Разработка ИИ-агентов закончилась — началось обучение: как менеджер учит агента без единой строчки кода

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

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

Первая попытка: файнтюнинг, которого никто не просил

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

Первая — время реакции. От момента «мы поняли, что агент ошибается» до момента «доученная модель поехала в прод» проходило столько времени, что клиент успевал забыть, зачем всё это затевалось. Категории вопросов меняются быстрее, чем едет пайплайн обучения.

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

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

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

Поворот: агент не учится, а вспоминает

Мы посмотрели, как ошибку разбирал бы живой наставник. Он бы не отправлял стажёра на переподготовку. Он бы сказал: «смотри, вот пример похожего вопроса и как на него надо было ответить — держи в голове». И в следующий раз стажёр бы вспомнил.

Ровно этот механизм мы и реализовали. При поступлении вопроса агент сначала идёт в pgvector, находит два-три самых близких примера из базы «эталонных диалогов» и подкладывает их в промпт как few-shot. Модель — GigaChat Pro или YandexGPT в зависимости от контура — видит не абстрактную инструкцию, а живую пару «похожий вопрос → правильный ответ». И повторяет паттерн.

Ключевая мысль: обучение ИИ-агентов теперь — это не обучение модели. Это управление корпусом примеров. А корпус — это база данных, которую менеджер может пополнять сам.

Интерфейс «Учитель»: как менеджер стал править агента

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

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

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

Что важно: инженер к этому процессу не подключается вообще. Раньше правка поведения агента была задачей на разработку. Теперь — задачей на минуту работы продакт-менеджера. Тот самый случай, когда «разработка ИИ-агентов» превращается в «настройку ИИ-агентов» — и это здоровое разделение труда.

А как это делают другие: Яндекс, Anthropic и рынок в целом

Мы держим руку на пульсе, поэтому иногда я рассказываю клиентам, где искать вдохновение. Яндекс летом опубликовал большой тьюториал по сборке агента на Cloud Functions с внешними вызовами через API Gateway, а параллельно запустил Agents Week — серию материалов о том, как устроены их внутренние агенты, тот же ассистент для Лавки. Если вам нужен быстрый прототип и вы уже в облаке Яндекса, «яндекс ИИ-агент» на AI Studio собирается за вечер — это отличная точка входа для команды, которая только начинает.

Anthropic в конце июля выкатила Claude Opus 5, где сильно подтянули agentic-бенчмарки вроде OSWorld и Frontier-Bench. Google — Gemini 3.6 Flash с упором на планирование и токен-эффективность. Все крупные игроки сходятся в одну точку: лучшие ИИ-агенты сегодня — это не самые «умные» модели, а те, у кого выстроен цикл обратной связи с людьми. Модель — двигатель, но рулит корпус примеров и правила поведения.

Отдельная волна, которую сейчас обсуждают — agentic retrieval вместо классического векторного RAG. Идея в том, что агент сам решает, чем искать: pdfgrep, keyword search, SQL-запрос, вызов внешнего сервиса. Векторный поиск становится одним из инструментов, а не единственным. Мы пробуем этот подход на новом проекте и уже видим, что для структурированных документов он работает точнее. Про это будет отдельная статья.

Где эта схема ломается и что мы с этим делаем

Честный дисклеймер: подход «обучаем через примеры» — не серебряная пуля.

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

Второе — типовые задачи, где ответ должен быть строго форматированным. Здесь few-shot помогает, но не решает всё; надо ещё JSON Schema, валидацию и повторный вызов при неудаче.

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

Что изменилось у клиента

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

Инженеры высвободили руки на действительно инженерные задачи: инфраструктуру, надёжность, наблюдаемость. А продукт — тот, кто реально понимает клиента, — получил рычаг, которым раньше владел только программист.

Мой главный вывод из этой истории: если ваш проект стоит на месте, потому что «нужно доучить агента», проверьте, точно ли вам нужен файнтюнинг. Возможно, вам нужен экран, где менеджер пишет одну строчку — и агент завтра ведёт себя иначе. Обучение ИИ-агентов в 2026 году всё чаще начинается не со сбора датасета, а с человеческого разговора о том, как правильно.

А как в вашей команде устроен цикл «агент ошибся → агент исправился»? Кто держит руки на этом руле — инженер или продукт?

Похожие статьи

• Один большой промпт превратился в систему ИИ-агентов: история, где мы перестали чинить и начали делить
• Кодекс ИИ-агента в продакшене: правила, которые мы выписали после нескольких дорогих ошибок
• ИИ-агент для учётной системы «Гермес»: как мы построили платформу ИИ-агентов вокруг легаси-ERP
• Локальный ИИ-агент без интернета: как мы собрали помощника инженера на T-Lite и MCP внутри периметра заказчика