Choice: категорія з чітким значенням
Choice підходить, коли потрібно обрати один із заданих варіантів. У сценарії повернення товару це може бути стандартна процедура, розгляд менеджером або запит відсутніх фактів. Три варіанти означають три різні наступні дії, які ваш застосунок може обробити явно.
Описуйте категорії так, щоб їхні межі були зрозумілими. Варіанти «важливо» і «терміново» можуть перетинатися; напрям роботи та рівень терміновості краще винести в різні питання. Якщо потік містить неповні дані, закладіть у свої правила, що з ними робити.
Score: шкала, кожен рівень якої можна пояснити
Для впорядкованої оцінки використовуйте Score. Шкала з описами «не перешкоджає оформленню», «ускладнює одному клієнту», «блокує один спосіб оплати» і «блокує всі способи» пояснює, що саме змінюється від рівня до рівня.
Це краще піддається перевірці, ніж прохання поставити абстрактний бал без критеріїв. Під час аналізу помилок можна запитати, яку ознаку модель пропустила: масштаб, доступність альтернативи чи сам факт блокування. Змінюючи порядок або зміст рівнів, версіонуйте шкалу разом з інтеграцією.
{
"completeness": {
"type": "score",
"instructions": "Скільки з трьох фактів відомо: строк, використання товару та наявність бирок?",
"criteria": [
"Жодного",
"Один факт",
"Два факти",
"Усі три факти"
]
}
}Noul: одне твердження, одна наступна перевірка
Noul корисний для сформульованого твердження: наприклад, чи містить чернетка відповідь, яка суперечить наведеному джерелу. Вкажіть саме джерело у контексті та поясніть, що потрібно оцінювати. Не змішуйте перевірку факту з побажанням щодо стилю в одному твердженні.
Який би тип ви не обрали, структурована форма сама по собі не доводить правильність рішення. Перевіряйте зміст на своїх даних, обробляйте помилки API та визначайте наступну дію у власному коді. Так формат відповіді стає зрозумілою частиною процесу.