RAG для бизнеса: как научить нейросеть отвечать по базе знаний компании

Как устроена RAG-система для корпоративной базы знаний: подготовка документов, разбиение, гибридный поиск и переранжирование, метрики качества, права доступа и 152-ФЗ, план внедрения и случаи, когда RAG не нужен.

Языковые модели хорошо пишут, переводят и рассуждают, но ничего не знают о вашей компании. Они не читали регламенты, договоры, инструкции к продуктам и переписку с клиентами. Когда сотрудник спрашивает модель о порядке согласования скидки или условиях возврата, она либо честно отказывается, либо — что хуже — уверенно придумывает правдоподобный ответ. RAG (Retrieval-Augmented Generation, генерация с дополнением из поиска) — самый практичный способ научить модель отвечать по внутренним документам компании. Ниже — как устроена такая система, из каких этапов она состоит, где она ломается, как проверять её качество и как подойти к внедрению так, чтобы через три месяца система отвечала точно, а не просто красиво. Что такое RAG простыми словами Идея укладывается в одно предложение: прежде чем отвечать, модель ищет подходящие фрагменты в базе знаний компании и отвечает на их основе. Процесс выглядит так: Пользователь задаёт вопрос. Система находит в базе знаний несколько фрагментов документов, которые с наибольшей вероятностью содержат ответ. Эти фрагменты вместе с вопросом передаются языковой модели с инструкцией отвечать только на их основе. Модель формулирует ответ и указывает, из каких документов взята информация. Модель в этой схеме работает как очень быстрый и грамотный сотрудник, которому на стол положили нужные страницы из архива. Она не помнит архив целиком — ей каждый раз приносят то, что относится к вопросу. Зачем RAG, если можно дообучить модель Это первый вопрос, который задают на старте, и ответ на него определяет архитектуру проекта. Дообучение меняет поведение, а не знания Дообучение (fine-tuning) хорошо учит модель стилю, формату ответов, терминологии и типовым реакциям. Но как способ «загрузить» в модель факты оно работает плохо: модель запоминает их неточно, смешивает с тем, что знала раньше, и не может сказать, откуда взяла конкретное утверждение. Знания устаревают, модель — нет Регламент обновили в понедельник. В RAG-системе достаточно заменить документ в базе, и со следующего вопроса ответы будут новыми. Дообученную модель пришлось бы переобучать, а до этого она продолжала бы уверенно цитировать старую версию. Проверяемость RAG-система может показать источник каждого утверждения. Для юридических, финансовых и медицинских ответов это не удобство, а обязательное условие: сотрудник должен иметь возможность открыть документ и убедиться, что модель поняла его правильно. Права доступа Разные сотрудники имеют доступ к разным документам. В RAG это решается на этапе поиска: система ищет только среди документов, доступных пользователю. В дообученной модели знания смешаны, и отделить то, что конкретному человеку видеть нельзя, невозможно. На практике подходы комбинируются: RAG отвечает за знания, дообучение или подробные инструкции — за форму ответа. Но начинать почти всегда разумно с RAG. Где RAG приносит пользу Внутренняя база знаний. Сотрудники задают вопросы по регламентам, политикам, инструкциям вместо поиска по десяткам папок и корпоративному порталу. Особенно заметен эффект при адаптации новых сотрудников. Поддержка клиентов. Бот или подсказки оператору по документации продукта, условиям тарифов, частым проблемам. Оператор получает черновик ответа со ссылкой на источник и проверяет его, а не ищет информацию с нуля. Работа с договорами и нормативкой. Поиск условий в массиве договоров, сравнение формулировок, ответы на вопросы о требованиях внутренних стандартов. Техническая документация. Инженеры и специалисты поддержки получают ответы по руководствам к оборудованию, схемам, журналам инцидентов. Продажи. Менеджер быстро находит характеристики продукта, отличия от конкурентов, условия поставки, примеры похожих сделок. Общий признак подходящей задачи: ответ существует в документах, но найти его долго, а цена ошибки или задержки ощутима. Архитектура RAG-системы Демонстрационная RAG-система собирается за день по любому руководству. Промышленная отличается от неё тем, что каждый этап продуман с учётом реальных документов, реальных вопросов и реальных ошибок. Разберём этапы по порядку. 1. Сбор и подготовка документов Самый недооценённый этап и главный источник проблем с качеством. Документы в компании хранятся в разных системах и форматах: файлы Word и PDF, сканы, страницы корпоративного портала, таблицы, письма, карточки в CRM. Что приходится решать: Извлечение текста. PDF с текстовым слоем, сканы без него, таблицы, многоколоночная вёрстка, колонтитулы, повторяющиеся на каждой странице. Плохо извлечённый текст не исправит ни одна модель: если таблица превратилась в мешанину чисел, правильного ответа по ней не будет. Актуальность. В архиве лежат три версии одного регламента. Если в базу попадут все, система будет отвечать то по старой, то по новой. Нужны правила, какая версия действующая, и процесс удаления устаревших. Метаданные. Тип документа, подразделение, дата вступления в силу, уровень доступа. Метаданные нужны для фильтрации при поиске и для отображения источника. Регулярное обновление. Система должна подхватывать изменения автоматически, иначе через два месяца база знаний разойдётся с реальностью. 2. Разбиение на фрагменты Документ целиком в модель не передают: он может быть огромным, а нужный ответ занимает абзац. Документы разбиваются на фрагменты, и искать система будет именно фрагменты. Размер фрагмента — компромисс. Слишком маленький теряет контекст: пункт «срок — 10 рабочих дней» без заголовка раздела не говорит, срок чего. Слишком большой размывает смысл при поиске и занимает место в запросе к модели. Практические приёмы: резать по структуре документа — разделам, пунктам, статьям договора, — а не по фиксированному числу символов; добавлять к каждому фрагменту заголовки разделов, в которые он входит, и название документа; делать небольшое перекрытие соседних фрагментов, чтобы мысль на границе не терялась; таблицы разбивать построчно с сохранением заголовков столбцов в каждой строке. 3. Векторные представления Каждый фрагмент преобразуется специальной моделью в вектор — набор чисел, отражающий смысл текста. Близкие по смыслу тексты получают близкие векторы, даже если в них разные слова. Благодаря этому вопрос «как оформить отпуск за свой счёт» находит пункт регламента «порядок предоставления отпуска без сохранения заработной платы». Для русского языка выбор модели векторизации важен: модели, обученные преимущественно на английском, заметно хуже различают оттенки смысла в русских текстах. Выбор стоит делать не по рейтингам, а по результатам на собственном наборе вопросов. 4. Хранилище Векторы хранятся в базе, умеющей быстро находить ближайшие к заданному. Это может быть специализированная векторная база или расширение для привычной СУБД — например, pgvector для PostgreSQL. Для большинства корпоративных баз знаний — до нескольких миллионов фрагментов — второго варианта достаточно, и он проще в эксплуатации: одна база вместо двух, привычные резервное копирование и права доступа. 5. Поиск Здесь решается, увидит ли модель нужный фрагмент. Если поиск его не нашёл, никакая модель не ответит правильно. Гибридный поиск. Векторный поиск хорошо ищет по смыслу, но плохо — по точным совпадениям: артикулам, номерам договоров, кодам ошибок, фамилиям. Классический полнотекстовый поиск делает ровно обратное. Промышленные системы используют оба и объединяют результаты. Переранжирование. Поиск возвращает, например, пятьдесят кандидатов, затем отдельная модель оценивает релевантность каждого вопросу точнее и оставляет лучшие пять-десять. Этот шаг заметно повышает точность при небольших затратах. Фильтры. Поиск ограничивается документами, доступными пользователю, действующими на текущую дату, относящимися к нужному подразделению или продукту. Переформулирование вопроса. Пользователи пишут коротко и с опорой на контекст разговора: «а для юрлиц?». Перед поиском вопрос дополняется контекстом диалога до самостоятельной формулировки. 6. Генерация ответа Найденные фрагменты передаются модели вместе с вопросом и инструкцией. Качество инструкции влияет на результат не меньше выбора модели. В ней фиксируется: отвечать только на основании переданных фрагментов; если ответа во фрагментах нет — прямо сказать об этом, а не додумывать; указывать источник для каждого утверждения; при противоречии между документами — показать оба варианта и назвать документы; формат, тон, длина ответа. 7. Интерфейс и обратная связь Ответ показывается вместе со ссылками на источники, которые можно открыть. Пользователь оценивает ответ, и эти оценки становятся главным материалом для улучшения системы. Без механизма обратной связи команда узнаёт о плохих ответах только из жалоб, то есть слишком поздно и слишком выборочно. Почему RAG-системы ошибаются Когда система отвечает неправильно, ошибка почти всегда относится к одному из четырёх типов. Разделять их важно, потому что лечатся они по-разному. Нужного документа нет в базе Ответ существует, но в другой системе, которую не подключили, или в голове опытного сотрудника. Лечится не настройкой модели, а расширением источников и работой с владельцами знаний. Документ есть, но поиск его не нашёл Самый частый тип ошибки. Причины: неудачное разбиение, отсутствие полнотекстового поиска для точных терминов, расхождение языка вопроса и документа («заморозка карты» и «временная блокировка платёжного инструмента»). Лечится улучшением разбиения, гибридным поиском, переранжированием, словарём синонимов. Фрагмент найден, но модель ответила неверно Модель неправильно поняла текст, смешала два фрагмента, проигнорировала оговорку. Лечится инструкцией, выбором более сильной модели, передачей фрагментов с большим контекстом. Модель ответила то, чего нет в документах Классическая «галлюцинация»: ответ правдоподобный, но выдуманный. Снижается инструкцией с прямым разрешением сказать «не знаю», требованием ссылаться на источник и автоматической проверкой, подтверждается ли каждое утверждение найденными фрагментами. Как измерять качество Фраза «система хорошо отвечает» ничего не значит, пока не выражена числами на фиксированном наборе вопросов. Без измерений каждое изменение настроек — лотерея: оно может улучшить ответы на одни вопросы и незаметно ухудшить на другие. Эталонный набор вопросов Основа оценки — набор из нескольких сотен реальных вопросов с правильными ответами и указанием документов, где эти ответы находятся. Вопросы собираются из обращений в поддержку, писем, чатов, интервью с сотрудниками. Важно включить трудные случаи: вопросы с опечатками, вопросы, на которые в базе нет ответа, вопросы, требующие объединить два документа. Метрики Полнота поиска. В какой доле вопросов нужный фрагмент попал в число переданных модели. Если она низкая, улучшать генерацию бессмысленно. Верность источнику. Подтверждается ли каждое утверждение ответа найденными фрагментами. Показывает склонность к выдумыванию. Правильность ответа. Совпадает ли ответ по смыслу с эталонным. Оценивается экспертами на выборке и автоматически — сильной моделью в роли проверяющего, откалиброванной по экспертным оценкам. Корректный отказ. Как часто система честно говорит «в документах нет ответа», когда его действительно нет. Скорость и стоимость ответа. Время до первого слова и стоимость обработки одного вопроса. Процесс Каждое изменение — новая модель векторизации, другое разбиение, правка инструкции — прогоняется по эталонному набору до выкладки. Изменение принимается, если улучшает целевые метрики и не ухудшает остальные. Эталонный набор пополняется вопросами, на которые пользователи поставили низкую оценку. Безопасность и данные в российских условиях Где обрабатываются данные При использовании облачной модели фрагменты документов и вопросы пользователей передаются провайдеру. Если в документах есть персональные данные, коммерческая тайна или сведения, на которые распространяются отраслевые требования, это нужно решить до начала проекта, а не после пилота. Варианты: российские облачные модели с обработкой данных на серверах в России; открытые модели, развёрнутые в собственном контуре компании или у облачного пр