Про PDF OCR и Bounding Boxes: рентген для ваших документов — где это применяется и на что обращать внимание при выборе парсеров документов.
Сейчас работаю над проектом, где также требуется ручная проверка результатов AI. И в очередной раз провел раунд сравнения различных инструментов для парсинга PDF. Расскажу про bbox в целом и конкретные тулы, которые я использую.
Про bbox я уже упоминал — это координаты прямоугольника, который описывает положение элемента на странице. Формат обычно [x1, y1, x2, y2].
Где это применяется
Очевидный юзкейс — Human Review (например на видео — реальный проект) или эдакий deeplink на точку в документе в RAG-системах. Но применение шире, например, я часто использую это в Evaluation пайплайнах — Bbox дает ground truth для автоматической оценки.
Уровни гранулярности
Не все bounding boxes одинаковые. Есть спектр:
— Блок — крупный кусок: весь текст до следующего заголовка
— Элемент — абзац, пункт списка, таблица, рисунок (обычно идеальный баланс гранулярности)
— Строка/слово/символ — максимальная гранулярность, на практике нужно редко
Два подхода к grounding
1. Inline grounding (eager) — каждый блок текста несет ссылку на свой источник. Обычно это anchor/референс (ID блока), реже и сами bbox прямо инлайном. В ответах LLM будет сразу референс на bbox.
1. Post-hoc grounding (lazy) — LLM/агент работает с чистым markdown без каких-либо референсов. Рядом лежит JSON с bbox и текстом каждого блока. Когда агент возвращает цитату и страницу — детерминированно ищем этот текст в JSON и достаем bbox. Агент вообще не знает про bbox, input чистый.
На практике post-hoc почти всегда лучше для контекст-инжиниринга. Бывают исключения, но rule of thumb — при прочих равных выбирайте его.
Мой опыт: Marker -> MinerU
До недавнего времени моим фаворитом был Marker + DataLab (их hosted API). Отличный инструмент, прекрасный playground для тестирования. Но в этом проекте столкнулся с проблемой гранулярности: когда вместо элемента списка — подсвечивается полстраницы.
Переехал на MinerU от OpenDataLab (китайские ребята). Ключевое отличие — MinerU отдает каждый ListItem как отдельный элемент с собственным bbox. Именно то, что нужно для точного grounding, еще и поддерживается правильная иерархия. У MinerU есть облако с какими-то супер-щедрыми лимитами типа 10K файлов в день. И локально запускается, но учитывайте что это 3-10 секунд на страницу при больших объемах — медленно. И, кстати, они используют в том числе SOTA модель PaddleOCR, которую не зря нахваливал Глеб.
Альтернативы
Альтернатив море: Docling, LlamaParse, cloud APIs (Azure Document Intelligence, AWS Textract, Google Document AI), можно даже Gemini напрямую скармливать страницы и тд. Я тестил многое из этого.
Мой критерий простой: нужен инструмент, у которого есть и облако, и совместимая локальная версия. Облако — для скорости и чтобы мой комп не жужжал. Локальная версия — для sensitive данных.
Второй момент: зрелый пайплайн. Когда подключаешь Gemini или PaddleOCR напрямую, весь scaffolding (PDF->IMG, нормализация, reading order, иерархия элементов, обработка таблиц, SO) ложится на тебя.
Фронтенд: подсветка в PDF
Для визуализации bbox в браузере — PDF.js и React-обертки вокруг него: react-pdf-viewer с highlight plugin (как на видео).
Короче, если работаете с PDF — заранее продумайте grounding. Это относительно недорогая фича, которая дает кратный рост доверия пользователей к системе.
🔥➕🔁 @nobilix
Добавить комментарий