Прочитати документ замало: як AI готує дані
Документ можна прочитати без жодної помилки в літерах і все одно перенести в систему неправильні дані. Дата у шапці може бути датою оформлення, а роботи виконали раніше. Адреса в реквізитах може належати офісу виконавця, хоча обладнання стоїть на іншому об'єкті. Для працівника ці відмінності звичні. Для автоматизованого опрацювання їх потрібно описати.
Тому розмову про AI варто починати з майбутнього запису: що саме має отримати команда, яка планує обслуговування, веде історію обладнання або приймає виконані роботи. У матеріалі InBase про неструктуровані документи йдеться про витяг значень і заповнення полів системи документообігу; автори також зазначають потребу налаштування під типи документів. Далі розберемо, які рішення варто прийняти до такого налаштування.
Придатне для роботи поле — це значення з поясненим змістом, джерелом і статусом перевірки.
Дві дати — два різні запитання
Уявімо акт обслуговування обладнання. Це ілюстративний приклад, а не опис впровадження. У шапці зазначено дату складання й реквізити виконавця. Нижче — день виконання робіт, місце встановлення обладнання та перелік операцій. Якщо створити поля «дата» й «адреса», документ пропонуватиме одразу кілька правдоподібних відповідей. Потрібні точніші запитання: коли оформили акт, коли обслуговували обладнання та де саме воно розташоване.
| Фрагмент документа | Поле запису | Із чим не плутати |
|---|---|---|
| Дата у шапці | Дата складання акта | День виконання робіт |
| Дата в описі обслуговування | Дата робіт | День оформлення |
| Адреса офісу в реквізитах | Офіс виконавця | Місце обладнання |
| Адреса біля опису об'єкта | Місце обладнання | Офіс виконавця |
Документація Google Document AI передбачає для поля назву, опис, тип значення та очікувану кількість появ. Це дає змогу описати схему документа. Саме визначення схеми ще не підтверджує, що кожне значення буде витягнуто правильно.
У власній схемі додайте до кожного поля коротке правило: звідки брати значення і що робити, коли є кілька кандидатів. Для дати робіт таким правилом може бути пошук в описі виконаних операцій. Якщо акт охоплює кілька днів, заздалегідь вирішіть, чи потрібен період, чи окремі дати для рядків. Інакше неоднозначність просто переїде з документа в облік.
Рядок має залишитися рядком
У нашому акті можуть повторюватися назви робіт: перевірка, очищення, заміна. Окремий список цих слів мало допоможе, якщо втрачено зв'язок із конкретним обладнанням, кількістю та одиницею виміру. Запис «заміна — два» ще не пояснює, що замінили й на якому об'єкті. Помилка тут виникає між правильно прочитаними клітинками.
Azure Document Intelligence описує результат аналізу таблиць через рядки, стовпці, індекси та охоплення клітинок. Координати й текстові позиції допомагають пов'язати отриманий результат із місцем у документі. Це технічні засоби для перевірки, а не обіцянка правильного відтворення будь-якої таблиці.
Для акта варто передавати перелік робіт як набір пов'язаних рядків. Усередині кожного зберігати обладнання, операцію, кількість та одиницю. Якщо назву обладнання винесено в заголовок над кількома рядками, перевірити, до яких саме операцій вона належить. Порожня клітинка не завжди означає те саме, що попередня.
Поруч зі значенням корисно залишити сторінку та посилання на фрагмент оригіналу. Тоді працівник перевіряє спірний рядок одразу, а не шукає його по всьому акту. Така прив'язка також допомагає пояснити виправлення: яке значення змінили й на підставі якого фрагмента.
Упорядкувати формат, не дописати зміст
Після витягу значення часто потрібно привести до формату системи. Дату, записану словами, можна подати у встановленому форматі, а зайві пробіли — прибрати. Але це не дозвіл заповнювати прогалини: місяць без числа не стає повною датою, а кількість без одиниці не перетворюється автоматично на штуки.
Google Document AI розрізняє вихідне витягнуте значення та нормалізоване представлення для підтримуваних полів. Документація окремо описує збагачення зовнішньою інформацією. Отже, повернуте значення не завжди варто вважати дослівним фрагментом документа: потрібно розуміти, яка операція його сформувала.
Для нашого прикладу доцільно зберігати початковий запис поруч із підготовленим значенням. Якщо адресу обладнання доповнили з внутрішнього довідника об'єктів, позначити джерелом саме довідник. Не подавати уточнений запис так, наче повна адреса була в акті.
Окрема домовленість потрібна для скорочень. Назву роботи можна зіставити з погодженим переліком операцій, але незнайоме скорочення краще передати на розбір. Після пояснення відповідальним працівником команда зможе доповнити правила. Так новий варіант стане контрольованим поповненням словника, а не прихованою здогадкою моделі.
Знайдене ще не означає прийняте
Система обліку очікує заповнену форму, але документ не зобов'язаний містити всі потрібні поля. Якщо акт не називає місце обладнання однозначно, вимога «адреса обов'язкова» не створює достовірної адреси. Для пілота можна погодити простий набір станів:
- Знайдено. Значення витягнуто та пов'язано з фрагментом; перевірка за правилами ще попереду.
- Потребує уточнення. Є кілька кандидатів, суперечність або неповний запис; потрібна відповідь працівника.
- Не знайдено. Очікуваного значення немає серед отриманих даних; важливу відсутність перевіряють за оригіналом.
- Підтверджено. Значення прийнято за погодженим правилом або відповідальним працівником; збережено спосіб підтвердження.
Це запропонована організація роботи, а не стандарт статусів конкретного продукту. Нормалізацію та доповнення з довідника краще записувати окремо: вони описують обробку значення, але самі собою не роблять його підтвердженим.
Передавання теж потребує правила. Чи можна створити чернетку запису з порожньою датою робіт? Чи має весь акт чекати уточнення? Для різних полів відповіді можуть відрізнятися. Власник процесу визначає їх до інтеграції, а команда перевіряє, що порожнє значення не підміняється поточною датою або адресою за замовчуванням.
Перевіряйте поля, які змінюють роботу
Добірка для пілота має показати не лише охайні акти, а й незручні варіанти: кілька дат, перенесення таблиці на іншу сторінку, пропущену одиницю виміру, різні адреси. Працівник, який користуватиметься результатом, заздалегідь позначає правильні значення та допустимі пропуски.
Google Document AI оцінює витяг порівнянням результату з розміченими тестовими документами та подає показники для окремих полів і загалом. Зведена оцінка враховує частоту появ полів, тому її недостатньо для окремого висновку про рідкісне, але важливе поле.
- Зміст. Дата робіт не підмінена датою складання, а місце обладнання — адресою офісу.
- Зв'язки. Операція, обладнання, кількість та одиниця залишилися в належному рядку.
- Походження. Можна відкрити фрагмент акта й відрізнити його текст від доповнення з довідника.
- Передавання. Пропуск або суперечність запускає погоджений сценарій, а не непомітне заповнення.
Почніть із однієї форми акта: випишіть потрібні поля, додайте приклади неоднозначностей і назвіть відповідального за кожне уточнення. З такою схемою та добіркою документів можна обговорювати пілот із IQusion: буде зрозуміло, який запис потрібен на виході й за якими прикладами перевіряти результат.
Поширені питання
Що робити з одним актом на кілька одиниць обладнання?
Визначити, як кожний рядок роботи пов'язаний з обладнанням. Якщо назва стоїть над групою рядків, перевірити межі цієї групи. Коли зв'язок неоднозначний, передати його на уточнення замість поширення першої назви на весь акт.
Чи означає статус «не знайдено», що даних у документі немає?
Ні. Він може означати, що значення не потрапило до результату витягу. Для важливого поля потрібно перевірити оригінал і розрізнити пропуск під час опрацювання та відсутність у самому акті.
Хто має пояснити спірний запис у документі?
Цю роль варто визначити до пілота: наприклад, працівник, який приймає роботи або веде історію обладнання. Якщо потрібної інформації немає в акті, може знадобитися уточнення в його автора. Підтвердження і підставу виправлення слід зберегти.
