Сколько ИИ-агентов нужно для счастья?

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

В чем идея?

Обычно, любые сложные процессы это синтез разных действий: сначала что-то почитал, потом понял, что прочитал, потом написал про это пост в тг… (а уже и GPT5 вышла)

Разумная мысль: давайте разные действия будут делать разные агенты. Один агент пишет код, другой агент тестирует. Тогда модели не будут распыляться. Каждая будет эффективна в своей узкой задаче.

Почему это почти всегда плохая идея

Тут 2 проблемы:

1) У всех агентов разный контекст. Каждый не в курсе, что делает другой. Есть риск, что агент-тестировщик пошел тестировать код, который агент-кодер уже признал легаси.

2) Так как контекст разный, вам придется делать какую-то синхронизацию. Дейлики для ИИ-агентов. Это и в реальном мире неприятно, ИИ-мир к такому не готов.

Когда это очень полезно

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

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

Нудный вывод

Не нужно пытаться напихать в проект побольше агентов.

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

Почти невозможно найти рабочие примеры архитектур мультиагентных систем. Обычно, пишут что-то вроде: "ну сделайте ИИ-бухгалтера, ИИ-программиста и объедините их в ИИ-семью". Брр.

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

Зачем тут мультиагенты?

Например, задача: "найти 100 конкурентов, выписать их выручку и позиционирование" (McKinsey на этом моменте напряглись, их хлеб). Человек пойдет задавать 200 тысяч запросов, переваривать тонну информацию, а потом долго писать отчет. Очень дорогая задача.

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

Дизайн архитектуры

Мы делаем систему с супер простой координацией агентов:

1) Есть агент-лидер, который бьет задачу на части и раздает подзадачи субагентам.

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

3) После завершения своих задач, субагенты отправляют результаты лиду. Лид всех ждет. Потом, если он считает, что тема разобрана, готовит финальный отчет. Иначе делает новые подзадачи и по новой.

4) Когда отчет готов, отдельный агент расставляет, из какого источника, что было взято.

Оценка качества

Ровно так, как рассказывал старина Сева.

1) LLM-as-a-judge на различные свойства: достоверность ответа, точность цитат полнота, качество источников.

2) LLM-ки ловили не все кейсы, так что частично оценивали людьми.

Коллеги выложили промпты всех 3-х агентов лид, субагент, цитирование.
Очень наглядная статья, просто бери и делай по аналогии.

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

#ai_cases

Сегодняшнее правило LLM-разработки сэкономит не только месяцы жизни, но и несчетное число нервных клеток. Мне точно сэкономило, хотя, может я просто нервный.

Правило 8. Сначала делайте прототип

Как делают обычно: придумали, как с помощь ИИ увеличить бизнес-метрику. И сразу пошли раздавать задачи инженерам: идите данные собирать да модели обучать. Чтобы метрика побольше стала.

Почему нельзя сразу в бой

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

2) В ИИ куча краевых случаев. Заранее прописать весь список в техническом задании невозможно. Но спустя полгода вы можете очень удивиться, что модель работает не так, как предполагалось.

Что такое прототип

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

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

Когда мы сделали прототип, мы переходим на следующий этап. Техническая команда, сохраняя его качество, снимает все другие ограничения. Например, ускоряет модели.

Как создать прототип по шагам

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

2) Тестовая выборка. В ней для всех входных в систему запросов вся команда точно понимает, какой правильный результат. Команде нужно до этого договориться.

3) Метрики качества на тестовой выборке. Подробнее в прошлом правиле.

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

По этой методике реально собрать рабочий прототип за несколько недель.

Литература для обязательного изучения

- Статья известнейшего специалиста (моя), в ней про это раздел.

- Гайд по быстрым итерациями. Это все нужно использовать на прототипе.

Тема нераспиаренная, но очень важная, полезного контента мало. Если остались вопросы — пишите в комментарии или в личные сообщения.


#llm_system_design

Урок по внедрению AI на полмиллиарда долларов

Меня один пример провала учит в 100 раз лучше, чем 100 историй успеха. Разберем классический кейс 2021 года: как IT-гигант Zillow потерял полмиллиарда долларов на AI-алгоритме.

Спойлер: проблема была вовсе не в алгоритме.

Контекст

Zillow — это медиа-платформа о недвижимости с оборотом $2.4 млрд. Это синоним поиска дома в США. Одна из ключевых фишек — "Zestimate": модель ИИ, которая предсказывает стоимость недвижимости.

В какой-то момент Zillow решила перевернуть игру. Раз у нас есть такая мощная модель, мы будем сами скупать дома по оценке ниже рыночной, делать косметический ремонт и перепродавать дороже. Может, они восхитились слайдом с метриками MSE от лида их тех. команды.

Что же может пойти не так? :)

Модель систематически переоценивала стоимость приобретаемых домов, в то время как компания агрессивно наращивала закупки. В итоге Zillow была вынуждена продавать дома с огромным дисконтом, получить $500 млн прямого убытка, закрыть программу и уволить 25% штата.

Реальная причина провала

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

Главная ошибка: Zillow использовали ИИ не чтобы улучшить свой бизнес, а чтобы сделать другой бизнес.

Их основная бизнес-модель — это классифайд: дешево привлечь аудиторию и дорого продать ее внимание агентам по недвижимости. Эту модель можно и нужно улучшать с помощью AI: в алгоритмах рекламы (самое важное), в поиске, в пользовательских фишках типа "Zestimate".

Но Zillow решила построить капиталоемкий, операционный бизнес по перепродаже активов. В этой нише есть свои успешные игроки (например, Opendoor), и они тоже применяют AI. Но они сначала досконально разобрались в самом бизнесе — в операциях, логистике, управлении рисками.

Сейчас я доделываю "12 правил внедрения LLM", но я совсем забыл правило 0: Встраивайте ИИ только в те процессы, которые вы досконально понимаете без него.

Сначала — понимание бизнеса и его точек роста. Затем — усиление узких мест с помощью AI. Никогда наоборот.

Пишите свои мысли в комментариях. Если есть вопросы, всегда можно задать в личке @seva_batareika

Купить интеллект из коробки

Очень хочется купить подписку на интеллект. Такую коробку, которую ты поставил рядом с бизнесом, и она сразу цену коробки стала отбивать.

Но нет. AI это не готовый продукт. Это скорее платформа, которую нужно настроить под ваши задачи. Если этого не понять — любое внедрение обернется провалом. Давайте теперь подробнее.

Отчет MIT о причинах провалов в AI

MIT выпустил отчет о состоянии внедрения генеративного AI в бизнес. Ничего хорошего, естественно, там нет: энтерпрайз массово закупает продукты, но всего 5 % из них достигают значимого экономического эффекта, профит от 95 % закопан где-то на слайдах. Почему так происходит?

По результатам исследования, 90 % сотрудников не доверяют свои объемные рабочие задачи ИИ. Топ-1 барьер: система не учится от нашего фидбека.

Цитата одного юриста из исследования, дословный перевод:

Она повторяет одни и те же ошибки и требует обширного контекста для каждого запроса. Для важной работы мне нужна система, которая накапливает знания и улучшается со временем.

Лучше и не скажешь.

Правда, в конце отчета они тоже говорят, что вот ИИ-агенты, вот это топ тема… Спишем это на текущую конъюнктуру.

Интеллект = Адаптация

Я за 8 лет работы с ИИ ни разу не видел рабочего и на 100 % коробочного решения. Всегда нужно что-то учесть под конкретный продукт.

Делаем поиск: «а что по этому запросу хочет наш пользователь найти? Ему здесь важнее цена товара, популярность, новизна?

Делаем суммаризацию отзывов: «а что в этом отзыве для нас самое главное? Что пользователь безумно рад товару или что доставка опоздала на 30 минут?

Мы всегда должны учесть наш продукт, наших клиентов, как нам удобнее всего с AI работать.

Как внедрять AI

Сначала прогнать от себя мысль, что AI это SaaS. Купил и сразу работает. Покупать можно и нужно. По тому же отчету MIT, компании, которые интегрируют AI вместе с партнером, в 2 раза более успешно его внедряют.

Но AI это скорее платформа. Вы покупаете систему, с которой вам нужно будет пройти последнюю милю. Покупаете у того, с кем вы хотите ее пройти.

После покупки кастомизация. Подключаете нужные источники данных и постоянно улучшаете систему. Через контроль качества, анализ ошибок и их исправление. Через дообучение/промптинг/RAG или как угодно еще.

И, конечно, обучение сотрудников. Как применять, как давать этот фидбек, как оценивать качество.

И так будет всегда. Никакой смузи-стартап c флотом ИИ-агентов не сделает жизнь ваших пользователей, сотрудников лучше, чем сделаете вы. Потому что только вы их знаете. Вы прошли с ними этот путь и без всякого AI.

Так что можно купить технологию. Но потом придется немного поработать.

Друзья, я тоже рад вашему фидбеку. Обязательно пишите ваши мысли или вопросы в личные сообщения @seva_batareika или в комментариях.

Как скинуть обработку тысяч документов на LLM. Кейс Uber.

Вот вы работаете с поставщиками. Поставщик выставляет вам счет за товар/услугу. Конечно, в виде PDF-ки на электронную почту. Очень удобно.

Можно все эти PDF-ки разгребать руками, а можно попросить это сделать LLM, как сделали коллеги из Uber. Давайте разберемся с этим кейсом.

Архитектура решения

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

По шагам:

1. Взяли PDF-ку, сделали из нее картинку, чтобы дальше применять CV-модели
2. Накатили на нее OCR-модель. Распознали текст.
3. Взяли текст, извлекли из него все нужные поля LLM-кой
4. В красивом интрфейсе показали сотруднику извлеченные поля. Он ОКает, либо правит (наш любимый human-in-the-loop)

Самой проблемной точкой мне видится связка OCR + LLM. На шаге OCR уже может накопиться большая ошибка. Можно сразу делать VLM. Например, вот дообученный qwen, который по картинке документа текст распознает. Или, например, VLM Gemini сразу умеет работать с PDF .

Какая LLM под капотом?

Пробовали дообучать опенсорс и просто промптить GPT-4. Удивительно, но промптить GPT-4 оказалось сильно лучше.

Вообще, довольно сложно на опенсорсе победить OpenAI на широких задачах, вроде разработки кода. Но в задачах типа выделение именованных сущностей, классификации это обычно довольно просто (вот пруф).

Странно, что у коллег не получилось. Хотя, они использовали довольно слабые опенсорс модели, вроде Flan T5. Надо было на дипсике пробовать 🙂

Результаты

На первый взгляд, все благополучно. Средняя точность около 90%. В 2 раза сократили ручную обработку документов и на 70% сократили среднее время обработки.

Теперь чуть-чуть подумаем. Допустим, у Uber тысячи поставщиков. И есть целый отдел, не знаю, из 15 человек, который только обработкой счетов и занимается.

Такой проект LLM-автоматизации, если делать все с нуля (и сразу хорошо), делать несколько месяцев отдельной командой инженеров. Как думаете, он окупится?

Что нужно изменить

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

AI-команда делает платформу по автоматизации. Там должны быть инструменты: как писать промпты, как оценивать качество, как собирать датасеты, как потом это деплоить и мониторить качество.

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

Хороший, качественно сделанный пример внедрения LLM с понятной пользой. Главное, чтобы это был только первый шаг, а не конечная точка.

#ai_cases

Как сделать LLM лучше OpenAI, потратив всего 8 долларов

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

Статья, как дешево и сердито дообучать опенсорс

В статье коллеги взяли 31 NLP задач, в которых есть обучающая и тестовая выборки. Взяли 10 опенсорс LLM. Дообучили эти модели под все задачи, получили 310 новых LLM.

В итоге эти модели оказались в среднем на 10% лучше, чем GPT-4. При этом по числу параметров они в 1000 раз меньше. Обучали модели с помощью LORA, но это неважно, аналогичный эффект получился бы с чем угодно.

Такое дообучение еще и очень дешевое, потому что обновляет не модель целиком, а обучает только адаптер. Одна модель авторам обходилась примерно в 8 долларов.

Как это возможно?

Самое важное разобраться, в каких задачах авторам было легко побить GPT-4, а в каких не получилось.

Невозможно победить на широких задачах. На задачах, где надо одновременно много всего знать и уметь. Например, чтобы решать бенчмарк MMLU, своеобразный ЕГЭ для LLM, надо знать кучу фактов. Или для генерации кода надо знать синтаксис и уметь им оперировать для кучи различных ситуаций.

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

Сэм Альтман хорошо понял законы масштабирования. Теперь он поднимает раунды, чтобы делать мега-модели, которые сразу хороши для всех.

Но вы то не все.

Алгоритм, как правильно дообучать опенсорс

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

2) Подумайте, широкая или узкая ваша задача. Если широкая — не надо ничего обучать, берите просто самый большой опенсорс и не думайте. Если к узким — можно дообучать. Как выбрать размер модели написано в моем гайде.

3) Первая итерация — Supervised Fine Tuning (SFT). Модель учится воспроизводить правильный ответ. Возможно, этого хватит и дальше лезть не придется.

4) Вторая итерация — Reinforcement Learning (RL). Модель награждают за хорошие ответы и ругают за плохие.

Дообучать можно адаптеры (LORA и ее друзья) или полным дообучением. В зависимости от количества данных.

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

Будьте рациональны.

Не надо дообучать модель в любом LLM-проекте. Проверьте, чаще всего все прекрасно работает на промпте + RAG. Тогда сильно сэкономите нервы.

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

12 правил разработки проектов с LLM

Давно не писал в канал. Не потому что забросил, а потому что писал свод правил по внедрению LLM. Попутно создал сайт, где я буду публиковать дальше статьи. Пока обошелся без AI, собрал на Тильде. Но AI консультировал по Тильде :)

В статье суммаризовал все правила внедрения LLM: про прототипирование, оценку качества, RAG, дообучение, оптимизации, агентов и про все все все, что вам может понадобиться. Читайте, делитесь с друзьями, делитесь мнением о прочитанном.

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

Еще очень важных новостей.

Мне сегодня стукнуло 30. Я уже совсем взрослый дата саентист. Если вы хотите меня поздравить, разберите статью из прошлого поста. Мне будет приятно.

И раз я теперь такой взрослый, пора становиться Всеволодом и менять название канала. «AI разбор» отличное название, именно этим я тут и планирую заниматься. А шутка про ИИнженера мне даже в начале не казалась особенно смешной.

И всем огромное спасибо за теплые слова и поздравления!

Aгент-аналитик для всех и каждого. Кейс компании Ramp.

Чтобы принять решение, нам нужна аналитика. Узнать, что покупали, куда кликали, что читали за прошлый день/месяц/год. Вопросы эти срочные. Отлично, если вы сами умеете в SQL. Хорошо, когда у вас свой аналитик. Ожидаемо, когда вы сделали задачу на аналитику, но не дождались ответа и все решили сами. Вот чтобы такого не было, финтех компания Ramp сделала агента дата-аналитика. Разбираем этот кейс.

Архитектура решения

Канал в Слаке, вы тегаете бота, задаете ему вопрос, агент уходит анализировать. Отвечает вам в треде, в этом же треде ему можно задавать доп. вопросы. Деталей, как работает агент, в посте немного, но все такие решения +- одинаково устроены.

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

2) По этой документации запускаем RAG. Находим релевантные базы данных. В контекст агента отправляем полное описание всех полей в базе. Про это читайте мое 5-е правило.

3) Агент пишет SQL-запросы. Запросы выполняются, результаты работы и ошибки отправляются на вход агенту.

4) Агент рефлексирует: все ли, что спрашивал пользователь он нашел? Если нет, можно еще поискать другие БД в пунте 2 или еще пописать SQL в пункте 3.

5) Если все нашли, формируем финальный ответ, показываем пользователю, ждем нагоняй конструктивную обратную связь.

Вот, кстати, неплохой туториал от Google по Text2SQL системам. Очень похожие идеи.

Бизнес эффект

Вы не оптимизируете работу аналитиков. Нет. Вы упрощаете сотрудникам доступ к информации для принятия решения.

В Ramp этому агенту задают 1500 запросов в месяц, а людям-аналитикам задают 66 запросов. Разница больше, чем в 20 раз. Это все те вопросы, которые люди боялись спрашивать или откладывали в длинный бэклог. Не трогай, это вопрос на новый год!

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

Основная проблема этого кейса

Ненадежность. Если по компании пойдет молва, что агент сгаллюцинировал, и из-за этого приняли неверное решение, это будет последний день этого агента. Нужна мощная система защиты от галлюцинаций (читайте правило 8). Мои варианты защиты от менее надежного к более:

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

2) Явная проверка. Вы делаете через бота предварительную разведку. Если хотите результаты анализа написать на слайде, делаете задачу на отдел аналитики. Они перепроверяют.

3) Copilot для аналитика. Не даем инструмент всем, а только ускоряем работу аналитиков. Они проверяют, что агент отработал адекватно.

Резюме

Из этого кейса нам нужно вынести 2 урока:

- ИИ это не только про автоматизацию. Это про демократизацию и более широкий доступ. Который в долгую может быть намного важнее.

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

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

#ai_cases

Как AI делает деньги.
Классический зарабатывает больше генеративного?

В 2024 компании инвестировали 250 млрд. долларов. Пошли внедрять GenAI на эти деньги, куда только можно, но 80% компаний не получили финансового эффекта. Зато внедрили, отчитались.

Почему все вкладывают деньги, но не получают выхлопа? И можно ли его вообще получить? Обсудим в серии постов «Как AI делает деньги».

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

Как на самом деле работает любой AI

Сейчас раскрою все карты нашей ИИ-ложи. Неважно, автоматизируете ли вы, ускоряете или делаете новый ИИ-продукт, по сути все одинаково.

У вас есть процесс, который вы хотите наделить этим самым интеллектом. У процесса есть входные данные (текст, картинка, видео, etc) и метрика, где мы понимаем, что выход процесса нам нравится. Дальше вы оптимизируете модель делать этот процесс под эту метрику. Все.

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

Какой AI зарабатывает больше

По оценкам McKinsey 70% потенциала влияния ИИ на мировую экономику, это классический ИИ и только 30% — генеративный. Это именно потенциал. Если даже все внедрить правильно, генеративный ИИ будет приносить денег меньше. Если вы постоянный подписчик, то понимаете, что внедряют чаще всего неправильно :)

Самые денежные процессы сейчас оптимизируются по старинке, без всяких LLM. Это, например:

- Рекомендательные системы

- Кредитный скоринг

- Видео аналитика на производстве

Это массовые изолированные процессы с моментальной обратной связью. Пользователь купил? Клиент вернул кредит? Оборудование исправно? Сама Вселенная хочет, чтобы мы поставили здесь модельку и научили ее делать это действие оптимальным образом.

А что с LLM?

В генеративном ИИ такие удобные процессы тоже есть. И они, очевидно, будут внедрены в первую очередь. Это, например:

- поддержка клиентов. Бот решил проблему?

- маркетинг. На письмо ответили?

- продажи. Встречу согласовали?

Но здесь таких процессов сильно меньше, чем в классическом AI. Тут мы много денег не заработаем.

Значит, зарабатывать нужно по-другому. Не как с классическим AI. Каким образом? Об этом расскажу в следующих постах. Там и вылезут наши любимые AI-агенты.

LLM уже решает реальные рабочие задачи, как человек? Бенчмарк от OpenAI

Недавно OpenAI опубликовала бенчмарк GDPval, в котором модели проверяют на способность выполнять экономически важные задачи, которые регулярно возникают в работе. Модели часто показывают паритет с человеком, а в некоторых задачах и сильно превосходят.

Как OpenAI проводили этот замер, пора ли хантить AI-сотрудников, поговорим в этом посте. Поехали.

Как замеряли модели

Взяли 44 цифровых профессии, на которые приходится больше всего денежных выплат в США. Эти профессии зарабатывают 3 триллиона $ в год.

Дальше рекрутировали экспертов в каждой профессии. Эксперт предлагал реальную задачу из своей практики. Задача это не только текст, но и картинка/видео/excel-файл и тд.

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

Результаты

- На 1-м месте Claude Opus 4.1 с винрейтом 47.6 % против человека.

- На втором GPT-5, которая побеждает человека в 38.8 % случаев.

- Дальше ризонинг-модели от OpenAI с чудовищным неймингом, и на 5-м месте Gemini 2.5 Pro. Маск даже не в пятерке :(

В бенчмарке есть много задач, с которыми LLM справляется лучше человека. Это, например, задачи из разработки, поддержки клиентов, продаж.

У вас могла возникнуть идея…

Пора переходить на AI-сотрудников?

Не пора. В эту ловушку попадал сам Джеффри Хинтон в 2016 году, когда сказал, что рентгенологи не нужны, ведь AI находит на снимках болезни лучше. С тех пор спрос на рентгенологов только растет. Почему?

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

Но работа рентгенолога целиком это огроменная композиция этих задач и постоянное переключение между ними в зависимости от текущей ситуации. Кстати, именно по этой причине мне нравится copilot режим — рутинные задачи отдаются в AI, но проверяет их решение и склеивает все воедино эксперт.

Резюме

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

Здесь нужны агентские динамические бенчмарки, где модель работает со средой. В них модель сможет уточнить задачу, спросить совета, переделать решение. А среда может в любой момент внести коррективы. Такие бенчмарки мы должны будем с вами построить.

Значит, работаем дальше. Пока работаем, не доверяем хайпу про ИИ-сотрудников и читаем этот канал.

Сева-новости

Понял, что безумно приятно в нашем уютном канале делиться личными новостями. Готовьтесь :)

Сегодня я выхожу на работу в Т-Банк в AI центр. Займусь улучшением клиентского сервиса на наших с вами любимых LLM-ах. Сервис в Т-Банке мне изначально очень нравился, так что ставлю себе базовую задачу — не испортить.

Большие и очень теплые слова благодарности всем коллегам и друзьям из Яндекса. Мы действительно много сделали, чем можно гордиться. А я еще очень горжусь, что вместе с вами работал.

Карпатый обещал нам еще 10 лет до AGI. Так что нас с вами ждет много увлекательной работы.

4 шаблона разработки AI-агентов

Карпатый недавно высказал непопулярное мнение, (а я давно это говорил!) что неправильно рассуждать, про “год ИИ-агентов”, а надо говорить про "десятилетие ИИ-агентов". У агентов столько проблем, что мы 10 лет будем их решать. Маск, конечно, возвразил, что Грок завтра всех победит, но мы то с вами все понимаем.

Из 10 лет прошел только год, давайте взглянем, как поменялись подходы к разработке агентских систем.

Базовая архитектура AI-агента

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

context = [{{"role": "user", "content": first_prompt}}]

while True:
    response = llm(context)
    context.append({"role": "agent", "content": response.text})
    if response.tool_calls:
        tool_result = execute_tool_calls(response.tool_calls)
        context.append(tool_result)
    else:
        return response.text

В чем основная проблема?

Контекстное окно адски растет, и тогда агент начинает путаться, что важно, а что нет, делает лишние действия, окно дальше растет, ну и он обречен.

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

Новые шаблоны архитектуры

- Мультиагенты. Задача бьется на подзадачи, чтобы свою задачу субагент мог решать в изолированном от других агентов контексте. Идеально применять, когда подзадачи друг с другом несвязаны, например, это чаще всего применяют в DeepResearch архитектурах.

- Внешняя память. Не все нужно писать в контекст. Часть информации может быть полезна только в очень редкие моменты. Разумно такую информацию добавлять не в контекст, а записывать во внешние файлы, которые потом можно загрузить через отдельный tool. Ну или через RAG поверх всей памяти. Особо деликатный вариант использует Manus: информация записывается во внешней файл, а агент может пользоваться обычными bash-утилитами, вроде grep, чтобы найти в файле все, что агенту нужно.

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

- Актуальный план через файл. Агент всегда должен иметь возможность вернуться к плану, чтобы отрефлексировать, туда ли он сейчас идет. Это позволяет постоянно фокусироваться на решении исходной задачи. Все как у людей. Например, в Claude Code есть файл ToDo List, где агент пишет, что он собирается сделать.


Применение всех 4-х не сделает из агентов машину по уничтожению любых задач. Но глючить будет сильно меньше, это я обещаю. А дальше у нас еще есть 9 лет, чтобы довести агентов до ума.

Как AI делает деньги. Заставляем LLM приносить пользу

В прошлом посте мы раскрыли секрет успеха классического AI — оптимизация узкого частотного процесса. Но когда мы переходим к реальным бизнес процессам, радужная картинка рушится — процессы состоят из кучи маленьких задач да и еще меняются от отдела к отделу.

Наш с вами классический рецепт успеха: наняли команду из 5 ML-щиков, собрали датасет, обучили модель, работать тут уже не будет. А что будет? Разбираемся в этом посте.

Горизонтальное и вертикальное внедрение

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

На самом деле, так почти все и делают. Именно отсюда берутся отчеты про 99.9% компаний внедрили LLM :) Здесь внедрение AI больше похоже SaaS. Купил, поставил, работает. Ничего перестраивать не надо. Только бизнес-эффект вы тоже никак не замерите. Но для SaaS вы же тоже его никогда не мерили, правда? Попробуйте посчитать на досуге ROI от покупки Microsoft Outlook. Про это отлично написали коллеги из McKinsey, но суть вы уже поняли.

Гораздо эффективнее брать один бизнес-процесс и оптимизировать именно его. Это называется вертикальное внедрение. Тут уже и ROI понятно как считать.

Но есть 2 проблемы:

1) Процесс состоит из кучи связанных задач. Вот поэтому все и носятся вокруг AI-агентов. Нужно, чтобы система умела делать сложную многоэтапную работу. Пока выходит так себе. Но мы работаем над этим. Я верю, что следующий год подарит нам много прорывов в области обучения агентов с помощью Reinforcement learning. Следите за моими публикациями :)

2) Каждая такая задача уникальна. В разных отделах могут быть абсолютно разные процессы, например, работы с клиентами. Наивно думать, что кто-то выпустит коробку, которая начнет пользу приносить, как только вы примете лицензионное соглашение. Здесь AI вообще не SaaS. Модель под каждую задачу нужно будет адаптировать. И нельзя адаптировать как раньше: собрать 5 ML-инженеров и дать им датасет. Не хватит времени и денег. Здесь нам AI внедрение нужно разделять на 2 разных этапа.

Платформа и масштабирование

Платформа создает интеллектуальную мощь системы. На этом этапе работают много ML-инженеров, они пишут много кода, создают AI-системы, от которых требуется обобщаемость. То есть, когда эту платформу будут внедрять в реальные процессы, допиливать напильником придется, но максимально мало. Эту платформу можно разрабатывать внутри компании или купить у вендора.

Масштабирование — это внедрение платформы сразу во многие процессы. На этом этапе должно работать как можно больше бизнес экспертов, которые точно понимают, что им нужно. И как можно меньше ML-инженеров, потому что это дорого. Здесь происходит допиливание напильником и оценка качества. Если все ок — внедряем, если напильника не хватает — делаем заказ в платформу.

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

Сегодня вечером буду душевно общаться про наши любимые LLM с коллегами из R77 AI.

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

Приходите общаться про LLM, агентов, технологии и что с этим всем поменяется в будущем. Постараемся выдать базу, но и немного пофантазировать.

Друзья, выпустил новую статью про экономический эффект от внедрения генеративного AI. Спойлер: часто эффект отсутствует.

Постарался разобрать причины этого печального факта и наметить план, как мы с вами должны будем это порешать. То, что мы порешаем, я ни капли не сомневаюсь. Честно.

В статье все, что мы любим: смешное название (надеюсь, жена так меня не называет), отчеты McKinsey, сгенерированные картинки. Но главное, там таится отчаянная попытка донести до вас реальное состояние наших дел.

Читайте, делитесь прочитанным с друзьями, пишите вопросы и возражения

Ставим агентов на поток. Кейс компании DoorDash

В своих статьях и постах (один и два) я занудствую про важность платформ. Нет ничего сильнее семьи платформы. Делают ли так на практике, или это просто мнение одного фантазера? Неделю назад вышла статья DoorDash, которая поможет нам разобраться, зачем кому-то понадобилась платформа AI-агентов.

Про что платформа

DoorDash — крупнейшая компания по доставке еды в США. У них накоплена масса полезных знаний о их бизнесе: корпоративная вики, таски в джире, множество SQL-таблиц, регламентов и прочих разных вкусностей корпоративных гигантов.

Вот бы кто-то прочитал и умел отвечать по этому… Одному, правда, будет невмоготу. У каждого департамента свои форматы данных и совершенно разные правила поиска по ним.

Решение: каждый департамент может собрать своего агента-помощника. Подключить необходимые базы и объяснить, как по ним искать (с людьми не получилось, пробуем агентов).

Каких агентов можно создавать

- LLM-workflow. Агент работает по строгому протоколу. Используется, когда нужна высокая надежность и есть этот самый протокол.

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

- мультиагент через планировщика. Самый простой и рабочий вариант мультиагентной системы. Главный агент независимые подзадачи раздает субагентам, а потом собирает ответ. Классический пример от Anthropic.

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

Такое разнообразие позволяет брать нужную архитектуру под ваши ограничения. Подробнее про это посмотрите в статье.

Техническое устройство

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

- RAG-платформа, через которую вы добавляете информацию

- Поддержка SQL

- Система оценки качества агента

- Валидация ответа и Guardrails

И много чего еще. После небольшого инструктажа обычный человек, используя эти кубики, сможет собрать реально полезного агента. Да, там не будет последних трюков из контекст-инжениринга. Да, LLM там обычные, а не дообученные под эту задачу. Но мы получим 80% результата за 20% сил.

Главный секрет успеха платформы — как надежно и удобно работает система оценки качества. Если получилось — дальше собирать Лего одно удовольствие. Если нет — всегда будут получаться жигули.

Моя вера в будущее

Я верю, что только так мы сможем масштабировать AI. Многие со мной согласны. Компании валом побежали делать платформы для создания агентов. Даже OpenAI, которые ранее верили только в один мега-мозг.

Никто не сделает AI для вашей задачи лучше, чем сделаете вы. Только вы знаете, как сделать удобнее всего. Платформы позволят любому создавать AI-решения, не делегируя никому их разработку. Не стоит делегировать интеллект.

#llm_cases