Dutch 
English 
French 
German 
Docbyte heeft in samenwerking met een grote verzekeraar een groot taalmodel (LLM) geïntegreerd als contextuele redeneerlaag bovenop een bestaande documentworkflow. De workflow zelf bleef ongewijzigd.
De verzekeraar’s intelligent document processing De (IDP)-workflow verwerkte reeds inkomende correspondentie van klanten en makelaars, maar maakte daarbij gebruik van meer traditionele technologieën: cloudgebaseerde machine learning-modellen in combinatie met regels op basis van trefwoorden. Niets bijzonders, maar het werkte. Het vereiste echter voortdurende aanpassingen, omdat documentformaten, producten en terminologie voortdurend veranderen en documenttypes met een hoge mate van gelijkenis moeilijk betrouwbaar van elkaar te onderscheiden waren. De machine-learningmodellen misten het vereiste vermogen om te redeneren op basis van nuances en context die starre regels simpelweg niet konden vatten.
Het probleem: een werkproces dat voortdurend aandacht vereiste
De workflow verwerkt ongeveer 50.000 documenten per werkdag. Ongeveer 97% van het binnenkomende materiaal bestaat uit e-mails van klanten, verzekeraars en makelaars, vaak met meerdere bijlagen, die grotendeels digitaal zijn gegenereerd, maar waarin ook enkele scans en handgeschreven tekst zijn verwerkt. Voor elk van deze documenten moet het proces twee vragen beantwoorden: bij welke bestaande schadeclaim het hoort en om wat voor soort verzoek het gaat.
Dit is dus duidelijk een taak op het gebied van informatieclassificatie: het vaststellen van het juiste documenttype, het juiste dossiertype en de juiste schadeclaim. Classificatie is moeilijker dan gegevensextractie. Veel IDP-platforms bieden alleen extractie aan, omdat zij denken: “Ach, we hoeven alleen maar het schadeclaimnummer en een paar trefwoorden te extraheren!”
Een verkeerd type maar de juiste hoofdletter of kleine letter leidt tot een snelle herindeling. Als de hoofdletters of kleine letters helemaal niet overeenkomen, wordt het document doorgestuurd voor menselijke beoordeling, omdat er geen
een veilige, geautomatiseerde uitwijkoplossing hiervoor. De typeclassificatie is belangrijk, maar vormt een secundaire maatstaf.
De verzekeraar heeft deze aanpak getest binnen zijn bedrijfsonderdeel autoverzekeringen: het onderdeel met het grootste volume en de meest complexe, moeilijkst te onderscheiden documentenverzameling. Dit werd bewust gekozen als een veeleisende testcase. Indien de redeneringslaag de lat niet zou kunnen halen bij het moeilijkste probleem waarmee het bedrijf te maken had, was het niet de moeite waard om verder uit te bouwen.
Het proefproject had betrekking op 16 door het bedrijf gedefinieerde documentcategorieën: offerteaanvragen, voorstellen en contracten, poliswijzigingen, registraties
en annuleringsverzoeken, uitschrijvingsberichten, informatieverzoeken, overlijdensberichten en faillissementsberichten. Deze zijn niet altijd visueel
verschillende sjablonen. Een kennisgeving van uitschrijving, waarbij een kenteken wordt ingetrokken, kan ook de opzegging van de bijbehorende verzekering inhouden. Het betreft hier een specifieke zakelijke gebeurtenis en geen standaardformulering voor een opzegging. Dat is precies het soort dubbelzinnigheid waarmee op trefwoorden en voorbeelden getrainde machine learning-modellen moeite hebben om bij te blijven.
De uitgangssituatie: een systeem dat steeds meer achterop raakte
Alvorens iets nieuws te testen, bracht het team de huidige stand van zaken in kaart. Het bestaande model maakt gebruik van OCR als invoer en begon bij deze taak met een nauwkeurigheid van ongeveer 60%, maar was teruggevallen tot ongeveer 40% naarmate de opmaak en terminologie waren veranderd. Hertraining was evenmin een optie. De documenttypes waren nooit op consistente wijze opnieuw gelabeld, waardoor er geen betrouwbare referentiebron beschikbaar was om het model op te trainen.
Die achteruitgang was belangrijker dan het absolute cijfer. Een model dat na verloop van tijd aan nauwkeurigheid inboet, zorgt ervoor dat er meer werk moet worden verricht door middel van handmatige controle, en die verschuiving
wordt steeds ernstiger naarmate het model langer ongewijzigd blijft.
Wat er is gebouwd: een LLM die op het bestaande platform is geïntegreerd
In het kader van het project werd de bestaande workflow voor gecontroleerde documenten gehandhaafd en werd daarbovenop een LLM toegevoegd als redeneerlaag. De pijplijn:
- Sla de e-mail en de bijlagen op, inclusief gescand materiaal.
- Zet de invoer om in een PDF-weergave.
- Stuur het naar het LLM, samen met de toegestane classificaties, bedrijfsdefinities en beslissingsregels.
- Geef het dossiernummer, een gestructureerde classificatie en de door het model gegenereerde toelichting weer.
- Controleer het resultaat en exporteer het naar de casemanagementomgeving, waar de daadwerkelijke vervolgacties plaatsvinden.
Het model krijgt geen taak met een open einde. Om het risico en de operationele gevolgen van niet-ondersteunde antwoorden te beperken, wordt bij elk verzoek een nieuwe, beperkte sessie gestart en moet de classificatie afkomstig zijn uit een gesloten reeks toegestane waarden. Deterministische diensten blijven verantwoordelijk voor validatie, routering, opslag en de uitvoering van de workflow. Juist dankzij die beperking is het mogelijk om te vertrouwen op de output van het model zonder dat men hoeft te vertrouwen op de
het model zelf.
Aangezien de toewijzing van schadeclaims de maatstaf is die ertoe doet, wordt hier in de verwerkingsstroom op passende wijze rekening mee gehouden: het geëxtraheerde zaaknummer doorloopt een deterministische
Validatie en ongeldige resultaten worden aan een medewerker doorgegeven in plaats van dat er een ogenschijnlijk plausibele toewijzing wordt afgedwongen. Fouten in de classificatie van typen worden soepeler behandeld, aangezien dit de goedkoopste fout is om te corrigeren. De door het model gegenereerde toelichting wordt eveneens in de interface weergegeven. Dit is evenmin een bewijs dat het antwoord correct is, maar het stelt de medewerkers die de zaak behandelen in staat te zien waarom het document in die categorie is ingedeeld, in plaats van het heen en weer te sturen. Dit is min of meer dezelfde werkwijze als bij menselijke casemanagers, waarbij de ene persoon een document op een andere manier zou classificeren dan zijn of haar collega. Bovendien helpt dit implementatieteams om systematische fouten op te sporen en documentdefinities te verfijnen.
De fouten hebben ons iets nuttigs geleerd
De meest opvallende verwarring bestond tussen een kennisgeving van uitschrijving en een algemene annulering. In plaats van een hertrainingscyclus uit te voeren, wordt dit opgelost door de definitie van de classificatie te verduidelijken: uitschrijving als een specifiek subtype van annulering, dat expliciet gekoppeld is aan het verwijderen van de kentekenplaat. Het corrigeren van een bekend foutpatroon vereist het aanpassen van een definitie in plaats van het trainen of hertrainen van een model.
In een afzonderlijke test werd nagegaan of het LLM een meerwaarde bood voor de documenten die het belangrijkst waren: namelijk die documenten die het bestaande ML-model al verkeerd had ingedeeld. Het LLM classificeerde 7% van de documenten in deze subgroep correct, die juist was geselecteerd omdat het bestaande model ze verkeerd had ingedeeld. Dit is geen rechtstreekse algemene benchmark, aangezien de nauwkeurigheid van het bestaande model op diezelfde subset per definitie 0% bedraagt, maar het toont aan dat de redeneringslaag een aanzienlijk deel van de fouten in de bestaande workflow heeft gecorrigeerd. Dit betekent dat het slagingspercentage voor deze uitzonderingen is gestegen van 0% naar 73%.
De resultaten tot nu toe
De onderstaande cijfers geven de classificatie naar documenttype weer, de secundaire maatstaf. De toewijzing van dossiers zelf wordt niet op dezelfde manier beoordeeld: het geëxtraheerde dossiernummer doorstaat de deterministische validatie of niet, en onduidelijke gevallen worden ter beoordeling aan een medewerker voorgelegd in plaats van als percentage weergegeven.
| Aanpak | Nauwkeurigheid |
|---|---|
| Bestaand ML-model (in kwaliteit achteruitgegaan ten opzichte van een oorspronkelijk model van ~60%) | 40% |
| LLM (Gemini 2.5 Flash) – volledig testvoorbeeld | 80% |
Het cijfer van 80% werd bereikt zonder aanvullende modeltraining of fijnafstemming, op basis van een eerste testset die handmatig was gecontroleerd en beoordeeld in overleg met de vakspecialisten van de verzekeraar. Het voordeel vloeide voort uit het vermogen van het model om de relatie tussen zinsdelen in een e-mail en de bijlagen daarvan te wegen, en om een in natuurlijke taal opgestelde bedrijfsdefinitie toe te passen in plaats van een definitie die was ingebakken in een eigen, opnieuw trainbare classificator.
Wat dit voor het bedrijf betekent
In de dagelijkse praktijk verloopt de workflow nu op drie concrete punten anders.
- Meertalige verwerking: de oplossing levert in elke taal dezelfde resultaten op, zonder dat er voor elke taal een aparte set documenten nodig is om het model te trainen.
- Het verfijnen van regels wordt eenvoudiger: een bekend punt van verwarring, zoals de overlap tussen uitschrijving en annulering, wordt verholpen door een definitie te verscherpen, en niet door een model opnieuw te trainen of te wachten op een nieuwe releasecyclus.
- De beoordeling wordt transparanter: de door het model gegenereerde uitleg wordt in de interface weergegeven, zodat de medewerkers die een zaak behandelen, direct kunnen zien waarom deze daar terecht is gekomen, in plaats van de zaak door te moeten sturen om daar achter te komen.
Een tip: betrek de beveiligingsafdeling en de functionaris voor gegevensbescherming erbij voordat de businesscase is afgerond
Een sterke businesscase is op zichzelf niet voldoende. Als het bedrijf een LLM in de werkstroom wil opnemen, maar de beveiliging of de functionaris voor gegevensbescherming
Zolang er geen goedkeuring is gegeven voor de bestemming van de gegevens, de wijze waarop deze worden bewaard en wie er toegang toe heeft, gaat het project niet van start, hoe goed de nauwkeurigheidscijfers er ook uitzien. Betrek die belanghebbenden erbij terwijl de architectuur nog in ontwikkeling is, en niet pas nadat een pilot het concept al heeft bewezen. Juist die volgorde zorgt er meestal voor dat een goed werkende pilot vastloopt voordat deze in productie gaat: de gegevensstroom, de bewaartermijnen en de voorwaarden voor gegevensverwerking worden pas beoordeeld als het concept al werkt, in plaats van terwijl de architectuur nog openstaat.
Het ontwerp en de eerste ontwikkelingsfase hebben ongeveer drie tot vier maanden in beslag genomen. Het grootste deel van die tijd is besteed aan het herontwerpen van de pijplijn zelf, samen met
overleg met de organisatie over documenttypes en wat deze van elkaar onderscheidt. De LLM neemt de noodzaak van die domeinkennis niet weg. Het maakt het wel gemakkelijker om deze kennis te verwoorden, te toetsen en te verfijnen, en dat is precies het werk dat momenteel wordt verricht om de overstap te maken van 80% naar 90%.
IDP biedt nog steeds de mogelijkheden voor vastlegging, structurering en controle, en de LLM voegt daar contextuele interpretatie aan toe. Bedrijfsregels, validatie en
Het zijn de mensen die van die combinatie een proces maken waarop men kan vertrouwen. In plaats van uitsluitend te focussen op de classificatienauwkeurigheid, is de belangrijkste maatstaf hoe vaak het document bij de eerste poging bij de juiste zaak terechtkomt.
Ga na hoe uw documentworkflow omgaat met gevallen die niet in het stramien passen
Wij kunnen u helpen in kaart te brengen op welke punten in uw documentworkflow een LLM-redeneringslaag het meest van pas zou komen: welke classificaties dubbelzinnig zijn, hoe een veilige terugvaloptie naar menselijke beoordeling eruitziet, en hoe de validatie van zaken deterministisch blijft terwijl het model de interpretatie voor zijn rekening neemt.
FAQs
Betekent de invoering van een LLM dat het bestaande IDP-systeem wordt afgeschaft?
Nee. De LLM fungeert als een redeneerlaag bovenop de bestaande workflow. Deterministische validatie, routering en casemanagement blijven bepalend voor wat er verderop in het proces gebeurt.
Waarom wordt de toewijzing van gevallen gemeten in plaats van de algehele classificatienauwkeurigheid?
Omdat de twee fouten verschillende kosten met zich meebrengen. Een document dat wel bij de juiste zaak hoort, maar van het verkeerde type is, kan snel worden doorverwezen. Een document dat bij geen enkele zaak past, wordt handmatig beoordeeld, zonder dat er een geautomatiseerde alternatieve oplossing beschikbaar is.
Waarom zou men met de moeilijkste documentenset beginnen in plaats van met de gemakkelijkste?
Om in een vroeg stadium na te gaan of de aanpak onder reële omstandigheden standhoudt, in plaats van een kleiner punt aan te tonen bij een eenvoudigere bedrijfsonderdeel en de moeilijkere vraag open te laten.
