Slayer benchmarks

Harness ewaluacyjny projektu Slayer (otwarty polski LLM, baza Qwen3.5-27B). Jedno miejsce prawdy o tym, czym i jak mierzymy model: skrypty, karty benchmarków i zasady czystości. Karty służą do debugowania wyników i podejmowania decyzji treningowych (SFT / CPT / GRPO / nic).

Wyniki (JSON-y) żyją w głównym repo Slayera w results/; tu trzymamy kod i dokumentację.

Mapa benchmarków

Pełna mapa kompetencja → benchmark → metoda (gate'y v2): docs/GATES.md. Taksonomia i plan zadań ewaluacyjnych: docs/TASKS_BENCHMARKS.md.

Zasady czystości (bench purity)

1. Tylko agregaty. Patrzymy na accuracy per kategoria / domena / rok. Nie oglądamy pojedynczych itemów benchmarku i nie piszemy na ich podstawie danych treningowych.
2. Eval-only znaczy eval-only. Itemy benchmarków nie wchodzą do SFT/CPT nawet jako "seed". Pliki benchmarków są wejściem deduplikacji (--decon-files) w pipeline danych.
3. Stały n i seed. Porównania między modelami tylko przy identycznej próbce, seedzie i backendzie. Skrypty są idempotentne (skip, jeśli wynik dla (bench, seed) istnieje).
4. Matched decoding. Klasyfikacja/MCQ: greedy albo likelihood, ta sama temperatura dla wszystkich modeli. Mismatch temperatur unieważnia porównanie (lekcja: baseline KLEJ Bielik@0.2 vs Qwen@0.7).
5. Likelihood ≠ generacja litery. To dwie różne metryki tego samego datasetu; nigdy nie porównujemy wyniku likelihood jednego modelu z wynikiem generatywnym drugiego.
6. Δ vs base, nie tylko absolut. Główny odczyt po treningu to zmiana względem bazy (sygnał zapominania); Bielik-11B-v3 to zewnętrzny punkt odniesienia.

Lekcja v2: kontaminacja train-splitów

"Zwycięstwo" v2 na KLEJ okazało się artefaktem trenowania na train splitach tych samych zadań (belebele +0 pp tam, gdzie nie było train splitu, vs psc +26.5 tam, gdzie był). Wniosek wpisany w karty: chwalimy się wyłącznie wynikami held-out (linia v3, claim 5-shot), a każdy wynik na zadaniu, którego train split był w miksie, oznaczamy jako trenowany.

Jak uruchomić

Większość skryptów: python3 scripts/<skrypt> --help albo docstring na górze pliku. Dwa backendy:

• ollama (lokalnie, GGUF): bench_mcq.py, bench_poquad.py, bench_flores.py, bench_gsm8k.py
• HF transformers (pod/GPU, opcjonalnie --adapter LoRA): bench_llmzszl_likelihood.py, bench_llmzszl_generate.py, klej_eval.py, humaneval_hf.py, eval_hf_mcq.py, eval_style.py

Przykład pełnego gate'u po treningu:

# LLMzSzŁ likelihood, apples-to-apples z baseline n=400 seed=42
python3 scripts/bench_llmzszl_likelihood.py --model Qwen/Qwen3.5-27B --adapter <ckpt> --n 400 --seed 42

# KLEJ 10 zadań, test split, greedy
python3 scripts/klej_eval.py --adapter <ckpt> --n 300 --seed 42

# regresja EN + kod
python3 scripts/bench_gsm8k.py 600 42
python3 scripts/humaneval_hf.py --model Qwen/Qwen3.5-27B --adapter <ckpt>

Macierz decyzyjna (wynik → akcja treningowa)

• Open PL słabe, MCQ/EN mocne: SFT na zadaniach w stylu Open PL (train splity, nigdy test).
• LLMzSzŁ słabe w kategoriach liczbowych/jednostkach/zawodowych: syntetyczne MCQ z weryfikatorem + GRPO/RLVR.
• PoQuAD słabe na pytaniach bez odpowiedzi: SFT na answerability.
• FLORES słabe: SFT tłumaczeniowy tylko, jeśli tłumaczenie jest priorytetem.
• Regresja EN spada po tuningu: zmniejszyć wagę zadań PL albo dodać replay.
• CPT tylko, gdy perplexity i szeroki zestaw zadań pokazują ogólną słabość językową PL.

Żaden dataset nie jest uzasadniony przez "więcej polskich danych" samo w sobie; każdy musi linkować do konkretnego failure mode z benchmarku.