Как измерить качество рассуждений ИИ-агента, а не угадать

Когда команда внедряет ИИ-агента¹ в поддержку, аналитику или автоматизацию, первый вопрос звучит так: он вообще правильно думает? Проблема в том, что «правильно» и «правдоподобно» — разные вещи. Модель может выдать верный итоговый ответ, но собрать его из выдуманного промежуточного шага, лишнего вызова инструмента и удачного совпадения. Финальная метрика точности этого не покажет. Ниже — что именно измерять в самой цепочке рассуждений и какими инструментами, если вы отвечаете за качество агента в проде.

Почему точность на выходе врёт

Классическая оценка LLM — сравнить финальный ответ с эталоном: exact match, F1, pass@1 на бенчмарке. Для агента этого мало по трём причинам.

• Правильный ответ по неправильной причине. Агент угадал число, но обоснование содержит ложное промежуточное утверждение. В новой задаче того же типа он ошибётся.
• Стоимость пути. Один агент решает задачу за 3 шага и один вызов инструмента, другой — за 14 шагов и восемь вызовов платного API. По финальной метрике они равны, по счёту за месяц — нет.
• Хрупкость. Многошаговый процесс копит ошибки. Если на каждом из 6 шагов вероятность ошибки 10%, шанс пройти всю цепочку чисто — около 53%, а не 90%.

Поэтому оценивать агента приходится минимум по двум осям: исход (решил ли задачу) и процесс (как он к этому шёл).

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

Что конкретно измерять в цепочке

Разложите «качество рассуждений» на измеримые компоненты. Каждый из них можно собрать в лог и посчитать по трассам агента².

1. Фактическая обоснованность (groundedness)

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

2. Корректность вызовов инструментов

Для tool-use агента считают: выбрал ли он нужный инструмент, передал ли валидные аргументы, правильно ли интерпретировал ответ. Отдельно — лишние вызовы: обращения к API, которые не понадобились для ответа.

3. Связность и отсутствие противоречий

Шаг N не должен противоречить шагу N−2. Длинные цепочки часто «забывают» ранний вывод и приходят к обратному. Это ловится сверкой утверждений между шагами.

4. Эффективность

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

Три способа получить оценку

У каждого метода своя цена и свой потолок надёжности. На практике их комбинируют: дешёвое покрывает объём, дорогое проверяет спорное.

LLM-судья — рабочая лошадка последних двух лет, но у него есть задокументированные искажения: чувствительность к длине ответа и позиционное смещение при парном сравнении (модель чаще выбирает первый из двух вариантов). Это описано авторами подхода MT-Bench и системы LLM-as-a-judge (Zheng et al., 2023). Отсюда практическое правило: судью нужно калибровать по размеченной людьми выборке и хотя бы иногда менять порядок вариантов местами.

Процессные метрики против исходных

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

Кому это нужно, а кому нет

Глубокая оценка рассуждений — не бесплатная и оправдана не всегда.

• Нужна: агент действует в проде с реальными последствиями — оформляет возвраты, ходит по внутренним API, готовит цифры для отчёта. Здесь ошибка в промежуточном шаге стоит денег или репутации, и знать про неё до выката важнее финальной точности.
• Нужна: вы сравниваете две версии агента или две модели под капотом и видите одинаковую точность. Различить их можно только по процессу — эффективности и обоснованности.
• Скорее нет: одноходовый ассистент без инструментов, где ответ либо верен, либо нет, а цена ошибки — переспросить. Хватит exact match и выборочного глазами.
• Скорее нет: прототип на стадии «взлетит ли идея вообще». Сначала докажите ценность, потом стройте пайплайн оценки — иначе оцениваете то, что через неделю выбросите.

С чего начать на практике

1. Включите логирование трасс: каждый шаг, вход, вызов инструмента, ответ инструмента, промежуточный вывод. Без трасс оценивать нечего.
2. Соберите 50–200 репрезентативных задач с известным исходом — это ваш golden set.
3. Навесьте дешёвые программные проверки: валидность аргументов, лимит шагов, отсутствие запрещённых вызовов.
4. Добавьте LLM-судью на groundedness и связность, но сначала прогоните его по 30–50 примерам, размеченным человеком, и посмотрите, совпадает ли он с людьми.
5. Считайте эффективность: шаги, вызовы, токены, деньги на решённую задачу. Ставьте порог и следите за дрейфом от релиза к релизу.

Итог оценки — не одно число «качество 8 из 10», а профиль: решает X% задач, при этом Y% рассуждений содержат необоснованные утверждения, в среднем Z вызовов инструментов, из которых часть лишние. С таким профилем видно, где именно чинить.

¹ Агент — LLM, которая не просто отвечает текстом, а планирует шаги и вызывает внешние инструменты (поиск, код, API), используя их результаты в следующих шагах.

² Трасса (trace) — полная запись одного запуска агента: последовательность шагов, вызванных инструментов и промежуточных выводов.

³ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом достаёт релевантные документы из базы и опирается на них, а не только на память из обучения.