Превращение корпоративных регламентов в структурированные знания: опыт построения RAG-сервиса

# От «научного» RAG к измеримому промышленному процессу

В крупных компаниях сотрудники ежедневно сталкиваются с необходимостью быстро находить ответы в сотнях внутренних регламентов. Задача создать «Помощника для сотрудника», который на основе нормативных актов дает точные ответы со ссылками, казалась стандартной задачей для RAG-систем. Однако на практике выяснилось, что простой загрузки текста в векторную базу недостаточно. Нормативные документы с их сложной структурой, таблицами и канцелярским языком требуют принципиально иного подхода к подготовке данных.

В статье рассматривается кейс миграции от наивной архитектуры на n8n и Qdrant до гибридной системы, использующей специализированные модели для извлечения, индексации и ранжирования фрагментов. Ключевой вывод: в production-среде важнее не выбор самой мощной языковой модели, а качество preprocessing документов и надежность механизма retrieval.

Почему стандартный чанкер разрушает смысл регламентов

Корпоративные документы имеют уникальную семантику. Правило часто существует только на стыке заголовка таблицы, названия колонки и значения в ячейке. Стандартный алгоритм нарезки текста (chunking) по фиксированному числу символов разбивает такие логические блоки на осколки. В результате модель может найти число «4» в ответе на вопрос о сроках, но не понять контекст, из-за чего ответ будет фактически неверным, даже если модель не выдумала ничего лишнего.

Автор проекта предложил отказаться от жёстких границ по символам в пользу структурно-осознанного чанкинга (structure-aware chunking). Документ разбивается на логические единицы: раздел, подраздел, абзац. Размер чанка становится ориентиром, но не абсолютным правилом: лучше получить чанк на 1400 символов, содержащий целую таблицу, чем два идеальных фрагмента по 700 символов, разрывающих смысловую связь.

Кроме того, для нормативных текстов вреден механизм перекрытия (overlap), который в обычных статьях помогает сохранить контекст перехода мысли. В регламентах же соседство разных пунктов (например, 5.3 и 5.4) может привести к захламлению контекста релевантными, но нефактическими данными. Решение — сохранять целостность разделов и избегать дублирования.

Гибридный поиск и обработка сложного контента

Векторный поиск, основанный на embeddings, отлично работает для семантического сходства, но терпит неудачу при запросах, требующих точного совпадения терминов или цифр. Для решения этой проблемы была внедрена гибридная архитектура retrieval, объединяющая:

1. Lexical search (BM25 + FTS5): Позволяет находить документы по точным формулировкам и лемматизированным словам. Используется словарь Natasha для нормализации корпусов, чтобы формы слова «согласовать», «соглашение» и «согласованный» воспринимались системой как родственные. 2. Dense retrieval: Семантический поиск через векторные индексы для понимания смысла. 3. RRF (Reciprocal Rank Fusion): Алгоритм объединения результатов лексического и векторного поиска в единый рейтинг. Это позволяет использовать независимые метрики ранжирования без попытки привести их к общему знаменателю. 4. Reranking: Дорогостоящий этап, запускаемый только для финальной выборки кандидатов. Специализированная модель bge-reranker-v2-m3 оценивает релевантность пары «запрос — фрагмент» более глубоко.

Для работы со схемами, изображениями и сложными визуальными элементами в документах была добавлена мультимодальная модель Qwen3.6. Весь корпус документов приводится к единому Markdown-формату, что позволяет сохранять иерархию заголовков, списков и таблиц, что критически важно для понимания контекста моделью.

Эксперимент: как реранкер изменил качество ответов

Для объективной оценки эффективности внедренных изменений была создана система измерения качества через Arize Phoenix и метод LLM-as-a-Judge. Сформировался золотой датасет с эталонными ответами и указанием конкретных фактов и разделов. Проведен A/B-тест с 20 контрольными вопросами, запущенный трижды для каждой конфигурации.

Сравнение было проведено между системой без реранкера и системой с ним. Результаты A/B-теста показали значимое улучшение ключевых метрик:

* Recall@5: Вырос с 0,285 до 0,464 (+63%). Это означает, что после применения реранкера в топ-5 результатов попадало почти в два раза больше необходимых фрагментов. * MRR@5 (Mean Reciprocal Rank): Увеличился с 0,531 до 0,814. Самые важные куски текста переместились выше в списке результатов. * Context Recall: Самый показательный рост — с 0,501 до 0,768. До внедрения реранкера LLM получала лишь половину необходимых фактов, после — около 77%. Именно этот показатель стал главным ограничителем (bottleneck) качества генерации. * Correctness: Правильность ответов выросла с 0,377 до 0,586 (+55%).

Важно отметить, что метрика Faithfulness (верность контексту) изменилась незначительно (с 0,973 до 0,984), что подтвердило гипотезу: основная проблема системы заключалась не в склонности LLM выдумывать факты, а в неспособности retrieval-модуля предоставить ей все необходимые данные для формирования полного ответа.

Заключение

Проект показал, что построение качественного RAG-сервиса — это долгая цепочка процессов, где генерация ответа является лишь финальным этапом. Успех зависит от правильной подготовки знаний, нормализации структуры документов и использования специализированных инструментов для поиска и ранжирования. Операционные расходы на инфраструктуру, включая использование мощных GPU для инференса моделей, оправданы только при наличии надежной системы оценки и итеративного улучшения pipeline.