Latency: waarom je gebruiker afhaakt bij acht seconden

Gebruikers ervaren wachttijd bij een AI-assistent snel als storend. Acht seconden kan lang voelen, maar er bestaat geen vaste magische grens: wat aanvaardbaar is, verschilt per gebruiker, taak en verwachting. Een lange stilte zonder uitleg maakt afhaken waarschijnlijker, ook als het antwoord uiteindelijk goed is.

Ontwerp daarom voor gevoelde snelheid én werkelijke snelheid. Laat tekst streamen zodra die beschikbaar is, toon bij taken op de achtergrond waar de assistent mee bezig is en beperk waar mogelijk de context of kies een kleiner, sneller model. Test met echte gebruikers; hun ervaring vertelt je of de wachttijd in jouw situatie werkt.

Waar komt de wachttijd vandaan?

Latency is de tijd tussen de vraag van de gebruiker en het moment waarop de assistent reageert. Die tijd bestaat meestal uit meerdere stappen. Het model moet de invoer verwerken en een antwoord maken. Een lange conversatie of een uitgebreide prompt kan meer verwerking vragen. Bij een RAG-assistent komt daar het ophalen en rangschikken van documenten bij. Een agent kan ook externe tools aanroepen, resultaten verwerken en daarna opnieuw het model raadplegen.

Ook netwerkverkeer en de manier waarop onderdelen met elkaar communiceren spelen mee. Een trage documentbron of tool kan de hele taak vertragen, zelfs wanneer het model zelf vlot antwoordt. Kijk daarom naar de volledige keten. Alleen de snelheid van het model meten geeft geen compleet beeld van wat de gebruiker ervaart. Bij RAG helpt het om ook de zoekstappen te volgen en te verbeteren; zie RAG van demo naar productie.

Werkelijke en gevoelde snelheid

De totale wachttijd is belangrijk, maar niet het enige dat telt. Als er snel een eerste teken van activiteit verschijnt, weet de gebruiker dat de vraag is aangekomen. Bij een antwoord dat direct bruikbaar wordt, kan dat de ervaring merkbaar verbeteren. Andersom voelt dezelfde totale duur langer wanneer het scherm niets laat zien en niet duidelijk is of de assistent nog werkt.

Streaming helpt doordat het antwoord stukje voor stukje verschijnt, in plaats van pas wanneer de volledige tekst klaar is. De gebruiker ziet de eerste woorden eerder en kan alvast beginnen met lezen. Dat is vooral nuttig bij antwoorden die geleidelijk worden gegenereerd. Streaming verkort niet automatisch de totale rekentijd en helpt minder wanneer de assistent eerst meerdere tools moet aanroepen voordat hij iets zinnigs kan tonen.

Geef tijdens zulke taken een korte, eerlijke status. Laat bijvoorbeeld zien dat de assistent documenten doorzoekt of een bron raadpleegt. Een voortgangsindicatie moet aansluiten bij wat er werkelijk gebeurt: verzin geen precieze voorspelling als je die niet betrouwbaar kunt geven. Bij agents zijn duidelijke tussenstatussen onderdeel van een betrouwbaar ontwerp; zie ook Retries, time-outs en dode agents.

Maak het werk lichter en kies het juiste model

Een kortere prompt en alleen relevante context kunnen verwerking verminderen. Neem niet automatisch het volledige gesprek of elk document mee. Selecteer wat nodig is voor de huidige vraag en voorkom dat instructies elkaar herhalen. Bij een documentassistent kan betere filtering vooraf voorkomen dat het model veel irrelevante tekst moet verwerken.

Niet elke vraag heeft hetzelfde model nodig. Een router kan eenvoudige, afgebakende vragen naar een kleiner of sneller model sturen en complexe vragen naar een model dat meer redeneercapaciteit biedt. De keuze moet passen bij de taak en de kwaliteitseisen: snelheid winnen heeft weinig waarde als antwoorden daardoor vaker onjuist of onvolledig zijn. Lees meer over modelrouting. Ook quantisatie kan de benodigde rekenkracht beïnvloeden, afhankelijk van model en gebruik.

Veelgestelde vragen met stabiele antwoorden kunnen soms uit een cache komen. Dan hoeft het systeem niet telkens dezelfde bewerking uit te voeren. Controleer wel of de gecachte reactie nog geldig is en of de vraag voldoende overeenkomt. Persoonlijke, actuele of toegangsgevoelige informatie vraagt om extra zorg: gebruik geen antwoord van een andere gebruiker of een verouderde bron.

Time-outs en een nette terugval

Soms duurt een modelaanroep of tool langer dan verwacht. Stel daarom grenzen in voor afzonderlijke stappen en voor de totale taak. Als een stap vastloopt, voorkom je zo dat de gebruiker onbeperkt wacht. Bij agents zijn begrensde herpogingen en een zichtbare status nuttig, zolang een herhaling geen dubbele actie veroorzaakt.

Vertel duidelijk wanneer een antwoord niet op tijd beschikbaar is. Je kunt aanbieden de vraag te vereenvoudigen, een deelresultaat tonen of aangeven welke stap niet is gelukt. Geef geen schijnzeker antwoord wanneer de bron of tool ontbreekt. Een bruikbare terugval helpt de gebruiker verder en maakt duidelijk wat er nog nodig is.

Meten en verbeteren

Meet zowel de tijd tot de eerste zichtbare woorden als de totale tijd tot een afgerond antwoord. Bij een agent kun je daarnaast de duur van ophalen, toolaanroepen en modelstappen apart volgen. Gebruik percentielen om te zien hoe de ervaring verschilt tussen snelle gevallen en gevallen die langer duren. Een gemiddelde alleen kan lange uitschieters verbergen.

Combineer technische metingen met gebruikerstests. Kijk of mensen begrijpen wat de assistent doet, of ze wachten of afhaken en of het getoonde deelantwoord al bruikbaar is. Vergelijk daarna één wijziging tegelijk, zoals streaming, een kortere context of routering naar een ander model. De juiste grens bepaal je op basis van de taak en de mensen die de assistent gebruiken, niet op basis van de titel.

Korte checklist:

• Meet de tijd tot de eerste woorden én de totale antwoordtijd.
• Toon streaming of een eerlijke status tijdens wachten.
• Beperk prompts en context tot wat de taak nodig heeft.
• Routeer eenvoudige en complexe vragen passend naar een model.
• Gebruik caching alleen wanneer antwoord en context veilig herbruikbaar zijn.
• Stel time-outs in en geef een duidelijke terugval bij vertraging.
• Test de ervaring met echte gebruikers en bekijk percentielen.