Разработка RAG-системы (Retrieval-Augmented Generation)

Разработка RAG-системы: где ломается поиск ответов

Корпоративный ассистент по внутренней документации ломается не на генерации, а раньше — на этапе поиска. Модель формулирует ответ гладко и уверенно, но если в контекст попали не те фрагменты, гладкость только маскирует ошибку. Поэтому разработка RAG-системы начинается с диагностики корпуса и стратегии извлечения, а не с выбора модели.

Мы разбираем четыре точки отказа, которые встречаются почти в каждом проекте.

• Разрозненный корпус. Регламенты лежат в wiki, договоры — в файловом хранилище, переписка — в почте. Пока нет единой схемы метаданных и владельца у каждого набора, поиск по базе знаний не может отфильтровать нужный раздел и возвращает смесь из разных областей.
• Поиск по точным словам. Лексическое совпадение вроде BM25 в Elasticsearch не видит синонимов и перефразировок: «отпуск» и «ежегодный оплачиваемый отдых» для него разные слова, и половина релевантных документов остаётся за бортом.
• Ответы без источника. Если ответы со ссылкой на источник не встроены в выдачу по умолчанию, проверить утверждение нельзя. Сотрудник либо идёт читать документ сам, либо перестаёт пользоваться ассистентом.
• Устаревшие копии. Несколько редакций одного документа в индексе дают противоречивые ответы, а правка в источнике не доезжает до поиска: ассистент цитирует отменённую версию.

Каждая из этих точек закрывается на уровне подготовки данных и схемы индекса, а не формулировки запроса к модели. Ниже — как мы выстраиваем этот слой.

Что меняется после запуска: скорость и класс отказов

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

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

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

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

Варианты архитектуры: сравнение подходов к поиску

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

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

Этапы внедрения: от аудита корпуса до передачи

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

1. Аудит корпуса документов. Смотрим форматы, дубли, редакции, срок годности и права доступа. На выходе — карта корпуса с долей пригодных к индексации материалов и списком того, что придётся чистить или дописывать.
2. Схема контуров. Разделяем поиск и генерацию: что отдаём в индекс, что уходит в модель, где стоит фильтр по правам пользователя. Так ответ не соберётся из документов, недоступных конкретному сотруднику.
3. Подготовка данных и сборка поискового индекса. Нарезка на фрагменты по смысловым границам, векторные представления, гибридный поиск с переранжированием. Мелкие фрагменты дают точность, крупные — контекст; баланс подбираем по замерам.
4. Настройка ответов. Системная инструкция, правила цитирования, поведение при отсутствии данных: система говорит «в базе нет», а не достраивает факты. Отдельно описываем, как обрабатываются противоречия между редакциями.
5. Тестирование ответов на реальных вопросах. Набор эталонных вопросов от ваших сотрудников, включая каверзные и пограничные. Считаем долю корректных ответов со ссылкой, долю честных отказов и разбираем каждую ошибку до причины.
6. Передача. Конфигурации, регламент обновления корпуса, скрипты переиндексации, метрики и инструкции для поддержки. После передачи команда заказчика может добавлять документы, не ломая качество ответов.

Что передаём на руки: индекс, схемы, регламенты

Передача решения — не архив с исходниками, а комплект, по которому ваша команда сможет сама эксплуатировать и развивать систему. Что физически окажется у вас на руках:

• Рабочий контур — развёрнутая система, конфигурации сервисов, доступы к хранилищам, порядок резервного копирования и восстановления.
• Схема интеграций — какие источники подключены, в каком формате забираются данные, как часто синхронизируются и что происходит при недоступности источника.
• Устройство индекса — правила нарезки документов на фрагменты, состав метаданных, порядок фильтрации выдачи по правам пользователя.
• Роли доступа — кто загружает документы, кто меняет настройки выдачи, кто видит журналы; ограничения работают на уровне индекса, а не интерфейса.
• Регламент обновления индекса — расписание полной и частичной переиндексации, удаление устаревших документов, порядок отката к предыдущему состоянию.
• Мониторинг и журналы — метрики качества и скорости ответов, оповещения о деградации, сроки хранения истории запросов.
• Документация по системе — архитектурные схемы, инструкции поддержки по типовым отказам, набор эталонных запросов для проверки после изменений.

Комплект остаётся живым: при смене источников или модели обновляем схемы и регламенты, чтобы документация не расходилась с реальным состоянием системы.

Кейс: ответы по регламентам вместо ручного поиска

Внутренняя база знаний производственного холдинга «Северный контур» — около 4 000 документов: регламенты, приказы, инструкции по охране труда, шаблоны договоров. Сотрудники искали по ключевым словам и названиям файлов, поэтому ответ на типовой вопрос занимал 15-25 минут, а спорные случаи всё равно уходили юристу или в кадры. В базе при этом лежали устаревшие редакции, и находились они наравне с действующими.

Что изменили

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

Что стало

Доля вопросов, закрытых без эскалации, выросла с 38% до 79%, медиана времени до ответа — с 20 минут до 40 секунд. Точность попадания в нужный пункт на контрольной выборке — 9 из 10 обращений. Оставшиеся промахи приходятся на ситуации, где регламенты противоречат друг другу: такие случаи система помечает как конфликт и не выбирает сторону за человека. Внедрение заняло шесть недель — две на разбор корпуса и разметку статусов, две на сборку и настройку выдачи, две на пилот в двух отделах с замером метрик.

Чем отличается RAG-поиск от дообучения модели?

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

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

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

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

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

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

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

У сотрудников разные права доступа — система это учтёт?

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

Можно ли не выпускать данные за периметр?

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

Как понять, что качество ответов не упало?

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

Придётся перестраивать текущие системы?

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

Обсудим задачу и вернёмся с планом и оценкой

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

• Какие документы и базы попадают в поиск: форматы, примерный объём, кто отвечает за их актуальность.
• 10–20 реальных вопросов пользователей и эталонные ответы на них — по ним настраивается качество.
• Где система будет работать: ваш контур или внешняя инфраструктура, требования к доступам и аудиту обращений.
• Сценарии использования: кто спрашивает, как часто, что считаем верным ответом, а что — корректным отказом.
• Какие системы нужно связать: портал, CRM, мессенджеры, внутренние сервисы, справочники.
• Кто со стороны заказчика принимает результат и по каким критериям.

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

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