Что такое RAG: как AI отвечает по документам компании

Коротко: RAG ищет знание перед ответом

RAG — это способ дать AI доступ к актуальным документам компании перед ответом. Вместо того чтобы надеяться на память модели или отправлять ей всю папку целиком, система находит несколько подходящих фрагментов в базе знаний и передаёт их в контекст вопроса. Так ассистент может ответить по регламенту, каталогу, проектной документации или инструкции и показать, на какой материал он опирался.

Представьте диспетчера сервисной компании. Он спрашивает: «Какая гарантия на насос серии X, поставленный в Казань в прошлом году?» У него есть прайс, технический паспорт, договор и несколько старых редакций условий. RAG ищет фрагменты с нужной серией, регионом и версией условий, а затем отдаёт их модели для ответа. Если подходящего источника нет, правильный результат — не догадка, а сообщение: «в базе нет подтверждения; уточните у ответственного».

Почему файл в чате — не то же самое, что RAG

Руководство на 100 страниц можно загрузить в чат и спросить: «Какой порядок обслуживания у узла А?». Это удобно для одного файла или разовой сводки, но плохо превращается в рабочий процесс. В компании обычно есть версии инструкций, договоры, спецификации, прайсы и карточки товаров. Загрузка не задаёт, какой источник приоритетный и когда он устарел; ответ может выглядеть уверенно, хотя нужный пункт был в другой версии.

В RAG документ разбивают на осмысленные части, снабжают версией, датой и другими признаками. По вопросу система находит несколько релевантных частей, отсекает неподходящие фильтрами и только затем передаёт контекст языковой модели. Это позволяет обновлять источник, ограничивать доступ, показывать первоисточник и тестировать выдачу.

Многие сервисы, где пользователь «загружает файл в чат», внутри тоже строят индекс и используют поиск. Для бизнеса разница в другом: в разовом чате файл живёт в конкретном разговоре, а корпоративный RAG заранее задаёт базу, правила обновления, доступы и поведение агента, когда знания не найдены. Один документ можно и разово проанализировать в чате, и отдельно проиндексировать для будущих обращений.

Как RAG отвечает на вопрос

Система извлекает текст, делит его на чанки, создаёт эмбеддинги и сохраняет всё вместе с метаданными. Вопрос пользователя тоже превращается в эмбеддинг; поиск по близости смыслов и фильтрам выбирает нужные чанки и передаёт их LLM. Модель отвечает по найденному контексту или сообщает, что подтверждения нет. Это и есть retrieval-augmented generation: генерация, дополненная поиском.

Полезно разделить роли. LLM читает вопрос и пишет понятный ответ. Эмбеддинговая модель не отвечает пользователю: она превращает смысл вопроса и фрагментов в сопоставимые координаты. Векторная база быстро находит соседние по этим координатам фрагменты. Retriever — логика, которая выполняет поиск и отдаёт отобранные куски агенту. Если ответ слабый, важно понять, какой компонент дал сбой.

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

Чанки, эмбеддинги и метаданные

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

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

Эмбеддинговая модель преобразует текст в набор чисел. Она помогает связать «порядок замены фильтра» с вопросом «когда менять картридж», даже без совпадения слов, но не пишет ответ пользователю. Поставщика выбирают по языкам, качеству поиска, требованиям к данным и стоимости индексации. В n8n есть ноды эмбеддингов OpenAI, Cohere, Google, Mistral и локальных моделей через Ollama.

Метаданные — служебные поля рядом с чанком: document_id, название, версия, дата актуальности, раздел, тип документа, владелец и права доступа. Для каталога это бренд, категория, артикул и регион; для стройки — объект, стадия и редакция проекта. Метаданные помогают не показать внутренний документ клиенту, искать только действующую версию и переиндексировать весь документ по его идентификатору.

Как добиться точного поиска

Векторный поиск часто называют семантическим: он ищет близость по смыслу, а не только буквальное совпадение слов. Для артикулов, кодов и точных названий этого недостаточно — добавляют полнотекстовый или гибридный поиск. Для каталога полезно сначала сузить выборку метаданными: бренд, категория, доступный регион, — а затем искать смысловой ответ.

Если документов много и они похожи, не решайте проблему промптом «будь внимателен». Дайте каждому источнику стабильный идентификатор, версию, статус «действует / архив», владельца и дату проверки. Не смешивайте черновики с действующими документами. В запросе подставляйте известный контекст: объект, роль, продукт или регион. Тогда вопрос про насос на объекте А не будет искать похожие инструкции для объекта Б.

Проверяйте найденные чанки, а не только красивый ответ. Если нужный фрагмент не вошёл в выдачу, сильная LLM его надёжно не додумает. Для критичных процедур нужен порог релевантности: если доказательства нет, ассистент возвращает «не найдено подтверждение» и передаёт вопрос ответственному.

Какой RAG выбрать и сколько он стоит

В n8n можно собрать цепочку из загрузчика документов, text splitter, эмбеддингов, векторного хранилища и retriever. Документация n8n перечисляет Simple Vector Store, а также подключения к PGVector, Qdrant, Pinecone, Weaviate, Supabase, Redis и другим хранилищам. Простой вариант подходит, чтобы проверить логику на небольшом наборе данных. Для постоянно работающего сервиса важнее определить, где хранятся данные, как выполняются резервные копии, разграничиваются права, ведутся версии и мониторятся ошибки.

Управляемый провайдер может сам принять файлы, разбить их и дать готовый поиск. Это быстрее в запуске, но не отменяет вопросов к доступам, обновлениям и стоимости. Внешняя база даёт больше контроля, но требует настройки. На практике есть три уровня: тест на нескольких документах; рабочий помощник отдела с метаданными, обновлением и журналом источников; критичный сервис с авторизацией, разделением данных, резервным копированием и человеком для спорных ответов.

Стоимость RAG складывается не только из «цены нейросети». Есть индексация: извлечение текста, эмбеддинги и хранение векторов. Есть стоимость ответа: поиск, иногда reranking, и токены LLM, которая читает найденный контекст. При маленькой базе обычно важнее время на подготовку и проверку документов; при большом потоке запросов — хранение и размер контекста. Бюджет оценивают на реальной выборке и типовых вопросах, а не по рекламной цене одного запроса.

Можно ли редактировать RAG

RAG — не файл, который «лежит внутри нейросети». Это набор записей: чанков, эмбеддингов и метаданных. Если понятны затронутые части и их идентификаторы стабильны, можно точечно обновить цену или один раздел инструкции и пересчитать эмбеддинги только для этих чанков.

Если меняется структура документа, размер чанков, порядок разделов или эмбеддинговая модель, безопаснее удалить старые части документа и загрузить новую версию целиком. Иначе остаются дубли и устаревшие фрагменты. При смене embedding-модели обычно переиндексируют всю коллекцию: векторы, созданные разными моделями, нельзя бездумно сравнивать в одном поисковом пространстве.

Минимальный операционный цикл: загрузка новой версии, проверка числа чанков и метаданных, пробные вопросы, публикация и исключение старой версии. Такой цикл можно запускать вручную, по событию из папки или CMS, а в крупной системе — через очередь и отдельный тестовый индекс.

Где RAG нужен, а где нет

RAG оправдан не числом страниц, а повторяемостью поиска и ценой ошибки: когда сотрудники или клиенты часто спрашивают по меняющимся материалам и важно быстро найти первоисточник. Нет порога вроде «после 100 страниц RAG обязателен»: десять плохо подготовленных документов могут давать хаотичные ответы, а большая аккуратно размеченная база — работать устойчиво.

Если ответ можно получить одной интеграцией с системой-источником, делайте интеграцию. Остаток товара, статус заказа или текущая цена — данные из ERP или CRM, а не из RAG. RAG нужен для неструктурированного знания: инструкций, политик, описаний, договоров и проектных материалов. В одном агенте оба подхода могут работать вместе: API даст точный остаток, а RAG объяснит условия доставки.

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

• Необходимые правила безопасности и короткие инструкции дублируйте в явной логике агента: они не должны зависеть от того, нашёлся ли чанк.
• Для цен, юридических условий, норм безопасности и технических решений показывайте источник и предусматривайте проверку человеком.
• Начинайте с одного домена знаний и 20–50 реальных вопросов; если нужный источник не находится, сначала исправляйте данные и поиск, а не добавляйте документы.

AI-агент с RAG и без него

AI-агент без RAG использует инструкции, диалог и другие инструменты; этого достаточно, чтобы классифицировать заявку или подготовить письмо. С RAG он получает инструмент поиска в живой базе знаний. Это не делает его «лучше» вообще, но даёт проверяемость: видно, что найдено, передано модели и где обновить источник.

Качество зависит от всей цепочки. Слабая модель может неверно собрать ответ даже с хорошими чанками, а плохие эмбеддинги, разбиение и фильтры испортят результат сильной LLM. Проверяйте два шага отдельно: нашёлся ли нужный чанк и верно ли модель использовала его. Если сбоит поиск — правьте данные и метаданные; если сборка ответа — меняйте промпт, модель или добавляйте проверку человеком.

С чего начать

Выберите одну узкую задачу: например, ответы первой линии по актуальному каталогу или поиск инструкции для одной модели оборудования. Соберите небольшой набор действующих документов, назначьте владельца каждого и до загрузки определите метаданные и права доступа.

Составьте реальные вопросы сотрудников вместе с правильными источниками, соберите тестовый RAG в n8n и смотрите на найденные чанки, а не только на итоговый текст. Добавьте порог релевантности, журнал источников и передачу человеку случаев без подтверждения. Так RAG становится не «чатом с папкой», а управляемым слоем доступа к знаниям компании.