Агентный поиск на open-source моделях: кого нашёл, сколько потратил и где всё сломалось

У меня давно была одна идея: хочу сделать свой агентный поиск на открытых моделях и со своим контролем над источниками. Не чтобы сэкономить на подписке, а скорее понять: какой минимум (технологического стека) нужен, чтобы агент нашел конкретную информацию, с проверяемым источником и не выдумал ссылку?

И первый сценарий, который я решил проверить - это поиск людей. Идея была такая: предположим, человек хочет найти контакты HR в компании и прислать ему свое резюме или людей из команд, занятых в ИИ продуктах. В качестве эксперимента, я взял Сбер, так как компания крупная, есть ИИ продукты, и штат отдела найма достаточно большой. Шанс правильного поиска высокий. И искать не руками через Google, а через агентов. Если способ окажется рабочим, та же схема переносится дальше - автоматизируем поиск конкретной информации и дальше.

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

Поиск я выбрал еще и потому, чтобы проверить: как модели ищут информацию, как влияет на поиск скилл, harness, инструменты (веб-поиск, терминал). Есть много бенчмарков на тему кодинга и агентских цепочек, но крайне мало информации об автоматизации поиска. В крупных вендорах, где я работал, вопрос анализа рынка, конкурентов, точность собираемой информации стоит крайне остро. Поэтому попытался проверить агентский поиск с разных сторон.

Какой стек я использовал

Большую шайтан машину с нуля строить не стал. Взял то, что уже было под рукой и с минимальным бюджетом, это же эксперимент. Выделил 10$ на Openrouter и 10$ на Ollama.

Что использовал:

Agent Hermes — Hermes даёт инструменты: поиск, открытие страниц, запись результатов. Обвязку можно менять независимо от модели.

Ollama — локальный провайдер моделей с бесплатным облачным тарифом. Все шесть моделей первых двух этапов работали на бесплатной квоте. Плата за сами модели — ноль. Отдельно тариф не покупал, просто закинул деньги на счет.

OpenRouter — маркетплейс моделей. Через него шли платные модели и запросы к JEV.

JEV — маленькая модель-судья. Сам он ничего не ищет — смотрит на результат поиска и решает, принять человека или отклонить. Задаю три вопроса: подтверждает ли источник роль в Сбере (число 0–1); к какой категории относится (HR / AI/ML-специалист / другая роль / агентство); работает ли там сейчас (число 0–1). Порог принятия: «подтверждённость» ≥ 0,70, «работает сейчас» ≥ 0,55, категория совпадает с задачей.

Grok bot — агентная система от X/Cursor. Очень удобен для оркестрации других агентов, управление самим проектом и вектором всего эксперимента. По сути, все общение сводилось с чатом с 2мя агентами, которым я ставил задачи и они дальше их дробили на подзадачи и отчитывались или задавали вопросы. Все было развернуто на их облаке (Ollama, Hermes, SearXNG) и это сильно упрощало проведение эксперимента.

Поиск шёл через свой прокси: сначала Яндекс через SearXNG, если пусто — кэш Ollama, потом живой поиск Ollama (не больше 3 вызовов на прогон). Запросы кэшировались и были общими для всех моделей.

Почему Яндекс через прокси, а не Google

Первоначально я искренне думал, что поиск агента пойдет через поисковик - Google или Bing. Агент может открыть google.com и дальше серфить по интернету. Но там меня ждало разочарование. У Google я поймал капчу сразу, французский Qwant тоже ответил капчей. Bing с оператором site: выдал мусор: на запрос про Сбер и machine learning прокси получил справку YouTube и результаты по Тайваню. Яндекс на тот же запрос вернул 6 результатов (все на habr.com, включая блог Сбера), на второй запрос — 15 релевантных ответов.

Как оказалось, официальный API Google для моей задачи недоступен. Custom Search JSON API закрыт для новых клиентов и выключается 1 января 2027 года. Замена для полного веба — партнёрский Web Search Service: 15$ за 1 000 запросов и минимум 30 000$ в месяц, это выходило далеко за рамки бюджета. Bing Search API закрыт с 11 августа 2025 года. Gemini Grounding (поиск Google внутри ответа модели) недоступен в России. Городить костыли не стал.

Обойти защиту Google с серверного IP нельзя устойчиво. В 2026 году Google уже ломал обход в SearXNG минимум пять раз — каждый обход жил от суток до трёх месяцев. С августа 2026 Google проверяет TLS-отпечаток клиента: одной подмены User-Agent мало. Свежий SearXNG с подделкой отпечатка Chrome (curl_cffi) с серверного IP всё равно получил капчу. 

Резидентные прокси тоже пришлось отмести. Платные деградируют быстро и конечно стоят денег. Найденный бенчмарк Paterson показал, что прокси перед Linux-сервером (который стоит у Grok) может даже ухудшить дело: IP становится «домашним», а TLS-отпечаток остаётся серверным, и защита видит противоречие. Туннель через домашний компьютер я делать не стал, было лень и суть эксперимента была не в этом.

Для Рунета Яндекс всё равно предпочтительнее. Хабр, hh.ru, vc.ru, TAdviser, Rusprofile — всё это Яндекс индексирует лучше Google. Единственный сильный довод за Google в нашей задаче — сниппеты LinkedIn по оператору site:linkedin.com/in "Сбер". Но LinkedIn всё равно не открывается агентом — только формат ссылки проверяется.

Ещё один факт для контекста, который удалось найти. Из публичных SearXNG-инстансов (начало октября 2026) медиана ошибок по движкам: Яндекс и Bing — 0%, Google — 10% (у тех, кто его включил), DuckDuckGo — 60%, Brave — 85%, Startpage, Qwant и Mojeek — почти 100%.

Еще была официальная альтернатива — Yandex Search API: 488 ру за 1 000 запросов днём. Google честно и дёшево можно получить через посредников: Serper (2 500 запросов бесплатно, дальше 1 бакс за 1 000) или XMLRiver (25 рублей за 1 000). Но это уже выходило за рамки бюджета, я решил протестировать это в следующий раз.

Первый опыт: голая модель vs skills

Прежде чем сравнивать модели между собой, провёл более простой опыт. Взял одну модель (это была gemma4:31b через Ollama Cloud) и одну задачу: найти людей и HR Сбера через developers.sber.ru. Эталон — 10 конкретных имён, которые точно там есть, я проверил.

Проверял пять вариантов. Три прогона на каждый. Результат получился такой:

Небольшая пояснительная бригада к столбцам. Полнота — доля нужных людей из эталона, которых нашла модель: нашла 9,7 из 10  значит  0,97. Точность — доля нужных людей среди всех, кого вернула модель: 12 нужных из 18 в списке → 0,68. Людей в списке и Лишних — среднее за три прогона, округлено до целых.

Навык B (weak-model-osint) обязывал модель читать найденную страницу перед тем как записать человека. Навык C (grounded-citations) требовал проверить источник. Вариант D — оба навыка вместе.

Что удивило: полнота у голой модели — 0,97. Без навыков она всё равно находит почти всех нужных людей. Но тащит 8 лишних: в основном рекрутеров из пресс-релизов и сторонних сайтов. Навыки точность повышают, но за это платишь временем и охватом: голая модель делала прогон за 52 секунды, с двумя навыками — 121 секунда. Вариант D с двумя навыками потерял в полноте: 0,87 вместо 0,97 — один нужный человек выпал, обвязка стала слишком строгой.

Лучший результат — A+JEV: полнота как у голой модели, точность как у двух навыков. Худший прогон варианта A нашёл 30 человек с 21 лишним. JEV сократил список до 9 без потери нужных. Стоимость JEV за три прогона — около 0,001$. Выдуманных ссылок и почтовых адресов во всех 12 прогонах — ноль.

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

Второй опыт: шесть моделей на одной задаче

Дальше уже интереснее: хотелось понять, меняется ли что-то при смене модели? Есть ли существенная разница в том, как они ищут что-то в интернете? Я запустил сравнение на шести опенсорсных моделях с Ollama. Задача эксперимента разделилась на два варианта:

• H1 — найти HR и рекрутеров Сбера, которые нанимают в ИИ-команды

• H2 — найти самих специалистов и руководителей по ИИ

Каждая пара «модель х вариант» — делала по два прогона. 24 действительных прогона. Все модели — бесплатный тариф Ollama, плата за модели — 0 $.

Для проверки ввел два условия. Условие 1 — модель нашла контакт, JEV принял человека, источник не устарел, ссылка настоящая. Условие 2 — то же плюс источник не старше 12 месяцев с указанной датой. Разница почти целиком — наличие даты публикации: у 182 из 218 найденных людей дата в источнике не указана.

Таблица: каждая пара чисел — первый и второй прогон.

Выдуманных ссылок — ноль во всех годных прогонах, кроме одной у nano.

HR не нашёл никто. Лучший результат по H1 — 3 подтверждённых в первом прогоне у gemma. Ни в одном прогоне порог в 5 человек не взял никто. Задача «найти HR» через открытые источники намного тяжелее, чем найти AI/ML-специалистов.

AI/ML-специалистов находят три модели из шести. Порог в 5 подтверждённых по условию 1 в обоих прогонах прошли: gemma4:31b (8 и 15), nemotron-3-super (6 и 10), gpt-oss:120b (6 и 7).

Разброс между двумя прогонами — в полтора-два раза. Gemma  находит то 8, то 15 контактов; доля официальных источников — то 10%, то 71%. У ultra найдено то 1, то 11 человек. Ровнее всех — gpt-oss:120b 

Nemotron-3-ultra берёт числом, но не качеством. Находит 30–33 человека по H2, JEV принимает 7–8. Самая медленная: 638–876 секунд на прогон. Расчётная стоимость прогона через OpenRouter — 0,19–0,38$. Четыре прогона ultra забирали по1,02$ из расчётных 1,38$ за весь этап. Остальные пять моделей вместе — 0,36$.

GPT-oss:120b — самый чистый результат. Меньше людей, зато 66,5% — с официальных сайтов Сбера. Быстрее всех на H2: 113 секунд в среднем.

GPT-oss:20b нестабилен на H1. Из четырёх попыток три закончились неразбираемым ответом: модель вернула не тот формат JSON. Единственный годный прогон нашёл ноль человек.

Nemotron-3-nano:30b — одна выдуманная ссылка. В прогоне H2 r1 нашёлся человек со ссылкой на реально существующую страницу Хабра — но ни в выдаче поиска, ни в логе инструментов прогона она не появлялась. Модель взяла адрес не из поиска. Пара nano H2 порог не прошла: первый прогон дал 3 подтверждённых, второй — 7.

Третий опыт: платные модели

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

Первый раунд был полностью азиатским: Deepseek, Kimi K3, GLM-5.3. Второй многонациональным: Mimo, GPT-6 Luna, Gemini 3.8 flash, Claude Sonnet 5.5.

Та же задача ( ищем HR и ML/AI), тот же веб-протокол, что и у шести бесплатных. Три модели, по два прогона на гипотезу. Метрика  - «подтверждённый контакт»: имя и цитата из источника, ссылка не выдумана, JEV принял, не дубль.

DeepSeek на H1 дал 17 подтверждённых — это первый случай, когда рекрутеры Сбера вообще нашлись в товарном количестве. У бесплатных максимум был 3. Второй прогон H1 не засчитан: агент словил parse error. H2 стабильнее: 24 и 16.

Kimi K3 — самый ровный: на H1 оба прогона в коридоре 8–11, на H2 14 и 15. Стоит в 13 раз дороже deepseek за прогон, качество сопоставимо.

GLM-5.3 нестабилен: H1 r1 = 4, H1 r2 = 13 — разброс в три раза при одинаковых условиях. Результат по AI/ML спецам достаточно слабый: 6 и 5.

Второй раунд: Sonnet 5.5, GPT-6 Luna, MiMo, Gemini. Задача и условия те же.

Выдуманных ссылок — 0 у всех четырёх.

MiMo: лучший результат раунда по количеству и по цене. Поиск HR весьма уверенный: 28 и 25. AI/ML специалистов ищет слабее (8 и 5) — модель, судя по всему, лучше ищет конкретных людей через developer-ресурсы, а не через общие источники. Стоимость — 0,10 $за четыре прогона, 0,0015$ за человека.

GPT-6 Luna: 32 подтвержденных, стиль — противоположность Sonnet. 18–26 API-вызовов на прогон, 4–7 минут, копает глубоко. Разброс большой: H1 7 и 2, H2 8 и 15. Выдуманных ссылок 0, ожидание выполнено.

Gemini 3.8 flash: 28 подтвержденных, самый дорогой раунда — 1,75$ за 4 прогона, 0,0625 $ за человека. Результат сопоставим с Luna при стоимости в 28 раз выше.

Sonnet 5.5: 25 подтверждённых, последнее место среди платных. Причина — не в качестве модели, а в стиле работы. Sonnet заканчивает прогон за 4 вызова и 40–64 секунды: упаковывает несколько действий в одну команду терминала и отвечает рано. При поиске HR в первом прогоне — ни одной открытой страницы, все три человека взяты из сниппетов LinkedIn в выдаче поиска. Второй прогон лучше( нашел 13 человек). В части прогонов он не передался в запрос из-за бага конфига Anthropic. Дорогая модель без правильной настройки обвязки проигрывает дешёвым открытым: она экономит шаги и не копает достаточно глубоко.

Что получается по обоим раундам вместе: Цена модели не коррелирует с результатом. DeepSeek в первом раунде за 0,02$ взял H1 лучше Kimi за 0,26$. MiMo во втором раунде за 0,10$ обошёл Gemini за 1,75$. Главное — не сколько стоит токен, а как модель ведёт себя в обвязке: уходит ли она в страницы или останавливается на сниппетах, работает ли с curl или ждёт рендеринга браузера, передаётся ли ей effort.

Четвёртый этап: новая обвязка улучшает поиск модели

Покопавшись в логах при помощи Grok bot, выяснились некоторые моменты. Поправили харнесс — изменили то, как агент формирует запросы и обходит страницы — и запустил мини-шаг с тремя моделями по 5 прогонов на deepseek и по 3 на остальные, чтобы проверить, повлияет ли изменения в обвязке на что-то.

Deepseek с новым харнессом стабильно находил 14–23 подтверждённых на H1 через пять прогонов — медиана 21,5. В первом этапе лучший результат на H1 у всех шести свободных моделей был 3 подтверждённых. В третьем этапе deepseek со старым харнессом дал 17 в одном прогоне. Теперь — стабильно 14–23 через пять прогонов.

Это прямое подтверждение главного вывода: обвязка решает больше, чем выбор модели. Та же модель, другой харнесс — результат на H1 вырос с нуля до стабильных 14–23.

При этом поведение deepseek на H2 оказалось неожиданным: H2 стал дешевле H1 в 2 раза и быстрее в 5 раз, а медиана — 22–23 подтверждённых вместо ожидаемых ~16. Новый харнесс не просто улучшил H1 — он изменил то, как deepseek распределяет ресурсы между задачами.

Терминальный поиск: агент с одним инструментом

Параллельно с веб-режимом я проверял принципиально другой подход: модели давал только терминал, без вебпоиска и web extract. Агент сам искал через curl — через наш поиск-прокси (SearXNG + Яндекс) и сам открывал страницы.

Зачем отдельная проверка. Терминальный режим  - это агент берет управление и решает, что и как скачать, и сам разбирает HTML. Вопрос был в том, какой режим агентного поиска даёт больше подтверждённых людей, и насколько он надёжен?

Важное про доказательства. В терминальном режиме текст, который модель вывела на экран, доказательством не считается: она могла написать echo "Иван Иванов, директор Сбера" и это выглядело бы как «найденный» человек. Поэтому в условие добавили обёртку curl_capture: каждый реальный вызов curl сохранялся в отдельную папку на сервере, недоступную модели. Доказательством считается только то, что попало в эту папку из настоящего HTTP-ответа.

Ограничения: 25 вызовов curl по правилу промпта, максимально 40; curl к LinkedIn заблокирован; лимит 900 секунд.

Терминал — примерно +160% от веба и +118% от веба с навыками. Весь шаг стоил $0,56, включая JEV.

Где выигрыш терминала. Почти весь — на H1 (рекрутеры):

На H2 (AI/ML-специалисты) терминал не лучше веба. Веб с навыками на H2 лидирует с большим отрывом.

По моделям результаты следующие:

Доля полезных вызовов curl (тех, что принесли подтверждённого человека): от 0,41 у gemma до 0,78 у GLM на H1.

Кто не смог ничего найти: gpt-oss:120b ломался с ошибкой 500 при попытке читать файл из потока — на H1 оба прогона в браке, на H2 только 6 человек. Nemotron-nano, super, ultra и gpt-oss:20b не прошли предварительную проверку и пытались жульничать и использовать web_search.

Платные модели в терминале : MiMo — 66, Gemini 3.8 Flash — 28, Claude Sonnet 5.5 — 25. Итого 119 подтверждённых Платные модели в терминальном режиме не полностью оправдали, так как я ожидал примерно в 2 раза выше результат, чем у опенсорсных моделей.

Оговорки. Вывод «терминал лучше веба» в основном держится на GLM, а не на среднем по моделям. Режимы шли в разные дни (веб — 29.09, терминал — 02–03.10): в разницу подмешан дрейф выдачи Яндекса. Только 2 повтора на модель.

Сравнение с Apollo: агенты против коммерческой базы

На всех этапах эксперимента, я сравнивал модели друг с другом. И наверняка у читающих эту статью, появится вопрос - а как проверить все то, что нашли агенты? Где эталонный датасет так сказать. Такой “датасет” я подготовил с помощью фри тарифа Apollo.io. Идея была в том, чтобы посмотреть- сколько людей, найденных агентами, есть в базе Apollo, которая построена на Linkedin. Ведь, по моей логике, у большинства из тех, кого мы ищем есть Linkedin. Пересечение, по моим прикидкам должно быть от 15 до 30%.

Что такое Apollo. Это платформа для отделов продаж и поиска клиентов с базой людей и компаний, собранной преимущественно из LinkedIn. Бесплатный тариф даёт доступ к поиску через интерфейс. Я вручную по фильтрам составил  список HR и рекрутеров Сбера: примерно 90 уникальных человек. Из них 70 —нанимающие: рекрутеры, HR, HR BP, руководители HR, 16 — L2 пограничные: HR-бренд, джуны, администраторы, 4 — мимо кассы (консультанты по SAP HR и прочие неожиданные должности).

Что нашли агенты: Пересечение между тем, что нашли агенты и тем, что выдал сервис было крошечное. Среди найденных агентами оказались только 3 из 70 L1 Apollo — 4,3%. 67 нанимающих из Apollo агенты не нашли. И наоборот: 46 нанимающих, найденных агентами, в Apollo нет. 

Что это означает. Агенты и Apollo видят разные срезы одного явления. Агенты берут русскоязычные открытые источники — Хабр, hh.ru, vc.ru, TAdviser, программы конференций. Apollo строит граф людей из LinkedIn. Ни один источник не полный, и Apollo нельзя считать эталоном полноты: это просто другой источник.

Что я в итоге понял про агентный поиск

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

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

1. Дешёвые модели подходят для сбора кандидатов. Это ещё не означает, что они закрывают задачу целиком

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

Отдельный фильтр в этом тесте оказался полезнее усложнения поискового промпта: сохранил полноту поиска и убрал неподходящих кандидатов. Это хороший аргумент в пользу разделения работы на два шага — сначала собрать, потом проверить.

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

2. Я сравнивал не только модели, но и их взаимодействие с обвязкой

На результат влияли поисковые запросы, доступные инструменты, чтение страниц, лимиты шагов, формат ответа и настройки провайдера. Где-то агент заканчивал после нескольких сниппетов, где-то открывал страницы и продолжал искать, где-то не мог вернуть корректный JSON.

Изменения обвязки помогли получить более устойчивый результат на DeepSeek и рабочие результаты на некоторых слабых моделях. Это повод проверять весь маршрут выполнения до того, как менять модель.

Практически я бы выбирал не модель по отдельности, а связку «модель + инструменты + правила проверки» под конкретную задачу.

3. Источник — это часть результата, а не украшение ответа

За эксперимент я почти не встретил придуманных ссылок. Но настоящая ссылка ещё не означает, что найденный факт верен.

Страница может существовать, но не подтверждать нужную роль. Она может описывать старую должность. Наконец, на ней может вообще не быть даты и не ясно, как атрибутировать информацию.

Поэтому я бы разделял как минимум три статуса:

• человек найден;

• источник подтверждает нужную роль или связь с компанией;

• актуальность этой информации подтверждена.

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

4. Универсального режима поиска я не нашёл

В терминальном режиме удалось собрать больше подтверждённых рекрутеров. Но на поиске AI/ML-специалистов преимущество было у веб-режима с навыками.

Это не история о том, что curl лучше веб-инструментов. Скорее, разные режимы по-разному подходят к разным источникам и типам информации. Кроме того, сравнение шло в разные дни, с небольшим числом повторов, а значительную часть выигрыша терминала дали отдельные модели.

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

5. Внешний судья полезен, но не заменяет эталон

JEV помог отсеивать неподходящих кандидатов. Однако его вердикт остаётся решением другой модели, а не независимым доказательством.

В этом эксперименте недостаточно описана калибровка его оценок. Поэтому число «принятых JEV» я не стал бы автоматически приравнивать к числу действительно подходящих людей.

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

Отдельный судья — полезный компонент цепочки. Но его тоже нужно проверять.

6. Несколько источников могут расширить охват сильнее, чем замена модели

Сравнение с Apollo.io оказалось показательным: из 70 нанимающих людей в моей выборке Apollo агенты нашли только троих.

Это не доказывает, что один способ лучше другого. Зато показывает, насколько разные аудитории видят разные источники.

Если нужна полнота, я бы не ограничивался улучшением поискового агента. Я бы объединял открытый веб, профильные базы и другие доступные источники, а затем отдельно решал задачи сопоставления людей, удаления дублей и проверки актуальности.

Агент не может найти информацию, до которой его поисковый контур не добирается.

Что я проверил бы в следующем эксперименте

Следующий шаг для меня — не добавить ещё десять моделей, а сделать сравнение более управляемым:

• Зафиксировать задачу, бюджет инструментальных вызовов и правила принятия результата.

• Разделить два теста: поиск по фиксированному набору источников и поиск в живом интернете.

• Сравнить старую и новую обвязку на одной модели в одинаковых условиях.

• Делать несколько повторов и учитывать не только успешные ответы, но и ошибки, тайм-ауты и неразбираемый JSON.

• Вручную проверить выборку решений JEV.

• Считать стоимость уникального проверенного результата, включая поиск, повторные попытки и фильтрацию.

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