
Если мы говорим про AI, говорим и про галлюцинации. Эти два понятия, к сожалению, стали неразрывны. И главная задача в 2026 не просто внедрить AI, чтобы потом всем рассказывать о своих успехах и как затраты сократились на 900%. Главная задача – сделать так, чтобы AI не врал. А врать он любит. Он буквально патологический врун! Но его можно понять, ведь наш друг боится показаться несведущим. И если он чего-то не знает о чем его спрашивают, он с высокой долей вероятности начинает привирать.
Давайте разберемся, как сделать так, чтобы AI не врал. И кратко рассмотрим аж 9 способов, а точнее 9 видов архитектур RAG.
Эта статья написана простым языком для простых граждан. Если хотите настоящее погружение в сложный мир ИИ, то на Хабре есть отличная техническая статья (которая мне далась сложно, буду честен).
Что такое RAG?
Прежде, чем начать говорить о каких-то там архитектурах и высших материях, сначала поговорим, что такое RAG в принципе. Да, я понимаю, что вы, конечно же, знаете, что это такое, но повторим мат часть еще раз.
RAG или Retrieval-Augmented Generation предназначен, чтобы ИИ сначала искал нужную информацию, так скажем, в базе знаний, и только потом формировал свой ответ того, что нашел. Естественно, эта «база знаний для AI» должна быть где-то ранее сохранена и структурирована, чтобы AI мог эффективно с ней работать.
Модель не опирается на те данные, которые были использованы при ее обучении, а только на ту информацию, которую ей удалось найти в «базе знаний».

Вот как организовать взаимодействие AI с этой «базой знаний» мы и будем говорить в этой статье.
1. Стандартный RAG

Самый простой способ и самый менее замороченный.
Механизм ровно такой, как было описано при объяснении, что такое RAG в принципе. Ничего более.
Стоит заметить, что лучше использовать этот способ в тех задач, где цена ошибки не сильно велика. Когда вам важнее скорость внедрения и самой работы, а не точность.
Как это работает?
Chunking: документы разбиваются на небольшие, удобные для обработки текстовые фрагменты.
Embedding: каждый фрагмент преобразуется в вектор и сохраняется в базе данных (например, Qdrant, ChromaDB или PostgreSQL через pgvector).
Retrieval: пользовательский запрос также переводится в вектор, после чего извлекаются
· Top-K наиболее похожих фрагментов по косинусному сходству.
· Generation: эти фрагменты передаются LLM как «контекст», на основе которого формируется обоснованный ответ.
Плюсы
задержка меньше секунды;
очень низкая вычислительная стоимость;
простота отладки и мониторинга.
Минусы
высокая чувствительность к «шуму» (может извлекать нерелевантные фрагменты);
не справляется со сложными составными вопросами;
не умеет исправлять себя, если извлечённые данные оказались неверными.
2. Conversational RAG — добавляем памяти

Простыми словами – добавляем контекст нашего общения. Вот пользователь задает вопрос: «Сколько это стоит?». А что «это»? То есть нам нужен контекст, о чем мы говорили ранее.
В данной архитектуре мы как раз добавляем эту самую память нашему AI. Чтобы общение с ним не было похоже на общение с больным деменцией.
Как это работает
1. Загрузка контекста: система хранит последние 5–10 ходов диалога.
2. Переписывание запроса: LLM берёт историю + новый запрос и формирует «самодостаточный запрос» (например, «Сколько стоит подписка Pro?»).
3. Извлечение: этот расширенный запрос используется для поиска по векторной базе.
4. Генерация: ответ формируется с учётом нового контекста.
Плюсы
создаёт чат без деменции;
пользователю не нужно повторять информацию
Минусы
дрейф памяти: нерелевантный контекст из прошлых 10 минут может мешать поиску;
выше расходы на токены из-за автоматического переписывания запроса
3. Corrective RAG (CRAG) — «Самопроверяющийся»

Начинают идти высокие материи. Эта архитектура уже более похожа на то, чтобы применять ее в тех задачах, когда цена ошибки высока.
Здесь подразумевается добавление дополнительного шага контроля, при котором модель оценивается качество полученных документов (полученной информации из «базы знаний») до того, как они перейдут для генерации ответа.
Если полученные данные оказались некачественными, переходим к резервному варианту. К примеру, ищем информацию в интернете.
Retrieval: извлечение документов из внутреннего векторного хранилища.
Evaluation: какая-нибудь лёгкая модель (не основная) присваивает каждому фрагменту оценку:Correct (верно), Ambiguous (неоднозначно) или Incorrect (неверно)
Decision Gate: Correct — данные идут к генератору или Incorrect — фрагмент отбрасывается, запускается внешний API (например, Google Search).
Synthesis: генерация ответа с использованием проверенных внутренних или свежих внешних данных.
Плюсы
резко снижает количество галлюцинаций;
соединяет внутренние данные с реальными актуальными фактами.
Минусы
заметное увеличение задержки (добавляет 2–4 секунды);
необходимо управлять расходами и лимитами внешних API
4. Adaptive RAG — какая сложность, такие и усилия

Adaptive RAG – наш чемпион по эффективности. Если знакомы с базами данных и что такое «план запрос», то adaptive rag как планировщик в базах данных. Он определяет наиболее эффективный вариант.
Как это работает
Анализ сложности: снова небольшая модель (не основная) определяет, насколько сложен запрос.
Варианты обработки:
Путь A (без поиска): Для элементарных запросов, которые не требуют дополнительных знаний («Сколько будет 2+2?»)
Путь B (Standard RAG): для запросов, которым требуется дополнительная информация для ответа
Путь C (Многошаговый агент): для сложных аналитических вопросов, требующих поиска по нескольким источникам
**Мы**: привет! **Агент**: Привет! (Путь А) **Мы**: Во сколько будет встреча с клиентом? **Агент**: Встреча назначена на 15:00 и продлится час (Путь B) **Мы**: Какая у компании была выручка за последний квартал? Сравни с предыдущим кварталом. **Агент**: …. (Путь C)
Плюсы
значительная экономия ресурсов за счёт пропуска лишнего поиска;
минимальная задержка для простых запросов.
Минусы
риск ошибки классификации: если сложный вопрос определён как простой, поиск не выполнится
5. Self-RAG — ИИ, который сам себя проверяет

Self-RAG — это уже продвинутая архитектура, в которой модель обучена критически оценивать собственные рассуждения. Она не просто извлекает информацию, а еще проводит аудит собственного ответа через “self-evaluation tokens”
Как это работает
1. Retrieve: стандартный поиск
2. Generate with Tokens: модель генерирует текст вместе со специальными токенами, например:
a. [IsRel] — «Это релевантно?»
b. [IsSup] — «Подтверждается ли это утверждение?»
c. [IsUse] — «Полезна ли эта информация?»
3. Self-Correction: если модель (может использовать сторонняя модель поменьше) отрицательно отвечает на эти вопросы, основная модель делает паузу, повторно извлекает данные и переписывает предложение.
Пример: Инструмент для юридических исследований. Модель формулирует утверждение о судебном деле, замечает, что найденный документ на самом деле его не подтверждает, и автоматически ищет другой прецедент.
Плюсы
максимальная фактическая точность;
встроенная прозрачность процесса рассуждений.
Минусы
· требует специализированных, дообученных моделей (например, Self-RAG Llama);
· крайне высокие вычислительные затраты.
6. Fusion RAG — несколько подходов для лучших результатов

Fusion RAG решает проблему «неоднозначности». Будем честны, многие из нас откровенно плохо формулируют запросы. Какой вопрос, таков и ответ.
Fusion RAG берёт один запрос и рассматривает его с нескольких сторон, чтобы повысить полноту поиска.
Как это работает
1. Вариации запроса: создаются 3–5 вариаций исходного вопроса пользователя.
2. Параллельное извлечение: поиск проводится по всем вариациям в векторной базе данных.
3. Reciprocal Rank Fusion (RRF): с помощью математической формулы результаты пересортировываются.
4. Окончательная ранжировка: документы, которые оказались в верхних результатах нескольких поисков, поднимаются на верх списка.
Плюсы
высокая полнота поиска (находит документы, которые один запрос мог бы пропустить);
устойчива к плохой формулировке запроса пользователем.
Минусы
увеличивает стоимость поиска (в 3–5 раз);
выше задержка из-за дополнительных вычислений для пересортировки.
7. HyDE — сначала генерируем ответ, потом ищем похожие документы

HyDE —необычный, но очень эффективный подход. Он учитывает, что «вопросы» и «ответы» семантически разные. Система строит мост между ними, сначала создавая «фейковый» (гипотетический) ответ.
Как это работает
1. Hypothesize: LLM пишет фейковый или гипотетический ответ на запрос.
2. Embedding: фейковый ответ превращается в вектор.
3. Retrieval: этот вектор используется для поиска реальных документов, похожих на фейковый ответ.
4. Generation: найденные реальные документы используются для формирования окончательного ответа.
Пример: Пользователь задает вопрос из разряда «Тот федеральный закон про персональные данные, что в нем говорится?». AI сама пишет краткое резюме 152-ФЗ, а затем на основе этого резюме ищет закон в «базе знаний».
Плюсы
значительно улучшает поиск для концептуальных или расплывчатых вопросов;
не требует сложной логики агента.
Минусы
риск ошибок: если «фейковый ответ» изначально неверен, поиск будет вести не туда;
неэффективно для простых фактических запросов (например, «Сколько будет 2+2?»).
8. Agentic RAG — осторожно, работают профессионалы (агенты)

Вместо того чтобы просто извлекать документы, вводим автономного агента, который планирует, рассуждает и решает, как и где искать информацию, прежде чем генерировать ответ. Здесь поиск информации рассматривается как исследование, а не простое извлечение.
Как это работает
1. Analyze: агент сначала интерпретирует запрос пользователя и определяет, простой он, многошаговый, неоднозначный или требует актуальных данных.
2. Plan: разбивает запрос на подзадачи и выбирает стратегию:
a. сначала поиск по векторной базе?
b. поиск в вебе?
c. вызов API?
d. задать уточняющий вопрос?
3. Act: агент выполняет выбранные шаги с помощью инструментов: векторные базы, веб-поиск, внутренние API, калькуляторы и т.д.
4. Iterate: по мере получения промежуточных результатов агент может уточнять запросы, искать дополнительные данные или проверять источники.
5. Generate: когда собрано достаточно доказательств, LLM создаёт обоснованный, контекстно-зависимый финальный ответ.
Плюсы
справляется со сложными, многошаговыми и неоднозначными запросами;
снижает галлюцинации за счёт проверки и итераций;
может работать с актуальными внешними данными;
более гибок при изменении контекста и требований.
Минусы
большая задержка из-за многошаговой обработки;
дороже в эксплуатации, чем простой RAG;
требует тщательной координации инструментов и агента;
избыточен для простых фактических запросов
9. GraphRAG — «Разум отношений»

В отличие от всех предыдущих архитектур, которые извлекают документы на основе семантического сходства, GraphRAG ищет сущности и явные связи между ними.
Как это работает
1. Построение графа: знания моделируются в виде графа, где узлы — это сущности (люди, организации, концепции, события), а рёбра — отношения между ними (влияет на, зависит от, регулируется на основе, заблокирован).
2. Парсинг запроса: анализируется запрос пользователя, чтобы определить ключевые сущности и типы отношений, а не просто ключевые слова.
3. Обход графа: система ищет значимые пути, соединяющие сущности через несколько шагов.
4. Опциональное гибридное извлечение: часто вместе с графом используют векторный поиск, чтобы связать сущности с неструктурированным текстом.
5. Генерация ответа: LLM преобразует найденные пути отношений в структурированный и объяснимый ответ.
Пример: «Как решения ЦБ по процентной ставке влияют на стоимость ОФЗ?». Затем начинается обход графа: ЦБ – (устанавливает)-> ключевая ставка –(влияет на)-> доходность ОФЗ –(снижает)-> интерес покупателей и спрос –(снижает)-> стоимость облигаций.
ЦБ → устанавливает → ключевая ставка → влияет на → доходность ОФЗ → → снижает → интерес покупателей и спрос → снижает → стоимость облигаций
Плюсы
отлично подходит для причинно-следственного анализа;
высоко объяснимые ответы благодаря явным связям;
снижает ложные срабатывания, вызванные семантической похожестью.
Минусы
высокая первоначальная стоимость создания и поддержки графов знаний;
построение графа может быть вычислительно затратным;
сложнее адаптировать при изменении предметной области;
избыточен для открытых или диалоговых запросов.
Заключение
Как и в каждой подобной статье, требуется какой-нибудь заключительный совет.
Расписывать, когда и как применять данные подходы я не буду. Считаю, что вы и сами прекрасно разберетесь. К тому же, чтобы начать применять у себя описанное, я бы лучше детальнее ознакомился с технической составляющей, потому как данная статья более обзорная, чем детальная инструкция.
Скажу лишь свое мнение, не претендующее на истину – первый вариант подойдет для 90% задач.
