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