Projekt F: finjustera och utvärdera en språkmodell

Projekt F: ta en öppen modell, anpassa den till en uppgift du bryr dig om, och visa med siffror att den blev bättre — utan att bli sämre på annat.

Leverabler:

Del	Krav
Dataset	≥ 500 par, rensat (dubbletter, evalläckage), balanserat, dokumenterat
Eval	≥ 50 fall som mäter måluppgiften, byggda före träningen
Hållbarhetssvit	≥ 50 fall för allmänna förmågor som ska bevaras
Baslinjer	basmodellen som den är, plus en promptad variant (few-shot)
Träning	LoRA/QLoRA, konfiguration loggad, ≥ 2 frön
Rapport	före/efter på båda sviterna, med spridning; begränsningar

Kravet som gör projektet ärligt: evalsviten byggs innan träningen. Annars anpassas den omedvetet till det modellen råkade bli bra på.

Resultattabellen du ska producera:

Variant	Måleval	Hållbarhet	Tränbara par.	GPU-tid
bas, zero-shot	0,41 ± 0,00	0,78 ± 0,00	—	—
bas, few-shot	0,58 ± 0,01	0,78 ± 0,00	—	—
LoRA r=8	0,79 ± 0,02	0,75 ± 0,01	15 M	25 min
LoRA r=32	0,82 ± 0,02	0,71 ± 0,02	61 M	31 min

Läs den: r=32 ger +3 pe på målet men −4 pe på hållbarheten. Är det rätt val? Det beror på användningen — och det är det beslutet som är projektets poäng, inte den högsta siffran.

Vanliga misstag:

1. Few-shot-baslinjen hoppas över — och då vet ingen om finjusteringen ens behövdes.
2. Bara ett frö.
3. Hållbarhetssviten saknas.
4. Chat-mallen skiljer sig mellan träning och utvärdering (tyst kvalitetsförlust).
5. Evalfallen skrivna efteråt.

Tidsplan (ca 5 h aktiv tid): 1,5 h dataset · 1 h evalsviter · 1 h träning (svep) · 1 h utvärdering · 0,5 h rapport.