Готовим ИИ-агента к продакшену

Всем привет! На связи Сергей Смирнов, AI-инженер в LLMStart. ИИ интересовал меня задолго до нынешнего хайпа: ещё со времён защиты кандидатской, он всегда был для меня не панацеей, а инструментом автоматизации и решения прикладных задач. С началом эры генеративного ИИ я занимаюсь разработкой агентских систем для бизнеса — и в этой статье хочу поделиться тем, что происходит, когда агента нужно не просто запустить, а сделать так, чтобы он работал надёжно, предсказуемо и без страха отдать его реальным пользователям.

Это будет своего рода дорожная карта подготовки агента к продакшену.

На примере ИИ-консультанта для взаимодействия с клиентами, разберём архитектуру production-ready системы: в первой части — ReAct-агент, инструменты, RAG и промпт-инжиниринг, во второй — то, что «под водой»: безопасность, MCP, observability, evaluation и dataset management.

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

AI как автоматизация и системный подход

Если рассматривать искусственный интеллект ^[1] как одно из средств автоматизации и повышения эффективности бизнеса, то это неизбежное будущее, поскольку автоматизация уже давно была, есть и, конечно же, будет.

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

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

Часть 1. Архитектура агента

Чтобы повествование не было абстрактным, буду рассказывать на примере своей предметной области — AI‑консультанта для клиентов компании LLMStart.

В этой статье мы уделим внимание ^[2] архитектуре и принципам проектирования без привязки к конкретным фреймворкам и библиотекам. Реализовать это можно будет на любом стеке (LangChain ^[3], LlamaIndex ^[4], CrewAI ^[5] и др.).

В первую версию агента заложим следующие задачи:

1. Взаимодействие с клиентами — первичная коммуникация.

2. Информирование клиентов о компании и предоставляемых услугах.

3. Работа с портфолио — поиск информации в кейсах, программах обучения ^[6], тренингах по искусственному интеллекту.

4. Управление заявками — создание заявок, отслеживание статуса.

5. Планирование встреч — назначение созвонов с экспертами.

Теоретический минимум: что такое ReAct-агент

Я решил строить агента на основе наиболее распространённого архитектурного паттерна ReAct (Reason + Act).

В центре этой архитектуры у нас языковая модель (LLM), которая взаимодействует непосредственно с пользователем. Она обрабатывает входящий запрос и решает (Reason), надо ли сразу дать ответ — например, поздороваться или попрощаться — воспользовавшись историей сообщений (Memory) или своей параметрической памятью ^[7].

Или же необходимо действовать (Act) — воспользоваться дополнительными инструментами, которыми агент снабжён:

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

2. Вызвать другие инструменты (Tools) для взаимодействия с CRM‑системой — подать заявку, посмотреть её статус или назначить встречу, добавить в календаре встречу с экспертом.

После выполнения действия агент наблюдает результат (Observe) и решает, достаточно ли информации для ответа или нужен ещё один цикл Reason → Act → Observe.

Архитектура агента

В нашем случае архитектурно это будет выглядеть так.

Пользователь будет взаимодействовать с системой через бота, а на бэкенде будет наш ReAct‑агент с LLM.

Также у нас будет Short‑term memory — как минимум, для хранения истории диалогов.

И набор инструментов:

1. Поиск информации по портфолио, образовательным программам на основе векторного (семантического) хранилища информации и документов.

2. Функциональные инструменты — поиск информации по клиенту, по его заявкам, создание новой заявки или регистрация новой встречи.

Эти инструменты уже будут взаимодействовать с базой данных CRM. Выбор СУБД и CRM нам сейчас не принципиален — мы рассматриваем архитектурную составляющую.

Инструменты агента

Давайте по каждому инструменту пройдёмся чуть‑чуть подробнее.

📅 schedule_meeting

Назначение встречи с клиентом в определённую дату и время.

📊 search_client_history

Поиск истории взаимодействия клиента с компанией.

📋 create_request

Создание заявки на консультацию, разработку или обучение.

По сути, самый основной инструмент — помещает информацию о клиенте в базу данных.

🔍 rag_search

Поиск информации о компании, услугах, кейсах.

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

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

RAG: Retrieval Augmented Generation

Под капотом этого инструмента — технология Retrieval Augmented Generation (RAG).

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

Документы для индексации

В первой версии агента будут загружены и проиндексированы 4 PDF‑документа:

1. Портфолио компании с кейсами (1 PDF, 25 страниц).

2. Программы консалтинга и обучения (3 PDF, по ~10 страниц каждый).

Архитектура RAG-пайплайна

Рассмотрим архитектуру RAG‑пайплайна внутри инструмента.

Поток данных:

1. Пользовательский запрос поступает к агенту.

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

3. Поисковая фраза отправляется как аргумент query в инструмент rag_search — точку входа в RAG‑пайплайн.

4. Производится поиск информации.

5. Ранжирование найденных чанков.

6. Отсечение топ‑k чанков — фрагментов документов, которые мы будем отдавать обратно агенту.

7. Агент использует их для формирования ответа.

8. Либо агент может принять решение, что ему нужно изменить свой запрос и повторно вызвать rag_search с другими аргументами.

Advanced RAG

Сразу скажу: я решил заложить Advanced RAG с самого начала — это не усложнение ради усложнения, а просто выработанная практика на основе предыдущего опыта ^[8]. Простой RAG почти никогда не дает хороших результатов с качеством поиска, поэтому я все чаще сразу начинаю с “джентельменского набора” RAG пайплайна.

Query Transformation. Агент выполняет преобразование (rewrite) всей истории переписки и последнего сообщения в конкретный поисковый запрос.

Hybrid Retrieval. Дальше, на этапе извлечения информации, у нас используется семантический и полнотекстовый поиск.

Мы используем эти два источника для поиска релевантных фрагментов, после чего объединяем их (Ensemble). У нас получается на выходе уже top-40 документов (этот параметр будет настраиваемый).

Reranking с Cross‑Encoder. Далее найденные фрагменты документов отправляем в следующий элемент Reranker, где у нас используется модель Cross‑Encoder.

Cross‑Encoder ранжирует каждый документ относительно пользовательского вопроса и определяет степень релевантности. Агенту мы возвращаем top‑5 наиболее релевантных документов.

Индексация документов

Для первой версии агента используем простой подход к индексации документов:

1. Загружаем все документы.

2. Разбиваем на чанки (chunking, splitting) — на фрагменты определённой длины. Размер чанка: 500 токенов, метод: скользящее окно (overlap), пересечение: 100 токенов с предыдущим чанком. Это стартовые параметры — оптимальный размер зависит от типа документов и модели эмбеддинга, подбирается экспериментально.

3. Вычисляем векторное представление чанка (vector embedding) и помещаем в семантическое/векторное хранилище.

4. Добавляем чанк в полнотекстовый индекс BM25.

Системный промпт — мозг и сердце агента

Мы разобрали все инструменты агента. Осталось главное связующее звено — системный промпт. Можно назвать его сердцем и мозгом ^[9] агента: именно он задаёт поведение ^[10].

Из чего же он у нас будет состоять?

Информация о компании

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

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

Правила ответов

Следующий блок — правила ответов: как именно агент должен отвечать.

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

Правила работы с инструментами

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

1. Чем отличается один инструмент от другого?

2. Когда использовать один, когда второй, когда третий?

3. Задать правила безопасности.

4. Можно проинструктировать по особенностям, например, работы с датами.

Примеры и антипаттерны

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

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

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

Резюме первой части

Итак, мы с вами рассмотрели всё самое необходимое, чтобы перейти к созданию агента.

С этой архитектурой можно приступать к реализации. Если воспользоваться AI‑driven подходом к разработке из статьи ^[11], то создание агента с такой архитектурой займёт несколько часов.

Мы разобрали архитектуру агента: ReAct, инструменты, RAG, системный промпт. Это солидный архитектурный фундамент — те самые видимые 20% системы, которые определяют, как агент думает, действует и взаимодействует с пользователем.

Но большая часть настоящей production‑ready агентской системы скрыта от глаз. Давайте перейдём к ней.

---

Часть 2. Подводная часть айсберга

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

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

Безопасность: Guards и Rate Limiters

Начну с безопасности. Здесь два взаимодополняющих слоя защиты: Guards отвечают за содержание (что входит и выходит из системы), а Rate Limiters — за количество и стоимость (сколько запросов, токенов и денег расходуется).

Guards — контроль содержания

Защита от зацикливания агента. Ограничение количества итераций внутри агентского цикла — максимум вызовов LLM (Model Call Limit) и инструментов (Tool Call Limit) на один запрос. Это защита не от внешних атак, а от ситуаций, когда агент сам себя вводит в бесконечный цикл размышлений или «tool bombing» — избыточное использование инструментов.

Защита персональных данных. Персональные данные не должны передаваться вне системы и утекать даже внутри неё. Для этого применяются маскирование, замена, подстановка и деперсонализация данных (PII Protection).

Фильтрация контента. Фильтрация на токсичность, запрещённые темы, prompt‑инъекции и прочие нежелательные паттерны (Content Filtering).

Rate Limiters — контроль затрат и нагрузки

Отдельный слой защиты — Rate Limiters: лимиты по стоимости, токенам, количеству запросов в минуту, бюджету в час и в день — как по пользователю, так и по системе в целом. Из инструментов — LiteLLM Proxy ^[12]: open-source шлюз перед LLM-провайдерами, который умеет ограничивать количество токенов и запросов в минуту, следить за бюджетом на пользователя и команду и сбрасывать счётчики по расписанию.

Guards и Rate Limiters защищают систему автоматически. Но есть операции, где автоматики недостаточно — нужно решение человека.

Human‑in‑the‑Loop: контроль необратимых действий

Дословно, это «человек в цикле» – в цикле работы агента — система запрашивает подтверждение перед выполнением операции. Общее правило: HITL нужно использовать, если операция необратима или влечёт серьёзные последствия.

Грубая классификация операций:

Обязательно — если действие необратимо или влечёт внешние последствия: финансовые транзакции, отправка сообщений от имени пользователя, изменение критичных данных, интеграции с внешними сервисами.

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

Не нужно — поиск информации, ответы на вопросы, чтение истории взаимодействий.

MCP‑протокол: стандартизация инструментов

MCP (Model Context Protocol) ^[13] — стандарт Anthropic для подключения инструментов к агентам: USB для AI-систем.

До MCP каждый агент интегрировал каждый инструмент отдельно: N агентов × M инструментов = N×M интеграций. MCP решает это через единый протокол: инструмент один раз оборачивается в MCP-сервер, любой агент подключается по стандартному интерфейсу — итого N+M вместо N×M.

MCP-сервер предоставляет агенту три типа возможностей: tools (инструменты для вызова), resources (данные и контекст) и prompts (готовые шаблоны промптов).

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

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

Какие преимущества мы от этого получим?

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

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

Изоляция. Агент ничего не знает о реализации каждого инструмента — в коде непосредственно нашего агента нет этой реализации. Она вынесена в одно место — в реализацию инструментов в MCP‑сервере.

Безопасность. Централизованный контроль доступа в одном месте.

Наблюдаемость. Все вызовы проводятся через MCP — легко трейсить и логировать.

RAG в продакшене: проблема «чёрного ящика»

Вернёмся к RAG Search из первой части.

Проблемы RAG в продакшене зачастую типовые. Откуда эта информация? Из каких документов она была получена? Сложно отлаживать: почему именно этот документ? Какой был score при поиске? Что в итоге попало в контекст? Бороться с галлюцинациями тоже сложно — модель придумала ответ или он из документа получен? Какой чанк был использован?

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

Источники ответов и прозрачность

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

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

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

Векторные базы данных

Для продакшена нам нужны векторные базы данных. In‑memory решения удобны при разработке, но в проде не работают:

• Перезапустил сервис — все данные пропали, индекс надо строить заново.

• База документов растёт — оперативка заканчивается, всё падает.

Векторная БД решает всё это: данные хранятся на диске, масштабируется горизонтально.

Популярные векторные базы: Qdrant ^[14], Chroma ^[15], Pinecone ^[16].

Для разработки и первых стадий подойдёт Chroma DB. Для продакшена я обычно использую Qdrant — он поддерживает self‑hosted режим и работает как с плотными (dense), так и с разреженными (sparse) векторами, что позволяет реализовать гибридный поиск. Альтернатива — Pinecone как managed‑решение.

Сразу оговорюсь, я разобрал трёх типичных представителей, но есть и другие варианты, например pgvector ^[17] (отличный выбор, если у вас уже PostgreSQL), Weaviate ^[18], Milvus ^[19] и другие — выбор зависит от существующего стека и требований к масштабированию.

Архитектура с векторной базой данных

Архитектурно это работает так: векторная БД хранит вектор каждого документа. При поиске вычисляется вектор запроса, база находит наиболее близкие документы по мере сходства векторов и отдаёт top‑k результатов.

Метаданные для фильтрации

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

Платформы для контроля за агентами

Две платформы покрывают 95% потребностей ^[20]: LangSmith ^[21] от команды LangChain и Langfuse ^[22] — open-source альтернатива. По функционалу почти идентичны, разница — в модели развёртывания.

LangSmith — облачный SaaS, есть бесплатный план с ограничением по трейсам: удобно на старте, без лишней инфраструктуры. Langfuse можно поднять у себя (self-hosted) — бесплатно и без ограничений, но нужно самому деплоить и обслуживать.

Мне они нравятся обе — для старта очень удобно LangSmith, для продакшена с требованиями к данным — Langfuse self-hosted.

Эти платформы покрывают три ключевые области, которые мы рассмотрим дальше: observability (мониторинг работы агентов), evaluation (контроль качества) и dataset management.

Observability: что происходит внутри LLM‑системы

Observability — мониторинг и трейсинг. Очень важно понимать, что происходит внутри LLM‑системы:

• Какой промпт использовался?

• Какие параметры передавали в LLM?

• Сколько токенов потрачено?

• Сколько стоит запрос?

• Какие документы нашлись в RAG? С каким score?

• Какие инструменты агент вызывал?

• Сколько шагов сделано?

• Где произошла ошибка ^[23]?

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

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

Дашборды и метрики

Благодаря сохранённым трейсам платформы позволяют строить дашборды для анализа производительности, стоимости и качества работы агентов. Можно создавать и кастомные метрики для бизнес‑показателей: возврат пользователей, конверсия в заявки и так далее.

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

• Производительность: Latency, Throughput — запросов в секунду, Tool call duration — время вызова инструментов.

• Стоимость: Cost per request, Tokens per request, Daily burn rate — ежедневные расходы.

• Качество: Success rate — % успешных запросов, Error rate, Hallucination rate, User satisfaction.

• Агентские: Reasoning steps — количество шагов мышления ^[24], Tool usage — какие инструменты используются, Retrieval quality – качество поиска.

Как прикинуть стоимость запроса

Любую LLM‑систему полезно оценить по стоимости до запуска. Покажем порядок расчёта на примере модели GPT‑4.1 (ориентировочные цены: $2 / 1M входных токенов, $8 / 1M выходных).

Один запрос пользователя к агенту — это системный промпт + история диалога + контекст из RAG на входе, плюс ответ на выходе. Допустим, вход ~2 000 токенов, выход ~500 токенов — получаем ~$0.008 за один вызов LLM. Но агент в ReAct‑цикле может сделать 2–3 итерации (вызов инструмента → обработка результата → ответ), значит умножаем на 2–3. Эмбеддинги же при RAG‑поиске добавляют доли цента.

Итого один диалог из 5 реплик пользователя: порядка $0.05–0.15. При 100 диалогах в день — $150–450/мес только на LLM. Добавьте инфраструктуру (векторная БД, хостинг, observability‑платформа) — и получите полную картину. Для снижения стоимости можно использовать модели поменьше, плюс реальная стоимость будет меньше за счет кэширования контекста (скидка до 75%).

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

Evaluation: контроль качества

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

Evaluation отвечает на эти вопросы: какое качество ответов мы имеем, пошла ли регрессия, где основные источники галлюцинаций.

С точки зрения ^[25] контроля качества есть два подхода: offline evaluation и online evaluation.

Offline Evaluation

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

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

Датасет — это, упрощённо, пара вопрос и эталонный ответ. На нём мы запускаем агента, сравниваем ответы с эталоном, вычисляем метрики, сохраняем результаты.

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

Минусы: не покрывает кейсы из реального трафика; датасет нужно создавать и поддерживать вручную или синтетически.

Метрики для Retrieval‑компоненты

Стандарт де‑факто — метрики от фреймворка RAGAS ^[26]. Две группы:

Retrieval — качество поиска:

• Context Precision — точность найденных документов (нет ли мусора в контексте?)

• Context Recall — полнота поиска (нашли ли всё нужное?)

Generation — качество ответа:

• Faithfulness — нет галлюцинаций, ответ построен на найденных документах

• Answer Relevance — ответ отвечает на вопрос

• Answer Correctness — ответ фактически верен

Почему нет привычной accuracy? Классическая accuracy требует точного совпадения с эталоном — для генеративных систем это не работает: два текстово разных ответа могут быть одинаково правильными.

Вместо неё RAGAS предлагает две метрики разной глубины:

• Answer Semantic Similarity — быстрая и дешёвая: сравнивает эмбеддинги ответа и эталона без вызова LLM. Показывает семантическую близость, но не говорит, откуда ответ — из базы знаний или придуман.

• Answer Correctness — составная: семантическое сходство + фактическое совпадение по извлечённым утверждениям. Дороже, но надёжнее.

Причём многие метрики не требуют эталонных ответов — оцениваются через LLM‑as‑Judge, когда другая языковая модель оценивает работу нашей системы.

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

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

Конкретные цифры — например, Faithfulness ≥ 0.95 или Context Precision ≥ 0.85 — появляются не из абстрактных best practices, а из вашего домена: в клиентской поддержке допустимый порог ниже, чем в медицинском или юридическом агенте.

Главное — иметь числа и отслеживать их динамику от версии к версии.

Фреймворков для оценки много: RAGAS ^[26], TruLens ^[27], DeepEval ^[28], встроенные метрики LangSmith ^[21] и Langfuse ^[22]. Для старта я предпочитаю метрики RAGAS + LangSmith или Langfuse для визуализации.

Метрики для агентов

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

Для оценки рассуждений и планирования зачастую применяется LLM‑as‑Judge. Классические способы тоже никто не отменял — например, прямое сравнение с эталонным датасетом: для решения конкретной задачи должны быть вызваны определённые инструменты с определёнными параметрами.

Тема оценки агентов в целом ещё молодая: во второй половине 2025 года многие фреймворки только начали добавлять агентские метрики, а туториалы обновляются до сих пор. Фреймворки те же, что и для RAG — RAGAS, DeepEval, LangSmith, Langfuse — плюс появляются специализированные библиотеки вроде LangChain AgentEvals ^[29]. Названия метрик у каждого фреймворка свои, но общая суть не меняется.

Online Evaluation и User Feedback

Теперь перейдем к online‑оценке — сбору обратной связи в реальном времени, на живых диалогах реальных пользователей. Есть два подхода:

User Feedback. Непосредственная обратная связь от пользователя — кнопочкой «лайк/дизлайк», «оцени ответ». Агент даёт ответ, и мы предоставляем пользователю возможность его оценить. Платформы вроде LangSmith обеспечивают удобную агрегацию и анализ этих данных. Плюсы: реальная оценка реальных пользователей. Минусы: низкий отклик — большинство не нажимает ничего; смещение выборки (жалуются сильнее, чем хвалят).

LLM‑as‑Judge. Автоматическая оценка в фоне — другая языковая модель оценивает качество ответов нашей системы. Плюсы: покрывает весь трафик без участия пользователя; настраивается под любые критерии. Минусы: стоит денег; судья-LLM тоже может ошибаться.

Схема такая: пользователь задал вопрос, агент сгенерировал ответ, а в фоне модель‑судья оценила его по набору метрик. Например:

• релевантность ответа вопросу,

• полнота,

• фактическая точность (построен ли ответ на извлечённом контексте, а не выдуман),

• грамматика,

• стиль,

• наличие галлюцинаций,

• токсичность,

• тональность.

В общем, всё, что угодно, можно настроить в промпте для такого «третейского судьи».

Для оценки желательно использовать сильную модель, отличную от той, что генерирует ответы. И, конечно, комбинировать автооценку с user feedback. Оценивать 100% запросов дорого, поэтому на практике LLM‑as‑Judge запускаем на выборке — обычно 5–20% трафика в зависимости от бюджета и объёма.

Датасеты: от обратной связи к улучшению системы

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

Платформы предоставляют удобный способ аннотирования проблемных трейсов и формирования датасетов на их основе. Цикл выглядит так: текущая версия работает в проде → собираем онлайн‑фидбек → создаём датасет из реальных вопросов, ответов и траекторий работы агента → дорабатываем решение → проводим offline‑оценку → если качество улучшилось — выпускаем новую версию в продакшен.

Dataset Management

Здесь рождается понятие dataset management — грамотное хранение и версионирование датасетов, чтобы можно было к ним вернуться, посмотреть, на каком датасете была получена та или иная оценка качества.

Это одна из первых вещей, с которой сталкиваешься при разработке production‑ready системы — и которая является одной из самой сложной, так как требует участия бизнеса – заставляет думать, анализировать. Вообщем, датасеты нужно создать ещё до запуска — руками или синтезировать с помощью языковой модели на основе базы знаний, реальных диалогов, логов.

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

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

Итоги

Вот мы и разобрали необходимую базу для построения production‑ready агентской системы, готовой к запуску в реальных условиях. Надеюсь это пригодится вам при проектировании, разработке, оценки трудоемкости и планировании вывода ваших агентов в продакшен.

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

---

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

Также за последние два года к нам часто обращались с запросом на проведение консультаций, курсов и тренингов по ИИ, мы хорошо “набили руку” на передаче своего опыта специалистам, командам и компаниям, и в этом году подготовили набор открытых онлайн-курсов по AI-driven разработке ИИ-агентов ^[30].

C описанием наших услуг, портфолио и курсов, можно ознакомиться на LLMStart.ru ^[31].

По вопросам сотрудничества пишите личное сообщение в Telegram ^[32] или ВКонтакте ^[33].

Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал ^[34] и ВК-сообщество ^[35]