ИИ-проверяющий одобрил ошибку агента: один процент успеха скрыл три разных дефекта

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

Эта история из разбора на Хабре хороша тем, что в ней нет ни одной откровенной лжи. И при этом результат плохой.

Почему проверяющий не заметил проблему

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

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

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

Три разных дефекта под одним процентом

Автор начинал с другой гипотезы: он думал, что короткая добавка к инструкции ухудшит работу агента. Эксперимент этого не подтвердил. Зато разбор записей показал, что за общей цифрой успеха прячутся три разные проблемы, и лечатся они по-разному.

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

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

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

Если смотреть только на средний процент, все три случая выглядят одинаково: «тест не пройден» или «тест пройден». Выбрать правильное лекарство по такой цифре невозможно.

Что делать на практике

Во-первых, разделяйте оценку действия и оценку объяснения. Факт отмены заказа, вызов нужного инструмента, наличие уточняющего вопроса лучше проверять кодом по логам и состоянию системы. Это детерминированно и не зависит от настроения модели.

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

В-третьих, давайте судье-ИИ узкую и явную рубрику. Чем меньше у него свободы «додумывать», тем реже он придумывает причины для отказа или, наоборот, одобряет то, что не должен.

В-четвёртых, раскладывайте провалы по типам. Для каждого неудачного прогона отвечайте на три вопроса. Ошибся агент? Была ли неполной инструкция или тест? Ошибся ли судья? Только после этого имеет смысл что-то менять.

Ограничения

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