Как я тестировал поиск для ИИ-агентов и не нашёл одного победителя

В какой-то момент почти любой ИИ-агент упирается в одну и ту же проблему: модель умеет писать, но факты ей всё равно надо откуда-то брать.

Можно подключить поиск, разрешить агенту читать страницы и считать задачу решённой. Я попробовал сделать именно так — а потом обнаружил, что под словом «поиск» скрываются как минимум три разные работы.

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

Я сравнил обычный веб-поиск, Keenable и Firecrawl на 24 одинаковых запросах. Результат оказался полезнее рейтинга: универсального победителя нет, зато у каждого инструмента обнаружилась понятная роль.

Зачем я вообще полез сравнивать поиск

На pimenov.ai я строю материалы из источников. Агент может помочь с поиском, разбором, структурой и черновиком, но каждое существенное утверждение должно возвращаться к конкретному документу.

Слабое место такого процесса — не генерация текста. Слабое место начинается раньше: какой источник попал в контекст, почему агент выбрал именно его и не потерял ли он по дороге официальную страницу, дату или важное ограничение.

Один поисковик легко создаёт иллюзию полноты. Он приносит десять аккуратных результатов, и кажется, что тема изучена. Но в этой десятке могут оказаться пять пересказов одной новости, две SEO-подборки, устаревшая документация и один первоисточник, который почему-то лежит внизу.

Поэтому я начал не с вопроса «кто ищет лучше», а с более практичного: какую работу разумно поручить каждому поисковому слою, чтобы агент собирал проверяемый материал.

Как маленький тест превратился в 24 запроса

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

Тогда я зафиксировал расширенный план:

• 8 тем, близких к моей реальной работе;
• 3 поисковых намерения на каждую тему;
• 24 одинаковых запроса для каждого провайдера.

Темы включали агентную разработку, исследовательские инструменты, редакционный процесс и происхождение фактов, ИИ в бизнесе, мультимодальность, российскую инфраструктуру, локальные модели и ранние социальные сигналы.

Для каждой темы я проверял три намерения:

1. Свежесть — что появилось недавно.
2. Первоисточник — где находится канонический документ.
3. Решение — какие данные помогают принять редакционное или техническое решение.

Для Keenable я использовал зафиксированное время запроса. Firecrawl точного аналога query_time не дал, поэтому для него я сохранил те же интервалы публикации. Это делает третью дорожку приблизительно сопоставимой, но не идентичной. В итогах я не скрываю это ограничение.

Результаты без рекламного тумана

После общего редакционного сравнения 24 запросов картина получилась такой:

У Keenable успешно завершились 24 поиска и 48 чтений страниц. Все 48 выбранных страниц были получены, 40 источников прошли редакционный отбор как полезные.

У обычного веб-поиска получилось 44 успешных открытия из 48 и 44 полезных источника. Это не делает его технически надёжнее как загрузчик страниц, но по широте обнаружения он оказался сильнее.

Firecrawl выполнил 24 поиска. Из 43 попыток извлечения страниц успешными были 36; после исключения двух антибот-страниц с формальным HTTP 200 осталось 34 полезных текста. Ещё пять запланированных извлечений я сознательно не запускал после срабатывания стоп-линии.

Денежный расход во всех трёх дорожках составил $0: использовались существующие бесплатные лимиты, карту и платный план я не добавлял. Остаток бесплатного лимита после пилота отдельно не считывался, поэтому я утверждаю только то, что реально наблюдал в выполненных действиях.

Обычный веб-поиск лучше видел широкую картину

Самый сильный результат обычного поиска — не конкретная ссылка, а разнообразие поля.

Он лучше находил независимые исследования, российские сравнения, Reddit, Hacker News, YouTube, X и материалы, которые не лежат на очевидном официальном домене. На темах про бизнес, локальный ИИ, российскую инфраструктуру и ранние сигналы это давало более содержательную картину.

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

Но веб-поиск не всегда хорошо читает найденное. Четыре выбранные страницы не открылись. Поэтому широкий поиск стоит считать разведкой, а не гарантированным способом получить полный текст каждого источника.

Keenable оказался хорошим вторым проходом

Keenable лучше всего работал там, где я заранее понимал, какой класс источника нужен: официальная документация OpenAI, тарифная страница, журнал изменений, документация Yandex Cloud или исторический срез на конкретную дату.

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

Слабость проявилась на широких запросах. В верх выдачи чаще попадали SEO-подборки, каталоги, сравнительные тесты самих поставщиков и повторяющиеся пересказы. На социальных источниках и русскоязычном поиске разница была ещё заметнее.

Поэтому итог двухпровайдерного этапа я сформулировал как supplement_not_replace: Keenable дополняет основной поиск, но не заменяет его.

Firecrawl полезен после поиска

Firecrawl раскрылся не как ещё один универсальный поисковик, а как инструмент извлечения. После того как URL уже выбран, он хорошо превращал длинные HTML-страницы в чистый текст. Особенно полезными оказались официальная документация и длинные страницы NIST, Frontiers, PMC и Apple.

На этапе свежего поиска результаты были слабее: заметную долю занимали LinkedIn, Facebook и SEO-страницы. Это увеличивало работу редактора и не давало преимуществ перед обычным веб-поиском.

Отсюда и рабочее решение: Firecrawl включается после отбора URL. Поиск отвечает за обнаружение, редактор или правило — за выбор страницы, Firecrawl — за глубокое чтение там, где обычного открытия недостаточно.

Один X-запрос пробил установленный лимит

Самый полезный момент пилота произошёл не на удачном результате, а на неожиданном расходе.

Я установил для Firecrawl максимум 96 кредитов из существующего бесплатного лимита. После 24 поисков и серии обычных извлечений один запрос к публичной странице X был отправлен с proxy=basic. В ответных метаданных сервис сообщил creditsUsed: 30.

После этого вызова подтверждённый расход Firecrawl составил 113 кредитов: 48 на поиск и 65 на извлечение. Лимит оказался превышен на 17 кредитов, хотя следующий вызов я остановил сразу. Пять оставшихся страниц не запускал.

Это не означает, что Firecrawl всегда берёт 30 кредитов за X, и не доказывает платное списание. Это означает ровно то, что я увидел: один конкретный ответ вернул такое значение в метаданных, а защитный контур узнал о превышении уже после выполнения запроса.

В актуальной документации Firecrawl обычное извлечение с режимом basic описано как операция стоимостью 1 кредит, а усиленный прокси — до 5 кредитов. Наблюдаемый в пилоте ответ в эту модель не уложился. Значит, одного общего лимита на сессию недостаточно: нужна проверка стоимости после каждого вызова, запрет рискованных доменов и остановка до следующей операции.

Поиск и чтение страницы — разные задачи

До пилота я обсуждал три сервиса так, будто они делают одно и то же. После пилота стало понятно, что сравнение «кто лучше ищет» слишком грубое.

Есть как минимум четыре разных качества:

• широкий поиск — заметить релевантную страницу среди шума;
• точечный поиск — вернуть нужную страницу по точному намерению;
• извлечение — получить из выбранного URL полный и чистый текст;
• редакторская проверка — связать утверждение с источником и решить, достаточно ли доказательств.

Один инструмент может отлично извлекать текст и посредственно выполнять широкий поиск. Другой широко видит поле, но не открывает часть страниц. Третий надёжно возвращает официальную документацию, но хуже замечает ранние социальные сигналы.

Как только эти роли разделены, исчезает требование найти одного победителя. Появляется система, в которой каждый слой отвечает за свою часть работы.

Контур, который я оставил для pimenov.ai

После пилота рабочая схема выглядит так:

1. Обычный веб-поиск запускает широкий поиск по трём задачам: свежесть, первоисточник и решение.
2. Keenable делает второй независимый проход по официальным документам, тарифам, журналам изменений и историческим срезам.
3. Редакторский отбор определяет, какие URL действительно нужны для материала.
4. Firecrawl получает только выбранные страницы, если нужен полный HTML или обычное открытие не сработало.
5. Реестр утверждений хранит связь «утверждение → источник → дата → ограничение».
6. Человек принимает финальное решение о тексте и публикации.

Для Firecrawl добавляется отдельная защита: список запрещённых доменов для X, Reddit и других непредсказуемых источников, ожидаемый потолок кредита на один вызов и жёсткая остановка после любого отклонения. Пока провайдер не даёт безопасный предварительный расчёт стоимости, контроль остаётся реактивным, поэтому рискованные страницы лучше читать другим способом.

Семь правил, которые я вынес из пилота

1. Замораживайте план до запуска. Одинаковые запросы и критерии уменьшают соблазн подогнать эксперимент под понравившийся результат.
2. Разделяйте поисковые намерения. Свежесть, первоисточник и решение требуют разных формулировок и разных источников.
3. Считайте вызовы и полезные источники отдельно. Технически успешный ответ ещё не означает редакционную ценность.
4. Сравнивайте на реальных темах. Красивый сравнительный тест мало говорит о русском контексте, социальных сигналах или вашей системе управления контентом.
5. Не смешивайте поиск и извлечение. Сначала выберите URL, затем платите за глубокое чтение.
6. Ставьте стоп на следующий вызов. Постфактум вернуть уже потраченные кредиты нельзя, но можно не продолжать каскад.
7. Оставляйте человеческий гейт. Агент собирает доказательства, редактор отвечает за вывод.

Победила архитектура процесса

Если превратить пилот в рейтинг, получится простой заголовок: обычный веб-поиск выиграл 14 запросов, Keenable — 3, Firecrawl — 2, ещё 5 закончились ничьей.

Но для практической работы важнее другое.

Обычный поиск дал широту. Keenable добавил воспроизводимый проход по первоисточникам. Firecrawl показал ценность глубокого извлечения и одновременно обнаружил слабое место в контроле расходов. Редакторский слой собрал это в проверяемую систему.

Поэтому главный вывод пилота — не название сервиса. Надёжный ИИ-материал начинается с маршрута: найти, выбрать источник, получить текст, проверить утверждение, принять решение.

Следующий шаг

ИИ-контент на потоке: почему проблема не в генерации, а в контроле

Связанные материалы

• Статья: Как я собрал команду из трёх ИИ-агентов и автоматизировал разработку через Notion
• Блог: Сделали pimenov.ai agent-ready: что реально внедрили и зачем
• База знаний: OpenAI Codex — облачный coding-агент для параллельной разработки

Если вы строите исследовательский или редакционный контур с ИИ-агентами, полезно заранее разделить роли поиска, извлечения и проверки — и только потом выбирать инструменты.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov