Сергей Смирнов, ИИ-инженер и основатель LLMStart.ru, описал подход к оценке production-агента, который консультирует клиентов компании «Айтон» по системе 1С:УНФ через Telegram-бот. Агент построен на фреймворке Langchain и заменяет живых менеджеров, отвечавших на вопросы вроде «Как настроить склад с учётом резерва?» или «Можно ли вести производство по серийникам?».
Главная проблема, с которой столкнулась команда, — невозможность доказать прогресс на малом числе тестов. При 15 кейсах в одной области правильный ответ на один дополнительный вопрос даёт скачок метрики на 7%. Это статистический шум, а не реальное улучшение. Ручной просмотр 10–15 примеров командой — то, с чего начинают большинство проектов, — Смирнов называет «глухим потолком»: выше него не прыгнуть без инструмента, который измеряет качество в цифрах.
| Область оценки | Что проверяется | Метрики |
|---|---|---|
| RAG | Качество поиска и ответа по базе знаний | faithfulness, answer_correctness, answer_relevancy (RAGAS) |
| Agent | Выбор инструмента и корректность передаваемых данных | Авторские метрики поверх RAGAS |
| Clarifying | Умение задавать уточняющие вопросы при неоднозначных запросах | Clarifying Accuracy (0.0 / 0.5 / 1.0), F1 через Венгерский алгоритм |
| No-feature | Корректная реакция на запросы несуществующего функционала | No-feature Verdict: «есть» / «нет» / «не знаю» |
Основа системы оценки — 10 317 сообщений из Telegram, которые заказчик выгрузил из реальных переписок менеджеров с клиентами за несколько месяцев. Эти логи прогнали через Gemini 2.5 Pro двумя промптами: первый искал паттерны, где менеджер задаёт уточняющие вопросы, второй — запросы клиентов на проверку наличия конкретного функционала. Такой подход позволил не выдумывать эталоны «из головы», а извлечь их из реального поведения людей, которых агент должен заменить.
Система разбита на четыре области: RAG, работа с инструментами, уточняющие вопросы и обработка отсутствующего функционала.
Система оценки разбита на четыре функциональные области. Первая — RAG (поиск по базе знаний): стандартные метрики RAGAS (faithfulness, answer_correctness, answer_relevancy), агент здесь — чёрный ящик. Вторая — Agent (работа с инструментами): проверяется не качество текста, а механика — правильный ли инструмент выбран, корректные ли данные переданы. Третья — Clarifying (уточняющие вопросы): измеряет, умеет ли агент остановиться перед неоднозначным запросом и задать нужный вопрос. Четвёртая — No-feature (отсутствующий функционал): фиксирует, не галлюцинирует ли агент несуществующие возможности системы.
Из анализа переписок выделены девять категорий контекста, которого клиентам постоянно не хватает: техническая среда (браузер или тонкий клиент, версия), состояние процесса, идентификация объекта, терминологическая неоднозначность (слово «резерв» в 1С:УНФ может быть товарным, финансовым или оценочным), истинная цель запроса, источник данных, бизнес-логика, визуальный контекст и зависимость от конфигурации. Последнюю категорию добавили уже после запуска — из боевого опыта.
Для области No-feature введены три жёстких вердикта: «есть» (подтверждение найдено в базе), «нет» (точно отсутствует, с доказательствами) и «не знаю» (информации нет вообще). До появления третьего варианта агент либо утверждал, что функция существует, либо уходил в расплывчатые формулировки вроде «это возможно при правильных настройках».
Две авторские метрики — Clarifying Accuracy и No-feature Verdict — не покрываются стандартным RAGAS. Clarifying Accuracy оценивается по трём уровням: 1.0 — агент задал вопрос и попал в нужную категорию, 0.5 — вопрос задан, но категория не та или вопрос лишний, 0.0 — агент не спросил, хотя должен был, или наоборот. Для честного расчёта F1 при сопоставлении нескольких уточняющих вопросов агента с эталонными применяется Венгерский алгоритм — классический метод оптимального назначения из комбинаторной оптимизации, который исключает задвоение совпадений.
Вся инфраструктура хранится в Langfuse — там лежат датасеты и логи трейсов. Запуск оценки происходит из одной точки: скрипт сам распределяет вопросы по областям и применяет нужные метрики. Команда отмечает показательный момент: однажды метрика упала не потому, что агент деградировал, а потому что его ответ оказался точнее старого эталона — и LLM-судья оценил новый ответ выше. Это, по словам Смирнова, и есть признак работающей системы оценки: она честна даже когда результат неудобен.
