Agentic CRAG на n8n: умный RAG с самокоррекцией

Почему обычный RAG больше не справляется

Вы строите чат-бота поверх корпоративной базы знаний. Загружаете PDF, нарезаете чанки, кладёте в векторную базу, подключаете LLM — и радуетесь первым ответам. А потом приходит первый сложный вопрос: «Какова наша политика возвратов для клиентов Enterprise, оформивших заказ до Q3 2024?» — и система уверенно галлюцинирует.

Проблема не в LLM и не в качестве данных. Проблема — в архитектуре.

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

Мартовское 2026 года систематизированное исследование зафиксировало: традиционный RAG достигает лишь ~34% точности на сложных многоходовых запросах. Agentic RAG — там, где агент управляет петлёй поиска с маршрутизацией, оцениванием и самокоррекцией — поднимает показатель до 78%.

Это не маргинальное улучшение. Это разница между прототипом и продакшн-системой.

В этой статье мы разберём, как собрать Agentic CRAG (Corrective RAG) pipeline на платформе n8n — без написания тысяч строк кода, но с полным контролем над каждым шагом.

Что такое CRAG и чем он отличается от обычного RAG

Corrective Retrieval Augmented Generation (CRAG) разработан для повышения устойчивости генерации в условиях ошибок при поиске. Ключевой элемент CRAG — лёгкий оценщик качества, который анализирует релевантность найденных документов и присваивает им степень уверенности, чтобы инициировать различные стратегии пополнения знаний.

CRAG добавляет лёгкий оценщик, который проставляет оценки документам и инициирует одно из трёх корректирующих действий:

• Correct (высокая уверенность) — уточняет документы, убирая нерелевантные предложения.
• Incorrect (низкая уверенность) — полностью отбрасывает найденные документы и переключается на веб-поиск.
• Ambiguous (средняя уверенность) — уточняет локальные документы и параллельно запускает веб-поиск, смешивая результаты перед генерацией.

Это принципиально меняет роль системы: она перестаёт слепо доверять ретривалу.

Классический RAG предполагает, что найденные документы всегда полезны. CRAG явно оценивает качество поиска и имеет стратегии отступления — что делает RAG-системы устойчивее к сбоям поиска.

CRAG vs Self-RAG vs Agentic RAG: в чём разница?

Три подхода часто путают:

• Corrective RAG (CRAG) добавляет шаг оценки релевантности после извлечения — компонент-«Grader» в изоляции, ценный, но не решающий проблему декомпозиции запросов или верификации выходных данных.
• Self-RAG обучает LLM самостоятельно решать, когда нужен поиск, и критиковать собственные выходы с помощью специальных токенов отражения. Поведение маршрутизации и проверки вшито в веса модели, но требует файнтюнинга.
• Agentic RAG — надмножество. Оркестрирует все компоненты через внешний агентский цикл: можно использовать любую LLM без файнтюнинга, динамически менять стратегии поиска и добавлять/удалять компоненты по мере необходимости.

Архитектура Agentic CRAG пайплайна

Agentic RAG оборачивает поиск в агентский цикл из пяти компонентов: Router, Retriever, Grader, Generator и Hallucination Checker.

Вот как это выглядит в виде потока:

graph TD
    A["🧑 Пользователь задаёт вопрос"] --> B["Router Agent\n(классификация запроса)"]
    B -->|"Простой / известный"| C["Прямой ответ LLM"]
    B -->|"Требует поиска"| D["Retriever\n(Vector Store)"]
    D --> E["Grader Agent\n(оценка релевантности)"]
    E -->|"Correct: высокая уверенность"| G["Generator\n(генерация ответа)"]
    E -->|"Incorrect: низкая уверенность"| F["Web Search Fallback\n(SerpAPI / Tavily)"]
    E -->|"Ambiguous: средняя"| F
    F --> G
    G --> H["Hallucination Checker\n(верификация фактов)"]
    H -->|"ОК"| I["✅ Финальный ответ"]
    H -->|"Обнаружены проблемы"| D

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

Почему n8n — идеальная платформа для CRAG

n8n — визуальный инструмент автоматизации рабочих процессов, упрощающий оркестрацию сложных AI-потоков. Его интерфейс на основе нодов позволяет соединять вызовы AI, запросы к базам данных, файловые операции и многое другое — без написания целого приложения вручную. В n8n можно смешивать «традиционные» ноды (HTTP-запросы, запросы к базам данных) с AI-нодами (ChatGPT или другими LLM) и даже нодами LangChain-агентов.

Платформы вроде LangChain или LlamaIndex фокусируются на RAG-пайплайнах, но зачастую требуют тяжёлого кодирования. n8n предлагает: low-code/no-code построение воркфлоу с расширенным контролем логики, нативные интеграции с API, базами данных и облачными хранилищами, а также лёгкое объединение AI-рассуждений с реальными действиями.

Последние версии n8n поддерживают добавление векторных хранилищ непосредственно как инструментов AI-агента. Агент самостоятельно решает, когда выполнять поиск (не для каждого запроса), что снижает задержку для простых вопросов. Это рекомендуемый подход для agentic RAG.

Пошаговая сборка Agentic CRAG на n8n

Шаг 1. Индексирование документов

В n8n каждый из этих этапов существует как нод в единственном воркфлоу, а не как разрозненные скрипты по разным сервисам.

Создайте первый воркфлоу — Ingestion Pipeline:

[Google Drive / Webhook] 
  → [Extract from File (PDF/DOCX)]
  → [Recursive Character Text Splitter]
  → [Embeddings OpenAI / Cohere]
  → [Vector Store — Insert Documents]

Длинные документы разбиваются на меньшие сегменты для более точного поиска — обычно размером около 500 символов. Каждый чанк преобразуется в вектор с помощью embedding-модели: текстовый смысл переводится в числовую форму, которую система может сравнивать и обрабатывать.

n8n предлагает несколько стратегий разбивки: Character Text Splitter делит по длине символов, а Recursive Character Text Splitter рекурсивно делит по Markdown, HTML, блокам кода или простым символам (рекомендуется для большинства случаев).

Шаг 2. Router Agent — классификация запроса

Второй воркфлоу — Query Pipeline — начинается с классификации входящего запроса.

Агент использует «мозг» LLM для анализа запроса и выбора подходящего инструмента. Например, если пользователь спрашивает «Что такое Model Context Protocol?», агент распознаёт это как вопрос об известной теме и направляет его в инструмент RAG-базы данных. Но если пользователь спрашивает «Кто победил вчера в матче?», агент видит потребность в свежих данных и использует инструмент веб-поиска. Это поведение «маршрутизатора поиска» позволяет системе комбинировать актуальную информацию с курируемыми знаниями.

В n8n это реализуется так:

[Chat Trigger] 
  → [AI Agent Node — Router]
     ├── Tool: Vector Store (для контекстных вопросов)
     ├── Tool: SerpAPI / Tavily (для веб-поиска)
     └── Tool: Direct LLM (для простых вопросов)

Системный промпт Router-агента:

You are a query router. Analyze the user's question and decide:
1. If answerable from internal knowledge base → use vector_search tool
2. If requires real-time or web information → use web_search tool  
3. If factual and within LLM training data → answer directly
Always explain your routing decision.

Шаг 3. Grader Agent — оценка релевантности

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

Grader-агент в n8n — это отдельный AI Agent Node или OpenAI node с промптом:

You are a document relevance grader.
Given the user query and retrieved documents, output JSON:
{
  "score": "correct" | "ambiguous" | "incorrect",
  "confidence": 0.0-1.0,
  "reason": "explanation"
}

Criteria:
- "correct": documents directly answer the query (confidence > 0.7)
- "ambiguous": partial relevance (0.3-0.7)
- "incorrect": documents are off-topic (confidence < 0.3)

Затем Switch Node маршрутизирует по полю score:

• correct → идём в Generator
• ambiguous → запускаем веб-поиск + Generator
• incorrect → только веб-поиск → Generator

Шаг 4. Fallback — веб-поиск

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

Подключите SerpAPI, Tavily или Brave Search через HTTP Request Node. Результаты веб-поиска объединяются с (при наличии) частично релевантными локальными документами и передаются в Generator.

Шаг 5. Generator + Hallucination Checker

После того как LLM сгенерировал ответ, добавьте нод «Answer Critic» — агента, который проверяет ответ относительно исходного вопроса. Если критик обнаруживает, что ответ неполный или некорректный, он формирует уточняющий запрос для заполнения пробела. Воркфлоу выполняет ещё один цикл поиска/генерации перед возвратом финального ответа.

Hallucination Checker промпт:

Compare the answer to the retrieved documents.
Identify any claims in the answer NOT supported by documents.
Output JSON:
{
  "grounded": true | false,
  "unsupported_claims": ["claim1", "claim2"],
  "action": "return" | "retry"
}

Полная схема воркфлоу в n8n

graph LR
    A(["Chat Trigger"]) --> B["AI Agent\n(Router)"]
    B --> C["Vector Store Tool\n(Pinecone/Qdrant)"]
    B --> D["Web Search Tool\n(SerpAPI)"]
    C --> E["Grader Agent\n(Relevance Score)"]
    E -->|"correct"| H
    E -->|"ambiguous"| F["Web Search\n+ Merge"]
    E -->|"incorrect"| D
    D --> F
    F --> H["Generator\n(LLM Node)"]
    H --> I["Hallucination\nChecker"]
    I -->|"grounded: true"| J(["✅ Response"])
    I -->|"grounded: false"| K["Retry Counter\n(IF Node)"]
    K -->|"attempts < 3"| C
    K -->|"attempts >= 3"| L(["⚠️ Partial Answer"])

Ключевые ноды для реализации

n8n позволяет проектировать весь пайплайн — от загрузки данных и эмбеддингов до поиска, генерации и постпроцессинга ответов — в одном месте.

Практические советы и типичные ошибки

Чанкинг решает всё

Чанкинг — это место, где большинство RAG-пайплайнов тихо ломаются. Плохой чанкинг даёт плохой поиск. Используйте Recursive Character Text Splitter с overlap 10-20% от размера чанка. Для технической документации — чанки 400-600 символов, для нарративных текстов — 800-1000.

Количество результатов поиска (top-k)

Слишком много чанков тратит токены и может запутать LLM. Слишком мало рискует упустить критическую информацию. Начните с top-5. Если ответы кажутся неполными — увеличьте до 10. Если ответы включают нерелевантные отступления — уменьшите до 3.

Используйте одну embedding-модель

Всегда используйте одну и ту же embedding-модель как для вставки, так и для извлечения данных. Смешение моделей (например, text-embedding-ada-002 при индексировании и text-embedding-3-large при поиске) гарантирует нерабочий поиск.

Память диалога

Window Buffer Memory Node позволяет сохранять краткосрочную память разговора, делая уточняющие вопросы естественными. Для CRAG-пайплайна это критично: без памяти агент-маршрутизатор не сможет учитывать контекст предыдущих сообщений при классификации.

CRAG vs LangGraph: когда n8n — правильный выбор?

n8n существует с 2019 года и стал одним из самых популярных инструментов автоматизации в мире. Его репозиторий на GitHub набрал ~124 000 звёзд, что ставит его в топ-50 публичных репозиториев.

LangGraph — фреймворк code-first для построения stateful, многоагентных AI-приложений в виде явных графов. Он даёт больше контроля над состоянием, но требует глубоких знаний Python и понимания теории графов.

Когда выбирать n8n для CRAG:

• Команда включает не только разработчиков (аналитики, DevOps, product managers)
• Нужна интеграция с десятками внешних сервисов без написания коннекторов
• Важна визуальная отладка и наблюдаемость каждого шага
• Прототип нужен за дни, а не недели

Когда LangGraph предпочтительнее:

• Сложные stateful сценарии с многоагентными иерархиями
• Нужна fine-grained оркестрация на уровне кода
• Команда полностью Python-native

В n8n каждый шаг виден, что делает отладку простой и наглядной. Для большинства enterprise-команд это решающий аргумент.

Заключение

Agentic CRAG на n8n — это не очередная AI-buzzword-конструкция, а практически реализуемый архитектурный паттерн, который решает главную проблему классического RAG: слепое доверие к результатам поиска.

Ключевые выводы:

1. CRAG добавляет Grader — оценщик, который делит результаты поиска на «correct», «ambiguous» и «incorrect» и применяет соответствующие стратегии
2. Agentic RAG — надмножество, добавляющее декомпозицию запросов, мультиисточниковый поиск и верификацию ответов
3. n8n — оптимальная платформа для реализации без тяжёлого кодирования, с нативными интеграциями и визуальной отладкой
4. Петля, а не конвейер — ключевое отличие от классического RAG
5. Ограничение итераций обязательно — иначе рискуете бесконечными циклами и раздутыми счетами за API

Начните с малого: добавьте только Grader-шаг к существующему RAG-воркфлоу. Это уже даст заметный рост качества. Затем постепенно добавляйте Router, веб-поиск и Hallucination Checker — и ваш чат-бот из «иногда галлюцинирующего» превратится в надёжный production-инструмент.