Ставим агентов на поток. Кейс компании 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-летней практике.

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

Друзья, привет!

Меня зовут Всеволод, я 9 лет занимаюсь внедрением AI (Yandex, VK, T-Банк). Прошел путь от инженера до руководителя команд разработки.

За 9 лет в индустрии я видел сотни проектов. И успешных, и провальных. Я вывел закономерность. Секрет успеха — не в гениальной архитектуре нейросети и не в тысячах GPU. Успех — это всегда системный подход.

Провальные проекты начинаются с фразы «давайте попробуем тут AI». В AI проще простого собрать демку за пару дней. Но невероятно сложно превратить её в актив, приносящий прибыль. Так рождается «кладбище пилотов»: проекты умирают через год, съев бюджет, потому что никто не подумал про надежность, безопасность и риски.

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

1. Стратегия: AI решает важные бизнес-задачи, вытекающие из целей компании. Не всегда нужен AI.

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

3. Дисциплина: Все инициативы проходят конкретные стадии, и мы объективно оцениваем их потенциал.

Этот канал — квинтэссенция моего опыта.
Я объясняю, как строить AI как бизнес-функцию: постоянную фабрику решений, а не разовый аттракцион.

Далее — материалы, которыми я горжусь больше всего:

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

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

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

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

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

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

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

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

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

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

- Как можно сделать модель лучше, чем 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-м читать этот канал будет еще интереснее.

Как рождается магия в AI-проектах.

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

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

Магия R&D проектов

Это, как раз, про инженеров и пиццу. Когда ваша задача настолько непонятна, индустрия с таким не сталкивалась, про это всего 5 статей.

Лучшие инженеры с колоссальной интуицией ищут прорыв. Читают статьи, их имплементируют, проводят сотни экспертов. Большая часть провалится. Иногда один выстреливает. Тогда рождается магия.

За этим обычно и идут заниматься машинным обучением. Но знаете сколько таких проектов? 1 %.

Магия продуктовых проектов

Это задачи, где понятна технология. Классификация, суммаризация, простой чат-бот. Непонятно только одно. Что на самом деле нам нужно сделать?

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

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

- Делаем метрики качества.

- Подстраиваем под них модель (на промптах тоже можно!).

- Делаем итеративно, шаг за шагом, контролируя метрики и психологическое состояние.

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

И таких проектов 99 %.

Вместо резюме

Большинство на старте проекта превращают его в R&D. Архитектуры, данные, функции потерь. И сразу теряют шансы на успех.

Надо начинать AI с общения. С диалога с тем, кто будет этот AI использовать. И тогда обязательно случится магия.

Да, и вот тогда, если остались ресурсы, можете идти делать еще R&D. Вот тогда уже можно.

AI-агент рекрутер. Кейс компании LinkedIn

Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.

Архитектура

Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.

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

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

3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...

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

4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).

Что здесь на самом деле сложно

Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.

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

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

У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.

Резюме

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

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

Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.

Observability в агентах. Почему прозрачность важнее технологичности.

LLM не славятся надежностью. Галлюцинации — топ-1 барьер для внедрения их в бизнес. Еще мы дали LLM кучу инструментов, разрешили ей планировать, добавили мультиагентность для души. Можно ли этот коктейль спроектировать так, чтобы всё это работало без сбоев? Нет. Обязательно что-то сломается.

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

Что такое observability

В обычной разработке всё прозрачно: код — источник правды. При любой ошибке можно разобраться, что пошло не так.

В AI-разработке код ничего не объяснит. Источник правды — только история: какие были входные данные и какие действия совершила модель. Набор методов для эффективного анализа этой истории и есть observability. Это:

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

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

3. Метрики качества (подробнее тут). В рамках одного трейса нужно обязательно оценить финальный ответ агента и, желательно, все его промежуточные действия. Разметить всё это вручную нереально, чаще используется LLM-as-a-judge (гайд по теме)

4. Дашборды. Помимо метрик качества, там должны быть технические метрики: скорость ответа, среднее число токенов и т. д.

Самые известные observability-библиотеки — это Langfuse и Arize Phoenix.

Как это работает вместе

- Вы мониторите состояние агентов на дашборде по техническим метрикам и метрикам качества.

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

- Во время дебага смотрите на прокси-метрики действий агента (через LLM-as-a-judge), проверяете все тулы. Благо для этого мы заранее настроили логирование.

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

Резюме

Черные технологичные ящики — это прикольно на презентации. Для инвесторов и начальников. Об этом прикольно рассказывать коллегам и друзьям. Но их очень не прикольно масштабировать и держать в продакшене. Любая поломка черного ящика — всю ночь будете разбирать причину. Лучше сделайте эти ящики прозрачными и спите спокойно.

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

Испечь AI-агента и не сжечь продакшн. Разбор ингредиентов

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

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

Из каких компонентов состоят агенты

5 кубиков агентской системы:

1) Оркестратор. Сердце (душа?) агента

Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.

2) LLM. Мозг агента

Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.

3) Инструменты. Руки агента

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

4) Контекстное окно. Память агента

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

5) Внешняя информация. Знания агента

Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).

Как компоненты взаимодействуют

Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:

- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.

- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.

Заключение

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

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

Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?

Вправляем мозги AI-агенту: 3 закона успешного LLM-инференса

Недавно мы разбирали рецептуру приготовления AI-агентов. Сегодня детально поговорим про один из главных ингредиентов — LLM (мозг агента). А точнее, про инференс: как заставить этот мозг работать так, чтобы агент был надежным, безопасным и не стоил вам как крыло самолета?

1. Запрос к LLM должен идти через Gateway (Шлюз)

Нельзя пускать компоненты агента напрямую к моделям. Все запросы — неважно, к внешней API или к вашей внутренней модели — должны проходить через единый прокси-сервис (Gateway). Клиент общается только с ним. Что должно быть «под капотом» у шлюза:

- Аналитика: логируем, какую модель вызвали, сколько токенов съели и как долго она отвечала. Без этого вы не посчитаете ни health-статус системы, ни юнит-экономику, ни качество.

- Безопасность: здесь мы прячем шифрование персональных данных, аутентификацию и проверку входного промпта на prompt injection.

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

- Контролируемая деградация: GPU неизбежно выходят из строя, а резервировать железо х2 — удел AI-мажоров. Шлюз должен уметь перехватывать ошибки отвалившегося сервера и бесшовно переводить запрос на модель поменьше (или в код, или в модель в облаке ). Пусть агент временно деградирует, но сама система продолжает решать задачу бизнеса (с контролиуремо меньшим качеством).

Кстати, хороший пример такого Gateway можно подсмотреть у коллег из Uber.

2. Стоимость инференса — KPI отдельной команды

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

Эти методы не универсальны и сильно зависят от задачи. У вас должна быть выделенная ML-инфра команда, которая будет разбираться во всех нюансов инференса LLM. Их прямой KPI — удешевлять и ускорять генерацию токенов для разных продуктов компании. Чем больше потребение LLM в вашей компании, тем мощнее будет ROI этой команды.

3. Понимайте потребление LLM в вашей компании

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

- Единый LLM-сервис на всю компанию

Одна команда развернула сервис с LLM. Все продукты ходят в эту одну общую «розетку».

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

- Выделенный LLM-инференс под продукт

Продукт физически забирает сервера с картами и разворачивает инференс сугубо под себя.

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

Резюме

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

Контекст — всему голова. Почему In-Context Learning — единственный способ строить надежные AI-продукты

Я ненавижу галлюцинации. Я хочу их все уничтожить. Но чтобы победить врага, мне нужно научиться его определять.

Сама LLM сгаллюцинировала дала такое определение галлюцинаций: «Феномен, при котором LLM генерирует уверенные, но фактически неверные, вымышленные ответы». Мне это совсем не помогает. Что значит «фактически неверный» в вакууме? Где источник правды, что есть верные факты?

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

Что такое In-Context Learning

Мы закладываем все ожидаемое поведение LLM (то есть обучаем) прямо в контекстное окно (промпт). Без классического обучения.

- Нужно, чтобы модель узнала информацию? Закинули RAG в контекст.
- Модель делает ошибку? Написали в промпте корнер-кейс (от души прошу, не делай так»).
- Нужно рассуждение? Просто попросили подумать шаг за шагом.
- Модель тупит? Почистили контекст от мусора.

Это в разы быстрее и дешевле, чем дообучать саму модель. Скорость итераций взлетает. А главное — это легко оценивать и контролировать.

Как теперь мы уничтожаем галлюцинации

Как только мы зафиксировали чудовище, его очень просто победить. Алгоритм прямолинейный:

1. Мы делаем строгую метрику, которая автоматически детектирует: модель взяла ответ из выданного текста или выдумала его из своих «весов»? (вот тут написано как делать)

2. Мы начинаем мочить модель, чтобы она не отвечала из весов. Как обычно, 3-мя способами: промтинг, раг, дообучение (тут особенно круто раскрывается методы Reinforcment Learning)

Минусы подхода очевидны. Придется строить инфраструктуру, чтобы этот контекст собирать. Ходить в нужные системы, доставать информацию и пихать ее в промпт. Контекст будет «пухнуть», а модели на больших объемах данных могут терять фокус. Благо, с каждым днем они справляются с этим всё лучше. Тренд играет за нас.

LLM — движок рассуждений, а не энциклопедия

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

Для моих кейсов не важно, чтобы LLM знала анатомию горилл. Можно, пожалуйста, не платить за горилл стоимостью инференса?

Я верю, что модели должны стать исключительно процессорами информации. Запомнить базовое — да. Всё остальное делать только логическими операциями на основе доверенных источников (но не стоит брать за источник правды текущие LLM, иначе весь этот схематоз развалится)

Нудное резюме

Хотите делать надежные AI-продукты? Нудно, системно и последовательно собирайте информацию, которая будете скармливать моделям нужный контекст.

Да, вам придется хорошенько подумать, какую именно информацию и когда вставлять. Зато, если не подумаете вы, LLM с радостью «подумает» за вас. И эта галлюцинация вам точно не понравится.