Створіть набір оцінювання до демонстрації ШІ

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

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

Описуйте властивості відповіді, а не одне ідеальне речення

Генерована відповідь може бути правильною, не повторюючи еталон дослівно. Тому для випадку варто записати обов’язкові факти, дозволені джерела, заборонені твердження, прийнятну невпевненість, формат і очікувану дію: відповісти, уточнити, відмовити або передати людині. Для вилучення даних поля можуть бути точними; для підтримки чи дослідження важливіші джерела й фактичні властивості.

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

Оцінюйте частини конвеєра окремо

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

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

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

Зробіть набір частиною контролю змін

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

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