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

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

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

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

Что подтверждают инструменты и исследования

Docling описывает единое представление документа, которое хранит текст, таблицы, изображения, иерархию, порядок чтения, координаты элементов и provenance — указатель на страницу и область исходника. Это полезнее плоского Markdown, если пользователю нужно показать, откуда взялся фрагмент ответа.

В документации Docling отдельно настраиваются OCR, распознавание структуры таблиц, режим точности TableFormer, ограничения на число страниц и размер файла, а также предварительная загрузка моделей для изолированного контура. То есть даже один инструмент предполагает разные режимы, а не универсальную кнопку «распознать PDF».

Unstructured формулирует ту же развилку иначе. Для PDF доступны стратегии `fast`, `hi_res`, `ocr_only` и автоматический выбор: цифровой текст можно извлечь быстро, скан требует OCR, а структура таблиц и сложная верстка требуют более тяжёлого layout-aware режима. В документации также отмечены ограничения: например, порядок элементов в многоколоночных документах может зависеть от выбранной стратегии.

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

Референсная схема конвейера

Минимальный надёжный поток состоит из восьми шагов:

1. Приём файла в неизменяемое хранилище исходников.
2. Проверка типа, размера, числа страниц, пароля, вредоносного содержимого и прав на использование.
3. Классификация страниц: цифровой текст, скан, смешанный документ, сложная таблица или нестандартная верстка.
4. Маршрутизация в быстрый экстрактор, OCR или layout-aware парсер.
5. Нормализация структуры без потери страницы, заголовков, таблиц и координат.
6. Автоматические проверки качества и выборочная визуальная сверка.
7. Карантин ошибок либо создание фрагментов со стабильными метаданными.
8. Индексация только принятой версии и запись журнала обработки.

Схематично это выглядит так:

`исходник → классификатор → parser/OCR → нормализованный документ → quality gate → карантин или chunker → индекс`

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

Шаг 1. Классифицировать документ, а не угадывать по расширению

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

Полезные признаки:

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

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

Шаг 2. Сохранить происхождение каждого фрагмента

В индекс не стоит отправлять только поля `text` и `embedding`. Минимальный payload фрагмента должен включать:

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

Qdrant позволяет хранить такие JSON-метаданные как payload и фильтровать по ним. Аналогичный принцип работает с другими векторными базами. Права доступа, актуальная версия и статус `accepted` должны участвовать в фильтре до передачи контекста модели, а не проверяться после ответа.

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

Шаг 3. Поставить автоматические ворота качества

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

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

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

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

Шаг 4. Создать карантин вместо молчаливого успеха

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

Карантин — это очередь документов с причиной, превью проблемной страницы и доступным действием:

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

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

Как проверить конвейер на собственных документах

Соберите золотой набор из 50–100 файлов. В него должны войти не самые красивые примеры, а реальная смесь:

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

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

1. полноту и порядок извлечённого текста;
2. сохранность структуры и таблиц;
3. корректность фрагментов и метаданных;
4. способность ответа показать верную страницу.

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

Инфраструктура и локальный контур

Такой загрузчик можно разместить внутри сети компании. Быстрое извлечение цифрового текста обычно работает на CPU. OCR и анализ макета требуют больше процессорного времени; некоторые модели могут ускоряться на GPU, но покупать видеокарту до замера собственного потока не следует.

Разделите сервисы логически:

  • приём и антивирусная проверка;
  • очередь заданий;
  • CPU-воркеры быстрого разбора;
  • отдельные OCR/layout-воркеры с ограничениями ресурсов;
  • хранилище исходников и результатов;
  • база метаданных и журнал;
  • векторный индекс;
  • интерфейс карантина.

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

Экономика: считать страницу, а не «один RAG»

Расчёт ниже модельный. Допустим, компания принимает 1 000 документов в месяц, в среднем по 12 страниц. Из 12 000 страниц 70% имеют цифровой текст, 20% требуют OCR, а 10% — дорогого разбора макета и таблиц. Эти доли нужно заменить фактическими после пилота.

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

`страницы × время выбранного режима × стоимость вычислений + хранение + ручная проверка + повторная обработка`

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

Для решения о пилоте достаточно четырёх показателей:

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

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

Ограничения и риски

Ни Docling, ни Unstructured, ни OCR-модель не гарантируют корректность любого PDF. Рукописные правки, сложные схемы, вложенные таблицы, плохие факсы и нестандартные шрифты остаются трудными случаями. Бенчмарк измеряет качество на своей выборке, но не заменяет корпоративный золотой набор.

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

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

Следующий шаг без дорогого проекта

Выберите один тип документов и один бизнес-сценарий — например, инструкции службы поддержки. За две недели можно:

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

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