TinyFish разбирает архитектуру агентного поиска для продукционных ИИ-агентов
ИИ-агент поиска может успешно работать в демонстрационной версии, но давать сбои при производственных нагрузках, если поиск возвращает неполные данные, повторные попытки воспроизводят неудачные действия или выполнение превышает ограничения по времени и стоимости. TinyFish, предоставляющая веб-инфраструктуру для ИИ-агентов, опубликовала два технических руководства, посвящённых этим проблемам. В первом описывается архитектура агентского поиска для промышленной эксплуатации, а во втором представлены уроки создания системы глубокого исследования. Вместе они рассматривают, как автономный поисковый агент может планировать получение данных, оценивать доказательства, обрабатывать сбои и управлять границей между рассуждениями модели и детерминированным выполнением.
КРАТКО
TinyFish представила архитектуру агентского поиска и ключевые инженерные выводы, сделанные при создании систем глубокого исследования. Система построена на четырёх веб-примитивах (TinySearch, TinyFetch, TinyBrowser и TinyAgent) и работает посредством семифазного управляющего цикла вокруг базовой модели. На OpenBenchmarks TinyFish достигла показателя завершения 79,0% в задачах программирования, обеспечив при этом наименьшую медианную стоимость задачи (0,050 доллара) и наименьшее количество токенов, что подчёркивает важность жёстких управляющих циклов, повторных попыток с учётом типа сбоя и единого рассуждения вместо отдельных планировщиков.
Что такое архитектура агентского поиска?
Архитектура агентского поиска позволяет ИИ-агенту планировать получение данных, обращаться к источникам, оценивать доказательства и адаптировать свой подход по мере появления новой информации. Модель отвечает за рассуждения, а окружающее приложение управляет состоянием, выполнением инструментов, обработкой доказательств, политиками времени выполнения и проверкой результатов. Вместе эти компоненты позволяют агенту работать с неполными результатами, устранимыми сбоями и меняющимися требованиями к информации.
Архитектура TinyFish заимствует фундаментальные концепции из архитектурного препринта, опубликованного в феврале 2026 года, в котором рассуждения отделяются от выполнения с помощью типизированных интерфейсов инструментов. В статье устанавливаются важные системные ограничения, включая подробную трассировку наряду со строгими лимитами на количество токенов, время выполнения, общую стоимость и число вызовов инструментов.
Как выполняется поисковый запрос в промышленной системе?
TinyFish разделяет выполнение на 7 фаз:
- Определение задачи: Преобразовать цель в «контракт на доказательства»: обязательные поля, источники, актуальность и правила завершения.
- Планирование получения данных: Отделить независимые потребности от зависимых. Зависимые запросы ожидают ответов на предыдущие.
- Выбор первого маршрута: Выбрать инструмент на основе того, что системе известно о доказательствах.
- Обнаружение, отбор и получение: Считать результаты поиска кандидатами до тех пор, пока не будет получено содержимое страницы.
- Оценка: Пометить доказательства как достаточные, неполные, противоречивые, недоступные или исчерпавшие бюджет.
- Восстановление или эскалация: Изменить запрос, повторить попытку, сменить источники или способ доступа.
- Остановка и проверка: Вернуть статус «завершено», «неполно», «ошибка», «отменено» или «требуется проверка человеком».
Фаза 2 направлена на устранение известной проблемы. ChainRAG (ACL 2025) называет её проблемой «потери при поиске», когда ключевые сущности исчезают в процессе декомпозиции многоэтапного вопроса. Фаза 6 опирается на Search-R1, демонстрирующую, как модели могут обучаться генерировать дополнительные поисковые запросы в процессе рассуждения, когда предыдущий поиск оказывается недостаточным. В 7 наборах данных для вопросов и ответов её обученный многошаговый поиск превзошёл базовые показатели RAG на 41% (Qwen2.5-7B) и 20% (Qwen2.5-3B).
Как поисковому агенту выбирать инструменты?
Маршрутизация должна определяться информационным пробелом, а не фиксированной последовательностью.
| Исходное условие | Примитив | Что по-прежнему контролирует приложение |
| Местоположение источника неизвестно | Search | Планирование запросов, политика выбора источников, остановка |
| URL известен и доступен для чтения | Fetch | Проверка полноты, валидация утверждений |
| Приложение должно управлять действиями на странице | Browser | Каждое действие, повторная попытка и контрольная точка |
| Решения по нескольким страницам | Web Agent | Бизнес-правила, бюджеты, валидация |
Эскалация не всегда является решением. Слабые результаты требуют более качественного запроса. Противоречивые источники требуют более убедительных доказательств. Более мощный инструмент не устранит ни одну из этих проблем.
Повторные попытки должны зависеть от типа сбоя и укладываться в установленные ограничения. Временные ошибки могут оправдывать повторение запроса, тогда как неполные или противоречивые доказательства требуют другого подхода. При повторных попытках в браузере также необходимо учитывать уже выполненные действия, чтобы избежать непреднамеренных последствий, например повторной отправки одной и той же формы.
Чему TinyFish научилась при создании системы глубокого исследования?
Агент глубокого исследования ищет, просматривает веб-страницы и создаёт подробные отчёты с цитатами. Большинство инженерных проблем было связано с управлением контекстом, оркестрацией системы и дизайном продукта.
Урок №1: отказ от отдельного планировщика
На первых этапах использовался отдельный планировщик, который вызывался заново при каждом запуске. В него передавалось только структурированное состояние. В дополнительных запросах вроде «сосредоточься только на ценовых рисках в Юго-Восточной Азии» агент возвращался к широкому исследованию рынка. Впоследствии TinyFish перенесла планирование в единый цикл рассуждений самого оркестратора.
Урок №2: отказ от субагентов:
TinyFish изначально назначала отдельного субагента для каждого поискового запроса, увеличивая накладные расходы на переключение контекста, задержку и стоимость. Позднее команда заменила этих субагентов вызовами инструментов для повторяемых задач, таких как ранжирование результатов поиска, классификация источников и извлечение доказательств. Это уменьшило объём информации, передаваемой оркестратору, позволив ему сосредоточиться на планировании исследования и решении, что изучать дальше.
Урок №3: подбор исследователей:
TinyFish изначально оптимизировала свою исследовательскую систему под охват источников, однако пользователи придавали большее значение качеству и релевантности подтверждающих доказательств. Команда скорректировала ранжирование источников с учётом цели исследования и добавила средства управления для приоритизации, исключения или ограничения доменов. Также она разработала внутреннюю систему оценки с использованием судьи на основе LLM для проверки отчётов по релевантности, убедительности доказательств, надёжности цитат и разнообразию источников.
Как складываются стоимость и задержка?
TinyFish учитывает бюджет всей задачи, а не отдельных вызовов:
- Задержка задачи = планирование + поиск + получение данных + оценка + повторные попытки + интерактивные шаги + постановка в очередь.
- Стоимость задачи = токены + вызовы инструментов + использование страниц или браузера + повторные попытки + инфраструктура.
SearchAgent-X (ICLR 2026) показывает почему. Точный поиск увеличивал накладные расходы, а грубый поиск вынуждал выполнять дополнительные рассуждения. Внесённые исправления обеспечили до 3,4-кратного роста пропускной способности и пятикратного снижения задержки по сравнению с протестированными базовыми системами.
Как TinyFish сравнивается с другими решениями в поиске и получении данных?
OpenBenchmarks фиксирует модель (gpt-5.6-sol), 100 задач и бюджеты, изменяя только поставщика. Показатели являются средними значениями по 3 запускам.
| Показатель | TinyFish | Exa deep | Perplexity | Firecrawl |
| Завершение поиска + получения данных | 79,0% ± 2,0 | 83,0% ± 1,0 | 77,7% ± 1,5 | 76,0% ± 1,0 |
| Медианное время задачи | 24 с | 37 с | 22 с | 34 с |
| Медианная стоимость задачи | $0,050 | $0,127 | $0,083 | $0,082 |
| Медианное количество токенов на задачу | 12 844 | 23 660 | 20 062 | 17 379 |
| Завершение только поиска | 59,3% | 66,3% (Exa fast) | 77,3% | 70,3% |
| Цена поискового списка | $0 | $0,012 | $0,005 | $0,005 |
Источник: таблица OpenBenchmarks, обновлено 26 сентября 2026 года. Задачи охватывают только документацию для корпоративного сектора.
OpenBenchmarks также отдельно публикует результаты только для поиска. В этой конфигурации TinyFish достигла показателя завершения задач 59,3% против 77,3% у Perplexity, 70,3% у Firecrawl и 66,3% у Exa Fast. Эти результаты не следует напрямую сравнивать с показателями поиска и получения данных, поскольку доступные возможности поиска различаются.
Основные выводы
- Контролируйте весь процесс, а не один поисковый запрос.
- Выбирайте маршрут по информационному пробелу; повышайте уровень инструмента только при сбое доступа.
- Объединяйте планирование и выполнение в одном цикле рассуждений.
- Переносите детерминированные шаги в вызовы инструментов, а не в субагенты.
- Ранжируйте источники по цели исследования, а не по единой оценке качества.
Читайте руководство по архитектуре, уроки глубокого исследования и документацию TinyFish.
Благодарим команду Tinyfish за экспертные материалы и ресурсы, использованные в этой статье. Эта статья спонсирована TinyFish.
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.