RAG: корпоративная база знаний с нейросетью
RAG позволяет нейросети отвечать по документам компании со ссылкой на источник. Как работает корпоративная база знаний, из чего состоит и как её внедрить.
RAG (Retrieval-Augmented Generation, генерация с дополнением из поиска) — это подход, при котором нейросеть отвечает не по своей «памяти», а по документам компании: сначала система находит в базе знаний фрагменты, относящиеся к вопросу, затем языковая модель формулирует ответ на их основе и указывает, откуда взята информация. Корпоративная база знаний на RAG позволяет сотруднику спросить обычными словами «какой срок возврата для оптовых клиентов?» и за секунды получить ответ со ссылкой на нужный пункт регламента, вместо того чтобы листать папки, вики и переписку. Модель при этом не нужно дообучать: достаточно подключить документы и поддерживать их в актуальном состоянии.
Почему нейросети нельзя просто «спросить про компанию»
Большие языковые модели обучены на огромном объёме общедоступных текстов. Они знают, как устроен договор поставки вообще, но не знают условий именно вашего договора. Если спросить модель о внутреннем регламенте, она либо честно скажет, что не знает, либо — что хуже — сочинит правдоподобный ответ. Это явление называют галлюцинациями.
Есть два очевидных способа «научить» модель знаниям компании:
- Дообучение (fine-tuning) — модель дополнительно обучают на ваших текстах. Это дорого, требует подготовки данных и повторяется при каждом изменении документов. К тому же дообученная модель всё равно не показывает, откуда взяла ответ.
- Вставить все документы в запрос — у современных моделей большое контекстное окно, но корпоративные базы знаний обычно намного больше. Да и платить за обработку тысяч страниц ради одного вопроса неразумно.
RAG решает задачу иначе: модель получает ровно те фрагменты, которые нужны для ответа на конкретный вопрос. Знания лежат в базе, а не «зашиты» в модель, поэтому обновить их так же просто, как заменить документ.
Как работает RAG: пошагово
Систему RAG удобно представить как две части: подготовку базы знаний и обработку вопроса.
Подготовка базы знаний
- Сбор документов. Подключаются источники: файловые хранилища, вики, базы регламентов, выгрузки из CRM и Service Desk, PDF и сканы.
- Извлечение текста. Из файлов получают чистый текст, для сканов используют распознавание. Таблицы и структура по возможности сохраняются.
- Разбиение на фрагменты. Документы делят на смысловые куски — обычно по разделам и абзацам, чтобы каждый фрагмент был понятен сам по себе.
- Векторизация. Каждый фрагмент превращают в эмбеддинг — числовой вектор, который отражает смысл текста. Близкие по смыслу фрагменты получают близкие векторы.
- Индексация. Векторы и сами тексты сохраняют в базу с поддержкой векторного поиска, например в PostgreSQL с расширением pgvector или в специализированную векторную базу. Рядом хранятся метаданные: источник, дата, отдел, уровень доступа.
Обработка вопроса
- Поиск. Вопрос пользователя тоже превращают в вектор и ищут самые близкие по смыслу фрагменты. Часто векторный поиск дополняют обычным полнотекстовым — так лучше находятся точные термины, артикулы и номера пунктов.
- Переранжирование. Найденные кандидаты дополнительно сортируют по релевантности, чтобы в ответ попали действительно подходящие фрагменты.
- Генерация. Языковая модель получает вопрос и отобранные фрагменты с инструкцией отвечать только по ним и ссылаться на источники.
- Ответ со ссылками. Пользователь видит ответ и ссылки на документы, из которых он собран, и может проверить формулировку в оригинале.
Если в базе нет ничего подходящего, правильно настроенная система так и отвечает: «в документах информации не найдено», а не придумывает.
Что можно сделать на базе RAG
Корпоративная база знаний — это не отдельный продукт, а основа для нескольких сценариев:
- Ассистент для сотрудников. Ответы по регламентам, кадровым политикам, инструкциям к внутренним системам. Особенно полезно для адаптации новичков.
- Помощник службы поддержки. Оператор получает подсказку с готовым ответом клиенту и ссылкой на статью базы знаний.
- Ответы клиентам на сайте и в мессенджерах. Ассистент отвечает по условиям доставки, гарантии, тарифам, опираясь на актуальные документы.
- Работа с договорами. Поиск похожих формулировок, проверка, что сказано про сроки и ответственность в конкретном договоре.
- Знания для AI-агента. Агент, который обрабатывает заявки, берёт из базы условия и прайс, чтобы ответить клиенту по делу. Такой сценарий мы описывали в статье про AI-агента для обработки заявок.
Доступ к базе знаний для разных AI-приложений удобно оформить через MCP-сервер — тогда одна и та же база работает и в чат-боте, и в агенте, и в ассистенте руководителя. Подробнее — в материале «Что такое MCP-сервер и зачем он бизнесу».
Из чего складывается качество ответов
Качество RAG-системы определяется не только выбором модели. Чаще всего ответы портятся на этапах, которые кажутся второстепенными.
Качество документов
Если в базе лежат три версии одного регламента и все противоречат друг другу, модель честно процитирует одну из них — не обязательно актуальную. Перед запуском стоит навести порядок: убрать устаревшее, отметить действующие версии, добавить даты.
Разбиение на фрагменты
Слишком мелкие куски теряют контекст: фрагмент «срок — 14 дней» без заголовка раздела бесполезен. Слишком крупные размывают поиск. Хорошая практика — резать по структуре документа и добавлять к каждому фрагменту заголовки разделов.
Поиск
Именно поиск чаще всего оказывается узким местом. Если нужный фрагмент не нашёлся, никакая модель не даст правильный ответ. Поэтому качество поиска проверяют отдельно — на наборе реальных вопросов сотрудников с заранее известными правильными источниками.
Инструкции модели
Модель нужно явно ограничить: отвечать только по предоставленным фрагментам, ссылаться на источник, честно говорить, если информации нет. Без таких инструкций она будет «дополнять» ответ общими знаниями.
Оценка и обратная связь
Кнопки «полезно / неполезно» и разбор неудачных ответов позволяют постоянно улучшать базу. Часто выясняется, что проблема не в системе, а в том, что нужного документа просто нет.
RAG или дообучение: что выбрать
Вопрос «а может, проще дообучить модель на наших данных?» возникает почти в каждом проекте. Короткий ответ: для задачи «отвечать по документам компании» в большинстве случаев подходит RAG, а дообучение решает другие задачи.
| Критерий | RAG | Дообучение |
|---|---|---|
| Обновление знаний | Заменили документ — ответы сразу актуальны | Нужно повторное обучение |
| Ссылки на источник | Есть, ответ можно проверить | Нет, модель «просто знает» |
| Учёт прав доступа | Фильтрация на этапе поиска | Практически невозможен |
| Стоимость старта | Ниже: модель используется как есть | Выше: подготовка данных и вычисления |
| Для чего подходит лучше | Факты, регламенты, условия, справочники | Стиль, формат ответов, узкая терминология |
Подходы не исключают друг друга. Иногда модель дообучают, чтобы она лучше понимала отраслевой язык или отвечала в нужном формате, а факты по-прежнему берёт из базы знаний через RAG. Но начинать почти всегда разумно с RAG: он быстрее даёт результат и проще в поддержке.
Безопасность и 152-ФЗ
Корпоративные документы часто содержат персональные данные, коммерческую тайну и сведения, к которым доступ есть не у всех. Это нужно учесть в архитектуре с первого дня.
- Права доступа. Система должна учитывать, кто задаёт вопрос. Сотрудник отдела продаж не должен получить в ответе фрагмент из документов бухгалтерии. Права проверяются на этапе поиска: фрагменты, к которым у пользователя нет доступа, вообще не попадают в модель.
- Где работает модель. Если в документах есть персональные данные граждан РФ, важно соблюсти требования 152-ФЗ, в том числе о локализации и о трансграничной передаче. Практичные варианты — российские модели вроде GigaChat и YandexGPT или открытые модели, развёрнутые на собственных серверах компании. Тогда данные не покидают контролируемый контур.
- Журнал запросов. Логи вопросов и ответов помогают разбирать ошибки и расследовать инциденты, но сами по себе содержат чувствительные данные — их хранение тоже нужно регламентировать.
Как внедрить корпоративную базу знаний на RAG
Проект обычно идёт в несколько этапов:
- Выбор сценария и источников. Определяем, кто будет пользоваться системой и какие вопросы задаёт. Собираем источники для пилота — лучше ограниченный, но качественный набор документов.
- Набор тестовых вопросов. Вместе с будущими пользователями составляем список реальных вопросов с правильными ответами. Это основа для оценки качества.
- Пилот. Подключаем документы, настраиваем поиск и модель, проверяем на тестовом наборе. Даём системе ограниченной группе сотрудников.
- Доработка. Разбираем неудачные ответы, улучшаем разбиение, поиск и инструкции, дополняем базу недостающими документами.
- Интеграция и масштабирование. Встраиваем ассистента туда, где люди работают: в корпоративный мессенджер, портал, CRM. Настраиваем автоматическое обновление базы при изменении документов.
Итог
RAG — практичный способ дать нейросети знания компании без дообучения: система находит нужные фрагменты документов, а модель отвечает по ним со ссылкой на источник. Успех такого проекта больше зависит от порядка в документах, качества поиска и продуманных прав доступа, чем от выбора конкретной модели. Начинать стоит с одного сценария и тестового набора реальных вопросов.
Если хотите собрать базу знаний с нейросетью для своей компании, посмотрите, как мы подходим к RAG и внедрению AI-решений. Расскажите в форме ниже, какие документы и для кого нужно подключить, — предложим архитектуру и план пилота.