Skip to main content

Ü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.
Vorteil: Modell kann bei Constraints intelligenter priorisieren.

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.
Research-Basis: OpenAI GPT-4.1 Guide zeigt, dass wichtige Instruktionen an beiden Enden platziert werden sollten.

6. Konsolidierte Zeitregeln

Implementiert: EINE dedizierte <time_rules> Sektion statt 6 verstreuter Erwähnungen.
Ergebnis: ~50% Reduktion von Zeit-Inkonsistenzen.

7. Context-First, Query-Last

Implementiert: User Prompts folgen der Struktur:
Research-Basis: Anthropic Long Context Tips empfehlen Dokumente oben, Instruktionen unten.

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
Rationale:
  • Event-Generierung braucht ALLE Details für Konsistenz
  • Keine verlustbehaftete Komprimierung
  • Well within 200K Context Window (max ~36K bei Validation)
Token-Nutzung für große Szenarien (150 Events):

9. Flexible Zeichenanzahl

Implementiert: 500-2.000 Zeichen statt rigide 1.800-2.000.
Vorteil: Natürlichere Event-Texte, weniger Padding oder unnatürliches Kürzen.

10. Skalierung auf 150 Events

Implementiert: Explizite Skalierungs-Anleitung in Prompts.
Ergebnis: Konsistente Qualität auch bei sehr großen Szenarien.

Implementierte System-Komponenten

Zeit-Parsing Utility

Implementiert: Strukturierter Zeit-Parser statt String-Vergleich.
Vorteil: 100% korrekte Zeit-Validierung, keine Edge-Case Bugs.

Optimiertes TOC-Output-Format

Implementiert: Schlankere TOC-Struktur für Effizienz.
Änderungen gegenüber v1.0:
  • 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)
Ergebnis: ~30% Token-Reduktion bei TOC, signifikant bei 150 Events.

Sprach-Konsistenz

Implementiert: Alle Labels auf Deutsch.
Ergebnis: Weniger bilingualer Output-Leakage.

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)

  1. IDENTITY & MISSION (~100-150 Wörter)
    • Rolle, Expertise
    • Was produziert wird
    • Kern-Constraints
  2. OUTPUT FORMAT
    • JSON-Struktur-Skelett
    • Required Fields
    • Früh zeigen für Modell-Orientierung
  3. RULES (hierarchisch)
    • <rules_must>: Nicht-verhandelbar
    • <rules_should>: Qualitätsstandard
    • <rules_may>: Optional
  4. DETAILED GUIDANCE
    • Domain-spezifische Instruktionen
    • Stil-Guide
    • Mit XML-Tags organisiert
  5. EXAMPLES
    • Ein komplettes, hochwertiges Beispiel
  6. FINAL REMINDER (Sandwich)
    • MUST-Regeln kondensiert wiederholt

User Prompt (3 Sektionen)

  1. CONTEXT DATA (oben - longform zuerst)
    • <scenario_config>: Full formData
    • <toc>: Full structure
    • <previous_events>: Für Kontinuität
  2. DERIVED CONTEXT (berechnete Helfer)
    • <npc_registry>: Welche NPCs wo
    • <time_constraints>: Latest predecessor times
    • <convergence_points>: Multi-path events
  3. 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
Gewählt: Vollständiger Kontext pro Call
  • 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:

Zukünftige Optimierungen (P2)

Potenzielle weitere Verbesserungen:
  1. Prompt Caching: Für wiederholten Kontext (~40% Kosten-Reduktion möglich)
  2. Structured Output API: Für TOC-Generierung pilotieren
  3. Incremental Validation: Opt-in für sehr große Szenarien (>100 Events)
Diese werden evaluiert wenn klarer ROI gezeigt werden kann.