Безопасный приём документов для RAG: PDF, OCR, метаданные и хранение

Большинство сбоев RAG случается ещё до этапа извлечения. Документ оказался устаревшим. OCR пропустил таблицу. У источника не было ответственного. Метаданные о правах доступа потерялись. Удалённый договор остался в векторном хранилище. У отсканированного PDF был скрытый текстовый слой, который никто не проверил. Система отвечала уверенно, потому что конвейер приёма считал, что «текст есть» — значит «знанием можно безопасно пользоваться».

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

Эта статья охватывает слой приёма: PDF, OCR, метаданные, права доступа, хранение и эксплуатационные проверки.

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

Конвейер приёма документов

У промышленного конвейера должны быть явно выделенные этапы:

1. Регистрация источника.
2. Классификация данных.
3. Проверки безопасности файлов.
4. Извлечение текста и OCR.
5. Сохранение структуры.
6. Прикрепление метаданных.
7. Сопоставление прав доступа.
8. Разбиение на фрагменты и построение эмбеддингов.
9. Проверки качества.
10. Публикация индекса.
11. Обработка хранения и удаления.

Конкретные инструменты могут отличаться. Контрольные точки — нет.

Этап 1: регистрация источника

Не подключайте случайные папки только потому, что их легко подключить.

Для каждого источника фиксируйте:

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

Примеры источников:

• публичный центр помощи,
• внутренний плейбук поддержки,
• маркетинговые материалы,
• клиентские договоры,
• кадровые политики,
• инженерные ранбуки,
• документация по продукту,
• расшифровки встреч.

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

Этап 2: классифицируйте данные до извлечения

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

Полезные классы:

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

Этап 3: проверки безопасности файлов

Документы могут быть враждебными или просто битыми.

Перед извлечением:

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

Это особенно важно, если загружать документы могут пользователи без прав администратора. Приём только силами администраторов снижает риск, но не устраняет его.

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

Как этот слой выглядит на практике, в порядке возрастания паранойи: сигнатурный сканер (класса ClamAV) как минимальная планка; парсинг в изолированном контейнере без доступа в сеть — у парсеров PDF и офисных форматов длинная история уязвимостей (CVE), поэтому считайте сам парсер поверхностью атаки; и для по-настоящему недоверенного потока — обезвреживание и пересборка содержимого (CDR), которое собирает чистую копию файла вместо того, чтобы доверять оригиналу. Большинству конвейеров в малом и среднем бизнесе нужны первые два; добавляйте CDR, когда документы могут присылать посторонние.

Этап 4: извлечение текста и OCR

PDF на практике — не один формат. В одних есть выделяемый текст. Другие представляют собой сканы. В третьих есть колонки, таблицы, сноски, формы, комментарии, штампы или скрытые текстовые слои.

Выбирайте способ извлечения по типу документа: текстовый экстрактор для изначально цифровых PDF (класса PyMuPDF или pdfplumber), конвертер с учётом вёрстки для структурированных документов (класса Docling или Unstructured — таблицы и порядок чтения сохраняются заметно лучше) и OCR только для настоящих сканов (Tesseract как базовый вариант для собственного развёртывания; облачный OCR-сервис там, где качество скана плохое, а классификация данных это позволяет).

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

Замечание, специфичное для нашего рынка: эстонский OCR сложнее английского. У Tesseract есть эстонская модель, но точность на õ/ä/ö/ü, старых машинописных архивах и смешанных эстонско-русских документах разнится настолько, что перед выбором движка стоит прогнать пилотное сравнение на репрезентативной выборке собственного архива. Для эстонской компании такой пилот — это полдня, которые потом экономят четверть тихих сбоев извлечения.

Отслеживайте качество извлечения:

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

Извлечение низкого качества не должно тихо попадать в индекс. Направьте его на проверку или пометьте как низкую уверенность.

Типичные проблемы:

• колонки прочитаны в неверном порядке,
• строки таблиц объединены неправильно,
• заголовки повторяются в каждом фрагменте,
• отсканированные страницы пропущены целиком,
• рукописные пометки проигнорированы,
• скрытый текстовый слой противоречит видимому скану,
• OCR неверно распознаёт номера счетов.

Для ценных документов выборочно сверяйте отрендеренную страницу с извлечённым текстом.

Этап 5: сохраняйте структуру

RAG-системам нужен не только текст. Им нужно достаточно структуры, чтобы давать полезные ответы, опирающиеся на источник.

Сохраняйте:

• заголовок,
• путь по заголовкам,
• номер раздела,
• номер страницы,
• подписи к таблицам,
• границы списков,
• версию документа,
• дату вступления в силу,
• URL источника или путь к хранилищу.

Разбивайте текст на фрагменты вместе с заголовками и ссылками на страницы. Фрагмент, где написано «применяется следующее» без предшествующего заголовка, — слабое свидетельство.

Для таблиц решите, что делать:

• сохранить таблицу как Markdown,
• преобразовать её в структурированный JSON,
• хранить и текст, и структурированные строки,
• исключить её, пока не появится более качественный парсер.

Не делайте вид, что извлечение таблиц — решённая задача, если ваш сценарий зависит от точных цен, дат, лимитов или порогов.

Этап 6: прикрепите метаданные

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

{
  "sourceId": "policy-2026-expenses",
  "documentId": "doc_123",
  "tenantId": "tenant_a",
  "visibility": "internal",
  "allowedRoles": ["finance", "leadership"],
  "sensitivity": "confidential",
  "sourceOwner": "Finance",
  "version": "2026-02",
  "lastReviewedAt": "2026-02-10",
  "effectiveFrom": "2026-03-01",
  "page": 7,
  "headingPath": ["Travel", "Hotel limits"],
  "contentHash": "sha256:..."
}

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

Этап 7: сопоставление прав доступа

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

Хорошая схема:

1. Пользователь задаёт вопрос.
2. Приложение выводит тенант, пользователя, роли, группы и права на данные из системы аутентификации.
3. Модуль извлечения отбирает фрагменты-кандидаты по правам доступа.
4. Ранжирование происходит только среди разрешённых фрагментов.
5. Модель получает только разрешённые фрагменты.

Плохая схема:

1. Извлечь широко.
2. Отправить модели все подходящие фрагменты.
3. В промпте написать: «отвечай только по фрагментам, к которым у пользователя есть доступ».

Плохая схема уже раскрыла данные в контексте модели.

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

Этап 8: разбиение на фрагменты и эмбеддинги

Разбиение на фрагменты — это решение о безопасности и качестве, а не только о настройке поиска.

Рекомендации:

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

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

Этап 9: контроль качества

Перед публикацией источника в промышленное извлечение запустите проверки:

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

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

Этап 10: хранение и удаление (здесь живёт статья 17 GDPR)

RAG-системы часто случайно хранят данные дольше, чем система-источник.

Именно на этом этапе право на удаление из GDPR (статья 17) превращается из положения политики в инженерное требование: когда приходит запрос на удаление, ответ «мы удалили исходный файл» несостоятелен, если копии живут в других местах конвейера. Удаление должно охватывать:

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

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

Отслеживайте:

• когда удалено,
• кем удалено или каким событием-источником,
• причину удаления,
• статус очистки в нижестоящих системах,
• результат проверки.

Не полагайтесь на «мы убрали это из интерфейса». О векторных хранилищах и кешах легко забыть.

Этап 11: эксплуатационная ответственность

У каждого источника должен быть владелец. У каждого владельца — своя регулярность пересмотра.

Для каждого источника определите:

• кто одобряет приём,
• кто одобряет изменения прав доступа,
• кто пересматривает устаревшие документы,
• кто разбирается со сбоями извлечения,
• кто отвечает на запросы об удалении данных,
• кто расследует ошибки извлечения.

Если у источника нет владельца, ему не место в промышленной RAG-системе.

Итог

Безопасный приём в RAG скучен в самом хорошем смысле. Он делает извлечение предсказуемым.

Основные меры контроля:

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

Хорошие ответы рождаются из хороших источников. Безопасные ответы — из хорошего контроля над источниками.