Quality-Driven Agentic Reasoning for LLM-Assisted Software Design: Questions-of-Thoughts (QoT) as a Time-Series Self-QA Chain

Dit paper introduceert Questions-of-Thoughts (QoT), een kwaliteitsgestuurde redeneermethode die de prestaties van LLM's bij softwareontwerp verbetert door gestructureerde stappen en zelfvragen te gebruiken om fouten te verminderen, met name bij complexere taken en grotere modellen.

De kern

Stel je voor dat je een zeer slimme, maar soms wat ongeduldige assistent hebt die code kan schrijven. Deze assistent (een Large Language Model of LLM) is geweldig in het snel typen van zinnen en stukjes code. Maar als je hem vraagt om een heel complex systeem te bouwen, zoals een boekingsysteem voor hotels of een beveiligde bestandsopslag, maakt hij vaak fouten. Hij vergeet belangrijke stappen, bouwt de structuur slordig op of vergeet de veiligheid. Het resultaat is code die wel "werkt", maar niet betrouwbaar of veilig is.

Deze paper introduceert een nieuwe methode genaamd QoT (Questions-of-Thoughts), oftewel "Vragen-van-Gedachten". Hier is hoe het werkt, vertaald naar alledaagse taal:

1. Het Probleem: De "Snelkookpan"-aanpak

Normaal gesproken vraagt een ontwikkelaar aan de AI: "Bouw een hotelboekingsysteem."
De AI pakt dan direct de pen en begint te schrijven, net als iemand die een recept probeert te bedenken terwijl hij al aan het koken is. Hij vergeet vaak dat hij eerst de ingrediënten moet controleren, of dat hij een vuilnisbak nodig heeft voor de afval. Het resultaat is vaak rommelig.

2. De Oplossing: De "Architect met een Vraagboek"

QoT verandert de AI van een snelle schrijver in een gedisciplineerde architect. In plaats van direct te bouwen, dwingt QoT de AI om eerst een plan te maken en zichzelf constant vragen te stellen.

Het proces ziet eruit als een bouwproject in drie fasen:

• Fase 1: De Bouwplannen (De Stappenketen)
  De AI breekt het grote probleem niet in één keer op, maar maakt een lijstje met kleine, logische stappen.

  • Vergelijking: In plaats van "Bouw een huis", zegt de AI: "Stap 1: Giet het fundament. Stap 2: Zet de muren op. Stap 3: Doe het dak erop."

• Fase 2: De Interne Check (De Zelf-Vraagketen)
  Dit is het hart van QoT. Bij elke stap stelt de AI zichzelf kritische vragen, net als een strenge bouwkundige die een inspectie doet.

  • Voorbeeld: Bij stap 2 (de muren) vraagt de AI zichzelf: "Zijn de muren sterk genoeg? Heb ik rekening gehouden met de ramen? Wat gebeurt er als het regent?"
  • De AI moet deze vragen beantwoorden voordat hij de daadwerkelijke code schrijft. Dit voorkomt dat hij dingen vergeet.

• Fase 3: Het Dagboek (De Kennisbank)
  Alle antwoorden en beslissingen worden opgeschreven in een digitaal dagboek. Als de AI bij stap 5 een beslissing neemt, kijkt hij terug in het dagboek van stap 1 om te zien of dat nog steeds klopt.

  • Vergelijking: Het is alsof je een bouwheer hebt die bij elke stap noteert: "We hebben besloten om rode bakstenen te gebruiken." Als je later bij het dak komt, weet je nog steeds waarom je rode bakstenen hebt gekozen, in plaats van dat je het vergeten bent.

3. Wat levert dit op? (De Resultaten)

De auteurs hebben deze methode getest op drie moeilijke gebieden:

1. API Design (Het verkeer tussen verschillende softwareprogramma's).
2. Data Communicatie (Hoe computers berichten sturen).
3. Bestandssystemen (Hoe bestanden veilig worden opgeslagen).

Ze hebben de code die met QoT werd gemaakt vergeleken met code die zonder deze methode werd gemaakt. Ze keken niet alleen of het werkte, maar ook of het:

• Schaalbaar was (kan het groeien?).
• Volledig was (zijn er geen gaten?).
• Modulair was (is het netjes opgedeeld?).
• Veilig was (is het niet te hacken?).

De bevindingen:

• Bij grote, slimme modellen: QoT werkt als een krachtige versterker. De code wordt veel beter, veiliger en netter. Het is alsof je een slimme architect een strenge checklist geeft; hij maakt minder fouten.
• Bij kleinere modellen: Soms helpt het enorm (ze worden veel beter), maar soms kan het ook verwarrend zijn als het model te veel vragen moet beantwoorden en de draad kwijtraakt.
• De valkuil: Bij heel complexe taken (zoals bestandssystemen) kan het soms "te veel van het goede" zijn. De AI denkt dan te veel na ("over-engineering") en raakt in de war, wat juist slechtere resultaten oplevert.

4. Waarom is dit belangrijk?

Vroeger was het doel van AI in software: "Maak het werkend."
Met QoT is het doel: "Maak het werkend, veilig, en zo gebouwd dat mensen het over 10 jaar nog kunnen begrijpen en repareren."

Het is het verschil tussen een snelle, rommelige schets die je op een servet tekent, en een gedetailleerd bouwplan dat een ingenieur kan gebruiken om een brug te bouwen die niet instort.

Kortom: QoT dwingt de AI om te nadenken voordat hij handelt, door zichzelf constant kritische vragen te stellen. Hierdoor ontstaat er software die niet alleen werkt, maar ook betrouwbaar, veilig en professioneel is.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Quality-Driven Agentic Reasoning for LLM-Assisted Software Design: Questions-of-Thoughts (QoT) as a Time-Series Self-QA Chain", geschreven in het Nederlands.

Probleemstelling

Hoewel Large Language Models (LLMs) de AI-gestunde softwareontwikkeling hebben versneld, blijven praktische implementaties beperkt door onvolledige implementaties, zwakke modularisatie en inconsistente beveiligingspraktijken. Bestaande agentische systemen optimaliseren vaak alleen voor functionele correctheid (bijv. het doorstaan van tests) zonder expliciet rekening te houden met cruciale softwarekwaliteitsattributen zoals schaalbaarheid, onderhoudbaarheid en transparantie.

Dit leidt tot drie hoofdpijnpunten:

1. Onbetrouwbare correctheid onder distributieveranderingen en bij langdurige taken.
2. Gebrek aan bewijslast voor reviewers om een oplossing te vertrouwen.
3. Instabiele evaluatie door benchmark-overfitting en verontreiniging.

Er is een behoefte aan systemen die niet alleen werkende code genereren, maar ook transparante, herbruikbare redeneerartefacten leveren die geschikt zijn voor audit, debugging en governance.

Methodologie: Questions-of-Thoughts (QoT)

De auteurs introduceren Questions-of-Thoughts (QoT), een kwaliteitsgedreven inferentie-tijd (inference-time) raamwerk dat een gebruikersdoel omzet in een gestructureerd proces. QoT fungeert als een "Time-Series Self-QA Chain" en bestaat uit drie kerncomponenten:

1. Sequentiële Procesketen (Sequential Process Chain):

   • Het hooglevel-doel wordt systematisch opgesplitst in een geordende reeks van stappen ($S_1, S_2, ..., S_n$).
   • Dit zorgt voor een logische progressie en voorkomt redundantie of onvolledige antwoorden door afhankelijkheden tussen modules expliciet te maken.

2. Vraag-Antwoord Keten (Question-Answer Chain):

   • Voor elke stap $S_i$ genereert het model een reeks zelfgegenereerde vragen ($Q_{i,j}$).
   • Deze vragen dienen om informatie te verduidelijken, uit te breiden of te verifiëren (geïnspireerd op de Socratische methode).
   • Het doel is om ontwerprichtlijnen en potentiele omissies vroeg in het proces te identificeren, voordat de definitieve code wordt gegenereerd.

3. Redeneerkennisbasis (Reasoning Knowledge Base):

   • Dit is het geheugenmodule dat de tussenstappen van het redeneren en de geaccumuleerde inzichten opslaat.
   • Het bevat een Thinking Process (TP) (intermediaire stappen) en een Response (R) (de progressief bijgewerkte oplossing).
   • Deze kennisbasis zorgt ervoor dat eerdere beslissingen en beperkingen worden meegenomen in latere stappen, wat de stabiliteit van het ontwerp verhoogt.

Het algoritme werkt als volgt: het genereert eerst stappen, vervolgens een vragenreeks per stap, beantwoordt deze vragen om de kennisbasis te vullen, en update tenslotte de definitieve respons op basis van de geaccumuleerde redenering.

Belangrijkste Bijdragen

1. Het QoT-protocol: Een gestructureerd agentisch redeneerprotocol dat sequentiële planning koppelt aan stapsgewijze zelf-vraag-en-antwoord (self-QA) en beperkingstracking.
2. Evaluatiebenchmark: Een benchmark over drie praktische backend-domeinen: API-ontwerp, Datacommunicatie en Bestandsystemen.
3. Kwaliteitsgedreven evaluatie: Een meetlat gebaseerd op ISO/IEC 25010 en FURPS, die vier dimensies meet: Schaalbaarheid, Volledigheid, Modulariteit en Beveiliging.
4. Open Artefact: Een openbare repository met prompts, scorerichtlijnen, ruwe generaties en scripts om de resultaten te reproduceren.

Resultaten

De auteurs evalueerden QoT op verschillende modellen (o.a. Llama 3.1, 3.2, 3.3 in 8B, 70B en 3B varianten) en vergeleken het met baselines zonder QoT (NoQoT) en met Chain-of-Thought (CoT).

• Kwaliteitsverbetering: QoT leidt over het algemeen tot significante verbeteringen in de totale kwaliteitscore, vooral bij grotere modellen en complexere domeinen.
  • Bijvoorbeeld: Voor het model llama3.1_70b werd een verbetering van +5.8 punten gezien in API-ontwerp en +6.6 in datacommunicatie ten opzichte van CoT.
• Grootte van het model:
  • Grote modellen: Profiteren sterk van de gestructureerde zelf-reflectie, hoewel er bij zeer complexe taken (zoals Bestandsystemen) soms een lichte achteruitgang optreedt door "over-thinking" of over-engineering.
  • Kleine modellen: Krijgen aanzienlijke kwaliteitswinst, waardoor ze in kwaliteit dichter bij de prestaties van grotere modellen komen. Echter, bij zeer beperkte context of planningbudgetten kunnen kleine modellen moeite hebben met het genereren van hoogwaardige tussenvragen, wat de effectiviteit kan beperken.
• Domeinspecifieke inzichten: De grootste winst werd geboekt in modularisatie, invoervalidatie en beveiligingscontroles (zoals toegangscontrole en foutafhandeling).
• Trade-offs: Er is een afweging tussen de rekenkosten (meer inferentiestappen) en de kwaliteit. Voor kritieke backend-taken weegt de reductie in ontwerpfouten en onderhoudskosten op tegen de extra latentie.

Betekenis en Conclusie

QoT vult een cruciale kloof in de AI-gestunde software-engineering door codegeneratie te transformeren van een "single-shot" synthetische taak naar een traceerbaar, criteria-gedreven proces.

• Vertrouwen en Transparantie: Door de redenering te structureren rondom softwarekwaliteitscriteria, maakt QoT het mogelijk om ontwerprichtlijnen en beperkingen te auditeren. Dit is essentieel voor veilige en betrouwbare AI-toepassingen in de praktijk.
• Toekomstperspectief: Het paper pleit voor de integratie van QoT met geautomatiseerde verificatiepijplijnen (zoals statische analyse en testsynthese) om de betrouwbaarheid verder te verhogen.
• Algemene Toepasbaarheid: De resultaten suggereren dat QoT een praktische, kwaliteitsgedreven aanpak is die niet alleen de functionele correctheid verbetert, maar ook de onderhoudbaarheid en veiligheid van gegenereerde softwaresystemen, zelfs met kleinere modellen.

Kortom, QoT biedt een robuust raamwerk om LLM-agents te sturen naar het produceren van professionele, veilige en goed gestructureerde software, in plaats van slechts functionele codefragmenten.