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

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

Что учитывает разбиение

• Структуру документа. Раздел, пункт, подпункт идут вместе с заголовками верхнего уровня: фраза «срок десять дней» без названия раздела ничего не значит.
• Таблицы. Строку таблицы хранят вместе с шапкой, иначе в индексе остаются числа без названий столбцов.
• Редакции. Номер и дата редакции записываются в метаданные, а устаревшие помечаются, чтобы поиск мог их исключать.
• Размер и перекрытие. Короткие фрагменты точнее находятся, но не дают контекста; длинные дают контекст, но размывают поиск. Размер подбираем по эталонной выборке, а не берём из руководства.

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

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

• Права применяются до поиска. Фильтр по правам спрашивающего входит в сам запрос к базе. Если отфильтровать результат после поиска, из десяти найденных фрагментов могут остаться два, и ответ будет бедным, а в журнале всё равно останутся чужие фрагменты. Фильтр вместе с поиском избавляет от обоих эффектов.
• Обновление идёт по изменению. Новая редакция регламента заменяет старую в индексе, а не добавляется рядом. Источник сообщает об изменениях или конвейер сравнивает версии по расписанию, и мы договариваемся заранее, какой из способов подходит вашему хранилищу.
• Удаление реально удаляет. Документ, снятый с публикации или отозванный по требованию, удаляется из индекса вместе со всеми фрагментами. Это проверяется отдельным прогоном, потому что в индексе остаются следы документа, которые не видны в исходном хранилище.

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

У RAG-системы два независимых места ошибки, и измеряем их по отдельности, иначе непонятно, что чинить.

1. Поиск. Для каждого вопроса выборки известно, в каких документах лежит ответ. Смотрим, попал ли нужный фрагмент в число найденных. Если нет, дело в разбиении, эмбеддингах или фильтрах.
2. Ответ. Нужный фрагмент найден, но модель ответила неверно, не сослалась на источник или добавила лишнее. Это проблема шаблона запроса или самой модели.
3. Отказ. В выборку входят вопросы, на которые в базе ответа нет. Система должна сказать «не нашла», а не выдумать. Этот показатель считаем отдельно, потому что по нему видно главное: можно ли доверять системе.

Выборку собираем вместе с вами из реальных вопросов сотрудников или клиентов, а не придумываем. Часть вопросов не показываем при настройке и используем только в конце. После любого изменения (разбиение, модель эмбеддингов, шаблон запроса, новая модель) выборка прогоняется заново, и результаты сравниваются с предыдущими. Так замена модели не превращается в тихое ухудшение.

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

Готовый ассистент по документам для сотрудников описан на странице ИИ-ассистента по документам: если ваш случай укладывается в него, отдельная разработка не нужна. Если RAG — одна из частей приложения с агентами, интеграциями и собственным интерфейсом, смотрите разработку LLM-приложений.