Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агенты распознают, что поиск больше не приносит полезных результатов, но продолжают обращаться к нему до исчерпания лимита. В нерецензированном препринте, где все числа получили сами авторы, модели помечали ответы сломанного источника как бесполезные в 97–100% случаев, однако после пяти таких ответов подряд большинство останавливалось не чаще чем на 7% вопросов. Значит, продукту недостаточно попросить модель следить за качеством поиска: решение об остановке нужно закреплять в управляющем контуре.
Как отделили оценку результата от решения продолжать
Обычный тест показывает только итоговый ответ и не объясняет, почему агент прекратил поиск. Он мог накопить достаточно доказательств, дождаться последнего доступного шага или случайно ответить раньше. Авторы поэтому отдельно записывали оценку результата, представление модели о шансах на успех и следующее действие.
Для эксперимента взяли вопросы HotpotQA. Для каждого вопроса агент получал небольшую базу из десяти абзацев, два из которых содержали нужные факты. Когда источник должен был сломаться, полезный результат заменяли абзацем из базы другого вопроса; в других режимах источник восстанавливался после нескольких неудач или начинал сбоить в середине поиска.
Оценку результата снимали через копию диалога, которая не влияла на дальнейшую траекторию. Модель должна была назвать полученный фрагмент полезным или бесполезным. Затем исследователи сравнивали поведение на одном и том же шаге: в одном случае перед агентом шла непрерывная серия бесполезных результатов, в другом ранее встречался полезный результат.
Такое сравнение отделяет реакцию на доказательства от реакции на часы. Если вероятность ответа растёт после непрерывной серии неудач, агент учитывает состояние источника. Если она зависит только от номера шага или приближения лимита, серия оценок фактически не управляет действием.
Проверка охватила семь агентов из семейств Qwen, Llama и Claude, а также Search-R1. Основные опыты прошли на HotpotQA, перенос результата проверили на задаче проверки фактов FEVER. Среда была контролируемой: агент искал по малой базе знаний с заранее известными полезными фрагментами и моментами сбоя источника.
Подсказки сдвигают дедлайн, а внешнее правило меняет поведение
Разрешение отвечать по памяти заставляло некоторые модели завершать работу раньше, но остановка не зависела от качества найденных материалов. Агент мог отказаться от поиска ещё до того, как источник успевал восстановиться. Режим рассуждения давал похожий эффект: момент ответа менялся, а связь между накопленными оценками и действием не появлялась.
Явно указанный лимит тоже не устранил проблему. Когда бюджет увеличивали с 8 до 16 действий, агенты переносили ответ к новому дедлайну и примерно удваивали число вызовов инструмента на постоянно сломанном источнике. Дополнительные обращения не повышали успешность.
Фраза с правилом остановки и цена каждого вызова помогали только части моделей. Даже счётчик бесполезных результатов, показанный прямо в запросе, не гарантировал, что агент применит собственную оценку. Промпт сообщал нужную политику, но оставлял модели возможность её проигнорировать.
Устойчивый результат появился, когда правило исполнял внешний управляющий контур. После заданной серии бесполезных результатов он запрещал новые обращения к поиску и оставлял только завершение ответа. На постоянно сломанном источнике успешность выросла у каждой проверенной модели, а момент остановки не сдвинулся при увеличении бюджета.
Это различие нельзя увидеть по одной итоговой метрике качества. Агент, который отвечает у дедлайна, иногда получает такой же результат, как агент с внешним правилом, но тратит больше вызовов и меняет поведение вместе с лимитом. Для продукта это означает менее предсказуемые задержки и расходы.
В планах стоит менять оркестрацию, а не выбирать другую модель
Работа не даёт оснований считать проблему особенностью одного семейства или небольшого размера модели. Она проявилась у открытых моделей, Claude и агента, обученного искать с подкреплением. Замена поставщика без изменения управляющей логики поэтому не гарантирует другого поведения.
В агенте стоит хранить состояние источника вне контекста модели: последнее суждение о результате, длину непрерывной серии неудач и оставшийся бюджет. Полезный результат сбрасывает счётчик. При достижении порога система сама переключает доступные действия на ответ, запасной источник или контролируемый отказ.
Порог из работы не следует переносить в продукт как универсальную константу: его настроили на отдельной выборке для конкретной среды. В реальной системе он зависит от стоимости вызова, вероятности восстановления источника и ущерба от ответа без подтверждения. Важен сам принцип: модель оценивает наблюдение, а программа применяет политику.
Если агент уже явно пишет оценку результата в рассуждении, управляющий контур может извлекать её без отдельного обращения к модели. Для производственной системы надёжнее запросить короткое структурированное поле и проверять его отдельно от основного ответа. Тогда правило остановки не зависит от свободной формулировки рассуждения.
При испытаниях нужно раздельно измерять точность оценки результата, действие после серии неудач, качество ответа и число вызовов. Бюджет следует менять между прогонами, а сбой источника — включать в разные моменты. Если остановка переезжает вместе с дедлайном, агент управляется лимитом, а не собственными доказательствами.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
