Ü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.
Research-Basis: Claude 4 Best Practices empfehlen positive Instruktionen statt aggressive Verbote.
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)
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.
Vorteil:
- 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
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)

