AI для автоматичного заповнення форм: Donut, LLM та PyTorch

Відзначимо: коли документ сканується, стандартний OCR видає плоский текст без структури. Адреса може опинитися в полі «ПІБ», а дата — в примітці. Така ситуація типова для бухгалтерії, де на ручне введення даних витрачаються години. Ми вирішуємо цю проблему за допомогою пайплайну Document Understanding — він не просто розпізнає символи, але й розуміє, де що знаходиться. На практиці це прискорює введення даних у 5–10 разів і знижує кількість помилок на 70%. Для відділу з п'яти операторів економія може сягати 1,5 млн грн на рік. Система окупається за 3–6 місяців за рахунок скорочення трудовитрат. Для великих компаній з 20 операторами щомісячна економія може досягати 500 000 грн, а річна — до 6 млн грн.

Автоматичне заповнення форм з документів за допомогою AI

Проблеми, які вирішуємо

• Неструктурований текст після OCR. Класичні Tesseract або Google Vision дають сирий текст з координатами, але не знають, що «Іванов» — прізвище, а «123456» — номер паспорта. Ми використовуємо LayoutLM v3, який аналізує і текст, і геометрію блоків, використовуючи механізм self-attention.
• Різні шаблони документів. Накладна від одного постачальника відрізняється від іншого, а паспорт змінює формат сторінок. Наш пайплайн класифікує тип документа і застосовує спеціалізований екстрактор.
• Низька точність на складних документах. Рахунки з таблицями, рукописні позначки, низька якість скану — все це ламає звичайний OCR. Ми додаємо мультимодальний LLM, який розуміє контекст і відновлює пропущене.

Як автоматичне заповнення форм з документів прискорює введення даних?

Основою служить триланковий пайплайн: класифікація → екстракція → мапінг. Для стандартних типів (паспорт, ІПН) використовуємо LayoutLM, навчений на тисячах розмічених зразків. Для нестандартних — мультимодальний LLM, який обробляє зображення і повертає JSON з полями.

from typing import Any
from dataclasses import dataclass

@dataclass
class FormField:
    name: str           # ім'я поля в цільовій формі
    value: Any          # вилучене значення
    confidence: float   # впевненість 0..1
    source_location: str | None = None  # звідки вилучено

class DocumentToFormPipeline:
    """
    Пайплайн: документ → поля форми.
    Кроки:
    1. Класифікація типу документа
    2. OCR + layout analysis
    3. NER/IE для вилучення полів
    4. Мапінг на поля цільової форми
    5. Валідація та нормалізація
    """
    def __init__(
        self,
        document_classifier,   # модель класифікації типу документа
        extractors: dict,      # {doc_type: extractor}
        form_mapper: dict,     # {doc_field: form_field} мапінг
        validators: dict       # {form_field: validator_fn}
    ):
        self.classifier = document_classifier
        self.extractors = extractors
        self.form_mapper = form_mapper
        self.validators = validators

    def process(self, document_image) -> dict[str, FormField]:
        # Крок 1: визначаємо тип документа
        doc_type = self.classifier.predict(document_image)

        if doc_type not in self.extractors:
            raise ValueError(f'Unsupported document type: {doc_type}')

        # Крок 2-3: вилучення полів
        extractor = self.extractors[doc_type]
        raw_fields = extractor.extract(document_image)

        # Крок 4: мапінг
        form_fields = {}
        mapping = self.form_mapper.get(doc_type, {})

        for doc_field, value in raw_fields.items():
            if doc_field in mapping:
                form_field_name = mapping[doc_field]
                form_fields[form_field_name] = FormField(
                    name=form_field_name,
                    value=value.get('text'),
                    confidence=value.get('confidence', 0.0),
                    source_location=doc_field
                )

        # Крок 5: валідація
        for field_name, field in form_fields.items():
            if field_name in self.validators:
                try:
                    field.value = self.validators[field_name](field.value)
                except Exception as e:
                    field.confidence *= 0.5   # знижуємо впевненість при помилці валідації

        return form_fields

Гібрид LayoutLM і LLM — перевага перед класичним OCR

Класичний OCR не розуміє семантику: слово «Київ» може бути і містом, і назвою вулиці. LLM з vision (наприклад, Claude 3.5 або GPT-4o) аналізує весь документ цілком: він бачить розташування полів, пов'язані заголовки та таблиці. Це дає приріст точності на 15–20% на складних макетах. Ми використовуємо LLM як fallback для типів документів, які рідко зустрічаються. OCR (Wikipedia) сам по собі не вирішує задачу розуміння структури. Гібридний підхід у 3 рази кращий за класичний OCR на складних документах.

Для навчання моделей використовуються згорткові нейронні мережі та трансформери. Токенізація зображень відбувається за допомогою патчів з накладанням позиційних енкодингів, як у Vision Transformer. Механізм cross-attention дозволяє моделі фокусуватися на релевантних ділянках.

import anthropic
import base64
from pathlib import Path

def extract_form_fields_llm(
    document_path: str,
    form_schema: dict,    # JSON Schema цільової форми
    model: str = 'claude-opus-4-5'
) -> dict:
    """
    Мультимодальний LLM як універсальний Document Understanding engine.
    form_schema: {'field_name': {'type': 'str', 'description': '...', 'required': bool}}
    """
    client = anthropic.Anthropic()

    # Завантажуємо документ як base64
    with open(document_path, 'rb') as f:
        doc_b64 = base64.standard_b64encode(f.read()).decode()

    ext = Path(document_path).suffix.lower()
    media_type = {
        '.jpg': 'image/jpeg', '.jpeg': 'image/jpeg',
        '.png': 'image/png',  '.pdf': 'application/pdf'
    }.get(ext, 'image/jpeg')

    # Формуємо опис схеми форми
    schema_desc = '\n'.join([
        f'- {name}: {info["description"]} ({"обов\'язкове" if info.get("required") else "опціональне"})'
        for name, info in form_schema.items()
    ])

    message = client.messages.create(
        model=model,
        max_tokens=2048,
        messages=[{
            'role': 'user',
            'content': [
                {
                    'type': 'image',
                    'source': {
                        'type': 'base64',
                        'media_type': media_type,
                        'data': doc_b64
                    }
                },
                {
                    'type': 'text',
                    'text': f"""Вилучи з документа наступні поля для заповнення форми:

{schema_desc}

Поверни результат строго у форматі JSON:
{{
  "field_name": {{"value": "...", "confidence": 0.0-1.0, "not_found": false}},
  ...
}}

Якщо поле не знайдено в документі, вкажи "not_found": true.
Для confidence: 1.0 = точно впевнений, 0.5 = сумніваюся."""
                }
            ]
        }]
    )

    import json
    try:
        return json.loads(message.content[0].text)
    except json.JSONDecodeError:
        # Вилучаємо JSON з текстової відповіді
        import re
        match = re.search(r'\{.*\}', message.content[0].text, re.DOTALL)
        return json.loads(match.group()) if match else {}

Як ми забезпечуємо точність вилучення даних?

Ми комбінуємо три рівні верифікації:

• LayoutLM видає confidence для кожного поля на основі навченої моделі.
• LLM додатково перевіряє логічну узгодженість (наприклад, дата народження не пізніше сьогоднішнього дня).
• User-in-the-loop: поля з confidence < 0.85 підсвічуються в UI для ручної перевірки. Це стандартна практика в enterprise-рішеннях.

def prepare_form_ui_state(
    form_fields: dict,
    confidence_threshold: float = 0.85
) -> dict:
    """
    Підготовка стану форми для UI:
    - Поля з високою впевненістю — автозаповнені
    - Поля з низькою — позначені для перевірки
    - Обов'язкові не знайдені — помилка
    """
    ui_state = {}
    for field_name, field in form_fields.items():
        status = 'autofilled'
        if field.value is None:
            status = 'not_found'
        elif field.confidence < confidence_threshold:
            status = 'needs_review'

        ui_state[field_name] = {
            'value': field.value,
            'status': status,
            'confidence': field.confidence,
            'editable': status != 'autofilled' or True  # завжди редаговано
        }
    return ui_state

Таблиця порівняння підходів

Строки

Що входить в роботу

• Документація API (Swagger, Postman collection) та опис пайплайну.
• Навчання моделі на ваших зразках (до 100 документів безкоштовно).
• Тестовий період — 2 тижні з підтримкою інженера.
• Інтеграція — готові модулі для 1С та Bitrix24.
• Супровід — гарантія на точність 95% протягом 3 місяців, SLA по багфіксах.

Наша команда має 10-річний досвід в Computer Vision та NLP і реалізувала понад 50 проектів з Document Understanding. Ми гарантуємо, що система впишеться у ваш ландшафт без зриву строків. Замовте демо-версію системи для тестування на ваших документах. Зв'яжіться з нами для оцінки вашого проекту — підготуємо прототип за 2 тижні. Ми пропонуємо рішення під ключ: входить навчання моделі, інтеграція та супровід. Вартість рішення — від 1 000 000 грн залежно від складності. Напишіть нам — оцінимо ваш проект безкоштовно.

Як distribution shift вбиває метрики CV-моделі в промисловості

На виробництві ставлять камеру, контролюють якість продукції. Модель навчена на 10 000 розмічених зображень — точність на тесті mAP 0.84. Запускають у продакшен — і в перший же тиждень пропускають 30% дефектів. Освітлення на лінії змінюється по змінах, distribution shift обнуляє метрики. Це класична історія з Computer Vision у промисловості, де розпізнавання образів дає збій без правильної обробки дрейфу.

Наші інженери з досвідом 60+ проектів з комп'ютерного зору знають, як виключити такі сценарії. Гарантуємо стабільну роботу моделі в реальних умовах.

Які архітектури детекції об'єктів обрати: YOLO, RT‑DETR чи інші?

YOLO — стандарт для real‑time детекції. YOLOv8 та YOLOv11 від Ultralytics — найбільш використовувані версії у виробництві: простий API, активна спільнота, вбудована валідація та експорт в ONNX/TensorRT. Для задач з високими вимогами до точності та коли latency менш критична — RT‑DETR, transformer‑based архітектура без NMS, дає кращий mAP на COCO при порівнянній швидкості з YOLOv8l.

Типова помилка при навчанні детектора: датасет 8000 зображень, 3 класи, fine‑tune YOLOv8m — F1 0.73 на валідації. Дивимося confusion matrix — один клас майже ніколи не детектується. Причина: дисбаланс 1:23. Рішення: oversampling рідкісного класу, focal loss для objectness, аугментації (Mosaic, MixUp вимкнути для рідкісного класу — вони його «розмивають»). Transfer learning обов'язковий: передтреновані на COCO ваги скорочують потребу в даних у 10 разів. Fine‑tune на 500–2000 доменних зображеннях дає робочу модель за 1–2 дні на одній GPU.

Для edge deployment: експорт в ONNX → TensorRT engine. YOLOv8n в TensorRT FP16 на Jetson AGX Orin дає 150+ FPS при P99 latency < 8 ms — це в 3 рази швидше, ніж ONNX Runtime без TensorRT. На сервері A10G: 700+ FPS для YOLOv8n в TensorRT INT8.

Як fine‑tuning YOLO допомагає в розпізнаванні образів?

Припустимо, потрібно знаходити мікродефекти на поверхні металу — задача з високою роздільною здатністю та перекосом класів. Використовуємо YOLOv8m, передтренований на COCO (документація Ultralytics), і донавчаємо на 2000 власних зображень. Застосовуємо аугментації Mosaic, MixUp, random perspective. Після 200 епох mAP 0.5 досягає 0.93. Ключові прийоми:

• focal loss для objectness голови — зменшує внесок легко класифікованих прикладів.
• class‑balanced sampling — вирівнює представництво рідкісних класів.
• Test Time Augmentation (TTA) — підвищує recall на 5–7% за рахунок усереднення по фліпах та масштабах.

Отримайте консультацію з підбору архітектури для вашого завдання — зв'яжіться з нами.

Які архітектури сегментації обрати: SAM, Mask R‑CNN чи інші?

SAM (Segment Anything Model) від Meta змінив підхід до сегментації. SAM 2 працює з відео, підтримує трекінг об'єктів через кадри — для інтерактивного виділення об'єкта по точці або bbox це найкращий вибір з коробки. Для production instance segmentation без інтерактивного промпту — Mask R‑CNN або YOLOv8‑seg. YOLOv8‑seg навчається як звичайний детектор з додатковими масками, зручний у тих же пайплайнах. Семантична сегментація (кожен піксель — клас) — SegFormer, DeepLabV3+. SegFormer‑B5 дає хороший баланс точності та швидкості для аналізу супутникових знімків або медичної сегментації.

Кейс: сегментація клітин на мікроскопічних зображеннях. Датасет 400 зображень з ручною розміткою. Навчання Mask R‑CNN на ResNet‑50 backbone дало IoU 0.61 — погано. Проблема: об'єкти (клітини) перекриваються, стандартний NMS вбиває перекриваючі передбачення. Рішення: перехід на cellpose (спеціалізована архітектура для біомедичних задач) + soft‑NMS. IoU зріс до 0.79.

Коли Tesseract не справляється з OCR?

Tesseract — відправна точка для простих задач: друкований текст, хороше освітлення, рівне розташування. Як тільки з'являються рукописні елементи, нестандартні шрифти, перспективні спотворення або багатоколоночний макет — Tesseract деградує швидко.

PaddleOCR — production‑grade рішення: виявлення текстових блоків + розпізнавання + структурний аналіз. Працює з коробки для 80+ мов, включаючи українську. Підтримує таблиці та документи зі складною структурою. Wikipedia: Оптичне розпізнавання символів. TrOCR (Microsoft) — трансформерний OCR з сильними результатами на рукописному тексті. Для українського рукописного тексту потрібен fine‑tuning: базова модель навчена переважно на латиниці.

Що робити, якщо Tesseract не справляється з розпізнаванням образів на документах?

Для задач «витягни дані з рахунку / договору / паспорта» використовуємо LayoutLMv3 або Donut — ці моделі розуміють layout документа, а не тільки текст. Інтеграція через Hugging Face Transformers, fine‑tuning на 200–500 розмічених документах. Типовий pipeline:

1. Preprocessing: deskew, denoising, binarization через OpenCV.
2. Виявлення текстових блоків: PaddleOCR detection або CRAFT.
3. Розпізнавання: PaddleOCR recognition або TrOCR.
4. Post‑processing: нормалізація, валідація через regex або LLM для структурованих полів.

Для документів з фіксованою структурою template matching + OCR точково по координатах часто надійніше за end‑to‑end рішення.

Face Recognition: ідентифікація та верифікація

Face recognition = detection + alignment + embedding + matching. Кожен етап важливий.

Detection: RetinaFace або InsightFace для точної локалізації обличчя та ключових точок. MTCNN — старіше, але надійне рішення. Embedding: ArcFace (InsightFace) — state‑of‑the‑art для face recognition embeddings. Моделі iresnet50/iresnet100 передтреновані на MS1MV3 (5M ідентичностей). Ембеддинг‑вектор 512 float32, порівняння за cosine similarity. Threshold tuning: поріг рішення — критичний параметр. При threshold 0.6 типовий FPR на LFW benchmark — 0.001, TPR — 0.985. У production threshold потрібно калібрувати під реальний distribution: люди в масках, зі зміненою зовнішністю, в різних умовах освітлення. Liveness detection обов'язковий: MiniFASNet — lightweight модель на CPU, FaceX‑Zoo містить кілька передтренованих liveness‑детекторів.

Відеоаналітика

Відео — послідовність кадрів плюс часовий вимір. Наївний підхід — детектувати на кожному кадрі — дорого.

Трекінг: ByteTrack та BoT‑SORT — стандарт для multi‑object tracking. Працюють поверх будь-якого детектора, додають persistent ID об'єктам між кадрами — це дає підрахунок об'єктів, трекі руху, velocity.

Оптимізація: не потрібно обробляти кожен кадр. Для статичних сцен детекція на кожному 5–10 кадрі, між ними — трекер. Для детекції подій (людина увійшла в зону) background subtraction (OpenCV MOG2) як lightweight pre‑filter перед нейромережевою детекцією. Action Recognition: SlowFast, VideoMAE для класифікації дій. Важкі моделі — для production використовуємо ONNX export + TensorRT або офлайн обробку.

Як виміряти якість моделі розпізнавання образів у продакшені?

Моніторинг якості — ключовий елемент MLOps. Відстежуємо:

• розподіл prediction confidence;
• частку low‑confidence передбачень (індикатор OOD‑даних);
• дрейф вхідних зображень через feature distribution (embeddings з backbone).

Падіння середньої confidence з 0.87 до 0.71 за тиждень — ранній сигнал про distribution shift. NVIDIA Triton Inference Server рекомендує відстежувати ці метрики через Prometheus. Наші сертифіковані інженери налаштовують моніторинг і гарантують SLA по якості інференсу.

Деплой CV‑моделей

Для онлайн інференсу використовуємо Triton Inference Server (NVIDIA) — production‑стандарт для serving CV‑моделей. Підтримує TensorRT, ONNX, PyTorch, dynamic batching, multiple instances. REST та gRPC API. Гарантуємо стабільну роботу під навантаженням.

Edge deployment: ONNX Runtime на ARM/x86 CPU. TensorFlow Lite для мобільних пристроїв. OpenVINO для Intel CPU/GPU/VPU — дає 2–3× приріст швидкості на Intel залізі порівняно з ONNX Runtime. Після деплою передаємо модель з документацією та навчаємо персонал.

Що входить в роботу

Терміни та вартість

Прототип детектора на існуючих даних — 1–2 тижні. Production‑система з оптимізацією під цільове залізо — 4–8 тижнів. Повний цикл включаючи розмітку даних (1000–5000 зображень) — 2–4 місяці. Вартість розраховується індивідуально під кожну задачу. Ми на ринку більше 5 років, реалізували 60+ проектів з комп'ютерного зору. Оцінимо ваш проект під ключ — замовте консультацію, щоб отримати розрахунок та технічну пропозицію.