Написано в соавторстве с @bear7

Deep Research часто описывают как «LLM с интернет-поиском». Однако если система просто делает несколько поисковых запросов, читает часть выдачи и пишет ответ, то она упускает несколько важных аспектов, без которых невозможно полноценное исследование.

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

В этой статье мы расскажем о том, как решили задачу построения системы B2C Deep Research на основе Instruct-модели (GigaChat Ultra 3.1), в которой модель выполняет специфицированные задачи, а логика исследования реализована с помощью конвейера из набора ролей, условий завершения, циклов поиска и постепенного накопления контекста, подкреплённого цитатами. Так Deep Research становится не просто набором промптов с доступом к источникам в интернете, а управляемым исследовательским контуром.

Почему недостаточно обычного LLM и веб-поиска?

Обычный LLM-ответ без внешнего поиска хорошо работает там, где достаточно общего знания модели. Но для исследовательских запросов этого мало: факты могут устареть, подробности могут быть спорными, а пользователь часто просит не «объясни тему», а «найди, сравни, проверь и сделай вывод».

Простая связка LLM + веб-поиск добавляет источники, но сама по себе не решает исследовательскую задачу. Она часто работает как одношаговая схема:

1. Сформировать несколько поисковых запросов.

2. Прочитать часть результатов.

3. Сразу написать итоговый ответ.

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

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

Качественный Deep Research должен:

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

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

• фиксировать, какие части задачи закрыты, а какие остались открытыми;

• различать факты, интерпретации, противоречия и ограничения;

• переносить результаты между стадиями без потери контекста;

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

Карта подходов

Многие Deep Research-системы опираются на сильную reasoning-модель, которая сама планирует исследование и пишет ответ. Мы пошли другим путём: сделали исследование явным процессом — узкие роли, проверяемые DoD, конвейер со стадиями, памятью и финальной сборкой. Модель рассуждает локально, а сходимость и воспроизводимость обеспечивает контур, а не один длинный агентный промпт.

Чтобы правильно позиционировать систему, полезно сравнивать не отдельные продукты, а классы архитектур.

Таблица демонстрирует сравнение подходов, а не конкретные реализации. Глубокое исследование на основе многоагентных рассуждений хорошо заметно в OpenAI Deep Research, Gemini Deep Research и Perplexity Deep Research. Направление Open source представлено проектами вроде Open Deep Research и GPT Researcher. Отдельно стоит отметить STORM-like, где акцент сделан на подготовке структуры и написании объёмных текстов, подкреплённых источниками, а не только на поиске ответа.

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

Такая структура особенно важна для B2C: пользовательские вопросы слишком разные, чтобы закрывать их одним шаблоном. Но при работе с instruct-моделью слишком рискованно отдавать весь процесс свободному агенту без контроля.

Как мы пришли к этой архитектуре

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

Прямой перенос идей reasoning-first не сработал: при слишком свободном агенте растёт дрейф — неверный следующий шаг, повторы поиска, преждевременные выводы.

Главный вывод был таким:

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

Отсюда родилась архитектура с несколькими принципами:

• Изначально составляем общий план, чтобы задать предсказуемую траекторию.

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

• ReAct используем локально, внутри одного критерия готовности, не допуская дрейфа темы.

• Результаты каждой локальной задачи фиксируем в отчёте.

• Контекст переносим слоями, а не одним растущим промптом.

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

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

Общая схема конвейера

Верхнеуровнево система проходит такой путь:

User request
→ Brief
→ Scout
→ Needs + DoD plan
→ Research loop по каждому DoD
→ DoD Reports
→ Need Report / Need Transfer
→ Answer Planner
→ Section Writers
→ Final Answer

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

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

Brief: понимание исходной задачи

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

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

На стадии Brief важно сохранить:

• сущности, даты, географию и ограничения;

• тип ожидаемого результата;

• уровень детализации;

• язык финального ответа;

• негативные условия вроде «не учитывать», «только после», «исключая».

Задача Brief — сделать так, чтобы все следующие стадии решали именно исходную задачу.

Scout: разведка перед составлением плана

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

Scout помогает ориентироваться в теме, но не должен становиться самостоятельным исследованием или подменять собой будущий план.

Needs и DoD: проверяемый план исследования

После Brief и Scout система строит список крупных исследовательских потребностей, то есть смысловых блоков, которые надо закрыть, чтобы ответить пользователю.

Например, для запроса:

«Сравни Kubernetes, Docker Swarm и Nomad для стартапа из 5 человек»

план может содержать такие потребности:

• архитектура и сложность эксплуатации;

• масштабирование и надёжность;

• экосистема и готовность к эксплуатации;

• практическая рекомендация для маленькой команды.

Но одного лишь уровня потребностей мало. Формулировка «изучить архитектуру и эксплуатацию» всё ещё слишком широкая. Поэтому внутри каждой потребности создаются проверяемые условия завершения (DoD, Definition of Done).

Для первой потребности это может выглядеть так:

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

Локальный ReAct-loop

Каждое условие завершения выполняется через локальный ReAct-loop. Это место, где в системе всё ещё есть агентность, но она ограничена конкретной подзадачей.

Внутри одного условия завершения цикл выглядит так:

Текущий DoD
→ Planner
→ Tools
→ Extractor
→ Analyzer / Reflector
→ Validator
→ Continue или Stop
→ DoD Report

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

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

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

Analyzer или Reflector оценивает, что изменилось. Появился ли новый факт? Это подтверждение уже известного или реальное продвижение? Есть ли противоречие? Какой пробел остаётся главным?

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

Благодаря таким рамкам ReAct становится управляемым локальным механизмом исследования.

Почему роли разделены

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

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

Контекст как серия переносимых состояний

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

Поэтому контекст в системе устроен слоями.

DoD Trace хранит живую память текущего локального цикла: что уже пробовали, что нашли, что не сработало, какие сигналы появились.

DoD Report фиксирует итог одного завершённого условия: найденные факты, выводы, ограничения, открытые вопросы и цитирования.

Need Report собирает результаты всех условий завершения внутри одной потребности.

Need Transfer создаёт компактный артефакт для передачи: что уже установлено, как это влияет на последующие шаги, что осталось неясным и что нельзя забыть. Конвейер сохраняет Need Transfer как артефакт и подмешивает в промпт следующих вызовов модели — как в цикле исследования (следующие потребности и локальные DoD-циклы: planner, extractor, validator и др.), так и в конвейере для сборки ответа (Answer Planner, Section Writer). Сырая трассировка и полный Need Report в промпты не включаются — только сжатый блок. Накопленные артефакты для передачи образуют Need Trace.

Контекст для финальной сборки ответа строится в основном из всех Need Transfer-ов и при необходимости из отдельных DoD Report-ов.

Так система живёт не в одном неконтролируемо растущем контексте, а переносит состояние через специализированные слои памяти. Каждый слой отвечает за свой уровень детализации.

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

Цитирования как важная часть текста

Одна из скрытых проблем глубокого исследования — перенос источников. Ценный факт появляется в Extractor, затем попадает в DoD Report, потом в Need Transfer, потом в контекст для сборки финального ответа и в результате — в итоговый отчёт. Если источник живёт отдельно от текста, связь «утверждение — источник» легко теряется.

Поэтому цитирования живут прямо рядом с фактом в компактном техническом формате:

Kubernetes требует более высокой операционной зрелости для production-среды [@A12#3].

Здесь технически важны artifact_id и, если нужно, индекс элемента внутри артефакта. Человекочитаемое оформление источника делается позже, на уровне интерфейса с пользователем.

Такой подход даёт несколько преимуществ:

• факт и источник проходят через конвейер вместе;

• модель не должна помнить полный URL или объект источника;

• цитирования можно переносить через промежуточные отчёты и артефакты;

• финальный слой может восстановить ссылки уже после написания ответа;

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

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

Отдельный конвейер для сборки финального ответа

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

Поэтому конвейер подготовки ответа отделён от конвейера самого исследования.

После завершения исследования система не пишет ответ напрямую из сырых Need Report-ов. Сначала конвейер подготовки ответа выбирает материал, который действительно соответствует запросу пользователя. Затем Answer Planner строит план ответа: какие секции нужны, в каком порядке раскрывать аргументы, где дать прямой вывод, где пояснить ограничения.

После этого Section Writer пишет ответ по частям. Это снижает риск, что большой документ развалится в одном длинном вызове модели. При этом каждая секция опирается на уже подготовленный на этапе исследования контекст с цитированиями, а не на свободное знание модели.

Главный принцип:

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

Сквозной пример

Возьмём запрос:

Сравни Kubernetes, Docker Swarm и Nomad для стартапа из 5 человек.

Brief

Система фиксирует:

• пользователь хочет практическое сравнение, а не абстрактный обзор оркестраторов;

• важен контекст маленькой команды;

• нужно учитывать сложность эксплуатации, готовность к эксплуатации, поддержку, риски и итоговую рекомендацию;

• ответ должен быть структурированным и применимым для выбора.

Needs

План исследования может выглядеть так:

Условие завершения внутри первой потребности

Одна итерация исследования

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

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

Kubernetes даёт наиболее богатую экосистему, но требует больше операционной настройки и понимания control plane, networking и storage [@A12#2]. Docker Swarm проще запустить для маленькой команды, но имеет более ограниченную экосистему и меньше современных production-практик [@A15]. Nomad проще по архитектуре, но требует отдельной оценки HashiCorp-стека и интеграций [@A18#4].

Отчёт об условиях завершения

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

DoD: оценить сложность начальной настройки.

Status: CLOSED.

Finding: Kubernetes наиболее функционален, но требует больше операционной зрелости. Docker Swarm проще для старта, но слабее как долгосрочный продакшн-контур. Nomad занимает промежуточную позицию: проще ядро, но важны интеграции и стек вокруг него.

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

Citations: [@A12#2], [@A15], [@A18#4].

Перенос потребностей

После завершения всей потребности в следующий слой уходит не вся трассировка, а переносимый итог:

Для маленькой команды эксплуатационная сложность становится ключевым фактором. Kubernetes может быть избыточен без managed-платформы или сильной DevOps-компетенции. Docker Swarm проще, но потенциально ограничивает развитие. Nomad требует отдельной проверки на совместимость с экосистемой.

Этот блок попадёт в контекст следующих потребностей (например, при сравнении экосистем) и позже — в конвейер сборки финального ответа.

Финальный ответ

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

1. Короткий вывод.

2. Таблица сравнения.

3. Риски для маленькой команды.

4. Когда выбирать Kubernetes, Docker Swarm или Nomad.

5. Итоговая рекомендация.

Так внутренний план остаётся инструментом исследования, а финальный ответ становится удобным пользовательским отчётом.

Защиты от типичных поломок

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

Защита от потери вопроса

Brief сохраняет исходные ограничения, а Answer Planner возвращает финальный ответ на пользовательскую задачу. Это снижает риск, что система проведёт исследование на похожую, но другую тему.

Защита от свободного дрейфа

План потребностей и условий завершения задаёт каркас исследования. Модель может адаптироваться внутри условия, но не должна каждый раз заново изобретать весь план.

Защита от повторов и стагнации

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

Защита от потери контекста

Трассировка, промежуточные отчёты и артефакты для передачи позволяют переносить результаты, а не полный сырой архив. Это снижает риски снижения качества из-за разрастающегося промпта и локализует потери информации.

Защита от отрыва фактов от источников

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

Защита от слабой финальной подачи

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

Результаты

Мы проверяли архитектуру на двух типах бенчмарков:

• SEAL-Hard проверяет точность многошагового фактологического поиска. В этом бенчмарке важно добраться до конкретного ответа и не потерять условия вопроса.

• Deep Research Bench (RACE) ближе к длинным исследовательским пользовательским запросам. Он проверяет не только точность отдельного факта, но и способность собрать развёрнутый ответ.

Основное сравнение: насколько новый контур на GigaChat Ultra 3.1 превосходит baseline. Для проверки, как влияет выбор другой сильной модели на качество исследования, запустили тот же конвейер на GPT-4.1 как внешний instruct-ориентир.

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

Вывод: новый исследовательский конвейер сильно поднял качество по сравнению со старым baseline. Сравнение одного и того же конвейера на Ultra 3.1 и на GPT-4.1 подтверждает, что архитектура и перенос контекста дают видимый эффект даже на фоне сильных instruct-моделей.

Интерпретация результатов

Важно обозначить границы результата.

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

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

Также нельзя утверждать, что качество растёт только за счёт алгоритма проведения исследования. Нужно учитывать и другие факторы: качество поиска, отбор источников, фильтрацию SEO-мусора, актуальность данных, противоречия в интернете, стоимость и длительность глубокого исследования.

Что показывают результаты:

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

• Фиксация логики исследовательского контура позволила существенно улучшить качество.

• Разделение ролей, условия завершения, отчёты, передачи артефактов и выделение конвейера сборки финального ответа дали требуемый практический эффект.

• Глубокое исследование с подходом instruct-first имеет смысл строить как конвейер, а не как один большой агентный промпт.

Почему этот подход полезен и дальше

Более сильная модель улучшит отдельные роли, но ей всё равно нужны постановка задачи, проверяемые условия завершения, работа с цитированиями, передача артефактов между этапами и отдельный конвейер сборки ответа. Подходящий конвейер компенсирует особенности instruct-модели и делает исследование наблюдаемым. Сильная модель с неподходящим подходом к исследованию может потерять источник или уйти от вопроса.

Ограничения и следующие шаги

У системы остаются понятные направления развития.

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

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

Третье направление — сжатие и передача контекста. Чем длиннее исследование, тем важнее не потерять ранние факты, противоречия и цитирования при переходе между DoD Trace, DoD Report, Need Transfer и набором материалов для сборки финального ответа.

Четвёртое направление — обучение модели на собственных траекториях. Поскольку конвейер уже умеет журналировать входы и выходы стадий, можно собирать данные для улучшения локальных ролей: planner, extractor, validator, section writer.

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