💬 NLP

Building Customer Support AI Agents at 100M-User Scale: An Evaluation-Driven Framework

Dit artikel presenteert een verenigd, evaluatiegestuurd framework ontwikkeld bij Nubank dat gestructureerde context engineering, human-in-the-loop iteratie en rigoureuze LLM-judge evaluatie integreert om succesvol productie-klare klantenservice AI-agenten te implementeren over vijf domeinen voor meer dan 100 miljoen gebruikers, waarbij significante verbeteringen in tevredenheid en zelfbedieningspercentages worden bereikt terwijl een sterke correlatie tussen offline metrieken en online impact wordt aangetoond.

Oorspronkelijke auteurs: Aman Gupta, Kevin Rossell, Edesio Alcobaça, Jose Chrystian Lima Pacheco, Carolina Baptista de Lima, Shao Tang, Luiz Paulo Rabachini, Luis Moneda, Herbert Fei, Daniel Silva, Rohan Ramanath

Gepubliceerd 2026-06-09

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Aman Gupta, Kevin Rossell, Edesio Alcobaça, Jose Chrystian Lima Pacheco, Carolina Baptista de Lima, Shao Tang, Luiz Paulo Rabachini, Luis Moneda, Herbert Fei, Daniel Silva, Rohan Ramanath

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme bank runt met 100 miljoen klanten. Elke dag bellen of chatten miljoenen mensen met vragen als: "Waar is mijn creditcard?" of "Waarom moet ik dit bedrag betalen?"

In het verleden had je een leger aan menselijke agenten nodig om deze vragen te beantwoorden. Maar nu wil je een super-slimme AI-robot bouwen om deze gesprekken af te handelen. Het probleem? Als de robot een fout antwoord geeft, wordt een klant boos, verliest hij vertrouwen en vertrekt hij. Je kunt niet zomaar "gokken" of de robot goed is; je moet 100% zeker zijn voordat je hem met echte mensen laat praten.

Dit artikel is een blauwdruk van Nubank (een gigantische bank) over hoe zij deze AI-robots veilig en succesvol hebben gebouwd. Hier is hoe ze het deden, simpel uitgelegd:

1. Het Probleel: Een Robot Bouwen Zonder een Crashtest

Normaal gesproken, wanneer mensen AI bouwen, schrijven ze instructies, testen het een beetje en hopen ze op het beste. De auteurs zeggen dat dit is alsof je een auto bouwt en van een klif afrijdt om te zien of de airbags werken. In de klantenservice is een crash te duur.

Ze hadden een manier nodig om de robot duizenden keren te testen in een "simulator" voordat ze zelfs maar met één echt mens lieten praten.

2. De Oplossing: De "Evaluatie-gestuurde" Fabriek

In plaats van alleen instructies te schrijven, bouwden ze een productielijn met vier stations. Denk aan het afstellen van een racewagen:

Station 1: De Modulaire Kit (Context Engineering)
In plaats van één grote, rommelige instructiehandleiding voor de robot te schrijven, braken ze deze op in Lego-blokjes.
- De Regels: Hoe de robot moet spreken (beleefd, bondig).
- Het Playbook: Stap-voor-stap handleidingen voor specifieke problemen (bijv. "Als de kaart verloren is, doe dan stap A, en dan stap B").
- De Tools: Een lijst met dingen die de robot daadwerkelijk kan doen (zoals een database controleren of een kaart opnieuw uitgeven).
- Het Geheugen: Een kladblok waar de robot aantekeningen maakt van wat hij tijdens de chat heeft geleerd.
- Waarom het belangrijk is: Als de robot de begroeting fout doet, vervang je alleen het "Begroetings-Lego blokje". Je hoeft niet de hele auto opnieuw te bouwen.
Station 2: De Robot-rechters (LLM-as-a-Judge)
Hoe weet je of de robot zijn werk goed doet? Je kunt de robot niet zichzelf laten beoordelen. Daarom gebruikten ze een andere AI (de "Rechter") om de antwoorden van de eerste robot te beoordelen.
- De Valkuil: Soms is de Rechter-AI bevooroordeeld of lui. Om dit op te lossen, gebruikten ze een speciale techniek genaamd GEPA. Stel je een coach voor die de Rechter-AI ziet een toets nakijken, beseft dat de Rechter te streng was, en het beoordelingsprotocol herschrijft om het eerlijker te maken. Ze deden dit automatisch totdat de beoordeling super consistent werd.
Station 3: Het Menselijke Veiligheidsnet (Inter-Rater Reliability)
Voordat ze de AI-rechter vertrouwden, lieten ze echte mensen dezelfde antwoorden beoordelen. Ze controleerden of de mensen het met elkaar eens waren. Als de mensen in 90% van de gevallen het eens waren, wisten ze dat de test eerlijk was. Vervolgens zorgden ze ervoor dat de AI-rechter net zo goed met de mensen overeenkwam.
Station 4: De Test in de Echte Wereld (A/B-testen)
Zodra de robot de tests in de simulator had doorstaan, lieten ze hem praten met een kleine groep echte klanten (zoals 1% van de gebruikers). Ze vergeleken deze robot met het oude systeem. Als de nieuwe robot klanten gelukkiger maakte, lieten ze hem met meer mensen praten.

3. De Resultaten: De Robot Wint

Ze testten dit systeem op vijf verschillende soorten problemen:

Kaartlevering: "Waar is mijn kaart?"
Schuldbeheer: "Hoe betaal ik mijn lening af?"
Kredietlimieten: "Kan ik een hogere limiet krijgen?"
Kaartbeheer: "Mijn pincode wijzigen."
Productverklaring: "Wat doet deze functie?"

De Magische Cijfers:

Geluk: Voor de "Kaartlevering"-robot steeg het klantgeluk (gemeten via een score genaamd tNPS) met 37 punten. Dat is een enorme verbetering.
Zelfbediening: Meer mensen losten hun problemen op zonder een mens nodig te hebben. De "zelfbedieningsgraad" steeg met 29 punten.
Mens vs. Robot: In vier van de vijf gevallen was de robot bijna net zo goed als een top-expert mens (binnen enkele procentpunten). Het enige gebied waar de robot wat moeite mee had, was het zeer complexe "Schuldbeheer", wat logisch is omdat dat de moeilijkste wiskunde en empathie vereist.

4. De Belangrijkste Les: "Als je het kunt meten, kun je het oplossen"

De belangrijkste les uit het artikel is dit: De kwaliteit van je testen bepaalt hoe snel je kunt verbeteren.

Omdat ze zo'n rigoureus testingsysteem (de "simulator") hadden gebouwd, konden ze wijzigingen aanbrengen in de instructies van de robot en onmiddellijk weten of het beter of slechter werd. Ze hoefden niet weken te wachten om te zien of klanten gelukkig waren. Ze konden de robot tientallen keren verbeteren in de simulator, en toen ze hem eindelijk lanceerden, was hij al een kampioen.

Kortom: Ze bouwden niet alleen een slimme AI; ze bouwden een slim testlaboratorium voor de AI. En omdat het lab zo goed was, was de robot die ze de wereld in stuurden ongelooflijk betrouwbaar, maakte hij mensen gelukkig en was hij klaar voor 100 miljoen gebruikers.

Technische Samenvatting: Het bouwen van AI-klantenserviceagenten op een schaal van 100 miljoen gebruikers

Probleemstelling

De snelle vooruitgang van Large Language Models (LLM's) heeft AI-agenten levensvatbaar gemaakt voor complexe taken, maar het implementeren van productie-klare, klantgerichte agenten op schaal blijft een aanzienlijke uitdaging. Binnen de klantenservice (CS), specifiek in omgevingen met een hoog risico zoals de banksector, worden agenten geconfronteerd met unieke beperkingen:

Hoge betrouwbaarheidsdrempels: Een enkele fout kan vertrouwen schaden en leiden tot klantverloop; financiële misslagen kunnen leiden tot aanzienlijke verliezen.
Gevoeligheid van gegevens: Agenten moeten echte klantgegevens verwerken (saldi, transacties) onder strikte privacy- en regelgevingsbeperkingen.
Specialisatie versus Diversiteit: Agenten maken gebruik van nauwe, domeinspecifieke toolsets (5–15 tools), maar moeten een substantiële diversiteit aan randgevallen (edge cases) afhandelen.
Gracieus overdragen (Graceful Handoff): Agenten moeten opereren binnen een human-in-the-loop workflow, waarbij de controle wordt overgedragen met behoud van de volledige context wanneer automatisering faalt.

Een kritische kloof die is geïdentificeerd, is dat evaluatiemethodologie, context engineering, training en online meting doorgaans geïsoleerd worden ontwikkeld. Dit creëert "blinde vlekken" die pas na implementatie aan de oppervlakte komen, wat de iteratiesnelheid vertraagt en het risico op productiefouten vergroot.

Methodologie: Een Evaluatie-gestuurd Framework

De auteurs presenteren een verenigd framework dat offline ontwikkeling verbindt met online impact, gevalideerd bij een bedrijf dat meer dan 100 miljoen gebruikers bedient. De kernfilosofie is dat de kwaliteit van de evaluatie-pipeline direct de iteratiesnelheid bepaalt.

1. Modulaire Context Engineering

In plaats van monolithische prompts gebruikt het systeem een semantisch versioneerde, modulaire architectuur waarbij componenten onafhankelijk worden beheerd:

Instructies: Roldefinities, gedragsrestricties en nalevingsregels (compliance guardrails).
Routines: Geordende, stapsgewijze procedures afgeleid van menselijke standaardwerkinstructies (SOP's) (bijv. flows voor het onderzoeken van de bezorging van een kaart).
Macros: Vooraf geschreven antwoordtemplates die door de agent worden aangepast.
Tool Specificaties: Onafhankelijke beschrijvingen van tools (schema, input/output, aanroepvoorwaarden) waardoor recombinatie mogelijk is.
Werkgeheugen (Working Memory): Een persistent kladblok dat de status van het gesprek bijhoudt om redundante aanroepen te voorkomen.

2. Rigoureuze Evaluatie Pipeline

Het framework maakt gebruik van een LLM-as-a-Judge benadering, versterkt door specifieke betrouwbaarheidsmaatregelen:

Human-in-the-Loop (HITL) Iteratie: Domeinexperts annoteren gegevens met binaire labels en tekstuele rationales.
GEPA Optimalisatie: Het systeem gebruikt GEPA (binnen het DSPy-framework) om de judge-prompts automatisch te verfijnen. Een sterk model bekritiseert fouten en synthetiseert revisies op basis van menselijke feedback, waarbij geoptimaliseerd wordt voor consistentie.
Inter-Rater Betrouwbaarheid (IRR): Het framework handhaaft minimale overeenkomstdrempels (gemeten via Cohen's $\kappa$ ) tussen meerdere judge-modellen. Prompts worden alleen als betrouwbaar beschouwd als ze stabiele scores opleveren over verschillende modelarchitecturen heen (bijv. GPT-4.1, GPT-5, o3).
Cross-Model Validatie: Zorgt ervoor dat goed gespecificeerde rubrieken stabiele scores opleveren, ongeacht het specifieke judge-model dat wordt gebruikt.

3. Ontwikkelingscyclus

Het proces werkt met twee geneste lussen:

Snelle Lus (Fast Loop): Resultaten van offline evaluaties (simulatiescores) drijven directe prompt-correcties aan. Als een evaluator een fout signaleert, wordt de specifieke promptcomponent chirurgisch aangepast en opnieuw geëvalueerd.
Langzame Lus (Slow Loop): Online metrieken (uit A/B-tests) informeren architecturale wijzigingen, zoals het toevoegen van nieuwe routines of het herontwerpen van tool-interfaces.

4. Infrastructuur en Implementatie

Tool Design: Tools zijn ontworpen voor idempotentie en deterministische orchestratie (het inkapselen van meerstapslogica in enkele tools) om latentie en fouten te verminderen.
Progressieve Uitrol: Nieuwe agenten worden uitgerold bij 1–5% van het verkeer met escalatie naar menselijke agenten op basis van vertrouwen.
Model Portabiliteit: De modulaire architectuur maakt snelle adaptatie mogelijk bij de migratie tussen fundamentele modellen (bijv. van GPT-4.1 naar GPT-5) door specifieke promptcomponenten aan te passen in plaats van het hele systeem te herschrijven.

Belangrijkste Bijdragen

Verenigd Framework: Een gesloten systeem dat agent-architectuur, prompt-versiebeheer, offline evaluatie en online meting verbindt.
Modulaire Context Engineering: Een designpatroon dat onafhankelijke versiebeheer van instructies, routines, macros en tools mogelijk maakt.
Gecalibreerde LLM-as-a-Judge Pipeline: Een rigoureus evaluatiesysteem voorzien van eisen voor inter-rater betrouwbaarheid, GEPA-geoptimaliseerde judge-prompts en cross-model validatie.
In Productie Gevalideerde Resultaten: Empirisch bewijs uit vijf verschillende productie-implementaties (Kaartbezorging, Schuldbeheer, Kredietlimiet, Kaartbeheer, Productverklaring).

Resultaten

Het framework werd gevalideerd over vijf productie-use cases, waarbij de Kaartbezorging-agent als primaire casestudy diende.

Kaartbezorging Implementatie (Hoofdresultaten)

Klanttevredenheid: Behaalde een verbetering van 37 procentpunt (p.p.) in de AI Transactional Net Promoter Score (tNPS) vergeleken met eerdere varianten.
Automatisering: Behaalde een 29 p.p. winst in de Self-Service Rate (SSR).
Menselijke Pariteit: De uiteindelijke AI tNPS landde binnen 10 p.p. van deskundige menselijke agenten.
Offline-Online Correlatie: Er werd een sterke positieve correlatie waargenomen tussen offline evaluatiefoutpercentages en online tNPS/SSR-winsten. Versies met de grootste offline verbeteringen (bijv. V10) leverden de hoogste online winsten op.

Prestaties over Verschillende Domeinen

Over alle vijf de domeinen leverde het framework consistente winst op:

Schuldbeheer: +40 p.p. tNPS winst (hoewel een grotere kloof van -23,6 p.p. restte vergeleken met mensen, wat de complexiteit van het domein weerspiegelt).
Kredietlimiet: +4,5 p.p. tNPS winst; significante reducties in evaluator-foutpercentages voor context en empathie.
Kaartbeheer: +38,3 p.p. tNPS winst.
Productverklaring: +12,3 p.p. tNPS winst.

Effectiviteit van de Evaluatie Pipeline

Prompt Optimalisatie: Geautomatiseerde optimalisatie (GEPA) presteerde consequent beter dan handmatige prompt engineering en de meerderheidsklasse-baselines. Bijvoorbeeld, in Eval E3 steeg de nauwkeurigheid van 58,07% (handmatig) naar 73,01% (geoptimaliseerd).
Inter-Rater Overeenstemming: Niet-geoptimaliseerde "starter" prompts resulteerden in verwaarloosbare overeenstemming tussen modellen ( $\kappa \approx 0,00$ tot $0,10$). GEPA-geoptimaliseerde prompts verhoogden de overeenstemming aanzienlijk (bijv. $\kappa = 0,745$ tussen GPT-4.1 en GPT-4.1-mini; $\kappa = 0,950$ tussen reasoning-intensieve modellen).

Betekenis en Claims

Het artikel claimt dat evaluatiekwaliteit de primaire determinant is van de iteratiesnelheid. Door een betrouwbare "snelle lus" te vestigen via gekalibreerde judges en rigoureuze inter-rater overeenstemming, kunnen teams offline met vertrouwen itereren zonder te hoeven wachten op schaarse online signalen.

De auteurs stellen dat hun framework er succesvol in is geslaagd de kloof te overbruggen tussen offline simulatie en online realiteit, en daarmee bewijst dat eval-gestuurde ontwikkeling betrouwbaar de impact in productie voorspelt. De methodologie bewijst generaliseerbaar te zijn over diverse klantenservice-domeinen, waardoor organisaties AI-agenten kunnen schalen naar 100 miljoen+ gebruikers terwijl ze een hoge kwaliteit, naleving en klanttevredenheid behouden. Het werk benadrukt dat hoewel AI-agenten in veel domeinen menselijk niveau kunnen benaderen, de moeilijkste taken (zoals schuldbeheer) nog steeds zorgvuldig menselijk toezicht en iteratieve verfijning vereisen.