Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ошибочные вызовы инструментов закрытого LLM-агента можно отсекать без доступа к вероятностям самого агента. В не прошедшем рецензирование препринте Amazon, где все числа измерили сами авторы, внешний оценщик достиг AUROC 0,825 против 0,598 у словесной самооценки агента: эта метрика показывает, насколько уверенно сигнал ставит правильные действия выше ошибочных. Такой оценщик можно подключить перед возвратом денег, изменением данных или запуском кода и отправлять сомнительные действия человеку.
Как внешний оценщик читает чужой вызов
Агент сначала формирует действие: имя инструмента, запрос, код или набор аргументов. Отдельная модель с открытыми весами получает тот же контекст, схему инструмента и уже готовое действие, но не видит веса и внутренние вероятности агента.
Оценщик не генерирует вызов заново. Он проводит предварительный проход по известному тексту и вычисляет его логарифмическую вероятность. Это убирает длительную генерацию и позволяет проверять модель от другого поставщика через стандартный перехватчик вызовов инструментов.
Сигнал читают несколькими способами. Принудительное продолжение оценивает вероятность каждого значения аргумента. Request-PMI дополнительно вычитает вероятность того же значения без пользовательского запроса, чтобы частое и правдоподобное значение не выглядело правильным само по себе.
Два других способа смотрят на действие целиком. Бинарный вердикт сравнивает вероятности ответов YES и NO на вопрос о корректности, а конкуренция инструментов проверяет, предпочитает ли оценщик выбранную функцию похожим альтернативам.
Разделение оказалось практичным. Вероятность конкретных токенов лучше выявляет неверные аргументы, а общий вердикт — вызов неподходящего инструмента или целиком ошибочное решение. Если тип ошибки заранее неизвестен, сигналы объединяют, предварительно определив на размеченной проверочной выборке, в какую сторону каждый из них связан с корректностью.
Где оценка помогает, а где теряет смысл
Метод проверяли на вызовах функций, генерации кода, командах оболочки и запросах SQL. В набор вошли BFCL, xLAM/APIGen, NESTFUL, AppWorld, InterCode nl2bash, LiveCodeBench, APPS, CodeContests и BIRD. Правильность определяли исполнением, разбором синтаксического дерева или сравнением с эталоном, а не другой моделью.
На почти детерминированных агентах 94–96% повторных вызовов совпадали, поэтому согласованность повторов почти не давала нового сигнала. Внешняя оценка превосходила её на +0,14–0,19 AUROC и не требовала многократно запускать дорогого агента.
Сигнал также работал как гейт. Когда автоматика принимала половину наиболее уверенных вызовов, а остальные отправляла на проверку, доля правильных принятых действий выросла на +0,05–0,30. Это не означает, что оценщик исправляет вызов: он ранжирует действия и помогает расходовать ограниченный бюджет ручной проверки.
Второй режим возвращал оценку уверенности самому агенту вместе с результатом инструмента. Успешность задач выросла на +0,119 в nl2bash и на +0,137 в AppWorld, но контрольные опыты показали разные причины. В nl2bash значение оценки действительно помогало при тихих ошибках, тогда как в AppWorld похожий эффект давало случайное число: исключение и трассировка уже сообщали агенту о проблеме.
Граница метода проходит там, где корректность можно вывести из контекста, схемы и действия. Он не проверяет внешний факт, которого нет во входных данных, а на tau2-bench не помог с ошибками-пропусками, когда агент вообще не совершал требуемое действие.
Что менять в архитектуре агента
Для рискованных вызовов нужен отдельный этап между формированием действия и его исполнением. Он передаёт вызов оценщику, сравнивает результат с порогом и либо разрешает действие, либо переводит его на ручную проверку. Оценивать все шаги необязательно: перехватчик можно поставить только перед записью, удалением, платежом или исполнением кода.
Отсутствие обучения не отменяет проверку на собственных данных. Направление некоторых сигналов меняется между режимами: правдоподобный, но неверный аргумент может получить высокую вероятность. Порог и знак связи нужно подбирать отдельно для каждого класса действий, иначе гейт способен пропускать именно худшие вызовы.
Инфраструктурная цена — ещё одна размещённая модель. Для Qwen3-14B в формате fp8 на одной L40S медианное время оценки составило 123–159 мс. Замер относится к одиночной GPU и предварительному проходу; работу при общей очереди нескольких продуктов отдельно не профилировали.
Стоит также явно выбрать поведение при сбое оценщика. Предложенная схема пропускает вызов при тайм-ауте, чтобы проверка не останавливала агента. Для чтения данных это может быть приемлемо, но возврат денег или удаление записи требуют отдельного решения: остановить действие, переключиться на статическое правило или запросить подтверждение.
Работа не предлагает универсального детектора ошибок. Она даёт технически простой источник уверенности там, где закрытый API скрывает вероятности, повторная генерация возвращает тот же ответ, а последствия действия можно проверить только после исполнения. Для команд с такими агентами это повод добавить внешний гейт в архитектуру, но не повод запускать его без размеченной проверки на собственных вызовах.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
