Когда 3B-модель строит завод: DCD и иерархическая декомпозиция убирают необходимость в большой модели

Когда 3B-модель строит завод: как DCD и иерархическая декомпозиция убирают необходимость в большой модели

Допустим, ты хочешь написать систему, которая проектирует заводы. Не через "умного ИИ-архитектора", а через цепочку прорабов, инженеров и подсобных рабочих, каждый из которых получает ровно ту инструкцию, которую способен понять. Плохая новость: ни одна модель на 3 миллиарда параметров не способна сама разбить "построй завод" на 300 шагов со сроками, материалами и ГОСТами. Хорошая новость: и не нужно. Твоя инструкция уже существует, она называется "строительство промзданий". Её только нужно найти и выдать каждому исполнителю.

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

DCD: Не агент, а архитектура знаний

В апреле 2026 года команда red_mad_robot опубликовала исследование под названием "DCD: Domain-Oriented Design for Controlled Retrieval-Augmented Generation". Суть подхода: вместо того чтобы усложнять агентскую оркестрацию, структурируют сами знания. Не на лету, а заранее.

DCD строит трёхуровневую иерархию: домен (например, "Жилищное строительство"), коллекция (фундаменты, кровля, электрика), документ (конкретная инструкция по бетонированию). Когда приходит запрос, роутер, небольшая модель с структурированным выводом, последовательно выбирает домен, коллекцию, документ. Только из этого документа извлекаются фрагменты для генерации ответа.

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

Как это связано с маленькими моделями и декомпозицией

Вот что говорит практика и бенчмарки:

Модели на 3 миллиарда параметров (Qwen 2.5-3B, Gemma 3n) уверенно выполняют один инструмент с простой схемой. Два инструментальных вызова подряд - уже провал в 70% случаев. Самостоятельная декомпозиция задачи невозможна.

Но если модели дать готовую инструкцию из правильного домена, точность поднимается до 90%. Это подтверждается как BFCL-бенчмарком, так и исследованиями Task-Decomposable Agents, где большая модель декомпозирует, а малая исполняет - успех на 40% выше, чем при zero-shot.

Архитектура получается двухслойной: декомпозиционный слой (большой планировщик или RAG) и исполнительский (малая модель с жёсткой инструкцией). DCD решает именно первый слой - где взять инструкцию, как её найти, как не перепутать домен.

Формула: ГИП → Архитектор → Прораб → Рабочий

Представь систему из четырёх уровней. Пользователь даёт задачу типа "построй завод по производству окон". Первый уровень - ГИП (модель на 70 миллиардов параметров с доступом ко всем инструкциям предприятия). Он не проектирует сам, он обращается к RAG, находит домен "Строительство промзданий", коллекцию "Проектирование", документ "Типовой проект завода по производству ПВХ-окон".

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

Архитектор каждого направления получает релевантный контекст - типовые решения, нормативы, ограничения участка. Его модель уже может быть поменьше: 7 миллиардов параметров достаточно для комбинации типовых блоков по заданным правилам.

Прораб получает ещё более простую инструкцию: "залей бетон марки М300 в секции A1-A5, срок - 3 дня, бюджет - 450 тыс. руб." Для этого достаточно модели на 3 миллиарда параметров, если у неё есть RAG-контекст про бетонирование и чёткий шаблон ответа.

Рабочий ещё ниже: ему не нужна LLM вообще, достаточно cron-скрипта, который отправляет уведомление о начале работ и проверяет отчёт о завершении.

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

Что нужно для реализации в вашем проекте

Если у вас уже есть система типа Hermes Agent с delegate_task и kanban, то вам не нужно изобретать агентскую оркестрацию. Нужно построить DCD-слой над вашими документами.

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

Второй шаг: коллекции внутри домена. Для разработки это может быть: API-контракты, схемы данных, CI/CD-пайплайны, код-ревью чек-листы. Для DevOps: диагностические процедуры, планы откатов, инцидент-менеджмент.

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

Четвёртый шаг: роутер на предопределённых классах. Не генеративный, а классификационный. Структурированный вывод с ограниченным набором допустимых значений. Модель на 3 миллиарда параметров справляется с этим отлично, это буквально выбор из 5-10 опций.

Почему это работает, а большой модели не нужно

Цифры из исследования DCD: factual accuracy 0.965 против 0.823 у Contextual RAG. Разница в 14 процентных пунктов в пользу иерархической маршрутизации. При этом стоимость - один классификационный вызов вместо O(N) обогащений каждого чанка.

Цифры из BFCL: Qwen 2.5-3B делает один инструмент с 60% точностью. С констрейнтом на выход (предопределённая схема JSON) - до 92-95%. Модель не "соображает", она выбирает правильный параметр из предложенных. Это и есть DCD-паттерн на уровне исполнения.

Самое важное: модель не должна знать, "как строить завод". Она должна знать, "где найти документ про строительство заводов" и "как следовать инструкции из этого документа". Вся экспертиза - в корпусе, а не в параметрах.

Как начать с чего прямо сейчас

Если у вас есть LLM Wiki или RAG-индекс с документацией - попробуйте простейший DCD-паттерн. Выберите три-пять доменов. Для каждого напишите по одному документу, который является точкой входа (инструкция "как мы делаем X"). Когда придёт вопрос - не ищите по всему корпусу. Сначала определите домен, потом извлеките документ только оттуда.

Второй шаг: попробуйте заменить "думающего" агента на двухуровневый. Пусть один модуль определит, к какому домену относится задача (3B, 50 мс). Второй моделью на 7 миллиардов параметров сгенерируете план уже внутри этого домена. Третий уровень (снова 3B) будет исполнять каждый конкретный шаг с готовой инструкцией из DCD.

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

Интуиция простая: интеллект системы - это не сумма интеллектов моделей. Это качество маршрутизации между правильно структурированными знаниями. Опытный инженер отличается от начинающего не тем, что он "умнее", а тем, что он знает, где найти нужную инструкцию и как ей следовать.

И маленькая модель, которая знает, где искать, ценнее большой модели, которая не знает, что ей делать.