Про 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