Deterministische vs. Agentische Workflows: Lessen van het Bouwen van een Shopping Assistant

Lessen in Deterministische Workflows, Agentisch Redeneren en State Management

Het bouwen van AI-assistants begint vaak met een misleidend eenvoudig probleem. Een gebruiker stelt een vraag, het systeem haalt informatie op en een LLM genereert een antwoord. De eerste versie werkt meestal verrassend goed.

De echte uitdaging ontstaat naarmate de mogelijkheden uitbreiden. Wanneer er nieuwe tools en workflows worden geïntroduceerd, beginnen gebruikers vragen te stellen die meerdere domeinen beslaan. Gesprekken worden langer en contextueler, waardoor de assistant verandert van een eenvoudige QA-bot in een tool die gebruikers helpt complexe taken te voltooien.

Bij TrueFoundry kwamen we precies deze uitdaging tegen tijdens het bouwen van een conversationele shopping assistant. De assistant begon als een compagnon voor de Product Detail Page (PDP), in staat om vragen over één enkel product te beantwoorden. In de loop van de tijd evolueerde het naar een catalogusbrede shopping assistant die in staat is om productontdekking, ophalen, samenvatten van reviews, verwerking van coupons, ontdekken van winkels, voorraadcontroles, selectie van afhandeling en winkelmandbediening af te handelen.

Hoewel de externe mogelijkheden aanzienlijk uitbreidden, ontstonden de meest kritieke technische uitdagingen op twee gebieden:

1. Beslissen wanneer deterministische workflows moeten worden gebruikt versus agentisch redeneren.
2. Het laten evolueren van state management van een gespreksmodel voor één product naar een winkelervaring voor meerdere producten.

1. Overzicht van de Systeemarchitectuur

De shopping assistant is gebouwd op vier grote architectuurlagen die zijn ontworpen om prestaties, kosten en betrouwbaarheid in evenwicht te brengen.

A. Datalaag

Het systeem hanteert een strikte scheiding tussen gestructureerde en ongestructureerde opslagsystemen:

• Productcatalogus: Opgeslagen in PostgreSQL (Cloud SQL), bevat productmetadata, prijzen, varianten, categorie-informatie en afhandelingsmetadata.
• Reviews: Klantbeoordelingen worden opgeslagen in Qdrant. Dit maakt semantisch ophalen van reviewinhoud mogelijk in plaats van louter te vertrouwen op trefwoordmatching. Wanneer gebruikers semantische vragen stellen zoals "Wat zeggen klanten over de batterijduur?", haalt het systeem relevante reviews op en genereert het een op bewijs gebaseerde samenvatting.

B. Dataingestiepijplijn

Catalogus- en reviewdata komen continu binnen via Google Cloud Storage (GCS) en worden verwerkt via Google Dataflow-pijplijnen:

• Cataloguspijplijn: GCS → Dataflow → Cloud SQL (Dagelijks verwerkt).
• Reviewpijplijn: GCS → Dataflow → Embedding Generation → Qdrant (Verwerkt op zowel dagelijkse als uurlijkse schema's voor verse klantfeedback).

C. Modellaag

Alle modelinteracties worden geleid via de TrueFoundry AI Gateway. Dit biedt gecentraliseerde modeltoegang, observabiliteit, governance, kostentracking, rate limiting en modelabstractie. De assistant maakt gebruik van Gemini 2.5 Flash- en Qwen-modellen om latentie, kwaliteit en operationele kosten te balanceren.

D. Orchestratielaag

De conversationele workflow wordt georchestreerd met behulp van LangGraph, wat expliciete state-transities en workflowbeheer mogelijk maakt, terwijl het zowel deterministische uitvoeringspaden als agentisch redeneren ondersteunt.

2. Uitdaging #1: Deterministische vs. Agentische Workflows

Een veelvoorkomende trend in AI-systemen is om alles volledig agentisch te maken, uitgaande van de veronderstelling dat als een LLM kan redeneren, het alles zou moeten afhandelen. In productie wordt een puur agentische aanpak snel duur, traag en moeilijk te controleren.

We hebben winkelinteracties opgesplitst in twee verschillende uitvoeringsparadigma's op basis van duidelijke afwegingen in prestaties en intentie:

Onder de Motorkap: Het Mechanisme van Uitvoering

De architecturale beslissing om deze stromen te scheiden, wordt sterk gedreven door de interne loops, het totale aantal LLM-calls en de overhead van tokenverwerking.

De ReAct Agent Lifecycle (3-Stappen Loop)

Voor complexe workflows handelt een toegewijde ReAct-agent de uitvoering dynamisch af via een cyclus van drie stappen:

1. Stap 1: De Planningsprompt (LLM Call): Het systeem geeft de gebruikersquery door, samen met systeemprompts die de definities van alle beschikbare tools bevatten. De LLM moet redeneren over wat de gebruiker heeft gezegd, identificeren welke tool moet worden gebruikt en de exacte parameters extraheren die voor die tool vereist zijn.
2. Stap 2: De Tool-uitvoering: Het systeem voert de daadwerkelijke tool- of API-call uit met de geëxtraheerde parameters.
3. Stap 3: De Observatie- & Syntheseprompt (LLM Call): De ruwe tool-respons wordt teruggekoppeld naar de LLM. Het model evalueert de respons van de tool ten opzichte van de oorspronkelijke vraag van de gebruiker en vormt deze om tot een schone, contextuele gebruikersrespons.

De Deterministische Lifecycle (2-Stappen Snelkoppeling)

Mogelijkheden zoals productspecificaties, reviews en coupons hoeven niet te redeneren over toolkeuzes of uitvoeringsvolgorde. Om de prestaties te optimaliseren, slaan we de planningsfase volledig over:

1. Stap 1: Directe Tool-uitvoering: Omdat de intentieclassificatie rechtstreeks verwijst naar een bekende tool, wordt de eerste LLM-promptcall volledig overgeslagen. Het systeem voert de tool onmiddellijk uit, wat een volledige inferentiecyclus bespaart en de time-to-first-byte verkort.
2. Stap 2: Responssynthese (LLM Call): Het systeem geeft de ruwe tooldata en de gebruikersquery rechtstreeks door aan een zeer gerichte prompt om het uiteindelijke antwoord te formatteren.

De Latentie- en Promptcomplexiteitsstraf

Naast het tellen van het aantal calls, bepaalt de complexiteit van de prompt in grote mate de antwoordsnelheid:

• ReAct Prompt-belasting: In Stap 1 van een ReAct-agent is de prompt zeer complex. De LLM moet naar meerdere tools kijken, uitvoeringslogica evalueren en context behouden. Deze hoge cognitieve belasting verhoogt de tokenverwerkingstijd en de generatielatentie.
• Deterministische Prompt-efficiëntie: In een deterministische stroom is de uiteindelijke prompt eenvoudig: "Hier is de vraag en hier is de ruwe tool-respons. Geef het antwoord." Omdat het model geen paden hoeft te evalueren of tools hoeft bij te houden, is de tokengeneratie snel en lichtgewicht.

Kernles: Het forceren van een ReAct-redeneerloop op basisgegevensquery's voegt onnodige latentie, kosten en operationele complexiteit toe zonder de kwaliteit van het antwoord te verbeteren. Als een interactie deterministisch kan worden afgehandeld, moet dat ook gebeuren.

De ReAct-agents Binnen de Perken Houden

Waar deterministische paden tekortschieten (bijv. "Kan ik dit vandaag krijgen?" waarbij locatiebepaling, winkelontdekking en afhandelingscontroles betrokken zijn), zijn ReAct-agents essentieel. Volledig autonome agents zorgen echter vaak voor inconsequente klantervaringen. Om de controle te behouden, heeft TrueFoundry gestructureerde workflowfasen geïmplementeerd binnen de dynamische agents:

• Fasen van de Voorraad-agent: Locatiebepaling → Winkelselectie → Voorraadcontrole → Resultaat-toelichting.
• Fasen van de Aankoop-agent: Productvalidatie → Voorraadverificatie → Afhandelingsselectie → Winkelmandbediening → Bevestiging.

3. Uitdaging #2: Evolutie van State Management

Evolueren van een assistant voor één productpagina naar een catalogusbrede winkelcompagnon is in feite een state management-probleem.

• Fase 1 (State voor Eén Product): Productcontext werd impliciet afgeleid van de actieve pagina. Het state-model was een eenvoudige, platte gespreksgeschiedenisthread.
• Fase 2 (Gesprekken over Meerdere Producten): Cataloguszoeken stelt gebruikers in staat om meerdere producten tegelijkertijd te introduceren, te vergelijken en ertussen te schakelen.

Om te schalen zonder kwetsbaarheid in het systeem te introduceren, is de state-architectuur volledig herzien aan de hand van vier belangrijke ontwerpprincipes:

1. Scheiding van State-scopes

Het mengen van gebruikersdata met vluchtige productdata creëert kwetsbare systemen. State is geherstructureerd in duidelijke grenzen:

• State op Gebruikersniveau: Permanent gedurende de gehele winkelsessie (bijv. favoriete winkel, locatievoorkeuren, afhandelingskeuzes).
• State op Productniveau: Gekoppeld aan specifieke artikelen (bijv. catalogusmetadata, actieve coupons, reviews).

2. Expliciete Contexttracking (current_product_id)

We hebben de productcontext verplaatst van impliciet naar expliciet door current_product_id te introduceren als een eersteklas state-variabele. Wanneer een gebruiker de focus verplaatst naar een nieuw artikel, wist en ververst het bijwerken van dit enkele ID automatisch de stroomafwaartse catalogusdata, reviews, coupons en voorraadvariabelen.

3. Agent-specifiek Thread-geheugen

Het bijhouden van een enkele, platte conversation_history = [] array zorgde voor enorme token-ruis en verslechterde de modelprestaties. Zoekgesprekken vereisen heel andere contextwindows dan definitieve afrekenoperaties. Het geheugen werd rechtstreeks afgebakend in geïsoleerde agent-threads (Zoeken, Voorraad, Aankoop, Product) om vervuiling tussen contexten te minimaliseren.

4. Productreferentie-resolutie

Intentieclassificatie alleen is onvoldoende wanneer men te maken heeft met een globale catalogus. Wanneer een gebruiker vraagt "Is dit bij mij in de buurt verkrijgbaar?", vertrouwt het systeem op een nieuw geïntroduceerde Product Reference Resolution-laag om wiskundig af te leiden naar welk artikel "dit" verwijst, te evalueren of de query dubbelzinnig is en te beslissen of een verduidelijkingsprompt vereist is.

Belangrijkste Inzicht in de Architectuur: State moet workflows vertegenwoordigen (Zoeken, Voorraad, Aankoop) in plaats van datadomeinen (Reviews, Coupons, Producten). Het ontwerpen van state rondom de intentie van de gebruiker en workflowprogressie vereenvoudigt de orchestratie aanzienlijk en vermindert de complexiteit van multi-agent tracking.