Что такое RAG-система: как научить нейросеть отвечать по документам

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

Что такое RAG простыми словами

RAG расшифровывается как Retrieval-Augmented Generation — «генерация, дополненная поиском». Как устроена сама языковая модель, мы подробно разбирали в статье о больших языковых моделях; здесь важно одно её свойство: модель знает только то, на чём её обучили, и не знает ничего о вашей компании. Спросите её про условия возврата в вашем магазине — она уверенно сочинит правдоподобный ответ. Это и есть галлюцинация.

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

Зачем бизнесу RAG: четыре типовых сценария

RAG нужен везде, где ответ должен опираться на внутренние данные компании, которые меняются и которых нет в открытом интернете.

• Поддержка клиентов. Бот на сайте или в Telegram отвечает на вопросы о доставке, гарантии, тарифах по актуальным документам и передаёт оператору то, чего в базе нет. Типичный эффект — заметная доля повторяющихся обращений закрывается без человека.
• Внутренняя база знаний и регламенты. Сотрудник спрашивает «как оформить командировку» или «какой допуск по толщине для этой детали» и получает ответ со ссылкой на пункт инструкции вместо получаса поиска по папкам и вопросов коллегам.
• Продажи. Ассистент менеджера подбирает товар по каталогу и характеристикам, отвечает на технические вопросы, сверяет условия договора. Если нужно, чтобы бот сам квалифицировал лидов и заводил их в CRM, это уже ИИ-бот для продаж с RAG внутри.
• Работа с документами. Поиск по договорам, тендерной документации, технической документации, переписке: «в каких договорах с поставщиками есть штраф за просрочку больше 0,1% в день?».

Отдельный случай — ИИ-агенты: агенту, который выполняет действия в CRM или 1С, RAG нужен как источник правил, по которым он действует. Поэтому при разработке AI-агентов база знаний с поиском обычно проектируется в первую очередь.

Как работает RAG: схема по шагам

RAG-система состоит из двух контуров. Первый — подготовка (индексация): выполняется при загрузке документов и при каждом их обновлении. Второй — ответ на вопрос: выполняется в момент, когда пользователь что-то спросил.

Подготовка базы знаний

1. Сбор и очистка документов. Word, PDF, страницы wiki, выгрузки из 1С и CRM приводятся к чистому тексту: убираются колонтитулы, дубли, служебный мусор, таблицы переводятся в читаемый вид, сканы распознаются.
2. Чанкинг — нарезка на фрагменты. Длинный документ делится на куски (чанки) обычно по несколько сотен токенов, с небольшим перекрытием, чтобы мысль не обрывалась на границе. Хорошая нарезка идёт по смыслу: по разделам, пунктам, вопросам, а не механически каждые N символов.
3. Метаданные. К каждому чанку привязывается источник, раздел, дата, версия документа и уровень доступа — это понадобится для ссылок, фильтрации и прав.
4. Эмбеддинги. Специальная модель превращает каждый чанк в вектор — набор чисел, отражающий смысл текста. Тексты, близкие по смыслу, получают близкие векторы, даже если написаны разными словами.
5. Запись в векторную БД. Векторы, тексты и метаданные сохраняются в хранилище, которое умеет быстро искать «ближайших соседей» среди миллионов записей.

Ответ на вопрос

1. Вопрос превращается в вектор той же моделью эмбеддингов. При необходимости вопрос предварительно переформулируется с учётом истории диалога («а для юрлиц?» → «условия возврата для юридических лиц»).
2. Поиск. В базе находятся чанки, наиболее близкие к вопросу по смыслу. В продакшене поиск обычно гибридный: векторный плюс классический по ключевым словам — он точнее ловит артикулы, номера пунктов, фамилии и редкие термины.
3. Фильтрация и переранжирование. Отсекаются документы, к которым у пользователя нет доступа, и устаревшие версии; отдельная модель-реранкер пересортировывает кандидатов и оставляет 3–10 лучших.
4. Промпт с контекстом. В модель уходят инструкция, найденные фрагменты с пометками источников и сам вопрос.
5. Генерация ответа со ссылками на документы и честным «не нашёл» — если в найденном ответа нет.

RAG, дообучение или длинный контекст: что выбрать

Есть три способа «рассказать» модели о вашем бизнесе. Их часто путают, хотя решают они разные задачи.

Правило выбора простое: если модели не хватает знаний — нужен RAG; если не хватает манеры (формат ответа, тон, специфичные шаблоны) — дообучение или хороший промпт. Длинный контекст удобен для разовой задачи «прочитай этот договор и найди риски», но для базы знаний он дорог и деградирует: на больших объёмах модели хуже находят детали в середине текста. В реальных проектах подходы комбинируют: RAG для фактов, промпт или дообучение для формата.

Инструменты: векторные базы и модели эмбеддингов

Векторные базы данных

• pgvector — расширение для PostgreSQL. Если у компании уже есть PostgreSQL, это самый простой старт: векторы живут рядом с остальными данными, права и бэкапы — привычные. Хватает для баз на сотни тысяч и миллионы чанков.
• Qdrant — специализированная векторная БД с открытым кодом, разворачивается на своём сервере, хорошо фильтрует по метаданным, поддерживает гибридный поиск.
• Milvus, Weaviate, Chroma — альтернативы под разные масштабы; Chroma чаще используют для прототипов.
• OpenSearch / Elasticsearch — когда полнотекстовый поиск уже есть и к нему нужно добавить векторный.

Модели эмбеддингов, включая российские

Для проектов с требованиями к данным в РФ важно, что у обоих крупных российских вендоров есть собственные модели векторизации. В Yandex AI Studio (Yandex Cloud) это пара text-search-doc для документов и text-search-query для запросов. У GigaChat в API доступны модели Embeddings, Embeddings-2 и EmbeddingsGigaR — последняя с увеличенным контекстом. Альтернатива — открытые мультиязычные модели (например, семейства BGE-M3 и multilingual-e5), которые запускаются на своём сервере без передачи текстов наружу.

Модель для генерации ответа (GPT, YandexGPT, GigaChat, открытые модели) выбирается отдельно и может меняться без переиндексации — это ещё один плюс RAG-архитектуры.

Откуда берутся ошибки RAG-системы

Когда RAG-бот отвечает неправильно, в большинстве случаев виновата не языковая модель, а данные или поиск. Основные источники ошибок:

• Плохие документы. Противоречащие друг другу версии регламента, сканы без распознавания, знания «в головах», которых нет в текстах. Система не может найти то, что не записано.
• Неудачный чанкинг. Слишком мелкие куски теряют контекст («скидка 10%» — на что?), слишком крупные размывают смысл и хуже находятся. Таблица, разрезанная пополам, теряет заголовки столбцов.
• Слабый поиск. Чисто векторный поиск промахивается по артикулам, номерам и аббревиатурам; без реранкера в контекст попадают похожие, но нерелевантные фрагменты.
• Устаревшие данные. Прайс обновили, а индекс — нет. Нужна автоматическая переиндексация при изменении источника и удаление старых версий.
• Слабый промпт. Модели не запретили отвечать «из головы» и не научили говорить «в документах этого нет».

Как измерить качество RAG

«Вроде отвечает нормально» — не метрика. Качество RAG проверяется так же, как любая система: на наборе эталонных данных.

1. Соберите эталонный набор из 100–300 реальных вопросов (из чатов поддержки, писем, вопросов сотрудников) с правильными ответами и указанием, в каком документе ответ.
2. Измеряйте поиск отдельно от генерации. Точность поиска — какая доля найденных фрагментов относится к делу; полнота — нашла ли система все нужные фрагменты. Если нужный фрагмент не попал в топ-5 — дело в поиске, модель тут ни при чём.
3. Оценивайте ответы: верен ли ответ, опирается ли он только на найденный контекст (без выдумок), есть ли корректная ссылка на источник, правильно ли система отказалась отвечать, когда ответа в базе нет.
4. Автоматизируйте прогон. Для оценки используют фреймворки вроде RAGAS и модель-«судью» с выборочной проверкой человеком. Прогон повторяется после каждой правки чанкинга, промпта или смены модели.
5. Следите в продакшене: доля вопросов без ответа, переводы на оператора, оценки пользователей, повторные вопросы.

Безопасность, права доступа и 152-ФЗ

RAG-система видит все загруженные документы, поэтому без разграничения прав она становится удобным способом узнать чужую зарплату или условия договора с конкурентом. Базовые правила:

• Права на уровне чанков. Каждый фрагмент наследует права исходного документа, поиск фильтрует по ним до передачи в модель. Промпт «не показывай конфиденциальное» защитой не является.
• Защита от промпт-инъекций. Если в базу попадают внешние тексты (письма, документы клиентов), в них могут оказаться инструкции для модели. Инструкции из документов не должны исполняться, ответы с действиями — проверяться.
• Журналирование вопросов, найденных источников и ответов — для разбора инцидентов и контроля качества.

Если в документах или диалогах есть персональные данные клиентов и сотрудников, работает 152-ФЗ: первичная запись и хранение ПДн граждан РФ — в базах на территории России, а передача текстов с ПДн в API зарубежной модели — это трансграничная передача, о которой нужно заранее уведомлять Роскомнадзор. Практичные варианты: российские модели в облаке РФ (YandexGPT, GigaChat), открытые модели на своём сервере или обезличивание данных перед отправкой. Векторная БД при этом тоже хранит персональные данные — векторы и тексты чанков, — и её нужно защищать наравне с основной базой.

Сколько стоит и сколько длится внедрение RAG

Стоимость зависит от объёма и «грязности» документов, числа источников и интеграций, требований к правам доступа и контуру размещения. Ориентиры на рынке для заказной разработки:

Отдельно — ежемесячные расходы: токены модели (пропорциональны числу запросов и объёму контекста), хостинг векторной БД и поддержка — обновление индекса, разбор ошибок, пополнение эталонного набора. Подробнее о том, как проходят этапы от диагностики до продакшна, — на странице внедрения искусственного интеллекта в бизнес.

Типичные ошибки при внедрении RAG

• Загрузить «всё подряд». Старые версии, черновики и дубли в базе гарантируют противоречивые ответы. Сначала наведите порядок в источниках, потом индексируйте.
• Оценивать на трёх примерах. Демо на удобных вопросах выглядит блестяще, на реальном потоке доля ошибок может оказаться в разы выше. Без эталонного набора вы этого не увидите до жалоб клиентов.
• Лечить поиск сменой модели. Переход на более дорогую LLM не поможет, если нужный фрагмент не находится. Сначала проверяйте поиск.
• Не назначить владельца базы знаний. RAG устаревает вместе с документами. Нужен человек или процесс, отвечающий за актуальность.
• Забыть про права и ПДн. Общий индекс для всех сотрудников и отправка персональных данных в зарубежный API — прямой путь к утечке и претензиям регулятора.
• Не предусмотреть «не знаю». Система, которая всегда отвечает, рано или поздно уверенно ответит неправильно. Честный отказ с переводом на человека лучше выдумки.

Чек-лист: готова ли компания к RAG

• Определена задача и аудитория: кто задаёт вопросы и какие решения принимает по ответам.
• Знания записаны: регламенты, каталог, FAQ существуют в виде документов, а не только в головах.
• Есть актуальные версии документов и понятный владелец каждого источника.
• Собрано 100+ реальных вопросов с эталонными ответами для оценки.
• Определены права доступа: кто какие документы может видеть.
• Решено, есть ли персональные данные и где будут работать модели (облако РФ, свой сервер, зарубежный API).
• Выбраны метрики пилота: доля верных ответов, доля вопросов без оператора, время ответа.
• Настроен процесс обновления индекса при изменении документов.
• Предусмотрен перевод на человека, когда в базе нет ответа.

Итог

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