Массовый OCR сканов PDF: самый быстрый путь для десятков тысяч файлов

Кратко: Когда нужно распознать десятки тысяч отсканированных PDF, узкое место редко сводится только к выбору OCR-движка. Важно, есть ли у вас предварительная маршрутизация, параллелизация и возобновляемая очередь задач. Обработка через десктопное приложение по одному файлу может занять недели на 10 000 документов; описанный ниже конвейер на VPS с 8–16 ядрами или GPU-воркерах часто сжимает тот же объём до часов или пары дней——если принять инженерные компромиссы: быстрый скрининг сначала, точный OCR потом, плохие страницы в карантине.

Руководство для архивов, юридических дел, медицинских отчётов, исторических бумаг и корпоративных договоров——обычно 10 000–100 000+ файлов, в основном чистые сканы или смешанные PDF. Ключевые слова: пакетный OCR, распознавание сканов PDF, ocrmypdf, PaddleOCR. Если результаты пойдут в RAG, прочитайте наши лучшие практики RAG PDF Parsing для ворот импорта——OCR лишь первый этап.

Проверено 08.08.2026 по документации OCRmyPDF, Tesseract и PaddleOCR.

Почему массовый OCR сканов PDF кажется невыносимо медленным

Типичный сбой: папка в GUI-инструмент, CPU 15 %, вентилятор тихий, 200 файлов за ночь. Причины накладываются:

• Последовательная обработка——один процесс, много простаивающих ядер.
• Нет предпроверки——30 % уже имеют текстовый слой, но проходят полный OCR.
• Параллелизм только на уровне файлов——папка на 800 страниц блокирует воркер, мелкие файлы платят за запуск.
• Тяжёлый вывод——пересжатие изображений и встраивание шрифтов на каждой странице.
• Нет контрольных точек——сбой на файле 9 000, перезапуск с нуля.

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

Шаг 0: предпроверка и маршрутизация——не OCRить то, что не нужно

Перед OCR просканируйте дерево (Python multiprocessing или find | parallel):

• Считайте get_text() на страницу через PyMuPDF / pdfinfo. Страницы с ~80+ читаемыми символами → тег text_layer, копировать в вывод, пропустить OCR.
• Зашифрованные или битые PDF → quarantine/, чтобы не стопорить очередь.
• Смешанные PDF: маршрутизация по страницам——главная экономия времени в масштабе.

Юридический проект: 42 000 PDF, 38 % уже с текстом, 12 % зашифрованы——только ~50 % требовали OCR. Это сократило время вдвое до выбора движка.

Самый быстрый путь сегодня (1 000–5 000 файлов)

На 8-ядерном Linux или облачном VPS сегодня:

1. Установите ocrmypdf + Tesseract (chi_sim/chi_tra для китайского).
2. GNU parallel или xargs -P на файл; параллелизм ≈ ядер CPU − 1.
3. Флаги: --skip-text, низкий --optimize, --jobs 1 внутри каждого ocrmypdf против вложенной перегрузки.
4. Пишите во временную локальную SSD, после батчей rsync в object storage——сетевые монтирования убивают пропускную способность.

cat scan_only.txt | parallel -j 8 \
                  'ocrmypdf --skip-text --optimize 0 --language chi_sim+eng \
                   {} /data/ocr_out/{/.}.pdf'

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

Архитектура 10 000+: очередь, воркеры, возобновление

• Очередь: Redis+RQ, Celery или облачный Batch. Задача = один PDF или диапазон страниц.
• БД состояния: SQLite/Postgres с file_hash, статусом, повторами, версией движка.
• Масштабирование: несколько средних VPS часто лучше одной гигантской машины для CPU-bound OCR.
• Параллелизм по страницам: pdftoppm → очередь страниц → слияние текстовых слоёв для папок 200+ страниц.
• GPU-пул: PaddleOCR/Surya на отдельных воркерах; маршрутизация по языку/вёрстке.

Kubernetes не нужен с первого дня. Многие команды запускают Docker Compose + Redis на 2–4 VPS-воркерах: один для очереди/метаданных, остальные только OCR.

Матрица инструментов: скорость, китайский, поисковый PDF

Самый быстрый ≠ самый дешёвый: бенчмарк 200 репрезентативных файлов по точности × сек/страница × цена перед решением.

Ещё 30–50 % скорости: практические рычаги

• Попробуйте рендер 300 DPI, если источник 600 DPI——часто хватает для договоров.
• OpenCV: шумоподавление/порог для чистых ч/б сканов.
• Загружайте только минимальные языковые пакеты.
• Пропускайте пустые/штамп-страницы по дисперсии пикселей.
• Экспорт .txt/.jsonl, если нужен только поиск; тяжёлый PDF/A только для архивного уровня.
• Укажите TMPDIR на локальный NVMe в облачных ВМ.

Скорость и качество вместе

После батча: выборка 0,5 % для ручной проверки или CER; regex на страницах с ID; повторная очередь для низкой уверенности. Плохой OCR в поисковом индексе дороже второго прохода движка. Архивные проекты требуют аудит-логов——кто, когда, какая версия движка.

Грубая оценка: 50 000 OCR-страниц

При ~5 с/страница Tesseract средний класс: ~69 ч в один поток; ~8–12 ч на 8 ядрах; ~4–6 ч на двух 8-ядерных воркерах; GPU PaddleOCR часто 1–3 с/страница——карты масштабируются линейно. Измерьте свою выборку из 100 страниц для pages_per_hour.

Чеклист для копирования

1. Рекурсивная инвентаризация + SHA256-дедуп манифест.
2. Предпроверка: text_layer / scan / mixed / encrypted.
3. Постановка в очередь (баланс по OCR-страницам).
4. Параллельный OCR с --skip-text или маршрутизацией страниц.
5. Поисковый PDF или sidecar-текст + JSON-метаданные.
6. Выборочный QA + второй проход низкой уверенности.
7. Архив с ocr_engine_version для будущих перезапусков.

Для RAG downstream храните типы страниц в метаданных. Контроль стоимости длинного контекста: наш гайд по стоимости Context Caching.

Последняя строка

Нет серебряной пули для десятков тысяч сканов——есть воспроизводимый самый быстрый путь: предпроверка срезает половину лишнего OCR → очередь переживает сбои → воркеры насыщают CPU/GPU → QA блокирует плохие страницы. Сначала зелёный конвейер; настройка движков потом.