ki-engineeering/15-fine-tuning-und-distillation.md

Fine-Tuning und Distillation

Pipeline, RAG und Tools sind ausgereizt — oder jemand behauptet das im Steering Committee: „Wir fine-tunen einfach unser Modell, dann brauchen wir kein RAG mehr.“ Sechs Wochen Labeling später ist das Adapter-Modell stilistisch glänzend, faktisch veraltet, und niemand will den Trainingsjob on-call besitzen.

Fine-Tuning (FT) und Distillation sind echte Hebel — und teure Stufen auf der Ladder. Der ehrliche Default in AI Engineering: meistens nicht (noch nicht).

Kern in einem Satz: Steige zu Fine-Tuning/Distillation erst nach messbarem Plateau auf Stufen 1–5 und mit Daten + Eval + Ops-Owner; FT ersetzt weder RAG für Fakten noch AuthZ für Wirkung — und „meistens nicht“ ist eine Architekturentscheidung, kein Motivationsmangel (Ladder-Stufe 6, Kapitel 08).

ADR-Denke: adr-adaptation.md. Model-Lifecycle: Kapitel 24, model-change-checklist.md.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	FT / Distillation …
Spezialbibliothek vs. generisches Framework	Spezialgewichte vs. Prompt/RAG/Tools am Foundation Model
Compiler-Flag / Build-Artefakt	Checkpoint / Adapter als versioniertes Artefakt
A/B und Canary von Binaries	Canary von Modellgewichten + Prompt-Bundle
Trainingsdaten ≈ Fixtures?	Datenpipeline ist Produkt: Qualität, Lizenz, Drift, Löschung
Ops für Batch-Jobs	Training, Eval-Regression, Serving, Rollback — ML-nahe Ops
Cost: Build once	Cost: Data + Train + Serve + kontinuierliche Re-Evals

Die Brücke: FT ist näher an Release Engineering für ein gelerntes Artefakt als an „Prompt in groß“. Wer keine Owner für Daten und Checkpoints hat, baut eine Einwegstraße (T9, T10).

---

Was FT und Distillation hier meinen

Ansatz	Idee	Typische Ziele
Fine-Tuning (SFT, Preference-Methoden, Adapter/LoRA o. Ä.)	Gewichte an Task-/Domänendaten anpassen	Format, Stil, Domänenjargon, Tool-Call-Muster, Policy-Verhalten in Grenzen
Distillation	großes/starkes Modell „lehrt“ kleineres	ähnliche Qualität bei weniger €/Latenz auf engem Task
Weiteres (kurz)	RLHF/analog, domain continue-pretrain	selten Produkt-Default; hohe Kosten/Komplexität

Nicht in diesem Kapitel: Foundation Models von null pretrainen (Stufe 7) — ML-Research/Eng-Track, nicht Feature-Sprint.

Anbieter-APIs und Open-Weight-Serving unterscheiden sich (Stand August 2026) — Prinzipien bleiben: Daten, Eval, Pin, Rollback.

---

Wann FT lohnt (Climb Signals)

Steige nur mit Evidenz, nicht mit Langeweile an Prompt-Iteration:

Signal	Beispiel
Plateau dokumentiert	Golden Set + Online-Metriken: Prompt/RAG/Tools ausgereizt
Stabiler Task, hohes Volumen	gleiches Schema 10M×/Monat — kleine Qualitäts- oder Kostenhebel lohnen
Format-/Stil-Rigidität	Modell bricht Structured Output systematisch trotz Schema/Repair
Latenz/€-Druck	Strong-Tier zu teuer; Distill auf Smaller mit Paritäts-Eval
Domänensprache	Fachjargon, interne Labels — nicht die Fakten-DB
Daten moat	kuratierte, lizenzklare Interaktionsdaten, die Prompt nicht einfängt

Wann FT nicht die Antwort ist

Problem	Besser
Veraltetes / firmeneigenes Wissen	RAG + Freshness (Kapitel 12)
Live-State, Buchen, Rechte	Tools + AuthZ (Kapitel 13)
Offene Prozesswahl	Workflow/Agent-Caps (Kapitel 14)
Kein Golden Set	Eval bauen, nicht trainieren (T3)
Einmalige Demo-Qualität	Prompt/Context
„Modell soll Policies auswendig können“	RAG + Code-Policy; FT veraltet still
Team ohne Train/Serve-Owner	Stufe 2–4 vertiefen

Faustregel: Fakten fließen über Retrieval und Tools; FT formt Verhalten und Effizienz auf einem stabilen Verteilungsbild.

---

Datenqualität schlägt Trainings-Hobby

Daten als Produkt

Anforderung	Warum
Repräsentativ für Prod	sonst trainiert ihr die Demo
Saubere Labels / Prefs	Müll rein → selbstbewusst Müll raus
Lizenz & Privacy	Trainingssets sind Compliance-Objekte (Kapitel 20)
Versioniert	dataset_version neben model_version
Lösch- und Korrekturpfad	„Recht auf…“ und Bugfixes an Labels
Leak-Kontrolle	keine Secrets, keine fremden Tenants

SFT vs. Preference (kurz)

• SFT: Input→gewünschter Output (Format, Stil, Tool-Spuren).
• Preference / Ranking: „A besser als B“ für Ton, Safety-Nuancen, relative Qualität — braucht saubere Vergleiche und klare Policy.

Beide brauchen gehaltene Eval-Sets, die nicht im Training waren.

Größe und „noch mehr Daten“

Mehr Daten helfen nur bis zur Verteilungsgrenze. 10× schlechte Tickets skalieren den Bias. Kuratieren, hard cases, Refusal-Beispiele, Schema-Edge-Cases — Qualität vor Rohvolumen.

---

Distillation: kleiner, billiger, eng

Typisches Muster:

Teacher (Strong / teuer)  →  synthetische oder gelabelte Targets
Student (Fast/Cheap)      →  SFT/Distill auf dieselben Tasks
Eval: Parität auf Golden Set + Cost/Latency-Gewinn

Passt	Passt schlecht
enger Task, klares Schema	offene Allzweck-Assistenz
Teacher stabil und evalbar	Teacher halluziniert Fakten → Student lernt Lügen
Serving-Kosten dominieren	Problem ist Knowledge-Freshness

Distillation multipliziert Teacher-Fehler. Grounding und Tools bleiben oft im Student-System — FT macht den Student zuverlässiger im Format, nicht allwissend.

---

Ops-Last (ehrlich rechnen)

FT ist nicht „ein Job und fertig“:

Disziplin	Inhalt
Training pipeline	repro, hyperparams, dataset pin, secrets
Eval gate	regress gegen Golden Set + Safety suite vor Promote
Serving	Adapter/Checkpoint laden, Warmup, Limits
Versioning	base_model + adapter_id / checkpoint + prompt bundle
Monitoring	quality drift, cost, latency nach Deploy
Rollback	vorherige Gewichte pinbar in Minuten
Retrain cadence	wann Daten/Base-Model zwingen neu zu trainieren

Wenn das Platform-Team das nicht tragen kann, ist der ADR-Ausgang nicht FT — auch wenn ein Blogpost es verspricht. Hosting-Trade-offs: Kapitel 09, 21.

Base-Model-Updates (T9)

Provider ändern Base-Modelle; euer Adapter kann brechen oder still schlechter werden. Plan: Re-FT-Pipeline, Eval, Canary — analog model-change-checklist.md. FT erhöht Kopplung an eine Modellfamilie, statt sie zu entfernen.

---

Decision Frame und Patterns

Decision Frame: FT jetzt?

Frage	Nein →
Plateau auf 1–5 mit Zahlen belegt?	optimiere Context/RAG/Tools/Prompt
Golden Set + held-out vorhanden?	baue Eval
Daten lizenz- und privacy-klar?	stopp / redaction / Legal
Owner für Train+Serve+Rollback?	nicht starten
Ziel = Faktenwissen?	RAG
Ziel = €/Latenz bei Parität?	Distill-Kandidat
Ziel = Stil/Format bei Volumen?	FT-Kandidat

Schreib die Entscheidung in adr-adaptation.md.

Pattern: FT + RAG (nicht FT statt RAG)

Adapter für Format/Domänenton; Retrieval für Fakten. Häufigste reife Kombi.

Trade-off: zwei Systeme; verhindert veraltetes „eingebranntes“ Wissen.

Pattern: Distill the hot path

Nur den High-QPS-Pfad destillieren; Long-Tail auf Balanced/Strong + Cascade (Kapitel 09).

Trade-off: Routing-Komplexität; bessere Unit Economics.

Pattern: Adapter small, eval large

Kleine Gewichtsanpassung (wo technisch sinnvoll) + große Regression-Suite.

Trade-off: nicht jedes Verhalten ist „LoRA-bar“; Ehrlichkeit in der Eval.

Pattern: Synthetic data mit Misstrauen

Teacher-generierte Daten nur mit Filter, Dedup, Human-Spotcheck und separatem Gold-Eval.

Trade-off: Skalierung vs. Self-Bias und Leakage von Teacher-Artifacts.

Trade-off: Flexibilität vs. Spezialisierung

Mehr FT-Spezial	Mehr Prompt/RAG/Tools
stark auf Verteilungsbild	schnell iterierbar
teurer Shift bei Task-Change	schwächer bei extremem Format-Druck
Ops-Last Gewichte	Ops-Last Index/Prompt
Risiko stiller Knowledge-Stale	Freshness steuerbar

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
FT als Wiki	Policies im Gewicht, wöchentlich falsch	RAG + Version
FT ohne Eval	„fühlt sich besser an“	Golden Set, Gate
FT vor Ladder	kein Schema/RAG/Tools versucht	Stufe 2–4 zuerst
Datenstaubsauger	alles in Train, inkl. PII/Secrets	Kuratierung, Klassen
Einmal trainieren, nie retrain	Drift gegen Prod	Cadence + Monitoring
Teacher-Halluzination destillieren	Student lernt erfundene Fakten	Grounded Teacher-Targets
FT heilt AuthZ	„Modell weiß, was verboten ist“	Code-Policy
Unpinnte Checkpoints	Prod nicht reproduzierbar	pin + rollback
Team ohne Owner	„ML-Praktikum“ in Prod	nicht shippen (T10)
Allzweck-FT	ein Adapter für alle Features	enge Task-Adapter oder gar nicht

---

Production Notes

Cost. Rechnet Total Cost of Ownership: Annotation, Train-Jobs, failed experiments, Serving, Re-FT nach Base-Update — gegen €-Gewinn pro 1k Requests. Manchmal gewinnt Cascade+Cache ohne Gewichte (T7).

Latency. Kleineres destilliertes Modell kann p95 senken — nur mit Paritäts-Eval und realistischem Load. Adapter-Overhead und Cold-Start messen.

Observability. model_id / adapter_id / dataset_version / training_run_id in Traces. Quality-Signale nach Deploy vergleichen (shadow/canary). Minimum: observability-minimum.md.

Security / Privacy. Trainingsdaten = Angriffs- und Leakage-Fläche (Memorization, exfil über Outputs). Keine Secrets im Set; Tenant-Isolation in Samples; Safety-Suite vor Promote (Kapitel 19, 20).

Lifecycle. Jeder Promote: Offline-Eval, Safety, Cost-Estimate, Canary, Rollback. Base-Model-Change triggert Re-Eval und oft Re-FT (T9). Ownership schriftlich (T10).

---

Key Takeaways

• Meistens nicht: FT/Distill erst nach Plateau auf Prompt, Schema, Context, RAG, Tools/Workflows — mit Zahlen.
• FT formt Verhalten/Effizienz; RAG/Tools tragen Fakten und Wirkung.
• Datenqualität und held-out Eval entscheiden über Erfolg — nicht die Wahl des Trainings-UI.
• Ops-Last und T9-Kopplung ehrlich in den ADR; ohne Owner kein Prod-Adapter.
• Distill den Hot Path, nicht die ganze Produktvision.
• Ladder und ADR: Kapitel 08, adr-adaptation.md.

Praktische nächste Schritte

1. Liste Top-Failure-Modes eures Features — welche sind echt FT-Themen, welche RAG/Tools/Prompt?
2. Wenn FT-Idee bleibt: schreibe Plateau-Evidenz (Metriken, was auf 1–5 probiert wurde) in den ADR.
3. Skizziere dataset_version, Label-Prozess, Privacy-Klasse und held-out-Größe bevor der erste Trainingsjob läuft.
4. Definiere Promote-Gates: min. Task Success, Safety, €/Latency vs. Baseline.
5. Benenne Owner für Daten, Training, Serving, Rollback — fehlen sie, stoppt der Slice.
6. Als Nächstes Orchestrierung im Code bündeln: Orchestrierung im Code — Validate/Repair/Fallback/Caps unabhängig von der Ladder-Stufe.