Fine-Tuning 2026: Wann GRPO besser ist als SFT — und was RULER mit Evaluierung zu tun hat

Die Ausgangslage: Warum Fine-Tuning 2026 anders ist

2023 war Fine-Tuning der Standard-Ratschlag für jeden, der ein LLM an einen spezifischen Use Case anpassen wollte. 2025/2026 hat sich das Bild verändert.

Prompt Engineering, RAG und In-Context-Learning haben das Einsatzgebiet von Fine-Tuning stark eingeschränkt. Nicht weil Fine-Tuning schlechter geworden ist — sondern weil die Alternativen besser wurden.

Trotzdem gibt es klare Szenarien, wo Fine-Tuning die überlegene Wahl ist. Dieser Artikel ist für genau diese Szenarien.

Wann Fine-Tuning die richtige Wahl ist

Bevor wir über GRPO vs. SFT reden: Die fundamentale Frage ist, ob Fine-Tuning überhaupt sinnvoll ist.

Fine-Tuning ist sinnvoll wenn:

1. Konsistenter Style/Format — Du brauchst Output in einem sehr spezifischen Format, das Prompting nicht zuverlässig reproduziert
2. Proprietäres Domain-Wissen — Daten, die nicht öffentlich zugänglich sind und in keine RAG-Datenbank passen
3. Latenz-Anforderungen — Kürzere Prompts (kein Few-Shot-Overhead) = schnellere Inferenz
4. Kosten-Optimierung bei hohem Volumen — Ein gut gefinetuned kleineres Modell schlägt oft ein großes mit aufwendigem Prompting

Fine-Tuning ist falsch wenn:

• Du es als Ersatz für gutes Prompt Engineering einsetzt
• Deine Trainingsdaten < 1.000 qualitativ hochwertige Beispiele sind
• Dein Use Case sich häufig ändert (Fine-tuned Models sind "frozen in time")

SFT: Der Standard — und seine Grenzen

Supervised Fine-Tuning (SFT) ist das bekannteste Verfahren: Du trainierst auf Input-Output-Paaren.

# Schematische SFT-Datenstruktur (OpenAI-Format, auf andere übertragbar)
training_example = {
    "messages": [
        {"role": "system", "content": "Du bist ein präziser Datenanalyst..."},
        {"role": "user", "content": "Analysiere folgende Verkaufszahlen: [...]"},
        {"role": "assistant", "content": "Analyse: Die Zahlen zeigen..."}  # Ground Truth
    ]
}

SFT funktioniert gut wenn:

• Du klare richtige Antworten hast (Klassifikation, strukturierte Extraktion)
• Deine Ground-Truth-Daten hochwertig sind
• Der Task wohldefiniert ist

SFT ist problematisch wenn:

• Es mehrere "richtige" Antworten gibt
• Du Modell-Verhalten formen willst, nicht nur Outputs
• Du Reasoning-Qualität trainieren willst

GRPO: Group Relative Policy Optimization

GRPO ist eine Variante von Reinforcement Learning from Human Feedback (RLHF), die 2024/2025 stark an Bedeutung gewonnen hat — vor allem durch DeepSeeks Erfolge.

Der Kernunterschied zu SFT: Statt auf festen "richtigen" Antworten zu trainieren, lernt das Modell aus relativem Feedback innerhalb einer Gruppe von generierten Antworten.

Wie GRPO funktioniert (vereinfacht)

1. Das Modell generiert mehrere Antworten auf dieselbe Anfrage (z.B. 8 Varianten)
2. Jede Antwort bekommt einen Reward-Score (Korrektheit, Format, Qualität)
3. Antworten besser als der Gruppen-Durchschnitt werden positiv verstärkt
4. Antworten schlechter als Durchschnitt werden negativ bestraft

# Schematisch: Reward-Funktion für mathematische Aufgaben
def compute_reward(generated_answer: str, correct_answer: str) -> float:
    # Format-Check: Antwort im erwarteten Format?
    format_score = 1.0 if is_valid_format(generated_answer) else 0.0

    # Korrektheit: Numerisch korrekt?
    correctness_score = 1.0 if extract_number(generated_answer) == float(correct_answer) else 0.0

    # Reasoning-Qualität: Wurden Schritte gezeigt?
    reasoning_score = evaluate_reasoning_steps(generated_answer)

    return 0.3 * format_score + 0.5 * correctness_score + 0.2 * reasoning_score

Wann GRPO besser ist als SFT

GRPO ist besser bei:

• Mathematischen / logischen Reasoning-Tasks
• Code-Generierung (wo Correctness klar messbar ist)
• Tasks mit definierbaren Qualitätskriterien ohne feste "beste Antwort"

SFT ist besser bei:

• Stil- und Format-Anpassung
• Domänen-Vokabular einbetten
• Einfachen Klassifikations- oder Extraktions-Tasks

RULER: Evaluierung, die nichts beschönigt

Das dritte Element: Wie misst man, ob das Fine-Tuning überhaupt funktioniert hat?

RULER (Rule-based Evaluation with LLM-generated References) ist ein Evaluierungs-Framework, das 2024 etabliert wurde. Der Kerngedanke: Statt manueller Human-Evaluation oder simplen String-Matches verwendet RULER ein separates LLM als Judge — aber mit regelbasierten Checks als Anker.

Das Problem mit naiven Benchmarks

• Accuracy auf Testset: Gibt es Leakage? Ist der Testset repräsentativ?
• BLEU/ROUGE: Nur sinnvoll für exakte Antworten — für generative Tasks ungeeignet
• LLM-as-Judge ohne Anker: Anfällig für Bias, inkonsistente Scores

RULER-Prinzip in der Praxis

def ruler_evaluate(
    generated: str,
    reference: str,
    rules: list[str],
    judge_model: str = "claude-opus-4-6"
) -> dict:
    """
    Evaluiert Output gegen regelbasierte Kriterien mit LLM-Judge.
    """
    rules_str = "\n".join([f"- {r}" for r in rules])

    prompt = f"""Bewerte den generierten Output gegen den Referenz-Output.

Regeln (müssen erfüllt sein):
{rules_str}

Referenz: {reference}
Generiert: {generated}

Bewerte jede Regel mit: ERFÜLLT / VERLETZT / NICHT_ANWENDBAR
Gib einen Gesamt-Score von 0.0 bis 1.0."""

    response = client.messages.create(
        model=judge_model,
        max_tokens=500,
        messages=[{"role": "user", "content": prompt}]
    )

    return parse_ruler_response(response.content[0].text)

# Beispiel-Regeln für Rechnungsextraktion
rules = [
    "Rechnungsnummer ist im korrekten Format (Buchstaben-Zahlen-Kombination)",
    "Datum im ISO-Format (YYYY-MM-DD)",
    "Gesamtbetrag stimmt mit Summe der Positionen überein",
    "Kein Feld ist halluziniert (nur extrahierte, keine erfundene Information)"
]

Die pragmatische Entscheidungsmatrix

Brauchst du Fine-Tuning?
│
├─ Nein → Gutes Prompting + RAG reicht
│
└─ Ja → Welche Methode?
   │
   ├─ Klare Ground Truth + einfache Anpassung → SFT
   │
   └─ Reasoning + mehrere valide Outputs → GRPO
      │
      └─ Evaluierung → RULER-Framework

Was das konkret für Enterprise-Teams bedeutet

Wenn euer Use Case Fine-Tuning rechtfertigt:

1. Startet mit SFT — einfacher, schneller, billiger für erste Validierung
2. Evaluiert mit RULER von Anfang an — nicht erst am Ende
3. Wechselt zu GRPO nur wenn SFT an klare Grenzen stößt (und ihr Reward-Design investieren wollt)
4. Plant Evaluierungs-Kosten ein — 10-15% des Trainingsbudgets für solide Eval ist keine Verschwendung

Das Wichtigste: Fine-Tuning ist kein Silberkugel. Ein gut implementierter RAG-Stack oder ein sorgfältig designter Prompt schlägt oft ein schlecht trainiertes Fine-tuned Modell.

Konkrete Fragen zu eurem Fine-Tuning-Use-Case? [Gespräch buchen](/kontakt)