Программное обеспечение для обработки изображений также является парсером PDF-файлов: чтение диаграмм и графиков для RAG.

Enterprise Document Intelligence [Том 1 #5квартал] – Другие парсеры считывают слова на странице. Модель машинного зрения также считывает изображения.

Делиться

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

Если показать парсеру PDF-файлов диаграмму, он увидит пустой прямоугольник. Текстовые движки, встроенные, облачные или локальные, находят слова на странице и помещают их в таблицы с возможностью поиска. Диаграмма же не содержит слов, поэтому для каждого из них эта область пуста, а для системы поиска она как бы не существует.

Модель компьютерного зрения отличается. Она анализирует страницу так же, как это делал бы человек. Если вы запросите у неё текст, она предоставит вам текст и таблицы, как и другие. Если вы покажете ей диаграмму, она объяснит, что на ней написано, простыми словами, с помощью которых можно выполнить поиск. Именно этого не могут сделать другие модели.

Подвох в том, что он медленнее, дороже и считывает числа с диаграммы лишь приблизительно. Кроме того, его качество зависит от выбранной модели. gpt-4.1 считывает диаграмму, которую более дешевый gpt-4o-mini считывает лишь частично. Поэтому его не стоит использовать везде. Он нужен только для страниц, содержащих в основном изображения, где другие парсеры дают пустые результаты.

1. Единственное, что может сделать только модель компьютерного зрения: сделать изображение доступным для поиска.

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

Модель обработки изображений считывает картинку. Ниже представлены три рисунка, взятые непосредственно из двух PDF-файлов: диаграммы Transformer из работы Attention Is All You Need (Vaswani et al. 2017) и графики цен на сырьевые товары из обзора товарных рынков Всемирного банка (выпуск за апрель 2026 г.). Каждый рисунок сопровождается однострочным описанием, написанным для него gpt-4.1 . Исходные документы и информация о лицензировании приведены в конце статьи.

Теперь график цен представляет собой предложение: индексы цен на сырьевые товары по секторам, снижающиеся с пика 2022 года. Пользователь, ищущий «индекс цен на сырьевые товары с 2022 года», теперь может попасть на эту страницу. Раньше на ней не было ничего, что соответствовало бы запросу.

Вот аргумент в его наиболее наглядной форме. Представьте спутниковый снимок парковки. На нем нет никакого текста. OCR ничего не находит, макет находит один блок, и для системы поиска изображение как бы не существует. Модель машинного зрения пишет: «Вид сверху на парковку, примерно наполовину заполненную, около сорока машин». Теперь поиск по запросу «занятость парковки» находит это. Это предложение — результат синтаксического анализа, и только модель машинного зрения может его воспроизвести. OCR и макет по определению не могут этого сделать, потому что символов для чтения никогда и не было.

2. Он также анализирует текст и таблицы, как и другие.

Рисунок — это уникальная часть, но парсер, который читает только изображения, был бы бесполезен. Модель компьютерного зрения читает также текст и таблицы, и делает это не хуже, чем текстовые движки на чистом материале. Мы направили parse_page_vision на страницу 30 Рамочной программы кибербезопасности NIST, таблицу «Основа Рамочной программы», и запросили разметку Markdown. Она вернула столбцы таблицы без изменений, объединенные ячейки обработаны (имя функции находится в первой строке своего блока, а в последующих строках оно остается пустым).

Это та же самая структура ячеек, которую Docling и Azure создают с той же страницы в двух предыдущих статьях: они тоже генерируют таблицы в формате Markdown, поэтому формат не является тем, что отличает Vision. Модель Vision никогда не создавала объект таблицы; она считывала сетку с изображения и записывала данные в формате Markdown (она так же хорошо возвращает HTML). Таким образом, утверждение из ведущего верно: это парсер, возвращающий многократно используемую модель, которую возвращают другие, плюс изображения, которые они не могут вернуть.

3. Модель имеет значение: gpt-4o-mini не считывает диаграммы, которые считывает gpt-4.1.

Качество анализа во многом зависит от модели, и разница точно показывает, где это важно — на графиках. Мы прогнали одну и ту же страницу с диаграммами CMO через gpt-4o-mini и gpt-4.1 .

gpt-4o-mini обнаружил три из шести диаграмм и обозначил две из них как таблицы. gpt-4.1 обнаружил все шесть и перенёс их оси до месяца, включая диаграммы неопределённости политики и температурных аномалий, которые пропустила меньшая модель. Обе модели правильно прочитали текст страницы и таблицу NIST. Более слабая модель не справилась с изображениями, а ведь именно для этого и было создано компьютерное зрение. Таким образом, в этом парсере модель является частью качества, а не просто регулятором задержки и стоимости: более дешёвая модель компьютерного зрения корректно обрабатывает текст, но плохо — графики.

4. Честная торговля: точность и стоимость

Всё это не бесплатно, и подвох стоит обозначить прямо. Дело не в том, что система компьютерного зрения «на самом деле не анализирует информацию», потому что она это делает. Дело в том, что анализ менее точен и обходится дороже за страницу.

Выделяются две статьи расходов.

Точность имеет две стороны: значения, считываемые с кривой, являются приблизительными: форма и суть верны, но конкретная отметка может быть неточной, поэтому следует рассматривать записанное число как подсказку, а не как факт. Хуже того, он может незаметно пропустить элемент, строку таблицы или один график на панели, как это сделал gpt-4o-mini пропустив половину графиков в разделе 3. Это проблема полноты, своего рода галлюцинация путем пропуска, и детерминированный парсер никогда с ней не сталкивается: когда fitz или Docling считывают таблицу, ни одна строка не пропускается.

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

Таким образом, правило заключается не в «визуализации вместо анализа». Оно заключается в «визуализации страниц, которые текстовые парсеры не замечают».

5. Как это работает: parse_page_vision

Механизм невелик. Функция отображает страницу, отправляет изображение в модель обработки изображений через тот же responses.parse для структурированного вывода, который используется в других местах серии, и возвращает небольшой объект: страницу в формате Markdown и список рисунков, каждый из которых имеет kind , description и transcription .

 page = parse_page_vision("CMO-April-2026.pdf", 10, model="gpt-4.1") page.markdown # headings, paragraphs, tables page.figures # one entry per chart / diagram page.figures[0].description # "line chart, price index ..." page.figures[0].transcription # axes, legend, readable values

parse_page_vision является родственным парсерам fitz , azure_layout и docling , поскольку он тоже является парсером. Диспетчер адаптивного парсинга (статья 10) обращается к нему, когда страница достаточно визуальна, чтобы текстовые движки возвращали пустые результаты.

Текст достаточно короткий, чтобы его можно было прочитать за один проход. Две модели Pydantic задают выходные данные: страница в формате Markdown, плюс одна запись для каждого рисунка с указанием его типа, описания и транскрипции. Функция преобразует страницу в изображение, добавляет инструкцию и выполняет один структурированный вызов через общую обертку llm_parse . Повторные попытки, ограничения на количество токенов и кэш вызовов входят в состав обертки. Нет модели компоновки и нет этапа распознавания текста: модель считывает пиксели и заполняет схему.

 class FigureContent(BaseModel): kind: str # chart, diagram, photo, map, ... description: str # what it shows, in searchable words transcription: str # axes, legend, readable values class VisionPageParse(BaseModel): markdown: str # the page as markdown, tables kept figures: list[FigureContent] # one entry per figure on the page def parse_page_vision(pdf_path, page, *, client=None, model=None, zoom=2.0): client = client or get_vision_client() model = model or vision_model() page_image = render_page_data_url(pdf_path, page, zoom=zoom) content = [{"type": "input_text", "text": "Parse this page."}, {"type": "input_image", "image_url": page_image}] return llm_parse( input=[{"role": "system", "content": VISION_PARSE_SYSTEM_PROMPT}, {"role": "user", "content": content}], text_format=VisionPageParse, # the Pydantic contract above client=client, model=model, label="vision.parse_page", )

Системная подсказка ( VISION_PARSE_SYSTEM_PROMPT ) — это вторая половина движка: она указывает модели сохранять заголовки и порядок чтения, отображать каждую таблицу как таблицу Markdown и добавлять по одной записи к каждому рисунку, описание которого можно будет позже найти с помощью поиска. Изменение этой инструкции изменит работу парсера.

6. Более лёгкий режим: задайте вопрос непосредственно странице.

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

 ans = answer_from_pdf_vision( "data/nist/NIST.CSWP.04162018.pdf", "Category Unique Identifier for 'Asset Management'?", pages=30, ) ans.answer # "ID.AM" ans.answer_found # True (False when not on the page)

Оно ведет себя нормально, и здесь модель практически не имеет значения: и gpt-4o-mini , и gpt-4.1 отвечают на эти вопросы одинаково. Поиск в ядре фреймворка вернул ID.AM , Function Identify ; вопрос о рисунке 1 из статьи Attention, который можно прочитать по диаграмме, дал правильный ответ; а вопрос, ответа на который не было на странице, не дал никакого результата.

Третий ряд так же важен, как и первые два. Модель, считывающая страницу, придумает правдоподобный ответ, если схема и инструкция не предоставят ей явного способа сказать «не здесь». Срабатывание нулевого пути делает этот режим безопасным для использования.

Та же идея, только в готовом виде. Шаблон «зрение как парсер» теперь поставляется в виде оптимизированного продукта несколькими поставщиками. Mistral Document AI на Azure AI Foundry (модель mistral-document-ai-2512 , доступная как бессерверный API в регионах East US / East US 2 / Sweden Central) объединяет компонент OCR ( mistral-ocr-2512 ) с небольшой моделью рассуждений ( mistral-small-2506 ) и возвращает Markdown плюс объект JSON, схему которого можно настроить. Контракт вывода отличается от parse_page_vision : вместо line_df используется Markdown, структурированное извлечение встроено в тот же вызов, а не перенесено на этап генерации. Та же основная идея, но в готовом виде для модели оплаты за страницу. Для конвейеров, которые уже используют Markdown или хотят объединить этап компоновки и извлечения в один вызов API, стоит сравнить это с подходом OpenAI Vision, использованным в этой статье.

Проблема с ограничивающими рамками реальна. Mistral OCR возвращает ограничивающие рамки только для изображений, встроенных в страницу (каждое изображение содержит координаты top_left_x / top_left_y / bottom_right_x / bottom_right_y ). В самом тексте Markdown отсутствуют ограничивающие рамки для каждой строки, абзаца или ячейки таблицы . Это нарушает работу двух функций, на которые опирается остальная часть серии: этап аннотирования PDF в статье 1 (для выделения цитируемых строк в исходном PDF-файле необходимы ограничивающие рамки) и проверка поиска на уровне строк в статье 7 (каждая найденная строка указывает на свою ограничивающую рамку, чтобы читатель мог проверить ее на странице).

Таким образом, перед читателем встаёт открытый вопрос. Как можно согласовать работу двух парсеров, работающих на одной странице: Markdown от Mistral (структурированный, но без ограничивающих рамок) и line_df от fitz/Docling (богатый ограничивающими рамками, но более плоский), в единый согласованный результат, который сможет использовать ваш последующий клиент? Выравнивание двух текстовых потоков на уровне строк или токенов — известная сложная проблема (сегментация различается, ошибки OCR различаются, сглаживание таблиц в Markdown приводит к потере позиций ячеек). В статье не предлагается решения. Если вашему последующему клиенту необходима отслеживаемость на уровне ограничивающих рамок, затраты на согласование реальны и их стоит оценить, прежде чем принимать окончательное решение по контракту Markdown.

Источники для этого раздела:

• Спецификация конечной точки API Mistral OCR, схема ввода, схема ответа (страницы с markdown + массив images , только ограничивающие рамки изображений).
• Документация по процессору OCR Mistral (базовый OCR), параметр table_format , структура ответа для каждой страницы.
• Документы с аннотациями Mistral, опциональное структурированное извлечение с использованием пользовательских схем, аннотации на уровне ограничивающих рамок (bbox) по явному запросу.
• Mistral Document AI 2512 на каталоге Azure AI Foundry, бессерверное развертывание в восточной части США / восточной части США 2 / центральной части Швеции, оплата за страницу.
• Раскрытие потенциала распознавания документов с помощью Mistral Document AI в Microsoft Foundry, входящего в состав пакета mistral-ocr-2512 + mistral-small-2506 .

7. Теперь четыре парсера, один из них считывает изображения.

Все четыре движка являются парсерами. Три считывают текст и структуру; четвёртый считывает и их, и изображения поверх них.

Статья 10 (адаптивный синтаксический анализ) создает диспетчер, который выбирает элементы для каждой страницы. Визуальный синтаксический анализатор находится на визуальном конце: его следует использовать, когда страница в основном состоит из диаграммы, когда ответ содержится в схеме, когда отсканированное изображение слишком плохого качества для распознавания текста или когда контент представляет собой изображение без текста. Он является самым ресурсоемким на страницу и наименее точным по показателям, поэтому работает последним. Но это единственный механизм, который преобразует изображение в нечто, что можно восстановить.

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

Модель машинного зрения — это парсер: запросите Markdown, и он вернет текст и таблицы, как Fitz или Azure; запросите описание изображений, и он вернет то, чего не могут текстовые парсеры — поисковые слова по изображению. Разница реальна (менее точная, нет ограничивающих рамок, один вызов модели на страницу), поэтому парсер машинного зрения не заменяет текстовые, а закрывает их «слепое пятно». Они читают слова на странице; он читает страницу, на которой нет слов.

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

Модели обработки визуальной информации на языке программирования (VLM) как парсеры документов происходят из двух направлений: открытой литературы VLM (PaliGemma, Florence-2, семейство Qwen-VL) и передовых мультимодальных API (OpenAI GPT-4o / GPT-4.1, Anthropic Claude с функциями обработки визуальной информации, Google Gemini). Правильным перекрестным прочтением для этой статьи является ColPali (Faysse et al. 2024), где визуальная страница сама по себе является примитивом поиска, и страницы документации, специфичные для каждой модели, где OpenAI публикует возможности обработки визуальной информации gpt-4.1 и gpt-4o-mini .

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

• Возможности OpenAI в области машинного зрения семейства gpt-4.1. Справочная документация по модели, лежащей в основе parse_page_vision ; та же архитектурная схема (машинное зрение LLM в качестве парсера, возвращающего Markdown или структурированный вывод).
• Фейсс и др., ColPali: Эффективный поиск документов с использованием моделей визуального языка, 2024 (arXiv:2407.01449). Поиск визуального языка непосредственно на изображении страницы. Привязывается к визуальной строке диагностической сетки статьи 4; тот же набор методов применяется к другому блоку (поиск, а не анализ).

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

• Ауэр и др., Технический отчет Docling, IBM Research 2024 (arXiv:2408.09869). Парсинг на основе компоновки без генеративной модели. Различные компромиссы между стоимостью и качеством: детерминированный, дешевый, нечувствительный к цифрам. Статья 5ter (парсинг Docling) описывает разработку этого механизма от начала до конца.
• Microsoft, Azure AI Document Intelligence. Облачный парсер на уровне ячеек. Та же проблема, что и у Docling при работе с цифрами, дополняет технологию Vision LLM для всех остальных типов контента.

Исходные документы и лицензирование. Рисунки и таблицы в этой статье воспроизведены из источников с открытой лицензией:

• Внимание — это всё, что вам нужно (Васвани и др., 2017), arXiv:1706.03762. Лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv.
• Всемирный банк, Обзор товарных рынков, выпуск за апрель 2026 г. CC BY 3.0 IGO, как указано на странице публикации OKR.
• Структура кибербезопасности NIST версии 1.1 (NIST CSWP 04162018). Работа правительства США, общественное достояние в США (см. заявление NIST об авторских правах).
• gpt-4.1 и gpt-4o-mini — это проприетарные модели OpenAI, способные обрабатывать изображения, и на них распространяются Условия использования OpenAI.

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

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

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

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