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

Habr опубликовал разбор эксперимента, который сегодня повторяют многие команды: агентный поиск на открытых моделях вместо готового сервиса вроде Deep Research. Автор сразу оговаривает мотив. Экономия на подписке его не интересует. Он хочет выяснить, какой минимум технологического стека нужен, чтобы агент нашёл конкретную информацию, привёл источник, который можно проверить, и не выдумал ссылку. В анонсе цифр нет. Стоимость прогонов и конкретные сбои вынесены в полный текст, и здесь мы опираемся только на заявленную постановку задачи.

Какую задачу решает автор

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

Отдельно стоит требование «со своим контролем над источниками». Коммерческие агенты ходят по вебу сами, и пользователь видит только итоговый отчёт. В самосборной системе можно ограничить домены, логировать каждый запрос и сохранять страницу, из которой взята цитата.

Из чего обычно собирается такой стек

Автор в анонсе не перечисляет компоненты, поэтому ниже общая схема, по которой строят подобные системы. Это не описание его конструкции.

• Поисковый слой: метапоисковик или API выдачи, который отдаёт список URL.
• Загрузчик страниц: получает HTML, очищает его до читаемого текста и справляется с JavaScript и блокировками.
• Планировщик: открытая LLM, которая разбивает вопрос на подзапросы и решает, когда остановиться.
• Экстрактор: вытаскивает из страницы нужный факт вместе с дословной цитатой.
• Верификатор: проверяет, что URL существует и что цитата действительно есть на странице.

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

Где такие системы обычно ломаются

Заголовок прямо говорит, что сломалось. Типовые точки отказа в агентном поиске хорошо известны, и вероятно, часть из них автор и описывает.

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

Как использовать этот подход на практике

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

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

Стоимость успешного ответа важнее цены запуска. Дешёвая модель, которая в половине случаев проваливается, может обойтись дороже дорогой. Чтобы сравнить свой стек с результатами автора, нужны его реальные цифры, и они есть только в полной статье на Habr.