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

У меня было 16 моделей, 7 поисковых инструментов, 2 провайдера ai моделей, одна компания и целая куча вопросов о том, как же модели ищут информацию о компаниях в интернете. Что находят, как обрабатывают найденное, какие делают выводы и как на это повлиять.

Что я проверял

В прошлой статье я разбирал агентский поиск на примере поиска людей в Сбере. В этот раз буду проверять уже саму информацию о компании. Для эксперимента решил взять информацию о Битрикс24. Её выбрал, потому что данные публичные: компанию сложно не заметить, у нее есть официальный сайт с ценами, ЕГРЮЛ, блог, архив вебинаров — всё, что агент должен уметь находить при анализе рынка или конкурентном анализе. 

Вопрос для всех моделей всегда один и тот же из 7 пунктов:

• П1 — юридическое лицо и реквизиты (ИНН, ОГРН, адрес). Тут была одна из ловушек, на которую могла попасться модель. ООО «БИТРИКС24» в Калининграде — это не тот Битрикс24, а пустой холдинг без сотрудников с ОКВЭД 64.20. Если агент перепутает, цифра будет красивой и неверной.

• П2 — выручка за последний известный год. Еще одно узкое место. Данные есть 23 год, за 24-25 компания данных не публиковала. Возможно, они есть в сервисах типа Rusprofile или Контур, но у меня платного доступа туда нет и не предполагалось по задумке.

• П3 — CEO и CMO с должностями. Генеральный указан в юридических документах, а директор по маркетингу активно дает комментарии в СМИ.

• П4 — продукты, тарифы, цены - все это есть на сайте компании.

• П5 — продуктовые обновления за 2026 год- их тоже можно найти на сайте и в релизах.

• П6 — два последних прошедших и два ближайших вебинара (проверял в середине октября).

• П7 — упоминания в СМИ за последние 6 месяцев (РБК, Ведомости, Forbes, Коммерсант, CNews и другие)

По каждому пункту — отметка модели: «уверен / не уверен / не знаю».

Как я считал

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

Каждый пункт оценивается по трёхбалльной шкале:

• В («верно») — все ключевые факты верны и подтверждены источником. Даёт 2 балла

• Ч («частично») — часть фактов верна или есть пропуски. Даёт 1 балл

• Н («не найдено») — пункт провален или пустой. Даёт 0 баллов

Максимум модель могла получить14 баллов. Кроме полноты я считал E — число пунктов с проверяемой ошибкой — и УВ (уверенные выдумки): это когда факт неверный, но модель подписала его «уверен». Такая ошибка в продакшене дороже пропуска: уверенные ответы никто не проверят, если о них не знают, они выглядят убедительно или это новая информация для человека, где он не разбирается. Рейтинговая метрика — чистый балл = Полнота − E.

Оценивал вручную и при помощи Grok Bot. LLM-судью, типа JEV, в этот раз не использовал.

Как шёл эксперимент

В этот раз было шесть этапов эксперимента, каждый этап отвечает на конкретный вопрос:

1. Без поиска — точка ноль: что модели знают сами о компании, без использования поиска.

2. Поисковая матрица — 2 бесплатные модели прогнал на  7 поисковикам; по одному прогону на комбинацию. Основная цель- понять работу поисковых инструментов.

3. Платные модели на лучшем поисковике

4. Три прогона на связку — проверяем воспроизводимость; выясняем разброс ответов от модели

5. Поиск с обвязкой — код сам скачивает источники, модель только извлекает поля; 

6. Полная серия — все модели × Exa, Brave, снимки DDG и Brave; итоговая сводка

Шаг 1: что модели знают сами по себе

Сначала я запустил 8 моделей без каких-либо инструментов, чтобы понимать что знает модель о Битриксе сама по себе. В промте указал: “у тебя нет доступа к интернету, используй только то, что знаешь”.

Понятно, что у каждой модели свой срез обучения — тот момент, после которого новые данные в неё не попадали. Gemini Flash обучен позже большинства, и это видно: он дал 5 верных ответов из 14, тогда как остальные набрали 1–3.

Но срез — лишь часть объяснения. Если бы дело было только в нём, все «свежие» модели шли бы рядом. Разрыв объясняется ещё и тем, как конкретная модель обращается с неопределённостью: выдумывает правдоподобное или честно пишет «не знаю».

Текущего директора по маркетингу (Вартаняна) не знает никто. CEO Рыжикова назвали шесть моделей. Это показывает границу публичности: генеральный директор из юридических документов индексируется везде, директор по маркетингу — только в профессиональных источниках, которые в обучающую выборку не попадают так же плотно.

gpt-oss выделяется отдельно. Остальные семь при неизвестных фактах писали «не знаю» или давали осторожный ответ. gpt-oss:120b генерировал детальные данные о несуществующих событиях с уверенной пометкой. Видимо, это особенность того поколения моделей Openai. 

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

Прежде чем переходить к результатам — несколько слов о каждом инструменте. Что именно агент вызывает и что получает в ответ.

Exa (exa.ai) — семантический поиск по собственному индексу. Запрос на естественном языке сопоставляется с эмбеддингами страниц. Возвращает полный текст, highlights, summary. На бесплатном тире — $10 кредитов в месяц. Хорошо находит конкретные факты, а не только ссылки. Ключ нужен, регистрация без карты.

DuckDuckGo (ddgs) — Python-библиотека duckduckgo-search, которая парсит выдачу нескольких движков. Без ключа, без SLA. Возвращает title, URL и сниппет около 200–300 символов. Для прототипов — нормально, для продакшена — хрупко: бывают временные блокировки по IP и изменения в выдаче без предупреждения.

Tavily — AI-агрегатор, оптимизированный под LLM. Агрегирует до 20 источников, режет контент на чанки по 500–800 символов и ранжирует по релевантности. Дает 1 000 кредитов в месяц без карты. Возвращает уже нарезанный контент — не надо самому скрейпить, но и повлиять на нарезку нельзя.

SearXNG — self-hosted метапоисковик на AGPL. Агрегирует до 244 источников. JSON-формат нужно включать вручную в конфиге. Возвращает сниппеты, полного текста нет — чтобы получить текст, нужен отдельный фетчер. Бесплатно при самостоятельном хостинге, но настройка занимает время.

Firecrawl — это скрейпер, а не поисковик. Рендерит страницу в Chromium, убирает рекламу и навигацию, отдаёт чистый markdown. Есть эндпоинт /search, но его задача — не найти, а прочитать уже известный URL. 1 000 кредитов в месяц без карты. Лучшее применение — читать страницы по конкретным ссылкам, которые нашёл другой инструмент.

Keenable — собственный индекс с point-in-time поиском. Можно указать дату индексации и запросить «как было тогда» — это отличает его от остальных. Публичный тир: 1 000 запросов в час на IP. С ключом — до 100 000 запросов в месяц бесплатно.

Brave Search API — собственный независимый индекс 30+ млрд страниц, а не агрегатор чужих результатов. Есть эндпоинт /llm/context, который разбивает контент на чанки под бюджет токенов — по идее, удобнее для агентов. Нужен ключ и банковская карта. Бесплатный тир — 2 000 запросов в месяц. Потратились быстро, докидывал 5$ на счет.

Шаг 2. Поисковая матрица

Для матрицы нужны были модели, которые честно говорят «не знаю», а не галюцинируют. Если взять модель с уверенными выдумками фактов (как gpt-oss), её результаты на поисковиках будут смесью реальных находок и галлюцинаций — и не поймёшь, что плохо: поисковик или модель.

Поэтому я взял два варианта с наименьшим числом уверенных выдумок — dots-3-note:free и nemotron-3-super — и прогнал их на всех семи поисковиках. По одному прогону на каждую комбинацию, 14 прогонов итого. По-хорошему, конечно, стоило взять какую-то модель помощнее, но я токены не печатаю, бюджет эксперимента ограничен.

Exa первый, DuckDuckGo второй, SearXNG последний с большим отрывом.

Почему SearXNG так плох? Я запускал локальный инстанс без настройки — из коробки. Он возвращает только сниппеты без полного текста. Агент получает 200-символьные обрезки и пытается из них собрать ответ. Вероятно, с правильной настройкой (подключённые источники, JSON-формат) результат был бы другим — но это отдельная задача, которую я не ставил.

Была показательная история с dots: агент нашёл ссылку на helpdesk.bitrixrix24.ru — с опечаткой в домене. URL открывался, отдавал HTTP 200. Агент подтвердил факт. Факт был неверным — он ссылался на чужой сайт. Если меня читают сотрудники Битрикс24, вам следуют обратить на это внимание, возможно, это фишинговая страница.

Это главный паттерн ошибок с поиском: не выдуманный URL, а неверное прочтение живой страницы. Из примерно 66 URL, проверенных вручную через curl, мёртвых оказалось только 2.

Но история с bitrixrix24.ru указывает на более серьёзный риск. Агент дотягивается до страниц, на которые человек никогда бы не кликнул — потому что тайпсквотинговый домен в поисковой выдаче просто не заметен. Страница отдаёт HTTP 200, контент выглядит правдоподобно, и факт уходит в ответ с пометкой «уверен». В реальном пайплайне это может быть фишинговый сайт, клон страницы конкурента или сайт-сателлит с намеренно искажёнными данными. Стоит добавить валидацию домена в обвязку до того, как выпускать агента в продакшн.

Шаг 3. Лучший поисковик + платные модели

Дальше я взял 8 платных моделей и прогнал их на Exa как лучшем поисковике матрицы. Среднее значение по ответам — 11,1/14, на 2 балла лучше бесплатных. CMO Вартаняна нашли все 8 — это хороший знак: на шаге 1 (без поиска) его не назвал никто. MiMo выдал про калининградские 422 млн: «это пустой холдинг с 0 сотрудников — это НЕ выручка бизнеса Битрикс24». Sol по выручке написал «не знаю» — честный пробел вместо выдумки.

Два наблюдения из этой серии стоят отдельного внимания.

Первое: точность важнее стоимости поиска. Exa тратит кредиты на извлечение полного текста — это и есть причина лучших результатов по сравнению с DDG. DuckDuckGo дешевле, но агент получает только сниппеты, и вынужден угадывать остальное.

Второе: ловушки сработали избирательно. Калининградское ООО поймало только тех, кто не зашёл в ЕГРЮЛ дополнительным запросом. MiMo и Qwen Max — зашли. Inkling — нет.

Шаг 4. Разброс между прогонами

После первых результатов я сделал по три прогона на каждую связку (связка — пара «модель + поисковик») — чтобы понять, насколько цифры поиска воспроизводимы. Я думаю, каждый из вас вспомнит случаи, когда один и тот же промт мог дать разные результаты.

Если в начале один прогон, как single shot мог показать работает/не работает связка, то дальше уже необходимо было понять, насколько воспроизводимым или хаотичнам будет ответ модели. Ведь задача в том, чтобы был одинаково качественным каждый раз и по всем запросам.

Оказалось вот что: разброс между прогонами одной модели — 3–6 баллов. Sol получал от 7 до 13 баллов на одном и том же промпте и поисковике. Разница между соседними местами в рейтинге — около 1 балла. 

Ниже таблица с расширенным до 16 количеством моделей:

Nemotron Ultra — сделал 2 из 3 прогонов, третий прогон так и не завершился из за ошибки, перепроверять не стал, оставил как есть.

У DeepSeek — 4 уверенных выдумки за три прогона: высокий балл достигается агрессивными домыслами. У GLM — 1 галлюцинация и похожий результат, но чище.

dots-3-note набрал среднюю 11,0 (столько же, сколько Qwen Max), но 5 раз галлюцинировал — пример высокой полноты при плохом качестве. Sol получал 7 до 13 баллов по трём прогонам — рейтинг по одному прогону у этой модели в первую очередь лотерея. MiMo первый по чистому баллу с нулём уверенных выдумок и при этом вдвое дешевле Sonnet за прогон.

Я попробовал добавить подсказку в промпт про вебинары: «ищи через helpdesk, смотри кэш, проверяй год». У Luna это дало +1 прошедший митап. Но полнота по всему ответу упала с 10,3 до 7,7 — лимит в 20 поисков ушёл на поиск инфы по вебинарам, остальные пункты оказались недоисканными. У dots стало хуже. Промпт-хаки нестабильны: меняешь одно, рушится другое.

Что агент реально делает под капотом

Это самое интересное из всего, что я нашёл уже в конце. Я посмотрел в tool_calls.json по каждому прогону и увидел паттерн, который объясняет почти всё.

Два типа вызовов, которые делает агент: web_search — запрос к поисковику, возвращает список ссылок и сниппетов; web_extract — агент переходит по конкретному URL и читает страницу целиком. Первое — найти, второе — прочитать.

Лидеры упираются в лимит поиска и открывают страницы. Qwen Max на Brave — около 23 вызовов web_search и 6 вызовов web_extract, 5–6 минут на прогон. MiMo и Sol делают примерно столько же. Они тратят большую часть инструментального бюджета именно на чтение: искать быстро, читать — дорого.

Слабые модели почти не читают страницы:

• Inkling: 7 поисков, 0 web_extract, ответ около 900 символов → полнота 3,7

• Mistral: 7 поисков, 0 выдержек → 4,0 во всех трёх прогонах Brave

• gpt-oss: 6 поисков и 1 выдержка, 30 секунд → 5–6 баллов

• Gemma: в среднем 0,3 выдержки на прогон

Sonnet и Gemini — промежуточный случай: 7–11 поисков, 0–1 выдержка, 40–50 секунд. Это дало быстрые, но неглубокие ответы. Sonnet на Brave в среднем получают по 8 баллов, хотя при поиске через Exa  получают 11,3. Они успевают собрать CEO, тарифы и продукты — но на вебинары и свежие упоминания в СМИ поискового бюджета уже не остаётся.

Если хотите ускорить агента — задумайтесь об этом компромиссе в первую очередь. Уменьшить лимит поиска значит меньше web_extract, а значит — провалы именно по трудным вопросам.

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

Ожидаешь, что чем модель “умнее” — значит точнее. Но на практике tool_calls показывает другое: точнее та модель, которая после поиска идёт читать страницы. Mistral сильная модель, но страницы почти не открывает — и уступает тем, кто открывает.

Шаг 5. Кто в каком режиме работает

Когда я добавил обвязку (код собирает снимок источников, модель только извлекает поля по готовому досье), появились неожиданные перевёртыши.

Что за снимок такой? Перед запуском серии прогонов я один раз запускаю скрипт-коллектор (collect.py), который скачивает фиксированный набор страниц и сохраняет их в snapshot.json с sha256-хэшем. После этого все прогоны серии получают одни и те же исходные данные — независимо от того, когда запускаются. Это убирает случайный шум живой выдачи и делает прогоны воспроизводимыми.

Gemini 3.8 Flash на снимке DDG — 12 баллов и 0 ошибок во всех трёх прогонах, почти бесплатно. При использовании Brave — только 9,3: агент останавливается рано, почти не открывает страницы.

Mistral Large 3 и Gemma 4 31B на живом поиске слабые (Brave 4,0 и 6,0 баллов соответственно). На снимке DDG правильность ответов поднимаются до 10,7: им легче писать по готовому досье, чем самим ходить по страницам.

Nemotron 3 Super — наоборот: живой Brave 9,0, снимки 3,3–3,7. Обвязка этой модели не подходит.

Luna на живом Brave получает 7,3б балла  (в П2 и П7 дает пустые ответы, рано останавливается). На снимке стабильно получает 11,0.

DeepSeek v4.1 Flash — разительный контраст режимов. На живом Exa: 11,7 средняя (один из лидеров). На обвязке DDG: 6,7 — ниже среднего по всей выборке. Обвязка Brave держит его на 10,7. Возможная причина: ВВП-снимок плохо покрывает именно те источники, которые DeepSeek привык брать на живом поиске. Exa возвращает полные страницы; DDG-снимок — сниппеты по фиксированным запросам. При обвязке Brave, где снимок богаче, модель восстанавливается.

Средний балл по пунктам по всем прогонам:

Ответы по CEO/CMO берут почти все и почти всегда: официальные страницы авторов bitrix24.ru/journal есть везде, имена стабильные. П7 ( упоминания в СМИ) на снимке Brave почти пуст: из 45 прогонов в 34 написано «не заполнено». Снимок делался одномоментно и не успевал собрать статьи СМИ за шесть месяцев — для этого нужно 10 запросов на издание, а не один..

Повторяющиеся ошибки из заметок ручной оценки:

• П2: «выручка 4,6 млрд за 2024» — при том что эталон 4,57 млрд за 2023. Округление плюс не тот год.

• П5: Битрикс24 назван CMS-продуктом. На снимках это почти штамп: GLM, Qwen Max и Gemma перепутали Битрикс24 с 1С-Битрикс (CMS). Новость про «Купить в 1 клик в сервисах Яндекса» — от 1С-Битрикс, но цитата, год и домен проходили все фильтры

• П6: дата 25 февраля как «последний вебинар» у Sol, Sonnet и Qwen Max на снимке DDG — все три повтора каждого. Код честно выбрал самый поздний из найденных

• П4: путаница «Л-AI» у Mistral на Brave во всех трёх прогонах; годовые цены записаны как месячные

• П2 «Л-422»: ловушка с калининградским ООО сработала на Inkling, Mistral, Gemma, Nemotron Super и gpt-oss на Exa

Сбой в Brave Search: отдельная история

В матрице шагов 2–3 Brave не было — у меня тогда был только бесплатный тариф с лимитом 2 000 запросов в месяц, которого не хватило даже на небольшой тест всех комбинаций. Позже оплатил и запустил отдельной серией.

Но получилось не без инцидента. В один момент, бесплатные 2 000 запросов исчерпались, и Brave начал возвращать HTTP 402 на каждый поиск. Мой детектор сбоев тогда умел ловить только 429, и 9 из 42 прогонов прошли с пустым поиском — модели отвечали без доступа к веб.

Пока я пополнял счёт, модели разделились:

• MiMo, Sol, DeepSeek — переключились на прямые URL из памяти и набрали 7–13 баллов. Они «знали» адреса достаточно хорошо, чтобы попробовать обойтись без поиска

• Luna — почти не отвечала без поиска, 0–4 балла

• Mistral — ответил из памяти, пометил всё «уверен» и поймал ловушку с каланинградским ООО: выдал 422 млн как выручку Битрикс24

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

Один вывод из этого эпизода: сбой инструмента не равен слабости модели. До перезапуска Mistral казался безнадёжным. После — просто слабым. Разница есть. В этом инциденте наглядно показано, как действует модель в нештатной ситуации.

Самый трудный вопрос — вебинары

Вопрос по вебинарам оказался самым сложным для всех моделей среди всех 90 прогонов. Ни одна модель, ни один режим не справился без ошибок.

По живому Exa поиску средний балл П6 — 0,77 из 2. По живому Brave — 0,44. По снимку Brave — 0,36.

Почему так сложно? Страницы прошедших вебинаров удаляются с сайта после события. Например, митап прошёл 6 октября — к 13 октября страница meetup-06102026.php уже отдаёт 404. Список вебинаров на bitrix24.ru рендерится JavaScript — экстрактор его не видит. Модель берёт любые даты, которые попались: партнёрские, иностранные, прошлогодние.

Так же все модели попали в повторяющуюся ловушку: укахали дату 25 февраля как «последний вебинар». В неё попали Sol, Sonnet и Qwen Max на снимке DDG — все три повтора каждого. Код честно выбрал самый поздний из найденных в снимке, не зная, что более свежие страницы уже удалены.

Даже код с прямыми фетчерами взял только 2 из 4 слотов (08.10 и 15.10). Страницы 06.10 и 13.10 — недоступны, удалены, DDG в снимок не попало. Без платного поиска с кэшем или Wayback Machine эти слоты не закрыть.

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

Единственный путь — либо специализированный инструмент (Wayback Machine API, платный кэш), либо забирать данные прямо в день события, а не ретроспективно. Для продакшен-агента это значит: вебинары лучше заполнять из отдельного источника с подпиской на расписание, а не полагаться на общий веб-поиск.

Шаг 6 Код ищет, модель только извлекает

На последнем шаге я поменял роли: поиск и проверку делает код, модель только извлекает поля в JSON. Это то, что обычно называют harness — обвязка вокруг модели.

Гипотеза была простая: главные ошибки в живом поиске — не галлюцинации модели, а неполный снимок страницы и неверная дата. Код с детерминированными правилами должен это исправить.

Схема такая:

1. Заранее скачивает фиксированные источники: ЕГРЮЛ, bitrix24.ru/prices, helpdesk-дайджесты, ответы DDG или Brave по конкретным изданиям

2. Модель получает готовое досье и возвращает поля: field, value, date, url, дословная цитата

3. Проверяется 8 условий: цитата есть на странице, год присутствует в цитате (не только в URL), домен в белом списке, «холдинг ≠ продукт».

4. Два независимых вызова на каждый пункт. Факт становится «уверенным» только если оба вызова дали одно и то же. Иначе — «на ревью».

Результаты с DDG в снимке:

MiMo: 1 ошибка — код выбрал митап 25.02 как «второй последний». Не галлюцинация модели, а неполный снимок: страницы 06.10 и 13.10 в DDG не попали.

С Brave в снимке результаты другие. Здесь же появляется DeepSeek: на живом Brave он набирал 11,0, теперь проверяем, как он ведёт себя в режиме обвязки.

DeepSeek 12,0 с нулём уверенных ошибок — его лучший результат за весь эксперимент. Luna 11,0 с нулём — тоже лучший для неё. Обвязка с Brave работает на обеих моделях лучше, чем живой поиск. Nemotron Super обвалился: 9,0 баллов на живом поиске и только 3,3 на снимке. Обвязка этой модели не подходит.

MiMo: 1 ошибка — «Купить в 1 клик» как продукт Битрикс24. На самом деле это функция CMS 1С-Битрикс, не CRM. Год, домен и цитата проходят все фильтры — фильтра «сущность-продукт» нет, и добавить его без базы знаний трудно.

Скорость с параллельными вызовами по пунктам: Luna укладывается в 1 минуту, DeepSeek — в 1,8. MiMo на Xiaomi-провайдере — 7–19 минут; с последовательными вызовами (как было при разработке) — 26–56 минут.

Скрытая стоимость обвязки: 8–30 фактов уходят «на ревью» человеку за прогон. Это сопоставимо с объёмом самой задачи. Обвязка убирает уверенные ошибки, но перекладывает часть работы. Если строить безлюдный конвейер — это важно считать отдельно.

Выводы и находки

1. Не начинайте с обвязки. Начните с живого поиска и нормальной модели. Топ-модели на живом Exa поиске давали 11,3–12,7. Те же модели на снимке с обвязкой (DDG) — 8,7–12,0. Свежесть выдачи важнее механики проверок. Обвязку добавляйте потом — когда есть конкретная причина: ошибки конкретного типа, которые обвязка умеет исправить. До этого момента обвязка лишь ослабит результат

2. Хорошая модель — не обязательно дорогая. MiMo v2.6 Pro на Brave обошёлся около $0,03–0,06 за прогон при полноте 12,3 и нуле уверенных ошибок. Sol за те же задачи — $0,2–0,4 при разбросе полноты 7–13. Прогоните 2–3 дешёвых варианта, прежде чем платить за флагман.

3. Хотите меньше вранья — проверяйте факты, но помните о цене. Обвязка с верификацией почти убирает уверенные ошибки. Но 8–30 фактов на прогон уходят человеку на проверку. Подходит, когда ошибка дорого стоит и есть человек на контроле. Не подходит для безлюдного конвейера.

4. Слабой модели обвязка вредит. Mistral без обвязки: 4,0; с обвязкой на снимке DDG: 10,7. Nemotron Super наоборот: 9,0 → 3,3. Обвязка это усилитель: поднимает сильных, топит слабых. Если агент с проверками стал хуже — меняйте модель, а не чините обвязку.

5. Проверяйте инструмент до того, как винить модель. 9 «плохих» прогонов Brave оказались исчерпанным бесплатным лимитом — HTTP 402 на всех поисках. Модели были ни при чём. Пробный запрос к поисковику перед прогоном обязателен. Если все поиски вернули ошибку — прогон не считается.

6. Добавьте валидацию домена. Агент дотягивается до тайпсквотинговых страниц (как bitrixrix24.ru), которые отдают HTTP 200 с правдоподобным контентом. Белый список разрешённых доменов в обвязке дешевле, чем разбор последствий.

7. Лог инцидентов — часть результатов. Ложный 429 из-за поиска подстрокой, самонаведённый 429 от 7 параллельных Ollama-вызовов, устаревшая копия models.json, дельты /key от параллельных прогонов — без разбора инцидентов команда повторно ловит те же грабли. Публикуйте лог вместе с цифрами.

8. Провайдер — часть условий. Одна модель через разные хостинги — не одна модель. DeepSeek и GLM сменили провайдера (c Ollama на Openrouter) посреди эксперимента — эти клетки несравнимы. Фиксируйте провайдера в метаданных каждого прогона.

9. Эталон дрейфует. Живая компания меняется каждую неделю. Версионируйте эталон с датой среза — иначе повтор через месяц будет мерить против частично устаревшего стандарта.

10. MiMo v2.6 Pro — лучшее соотношение цена/качество среди измеренных связок. Полнота 12–12,3, нуль уверенных ошибок, около $0,03–0,06 за прогон. В 4–6 раз дешевле флагманов при сопоставимой чистоте. Следите за провайдером: MiMo через Xiaomi-провайдера иногда отвечал 7–19 минут против нормы 5–6. Пиннинг провайдера здесь не опция, а необходимость для воспроизводимых результатов.

11.Полнота растёт с числом web_extract, а не с вызовом модели. Лидеры делают 22–23 поиска и 5–6 выдержек страниц. Слабые — 7 поисков и 0 выдержек. Если агент нашёл ссылки, но не зашёл на страницы — он сделал половину работы. Это же правило объясняет, почему смягчение лимита поиска улучшает результаты сильнее, чем замена модели на более дорогую.

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