Как пакетно определить, нужен ли OCR для 100 000 PDF: руководство по автоматизации

Кратко: В корпоративных архивах, юридических фирмах и финансовых организациях часто хранятся десятки тысяч PDF — от born-digital файлов с настоящим текстовым слоем до «псевдо-PDF» со сканеров 2005 года (полностраничные изображения, нельзя скопировать текст). Полный OCR на 100 000 файлов сжигает бюджет и повторно обрабатывает уже поисковые документы. Правильный путь: сначала пакетно определить, каким PDF действительно нужен OCR, затем маршрутизировать по типу в локальные или облачные движки распознавания.

Что значит «нужен OCR»

В инженерном контексте «нужен OCR» ≠ «в файле есть картинки». Это означает:

Ключевая идея: Цель этапа проверки — не распознать содержание, а дёшево разложить 100k файлов по корзинам skip / partial / full-OCR до любого платного API или тяжёлого OCR.

Трёхуровневый пайплайн проверки

Одного прохода pdftotext недостаточно — ложные срабатывания и пропуски умножаются на объёме 100k. Используйте три уровня:

L1: Быстрая проверка текстового слоя (< 50 мс/файл)

PyMuPDF (fitz) или poppler pdftotext считают печатные символы:

• avg_chars >= 80 → SKIP
• avg_chars < 20 → OCR_REQUIRED
• Серая зона → L2

L2: Доля площади изображений на странице

Для серой зоны L1 вычисляйте площадь изображений / площадь страницы:

• Доля > 85% и мало символов L1 → OCR_REQUIRED
• Доля < 30% и умеренное число символов L1 → SKIP
• Иначе → L3 выборочная проверка

L3: Рендер выборки + лёгкий OCR-зонд

Для неопределённых файлов рендерьте только 1-ю, среднюю и последнюю страницы (всего 3). Запустите лёгкий macOS Vision или Tesseract. L3 обрабатывает лишь ~5–8% серой зоны.

Параллельная архитектура для 100 000 файлов

Горизонтальное масштабирование через манифест + очередь сообщений:

S3/MinIO bucket
  └── manifest.jsonl (100k строк: path, sha256, size)
        ↓
  Redis/RabbitMQ task queue
        ↓
  N × Workers (Cloud Mac / Linux VM)
        ↓
  SQLite / Parquet results

Пропускная способность (ZavCloud Cloud Mac mini M4, 24 ГБ):

Используйте ProcessPoolExecutor с 32 воркерами. Результаты пишите в Parquet для аналитики.

Трёхуровневая маршрутизация по вердиктам

Обязательно дедуплицируйте по SHA-256: дубликаты загрузок из разных систем — обычное дело. Кэш результатов на 90 дней экономит ещё 20–40% вычислений.

Выбор инструментов

Чистые PDF: PyMuPDF + pdftotext — оба должны вернуть SKIP, прежде чем пропускать файл.

Типичные ошибки

1. Зашифрованные PDF: расшифруйте копию через qpdf --decrypt перед проверкой
2. Искажение CID-шрифтов: L1 завышает счётчик, но текст нечитаем → L3 проверяет долю печатного Unicode
3. Двухслойные PDF (скан + скрытый OCR): pdffonts — нет шрифтов, но текст есть → вероятно плохой существующий OCR → PARTIAL
4. Повреждённые файлы: исключения fitz.open → отдельная корзина CORRUPT, не блокируйте основную очередь
5. Случайный I/O с NAS: rsync на локальный NVMe перед проверкой 100k мелких файлов

Зачем Cloud Mac для очередей проверки

Проверка PDF — это I/O + многопроцессный CPU, не GPU — но Cloud Mac подходит отлично:

• tmux 24/7: закрытие ноутбука убивает ночную очередь. Узлы Cloud Mac работают постоянно; проверка переходит в OCR-batch на той же машине.
• Unified Memory Apple Silicon: парсинг PyMuPDF выигрывает от пропускной способности памяти; L1 на M4 на 20–40% быстрее сопоставимых x86 VPS.
• Проверка → OCR на одном узле: файлы OCR_REQUIRED идут в ocrmypdf + Vision без передачи 100k файлов между машинами.
• Изоляция для compliance: юридические и финансовые клиенты часто требуют data residency — проверка и локальный OCR остаются на арендованном узле; облачный API обрабатывает только явно помеченные сложные страницы.

Чеклист из 7 шагов

1. Экспортируйте manifest.jsonl из object storage (path + sha256 + size)
2. На Cloud Mac: brew install poppler qpdf + pip install pymupdf pyarrow
3. Запустите полную проверку L1 → вывод в Parquet
4. Вручную проверьте 200 файлов из корзины PARTIAL, откалибруйте пороги
5. OCR_REQUIRED → очередь ocrmypdf; PARTIAL → постраничный OCR
6. Запишите sidecar-файлы ({sha256}.json) для RAG / ES индексации
7. Ежедневная инкрементальная проверка — не пересканируйте весь корпус

Итог: По меньшей мере половина затрат на OCR 100k PDF уходит на файлы, которым OCR никогда не был нужен. Сначала разложите корзины трёхуровневым пайплайном, затем выбирайте локальный Vision или облачный Document AI — так выглядит оцифровка документов в 2026 году.