Как автоматизировать извлечение данных из PDF с помощью локальных ИИ-моделей без облачного API

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

Это различие важно, если ваша цель — «отсутствие облачного API». Вы по-прежнему можете использовать локальный API на своей машине, например, HTTP-эндпоинт Ollama на localhost, не отправляя содержимое документов в хостинговый сервис. Ollama заявляет, что запросы и ответы не отправляются обратно в Ollama при локальном запуске моделей, и предоставляет локальный режим, отключающий облачные функции. Docling также по умолчанию отключает удаленные сервисы, хотя файлы моделей могут потребовать загрузки во время настройки, если вы не загрузите их заранее для автономного использования.

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

Быстрая рекомендация: выберите конвейер по типу документа

Нет универсального победителя. Если ваши документы предсказуемы и содержат встроенный текст, парсер плюс небольшая локальная языковая модель могут превзойти гораздо более крупный рабочий процесс компьютерного зрения по стоимости, скорости и воспроизводимости. Если положение текста является частью смысла — например, таблица с объединенными ячейками или форма, где метки и значения пространственно связаны, — обработка с учетом макета становится более ценной.

Шаг 1: Классифицируйте PDF перед выбором OCR или ИИ

Начните с определения того, содержит ли документ уже полезный текст. Цифровой (born-digital) означает, что PDF был создан программным обеспечением и обычно содержит текстовые объекты, которые можно выделить и скопировать. Отсканированный PDF может содержать только изображения страниц, поэтому обычный текстовый парсер вернет мало или ничего.

Официальная документация PyMuPDF показывает прямое извлечение текста с помощью page.get_text(). Минимальный локальный тест выглядит так:

import pymupdf

def extract_native_text(pdf_path: str) -> str:
    pages = []
    with pymupdf.open(pdf_path) as doc:
        for page in doc:
            pages.append(page.get_text())
    return "\f".join(pages)

text = extract_native_text("invoice.pdf")
print(text[:1000])

См. официальные основы PyMuPDF. PyMuPDF также предупреждает, что простой текст PDF может не появляться в естественном порядке чтения и может содержать неожиданные переносы строк. Это ограничение парсера, а не обязательно проблема ИИ.

Лучший вариант: счета-фактуры, выписки, отчеты и формы, где копирование/вставка текста уже работает, и поля легко идентифицировать по соседним меткам.

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

Действие: возьмите 20–50 репрезентативных PDF и классифицируйте их на группы: цифровые, отсканированные, смешанные и с плотной версткой. Ваш конвейер должен маршрутизировать документы по их поведению, а не только по расширению файла.

Шаг 2: Извлекайте текст локально — или используйте OCR только при необходимости

Вариант A: PyMuPDF для чистых цифровых PDF

Если текстовый слой надежен, прямое извлечение обычно является самым простым путем. Это позволяет избежать задержек OCR и ошибок символов OCR в тексте, который уже был закодирован правильно. Для длинных документов вы можете сохранять разделители страниц и обрабатывать группы страниц или логические разделы, а не передавать весь документ в модель сразу.

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

Вариант B: OCRmyPDF плюс Tesseract для отсканированных страниц

Tesseract — это движок OCR с открытым исходным кодом. Его текущее руководство пользователя документирует серию 5.x и поддержку многих языков через отдельные файлы обученных данных. OCRmyPDF оборачивает OCR вокруг специфичной для PDF обработки, чтобы отсканированные страницы могли получить поисковый текстовый слой.

Для смешанного документа, где некоторые страницы уже содержат текст, текущие версии OCRmyPDF поддерживают режим skip:

ocrmypdf --mode skip input.pdf searchable.pdf

Официальная расширенная документация OCRmyPDF объясняет, что --mode skip оставляет страницы с существующим текстом без изменений и выполняет OCR только для тех страниц, которые в этом нуждаются. Та же документация описывает redo для замены ранее обнаруженного OCR и force для растеризации и выполнения OCR всего содержимого. Используйте force осторожно, так как растеризация может удалить преимущества векторной графики и сгладить интерактивный контент.

Для установки Tesseract, языков и поведения командной строки используйте официальное руководство пользователя Tesseract. Язык OCR важен: если ваши счета-фактуры содержат английский и немецкий языки, например, установите и настройте соответствующие языковые данные, а не предполагайте, что модель по умолчанию для английского языка будет одинаково хорошо обрабатывать оба.

Вариант C: Docling, когда важна структура

Docling разработан для преобразования документов с опциями обработки макета, таблиц, OCR и локального зрения-языка. Документация проекта перечисляет расширенное понимание PDF, структуру таблиц, OCR и безпотерьные выводы в формате JSON/Markdown, при этом локальное выполнение предназначено для чувствительных и изолированных рабочих процессов.

Базовое преобразование на Python может быть таким простым:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
doc = converter.convert("input.pdf").document

markdown = doc.export_to_markdown()
structured = doc.export_to_dict()

См. официальное быстрое начало Docling. Docling также поддерживает локальные конвейеры VLM и несколько бэкендов OCR. Его расширенные опции объясняют, что вызовы удаленных сервисов требуют явного согласия, в то время как артефакты моделей можно загрузить заранее для автономного использования.

Лучший вариант: сложные таблицы, заголовки, многостраничные отчеты, смешанные сканы или случаи, когда вам нужно переиспользуемое представление документа вместо простого дампа текста.

Компромисс: конвейер тяжелее, чем простой парсер PDF. Используйте его, потому что дополнительная структура улучшает точность извлечения, а не просто потому, что в нем больше компонентов.

Действие: выберите самый легкий метод извлечения, который сохраняет информацию, необходимую вашей целевой схеме. Не выполняйте OCR чистого встроенного текста и не отбрасывайте макет, когда макет определяет смысл.

Шаг 3: Преобразуйте восстановленный контент в строгую схему с помощью локальной модели

Как только у вас есть достоверный исходный контент, используйте локальную модель для того, в чем она хороша: семантического маппинга. Вместо того чтобы спрашивать: «Извлеки все из этого счета-фактуры», определите поля, которые вам действительно нужны.

Например:

from pydantic import BaseModel
from typing import Optional

class LineItem(BaseModel):
    description: str
    quantity: Optional[float]
    unit_price: Optional[float]
    amount: Optional[float]

class Invoice(BaseModel):
    invoice_number: Optional[str]
    invoice_date: Optional[str]
    vendor_name: Optional[str]
    currency: Optional[str]
    subtotal: Optional[float]
    tax: Optional[float]
    total: Optional[float]
    items: list[LineItem]

Текущая документация Ollama по структурированным выводам поддерживает передачу JSON Schema через поле format и валидацию ответа с помощью Pydantic. Локальный вызов может выглядеть так:

from ollama import chat

schema = Invoice.model_json_schema()

prompt = f"""
Extract the invoice into the supplied schema.

Rules:
- Use only information present in the source.
- Use null when a field is not found.
- Do not infer missing invoice numbers, dates, tax, or totals.
- Preserve line items individually.

SOURCE:
{text}
"""

response = chat(
    model="gpt-oss",
    messages=[{"role": "user", "content": prompt}],
    format=schema,
    options={"temperature": 0},
)

invoice = Invoice.model_validate_json(response.message.content)

Это следует шаблону из официальной документации Ollama по структурированным выводам, которая рекомендует переиспользуемые схемы и низкую температуру, такую как ноль, для более детерминированных структурированных завершений.

Название модели выше является примером из собственной документации Ollama по структурированным выводам, а не утверждением, что это лучшая модель для каждой задачи извлечения. Меньшая модель может быть достаточной для повторяющихся счетов-фактур с четкими метками; более сильная модель может помочь с неоднозначными контрактами или непоследовательными макетами, но обычно потребует больше памяти и времени обработки.

Текстовая модель или модель компьютерного зрения?

Используйте текстовую модель, когда вывод парсера/OCR уже сохраняет отношения между полями, которые вам нужны. Используйте локальную модель с поддержкой зрения, когда визуальное положение существенно или преобразование текста последовательно теряет структуру. Официальная документация Ollama по компьютерному зрению поддерживает входные данные изображений для локальных моделей зрения, и ее функция структурированных выводов может быть объединена с моделями, поддерживающими зрение.

Однако рендеринг каждой страницы в изображение меняет компромисс:

• необходимо обрабатывать больше пикселей;
• страницы высокого разрешения потребляют больше вычислительных мощностей и памяти;
• пакетная обработка страниц становится важной для длинных PDF;
• визуальные модели все еще могут выдумать поле или неправильно прочитать число;
• вам нужен способ отследить извлеченные значения до страницы или области источника.

Действие: начните с текста парсера/OCR плюс локальная LLM с ограничением схемы. Эскалируйте только сложные типы страниц до локальной VLM, вместо того чтобы платить за зрение за каждую страницу.

Шаг 4: Валидируйте перед записью в JSON, CSV, Excel или базу данных

JSON, валидный по схеме, не автоматически фактически корректен. Модель может создать валидные поля с неправильными значениями. Поэтому последний этап должен использовать детерминированные проверки везде, где это возможно.

Для счета-фактуры полезные проверки включают:

• Обязательные поля идентификации: номер счета-фактуры или имя поставщика должны присутствовать, если они нужны вашему рабочему процессу.
• Парсинг дат: анализируйте даты с фиксированной политикой, а не доверяйте неоднозначным строкам, таким как 03/04/26.
• Арифметика: сравните сумму сумм строк с подытогом документа в пределах определенной погрешности.
• Итоги: проверьте, согласован ли подытог плюс налоги и другие сборы с общим итогом.
• Валюта: не предполагайте USD только потому, что документ на английском языке.
• Провенанс: сохраняйте имя исходного файла, номер страницы, временную метку извлечения и, опционально, хэш исходного PDF.
• Очередь на проверку: маршрутизируйте случаи с отсутствующими, конфликтующими или низкими показателями уверенности для ручной проверки, вместо того чтобы молча заполнять значения.

Базовая структура пакета может отделить извлечение от валидации:

from pathlib import Path
import json

for pdf_path in Path("inbox").glob("*.pdf"):
    source_text = extract_native_text(str(pdf_path))

    # If text is unusable, run your OCR or Docling branch here.
    record = extract_with_local_model(source_text)

    errors = validate_record(record)

    if errors:
        save_for_review(pdf_path, record, errors)
    else:
        output = Path("processed") / f"{pdf_path.stem}.json"
        output.write_text(
            json.dumps(record, ensure_ascii=False, indent=2),
            encoding="utf-8"
        )

Вспомогательные функции намеренно оставлены специфичными для приложения, потому что правила валидации радикально различаются между счетами-фактурами, контрактами, налоговыми формами, лабораторными отчетами и заказами на поставку. Универсальный валидатор создал бы ложную уверенность.

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

Действие: определите правила валидации перед обработкой тысяч файлов. Тестируйте на размеченной выборке и записывайте точность на уровне полей, а не просто «документы успешно обработаны».

Практичная полностью локальная архитектура

Для многих малых и средних задач автоматизации это разделение ответственности легче поддерживать, чем модель «все в одном»:

PDF inbox
   |
   +-- born-digital --> PyMuPDF -------------------+
   |                                               |
   +-- scanned/mixed --> OCRmyPDF/Tesseract -------+--> normalized text/layout
   |                                               |
   +-- layout-heavy --> Docling -------------------+
                                                   |
                                                   v
                                         local LLM / VLM
                                                   |
                                            JSON Schema
                                                   |
                                                   v
                                   deterministic validation
                                                   |
                            +----------------------+----------------+
                            |                      |                |
                           JSON                   CSV             database

Этот дизайн позволяет заменять компоненты независимо. Если качество OCR слабое, улучшите слой OCR без переобучения LLM. Если локальная модель слишком медленная, используйте меньшую, не меняя парсер PDF. Если счета-фактуры одного поставщика требуют специальной обработки таблиц, маршрутизируйте только эти файлы через Docling или ветку компьютерного зрения.

Ollama vs. llama.cpp vs. Docling VLM: какой локальный рантайм выбрать?

Официальный репозиторий llama.cpp документирует локальный llama-server и генерацию с ограничением грамматики; текущий код сервера также принимает ограничения JSON-схемы. Документация Docling по моделям зрения перечисляет локальные варианты VLM для преобразования документов.

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

Как сохранить конвейер действительно локальным

«Отсутствие облачного API» должно быть свойством развертывания, которое можно проверить, а не просто маркетинговой этикеткой.

Ollama

Официальный FAQ Ollama говорит, что локальные запросы и ответы не отправляются обратно в Ollama. Он также документирует настройку отключения облака:

OLLAMA_NO_CLOUD=1

или эквивалентную настройку сервера disable_ollama_cloud. Локальный API Ollama работает на http://localhost:11434 и не требует аутентификации для локального доступа, согласно его документации по аутентификации.

Помните, что сервис, привязанный к localhost, отличается от того, который доступен в вашей локальной сети. Если вы измените его адрес привязки или поместите за другой сервер, вы несете ответственность за контроль доступа.

Docling

Docling по умолчанию отключает использование удаленных сервисов. Его документация также различает конфиденциальность обработки и получение моделей: модели могут загружаться при первом использовании, если вы не загрузите их заранее. Для изолированной системы используйте docling-tools models download на подключенной машине подготовки или иначе предварительно загрузите одобренные артефакты моделей, затем укажите автономной среде этот локальный каталог артефактов.

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

Что локальный ИИ не решает

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

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

Как тестировать перед автоматизацией целой папки

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

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

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

Если более простой путь PyMuPDF плюс LLM достигает требуемой точности, оставьте его. Если сканы являются основной причиной сбоев, улучшите OCR. Если проблема в отношениях таблиц, протестируйте Docling. Если поля, расположенные визуально, остаются сложными, маршрутизируйте эту подмножество через локальную модель зрения. Эта поэтапная эскалация обычно дает вам лучший контроль над скоростью и использованием оборудования, чем применение самой тяжелой модели к каждой странице.

Итог

Хорошая локальная система извлечения данных из PDF разделяет чтение документа и семантическое извлечение. Используйте PyMuPDF, когда PDF уже содержит хороший текст; OCRmyPDF/Tesseract, когда страница отсканирована; Docling, когда важны структура и таблицы; и локальную модель Ollama или llama.cpp, когда вам нужен гибкий маппинг в бизнес-схему. Используйте локальное зрение только там, где визуальный макет добавляет информацию, которую текстовый конвейер не может надежно сохранить.

Финальное требование — валидация. JSON Schema может ограничить форму ответа модели, но не может доказать, что сумма, дата, имя или номер счета соответствуют источнику. Если вы спроектируете конвейер так, чтобы неопределенные документы были видны и доступны для проверки, вы можете автоматизировать большую часть извлечения данных из PDF, не передавая документы в облачный API, и не притворяясь, что локальный ИИ устраняет необходимость в контроле качества.