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

Что произошло

За последние два года корпоративный поиск на основе больших языковых моделей прошёл путь от эксперимента до строки в бюджете. Схема RAG (retrieval-augmented generation — генерация с опорой на найденные документы) стала стандартным ответом на вопрос «как заставить модель отвечать по нашим документам, а не по интернету». Собрать демонстрацию на нескольких десятках чистых PDF-файлов — задача на неделю для одного инженера.

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

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

Демо проверяет, умеет ли модель отвечать. Прод проверяет, умеет ли компания поддерживать документы в состоянии, по которому можно отвечать.

Как устроен RAG и где он ломается

Пайплайн индексации: парсинг, чанки, эмбеддинги, векторная база

Индексация — это конвейер из четырёх этапов, и каждый вносит свои потери.

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

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

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

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

Права доступа: фильтрация до поиска

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

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

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

Устаревшие регламенты и проблема версии

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

Решение не в модели. В метаданных чанка должны быть статус документа (действует, отменён, проект), дата начала действия, дата отмены и ссылка на документ-преемник. Поиск по умолчанию фильтрует только действующие. Но эти поля откуда-то должны взяться: если в компании нет практики регистрировать статус документа при утверждении и отмене, индекс их не получит. Это и есть точка, где качество поиска упирается в документооборот.

Реранжирование и ответ со ссылкой на пункт

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

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

Обновление индекса

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

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

Как это выглядит на практике

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

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

Сеть клиник, клинические протоколы и внутренние стандарты. Корпус небольшой, но обновляется часто, и цена ошибки высока. Здесь главным решением стало правило отказа: если реранкер не уверен, система не отвечает, а показывает список документов, где стоит искать. Пользователи приняли такую систему быстрее, чем «умную», потому что она не подводила.

Что это значит для российской компании

Закрытый контур. Для большинства российских компаний среднего и крупного бизнеса отправка внутренних документов во внешний облачный сервис исключена — по требованиям 152-ФЗ в части персональных данных, по режиму коммерческой тайны, а для субъектов КИИ — по требованиям регулятора. Это означает, что и модель эмбеддингов, и реранкер, и генеративная модель разворачиваются внутри периметра. Технически это решаемо: открытые модели с достаточным качеством на русском языке существуют, а сервер инференса vLLM позволяет обслуживать их на собственных GPU с приемлемой пропускной способностью.

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

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

Документооборот. Наличие СЭД с обязательными реквизитами документов, регламент утверждения и отмены, единое место хранения действующих редакций — это не ИТ-инфраструктура, а управленческая практика. В компаниях, где она есть, RAG внедряется за квартал. Там, где её нет, проект превращается в наведение порядка в документах, и его надо так и планировать.

Что делать: пошагово

1. Проведите инвентаризацию корпуса до выбора технологии. Сколько документов, в каких форматах, какая доля сканов, сколько документов имеют владельца и статус. Результат — таблица по типам документов с оценкой готовности к индексации.
2. Определите модель прав. Откуда берутся права на каждый источник, как они попадают в метаданные индекса и с какой периодичностью синхронизируются. Зафиксируйте, что фильтрация выполняется в запросе, до поиска.
3. Введите обязательные реквизиты документов. Статус, дата начала действия, владелец, документ-преемник при отмене. Заведите их в СЭД или в реестре, если СЭД нет. Без этого шага остальные бесполезны.
4. Соберите эталонный набор вопросов. Одна-две сотни реальных вопросов от будущих пользователей с ожидаемыми ответами и ссылками на документы. Это критерий приёмки и инструмент регрессионного тестирования при каждом изменении.
5. Постройте конвейер индексации с сохранением структуры. Парсинг с восстановлением заголовков и таблиц, чанкинг по структуре, метаданные на каждом чанке, автоматическое инкрементальное обновление с обработкой удалений.
6. Добавьте гибридный поиск, реранкер и правило отказа. Ответ всегда со ссылкой на документ и пункт. Если уверенность ниже порога — система показывает список документов вместо ответа.
7. Разверните модели в контуре и проведите приёмку на эталоне. Зафиксируйте долю правильных ответов, долю обоснованных отказов и долю ошибок. Договоритесь о целевых значениях до запуска.
8. Назначьте владельца корпуса и регламент сопровождения. Кто отвечает за актуальность документов, кто разбирает жалобы пользователей на неверные ответы, как часто пересматривается эталонный набор.

Типичные ошибки

• Начинать с выбора векторной базы и модели. Почему: архитектурные различия дают проценты, а состояние корпуса — разы. Что вместо: начинать с инвентаризации документов и модели прав.
• Фильтровать права после поиска. Почему: утечки через контекст и пустые выдачи для пользователей с узкими правами. Что вместо: фильтр по субъектам доступа в запросе к векторной базе, синхронизация прав с источником.
• Индексировать «всё, что есть». Почему: старые редакции, черновики и дубликаты конкурируют с действующими документами и выигрывают. Что вместо: индексировать только документы со статусом «действует», остальное — по явному запросу.
• Принимать систему по впечатлению. Почему: несколько удачных ответов на демонстрации не говорят ничего о доле ошибок на реальном потоке. Что вместо: приёмка на эталонном наборе с зафиксированными метриками.
• Запрещать системе отказываться от ответа. Почему: модель, обязанная ответить всегда, отвечает правдоподобной выдумкой. Что вместо: порог уверенности и честный отказ со списком документов.

Как понять, что вы на верном пути

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

Вопросы, которые нам задают

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

Насколько большая модель нужна для генерации ответа в закрытом контуре? Меньше, чем кажется. Если поиск и реранкер работают хорошо, генеративной модели остаётся пересказать несколько релевантных фрагментов и поставить ссылку. С этим справляются открытые модели среднего размера, которые обслуживаются через vLLM на одной-двух GPU. Большая модель не компенсирует плохой поиск: она лишь убедительнее излагает неверный ответ.

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

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