Post 7.2: Quality Comparison Redux – Fairer Vergleich mit Llama-3.1-8B

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub

In Post 7.1 haben wir Dataset-Generierung auf 15 Minuten beschleunigt - ein 9× Speedup der iterative Entwicklung praktikabel macht. Statt 138 Minuten pro Run können wir jetzt 4 Experimente pro Stunde durchführen. Das ermöglicht systematisches Testing verschiedener Models, Prompts und Parameter.

Jetzt nutzen wir diese schnelle Iteration: Kann ein besseres Model die Quality von Mistral-7B (77% in Post 7) in Richtung gpt-4o-mini (93%) steigern? Bei 15 Minuten pro Run können wir 3-4 Models in unter einer Stunde testen - was früher einen ganzen Arbeitstag gekostet hätte.

Also los: Wir testen Llama-3.1-8B systematisch gegen Mistral-7B. Gleiche Daten, faire Vergleichbarkeit, reproduzierbare Methodik. Doch bereits beim Setup für diesen Vergleich stolpern wir über ein fundamentales Problem: Die Quality-Bewertung aus Post 7 hatte methodische Fehler.

Die Zahlen passen nicht zusammen. 100% A-Quality bei Llama? Unmöglich. Die Analyse zeigt: Die Bewertung hatte keinen Zugriff auf die originalen Chunks - Halluzinationen waren nicht erkennbar. Unterschiedliche Sample-Auswahl bei jedem Run machte Vergleiche invalid. Die Zahlen aus Post 7 sind wertlos.

Learning: Doppelt und dreifach prüfen. Auch eigene Analysen.

Was dieser Post leistet: Wir führen einen methodisch sauberen Vergleich durch - identische Samples für alle Models, vollständige Chunks, reproduzierbare Methodik. Die Ergebnisse sind ernüchternd und ermutigend zugleich.

TL;DR – Für eilige Leser

Setup: Llama-3.1-8B & Mistral-7B auf vLLM, GPT-4o-mini als Baseline, identische 20 Samples (60 QA-Pairs pro Model)

Ergebnisse – Fairer Vergleich:

Konsistenz über 3 Bewertungen:

Key Findings:

1. Zero Hallucinations mit vollständigen Chunks - Alle drei Models bleiben faktentreu (0 Halluzinationen)
2. Llama konsistent besser als Mistral - Über alle 3 Bewertungen, trotz unterschiedlicher Sample-Sets
3. Sample Selection Bias ist massiv - Llama auf “einfachen” Samples: 97.9%, auf fairen Samples: 93.3% (4.6pp Unterschied!)
4. Methodische Sorgfalt ist essentiell - Ohne identische Samples vergleichst du Sample-Schwierigkeit, nicht Model-Quality
5. 93% ist gut genug für Dataset Generation - Unterschied zu GPT (7pp) akzeptabel für Batch Use Cases

Warum das wichtig ist:

• Data Sovereignty funktioniert: Llama-3.1-8B liefert 93.3% A-Quality bei kompletter Datenkontrolle
• Realistische Erwartungen: 90%+ reicht für Dataset Generation (Post-processing, Volume, Error Handling)
• End-to-End Denken: Chunking-Entscheidungen (Post 4) beeinflussen Quality-Bewertung (Post 7.2)
• Instruction-Following exzellent: Alle Models folgen “STRICTLY based on chunk” zuverlässig

Im nächsten Post: LLM-as-Judge auch self-hosted. Wir schließen die letzte Lücke in der Data-Sovereign Pipeline - Quality Evaluation ohne externe APIs.

Inhaltsverzeichnis

• Warnsignale: Als die Zahlen nicht mehr passten
• Verbesserte Methodologie: Fairer Vergleich
• Ergebnisse: Fairer Vergleich auf identischen Samples
• Konsistenz über drei Bewertungen
• Performance & Praktische Aspekte
• Realistische Erwartungen für Dataset Generation
• Warum Llama-3.1-8B die beste Wahl ist
• Learnings & Critical Takeaways
• Code & Daten
• Fazit

Warnsignale: Als die Zahlen nicht mehr passten

Für diesen Post wollten wir Llama-3.1-8B als drittes Model hinzufügen. Die ersten Ergebnisse waren verdächtig:

Llama-3.1-8B: 100% A-Quality (60/60 Pairs) 🤔
Mistral-7B (Post 7): 77% A-Quality
Mistral-7B (neuer Test): 84.4% A-Quality

Das passt nicht zusammen. Kein Model ist perfekt, und die Mistral-Zahlen schwanken um 7pp. Zeit für eine gründliche Analyse der Methodik.

Die Kaskade der Entdeckungen

Erste Entdeckung: Chunks fehlen bzw. sind gekürzt

Beim Vergleich der Bewertungs-Files:

# quality_comparison_for_review.md (Post 7)
### Original Chunk Content
*Chunk not found*    # ❌ Für ALLE Samples!

# quality_comparison_Mistral_7B.md (neue Version)
### Original Chunk Content

[First 1000 chars...]... [truncated]    # ⚠️ Gekürzt!

Post 7: Keine Chunks → Halluzinationen nicht erkennbar
Neue Reviews: Nur erste 1000 Zeichen → False Positives möglich

Warum truncated Chunks problematisch sind:

Sample: amazon-faq-6

Chunk (truncated nach 1000 chars):
"With Amazon MQ, you pay for broker instance usage, 
 storage usage, and standard data transfer fees..."
[ABGESCHNITTEN - Compliance-Infos fehlen]

Full Chunk enthält am Ende:
"Amazon MQ is compliant with: HIPAA eligible, PCI DSS 
 compliant, SOC 1,2,3, ISO 9001, 27001..."

Generated Q&A:
Q: "What compliance programs is Amazon MQ eligible for?"
A: "HIPAA eligible, PCI DSS compliant, SOC 1,2,3 compliant, 
    ISO 9001, 27001, 27017, and 27018 certified"

Mit truncated chunk: ❌ FALSE POSITIVE - sieht aus wie Halluzination
                       (Compliance-Info nicht im sichtbaren Teil)
Mit full chunk: ✅ KORREKT - Info steht am Ende des Chunks

Das Problem: Model generiert basierend auf dem vollen Chunk, aber der Reviewer sieht nur die ersten 1000 Zeichen. Info die hinten im Chunk steht, ist nicht verifizierbar → korrekte Antworten sehen aus wie Halluzinationen.

Das erklärt warum in Post 7 kein Halluzination-Check stattfand:

• Ohne Chunks: Verifikation unmöglich → Check übersprungen
• Mit truncated Chunks: Verifikation unzuverlässig → False Positives möglich
• Für beide: Keine aussagekräftigen Zahlen

Zweite Entdeckung: Kein Random Seed

Im Original-Script:

# prepare_review_for_claude.py (alte Version)
sampled_chunks = random.sample(common_chunks, n_samples)  # ❌ Kein seed!

Jeder Bewertungs-Run wählte zufällige Samples. Kein Wunder, dass die Zahlen schwankten - wir verglichen jedes Mal andere Chunks!

Dritte Entdeckung: Seed hilft nicht (unterschiedliche common_chunks)

Okay, also random.seed(42) hinzufügen und fertig? Nicht ganz.

# Script Logic
common_chunks = set(chunks_all) & set(gpt4_pairs) & set(model_b_pairs)
sampled = random.sample(list(common_chunks), n_samples)

Problem: Mistral und Llama haben unterschiedlich viele Chunks:

• Mistral: 1846 Chunks (33 failed)
• Llama: 1875 Chunks (14 failed)

→ common_chunks ist unterschiedlich für Mistral vs Llama
→ random.sample() mit seed=42 wählt trotzdem verschiedene Chunks
→ Mistral-Bewertung und Llama-Bewertung nutzen verschiedene Samples!

Beispiel:

# Mistral Review
common_chunks_mistral = {chunk1, chunk2, ..., chunk1846}  # 1846 Chunks
random.seed(42)
samples_mistral = random.sample(common_chunks_mistral, 20)
# → [chunk_7, chunk_42, chunk_103, ...]

# Llama Bewertung  
common_chunks_llama = {chunk1, chunk2, ..., chunk1875}   # 1875 Chunks
random.seed(42)
samples_llama = random.sample(common_chunks_llama, 20)
# → [chunk_15, chunk_89, chunk_201, ...]   # ANDERE Chunks!

Die vollständige Diagnose:

1. Post 7: Keine Chunks → keine Halluzination-Detection
2. Neue Reviews: Truncated Chunks → limitierte Verification
3. Alle Reviews: Kein seed → zufällige Sample-Auswahl
4. Mistral vs Llama: Unterschiedliche common_chunks trotz seed
5. Konsequenz: Keine zwei Reviews sind vergleichbar

Das war der Weckruf: Komplettes Re-Design nötig - identische Samples für ALLE Models, vollständige Chunks, reproduzierbare Methodik.

Verbesserte Methodologie: Fairer Vergleich

Wir haben die Evaluation von Grund auf neu aufgesetzt - mit methodischer Sorgfalt:

1. Identische Samples für alle Models

Neues Script:

def prepare_fair_comparison():
    # Load all QA pairs
    gpt4_pairs = load_qa_pairs('qa_pairs_gpt4o_mini.jsonl')
    mistral_pairs = load_qa_pairs('qa_pairs_mistral.jsonl')
    llama_pairs = load_qa_pairs('qa_pairs_llama.jsonl')
    
    # Find COMMON chunks (present in ALL THREE models)
    common_all_three = (
        set(gpt4_pairs.keys()) & 
        set(mistral_pairs.keys()) & 
        set(llama_pairs.keys())
    )
    
    print(f"Common to all three: {len(common_all_three)} chunks")
    # Output: Common to all three: 1846 chunks ✅
    
    # Stratified sampling with fixed seed
    random.seed(42)
    selected_chunks = stratified_sample(common_all_three, n=20)
    
    # Generate review files with IDENTICAL samples
    generate_review(selected_chunks, 'Mistral-7B', mistral_pairs)
    generate_review(selected_chunks, 'Llama-3.1-8B', llama_pairs)

Ergebnis:

• 1846 Chunks verfügbar in allen drei Models
• 20 Samples stratifiziert über AWS Services
• Identische chunk_ids in beiden Bewertungs-Files ✅

Verification:

$ diff <(grep "^## Sample" quality_comparison_Mistral_FAIR.md) \
       <(grep "^## Sample" quality_comparison_Llama_FAIR.md)
# Output: (keine Unterschiede) ✅

2. Vollständige Chunks

Alte Version:

# Truncate chunks
if len(content) > 1000:
    content = content[:1000] + "... [truncated]"  # ❌

Neue Version:

# NO truncation - full chunks
content = chunk.get('content')  # ✅ Voller Content

Wie in der Kaskade gezeigt: Truncated Chunks erzeugen False Positives, weil der Reviewer nicht den kompletten Context sieht, den das Model während der Generation hatte.

3. Reproduzierbare Methodik

Random Seed:

RANDOM_SEED = 42  # Fixed for reproducibility
random.seed(RANDOM_SEED)

Documented Process:

# quality_comparison_Mistral_FAIR.md
**Random Seed:** 42
**Fairer Vergleich:** YES - identical samples for both models

Sample Distribution dokumentiert:

| Service | Count |
|---------|-------|
| amazon | 1 |
| amplify | 1 |
| api | 1 |
...
| cloudformation | 1 |

→ Jeder kann die Evaluation reproduzieren
→ Results sind nachvollziehbar
→ Methodisch sauber

Ergebnisse: Fairer Vergleich auf identischen Samples

Systematische Bewertung aller 20 Samples (60 QA-Pairs pro Model) mit vollständigem Chunk-Zugriff:

Quality Distribution

Die wichtigste Erkenntnis: Zero Hallucinations bei allen drei Models! Mit vollständigem Chunk-Zugriff blieben alle Models faktentreu.

Llama-3.1-8B: 93.3% A-Quality

Stärken:

• ✅ Faktisch präzise (0 Halluzinationen)
• ✅ Konsistent gute Performance
• ✅ Natürliche Fragen
• ✅ Vollständige Antworten

B-Ratings (4 Fälle):

1. Sample 1: Awkward phrasing (“paid plan will allow you to use remaining credit”)
2. Sample 2: Minor interpretation (“simplifies cost management” - nicht im Chunk)
3. Sample 16: Best practices hint (“use consistent naming” - nicht im Chunk)

Muster: Llama tendiert zu leichten Interpretationen über den Chunk hinaus - sachlich korrekt, aber nicht strikt ableitbar.

Mistral-7B: 90.0% A-Quality

Stärken:

• ✅ Faktisch korrekt (0 Halluzinationen)
• ✅ Comprehensive answers
• ✅ Good chunk coverage

B-Ratings (6 Fälle):

1. Sample 2: Spekulation (“to ensure fairness” - nicht im Chunk)
2. Sample 15: Spekulation (“typically quick” - nicht im Chunk)
3. Sample 16: Best practices (nicht im Chunk)
4. Sample 17: Faktischer Fehler - Wildcard Subdomain Coverage falsch erklärt

Muster: Mistral spekuliert etwas häufiger Speculation und hat einen tatsächlichen Fehler (Sample 17).

GPT-4o-mini: 100% A-Quality

Perfekte Performance auf diesen 20 Samples - setzt die Baseline. Alle 60 Pairs waren faktisch korrekt, gut formuliert, und vollständig.

Warum keine Detailanalyse? GPT-4o-mini ist extern gehostet und steht nicht zur Diskussion für unseren self-hosted Anwendungsfall. Die Frage ist nicht “Wie gut ist GPT?” (Antwort: exzellent), sondern “Wie nah kommen self-hosted Alternativen ran?”

Der folgende Vergleich fokussiert daher auf Llama-3.1-8B vs Mistral-7B als realistische self-hosted Optionen.

Konsistenz über drei Bewertungen

Ein kritischer Test: Wie stabil sind die Ergebnisse über verschiedene Sample-Sets?

Erkenntnis: Trotz unterschiedlicher Sample-Sets war Llama konsistent besser als Mistral. Das ist eine robuste Aussage.

Sample Selection Bias ist real:

• Llama auf “einfachen” Samples (Set B): 97.9%
• Llama auf FAIR Samples (Set C): 93.3%
• 4.6pp Unterschied nur durch Sample-Wahl!

Lesson: Fairer Vergleich erfordert identische Samples - sonst vergleichst du Sample-Schwierigkeit, nicht Model-Quality.

Performance & Praktische Aspekte

Neben Quality auch Performance-Daten von den vollständigen Runs:

Runtime & Durchsatz

Interpretation:

Nicht überbewerten: Der absolute Zeitunterschied ist klein (3 Minuten bei ~13-15 Minuten Runtime). Mögliche Einflussfaktoren:

• Netzwerklatenz (Llama auf einem Node, Mistral distributed?)
• Cluster-Load zur Laufzeit
• Scheduling-Unterschiede
• Random variance

Wichtiger: Die höhere Erfolgsrate bei Llama (99.3% vs 98.3%) bedeutet weniger Failed Chunks und damit weniger manuelle Nacharbeit.

Cost-Überlegungen

Bei self-hosting mit scale-to-zero hängen Kosten direkt von GPU-Zeit ab:

GPU Cost = Stundensatz × Runtime

Beispiel: L4 GPU auf AWS (~$1.01/Stunde)
- Llama: 12.6 min = 0.210h × $0.50 = $0.2121
- Mistral: 15.3 min = 0.255h × $0.50 = $0.25755
- Differenz: $0.045 (21% teurer für Mistral)

Aber: Für 1932 Chunks sind beide vernachlässigbar ($0.21 vs $0.26). Der Kostenunterschied ist praktisch irrelevant.

Entscheidend ist hier die Qualität, nicht die Kosten.

Realistische Erwartungen für Dataset Generation

Der 10pp Abstand zu GPT-4o-mini

Die Zahlen:

• GPT-4o-mini: 100% A-Quality
• Llama-3.1-8B: 93.3% A-Quality
• Gap: 6.7 Prozentpunkte

Ist das viel?

Kommt auf den Anwendungsfall an:

Warum 93% für Dataset Generation gut genug ist:

1. Post-processing möglich

   • Validation Layer
   • Filtering (entferne B/C-rated Pairs)
   • Human-in-the-loop für Edge Cases

2. Iterativ & error-tolerant

   • Nicht zeitkritisch (Batch Processing)
   • Failures sind okay (99% Erfolgsrate)
   • Re-runs kosten wenig

3. Volume matters

   • 5000+ QA-Pairs generiert
   • 93% = ~4650 high-quality pairs
   • Mehr als ausreichend für Fine-tuning

4. Error Handling braucht man IMMER

Auch GPT-4o kann:

• JSON-Parsing Errors produzieren
• API Rate Limits erreichen
• Timeouts haben
• Retries brauchen

Der Unterschied: Bei self-hosted hast du Kontrolle über Error Handling UND über die Daten.

Zero Hallucinations = Kritischer Erfolg

Alle drei Models: 0 Halluzinationen mit vollständigen Chunks.

Das ist die wichtigste Metrik für Data Sovereignty:

• ✅ Models bleiben faktentreu
• ✅ Keine erfundenen AWS Services
• ✅ Keine falschen API Calls
• ✅ Keine imaginierten Konzepte

Warum das funktioniert:

# Instruction in system prompt
"Generate QA pairs STRICTLY based on the provided chunk. 
Do NOT add information not present in the chunk."

Zwei kritische Faktoren:

1. Models folgen Instructions exzellent

   • Llama-3.1-8B, Mistral-7B, GPT-4o-mini: Alle 0 Halluzinationen
   • “STRICTLY based on chunk” funktioniert zuverlässig
   • Starker Indikator für gute Instruction-Following Fähigkeiten

2. Vollständige Chunks ermöglichen korrektes Verhalten

Mit vollständigem Chunk-Zugriff können Models:

1. Chunk komplett lesen
2. Relevante Fakten extrahieren
3. Daraus QA-Pairs konstruieren
4. Innerhalb der Chunk-Grenzen bleiben

Truncated Chunks zerstören das:

• Model sieht nur ersten Teil
• Muss “raten” was danach kommt
• → Halluzinationen möglich

Lesson: End-to-End Denken in der Pipeline

Die Chunk-Größe in Post 4 (Dataset Engineering) hat direkte Auswirkungen auf Quality-Verifikation in Post 7.2:

1. Chunks nicht zu klein schneiden - Information vollständig halten
2. Recursive Chunker respektiert natürliche Sprachgrenzen - aus Post 4
3. Pipeline-Entscheidungen bauen aufeinander auf - Chunking → Generation → Review

Hier zeigt sich, warum es so wichtig ist, von Ende-zu-Ende zu denken: Gute Pipeline-Architektur bedeutet, diese Abhängigkeiten zu verstehen. Eine schlechte Entscheidung in Post 4 (zu kleine Chunks) würde sich erst in Post 7.2 (Quality Review) rächen.

Das ist Data Sovereignty in der Praxis: Kontrolle über jeden Schritt der Pipeline - von Chunking bis Generation bis Evaluation.

Warum Llama-3.1-8B die beste Wahl ist

Über alle Dimensionen betrachtet:

Qualität: Konsistent führend

Drei Reviews, drei Mal vorne:

• Post 7.2 FAIR: 93.3% (identische Samples)
• Konsistenter Abstand zu Mistral (~3-7pp)

Performance: Geringfügig besser

• 3 Minuten schneller (nicht dramatisch)
• 1pp höhere Erfolgsrate (weniger Nacharbeit)
• Mehr Output (74 zusätzliche Pairs)

Ökosystem: Weit verbreitet

• ✅ Aktive Meta/Community Support
• ✅ Exzellente vLLM Integration
• ✅ Viele LoRA Adapter verfügbar
• ✅ Gut dokumentiert

Der optimaler Punkt für Data Sovereignty

Llama-3.1-8B:
├─ Quality: 93.3% (nah an GPT, besser als Mistral)
├─ Hallucinations: 0% (faktentreu)
├─ Control: 100% (self-hosted)
├─ Cost: Vernachlässigbar (~$0.10 per run)
└─ Compliance: ✅ (data bleibt intern)

Für Dataset Generation: Llama bietet das beste Quality-to-Control Verhältnis.

Learnings & Critical Takeaways

1. Methodische Sorgfalt ist essentiell

Was wir gelernt haben:

❌ Fehler in Post 7:

• Keine Chunks → Halluzinationen nicht erkennbar
• Kein Seed → Samples nicht vergleichbar
• Inkonsistente Zahlen → Methodologie fraglich

✅ Fix in Post 7.2:

• Vollständige Chunks → Halluzination Detection
• Fixed Seed → Reproduzierbare Samples
• Identische Samples → Fairer Vergleich

Lesson: Bei LLM Evaluation gibt es keine Shortcuts. Jeder methodische Fehler verfälscht die Ergebnisse.

2. Sample Selection Bias ist massiv

Beweis:

• Llama auf Sample-Set B: 97.9%
• Llama auf Sample-Set C: 93.3%
• 4.6pp Unterschied nur durch Sample-Wahl!

Bei unfairen Samples:

• Model A bekommt “einfache” Chunks
• Model B bekommt “schwierige” Chunks
• Vergleich misst Sample-Schwierigkeit, nicht Model-Quality

Lesson:

• Fairer Vergleich MUSS identische Samples verwenden - sonst sind Zahlen wertlos.
• Wenn möglich, mehr Samples verwenden - dann sind prozentuale Abweichungen aussagekräftiger

3. Vollständige Chunks sind nicht optional

Impact auf Halluzination Detection:

Unterschied:

• Truncated: “0 Hallucinations” könnte falsch sein (can’t verify fully)
• Full: “0 Hallucinations” = Fakten (verified)

Lesson: Für Quality Reviews sind vollständige Chunks essentiell.

4. Self-hosting funktioniert für Dataset Generation

Die Zahlen belegen es:

• Llama-3.1-8B: 93.3% A-Quality
• Zero Hallucinations
• 99.3% Erfolgsrate
• ~$0.21 per 1932 Chunks

Aber: Dataset Generation ≠ Production RAG

Self-hosting optimaler Punkt: Batch-Processing Anwendungsfalls wie Dataset Generation, wo Fehler tolerierbar und Post-processing möglich ist.

5. Der Anwendungsfall bestimmt die Anforderungen

Warum 93% für uns gut genug ist:

Anwendungsfall: Synthetische QA-Paare für AWS FAQ Fine-tuning

Anforderungen:
├─ Volume: 5000+ Pairs ✅ (5785 generiert)
├─ Quality: Majority high-quality ✅ (93% A-rated)
├─ Factual: No hallucinations ✅ (0 detected)
├─ Data Sovereignty: Must stay internal ✅ (self-hosted)
└─ Cost: Budget-friendly ✅ (~$0.10)

Kompromiss akzeptabel:
├─ 7pp Quality-Gap zu GPT ✓ (93% vs 100%)
└─ Für full data control ✓

Anders bei Production RAG:

Anwendungsfall: Customer-facing AWS Documentation Chatbot

Anforderungen:
├─ Accuracy: 99%+ (customer trust)
├─ Latency: <500ms (UX)
├─ Uptime: 99.9% (SLA)
└─ Hallucinations: 0% (brand risk)

→ Möglicherweise GPT-4o-mini nötig
→ Kompromiss: Qualität > Data Control

Andere Sprache:
Unser Anwendungsfall ist ein englischsprachiges Dataset. Wie wären die Resultate, wenn es ein deutschsprachiges Dataset sein müsste? Möglicherweise wäre Mistral-7B die bessere Wahl.

Lesson: Es gibt keine “beste” Lösung - nur die beste Lösung für DEINEN Anwendungsfall.

Code & Daten

Dataset-Generierung: Die QA-Pairs wurden mit der parallelisierten Methode aus Post 7.1 generiert (15 Minuten pro Model). Die Performance Logs unten zeigen die Original-Runs. Review Script (neu in Post 7.2):

Review Script:

analyze_and_prepare_fair_comparison.py

Dieses Script implementiert den fairen Vergleich:

• Findet gemeinsame Chunks aller drei Modelle
• Wählt 20 identische Samples (seed=42)
• Generiert Review-Files mit vollständigen Chunks

Review Results:

• FINAL_FAIR_COMPARISON_Mistral_vs_Llama.md - Detaillierte Analyse beider Models
• quality_comparison_Mistral_7B_FAIR.md - 20 Samples, identisch
• quality_comparison_Llama_3.1_8B_FAIR.md - 20 Samples, identisch

Performance Logs:

# Llama-3.1-8B
Total duration: 12.6 minutes (758 seconds)
Success rate: 99.3% (1918/1932)
QA pairs generated: 5785
Throughput: 152.9 chunks/minute

# Mistral-7B  
Total duration: 15.3 minutes (915 seconds)
Success rate: 98.3% (1899/1932)
QA pairs generated: 5711
Throughput: 126.7 chunks/minute

Fazit

Post 7 hatte methodische Fehler - peinlich, aber lehrreich. Der komplette Re-Design der Evaluation zeigt: Methodische Sorgfalt ist nicht optional.

Was funktioniert:

Self-hosted Dataset Generation mit Llama-3.1-8B ist produktionsreif für Batch Anwendungsfälle:

• 93.3% A-Quality (7pp von GPT-4o-mini)
• Zero Hallucinations (mit vollständigen Chunks)
• Konsistent besser als Mistral (über 3 Reviews)
• 99.3% Success Rate, vernachlässigbare Kosten

Was wir gelernt haben:

1. Ein fairer Vergleich erfordert identische Samples - sonst vergleichst du Sample-Schwierigkeit, nicht Model-Quality
2. Vollständige Chunks sind essentiell - Truncation erzeugt False Positives
3. End-to-End Denken - Chunking-Entscheidungen (Post 4) beeinflussen Quality-Review (Post 7.2)
4. Der Anwendungsfall bestimmt die Anforderungen - 93% ist exzellent für Dataset Generation, aber vielleicht zu wenig für Production RAG
5. Instruction-Following funktioniert - Alle drei Models (Llama, Mistral, GPT) halten sich strikt an “STRICTLY based on chunk”

Der Sweet Spot:

Llama-3.1-8B trifft den Sweet Spot zwischen Quality und Data Sovereignty:

• Nah genug an GPT (93.3% vs 100%)
• Gut genug für Dataset Generierung (90%+ reicht)
• Volle Kontrolle über Daten und Pipeline
• Vernachlässigbare Kosten (~$0.21 per 1932 Chunks)

Data Sovereignty ist machbar - für die richtigen Anwendungsfalls. Batch Processing wie Datengenerierung ist ideal. Real-time Production RAG mit 99.9% Requirements? Da wird’s schwieriger.

Im nächsten Post: LLM-as-Judge auch self-hosted. Wir schließen die letzte Lücke in der Data Sovereignty Pipeline - Quality Evaluation ohne externe APIs.