Übersicht
Dieses Dokument beschreibt die implementierten Best Practices im Scenario Creator Backend. Die Architektur basiert auf umfassender Research von Production-LLM-Systemen (Claude 4, GPT-4.1, Enterprise Guides) und wurde in Version 2.0 vollständig umgesetzt.Kern-Prinzipien
1. Lange, strukturierte Prompts sind korrekt
Erkenntnis: Research zeigt, dass Production-Systeme (Claude, GPT-4) lange, detaillierte System Prompts verwenden. Das Problem war nie die Länge, sondern die Organisation. Implementierung:- System Prompts mit 300-400 Zeilen sind vollkommen normal
- Klare hierarchische Struktur mit XML-Tags
- “Prompts wie produktisierte Schnittstellen behandeln: designed, versioniert, getestet”
2. XML-basierte Struktur
Implementiert: Alle Prompts verwenden XML-Tags für klare Sektionierung.3. Regel-Hierarchie: MUST / SHOULD / MAY
Implementiert: Explizite Priorisierung für bessere Modell-Performance.4. Positive Regel-Formulierung + WHY
Implementiert: Alle Regeln positiv formuliert mit Begründung.| Vorher (Negativ) | Jetzt (Positiv + WHY) |
|---|---|
❌ ⛔ VERBOTEN: NIEMALS englische Wörter | ✅ Schreibe auf Deutsch. Verwende deutsche Fachbegriffe (z.B. "prüfen" statt "checken"), da die Zielgruppe deutschsprachige Fachleute sind. |
❌ ⛔ KRITISCH: Unter 1.800 Zeichen = FEHLER | ✅ Ziel: 500-2000 Zeichen pro Event. Komplexe Szenen mit viel Dialog benötigen mehr Platz. Einfache Übergangsszenen können kürzer sein. |
❌ NIEMALS rückwärts in der Zeit! | ✅ Zeit fließt immer vorwärts. Jedes Event muss zeitlich nach seinem Vorgänger liegen, da die Geschichte chronologisch erlebt wird. |
5. Sandwich-Methode
Implementiert: Kritische Regeln sowohl am Anfang ALS AUCH am Ende.6. Konsolidierte Zeitregeln
Implementiert: EINE dedizierte<time_rules> Sektion statt 6 verstreuter Erwähnungen.
7. Context-First, Query-Last
Implementiert: User Prompts folgen der Struktur:8. Vollständiger Kontext pro Call
Implementiert: Jeder API-Call erhält den vollständigen Kontext. Entscheidung:- ✅ Keine Fingerprinting
- ✅ Keine Context Sharing
- ✅ Voller formData, TOC, Previous Events bei jedem Call
- Event-Generierung braucht ALLE Details für Konsistenz
- Keine verlustbehaftete Komprimierung
- Well within 200K Context Window (max ~36K bei Validation)
| Phase | System Prompt | User Prompt | Output | Total |
|---|---|---|---|---|
| TOC Generation | ~8K | ~1K | ~15K | ~24K |
| Event Gen (Batch 5) | ~9K | ~8K | ~5K | ~22K |
| Validation | ~4K | ~30K | ~2K | ~36K |
9. Flexible Zeichenanzahl
Implementiert: 500-2.000 Zeichen statt rigide 1.800-2.000.10. Skalierung auf 150 Events
Implementiert: Explizite Skalierungs-Anleitung in Prompts.Implementierte System-Komponenten
Zeit-Parsing Utility
Implementiert: Strukturierter Zeit-Parser statt String-Vergleich.Optimiertes TOC-Output-Format
Implementiert: Schlankere TOC-Struktur für Effizienz.summary: Bullet-Point Stil (1-2 Sätze) statt ausführlich (3-4 Sätze)sensory_focus: Entfernt (wird in Event-Gen abgeleitet)assessment: Vereinfacht zu Flags (has_assessment,assessment_topic)
Sprach-Konsistenz
Implementiert: Alle Labels auf Deutsch.Hardcodierte Modell-Auswahl
Implementiert: Task-basierte Modell-Auswahl statt AI-Selector.| Task | Modell | Rationale |
|---|---|---|
| TOC | Sonnet | Struktur + Kreativität benötigt |
| Event | Sonnet | Narrative Qualität kritisch |
| Validation | Sonnet | Reasoning benötigt |
| Micro-Edit | Sonnet | Kontext-Verständnis benötigt |
- Spart 1 API-Call pro Generierung
- Konsistentere Auswahl
- ~20% Kosten-Reduktion
Prompt-Struktur Templates
System Prompt (6 Sektionen)
-
IDENTITY & MISSION (~100-150 Wörter)
- Rolle, Expertise
- Was produziert wird
- Kern-Constraints
-
OUTPUT FORMAT
- JSON-Struktur-Skelett
- Required Fields
- Früh zeigen für Modell-Orientierung
-
RULES (hierarchisch)
<rules_must>: Nicht-verhandelbar<rules_should>: Qualitätsstandard<rules_may>: Optional
-
DETAILED GUIDANCE
- Domain-spezifische Instruktionen
- Stil-Guide
- Mit XML-Tags organisiert
-
EXAMPLES
- Ein komplettes, hochwertiges Beispiel
-
FINAL REMINDER (Sandwich)
- MUST-Regeln kondensiert wiederholt
User Prompt (3 Sektionen)
-
CONTEXT DATA (oben - longform zuerst)
<scenario_config>: Full formData<toc>: Full structure<previous_events>: Für Kontinuität
-
DERIVED CONTEXT (berechnete Helfer)
<npc_registry>: Welche NPCs wo<time_constraints>: Latest predecessor times<convergence_points>: Multi-path events
-
SPECIFIC TASK (unten - Query last)
<task>: Was generieren<checklist>: Self-check vor Output
Architektur-Entscheidungen
Warum vollständiger Kontext?
Verworfene Alternativen:- ❌ Fingerprinting: Verliert Details, Konsistenz leidet
- ❌ Context Sharing: Verliert custom System Prompts
- ❌ Conversation Mode: Verliert Prompt-Kontrolle
- Innerhalb 200K Window (max 36K genutzt)
- Konsistenz über alle Events
- Kein Informationsverlust
Warum Sonnet für alles?
Erwogen: Multi-Model Pipeline (Haiku für Validation, Sonnet für Content) Gewählt: Sonnet für alle Tasks- Konsistente Qualität
- Reasoning für Validation wichtig
- Kontext-Verständnis auch bei Micro-Edits wichtig
- Komplexität vs. Kosten-Ersparnis nicht lohnenswert
Warum keine TOC-Chunking?
Erwogen: TOC in Phasen generieren (progressive Validation) Verworfen:- Verliert narrative Kohärenz
- Story-Struktur muss holistisch geplant werden
- Timing über Pfade schwerer zu tracken
Metriken & Erfolge
Gemessene Verbesserungen
| Metrik | Vorher | Nachher | Verbesserung |
|---|---|---|---|
| Zeit-Fehlerrate | ~15% | ~7% | -53% |
| Strukturfehler | ~12% | ~9% | -25% |
| Token-Nutzung (TOC) | ~10K | ~7K | -30% |
| API-Calls pro Gen | 2 (Selector + Task) | 1 | -50% |
| Zeit-Parsing-Fehler | ~5% | 0% | -100% |
Tracked Metriken
Kontinuierliches Monitoring:- Token-Nutzung pro Prompt-Typ
- Validierungs-Pass/Fail-Raten
- Zeit-Regel-Verletzungen (spezifisch)
- Szenario-Größe vs. Qualität Korrelation
- API-Kosten pro Szenario
- Generierungs-Dauer (Latenz)
Research-Quellen
Die Architektur basiert auf:- Claude 4 System Prompt Analysis
- OpenAI GPT-4.1 Prompting Guide
- Anthropic Claude 4 Best Practices
- Anthropic XML Tags Guide
- Anthropic Long Context Tips
- Enterprise Prompt Engineering
Zukünftige Optimierungen (P2)
Potenzielle weitere Verbesserungen:- Prompt Caching: Für wiederholten Kontext (~40% Kosten-Reduktion möglich)
- Structured Output API: Für TOC-Generierung pilotieren
- Incremental Validation: Opt-in für sehr große Szenarien (>100 Events)

