Анализ отсканированных PDF-файлов для RAG с помощью EasyOCR: бесплатное распознавание текста позволяет получить не документ, а слова.

Enterprise Document Intelligence [Vol.1 #5quinquies] – Тот же отсканированный PDF-файл 1974 года, два механизма распознавания текста. EasyOCR восстанавливает текст. Docling восстанавливает текст + разделы + рисунки. Структурный разрыв позволяет использовать один результат в дальнейшем, а другой – в виде простой строки.

Делиться

Эта статья является дополнением к серии статей об интеллектуальном анализе корпоративных документов (Enterprise Document Intelligence), посвященной созданию корпоративной системы распознавания текста (RAG) из четырех компонентов. В статье 5 (анализ документов) парсер был создан с использованием PyMuPDF (fitz), который возвращает пустую строку на отсканированной странице без текстового слоя. В этой статье движок заменен на EasyOCR , бесплатный пакет OCR, который восстанавливает этот текст. Это единственный случай в этом семействе, когда новый движок дает меньше, а не больше: он восстанавливает текст, но ничего вокруг него, и этот пробел является уроком.

Проблема с отсканированными PDF-файлами не решается простым применением OCR. Этап OCR восстанавливает текст; это необходимо, но недостаточно для корпоративного конвейера обработки RAG. Конвейеру также необходимо все, что окружает текст : границы страниц, заголовки разделов, рисунки, таблицы и абзацы. «Традиционный OCR» (термин, обозначающий механизмы обнаружения и распознавания текста, такие как EasyOCR, Tesseract, PaddleOCR) дает вам текст. Ничего больше. Остальное — это проблема верстки, а проблема верстки — это более сложная половина.

В этой статье это различие рассматривается конкретно. Традиционный движок распознавания текста — EasyOCR : самая простая, быстрая и бесплатная библиотека для обнаружения и распознавания текста от JaidedAI (Apache 2.0, указана в файле LICENSE проекта). Движок, учитывающий структуру страницы, — Docling (статья 5ter; лицензия MIT, указана в файле LICENSE проекта). Оба могут распознавать текст на отсканированной странице. Они различаются тем, что делают с результатом. Вся статья представляет собой подготовку к сравнению результатов на реальном скане 1974 года, находящемся в общественном достоянии, в разделе 5.

1. Что делает (и чего не делает) «традиционное оптическое распознавание символов»

Традиционный алгоритм оптического распознавания текста (OCR) считывает пиксели и возвращает текстовые прямоугольники. Все остальное — разделы, таблицы, рисунки, порядок чтения — это отдельная задача компоновки, которую движок отказывается рассматривать. В основе этого лежат две модели: обнаружение текста (поиск прямоугольных областей изображения, содержащих текст) и распознавание текста (считывание пикселей каждой области и возврат символов с оценкой достоверности). На выходе получается плоский список (bbox, text, confidence) для каждой обнаруженной области.

Именно это и делает EasyOCR (или Tesseract, или PaddleOCR). Система считывает пиксели и возвращает текстовые прямоугольники. Страница с двумя колонками отображается в виде плоского списка текстовых полей слева и справа, перемешанных по координате Y; система не знает, что есть две колонки. Таблица отображается в виде сетки несвязанных ячеек, которые система не может отличить от обычных абзацев. Подпись к рисунку — это просто еще одно текстовое поле. Верхний и нижний колонтитулы страницы, поля также отображаются в виде прямоугольников.

Для всего, что требует указания типа «этот текст является заголовком раздела» или «эти четыре блока составляют одну строку таблицы», необходима вторая модель — модель компоновки . Модель компоновки считывает результат распознавания текста (OCR) и изображение страницы, классифицирует каждый регион (заголовок, абзац, ячейка таблицы, рисунок, подпись, нижний колонтитул и т. д.) и группирует их в порядке чтения. Именно это добавляют к этапу распознавания текста статьи 5bis (Azure DI), 5ter (Docling) и 5quater (vision LLM). Без этой модели вы получаете «результат распознавания текста», а не «разобранный документ».

2. EasyOCR: канонический традиционный OCR

EasyOCR — это наиболее наглядная демонстрация «традиционного распознавания текста» как класса алгоритмов. Библиотека небольшая (~150 МБ весов модели кэшируются при первом вызове), бесплатная, по умолчанию работает только на ЦП и локально. Весь API библиотеки состоит из двух вызовов: создание Reader для необходимых языков, а затем ручное readtext с изображения. Каждое обнаружение возвращается в виде тройки: многоугольник вокруг текста, распознанная строка и собственная уверенность распознавателя.

 import easyocr import fitz import numpy as np reader = easyocr.Reader(["en"], gpu=False) # first call downloads ~150 MB # render page 1 of a scanned PDF to a numpy array EasyOCR can read page = fitz.open("data/contracts/scanned_amendment.pdf")[0] pix = page.get_pixmap(matrix=fitz.Matrix(2.0, 2.0)) # 2x zoom = ~144 DPI img = np.frombuffer(pix.samples, dtype=np.uint8).reshape( pix.height, pix.width, pix.n, ) # the recogniser: one image in, one triple per detected text region out detections = reader.readtext(img) for quad, text, conf in detections: # quad = [[x0,y0], [x1,y0], [x1,y1], [x0,y1]] in pixel coords print(round(conf, 2), text)

parse_pdf_easyocr оборачивает этот цикл. Она проходит по каждой странице PDF-файла, преобразует каждую в массив numpy, вызывает readtext , преобразует полигоны в пиксельном пространстве обратно в координаты PDF и упаковывает результаты распознавания в тот же контракт типа «словарь таблиц», что и другие парсеры, тот же line_df , тот же parsing_summary , те же конечные потребители, за исключением того, что данные содержатся только в этих двух ключах . Каждый другой слот ( page_df , image_df , toc_df , span_df , object_registry , cross_ref_df ) возвращается в виде пустого DataFrame. Это не ошибка, связанная с отсутствием функции; это именно то, что означает «традиционное OCR».

 parsed = parse_pdf_easyocr( "data/contracts/scanned_amendment.pdf", languages=("en",), # add "fr", "de", ... for multilingual scans render_scale=2.0, # 2.0 = ~144 DPI ; raise for small fonts gpu=False, # CPU-only by default ; set True if CUDA available confidence_threshold=0.0, # filter low-confidence detections if needed ) parsed["line_df"] # text + bbox + confidence per detection parsed["parsing_summary"] # method, page count, line count, render scale # Every other key (page_df, image_df, toc_df, span_df, object_registry, # cross_ref_df) is an empty DataFrame ; EasyOCR has nothing to put there.

Единственными регуляторами являются подпись kwargs:

• languages : кортеж кодов ISO-639-1 ( en , fr , de , zh , …). Многоязычный корпус загружает один Reader для каждого набора языков; аннотация @lru_cache в get_easyocr_reader хранит несколько таких Reader в памяти между вызовами.
• render_scale : количество пикселей на единицу PDF-файла при растеризации каждой страницы. 1.0 — это исходное значение (~72 DPI, часто слишком маленькое). 2.0 — оптимальное значение для основного текста. Увеличьте до 3.0 для очень мелких шрифтов; уменьшите, если у вас ограничен объем памяти.
• В качестве графического процессора gpu используется центральный процессор (CPU), поэтому модуль работает на любой машине. CUDA обеспечивает ускорение в 3-5 раз при обработке страниц с большим количеством текста.
• confidence_threshold : отбрасывает результаты с низкой степенью достоверности. Значение 0.0 сохраняет все данные (столбец сохраняется, чтобы последующий код мог выполнять фильтрацию), 0.3 уменьшает большую часть шума на некачественных сканах.

3. Как выглядит line_df

Примеры строк из стандарта NIST FIPS 199 (работа правительства США, общественное достояние в США, см. заявление NIST об авторских правах), по одной на каждый обнаруженный фрагмент текста: координаты страницы, распознанный текст и собственная оценка достоверности распознавателя. Это весь результат.

Размер намеренно выбран небольшим:

• text + bbox : полезная нагрузка распознавателя, одна строка на каждый обнаруженный текстовый регион.
• confidence : значение от 0 до 1, собственная оценка EasyOCR. Полезна как в качестве фильтра (значение падает ниже 0,3 на зашумленных сканах), так и в качестве сигнала обратной связи (генерация Article 8 может помечать для пользователя фрагменты с низкой степенью уверенности).
• character_count : сохранено для симметрии с другими парсерами; в EasyOCR это просто len(text) .
• Нет столбцов / столбцов порядка чтения. Страница в два столбца отображается в виде плоского списка, в котором блоки слева и справа перемешаны по координате Y.

Каждый второй ключ в возвращаемом словаре ( page_df , image_df , toc_df , span_df , object_registry , cross_ref_df ) представляет собой пустой DataFrame. Потребитель, вызывающий parsed["image_df"] , не завершает работу с ошибкой; он итерирует по пустому DataFrame.

4. Что упускает традиционное оптическое распознавание символов: пробел в расположении элементов, поэлементно.

Пять структурных артефактов, необходимых для конвейера RAG и которые традиционный OCR не может воспроизвести, независимо от размера модели распознавания. Каждый из них нарушает последующую операцию, на которую опирается вся остальная серия.

• Оглавление / разделы. Разрешение перекрестных ссылок (статья 11) и поиск в корпусе с ограничением по разделам (статья 17) зависят от toc_df . EasyOCR возвращает ноль строк. Диспетчер не может направлять вопросы типа «ответ в разделе 3.2», поскольку раздел 3.2 не имеет границ.
• Отдельные изображения внутри страницы. Отсканированный 30-страничный контракт может содержать шесть скриншотов диаграмм, встроенных в основной текст. EasyOCR обрабатывает всю страницу как одно изображение и возвращает текст вокруг изображений; сами изображения никогда не становятся строками. Конвейер обработки данных, которому необходимо получить «диаграмму на странице 14», не имеет дескриптора.
• Порядок чтения на страницах с несколькими колонками/зонами. Научная статья в двух колонках читается сверху вниз, чередуя строки слева (первая строка), справа (первая строка), слева (вторая строка), справа (вторая строка)… В итоге получается некачественный текст. Боковые панели, сноски, заметки на полях — всё это вторгается в основной поток информации.
• Ячейки таблицы. Отсканированная таблица тарифов или премий возвращается в виде плоского списка несвязанных текстовых полей (метки строк в одном столбце, значения в другом, заголовки единиц где-то еще). Связь «это значение относится к этой метке» теряется. Статья 5 (анализ документов) посвящена именно этому типу ошибок («анализатор прошел по ячейкам таблицы и объединил их в плоскую строку»). Механизмы, учитывающие компоновку, используют отдельную модель в стиле TableFormer для восстановления строк × столбцов × заголовков.
• Сигналы шрифта/толщины/размера. OCR восстанавливает форму символа, а не его типографическое кодирование. «Эта строка выделена жирным шрифтом 18pt» — это информация, которую механизм верстки считывает из процесса отрисовки страницы; EasyOCR её отбрасывает. Заголовки, выделения, сноски теряют подсказку, которая позволила бы их классифицировать.

Возьмем третий пункт, порядок чтения, потому что именно он незаметно искажает ответ. EasyOCR возвращает текстовые поля, отсортированные по их координате Y. На странице с двумя колонками обе колонки расположены на одинаковой высоте, поэтому поля возвращаются вперемешку: первая строка левой колонки, первая строка правой колонки, вторая строка левой и так далее. Текст читается зигзагом, и генерация цитирует этот зигзаг.

Единственная фраза: этап OCR восстанавливает текст, этап компоновки восстанавливает то, что делает текст пригодным для использования . Статья 5ter (Docling) и статья 5bis (Azure DI) добавляют этап компоновки поверх того же самого OCR. Статья 5quater (vision LLM) объединяет эти два этапа в один вызов. EasyOCR останавливается на этапе OCR.

5. Сравнение EasyOCR и Docling на реальном отсканированном PDF-файле.

При сканировании того же документа 1974 года Docling извлекает больше символов (5423 против 4952), границы страниц, одиннадцать записей оглавления и четыре области рисунков. EasyOCR извлекает текстовые прямоугольники и точки. Оба движка согласуются на уровне символов, оба распознают текст с одинаковой точностью класса распознавания, но этап компоновки Docling преобразует результат распознавания в документ.

Интересное сравнение проводится не с fitz (fitz возвращает ноль при сканировании), а со следующим по уровню движком: Docling, локальным парсером, учитывающим структуру текста, из Article 5ter. Сравнение выглядит более понятным, чем кажется: в качестве бэкенда OCR по умолчанию используется EasyOCR. Один и тот же распознаватель считывает одни и те же пиксели; разница заключается во всем, что Docling строит вокруг него.

В качестве тестового примера используется реальное сканирование общедоступного материала: страницы 1–5 файла karg74.pdf, представляющего собой отчет ВВС США 1974 года о безопасности MULTICS (Karger & Schell, ESD-TR-74-193 Vol. II). NIST размещает его в своем архиве ранних работ по компьютерной безопасности; эта работа находится в общественном достоянии как результат деятельности офицеров ВВС США. В PDF-файл встроен слой оптического распознавания текста Adobe «Paper Capture», но мы его игнорируем, поскольку оба движка повторно распознают текст с изображений страниц, что является реалистичным сценарием, когда встроенный OCR (если он присутствует) ненадежен.

Эти две колонки рассказывают разные истории.

EasyOCR (слева). Быстрее (59,7 с против 134,4 с, не требуется загрузка и запуск модели компоновки), передает уровень достоверности распознавателя в виде столбца (среднее значение 0,81 на этом сканировании), обеспечивает больше обнаружений на уровне строк (346 рамок), поскольку каждая текстовая область на странице становится одной строкой. Нулевая структура: нет page_df , нет toc_df , нет image_df . Выходные данные — текст в формате bbox, ничего больше.

Docling (справа). Работает медленнее (в 2,3 раза больше вычислительных ресурсов), объединяет результаты обнаружения в 105 строк/абзацев вместо 346 блоков, отсутствует столбец достоверности. Структурное преимущество реально: 5 строк page_df , 11 записей toc_df (модель компоновки Docling классифицирует заголовки как разделы), 4 строки image_df (рисунки, обнаруженные внутри страницы как отдельные объекты). В PDF-файлах с таблицами разрыв увеличивается еще больше: TableFormer в Docling распознает строки × столбцы × заголовки, чего EasyOCR вообще не может сделать. В статье 5ter подробно рассматривается случай с таблицами.

Оба движка распознавания текста демонстрируют схожие показатели ошибок на уровне символов при сканировании этого текста 1974 года (Karger → “Karger” от EasyOCR, “Karger” от Docling на самой чистой странице; поврежденные области дают схожий уровень шума в обоих случаях: “Laboralory”, “und” вместо “and”). Движок распознавания текста внутри Docling (EasyOCR или OnnxTR в зависимости от установки) не является волшебным образом точнее, чем прямой вызов EasyOCR. Docling добавляет способ организации выходных данных распознавания текста, а не сам процесс распознавания.

Для корпоративных систем RAG правильным решением почти всегда является Docling . Увеличение вычислительных ресурсов в 2,3 раза оплачивается один раз при обработке данных (кэш анализа из статьи 5 (анализ документов) использует результаты бесконечно); структурный выигрыш (оглавление, рисунки, ячейки таблиц, порядок чтения) окупается при каждом последующем запросе. Единственное, чего не хватает Docling, — это сигнала достоверности на уровне строк, который есть в EasyOCR, и который редко оправдывает отказ от разделов, рисунков и таблиц.

6. Когда традиционное оптическое распознавание символов по-прежнему оправдывает себя

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

• Документы класса квитанций. Одностраничный счет-фактура или квитанция без заголовков, разделов, рисунков, таблиц с объединенными ячейками. Макет тривиален; вся работа заключается в распознавании документа. Добавление вычислительной мощности Docling в 2 раза увеличивает структуру документа, которой он не обладает.
• Уверенность по регионам как сигнал обратной связи для генерации. Генерация (статья 8) может считывать уровень confidence строки из цитируемого фрагмента и предупреждать пользователя, когда ответ основан на бите OCR с уровнем достоверности 0,3. Docling не включает этот столбец. Для конвейеров, где этот сигнал является основным, EasyOCR (или запуск EasyOCR вместе с Docling) — это решение.
• Поддержка нелатинских шрифтов в больших масштабах. EasyOCR поставляется с предварительно обученными моделями для более чем 80 языков, включая китайский, японский, корейский, арабский, хинди и кириллицу. На момент написания статьи набор инструментов OCR от Docling имеет более ограниченное покрытие нелатинских языков.
• Операционные ограничения, блокирующие Docling. Проверка SSL-сертификатов в корпорации нарушает загрузку модели HuggingFace. Windows блокирует символические ссылки без режима разработчика. Образ для производственной среды имеет строгий лимит зависимостей. Развертывание в изолированной среде без возможности передачи 3 ГБ весовых коэффициентов разметки. Во всех этих случаях кэшированная модель EasyOCR объемом 150 МБ + вывод данных с помощью ЦП проходят успешно, в то время как Docling — нет. Вы видите меньшую часть документа, но все же видите что-то.

Вне этих случаев: по умолчанию используется Docling для сканированных документов, Azure DI для облачных провайдеров, соответствующих требованиям регулирования, Vision LLM, если документ содержит рукописный текст/подписи/нетекстовый семантический слой. Диспетчер адаптивного анализа (статья 10) направляет запросы автоматически.

7. Заключение

OCR восстанавливает символы. Макет восстанавливает то, что делает символы полезными: разделы, рисунки, ячейки таблиц, порядок чтения. Механизм сканирования по умолчанию выполняет обе функции. Вся серия Article-5 выровнена по одной оси:

EasyOCR — это базовый уровень распознавания текста, то, что получается, когда ограничиваешься распознаванием символов и никогда не спрашиваешь: «А где они находятся на странице?» Этот вопрос важен. «Где они находятся на странице» — это разница между списком текстовых блоков и проанализированным документом. Диспетчер статьи 10 (адаптивный анализ) выбирает правильный движок для каждой страницы; эта статья существует для того, чтобы диспетчер знал, что он теряет, выбирая самый дешевый вариант.

8. Источники и дополнительная литература

EasyOCR — наиболее доступный традиционный движок распознавания текста в 2026 году; PaddleOCR (Baidu) и Tesseract (Google, существует уже несколько десятилетий) находятся рядом с ним в одном семействе. Этап компоновки — вот что отличает «распознавание текста» от «анализа документов»; Docling (статья 5ter) и Azure DI (статья 5bis) добавляют его, соответственно, на локальном оборудовании и в облаке. Правильное сопоставление — это литература по компоновке (Smock et al. 2022 для структуры таблиц, Auer et al. 2024 для полного каскада компоновки) и альтернативные движки распознавания текста для нелатинских шрифтов.

В том же направлении, что и в статье:

• JaidedAI, EasyOCR. Библиотека, описанная в этой статье, включает более 80 пакетов языковых моделей.
• PaddleOCR (Baidu). Традиционный движок распознавания текста того же класса; лучшее покрытие китайского языка, аналогичная проблема «слепоты» к разметке.
• Tesseract OCR. Эталонная система, существующая уже несколько десятилетий и до сих пор широко используемая; имеет ту же архитектуру, что и EasyOCR (обнаружение + распознавание, без разметки).

Другой ракурс, другой контекст:

• Ауэр и др., Технический отчет Docling, IBM Research 2024 (arXiv:2408.09869). Каскад, учитывающий структуру документа, преобразует результат распознавания текста в проанализированный документ; точка сравнения в разделе 5 данной статьи.
• Смок, Песала, Абрахам, PubTables-1M / Table Transformer (TATR), CVPR 2022 (arXiv:2110.00061). Научная линия, лежащая в основе извлечения таблиц на уровне ячеек, — единственной возможности, которой не хватает EasyOCR.

Ранее в серии:

• Документальная разведка: введение к серии. Что представляет собой серия, кирпичик за кирпичиком, и в каком порядке.
• Базовая модель Enterprise RAG: от PDF-файла до выделенного ответа. Четырехэтапный конвейер от начала до конца: PDF-файл на входе, выделенный ответ на выходе.
• Эмбеддинги — это не магия: предсказуемые сбои в поиске RAG. Где сходство эмбеддингов приносит пользу (синонимы, опечатки, перефразирование), где оно предсказуемо дает сбой (неизвестные термины, отрицание, релевантность термина и ответа) и как его все равно использовать.
• Переранжировщики тоже не волшебство: когда слой кросс-кодировщика оправдывает затраты. Что добавляет кросс-кодировщик по сравнению с встраиванием на основе двух кодировщиков (измеренные показатели) и когда оправдана задержка.
• RAG — это не машинное обучение, и инструментарий машинного обучения решает не ту задачу. Почему оптимизация по размеру фрагментов и тонкая настройка оптимизируют не то, что нужно; вместо этого следует ориентироваться на тип вопроса.
• От регулярных выражений до моделей компьютерного зрения: какой метод RAG подходит для какой задачи? Две оси — сложность документа и контроль вопросов — определяют, какой метод подходит для каждого конкретного случая.
• 10 распространенных ошибок RAG, которые мы постоянно видим на производстве. Десять производственных ошибок, расположенные по пунктам, с указанием способа их исправления.
• Помимо функции extract_text: два слоя PDF-файла, определяющие качество RAG. Первая половина блока анализа: характер документа, сигналы и резюме.
• Прекратите возвращать плоский текст из PDF-файла: необходима реляционная структура RAG. Вторая половина блока парсинга: реляционные таблицы, которые считывает каждый последующий блок.

Кежан Ши Посмотреть все Кежан Ши

Источник: towardsdatascience.com