Technische Samenvatting: BatchDAG

1. Probleemstelling

Large Language Models (LLMs) blinken uit in het analyseren van individuele documenten, maar hebben moeite met uitvoerige, cross-entiteit analytische queries over enterprise-scale datasets. Wanneer ze worden toegepast op taken die het verwerken van honderden of duizenden entiteiten vereisen (bijv. het analyseren van 50.000 vergadertranscripten), kampen standaard single-agent loops met drie kritieke beperkingen:

• Context Window Overflow: Het aggregeren van resultaten voor duizenden entiteiten overschrijdt zelfs de grootste commerciële context windows (bijv. 1,25M tokens voor 50k vergaderingen).
• Verlies van Per-Entiteit Attributie: Global top-$N$ zoekopdrachten leveren de meest relevante resultaten over alle entiteiten terug, maar falen in het attribueren van bevindingen aan specifieke deals of vergaderingen, wat het onmogelijk maakt om vragen te beantwoorden die gericht zijn op "elke entiteit".
• Lineaire Latentie: Sequentiële tool-aanroepen zorgen ervoor dat de latentie evenredig groeit met het aantal entiteiten, waardoor analyse van grote corpora onpraktisch traag wordt.

Bestaande frameworks (bijv. ReAct, LangChain) delegeren de executieplanning aan de LLM bij elke stap, waardoor ze lijden onder sequentiële bottlenecks en niet de ondersteuning bieden voor de op entiteitsniveau vereiste parallelliteit voor cross-corpus analyse.

2. Methodologie: BatchDAG Architectuur

BatchDAG lost deze beperkingen op door het probleem te deconstrueren in een planningsfase en een deterministische executiefase. Het systeem werkt in drie afzonderlijke fasen:

Fase 1: Planning (LLM-gegenereerde DAG)

Een planner-LLM ontvangt de natuurlijke taalquery van de gebruiker, een schema van beschikbare databronnen en een definitie van operatietypes. In plaats van een lineaire chain of thought te genereren, produceert de planner een Typed Directed Acyclic Graph (DAG).

• Doelgerichte Prompting: De planner wordt gestuurd door een "doelgerichte" prompt-architectuur die de kostenkenmerken en datamodellen van operaties beschrijft, in plaats van te vertrouwen op uitputtende regellijsten of few-shot voorbeelden. Dit stelt de LLM in staat om vanuit eerste principes te redeneren over welke operaties gecombineerd moeten worden.
• Output Constraints: De planner genereert een gestructureerde JSON DAG met getypeerde stappen en expliciete input-specificaties (bijv. directe referenties, merge joins). Een "safe-specification filter" verwijdert onbekende velden om te voorkomen dat gehalucineerde parameters het systeem breken.

Fase 2: Executie (Deterministische Engine)

Een deterministische engine evalueert de DAG met behulp van topologische-golf parallelliteit.

• Getypeerde Operaties: De DAG bestaat uit zes operatietypes: sql, search, transform, fan out, analyze, en compare.
  • Nul LLM-kosten: sql, search, transform, en compare worden uitgevoerd via deterministische backends (Relationele DB, Vector DB, Pure Python) en vereisen nul LLM-aanroepen.
  • LLM-kosten: Alleen fan out (per-entiteit analyse) en analyze (aggregatie) roepen de LLM aan.
• Gestructureerde Inter-stap Datastroom: Stappen geven gestructureerde JSON-rijen door aan elkaar, nooit proza-samenvattingen. Dit behoudt de herkomst (provenance), maakt database-achtige joins/filters tussen stappen mogelijk, en voorkomt downstream hallucinaties.
• Entiteit-bewuste Batching: Een cruciale optimalisatie waarbij rijen gegroepeerd worden op logische entiteit (bijv. meeting ID) voordat de fan out stap plaatsvindt. Dit zorgt ervoor dat elke LLM-aanroep een volledige entiteitscontext verwerkt in plaats van gefragmenteerde rijen, wat het aantal LLM-aanroepen met wel 47× vermindert ten opzichte van naïeve rij-niveau batching.
• Wave Executie: Onafhankelijke stappen worden uitgevoerd in parallelle golven. fan out stappen spawnen parallelle child-taken met per-batch retry-semantiek (als één batch faalt, wordt alleen die batch opnieuw geprobeerd).

Fase 3: Synthese

Een synthese-LLM compileert de gestructureerde resultaten uit de DAG tot een coherent antwoord met per-entiteit citaties.

3. Belangrijkste Bijdragen

1. Typed DAG Formalisme: Een systeem voor het deconstrueren van ad-hoc analytische queries in composabele operaties met gestructureerde inter-stap datastroom, waarbij planning en executie van elkaar gescheiden zijn.
2. Entiteit-bewuste Batching: Een algoritme dat data groepeert per logische entiteit vóór de fan-out, wat een 47× reductie in LLM-aanroepen oplevert terwijl de holistische context behouden blijft.
3. Doelgerichte Planning Architectuur: Een prompt-ontwerp dat beter presteert dan uitputtende regels en few-shot voorbeelden door te redeneren over operatiekosten en datamodellen.
4. Productie-implementatie: Een rapport over de implementatie van BatchDAG bij Brevian.ai, waarbij queries over 50.000+ vergaderingen zijn verwerkt met gemeten kosten en latentie.
5. Empirische Evaluatie: Een gecontroleerde studie die aantoont dat automatisch gegenereerde DAGs een kwaliteit bereiken die vergelijkbaar is met expert-ontworpen pipelines, maar met superieure herkomst en minder hallucinaties.

4. Experimentele Resultaten

Experimenten werden uitgevoerd op een ontwikkelingsdataset (46 vergaderingen, 62 deals) en productiegegevens (50.000+ vergaderingen).

• Planner Correctheid: Over 300 planning-aanroepen behaalde het systeem een 98,8% valid-DAG rate.
• Antwoordkwaliteit: Op 12 transcript-zware queries behaalde BatchDAG een gemiddelde kwaliteitsscore van 3,74/5, wat vergelijkbaar is met een expert-ontworpen baseline (S5b, 3,25/5) en significant beter presteert dan een ReAct agent (S3, 3,09/5, $p<0,01$).
• Herkomst (Provenance): BatchDAG behaalde een 77% transcript bewijslast, wat aanzienlijk hoger is dan de baseline (46–60%), wat controleerbare antwoorden garandeert.
• Controle op Hallucinaties: Een ablatie-studie toonde aan dat het gebruik van gestructureerde JSON-intermediaire data hallucinaties met 27% verminderde vergeleken met proza-samenvattingen (hoewel de statistische significantie marginaal was, $p=0,107$, de trend was consistent).
• Efficiëntie:
  • Latentie: BatchDAG verwerkte een analyse van 3.000 deals in ~60 seconden, vergeleken met een theoretische sequentiële agent-tijd van ~100 minuten.
  • Kosten: De kosten per query varieerden van $0,02 (alleen SQL) tot $0,24 (transcript-zware fan-out). Vergeleken met een vaste pipeline projecteerde BatchDAG een 6,2× jaarvoordeel in kosten op een gemengde query-workload.

5. Betekenis en Claims

Het paper positioneert BatchDAG niet primair als een verbetering in nauwkeurigheid ten opzichte van handmatige pipelines, maar als een general-purpose orchestratie-laag. De betekenis ligt in:

• Eliminatie van Pipeline Engineering: Het vervangt de noodzaak om meerdere handmatig ontworpen workflows te ontwerpen voor verschillende typen queries door een enkel systeem dat de passende executiestrategie genereert vanuit natuurlijke taal.
• Schaalbaarheid: Door het gebruik van de LLM te beperken tot specifieke fan out en analyze stappen, en door deterministische backends te gebruiken voor de rest, maakt het analyse op enterprise-scale datasets mogelijk die anders te groot of te duur zouden zijn om te verwerken.
• Architecturale Verschuiving: De kerninzicht is dat voor cross-entiteit analytische workloads, de LLM moet plannen, niet uitvoeren. Het systeem bereikt een hoge validiteit en kwaliteit door de LLM te behandelen als een compiler voor executiegrafen in plaats van een directe uitvoerder van elke stap.

De auteurs merken beperkingen op, waaronder het gebrek aan een gevestigde benchmark voor cross-entiteit queries, de afwezigheid van een "probe fase" om DAGs te valideren vóór volledige executie, en de huidige onmogelijkheid om DAGs dynamisch uit te breiden tijdens de executie. Desondanks is het systeem al in productie en verwerkt het duizenden vergaderingen met hoge betrouwbaarheid en kostenefficiëntie.