Voordat je fouten kunt afhandelen, moet je weten welke fouten er voorkomen:

• API-fouten: De provider retourneert een foutcode (429 rate limit, 500 serverfout, 503 tijdelijk niet beschikbaar).
• Timeouts: De aanroep duurt te lang en wordt afgebroken.
• Ongeldige output: Het model retourneert tekst die niet overeenkomt met wat je verwacht, zoals tekst in plaats van JSON.
• Hallucinaties: Het model geeft een inhoudelijk fout maar syntactisch correct antwoord.
• Toolfouten: Een externe tool of API die het model aanroept, mislukt.

Elke foutcategorie vereist een andere aanpak.

De meest basale foutafhandeling voor API-fouten is opnieuw proberen. Maar doe dit nooit naïef: een onmiddellijke retry bij een overbelaste API maakt het probleem erger. Gebruik exponential backoff: wacht na de eerste mislukking even, na de tweede iets langer, enzovoort.

Een eenvoudig patroon:

• Eerste retry: wacht 1 seconde
• Tweede retry: wacht 2 seconden
• Derde retry: wacht 4 seconden
• Geef daarna op en log de fout

Bibliotheken zoals tenacity (Python) of p-retry (Node.js) implementeren dit patroon kant-en-klaar.

Niet elke fout rechtvaardigt een retry. Soms is het beter om terug te vallen op een alternatief:

• Alternatief model: Als GPT-4o niet beschikbaar is, probeer dan een lichtere modelversie of een ander platform.
• Cached response: Als dezelfde vraag eerder succesvol beantwoord is, geef de gecachede response terug.
• Menselijke escalatie: Stuur de taak door naar een medewerker als het model het herhaaldelijk niet oplost.
• Gracefu degradation: Toon een beperkte versie van de functionaliteit in plaats van een foutmelding.

De juiste fallback hangt af van hoe kritiek de output is. Voor een chatbot-reactie is een eenvoudiger antwoord acceptabel; voor een financieel document is dat het niet.

Zelfs als een aanroep technisch slaagt, kan de output onbruikbaar zijn. Bouw altijd een validatiestap in die controleert of de output aan je verwachtingen voldoet:

• Is de JSON valide en bevat het de verwachte velden?
• Valt een getal binnen de verwachte range?
• Is de tekst niet leeg of abnormaal kort?

Gebruik schema-validatie (Pydantic, Zod) voor structurele controles. Voeg domein-specifieke checks toe voor inhoudelijke validatie.

Zet altijd een timeout op AI-aanroepen. Een aanroep die blijft hangen, blokkeert je systeem. Stel een timeout in die past bij de verwachte responstijd: voor snelle modellen is 10 seconden ruim voldoende, voor complexe redeneermodellen kan 60 seconden nodig zijn.

Combineer timeouts met retry-logica: als een aanroep uitvalt door een timeout, probeer het opnieuw met dezelfde of een langere timeout.

Goede error handling is onzichtbaar voor de gebruiker maar goed zichtbaar voor het ontwikkelteam. Log elke fout met voldoende context: het tijdstip, de input die de fout veroorzaakte, het type fout en of de retry slaagde.

Koppel je logs aan een monitoring-dashboard zodat je snel ziet als het foutpercentage stijgt. Een plotselinge piek in fouten is vaak het eerste teken van een API-wijziging bij de provider.

Als een externe dienst herhaaldelijk faalt, heeft het geen zin om te blijven proberen. Het circuit breaker patroon stopt aanroepen automatisch als het foutpercentage een drempel overschrijdt, wacht een bepaalde tijd en probeert dan opnieuw. Dit beschermt je systeem tegen cascadefouten en geeft de externe dienst tijd om te herstellen.

Robuuste error handling is geen optioneel extra maar een kernonderdeel van elke AI-applicatie die in productie draait. Mach8 bouwt AI-workflows met retry-logica, validatie en monitoring ingebakken, zodat ze stabiel blijven ook als het model of de onderliggende API een keer tegenvalt.

Wil je weten hoe Mach8 betrouwbare AI-systemen bouwt? Bekijk onze AI-agents service of plan een gesprek.