Российские разработчики предложили новую архитектуру для RAG-систем - и подкрепили её экспериментами
Команда R&D-лаборатории red_mad_robot опубликовала на arXiv исследование с архитектурным подходом DCD - трёхуровневой системой организации знаний для RAG-пайплайнов. Главный тезис прост: поиск работает лучше, когда он заранее знает, где искать.
Что не так с классическими RAG-системами
Стандартные RAG-пайплайны давно стали рабочей лошадкой корпоративного ИИ. Но у них есть фундаментальная слабость. Когда документы из разных предметных областей свалены в одно поисковое пространство, одного сходства эмбеддингов не хватает: отдельные фрагменты кажутся релевантными, но вместе не складываются в связный ответ. Особенно больно это ощущается на многошаговых запросах и неоднородных корпусах. Иордания - Аргентина эфир
Именно из этой боли вырос DCD. Не как очередная надстройка поверх языковой модели, а как переосмысление самой структуры хранения и навигации по знаниям.
Три уровня вместо плоского списка
Архитектура DCD делит базу знаний на три слоя: Domain, Collection и Document. Домен задаёт верхнюю границу поиска - семантически изолированную предметную область. Коллекция дробит её на более узкие тематические кластеры: например, юридические документы, справочные материалы или пользовательские FAQ. Документ - базовая единица, которая уже режется на чанки.
Поиск всегда идёт сверху вниз: сначала выбирается домен, потом коллекция, затем конкретный фрагмент. Этим занимается DCD Router - модуль, который через структурированные ответы языковой модели последовательно сужает пространство поиска ещё до того, как начнётся само извлечение. Если модель ошибается на каком-то уровне, система не падает - включаются резервные элементы.
Чанкинг при этом не просто механический: скользящее окно с перекрытием сохраняет локальную связность текста, а каждый фрагмент получает метаданные о своём положении в иерархии. Так поиск опирается не только на семантику, но и на структуру.
Эксперимент и результаты
Авторы проверили гипотезу на синтетическом корпусе, построенном по данным реального клиента из сферы девелопмента - с заменой всех чувствительных данных. В качестве соперников выступили Naive RAG, Naive RAG с реранкером, Contextual RAG и RAPTOR. Генерацию во всех конфигурациях вёл Qwen3.6, оценку качества - GPT-oss-120b в роли судьи.
Результат подтвердил центральную идею: явная иерархия и предварительная маршрутизация повышают фактическую точность ответов без усложнения самой языковой модели. При этом DCD дешевле на этапе индексации, чем Contextual RAG или RAPTOR, - потому что не гоняет LLM через каждый чанк.
- Поиск ограничивается семантически однородным пространством до начала извлечения
- Fast Guardrails проверяют первые 150 токенов параллельно с генерацией - без заметной задержки
- Меньше вычислений на индексацию по сравнению с аналогами
- Датасет и код открыты: Hugging Face и GitHub
Ограничения и честный взгляд
Авторы не скрывают подводных камней. Чем больше растёт база знаний, тем сложнее удерживать чёткие границы между доменами - особенно если соседние области используют похожую терминологию. В эксперименте применялась упрощённая конфигурация без маршрутизации на уровне документа, а сам корпус был достаточно структурированным. В условиях полного хаоса из несвязанных документов преимущества DCD сходят на нет.
Тем не менее подход занимает чёткую нишу: корпоративные базы знаний с хотя бы минимальной структурой, где семантические границы можно определить заранее. Для таких сценариев грамотная организация пространства знаний оказывается эффективнее, чем усложнение агентных цепочек или добавление лишних циклов рассуждений. Это не универсальный рецепт - но вполне рабочий инструмент там, где он нужен.
