Регресія промптів

Що означає регресія, коли відповідь оцінюють

У звичайному ПЗ регресія однозначна: тест, що проходив, тепер падає. Тут її треба визначити, бо кейс може дати 0,83 сьогодні й 0,79 завтра без жодних змін. Робоче визначення — покейсне й проти порога: кейс регресував, коли на базовій лінії він проходив власний критерій, а тепер не проходить, — і виміряно це на достатній кількості запусків, щоб семплінг не пояснював різницю.

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

Порівняння чесне, лише коли решта закріплена

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

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

Як відрізнити справжню зміну від шуму семплінгу

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

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

Ворота: що запускається, що блокує, скільки коштує

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

• Що блокує

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

• Що попереджає

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

• Що записується

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

• Скільки це коштує

  Девʼяносто кейсів по три запуски — це кілька хвилин і пара доларів на пулреквест. Закладайте це явно, інакше хтось тихо це вимкне.

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

Антипатерни, які варто назвати

• Редагувати продакшн-промпт в адмінці — це розгортання без диффу, без рев’ю і без шляху назад.
• Судити про зміну за сукупною оцінкою — саме та статистика, що ховає зламані кейси.
• Перезапускати лише ті результати, що не подобаються: оцінювання стає відбором, а промпт — підігнаним під щасливі seed’и.
• Прив’язуватися до рухомого аліаса: розгорнута система змінюється за графіком провайдера, а не за вашим.
• Не зберігати артефакт базової лінії: «раніше працювало» стає спогадом, а не файлом, який можна відкрити.

Коли це застосовувати

Пов’язані сторінки

• QAОцінювання AIОцінювання AI — це те, як ви дізнаєтесь, чи достатньо добрий вивід моделі, щоб його випускати. Набір оцінок — це фіксована збірка вводів із способом судити кожен вивід, що запускається на кожну зміну й звітується частками. Зібрати такий набір неважко. Важко зібрати той, що каже правду, бо все вирішують два рішення: які кейси в ньому і як оцінюється кожна відповідь. Ця сторінка — про ці два рішення: драбина оцінювачів від безкоштовного точного збігу до дорогої людини, коли модель може судити модель і як читати число, не обманюючи себе.
• QAТестування LLM-продуктівТестування LLM-продукту — це тестування фічі, яка може двічі відповісти на те саме питання по-різному, а кожна ваша практика тестування припускає, що той самий ввід дає той самий вивід. LLM-фіча це ламає, і звична реакція — вирішити, що її не можна тестувати. Це неправда, і дорога неправда. Більшість важливого в LLM-фічі досі перевіряється точно, та частина, що ні, стає вимірюванням проти порога, а робота тестувальника зміщується від написання кроків до визначення, якою є добра відповідь. Ця сторінка — про це зміщення і про те, що робити в понеділок після нього.
• QAРегресійне тестуванняРегресійне тестування — це практика швидко помічати регресію, тобто коли те, що працювало, перестає працювати, а ніхто не збирався його чіпати. Набір, який вона породжує, найкраще розуміти як памʼять організації: запис усього, чого систему вже навчили, у формі, яку можна відтворити. Складне тут не в написанні кейсів. Складне — вирішити, що заслуговує на постійне місце, що запускати, коли весь набір надто повільний, і що робити з кейсом, який падає без причини.