Een ontwikkelaarsgids waarschuwt dat het openhouden van een database-transactie gedurende de gehele duur van een AI-gestuurde chat de antwoorden kan corrumperen en de onderliggende DBMS kan verstikken. De opmerking, gericht aan teams die tools bouwen op basis van LLM's, stelt dat deze praktijk "niet gedaan moet worden" en biedt in plaats daarvan vier kortstondige consistentiepatronen aan.

Waarom de waarschuwing belangrijk is

LLM-gestuurde assistenten stellen vaak een reeks vervolgvragen: ze lezen een record, vragen om een detail en vragen vervolgens om een totaal. Als de onderliggende gegevens tussen deze stappen veranderen, kan de assistent tegenstrijdige cijfers teruggeven — één antwoord zal onjuist zijn. De verleidelijke oplossing is om aan het begin van het gesprek een enkele transactie te openen en deze open te houden tot het gesprek eindigt. In de praktijk houdt deze aanpak rijversies vast, vult de tempdb, houdt locks vast en verstoort de connection pooling.

Wat leidt tot langdurige transacties

  • Multi-turn prompting – LLM's genereren doorgaans meerdere prompts voordat de gebruiker een reactie ziet.
  • Tool-aanroepen die de database benaderen – Elke beurt kan een stored procedure, een SELECT of een UPDATE aanroepen.
  • Ongecontroleerde transactieomvang – Ontwikkelaars verpakken soms het hele gesprek in een BEGIN…COMMIT-blok, in de veronderstelling dat dit consistentie garandeert.

Wanneer het gesprek uitloopt, moet de DB-engine de oorspronkelijke rijversies behouden zodat de transactie een stabiel beeld heeft. Die versies staan in de tempdb, wat ruimte en I/O verbruikt. Locks die gedurende dezelfde periode worden vastgehouden, blokkeren gelijktijdige schrijfacties, en de inactieve verbinding kan de pool uitputten, waardoor nieuwe aanroepers moeten wachten op een vrije plek.

Vier kortstondige patronen

De gids raadt aan om consistentie te behandelen als een zorg per tool-call in plaats van per gesprek. De vier patronen zijn:

  1. Live statements – Elke aanroep wordt uitgevoerd onder het standaard isolatieniveau, waarbij alleen gegevens worden gezien die op het moment van uitvoering zijn gecommit. Dit is het eenvoudigste model; de aanroeper accepteert dat gegevens sinds de vorige beurt gewijzigd kunnen zijn.
  2. Begrensde transacties – Een ontwikkelaar groepeert een handvol statements binnen een enkele korte transactie die wordt afgerond voordat de volgende LLM-beurt begint. Dit garandeert atomiciteit voor die batch zonder langer te blijven bestaan dan de tool-call.
  3. Snapshot-reads – De operatie begint met een gedefinieerde snapshot-timestamp, wat gedurende de duur van de aanroep een stabiel beeld van de database geeft. Alle reads binnen de aanroep zien dezelfde gegevens, zelfs als er gelijktijdige schrijfacties plaatsvinden.
  4. Gematerialiseerde rapporten – De tool leest uit een vooraf gegenereerde, versioneerde resultaatset die de database reflecteert op een bekend afkapmoment. Paginering of verdere berekeningen werken vervolgens op deze bevroren dataset.

Controleer in SQL Server of READ_COMMITTED_SNAPSHOT actief is. Ga er niet vanuit dat de naam het hele verhaal vertelt.

Praktische regels voor door LLM's aangedreven apps

  • Batch wat je nodig hebt – Als een vraag veel waarden vereist, bereken deze dan in een enkele tool-call in plaats van afzonderlijke queries uit te voeren die elk een nieuwe transactie starten.
  • Deterministische paginering – Gebruik bij het presenteren van resultaten over meerdere pagina's een stabiele sorteersleutel, een cursor of een gematerialiseerde resultaatset. Houd nooit een transactie open terwijl de gebruiker scrolt.
  • Lever bewijslast aan – Voeg naast de gegevens metadata toe die het consistentiemodel expliciet maakt: de consistentieklasse, de starttijd van de snapshot, het afkapmoment van de rapportage, de versheid van de gegevens, het aantal rijen, de database-identiteit en een trace ID.
  • Stress-test met gelijktijdigheid – Simuleer gelijktijdige schrijfacties terwijl de LLM prompts genereert, en verifieer of de applicatie netjes opnieuw probeert of een fallback gebruikt.

De kernboodschap is duidelijk: een AI-chat mag de levensduur van een database-transactie niet dicteren. Door de consistentie te beperken tot elke tool-call, houden ontwikkelaars de database gezond, behouden ze de prestaties voor alle gebruikers en geven ze de LLM nog steeds voldoende betrouwbare gegevens om nauwkeurig te antwoorden.