--- title: "RAG в n8n: как сделать базу знаний, которая — Nodbot" source_url: "https://nodbot.ru/ai/rag/" canonical_url: "https://nodbot.ru/ai/rag/" language: "ru" content_type: "AIGuide" section: "ai" generated_at: "2026-05-30" word_count_source: 1011 --- # RAG в n8n: как сделать базу знаний, которая отвечает по источникам ## AI summary AI-гайд для n8n: RAG в n8n: как сделать базу знаний, которая отвечает по. Архитектура workflow, ограничения, проверки качества, безопасность и cost control. ## Best used for Страница объясняет «RAG в n8n: как сделать базу знаний, которая — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда RAG действительно нужен - Архитектура RAG workflow - Подготовка документов - Chunking: где чаще всего ошибка - Metadata: главный способ снизить hallucination - Как проверять качество retrieval - Ответ должен показывать источники ## Source outline # RAG в n8n: как сделать базу знаний, которая отвечает по источникам Обновлено: 2026-05-29 ## Короткий ответ RAG в n8n нужен, когда AI должен отвечать не “из головы”, а по вашим документам: базе знаний, регламентам, тарифам, инструкциям, FAQ или внутренней wiki. Качественный RAG — это не только vector store и embeddings, а полный процесс: подготовить документы, правильно нарезать chunks, добавить metadata, настроить retrieval, показывать источники, проверять ответы на тестовом наборе и регулярно обновлять индекс. Если пропустить хотя бы один слой, агент будет звучать уверенно, но ссылаться на устаревшие или нерелевантные данные. ## Когда RAG действительно нужен RAG подходит, если ответ зависит от приватных или часто меняющихся знаний: внутренних регламентов, цен, инструкций, условий продукта, статей поддержки. Он не нужен для простых задач вроде классификации текста, извлечения email или генерации короткого summary — там достаточно LLM без базы знаний. - Сценарий | Нужен RAG | Почему - Ответы по базе поддержки | да | модель должна ссылаться на статьи - Проверка статуса заказа | нет | лучше запросить CRM/API - Внутренний ассистент по регламентам | да | нужны актуальные документы - Классификация лида | обычно нет | хватает prompt + examples - Ответы по договорам/шаблонам | да, с review | высока цена ошибки ## Архитектура RAG workflow Типовой RAG в n8n состоит из двух разных workflow: ingestion и answering. Ingestion workflow : - забирает документы из Notion, Google Drive, сайта, Git, PDF или базы; - очищает HTML/markdown от меню, footer и мусора; - режет текст на chunks; - добавляет metadata; - создаёт embeddings; - записывает chunks в vector store; - логирует версию индекса. Answering workflow : - получает вопрос пользователя; - нормализует язык, продукт, тариф, регион; - делает retrieval по vector store; - фильтрует источники по metadata; - передаёт найденные chunks в AI Agent или QA chain; - требует ответ со ссылками на source IDs; - отправляет review, если источники слабые или конфликтуют. Разделение важно: если ingestion и answering смешаны, вы не сможете понять, проблема в документах, embeddings, retrieval или prompt. ## Подготовка документов Плохой документ для RAG — это страница, где вперемешку меню, реклама, хлебные крошки, кнопки, похожие FAQ и устаревший текст. Перед embedding нужно оставить только смысловой контент. Минимальная очистка: - удалить навигацию, footer, “читать дальше”, cookie banners; - сохранить заголовки H2/H3 как часть контекста; - добавить source_url , title , updated_at ; - пометить deprecated-страницы; - разбить большие таблицы на осмысленные блоки; - убрать дубли между языковыми/print-версиями. Если база знаний изначально хаотичная, RAG не исправит её. Он только сделает хаос быстрее доступным. ## Chunking: где чаще всего ошибка Слишком короткие chunks теряют смысл, слишком длинные тащат лишний шум. Начинайте с логического chunking по разделам, а не просто по 1000 символов. - Тип документа | Подход к chunks - FAQ | один вопрос-ответ = один chunk - Инструкция | шаг или раздел = chunk - Регламент | правило + исключения = chunk - API docs | endpoint + параметры + ошибки = chunk - Длинная статья | H2-блоки с overlap Добавляйте overlap только там, где разделы реально зависят друг от друга. Большой overlap увеличивает стоимость и делает retrieval более шумным. ## Metadata: главный способ снизить hallucination Metadata помогает не искать “во всех документах сразу”. Для Nodbot-подобного сайта полезны: ``` { "source_url": "/ai/rag/", "title": "RAG в n8n", "section": "chunking", "product": "n8n", "language": "ru", "audience": "developer", "updated_at": "2026-05-29", "status": "current" } ``` Для customer support добавьте plan , region , product_line , version , visibility . Если клиент спрашивает про тариф в РФ, retrieval не должен подмешивать старый англоязычный документ для другого рынка. ## Как проверять качество retrieval Не оценивайте RAG только по красоте финального ответа. Сначала проверьте, какие chunks возвращаются. Тестовый набор должен включать: - точные вопросы, где источник очевиден; - вопросы с синонимами; - вопросы с устаревшей информацией; - вопросы без ответа в базе; - конфликтующие документы; - вопросы на другом языке; - короткие запросы из 2–3 слов. Для каждого вопроса храните expected source IDs. Если retrieval не достал правильный источник, prompt уже не спасёт. ## Ответ должен показывать источники Production RAG должен возвращать не только текст, но и список источников. ``` { "answer": "...", "sources": [ {"source_url":"/ai/rag/", "section":"Metadata", "confidence":0.84} ], "needs_human_review": false, "missing_information": [] } ``` Если sources пустые, запрещайте уверенный ответ. Лучше честно сказать, что в базе знаний нет подтверждения, чем сгенерировать “правдоподобный” ответ. ## Обновление индекса RAG устаревает тихо: документы обновили, а embeddings остались прежними. Нужен refresh-процесс. Проверяйте: - изменился ли updated_at источника; - удалены ли deprecated chunks; - не задвоились ли chunks после re-index; - сохраняется ли версия embedding model; - есть ли smoke test после обновления базы; - кто владелец документа. Для критичных баз знаний обновление индекса лучше запускать по событию изменения документа, а не только вручную. ## FAQ Можно ли собрать RAG без vector store? Для маленькой базы можно передавать несколько документов прямо в prompt, но это быстро упирается в context window и стоимость. Vector store нужен, когда документов много и нужен поиск по смыслу. Что важнее: embeddings или prompt? Для RAG сначала важны документы, chunking и retrieval. Prompt не исправит ситуацию, когда в контекст попал неправильный источник. Почему RAG даёт плохие ответы, хотя документы есть? Чаще всего из-за плохой очистки документов, слишком крупных chunks, отсутствия metadata, устаревшего индекса или слабого тестового набора. ## Контроль качества AI-workflow AI-workflow по теме «RAG в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо. Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «RAG в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - определён JSON-контракт ответа и validation step после модели - опасные действия проходят через approval или создают только draft - логируются prompt_version, model, sources, cost и fallback_reason - есть eval-набор минимум для happy path, low confidence и prompt injection ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.