Асистент витягнув реквізити рахунку й показав високу впевненість. Номер документа правильний, але валюта взята з примітки, а не з підсумку. Це умовний приклад, у якому успішне розпізнавання не дорівнює правильному результату. До передачі запису в наступний процес потрібні окремі перевірки змісту.
Оцінюйте поля за наслідками помилки
Помилка в описі може ускладнити пошук. Помилка в ідентифікаторі контрагента, сумі чи валюті може спрямувати запис у неправильний процес. Складіть перелік критичних полів і визначте, які перевірки для них обов’язкові.
Розпізнавання, перевірка довідника, погодження документа та виконання операції є різними діями. Навіть повністю правильне вилучення тексту не є дозволом на оплату або підтвердженням облікового рішення.
Перевіряйте на документах, яких модель не бачила
Тестова вибірка має представляти типи документів, які надходитимуть у роботу: різні форми, якість сканування, сторінки й винятки. Очікувані значення готують і перевіряють окремо. Якщо тест використовували для налаштування, його вже недостатньо для незалежного приймання.
Документація Google Document AI розділяє precision, recall і F1 та показує вплив порогу впевненості на результат. Вищий поріг може зменшити кількість хибних прийнятих прогнозів, одночасно збільшуючи пропуски. Універсальне число для всіх документів із цього не випливає.
Визначте маршрут для невпевненого результату
Для нашого прикладу валюта має бути зіставлена з правильним підсумком документа. Якщо джерела суперечать одне одному, запис переходить на перевірку, а не отримує значення за замовчуванням. Людина повинна бачити відповідний фрагмент оригіналу та причину зупинки.
Окремо перевірте повторне надходження того самого документа. Виправлення поля має оновити потрібний запис, а не створити ще одну операцію. Правило ідентифікації документа погоджують до запуску; один лише номер може бути недостатнім.
| Результат | Наступна дія | Хто відповідає |
|---|---|---|
| Поле відповідає джерелу та правилам | Передати в погоджений наступний етап | Власник процесу визначає правило |
| Значення суперечить іншому фрагменту | Показати джерела для перевірки | Уповноважений перевіряльник |
| Документ уже оброблявся | Зіставити ідентичність і стан | Відповідальний за реєстр |
Приймайте процес, а не красиву демонстрацію
Збережіть результати окремо за критичними полями, типами документів і причинами ручної перевірки. Середній показник не повинен приховувати проблемний тип. Пороги та допустимі наслідки погоджує власник процесу на основі тестів.
E-Data Consulting розглядає Scriptum.DMS та інші рішення Intecracy Group після визначення цих вимог. Підтримку форматів, спосіб показу джерела й інтеграцію перевіряємо на реальній конфігурації. Практичний перший крок: зібрати представницьку вибірку та описати, що вважатиметься помилкою кожного критичного поля.
Питання та відповіді
Чи достатньо високої впевненості моделі?
Ні. Її потрібно зіставити з правильними відповідями на незалежній вибірці та перевірити наслідки помилок у конкретному процесі.
Чи потрібно перевіряти всі поля вручну?
Це рішення власника процесу після тестування. Частина перевірок може бути формалізована, а неоднозначні та критичні випадки мають визначений маршрут до людини.
Джерело та метод
Google Document AI: Evaluate performance. Приклад і порядок приймання вище є редакційним методом, а не цитатою зі стандарту чи описом реального клієнтського кейсу.