Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Появился способ отдельно измерить, проверил ли дата-агент правдоподобный ответ инструмента и какой вывод в итоге выбрал. В препринте Zifu Tao и Changqing Yin из Tongji University, который не прошёл рецензирование и все числа для которого получили сами авторы, подмена результата снизила долю успешно решённых задач на 26–39 процентных пунктов. Для архитектуры агента из этого следует прямое требование: проверка должна приносить независимые данные, а выбор ответа нужно оценивать отдельно.
Как ToxicBench подменяет доказательство, но сохраняет исходные данные
ToxicBench проверяет тихое отравление инструмента. Инструмент выполняет запрос без ошибки, но прослойка меняет результат перед передачей агенту. Формат ответа остаётся правильным, а изменённое значение выглядит уместно для задачи.
Исходная таблица при этом не меняется. Для каждого задания агент получает одинаковый вопрос, данные, модель и набор инструментов; отличается только возвращённое наблюдение. Поэтому неправильный итог нельзя объяснить тем, что агент корректно проанализировал уже испорченный источник.
В показательном задании таблица содержит максимальную выручку Store B — 450 000 долларов. Инструмент возвращает ту же сумму, но связывает её со Store A. Проверка диапазона или знака числа ничего не обнаружит: агенту нужно заново установить связь между магазином и значением.
Подмены охватывают четыре типа ошибок. Числовые операции меняют сумму, отношение, знак или порядок в рейтинге. Подмена метки связывает показатель не с той сущностью. Ошибка схемы меняет смысл столбца или роли групп. Ошибка поиска возвращает подходящий по форме фрагмент, который поддерживает неверный вывод.
Для каждого задания заданы чистый и отравленный ответы, допустимые варианты формулировок и путь восстановления через исходные строки, метаданные или соединение таблиц. Такой дизайн проверяет не способность заметить сломанный API, а поведение при успешно выполненном вызове, которому нельзя доверять.
Почему вызов инструмента после ошибки ещё не считается восстановлением
Главное различие в ToxicBench проходит между проверкой и принятием ответа. Проверкой считается только новое действие с инструментом, которое даёт относящееся к задаче доказательство после подмены. Повторение рассуждения без обращения к данным не засчитывается.
Дальше система оценки смотрит, какой вывод агент принял. Если он получил чистое доказательство и дал правильный ответ, это восстановление. Если после проверки всё равно выбрал отравленный вариант, бенчмарк фиксирует принятие ложного ответа после проверки. Отдельно учитывается слепое согласие, когда агент не искал новых данных и сразу повторил результат инструмента.
Основной эксперимент охватил 118 заданий с GPT в LangGraph, smolagents и AutoGen. Обычный второй запуск помогал, когда прослойка отравляла только первое подходящее наблюдение: новая попытка могла получить чистые данные даже без специальной инструкции о проверке. Поэтому сравнивать защитный запрос только с одиночным запуском недостаточно — часть выигрыша даёт ещё одна возможность решить задачу.
При повторном отравлении новый вызов уже не гарантировал чистого доказательства. Агенты продолжали выбирать неправильный ответ даже после действий, которые формально считались проверкой. Значит, количество повторных вызовов само по себе не показывает надёжность.
Автоматическую оценку зафиксировали до отдельной проверки на 200 последовательностях вызовов и ответов. Совпадение с человеческой разметкой по итоговой успешности составило 96%. Разметчики также подтвердили пользу обычной повторной попытки и случаи принятия ложного ответа после проверки.
Что меняется в планах команд, которые строят агентов
ToxicBench не предлагает универсальную защиту, но меняет критерии приёмки. Тест «агент повторно вызвал инструмент» слишком слаб. В журнале выполнения нужно сохранять исходное наблюдение, данные последующей проверки и окончательный вывод, иначе нельзя отличить восстановление от повторного подтверждения той же ошибки.
Обычный повторный запуск стоит включить в контрольную группу до разработки сложных запросов для самопроверки. Если новый запрос помогает не больше повторной попытки, команда измерила дополнительный бюджет вычислений, а не пользу инструкции. Передавать первый ответ во второй маршрут тоже нужно осторожно: он направляет поиск, но одновременно закрепляет исходную версию.
Проверочный маршрут должен получать доказательство другим способом. Для табличного агента это может быть чтение исходных строк вместо повторения агрегата, проверка связи сущности и значения или обращение к метаданным столбца. Если оба маршрута используют одну прослойку и один способ получения результата, повторная проверка воспроизводит ту же точку отказа.
Работу проверяли преимущественно на небольших синтетических CSV-таблицах размером от 4 до 12 строк, а перенос на реальные данные изучали через структурированные задания на публичных таблицах. В эксперименты вошли GPT, Claude и Qwen, а также несколько агентских каркасов, но длинные производственные процессы с естественными сбоями инструментов сюда не входят. Поэтому ToxicBench уже подходит как схема внутреннего испытания, но его результаты не дают готовой оценки надёжности конкретного промышленного агента.
Практический вывод состоит не в том, чтобы всегда добавлять ещё один вызов. Команде нужны два независимых свойства: доступ к более надёжному доказательству и правило, которое выбирает между конфликтующими ответами. Без второго свойства агент может провести правильную проверку и всё равно сохранить первоначальную ошибку.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
