Переконлива відповідь під час демонстрації показує, що ШІ-рішення може виконати один сценарій. Перед щоденним використанням потрібно перевірити значно більше: правильність фактів, роботу інтеграцій, права доступу, неповні запити та поведінку за помилок. Оцінюють увесь програмний процес, а не лише якість тексту.
Розглянемо умовного помічника, який відповідає за внутрішніми інструкціями та готує чернетки звернень. На цьому прикладі пояснимо, як організувати перевірку, що включити в тестовий набір і чому вона продовжується після першого запуску.
Спочатку визначте правильний результат
Для одного запиту можуть існувати кілька прийнятних формулювань. Тому вимога дослівно повторити еталон часто не відображає реальну задачу. Корисніше визначити ознаки результату: правильне джерело, збережені умови, потрібні поля та відсутність непідтверджених тверджень.
У нашому прикладі помічник має знайти чинну інструкцію, пояснити порядок дій і надати посилання. Якщо потрібної інформації немає, правильною поведінкою буде повідомлення про це або уточнення. Вигадана, хоча й добре написана відповідь, не проходить таку перевірку.
Зберіть набір різноманітних випадків
Тестові приклади повинні представляти майбутню роботу. Частину можна взяти з реальних звернень після належної підготовки даних. Складні й рідкісні випадки додають окремо, щоб їх не приховала велика кількість простих запитань. Очікуваний результат пояснює фахівець із відповідного процесу.
- Звичайне запитання з одним актуальним джерелом.
- Те саме запитання іншими словами або з помилками.
- Неповний запит, який потребує уточнення.
- Суперечливі чи застарілі документи.
- Відсутність відповіді в доступних матеріалах.
- Запит до документа або запису поза правами користувача.
- Недоступний сервіс і перерване виконання операції.
Зберігайте опис випадку разом із потрібними джерелами та критеріями. Так команда зможе повторити перевірку після змін і зрозуміти, чи проблема справді зникла, а не просто не проявилася в наступній демонстрації.
Розділіть пошук, пояснення та дію
Коли відповідь неправильна, важливо знайти причину. Пошук міг не повернути потрібний документ, модель могла пропустити важливу умову, а інтеграція — отримати інший запис. Якщо перевіряти тільки фінальний текст, ці різні помилки виглядатимуть однаково.
Тому в нашому сценарії спочатку перевіряють вибраний документ, потім відповідність пояснення його змісту та окремо — поля чернетки звернення. Для операції створення заявки додають підтвердження з боку системи, яка її приймає. Заявлений у чаті успіх повинен збігатися з фактичним результатом.
Що можна перевірити автоматично
Програмні перевірки добре підходять для формату даних, обов’язкових полів, дозволених операцій і реакції на відмову API. Можна перевіряти, чи не створюється дубль за повторного запиту та чи користувач не отримує недоступний йому запис. Ці властивості не повинні залежати від вдалого формулювання моделі.
Для змісту відповіді використовують погоджені критерії й перегляд фахівцем. Автоматична оцінка іншою моделлю може допомагати сортувати результати, але теж потребує перевірки на прикладах із відомими оцінками. Її висновок не варто приймати як безумовний доказ правильності.
Чому одного відсотка точності недостатньо
Уявімо набір із багатьох простих запитань і кількох випадків із застарілими документами. Загальний показник може виглядати добрим, хоча система регулярно помиляється саме на виборі чинної інструкції. Тому результати корисно розглядати за типами задач і причин невдачі.
Окремо вимірюйте те, що важливе для процесу: правильність джерела, повноту відповіді, кількість потрібних виправлень і час завершення всієї роботи. Для чернетки також має значення, чи працівник може зрозуміти її основу та швидко перевірити ключові факти.
Повторні запуски доречні для оцінки мінливості генерації, але вони не повинні приховувати невдалий результат. Зберігайте випадки помилок і перевіряйте їх після виправлення. Так поступово формується набір перевірок від повернення вже відомих проблем.
Як організувати пілот
Почніть із погодженої групи користувачів і визначеного обсягу задач. Працівники переглядають результати та фіксують конкретні проблеми: запит, використане джерело, отриману відповідь і те, що потрібно було отримати. Це значно корисніше за загальний відгук «працює погано».
Заздалегідь домовтеся, хто розбирає випадки та як команда реагує на суттєвий дефект. Іноді потрібно виправити документ або прибрати окрему можливість до перевірки, а не міняти модель. У пілота має бути зрозумілий спосіб передати роботу людині.
Що перевіряти після змін
На поведінку впливають нова версія моделі, інструкції, налаштування пошуку, документи та зовнішні API. Після зміни потрібен відповідний повторний прогін прикладів. Особливо корисні ті, на яких раніше виникали помилки або перевіряються важливі межі доступу.
Результати мають бути пов’язані з конкретною версією рішення та набором даних. Без цього складно пояснити, чому сьогодні система відповідає інакше, ніж під час приймання. Обсяг перевірки визначають характером зміни та процесом використання.
Які свідчення готовності потрібні команді
Перед запуском варто мати погоджені критерії, результати перевірки за групами випадків, перелік відомих обмежень і відповідальних за підтримку. Це дає команді основу для рішення про використання системи та подальші зміни.
Тестування допомагає зробити поведінку спостережуваною й зрозумілою. Щоб закласти такі перевірки від початку, використайте опис підготовки до розробки. Для сценаріїв із зовнішніми діями також стане в пригоді матеріал про інтеграції.
