V4 plan · feedback open · po autopsji v3

Najpierw harness, potem trening

V3 podniósł LLMzSzŁ, ale obniżył CDSC-E z 87.0 do 64.5 na poprawionym promptcie. To jest klasyczny przypadek, gdzie pojedynczy benchmark docelowy wygląda lepiej, a model traci kalibrację logiczną. V4 ma zamknąć tę lukę: każdy checkpoint przechodzi bramki rozkładu etykiet, neutral recall i parser error zanim w ogóle mówimy o release.

Case: co poszło źle

CDSC-E n=200 seed 42 · prompt fixed · base vs v3
regresjanie szum metryki

V3 nie popsuł wszystkich etykiet po równo. Model stał się zbyt stanowczy: zamiast wybierać neutralna , przesuwał neutralne pary w sprzeczność i częściowo w wynikanie . Dlatego średnia KLEJ może wyglądać niewinnie, a konkretna umiejętność logiczna jest realnie naruszona.

LLMzSzŁ+3.3 pp63.5 → 66.8
CDSC-E-22.5 pp87.0 → 64.5
neutral recall55.1%base: 89.8%
pred distributionv3
neutralna86
wynikanie50
sprzeczność64

Gold miał 147/200 neutralnych par. Base przewidział neutralność 143 razy, v3 tylko 86 razy. Taki drift musi blokować release nawet wtedy, gdy target score rośnie.

Plan V4

kolejność działań
01

Autopsja przed treningiem

Każdy spadek rozbijamy na gold distribution, base pred distribution, candidate pred distribution, confusion matrix i parser error. Bez tej tabeli nie ma diagnozy.

02

Likelihood eval dla klasyfikacji

Generacja mierzy też styl i gadatliwość. Dla KLEJ classification dokładamy scoring etykiet logprobami: model wybiera spośród zamkniętej listy labeli.

03

Adapter scale sweep bez retrainingu

Najpierw sprawdzamy λ = 0.0, 0.1, 0.2, 0.3, 0.5, 0.7, 1.0. Jeśli mniejsza skala odzyskuje CDSC-E i trzyma target, można wypuścić calibrated adapter.

04

Dane naprawcze dopiero po diagnozie

CDSC-like NLI ma mieć realny prior: 70-80% neutral, 15-25% entailment, 5-10% contradiction, z dużym udziałem hard-neutral. Zero przykładów testowych.

05

Replay + KL do bazy

V4 mix: target data, general replay, task-preservation replay (typy zadań na własnych/zdekontaminowanych danych, nie na splitach benchmarków) i NLI calibration. Na preservation set testujemy KL-to-base, żeby adapter nie przesuwał całej polityki decyzji.

06

Wybór przez Pareto

Nie wybieramy najlepszego checkpointa po jednym target score. Warunek: target w górę, CDSC-E blisko bazy, neutral pred blisko gold/base, parser error 0.

Nowe bramki

wdrożone do harnessu
CDSC-E score dropfail jeśli kandydat spada względem bazy o więcej niż 3 pp.
Neutral prediction driftfail jeśli udział predykcji neutralnych odpływa od bazy o więcej niż 5 pp.
Neutral recallfail jeśli recall klasy neutralnej spada o więcej niż 5 pp.
Parser errorfail jeśli odpowiedzi nie da się sparsować do oczekiwanej etykiety.
Macro nie wystarczaKLEJ macro jest raportowane, ale nie może przykryć dużej regresji pojedynczego taska.
Audit raw błędówopcjonalny prywatny JSONL z raw outputami błędów do szybkiej ręcznej autopsji.
python3 klej_eval.py --tasks cdsc_e --n 200 --seed 42 --mode likelihood --out results/base_cdsc.json python3 klej_eval.py --adapter "$CKPT" --tasks cdsc_e --n 200 --seed 42 --mode likelihood --out results/candidate_cdsc.json python3 regression_gate.py --base results/base_cdsc.json --candidate results/candidate_cdsc.json

Reguły V4

monotoniczność tylko tam, gdzie ma sens
R1

Nie wymagamy wzrostu wszystkiego

Wszystkie benchmarki monotonicznie w górę to zbyt ostra reguła. Małe próbki, judge-based evale i prompt-sensitive zadania mają szum, więc decyzja idzie po progach i trendach, nie po pojedynczym zielonym/czerwonym polu.

R2

Target runu musi rosnąć

Jeśli run jest pod LLMzSzŁ, LLMzSzŁ ma iść w górę. Jeśli run jest pod natywność polszczyzny, PolNative ma iść w górę. Bez wyraźnego zysku na celu nie ma sensu akceptować ryzyka regresji.

R3

Krytyczne gate’y nie mogą spaść znacząco

CDSC-E/NLI, KLEJ critical tasks, parser error, MMLU/ARC/GSM8K i podstawowe EN retention mają tolerancję spadku, ale nie mogą zostać rozwalone. Parser error ma zostać 0.

R4

Noisy benchmarki wymagają rerun albo CI

PolNative judge, EQ-Bench, małe sample i zadania z otwartym sędzią oceniamy przez powtórki, przedziały ufności albo większą próbkę release. Pojedynczy spadek o 1-2 pp nie musi być realny.

R5

Release wybiera Pareto-front

Nie wybieramy checkpointa z najlepszym jednym score. Wybieramy taki, który daje zysk na celu i nie przekracza progów regresji. +3 pp LLMzSzŁ przy -22 pp CDSC-E odpada; +10 pp PolNative przy -0.5 pp MMLU może przejść.

V4 promotion policy: target benchmark must improve critical regression gates max -1..-3 pp, depending on task parser_error_rate must equal 0 noisy/judge benchmarks rerun or larger sample before blocking final decision Pareto, not single metric Example: OK: PolNative +10 pp, MMLU -0.5 pp, CDSC-E stable FAIL: LLMzSzŁ +3 pp, CDSC-E -22 pp, neutral recall collapsed

Czy mamy dane

co realnie mierzy improvement
Gotowe jako twardy gateLLMzSzŁ, KLEJ/CDSC-E, Belebele PL, PolNative, PES, PoQuAD, FLORES PL↔EN, Belebele EN, ARC-C, MMLU, GSM8K. Tu improvement/regresję da się mierzyć już teraz, przy stałym seedzie i protokole.
Publiczne, do spięcia w runnerHellaSwag, TruthfulQA MC2, WinoGrande, PolQA, INCLUDE-base-44, szersze Belebele multilingual, szersze FLORES. Dataset istnieje, ale trzeba jeszcze wyrównać harness i metrykę.
Zamknięte albo leaderboard-onlyCPTUB, Polish EQ-Bench i częściowo PLCC. Tego nie wolno udawać jako powtarzalnego gate’u, jeśli nie mamy test setu. Możemy użyć jako zewnętrzny release check albo zbudować własny izomorficzny dev set.
Do treningu nie wchodzą itemy benchmarkówLLMzSzŁ, PES, PoQuAD, PolNative oraz wszystkie splity KLEJ — train, dev i test — są wyłącznie decon/eval. Nawet oficjalne train splity benchmarków nie są źródłem treningu; replay i task-preservation robimy na własnych/zdekontaminowanych danych. Improvement ma pochodzić z umiejętności, nie z widzenia pytań.
Dev set potrzebny do iteracjiDla PolNative/PLCC/CPTUB-like robimy osobny dev set podobny typem, ale rozłączny. Realny benchmark odpalamy rzadko: po zamrożeniu kandydata.
Claim tylko tam, gdzie jest protokółJeśli dataset jest zamknięty albo protokół niestandardowy, piszemy “internal gate” albo “proxy”, nie “pobiliśmy benchmark”.

Systematyczny benchmark

jeden runner dla kolejnych checkpointów
SMOKE

Po każdym sensownym checkpointcie

Mała próbka KLEJ/CDSC-E + LLMzSzŁ. Łapie awarie promptu, parsera, label drift i oczywisty spadek targetu.

GATE

Przed promocją checkpointa

KLEJ generation i likelihood, rozkłady etykiet, confusion matrix, parser error, neutral recall oraz LLMzSzŁ n=400.

REL

Przed publicznym claimem

Większe próbki, ostrzejsze progi i raport PASS/FAIL. Release nie przechodzi, jeśli pojedyncza umiejętność odpada mimo dobrego target score.

STYLE

PolNative jako gate natywności

V4 musi przejść PolNative: fleksja, frazeologia, literatura, realia, rejestr, EQ, naturalność i kalibracja. To osobny gate dla claimu “lepsza polszczyzna”, komplementarny do PLCC.

cd /home/ubuntu/slayer-train python3 systematic_benchmark.py --adapter ~/slayer-out/qwen-v4-dora/checkpoint-240 --preset checkpoint # szybki podgląd bez odpalania modeli: python3 systematic_benchmark.py --adapter ~/slayer-out/qwen-v4-dora/checkpoint-240 --preset smoke --dry-run # style/native release gate: python3 bench/polnative_eval.py --from-file slayer-v4=/tmp/answers_slayer_v4.jsonl python3 bench/polnative_report.py