Автоматизация обработки счетов: как довести пайплайн Azure AI Document Intelligence до реального продакшена

Большинство гайдов по Azure AI Document Intelligence заканчиваются на получении JSON-ответа. В реальной работе самое сложное начинается после — когда нужно научить систему принимать решения без участия человека и не ошибаться на сотом документе.

Получить JSON с данными из счёта — это простые 20% работы. Остальные 80% — это научить пайплайн не отправлять в бухгалтерию сумму с достоверностью 0.61, не терять счета из многостраничных PDF и не дублировать одну и ту же оплату дважды.

Зачем это нужно

Представьте типичный отдел бухгалтерии средней компании. Каждый день на почту приходят десятки счетов от разных поставщиков: кто-то присылает аккуратный PDF, кто-то — отсканированный факс с рукописным номером заказа. Вручную вбивать данные из каждого документа в учётную систему — долго и чревато ошибками.

Azure AI Document Intelligence (ранее известный как Form Recognizer) умеет «читать» такие документы автоматически: извлекать сумму, дату, название поставщика и другие поля. В паре с Power Automate — платформой для автоматизации бизнес-процессов от Microsoft — это превращается в конвейер: документ приходит, система его распознаёт, проверяет и отправляет данные в нужное место.

Но подавляющее большинство обучающих материалов обрывают объяснение на самом простом этапе — «вызвали API, получили ответ». Дальше начинается настоящая инженерия.

Из чего состоит пайплайн

Конвейер обработки документов разбивается на пять стадий:

1. Приём. Файл появляется в SharePoint, почтовом ящике или облачном хранилище.
2. Классификация. Система определяет тип документа, прежде чем решать, как его читать.
3. Извлечение. Вызывается нужная модель, возвращаются структурированные поля и уровень уверенности по каждому из них.
4. Маршрутизация. Каждый документ попадает в один из трёх потоков: автоматическая обработка, очередь на ручную проверку или отклонение.
5. Запись. Данные попадают в учётную систему или в очередь ревью — с полным аудиторским следом.

Именно четвёртая стадия — маршрутизация по результатам проверки — и отличает промышленный пайплайн от игрушечного демо.

Какую модель выбрать

Document Intelligence предлагает три основных варианта, и ошибка на этом этапе может стоить недель работы.

Встроенная модель для счетов (prebuilt-invoice) — самый быстрый старт. Она работает «из коробки» без обучения и поддерживает 27 языков. Схема полей фиксированная: Microsoft определил, какие именно данные модель будет извлекать (номер счёта, сумма, дата, поставщик и так далее). Если этих полей хватает — начинайте с неё.

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

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

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

Какой коннектор использовать в Power Automate

Многие руководства рекомендуют действие Analyze Invoice. Проблема в том, что оно, как и ряд аналогичных действий (Analyze Receipt, Analyze Layout, Analyze Business Card и другие), устарело.

Актуальные действия коннектора Azure AI Document Intelligence на сегодня:

• Analyze Document for Prebuilt or Custom models (v4.x API) — основное рабочее действие
• Classify document with document classifier (v4.x API) — для классификации

В v4.x-действии передаётся идентификатор модели как параметр: prebuilt-invoice для счетов, prebuilt-layout для извлечения табличной структуры, или ваш собственный идентификатор для кастомной модели.

С точки зрения лицензирования этот коннектор относится к стандартным (не премиальным), что приятно для бюджета. Он доступен в Power Automate, Logic Apps и Copilot Studio, но не в Power Apps — если интерфейс ревью строится на canvas-приложении, придётся вызывать поток, а не коннектор напрямую.

Достоверность и уверенность — это разные вещи

Это различие путает даже опытные команды, а оно принципиально влияет на архитектуру.

Уверенность (confidence) возвращается в момент анализа. Это вероятность того, что конкретное извлечённое значение распознано корректно — число от 0 до 1 для каждого поля, каждого слова, каждой галочки.

Точность (accuracy) возвращается при обучении пользовательских моделей и описывает, насколько хорошо модель предсказывает размеченные значения на визуально похожих документах. Нейросетевые и генеративные модели вообще не выдают показатель точности при обучении.

Принимать решение об автоматической обработке нужно на основе уверенности. А точность использовать, чтобы решить, стоит ли вообще разворачивать модель в продакшене.

Сама Microsoft в документации рекомендует: «Стремитесь к показателю 80% и выше. Для более чувствительных случаев, таких как финансовые или медицинские записи, рекомендуется показатель, близкий к 100%.»

Счета — это финансовые документы. Универсальный порог в 0.80 по всем полям — не лучшая идея для системы, которая двигает деньги.

Как выглядит ответ модели

Результат анализа содержит не только документ-уровневый показатель уверенности, но и покаждому полю отдельно. И вот здесь кроется ловушка.

Допустим, документ-уровневая уверенность составляет 0.93 — выглядит отлично. Но если посмотреть на конкретные поля, оказывается, что сумма счёта (InvoiceTotal) извлечена с уверенностью всего 0.61. Если система принимает решение на основе общего показателя, она автоматически одобрит платёж, в сумме которого модель сама не уверена.

Строим «калитку» с порогами по полям

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

• Сумма счёта, итого к оплате, налоги — порог 0.95 и выше, плюс арифметическая проверка (сумма + налог = итого). Это поле напрямую связано с деньгами.
• Название поставщика, ИНН поставщика — порог 0.90. Ошибка в получателе платежа — дорогая ошибка.
• Номер счёта — порог 0.90, плюс проверка на дубликаты. Этот номер обеспечивает идемпотентность — защиту от повторной оплаты.
• Даты (счёт, оплата) — порог 0.85. Влияют на условия, но редко катастрофичны.
• Номер заказа — порог 0.85 или отсутствие значения с поздним сопоставлением. Часто отсутствует или написан от руки.
• Позиции в счёте — оценивать построчно. Одна некорректная строка не должна блокировать сорок корректных.

В Power Automate значение уверенности конкретного поля извлекается из ответа модели по вложенномупути — через analyzeResult, documents, fields и имя поля. Лучше вытащить его в отдельный шаг-«Compose», а не встраивать прямо в условие. Если поле отсутствует в документе, вложенная ссылка вернёт null, и условие отработает непредсказуемым образом — разбираться в этом в два часа ночи удовольствие сомнительное.

Логика маршрутизации на понятном языке:

• Если сумма ≥ 0.95, поставщик ≥ 0.90, номер счёта ≥ 0.90, подитог + налог = итого (с допуском в 0.02) и счёт ещё не обрабатывался → автоматическая обработка
• Если любое ключевое поле ниже порога или арифметика не сходится → ручная проверка
• Если документ вообще не счёт или поля не извлечены → отклонение

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

Четыре вещи, которые ломают пайплайн в реальной работе

Дублирование обработки. Power Automate повторяет попытки при сбоях. Почтовые триггеры срабатывают дважды. Кто-то пересылает один и тот же счёт двум людям. Хеширование файла и номера счёта с проверкой перед записью — самый ценный защитный шаг во всём пайплайне.

Многосчётные PDF. Поставщик присылает один PDF, содержащий шесть счетов. Результат анализа содержит массив документов. Если ваш поток читает только первый элемент массива, пять счетов теряются молча. Всегда итерируйте массив, даже если уверены, что там всегда будет одна запись.

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

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

Что измерять: пропускную способность, а не точность

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

С первого дня стоит фиксировать четыре числа:

• Доля автоматической обработки — сколько документов прошли без ревью от общего числа.
• Причины направления на проверку — какой срабатывает порог чаще всего. Это подсказывает, что улучшать.
• Частота исправлений ревьюером — как часто человек меняет значение, извлечённое моделью. Высокая частота исправлений среди автоматически обработанных документов означает, что пороги слишком мягкие.
• Стоимость обработки одного документа — затраты на Azure плюс минуты ревьюера, отслеживаемые во времени.

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

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

Организационная сторона, которую постоянно пропускают

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

Пайплайн, которому никто не доверяет, будут обходить стороной. А обходимый пайплайн имеет нулевую долю автоматической обработки — независимо от качества модели.

Ещё один практический совет: проектируйте интерфейс ревью и аудиторский след одновременно с самим потоком, а не после. Платформа Power Platform, которая с первого дня сохраняет причины направления на проверку, личность ревьюера и значения «до и после» в Dataverse, на порядки проще в защите при аудите, чем та, которая логирует только флаг успеха.

Что дальше

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

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