Как ИИ-агенты обрабатывают бизнес-документы: PDF, таблицы и контракты

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

Современный пайплайн обработки документов

Каждый серьёзный пайплайн обработки документов в 2026 году следует одной и той же базовой архитектуре, независимо от типа файла:

1. Приём — файл поступает через вложение в электронной почте, загрузку, API-вебхук или отслеживание файловой системы. 2. Нормализация формата — парсер преобразует файл в рабочее представление (необработанный текст, markdown или структурированные элементы). 3. Извлечение с помощью OCR / компьютерного зрения (для отсканированных или основанных на изображениях файлов) — OCR-движок считывает пиксели и генерирует текст. 4. Извлечение на основе LLM — языковая модель принимает нормализованный текст и извлекает структурированные поля, классификации или резюме. 5. Проверка и маршрутизация — извлечённые данные проверяются по схемам, помечаются для ручной проверки, если достоверность низкая, и записываются в целевую систему.

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

Обработка PDF: текстовые, сканированные и гибридные кошмары

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

Текстовые PDF — созданные в цифровом виде, обычно из Word или Google Docs. Это простой случай. Такие инструменты, как pdfplumber, PyMuPDF (fitz) или pdf-parse, извлекают текст напрямую без какого-либо OCR. Типичный PDF-счёт-фактура выдаёт чистый текст менее чем за 200 мс.

Отсканированные PDF — изображения, встроенные в PDF-контейнер. Здесь нужен OCR. Ландшафт 2026 года предлагает несколько уровней:

• Tesseract 5 — бесплатный, с открытым исходным кодом, работает локально. Хорошая точность на чистых сканах (90%+ при 300 DPI печатного текста). Испытывает трудности с наклоном, низким разрешением и рукописным текстом.
• PaddleOCR — с открытым исходным кодом от Baidu. Лучше справляется с многоязычными и деградированными сканами. Чуть тяжелее в запуске.
• Document AI / Azure Form Recognizer / Amazon Textract — облачные сервисы со специализированным пониманием макета. Лучшая точность на сложных формах и таблицах, но вы загружаете документы третьей стороне.

Гибридные PDF — одни страницы текстовые, другие отсканированные. Здесь нужен слой маршрутизации. Практичный подход: сначала попробовать извлечение текста; если страница выдаёт менее 10 символов, отправить её на OCR. Это тривиально реализовать в коде и экономит ненужную обработку OCR на текстовых страницах.

Практический пайплайн извлечения счетов-фактур

Вот конкретный пайплайн, который обрабатывает смешанные счета-фактуры в масштабе:

Поступает файл → pdfplumber пытается извлечь текст
  ↓ (текст найден?)
  Да → передать необработанный текст в LLM
  Нет → отрисовать страницу как изображение → OCR → передать текст в LLM
  ↓
LLM получает текст + JSON-схему с описанием нужных полей:
  vendor_name, invoice_number, date, line_items[], total, currency
  ↓
LLM возвращает структурированный JSON
  ↓
Проверка схемы (Pydantic / Zod) ловит некорректный вывод
  ↓
Проверка достоверности: если LLM вернула "unknown" для 2+ полей → отправить на ручную проверку
  ↓
Запись в базу данных / ERP / бухгалтерскую систему

Ключевой нюанс, который упускают большинство руководств: промпт-инжиниринг здесь имеет огромное значение. Сказать LLM «извлеки данные из счёта-фактуры» даёт посредственные результаты. Сказать: «Вы — система извлечения данных. На основе следующего вывода OCR из счёта-фактуры верните JSON-объект с этими точными полями. Если поле нечитаемо или отсутствует, используйте строку 'UNKNOWN'. Не угадывайте. Вот текст: ...» — даёт значительно лучшую точность, часто разницу между 70% и 95% точности на уровне полей.

Работа с таблицами: за пределами чтения ячеек

Таблицы выглядят простыми, но обманчиво сложны. Проблема не в чтении ячеек — а в понимании того, что они *означают*.

Структурная сложность

Реальные бизнес-таблицы содержат:

• Объединённые ячейки, которые ломают наивный разбор строк/столбцов.
• Таблицы с несколькими заголовками, где первые 3 строки формируют составной заголовок.
• Скрытые строки/столбцы с промежуточными расчётами.
• Несколько листов с несогласованными схемами.
• Формулы, ссылающиеся на другие листы или внешние файлы.
• Смешанное содержимое — лист, наполовину состоящий из таблицы данных, наполовину из произвольных заметок.

ИИ-агенты справляются с этим с помощью двухфазного подхода:

Фаза 1: Структурный парсинг. Такие библиотеки, как openpyxl (для Excel), aggregator (API Google Таблиц) или polars/pandas, считывают сырую структуру. Агент анализирует метаданные файла: имена листов, диапазоны объединённых ячеек, высоту строк, ширину столбцов. Это говорит агенту, где начинаются и заканчиваются таблицы.

Фаза 2: Семантическое понимание. LLM получает разобранную таблицу в виде markdown или CSV вместе с контекстом: «Это квартальный отчёт о продажах компании SaaS. Первые 3 строки — заголовки. Определите: (1) охваченные периоды времени, (2) категории продуктов, (3) показатели выручки и (4) любые итоги или промежуточные итоги».

Практический пример: сверка бюджетной таблицы

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

1. Считывает оба файла с помощью openpyxl, игнорируя шум форматирования. 2. Нормализует имена столбцов с использованием нечёткого сопоставления (в бюджете написано «Q3 Marketing Spend», в фактических данных — «MKT Q3»). 3. Преобразует строки в валютном формате ("$12,345.67") в числа с плавающей точкой, обрабатывая различия в локали (европейский формат 12.345,67). 4. Вычисляет отклонения по каждой статье. 5. Помечает любую строку, где отклонение превышает 15%. 6. Создаёт сводную таблицу в формате, который ожидает финансовый отдел.

Роль LLM — не выполнять вычисления, а *понимать намерение*. Когда в заголовке столбца написано «Est. Rev (w/ churn adj)», LLM знает, что это прогнозируемая выручка с корректировкой на отток, и может сопоставить её с правильным столбцом фактических данных, даже если названия различаются.

CSV против Excel: разные стратегии

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

Для файлов Excel с несколькими листами, формулами и форматированием сначала используйте специализированный парсер. Извлеките данные, по возможности вычислите формулы и представьте LLM чистые таблицы. Попытка заставить LLM интерпретировать сырой .xlsx XML — рецепт для галлюцинаций.

Анализ контрактов: сложная задача

Контракты — самый сложный тип документов, потому что они требуют *рассуждения*, а не просто извлечения.

Что ИИ-агенты могут надёжно делать сегодня

Идентификация пунктов. При наличии 40-страничного контракта агент может идентифицировать и пометить: пункты о возмещении ущерба, ограничение ответственности, положения о прекращении, передачу интеллектуальной собственности, условия неконкуренции, применимое право и условия оплаты. Это работает с 85–92% полнотой на стандартных коммерческих контрактах. Оставшиеся 8–15% — это крайние случаи: необычные структуры пунктов, перекрёстные ссылки на внешние документы или намеренно запутанный язык.

Флаги рисков. Агент сравнивает идентифицированные пункты с настраиваемой политикой рисков. Пример: «Пометить любой пункт об ограничении ответственности, который ограничивает убытки суммой ниже 1 миллиона долларов для контракта стоимостью более 500 тысяч долларов». Это проверка на основе правил после извлечения LLM — надёжная и поддающаяся аудиту.

Извлечение терминов. Графики платежей, даты продления, периоды уведомления и показатели SLA могут быть извлечены как структурированные данные с высокой точностью (90%+), потому что они числовые и следуют предсказуемым шаблонам.

Что ИИ-агенты не могут надёжно делать

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

Согласованность между документами. Проверка того, противоречат ли друг другу генеральное соглашение, описание работ и форма заказа, улучшается, но по-прежнему ненадёжна для сложных многодокументных настроек.

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

Практический рабочий процесс обработки контрактов

Поступает PDF контракта
  ↓
OCR, если отсканирован → извлечение текста
  ↓
Сегментация по разделам (LLM разделяет на: Определения, Объём, Оплата,
  ИС, Ответственность, Прекращение, Общие положения)
  ↓
Извлечение по разделам: ключевые термины, обязательства, даты, суммы
  ↓
Движок рисков: каждый пункт проверяется по правилам политики
  ↓
Генерация резюме: понятный обзор + матрица рисков
  ↓
Структурированный вывод: JSON со всеми извлечёнными полями + оценки рисков
  ↓
Маршрутизация в инструмент юридической проверки / систему управления контрактами

Шаг сегментации по разделам критически важен. Отправить 40-страничный контракт в LLM и попросить «извлечь всё важное» даёт другой результат, чем попросить систематически проработать определённые разделы. Структура на входе — структура на выходе.

Создание собственного пайплайна: конкретные шаги

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

Шаг 1: Инвентаризация типов документов

Перечислите каждый повторяющийся тип документов, который обрабатывает ваш бизнес. Для каждого укажите: формат (PDF, Excel, электронная почта), происхождение (клиент, внутренний, партнёр), объём (в день/неделю/месяц) и какие данные вам нужно извлечь. Это определяет сложность вашего пайплайна.

Шаг 2: Выберите уровень обработки

• Уровень 1 (простой): Текстовые PDF и чистые CSV. Парсер + промпт для LLM. OCR не нужен. Начинайте здесь.
• Уровень 2 (средний): Добавьте отсканированные документы. Нужен OCR-движок (Tesseract или PaddleOCR локально, или облачный API Vision).
• Уровень 3 (сложный): Многолистовые Excel с формулами, контракты с юридическим рассуждением, рукописные формы. Требуются специализированные парсеры, многошаговые LLM-цепочки и рабочие процессы с участием человека.

Большинство компаний обнаруживают, что 80% их объёма — это Уровень 1, а оставшиеся 20% составляют 80% инженерных усилий.

Шаг 3: Настройте слой извлечения

Начните с структурированных промптов. Определите JSON-схему для каждого типа документов. Используйте вызовы функций или режим структурированного вывода (доступен в GPT-4o, Claude и Gemini), чтобы заставить LLM возвращать валидный JSON. Это устраняет большинство головных болей с парсингом.

Шаг 4: Добавьте проверку

Никогда не доверяйте сырому выводу LLM для бизнес-критичных данных. Используйте валидацию схемы (Pydantic в Python, Zod в TypeScript) для перехвата ошибок типов. Добавьте бизнес-правила: «Итог счёта-фактуры должен быть равен сумме статей ± 2%» или «Дата вступления контракта в силу должна быть в прошлом».

Шаг 5: Создайте цикл ручной проверки

Для любого извлечения ниже вашего порога достоверности направляйте на ручную проверку. Отображайте исходный документ рядом с извлечёнными данными с выделенными исходными областями. Это необязательно даже при точности 95% — 1 документ из 20 содержит ошибку, и в финансах или юриспруденции это неприемлемо без проверки.

Шаг 6: Подключите к целевым системам

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

Распространённые ошибки и как их избежать

Чрезмерная зависимость от одной модели. Различные задачи извлечения подходят для разных моделей. Простое извлечение полей хорошо работает с быстрой и дешёвой моделью. Сложное рассуждение по контрактам требует более сильной (и дорогой) модели. Объединяйте их: дешёвая модель для парсинга, дорогая — только там, где требуется рассуждение.

Игнорирование макета. Извлечение текста, которое отбрасывает пространственную информацию — где текст находится на странице — теряет критически важный контекст. Итог в счёте-фактуре важен из-за *того, где* он появляется (внизу справа), а не только из-за того, что там написано. Используйте OCR-движки, которые сохраняют координаты ограничивающих рамок, и передавайте подсказки по макету в LLM.

Отсутствие версионирования промптов. Ваши промпты для