Сравнение открытых OCR API по качеству форматов вывода

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

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

Истинным отличием современных документооборотов является качество формата вывода: насколько последовательно и чисто движок предоставляет координаты, порядок чтения, структурную иерархию и табличные данные.

Ниже представлено сравнение, ориентированное на инженеров, четырёх ведущих OCR с открытым исходным кодом движков — Tesseract, PaddleOCR, EasyOCR, и Surya OCR — оценивающее, как их выводы ведут себя в автоматизированных конвейерах.

Распространённые форматы вывода: что действительно нужно инженерам

Каждый OCR API упаковывает обнаруженный текст по‑разному. Понимание этих форматов помогает определить, сколько постобработки требуется вашему конвейеру:

• Простой текст (.txt): Самое простое представление. Оно удаляет все позиционные метаданные и сводит много колонные макеты к горизонтальному чтению, что может перемешать абзацы.
• Стандарты архивирования (hOCR, ALTO XML): Форматы на основе XML/HTML, стандартные в библиотечном архивировании. Они встраивают координаты, оценки шрифтов и уровни уверенности в узлы DOM. Очень надёжны для восстановления документов, но громоздки для микросервисов.
• Структурированный JSON: Стандартный выбор для современных веб‑бэкендов. Предоставляет массивы координат (ограничивающие рамки или полигоны), уровни уверенности и иерархические структуры блоков/строк/слов.
• Markdown (.md) / HTML Tables: Современный стандарт для Retrieval-Augmented Generation (RAG). Сохраняет семантические разделы (заголовки, списки, жирный текст) и табличные матрицы без необходимости последующей пространственной реконструкции.

1. Tesseract OCR

Поддерживаемый Google, Tesseract остаётся фундаментальной рабочей лошадкой открытого OCR. Его архитектура сильно опирается на традиционные алгоритмы сегментации страниц, дополненные LSTM‑основанным движком символов.

Нативные форматы вывода

• Основные выводы: обычный текст, hOCR (HTML), ALTO XML, TSV (Tab-Separated Values) и поисковый PDF/A.
• Осведомлённость о макете: Эвристика на основе правил через режимы сегментации страниц (PSM).

Анализ форматов вывода

• Где он преуспевает: Экспорты TSV и hOCR из Tesseract стандартизированы и предсказуемы. Один экспорт TSV возвращает структурированные столбцы: level, page_num, block_num, par_num, line_num, word_num, left, top, width, height и conf. Если вы конвертируете бумажные архивы в поисковые PDF или вам требуется строгий контроль соответствия институциональным стандартам, Tesseract обрабатывает это нативно без пользовательского кода‑клея.
• Где он отстает: У Tesseract нет нативного JSON API. Использование его вывода в Python или Node.js требует парсинга XML/TSV файлов или применения обёрток, таких как pytesseract. Его движок макета также сталкивается с проблемами при нестандартном колонном потоке, часто смешивая текст из соседних колонок, если не предоставить ручные обрезки границ.

Tesseract Output Profile:
├── Plain Text: Clean for standard single-column pages
├── XML / hOCR: First-class, rock-solid support
├── JSON: Requires custom wrappers or TSV-to-JSON transforms
└── Markdown / Tables: Poor (requires custom reconstruction)

2. PaddleOCR

Поддерживаемый фреймворком PaddlePaddle от Baidu, PaddleOCR получил широкое распространение благодаря своим лёгким моделям, обширной поддержке множества языков и специализированному набору инструментов для анализа документов (PP-Structure).

Нативные форматы вывода

• Основные результаты: Python lists/dictionaries, raw JSON, наложения визуализации и структурированный HTML через PP-Structure.
• Осведомлённость о макете: Высокая (используется глубокое обучение для разбора макета, классификации ориентации и восстановления таблиц).

Анализ форматов вывода

• Где он преуспевает: Стандартный PaddleOCR возвращает координаты 4‑угольника ([[x1, y1], [x2, y2], [x3, y3], [x4, y4]]) вместе с текстовыми строками и оценками уверенности. Это эффективно обрабатывает наклонный или изогнутый текст. Однако его реальная сила заключается в наборе PP-Structure, который обнаруживает области макета (заголовок, текст, таблица, рисунок) и напрямую преобразует таблицы в корректные HTML‑строки (<table>...</table>). Это устраняет необходимость вручную вычислять объединения ячеек из ограничивающих рамок.
• Где он отстает: Базовый API возвращает вложенные массивы, в которых отсутствуют стандартные ключи свойств в разных версиях. Для структурированных приложений разработчики обычно пишут промежуточный адаптер для стандартизации имён полей (bbox, text, confidence).

PaddleOCR Output Profile:
├── Plain Text: Clean across multiple orientations
├── XML / hOCR: Limited (JSON is the preferred interchange format)
├── JSON: Highly detailed with 4-point polygons
└── Markdown / Tables: Excellent (direct HTML table generation via PP-Structure)

3. EasyOCR

Создан на основе PyTorch компанией JaidedAI, EasyOCR разработан для быстрого внедрения разработчиками. Он объединяет CRAFT (Character Region Awareness for Text Detection) с сетями распознавания на основе глубокого обучения в минимальный API.

Нативные форматы вывода

• Основные результаты: списки Python, содержащие кортежи координат, распознанных строк и значений уверенности.
• Осведомлённость о макете: Низкая до умеренной (только обнаружение строк текста; без структурного разбора уровня документа).

Анализ форматов вывода

• Где он превосходит: Простота возвращаемого объекта не имеет равных:

  [
      (
          [[x1, y1], [x2, y2], [x3, y3], [x4, y4]],
          "Total Balance Due",
          0.9842,
      )
  ]
  

Преобразование этого вывода в стандартный REST‑ответ или сериализация его напрямую в GeoJSON/пользовательские схемы занимает всего несколько строк кода. Он работает надёжно с текстом в естественных сценах, номерными знаками и отдельными фрагментами документов.

• Где он отстаёт: EasyOCR не выполняет целостный анализ макета документа. Он не определяет таблицы, иерархию заголовков или порядок чтения в сложных колонках. Применение EasyOCR к академической статье в двух колонках часто приводит к переплетённым фрагментам текста, если не использовать предварительную модель обнаружения макета (например, YOLO или LayoutLM).

EasyOCR Output Profile:
├── Plain Text: Good for isolated text blocks
├── XML / hOCR: Not supported natively
├── JSON: Trivial to generate from Python tuples
└── Markdown / Tables: None (requires external layout pipelines)

4. Surya OCR

Surya — современный OCR‑фреймворк на основе глубокого обучения, разработанный специально для сложного понимания документов и конвейеров загрузки LLM.

Нативные форматы вывода

• Основные результаты: JSON‑структуры, смоделированные с помощью Pydantic, индексы логического порядка чтения, ограничивающие регионы макета и полигоны обнаружения строк.
• Осведомлённость о макете: Исключительно высокая (анализ макета на основе глубокого обучения и сортировка порядка чтения).

Анализ форматов вывода

• Где он преуспевает: Surya напрямую решает задачи современной AI-инженерии. Вместо предположения, что документы читаются сверху вниз, слева направо, Surya использует специализированную модель для предсказания порядка чтения. Он группирует строки в логические семантические блоки, естественно обрабатывает много колонные диапазоны и выводит типизированные структуры через Pydantic. Это делает последующее поглощение в векторные базы данных и конвертеры Markdown прямым и надёжным.
• Где он отстаёт: Как более новая и тяжёлая фреймворк на основе PyTorch, Surya требует выделенного GPU для соответствия пропускной способности оптимизированных C++ движков, таких как Tesseract, или квантизированных моделей Paddle. Он не ориентирован на устаревшие архивные стандарты, такие как hOCR или ALTO.

Surya Output Profile:
├── Plain Text: Naturally ordered according to human reading flow
├── XML / hOCR: Not supported
├── JSON: Fully typed, modern Pydantic schemas
└── Markdown / Tables: Clean semantic blocks ideal for Markdown synthesis

Матрица сравнения «лицом к лицу»

Рекомендации по конвейеру: какой выбрать?

• Выберите Tesseract если ваши требования к соответствию требуют стандартизированных hOCR, ALTO XML или поисковых PDF/A‑документов для государственных или архивных записей.
• Выберите PaddleOCR если вы обрабатываете операционные финансовые документы (счета, квитанции, налоговые формы), содержащие сложные, таблицы без границ, которые необходимо преобразовать в HTML или электронные таблицы.
• Выберите EasyOCR если вам нужна легковесная, «питонистская» библиотека для обнаружения и извлечения текста из естественных изображений, уличных знаков или обрезанных элементов интерфейса без хлопот по настройке.
• Выберите Surya OCR если вы подаёте неструктурированные бизнес‑отчёты, научные статьи и технические руководства в LLM или векторный поисковый движок, где логический порядок чтения и чистые структурные границы имеют первостепенное значение.

Часто задаваемые вопросы (FAQ)

1. Какой открытый формат вывода OCR проще всего подавать в большие языковые модели?

JSON Surya OCR, учитывающий порядок чтения, и HTML‑таблицы PP‑Structure от PaddleOCR предоставляют самые чистые представления для контекстов подсказок LLM и индексации RAG.

2. Может ли Tesseract нативно генерировать ответы в формате JSON без сторонних инструментов?

Нет, Tesseract нативно выводит текст, TSV, PDF и hOCR/ALTO XML; создание JSON требует преобразования его TSV или hOCR вывода с помощью промежуточного парсера.

3. Чем отличаются координаты 4‑угольного полигона от осево‑ориентированных ограничивающих рамок?

Осиально выровненные прямоугольники используют [x, y, width, height], предполагая плоский текст, тогда как 4‑угольники предоставляют четыре пары координат для точного охвата повернутых, наклонных или изогнутых строк текста.

4. Какой движок выводит структуры таблиц непосредственно в код, а не в виде разрозненных координат?

Модуль PP-Structure в PaddleOCR восстанавливает обнаруженные границы таблиц в полные HTML‑теги таблицы (<table>, <tr>, <td>), избегая пользовательских пространственных вычислений.

5. Почему стандартный вывод EasyOCR сталкивается с трудностями в многоколоночных научных статьях?

EasyOCR определяет строки текста на основе локальной близости, а не глобальной иерархии макета, из‑за чего текст из соседних колонок переплетается, если его не ограничивает внешний движок макета.

См. также

• Сравнение форматов вывода OCR: TXT, PDF, PDF/A, XML, JSON
• Понимание форматов OCR‑файлов — объяснение HOCR vs ALTO vs PDF/A
• В чём разница между PDF и FDF?
• PDF против Word: какой использовать и когда?
• Как выбрать правильный формат файла для распознавания рукописного текста (HTR)