Архитектура State-of-the-Art Research Agent: философия и технические уроки от Tavily

Почему ваш research agent тупит, а Tavily — нет

Вы наверняка пробовали. Берёте GPT-4, даёте ему доступ к поиску, пишете промпт "Найди информацию о X и составь отчёт". Результат? Три ссылки из первой страницы выдачи, поверхностный анализ, куча галлюцинаций и счёт за токены, который хочется спрятать от бухгалтерии.

Tavily сделали иначе. Их агент не просто ищет. Он исследует. Глубоко, методично, с возвратами и перепроверками. Разница между "поисковым запросом" и "исследовательской сессией" — примерно как между гуглением симптомов и полноценным медицинским обследованием.

Agent Harness: философия упряжки, а не монолита

Забудьте про "умного агента". Вместо этого думайте о "умной упряжке" (harness). Разница фундаментальна.

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

Вот как это выглядит на практике:

• Planner — разбивает общую задачу на подзадачи
• Executor — выбирает конкретный инструмент для каждой подзадачи
• Critic — оценивает качество полученных результатов
• Synthesizer — объединяет информацию из разных источников
• Memory — хранит контекст всей исследовательской сессии

Каждый компонент может быть реализован по-разному. Planner — это одна LLM, Critic — другая (или та же, но с другим промптом). Executor — это код, который вызывает API поиска, базы данных, калькуляторы. Физически они разделены.

Управление контекстом: как не сжечь токены и не потерять нить

Research agent работает с огромными объёмами информации. Десятки веб-страниц, PDF-документы, таблицы данных. Если пытаться запихнуть всё это в контекст LLM, счёт за API достигнет космических величин. А качество анализа всё равно упадёт — модели плохо справляются с длинными контекстами.

Tavily решает это через многоуровневую систему фильтрации и компрессии:

1Извлечение релевантных фрагментов

Не загружаем всю страницу. Выделяем только абзацы, непосредственно относящиеся к запросу. Используем embedding-модели для семантического поиска внутри документа.

2Иерархическое суммирование

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

3Динамическое управление окном контекста

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

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

Если хотите глубже разобраться в оптимизации контекста, посмотрите мой разбор 4 техник оптимизации контекста для AI-кодинга — многие принципы применимы и к research агентам.

Оркестрация инструментов: когда поиска недостаточно

Наивный подход: дать агенту доступ к поисковику и считать, что он research-ready. Реальность сложнее.

Настоящий research agent использует целый арсенал инструментов:

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

Этот процесс хорошо описан в статье про Deep Research агенты, где сравниваются разные подходы к построению таких систем.

Устойчивость к обновлениям моделей: защита от регрессий

Вы построили идеального агента на GPT-4. Проработал месяц. OpenAI выпускает обновление — и всё ломается. Промпты, которые работали идеально, теперь дают странные результаты. Логика планирования сбоит. Бюджет на переобучение агента сравним с бюджетом небольшого стартапа.

Tavily столкнулись с этой проблемой раньше многих. Их решение — абстракция поверх LLM.

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

1. Стандартизированные интерфейсы для каждого типа задач (планирование, анализ, синтез)
2. Изоляция промптов в отдельные конфигурационные файлы
3. Система тестирования, которая проверяет каждый компонент при обновлении модели
4. Фолбэк-стратегии — если новая модель работает хуже на конкретном типе задач, система может использовать старую модель или альтернативный подход

Это похоже на то, как в традиционном софте вы абстрагируетесь от конкретной базы данных через ORM. Меняете PostgreSQL на MySQL — бизнес-логика остаётся неизменной.

Здесь та же философия: меняете GPT-4 на Claude 3 — система продолжает работать, потому что зависит от интерфейсов, а не от конкретной реализации.

О том, как упаковывать знания для агентов так, чтобы они переживали смену моделей, я подробно писал в статье про Agent Skills.

Синтез информации: от сырых данных к инсайтам

Самый сложный этап. Агент собрал 50 источников, выделил ключевые факты, проверил противоречия. Теперь нужно превратить это в связный отчёт, а не в список цитат.

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

Хороший подход (как у Tavily): многоэтапный синтез с постепенным углублением.

1Тематическая группировка

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

2Выявление паттернов и противоречий

Анализирует, как информация соотносится между группами. "Во всех источниках говорится X, кроме трёх, которые утверждают Y. Эти три источника — от конкурентов, поэтому возможна предвзятость."

3Построение нарратива

Превращает факты в историю. Не "компания A сделала X, компания B сделала Y", а "индустрия движется от X к Y, потому что... Компания A лидирует в этом переходе, но сталкивается с проблемами Z".

4Генерация инсайтов

Самое ценное. Не просто пересказ информации, а выводы, которые не очевидны при поверхностном чтении. "Хотя все говорят о технологии A, наши данные показывают, что настоящий прорыв произойдёт в смежной области B, которую пока игнорируют крупные игроки."

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

Ошибки, которые гарантированно сломают вашего research agent

За годы работы с агентскими системами я видел одни и те же ошибки снова и снова. Вот топ-5 способов угробить research agent:

• Доверять модели оценку качества её же работы. Это как просить студента самому поставить себе оценку за экзамен. Нужен отдельный компонент-критик, желательно на другой модели или с другими промптами.
• Использовать одну модель для всего. Планирование, исполнение, анализ, синтез — разные когнитивные задачи. Одна модель не может одинаково хорошо выполнять их все. Разделяйте ответственность.
• Экономить на тестировании источников. Дать агенту доступ к непроверенным сайтам — всё равно что нанять исследователя, который использует Википедию как единственный источник. Введите систему рейтингов источников, чёрные списки, перекрёстные проверки.
• Игнорировать проблему бесконечных циклов. Агент нашёл противоречивые данные → пошёл искать clarification → нашёл ещё больше противоречий → пошёл уточнять... И так до исчерпания бюджета или таймаута. Обязательно добавляйте лимиты на итерации и механизмы выхода из тупиков.
• Не вести лог принятия решений. Когда агент выдаёт странный результат, вы должны иметь возможность восстановить цепочку: какой запрос → какие источники → какой анализ → какой вывод. Без этого дебаггинг превращается в гадание на кофейной гуще.

Многие из этих ошибок происходят из-за фундаментального непонимания того, как LLM принимают решения. Если интересно, в статье LLM понимают цель, но игнорируют её я разбираю этот парадокс подробно.

Что дальше? Будущее research agents

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

Специализация агентов. Универсальный research agent умрёт. Появятся медицинские research agents (с доступом к PubMed и клиническим руководствам), юридические (с аналитикой судебных решений), финансовые (с реальным доступом к Bloomberg и Reuters).

Глубокая интеграция с enterprise-системами. Агент будет не только искать в интернете, но и анализировать внутренние документы компании, данные из CRM, переписку, отчёты. Это потребует решения проблем безопасности и конфиденциальности.

Мультимодальные исследования. Сегодня research agent работает в основном с текстом. Завтра он будет анализировать графики из отчётов, скриншоты интерфейсов, видео-презентации. Проблема поиска иголки в стоге визуальных данных станет критически важной.

Коллаборация агентов. Один агент проводит исследование, второй проверяет его выводы, третий ищет опровергающие доказательства, четвёртый синтезирует финальный отчёт. Как правильно организовать такую коллаборацию — отдельная большая тема, которую я затрагивал в статье про эффективность команд ИИ-агентов.

Самое важное: архитектура research agent — это не про то, какую модель выбрать. Это про то, как организовать процесс исследования. Модели будут меняться, API — обновляться, цены — колебаться. Но принципы останутся: разделение ответственности, управление контекстом, оркестрация инструментов, критическое мышление.

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

И последний совет: если ваш research agent никогда не говорит "я не знаю" или "данных недостаточно для вывода" — вы построили его неправильно. Уверенность при отсутствии оснований — самый опасный баг в исследовательской системе.