Technische Schwachstellen & Limits

Hier analysieren wir die realen technischen Engpässe des Gesamtsystems und wie ihnen in Produktion begegnet werden muss.

---

1. ReAct Loop Latenz (Die "5-Hop"-Falle)

Die Schwachstelle

Im ReAct-Loop von AgenticChatService entscheidet das Modell iterativ über Werkzeug-Aufrufe.

• Schritt 1: Prompt analysieren ➔ Tool-Call search_lore (Dauer: ~1,5s LLM + ~50ms Directus)
• Schritt 2: Ergebnis lesen ➔ Tool-Call get_entity_state (Dauer: ~1,5s LLM + ~50ms Directus)
• Schritt 3: Szene verfassen ➔ Tool-Call persist_scene (Dauer: ~3s LLM + ~50ms Directus)
• Schritt 4: Antwort formulieren ➔ (Dauer: ~2s LLM)

Gesamtlaufzeit: 8 bis 15 Sekunden für einen einzigen Chat-Turn!

Gegenmaßnahmen

• Parallel Tool Calling: Das Modell instruieren, unabhängige Recherchen (z. B. 3 Charaktere gleichzeitig) in einem einzigen Schritt als paralleles Tool-Calling-Array anzufordern.
• Stream-Modus / WebSockets: Dem Benutzer während der Denkpause Zwischenschritte ("Suche Vaelin im Kanon...") in Echtzeit anzeigen, um die gefühlte Wartezeit zu minimieren.

---

2. Partielle Persistierungsfehler (Fehlende ACID-Transaktion über HTTP)

Die Schwachstelle

Der Agent ruft nacheinander HTTP-Endpunkte auf:

1. persist_scene ➔ Szene wird in Directus angelegt (Erfolg).
2. record_lore_state ➔ State-Patch soll gespeichert werden (Netzwerk-Timeout oder Directus-Fehler).

Ergebnis: Die Szene ist in der Datenbank vorhanden, aber die daraus resultierende Verwundung der Figur fehlt! Das System befindet sich in einem inkonsistenten Zustand.

Gegenmaßnahmen

• Kompensation / Rollback: Schlägt ein Folgeschritt fehl, löscht der Service die erstellte Szene wieder (Kompensierende Transaktion).
• Directus Batch-Payloads: Bündelung von Szenenerstellung und Status-Update in einen einzelnen transaktionssicheren Request.

---

3. Token-Kosten & Context Accumulation

Die Schwachstelle

Mit jeder Tool-Ausführung wächst die Konversationshistorie im ReAct-Loop rasant an: Jedes Suchergebnis aus Directus (auch ungenutzte Datenfelder) wird als Tool-Message in den Kontext zurückgeschrieben. Bei 5 Iterationen können 15.000+ Tokens zusammenkommen.

Gegenmaßnahmen

• Tool Result Minification: Directus-Ergebnisse vor der Rückgabe an das LLM bereinigen (unwichtige Systemfelder wie created_at, updated_at, user_created herausfiltern).
• Token Pruning: Bei langen Multi-Turn Chats alte Tool-Meldungen nach erfolgreicher Antwort aus dem Cache entfernen.

---

4. Ausfall von Modell-Providern (Rate Limits & Spend Caps)

Die Schwachstelle

Wie in realen Testläufen beobachtet, können externe Provider wie Google Gemini plötzlich mit 429 RESOURCE_EXHAUSTED oder spending cap exceeded abbrechen.

Gegenmaßnahmen

• LiteLLM Fallback-Kaskaden: In litellm_config.yaml können Fallback-Modelle hinterlegt werden:

  router-model:
    - gemini/gemini-2.5-flash
    - gpt-4o-mini
    - claude-3-haiku

  Fällt Gemini aus, schwenkt LiteLLM innerhalb von Millisekunden transparent auf OpenAI oder Anthropic um, ohne dass der Fastify-Server einen Fehler bemerkt.