DiscoBench: почему AI-агенты ошибаются в поиске
DiscoBench проверяет, умеют ли поисковые AI-агенты замечать неоднозначность и задавать уточняющие вопросы. Главный вывод: искать больше не значит отвечать лучше.
По состоянию на 5 июля 2026 года DiscoBench — свежий бенчмарк от команды Tencent Hunyuan и Shenzhen International Graduate School, Tsinghua University. Фокус здесь смещён с самого search call на момент решения: продолжать искать или спросить пользователя, потому что запрос стал неоднозначным.
Вывод получился практичный. Доступ к вебу сам по себе проблему не решает. Агент выбирает правдоподобную, но неверную ветку поиска, когда в многошаговой задаче появляется неоднозначность: сущность, версия, критерий сравнения или фактическая ошибка в исходном вопросе. Дальше каждый новый search call только аккуратно развивает неправильную гипотезу.
Что показал DiscoBench?
DiscoBench показал: поисковые AI-агенты ошибаются на неоднозначных запросах, когда не превращают неопределённость в вопрос к пользователю. Лучший результат в основной нейтральной настройке у авторов — 43,1% end-to-end accuracy. То есть даже сильные системы в этом тесте чаще не доходят до правильного финального ответа, чем доходят.
Это важный сдвиг для всей темы агентного поиска. Рынок уже обсуждает, кто построит лучший поиск для AI-агентов, но DiscoBench напоминает: качество складывается из индекса, ранжирования, источников и отдельного навыка задавать вопросы. Агент должен понимать, когда найденных фактов достаточно, а когда надо остановиться и спросить человека.
Как устроен бенчмарк
Авторы описывают DiscoBench как benchmark for clarification-aware deep search. В наборе 211 задач, 463 точки неоднозначности, 11 предметных доменов и четыре типа неоднозначности: entity, version, criteria и factual inaccuracy. Бенчмарк в основном построен на китайском языке, чтобы отражать реальные паттерны поиска в китайскоязычной веб-среде.
Каждая задача разбита на checkpoints. На каждом шаге агент выбирает одно из трёх действий: продолжить поиск, задать уточняющий вопрос или дать ответ. Если checkpoint неоднозначный, правильное поведение — спросить пользователя о недостающей детали. Для этого в DiscoBench есть LLM-симулятор пользователя, который выдаёт заранее проверенную подсказку.
Цифры: сильные модели всё ещё ниже 50%
Ниже — данные из arXiv-версии 2606.27669v2. Названия моделей приведены так, как они указаны в таблицах авторов; это результаты конкретного исследовательского прогона, а не рейтинг коммерческих продуктов.
| Что проверяли | Результат | Источник |
|---|---|---|
| Размер DiscoBench | 211 задач, 463 ambiguity instances, 11 доменов и 4 типа неоднозначности. | arXiv v2, abstract и раздел 4.3 |
| Лучшие neutral-результаты | Doubao-Seed-2.0-Pro — 43,1% accuracy; Gemini-3.1-Pro-Preview — 40,8%; Claude-Opus-4.7 — 39,8%. | arXiv v2, Table 2 |
| Guided prompt | В среднем по 10 моделям accuracy выросла с 28,6% до 33,7%, detection F1 — с 45,3% до 64,9%. | arXiv v2, раздел 5.2 |
| Поведение на ambiguous checkpoints | SearchThenAsk даёт 93,4% pass rate в среднем; DirectGuess — 56,5%; SearchHeavyGuess — 51,9%. | arXiv v2, Table 3 |
| Роль внешнего поиска | Без search tool Doubao-Seed-2.0-Pro падает с 43,1% до 2,4%, Gemini-3.1-Pro — с 40,8% до 19,9%. | arXiv v2, Table 4 |
Самая показательная строка здесь не про победителя. Guided prompt заметно улучшает распознавание неоднозначности, но финальная точность растёт скромнее. Агент может понять, что где-то есть проблема, и всё равно не задать правильный вопрос или не использовать ответ пользователя так, чтобы вернуться на верную траекторию.
Почему больше поисковых запросов не помогает
В DiscoBench есть неприятный профиль поведения: SearchHeavyGuess. Агент много ищет, видит несколько кандидатов, но в итоге всё равно угадывает вместо того, чтобы спросить. По средней pass rate такой режим хуже прямого угадывания: 51,9% против 56,5%.
Это хорошо ложится на более широкий риск, который мы уже разбирали в статье про tool-use tax у LLM-агентов. Tool call сам по себе не делает систему умнее. Иногда он просто создаёт ощущение работы: агент строит всё более длинную цепочку действий, но ключевая неопределённость так и остаётся нерешённой.
Правильный паттерн в DiscoBench — SearchThenAsk. Сначала агент ищет достаточно, чтобы увидеть развилку, затем формулирует уточняющий вопрос. Не «спросить обо всём на всякий случай», а спросить о той детали, без которой дальше нельзя выбрать верную ветку.
Где агентам сложнее замечать неоднозначность
Авторы пишут, что factual inaccuracy обычно легче распознать: поиск быстро даёт конфликт с фактами. С entity и criteria сложнее. Несколько сущностей могут одинаково хорошо подходить под описание, а критерий «лучший», «первый» или «самый влиятельный» может зависеть от того, что именно считает пользователь.
Для продукта это превращается в отдельную задачу проектирования. Агенту мало иметь кнопку «поиск». Нужна политика вопросов: когда спросить, что именно спросить, как не превратить уточнения в допрос и как учесть ответ пользователя в следующих шагах, вместо того чтобы складывать его ещё одним фрагментом в длинный контекст.
Последствия для агентного поиска
Если поиск становится средой действий для агента, финального ответа уже недостаточно для оценки качества. DiscoBench предлагает смотреть на промежуточные решения: увидел ли агент ambiguous checkpoint, спросил ли в правильном месте, помог ли ответ пользователя продвинуться дальше, сколько токенов и tool calls ушло на попытку.
Для команд, которые делают deep research, AI search или корпоративных research-агентов, из этого следуют четыре требования.
- В интерфейсе должен быть нормальный сценарий уточняющего вопроса рядом с молчаливым режимом «найди ответ сам».
- Planner должен отличать недостаток фактов от развилки интерпретаций. Это разные ошибки.
- Метрики должны учитывать путь: где агент сбился, какие вопросы задавал, помогли ли они закрыть checkpoint.
- Стоимость поиска надо считать вместе с качеством. Лишние запросы увеличивают счёт за API и могут ухудшать результат.
DiscoBench полезен и исследователям, и продуктовым командам. Он даёт тест на зрелость агентного поиска: умеет ли система сказать «мне нужно уточнение», пока ещё не поздно.
Ограничения исследования
DiscoBench не стоит читать как финальный приговор всем поисковым агентам. Бенчмарк в основном китайскоязычный, user simulator построен на LLM, а задачи ограничены объективно проверяемыми вопросами. Субъективные предпочтения пользователя, шумная человеческая коммуникация и корпоративные knowledge base-сценарии остаются отдельными темами.
Есть и воспроизводимость. Авторы сами отмечают, что search backend ведёт себя как чёрный ящик: выдача, сниппеты и ранжирование могут меняться со временем. Поэтому важнее не спорить о десятых долях процента в таблице, а смотреть на устойчивый паттерн: неоднозначность ломает многошаговый поиск, если агент не умеет вовремя спросить.
FAQ
Что такое DiscoBench?
DiscoBench — бенчмарк для проверки, умеют ли поисковые AI-агенты распознавать неоднозначные запросы, задавать уточняющие вопросы и возвращаться на правильную траекторию многошагового поиска.
Почему больше поисковых запросов не помогает?
Потому что лишний поиск не снимает неоднозначность. Если агент уже видит несколько правдоподобных кандидатов, но не спрашивает пользователя о нужном критерии, он продолжает развивать случайно выбранную ветку.
Чем DiscoBench отличается от обычных LLM-бенчмарков?
Обычные benchmark-задачи часто оценивают финальный ответ и предполагают, что запрос понятен. DiscoBench смотрит на процесс: на каком checkpoint появилась неоднозначность, спросил ли агент о ней и помог ли ответ пользователя пройти дальше.
Источники и дата проверки
Факты проверены 5 июля 2026 года. Для быстро меняющихся данных использованы первоисточники и новостной контекст; модельные результаты приведены только из arXiv-таблиц DiscoBench.
- Yiling Tao et al.: When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search, arXiv:2606.27669v2, 1 июля 2026 года.
- arXiv abstract page: DiscoBench for Clarification-Aware Deep Search, первая версия 26 июня 2026 года.
- The Decoder: AI search agents don't fail at searching, they fail at asking the right questions when queries get ambiguous, 5 июля 2026 года.
