DOC OPS: як перетворити рахунок на перевірену таблицю

Чому «чат із PDF» не вирішує задачу

Коли говорять про «AI-помічника по документах», зазвичай уявляють чат: завантажив PDF, поставив питання, отримав відповідь. Для демо це виглядає ефектно. Для операційки — майже марно.

Менеджеру не потрібна відповідь «сума до сплати становить 5 678,26». Йому потрібні рядки в таблиці: артикул, кількість, ціна, сума, ПДВ. І потрібна впевненість, що дані можна проводити в облік, а не перевіряти кожну цифру вручну.

Тому DOC OPS будувався не як чат, а як document intake: файл → перевірені структуровані дані → дія.

Демо: docs.webdev07.tech
Кейс: portfolio.webdev07.tech/uk/cases/doc-ops

Що відбувається з документом

Конвеєр складається з п'яти кроків.

1. Ingest. PDF, JPG/PNG, DOCX або XLSX. Перевірка MIME і розміру, sha256, прев'ю сторінок.
2. Текст або OCR. Для PDF із текстовим шаром — pdftotext. Для сканів і фото — vision-модель.
3. Вилучення. Модель заповнює сувору JSON-схему: постачальник, номер, дати, суми, усі позиції.
4. Валідація. Звичайний TypeScript перевіряє арифметику, ПДВ, дублі, діапазон дат і обов'язкові поля.
5. Перевірка та експорт. Людина бачить спірні поля, виправляє їх і вивантажує XLSX/CSV/JSON.

Ключове рішення: вилучення й перевірки розділені. Модель не вирішує, чи сходиться арифметика. Якщо 12 × 245,00 не дорівнює 2 890,00, це ловить код, а не ще один запит до LLM.

Де модель помиляється

На синтетичному наборі з 44 документів модель помиляється рідко, але помиляється. У першому прогоні один скан взагалі не повернув JSON — низька якість зображення. В іншому прогоні дата на скані була прочитана як 2026-10-05 замість 2026-10-06.

Це не привід відмовлятися від моделі. Це привід не будувати процес так, ніби модель завжди права.

Що допомагає:

• Повтор із текстом помилки. Якщо JSON не пройшов Zod, модель отримує список проблем і пробує ще раз.
• Fallback на сильнішу vision-модель для сканів, які не пройшли з першого разу.
• Confidence за полями. Низька впевненість не ховається: поле підсвічене.
• Детерміновані перевірки. Арифметика, ПДВ і дублі не залежать від температури моделі.
• Human-in-the-loop. Нижче порогу документ не рухається далі без людини.

Що показав бенчмарк

44 синтетичні документи: текстові PDF, скани, DOCX, XLSX, рахунки з помилкою в сумі, дублем номера й пропущеним полем.

Метрика	Значення
Точність полів	99.6%
Точність позицій	100%
Документів повністю правильно	43 / 44
Медіана на документ	5.8 с
Оцінка вартості	$0.0015 / документ
Edge-case перевірки	3 / 3

В одному прогоні вийшло 44/44, у контрольному — 43/44. У кейсі опубліковані консервативні цифри й позначка про два прогони. Це синтетика, а не клієнтські дані: обіцяти таку точність на чужих сканах було б нечесно.

Чому XLSX розбирається без моделі

Прайс-лист у XLSX — це вже структуровані дані. Відправляти його в LLM дивно: дорожче, повільніше й менш передбачувано.

Код знаходить рядок заголовків, визначає колонки «Артикул», «Найменування», «Ціна», читає рядки й нормалізує числа. Такий документ обробляється за частки секунди й коштує $0.

Модель потрібна там, де структура втрачена: PDF, скани, фотографії, DOCX із таблицями.

Що важливо для довіри

• Цитати сторінок. Натиснув на поле — побачив фрагмент джерела.
• Перевірки прив'язані до полів. Помилка веде не в порожнечу, а до конкретного рядка.
• Правки зберігаються. Після підтвердження документ отримує статус done, а перевірки перераховуються.
• TTL 24 години. Завантажені файли видаляються автоматично; у демо — лише синтетика.
• Жодних публічних URL. Доступ до файлу — за ID і сесійною cookie.

Що далі

Наступні кроки — не «додати ще одну модель», а зміцнити процес:

• порівняння версій договорів;
• інтеграція з 1С і поштовою скринькою;
• кастомні схеми для клієнта;
• черга з ретраями й аудитом;
• більше сканів і мов у бенчмарку.

Але база вже працює: документ надходить, дані вилучаються, помилки ловляться, людина підтверджує, таблиця рухається далі. Саме це і є AI-помічник, який економить час, а не створює ще один інтерфейс для переперевірки.