n8n RAG собирают из двух сценариев: один загружает документы в векторную базу, другой находит нужные фрагменты и передаёт их модели, чтобы ответ шёл со ссылкой на источник. Разделение решает главную проблему базы знаний: документы меняются каждый день, вопросы приходят постоянно, и обновление индекса должно идти в фоне, без пауз в ответах. Схема подходит отделам с живой документацией, а для архива из пары десятков файлов хватит разовой загрузки без автоматики.
Два сценария
RAG в n8n строится из сценария загрузки, где документы режутся на фрагменты и попадают в векторное хранилище, и сценария ответа, где хранилище отдаёт найденное модели вместе с названием источника.
По документации n8n, узел векторного хранилища работает в нескольких режимах: получение документов по запросу, вставка, извлечение для цепочки или инструмента и, у части хранилищ, обновление по идентификатору. Для вставки нужны модель эмбеддингов и узел загрузки документов (Default Data Loader), который режет содержимое простым рекурсивным разделителем либо подключённым вами отдельным. Для ответа хранилище подключают к агенту как инструмент или вызывают напрямую.
Отделяйте RAG от общего агентного сценария: об устройстве агента, памяти и инструментах рассказывает статья как собрать ИИ-агента в n8n, а подключение внешних инструментов через MCP описано в материале n8n MCP: агент и сценарий с разделёнными правами. Здесь только поток документов и ответ по источникам.
| Сценарий | Когда запускается | Что делает |
|---|---|---|
| Загрузка и обновление | По расписанию или при изменении файла | Читает документ, режет, считает эмбеддинги, записывает с метаданными |
| Ответ на вопрос | По сообщению сотрудника | Ищет фрагменты, передаёт модели, возвращает ответ и ссылки |
| Контроль качества | Раз в неделю | Прогоняет тестовые вопросы и сравнивает с эталоном |
Загрузка и нарезка
Начинайте с одного набора документов, например регламентов отдела, и доводите его до рабочего состояния, прежде чем подключать остальные источники. Сценарий загрузки состоит из цепочки: источник, загрузчик, нарезка, эмбеддинги, запись. Каждое звено влияет на качество будущих ответов, и ошибка на раннем этапе ломает всё последующее.
- Подключите источник: папку, облачное хранилище, wiki или почтовый ящик с регламентами.
- Извлеките текст и очистите его от колонтитулов, оглавлений и повторяющихся подписей.
- Выберите способ нарезки: по символам, рекурсивный для структурированного текста или по токенам.
- Задайте размер фрагмента и перекрытие так, чтобы мысль целиком умещалась в одном куске.
- Добавьте метаданные: название файла, раздел, дата версии, владелец документа.
- Запишите фрагменты в векторное хранилище и сохраните отчёт о числе записей.
Чистка текста заслуживает отдельного внимания: повторяющиеся колонтитулы и оглавления попадают в каждый фрагмент и размывают поиск, а таблицы после извлечения часто превращаются в кашу из чисел. Для таблиц лучше сохранять названия столбцов в каждом фрагменте. Размер фрагмента подбирают на тестовых вопросах: мелкие куски дают точные попадания, но теряют контекст, крупные сохраняют смысл, но размывают поиск. Подробности о том, как проверять поиск по базе знаний, есть в разборе LangChain RAG: поиск и проверка ответов; принципы те же, меняется только инструмент.
Какие документы вашего отдела меняются чаще всего?
Метаданные источника
Ссылка на источник в ответе работает только тогда, когда она записана вместе с фрагментом. Хранилище отдаёт только то, что в него положили, и добавлять ссылку задним числом придётся перезаписью всех фрагментов. Поэтому метаданные проектируют до первой загрузки. В n8n их задают в узле загрузки документов, а при поиске по ним можно фильтровать.
- Название и адрес файла, чтобы сотрудник открыл оригинал.
- Раздел или страница, чтобы ссылка вела к месту в документе, а файл целиком открывать приходилось реже.
- Версия и дата документа, чтобы отличать действующую редакцию от старой.
- Владелец документа, к которому вопрос уходит, если ответ вызывает сомнения.
- Уровень доступа, чтобы поиск показывал только разрешённое.
Разные источники дают разный уровень порядка: в wiki есть заголовки, в почте их нет, в сканах нет даже текста. Для сканов потребуется распознавание, и результат нужно проверять отдельно. Загрузите три документа, задайте по вопросу на каждый и откройте ссылки из ответов. Если хотя бы одна ссылка ведёт мимо нужного места, исправляйте метаданные до загрузки остального архива.
Общую логику устройства таких систем описывает статья RAG: как устроена система, а правила цитирования в ответах агента разобраны в материале RAG-агент: поиск, инструменты и цитата.
Обновление документов
Самая частая беда RAG на живых документах — дубли. Файл изменили, сценарий загрузил новую версию рядом со старой, и поиск находит обе редакции, а модель смешивает их в одном ответе. Поэтому обновление включает удаление старого и запись нового, а обычного добавления мало.
- Определите, что изменилось: по дате изменения файла или по контрольной сумме содержимого.
- Удалите из хранилища старые фрагменты этого файла или перезапишите их по идентификатору (способ зависит от базы, см. ниже).
- Загрузите новую версию через тот же сценарий нарезки.
- Запишите в журнал файл, число старых и новых фрагментов и время операции.
- Для удалённых файлов выполните только удаление, чтобы поиск перестал ссылаться на исчезнувшие документы.
Для критичных документов добавьте уведомление владельцу: при обновлении файла он получает сообщение, что индекс переписан, и может проверить пару ответов. Журнал обновлений пригодится при первом же споре о том, почему ответ устарел. Готовой операции удаления по метаданным в узлах хранилищ n8n нет: у части баз есть режим Update Documents для обновления по идентификатору, у Pinecone при вставке доступна очистка пространства имён, а точечное удаление выполняют запросом к API самой базы через узел HTTP Request. Если назначать фрагментам предсказуемые идентификаторы вида «файл плюс номер части», обновление по идентификатору становится надёжным. Расписание подбирают по темпу изменений: для регламентов хватает ночного запуска, для каталога цен нужен более частый.
Ответ с источниками
Сценарий ответа получает вопрос, ищет фрагменты, передаёт их модели и формирует текст. Инструкция модели решает судьбу ответа: без чётких правил она смешивает найденное со своими знаниями и выдаёт уверенный вымысел. Подумайте и о правах: сотрудник отдела закупок должен оставаться без доступа к кадровым документам, даже если они лежат в общей базе. Метаданные об уровне доступа работают как фильтр поиска, и применять его нужно до того, как модель увидит фрагменты.
- Отвечать только по переданным фрагментам, а при нехватке данных прямо сообщать об этом.
- После каждого утверждения указывать название документа и раздел из метаданных.
- При противоречии между редакциями выбирать свежую и называть дату.
- Вопросы вне базы переадресовывать владельцу документа вместо выдуманного ответа.
Договоритесь о формате ссылки заранее: короткая подпись «Регламент закупок, раздел 3, редакция от даты» читается лучше сырого адреса, и по ней сотрудник находит нужное место в оригинале за секунды. Тест ответа — набор вопросов с известными источниками. Раз в неделю сценарий контроля прогоняет их и сравнивает названия источников в ответе с эталоном; расхождения попадают в отчёт. Для сотрудников удобнее всего канал, где они уже работают, например корпоративный мессенджер: тогда база знаний становится обычным коллегой, отвечающим со ссылками. Готовый контур с правами, обновлением и проверкой ответов мы собираем как часть разработки ИИ-агентов, а общие принципы выбора между RAG и дообучением описаны в статье RAG или дообучение модели.