Архитектуры RAG

Короткая версия

Условно современные RAG-архитектуры можно расположить так:

Задача: внутренний help center на 5 000 статей, короткие одношаговые вопросы, нужен быстрый SLA.

Как выбирать

• если вопросы короткие и повторяющиеся, начните с 2-step;
• если retrieval пропускает важные документы, добавьте hybrid, multi-query, reranking;
• если качество retrieval плавает, нужен corrective слой;
• если задача реально multi-step, тогда уже agentic;
• если пользователи спрашивают про связи и общие картины по большому корпусу, смотрите в сторону GraphRAG.

1. 2-step RAG остаётся основным baseline

Базовая схема всё ещё выглядит так:

user question
-> retrieval
-> prompt/context assembly
-> grounded answer

Эта архитектура до сих пор хороша, потому что:

• предсказуема;
• дёшева в отладке;
• легко оценивается;
• почти всегда достаточна для FAQ, documentation QA и support copilot.

Важно только не путать “простая” с “примитивная”. Хороший 2-step RAG в 2026 уже обычно включает:

• metadata filters;
• нормальный chunking;
• top-k discipline;
• answer policy с no-answer;
• иногда hosted file_search или vector_store.

2. Retrieval-enhanced RAG — это уже practical default

Следующий слой сложности не в оркестрации, а в улучшении retrieval stage.

Сюда входят:

• hybrid search;
• query rewriting;
• multi-query retrieval;
• reranking;
• context compression;
• weighted fusion.

Именно этот слой чаще всего даёт наибольший прирост качества без полного перехода в agentic architecture.

3. Corrective и adaptive architectures нужны, когда retrieval нестабилен

Не все корпуса одинаково чистые. Иногда:

• часть документов устарела;
• query formulation пользователя слабая;
• индекс даёт шум;
• ответа в базе вообще нет.

Тогда полезны corrective patterns:

• оценка retrieved docs;
• fallback на другой retriever;
• query rewrite;
• escalation на web search или другой knowledge source;
• честный I don't know.

Такие архитектуры полезнее понимать как retrieval governance, а не как “магический новый тип RAG”.

4. Agentic RAG — не upgrade для всех

Agentic RAG добавляет оркестрацию:

• решает, нужен ли retrieval вообще;
• выбирает источник;
• может делать несколько шагов поиска;
• вызывает tools;
• проверяет, достаточно ли данных.

Это имеет смысл, когда вопрос:

• составной;
• требует plan-and-search;
• комбинирует несколько источников;
• не укладывается в одно retrieval действие.

Но для обычного FAQ agentic path часто только:

• увеличивает latency;
• поднимает cost;
• усложняет eval и debug.

5. Graph-oriented architectures решают другой класс вопросов

GraphRAG и соседние graph-based retrieval patterns полезны не потому, что “графы моднее”, а потому что они лучше отвечают на вопросы:

• про связи между сущностями;
• про общие темы в большом корпусе;
• про cross-document synthesis;
• про общие тренды, а не один фрагмент текста.

Такие архитектуры дороже в индексации и сложнее в support, поэтому оправданы только если users действительно задают synthesis-heavy questions.

6. Hosted retrieval — уже полноценный архитектурный выбор

В 2026 RAG уже не всегда означает самодельные embeddings + self-managed vector DB.

Есть hosted paths:

• vector stores;
• file_search;
• managed retrieval inside provider APIs;
• integrated metadata filtering and citations.

Это меняет архитектурный выбор:

• custom path даёт контроль;
• hosted path даёт скорость запуска и меньше infra.

Поэтому “архитектура RAG” теперь включает и степень контроля над retrieval internals.

7. Полезная practical taxonomy

Вместо “naive / advanced / modular” полезнее думать так:

8. Как выбирать архитектуру по порядку

Здоровый порядок обычно такой:

1. сделать 2-step baseline;
2. измерить retrieval и answer quality;
3. добавить hybrid/rerank/multi-query, если baseline слаб;
4. только потом рассматривать corrective или agentic;
5. идти в GraphRAG только если появились corpus-level synthesis questions.

Именно так архитектурный выбор остаётся инженерным, а не декоративным.

Минимальная decision схема

single-step docs QA?
-> yes -> 2-step RAG
   -> retrieval weak? add hybrid + reranking

retrieval unreliable or answer often missing?
-> add corrective/adaptive layer

query needs multiple sources / planning / tools?
-> consider agentic RAG

query asks for themes, relationships, corpus synthesis?
-> consider GraphRAG

need fastest launch with less infra?
-> consider hosted file_search / vector_store path

Архитектурный upgrade стоит делать только если его можно обосновать через конкретный failure mode:

• low recall;
• noisy context;
• missing answers;
• cross-source tasks;
• overview questions.