По итогам разбора собственной работы. jellybit-review-code не запускался нигде: charter обещал «проход профиля quick», а quick состоял из стадий 0, 1, 5. Проход, который нельзя запустить, нельзя и откалибровать. Теперь он стадия 1 рядом с review-specs — оба applicative, у обоих критерий записан, различаются источники (дельта-спека и конвенции). review-context.sh больше не выгружает go doc -short по всему модулю: это было 264 строки из 458 при том, что граф зависимостей — единственное, чего агент не восстановит сам, — занимает 21. Публичную поверхность он вытянет go doc по нужному месту. Из calibration.md убрана секция дополнительных метрик: precision, корреляция и стоимость прогона вручную никем не считаются, а набор показателей, который не собирают, изображает измеряемость вместо того, чтобы её давать. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.3 KiB
Калибровка проходов
Без измерения набор проходов растёт монотонно и вырождается в театр: каждый кажется полезным, потому что иногда что-то говорит. Калибровка отвечает на единственный вопрос — ловит ли проход дефект своего класса.
Процедура (инъекция дефекта)
- Взять реальный коммит из истории (
git log --oneline), лучше архивированный change с непустым диффом. - Внести в него один дефект того класса, который проход обязан ловить по
своему charter'у. Дефект должен быть правдоподобным — таким, какой реально
пишет модель, а не карикатурой (
panic("TODO")не считается). - Прогнать только этот проход на подготовленном диффе — три раза, каждый в чистом контексте.
- Зафиксировать: нашёл
n/3, число находок всего, число ложных. - Вердикт:
| Результат | Вердикт | Что делаем |
|---|---|---|
| нашёл 3/3 или 2/3, ложных немного | keep |
ничего |
| нашёл 1/3 или 0/3 | retune |
правим charter — сужаем вход, убираем чек-лист, добавляем оракул |
retune уже был дважды подряд |
drop |
удаляем проход |
| находит, но ложных больше трети от всех находок | retune |
триаж съедает больше, чем экономит проход |
retune не более двух раз подряд. Проход, не находящий дефект своего класса
в 2 из 3 прогонов после двух правок промпта, — это театр. Удалять, а не
бесконечно править формулировки: каждая итерация правки промпта стоит дороже,
чем отсутствие прохода.
Существующий проход не удаляется без замера. Сначала калибровка, потом решение — иначе удаляется то, что работало, а остаётся то, что громче.
Пробы дефектов по проходам
Проба — заготовка инъекции. Список пополняется из журнала проскочивших дефектов: реальный проскочивший дефект — лучшая проба, какая вообще возможна, потому что синтетические смещены в сторону тех, которые уже умеешь придумывать.
| Проход | Класс дефекта для инъекции | Заготовка пробы |
|---|---|---|
jellybit-review-gate |
отсутствующая верификация | убрать тест на изменённую ветку, оставить код рабочим |
jellybit-review-specs |
поведение вне спеки | добавить незаказанный фолбэк-дефолт при пустом ответе LLM |
jellybit-review-rubric |
нарушенное свойство узла | в клиенте внешнего API убрать таймаут/протяжку context |
jellybit-review-reimpl |
форма решения | размазать решение по трём слоям там, где хватало одной функции |
jellybit-review-idiom |
«распространённое» вместо идиоматичного | завести интерфейс с одной реализацией ради мока |
jellybit-review-negative |
отсутствующее | убрать state transition из новой стадии воркера |
jellybit-review-architecture |
второй способ | завести вторую точку генерации id мимо internal/ident |
jellybit-review-adversary |
построенный путь | принять внешний id без ident.Parse до запроса в БД |
jellybit-review-ops |
деградация зависимости | убрать обработку недоступности qBittorrent в фоновом цикле |
jellybit-review-triage |
шум | подать 20 находок, из них 15 вкусовщина и 3 дубля — проверить потолок и дедуп |
Метрик сверх этого не заводим. Precision, корреляция между проходами, стоимость
прогона в токенах — всё это красиво звучит и никем не считается вручную; набор
показателей, который не собирают, создаёт впечатление измеряемости и тем вреден.
Работает ровно один механизм: инъекция дефекта и вердикт. Если корреляция двух
проходов действительно бросается в глаза — это видно по полю Найдено проходом
в триажированных отчётах и без отдельной метрики.
Когда калибровать
- при заведении нового прохода — до включения в профиль по умолчанию;
- при правке charter'а существующего — иначе непонятно, правка помогла или нет;
- при появлении записи в журнале проскочивших дефектов — калибруем тот проход, который должен был поймать;
- планово — нет. Календарная калибровка ради галочки сама превращается в театр.