За последние два года «поиск» перестал означать ранжированный список ссылок и стал означать агентный конвейер. Классификация, переписывание, веерная рассылка, переранжирование и синтез. От пятидесяти до ста вызовов 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
Тестируете производственный поисковый конвейер? Мы предоставим более высокую пропускную способность, чтобы вы могли измерить реальную задержку на своем наборе запросов, и поможем вам провести абляционное исследование с отключенным поиском на вашем собственном наборе оценок.
Свяжитесь с нашими инженерами.
