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

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

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

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

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

Конвейер загрузки документов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это особенно важно, если документы могут загружаться пользователями без прав администратора. Загрузка документов только администраторами снижает один из путей атаки, но не делает скомпрометированный, злонамеренный, избыточно большой или некорректно оформленный файл безопасным. Для загрузки через коннекторы и URL также требуются разрешённые источники, контроль перенаправлений и DNS, ограничение области аутентификации, лимиты скорости запросов и тестирование на уязвимость SSRF.

Если не доверенные пользователи могут загружать файлы, реализуйте слой безопасности файлов перед их разбором. Используйте поддерживаемый Cheat Sheet OWASP по загрузке файлов в качестве базовой линии и проведите моделирование угроз для выбранных парсеров и пути хранения. Для более широкой модели угроз при извлечении данных, включая отравление данных, утечку прав доступа, инъекцию промптов и небезопасный вывод, также используйте Cheat Sheet OWASP по безопасности RAG.

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

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

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

Выбирайте путь извлечения в зависимости от типа документа: сравнивайте экстракторы, ориентированные на текст, для изначально цифровых PDF-файлов; конвертеры с учётом макета для структурированных документов и OCR для сканов. Выбор инструмента должен основываться на бенчмарках точности работы с макетом и таблицами, поддержке языков, лицензии, процессе обновления патчей и границах данных.

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

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

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

• метод извлечения,
• уверенность 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:..."
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 10: атомарная публикация версии индекса

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

1. зафиксируйте манифест источника/версии и хэши содержимого;
2. проверьте количество документов, ошибки извлечения, покрытие правами доступа, политику дублирования, модель/версию встраивания и репрезентативные запросы с авторизованными и неавторизованными данными;
3. запишите кандидатскую версию, версии источников, результаты тестов, утверждающее лицо и цель отката;
4. атомарно переключите алиас или указатель приложения на одобренную версию там, где хранилище это поддерживает;
5. инвалидируйте или версионируйте кэши извлечения и ответов; и
6. отслеживайте ошибки, отказы в доступе, пустые результаты извлечения и трафик с устаревшими версиями после продвижения.

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

Откат должен восстанавливать последний утверждённый указатель индекса, не возвращая отозванные права доступа или удалённые данные. Проверьте, что откат не приводит к восстановлению устаревшего списка ACL, удалённого документа, отравленного источника или устаревшего ответа из кэша.

Этап 11: хранение и удаление

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

Статья 17 GDPR определяет право на стирание данных при определённых условиях и исключениях. Квалифицированный юрист должен определить применимые обязательства и любые законные основания для хранения данных. Система по-прежнему требует инвентаризации и операций жизненного цикла для каждой копии и производного объекта:

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

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

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

• deletedAt,
• deletedBy или событие-источник,
• причину удаления,
• статус очистки ниже по конвейеру,
• результат проверки.

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

Этап 12: операционная ответственность

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

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

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

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

Управление источниками, а не гарантии

Безопасная загрузка данных в RAG — это целенаправленное управление источниками. Оно делает поведение поиска и его сбои более наблюдаемыми и тестируемыми; однако оно не гарантирует, что сгенерированные ответы будут корректными или безопасными.

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

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

Качество источников и контроль над ними являются необходимыми, но не достаточными условиями для качества и безопасности ответов. Проводите сквозную валидацию поведения поиска, авторизации, привязки к контексту (grounding), отказа от ответа, использования инструментов и жизненного цикла.