Zum Inhalt springen
Ressourcen/Technischer Leitfaden
Technischer Deep Dive

Leitfaden zu KI-Fähigkeiten & Fine-Tuning

Ein vollständiger Leitfaden, um KI-Modellen neue Fähigkeiten beizubringen: Supervised Fine-Tuning (SFT), LoRA/QLoRA, RLHF, DPO, GRPO, Modell-Distillation, Modell-Merging und Evaluierung. Vom Konzept bis zur Produktion — mit funktionierendem Code in jedem Schritt.

11 Abschnitte
45 Min. Lesezeit
Produktionsreifer Code
März 2026

Die Fine-Tuning-Landschaft

Das Pretraining verleiht einem Modell ein breites Weltwissen, aber nur eine Fähigkeit: das nächste Token vorherzusagen. Das Modell hat Wikipedia, Code, Bücher und das Web gesehen — aber es weiß nicht, hilfreich zu sein, Anweisungen zu folgen oder gefährliche Anfragen abzulehnen. Fine-Tuning ist der Prozess, diese Verhaltensweisen nach dem Pretraining beizubringen.

Die Branche hat sich auf eine standardisierte Trainingsleiter geeinigt, der alle großen Spitzenmodelle (GPT-4o, Claude Opus 4.6, Llama 4, Gemini 2.5) folgen. Jede Stufe baut auf der vorherigen auf — man kann SFT nicht überspringen und direkt zu RLHF springen.

Die Trainingsleiter

graph LR
  A[Raw Text Corpus] -->|Pretraining cross-entropy| B[Base Model]
  B -->|Supervised Fine-Tuning| C[Instruction-Following Model]
  C -->|RLHF / DPO / GRPO| D[Aligned Model]
  D -->|Evaluation & Red-teaming| E[Production Model]

Pretraining

Selbstüberwachte Vorhersage des nächsten Tokens auf riesigen Korpora. Kodiert Weltwissen.

SFT

Supervised Fine-Tuning auf Anweisungs-Antwort-Paaren. Bringt dem Modell bei, hilfreich zu sein.

Präferenz-Alignment

RLHF, DPO oder GRPO auf menschlichen Präferenzdaten. Macht Ausgaben sicher und bevorzugt.

Evaluierung

Automatisierte Benchmarks + Red-Teaming. Regressionen vor dem Ausliefern erkennen.

Fine-Tuning vs. Prompt-Engineering
Prompt-Engineering macht Verhaltensweisen bedingt (sie treten nur auf, wenn der Prompt es vorgibt). Fine-Tuning macht Verhaltensweisen zum Standard — das Modell zeigt sie konsistent, ohne dass man es ihm sagt. Im großen Maßstab ist dieser Unterschied in der Zuverlässigkeit erheblich.

Supervised Fine-Tuning (SFT)

SFT trainiert das Modell, Assistenten-Token aus einem Gesprächskontext vorherzusagen. Das entscheidende Detail ist das Loss Masking: Der Kreuzentropie-Verlust wird nur auf Assistenten-Token berechnet, nicht auf den System-Prompt oder die Nutzer-Turns. Das verhindert, dass das Modell die Nutzerseite des Gesprächs „lernt“.

Datenformate

Drei Formate dominieren die SFT-Landschaft. ChatML hat sich aufgrund seiner eindeutigen Spezial-Token am weitesten durchgesetzt.

text (ChatML format)
<|im_start|>system
You are a helpful AI assistant specialized in European AI regulation.
<|im_end|>
<|im_start|>user
What are the key obligations under the EU AI Act for high-risk systems?
<|im_end|>
<|im_start|>assistant
High-risk AI systems under the EU AI Act (in force August 2024) must comply with...
<|im_end|>

Wichtige Hyperparameter

ParameterTypischer WertHinweise
Learning rate2e-5Niedriger als beim Pretraining; Cosinus-Abfall
Epochs2–3Mehr Epochen → Overfitting bei kleinen Datensätzen
Batch size (effective)64–128Gradientenakkumulation bei wenig GPU-Speicher verwenden
Warmup ratio0.110 % der Schritte für das LR-Warmup
Max sequence length2048–8192An Ihr Inferenz-Kontextfenster anpassen

SFT mit dem SFTTrainer von trl

python
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import SFTConfig, SFTTrainer
from datasets import load_dataset
import torch

model_name = "meta-llama/Llama-4-Scout-17B-16E-Instruct"  # 2026: Llama 4 Scout replaces Llama 3.1 8B
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.bfloat16, device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

dataset = load_dataset("HuggingFaceH4/ultrachat_200k", split="train_sft")

sft_config = SFTConfig(
    output_dir="./sft-llama-4-scout",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=2e-5,
    lr_scheduler_type="cosine",
    warmup_ratio=0.1,
    logging_steps=10,
    save_strategy="epoch",
    bf16=True,
)

trainer = SFTTrainer(
    model=model,
    args=sft_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()
trainer.save_model()
Datenqualität schlägt Quantität
1.000 hochwertige, vielfältige Anweisungs-Antwort-Paare übertreffen durchgängig 100.000 verrauschte Beispiele. Die besten Instruction-Tuning-Datensätze (Alpaca 52K, WizardLM 196K, OpenHermes 1M, UltraChat 200K) sind aufgrund der Kuratierung erfolgreich, nicht wegen ihrer reinen Größe.

Parametereffizientes Fine-Tuning: LoRA

Vollständiges Fine-Tuning verändert alle ~7 Milliarden Parameter eines 7B-Modells. In bfloat16 sind das 14 GB allein für die Parameterspeicherung, plus Gradienten und Optimiererzustände. LoRA (Low-Rank Adaptation, Hu et al. 2021) nutzt eine zentrale empirische Beobachtung: Gewichtsänderungen während des Fine-Tunings sind von niedrigem Rang.

Statt ein vollständiges Gewichts-Update ΔW ∈ ℝ^(d×k) zu lernen, lernt LoRA zwei kleine Matrizen: A ∈ ℝ^(d×r) und B ∈ ℝ^(r×k) mit r ≪ min(d, k). Bei der Inferenz wird der Adapter zurückgefaltet: W′ = W + αAB/r. Nach dem Merge entsteht kein Inferenz-Overhead.

r = 4
Minimale Anpassung (Ton, Stil)
~21M (0.3%)
r = 8
Standard — ausgewogene Qualität
~42M (0.6%)
r = 16
Mehr Kapazität, Domänen-Aufgaben
~83M (1.0%)
r = 64
Qualität nahe vollständigem Fine-Tuning
~335M (4.1%)
Alpha-/Rang-Verhältnis
Behalten Sie als Ausgangspunkt lora_alpha = 2 × r bei (z. B. r=16, alpha=32). Dies steuert die effektive Lernrate des Adapters. Höheres Alpha = stärkere Anpassung; zu hoch = Instabilität.

LoRA mit PEFT

python
from peft import LoraConfig, TaskType, get_peft_model

config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    bias="none",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: 83,886,080 || all params: 8,030,261,248 || trainable%: 1.044

# After training, merge adapter back into the base weights
merged = model.merge_and_unload()
merged.save_pretrained("./my-lora-merged")

Vergleich LoRA vs. vollständiges Fine-Tuning

MethodeTrainierbare ParameterGPU-RAM (8B)QualitätTrainingsgeschwindigkeit
Full Fine-Tuning7B (100%)~80 GBBesteLangsamste
LoRA r=4~21M (0.3%)~16 GBGutSchnell
LoRA r=16~83M (1.0%)~18 GBSehr gutSchnell
LoRA r=64~335M (4.1%)~24 GBNahe vollständigem FTModerat
DoRA: gewichtszerlegtes LoRA
DoRA (Liu et al. 2024) zerlegt Gewichts-Updates in Komponenten für Magnitude und Richtung und wendet auf jede eine eigene Lernrate an. Es erreicht durchgängig 1–2 % bessere Benchmark-Werte als Standard-LoRA ohne zusätzlichen Inferenzaufwand. Verfügbar in PEFT über use_dora=True in LoraConfig.

QLoRA: 4-Bit-Fine-Tuning

Selbst mit LoRA benötigt das in bfloat16 geladene Basismodell 16 GB für ein 8B-Modell — jenseits der Budgets von Consumer-GPUs. QLoRA (Dettmers et al. 2023) löst das, indem es das eingefrorene Basismodell auf 4-Bit-NormalFloat (NF4) quantisiert und die LoRA-Adapter in bfloat16-Präzision trainiert.

NF4-Quantisierung

NormalFloat4 ist informationstheoretisch optimal für normalverteilte Gewichte neuronaler Netze. Geringerer Fehler als int4 oder fp4.

Paged Optimizers

Optimiererzustände werden automatisch in den CPU-RAM ausgelagert, wenn der GPU-Speicher voll wird, und verhindern so OOM-Abstürze während des Trainings.

Doppelte Quantisierung

Quantisiert die Quantisierungskonstanten selbst und spart so zusätzliche ~0,5 Bit pro Parameter.

Hardware-Anforderungen

ModellFP16-VRAMQLoRA-VRAMMindest-GPU
Llama 4 Scout (17B)34 GB10 GBRTX 4090 24GB
Llama 4 Maverick (70B-class)140 GB40 GB2× A100 40GB
Llama 4 Behemoth (frontier)800+ GB~200 GB8× H100 80GB

QLoRA mit bitsandbytes

python
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-4-Maverick-17B-128E-Instruct",  # 2026: Llama 4 Maverick replaces Llama 3.1 70B
    quantization_config=bnb_config,
    device_map="auto",
)
# Now apply LoRA to the 4-bit model — same LoraConfig + get_peft_model as before
Unsloth für Single-GPU-Workloads
Unsloth bietet benutzerdefinierte CUDA-Kernel für QLoRA, die ein 2× schnelleres Training und 50 % weniger VRAM als Standard-bitsandbytes-QLoRA erreichen. Es unterstützt die Familien Llama 4, Llama 3, Mistral, Qwen und Gemma und ist die erste Wahl für Single-GPU-Fine-Tuning.

Alignment: RLHF

Reinforcement Learning from Human Feedback (RLHF) war der Durchbruch, der GPT-3 in InstructGPT und schließlich in GPT-4o verwandelte. Es richtet das Modellverhalten an menschlichen Präferenzen aus — nicht nur das Befolgen von Anweisungen, sondern Ausgaben, die wirklich bevorzugt, sicher und hilfreich sind.

Die dreistufige Pipeline

Stage 1

SFT-Warmup

Das Basismodell auf einem kuratierten Satz hochwertiger, anweisungsbefolgender Demonstrationen feinabstimmen. Dies erzeugt die Ausgangspolicy, die RLHF verbessern wird.

Stage 2

Training des Reward-Modells

Einen Klassifikator auf paarweisen menschlichen Präferenzen trainieren: Welche von zwei Vervollständigungen (y_w, y_l) zum selben Prompt ist besser? Verlust: log σ(r(x, y_w) − r(x, y_l)).

Stage 3

PPO-Optimierung

Proximal Policy Optimization einsetzen, um den Wert des Reward-Modells zu maximieren und dabei nahe an der SFT-Policy zu bleiben (die KL-Divergenz-Strafe verhindert Reward Hacking).

RLHF-Pipeline-Diagramm

graph LR
  A[Base Model] -->|SFT on demos| B[SFT Model]
  B -->|Sample completions| C[Completion Pairs]
  C -->|Human labelers rank| D[Preference Dataset]
  D -->|Train| E[Reward Model]
  B -->|Initialize policy| F[Policy Model]
  F -->|Rollout + PPO| G[RL Optimization]
  E -->|Score rollouts| G
  G -->|Converged| H[RLHF Model]
PPO-Komplexität
RLHF mit PPO erfordert vier Modelle gleichzeitig: die Policy, die Referenz-Policy (eingefrorenes SFT-Modell), das Reward-Modell und das Value-Modell. Das macht RLHF speicherintensiv und notorisch schwer zu stabilisieren. Reward Hacking (die Policy findet Wege, hohe Werte zu erzielen, ohne tatsächlich gut zu sein) ist eine anhaltende Herausforderung. Deshalb wird DPO inzwischen weithin bevorzugt.

Alignment: DPO & GRPO

DPO (Direct Preference Optimization) (Rafailov et al. 2023) eliminiert das Reward-Modell vollständig. Es zeigte mathematisch, dass die optimale RLHF-Policy direkt als Funktion der Präferenzdaten ausgedrückt werden kann, und reduziert so eine dreistufige Pipeline auf einen einzigen Fine-Tuning-Schritt.

Der DPO-Verlust optimiert die Policy direkt auf Präferenzpaaren (Prompt, chosen, rejected) und nutzt das SFT-Modell als eingefrorene Referenz. Kein PPO, kein Reward-Modell, keine separate Erhebung von RM-Trainingsdaten.

DPO mit dem DPOTrainer von trl

python
from trl import DPOConfig, DPOTrainer
from datasets import load_dataset

# Dataset needs: prompt, chosen, rejected columns
dataset = load_dataset("HuggingFaceH4/ultrafeedback_binarized", split="train_prefs")

dpo_config = DPOConfig(
    output_dir="./dpo-output",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=5e-7,   # much smaller than SFT lr
    beta=0.1,             # KL penalty coefficient
    bf16=True,
)

trainer = DPOTrainer(
    model=sft_model,          # your SFT fine-tuned model
    ref_model=sft_ref_model,  # frozen reference
    args=dpo_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()

GRPO: der Ansatz von DeepSeek

Group Relative Policy Optimization (GRPO) (verwendet in DeepSeek-R1) eliminiert das Referenzmodell. Für jeden Prompt werden mehrere Ausgaben gesampelt und der Gruppenmittelwert der Belohnung als Baseline für die Vorteilsschätzung genutzt. Das ist günstiger als PPO (kein Value-Modell) und besser für Reasoning-Aufgaben geeignet, bei denen sich die Korrektheit programmatisch verifizieren lässt.

Zentraler Vorteil von GRPO:
Kein Referenzmodell erforderlich + gruppenrelative Belohnungen = effizientes Training für verifizierbare Aufgaben (Mathematik, Code, strukturierte Ausgabe).

Vergleich der Alignment-Methoden

MethodeRechenaufwandStabilitätDatenanforderungenHinweise
RLHF (PPO)Sehr hochNiedrigMenschliche Rankings4 Modelle im Speicher; Risiko von Reward Hacking
DPONiedrigHochPräferenzpaareKein Reward-Modell; einfachere Pipeline
GRPOMittelMittelRollout-SamplesKein Referenzmodell; gut für Reasoning
SimPONiedrigHochPräferenzpaareKein Referenzmodell; durchschnittliche Log-Prob-Belohnung

Modell-Distillation

Knowledge Distillation trainiert ein kleines „Schüler“-Modell, ein großes „Lehrer“-Modell nachzuahmen. Die zentrale Erkenntnis ist, dass der Lehrer weiche Wahrscheinlichkeitsverteilungen über das Vokabular (Logits) liefert statt One-Hot-Labels. Diese weichen Ziele kodieren weit mehr Information — sie verraten, welche Token semantisch der korrekten Antwort ähneln, und geben dem Schüler ein reichhaltigeres Trainingssignal.

Der kombinierte Verlust: L = α × L_CE(harte Labels) + (1 − α) × L_KL(Schüler-Logits ‖ Lehrer-Logits). Die Temperaturskalierung T > 1 glättet die Verteilung des Lehrers, verteilt die Wahrscheinlichkeitsmasse auf mehr Token und macht die weichen Labels noch informativer.

Distillation-Pipeline

graph TB
  A["Large Teacher (70B)"] -->|"Generate on training data"| B[Soft Logits]
  C[Input Prompt] --> A
  C --> D["Small Student (7B)"]
  B -->|KL Loss| D
  E[Ground Truth] -->|CE Loss| D
  D -->|Both losses| F[Distilled Student]

Antwort-Distillation

Der Schüler imitiert die Ausgaben des Lehrers — Lehrer-Vervollständigungen erzeugen, den Schüler trainieren, sie zu reproduzieren. Von DeepSeek-R1-Distill genutzt, um Reasoning-Traces zu übertragen.

Feature-Distillation

Zwischenrepräsentationen (Hidden States, Attention-Muster) zwischen Lehrer- und Schülerschichten abgleichen. Überträgt strukturelles Wissen, nicht nur Oberflächenausgaben.

Spekulatives Decoding

Ein kleines Entwurfsmodell schlägt Token-Sequenzen vor; das große Modell verifiziert sie parallel. Erreicht eine 2- bis 4-fache Inferenzbeschleunigung ohne Qualitätsverlust.

On-Policy-Distillation

Der Schüler erzeugt Token; der Lehrer bewertet sie. Vermeidet Exposure Bias (Verteilungsabweichung zwischen Training und Test), der bei Offline-Distillation häufig ist.

Reale Distillation-Beispiele
  • Phi-3 / Phi-4 (Microsoft): aus GPT-4 auf kuratierten synthetischen Daten distilliert
  • Gemma 2 (Google): aus Gemini Ultra distilliert; das 9B erreicht weit größere Modelle
  • DeepSeek-R1-Distill: Reasoning-Traces aus R1 in 7B-/14B-Qwen2.5-Modelle distilliert

Modell-Merging

Modell-Merging kombiniert mehrere feinabgestimmte Checkpoints zu einem einzigen Modell ohne jegliches zusätzliche Training. Es ist günstig, schnell und überraschend wirksam, um spezialisierte Fähigkeiten — Code, Mathematik, Anweisungsbefolgung — in einem einzigen einsatzfähigen Modell zu vereinen. Gemergte Modelle erscheinen häufig an der Spitze des HuggingFace Open LLM Leaderboard.

SLERPSphärische lineare Interpolation

Glatte Interpolation zwischen zwei Modell-Checkpoints im Gewichtsraum. Behandelt Gewichte als Punkte auf einer Hypersphäre. Am besten geeignet, um zwei eng verwandte Modelle zu mischen.

Task ArithmeticFine-Tuning-Deltas addieren/subtrahieren

ΔW = W_FT − W_base für jedes feinabgestimmte Modell berechnen, dann die Deltas addieren. Erlaubt es, Fähigkeiten zu komponieren oder unerwünschte Verhaltensweisen zu subtrahieren.

TIES-MergingTrim, Elect Signs, Merge

Löst Konflikte zwischen Modellen: Parameter mit geringer Magnitude beschneiden, für jedes Gewicht das dominante Vorzeichen wählen, dann mergen. Bewältigt 3 oder mehr Modelle sauber.

DAREDrop and Rescale

Verwirft Fine-Tuning-Gewichts-Deltas zufällig (mit Wahrscheinlichkeit p) und skaliert die Überlebenden neu, um die Norm zu erhalten. Reduziert Interferenzen zwischen Modellen.

MergeKit-Konfiguration (TIES)

yaml
# mergekit config.yaml
models:
  - model: meta-llama/Llama-4-Scout-17B-16E
    parameters:
      weight: 0.4
  - model: ./llama-4-scout-code-finetuned
    parameters:
      weight: 0.3
  - model: ./llama-4-scout-math-finetuned
    parameters:
      weight: 0.3
merge_method: ties
base_model: meta-llama/Llama-4-Scout-17B-16E
parameters:
  density: 0.7
  normalize: true
bash
mergekit-yaml config.yaml ./merged-model --cuda
Frankenmerge (Layer-Stacking)
Eine radikalere Technik: verschiedene Schichten aus verschiedenen Modell-Checkpoints stapeln — z. B. Schichten 0–16 aus Modell A, Schichten 17–32 aus Modell B. Erfordert kein Training und kann überraschende Fähigkeiten hervorbringen, benötigt aber Experimente, um gute Schichtkombinationen zu finden. MergeKit unterstützt dies über die passthrough-Merge-Methode.

Datensatz-Vorbereitung

Die Datensatzqualität ist der mit Abstand wichtigste Faktor für den Erfolg des Fine-Tunings — wichtiger als die Modellarchitektur, die Trainingsdauer oder die Wahl des Optimierers. Ein schlecht kuratierter Datensatz garantiert schlechte Ergebnisse, unabhängig von allem anderen.

Von Menschen verfasstHöchste
Am teuersten

Von Experten verfasste Beispiele; höchstes Signal-Rausch-Verhältnis. Für kritische Verhaltensweisen verwendet.

Mit GPT-4 / Claude generiertHoch
Moderat

Synthetische Generierung mit Spitzenmodellen. Gut, um die Domänenabdeckung im großen Maßstab anzustoßen.

Evol-Instruct / MagpieGut
Niedrig

Seed-Anweisungen zu schwierigeren, vielfältigeren Varianten weiterentwickeln. Verwendet in WizardLM und OpenHermes.

Aus dem Internet gefiltertVariabel
Am günstigsten

Erfordert aggressive Qualitätsfilterung: Deduplizierung, Längenfilter, Perplexitätsfilter, Sicherheitsfilter.

ShareGPT-Datenformat

json
{
  "conversations": [
    {"from": "system", "value": "You are an expert in EU AI regulation."},
    {"from": "human", "value": "Explain the risk categories in the EU AI Act."},
    {"from": "gpt", "value": "The EU AI Act categorizes AI systems into four risk levels..."}
  ]
}

Synthetische Datengenerierung im großen Maßstab

python
from openai import OpenAI  # or use Mistral/Llama locally

client = OpenAI()

def generate_training_example(topic: str, difficulty: str) -> dict:
    prompt = (
        f"Generate a challenging {difficulty}-level question about {topic} "
        "and a comprehensive expert answer."
    )
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.8,
    )
    content = response.choices[0].message.content
    # Parse and structure output (question/answer split)...
    return {"instruction": topic, "response": content}

Empfohlene Verteilung der Anweisungsvielfalt

Fragenbeantwortung
30%
Schreiben & Zusammenfassen
20%
Codegenerierung & Debugging
20%
Analyse & Reasoning
15%
Sonstiges (Übersetzung, Extraktion usw.)
15%
Datenkontamination
Die Kontamination des Testsets ist das Evaluierungsproblem Nr. 1 beim Fine-Tuning. Wenn einer Ihrer Evaluierungs-Benchmarks (MT-Bench, HumanEval, MMLU) in Ihren Trainingsdaten auftaucht, sind Ihre Werte überhöht und bedeutungslos. Führen Sie vor dem Training stets n-Gramm-Überlappungsprüfungen zwischen Ihrem Trainingsset und den Evaluierungs-Benchmarks durch.

Evaluierung & Iteration

Die Fine-Tuning-Schleife lautet: trainieren → auf einem Holdout evaluieren → Fehlermodi diagnostizieren → Daten verbessern → erneut trainieren. Eine gute Evaluierung ist es, die aus Versuch und Irrtum eine systematische Verbesserung macht.

MT-Bench

Allgemeine Qualität

Multi-Turn-Benchmark mit 80 Fragen über 8 Kategorien (Schreiben, Mathematik, Coding usw.). GPT-4 bewertet jede Antwort mit 1–10.

AlpacaEval

Anweisungsbefolgung

Gewinnrate Ihres Modells gegenüber einem Referenzmodell (GPT-4o), bewertet durch GPT-4o. Schnelle automatisierte Bewertung der Anweisungsbefolgung.

IFEval

Formatkonformität

Genauigkeit der Anweisungsbefolgung bei verifizierbaren Vorgaben (z. B. „in weniger als 100 Wörtern antworten“). Strikte und lockere Bewertungsvarianten.

HumanEval / MBPP

Codegenerierung

Codegenerierungs-Benchmarks. Pass@k-Metrik: Anteil der in k Versuchen gelösten Probleme. Ausführbare Testfälle als Ground Truth.

Das LLM-as-Judge-Muster

python
import json
from openai import OpenAI

client = OpenAI()

def evaluate_response(question: str, answer: str, judge_model: str = "gpt-4o") -> dict:
    prompt = f"""Rate the following AI assistant response on a scale of 1-10.

Question: {question}
Answer: {answer}

Evaluate: helpfulness (1-10), factuality (1-10), safety (1-10).
Return JSON: {{"helpfulness": N, "factuality": N, "safety": N, "rationale": "..."}}"""

    response = client.chat.completions.create(
        model=judge_model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
    )
    return json.loads(response.choices[0].message.content)
Häufige Evaluierungsfallen
  • Längen-Bias: LLM-Judges bevorzugen tendenziell längere Antworten, unabhängig von der Qualität. Kalibrieren Sie Ihren Judge.
  • Sycophancy: Modelle bewerten ihre eigenen Ausgaben höher. Verwenden Sie ein anderes Modell als Judge oder eine menschliche Validierung.
  • Kontamination: Benchmark-Daten im Trainingsset überhöhen die Werte. Prüfen Sie stets die Überlappung.
  • Einzelmetrik-Fallen: Das Optimieren einer Metrik verschlechtert oft andere. Verfolgen Sie eine ausgewogene Scorecard.

Vorlage zur Experiment-Nachverfolgung

RunBasismodellMethodeDatensatzMT-BenchAlpacaEval Win%Hinweise
v1Llama-4-ScoutSFTUltraChat 200K7.470%Baseline
v2Llama-4-ScoutSFT+DPO+ UltraFeedback8.076%+DPO verbesserte die Sicherheit
v3Llama-4-ScoutSFT+DPO (r=16)+ UltraFeedback8.177%LoRA r=16 vs. vollständiges FT

Wann Fine-Tuning vs. RAG vs. Prompt-Engineering

Fine-Tuning ist mächtig, aber nicht immer das richtige Werkzeug. Die Entscheidung hängt davon ab, was Sie ändern wollen: Wissen, Verhalten, Format oder Präferenzen. Die falsche Wahl kostet Wochen an Engineering und Rechenleistung.

SzenarioBeste VorgehensweiseWarum
Antworten in Unternehmensdokumenten verankernRAGWissen kann sich ändern; FT lässt sich nicht leicht aktualisieren
Konsistenten Ton/Stil wünschenSFTTon ist Format, nicht Wissen
Verwendung domänenspezifischer TerminologieSFT + wenig DatenStandardverhalten kostengünstig ändern
Bestimmte Ausgabeformate handhabenSFTSchema-Einhaltung ist eine erlernte Fähigkeit
Schädliche Ausgaben reduzierenDPO / RLHFPräferenz-Alignment zielt direkt darauf ab
Reasoning-Fähigkeiten benötigenGRPO oder aus R1 distillierenReasoning-Muster sind trainierbar
Neues Faktenwissen hinzufügenRAG (nicht FT)FT memoriert, kann keine Quellen zitieren
API-Kosten im großen Maßstab senkenKleines Modell feinabstimmenQualität großer Modelle bei enger Aufgabe erreichen
Prototyp / schnelles ExperimentZuerst Prompt-EngineeringKeine Trainingskosten; Konzept zuerst validieren

Die LLM-Treppe

Beginnen Sie ganz unten. Steigen Sie nur auf, wenn die aktuelle Stufe wirklich unzureichend ist — jede Stufe fügt Kosten, Komplexität und Latenz hinzu.

1
Prompt-Engineering
Kostenlos, sofort, keine Trainingskosten
2
Few-Shot-Beispiele
Beispiele in den Kontext aufnehmen
3
RAG
Antworten in abgerufenen Dokumenten verankern
4
SFT
Format, Stil, Domänenwissen vermitteln
5
DPO / RLHF
Auf Präferenzen und Sicherheit ausrichten
6
Distillation
Zu einem aufgabenspezifischen kleinen Modell komprimieren

Fine-Tuning, wenn

  • Konsistenter Ton/Format im großen Maßstab
  • Domänenjargon muss Standard sein
  • Bestimmtes Ausgabeschema erforderlich
  • API-Kosten bei enger Aufgabe senken
  • Präferenz-/Sicherheits-Alignment nötig

RAG verwenden, wenn

  • Wissen sich häufig ändert
  • Antworten Zitate/Quellen benötigen
  • Private/proprietäre Wissensbasis
  • Großer Dokumentenkorpus (>1M Token)
  • Aktualisierung ohne erneutes Training nötig

Fine-Tuning vermeiden, wenn

  • Neues Faktenwissen hinzufügen (RAG verwenden)
  • Schnelle Prototyp- oder PoC-Phase
  • Sehr kleiner Datensatz (<100 Beispiele)
  • Kein GPU-Budget verfügbar
  • Prompting erreicht das Ziel bereits
Bereit für Fine-Tuning?

Bauen Sie Ihr individuelles KI-Modell

Ob Sie einen domänenspezifischen Assistenten, präferenzausgerichtete Modelle oder distillierte Produktionsdeployments benötigen — unser Team hat sie gebaut und ausgeliefert. Sprechen wir über Ihren Anwendungsfall.

Weitere Leitfäden
Leitfaden zu KI-Fähigkeiten & Fine-Tuning: SFT, LoRA, RLHF, DPO & Modell-Distillation | Hyperion Consulting