Від PDF до рішення: три перевірки для AI

Тому AI варто оцінювати за результатом конкретної роботи: чи впорядкований пакет, чи знайдений потрібний матеріал, чи допомагає стислий виклад розібратися в умовах. Нижче — запропонована редакцією IQusion карта перевірок для організації, яка хоче випробувати ці можливості на власних документах.

Три результати, три способи прийняти роботу

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

Пропонуємо домовитися про це до пілота. Оператора цікавить комплектність пакета, працівника закупівель — потрібна умова та її застосовність, керівника — зрозуміле пояснення з можливістю відкрити першоджерело. Спільна оцінка «асистент добре відповідає» приховує різницю між цими завданнями. Кожному потрібен свій спосіб перевірки.

Почніть із запитання до майбутнього користувача: яку дію він виконає після відповіді? Якщо це пошук потрібного пункту, покажіть пункт. Якщо підготовка до погодження — зберіть матеріали, які треба прочитати разом. Так вимоги до AI стають частиною звичайної роботи, а результат можна обговорювати предметно.

Розділити файл, зберегти справу

Документація Google Document AI розрізняє прогноз логічних меж документа і фізичне створення окремих файлів. У настанові для Custom Splitter Google називає перевірку людиною між прогнозом і фактичним поділом найкращою практикою: хибна межа може сформувати два неправильні документи й спричинити помилки подальшого витягання даних. Якщо організація використовує показник упевненості, щоб у частині випадків пропускати ручну перевірку, поріг варто визначати за історичними даними про частоту помилок і допустимим для бізнес-процесу ризиком.

Наш практичний орієнтир ширший за правильне розрізання PDF: після обробки має залишитися зрозуміло, які документи надійшли разом. Для пілота радимо зберігати оригінальний пакет і посилання на нього з кожної створеної картки. Окремо перевірте зв’язки договору з додатками: сусідство сторінок саме по собі ще не пояснює їхніх ділових відносин.

Розділення пакета в Scriptum.DMS: перелік документів поруч із переглядом сторінки. Скриншот InBase; ілюструє функцію розділення, а не описаний вище сценарій погодження. Натисніть зображення, щоб роздивитися інтерфейс.

Потрібна відповідь у дозволеній версії

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

Але знайти схоже недостатньо. Запропонуйте учасникам два завдання: з’ясувати умови, що діють зараз, і відновити умови на минулу дату. В обох випадках корисно бачити назву, версію та статус документа поруч із фрагментом. Старі редакції можуть бути потрібні для історичної перевірки; їх не слід безумовно прибирати з пошуку.

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

Перевіряйте доступ до змісту відповіді так само уважно, як доступ до самого файла.

Коротко прочитати, точно перевірити

Стислий виклад зручний як початкова карта великого документа: він допомагає визначити, які місця потребують уваги. Однак NIST описує ризик упевнено сформульованих помилкових відповідей генеративного AI. Неправильними можуть бути й посилання, якими модель підкріплює текст. Рекомендації NIST включають їх перевірку перед запуском і під час подальшого використання.

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

Окремо випробуйте запитання, відповіді на яке в наданому комплекті немає. Прийнятний для такого сценарію результат — чітко позначена прогалина, наприклад відсутній додаток із графіком поставки. Не вимагайте від асистента заповнювати кожне поле здогадкою: незаповнений пункт іноді краще показує наступну дію працівника.

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

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

Пілот починається з критеріїв приймання

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

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

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

• Комплектність. Зіставте запропоновані межі з перевіреним пакетом. З’ясуйте, чи можна повернутися до оригіналу та знайти пов’язані додатки.
• Дозволений зміст. Повторіть запити з різними правами. Перевірте, чи не з’являються закриті фрагменти у відповідях і цитатах.
• Перевірюване резюме. Відкрийте джерело кожної важливої тези. Зафіксуйте пропущені застереження й місця, де відповідь додала непідтверджене.
• Правильна версія. Перевірте поточні та історичні запити. Читач має розуміти, який документ використано і на яку дату він відповідає задачі.

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

Поширені питання

Джерела

• AI-розділення, пошук та резюме документів: як ці функції змінюють роботу з документами
• Custom splitter — Document AI
• Hybrid search using vectors and full-text search in Azure AI Search
• Document-level access control in Azure AI Search
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST AI 600-1