7 мин

0

Привет! Это Роботы.
Недавно мы выпустили статью на arXiv, где представили архитектурный подход DCD (Domain–Collection–Document) для структурирования пространства знаний и обработки запросов в RAG-системах. Мы провели подробные эксперименты, оценили работу подхода на собственном бенчмарке и показали, как он влияет на качество поиска и генерации в сравнении с другими подобными методами. А теперь хотим здесь рассказать о ключевых идеях, лежащих в основе DCD Design.

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

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

Ключевая идея метода

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

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

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

Каждый уровень выполняет свою задачу:

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

• Collection — более узкая тематическая область внутри домена дополнительно ограничивает пространство поиска. Например, внутри одного домена это могут быть юридические документы, справочные материалы или пользовательские FAQ.

• Document — базовая единица хранения знаний. Тут документы разбиваются на чанки для последующего поиска.

Поиск всегда выполняется сверху вниз: Domain → Collection → Document.

DCD Router

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

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

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

Умный чанкинг

Важная часть архитектуры DCD — механизм умного чанкинга. Документы разбиваются на чанки с помощью скользящего окна с перекрытием соседних фрагментов. Такой способ сегментации сохраняет локальную семантическую связность текста и снижает вероятность того, что важная информация окажется потеряна на границах чанков. Благодаря этому логически связанные фрагменты, занимающие несколько предложений или абзацев, остаются доступными во время поиска. Это особенно важно для сложных запросов, где ответ приходится собирать из нескольких частей документа.

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

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

Fast Guardrails

Помимо основного пайплайна поиска и генерации, DCD включает механизм Fast Guardrails для ранней проверки ответа. Он объединяет guardrails, защиту от галлюцинаций и быстрый предварительный анализ ответа ещё до завершения генерации.

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

• пользовательский запрос проходит проверку по словарю запрещённых слов;

• допустимые запросы передаются в DCD-пайплайн;

• во время потоковой генерации анализируются первые 150 токенов ответа;

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

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

Эмпирическая проверка гипотезы 

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

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

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

В качестве базовых методов мы использовали Naive RAG, Naive RAG + Reranker, Contextual RAG и RAPTOR. Для DCD дополнительно оценивались конфигурации с reranker и контекстным индексом.

Эксперимент включал генерацию синтетического корпуса, построение векторных индексов, запуск всех сравниваемых пайплайнов и оценку качества поиска и генерации. Во всех конфигурациях итоговый ответ генерировала одна и та же модель — Qwen3.6 с температурой 0. В качестве LLM-as-a-Judge использовалась GPT-oss-120b.

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

Подробные результаты экспериментов, математическое описание метрик и полное сравнение с Contextual RAG, RAPTOR и другими подходами смотрите в статье на arXiv.

Ограничения DCD

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

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

Во-вторых, в нашей работе использовалась упрощённая конфигурация DCD. Маршрутизация выполнялась только на уровнях Domain и Collection, без отдельного выбора документа. Такой вариант сохраняет основную идею иерархического ограничения пространства поиска, но уменьшает вычислительные затраты и упрощает экспериментальную постановку. Поэтому полученные результаты стоит рассматривать именно в контексте этой конфигурации.

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

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

Выводы

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

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

Если захотите подробнее изучить реализацию или повторить эксперименты, мы открыли исходные материалы проекта. Датасет доступен на Hugging Face, а код — на GitHub. Оба репозитория поддерживает лаборатория R&D red_mad_robot.

Над материалом работали

Авторы — Валера Ковальский, Никита Белов, Никита Митейко, Игорь Решетников, Максим Максимов;

Иллюстрации — Саша Буяк, Юля Ефимова.