Урок 4 із 6
Регресії та CI для промптів
7 хв читання
Ти правиш один рядок промпта, щоб пофіксити баг. Спрацювало. Чого ти не бачиш: та сама правка щойно зламала три кейси, які раніше проходили.
Промпти — це код
Промпт — це залежність, на яку спирається поведінка твого продукту, точнісінько як функція. Тож стався до нього так само: клади під контроль версій, рев'ю зміни й — те, що всі пропускають — проганяй оцінювання на кожній зміні. Правка на одне слово може відлунити так, як жодна людина не помітить, читаючи дифф.
Кожна зміна промпта чи моделі — це зміна коду. Якщо її не протестовано, ти релізиш наосліп.
Вбудуй оцінювання в CI
Зроби набір оцінювань перевіркою у своєму пайплайні. Відкриваєш пул-реквест, що чіпає промпт, модель чи ретрив, — і CI проганяє тест-сет та публікує оцінку. Якщо вона падає нижче базової лінії, мердж блокується — так само, як збійний юніт-тест зупиняє поганий коміт. Тихі регресії стають гучними, перш ніж їх зустрінуть користувачі.
Регресія, спіймана в CI, коштує коментаря в код-рев'ю. Та сама регресія, спіймана в проді, коштує клієнта.
Фіксуй версію моделі. «Провайдер оновив модель» — реальне джерело регресій; якщо зафіксувати не можеш, проганяй оцінювання за розкладом, щоб дрейф з'являвся як збійна перевірка, а не як тікет у підтримку.
Суть коротко
- —Версіонуй промпти й рев'ю зміни, як будь-який інший код.
- —Проганяй набір оцінювань на кожній зміні промпта, моделі чи ретриву.
- —Блокуй мердж, коли оцінка падає нижче базової лінії.
- —Фіксуй версію моделі — або став оцінювання за розкладом, щоб ловити дрейф провайдера.
Зміна промпта фіксить баг, який ти ловиш, і демо все ще виглядає нормально. Перед мерджем що робить налаштування «оцінювання в CI»?
Продовжити в застосунку
Пройди весь курс «Оцінювання та надійність» — з відстеженням
Отримай персональний план, прогрес і стріки в застосунку — цей урок і кожен наступний, по порядку.