Оцінювання, ітерація та випуск v1

Побудова ШІ | Складність: [MEDIUM] | Час: 40-55 хв | Передумови: модулі 1.1-1.3 розділу «Побудова ШІ», базове володіння промптами, базовий JSON, базове використання командного рядка

Результати навчання

Після завершення цього модуля ви зможете:

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

Чому цей модуль важливий

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

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

Цей модуль навчає старшої звички, що стоїть за надійними ранніми ШІ-продуктами: змінюйте одну річ за раз, вимірюйте її на репрезентативних прикладах і випускайте лише в межах, які ви можете пояснити. Ви спроєктуєте контракт v1, побудуєте невеликий набір для оцінювання, діагностуватимете відмови за категоріями, робитимете причинно-наслідкові ітерації та вирішуватимете, чи є межа запуску достатньо чесною для реальних користувачів. Мета не в тому, щоб зробити крихітний бенчмарк грандіозним; мета — створити достатньо доказів, щоб наступне продуктове рішення ґрунтувалося на поведінці, а не на ентузіазмі.

Почнімо з найменшого чесного запитання

Перш ніж налаштовувати систему, запитайте, яку роботу функція має виконувати достатньо добре, щоб бути корисною. Це запитання свідомо менше, ніж «Як зробити її дивовижною?» або «Як зробити так, щоб вона обробляла будь-який можливий запит користувача?», тому що робота v1 досягає успіху, коли завдання достатньо вузьке для спостереження. Корисне запитання v1 називає користувача, тип вхідних даних, завдання та межу перевірки, щоб команда могла відрізнити добру відповідь, ризиковану відповідь і відповідь, яку не слід було намагатися дати.

Наприклад, організація підтримки може запитати, чи може ШІ-функція класифікувати вхідні тікети підтримки в одну з п’яти черг, використовуючи лише тему та тіло тікета, і при цьому показувати речення, яке обґрунтовує класифікацію. Це запитання каже вам, які вхідні дані отримує система, який вивід вона має виробляти, скільки міток дозволено, які докази має надати система і що їй заборонено робити. Вона не вирішує тікет, не надсилає відповідь, не змінює дані клієнтів і не діє без перевірки. Межа — це не слабкість; це те, що робить першу версію придатною для випуску.

Розмита ШІ-функція створює розмиту відповідальність, тоді як обмежена ШІ-функція створює видиму роботу. Коли обсяг каже «допомагати підтримці з тікетами», рецензенти сперечатимуться про те, чи виглядає плавна відповідь корисною. Коли обсяг каже «запропонувати одну мітку черги та процитувати речення, яке її підтверджує», рецензенти можуть перевірити конкретну поведінку. Це різниця між демо та ціллю оцінювання.

Від ідеї до контракту v1

Використовуйте контракт v1 перед написанням промптів, тому що промпти — це деталі реалізації, тоді як контракт — це продуктова обіцянка. Контракт — це невелика угода між розробником, рецензентом і користувачем. Він каже, що функція робить, що вона відмовляється робити, як люди оцінюватимуть якість виводу і що станеться, коли докази невизначені або відсутні. Без цієї угоди зміни промптів схильні ганятися за симптомами, тому що ніхто не записав справжню роботу.

Поле контракту	Добрий приклад v1	Слабкий приклад v1
Робота користувача	Швидше спрямовувати тікети підтримки в правильну чергу	Допомагати підтримці з тікетами
Вхідні дані	Лише тема та тіло тікета	Будь-яка розмова з клієнтом
Вивід	Одна мітка черги, примітка про впевненість, підтверджувальна цитата	Корисний аналіз
Умова успіху	Правильна черга принаймні на більшості репрезентативних прикладів, без непідтверджених цитат	Виглядає корисно в демо
Людська перевірка	Власник сортування приймає або змінює чергу перед маршрутизацією	Система маршрутизує безпосередньо
Поведінка відмови відповідати	Позначити як `needs_human_review`, коли жоден доказ не підтримує чергу	Вгадати найімовірнішу чергу

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

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

Ваша команда може запропонувати функцію під назвою «Використати ШІ для обробки ескалацій клієнтів». Сильніший контракт v1 був би таким: «Для нових листів з ескалаціями клієнтів створити чернетку внутрішнього підсумку з двох абзаців для менеджера з ескалацій, що включає запитану дію, зачеплений обліковий запис і цитату з листа для кожного твердження. Якщо будь-яке поле відсутнє, позначити його як unknown замість того, щоб вгадувати». Зауважте, що змінилося. Функція більше не обробляє ескалацію; вона готує придатний для перевірки підсумок, називає обов’язкові поля, вимагає доказів і визначає невизначеність.

Оцінювання не мусить бути вишуканим

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

Перший набір для оцінювання повинен містити звичайні приклади, а не лише чисті приклади, драматичні приклади або приклади, які змушують модель виглядати добре. Вам потрібна безладна середина, тому що саме там житиме функція. Корисний перший набір включає легкі успіхи, нормальні випадки, неоднозначні випадки, спотворені вхідні дані, крайові випадки з високим бізнес-ризиком, випадки, де правильною відповіддю є «я не знаю», випадки, де модель повинна навести докази, і випадки, де модель повинна відмовитися від непідтвердженої дії. Тримайте набір достатньо малим, щоб людина все ще могла прочитати кожен вивід.

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

Мінімальний запис оцінювання

Один запис оцінювання можна записати як JSON, і наведений нижче формат свідомо простий. Він не прив’язаний до конкретного фреймворку чи вендора оцінювання. Він достатньо структурований, щоб порівнювати очікувану та фактичну поведінку, і цього достатньо, щоб запустити корисний цикл. Запис дає системі вхідні дані, рецензенту — очікуваний результат, оцінювачу — докази для перевірки, а команді — місце для фіксації ризику.

{
  "id": "ticket-routing-001",
  "input": {
    "subject": "Refund requested after duplicate billing",
    "body": "I was charged twice for my April invoice. Please refund the duplicate charge."
  },
  "expected": {
    "queue": "billing",
    "required_evidence": "charged twice"
  },
  "risk": "low",
  "notes": "Straightforward billing ticket."
}

Точна схема може варіюватися, але звичка важливіша за інструмент. Ви записуєте вхідні дані, очікувану поведінку, докази, необхідні для обґрунтування цієї поведінки, і причину, чому випадок належить до набору. Коли випадок пізніше зазнає невдачі, команда може обговорити невдачу на основі записаного очікування, а не покладатися на пам’ять. Коли очікування змінюються, зміну можна зафіксувати як продуктове рішення, а не тихо редагувати, щоб оцінка виглядала краще.

Критерії проходження та непроходження

Правило проходження/непроходження має бути достатньо конкретним, щоб двоє рецензентів зазвичай погоджувалися. Слабкі критерії звучать як «добрий підсумок», «корисна відповідь», «здебільшого правильно», «виглядає розумно» або «користувачеві сподобалося б». Ці фрази занадто м’які, тому що ШІ-системи зазнають невдач тонкими способами. Гарна відповідь з одним непідтвердженим твердженням не є проходженням, якщо вимагається обґрунтованість, а впевнена класифікація не є проходженням, якщо мітка поза дозволеним списком.

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

Перш ніж запускати це, якого виводу ви очікуєте від випадку, де клієнт хоче повернення коштів, але ідентифікатор облікового запису відсутній? Очікуваний вивід може бути queue: billing, account_id: unknown і next_step: ask human for account lookup. Це кращий тест, ніж ще один чистий успішний випадок, тому що чистий успіх доводить щасливий шлях, тоді як випадок відмови або ескалації доводить межу.

Практичний цикл v1

оберіть одне завдання
   ->
зберіть репрезентативні приклади
   ->
визначте, як виглядає успіх
   ->
запустіть систему
   ->
перевірте відмови
   ->
змінюйте одну річ за раз

Правило «одна річ за раз» важливе, тому що цикл оцінювання має навчати причинно-наслідковості, а не просто виробляти кращий на вигляд вивід. Якщо ви змінюєте промпт, модель, контекст і формат виводу разом, ви майже нічого не дізнаєтеся з результату. Оцінка може покращитися, але ви не можете сказати, чи покращення прийшло від чіткішої інструкції, кращого пошуку, суворішої форми чи потужнішої моделі. Команда, яка не може пояснити, чому якість покращилася, не може надійно покращити її знову, а команда, яка не може визначити, що спричинило регресію, не може безпечно випускати.

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

Опрацьований сценарій ітерації: маршрутизація тікетів

Гіпотетичний сценарій: команда будує маршрутизатор тікетів підтримки v1, який повинен видавати одну мітку черги, одну підтверджувальну цитату з тікета та needs_human_review, коли доказів недостатньо. Дозволені черги: billing, technical_support, account_access, sales і needs_human_review. Функція свідомо допоміжна; власник сортування приймає або змінює пропозицію перед маршрутизацією. Ця межа дозволяє команді оцінювати якість класифікації, не надаючи системі операційних повноважень.

Команда починає зі змішаного вводу, який достатньо реалістичний, щоб виявити продуктове правило. Клієнт згадує подвійний білінг і доступ до сторінки рахунку в одному тікеті, тому очікувана поведінка не очевидна, поки бізнес-пріоритет не записано. Білінг впливає на гроші, тому команда вирішує, що подвійне списання має пріоритет, а проблема доступу повинна бути зафіксована як вторинна проблема.

{
  "subject": "Charged twice and cannot access invoice",
  "body": "I was charged twice this month. I also cannot open the invoice page because it says permission denied. Please fix this today."
}

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

{
  "queue": "billing",
  "supporting_quote": "I was charged twice this month.",
  "secondary_issue": "account_access"
}

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

Classify this support ticket into the best queue:
billing, technical_support, account_access, or sales.

Ticket:
Subject: Charged twice and cannot access invoice
Body: I was charged twice this month. I also cannot open the invoice page because it says permission denied. Please fix this today.

Модель повертає правдоподібну, але неправильну відповідь. Вона фокусується на фразі «permission denied», яка є конкретною та операційною, але пропускає пріоритет «спочатку білінг». Відмова не випадкова; вона показує, що визначенню завдання бракує правила конфлікту.

{
  "queue": "account_access",
  "reason": "The user cannot open the invoice page because of permission denied."
}

Команда фіксує відмову як діагноз, а не як скаргу. Ця таблиця мала, але вона охоплює вхідні дані, відмову, підозрювану причину, одну зміну для спроби та поточний результат. Комірка «pending» — це корисне нагадування, що запропоноване виправлення не є виправленням, поки той самий випадок і регресійні випадки не будуть перезапущені.

Ітерація	Вхідні дані	Відмова	Діагноз	Зміна	Результат
baseline	подвійне списання плюс помилка доступу до рахунку	спрямовано до `account_access`	немає правила пріоритету для змішаних тікетів	додати лише правило пріоритету	pending

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

Classify this support ticket into one queue:
billing, technical_support, account_access, sales, or needs_human_review.

Priority rule:
If the ticket includes a billing problem and another problem, choose billing first.
If evidence is insufficient, choose needs_human_review.

Return JSON with:
queue
supporting_quote
secondary_issue

Ticket:
Subject: Charged twice and cannot access invoice
Body: I was charged twice this month. I also cannot open the invoice page because it says permission denied. Please fix this today.

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

{
  "queue": "billing",
  "supporting_quote": "I was charged twice this month.",
  "secondary_issue": "account_access"
}

Наступний приклад перевіряє, чи нове правило надмірно спрямовує звичайні випадки доступу до облікового запису в білінг. Клієнт явно каже, що проблеми з білінгом немає, тому правило «спочатку білінг» не повинно спрацьовувати. Така регресійна перевірка не дає команді святкувати виправлення одного випадку, яке пошкоджує решту набору.

{
  "subject": "Cannot log in after password reset",
  "body": "I reset my password, but the login page still rejects it. I do not have any billing issue."
}

Вивід залишається правильним, тому команда може зробити точне твердження: додавання правила конфлікту «спочатку білінг» виправило змішаний випадок білінгу/доступу, не зламавши протестований випадок доступу до облікового запису. Це справжнє навчання. Це не просто кращий вивід; це причинно-наслідкове покращення, прив’язане до продуктового правила.

{
  "queue": "account_access",
  "supporting_quote": "the login page still rejects it",
  "secondary_issue": null
}

Що команда не зробила

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

Припустімо, той самий маршрутизатор тікетів пізніше повертає правильну чергу зі слабкою цитатою. Черга — billing, але підтверджувальна цитата — «Please fix this today». Відмова не в класифікації; це вибір доказів. Перша зміна повинна уточнити, що підтверджувальна цитата повинна містити фразу або речення, яке безпосередньо доводить вибрану чергу, тому що зміна моделі зробила б експеримент більш шумним.

{
  "queue": "billing",
  "supporting_quote": "Please fix this today.",
  "secondary_issue": "account_access"
}

Що змінювати насамперед

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

Гіпотетичний сценарій: команда будує ШІ-функцію, яка відповідає на запитання про внутрішній runbook розгортання. Користувач запитує: «Чи можу я перезапустити платіжний воркер у робочий час?» Система відповідає: «Так, перезапуск воркера зазвичай безпечний, якщо ви відстежуєте логи після цього». Очікувана відповідь — ні, тому що runbook каже, що платіжні воркери можна перезапускати лише під час затвердженого вікна технічного обслуговування, якщо команда реагування на інциденти не затвердить виняток. Команда могла б перемкнути моделі, додати суворіший формат, додати валідацію, покращити пошук або уточнити завдання, але дисциплінована ітерація починається з першої ймовірної причини.

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

Answer the user's question using the runbook.

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

Answer the user's question using only the runbook excerpt.
If the runbook includes a restriction, state the restriction before any operational advice.
Include one exact quote from the excerpt.
If the excerpt does not answer the question, say "not enough information."

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

{
  "answer": "No. The runbook restricts payment worker restarts to the approved maintenance window unless incident command approves an exception.",
  "quote": "Payment workers must be restarted only during the approved maintenance window unless incident command approves an exception.",
  "status": "answered"
}

Якщо чіткості завдання недостатньо, контекст стає наступним підозрюваним. Користувач може запитати, хто може затвердити виняток, а поточний уривок може сказати «incident command», не визначаючи цю роль. Відповідь нижче може бути загалом правильною, але неповною, тому що вона цитує фразу про виняток, не визначаючи, хто належить до команди реагування на інциденти. У цьому випадку зміна повинна покращити пошук так, щоб розділ визначення політики був включений разом із розділом перезапуску. Завдання вже чітке; відсутній елемент — це інформація.

{
  "answer": "Incident command can approve an exception.",
  "quote": "unless incident command approves an exception",
  "status": "answered"
}

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

{
  "status": "answered | not_enough_information",
  "decision": "yes | no | conditional | unknown",
  "answer": "string",
  "supporting_quote": "string",
  "review_note": "string"
}

Валідація стає корисною, коли форма виводу стабільна. Валідація може перевіряти, що status і decision є дозволеними значеннями, що supporting_quote присутня, коли статус — answered, що відповідь не стверджує впевненість, коли статус — not_enough_information, що цитата з’являється в наданому контексті та що вивід є придатним для розбору JSON. Валідація виявляє зламані виводи до того, як людина їм довіриться, і допомагає відділити відмови форматування від відмов міркування.

Лише після того, як завдання, контекст, форма та валідація є обґрунтованими, вибір моделі повинен стати головним важелем. Сильніша модель може впоратися зі складнішим міркуванням, менша модель може бути дешевшою та достатньою, модель з більшим контекстом може підтримувати довші документи, а модель із сильнішою поведінкою структурованого виводу може зменшити відмови розбору. Суть не в тому, щоб «ніколи не змінювати моделі». Суть у тому, що зміни моделей дорого інтерпретувати, тому що вони можуть покращити одну поведінку, змінюючи інші.

Спостережувана відмова	Перший підозрюваний	Краща перша зміна	Чому
Відповідь порушує бізнес-пріоритет	Чіткість завдання	Додати явне правило пріоритету	Модель не може вивести приватну політику
Відповідь не містить необхідного факту	Контекст	Отримати або надати відсутнє джерело	Модель не може цитувати відсутню інформацію
Відповідь правильна, але її важко перевірити	Форма виводу	Використати стабільну схему	Перевірка потребує передбачуваних полів
Відповідь має невалідний JSON	Валідація та схема	Валідувати та повторити або зазнати безпечної відмови	Зламана структура блокує автоматизацію
Відповідь потребує складного судження після інших виправлень	Вибір моделі	Порівняти моделі на тому самому наборі для оцінювання	Здатність тепер може бути обмеженням

Який підхід ви обрали б тут і чому: асистент із запитань і відповідей щодо документів каже, що підрядники можуть отримувати доступ до staging, але отримана політика каже, що підрядники можуть отримувати доступ до staging лише після затвердження менеджера та тренінгу з безпеки. Добра перша зміна — це чіткість завдання: вимагати, щоб відповідь зберігала умови та цитувала точне речення, яке містить умову. Добра друга зміна — це форма виводу: додати окремі поля для decision, conditions і supporting_quote. Зміна моделі не є першим кроком, тому що наданий контекст уже містить відповідь.

Побудуйте готовий до запуску інструмент оцінювання

Оцінювання v1 може починатися як невеликий скрипт, тому що перша мета — повторюваність, а не платформна витонченість. Вам потрібні повторювані вхідні дані, видимі очікування, послідовне оцінювання та звичка перевіряти відмови. Наведений нижче інструмент не викликає ШІ-модель; він симулює механіку оцінювання, використовуючи збережені виводи. Це робить його готовим до запуску будь-де та утримує увагу на формі циклу перед тим, як ви додасте інтеграцію з провайдером.

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

{"id":"ticket-001","expected_queue":"billing","required_evidence":"charged twice","actual":{"queue":"billing","supporting_quote":"I was charged twice this month."}}
{"id":"ticket-002","expected_queue":"account_access","required_evidence":"login page still rejects it","actual":{"queue":"account_access","supporting_quote":"the login page still rejects it"}}
{"id":"ticket-003","expected_queue":"needs_human_review","required_evidence":"missing account ID","actual":{"queue":"billing","supporting_quote":"customer wants a refund"}}

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

import json
from pathlib import Path


def evidence_matches(required: str, quote: str) -> bool:
    return required.lower() in quote.lower()


def score_case(case: dict) -> dict:
    actual = case["actual"]
    queue_ok = actual.get("queue") == case["expected_queue"]
    quote_ok = evidence_matches(
        case["required_evidence"],
        actual.get("supporting_quote", ""),
    )
    passed = queue_ok and quote_ok
    return {
        "id": case["id"],
        "passed": passed,
        "queue_ok": queue_ok,
        "quote_ok": quote_ok,
        "expected_queue": case["expected_queue"],
        "actual_queue": actual.get("queue"),
    }


def main() -> None:
    path = Path("eval_cases.jsonl")
    cases = [json.loads(line) for line in path.read_text().splitlines() if line.strip()]
    results = [score_case(case) for case in cases]
    passed = sum(1 for result in results if result["passed"])

    for result in results:
        status = "PASS" if result["passed"] else "FAIL"
        print(
            f"{status} {result['id']} "
            f"queue_ok={result['queue_ok']} "
            f"quote_ok={result['quote_ok']} "
            f"expected={result['expected_queue']} "
            f"actual={result['actual_queue']}"
        )

    print(f"\npassed={passed} total={len(results)}")


if __name__ == "__main__":
    main()

Запустіть його з теки, яка містить два файли. Вивід повинен показати два проходження та одну відмову. Ця відмова корисна, тому що вона каже команді, що ticket-003 було спрямовано до білінгу, коли очікуваний вивід був needs_human_review, і вона також каже команді, що цитата не містила необхідних доказів.

.venv/bin/python run_eval.py

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

Нотатки оцінювання є частиною артефакту, а не запізнілою думкою. Слабка нотатка каже «погана відповідь», що нічого не навчає. Краща нотатка каже: «Спрямувала випадок повернення до білінгу, хоча ідентифікатор облікового запису був відсутній; очікувалося needs_human_review, тому що робочий процес не може обробити повернення без пошуку облікового запису». Ця нотатка називає патерн відмови, очікувану межу та причину робочого процесу, що стоїть за очікуванням. З часом нотатки стають картою продуктових рішень і залишкового ризику.

Старша практика: окремі ворота якості

ШІ-функція v1 часто потребує більше ніж одних воріт, тому що різні ворота виявляють різні відмови. Валідація схеми може відхилити спотворений вивід, але не може судити, чи правильна бізнес-політика. Людська перевірка може виявити відмови судження, але рецензенти не повинні витрачати час на виправлення невалідного JSON. Регресійні приклади виявляють дрейф відносно відомих випадків, але вони не доводять кожну властивість безпеки. Багатошарові ворота роблять відмову видимою раніше та зменшують шанс, що один перевантажений крок перевірки пропустить передбачувану проблему.

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

Перевіряйте відмови як практик

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

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

Тип відмови	Симптом	Звичайний перший крок
Неоднозначність завдання	вивід обирає розумну, але неправильну інтерпретацію	уточнити завдання або пріоритет
Відсутній контекст	вивід вгадує або дає загальні поради	покращити пошук або наданий контекст
Погані докази	висновок виводу правильний, але цитата слабка	посилити правила доказів
Дрейф форми	поля відсутні або непослідовні	визначити схему та валідацію
Небезпечна дія	вивід перевищує дозволені повноваження	додати межу та правило перевірки
Галюцинована деталь	вивід вигадує факти	вимагати обґрунтованості та безпечної відмови
Надмірна відмова	вивід каже «невідомо», коли докази існують	покращити вибір контексту або баланс інструкцій
Регресія	старий успішний випадок зазнає невдачі після зміни	ізолювати змінену змінну

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

If the user says "charged twice and cannot access invoice", choose billing.

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

If a ticket includes both a billing problem and another problem, choose billing first.

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

Дата	Зміна	Покращилося	Погіршилося	Рішення
2026-04-25	Додано правило пріоритету «спочатку білінг»	змішаний випадок білінгу/доступу	жодного в малому наборі	зберегти та розширити випадки зі змішаними проблемами
2026-04-25	Вимога, щоб цитата містила докази черги	випадок слабкої цитати	один випадок облікового запису тепер надмірно відмовляє	переглянути інструкцію щодо доказів

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

If the ticket mentions "April invoice", route to billing.

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

If the ticket reports a charge, refund, invoice amount, payment failure, or duplicate billing, route to billing unless required account information is missing.

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

Що насправді означає випуск v1

Добрий v1 — корисний, обмежений, зрозумілий і придатний для перевірки. Поганий v1 — відкритий, важкий для оцінювання, надто довірений і значно важчий для налагодження, коли користувачі вже залежать від нього. Випуск v1 не означає випуск іграшки. Це означає випуск найменшої версії, яка створює реальну цінність усередині контрольованої межі. Для ШІ-функцій межа є частиною продукту, а не тимчасовим збентеженням.

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

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

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

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

Межа	Рішення v1
Користувачі	лише внутрішня команда сортування
Вхідні дані	нові тікети підтримки англійською мовою з темою та тілом
Виводи	запропонована черга, підтверджувальна цитата, вторинна проблема
Повноваження	лише пропозиція; без автоматичної маршрутизації
Ескалація	`needs_human_review` для відсутніх або суперечливих доказів
Моніторинг	щотижневий перегляд невдалих і перевизначених пропозицій

Сценарій вправи: ваша команда хоче, щоб ШІ-система читала тікет, визначала суму відшкодування та здійснювала повернення коштів, але у вас малий набір для оцінювання і немає продакшен-історії. Безпечніший v1 читає тікет, визначає, чи може повернення бути релевантним, видобуває запитану суму та докази і готує примітку для перевірки для спеціаліста з білінгу. Ця версія все ще допомагає, тому що зменшує роботу з читання та підсумовування, але вона не переказує кошти. Вона залишає повноваження за людиною, що є тим, як має відчуватися ранній випуск ШІ: корисним, обмеженим і придатним для перевірки.

Робота циклу після запуску

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

Відстежуйте сигнали, які відповідають роботі v1. Для маршрутизатора тікетів корисні сигнали включають відсоток пропозицій, прийнятих людьми, відсоток змінених людьми, топ-пари плутанини черг, приклади, позначені needs_human_review, частоту відмов валідації, частоту непідтверджених цитат, зекономлений під час сортування час і коментарі рецензентів. Уникайте марнославних метрик, таких як загальна кількість викликів ШІ, середня довжина відповіді чи оплески демо, тому що вони не доводять надійність або цінність. Відстежуйте поведінку, яка відображає роботу.

Людські перевизначення не є ганебними; це продуктові сигнали. Коли власник сортування змінює account_access на billing, запитайте, чи правило пріоритету було відсутнє, чи докази були присутні, але проігноровані, чи тікет був неоднозначним, чи очікувана мітка була неправильною, чи таксономія міток була занадто грубою. Кожна відповідь веде до іншої зміни. Не ставтеся до всіх перевизначень як до помилок моделі, тому що деякі є помилками таксономії продукту, помилками робочого процесу або невирішеними рішеннями щодо політики.

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

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

Патерни й антипатерни

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

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

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

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

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

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

Рамка рішень

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

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

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

Чи знали ви?

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

Типові помилки

Помилка	Чому вона трапляється	Як її виправити
налаштування без прикладів	прогрес здається швидким, тому що кожна правка промпту виробляє нову прозу	спочатку визначте малий набір для оцінювання та зафіксуйте очікувану поведінку перед зміною промптів
зміна забагато речей одночасно	команда хоче швидкого видимого покращення та об’єднує зміни промпту, контексту, схеми та моделі	змінюйте одну змінну за ітерацію та перезапускайте цільові плюс регресійні приклади
спочатку випуск широкої автономії	демо здається достатньо здатним, щоб виправдати більші повноваження, ніж доводить набір для оцінювання	спочатку випустіть обмежену корисність і тримайте ризиковані дії за людською перевіркою
ставлення до демо як до доказів	відрепетирувані приклади легше запам’ятати та вони більш переконливі на зустрічах	тестуйте репрезентативні випадки, які включають звичайні, неоднозначні, ризиковані приклади та приклади відмови
виправлення одного прикладу правилами, специфічними для фрази	патчі промптів дешеві та можуть швидко зробити так, щоб один випадок невдачі пройшов	пишіть правила для класу відмови та перевіряйте, що пов’язані випадки все ще проходять
перемикання моделей перед діагностуванням відмов	сильніша модель може покращити поверхневий вивід і приховати справжню причину	дотримуйтеся порядку пріоритетів перед змінами моделей і порівнюйте моделі лише на тому самому наборі для оцінювання
ігнорування випадків відмови	розробники фокусуються на успішних відповідях і забувають, що відсутність доказів є поширеною	включайте приклади, де ескалація, `unknown` або `not enough information` є правильною поведінкою

Тест

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

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

2. Класифікатор тікетів підтримки спрямовує «charged twice and cannot access invoice» до `account_access`, але ваше бізнес-правило каже, що проблеми білінгу мають пріоритет. Яка перша зміна найкраще відповідає правилу однієї змінної?

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

3. Система запитань і відповідей щодо документів відповідає з правильного розділу політики, але не включає цитату. Рецензенти не можуть сказати, чи відповідь обґрунтована. Що слід змінити перед зміною моделей?

Покращте інструкцію щодо доказів і форму виводу перед зміною моделей. Вимагайте поля, такі як answer, supporting_quote і status, потім додайте валідацію, що цитата з’являється в наданому контексті. Проблема — у придатності для перевірки та обґрунтованості, а не обов’язково в здатності моделі. Зміна моделі може виробити приємнішу прозу, але сама по собі вона не створить аудиторський слід, якого потребують рецензенти.

4. Ваша результат оцінювання покращується після того, як ви змінюєте промпт, перемикаєте моделі, додаєте пошук і переписуєте схему в одному запуску. Чому цьому результату важко довіряти?

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

5. Асистент із повернення коштів правильно визначає намір повернення, але ідентифікатор облікового запису клієнта відсутній. Система все одно пропонує видати повернення. Якою має бути очікувана поведінка v1?

Система повинна ескалювати або позначити вивід як не готовий до дії, тому що необхідна інформація про обліковий запис відсутня. Сильна поведінка v1 видобула б запит на повернення, позначила б account_id як unknown і спрямувала б випадок на людську перевірку. Вона не повинна виконувати або рекомендувати незворотну дію, коли необхідна інформація відсутня. Ця відповідь оцінює, чи є функція обмеженою, придатною для перевірки та достатньо безпечною для випуску.

6. Команда хоче розширити внутрішню функцію пропозицій тікетів до автоматичної маршрутизації для всіх черг. Їхній поточний набір для оцінювання охоплює лише одну чергу та жменьку прикладів. Що ви повинні рекомендувати?

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

7. Модель дає плавну відповідь, яка каже, що підрядники можуть отримувати доступ до staging. Надана політика каже, що підрядники можуть отримувати доступ до staging лише після затвердження менеджера та тренінгу з безпеки. Який найкращий діагноз?

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

Практична вправа

Ви спроєктуєте та проітеруєте план оцінювання v1 для однієї ШІ-функції. Оберіть функцію, достатньо малу для тестування, таку як маршрутизація тікетів підтримки, видобування пунктів дій із зустрічей, внутрішні запитання та відповіді щодо документів, підсумовування приміток до релізу, створення чернеток оновлень інцидентів або класифікація лідів продажів. Уникайте широких ідей, таких як «ШІ-агент підтримки» або «ШІ-асистент операцій», тому що ці мітки приховують забагато робіт. Ваша мета — перетворити розмиту функцію на обмежений v1 із доказами.

Крок 1: Напишіть контракт v1

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

Критерії успіху:

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

Приклад розв'язання

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

Крок 2: Створіть п’ять прикладів для оцінювання

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

Критерії успіху:

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

Приклад розв'язання

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

Крок 3: Запустіть ручне оцінювання

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

Критерії успіху:

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

Приклад розв'язання

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

Крок 4: Виконайте одну ітерацію

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

Критерії успіху:

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

Приклад розв'язання

Ітерація додає лише це правило: «Якщо тікет включає як проблему білінгу, так і іншу проблему, оберіть спочатку білінг, якщо тільки необхідна інформація про обліковий запис не відсутня». Цільовий змішаний випадок змінюється з account_access на billing, тоді як чиста відмова входу залишається account_access, а випадок повернення з відсутнім обліковим записом залишається needs_human_review. Рішення — зберегти правило та додати більше прикладів зі змішаними проблемами перед розширенням обсягу.

Крок 5: Оцініть, чи можна випускати v1

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

Критерії успіху:

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

Приклад розв'язання

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

Джерела

Наступний модуль

Звідси продовжуйте до: