Ваші оператори витрачають години на введення рахунків і накладних, а помилки все одно проскакують? Ми стикалися з цим у десятків клієнтів і знаємо, як це виправити. На обробку 1000 рахунків іде до 80 годин роботи операторів, що обходиться в тисячі доларів щомісяця. За час нашої практики ми розробили десятки рішень для інтелектуальної обробки документів (IDP) для банків, логістики та ритейлу. Розповім, як будуються такі системи і яких результатів можна досягти.
Document AI обробляє документи в десятки разів швидше за людину, а економія на обробці одного документа сягає 95% порівняно з ручним введенням. Для клієнта з обсягом 2000 документів на місяць це означає економію від 2 до 5 мільйонів рублів на рік. Порівняємо ручну обробку та Document AI:
| Параметр | Ручна обробка | Document AI |
|---|---|---|
| Швидкість (1000 рахунків) | 40–80 годин | 10–15 хвилин |
| Помилки введення | 2–5% | <0.1% при confidence фільтрі |
| Масштабування | Лінійне зростання штату | Горизонтальне масштабування |
| Доступність | 9–5 | 24/7 |
| Вартість на документ | висока | у 10–20 разів нижча |
Як Document AI економить до 95% часу на обробку?
Платформа складається з декількох шарів, кожен з яких вирішує своє підзавдання. Типовий pipeline:
[Вхідний документ: PDF, DOCX, JPG, TXT] → [Document Intake Service]
├── Визначення типу (PDF/скан/текстовий)
└── Маршрутизація → [Pre-processing]
├── OCR (якщо скан): Tesseract / Azure DI / Google Document AI
├── Вилучення таблиць: Camelot / pdfplumber / Table Transformer
└── Layout Analysis: розташування елементів сторінки → [AI Processing Pipeline]
├── Класифікація типу документа
├── Вилучення структурованих даних
├── Валідація вилучених даних
└── Генерація суммарі / аналітики → [Output]
├── JSON з вилученими даними
├── Структурований запис у БД
└── Сповіщення / інтеграціїПроцес побудови такої системи включає п'ять етапів:
- Збір та розмітка репрезентативної вибірки документів (100–200 штук).
- Вибір та налаштування OCR + попередня обробка зображень.
- Навчання моделей класифікації та вилучення полів.
- Інтеграція з ERP через REST API або прямі конектори.
- Запуск моніторингу та цикл донавчання в міру надходження нових типів.
Чому preprocessing — критичний етап?
Якість OCR та layout analysis безпосередньо визначає точність подальшого вилучення. Для сканiв низької роздільної здатності доводиться застосовувати згорткові мережі (Table Transformer) для виявлення таблиць. В одному з проектів для ритейлу ми боролися з накладними, надрукованими на термопапері — довелося донавчати модель на синтетичних даних, що імітують вицвітання. Використання сучасних OCR-движків, таких як Azure Document Intelligence, дозволяє підвищити точність вилучення до 99% на якісних сканах, але для складних випадків потрібна кастомна попередня обробка.
Деталі порівняння OCR-рішень
Tesseract — безкоштовний, базовий рівень. Azure DI — висока точність на складних макетах, платний. PaddleOCR — on-premise, донавчається під специфічні шрифти. Google Document AI — хороший для багатосторінкових сканiв. Для OCR NLP pipeline обирайте движок виходячи з типів документів та вимог до конфіденційності.Типи документів, що обробляються
Система обробляє різні типи документів. Підходи відрізняються:
- Структуровані (рахунки, накладні, податкові форми): детерміновані формати, вилучення полів з високою точністю.
- Напівструктуровані (договори, анкети, заяви): варіативна структура, потребує розуміння контексту.
- Неструктуровані (листи, звіти, медичні записи): вільний текст, NLP-обробка.
- Зображення та скани: попередній OCR, потім NLP-обробка.
| Тип документа | Приклад | Метод обробки | Точність |
|---|---|---|---|
| Структурований | XML УПД | Парсинг XPath | 99% |
| Напівструктурований | Договір | LLM + шаблон | 90–95% |
| Неструктурований | Лист | NLP класифікація | 85–90% |
| Скан | Фото чека | OCR + IDP модель | 80–95% |
Технічна реалізація
Вилучення даних зі структурованих документів
Для стандартизованих форм (СФ, УПД, накладні у форматі ФНС XML) — детермінований парсинг через XPath, без ML:
from lxml import etree
def parse_upd(xml_path: str) -> InvoiceData:
tree = etree.parse(xml_path)
root = tree.getroot()
ns = {"n": "urn:NDS"}
return InvoiceData(
seller_inn=root.findtext(".//n:СвПродавца/n:ИдСв/n:СвЮЛ/@ИННЮЛ", namespaces=ns),
invoice_number=root.findtext(".//n:Документ/n:НомерДок", namespaces=ns),
total_amount=float(root.findtext(".//n:ВсегоОпл", namespaces=ns) or 0),
)
ML потрібен лише для нестандартних форматів.
IDP для сканiв: стек та приклади
from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.core.credentials import AzureKeyCredential
client = DocumentIntelligenceClient(endpoint, AzureKeyCredential(key))
# Аналіз рахунку
with open("invoice.jpg", "rb") as f:
poller = client.begin_analyze_document(
model_id="prebuilt-invoice",
body=f.read(),
content_type="application/octet-stream"
)
result = poller.result()
# Доступ до полів
invoice = result.documents[0]
vendor_name = invoice.fields.get("VendorName")
total_amount = invoice.fields.get("InvoiceTotal")Альтернативи: Google Document AI, AWS Textract, PaddleOCR + LLM extraction для on-premise. Детальніше про OCR.
Класифікація та валідація даних
Multi-class класифікатор на основі:
- Текстового вмісту (TF-IDF / BERT embeddings)
- Структурних ознак (наявність таблиць, кількість сторінок, розділи)
- Метаданих (ім'я файлу, джерело)
Типова точність: 96–99% для чітких типів (СФ vs договір vs акт), 88–94% для схожих типів.
Кожне вилучене поле супроводжується confidence score. При низькому confidence (< 0.8) — флаг для ручної перевірки. Cross-validation: суми прописом і цифрами збігаються? ІНН проходить checksum? Дата логічна? Straight-Through Processing rate для високоякісних структурованих документів сягає 85–95%. Економія часу та грошей: автоматизація повернення інвестицій за 6–12 місяців для середнього бізнесу. Багато клієнтів окупають впровадження за 8–10 місяців.
Результат та пілот
Що входить у готове рішення
- API з ендпоінтами для завантаження, обробки та отримання даних
- Модуль OCR з підтримкою Tesseract, Azure DI або Google DI
- Класифікатор типів документів (донавчувана модель)
- Вилучення полів з confidence score
- Валідація та логування
- Веб-інтерфейс для ручного коригування та моніторингу
- Інтеграція з 1С, SAP або іншою ERP (REST/SOAP/файловий обмін)
- Документація та інструкція з експлуатації
- Навчання операторів (2 дні)
- Гарантія на pipeline протягом 6 місяців
Строки впровадження
Місяць 1: OCR pipeline, класифікатор типів документів, базове вилучення Місяць 2–3: Обробка пріоритетних типів документів, валідація, інтеграції з ERP/ECM
Місяць 4: Семантичний пошук, UI для ручного коригування, аналітика Місяць 5–6: Production hardening, масштабування, моніторинг якості
Як запустити пілот?
Пілотний проект починається зі збору вибірки з 100–200 типових документів (скани, PDF, XML). За 1–2 дні ми оцінюємо архітектуру та точність вилучення, готуємо попередній кошторисний розрахунок. Після узгодження запускається повний pipeline — від OCR до інтеграції. Перші результати видні через 2–3 місяці. Потім доопрацьовуємо всі типи документів, підключаємо ERP, навчаємо операторів.
Замовте пілотний проект для оцінки ефективності на ваших документах. Зв'яжіться з нами — ми підготуємо попередню архітектуру за 1–2 дні та оцінимо проект. Отримайте консультацію щодо інтеграції Document AI у вашу інфраструктуру.
