Ваш CI пройшов успішно. Ваш агент не готовий до роботи оператора

Ми поставили агент для роботи з документами корпоративному клієнту минулого кварталу.

Наш набір тестів показав 94% успішних проходжень.

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

Наш CI весь цей час залишався «зеленим».

Проблема була не в моделі чи промпті. Проблема була в тих 6% даних, які ми не протестували. Ці 6% надійшли як перші реальні дані від оператора.

Це не граничний випадок (edge case). Це і є визначення готовності до роботи оператора.

Готовність до продакшену (production-ready) стосується інфраструктури. Це означає, що ваш сервіс працює стабільно та витримує навантаження.

Готовність до роботи оператора (operator-ready) — це інше. Це означає, що ваш агент працює для того, хто його не створював. Він працює з даними, які ви не проєктували. Він приймає рішення з реальними наслідками.

Більшість конвеєрів тестування (test pipelines) вимірюють рівень успішності на наборі даних, який створили ви. Вони не вимірюють те, що стається, коли реальні дані відрізняються від вашого тестового набору.

Модель із 97% успішної валідації звучить непогано. Але подивіться на ті 3%, які зазнають невдачі.

Якщо ваш агент заповнює відсутні поля значеннями за замовчуванням під час повторної спроби (retry), ви створили машину прихованих помилок. Схема проходить перевірку, але дані є неправильними.

Щоб виправити це, відокремте валідність схеми від впевненості в контенті (content confidence).

Ми додали показник впевненості (confidence score) до кожної відповіді. Низька впевненість тепер ініціює перевірку людиною замість повторної спроби. Ця зміна допомогла виявити 14 з наших перших 18 інцидентів.

Ваш тестовий набір охоплює те, про що ви подумали. Дані оператора охоплюють те, що ви пропустили.

У нашому випадку ми тестували односторінкові інвойси. Оператор використовував багатосторінкові інвойси у форматі сканованих PDF. Агент не впорався з новим форматом.

Не просто виправляйте парсер. Тестуйте на реальних даних оператора перед запуском у роботу.

Перед будь-якою передачею проєкту ми тепер вимагаємо 50 документів із власних даних оператора. Ми не використовуємо синтетичні дані. Ми використовуємо їхні.

Вам також потрібен повний аудиторський слід (audit trail). Не просто логуйте те, що повернула модель. Логуйте те, що модель вирішила не робити.

Мінімальний аудиторський слід має містити:

  • Вихідні дані з показниками впевненості на рівні полів
  • Індикатор відкату (fallback), що показує, чи робив агент повторну спробу
  • Хеш вхідних даних для відтворення саме того документа
  • Конкретну версію моделі та промпту, що використовувалися

Перш ніж передати агента оператору, перевірте ці п'ять речей:

  • Запустіть понад 50 зразків із реальних даних оператора.
  • Шукайте в логах результати, які пройшли перевірку схеми, але спричинили помилки на наступних етапах (downstream errors).
  • Подавайте некоректні вхідні дані, щоб переконатися, що агент безпечно завершує роботу у разі помилки.
  • Переконайтеся, що ви можете відповісти на питання, що сталося з конкретним документом, менш ніж за 5 хвилин.
  • Перевірте, щоб агент мав мінімально необхідні права доступу.

Наш рівень успішності тестів був 94%. Наш рівень помилок у перший місяць становив 8%.

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

Проблема була не в результатах тестування. Проблема була в охопленні тестування (test scope).

Джерело: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

Додаткова спільнота для навчання: https://t.me/GyaanSetuAi