За последние два года «поиск» перестал означать ранжированный список ссылок и стал означать агентный конвейер. Классификация, переписывание, веерная рассылка, переранжирование и синтез. От пятидесяти до ста вызовов LLM на один поисковый запрос, почти все последовательные.
Это крайне невыгодное положение для авторегрессионной модели: переписывание длительностью 400 мс блокирует поиск, который блокирует переранжирование, которое блокирует первое слово, которое видит пользователь. Поэтому команды сокращают конвейер до тех пор, пока он не станет достаточно коротким, чтобы быть быстрым.
Индустрия разделилась на два лагеря: синхронный поиск, использующий легкие и дешевые модели, которые почти не «думают», и агенты глубокого исследования, которым требуется тридцать минут. Никто не выпускает продукт, находящийся посередине: конвейер, достаточно глубокий, чтобы быть умным, и достаточно быстрый, чтобы быть полезным.
Mercury 2 декодирует более 1000 токенов в секунду на стандартных графических процессорах NVIDIA. Этого достаточно, чтобы выполнить каждый шаг в рамках уже имеющегося у вас бюджета задержки.
Задержка — это бюджет качества
В большинстве продуктов задержка и качество — это разные настройки. Вы можете улучшить ответ, заставив пользователя подождать. В поиске это одна и та же настройка, потому что каждый шаг, улучшающий ответ, сам по себе является вызовом LLM, который увеличивает задержку:
- Переписывание запроса находит документы, которые пропускает буквальное совпадение.
Переписывание запроса находит документы, которые пропускает буквальное совпадение.
- Переранжирование сужает объединенный набор до фрагментов, из которых стоит синтезировать ответ.
Переранжирование сужает объединенный набор до фрагментов, из которых стоит синтезировать ответ.
- Суммирование фрагментов сохраняет контекст синтеза достаточно чистым для цитирования.
Суммирование фрагментов сохраняет контекст синтеза достаточно чистым для цитирования.
Каждый шаг — это вызов LLM. Каждый из них либо блокирует пользователя, либо генерирует выходные данные, которые читает пользователь.
Агенты, которые выполняют шесть переписываний вместо одного, переранжируют сто результатов вместо десяти и суммируют каждую найденную страницу, не просто ищут быстрее, они ищут лучше.
Почему диффузии не нужно работать по одному токену за раз
Авторегрессионные модели генерируют слева направо, по одному токену за проход. Каждый токен ждет всех предыдущих токенов. Эта сериализация является структурным узким местом, и именно поэтому ответом индустрии на задержку поиска стало «использование модели меньшего размера». Это единственный доступный рычаг, когда порядок декодирования фиксирован.
Диффузионные языковые модели не имеют фиксированного порядка декодирования. Mercury 2 генерирует данные параллельно, уточняя весь диапазон выходных данных за небольшое, ограниченное количество шагов, а не выдавая по одному токену за проход. Каждый шаг — это полноконтекстный прямой проход по всему диапазону. Модель видит развивающийся ответ целостно и сходится к окончательному результату за последовательные проходы. Обоснование переранжирования на 300 токенов и резюме фрагмента на 500 токенов возвращаются за долю времени. Поисковый конвейер генерирует их сотнями.
Самая быстрая модель на каждом шаге, измеренная
«Быстро» в поисковом конвейере — это не одно число. Важно то, сколько времени занимает каждый шаг, потому что каждый шаг блокирует следующий. Поэтому мы измерили задержку на каждом шаге непосредственно в WideSearch, бенчмарке исчерпывающих задач по сбору информации, требующих десятков «живых» запросов каждая. Тот же агентный инструментарий, те же 100 задач, тот же «живой» поиск, четыре модели, время каждого вызова LLM зафиксировано.
Воспроизводимость: бенчмарк WideSearch, 100 задач на английском языке, «живой» поиск Exa. Медианные значения задержки по 336–493 вызовам для каждой модели, каждый через публичный API своего провайдера. Инструментарий и тайминги каждого вызова доступны по адресу: github.com/apoorvumang/retrieval-vs-recall
Воспроизводимость: бенчмарк WideSearch, 100 задач на английском языке, «живой» поиск Exa. Медианные значения задержки по 336–493 вызовам для каждой модели, каждый через публичный API своего провайдера. Инструментарий и тайминги каждого вызова доступны по адресу:
Mercury 2 — самая быстрая модель на каждом этапе конвейера, почти в 2 раза быстрее Gemini 3.1 Flash Lite при планировании запросов, в 4,7 раза быстрее Claude Haiku 4.5, в 10 раз быстрее GPT-5 Mini. Этот разрыв на каждом шаге и формирует сквозные показатели в следующем разделе: конвейер настолько быстр, насколько быстра сумма его переходов.
Математика реального конвейера
Возьмем запрос к движку ответов средней сложности с бюджетом в 2 секунды до первого токена.
Обычный конвейер тратит этот бюджет на одно переписывание, один проход поиска, отсутствие переранжирования LLM и этап синтеза, который начинает потоковую передачу с опозданием. Большая часть из 2 секунд — это время декодирования, а потолок качества определяется тем, что удалось вернуть поисковику.
Тот же бюджет на Mercury 2 позволяет выполнить четыре параллельных переписывания, веерный поиск по всем ним, переранжирование LLM по объединенному набору кандидатов, суммирование фрагментов для каждого документа и этап синтеза, который начинает потоковую передачу с запасом времени. Тот же конверт задержки. Структурно лучший ответ, потому что конвейер выполнил работу.
При цене $0,25 за миллион входных токенов и $0,75 за миллион выходных, этот более глубокий конвейер работает примерно в 2 раза дешевле, чем тот же конвейер на передовых моделях, оптимизированных по скорости.
Качество на полной скорости
Скорость важна только в том случае, если ответы остаются качественными. Поэтому мы запустили уровень генерации с учетом экономической эффективности на двух бенчмарках обоснованного поиска: FRAMES (многошаговый поиск и синтез, 2–15 статей Википедии на вопрос) и DeepSearchQA (агентный поиск с открытым ответом, оцениваемый по полноте набора ответов).
n=100 на бенчмарк, идентичный набор вопросов для каждой модели, все при среднем уровне усилий на рассуждение. Агентный цикл вызова инструментов через Exa; бюджет 25 вызовов на FRAMES, 30 на DSQA. Оценка проводилась с использованием официального промпта каждой статьи и обязательного судьи — GPT-5.4 для FRAMES, Gemini-2.5-flash для DSQA. Стоимость включает поиск Exa по прейскурантным ценам и оплату входных данных по полной цене без скидки на кэш промптов. *Claude Haiku 4.5 маршрутизировался через OpenRouter (прямой ключ исчерпан); его задержка включает прокси-переход и, вероятно, завышена на пару секунд.
n=100 на бенчмарк, идентичный набор вопросов для каждой модели, все при среднем уровне усилий на рассуждение. Агентный цикл вызова инструментов через Exa; бюджет 25 вызовов на FRAMES, 30 на DSQA. Оценка проводилась с использованием официального промпта каждой статьи и обязательного судьи — GPT-5.4 для FRAMES, Gemini-2.5-flash для DSQA. Стоимость включает поиск Exa по прейскурантным ценам и оплату входных данных по полной цене без скидки на кэш промптов. *Claude Haiku 4.5 маршрутизировался через OpenRouter (прямой ключ исчерпан); его задержка включает прокси-переход и, вероятно, завышена на пару секунд.
В FRAMES четыре модели находятся в пределах трех пунктов друг от друга — 0,78, 0,78, 0,78, 0,81. При n=100 стандартная ошибка составляет от четырех до пяти пунктов, поэтому этот разброс — шум. В многошаговых обоснованных вопросах и ответах этот уровень равен, и номинально лучший результат GPT-5 Mini не является реальным преимуществом.
DeepSearchQA разделяет их, и не в пользу Mercury 2. GPT-5 Mini набирает 0,44 против 0,34 у Mercury 2 — разрыв в десять пунктов, шире, чем разброс между остальными тремя, хотя все еще в пределах двух стандартных ошибок при данном размере выборки. DSQA вознаграждает широту: поиск каждого элемента, соответствующего ограничению, а не рассуждение по цепочке. Модель, которая планирует решительно и читает широко, справляется там лучше, и GPT-5 Mini делает именно это.
Что не меняется ни в одном из бенчмарков, так это стоимость правильного ответа и время ожидания. Mercury 2 завершает запрос FRAMES за 10,8 секунды, по сравнению с 19,8 для Gemini 3.5 Flash Lite, 21,0 для Claude Haiku 4.5 и 38,8 для GPT-5 Mini. А в пересчете на правильный ответ (сумма, которая попадает в ваш счет) Mercury 2 показывает самый низкий результат из четырех в обоих бенчмарках: $0,047 в FRAMES против $0,072, $0,097 и $0,133; $0,432 в DeepSearchQA против $0,457, $0,676 и $0,938.
Таким образом, GPT-5 Mini обеспечивает прирост точности в DeepSearchQA на десять пунктов при задержке, которая в 3,6 раза выше, и при этом все равно стоит немного дороже за правильный ответ, чем Mercury 2. В конвейере, который запускает модель сто раз на один запрос, такой компромисс не оправдывает себя.
Одно честное замечание по поводу DeepSearchQA: он стоит в три-семь раз дороже, чем FRAMES для каждой модели, потому что широта охвата означает большее количество итераций, а каждая дополнительная итерация требует повторной отправки растущего транскрипта. Стоимость в агентском конвейере определяется количеством итераций и объемом входных данных, а не длиной вывода или ценой за единицу. Это еще один способ сказать, что количество шагов, которые вы можете себе позволить, определяет стоимость работы вашего конвейера.
Как Mercury 2 проиграл в WideSearch
За каждой цифрой выше, включая наши, скрывается проблема. Мы обнаружили ее, потому что Mercury 2 проиграл.
Mercury 2 показал результат хуже, чем Gemini 3.1 Flash Lite в WideSearch, бенчмарке для агентского поиска. Клиент спросил почему. Мы углубились в детали и в итоге запустили бенчмарк с отключенным поиском (retrieval). Если бенчмарк измеряет поиск, то отключение поиска должно быть критичным.
Каждая модель выигрывает от использования поиска, кроме Gemini, которая показывает результат немного хуже с поиском (−0,02), чем без него. Она не ищет; она цитирует. Задачи WideSearch построены на фактах, которые старше даты отсечки каждой модели (например, рейтинги университетов, характеристики продуктов, цены на жилье 2022 года), поэтому модель может игнорировать каждую страницу, которую она извлекает, и отвечать, опираясь на свои веса. Никто не жульничает; это то, что поощряет система оценки. Оценка выглядит как поиск. На самом деле это воспроизведение по памяти (recall).
Для поискового продукта это различие является ключевым. Модель, которая отвечает по памяти, будет уверенно противоречить вашему индексу, вашему каталогу, вашим свежепросканированным страницам, и при этом отлично выглядеть в бенчмарке.
Одна задача делает это наглядным. ws_en_034 запрашивает ежемесячные цены на жилье в Великобритании и предписывает модели цитировать каждую статистику с правительственных веб-сайтов — поиск по заданию. С включенным поиском агент не смог проверить цифры в своих источниках и вернул пустую таблицу: 0,03. В режиме «закрытой книги» он процитировал правдоподобные цифры по памяти: 0,86. Достоверность проигрывает беглости в тридцать раз.
Поэтому мы перестроили задачи, используя события, произошедшие после даты отсечки обучения каждой модели (например, групповой этап Чемпионата мира 2026 года, Открытый чемпионат Франции, Канны, Евровидение). Тот же формат, тот же официальный оценщик, ничего, что можно запомнить. Оценки в режиме «закрытой книги» падают до нуля для каждой модели, подтверждая, что задачи нельзя воспроизвести по памяти. С включенным поиском Gemini набирает 0,929, а Mercury 2 — 0,923.
Это ничья, и мы сообщаем об этом как о таковой. На данных, где оценка основана исключительно на поиске и синтезе, диффузионная модель, работающая в несколько раз быстрее на каждом шаге, выполняет работу того же качества, что и передовая авторегрессионная модель.
SealQA, устойчивый к утечкам бенчмарк, обновляемый ежемесячно, показывает ту же закономерность с другой стороны: преимущество Gemini в режиме «закрытой книги» полностью держится на вопросах до 2024 года, исчезает по мере того, как факты становятся свежее, и переходит к Mercury на вопросах после даты отсечки 2026 года. Настройка везде одинакова — единственная переменная заключается в том, можно ли было запомнить ответ.
Прежде чем оценивать модель для поиска, выполните три проверки:
- отключите поиск (если оценка сохраняется, вы оцениваете воспроизведение по памяти)
отключите поиск (если оценка сохраняется, вы оцениваете воспроизведение по памяти)
- включите вопросы после даты отсечки, которые ни одна модель не могла запомнить
включите вопросы после даты отсечки, которые ни одна модель не могла запомнить
- подтвердите, что правильные ответы можно найти с помощью поиска, а не просто являются истинными.
подтвердите, что правильные ответы можно найти с помощью поиска, а не просто являются истинными.
Все вышеперечисленное воспроизводимо. Используйте свои ключи и запустите это на любой модели, включая нашу: github.com/apoorvumang/retrieval-vs-recall
Что дальше
Поиск — это самый очевидный случай для параллельной генерации, потому что это рабочая нагрузка, которая запускает LLM наибольшее количество раз на единицу терпения пользователя. Та же картина проявляется везде, где конвейер многократно запускает модель. Агентские исследования — очевидный следующий шаг. Сокращение задержки на каждом шаге в 5–10 раз превращает ночную исследовательскую работу в то, что вы завершаете за разумное время ожидания.
Попробуйте Mercury 2. API доступен по адресу
platform.inceptionlabs.ai
Тестируете производственный поисковый конвейер? Мы предоставим более высокую пропускную способность, чтобы вы могли измерить реальную задержку на вашем собственном наборе запросов, и поможем вам провести абляционное исследование с отключенным поиском на вашем собственном наборе оценок.
Свяжитесь с нашими инженерами.
