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

Фреймворк, как привести к успеху любой AI-проект

Самый частый вариант беседы, когда меня просят помочь с проектом:

- Сева, вот смотри, хотим решить проблему X. Понятно?
- Пока да.
- Супер! Короче, мы взяли 15 ИИ-агентов, в них запихали 4 роутера, облили это все графовой базой знаний. И все это на 1.5B квене, который мы специально доучили, но код обучения случайно удалили.
- Уже понятно меньше, но допустим. А что вы от меня хотите?
- Вот оно у нас плохо работает...

Беседа потом идет примерно одинаково. Готовьтесь, дальше не будет никакого роя AI-агентов. Дальше будет нуднота.

Итеративный фреймворк управления проектом

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

Элементом фреймворка является гипотеза. Гипотеза — это идея, что некоторое изменение улучшит качество AI-проекта. Например, что нужно LLM обновить до GPT 5.1. Гипотеза может быть в одном из трех состояний:

- Прототипирование. Нужно как можно скорее понять, а стоит ли инвестировать силы. Подробнее в статье.

- Оценка качества. Замерили и теперь понимаем успешная ли гипотеза. Гайд по замеру качества.

- Внедрение. Уверены, что гипотеза полезная. Разрабатываем и внедряем.

Любой проект начинается с самого простого и легко поддерживаемого решения. Например, чат-бот. Вначале просто API к GPT + простой промпт. Больше ничего. Смотрим недостатки (время/цена/галлюцинации/etc). Делаем гипотезу. Потом еще одну. Идею вы поняли.

Откуда берутся гипотезы

Нет, не из статей с хабра и даже не с arxiv.org. Гипотезы рождаются из анализа проблем. Типовой анализ выглядит примерно так:

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

- Оценили качество текущей системы.

- Разбили примеры с проблемами на понятные группы.

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

Резюме

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

Если за всю жизнь я смогу донести только одну эту идею, я буду уверен, что все было не зря.

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

А судьи кто? Гайд по LLM-as-a-judge

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

Сегодня погрузимся в самый популярный метод — оценка качества моделей “LLM-as-a-judge”. В нем вместо оценки ответов людьми мы оцениваем ответы другой "LLM-судьей". Тут обычно все шутят, что критиковать всегда проще, чем творить. Мне шутка уже надоела, но законы жанра. Извините.

Когда использовать LLM-as-a-judge?

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

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

2) Вам нужны очень быстрые итерации.
Гонка, пожар, стартап. Если вам нужно получать оценку качества через часы, а не дни.

3) У вас нет ресурсов.
Не только денег. Обучение разметчиков это обычное преподавание. Это материалы, ответы на вопросы, тесты, экзамены. Регулярные проверки, что они все не забыли и не жульничают. Это требует много сил и отдельного штата специалистов.

Как сделать LLM-судью? Пошаговый план

1) Берем бизнес-эксперта. Человека, который понимает, когда система работает правильно. Вместе с ним прорабатываем критерии, по которым оцениваем. Например, релевантность ответа, безопасность, достоверность и тд.

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

3) Переразмечаем, спорим, пока мы с экспертом согласованно не разметим корзинку. Так мы поверяем, что мы сами поняли критерии. В итоге у нас получается «голден корзинка» таких эталонных примеров хороших и плохих ответов.

4) На части этой корзинки тюним LLM-судью. Тестируем итоговое качество на другой части. Тюнить можно по-разному: писать промпты, разбивать задачу на подзадачи (на каждый критерий можно отдельного судью), добавлять агентность. Можно даже файнтюнить LLM. Важно делать это итеративно, как и во всем AI-проекте.

Резюме

Это не просто дешевый, быстрый в разработке подход. Он еще очень гибкий. Если вы хотите поменять критерии качества, намного проще поменять промпты в LLM, чем переучивать 50 людей размечать по-новому.

Если ваша разметка явно не противоречит 3-м пунктам из этого поста, начните с LLM-as-a-judge, а не с разметки людьми. Если не получится, вы всегда сможете часть простых задач разметить LLM, а все сложные отправить людям. Или сможете давать людям LLM-подсказки, чтобы они могли быстрее размечать.

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

Экологичный метод дообучения LLM

Я не люблю учить модели. Точнее, я не люблю, когда учат на каждый чих, хотя можно было обойтись методами попроще. Почему?

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

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

Чем LoRA экологичнее?

LoRA (low-rank adaptation) не трогает исходную модель. Метод обучает новые параметры, так называемый адаптер, который просто складывается с оригинальными весами модели. Из этого сразу вытекают два важных преимущества:

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

2) Удобство предсказания.
Вам не нужно держать 20 клонов модели для 20 разных внедрений. Вы можете только один раз запустить модель на дорогих сердцу GPU-серверах, а 20 раз использовать разные адаптеры, которые намного меньше. На этапе предсказания веса модели будут на лету складываться с параметрами адаптера и выдавать предсказания для 20 разных задач. Ну оооочень экологично, правда. Такой функционал реализован во многих библиотеках, например, в vLLM.

На второй пункт обычно все забивают. И часто в компании возникает зоопарк из 30 версий модели, у каждой по 1 H100 с 3% утилизации железа. Зла не хватает.

Когда и как применять LoRA?

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

Отличное исследование по LoRA, сделали коллеги из Thinking Machines. Некоторые выводы:

- Нужно применять адаптер ко всем слоям модели, а не только к слою внимания.

- Чем больше размер адаптера, тем больше он может заполнить, тем дольше надо учить.

- Шаг обучения ставить примерно в 10 раз выше, чем при полном обучении.

Резюме

Я не хочу, чтобы мы с вами делали разовую AI-активность. Я мечтаю, чтобы мы создавали методы массовой трансформации. LoRA намного больше подходит под эту мечту, чем классическое полное дообучение.

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

Друзья, опубликовал подробный фреймворк оценки качества LLM.

Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.

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

Друзья, привет! Нас уже более 3-х тысяч, спасибо вам за это. Для тех, кто недавно со мной знаком, расскажу про себя и канал.

Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.

За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.

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

Далее перечислю материалы, которыми я горжусь больше всего.

Статьи про методику внедрения AI:

- 12 правил внедрения LLM

- Почему генеративный AI не приносит прибыли

- Методика оценки качества LLM

Основные посты про методику:

- Главный пост про итеративный фреймворк работы с AI-проектом

- Платформа — ключ к массовому внедрению AI

- Почему нельзя купить AI из коробки

- Как неправильное внедрение стоило компании полмиллиарда долларов

- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber

- 3 кита улучшения любой LLM

- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов

Кейсы:

- Ставим разработку AI-агентов на поток

- Как создали AI-агента аналитика

- Агент, который исследует информацию в интернете

- Массовая обработка документов на LLM

Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.

Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika

Как посчитать профит от LLM. Если, конечно, он у вас есть.

Знаете, в чем феномен рекомендательных систем? Легко посчитать эффект. Обучили новую модель, потратили X денег на команду/железо. Провели АБ эксперимент, получили рост продаж на Y. Сравниваете X и Y. Для бизнеса все супер прозрачно.

В генеративном AI не так, 80 % компаний не видят финансового эффекта. Но не потому что LLM бесполезны. Обычно, LLM в компании делает что-то базово разумное (хотя бывает всякое). Но никто не может эффект от этой разумности посчитать. Почему это сложно, и что нам теперь делать, об этом сейчас поговорим.

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

Статистика работает, когда данные стремятся к бесконечности. Если у рек. системы сотни тысяч пользователей, вы уже победили. Делаете АБ сплитование, считаете деньги. Команда будет счастливо работать десятки лет.

В LLM все намного сложнее. Допустим, мы делаем копайлот для сотрудника. Нам нужно:

1) АБ-инфраструктура. Уникальный айди, по которому мы можем сотрудников сплитовать, и система, которая оценивает его перфоманс. Перфоманс, кстати, не у всех профессий можно легко замерить.

2) Много сотрудников, чтобы мы могли что-то прокрасить в АБ.

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

Что делать?

Большинство внедрений LLM не подходят под условие выше. Что нам, теперь не вдрять Copilot для 10 программистов? Внедрять. Варианты:

1) Самое смелое — принять риски.
Посчитать через полгода интегральные метрики. Например, сколько вы сделали релизов, как часто пропускали критичные баги и тд.

2) Самое наивное — проводить массовые опросы.
По шкале от 1 до 10 оцени, насколько Copilot делает тебя продуктивным. Это, конечно, шляпа. Никто не скажет, что я не разобрался даже с главным меню и пользовался им 2 раза. Конечно, мой босс купил очень хороший Copilot!

3) Самое сложное — подумать.
Если вы не можете померить эффект, вам нужно создать прокси. Вы не можете оценить перфоманс менеджера, который пишет вам отчеты через LLM-копайлот. Но вы можете проверить, что менеджер хотя бы им нормально пользуется. Логировать все вопросы, проверять качество отчета (он же этот отчет потом нам покажет!) и оценить, сколько времени требовало бы написать этот отчет (через другие LLM, например). И дальше по пункту 1, но уже более осознанно.

Это затраты на отдельную инфраструктуру, но ее можно использовать во всех AI-проектах внутри компании. Знаю, это гениально, жаль я не придумал это первым :) Уже давно есть стартапы, которые делают такую инфраструктуру.

Резюме

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

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

Друзья, с наступающим! Пусть в следующем году профит от ваших проектов будет такой гигантский, что этот пост вам не пригодится. Спасибо, что читали весь этот год. Обещаю, что в 2026-м читать этот канал будет еще интереснее.