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

Зачем вообще готовить документы перед RAG

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

Когда данные «грязные», поиск находит не тот фрагмент или подтягивает куски без контекста. В итоге RAG может цитировать таблицу без заголовка, вытаскивать старую редакцию регламента или собирать ответ из двух похожих документов, которые на самом деле противоречат друг другу.

Обычно это видно по простым симптомам:

• «Не находит», хотя документ точно есть.
• «Цитирует не то», подставляя похожий абзац из другого файла.
• «Путает версии», отвечая по устаревшему приказу или договору.
• Дает слишком общие ответы, потому что текст после плохого OCR превратился в «мусор».

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

Подготовка нужна еще и для управляемости. Когда ответы должны быть предсказуемыми, заранее договоритесь о ролях и ответственности: владелец контента решает, что является «истиной» и что можно публиковать; ИБ определяет, что можно индексировать и кому показывать; архив или документооборот задает правила хранения и статусы «черновик/действует/утратил силу»; ИТ настраивает конвейер (OCR, очистку, индексацию, обновления).

Если эти правила не зафиксированы, RAG быстро превращается в «поиск по всему», где точность зависит от удачи, а не от данных.

Инвентаризация: что у вас есть и где это лежит

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

Обычно документы расползаются по файлообменникам и сетевым дискам, почте, ECM/EDM-системам, архивам в отдельных папках, а иногда и по личным каталогам сотрудников. Важно зафиксировать не только место, но и механизм обновления: кто добавляет файлы, как часто, есть ли согласование.

Дальше разложите контент по типам. Для корпоративной базы это часто приказы и распоряжения, регламенты и политики, договоры и допсоглашения, инструкции и чек-листы, служебные письма и переписка. Для каждой группы заранее выберите «источник правды» - один канал, который считается главным при конфликте версий. Например, подписанный PDF в ECM может быть источником правды для приказов, а для инструкций - утвержденная страница в базе процедур.

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

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

Пример: у производственной компании вроде GSE.kz регламенты сервисной поддержки и 24/7 процессов могут лежать на сетевом диске, а приказы и документы для закупок - в ECM. Если не зафиксировать источник правды, RAG легко начнет цитировать черновик из общей папки вместо утвержденной версии.

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

OCR: как сделать текст пригодным для поиска и цитирования

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

Как выбрать OCR и настроить единые правила

Выбирайте движок не по демоверсии, а по вашим типовым документам. В корпоративной подготовке к RAG обычно критичны языки (русский, казахский, английский), качество на таблицах и поддержка PDF, где вперемешку есть и цифровой текст, и сканы.

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

• Качество входа: чаще всего 300 dpi хватает; хуже 200 dpi дает много ошибок на мелком шрифте.
• Геометрия страницы: поворот, перекос, обрезка полей.
• Шумы: фон, печати, полосы от сканера, серый фон.
• Правила для многостраничных PDF: что считается одним документом и как хранить страницы.
• Таблицы: режим, который сохраняет структуру хотя бы на уровне строк и столбцов.

Пример: если у вас есть сканы спецификаций на серверы и акты приемки, одна неверно распознанная цифра в модели, объеме RAM или количестве узлов меняет смысл ответа. Таблицы и числа стоит проверять строже, чем обычный текст.

Что сохранять и как контролировать качество

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

Качество удобно фиксировать простыми метриками, которые легко автоматизировать: доля «мусорных» символов, подозрительные пропуски, частота ошибок в числах (например, 0/O, 1/I), процент страниц, где текста почти нет.

Минимальный лог на каждый файл помогает разбирать инциденты и повторять обработку одинаково:

• Дата и время обработки.
• Версия OCR-движка и профиль настроек.
• Язык(и) распознавания.
• Статус (успех, частичный успех, ошибка) и причина.
• Оценка качества (например, процент «мусора» или флаг «нужна проверка»).

Так OCR перестает быть «черным ящиком» и становится контролируемым этапом, на который можно опираться при поиске и цитировании.

Очистка текста: меньше шума, больше смысла

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

Сначала приведите текст к нормальному виду: единая кодировка (например, UTF-8) и удаление «битых» символов, склейка переносов внутри предложений при сохранении абзацев, нормализация пробелов и табов, удаление служебной нумерации страниц и разделителей вроде "Page 3 of 12", приведение маркеров списков к единому стилю, чтобы пункты не «ломались».

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

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

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

Важно не переочистить. Не удаляйте то, что люди используют как опоры: даты и номера приказов/договоров, ссылки на пункты («п. 4.2», «раздел 7»), обозначения версий и редакций, коды и инвентарные номера, примечания с исключениями («кроме случаев...»).

Пример: в регламенте на 40 страниц шапка с названием отдела повторяется вверху, а внизу стоит «Стр. X». Убираем шапку и «Стр.», но сохраняем «Редакция 2 от 12.03.2024» и ссылки вида «см. п. 3.1». Тогда RAG отвечает по делу и может корректно сослаться на нужный пункт.

Дедупликация: чтобы ответы не повторяли одно и то же

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

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

Как находить дубли

Лучше сочетать несколько методов, потому что один способ не ловит все случаи:

• Хэш файла (точные копии байт-в-байт).
• Хэш нормализованного текста (после OCR и очистки).
• Сравнение похожести текста (для «почти копий»).
• Сопоставление ключевых полей (название, номер, дата, подразделение, автор).
• Отдельная обработка вложений из почты и тел писем.

После обнаружения дублей важно не просто «удалить лишнее», а сохранить связь «оригинал - копии». Храните список источников (где найдено), даты загрузки и, если возможно, идентификатор документа в системе (например, номер приказа или договора). Это помогает объяснить пользователю, почему показывается именно этот файл.

Как выбрать, что показывать

Заранее задайте правила приоритета: актуальная утвержденная версия выше черновика; оригинал из DMS/ECM выше пересланной копии из письма; файл с понятными метаданными выше «безымянного скана»; полный документ выше неполного.

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

Версионирование: как не отвечать по устаревшим документам

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

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

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

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

Историю лучше хранить как понятную цепочку: документ A заменен документом B, а B заменен C. Тогда даже если пользователь спросит «почему изменилось правило», вы сможете ответить по актуальной редакции и при необходимости показать, что именно было заменено.

Пример: в ИТ-службе обновили регламент по выдаче рабочих станций. Если в базе лежат два файла «Регламент_2023» и «Регламент_2024» без статусов и даты вступления, RAG может процитировать старые сроки или список ответственных. Если же у версии 2023 стоит «отменен», а у 2024 - «действует» и заполнено поле «заменяет», ответы будут предсказуемыми даже при похожих формулировках.

Метаданные: что добавить, чтобы поиск был предсказуемым

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

Минимальный набор лучше зафиксировать как стандарт. Обычно достаточно, чтобы у каждого файла были одинаковые базовые поля: тип документа (регламент, инструкция, договор, письмо, отчет), подразделение-источник и владелец, дата выпуска и версия, статус (черновик, действует, отменен), идентификатор (номер, код, тикет - если есть).

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

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

• уровень доступа (внутренний, только отдел, только руководство);
• класс конфиденциальности (обычный, ДСП, коммерческая тайна);
• срок хранения и дата пересмотра;
• применимость (например, сектор: образование, финансы, госсектор);
• язык документа.

Самая частая причина хаоса - разные написания одного и того же. Спасают единые справочники (контролируемые списки): названия отделов, систем, продуктов, регионов, типов документов. Тогда «ИТ-департамент», «IT» и «ДИТ» не превращаются в три разных фильтра.

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

Фрагментация для RAG: чтобы модель находила нужный кусок

Фрагментация (chunking) решает простую задачу: модель должна видеть не весь документ целиком, а тот кусок, где есть ответ, и при этом не терять смысл. Это часть подготовки, которая сильнее всего влияет на предсказуемость поиска.

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

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

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

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

Иногда помогает разнести индексы по типам контента. Политики и приказы лучше искать отдельно от техподдержки и переписки, а технические руководства - отдельно от закупочных шаблонов. Так меньше шума, и ответы получаются стабильнее.

Доступ и безопасность: чтобы RAG отвечал только по разрешенному

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

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

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

Отдельно храните и индексируйте «особые» категории: персональные данные, финансы, медицина, служебная тайна. Для них обычно нужны более жесткие правила доступа, сокращенный срок хранения, маскирование полей (например, ИИН/телефон), а иногда и полный запрет на использование в RAG.

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

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

Частые ошибки и ловушки при подготовке базы знаний

Самые дорогие проблемы обычно начинаются не с модели, а с того, как устроена подготовка документов к RAG. Если база собрана «как получилось», ответы будут то точными, то странными, и вы не сможете объяснить почему.

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

Не менее опасны смешанные версии. В папках лежат «финал», «финал2», «последний», и RAG отвечает по любому из них. Если нет статуса (черновик, действующий, архив) и владельца, системе нечем руководствоваться. На практике это приводит к ответам по устаревшим регламентам или формам, что особенно болезненно в закупках, кадровых правилах и ИБ.

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

Признаки, что подготовка пошла не туда:

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

Поймать это можно простыми проверками, без сложной аналитики. Прогоните 10-15 реальных вопросов пользователей и проверьте, совпадают ли источники с ожиданиями. Затем сделайте выборочную ручную проверку.

Быстрые тесты, которые обычно ловят 80% проблем:

• запрос по точной фразе из документа и сравнение с найденным фрагментом;
• поиск по номеру документа, дате, ИНН, сумме и проверка распознавания;
• проверка одного документа в трех местах: оригинал, OCR-текст, фрагменты для RAG;
• сравнение двух версий одного регламента по ключевым пунктам;
• просмотр топ-20 самых цитируемых источников на предмет «мусора» и дублей.

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

Чек-лист, пример и следующие шаги

Перед индексацией сделайте быстрый прогон по базе знаний. Это экономит дни отладки, когда RAG внезапно цитирует «мусор» из сканов или путает версии.

Короткий чек перед загрузкой в индекс:

• OCR проверен: текст копируется, кодировка нормальная, таблицы и заголовки читаемы.
• Очистка сделана: убраны колонтитулы, повторяющиеся шапки, пустые страницы, битые символы.
• Дубли сняты: одинаковые файлы и почти одинаковые копии сведены к одному источнику.
• Версии размечены: понятно, какой документ актуален, а какой архив.
• Метаданные и доступ настроены: владелец, дата, подразделение, тип документа, уровни прав.

Дальше нужна простая проверка качества, пока все еще дешево исправлять. Возьмите 10-20 типовых вопросов от реальных пользователей и заранее выпишите, какие документы (и какие разделы) должны быть источником ответа. Если ответ ссылается на другое, проблема обычно в OCR, фрагментации, метаданных или версиях.

Примеры вопросов для мини-теста:

• «Какая сейчас процедура согласования закупки?»
• «Какие сроки реакции по инцидентам 1 уровня?»
• «Кто утверждает отпуск и какие документы нужны?»
• «Какие требования по паролям действуют в этом году?»

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

Пример сценария: обновили регламент по ИБ. Документ проходит OCR (если был скан), очистку, получает метаданные «ИБ, регламент, версия 3.2, дата», старая версия уходит в архив с пометкой «неактуально». После этого запускается переиндексация, и контрольный вопрос про пароли должен ссылаться только на новую версию.

Дальше логично начать с пилота на одном типе документов (например, политики и регламенты), довести конвейер до предсказуемых ответов и только потом расширяться на договоры, письма и техдокументацию. Если параллельно нужна инфраструктура под RAG (серверы, хранение, контуры безопасности) и сопровождение 24/7, часто проще подключать системного интегратора: например, GSE.kz как производитель и интегратор может закрыть часть задач по инфраструктуре и поддержке, чтобы пилот не зависел от разрозненных поставщиков.