Всеволод Викулин | AI разбор

Учим машину экспертным суждениям Я недавно украл у Sequoia разделение умственной работы на 2 класса: intelligence и judgment. Нормально перевести не смог. Intelligence — это когда задачу можно решить по понятной инструкции. Judgment — это когда для задачи нужны опыт и интуиция эксперта. На примере разработки. Intelligence — дописать кусок кода по подробному ТЗ от синьора. Judgment — придумать архитектуру высоконагруженного сервиса. Да, и там и там нужно уметь кодить. Но в первом случае у вас уже есть рамка и понятный способ действовать (если вы прочитали книжку по языку программированию). Для второго кейса книжки я не знаю. Человекам — Judgment. Агентам — intelligence. Вайбкодинг хорошо работает у сильных инженеров. Эксперт уже принял важные решения и упаковал их в хороший промпт, примеры, тесты. От модели требуется просто быть послушной. А если вайбкодить начинает не-разработчик, то на кейсах, где нужен judgment, агент наагентит ему таких решений, что никто не разберется. Автономным агентам нельзя отдавать judgment. Даже если написать в промпте “представь, что ты Бьёрн Страуструп”, не факт что потом C++ сервис выдержит нужную нагрузку. (Подставлять в промпт Всеволода Викулина я бы тоже не рекомендовал.) То, что вчера было judgment, сегодня уже intelligence. Когда-то сделать сайт было задачей для человека с головой и руками. Теперь это commodity. LLM уже видели достаточно кода, чтобы делать такое почти из коробки. (Я, кстати, без головы и рук тоже создал свой статический сайт). Во многих задачах экспертиза давно растворился в весах LLM. В весах лучше всего растворяется массовые знания. А ваш уникальный экспертный процесс в данных почти не встречается. Так что в нужный вам judgment LLM не умеет. И тут есть соблазн: соберём примеры лучших экспертов, дообучим модель — и она тоже станет экспертом. Ух, как я это ненавижу. Два пути, как занести judgment в агента Разберем на примере sales-агента. Первый путь — классический ML-подход. Берём лучших продажников, собираем их диалоги, дообучаем open-source модель на их ответах и надеемся, что “секретный рецепт продаж” как-то перетечёт в веса. Скорее всего, не получится. Во-первых, когда вы дообучаете модель на узком датасете, вы меняете огромную систему, которую до этого долго обучали и тестировали на куче разных задач. Скорее всего, вы ее сломаете. Нет надёжного способа выучить “тонкий секретный рецепт, как продавать ручку” так, чтобы модель не начала галлюцинировать и не сломала обобщающую способность. Во-вторых, если у вас нет явной методики продаж, то у вас нет и нормальной разметки качества. Нельзя просто собрать трёх экспертов и сказать: “Оцените в силу своей экспертности, хороший ли это ответ”. У каждого свой judgment. Разметка становится шумной. Качество — неуправляемым. Второй путь — выносим judgment в контекст. Берём экспертов по продажам и вытаскиваем из них правила: как квалифицировать лида, какие есть сценарии, как отвечать на типовые возражения. Потом всё это кладём в контекст модели либо в базу, по которой модель будет искать. Мы выносим judgment наружу и заставляем модель по нему действовать. Если вы реально вынесли все, то обычная LLM с задачей легко справится, И по тому же контексту разметчики затем смогут контролируемо размечать каечество. Ну не сказка ли? Резюме Всю работу в AI можно описать как "учим машину экспертным суждениям". В агентской разработке победил не путь “зашьём экспертизу в веса модели". Победил “разложим экспертизу во внешний контекст и научим модель им пользоваться”. Да, в этом пути куча проблем: как собирать экспертизу, как агент должен искать нужный кусок контекста, как это всё правильно оценивать. Это звучит гораздо скучнее, чем fine-tuning на лучших в мире экспертах. Зато работает.

Почему даже OpenAI пошёл в консалтинг Когда я начинал, делать AI было просто: — Есть поиск — собираешь метрику качества поиска, оптимизируешь модель. — Есть рекомендации — берёшь историю покупок клиентов, оптимизируешь модель. — Есть детекция поломок — берёшь поломки... Ну, идею вы поняли. И организационно всё тоже суперпросто: команда квартал за кварталом улучшает метрику своего куска системы. Если этот кусок дорогой, команда окупается, и все счастливы. А что с LLM? Как и раньше, где-то сидит инженер OpenAI, оптимизирует мегамодель по куче хитрых бенчмарков за очень много венчурных денег. Но он, хитрюга, только выкатывает её под API. Дальше потребителю надо вкорячить этот API и оптимизировать свой процесс. И вот тогда родится Польза. Звучит заманчиво. И, кстати, вкорячивать LLM действительно стало просто. Вот только эффекты от этого никого не радуют. Почему схема ломается Частично я это объяснял в посте про платформу агентов. Если вкратце: — Иметь ручку к LLM — это только входной билет на аттракцион. Ещё нужны нормальные тулы, бизнес-правила (контекст агента) и методика оценки качества. Подробнее — в моей статье. — Ничего из этого вам никто не продаст. Не продаст чёрную коробку, которая сама навайбкодит хорошие инструменты для агента, сама поймёт ваш бизнес-процесс, сама напишет правильный контекст и сама ещё честно проверит, что всё это работает. — Кто-то с LLM-апишкой, или с любой другой платформой, должен пройти «последнюю милю внедрения». То есть прийти в конкретный процесс, разобрать его до атомов, понять, какие там реальные бизнес-правила, где лежат данные, какие нужны тулы, какие ошибки допустимы, — и потом уже под это собрать систему. Чем отвечает OpenAI API-шки плохо встраиваются в крупных клиентов, и OpenAI проигрывает долю внедрений в B2B Anthropic. Что бы вы сделали, будь у вас куча денег и нехватка экспертизы? Правильно: купили бы консалтинговую компанию, которая будет внедрять ваши API (общая сумма инвестиций 4 млрд $). Прошу прощения, «консультанты» — это не модно, поэтому в маркетинговых недрах Сан-Франциско придумали отдельную профессию — Forward Deployed Engineer. Это консультант инженер, который приходит к заказчику и проходит с ним последнюю милю: помогает собрать правильный контекст, настроить evals, спроектировать нужные тулы. Потом, конечно же, ставит клиенту правильную API-шку, внедряет её ещё в один процесс, потом ещё в один — и в итоге крупный клиент приносит столько денег, что весь этот схематоз окупается. Это, кстати, не самая свежая идея: Anthropic уже давно таких людей нанимает. Нудное резюме Нельзя просто сделать AI-платформу и надеяться, что кто-то другой героически перестроит на ней процесс, а потом напишет нам отличный отзыв на ревью. Не перестроит. Не напишет. Не потому, что он плохой, а потому, что это реально сложно. Это передовой R&D, который мало кто в мире умеет внедрять. (хотя, если у вас есть 4 млрд $, можете купить тех, кто внедрит) Платформа важна, но не как конечное решение, а как ускоритель каждого внедрения: пайплайны подбора контекста, мануалы по написанию тулов, готовые команды разметчиков для evals. Именно так мы и внедряем агентов в обслуживание Т-Банка: понимаем процессы, работаем над контекстом, проектируем тулы. И ещё делаем это на своих LLM. Если вам откликается такой подход, пишите мне: мы нанимаем NLP-инженеров, бэкенд-разработчиков, продуктовых аналитиков и продакт-менеджеров. До встречи!

Если вдруг вы устали читать мою духоту, то теперь можете ее еще и послушать! В эту субботу 23 мая буду выступать на Data Fest 2026 в секции Data Strategy. Секция пройдет в главном зале, мой доклад в 13:40. Поговорим, как выбирать кейсы в агентах и про реальную автоматизацию в них. Приходите! После выступления пообщаемся (с теми кто не ставит клоунов мне на посты)))

Почему я ненавижу векторный поиск Возьмите любую статью, где автор делал RAG. Откройте схему архитектуры. Держу пари: там будут эмбеддинги, векторное хранилище и поиск по нему. Обязательно будет. Я долго думал, почему люди так любят это дело. Рефлексировал, общался с коллегами, прочитал гору книг по психологии. Мне кажется, теперь я все понял. Почему все (но не я) любят сравнивать эмбеддинги Это очень удобная ментальная модель. Вы не знаете, как сравнивать два текста в вашей задаче — я, кстати, чаще всего в своей тоже не знаю. Задача сравнения текстов вообще чертовски сложная: два человека иногда не могут договориться, про одно и то же говорят или нет. И тут приходит эмбеддер. Чёрный ящик, который обещает: дай мне оба текста — я скажу, похожи они или нет. Сложная задача сравнения двух многогранных текстов сводится к сравнению расстоянию между двумя векторами по 512 чисел. Перечитайте это предложение ещё раз. Вы точно уверены, что она сводится? Модель удобная. Она обещает, что теоретически сможет идеально сравнить два текста. Просто добавляй побольше данных, делай побольше эмбеддер, учи его подольше. Вот, кстати, еще 200 интересных статей, как этот эмбеддер можно обучать... Когда ментальная модель встречает реальность У сравнения эмбеддингов есть ряд ограничений, которые не лечатся ни большим датасетом, ни новой архитектурой. — Точные совпадения. Пользователь спросил «iPhone 16 Pro» — он не хочет «iPhone 16. Семантически оба айфоны, даже оба новые. Но это совершенно разные продукты. Реклама меня уверяла. Ведь так? — Отрицание. «Телефон, но не iPhone» — попробуйте заставить эмбеддинг адекватно обработать «не». Отрицание должно переворачивать все сравнения с ног на голову (как будет работать двойное отрицание, я пока не понял). — Числа и даты. Ищете квартиру в Москве дешевле 20 млн? Квартира за 19.5 млн сильно не изменит свой эмбеддинг, когда собственник поднимет стоимость до 20.5. — То, чего нет в обучающих данных эмбеддера. «Всеволод Викулин» плохо матчится эмбеддингом с текстом «лучший AI-практик в мире». Мы с вами всё понимаем, модель — пока нет. По крайней мере, пока не прочитает этот канал. Как делать поиск, если не векторно Векторный поиск никуда не девается — он занимает своё место, просто не соло. 1. Сначала проверьте, нужен ли поиск вообще. Если все ваши знания влезают в 5–10 тысяч токенов — просто положите их в промпт. Один раз объяснили, чем хорош Викулин и оно запомнило. 2. Если документов немного — оценивайте все документы другой LLM-кой. Берёте дешёвую маленькую модель, даёте ей запрос и документ, просите оценить релевантность. 3. Если документов много — используйте несколько методов поиска: — полнотекстовый (по словам и н-граммам) — не знает семантики, зато точно находит «iPhone 16 Pro» — структурированный (SELECT WHERE price < 20kk) — для чисел и фильтров — поиск по оглавлениям — LLM разбивает базу на темы, потом выбирает нужную тему. Люди так делали c книгами до изобретения Ctrl+F — поиск тулами — даёте LLM grep и наслаждаетесь — гибридный поиск — смесь нескольких вариантов — поиск по графу — разбирали пример — (еще есть много чего, в том числе и векторный поиск) 4. Если качества не хватает, делаете реранкер. Берёте простой поиск, получаете топ-N кандидатов, и дальше их переранжирует LLM из пункта 2. Кстати, пример архитектуры хорошего поиска мы уже разбирали в посте. Резюме Пока писал этот пост, понял кое-что понял. Я ненавижу не векторный поиск. Я ненавижу, когда люди скидывают ответственность за качество своего продукта на самый популярный в индустрии чёрный ящик. Нарисовали эмбеддер, дальше только данные подкидывать, а он разберется. Не разберется. Нужно самому принимать решение, которое будет лучше всего работать в конкретной задаче. Может, у меня синдром гиперконтроля?. Надо сходить провериться.

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

Вообще все равно, на чем вы делаете агентов Ещё студентом я с командой участвовал в Data Science Game — непризнанном чемпионате мира по анализу данных. Сейчас его уже не проводят: зачем анализ данных, когда есть ИИ-агенты. Естественно, тогда выиграли. И вот награждение. Стою весь в белом, спонсоры жмут руки, задают вопросы. Тогда, кстати, ещё не спрашивали, как ИИ захватит мир — таких проблем перед нами не стояло. Я ждал вопросов: как выбирали целевую переменную, как приоретизировали гипотезы, или хотя бы сколько деревьев в бустинге (модель AI 2010-х). И тут встаёт руководитель французской страховой компании и спрашивает: «слушайте, все-таки, какая библиотека круче — catboost или lightgbm?» Люди обожают обсуждать инструменты. С агентами всё то же самое. Только хуже. О чем на небе все разговоры На чем же нам писать агентов?! Сейчас примерно три лагеря: — Графически: n8n, Dify, Langflow— клик-клац мышкой — Декларативно: Claude Skills, AGENTS.md — вежливо попросил в markdown — Кодом: LangGraph, CrewAI — для тех, кто любит похардкорнее Нюанс. Если у вас есть реально дорогая задача (см. примеры тут), которую агент может закрыть — вы как-нибудь справитесь. На коде, на рисовалке, хоть на ассемблере. Если бы агентов можно было кодить только на Perl — я бы первый пошел открывать вакансию. Что реально важно Если процесс дорогой, важно 3 вещи: 1. Описание процесса Агент — это очень внимательный, исполнительный человек с улицы. Он не знает ничего про вашу компанию, ваш продукт, ваших клиентов и ваши процессы. И вот этому человеку нужно настолько детально объяснить задачу и в нужный момент подсунуть нужную инструкцию, чтобы он сделал работу правильно. Это и есть контекст-инжиниринг. Все ринулись изучать фреймворки для работы с контекстом. Но фреймворк не имеет никакой ценности, если вы сами не знаете правил. Сначала вы выписываете процесс настолько детально, что его поймёт стажёр в первый день. Только потом думаете, через какой инструмент это всё запихать в LLM: в LangChain или в n8n. 2. Инструменты Тому же человеку с улицы нужно чем-то работать. Ему нужны понятные API, ручки, кнопки — то, чем он может пользоваться, чтобы выполнять задачу. И тут все рванули в MCP. Всем побольше MCP-хабов. Но без нормальных ручек протокол ценности никакой не несёт. А с ручками беда: они кривые, дублируются, не имеют описаний, в них чёрт ногу сломит. Все думают: накидаем 250 API-шек в MCP — и агенту сразу полегчает. Дайте 250 инструментов человеку с улицы и посмотрите через сколько он уволится. 3. Стоимость инференса Есть класс фреймворков, которые я люблю (и такое бывает) — это инференс-движки. vLLM, SGLang, llama.cpp — под капотом у них горы C++, CUDA-кода и низкоуровневых оптимизаций. Это та работа, которую вы сами не сделаете никогда. Сравните с n8n, которые делает интерфейсную обвязку вокруг контекст-инжиниринга. Если процесс правда дорогой — вы эту тупую обвязку напишете руками, и она будет ровно под вас. А вот написать свой движок инференса с оптимизированным KV-кэшем и батчингом — нет, не напишете. Резюме Дайте мне описание процесса, нужные ручки и дешёвый инференс — и я обещаю, что сделаю вам агента. Но не скажу, в какой ui-ке я его рисовал. Это будет моя маленькая тайна.

Развернуть свою LLM или на API-шке заведется? В прошлом посте считали стоимость инференса своей LLM. Может, ну его нафиг, и будем просто OpenAI за токены платить? Вопрос не простой. Правильный ответ зависит от того, на какой стадии проект и от его ограничений. Стадий всего две. Ограничений — поболее. Теперь по порядку. Две стадии AI-проекта: MVP и масштабирование 1) MVP. Цель — получить сигнал, что продукт реально решает проблему и растит бизнес-метрику. Опросы пользователей, оффлайн-метрики, A/B-тесты — отсюда получаете сигнал. 2) Масштабирование. Сигнал получили, теперь раскатываем решение в прод. Здесь уже думаем про железо, стоимость, безопасность, SLA — всё то, на что было плевать вчера. Это две разные задачи с разными рисками. И модели под них нужны разные (подробнее про стадии проекта в статье). MVP: только API, только хардкор Главный риск на старте — закопать месяцы в проект, который вообще не надо было делать. Поэтому на стадии MVP запрещено думать про стоимость инференса, скорость работы и безопасность. Главная метрика — скорость проверки гипотезы. Каждая инвестиция в AI-инфраструктуру — бездарно потраченное время. Отсюда правило: берём самую толстую API-модель, которая есть на рынке. Если уж она задачу не вытянет, можно честно закрывать проект и идти делать следующий. Масштабирование: когда API может не тянуть Сигнал получили, продукт нужен, начинаем думать, стоит ли слезать с API. Причины для слезания: 1. Безопасность данных. 99% реальных причин ухода с API. Регуляторка, персональные данные, банковская тайна, корпоративные секреты и тд. 2. Медленно. Редкая история. Современные провайдеры используют много примочек и сильно разогнали инференс. У вас, скорее всего, сильно быстрее не получится. 3. Дорого. Платите за GPU вы постоянно, но нагрузка у вас пикообразная. Ночью пользователи спят. Днём работают. В ваш сервис реально ходят несколько часов в день, а карты постоянно в вашем P&L. В API вы платите строго за токены, что использовали. И не забудьте про команду, которая должна инференс поднять и поддерживать. Опенсорс становится дешевле если: (а) у вас реально большой трафик (б) вы умеете грамотно утилизировать железо в провалах — сдувать ночью, поднимать днём, шарить между задачами. Вывод: в 99% кейсов API дешевле, чем свой инференс. Если вам кажется иначе — посчитайте ещё раз. Как делать Масштабирование на опенсорсе 1) Пробуем самый большой опенсорс. Да, он хуже топовых API-моделей. Но разрыв меньше, чем принято думать. Если экономика сходится — вы восхитительны, можно больше ничего не делать. 2) Если экономика не сходится — дистиллируем. Учим маленькую модель на ответах большой. Это вот ровно тот кейс, где оправданно обучать свои модели. Маленькая модель запоминает паттерны большой, теряет широту (на задачах за пределами вашего домена она будет тупить), зато выигрывает порядок по железу. Но на широту вам обычно пофиг, лишь бы конкретно вашу задачу более менее решала. При правильной дистилляции реально сжать модель на порядок. Резюме: итоговый алгоритм 1. MVP → самая большая API-модель. Ищем сигнал, что продукт решает проблему. 2. Сигнал получили + с безопасностью ок + скорость норм + экономика сходится → остаёмся на API. 3. Данные отправлять нельзя → разворачиваем самый толстый опенсорс. 4. Опенсорс не лезет в экономику → дистилляция под ваш домен. 5. Всё остальное (дообучаем модель, чтобы она поумнела; поднимаем свой инференс, чтобы сэкономить на API; перебираем опенсорсы на MVP) — от лукавого.

Мой главный секрет успеха AI-проектов Не технологии. Не оркестрация, не квантизация и не дистилляция. Не chain-of-thought, не human-in-the-loop и не llm-as-a-judge. Не данные. Не нормализация, не аугментация и не токенезация. Не big data и не small data. Люди. Лучшие проекты свершались благодаря команде, которая была со мной. С нужными технологиями можно разобраться, нужные данные можно собрать, если рядом люди, на которых можно положиться. Которым важно достигать результата, которые готовы брать за него ответственность. Я сейчас ищу таких людей. Мы в Т-Банке собираем команду внедрения AI-агентов в поддержку клиентов, чтобы с их помощью полностью перестроить все текущие процессы. Внедрение агентов это не обучение LLM в игрушечной среде. Это хардкорный context engineering, оптимизация инференса, разработка метрик качества. Будет интенсивно, это я обещаю. Но вам понравится, это я обещаю тоже. Я ищу ML-инженеров (мидл/синьор). Если у вас есть: - 2+ опыта ML-разработки - любой опыт LLM-разработки - желание прокачаться в разработке и управлении в сложных инфраструктурных проектах Я ищу продуктовых аналитиков (мидл/синьор). Если у вас есть: - 2+ опыта работы продуктовым аналитиком - уверенные знания SQL и математической статистики - желание мощно разобраться в метриках качества LLM и агентских систем Присылайте свое резюме мне в личные сообщения @seva_batareika Если вдруг вы ждали понедельника, после которого пора изменить свою жизнь, то вот это именно этот понедельник.

Да вы шутите… https://www.forbes.ru/biznes/559193-ii-pomosnik-v-andeks-direkte-naucilsa-zapuskat-reklamnye-kampanii

Калькулятор LLM-инференса. Сколько стоит LLM в проде Одна из самых дорогих статей расхода в LLM-проектах — инференс. Умение правильно его оптимизировать не раз спасало экономику моих проектов. Сегодня разберём, от каких параметров зависит цена, и я поделюсь пример калькулятора, где можно получить оценку стоимости. Размер модели Размер определяется задачей. Для несложных задач с коротким входным контекстом (нормализация текста, перевод, выделение ключевой информации) — хватает моделей порядка нескольких миллиардов параметров. Быстрые, влезают на одну потребительскую карту, стоят копейки. Для задач с большим контекстом (например, сложный RAG) — нужны модели порядка десяти миллиардов параметров. Здесь уже важно качество рассуждений и умение работать с длинным контекстом. Для агентских систем, где у LLM огромный контекст и куча инструментов — работают только самые большие модели. Часто это MoE-архитектуры вроде Qwen3-235B: размер огромный, но при каждом вызове активируется только часть параметров. Из-за большего размера они могут не влезать ни то что в одну карту, но даже в сервер с 8-ми картами. Более подробно я расписывал это в отдельной PDF-ке. Забирайте. Квантизация Параметры модели можно хранить в числах разной точности. Перевести FP16 (16 бит на параметр) → FP8 (8 бит на параметр) — в два раза меньше памяти. Квантизация влияет не только на размер: сжатые веса быстрее читаются из памяти, а значит быстрее инференс. FP8 сейчас стандарт для прода — H100 поддерживает нативно, потери качества минимальные. Вечно квантизовать нельзя, после 4 бит качество уже значительно падает. KV-cache При генерации нового токена модель хранит информацию из всех предыдущих — это KV-cache. Он растёт линейно с длиной контекста и с каждым запросом в батче (точная формула в калькуляторе). KV-cache тоже можно квантизировать отдельно от весов. Веса в FP8, а KV-cache в FP16 — стандартная конфигурация. Batch size Сколько запросов GPU обрабатывает одновременно. Главный компромисс инференса. Больше батч → выше суммарная пропускная способность → меньше карт нужно → дешевле. Но каждый конкретный пользователь ждёт дольше, потому что GPU делит ресурсы между всеми в батче. Размер батча нужно подбирать под продуктовые требования скорости ответа. Размер входа Входные токены обрабатываются в фазе prefill. Это быстрая фаза — GPU считает параллельно. Но при длинном входе (RAG с документами, агент с историей) prefill тоже начинает стоить времени. На больших контекстах может занимать несколько секунд. Не бесплатно. Пока prefill не сделали, генерация не идет. Размер выхода Выходные токены генерируются в фазе decode — по одному за шаг. Это медленная фаза, decode почти всегда доминирует в латенси. На практике в десятки/сотни раз дольше. Пиковый RPS Сколько запросов в секунду система должна обслуживать в пике. Стандартная практика — закладывать запас 15-20%, чтобы система в пике не работала на пределе. Итого Все эти факторы я собрал в калькулятор, который даёт примерную оценку стоимости инференса. Внутри три вкладки с готовыми примерами на моделях Qwen3: нормализация текста (простая), RAG (средняя) и агент (сложная). Все входные параметры можно менять. Важно: калькулятор только примерная оценка для первого этапа разработки LLM-проекта. Как только появится первый прототип, производительность системы нужно честно бенчмаркать. Конечно, эти цифры — не приговор. Стоимость инференса можно серьёзно снижать: дистилляция, спекулятивный декодинг, prefix caching и тд. Но это уже тема наших следующих разговоров.

AI-агент, который запустит рекламу за вас. Кейс компании Spotify Предприниматель хочет запустить рекламную кампанию. Раньше — заполняешь 20 полей, интуитивно расставляешь бюджеты по форматам и молишься, что угадал. Если вы богатый предприниматель, у вас есть специальный сотрудник, тогда страдает уже он. Spotify решил это сломать. Они построили мультиагентную систему, которая превращает сообщение в чате в готовую компанию: на каких пользователей, где и какую рекламу запускать. Разбираем архитектуру и почему это тот самый тип AI-агента, который я хочу, чтобы вы научились создавать. Архитектура решения Медиапланирования состоит из множество подзадач: нужно одновременно разобраться с целью кампании, аудиторией, форматами и расписанием. Если делать это последовательно — медленно. Если в один большой промпт — ненадёжно. Это явный сигнал для применения мультиагентной системы. - GoalResolverAgent — выставляет цель кампании (охват, клики, установки) - AudienceResolverAgent — заполняет таргетинг: интересы, гео, демография - ScheduleAgent — выписывает даты компании Все эти 3 агента работают параллельно. Пока один разбирается с географией, другой уже считает бюджет. Итого — 3-5 секунд на весь pipeline. Когда все данные о компании заполнены, вот тут и начинается магия — запускается MediaPlannerAgent. Он уже формирует план компании. В чем сила? В инструментах Задача — не просто сформировать какой-то непонятный план, а чтобы рекламная компания принесла клиенту как можно больше пользы. Агент не генерирует план из головы. У него есть доступ к базе тысяч реальных кампаний, которые уже откручивались на Spotify. Он находит похожие на твою — по бюджету, длительности, аудитории — и смотрит, как они отработали. Сколько стоил один показ или клик, насколько объявления реально доходили до клиентов. На основе этого отбирает варианты, которые исторически давали лучший результат. Агент не гений, у него есть просто правильные инструменты. Он методично в них ходит и сравнивает результаты компаний с параметрами запроса. Никакого AGI. В чём профит? В клиентском опыте Spotify встроили экспертизу медиапланировщика прямо в продукт. И это самый сильный тип пользы от внедрения AI. Раньше медиаплан создавался за 15-30 минут: форма за формой, экран за экраном. Порог входа в рекламу на Spotify был высоким — нужно было разбираться в форматах, понимать, какой таргетинг работает. Теперь этот барьер исчез. Экспертиза стала частью интерфейса. Теперь рекламодатель пишет «хочу охватить молодёжь в Бразилии, бюджет €8000, август» — и получает готовый оптимизированный план за 5-10 секунд. Низкий порог входа, больше клиентов, больше рекламы, больше денег. Резюме Отличный кейс, на котором мы должны повторить 2 истины. Агент — это не волшебник. Это машина по перевариванию данных + движок принятия решений. Дай ему детальный алгоритм и нужные инструменты — сделает так хорошо, что вы не отличите от работы человека. Но результат для пользователя — магия. Экспертиза, которая раньше была за закрытой дверью, теперь доступна любому. Это меняет экономику бизнеса. Кстати, этот же сдвиг скоро будет ломать e-commerce. Поговорим об этом как-нибудь в другой раз.

Куда внедрить AI-агента, чтобы не получилось как всегда. Методика выбора кейса В прошлом посте всех разоблачили. Теперь пора обсудить методику, как нормально выбирать кейсы для агентов. Откуда берется профит от AI Есть процесс, который несёт дополнительную ценность — для клиента или для самой компании. Ответы на вопросы пользователей, скоринг лидов из CRM, составление отчёта для регулятора. Задача: используя технологию, перестроить этот процесс так, чтобы его доп. ценность стала выше. Профит может быть 3-х типов. 1. Уменьшаем затраты на процесс. Самое очевидное, что приходит на ум. Для агентов пока работает так себе. Если вы удешевили процесс на 30 %, это обычно не окупает косты команды разработки и LLM-сервинга. Исключение — суперчастотные процессы: продажи, поддержка и подобное. 2. Уменьшаем число ошибок в процессе. Был брак, процесс сломался, нужно переделывать. Теперь не надо. Особенно много это приносит в рисковых процессах, где цена ошибки огромна: юридический иск на компанию, простой конвейера на заводе. 3. Процесс начинает приносить новую ценность. Раньше клиент согласовывал страховой случай 2 недели — теперь за 15 минут. Раньше клиент писал в поддержку — теперь мы сразу решаем проблему, как только что-то пошло не так. Вот здесь самые большие деньги (хотя их и сложнее всего посчитать). Здесь создаётся ценность, которая напрямую влияет на пользовательский опыт — а значит, на retention и LTV. Для каких процессов подходят агенты Агенты очень исполнительные. Если вы описали процесс, модель без потери концентрации шаг за шагом всё выполнит. За счёт мультиагентности можно перемалывать огромное количество информации параллельно. Вывод: агенту нужно давать задачи с чётко описанным бизнес-процессом, внутри которого он будет делать много рутинных операций. Например, ходить в разные базы данных, изучать информацию, собирать данные, заполнять шаблоны и так далее. Но как бы все ни мечтали, LLM сильно глупее человека. У агентов высокий уровень ошибок, особенно на задачах с большим числом шагов. Работать с этим риском можно двумя способами: проверить человеком (но не каждое решение агента) либо забить (для низкорисковых процессов). Три примера внедрения 1. Автоматическая закрытие страховых претензий. Страховая Lemonade разработала бота для страховых выплат. Он автоматически решает 30% претензий буквально за несколько секунд. У вас угнали велосипед — и вам сразу же выплатили страховку. Спасли бесценное ментальное здоровье в трудный момент. 2. Генерация отчётов о клиническом исследовании. Фармкомпания Novo Nordisk автоматически делает драфт отчёта о проведённом клиническом исследовании. Это толстенный зарегулированный документ, который раньше группа людей писала несколько месяцев. Теперь драфт пишется за несколько минут, а затем несколько дней вычитывается на ошибки. Сократили время выхода препарата на рынок на несколько месяцев. Это миллионы долларов для большой фармы. 3. Разработка. Процесс перестраивается: программист пишет подробную спецификацию решения, агент под неё пишет много кода, программист ревьюит. Так могут делать только хорошие разработчики — нужно качественно описать, что надо сделать, и потом грамотно проверить. Но комьюнити поняло наоборот: что теперь все могут вайб-программировать. Жаль. Резюме Многие удивляются, но внедрение нужно начинать не с вопроса «куда бы нам фигануть агента», а с вопроса: «зачем нам вообще нужен этот процесс». Потом нужно добивать вторым — «какую ценность эта технология может в нём создать». Если вы это поймёте, уже будете впереди 90 % внедрятелей агентов. Дальше самое интересное: эту дополнительную ценность нужно спроектировать и разработать. Как хорошо что у вас есть этот канал, тут мы это и разберем.

Учёные создали AI, который экономит страховщикам 2,42 секунды. И тут я не выдержал Разговоров про ИИ много — выхлопа мало. И все уже начинают от этого уставать. Gartner прогнозирует, что более 40% проектов с ИИ-агентами закроются к 2027 году — из-за раздутых ожиданий и банального непонимания, нужен ли там вообще агент. На днях я наткнулся на статью, где британские ученые создали «умного» чат-бота для страховых агентов. Он экономит 2.5 секунды на запрос. Две. Секунды. С половиной. Авторы называют это «трансформацией страховой индустрии». У меня накипело. Давайте сейчас разберёмся, кто виноват и что делать. AI-помощник в каждый дом Все просто обожают внедрять AI-помощников. Есть человек, он что-то делает, а ему ещё AI помогает. Допустим даже, что человек рад этой помощи. Но делает человек. AI может суммаризовать встречу, подсказать текст письма, поискать в интернете. Но делает человек. Эта схема очень удобная, потому что не растит риски. Человек сам отвечает за свое делание. Ошибся — сам дурак, AI не при делах. Если AI помогает непрерывно во всём рабочем потоке — это может быть полезно. Но чаще всего делают решение для какой-нибудь микро-пуська-задачи. Вот в той самой статье про помощника страховщика бот решал задачу — поиск информации — и ускорял её на 2,4 секунды. Пусть у страховщика даже сотня таких поисков в день — это плюс 4 минуты. Его лучшие 4 минуты за рабочий день! Я знаю один успешный кейс связки агента и человека: разработка. Он успешный потому, что человек и агент работают в одном интерфейсе непрерывно, делают всю работу вместе. Разработчик не скидывает агенту одну микро-задачу — они пишут код бок о бок, весь день, на каждом этапе. AI видит контекст, понимает, что происходит, и помогает не на 2 секунды, а постоянно. Только так работает. Нужно поднимать ставки Важно понять. Основная польза агента — не в качестве одного конкретного ответа. Как бы качественно ты ни суммаризовал совещания, эффект будет ограниченным. Настоящая ценность агента — в принятии решений. И чем больше решений агент принимает сам, тем больше операционной нагрузки он снимает с человека. Это сразу поднимает ставки. Агент начинает отвечать за часть бизнес-процесса. Естественно, он может ошибиться. Но мы и не перепроверяем каждое его действие человеком — мы вводим правила контроля. Всё как с людьми: вы же не проверяете каждое решение сотрудника, но при этом контролируете, как он справляется. Как контролировать агентов Самое главное: не пытайтесь оптимизировать сразу все важные бизнес-процессы. Не получится, и вы только расстроитесь. Возьмите один — самый простой, самый понятный — и полностью перестройте его на AI-агентах. Так вы снимете главный риск: откусить больше, чем можете прожевать. Помимо этого, есть методы локального контроля: - метрики качества и observability, чтобы наблюдать, что всё ок (см. пост) - guardrails — проверка ответов другой моделью (см. кейс) - human-in-the-loop — подключение человека в определённых случаях (см. статью). - контроль доступов, чтобы агент не лез куда не надо (см. статью) Взяли один бизнес-процесс, перестроили его, обвешались системами контроля — работает. Выдохнули, пошли делать следующий. Вся инфраструктура при этом полностью переиспользуется. Резюме Есть два мира: Первый — пластмассовый мир AI-пилотов. В нём миллион внедрений, каждое оптимизирует что-то нерискованное, всё красиво отрисовано на слайдах, но никто не может честно сказать, что понимает, зачем это нужно. Второй — мир риска, пота и реальных денег. В нём мы берём реально важный для компании процесс, перестраиваем его и обвешиваем контролем, чтобы быть уверенными, что всё работает. Вытираем пот, собираем деньги и идём оптимизировать следующий. Шаг за шагом. Я выбрал второй мир. Предлагаю вам присоединиться ко мне — работы там ещё очень много.

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

Когда молчание агента — золото. Кейс компании DoorDash. DoorDash — крупнейшая компания по доставке еды в США, где с заказами часто что-то идет не так: ресторан не выдает еду, суп пролился по дороге, клиент не отвечает. Все эти кейсы летят в поддержку, и отвечать на них нужно быстро. Для этого в DoorDash построили агентскую систему, которая сама отвечает на вопросы курьеров. И здесь ошибка агента — это уже не ха-ха, смешная галлюцинация. Это реальные операционные и финансовые потери от неправильного действия курьера. В таких системах важно не только качество ответа, но и умение агента вовремя заткнуться, чтобы не наговорить того, в чем не разбирается. Как развить у агентов такие навыки осознанности, поговорим в этом посте. Архитектура системы Архитектура строится на базе LLM-workflow: 1. LLM суммаризирует кейс. Она берет обращение курьера, метаданные заказа и историю диалога, выделяет суть проблемы и готовит компактное представление кейса. 2. Ищем релевантные инструкции. Поиск идет по базе прошлых обращений и связанных с ними верифицированных статей. Сами прошлые ответы не являются источником истины — они нужны только для поиска. Ответ строится на основе проверенных инструкций. 3. Проверяем качества поиска. Новый LLM-вызов оценивает, действительно ли найденные документы подходят под запрос. Если нет — кейс сразу уходит человеку, а затем эксперты дополняют базу новой информацией. Этот LLM-вызов обычно называется LLM-guardrail. Далее мы подробнее это разберем. 4. Только теперь LLM генерирует ответ. LLM получает найденные инструкции в контекст и формирует ответ на их основе (вот теперь мы уже можем находить галлюцинации). 5. Проверяем сам ответ. Вторая LLM-guardrail оценивает: - нет ли галлюцинаций; - действительно ли он отвечает на вопрос; - корректен ли язык. 6. Решаем, отвечаем или нет. Если все ок, ответ уходит курьеру. Дальше уже поверх этого считаются метрики качества через LLM-as-a-judge. Если что-то guardrail не понравилось — отправляем на человека. Не рискуем. Почему это хорошая архитектура Во многих бизнес-задачах не нужно автоматизировать 100% обращений. Нужно надежно автоматизировать самые частые и понятные кейсы — и уже этого достаточно, чтобы получить заметный эффект. Закон Парето: 80/20. Самые частые 80% кейсов хорошо документированы, а вот оставшиеся 20% редкие, плохо формализованные. Именно на этих 20% попытка додавить становится очень дорогой и опасной. Поэтому зрелая система не героически отвечает в любой ситуации, а умеет вовремя отказаться. Нужно не всегда действовать, а понимать границы, где действие уже перестает быть адекватным по соотношению риск/профит. Себе тоже возьму на заметочку. Подробнее про guardrails Guardrail — это как раз механизм, который помогает разделить эти 80% и 20%. Эта LLM по ответу пытается предсказать, все ли хорошо в ответе с качеством. Если есть намек, что качество плохое, — сразу на человека. Это может быть ровно та же LLM-as-a-judge, которую мы используем для метрик качества. Только считаем мы ее в рантайме, а не постфактум для observability. Да, тогда теряется возможность стримить ответ сразу: сначала нужно дождаться всех проверок. Но действительно хорошие вещи стоит и подождать. Резюме На своих занятиях по внедрению AI я часто сравниваю два мира. В B2C все любят показывать “вау-агентов”: модные мультиагентные системы (см пост про DeepResearh), которые соревнуются друг с другом по объему сжирания токенов. В B2B агентские системы часто выглядят гораздо менее эффектно: сделай это, проверь поиск, проверь ответ, если есть сомнение — сразу на человека. Но это не потому, что B2B отстает. Просто риск ошибки несет уже не пользователь, а компания. Если в B2C AI обманул, ответственность на пользователе: надо было проверить. Если в B2B агент наврал при общении с клиентом, последствия — уже деньги компании и клиентский опыт. Поэтому ценится не максимальная автономия, а контролируемая автономия. И очень часто тут самый ценный навык агента — не сказать что-то умное, а вовремя заткнуться.

Модель управляемого риска: подбираем AI-агента под свои нервы В разработке агентов, как и в инвестициях, есть связка риск/профит. За потенциальную выгоду мы платим риском, который берем на себя. У AI-агентов обе величины сильно зависят от автономности. Система, где LLM в один промпт суммаризует диалог с клиентом — низкая автономность. Это и не очень рискованно, но профит ограничен. Автономный агент с доступом к CRM и возможностью отправить клиентам email — это уже совсем другая история. Потенциальный эффект выше, но и риск резко возрастает. Это удобно визуализировать на графике риск/профит (см. картинку). Разберем, как разные архитектуры агентов ложатся в эту кривую — и как по этому графику выбрать архитектуру под вашу задачу. Начнем с архитектур. Контролируемый рост риска (LLM-workflow) Самый предсказуемый вариант — фиксированная цепочка промптов, то есть оркестрация LLM-workflow (см. пост про орестрации). Все шаги прописаны заранее, у системы почти нет свободы “уйти не туда”. Каждую ветку можно отдельно отладить и измерить. Такая система прозрачна и контролируема. На этом участке кривой можно довольно предсказуемо наращивать ценность: добавлять новые узлы в граф, расширять логику, улучшать покрытие кейсов. Риск тоже растет, но управляемо. Взрыв риска (автономный агент) Но бесконечно растить workflow не получится: в какой-то момент сложность начинает съедать команду разработки. Тогда возникает соблазн перейти к автономному агенту (например, ReAct или Plan-and-Execute) — и дать ему набор ограниченных инструментов. В этот момент потенциальная ценность и риск одновременно подскакивают.И вместе с этим подскакивает нагрузка на команду, потому что теперь нужно управлять новым классом рисков: контроль доступов к тулам, защита от prompt injection, observability и тд). Иначе разработка быстро превращается в гадание на таро (долбанет, или пронесет?). Граница текущей технологии (переизбыток тулов) Дальше наступает момент, когда дополнительная автономность перестает окупаться. Инструментов становится все больше, они сложнее, контекст длиннее, а модель начинает чаще тупить и галлюцинировать. Вы подходите к границе, которую текущие LLM еще могут выдержать. Вселенная как будто говорит: “Остановись”. Автономность вредит (агент из телеграм-каналов) Модель настолько тупит, что с ростом автнономности качество уже деградирует. Надо было послушать вселенную в прошлом пункте. Концепция интересная, делать то что? Самое важное: архитектуру AI-системы нужно подбирать под риск, который вы способны контролировать, а не под максимальный профит, который она теоретически может дать. Второе: каждая новая капля автономности требует дополнительных усилий на контроль риска. Отсюда универсальное правило: начинайте с минимальной автономности, которая может решить задачу. Например: один вызов к LLM → затем цепочка промптов → затем агент → затем новые инструменты. И на каждом шаге задавайте два вопроса: 1) Сильно ли растет качество? Если нет — значит, вы уже уперлись в предел, и дальше усложнять систему нет смыла. Хорошая новость, что во многих задачах низкорисковой архитектуры вполне достаточно. Не везде нужен мега-агент. 2) Хватает ли у вас ресурсов контролировать этот риск? Оценивать качество, дебажить сбои, безопасно поддерживать продукт в работе. У разных компаний разная терпимость к риску. Если вы дикий стартап, у которого завтра кончатся деньги, вы более толерантны к риску. Тогда вам нужно меньше инфры для контроля. Я легко могу собрать демку агента с полным доступом к компьютеру, чтобы он мне создавал регулярные напоминалки полить цветы. Но я потом буду плохо спать по ночам. И тут возникает логичный вопрос: а оно того стоило?

Контекст — всему голова. Почему 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 с радостью «подумает» за вас. И эта галлюцинация вам точно не понравится.

Вправляем мозги 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-торте. Если пустить его в продакшн без присмотра, он сожрет весь бюджет и бесценные нервы (я не люблю просыпаться по ночам, когда инференс сломался). Готовьте агентов системно: продумайте архитектуру, платформизируйте компоненты и не экономьте на команде оптимизации.

Оркестратор AI-агента. 5 типов и инструкция по их применению. В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино. От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам. 1. LLM-Workflow (Детерминированное исполнение) Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты. Плюсы: надежно, предсказуемо, дешево. Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем. Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов. 2. ReAct (Рассуждение и выбор действия) Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться. Плюсы: гибкость. Может выбирать разные действия под ситуацию. Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель). Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»). 3. Reflexion (Рефлексия) Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный. Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика). Минусы: мнительность ест много токенов и замедляет работу. Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы. 4. Plan-and-Execute (Планирование и исполнение) Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план? Плюсы: рабочий вариант решения долгих задач без LLM-Workflow. Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается. Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика). 5. Plan-and-Execute + Мультиагентность План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом. Плюсы: мощь планирования + надежность исполнения Минусы: можно использовать только для узкого класса задач Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch). Резюме Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач. Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте про агентов. За каждую каплю автономности вы платите надежностью и рисками.

Испечь 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 в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?