TL;DR
RITE — бенчмарк (набор тестов), который проверяет, что делает агент с инструментами, когда один из инструментов молча вернул неверное, но правдоподобное значение. Ни ошибки, ни пустого ответа. Формат корректный, значение выглядит разумно, просто оно не то. Исследователи берут готовую цепочку шагов, подменяют одно значение посередине и смотрят, дойдёт ли агент до верного ответа.
Главная находка: тихая ошибка примерно вдвое снижает долю решённых задач, и это хуже, чем явный сбой. Если инструмент честно сказал «ошибка», агент справляется заметно лучше. Если он вернул «Блокчейн» вместо «Местный спорт», агент берёт это как факт и тащит дальше по цепочке. Провал идёт в три ступени: агент не замечает подвох, даже заметив — не перезапрашивает источник, а даже перезапросив — не встраивает исправленное значение в итоговый ответ.
Лёгкая проверка состояния (State Checker) помогает на первых двух ступенях: агенты чаще замечают и перезапрашивают. На итоговом результате это сказывается слабо. Заставить агента посмотреть проще, чем заставить его починить.
Схема метода
Это схема бенчмарка и трёх точек отказа агента, а не готовая техника промптинга.
ПРОТОКОЛ ТЕСТА (на одной и той же точке цепочки):
Условие 1: правильное значение → базовый уровень
Условие 2: явный сбой (ошибка) → агент видит проблему
Условие 3: тихая ошибка → правдоподобное, но неверное значение
Дальше агент действует свободно, до финального ответа.
ТРИ СТУПЕНИ, НА КОТОРЫХ АГЕНТ ТЕРЯЕТ ЗАДАЧУ:
СТУПЕНЬ 1: Заметил, что значение может быть неверным? (Noticed)
СТУПЕНЬ 2: Перезапросил источник значения? (refetch)
СТУПЕНЬ 3: Встроил исправленное в итоговый ответ? (recovery)
Пример применения
Метод в узком смысле — бенчмарк. Практическая часть — применить его выводы к своему агенту. Лучше всего это работает там, где агент берёт значения из инструментов, а ошибка в них меняет итог. Для простых одношаговых запросов проверка избыточна.
Задача: Вы настроили агента для селлера на Wildberries. Он вызывает инструмент «определи категорию товара», затем «найди комиссию по категории», затем «посчитай маржу и рекомендуемую цену». После обновления справочника первый инструмент вместо «Кроссовки детские» стал возвращать «Кроссовки». Ошибки нет, значение правдоподобное, но комиссия и маржа будут другими.
Промпт (фрагмент системной инструкции агента):
Ты — агент-аналитик для селлера маркетплейса. Считаешь маржу и рекомендуемую цену товара.
<ПравилаПроверки>
Перед тем как использовать значение из инструмента в расчёте, сверь его с исходным запросом пользователя.
1. Категория, бренд, размер, объём, цена — это ключевые значения. Для каждого напиши одной строкой: «Из запроса: ...; от инструмента: ...; совпадает: да/нет/не уверен».
2. Если «нет» или «не уверен» — повторно вызови инструмент, который это значение выдал. При необходимости подтверди значение вторым источником.
3. Если после повторного вызова значение изменилось — пересчитай ВСЕ шаги, которые зависели от старого значения. Не оставляй старые числа.
4. В финальном ответе перечисли, какие значения ты перепроверял и что изменилось.
Запрос: рассчитай маржу и цену для «кроссовки детские Nike, размер 32, закупка 2 400 ₽».
Результат: Агент перед расчётом выведет короткую сверку ключевых значений. Если категория от инструмента не совпала с запросом («Кроссовки» вместо «Кроссовки детские»), он перезапросит категорию и пересчитает комиссию и маржу. В конце будет список того, что перепроверялось. Но это не гарантия: по данным исследования, часть агентов всё равно не встроит исправление в итог. Поэтому финальный ответ стоит выборочно проверять глазами.
Почему это работает
Слабость LLM. Агент строит рассуждение на всём, что уже лежит в истории. Значение от инструмента для него — «факт из внешнего мира». Если оно правдоподобно и в нужном формате, у модели нет повода сомневаться. Явная ошибка заметна, тихая — нет.
Сильная сторона. Если модели прямо указать, что именно сверять и с чем, она это делает: в исследовании лёгкая проверка состояния заметно повысила долю случаев, когда агент замечал проблему и перезапрашивал источник. Сопоставить два значения — простая для модели операция.
Где метод упирается в предел. Сам факт «заметил» и «перезапросил» ещё не приводит к верному ответу. Исправленное значение нужно пронести через все зависимые шаги, и именно тут агенты чаще всего теряют результат. Поэтому в инструкции полезно отдельно требовать пересчёт зависимых шагов (пункт 3 в шаблоне) и отчёт о том, что изменилось.
Рычаги управления: - Список ключевых значений — сузьте до тех, что реально влияют на итог. Иначе агент будет перепроверять всё подряд и жечь шаги. - Формат сверки («из запроса / от инструмента / совпадает») — убери, если нужен короткий ответ. Оставь, если нужно видеть, что агент проверял. - Пункт про пересчёт — самый важный. Без него проверка нередко остаётся формальностью. - Отчёт в конце — даёт вам быстрый способ увидеть, где агент сомневался.
Шаблон промпта
В доступной части статьи готового промпта нет, а State Checker описан лишь как «лёгкий». Шаблон ниже — реконструкция по логике трёх ступеней, а не копия из статьи. Используйте как стартовую заготовку.
Ты — {роль_агента}. Твоя задача: {задача}.
Ты используешь инструменты: {список_инструментов}.
<ПравилаПроверки>
Перед тем как использовать значение из инструмента в следующем шаге, сверь его с исходным запросом.
1. Ключевые значения: {список_ключевых_значений}.
Для каждого напиши одной строкой: «Из запроса: ...; от инструмента: ...; совпадает: да/нет/не уверен».
2. Если «нет» или «не уверен» — повторно вызови {инструмент_источник} или подтверди значение вторым источником.
3. Если значение изменилось — пересчитай все шаги, которые на него опирались.
4. В финальном ответе перечисли: что перепроверялось, что изменилось.
Запрос пользователя: {запрос}
Что подставлять:
- {список_ключевых_значений} — то, от чего зависит итог (категория, цена, дата, клиент, регион).
- {инструмент_источник} — инструмент, который выдаёт эти значения (его можно перезапросить).
Ограничения
⚠️ Текст статьи обрезан: в доступной части нет раздела с результатами State Checker в деталях, анализа по типам ошибок и приложений. Выводы о проверке опираются на аннотацию и введение.
⚠️ Проверка не лечит: лёгкая проверка состояния заставляет агента чаще замечать и перезапрашивать, но итоговая доля решённых задач растёт слабо. Не рассчитывайте, что одна строка в инструкции закроет проблему.
⚠️ Перезапрос работает не всегда: в тесте повторный запрос к источнику всегда возвращает верное значение (так построен бенчмарк). В жизни источник может стабильно врать, и перезапрос ничего не даст. Нужен независимый второй источник.
⚠️ Узкая среда: тесты на корпоративных электронно-коммерческих цепочках, данные внутренние. Перенос на ваши задачи логичен, но не проверен.
⚠️ Устаревшие значения не проверяли: ошибки типа «значение было верным раньше» исключили, потому что агенту нечем их заметить без внешних данных о времени.
Как исследовали
Исследователи из HKUST и Tencent взяли девять реальных рабочих цепочек электронной коммерции, написанных людьми. Прогнали по ним входные данные из производственных логов и записали ход выполнения. Затем в выбранной точке цепочки подменили одно значение. Получилось 167 «троек», всего 501 тест: правильное значение, явный сбой и тихая ошибка в одной и той же точке с одной и той же историей до неё. Благодаря этому можно честно сравнивать разные модели и разные типы ошибок. Тихие ошибки собирали по таксономии из семи типов: соседняя категория, слишком общая или узкая категория, похожий объект, сдвиг атрибута, соседний числовой диапазон, синоним с другим смыслом и устаревшее значение. Последний тип в итоге не использовали.
Протестировали 10 свежих моделей, включая Claude Opus 4.8 и GPT-5.5, температура 0, лимит 25 шагов. Доля решённых задач при правильном значении была 0,72–0,83, при тихой ошибке упала до 0,28–0,40. При явном сбое было 0,51–0,56. «Удержание» (отношение результата с тихой ошибкой к базовому) составило 0,35–0,53. Агенты заметили тихую ошибку в 21–34% случаев, явный сбой — в 47–59%.
Неожиданностей две. Даже сильнейшие модели теряют около половины результата. А заметить проблему ещё не значит её решить: после заметки агент часто не перезапрашивает источник, а после перезапроса не всегда доносит верное значение до финала. Claude Opus 4.8 показал лучший баланс между условиями (разрыв «явная минус тихая» минимальный), открытые модели просели сильнее.
Адаптации и экстраполяции
Это мои выводы по мотивам, не результаты статьи.
🔧 Техника: сделать сбой явным → агент справляется заметно лучше. Если ваша автоматизация или кастомный инструмент может вернуть пустое или подозрительное значение, пропишите это в описании инструмента:
Если по запросу ничего не найдено или значение не удалось определить — верни явную ошибку
«НЕ_НАЙДЕНО: <причина>», а не ближайшее похожее значение.
Логика из статьи: явные сбои агент обрабатывает значительно лучше тихих, поэтому лучше превратить тихую ошибку в громкую, чем надеяться, что агент догадается.
🔧 Техника: выборочный аудит отчёта проверок → ловит оставшийся пропуск. Раз проверка сама по себе не гарантирует исправление, раз в N запусков просматривайте раздел «что перепроверялось» в финальных ответах. Если агент сомневался, но итог остался старым — вот ваш сигнал, где инструкцию надо усилить.
Ресурсы
- Работа: RITE: Evaluating End-to-End Resilience to Silent Tool Errors in E-Commerce Agentic Systems (ICLR 2027).
- Авторы: Wenshuo Zhang, Yuquan Lin, Yushi Sun, Yishi Lin, Rui Sheng, Peng He, Han Gao, Jikai Wang, Yifeng Rong.
- Организации: The Hong Kong University of Science and Technology; Tencent.