Как адаптировать RAG-приложение к корпоративной специфике для обработки сложных запросов?

Корпоративный чат-бот становится обычным делом, как и корпоративный портал

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

Универсальные модели обладают «общими знаниями», но лишены информации о внутренних процессах, терминологии и отраслевых особенностях конкретной организации.

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

Возникает вопрос: как эффективно адаптировать RAG-решение под уникальные требования и знания конкретной компании?

Три ключа к успеху: умное разбиение документов, целевое дообучение и продуманная обработка запросов

1. Стратегии разбиения текста

Если в вашей компании документы хорошо структурированы (например, формуляры), то рекомендуется разработка специализированных алгоритмов фрагментирования. Для остальных случаев обычно используют один из самых распространенных методов – делят текст на равные части с небольшим перекрытием фрагментов.

Для своих целей мы реализовали собственное умное разбиение:

1) Семантическое/структурно-осознанное фрагментирование – алгоритм учитывает заголовки, разделы, таблицы, списки и понимает, где заканчивается один раздел и начинается другой.

2) Разный размер для разных задач – для ответов на вопросы берутся небольшие фрагменты, для аналитики – крупные и цельные.

3) Хорошие и структурированные метаданные – это помогает точнее искать и фильтровать информацию.

2. Дообучение (fine tuning) моделей

В первую очередь стоит дообучить Embedding модель, которая преобразует тексты в векторы (числовые представления) и ищет по ним. Ее обучают на тех же документах, которые составляют базу знаний компании. Периодически можно дообучать модель на новых данных. Это влечет за собой переиндексацию базы знаний, но и точность поиска значительно вырастет.

Частичное дообучение самой языковой модели (тренировки Low-Rank Adaptation) имеет смысл, только если ответы должны всегда следовать строгому шаблону, фирменному стилю или конкретной форме (как в чек-листах). Это дешевле полного обучения и часто этого достаточно.

В настоящее время каждые 3-6 месяцев появляются новые, более сильные и подходящие модели, разумнее протестировать и заменить старую модель на новую, а не тратить силы на ее дообучение (полное или частичное).

*по данным ResearchGate

3. Собственный конвейер обработки запроса (query pipeline)

При построении безопасных AI-решений, работающих внутри IT-контура компании, появляются ограничения на GPU-ресурсы.

Запускать большие модели внутри компании – дорого и не всегда оправданно. Поэтому мы советуем остановиться на компактных моделях (до 32 миллиардов параметров), например, Qwen3. Они поддерживают несколько языков и способны давать качественные ответы на основе предоставленной информации и специфики компании.

Именно в этот момент на первый план выходит качество и полнота выборки. После умного фрагментирования документов и дообучения поисковой модели нужно понять, как обеспечить качественный поиск и полноту?

Ответ на этот вопрос прост – надо задать query и терминологию так, чтобы при поиске по ним выдавалась вся необходимая информация. То есть нужно перевести вопросы пользователя на язык документов и правильно сформулировать дополнительные запросы.

Например, тестовый вопрос для авиакомпании у нас звучал так: «Как оформить билет пассажиру с ограничением по здоровью по льготе, его жену за мили, детям 1 и 10 лет за наличные и еще указать перевозку собаки в салоне и доп.багаж?»

Просто отправить исходный вопрос в поиск – мало. Нужные фрагменты текста могут быть в документах на разные темы. Нужно уметь «спросить» о каждый из этих тем по отдельности.

Разберем наш пример. В одном вопросе спрятано несколько независимых тем:

• Оформление субсидированной перевозки 
• Оформление сопровождающего лица
• Оформление по системе лояльности
• Перевозка младенцев
• Перевозка детей
• Оформление услуги по перевозке животного в салоне
• Прием наличных платежей
• …

Чтобы правильно «приземлить» вопрос в специфику компании, мы реализовали конвейер по обработке запроса и выдачи дополнительных запросов для качественного поиска:

1. Переводим на корпоративный язык – система дополняет или расшифровывает слова пользователя до официальных терминов: «особые категории пассажиров», «сопровождающее лицо» и тд.
2. Определяем темы – алгоритм находит все затрагиваемые области: «субсидированные перевозки», «дополнительные услуги», «способы оплаты».
3. Уточняем детали – для каждой темы определяются подтемы: например, для дополнительных услуг - «перевозка животного в салоне», для способов оплаты - «оплата бонусными милями».
4. Задаем уточняющие вопросы – система сама додумывает контекст и при необходимости уточняет детали. Например, «Нужно ли отдельное место для младенца?».
5. Формируем пакет запросов (query) – на основе всего вышеперечисленного создается набор поисковых запросов, гораздо более полный, чем исходный вопрос.
6. Собираем ответ – модель не просто говорит «нельзя», а предлагает решения: «Оформите перелет как субсидированную перевозку, а дополнительные услуги оплатите милями по системе лояльности».

Такой подход, с одной стороны, не дает системе искать то, чего не существует в наших правилах (например, неиспользуемые способы оплаты), а с другой – гарантирует, что она найдет все возможные варианты и предложит их пользователю.

С какими сложностями придется столкнуться

• Рост затрат на MLOps/контент-инжиниринг. Нужно постоянно обновлять конвейер: парсить документы, перестраивать поиск при изменениях, следить за качеством.
• Зависимость от правил. Чем жестче вы привяжете систему к своим процессам, тем чаще придется обновлять ее «словарный запас» при появлении нововведений.
• Необходимость постоянной проверки. После запуска нужны тесты и метрики для каждой версии системы. Дополнительно можно собирать базу эталонных ответов от экспертов для автоматической проверки качества.

Что дает такой подход

• Полные и точные ответы на сложные вопросы – собственный конвейер обработки запроса и многоступенчатый поиск улучшают покрытие и позволяют даже маленькой модели уверенно отвечать на сложные вопросы.
• Ответы составляются по правилам – чат-бот будет строго следовать регламентам, меньше «выдумывать», из-за чего растет доверие бизнеса. Дополнительно к этому бизнес проводит постоянный системный анализ процессов, стандартов и терминологической базы.
• Единые правила для всех – все сотрудники получают одинаково точные ответы с учетом их прав доступа. Это снижает риски и издержки, повышает прозрачность и ускоряет работу сотрудников.