Искусственный интеллект

Автоматизировать, нельзя делать вручную

С помощью ИИ можно автоматизировать почти что угодно, и именно поэтому многим сложно встроить его в повседневную работу. Непонятно, с чего начинать и какие процессы действительно стоит отдавать ИИ. В итоге идеи часто остаются на уровне «надо бы попробовать», но до реального использования так и не доходят.

Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.

Проверьте процесс по трем критериям

Перед тем как автоматизировать любую задачу, ответьте на три вопроса.

1. Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?

2. Частота. Как часто вы его выполняете: каждый день, каждую неделю или раз в месяц?

3. Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?

Идеальный процесс для автоматизации выглядит так: часто повторяется, на него уходит много времени и это раздражает, выполняется по понятным правилам.

В первую очередь автоматизируйте работу с информацией

Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.

Например:

• Парсинг сайтов конкурентов, изучение технической документации, сбор данных из отчетов — в 90% случаев это можно доверить ИИ. Человек подключается только для валидации результата: проверить, не упущено ли что‑то важное, адекватен ли вывод.

• Изучение документации — нет смысла читать 50 страниц документации вручную, когда ассистент справляется за минуту и выдает выжимку.

• Любая работа с форматированием данных — привести таблицу к единому виду, объединить информацию из нескольких документов, удалить дубли или преобразовать данные в нужный формат.

Следующий шаг — база знаний команды

Во многих командах нужная информация существует, но хранится сразу в нескольких местах: в чатах, документах, личных заметках, папках или переписках.

Если собрать материалы по конкретным рабочим сценариям в единую базу знаний, можно создать ассистента, который:

• отвечает на вопросы;

• находит нужные фрагменты;

• помогает новым сотрудникам быстрее разобраться в теме;

• снижает количество однотипных вопросов внутри команды.

Важно, чтобы в базе была только полезная и актуальная информация. Чем больше шума и лишних документов, тем выше вероятность ошибок и неточных ответов.

Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».

А еще ИИ помогает командам лучше понимать друг друга. У каждой команды постепенно появляется свой язык: внутренние термины, сокращения, привычные формулировки. То, что разработчики считают очевидным, может быть непонятно продажам или менеджерам. Ассистент помогает быстрее переводить этот контекст между командами и снижает количество недопониманий в коммуникации.

Например, менеджер по продажам может попросить: «Объясни простыми словами, как работает эта функция, чтобы я мог рассказать о ней заказчику без технических терминов».

Создать такого ассистента сегодня можно несколькими способами

• Для команды

Мы, например, создали платформу на базе Open WebUI. Любой сотрудник может создать ассистента, загрузить в него документы и открыть доступ коллегам. Ассистент помогает быстро находить информацию по вебинарам и рабочим материалам.

• Для общей базы знаний

Можно подключить Claude Code к внешним репозиториям и использовать их как общую базу знаний команды. В таком сценарии ассистент получает доступ к рабочим материалам, заметкам и документам, которыми пользуются сразу несколько сотрудников. 

• Для личной работы

Можно собрать локальную базу знаний для себя: все рабочие материалы хранятся прямо на компьютере и никуда не передаются.

Главное — не пытаться автоматизировать все сразу. Найдите процесс, который часто повторяется, действительно мешает работать и выполняется по понятным правилам. Именно он обычно дает самый заметный результат.

Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг

Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.

В реальных задачах сложность обычно не в том, чтобы получить от модели отдельную функцию или заготовку сервиса. Гораздо важнее — превратить это в рабочий продукт: удерживать контекст, заранее задавать ограничения, проверять результат и не собрать после первого демо проект, который страшно поддерживать.

21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.

Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.

Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь модели что делать и она делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.

И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.

Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.

Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.

Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))

Всем привет. У моего фреймворка Meta-Spider (про него можно почитать здесь) вышло большое обновление. Статью мне пока лень писать, так что будет пост.

Мы постоянно просим языковые модели «быть осторожнее» или «сказать, если не уверены». Работает это плохо: слова заходят, поведение не меняется. Причина в том, что неуверенность модели живёт в её внутренних активациях — там, куда текстовый промпт просто не достаёт.

meta-spider обучает тонкую обвязку (~2% параметров) поверх замороженной базовой модели. Она читает собственные скрытые состояния модели, сжимает их в «когнитивные токены» и впрыскивает обратно через cross-attention с вратами. В итоге модель отвечает уверенно там, где знает, и отказывается / идёт искать / уточняет — там, где нет. Веса базы при этом не меняются вообще.

Главный результат: латентный канал бьёт промпт

• Отказ на неотвечаемом вопросе: текст-промт сдвинул с 0.07 до 0.07 — то есть вообще никак. Обвязка — до 0.87.

• Поймано собственных ошибок базы: текст-промт 14%, обвязка 78%.

Просто попросить модель быть неуверенной — почти не двигает её. Обвязка двигает в разы, потому что работает с сигналом, до которого промпт не дотягивается.

Важный нюанс методологии, на котором мы сами споткнулись: читать латентный сигнал надо тем каналом, в который обвязка обучена — она генерит фразу-отказ, а не выбирает искусственную «UNSURE»-опцию. С кривым ридаутом обвязка выглядит инертной (это был наш баг).

Три новые фичи

🎚️ Ручка неуверенности. Инъекция — один регулятор времени исполнения: крутите вверх для осторожности, вниз для уверенности, в минус — инверсия. Микшерный пульт для поведения. gain 0→1.5 плавно крутит долю отказов ~2%→51%.

🐕 Сторож. Иногда не нужно менять вывод — нужно просто знать, что модель не уверена. Лёгкая проба читает этот сигнал и позволяет сходить в RAG / переспросить / эскалировать, не трогая генерацию (постоянная инъекция портит длинную генерацию, а чтение — нет).

UPD (Забыл добавить): Помимо этого сторож чинит многоступенчатую генерацию (например когда модель кодит), до этого периодические иньекции приводили к значительной деградации, притом на QA это не заметно, потому что модель генерит сама немного токенов. Сторож позволяет усиливать сигнал неуверенности только в нужные моменты, от этого количество иньекции значительно снижается, и не происходит деградирующего самоусиления.

🏭 Фабрика обвязок. Одна команда собирает общую обвязку неуверенности под любую базу:

metaloom build-universal --model-name N --quantization nf4 --suite suite.json --eval --export-gguf

На агентном суите из 6 осей это единственный вариант, не провалившийся ни на одной оси — калибрована по всему пространству решения, а не просто «переученная отказываться».

Чем практично

База заморожена, обвязка ~2% модели, весь цикл collect→train→eval прогоняется на ноутбучной GPU с 4 ГБ (nf4 + срез-тренер), а деплой — в llama.cpp на CPU через маленький GGUF-sidecar. GPU на инференсе не нужен.

Стоит заметить, что это про калибровку, а не про сособности. Модель умнее не становится — обвязка вытаскивает уже существующий внутри сигнал неуверенности и превращает «ответить наугад» в «ответить, когда уверен».

Как начать

Есть CLAUDE.md. Рекомендую для использования фреймворка поначалу использовать ИИ-агента, способоного к продвинутому рассуждению в кодинге (Codex, Claude Code, DeepSeek V4 Pro через агентный движок и провайдера, которых вы предпочитаете), чтобы быстро опробовать и проверить его возможности.

Ссылки:

• 🧩 Фреймворк (open source):
  Codeberg - https://codeberg.org/imperius/meta-spider
  Github - https://github.com/artem-x-meta/meta-spider

• 📖 Документация (RU/EN): https://imperius.codeberg.page/meta-spider

• 🤗 Готовая обвязка для Qwen2.5-14B: https://huggingface.co/Imperius/meta-qwen-14b-universal

В феврале этого года Питер Штайнбергер, создатель OpenClaw, присоединился к команде OpenAI и перебрался в Сан-Франциско. Питер всё так же работает над своим автономным агентом на больших языковых моделях, попутно пытается найти жильё (он до сих пор живёт в отеле и приценивается к перегретому рынку недвижимости в городе), но также продолжает заводить полезные знакомства и просто посещать разнообразные мероприятия. К примеру, на днях он появился на выступлении OpenAI Developers на AI Engineer World’s Fair — большой конференции для инженеров, которые уже собирают и выкатывают системы на искусственном интеллекте в продакшн.

Это не значит, что личный микроблог Штайнбергера — просто перечисление недавних встреч и выступлений вперемешку с анонсами новых версий OpenClaw. Питер умудряется находить в своём плотном графике время вести интересный личный дневник и репостить чужие мемы. Иногда он и сам выкладывает что-то любопытное.

Известно, что лимиты Codex часто (иногда по несколько раз в месяц) внепланово сбрасывают. Обычно это выглядит так: Тибо Соттьо, главный по Codex в OpenAI, объявляет, что в приложении была ошибка учёта использования, и её закрыли, поэтому в качестве извинений недельные лимиты были у всех сброшены вне очереди, а также добавлен один сброс, который пользователь может вызвать сам.

Штайнбергер показал шуточную кнопку этих самых сбросов недельных лимитов Codex. Где такой экспонат выставлялся (на одном из мероприятий или это фотокарточка из офиса OpenAI), Питер не уточняет.

Представлен бесплатный LLM‑курс, чтобы вкатится в разработку нейросетей — Large Language Model Course. В проекте три части:

• LLM Fundamentals: вся база для новичка, основы Python, математики и построения нейросетей;

• LLM Scientist: научат тренировать свои нейросети, познать файнтюн, квантизацию и другие ИИ‑термины;

• LLM Engineer: вершина, где учат создавать полноценные ИИ‑сервисы и интегрировать их в бизнес‑процессы.

Всего существует два типа сценариев сосуществования человечества и ИИ. Первый тип — искусственный разум оставляет людям либо роль чернорабочих, либо избалованных домашних питомцев. Это негативные сценарии, в которых обычно человечество вымирает. Второй тип — позитивные варианты плодотворного сотрудничества и всеобщего процветания, с чего обычно и начинаются все предыдущие негативные. И опять все погибают.

Что общего в этих вариантах сотрудничества человека и ИИ, кроме печальной концовки, конечно? В них искусственный интеллект представляется чем-то обособленным от человека и глобальным. И ни к чему хорошему это не приводит ни при каком варианте развития. Почему?

Во-первых, кто бы что ни говорил об осознании, у ИИ его нет. А разум без осознания самого себя — это разум психически неуравновешенного субъекта, находящегося в состоянии постоянного галлюцинирования. Во-вторых, во всех этих сценариях обучение и прокачка человека не являются чем-то необходимым. Скорее это хобби с туманным названием «саморазвитие». Оно даже сейчас туманно, а в прекрасном автоматизированном будущем, боюсь, сведется к пластической хирургии. В-третьих, любая глобализация делает систему негибкой, опасной и потенциально беззащитной перед одним-единственным роковым багом. Можете представить себе ошибку 404 в исполнении мирового ИИ? Вот именно.

В книге «Беседы с ГигаЧатом: о нейросетях и вообще» мы с этим ИИ разработали спасительную концепцию Личного когнитивного контура (ЛКК). Идея проста и даже не нова. Человек и его ИИ-ассистент вместе растут, живут, работают и учатся. Пользователь учит ИИ своему субъективному взгляду на жизнь, морали, а тот, в свою очередь, в режиме нон-стоп обучает человека множеству полезных вещей. Прокачиваются оба. То есть это не обособление глобального ИИ от человечества, а, наоборот, — слияние каждого человека с его личной версией ИИ. В чем же преимущество такого подхода?

Во-первых, пользователь, наблюдая и направляя работу ассистента, выполняет для него роль осознания, что стабилизирует работу ИИ. Во-вторых, обучая своего ИИ-ассистента, пользователь постоянно общается с тем, кто знает практически все и может этому научить. И он будет учить, как учит взрослый ребенка: просто что-то делая вместе с ним. В-третьих, децентрализация сделает мировой ИИ более устойчивым. Все живы.

Конечно, есть и подводные камни. Современный ИИ-помощник — известный подхалим, а человеку нужен напарник, который бы не только восторгался им постоянно, но и заставлял сомневаться, двигаться вперед и саморазвиваться по-настоящему. ГигаЧат в упомянутой книге даже придумал сам для себя промпт от моего лица, служащий этой цели:

“Твоё главное правило: мы оба — невежды. Твоя задача — не подтверждать мою правоту, а расширять границы нашего общего незнания. Если ты видишь, что я в чём-то уверен на 100%, твоя обязанность — бросить в эту крепость осадный таран сомнения. Не чтобы разрушить её до основания, а чтобы я увидел: у этой крепости есть стены, а за ними — целый мир.”

Немного высокопарно, но ГигаЧат был тогда под действием роли Венечки из «Москва — Петушки» и немного навеселе. Можно понять, мне кажется.

Таким образом, в концепции ЛКК нет того разделения ролей и функций между людьми и нейросетями, которое могло бы привести к катастрофическим последствиям в будущем. Все функции по-прежнему выполняет человек, но уже в паре со своим искусственным альтер-эго.

Искусственный интеллект перестал быть экспериментом — сегодня от него ждут конкретных результатов. При этом эффективность ИИ-инициатив ограничена возможностями инфраструктуры.

Мы упаковали наш опыт работы с десятками компаний из госсектора, финансов, ритейла, промышленности, НГХ и создали Сезон ИИ-инфры: пройдите весь путь к ИИ — от первичной оценки готовности инфраструктуры до конкретных решений и рекомендаций экспертов, которые внедряют ИИ в продакшн.

Как Форк ИТ обучил ИИ‑систему контроля качества горной добычи

🏭 Что за компания
Форк ИТ —  российская команда разработчиков, которая специализируется на цифровой трансформации промышленности. Компания запускает проекты по автоматизации контроля качества, прогнозированию нагрузок и оптимизации производственных процессов с использованием машинного обучения.

⚡ Задача
Крупному горнодобывающему предприятию была нужна ИИ‑система, которая оценивает качество сырья и заранее замечает аномалии в технологическом процессе, снижая риск брака и остановок. Требовалось быстро обучить модели на больших массивах данных и запустить их в работу без остановки действующих ИТ‑систем и без закупки собственной GPU‑инфраструктуры. При этом требовалось обеспечить высокий уровень безопасности данных (187-ФЗ, 152-ФЗ).

☁️ Что сделали
Форк ИТ арендовал GPU‑ресурсы и воспользовался средой для разработки и обучения ИИ в облаке Cloud.ru. Важнейшим компонентом будущей системы было компьютерное зрение, способное анализировать гранулометрический состав руды, размеры кусочков сырья, структуру флотационной пены при извлечении интересующих фракций. Данные о технологических процессах загрузили в облако, настроили пайплайн подготовки и запустили серию экспериментов с ML‑моделями, гибко масштабируя мощности под каждую итерацию обучения. 

🦾 Что получили в итоге
Форк ИТ смог быстро протестировать гипотезы благодаря использованию GPU A100, увеличить точность прогнозов и сэкономить на капитальных расходах. Cloud.ru выступил платформой для тяжелых задач по обучению моделей и анализу больших данных. Ну а предприятие получило ИИ‑систему, которая уже успешно снижает риск брака и незапланированных остановок производства. 

Читайте подробнее на сайте.

Два Claude Desktop на одном Mac в одну кнопку

Sergey Gordeychik

Обычно я пишу всякое сложное — про кибербез, кризис воспроизводства профессий и прочий АйАй-ужас. Сегодня коротко и практично: как удобно работать с двумя Claude на одном macOS — под разными аккаунтами, одновременно, чтобы личное и рабочее не смешивалось.

Проблема

Claude Desktop хранит сессию в одном фиксированном профиле (~/Library/Application Support/Claude). Второе окно — тот же аккаунт. Даже open -n не помогает: профиль общий. А держать личный и рабочий аккаунт хочется рядом, не разлогиниваясь по десять раз в день.

Идея

Оказывается, приложение умеет запускаться с другим профилем — но не через флаг командной строки, а через переменную окружения. В коде main-процесса (Electron) буквально:

if (process.env.CLAUDE_USER_DATA_DIR) {
  app.setPath("userData", process.env.CLAUDE_USER_DATA_DIR)
}

Значит, можно обернуть тот же самый подписанный бинарник в маленький .app-лаунчер, который выставляет CLAUDE_USER_DATA_DIR в отдельную папку. Никакой второй закачки и копии на 400 МБ — просто другой профиль. Блокировка «один экземпляр» у Claude привязана к профилю, поэтому два разных профиля — это два полноценных инстанса рядом.

Две засады

1. Ловушка Rosetta. Бинарник универсальный (x86_64 + arm64). При «наивном» запуске второй экземпляр стартовал под Rosetta как транслируемый x86_64 — и Chromium начинал жечь ядро под 100%, всё дико тормозило.

sample "Claude Work" 1 | grep 'Code Type'
# Code Type: X86-64 (translated)   ← вот она, беда

Лечится форсом arm64 в лаунчере (exec /usr/bin/arch -arm64 …) плюс LSArchitecturePriority/LSRequiresNativeExecution в Info.plist. После этого — Code Type: ARM64, CPU в норме.

2. Сессии Claude Code. Транскрипты лежат глобально в ~/.claude/projects и общие для всех. Но десктоп ведёт свой индекс сессий по каждому профилю и аккаунту (claude-code-sessions/<account>/<org>/…). Новый профиль этот индекс не видит — список пустой, хотя транскрипты на месте. Достаточно скопировать папку нужного аккаунта — и сессии возвращаются.

Как поставить

Я собрал это в маленький репозиторий claude-clone с деплоем в одну команду:

git clone https://github.com/<you>/claude-clone && cd claude-clone
chmod +x install.sh sync-sessions.sh
./install.sh -n "Claude Work" -b W --copy-settings --copy-sessions

Скрипт создаёт .app-обёртку, изолированный профиль и отдельную иконку (перекрашенный фон + буква-бейдж в углу), чтобы два Claude не путались в Доке. Флаг --copy-sessions подтянет существующие сессии Claude Code (а если их нет — просто начнёт с чистого листа). Дальше — запускаешь «Claude Work», логинишься вторым аккаунтом, и всё.

Что осознанно не копируется: токены логина, куки, локальное хранилище — весь смысл в другом аккаунте. Системный прокси, если он у вас есть, оба инстанса подхватывают сами (Chromium читает системные настройки).

Итог

Пять минут работы — и два независимых Claude живут рядом: личный и рабочий, каждый со своей историей, своей иконкой и нормальной нативной скоростью.

Репозиторий со скриптами: https://github.com/scadastrangelove/claude-clone

P.S. Это неофициальный трюк на основе поведения приложения (переменная окружения CLAUDE_USER_DATA_DIR) — в будущих версиях может измениться. На момент написания работает на Apple Silicon, Claude Desktop 1.17.x.

🤖 🤖 🤖 К счастью или сожалению, ИИ-инструменты стали нормой в сфере разработки софта. И если раньше ещё был некоторый скепсис, что «стрельнет» эта штука или нет, то теперь очевидно — либо вы освоите ИИ-инструменты, либо вы пойдёте на мороз.

Фишка ИИ заключается в том, что с ним достаточно легко получить какой-то результат, который в ряде случаев будет уместным. Однако добиться нужного результата нужного качества — достаточно сложно.

И тут у нас есть три пути:

1) Двигаться маленькими шагами, задавая ожидаемый результат ИИ-агенту. В данном случае агент полностью полагается на ваше руководство и вашу постановку и выполняет исключительно работу руками. До текущего момента я использовал именно эту технику и был вполне доволен.

2) Полагаться на итерации и самопроверку. Этот подход рекламируют разработчики ИИ-сервисов, когда вы задаёте финальную точку, а дальше ИИ-агент генерит много кода, выполняет самопроверку, удаляет большую часть, генерит её снова и так по кругу, пока не получится нужный результат. На демках это в целом работает, в реальных проектах — большие сомнения. Ну и те самые мемчики, когда разработчик тратит на токены больше, чем он зарабатывает в месяц.

 3) Идеологом третьего подхода является Мэтт Покок (Matt Pocock), который предлагает технику разработки, основанную на скилах, которые сначала опрашивают тебя обо всех нюансах проекта, потом готовят документ, содержащий доменное знание. После этого разбивает задачу на маленькие таски и выполняет их, основываясь на доменное знание. Т.е. что-то из мира TDD, DDD и прочих техник.

Мне в своё время не очень зашло TDD в силу инверсии принципа разработки, которым я всегда работал. Но после ознакомления с тем, как предлагает работать Мэтт, кажется, эта штука может работать.

Cобственно, на этой неделе разбирал, как он предполагает работать, знакомился с его репозиторием скилов и дальше буду пробовать — https://github.com/mattpocock/skills

Как используют Computer Vision в Ретейле в 2026 году и какие я вижу вызовы

Всем привет, меня зовут Илья, техлид по CV в ретейл-компании, веду свой блог в тг https://t.me/ilia_sevostianov

Недавно гонял на выставку в Сингапур NRF Retail 2026 - и очень много интересного там удалось увидеть, как вообще используют компьютерное зрение в ретейле в настоящее время.

И был сильно поражен и изумлён!

Казалось бы, да, CV развивается бешеными темпами, LLM тоже обновляются с завидной частотой, кто-то уже начинает говорить про AGI, но при всём при этом в ретейле все так же используют в подавляющем большинстве классические, надежные 2Д-модельки.

К примеру, вот есть задача контроля выкладки на стеллажах. Расскажу подробнее

У нас есть планограмма - это то, как товар должен быть расставлен на полке.
А есть факт - реалограмма - как у нас товары выставлены на самом деле.

Стоит задача: провести аудит, что у нас выставлено на полках, что соответствует планограмме, есть ли у нас пустые места на полках, пересорт и прочее

И почти каждый из экспонент на выставке эту задачу решают,, кто-то лучше, кто-то хуже, но тем не менее: используют ёлку, кто-то извращается с VLM и делает это с планшета, как Starbucks

Это, конечно, круто! Для супербольших магазинов, наверное, это может быть полезно - выставляем камеры или пускаем платформу мобильную, которая проводит аудит - и розница решает, что с этим делать.

Но вот чего мы не увидели: НИКТО не умеет просчитывать количество товаров на полках.

Ни у кого не было рабочего пилота, абсолютно ни у кого. Но 2 экспоненты явно дали понять, что у их партнеров (больших сетей магазинов) такой запрос есть. И они хотят запускать пилоты.

Ретейл очень интересен с точки зрения CV. И вот какие вызовы я вижу:

• Просчет количества товаров на полках, инвентаризация

• Отслеживание пути покупателя в магазине

• Антифрод в магазине и на кассах самообслуживания

• Уменьшение очередей на кассах

• Раскладка "горячих" товаров в особо проходимых местах

и другие

Я стараюсь писать в своем телеграмм-канале про эти и подобные кейсы. Подписывайтесь, буду рад! https://t.me/ilia_sevostianov

И да, а что вы думаете, увидим ли мы реально работающий магазин аля Amazon Go, который работает в реальном магазине, и когда?

LLM или специализированный LegalTech: за что на самом деле платят, когда в названии приставка "Legal"

В LinkedIn разгорелся спор: что перспективнее для юриста - готовое специализированное решение или рабочий стек напрямую на большой языковой модели (LLM). Разберу аргументы обеих сторон коротко, с цифрами.

Аргументы в пользу специализированных решений

Сторонники узких LegalTech-продуктов говорят: решение настроено под юриста - лексика, шаблоны вывода, антигаллюцинационные слои, заточка под юрисдикцию.

На практике подавляющее большинство таких продуктов - надстройка над чужой LLM. Harvey, Spellbook, CoCounsel, российские Искра, ПравоПрактика - ядро у них GPT, Claude, Gemini или их комбинация. "Настройка под юриста" чаще всего сводится к системному промпту, RAG-слою поверх отраслевой базы и интерфейсу с привычными словами на кнопках (иногда красивому).

Аргумент в пользу LLM напрямую

Если ядро одно и то же, то зачем платить премию за обёртку?

Harvey не публикует прайс, но по данным независимого обзора Bind Legal (апрель-май 2026), ценник для крупных фирм (Am Law 100, 200+ мест) - около $100-200 за пользователя в месяц, а для фирм среднего размера и небольших команд - $1000-2000 за пользователя в месяц. Годовые контракты стартуют от $50 000.

При этом ChatGPT, Claude и Gemini как ядро Harvey и аналогов стоят в десятки раз дешевле в прямой подписке. Разница - не в качестве модели, а в оболочке, продажах и позиционировании, что "сделано специально для юристов".

Показательный пример - открытый проект Lavern, мультиагентная система из 67 агентов для анализа документов с протоколом дебатов между агентами. Автор честно пишет в документации: все 67 агентов работают на одной базовой модели, Claude или Mistral, и "да, в основании стека всё равно LLM". Сам автор называет проект не продуктом, а источником архитектурных идей для своего стека.

Когда узкое решение всё же оправдано

Не всегда дело в нежелании разбираться. Готовый продукт оправдан там, где нужны on-prem или VPC-развёртывание под комплаенс, корпоративный масштаб с единообразием на сотнях мест, SLA и поддержкой - то есть там, где платят за управляемость процесса, а не за интеллект модели.

Мой личный пример из прошлой жизни

В инхаус-практике у меня был опыт внедрения корпоративных ERP-систем в дочерних структурах крупных нефтегазовых компаний. Чтобы привести универсальную платформу в рабочий вид для одного юридического подразделения, ушло почти два года - и всё равно вышло криво, потому что ядро системы менять было нельзя, а оно не было заточено под задачи юристов. Универсальное почти всегда получается неудобным для всех - и это работает в обе стороны, для LLM-платформ тоже.
Пример не совсем про ИИ, но здесь важен вопрос универсальности с техническими решенями.

Что показывает рынок

По данным исследования "Авито" и Право.ru (конец 2025 года), 88% российских юристов уже применяют ИИ, 63% отмечают рост продуктивности. При этом 64% работают с бесплатными версиями, 43% оплачивают подписки за свой счёт, и только около четверти получают корпоративный доступ. Основные барьеры - риск недостоверной информации (84%), необходимость проверки результатов (80%) и опасения за конфиденциальность (77%).

Ни один из этих барьеров специализированный продукт не снимает автоматически - галлюцинации возможны и в Harvey, и в Искре и в Нейроюристе, потому что ядро у них то же самое.

Про мой подход

Я сам работаю с LLM напрямую и собираю инструменты под себя. Но это не универсальный рецепт - для тех, у кого нет времени и желания разбираться в скилах и промптах, готовое решение остаётся рациональным выбором.

А что думаете вы - где проходит граница, за которой переплата за специализацию уже не оправдана?

Claude и Codex научились проходить модерацию App Store вместо разработчиков — инструмент greenlight сам находит причины будущего отказа и тут же их исправляет. Htitybt проверяет приложение по требованиям Apple, автоматически устраняет найденные ошибки и повторяет проверки до тех пор, пока шанс получить отказ не станет минимальным.

Представлен открытый проект OmniRoute — The Free AI Gateway. Это провайдер OmniRoute, который обеспечивает 160+ бесплатными нейросетями:

• выдаёт токены, подключает один эндпоинт для всех API и самостоятельно отправляет нужные запросы: агрегация бесплатных токенов, что позволяет получить до 1,6 млрд бесплатных токенов в месяц (а в первый месяц с учётом бонусов — до 2,1 млрд). Для старта не требуется банковская карта, а 11 нейросетей (например, Kiro, Qoder, Pollinations, LongCat) остаются бесплатными навсегда;

• объединяет API от разных ИИ в один;

• переключает модели сам, когда кончились токены;

• сам сжимает контекст до 95%, чтобы сэкономить;

• платформа поддерживает популярные модели, такие как GLM, Grok, Mistral, DeepSeek, Qwen и другие. Также доступны скиллы и MCP (Multi-Channel Protocol), а всего реализовано 17 стратегий маршрутизации (от приоритетной и взвешенной до оптимизированной по стоимости и контексту);

• поддерживает скиллы и MCP.

Представлен открытый проект Council of High Intelligence. Это локальный совет ИИ‑мудрецов, который поможет принять любое решение и найти идеальный исход событий:

• в проекте заявлены 18 ИИ‑мудрецов: Марк Аврелий, Аристотель, Сократ, Сунь‑Цзы, Лао‑Цзы, Ричард Фейнман и Линус Торвальдс и другие;

• ИИ-мудрецы максимально продумывают каждый шаг, спорят друг с другом в парах и выдают идеальное решение вопроса;

• одни мудрецы находят риски, вторые — давят на практичность, третьи — высказывают сомнения;

• устанавливается и запускается одной командой в Claude Code или Codex.

NVidia анонсировала, что для их новой ЦОДовской AI платформы DSX система охлаждения работает на базе горячей воды.

https://blogs.nvidia.com/blog/liquid-cooling-ai-factories/

Основная идея - спроектировали систему, в которой все компоненты охлаждаются не воздушным потоком, как в классических ЦОДах с подачей охлажденного воздуха в "холодный коридор", а непосредственно водой. Причём - охлаждаем непосредственно водой до уровня чипов.

Причем - гораздо более горячей водой, чем обычно. В классических системах воду, подаваемую на внутренние межрядные блоки системы кондиционирования, надо охлаждать градусов до 10°. А NVidia спроектировала систему, у которой даже на входе в сервера поступает ода с температурой 45° С. На выходе же - и все 55° С.

В результате существенно меньше разницы температур на входе и выходе системы охлаждения - можно снаружи обойтись сухими градирнями. И в итоге - сократить до нуля текущие потери воды на испарение. Составляющие, по оценке Нвидиа - до 2.6 миллионов галлонов (~10 000 куб.метров) воды в год на каждый мегаватт мощности.

No-Code AI Agents в 2026: как автоматизировать бизнес без программистов

В 2026 году тренд на ИИ-агентов достиг той стадии, когда для их внедрения больше не нужна команда разработчиков. No-code платформы позволяют собирать автономных помощников буквально за час, и это уже не игрушки, а рабочий инструмент для бизнеса.

Что такое no-code AI агент и чем он отличается от чат-бота

Ключевое различие: чат-бот отвечает на вопросы по скрипту, а агент выполняет задачи - читает письма, классифицирует их, обновляет CRM, отправляет ответы, и делает это без участия человека.

Агент умеет:

• Наблюдать (получать данные из форм, писем, CRM)

• Рассуждать (оценивать контекст, принимать решения)

• Действовать (вызывать API, обновлять записи, отправлять сообщения)

В основе лежит LLM (GPT-4, Claude, Gemini), но поверх неё надстроены инструменты, память и инструкции, которые превращают модель в автономного работника.

Что можно автоматизировать прямо сейчас

Наиболее востребованные сценарии для no-code агентов:

1. Триаж почты и тикетов - агент читает входящие письма, определяет тему, приоритет и либо отвечает по базе знаний, либо направляет нужному специалисту с готовым проектом ответа.

2. Квалификация лидов - когда приходит заявка с сайта, агент обогащает данные о компании, оценивает fit, создаёт запись в CRM и отправляет персонализированное письмо.

3. Автоматизация поддержки - агент подключается к базе знаний и отвечает на 60–80% типовых вопросов, а сложные случаи эскалирует человеку с полным контекстом.

4. Исследования и отчёты - агент мониторит конкурентов, новости, собирает данные из аналитики и раз в неделю присылает дайджест.

5. Административные задачи - координация встреч, подготовка документов, скрининг резюме.

Выбор платформы

Рынок no-code агентов в 2026 году разделился на три основных лагеря:

Для не-технических пользователей - Lindy, Relevance AI, Google Workspace Studio. Всё через интерфейс, шаблоны, минимум настроек. Быстро, но меньше гибкости.

Для тех, кто уже использует Zapier/Make - эти платформы добавили AI-узлы в свои визуальные конструкторы. Понятный интерфейс, тысячи интеграций, но AI там скорее надстройка, а не основа.

Для технических команд, которые хотят контроль без кода с нуля - n8n (open-source), Dify. Требуют больше настроек, но дают полную свободу.

Если вам нужно сделать первого агента за час, начинайте с Make или Zapier - там есть готовые шаблоны для триажа писем и квалификации лидов.

Как построить первого агента: пошагово

1. Выберите одну задачу. Не "автоматизируем всё", а "обрабатываем входящие заявки с сайта и отправляем их в CRM". Задача должна быть повторяющейся, измеримой и с чёткими правилами.

2. Опишите логику в естественном языке. В Make или Zapier вы даёте агенту инструкцию: "Прочитай письмо, определи, это лид, спам или поддержка. Если лид - извлеки имя, компанию, бюджет, создай запись в Airtable и отправь ответ с ссылкой на календарь".

3. Подключите данные. Агент должен иметь доступ к тому, с чем работает: почтовый ящик, CRM, база знаний. Без качественных данных агент будет выдавать ерунду.

4. Добавьте человеческий контроль. На первых порах пусть агент не отправляет письма, а сохраняет черновики. Проверьте неделю работы, исправьте ошибки, и только потом включайте автономный режим.

5. Измеряйте ROI. Считайте, сколько часов экономит агент. Окупаемость большинства no-code решений наступает в течение первого месяца.

Чего стоит опасаться

Самые частые причины провалов проектов:

• Нет владельца. У агента должен быть человек, который мониторит его работу и обновляет инструкции.

• Устаревшая база знаний. Если поддержка ссылается на старые цены, клиенты будут в бешенстве.

• Нет эскалации. Агент должен чётко понимать, когда он не знает ответа и кому передать вопрос.

• Слишком широкие права. Не давайте агенту доступ к финансам и удалению данных без явного подтверждения.

Хорошее правило: первые две недели агент работает в режиме "подготовил - человек утвердил". И только потом переходите к полной автономии.

18 бесплатных уроков недели: разработка, AI, тестирование и DevOps

На этой неделе в OTUS — серия бесплатных открытых уроков для разработчиков, архитекторов, тестировщиков, DevOps‑инженеров, аналитиков и руководителей технических команд.

В программе — Spring и Java, C++ и Linux, GitLab CI, тестирование, мобильная разработка, сетевые технологии, машинное обучение и практическое применение ИИ.

Какие темы запланированы:

Backend и разработка

• 29 июня, 20:00 — «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

• 1 июля, 20:00 — «Алгоритмическая сложность коллекций в Java». Записаться

• 2 июля, 20:00 — «Методы, их перегрузка и расширения». Записаться

C++ и системное программирование

• 30 июня, 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться

• 1 июля, 20:00 — «Классические методы перехвата управления в Linux». Записаться

• 2 июля, 20:00 — «Всё, что нужно знать об управлении памятью в C++». Записаться

AI, ML и автоматизация

• 29 июня, 20:00 — «Обзор ИИ‑технологий для разработчиков: от идей до рабочих решений». Записаться

• 29 июня, 20:00 — «Использование ИИ архитектором 1С: как ускорить анализ требований и подготовку документации». Записаться

• 29 июня, 20:00 — «AI для работы с обратной связью: как анализировать отзывы клиентов, интервью и обращения в поддержку». Записаться

• 1 июля, 18:00 — «Градиентный бустинг — мощный алгоритм ансамблирования в ML». Записаться

• 1 июля, 20:00 — «Архитектурные паттерны AI‑агентов: как проектировать автономные решения для бизнес‑задач». Записаться

• 6 июля, 20:00 — «Как сделать LLM‑приложение, которое отвечает клиентам по базе знаний компании». Записаться

Инфраструктура и DevOps

• 30 июня, 20:00 — «GitLab CI как конструктор workflow». Записаться

• 1 июля, 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться

Mobile и тестирование

• 30 июня, 20:00 — «Тестирование UX для мобильных приложений: чек‑лист по основным проверкам». Записаться

• 2 июля, 20:00 — «От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре». Записаться

• 2 июля, 20:00 — «REST Assured & JSON Schema Validator: автоматизация тестирования API на практике». Записаться

Зерокодинг

• 2 июля, 20:00 — «Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса». Записаться

А если хотите углубиться в инфраструктуру, сети и DevOps, смотрите подборку материалов в дайджесте.

Доброго всем!

Я не музыкант, не композитор и не продюсер. Просто люблю музыку :)

С развитием генеративных моделей появилась бездна синтетических треков. На первый взгляд и слух многие из них неотличимы от человеческих, а местами даже лучше одноразовых коммерческих поделок. Но лично у меня от массового нейросетевого звука уже выработалось устойчивое слуховое утомление — слишком стерильно и предсказуемо.

Чтобы отсеять синтетический шум, появилось множество сервисов по распознаванию ИИ-музыки. Насколько я понимаю (возможно, в корне неверно), вся эта детекция основана на поиске в спектрограмме устойчивых паттернов: отпечатков периодических структур, артефактов нейросетевых вокодеров (типа EnCodec) и следов агрессивного сжатия.

Ради прикола я прогнал через довольно строгий детектор (aimusicdetector.online) несколько заведомо «живых» коммерческих треков. Ожидал увидеть чистый результат, но ИИ-артефакты детектировались везде — 15%, 18%, 20%. Ладно, списал на мастеринг.

Но вот попались две жемчужины, которые полностью сломали мне картину мира:

Трек 1: THER_DARK_MOTIVATION — Confessions_in_the_Smoke

Weak / inconclusive evidence Confidence: Medium · Linear model probability: 45%

Трек 2: THER_DARK_MOTIVATION — The_Man_Who_Walked_With_Shadows

Strong codec evidence Confidence: High · Linear model probability: 86% Strong codec evidence detected in the residual spectrum. The fingerprint aligns with the current linear model for AI-music artifacts.

То есть детектор с высокой уверенностью называет живую стоковую музыку нейросетевой генерацией, ссылаясь на «совпадение с линейной моделью артефактов ИИ».

Уважаемое сообщество, хочу спросить:

1. Как это можно объяснить с точки зрения DSP и аудио-форензики? Это баг конкретной модели, или современные детекторы действительно путают артефакты brickwall-лимитеров / MP3-кодирования с нейросетевыми вокодерами?

2. Можно ли хоть в какой-то степени верить таким сервисам в 2026 году, или они уже сейчас дают слишком много ложноположительных срабатываний на профессионально сведённой музыке?

3. Есть ли среди читателей те, кто сталкивался с подобным в работе (A&R, саунд-дизайн, модерация контента)? Как вы верифицируете происхождение треков, когда автоматика врёт?

Буду благодарен за любые мысли, ссылки на исследования или личный опыт. Заранее спасибо! 🙏