RAG PDF: pdf-inspector или OCR для импорта (2026)

В конвейере RAG каждый PDF отправляется в OCR, хотя часть файлов уже содержит пригодный текст, а другая часть после OCR теряет структуру.

Быстрое решение: не выбирать между pdf-inspector и OCR как между взаимоисключающими инструментами — использовать pdf-inspector для классификации и нативного извлечения, а OCR включать только для сканированных страниц, плохого скрытого текстового слоя или отдельных смешанных участков.

Эта статья предназначена разработчикам, которые с нуля строят импорт PDF в RAG и выбирают первую архитектуру. Она также полезна командам с уже работающим OCR-конвейером, если обработка стала медленной или нестабильной, и руководителям, которым нужно подготовить удалённую среду для массовой регрессии.

Последнее обновление: 10 августа 2026 года. Сведения проверены по актуальному README и материалам репозитория pdf-inspector, документации PyMuPDF, OCRmyPDF и Tesseract.

Решение определяется не наличием текста, а качеством результата

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

На практике встречаются как минимум четыре типа входных файлов:

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

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

Для предварительной оценки следует проверять не один показатель, а минимум пять:

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

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

Нужно ли всегда сначала выполнять OCR для импорта PDF в RAG?

Нет. Для текстовых страниц это добавляет отдельную стадию, меняет представление текста и может ухудшить точность в таблицах, формулах, коде и обозначениях. Сначала следует определить тип страницы, затем выбрать обработчик. Именно такую логику поддерживает pdf-inspector: проект классифицирует PDF как text_based, scanned, image_based или mixed, а затем может вернуть нативно извлечённый Markdown для подходящего типа. Официальный репозиторий pdf-inspector и описание API

pdf-inspector и OCR решают разные задачи

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

Это различие влияет на архитектуру:

pdf-inspector отвечает на вопрос «какой путь обработки выбрать?»;
нативный парсер отвечает на вопрос «как извлечь уже закодированный текст?»;
OCR отвечает на вопрос «как получить текст из изображения?»;
последующий слой RAG отвечает за очистку, разбиение, метаданные, эмбеддинги и индексацию.

В README pdf-inspector заявлены обнаружение типа PDF, позиционно-зависимое извлечение, обработка колонок, таблиц, заголовков и преобразование в Markdown. Там же указано, что классификация выполняется выборочно по потокам содержимого, а для отдельных сценариев возвращается решение о маршрутизации на уровне страницы. Эти сведения подтверждают назначение проекта, но не доказывают, что его результат будет достаточным для конкретной коллекции документов. README и примеры pdf-inspector

OCR-инструмент также не следует рассматривать как «улучшенный парсер». Например, документация PyMuPDF указывает, что встроенный OCR основан на Tesseract, который должен быть установлен отдельно; распознанный текст добавляется скрытым слоем, без исходных свойств шрифта, жирного начертания и курсива. Для RAG это означает, что визуальная копия страницы может сохраниться, но семантическая структура должна проверяться отдельно. Официальная документация PyMuPDF по OCR

Критерий	pdf-inspector и нативное извлечение	Прямой OCR	Смешанная маршрутизация
Текстовый PDF	Основной путь	Лишняя обработка	Нативное извлечение
Сканированные страницы	Только обнаружение	Основной путь	OCR по условию
Смешанный документ	Может определить тип	Обрабатывает всё одинаково	Разные пути по страницам
Заголовки и координаты	Сохраняются, если есть в PDF-структуре	Зависят от распознавания	Сохраняются на нативных страницах
Таблицы	Нужна проверка на образце	Возможны ошибки строк и ячеек	Нативный путь для текста, OCR для изображений
Эксплуатационная сложность	Ниже без OCR	Выше из-за рендеринга и языковых моделей	Выше на старте, ниже при масштабировании

Оценка по пяти метрикам

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

Метрика	Нативный путь через pdf-inspector	Прямой OCR	Гибридный путь
Качество исходного текста	5/5 для корректного текстового слоя	2–4/5 в зависимости от изображения	5/5 на текстовых страницах
Контроль задержки	5/5	2–3/5	4–5/5
Смешанные файлы	3–4/5	2/5	5/5
Сохранение структуры	4–5/5 при подходящем PDF	2–3/5	4–5/5
Простота первой версии	5/5	4/5	3/5
Контроль отказов	3/5 без дополнительной проверки	3/5	5/5 при явных fallback-ветках

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

Задержка и пропускная способность зависят от маршрута

Фиксированное утверждение вроде «OCR в десять раз медленнее» нельзя переносить между разными процессорами, разрешениями изображений, языками и режимами распознавания. Однако официальная документация PyMuPDF приводит ориентир: OCR может быть примерно в 1 000 раз медленнее стандартного извлечения текста. Это не универсальный бенчмарк для любой системы, а объяснение, почему OCR следует запускать условно и кэшировать результат. Раздел о производительности OCR в PyMuPDF

В README pdf-inspector также приведены результаты авторского сравнения на корпусе из 200 PDF: для версии 0.2.6 указан полный прогон за 0,470 секунды на Apple M4 Pro, а результаты обновлены 31 июля 2026 года. Эти цифры относятся к конкретному корпусу, версии, конфигурации и методике, поэтому их нельзя выдавать за обещанную скорость вашего RAG-конвейера. Они полезны только как пример того, какие параметры нужно фиксировать в собственном тесте. Методика и результаты сравнения в репозитории pdf-inspector

Разница между полной OCR-обработкой и маршрутизацией особенно заметна в трёх случаях:

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

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

чтения файла;
классификации;
нативного извлечения;
рендеринга изображения;
OCR;
очистки и структурирования;
эмбеддингов;
записи в индекс.

Смешанные файлы требуют маршрутизации по страницам

Файл «mixed» нельзя обрабатывать как обычный текстовый PDF только потому, что на первой странице есть заголовок. В отчёте могут присутствовать:

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

В такой ситуации pdf-inspector должен быть первым фильтром, но не финальным судьёй качества. Если классификация показывает смешанный тип, полезно сохранять решение для каждой страницы:

{
  "file_id": "document-042",
  "page": 7,
  "route": "ocr",
  "reason": "image-dominant",
  "parser_version": "fixed-in-lockfile"
}

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

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

Может ли pdf-inspector полностью заменить OCR?

Только для той части документов, где текст уже присутствует в пригодном для извлечения виде. Он не превращает изображение страницы в распознанный текст и не гарантирует, что сложная формула, рукописная пометка или фотография таблицы станут структурированными данными. Корректная формулировка для архитектуры — «pdf-inspector определяет, нужен ли OCR», а не «pdf-inspector устраняет потребность в OCR».

Стоимость нужно считать по этапам, а не по названию инструмента

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

Удобная модель расчёта выглядит так:

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

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

Это разные сценарии выбора:

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

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

Пошаговая схема для первой рабочей версии

Первый шаг: собрать размеченный набор

Нужно подготовить не случайные файлы, а выборку, отражающую будущий архив:

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

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

Второй шаг: зафиксировать версии и параметры

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

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

Третий шаг: выполнить классификацию до разбиения

Сначала обработать PDF через pdf-inspector или аналогичный классификационный слой. Для каждой страницы записать:

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

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

Четвёртый шаг: разделить нативный путь и OCR-ветку

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

Если OCR вернул пустой или подозрительно короткий результат, файл не должен молча попадать в индекс. Он переводится в очередь ручной проверки или повторной обработки с другим режимом.

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

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

Каждый чанк должен иметь как минимум:

идентификатор файла;
номер страницы;
диапазон координат, если он доступен;
тип маршрута;
версию парсера;
контрольную сумму исходного файла.

Шестой шаг: провести регрессию до индексации

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

Минимальный набор метрик:

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

Какие показатели следует оценивать при предобработке PDF для RAG?

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

Финальная проверка перед запуском

[ ] В наборе есть нативные, сканированные и смешанные PDF.
[ ] Для каждого файла размечен ожидаемый тип, а для смешанных файлов — тип каждой страницы.
[ ] Версии pdf-inspector, OCR и парсеров зафиксированы.
[ ] В журнале сохраняются маршрут, причина fallback и номер страницы.
[ ] Ошибка OCR не приводит к тихой индексации пустого результата.
[ ] В чанках есть ссылка на исходный файл и страницу.
[ ] Отдельно измеряются нативное извлечение, рендеринг, OCR и эмбеддинги.
[ ] Есть контрольные вопросы для проверки поиска после индексации.
[ ] После обновления зависимости запускается повторная регрессия.
[ ] Архивная партия и постоянный поток имеют разные лимиты параллелизма.

Итоговый выбор зависит от размера и режима загрузки

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

Для периодической пакетной загрузки оптимален гибрид: pdf-inspector передаёт текстовые страницы в нативный парсер, а сканы — в OCR-очередь. Результаты кэшируются по контрольной сумме файла и версии обработчика, чтобы повторный запуск после сбоя не распознавал уже готовые страницы.

Для постоянной производственной загрузки нужен полноценный многоуровневый маршрут:

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

Сценарий	Рекомендуемая схема	Когда пересматривать решение
Небольшой прототип	pdf-inspector → нативное извлечение → условный OCR	После появления смешанных файлов и ручных исключений
Периодическая партия	Классификация по страницам → две очереди → кэширование	При росте пикового времени или очереди OCR
Постоянный production-поток	Версионированный роутер, контроль качества, повторные запуски	После изменения коллекции, языков или требований к цитированию

В 2026 году наиболее безопасная стратегия для RAG PDF — не обещать универсальную точность одного инструмента, а строить проверяемый маршрут. pdf-inspector подходит как входной слой для обнаружения типа и нативного извлечения, OCR остаётся необходимым для изображений, а итоговое решение должно приниматься по измерениям на собственной коллекции.

Если текущая схема отправляет каждый файл в OCR, она обычно несёт три проблемы: лишнюю задержку на текстовых страницах, более высокие требования к вычислительной среде и сложную диагностику ошибок структуры. Полностью локальный сервер, в свою очередь, неудобен для коротких массовых регрессий, а обычная удалённая машина без запаса по памяти и диску может стать узким местом при параллельном рендеринге. Для временного тестового стенда или пакетной проверки разумнее рассмотреть аренду Mac через Zilmac, заранее сопоставив объём PDF, долю OCR-страниц, длительность прогона и необходимый срок доступа. Такой подход не отменяет покупку собственного оборудования для постоянной тяжёлой нагрузки, но позволяет проверить архитектуру до долгосрочных расходов и не строить production-маршрут на неподтверждённых предположениях.