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

Enterprise Document Intelligence [Том 1 #5ter] – Табличные ячейки, OCR, подписи, заголовки: структура облачного уровня, работающая на вашем собственном компьютере. Никаких ключей, никаких счетов за страницу, ничего не покидает здание.

Делиться

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

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

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

Docling — это вторая половина решения. Это парсер документов с открытым исходным кодом от IBM Research (лицензия MIT, указанная в файле LICENSE проекта на GitHub): определение структуры, оптическое распознавание текста (OCR), определение порядка чтения и TableFormer (модель глубокого обучения IBM, которая определяет структуру таблицы (строки, столбцы, заголовки) без использования регулярных выражений). Все это устанавливается через pip install . Он работает на вашем компьютере. Первый вызов загружает модели в локальный кэш; все последующие вызовы выполняются в автономном режиме. Нет ключа API, нет платы за страницу, документ никогда не покидает хост.

В результате получаются те же самые реляционные таблицы, что и в Fitz и Azure. Конвейер обработки данных не интересует, какой движок создал словарь. Извлечение, генерация, аннотирование — чтение строк. Они никогда не читают PDF-файл.

1. Облачные технологии являются ограничением, а не возможностью.

В статье 5 бис были приведены аргументы в пользу более совершенного синтаксического анализа. Таблицы, сохраняющие свои столбцы. Оптическое распознавание текста на отсканированных страницах. Восстановление текста внутри рисунков. Заголовки, даже если в PDF-файле нет закладок. Ни один из этих аргументов здесь не меняется. Меняется лишь место, где происходят вычисления.

Azure DI — это управляемый облачный сервис. Вы отправляете ему байты, он возвращает структуру. Для общедоступной статьи на arXiv это нормально. Но для документов, заполняющих реальный корпоративный архив, это часто не так:

• Конфиденциальность: страховые полисы, медицинские записи, договоры, заключенные в соответствии с соглашением о неразглашении, любые документы, содержащие персональные данные. Передача этих данных через API третьей стороны — это процесс обработки данных, который должен быть одобрен юридическим отделом, и зачастую он этого не делает.
• Место хранения: «Данные остаются в этом регионе» — это договорной термин во многих отраслях. Размещение парсера в облаке не в том регионе нарушает это правило.
• Изолированные от сети среды: В некоторых сетях исходящий интернет отсутствует вовсе. В таких условиях облачный звонок не просто медленный, он невозможен.
• Затраты в больших масштабах: несколько центов за страницу — это ничто для тысячи страниц, а для десяти миллионов — это уже отдельная статья расходов.

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

Остальная часть этой статьи имеет ту же структуру, что и статья 5 бис, поскольку договор тот же. В тех случаях, когда Docling отличается от Azure в деталях, это различие указывается отдельно.

2. Тот же контракт, запущен локально.

Один вызов, те же таблицы, что и в парсере Fitz, той же структуры, всё из одного локального преобразования Docling. Сам вызов SDK Docling короткий: создаём DocumentConverter , передаём ему путь, считываем обратно DoclingDocument . Первый вызов загружает макет и веса TableFormer в локальный кэш; все последующие вызовы выполняются в автономном режиме.

 from docling.document_converter import DocumentConverter converter = DocumentConverter() # lazy: loads no model yet result = converter.convert("data/paper/1706.03762v7.pdf") doc = result.document # a DoclingDocument # what one DoclingDocument exposes doc.export_to_markdown() # full document as markdown doc.tables # TableItem list (each carries .data.table_cells) doc.pictures # PictureItem list (bbox + optional ocr / classification) doc.texts # TextItem list, labelled title / section_header / paragraph / formula / caption

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

 out = parse_pdf_docling("data/contracts/MyContract.pdf") out["line_df"] # text items + table cells + checkboxes out["page_df"] # one row per page out["image_df"] # pictures, ocr_text + classification out["toc_df"] # reconstructed from layout labels out["object_registry"] # captions detected by label out["cross_ref_df"] # body-text mentions (regex) out["span_df"] # empty (no sub-line typography) out["parsing_summary"] # doc-level synthesis dict

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

 def parse_pdf_docling(pdf_path): doc = convert_pdf(pdf_path) # one Docling conversion, shared line_df = docling_pdf_to_line_df(pdf_path, doc=doc) # text + table cells image_df = build_image_df_docling(doc) # pictures + ocr_text toc_df = build_toc_df_docling(doc) # title / section_header object_registry = build_object_registry_docling(doc) # caption labels page_df = build_page_df(line_df) # reused fitz builder (line_df only) cross_ref_df = build_cross_ref_df(line_df) # reused fitz builder (line_df only) return {"line_df": line_df, "image_df": image_df, "toc_df": toc_df, "object_registry": object_registry, "page_df": page_df, "cross_ref_df": cross_ref_df, "span_df": pd.DataFrame(), "parsing_summary": parsing_summary}

Если читать сверху вниз: один convert_pdf запускает модели один раз, затем для каждой таблицы используется один небольшой построитель (каждый читает этот общий doc ), а две таблицы, которым нужен только line_df , page_df и cross_ref_df , создаются теми же самыми построителями fitz, которые использует нативный парсер. Словарь в конце — это контракт, который возвращает каждый движок.

Что именно выполняет эта одна операция преобразования. Заманчиво отнести Docling к категории «OCR». Но это не OCR; OCR — это один из необязательных этапов внутри него. Функция convert() сначала запускает модель макета (она находит области, таблицу, рисунок, заголовок, основной текст и порядок их чтения), затем TableFormer для каждой обнаруженной таблицы (сетка строк, столбцов и заголовков), и только затем, если страница является сканом без текстового слоя, запускается механизм OCR для чтения пикселей. В изначально цифровом PDF-файле этап OCR полностью пропускается: текст ячейки берется из исходного текстового слоя. Таким образом, разметка таблицы — это структура TableFormer, заполненная текстом ячеек, которую в исходном PDF-файле OCR никогда не обрабатывал. Выбранный вами механизм OCR (EasyOCR, PaddleOCR, Tesseract, RapidOCR) изменяет только то, что происходит со сканированными пикселями, а параметр качества для самих таблиц — это режим TableFormer ( fast или accurate ), а не бэкэнд OCR.

3. Что выигрывает каждый стол

Чтобы продемонстрировать это на наглядном примере, мы запустили Docling на статье «Attention Is All You Need» (Vaswani et al. 2017; лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv), на том же общедоступном PDF-файле arXiv, который использовался во всей серии. Пятнадцать страниц, изначально цифровой формат, без закладок, четыре реальные таблицы, шесть рисунков, пять уравнений отображения. Документ, в котором Фитц и так хорошо справляется с прозой, но теряет таблицы и структуру разделов. Вставьте свой собственный PDF-файл, и те же самые конструкторы запустят программу; приведенные ниже результаты — это то, что Docling вернул в этом случае.

3.1. line_df получает строки ячеек таблицы, текст рисунка и флажки.

Модель TableFormer от Docling распознает каждую таблицу как сетку ячеек с индексами строк и столбцов, а также флагами заголовка. Мы преобразуем эту сетку в строки Markdown, так что таблица располагается внутри line_df , как и любой другой контент, по одной строке на каждую строку таблицы, с разделителем | --- | после заголовка. Таблица 1 из статьи (сравнение сложности 5 строк, 4 столбца) возвращается в виде шести строк line_df : пять строк данных плюс разделитель | --- | после заголовка.

Сам процесс сглаживания несложный и заслуживает внимания, поскольку в нём и заключается весь секрет: создайте пустую сетку размером rows x cols , поместите каждую ячейку TableFormer в её слот (row, column) , а затем объедините каждую строку в одну строку Markdown.

 def table_to_markdown_rows(table): n_rows, n_cols = table.data.num_rows, table.data.num_cols grid = [[""] * n_cols for _ in range(n_rows)] header = set() for cell in table.data.table_cells: # the cells TableFormer found row, col = cell.start_row_offset_idx, cell.start_col_offset_idx grid[row][col] = cell.text.strip() if cell.column_header: header.add(row) h = min(header) if header else 0 rows = ["| " + " | ".join(grid[h]) + " |", # header row "| " + " | ".join(["---"] * n_cols) + " |"] # separator rows += ["| " + " | ".join(grid[r]) + " |" # data rows for r in range(n_rows) if r != h] return rows # one markdown line per source row -> one line_df row each 

Мы храним ячейки внутри line_df вместо добавления отдельной таблицы table-cells. Один DataFrame для каждого последующего блока данных; строки абзацев и строки таблицы выглядят одинаково при выводе. Цена: запросы к каждой ячейке требуют этапа анализа Markdown. Для вопросов RAG это приемлемо. Извлекатель сопоставляет ключевые слова с текстом строки. Модель считывает Markdown напрямую. Это то же самое проектное решение, что и в построителе Azure, поэтому последующий блок данных обрабатывает строки таблиц fitz, Azure и Docling одинаково.

Еще два источника данных передают информацию line_df . Текст, который Docling находит внутри области рисунка, отображается как обычные текстовые строки (восстановленные с помощью компоновки + OCR), поэтому метка, отображаемая внутри диаграммы, становится доступной для поиска. А флажки становятся строками из одного символа: [x] для выбранного и [ ] для невыбранного, поэтому поле формы с флажком становится доступным для запросов. В статье Attention количество строк увеличивается с исходного текста до 560 после объединения четырех таблиц.

3.2. image_df получает ocr_text и столбец classification .

Та же строка, два новых столбца. Для каждого обнаруженного изображения мы собираем все текстовые элементы, чей ограничивающий прямоугольник находится внутри области изображения не менее чем на 50%, и объединяем их в ocr_text . Диаграмма архитектуры на странице 3 и две диаграммы внимания на странице 4 содержат свои метки внутри изображения; эти метки отображаются в ocr_text и становятся доступными для извлечения.

Второй новый столбец — classification . Docling поставляется с дополнительным классификатором изображений, который помечает каждое изображение (тип диаграммы, логотип и т. д.). Когда классификатор включен, метка попадает в classification ; если нет, столбец присутствует для обеспечения идентичности формы, но остается пустым. В Azure нет аналога, поэтому Docling идет дальше. В image_df , созданном fitz, такого же столбца вообще нет; fitz возвращает width_px / height_px / image_hash и никогда не выполняет OCR-распознавание изображения.

3.3. toc_df восстанавливается из меток макета.

В документе «Внимание» отсутствуют встроенные закладки. Запустите на нем build_toc_df из пакета fitz, и вы получите пустую таблицу, что является типичным случаем в корпоративной среде: экспорт в Word, сканирование, все, что не создано в LaTeX с настроенными гиперссылками. В этом случае при генерации теряется структура разделов.

Docling напрямую подписывает каждый заголовок:

• title документа, если он обнаружен.
• Для каждого заголовка раздела создается элемент section_header (в данной работе Docling даже заголовок помечал как заголовок раздела).

Конструктор проходит по обеим меткам, назначает уровень и формирует оглавление с теми же столбцами start_page , end_page , start_y и breadcrumb , что и путь fitz. Проход обратного просмотра, вычисляющий end_page , идентичен проходу fitz и Azure; отличается только источник строк.

В статье Attention программа восстанавливает 28 заголовков, тогда как fitz не восстанавливает ни одного. Это число не завышено: Docling пометил каждый заголовок раздела один раз, включая подразделы «Метод» и «Результаты», что верно для данной статьи. В документе с более короткими и насыщенными разделами количество будет меньше.

Глубина иерархии зависит от документа. Когда модель компоновки Docling назначает отдельные уровни заголовков, получается настоящее многоуровневое дерево; в этом документе заголовки были помечены на одном уровне, поэтому восстановленное оглавление в основном плоское. В любом случае это пригодный для использования индекс разделов, тогда как fitz не дал бы ничего. Azure делает то же самое с помощью собственных тегов ролей; оба варианта одинаковы, поскольку Docling работает локально.

3.4. object_registry получает возможность определения меток подписи.

Fitz обнаруживает подписи с помощью регулярных выражений, привязанных к началу строки: ^Figure d+b , ^Table d+b . Он пропускает Fig. 2 и многострочные переносы, а также выдает ложные срабатывания на предложение, начинающееся со слов «Рисунок 2 показывает…».

Docling помечает блоки подписей меткой caption во время анализа макета. Мы считываем метку напрямую, без необходимости использования регулярных выражений для поиска подписи. Ключ объединения (object_type, object_id) в cross_ref_df по-прежнему извлекается из текста подписи с помощью того же регулярного выражения, которое используют fitz и Azure Builders, поэтому объединение работает одинаково с любым движком. В статье Attention это позволяет поместить все девять подписей (рисунки 1–5, таблицы 1–4) в object_registry . Преимущество заключается в возможности повторного поиска: Docling обнаруживает подписи, которые пропустило бы регулярное выражение fitz для начала строки.

3.5. parsing_summary получает специфичные для Docling статистические данные.

В сводном словаре на уровне документа обнаруживаются три пункта:

• n_tables_detected : количество таблиц, обнаруженных TableFormer (4 в статье об механизме внимания).
• n_pictures : сколько изображений идентифицировала модель компоновки (6).
• n_formulas : сколько уравнений Docling помечено как formula (5).

Это упрощает маршрутизацию. Документ с n_tables_detected = 18 выглядит как контракт, где структура таблиц имеет значение. Документ с n_formulas исчисляемым десятками, — это работа, насыщенная математическими вычислениями, где может потребоваться последующий этап обработки с учетом формул. Документ с n_pictures = 0 — это только текст; нет смысла сканировать рисунки на предмет наличия текста внутри.

3.6. page_df и cross_ref_df: без изменений

Две таблицы сохраняют свою форму. page_df и cross_ref_df создаются исключительно на основе line_df , поэтому механизм, создавший line_df не имеет значения. Одна реализация, три механизма, никакого смещения.

В Docling переменная span_df пуста, как и в Azure. Модель компоновки не поддерживает типографику подстрок (жирный или курсив для каждого слова). Если вам нужны span-элементы для определения заголовков или выделения терминов, используйте fitz для этого документа. Эти движки дополняют друг друга.

4. Столбец parsing_method: происхождение для адаптивного анализа.

Каждая таблица, содержащая данные из parse_pdf_docling имеет значение parsing_method == "docling" . Каждая таблица, содержащая данные из parse_pdf , имеет значение "fitz" ; из parse_pdf_azure_layout — "azure_layout" . Один и тот же столбец, одно и то же имя, во всех движках. Суть в следующем потоке.

Вот что использует адаптивный синтаксический анализ (статья 10). По умолчанию используется fitz. Страницы, не прошедшие предварительную проверку (область таблицы без извлеченных строк, страница с большим количеством изображений и редким текстом, слой OCR низкого качества), повторно анализируются более мощным движком. В Docling этот повторный анализ выполняется локально, поэтому он остается доступным, даже если документ не может быть загружен в облако. Повторно проанализированные строки заменяют или добавляются к исходным строкам line_df , а столбец parsing_method сохраняет историю изменений.

Три варианта дальнейшего использования, которые обеспечивает эта колонка:

• Дедупликация : если одна и та же страница проходит два прохода, сохраняйте строки более ресурсоемкого движка по сравнению со строками Fitz с помощью явной карты приоритета.
• Аудит : строка с parsing_method == "docling" указывает на то, что она была создана моделью, а не путем извлечения обычного текста; взвешивание достоверности ответа может использовать это значение.
• Учет маршрутизации : какие страницы нуждались в ускоренном прохождении по маршруту и сколько времени это занимало.

5. Стоимость, задержка и настройка.

Docling может работать бесплатно, но не бесплатно. Важны три вещи.

Задержка: На ЦП обработка страницы полным конвейером Docling (макет + TableFormer + OCR) занимает примерно от 1 до 5 секунд в зависимости от загруженности страницы. 15-страничный документ Attention с включенным OCR был обработан менее чем за пару минут на ЦП ноутбука. Использование графического процессора значительно сокращает это время. Fitz обрабатывает тот же документ менее чем за секунду. Таким образом, правило маршрутизации такое же, как и для Azure: сначала обрабатывается Fitz, затем переходит к Docling только для страниц, которые Fitz обработал плохо. Разница с Azure заключается в том, что переход к Docling стоит процессорного времени, а не денег или сетевого обмена данными.

Настройка: При первом преобразовании модели макета и TableFormer (сотни МБ) загружаются в локальный кэш, а установка docling подключает PyTorch, который тоже довольно большой. Заложите в бюджет средства на диск и однократную загрузку. После этого система работает в автономном режиме. В изолированной среде кэш моделей предварительно подготавливается; при выполнении запроса к кэшу данных нет.

Плата за вычислительные ресурсы, а не за страницу: плата за страницу отсутствует. Стоимость определяется используемым оборудованием. Для обработки десяти миллионов страниц конфиденциальных данных в год владение вычислительными ресурсами обычно обходится дешевле, чем оплата облачных услуг за страницу, и это единственный вариант, когда данные вообще нельзя выносить за пределы хранилища.

Эти показатели меняются в зависимости от аппаратного обеспечения и версий Docling. Важна именно форма: fitz практически бесплатен и работает мгновенно, Docling требует секунд локальных вычислений и одноразовой настройки, Azure стоит несколько центов за страницу и сетевой переход к облаку, которому нужно доверять.

6. Когда звонить в какой раз

По умолчанию используется fitz. При появлении определённого сигнала, указывающего на недостаточность fitz, следует активировать движок, определяющий, к какому уровню нагрузки может быть отнесен документ.

• fitz : по умолчанию выполняется каждый анализ. PDF-файлы, созданные в цифровом формате, с возможностью выделения текста и простой структурой. Бесплатно, мгновенно, в автономном режиме.
• Docling : когда Fitz не справляется (таблицы, сканы, текст рисунков, отсутствие закладок) , а документ является конфиденциальным или среда изолирована от сети. Локальный, бесплатный, ничего не покидает машину. Также это правильный вариант по умолчанию, когда вы предпочитаете владеть вычислительными ресурсами, а не платить за страницу.
• Azure DI : когда Fitz не срабатывает , и отправка документа в облако приемлема, а вы предпочитаете использовать управляемый сервис, а не запускать модели самостоятельно. Стоимость за страницу, нулевая инфраструктура для обслуживания, самое быстрое подключение.

Сигналы, запускающие эскалацию, те же самые, что перечислены в статье 5 bis: обнаруженная область таблицы без строковой структуры, страница с большим количеством изображений и редким текстом, низкий показатель качества OCR или документ без исходного оглавления, для генерации которого необходим контекст раздела. Статья 10 формирует диспетчер, который считывает эти сигналы. Столбец parsing_method позволяет каждому последующему этапу узнать, какой механизм работал с какой строкой.

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

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

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

Docling описан в техническом отчете IBM Research (Auer et al. 2024), в котором описывается конвейер компоновки, модель обнаружения ячеек TableFormer и этап определения порядка чтения. Извлечение таблиц на уровне ячеек, которое наследует Docling, имеет свою собственную исследовательскую родословную (Smock et al. 2022, PubTables-1M / Table Transformer). Правильным перекрестным прочтением для этой статьи является статья 5bis (Azure DI), которая описывает тот же контракт на таблицы из платного облачного сервиса: те же возможности, но другой операционный профиль.

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

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

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

• Microsoft, Azure AI Document Intelligence. Модель компоновки. Платный облачный аналог той же каскадной модели (статья 5bis). Тот же контракт на таблицы; обмен локальных вычислительных ресурсов на загрузку в облако и стоимость за страницу. Правильный выбор, когда оперативная группа предпочитает управляемый сервис размещению весовых коэффициентов модели локально.

Вопрос редко сводится к «какой парсер лучше», скорее к «что разрешено делать этому документу и что нужно этой странице». Страница, созданная в цифровом формате, с чистым текстом: Fitz. Страница с таблицей в общедоступном отчете: Azure, если вам нужно управляемое приложение, Docling, если вам нужно локальное. Статья 10 связывает диспетчер, который выполняет вызов для каждой страницы.

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

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

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

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