Як перевірити, що штучний інтелект не робить помилок: оцінка та людський огляд

Штучний інтелект, який читає документи або відповідає на запитання, іноді робитиме помилки. Важливе питання полягає не в тому, чи робить він помилки, а в тому, як часто, у яких випадках та чи помічають це хтось до того, як помилка потрапить до клієнта чи до облікових записів. Для відповіді на це потрібні дві речі: набір для оцінки, якому ви довіряєте, та етап перевірки, вбудований у робочий процес.

Почніть з набору тестів на власних даних

Універсальні критерії оцінки показують, як модель виконує завдання інших людей. Вони мало що говорять про сертифікати вашого постачальника чи шаблони контрактів. Першим результатом будь-якої серйозної автоматизації з використанням ШІ має бути набір тестів, створений на основі реальних випадків:

• 50–200 реальних прикладів для початку, більше — для процесів із багатьма типами документів;
• правильна відповідь для кожного з них, записана людиною, яка виконує роботу сьогодні;
• Навмисно додано складні випадки: погані сканування, рукописні нотатки, відсутні поля, документи іншою мовою, два документи, склеєні в один PDF;
• Примітка про те, які помилки є серйозними, а які лише дратують.

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

Вимірюйте те, що важливо

Одне число точності приховує ті невдачі, які вас цікавлять. Розберіть результат:

• Правильність на рівні полів під час вилучення даних: чи були правильно прочитані номер рахунку-фактури, дата, сума, ставка ПДВ?
• Перевірка правил під час завдань на перегляд: чи позначив агент прострочений сертифікат, відсутню підпис, умови оплати, що відрізняються від умов контракту?

Хибні спрацювання: скільки правильних документів було позначено як такі. Якщо їх занадто багато, люди перестають звертати увагу на ці позначки.

Утримання від відповіді: наскільки часто агент казав «не впевнений», замість того щоб здогадуватися. Добре створений агент утримується від відповіді у випадках, які він не може обробити.

Правила, які можна перевірити за допомогою коду, слід перевіряти саме кодом. Якщо запитання звучить як «чи є дата сертифіката у майбутньому», порівняйте дати в програмі та використовуйте модель лише для пошуку дати в документі. Це саме по собі усуває цілу категорію помилок.

Проводьте оцінку після кожної зміни

Підказки, моделі, налаштування OCR та код для обробки змінюються протягом усього життєвого циклу проекту. Кожна зміна може вирішити п’ять проблем, але пошкодити ще три. Набір для оцінки має запускатися автоматично перед тим, як будь-яка зміна потрапить у продакшн, причому результати порівнюються з попередньою версією. Якщо показники погіршуються, зміна відкладається.

Те саме стосується й заміни моделей. Новіша чи дешевша модель не обов’язково краще працює з вашими документами. Запустіть набір для оцінки, порівняйте результати, а потім прийміть рішення.

Розмістіть людину там, де є ризик

Людський огляд — це не ознака невдачі автоматизації. Це спосіб отримати переваги автоматизації, не ризикуючи всім бізнесом через одну модель. Практична схема:

• результати, які перевищують узгоджений поріг надійності та пройшли всі перевірки за правилами, проходять автоматично або підлягають швидкій додатковій перевірці;
• Невизначені результати, невдалі перевірки та випадки високої цінності потрапляють у чергу на перегляд, де поруч із вилученими даними відображається вихідний документ;
• Кожне схвалення та корекція фіксуються з зазначенням того, хто їх здійснив та коли;
• Корекції повертаються у набір тестів, тож наступна оцінка враховує випадок, у якому виникли проблеми.

Поріг є бізнес-рішенням. Почніть із суворих умов, виміряйте, наскільки фактично змінюють їх переглядачі, та послаблюйте їх лише тоді, коли це підтверджують цифри.

Спостерігайте за цим у продакшені

Реальні дані постійно змінюються. Постачальник може змінити свою шаблонну структуру, сканер може бути замінений, з’являється новий тип документа. Моніторинг для ШІ-агента має відображати принаймні частку документів, надісланих на перевірку, частку корекцій, внесених перевіряючим, помилки обробки та періоди затримки, а також вік найстарішого елемента у черзі. Підвищена кількість корекцій зазвичай є першою ознакою того, що щось у передній частині ланцюга обробки змінилося.

Як має виглядати ефективний рішення

Ви можете на основі цифр з власних даних відповісти на запитання про те, наскільки часто агент правильно обробляє кожне поле та кожне правило, що відбувається з випадками, коли він робить помилки, та як ви будете помічати зміни. Якщо постачальник не може цього показати, ви спостерігаєте демо-версію, а не продакшн-систему.

Ми створюємо цей шар як частину нашої послуги від демо-версії до продакшну та в AI-агентах для перегляду документів. Щодо організаційних аспектів того, хто його створює та кому належить, дивіться що таке інженер з передовим розгортанням.