Deterministische vs. Agentische Workflows: Erkenntnisse aus der Entwicklung eines Shopping Assistants

Erkenntnisse zu deterministischen Workflows, agentischer Argumentation und Zustandsverwaltung (State Management)

Die Entwicklung von KI-Assistenten beginnt oft mit einer trügerisch einfachen Aufgabe. Ein Benutzer stellt eine Frage, das System ruft Informationen ab und ein LLM generiert eine Antwort. Die erste Version funktioniert meist erstaunlich gut.

Die echte Herausforderung entsteht, wenn die Funktionen erweitert werden. Mit der Einführung neuer Tools und Workflows beginnen Benutzer, Fragen zu stellen, die sich über mehrere Bereiche erstrecken. Gespräche werden länger und kontextbezogener, wodurch sich der Assistent von einem einfachen QA-Bot zu einem Werkzeug wandelt, das Benutzern bei der Bewältigung komplexer Aufgaben hilft.

Bei TrueFoundry standen wir genau vor dieser Herausforderung, als wir einen dialogorientierten Shopping Assistant entwickelten. Der Assistent begann als Begleiter für Produktdetailseiten (Product Detail Pages, PDP), der Fragen zu einem einzelnen Produkt beantworten konnte. Im Laufe der Zeit entwickelte er sich zu einem katalogweiten Shopping Assistant, der in der Lage ist, Produktsuche, Datenabruf, Zusammenfassung von Bewertungen, Gutscheinverarbeitung, Filialsuche, Bestandsprüfungen, Abwicklungsauswahl und Warenkorb-Aktionen zu handhaben.

Während sich die externen Funktionen erheblich erweiterten, traten die kritischsten technologischen Herausforderungen in zwei Bereichen auf:

1. Entscheidung, wann deterministische Workflows und wann agentische Argumentation (Agentic Reasoning) eingesetzt werden sollen.
2. Weiterentwicklung der Zustandsverwaltung von einem Einzelprodukt-Gesprächsmodell zu einem Shopping-Erlebnis für mehrere Produkte.

1. Überblick über die Systemarchitektur

Der Shopping Assistant basiert auf vier wesentlichen Architekturschichten, die darauf ausgelegt sind, Leistung, Kosten und Zuverlässigkeit in Einklang zu bringen.

A. Datenschicht (Data Layer)

Das System hält eine strikte Trennung zwischen strukturierten und unstrukturierten Speichersystemen aufrecht:

• Produktkatalog: Gespeichert in PostgreSQL (Cloud SQL), enthält Produktmetadaten, Preise, Varianten, Kategorieinformationen und Abwicklungsmetadaten.
• Bewertungen: Kundenbewertungen werden in Qdrant gespeichert. Dies ermöglicht den semantischen Abruf von Bewertungsinhalten, anstatt sich ausschließlich auf Keyword-Matching zu verlassen. Wenn Benutzer semantische Fragen stellen wie „Was sagen Kunden über die Akkulaufzeit?“, ruft das System relevante Bewertungen ab und generiert eine evidenzbasierte Zusammenfassung.

B. Datenverarbeitungspipeline (Data Ingestion Pipeline)

Katalog- und Bewertungsdaten treffen kontinuierlich über Google Cloud Storage (GCS) ein und werden über Google Dataflow-Pipelines verarbeitet:

• Katalog-Pipeline: GCS → Dataflow → Cloud SQL (Tägliche Verarbeitung).
• Bewertungs-Pipeline: GCS → Dataflow → Embedding-Generierung → Qdrant (Verarbeitung sowohl täglich als auch stündlich für aktuelles Kundenfeedback).

C. Modellschicht (Model Layer)

Alle Modellinteraktionen werden über das TrueFoundry AI Gateway geleitet. Dies bietet zentralen Modellzugriff, Observability, Governance, Kostenverfolgung, Rate Limiting und Modellabstraktion. Der Assistent nutzt Gemini 2.5 Flash und Qwen-Modelle, um Latenz, Qualität und Betriebskosten optimal auszubalancieren.

D. Orchestrierungsschicht (Orchestration Layer)

Der konversationelle Workflow wird mit LangGraph orchestriert. Dies ermöglicht explizite Zustandsübergänge und Workflow-Management und unterstützt sowohl deterministische Ausführungspfade als auch agentische Argumentation.

2. Herausforderung #1: Deterministische vs. Agentische Workflows

Ein häufiger Trend bei KI-Systemen besteht darin, alles vollständig agentisch zu gestalten – unter der Annahme, dass ein LLM, wenn es logisch argumentieren kann, auch alles handhaben sollte. In der Praxis wird ein rein agentischer Ansatz jedoch schnell teuer, langsam und schwer steuerbar.

Wir haben Shopping-Interaktionen basierend auf klaren Kompromissen bei Leistung und Absicht (Intent) in zwei verschiedene Ausführungsparadigmen unterteilt:

Unter der Haube: Die Mechanik der Ausführung

Die architektonische Entscheidung zur Trennung dieser Abläufe wird stark durch interne Schleifen, die Gesamtzahl der LLM-Aufrufe und den Token-Verarbeitungsaufwand getrieben.

Der ReAct-Agenten-Lebenszyklus (3-Stufen-Schleife)

Für komplexe Workflows verarbeitet ein dedizierter ReAct-Agent die Ausführung dynamisch über einen dreistufigen Zyklus:

1. Schritt 1: Der Planungsprompt (LLM-Aufruf): Das System übergibt die Benutzeranfrage zusammen mit Systemprompts, die die Definitionen aller verfügbaren Tools enthalten. Das LLM muss über die Eingabe des Benutzers nachdenken, das passende Tool identifizieren und die exakten Parameter extrahieren, die für dieses Tool erforderlich sind.
2. Schritt 2: Die Tool-Ausführung: Das System führt den eigentlichen Tool- oder API-Aufruf mit den extrahierten Parametern aus.
3. Schritt 3: Der Beobachtungs- & Syntheseprompt (LLM-Aufruf): Die rohe Tool-Antwort wird an das LLM zurückgesendet. Das Modell wertet die Antwort des Tools im Vergleich zur ursprünglichen Frage des Benutzers aus und wandelt sie in eine saubere, kontextbezogene Antwort um.

Der deterministische Lebenszyklus (2-Stufen-Abkürzung)

Funktionen wie Produktspezifikationen, Bewertungen und Gutscheine müssen nicht über Tool-Auswahl oder Ausführungsreihenfolgen nachdenken. Um die Leistung zu optimieren, überspringen wir die Planungsphase vollständig:

1. Schritt 1: Direkte Tool-Ausführung: Da die Intent-Klassifizierung direkt einem bekannten Tool zugeordnet werden kann, wird der erste LLM-Prompt-Aufruf komplett übersprungen. Das System führt das Tool sofort aus, spart einen gesamten Inferenzzyklus ein und verkürzt die Time-to-First-Byte.
2. Schritt 2: Antwort-Synthese (LLM-Aufruf): Das System übergibt die Rohdaten des Tools und die Benutzeranfrage direkt an einen hochfokussierten Prompt, um die finale Antwort zu formatieren.

Der Latenz- und Prompt-Komplexitäts-Nachteil

Abgesehen von der Anzahl der Aufrufe bestimmt die Komplexität des Prompts die Antwortgeschwindigkeit maßgeblich:

• ReAct-Prompt-Belastung: In Schritt 1 eines ReAct-Agenten ist der Prompt hochkomplex. Das LLM muss mehrere Tools analysieren, Ausführungslogiken bewerten und den Kontext aufrechterhalten. Diese hohe kognitive Last erhöht die Token-Verarbeitungszeit und die Generierungslatenz.
• Deterministische Prompt-Effizienz: In einem deterministischen Ablauf ist der finale Prompt einfach: „Hier ist die Frage und hier ist die Rohantwort des Tools. Gib die Antwort aus.“ Da das Modell keine Pfade evaluieren oder Tools nachverfolgen muss, erfolgt die Token-Generierung schnell und ressourcenschonend.

Zentrale Erkenntnis: Das Erzwingen einer ReAct-Argumentationsschleife bei einfachen Datenabfragen führt zu unnötiger Latenz, höheren Kosten und operativer Komplexität, ohne die Antwortqualität zu verbessern. Wenn eine Interaktion deterministisch behandelt werden kann, muss sie auch so behandelt werden.

Absicherung der ReAct-Agenten (Guardrailing)

Wo deterministische Pfade an ihre Grenzen stoßen (z. B. „Kann ich das heute geliefert bekommen?“ unter Einbeziehung von Standortermittlung, Filialsuche und Bestandsprüfungen), sind ReAct-Agenten unverzichtbar. Vollständig autonome Agenten führen jedoch oft zu uneinheitlichen Kundenerlebnissen. Um die Kontrolle zu behalten, hat TrueFoundry strukturierte Workflow-Phasen innerhalb der dynamischen Agenten implementiert:

• Bestands-Agenten-Phasen: Standortermittlung → Filialauswahl → Bestandsprüfung → Ergebniserklärung.
• Kauf-Agenten-Phasen: Produktvalidierung → Bestandsverifizierung → Abwicklungsauswahl → Warenkorb-Aktion → Bestätigung.

3. Herausforderung #2: Evolution der Zustandsverwaltung

Die Weiterentwicklung von einem Assistenten für eine einzelne Produktseite zu einem katalogweiten Shopping-Begleiter ist im Kern ein Problem der Zustandsverwaltung (State Management).

• Phase 1 (Einzelprodukt-Zustand): Der Produktkontext wurde implizit von der aktiven Seite abgeleitet. Das Zustandsmodell war ein einfacher, flacher Gesprächsverlauf (Thread).
• Phase 2 (Mehrprodukt-Gespräche): Die Katalogsuche ermöglicht es Benutzern, mehrere Produkte gleichzeitig einzuführen, zu vergleichen und zwischen ihnen zu wechseln.

Um zu skalieren, ohne die Systemstabilität zu gefährden, wurde die Zustandsarchitektur anhand von vier zentralen Designprinzipien grundlegend überarbeitet:

1. Trennung von Zustandsbereichen (State Scopes)

Die Vermischung von Benutzerdaten mit temporären Produktdaten führt zu instabilen Systemen. Der Zustand wurde in klare Grenzen unterteilt:

• Benutzer-Zustand (User-Level State): Dauerhaft über die gesamte Shopping-Sitzung hinweg (z. B. bevorzugte Filiale, Standorteinstellungen, bevorzugte Abwicklungsart).
• Produkt-Zustand (Product-Level State): Gebunden an bestimmte Artikel (z. B. Katalogmetadaten, aktive Gutscheine, Bewertungen).

2. Explizite Kontextverfolgung (current_product_id)

Wir haben den Produktkontext von implizit auf explizit umgestellt, indem wir current_product_id als primäre Zustandsvariable eingeführt haben. Wenn ein Benutzer den Fokus auf einen neuen Artikel richtet, werden durch die Aktualisierung dieser einzelnen ID nachgelagerte Katalogdaten, Bewertungen, Gutscheine und Bestandsvariablen automatisch zurückgesetzt und neu geladen.

3. Agentenspezifischer Thread-Speicher

Das Vorhalten eines einzigen, flachen conversation_history = []-Arrays führte zu massivem Token-Rauschen und verschlechterte die Modellleistung. Suchgespräche benötigen völlig andere Kontextfenster als finale Checkout-Vorgänge. Der Speicher wurde direkt in isolierte Agenten-Threads (Suche, Bestand, Kauf, Produkt) gekapselt, um kontextübergreifende Überlagerungen zu minimieren.

4. Produktreferenz-Auflösung (Product Reference Resolution)

Die reine Intent-Klassifizierung reicht bei der Arbeit mit einem globalen Katalog nicht aus. Wenn ein Benutzer fragt „Ist das in meiner Nähe verfügbar?“, nutzt das System eine neu eingeführte Schicht zur Produktreferenz-Auflösung, um mathematisch abzuleiten, worauf sich „das“ bezieht, zu bewerten, ob die Anfrage zweideutig ist, und zu entscheiden, ob eine Rückfrage zur Klärung erforderlich ist.

Wichtigste Erkenntnis zur Architektur: Der Zustand sollte Workflows (Suche, Bestand, Kauf) repräsentieren und nicht Datendomänen (Bewertungen, Gutscheine, Produkte). Die Gestaltung des Zustands rund um die Benutzerabsicht und den Workflow-Fortschritt vereinfacht die Orchestrierung erheblich und reduziert die Komplexität bei der Verfolgung mehrerer Agenten.