Проверка, която зависи от дисциплина, не работи
Правилото „преди промяна пускай златния набор“ важи, докато има време. В деня, в който бърза поправка трябва да излезе за десет минути, правилото се нарушава — и точно тогава става проблемът.
Непрекъсната интеграция (CI)
Автоматично изпълнение на проверки при всяка промяна в хранилището.
Разликата
Ръчната проверка се пропуска. Автоматичната спира промяната.
Три нива на проверки
| Ниво | Какво проверява | Цена | Кога |
|---|---|---|---|
| Бързи тестове | логика с фалшив модел, схеми, лимити | секунди, безплатно | при всяка промяна |
| Проверка на промптовете | съществуват ли файловете, има ли задължителни части | секунди, безплатно | при всяка промяна |
| Златен набор | поведението с истинския модел | минути, пари | при промяна на промпт или модел |
| Проверка на извличането | recall@k върху набора от заявки | секунди, безплатно (локален модел) | при промяна в данните или в търсенето |
Разделянето е важно, защото скъпите проверки не бива да се пускат при всяка запетая в README.
Как изглежда на практика
.github/workflows/proverki.yml
при всяка промяна:
- инсталирай зависимостите
- пусни бързите тестове (фалшив модел)
- провери промптовете (наличие и задължителни части)
- ако са променени prompts/** или модел:
пусни златния набор с ключа от тайните на хранилището
сравни с базовия резултат
ако е под прага — провали проверката- Ключът стои в тайните на хранилището, не в кода на работния процес.
- Базовият резултат се пази във файл в хранилището и се обновява съзнателно.
- Провалът блокира сливането, а не изпраща имейл, който никой не чете.
Праг и разсейване
Проблемът
Един и същ набор дава 18, 19 и 18 от 20 при три пускания. Праг „поне 19“ ще проваля промени без причина; праг „поне 15“ няма да хване влошаване.
Решението
- Пуснете набора 5 пъти без промени и вижте разсейването.
- Задайте праг под най-лошия резултат, но над очакваното влошаване.
- Ако разсейването е голямо, направете проверките по-точни (ключова стойност вместо преценка).
- Пазете историята — тенденцията надолу е по-важна от отделното число.
Мигащи проверки
Проверка, която веднъж минава и веднъж не, без причина, е по-лоша от липсваща — хората свикват да я пренебрегват. Или я направете стабилна, или я извадете от блокиращите.
Какво още може да се проверява
- Дали промптът не е надхвърлил приемлива дължина (цена на всяка заявка).
- Дали всички използвани версии на промпт съществуват като файлове.
- Дали има таймаут и лимит на всяко извикване (проверка по кода).
- Дали ключове не са попаднали в хранилището — отделен инструмент за търсене на тайни.
Последното е задължително
Автоматичната проверка за случайно комитнати ключове спасява повече проекти от всяка друга проверка в този списък.