В эпоху больших языковых моделей (LLM) веб-поиск перестал быть опциональной функцией — он стал базовым требованием. Большинство современных запросов к ИИ требуют актуальных данных, чтобы преодолеть ограничения «отсечки знаний» (knowledge cutoffs), заложенные в момент обучения модели. Однако экосистема развивается стремительно: провайдеры поисковых систем и лаборатории, создающие модели, постоянно совершенствуют свои инструменты, делая поиск эффективнее и дешевле. Перед разработчиками и архитекторами AI-агентов встает сложный выбор: использовать ли встроенный нативный поиск от провайдера модели (например, OpenAI или Anthropic) или подключать сторонние движки, такие как Exa, Parallel или Perplexity? Достаточно ли одного запроса к поисковику, или агенту нужно разрешить несколько итераций поиска? И главное — стоит ли платить больше за качество, которое покупается через увеличение количества поисковых запросов?
Ответ на эти вопросы не может быть универсальным, так как он сильно зависит от конкретного сценария использования. Чтобы помочь вам принять взвешенное решение, мы провели масштабное бэнчмаркирование, протестировав все возможные комбинации моделей, поисковых движков и стратегий поиска. В этой статье мы подробно разберем полученные данные, чтобы вы могли оптимизировать свои затраты и повысить качество ответов ваших AI-агентов.
01Четыре ключевых решения при настройке веб-поиска
Когда вы настраиваете запрос с веб-поиском, вы принимаете четыре фундаментальных архитектурных решения. Понимание того, как каждый из этих параметров влияет на результат, критически важно для построения эффективного агента.
1. Модель (Model)
Именно модель отвечает за две ключевые задачи: она формирует точный поисковый запрос, который отправляется в поисковую систему, и затем анализирует полученные результаты. Способность модели правильно интерпретировать фрагменты поисковой выдачи и синтезировать из них ответ напрямую определяет итоговое качество. Более «умные» модели лучше понимают контекст и могут задавать более релевантные уточняющие вопросы.
2. Движок поиска (Engine)
Здесь у вас есть выбор: использовать специфический сторонний движок или полагаться на встроенные (нативные) решения от лабораторий. На платформе OpenRouter, например, доступны такие мощные инструменты, как Exa, Parallel и Perplexity, а также нативные движки от OpenAI, Anthropic и Google. Каждый из них имеет свои особенности индексации и ранжирования результатов.
3. Метод поиска (Search method)
Существует два основных подхода. Первый — предварительный поиск: вы выполняете поиск до того, как модель начнет генерировать ответ, и передаете результаты в контекст. Это простой и быстрый метод. Второй подход — использование инструмента поиска (tool-use): модель оснащается специальным инструментом веб-поиска и вызывает его по своему усмотрению, когда понимает, что информации недостаточно. Этот метод дает агенту автономность, позволяя ему самому решать, когда и что искать.
4. Бюджет поиска (Search budget)
Если вы выбрали метод с использованием инструмента, вы можете задать модели «бюджет» — максимальное количество поисковых запросов, которые она может сделать. Это позволяет модели корректировать запрос, если первые результаты неудовлетворительны, или проводить последовательные уточняющие поиски. В наших тестах мы использовали бюджеты в 1, 5 и 25 ходов (turns). Именно этот параметр, как мы выяснили, оказывает наибольшее влияние на качество.
02Бюджет поиска важнее любого другого фактора
Наши данные показывают, что увеличение бюджета поиска (глубины) с 1 хода до большего числа улучшает качество ответа сильнее, чем любое другое единичное изменение в конфигурации. Давайте рассмотрим конкретные цифры из нашего первоначального запуска бенчмарка BrowseComp с использованием движка Perplexity при разных бюджетах:
Как видно из таблицы, для модели Claude Opus 5 (high) увеличение количества ходов с 1 до 25 подняло качество с 35.8% до 89.0%. При этом стоимость вопроса выросла с $0.14 до $0.99. Для GPT-5.6 Sol (high) качество выросло с 46.3% до 82.4%, а стоимость — с $0.20 до $0.50. Для более бюджетной GPT-5.6 Luna (extra-high) рост составил с 33.7% до 74.0% при стоимости от $0.02 до $0.10.
Эта закономерность сохраняется для всех провайдеров, которых мы тестировали. Увеличение глубины поиска — это самый дешевый способ повысить качество. Переход от 1 хода к 25 примерно удваивает или утраивает балл, при этом стоимость на один вопрос возрастает всего в 2.5–7 раз. Это делает многошаговый поиск крайне выгодным вложением.
Однако есть распространенное заблуждение, что увеличение глубины всегда замедляет ответ. Наши данные опровергают это. Например, модель Luna при 1 ходе отвечала 140 секунд, а при 25 ходах — всего 111 секунд. Из 35 конфигураций, которые мы запустили как с 1, так и с 5 ходами, более трети оказались медленнее при меньшем бюджете. Это произошло потому, что модели OpenAI тратили дополнительное время на «рассуждения» (reasoning) в условиях ограниченного бюджета, пытаясь угадать ответ без достаточных данных. При наличии бюджета они быстрее переходили к поиску.
С другой стороны, увеличение глубины может быть невыгодным для легких задач. Например, в бенчмарке HLE (expert exam questions) модель GPT-5.6 Sol с Perplexity показывала схожие результаты при 1 ходе и 25 ходах, но при этом тратила в три раза больше денег. Если ваши запросы просты, имеет смысл держать бюджет ограниченным.
03Сценарий наихудших затрат: как ошибка модели сжирает бюджет
Существует ситуация, при которой расширенный бюджет становится вредным: когда модель не может найти ответ. Мы обнаружили, что модели часто исчерпывают весь выделенный бюджет, пытаясь найти ответ, который на самом деле невозможно найти или который требует совершенно другого подхода. В итоге они тратят деньги впустую, даже если в конечном счете дают неверный ответ.
Таблица выше показывает среднее количество поисковых запросов, сделанных моделью, когда ответ был верным, и когда он был неверным, при бюджете в 25 ходов. Обратите внимание на разрыв: в BrowseComp модель делает в среднем 10.3 запроса, если ответ верен, и 19.7, если неверен. В WideSearch разрыв еще больше: 17.6 против 23.4. Самое глубокое исследование, которое мы зафиксировали, составило 81 поиск в таблице WideSearch, и даже оно было оценено как неверное.
Это означает, что если ваш рабочий процесс имеет высокий процент неудач (high failure rate), сокращение глубины поиска — это эффективный путь к снижению затрат. Модель просто не найдет ответ, и чем меньше у нее попыток, тем меньше денег она сожжет в попытках «достучаться» до истины.
04Движок важен, но модель важнее
После того как бюджет установлен, следующим по значимости фактором становится выбор модели. Давайте посмотрим на результаты BrowseComp при 25 ходах, сравнивая передовые модели (frontier) и бюджетные модели across разных поисковых движков:
Perplexity: Claude Opus 5 (89.0%, $0.99), GPT-5.6 Sol (82.4%, $0.50), DeepSeek V4 Flash (77.0%, $0.08), GPT-5.6 Luna (74.0%, $0.10).
Exa: Claude Opus 5 (82.2%, $1.29), GPT-5.6 Sol (77.8%, $0.54), DeepSeek V4 Flash (67.4%, $0.12), GPT-5.6 Luna (68.4%, $0.14).
Parallel: Claude Opus 5 (88.8%, $2.42), GPT-5.6 Sol (76.6%, $1.26), DeepSeek V4 Flash (64.6%, $0.10), GPT-5.6 Luna (58.0%, $0.11).
Изменение движка при фиксированной модели меняло результат в среднем на 10 пунктов. В то же время разница между передовыми и бюджетными моделями составляла в среднем 15 пунктов. Это доказывает, что выбор модели имеет большее значение, чем выбор поискового движка. Кроме того, стоимость варьировалась сильнее для передовых моделей: самый дорогой движк стоил в 2.5 раза дороже самого дешевого, тогда как для бюджетных моделей разница составляла всего 1.5 раза.
Возможность такого сравнения существует благодаря тому, что серверный инструмент (server tool) находится над провайдером. Вы меняете модель в запросе, а поведение поиска остается согласованным, даже для моделей, у которых самого провайдера нет собственного поиска. Это позволяет изолировать влияние модели от влияния движка.
05Методология бэнчмаркирования
Чтобы ваши данные были надежными, важно понимать, как проводились тесты. Каждый запуск проходил через публичный API OpenRouter против продакшн-эндпоинтов, используя наш открытый фреймворк бэнчмаркинга. Мы изолировали производительность поиска: стандартизировали 10 результатов на поиск, отключили получение полных страниц (page fetching) и выполнение кода. Рассуждения (reasoning) были зафиксированы для каждой модели, как отражено в таблицах.
Оценки были строгими: каждый ответ оценивался как «верно» или «неверно» относительно официального ключа ответов, с использованием LLM-судьи для семантического сравнения, где это было необходимо. WideSearch также отдельно сообщает об точности отдельных элементов ответа. Стоимость и скорость рассчитывались на один вопрос, включая затраты на оценку. На страницах лидерборда всегда отображается последний квалифицированный запуск для каждой конфигурации, что гарантирует актуальность данных.
06Как применить это на практике
Все вышеперечисленные параметры доступны вам прямо сейчас на OpenRouter. Вот как настроить ваш агент:
- Web plugin: Запускает один поиск перед тем, как модель начнет писать. Это быстрый и дешевый вариант для вопросов, которым нужны просто свежие факты.
- Server tool: Передает модели инструмент поиска, позволяя ей решать, что искать дальше. Это то, что нужно, когда ответ требует нескольких шагов.
- Engine: На OpenRouter вы можете установить
engineвexa,parallel,perplexityилиnative. Значениеautoпытается использовать нативный поиск, а затем переходит к стороннему. - Search budget: Поле
max_tool_callsограничивает количество ходов агента, аmax_resultsустанавливает количество результатов, возвращаемых каждый раз.
07Часто задаваемые вопросы (FAQ)
Как эти оценки сравниваются с опубликованными лидербордами вендоров?
Они не являются напрямую сопоставимыми. Большинство опубликованных таблиц для этих бенчмарков измеряют полные продукты агентов, которые сочетают поиск, получение полных страниц и инструменты кода. Наши лидерборды изолируют конфигурации поиска: модель читает только фрагменты результатов поиска, без получения страниц и инструментов кода. Это позволяет прямое сравнение между конфигурациями, но не максимизирует баллы бенчмарка.
Какой поисковый движок мне выбрать?
Это зависит от модели и задачи, поэтому и существуют эти страницы. Разрыв между движками велик для некоторых моделей и незначителен для других, и собственный нативный поиск провайдера не всегда является его лучшим вариантом. Проверьте живой лидерборд для набора, ближайшего к вашей рабочей нагрузке, прочитайте стоимость и задержку вместе с баллом, и перепроверяйте его со временем, так как порядок меняется по мере появления новых запусков.
Насколько актуальны цифры?
Лидерборды всегда показывают последний квалифицированный запуск для каждой конфигурации, выполненный в бэнчмарк-харе OpenRouter против продакшн-эндпоинтов. Новые запуски заменяют старые на странице.
08Что это значит на практике
Для разработчиков AI-агентов ключевой вывод заключается в том, что оптимизация бюджета поиска дает наибольшую отдачу. Не бойтесь увеличивать количество поисковых запросов для сложных задач — это часто дешевле, чем покупка более дорогой модели. Однако будьте осторожны с задачами, где ответ может отсутствовать, чтобы избежать бесконечных циклов поиска. Выбор модели критичен, но правильный движок может значительно снизить затраты, особенно для передовых моделей. Используйте живые лидерборды как отправную точку, но всегда валидируйте конфигурации на своих реальных данных, чтобы найти идеальный баланс между стоимостью, скоростью и качеством.
Источник: OpenRouter ↗