Всем привет! На связи Сергей Смирнов, AI-инженер в LLMStart. ИИ интересовал меня задолго до нынешнего хайпа: ещё со времён защиты кандидатской, он всегда был для меня не панацеей, а инструментом автоматизации и решения прикладных задач. С началом эры генеративного ИИ я занимаюсь разработкой агентских систем для бизнеса — и в этой статье хочу поделиться тем, что происходит, когда агента нужно не просто запустить, а сделать так, чтобы он работал надёжно, предсказуемо и без страха отдать его реальным пользователям.
Это будет своего рода дорожная карта подготовки агента к продакшену.
На примере ИИ-консультанта для взаимодействия с клиентами, разберём архитектуру production-ready системы: в первой части — ReAct-агент, инструменты, RAG и промпт-инжиниринг, во второй — то, что «под водой»: безопасность, MCP, observability, evaluation и dataset management.
Будет полезно разработчикам и техлидам, которые уже попробовали LLM в своём проекте и теперь думают, как выстроить вокруг этого нормальную систему. А также предпринимателям, которые хотят разобраться и понять, как строить и обеспечивать надежную работу подобных систем в продакшене.
AI как автоматизация и системный подход
Если рассматривать искусственный интеллект как одно из средств автоматизации и повышения эффективности бизнеса, то это неизбежное будущее, поскольку автоматизация уже давно была, есть и, конечно же, будет.
И как в любой качественной автоматизации, роль играет не какая‑то одна программная единица или компонент, а вся система и системный подход в целом.
Без системного подхода агент — просто дорогая игрушка. Это ключевой тезис всей статьи.
Часть 1. Архитектура агента
Чтобы повествование не было абстрактным, буду рассказывать на примере своей предметной области — AI‑консультанта для клиентов компании LLMStart.
В этой статье мы уделим внимание архитектуре и принципам проектирования без привязки к конкретным фреймворкам и библиотекам. Реализовать это можно будет на любом стеке (LangChain, LlamaIndex, CrewAI и др.).
В первую версию агента заложим следующие задачи:
-
Взаимодействие с клиентами — первичная коммуникация.
-
Информирование клиентов о компании и предоставляемых услугах.
-
Работа с портфолио — поиск информации в кейсах, программах обучения, тренингах по искусственному интеллекту.
-
Управление заявками — создание заявок, отслеживание статуса.
-
Планирование встреч — назначение созвонов с экспертами.
Теоретический минимум: что такое ReAct-агент
Я решил строить агента на основе наиболее распространённого архитектурного паттерна ReAct (Reason + Act).
В центре этой архитектуры у нас языковая модель (LLM), которая взаимодействует непосредственно с пользователем. Она обрабатывает входящий запрос и решает (Reason), надо ли сразу дать ответ — например, поздороваться или попрощаться — воспользовавшись историей сообщений (Memory) или своей параметрической памятью.
Или же необходимо действовать (Act) — воспользоваться дополнительными инструментами, которыми агент снабжён:
-
Обратиться в базу знаний для поиска информации по кейсам, портфолио, образовательным программам. То есть воспользоваться способностью Retrieve — извлекать информацию.
-
Вызвать другие инструменты (Tools) для взаимодействия с CRM‑системой — подать заявку, посмотреть её статус или назначить встречу, добавить в календаре встречу с экспертом.
После выполнения действия агент наблюдает результат (Observe) и решает, достаточно ли информации для ответа или нужен ещё один цикл Reason → Act → Observe.
Архитектура агента
В нашем случае архитектурно это будет выглядеть так.
Пользователь будет взаимодействовать с системой через бота, а на бэкенде будет наш ReAct‑агент с LLM.
Также у нас будет Short‑term memory — как минимум, для хранения истории диалогов.
И набор инструментов:
-
Поиск информации по портфолио, образовательным программам на основе векторного (семантического) хранилища информации и документов.
-
Функциональные инструменты — поиск информации по клиенту, по его заявкам, создание новой заявки или регистрация новой встречи.
Эти инструменты уже будут взаимодействовать с базой данных CRM. Выбор СУБД и CRM нам сейчас не принципиален — мы рассматриваем архитектурную составляющую.
Инструменты агента
Давайте по каждому инструменту пройдёмся чуть‑чуть подробнее.
📅 schedule_meeting
Назначение встречи с клиентом в определённую дату и время.
📊 search_client_history
Поиск истории взаимодействия клиента с компанией.
📋 create_request
Создание заявки на консультацию, разработку или обучение.
По сути, самый основной инструмент — помещает информацию о клиенте в базу данных.
🔍 rag_search
Поиск информации о компании, услугах, кейсах.
Остановлюсь на этом инструменте подробнее — это RAG Search, поиск по базе знаний. Он позволит агенту обладать информацией, которой нет в параметрической памяти языковой модели.
При вызове агент формирует поисковый запрос на основе всей истории диалога и последнего вопроса пользователя. Инструмент возвращает релевантные чанки (фрагменты документов), найденные в источниках.
RAG: Retrieval Augmented Generation
Под капотом этого инструмента — технология Retrieval Augmented Generation (RAG).
Её суть — поиск релевантной информации в документах для генерации точных ответов.
Документы для индексации
В первой версии агента будут загружены и проиндексированы 4 PDF‑документа:
-
Портфолио компании с кейсами (1 PDF, 25 страниц).
-
Программы консалтинга и обучения (3 PDF, по ~10 страниц каждый).
Архитектура RAG-пайплайна
Рассмотрим архитектуру RAG‑пайплайна внутри инструмента.
Поток данных:
-
Пользовательский запрос поступает к агенту.
-
Агент, учитывая всю историю взаимодействия с пользователем и последний вопрос, формирует поисковую фразу.
-
Поисковая фраза отправляется как аргумент query в инструмент rag_search — точку входа в RAG‑пайплайн.
-
Производится поиск информации.
-
Ранжирование найденных чанков.
-
Отсечение топ‑k чанков — фрагментов документов, которые мы будем отдавать обратно агенту.
-
Агент использует их для формирования ответа.
-
Либо агент может принять решение, что ему нужно изменить свой запрос и повторно вызвать rag_search с другими аргументами.
Advanced RAG
Сразу скажу: я решил заложить Advanced RAG с самого начала — это не усложнение ради усложнения, а просто выработанная практика на основе предыдущего опыта. Простой RAG почти никогда не дает хороших результатов с качеством поиска, поэтому я все чаще сразу начинаю с “джентельменского набора” RAG пайплайна.
Query Transformation. Агент выполняет преобразование (rewrite) всей истории переписки и последнего сообщения в конкретный поисковый запрос.
Hybrid Retrieval. Дальше, на этапе извлечения информации, у нас используется семантический и полнотекстовый поиск.
Мы используем эти два источника для поиска релевантных фрагментов, после чего объединяем их (Ensemble). У нас получается на выходе уже top-40 документов (этот параметр будет настраиваемый).
Reranking с Cross‑Encoder. Далее найденные фрагменты документов отправляем в следующий элемент Reranker, где у нас используется модель Cross‑Encoder.
Cross‑Encoder ранжирует каждый документ относительно пользовательского вопроса и определяет степень релевантности. Агенту мы возвращаем top‑5 наиболее релевантных документов.
Индексация документов
Для первой версии агента используем простой подход к индексации документов:
-
Загружаем все документы.
-
Разбиваем на чанки (chunking, splitting) — на фрагменты определённой длины. Размер чанка: 500 токенов, метод: скользящее окно (overlap), пересечение: 100 токенов с предыдущим чанком. Это стартовые параметры — оптимальный размер зависит от типа документов и модели эмбеддинга, подбирается экспериментально.
-
Вычисляем векторное представление чанка (vector embedding) и помещаем в семантическое/векторное хранилище.
-
Добавляем чанк в полнотекстовый индекс BM25.
Системный промпт — мозг и сердце агента
Мы разобрали все инструменты агента. Осталось главное связующее звено — системный промпт. Можно назвать его сердцем и мозгом агента: именно он задаёт поведение.
Из чего же он у нас будет состоять?
Информация о компании
Первое — мы положим в промпт информацию о компании. Вернее, будем загружать её из отдельного файла — для удобства сопровождения и обновления.
Расскажем, чем агентство занимается, и дадим агенту контактную информацию, которой он сможет делиться с клиентами, если диалог дойдёт до непосредственного взаимодействия с экспертами.
Правила ответов
Следующий блок — правила ответов: как именно агент должен отвечать.
Из практики: размещение наиболее часто востребованной информации прямо в промпте, наравне с чёткими правилами поиска, помогает избежать лишних вызовов инструментов и заметно повышает скорость ответа.
Правила работы с инструментами
Переходим к инструментам. Несмотря на то, что информация об инструментах автоматически добавляется к агенту через метаинформацию (при вызове LLM), бывает полезно дополнительно его проинструктировать:
-
Чем отличается один инструмент от другого?
-
Когда использовать один, когда второй, когда третий?
-
Задать правила безопасности.
-
Можно проинструктировать по особенностям, например, работы с датами.
Примеры и антипаттерны
Дальше в системном промпте стоит указать примеры и антипаттерны работы с инструментами, общий алгоритм взаимодействия.
Сразу оговорюсь: тщательность проработки системного промпта зависит от языковой модели, её зрелости и качества.
Слабые и маленькие модели потребуют детально проработанного промпта. Сильные модели ведут себя умнее и требуют меньше инструкций. Поэтому версия системного промпта всегда идёт в связке с языковой моделью, с которой применяется, а также параметрами ее запуска (температура и другие).
Резюме первой части
Итак, мы с вами рассмотрели всё самое необходимое, чтобы перейти к созданию агента.
С этой архитектурой можно приступать к реализации. Если воспользоваться AI‑driven подходом к разработке из статьи, то создание агента с такой архитектурой займёт несколько часов.
Мы разобрали архитектуру агента: 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: open-source шлюз перед LLM-провайдерами, который умеет ограничивать количество токенов и запросов в минуту, следить за бюджетом на пользователя и команду и сбрасывать счётчики по расписанию.
Guards и Rate Limiters защищают систему автоматически. Но есть операции, где автоматики недостаточно — нужно решение человека.
Human‑in‑the‑Loop: контроль необратимых действий
Дословно, это «человек в цикле» – в цикле работы агента — система запрашивает подтверждение перед выполнением операции. Общее правило: HITL нужно использовать, если операция необратима или влечёт серьёзные последствия.
Грубая классификация операций:
Обязательно — если действие необратимо или влечёт внешние последствия: финансовые транзакции, отправка сообщений от имени пользователя, изменение критичных данных, интеграции с внешними сервисами.
По ситуации — зависит от контекста и требований бизнеса: создание заявок, назначение встреч. В нашем агенте, например, клиент явно инициирует оба действия — подтверждение избыточно.
Не нужно — поиск информации, ответы на вопросы, чтение истории взаимодействий.
MCP‑протокол: стандартизация инструментов
MCP (Model Context Protocol) — стандарт 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, Chroma, Pinecone.
Для разработки и первых стадий подойдёт Chroma DB. Для продакшена я обычно использую Qdrant — он поддерживает self‑hosted режим и работает как с плотными (dense), так и с разреженными (sparse) векторами, что позволяет реализовать гибридный поиск. Альтернатива — Pinecone как managed‑решение.
Сразу оговорюсь, я разобрал трёх типичных представителей, но есть и другие варианты, например pgvector (отличный выбор, если у вас уже PostgreSQL), Weaviate, Milvus и другие — выбор зависит от существующего стека и требований к масштабированию.
Архитектура с векторной базой данных
Архитектурно это работает так: векторная БД хранит вектор каждого документа. При поиске вычисляется вектор запроса, база находит наиболее близкие документы по мере сходства векторов и отдаёт top‑k результатов.
Метаданные для фильтрации
Каждый чанк при индексации сохраняется не только как вектор, но и с метаданными: тип документа, ключевые слова, теги, язык, дата. При поиске это позволяет сначала отфильтровать нерелевантные документы — и только потом искать по смыслу. Результат: меньше мусора в контексте, точнее ответы.
Платформы для контроля за агентами
Две платформы покрывают 95% потребностей: LangSmith от команды LangChain и Langfuse — open-source альтернатива. По функционалу почти идентичны, разница — в модели развёртывания.
LangSmith — облачный SaaS, есть бесплатный план с ограничением по трейсам: удобно на старте, без лишней инфраструктуры. Langfuse можно поднять у себя (self-hosted) — бесплатно и без ограничений, но нужно самому деплоить и обслуживать.
Мне они нравятся обе — для старта очень удобно LangSmith, для продакшена с требованиями к данным — Langfuse self-hosted.
Эти платформы покрывают три ключевые области, которые мы рассмотрим дальше: observability (мониторинг работы агентов), evaluation (контроль качества) и dataset management.
Observability: что происходит внутри LLM‑системы
Observability — мониторинг и трейсинг. Очень важно понимать, что происходит внутри LLM‑системы:
-
Какой промпт использовался?
-
Какие параметры передавали в LLM?
-
Сколько токенов потрачено?
-
Сколько стоит запрос?
-
Какие документы нашлись в RAG? С каким score?
-
Какие инструменты агент вызывал?
-
Сколько шагов сделано?
-
Где произошла ошибка?
В общем, весь полноценный трейс — путь запроса от начала до конца с детализацией каждого шага. Очень полезно, чтобы он был сохранён и удобен для анализа.
Например, пользователь спрашивает: «Расскажи о ваших услугах по 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 — количество шагов мышления, 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 отвечает на эти вопросы: какое качество ответов мы имеем, пошла ли регрессия, где основные источники галлюцинаций.
С точки зрения контроля качества есть два подхода: offline evaluation и online evaluation.
Offline Evaluation
Суть в том, что мы тестируем систему на этапе разработки, вне контакта с пользователем, на заранее подготовленных датасетах.
Это обязательная вещь: любую разработку агентской системы надо начинать с анализа данных, вариантов использования и подготовки датасета, чтобы иметь численную метрику качества.
Датасет — это, упрощённо, пара вопрос и эталонный ответ. На нём мы запускаем агента, сравниваем ответы с эталоном, вычисляем метрики, сохраняем результаты.
Плюсы: быстро и дёшево — система ещё не в проде, но оценка уже есть; хорошо воспроизводимо; позволяет сравнивать версии пайплайнов между собой.
Минусы: не покрывает кейсы из реального трафика; датасет нужно создавать и поддерживать вручную или синтетически.
Метрики для Retrieval‑компоненты
Стандарт де‑факто — метрики от фреймворка RAGAS. Две группы:
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, TruLens, DeepEval, встроенные метрики LangSmith и Langfuse. Для старта я предпочитаю метрики RAGAS + LangSmith или Langfuse для визуализации.
Метрики для агентов
Метрики для агентов — отдельный блок, который не такой тривиальный, поскольку агент может выполнить одну и ту же задачу абсолютно разными путями, и надо понимать, как правильно оценивать его качество.
Для оценки рассуждений и планирования зачастую применяется LLM‑as‑Judge. Классические способы тоже никто не отменял — например, прямое сравнение с эталонным датасетом: для решения конкретной задачи должны быть вызваны определённые инструменты с определёнными параметрами.
Тема оценки агентов в целом ещё молодая: во второй половине 2025 года многие фреймворки только начали добавлять агентские метрики, а туториалы обновляются до сих пор. Фреймворки те же, что и для RAG — RAGAS, DeepEval, LangSmith, Langfuse — плюс появляются специализированные библиотеки вроде LangChain AgentEvals. Названия метрик у каждого фреймворка свои, но общая суть не меняется.
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 разработке ИИ-агентов.
C описанием наших услуг, портфолио и курсов, можно ознакомиться на LLMStart.ru.
По вопросам сотрудничества пишите личное сообщение в Telegram или ВКонтакте.
Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал и ВК-сообщество
Автор: smirnoff_ai
