Когда OpenAI запустила Deep Research, а Google ответила Gemini Deep Research, казалось, что поисковые агенты наконец-то научились самостоятельно копаться в интернете, синтезировать факты из десятков источников и выдавать ответы, которые человек собирал бы часами. Бенчмарки вроде BrowseComp подтверждали этот прогресс: лучшие модели набирали 70–80 баллов, и разрыв между поколениями сокращался. Но недавнее исследование из Harbin Institute of Technology и Xiaohongshu ставит под сомнение саму методологию этих тестов. Авторы выявили феномен, который они назвали Intrinsic Knowledge Dependence (IKD) — встроенная зависимость от знаний. Оказалось, что агенты отвечают на почти половину вопросов безо всякого поиска, генерируют поисковые запросы из собственных гипотез, а не из найденных фактов, и при удалении подтверждающих документов показывают результаты хуже, чем если бы поиска не было вообще. Чтобы это доказать, исследователи собрали новый бенчмарк LiveBrowseComp — 335 вопросов, основанных на событиях последних 90 дней, которые агент физически не мог запомнить. Результаты оказались суровы: точность закрытого ответа упала ниже 2%, а поисковые баллы рухнули на 25–40 пунктов относительно статических тестов. Давайте разберём, почему текущие бенчмарки обманывают нас и что это значит для разработчиков, бизнеса и пользователей.

Что такое Intrinsic Knowledge Dependence

Intrinsic Knowledge Dependence, или IKD, — это склонность LLM-агента решать задачи поиска, опираясь не на найденные в интернете факты, а на знания, зашитые в параметры модели во время обучения. Это звучит очевидно — любая нейросеть использует то, что «знает». Проблема в том, что когда агенту дают доступ к поиску, он продолжает действовать по той же схеме: сначала генерирует гипотезу из памяти, потом ищет в сети подтверждение. Поиск превращается не в инструмент открытия, а в интерфейс верификации. Авторы LiveBrowseComp провели три диагностики, чтобы измерить масштаб явления.

Первая диагностика — закрытый ответ без инструментов. Исследователи отключили у 24 конфигураций моделей всё: поиск, браузер, песочницу. Результат оказался шокирующим. Средняя точность pass@4 по четырём бенчмаркам — BrowseComp, BrowseComp-ZH, HLE и GAIA — составила 38,9%. Kimi K2.6 безо всякого поиска набрал 62,0 на BrowseComp-ZH. MiniMax M2.5 — 44,5 на BrowseComp. Seed 2.0 — 50,2 на HLE. Это означает, что почти половина «поисковых» успехов этих агентов объясняется не умением искать, а объёмом параметрической памяти.

Вторая диагностика — блокировка подтверждающих документов. Исследователи использовали BrowseComp-Plus, где для каждого вопроса известны золотые документы с ответом. Они удалили эти документы из поискового индекса, оставив только нерелевантные и hard-negative. Логично было ожидать, что агенты будут искать дальше, находить альтернативные источники и показывать результат лучше, чем без поиска. На деле вышло наоборот. Средняя точность упала с 26,1 в закрытом режиме до 6,2 при заблокированных документах. MiniMax M2.5 рухнул с 44,5 до 8,0. Kimi K2.6 — с 25,5 до 2,3. Для всех семи протестированных моделей поиск без подтверждающих документов оказался вреднее, чем отсутствие поиска вообще. Это говорит о том, что поисковый цикл не помогает агенту адаптироваться — он лишь отвлекает от правильного ответа, который модель уже «знала».

Третья диагностика — анализ траекторий. Авторы проследили происхождение каждого поискового запроса. Если ключевая информация для запроса впервые появилась в рассуждениях самой модели — это model-originated query. Если в найденном документе — retrieval-originated query. Для всех моделей более половины запросов оказались model-originated, и эта доля росла по мере продвижения по задаче, превышая 60% в поздних раундах. Агенты не развивали линию расследования на основе найденных фактов — они порождали новые гипотезы из головы и искали подтверждение. При этом даже когда релевантный документ попадал в выдачу, модели использовали его менее чем в трети случаев: от 24,7% у GLM-5.1 до 32,2% у DeepSeek v3.2. Поиск работал, но агенты не умели им пользоваться.

Как устроен LiveBrowseComp

Чтобы нейтрализовать IKD, исследователи построили бенчмарк, который ставит агентов за пределы их знаний по определению. LiveBrowseComp содержит 335 вопросов, каждый из которых завязан на факты, опубликованные в течение 90 дней до создания бенчмарка. Этого срока достаточно, чтобы факты гарантированно не попали в обучающую выборку ни одной из существующих моделей. При этом вопросы строятся не на громких мировых событиях — их модели могут подхватить через пост-тренинговые обновления — а на long-tail фактах из шести структурированных источников: GDELT для новостей, TMDB для кино, RAWG для игр, CVE для уязвимостей, SportsDB для спортивных событий и USGS для землетрясений.

Конструкция вопроса проходит пять стадий. Сначала события фильтруются по времени — отбрасывается всё старше 90 дней. Затем по long-tail метрикам — популярность, охват аудитории, объём освещения в СМИ. Остаются только события выше порога по каждому источнику. Третий фильтр — стабильность ответа. Исключаются вопросы, чьи ответы могут измениться за время жизни бенчмарка: накопительная касса, текущие турнирные таблицы, чарты. Затем профессиональные аннотаторы с высшим образованием и опытом в разметке данных формулируют вопросы, требующие многошагового поиска и синтеза. Каждый вопрос проходит независимую верификацию: три проверяющих подтверждают единственность ответа, три других пытаются решить задачу за 30 минут — если кто-то справляется быстрее, вопрос отбраковывается как слишком лёгкий. Четвёртый верификатор перепроверяет результаты первых троих.

Распределение по категориям отражает доступность данных после фильтрации: кино, развлечения, наука и технологии, спорт, общество и культура. Человеческие аннотаторы, не участвовавшие в создании вопросов, решили 30% задач BrowseComp и 31% задач LiveBrowseComp за сопоставимое время. Это подтверждает, что сложность поиска у бенчмарков одинаковая — разница только в том, можно ли ответить по памяти.

Что показали эксперименты

В LiveBrowseComp протестировали 11 моделей: семь open-source от 230B до 1,6T параметров и четыре закрытых API. Все использовали единый поисковый скелетон с доступом к веб-поиску через serper.dev, извлечению страниц через Jina и песочнице Python. Температура 0,7, top_p 0,9 — стандартные настройки для исследовательских задач.

Результаты оказались разрушительными для иллюзий. На статическом BrowseComp лидер Seed 2.0 набирал 77,3, а аутсайдер среди open-source — DeepSeek v3.2 с 51,4. На LiveBrowseComp Seed 2.0 упал до 41,5, а DeepSeek v3.2 — вырос относительно своей позиции до 37,6. GPT 5.4 лидировал на LiveBrowseComp с 43,2, но это всё равно на 28,9 пункта ниже его результата на BrowseComp. Самое интересное — изменение рейтингов. GLM 5.1 возглавлял BrowseComp с 68,0, но на LiveBrowseComp рухнул до 33,9. DeepSeek v3.2, который был почти на дне статического теста, на LiveBrowseComp обогнал GLM 5.0, MiniMax M2.5 и Kimi K2.5. Разброс среди open-source моделей сжался с 16,6 пунктов на BrowseComp до 10,3 на LiveBrowseComp. Это означает, что когда память убирается из уравнения, разница между моделями становится меньше — и она отражает не объём знаний, а качество поисковой стратегии.

Закрытый ответ без инструментов на LiveBrowseComp показал менее 2% для всех моделей. Против 20–44% на BrowseComp-Plus. Параметрическое знание действительно подавлено. Корреляция Спирмена между рейтингами BrowseComp и LiveBrowseComp упала с 0,87 до 0,74, а корреляция Пирсона — с 0,79 до 0,53. Пирсон чувствителен к абсолютным значениям, и его падение говорит о том, что модели, которые больше всего выигрывали от IKD на статических тестах, теряют это преимущество на живых вопросах.

Анализ распределения поисковых ходов показал ещё одну интересную картину. На BrowseComp большая часть вопросов решалась за минимальное число ходов — агент быстро находил подтверждение гипотезы и останавливался. На LiveBrowseComp этот пик коротких траекторий исчез, и распределение сдвинулось к бо́льшему числу ходов. Когда агент не может опереться на память, каждый запрос должен реально продвигать расследование, а не просто подтверждать догадку. Траектории становятся длиннее и более исследовательскими — что и должно происходить при настоящем поиске.

Почему это важно для разработчиков и бизнеса

Для разработчиков поисковых агентов вывод LiveBrowseComp прямолинеен: текущие бенчмарки не измеряют то, что мы считаем важным. Если ваша модель набирает 75 баллов на BrowseComp, это может означать, что она хорошо помнит факты, а не что она хорошо ищет. При внедрении в продукт, где пользователи задают вопросы о свежих событиях — рынках, уязвимостях, релизах — такой агент разочарует. Нужно тестировать на динамических, временно-чувствительных бенчмарках, а не только на статических пулах вопросов.

Для бизнеса, который покупает или внедряет поисковых агентов, это означает, что маркетинговые цифры про «глубокое исследование» стоит воспринимать с осторожностью. Агент, который блестяще справляется с вопросами про события 2023 года, может бессильно тупить перед вопросом про вчерашнюю уязвимость. При выборе решения стоит проверять не только баллы на статических тестах, но и способность агента работать с информацией за пределами своей обучающей выборки. Это особенно критично для финансовых аналитиков, security-команд, журналистов и исследователей — тех, кто платит за поиск именно потому, что не знает ответа заранее.

Для сообщества оценки ИИ LiveBrowseComp ставит вопрос о необходимости стандартизации динамических бенчмарков. Статические тесты имеют огромное преимущество — они воспроизводимы, их можно запускать тысячи раз, сравнивать модели по одной шкале. Но они уязвимы для загрязнения данных и IKD. Динамические бенчмарки сложнее в поддержке, требуют постоянного пополнения, но они измеряют то, что действительно важно: способность агента находить неизвестное, а не верифицировать известное. Вероятно, будущее оценки поисковых агентов — в гибридном подходе: статические тесты для регрессии, динамические — для валидации реальных способностей.

Часто задаваемые вопросы

Может ли модель просто запомнить LiveBrowseComp?

Нет. Вопросы зависят от фактов последних 90 дней, а сам бенчмарк публикуется сразу после создания. К моменту обучения следующей версии модели события устареют, и бенчмарк обновится новыми вопросами. Это принципиальное отличие от статических тестов.

Почему агенты не падают до нуля на LiveBrowseComp?

Потому что они всё ещё умеют искать — просто не так хорошо, как казалось. Даже без памяти LLM обладают базовыми навыками многошагового рассуждения, формулирования запросов и синтеза информации. Падение с 77 до 41 не означает полную непригодность — оно означает, что реальная способность к поиску скромнее, чем показывали статические тесты.

Что делать с существующими агентами?

Два пути. Первый — улучшать поисковую стратегию: обучать агентов порождать запросы на основе найденных фактов, а не внутренних гипотез, и учитывать отсутствие подтверждения как сигнал к смене направления, а не к упорству. Второй — менять сигналы обучения: вместо награды за правильный ответ вне зависимости от пути награждать за траектории, где поиск действительно ведёт к открытию.

Итог

LiveBrowseComp — это не просто новый бенчмарк. Это диагностика того, как мы оцениваем поисковых агентов, и напоминание о том, что высокий балл на статическом тесте не гарантирует способность искать в реальном мире. Агенты, которые «исследуют» интернет, на деле часто просто верифицируют собственные догадки. Когда эта возможность убирается, картина меняется: рейтинги перестраиваются, разброс сжимается, и становится видно, кто действительно умеет искать, а кто — только помнит. Для разработчиков это повод пересмотреть тренировочные сигналы. Для бизнеса — повод проверять агентов на свежих задачах. Для сообщества — повод признать, что оценка ИИ-агентов должна быть такой же динамичной, как и среда, в которой они работают.