Агент, который делает 3-5 тыс. поисковых запросов в месяц, быстро упирается в потолок бесплатных решений. Бесплатный поисковый API рано или поздно начинает валить вызовы, а self-hosted SearXNG получает капчи и теряет движки Google и Bing. Перезапуск контейнера помогает на пару дней, потом всё возвращается.
Кейс, вокруг которого построен разбор, типичен. Исследовательский агент месяцами жил на бесплатном поисковом API, пока все вызовы не начали падать. На замену развернули SearXNG, но его движки Google и Bing стали приостанавливаться из-за капч. Профиль нагрузки простой: документация и GitHub issues, нужны сниппеты, а для полезных результатов ещё и текст страницы. Автор кейса просит сообщество поделиться, кто сколько платит за 1 тыс. запросов и хватает ли дешёвых провайдеров для поиска по докам (обсуждение на r/LocalLLaMA).
Короткий ответ: при такой нагрузке нужен провайдер с оплатой за запрос, сниппетами и извлечением текста, а не очередной бесплатный ключ. Конкретные суммы зависят от тарифа, который вы выберете, поэтому ниже рамки выбора и вопросы, на которые придётся ответить до оплаты.
В чём проблема: бесплатный API падает, а SearXNG ловит капчи
Оба бесплатных пути выглядят по-разному, но упираются в одно: вы не контролируете сторону, которая отдаёт результаты. В первом случае это чужой сервис с квотой и политикой, во втором чужие поисковые движки, которые защищаются от автоматических запросов.
Почему бесплатный поисковый API перестаёт отвечать
Когда все вызовы одновременно начинают возвращать ошибку, причин обычно пять, и все они укладываются в категории:
- Квота. У бесплатного тарифа есть суточный или месячный лимит. Агент с фоновыми задачами упирается в него незаметно: часть запросов уходит на ретраи, часть на повторную проверку источников.
- Отсутствие SLA. Бесплатный доступ не гарантирует ни аптайм, ни латентность. Деградация на стороне сервиса проявляется в вашем коде только потоком исключений.
- Смена условий. Ключи отзывают, лимиты ужесточают, бесплатный тир закрывают или переносят в другой продукт. Уведомление приходит в лучшем случае письмом.
- Приоритет платных клиентов. При пиковой нагрузке бесплатные запросы отбрасываются первыми.
- Общий пул. Если ключ получен через демо-стенд или публичный прокси, квоту делят все пользователи пула.
В самом кейсе не указано, какой именно API отказал и какой лимит сработал. Для выбора замены это и не важно, важна закономерность. Бесплатный поисковый API это временная инфраструктура с горизонтом планирования в недели. Строить на нём агента, который должен работать месяцами, значит закладывать отказ в архитектуру.
Почему SearXNG не спасает: капчи и приостановка движков
SearXNG удобно воспринимать как «свой поисковик», но он ничего не ищет сам. Он отправляет запросы к внешним движкам, разбирает их HTML и склеивает выдачу. Дальше всё зависит от того, как Google и Bing отнесутся к вашему IP.
Антибот-защита у них строится на репутации адреса, частоте и шаблонности запросов. Агент с 3-5 тыс. запросов в месяц генерирует ровный механический трафик с одного IP, и для защиты это выглядит хуже, чем случайные запросы человека. Итог: капча на стороне движка и статус suspended у соответствующего engine в самом SearXNG. Движок не отдаёт меньше результатов, он перестаёт отвечать, пока вы не пройдёте проверку вручную.
Self-hosted в этой схеме не даёт иммунитета: запросы всё равно уходят наружу, с того же адреса и с той же периодичностью. Обход через прокси и ротацию адресов упирается в стоимость резидентных IP и в то, что правила движков меняются быстрее, чем вы будете обновлять конфиг. Разбор способов дать локальной LLM доступ к веб-поиску без дорогих API показывает, что SearXNG остаётся рабочей опцией для ручных экспериментов и низкой нагрузки, но не для постоянного фонового трафика.
Что на самом деле нужно агенту от поиска: сниппеты и текст страниц
Для исследовательского агента ссылка без текста почти бесполезна: модель не оценит релевантность по домену и заголовку. Ей нужен короткий фрагмент, чтобы решить, стоит ли открывать страницу, и полный текст, чтобы вытащить факт. Это два разных поля ответа, и они не всегда идут в комплекте.
Сниппеты, извлечение текста и формат ответа
Документацию провайдера стоит проверять по конкретному списку, а не по обещаниям на лендинге:
- Сниппет в ответе. Есть ли поле с фрагментом вокруг совпадения и какой у него лимит длины.
- Извлечение текста. Отдаёт ли API содержимое страницы отдельным вызовом, сколько стоит такой вызов, работает ли это на PDF и на страницах с JS-рендерингом.
- Структура JSON. Плоский список результатов или вложенные блоки с датой, языком и типом документа. Агенту проще работать с предсказуемой схемой.
- Лимиты на размер. Обрезка длинных страниц, максимальное число результатов на запрос, пагинация.
- Языки и домены. Умеет ли провайдер искать по конкретному сайту и фильтровать по языку: для документации это экономит половину выдачи.
- Свежесть. Фильтр по дате критичен для GitHub issues, где ответ трёхлетней давности часто уже неверен.
Разница между типами запросов заметна. Для документации важна точность попадания по термину: имя функции, флаг конфигурации, номер версии. Для GitHub issues важнее свежесть и живые комментарии в ветке. Провайдер, который хорошо ранжирует общие веб-страницы, не обязательно попадёт в оба сценария. Структурированный подход к запросам, о котором говорит разбор Keenable SELECT и SQL-подход к веб-поиску, тоже стоит держать в голове: он меняет формат выдачи, но не отменяет проверку фактов.
Критерии выбора платного поискового провайдера для агента
Сравнивать провайдеров по лендингам бессмысленно: у каждого своя единица тарификации. Приводите всё к двум числам: цена за 1 тыс. запросов и цена за 1 тыс. запросов с извлечением текста. Дальше сравнивайте лимиты и стабильность, потому что дешёвый тариф с жёстким RPS может обойтись дороже в пересчёте на сорванные задачи.
Цена за 1 тыс. запросов и как её считать под свой объём
Нагрузка 3-5 тыс. запросов в месяц удобна для расчёта: она достаточно велика, чтобы пакетные тарифы искажали картину, и достаточно мала, чтобы помещаться в дешёвые тиры. Считайте так:
| Что посчитать | Как считать | Где ошибиться |
|---|---|---|
| Приведённая цена | Стоимость тарифа / число запросов в нём × 1000 | Неиспользованные запросы из пакета сгорают, фактическая цена выше |
| Доля запросов с извлечением текста | Число глубоких чтений / общее число запросов | Извлечение часто тарифицируется отдельно и стоит дороже поиска |
| Месячный бюджет | Приведённая цена × 3-5 | Забыты ретраи, повторные вызовы по таймауту и фоновые проверки |
| Резерв | Бюджет × 1,2-1,5 | Всплеск задач в конце месяца упирается в лимит, а не в деньги |
Конкретные цифры в статье не приводятся намеренно: тарифы меняются, а перенос чужих цен в свой расчёт ничего не даёт. В обсуждении кейса автор как раз и просит сообщество поделиться текущими ставками за 1 тыс. запросов, потому что публичных сводок по этому рынку мало (тред на r/LocalLLaMA).
Лимиты, стабильность и SLA: что спросить до оплаты
Список вопросов, ответы на которые стоит получить письменно до привязки карты:
- Какой лимит на запросы в секунду и что происходит при его превышении: 429 с Retry-After или блокировка ключа?
- Есть ли суточный и месячный потолок, можно ли его поднять без смены тарифа?
- Есть ли SLA, статус-страница и история инцидентов за последние полгода?
- Как быстро отвечает поддержка на платном тарифе и есть ли отдельный канал для технических проблем?
- Есть ли ограничения на типы запросов и домены, например запрет на систематическую выборку с определённых сайтов.
- Что с логированием: хранятся ли тексты запросов и можно ли отключить хранение.
- Разрешено ли кэшировать и хранить результаты у себя: для агента с повторяющимися запросами к документации это прямая экономия.
Про стабильность конкретных провайдеров в исходных материалах данных нет, поэтому это именно вопросы, а не готовые оценки. Ответ «у нас всё стабильно» без статус-страницы и SLA проверкой не считается.
Хватит ли дешёвого провайдера для документации и GitHub issues
Для этих двух сценариев дешёвый тариф часто достаточен, но не автоматически. Логика простая: агенту нужен точный список страниц со сниппетами, а текст он может дочитать сам. Если в пайплайне уже есть загрузчик страниц, платить за извлечение текста на каждом запросе не обязательно.
Когда экономия работает:
- Запросы узкие и терминологические, выдачи на 3-5 результатов хватает.
- Документация лежит на известных доменах, и провайдер умеет искать по сайту.
- Агент умеет открывать страницу и вытаскивать текст самостоятельно.
Когда дешёвый тариф начинает мешать:
- Извлечение текста нужно на большинстве запросов, а оно тарифицируется отдельно или недоступно.
- Жёсткий RPS заставляет агента ждать, и общее время задачи растёт.
- Нет фильтра по дате, и по GitHub issues приходят устаревшие обсуждения.
- Лимит выбирается за первую неделю месяца, дальше агент работает вслепую.
Достоверного ответа, хватает ли дешёвых провайдеров для поиска по документации, в исходном кейсе нет: автор вопроса сам его задаёт. Проверять придётся на своём наборе запросов. Возьмите 30-50 реальных запросов из логов агента, прогоните через пробный тариф и посчитайте, в каком проценте случаев топ-3 результатов содержит нужную страницу и в каком приходится идти в текст. Если второй показатель высокий, считайте бюджет с извлечением, а не без него.
Как переехать с бесплатного API или SearXNG на платный поиск
Переезд стоит делать так, чтобы следующая смена провайдера заняла один вечер, а не неделю. Пять шагов, которые решают эту задачу:
- Вынести поиск в отдельный слой. Агент вызывает свою функцию поиска, а не SDK провайдера напрямую. Внутри адаптер под конкретный API.
- Нормализовать ответ. Привести выдачу к одной структуре: заголовок, URL, сниппет, текст страницы (если запрошен), дата, источник. Дальше агент работает только с ней.
- Добавить фолбэк. Основной провайдер, второй на случай 429 и 5xx, локальный SearXNG как последний резерв для ручной отладки. Резервный канал не должен быть основным: капчи никуда не делись.
- Логировать ошибки и латентность. Без этого не понять, платите вы за поиск или за ретраи. Пишите код ответа, время, число результатов и признак «понадобился текст страницы».
- Прогнать тестовый набор. Те же 30-50 запросов до и после миграции. Сравнивайте не общее впечатление, а долю запросов, где нужный документ попал в топ-3.
Отдельно предусмотрите счётчик расхода: жёсткий лимит в месяц на уровне обёртки. Провайдер пришлёт счёт, а фоновый агент сам не остановится.
Что проверить перед оплатой: короткий чек-лист
- Есть ли пробный период или бесплатный лимит и хватит ли его на 30-50 реальных запросов.
- Отдаёт ли API сниппеты и текст страницы, сколько стоит каждый тип вызова по отдельности.
- Какая приведённая цена за 1 тыс. запросов при объёме 3-5 тыс. в месяц и с учётом ретраев.
- Какие лимиты на RPS, сутки и месяц и что приходит при превышении: 429 или блокировка.
- Есть ли SLA, статус-страница и история инцидентов.
- Можно ли искать по конкретному домену и фильтровать по дате.
- Разрешено ли кэшировать результаты и хранить тексты страниц локально.
- Как устроен биллинг при ошибке: списываются ли неудачные запросы.
Если ответы есть в документации, а тестовый прогон показывает приемлемую точность, переход оправдан. Если по лимитам и извлечению текста ясности нет, дешевле уточнить до оплаты, чем потом переписывать пайплайн под новый API.
SearXNG при этом стоит оставить локальным резервом. Как основной канал он не годится, но при аварии провайдера позволит агенту дожить до утра.