Waarom je AI-zoekagent vastloopt bij lange taken

Waarom een demo weinig zegt over lange zoektaken

Demo’s worden doorgaans samengesteld met vragen waarvan het antwoord in één document staat. De zoekfunctie haalt een passage op, het taalmodel vat die samen en binnen enkele seconden staat er een overtuigend antwoord op het scherm. Echte klantvragen zijn zelden zo overzichtelijk.

Een klant die wil weten of de licenties van een oude vestiging kunnen worden overgezet naar een nieuwe, stelt een vraag die pas te beantwoorden is na het raadplegen van contractvoorwaarden, een actuele prijslijst en de uitzonderingen die sindsdien zijn afgesproken.

Een AI-agent lost zo’n vraag op door herhaaldelijk te zoeken, documenten te openen, tussentijds te redeneren en opnieuw te zoeken. Alles wat hij onderweg leest en bedenkt, blijft in zijn werkgeheugen staan, het contextvenster. Naarmate een zoektaak langer duurt, vult dat venster zich met tientallen zoekresultaten, half relevante passages en sporen van mislukte pogingen.

De kloof tussen een overtuigend prototype en software die in productie standhoudt, kennen veel teams inmiddels ook van vibe coding. Bij AI-zoekfuncties manifesteert zich eenzelfde soort kloof wanneer de vragen langer en rommeliger worden.

Wat het onderzoek naar contextrot laat zien

Shijie Xia en collega’s van onder meer Shanghai Jiao Tong University lieten vier open taalmodellen, waaronder GLM-4.7 en Qwen3.5, zoekopdrachten uitvoeren uit drie testsets. Een daarvan, BrowseComp-Plus, laat de agent zoeken in een vaste documentcollectie, een opzet die dicht in de buurt komt van een zoekfunctie over de eigen kennisbank. De onderzoekers legden naast de juistheid ook vast hoe de agent eindigde, met (1) een stellig antwoord, (2) een antwoord vol twijfel, (3) door op te geven of (4) zonder antwoord.

Naarmate het zoektraject langer wordt, daalt het aandeel juiste antwoorden scherp en krijgen opgeven en onzekere, onjuiste antwoorden de overhand, ruim voordat het contextvenster vol is. In het voorbeeld dat de auteurs uitlichten, gebeurt dat bij Qwen3.5 al rond een kwart van het beschikbare venster. Voor een klantgerichte zoekfunctie is vooral het onzekere antwoord zorgwekkend, omdat de klant een antwoord te zien krijgt dat als feit oogt, ook als het systeem er zelf aan twijfelde.

Deze mislukkingen treffen ook vragen die hetzelfde model in andere pogingen goed beantwoordt, wat wijst op voortijdig afhaken. Hoe meer sporen van vergeefs zoeken zich in de context opstapelen, hoe groter die kans. Bij GLM-4.7 op BrowseComp-Plus loopt het aandeel onbesliste uitkomsten op van nagenoeg nul bij korte trajecten tot 95 procent bij lange trajecten waarin vrijwel elke stap op niets uitliep. Het model aansporen om door te zoeken, haalde weinig uit.

Contextbeheer helpt en kost extra zoekwerk

De studie vergelijkt daarnaast zeven manieren om de context te beheren, verdeeld over samenvatten, inkorten en het uitbesteden van deeltaken aan subagents. Vrijwel alle methoden drukken het aandeel onbesliste zoektochten fors, omdat er minder sporen van vergeefs zoeken in de context blijven hangen. De agent zoekt langer door en vindt vaker het juiste antwoord, met navenant hogere kosten. Bij Qwen3.5 op BrowseComp steeg de nauwkeurigheid met samenvatten van 35,0 naar 46,6 procent, en het gemiddelde aantal zoek- en leesstappen per vraag van 21,7 naar 57,7.

Welke methode het meest oplevert, hangt af van het model. Subagents werkten het best voor Qwen3.5 en behoorden voor GLM-4.7 tot de zwakste methoden. Een andere bevinding is voor productteams wellicht het meest bruikbaar. Wie dezelfde vraag meerdere keren laat uitvoeren en de pogingen laat vallen die eindigen met opgeven of twijfel, wint gemiddeld 2,6 tot 4,9 procentpunt aan nauwkeurigheid. De eigen twijfel van het model blijkt daarmee een bruikbaar signaal, waarvan de betrouwbaarheid per toepassing te toetsen valt.

Een testopzet voor korte en lange zoektaken

De aanpak hieronder is een voorstel van onze kant, gebaseerd op de faalwijzen uit het onderzoek. Een bewezen universele oplossing bestaat nog niet, en de juiste opzet verschilt per product. Het vertrekpunt is een vaste set geanonimiseerde klantvragen waarvan vooraf vaststaat wat het juiste antwoord is en in welke bronnen dat staat. Neem korte en samengestelde vragen op, en bewust ook vragen waarop de documenten geen antwoord geven. Bij die laatste groep is een heldere melding met overdracht de gewenste uitkomst. De tabel toont een voorbeeld voor een fictieve leverancier van planningssoftware.

Beoordeel elke vraag op juistheid, brononderbouwing, de manier waarop de taak eindigt en de kosten in zoekstappen en tokens, en leg vast hoe lang het zoektraject werd. Pas dan zie je of de kwaliteit terugloopt naarmate een taak langer duurt. Draai dezelfde set vervolgens tegen een basisvariant, een variant met gerichte contextselectie en een variant die samenvat zodra een drempel is bereikt. Omdat de beste methode per model verschilt, geeft alleen die vergelijking op het eigen model en de eigen documenten uitsluitsel over wat extra nauwkeurigheid kost.

Grenzen stellen aan zoeken, stoppen en overdragen

Langer zoeken maakt een agent niet vanzelf beter. Leg daarom vooraf vast wanneer een zoekfunctie stopt en wat er daarna gebeurt.

• Een budget per vraag in zoekstappen of kosten, waarna de agent stopt en meldt wat hij heeft gevonden.
• Een drempel voor de omvang van de context, waarboven de agent samenvat of inkort.
• Een regel voor onzekere antwoorden, die verschijnen met die onzekerheid erbij of doorgaan naar een medewerker.
• Een overdracht met context, zodat een medewerker de vraag, de geraadpleegde bronnen en de punten waarop het systeem vastliep meekrijgt.