Waarom een chatbot op uw eigen documenten niet werkt zoals u hoopt
Ik bouw deze systemen. Documenten inlezen, opknippen, embeddings maken, een vectordatabase erachter, een taalmodel ervoor. Technisch is het inmiddels een avond werk. En toch krijg ik bij vrijwel elke klant dezelfde vraag terug: waarom klopt het antwoord niet?
Het eerlijke antwoord is ongemakkelijk voor mijn eigen vakgebied. Het ligt niet aan de chunking, niet aan het embeddingmodel en niet aan de reranker. Het ligt aan iets waar geen enkele architectuurkeuze omheen komt.
Wat retrieval werkelijk doet
Als iemand vraagt wat de maximale korting is voor een bepaalde klant, gebeurt er dit: de vraag wordt omgezet naar een vector, en het systeem zoekt de passages waarvan de vector daar het dichtst bij ligt. Dat is een gelijkenismaat, geen oordeel.
Wat er terugkomt zijn vier fragmenten. Een prijslijst uit het eerste kwartaal. Een presentatie van de salesdag. Een bericht van de verkoopleider. Een verkoophandboek uit 2021. Alle vier gaan ze over korting, alle vier lijken ze sterk op de vraag, en precies daarom scoren ze alle vier hoog.
Semantische gelijkenis meet waar iets over gáát. Het meet niet of het waar is, of het nog geldt, of wie het heeft goedgekeurd.
Het model krijgt die vier fragmenten in zijn context en moet er één antwoord van maken. Er is geen veld waaruit het kan aflezen welke de geldende is, want dat veld bestaat niet. Dus doet het wat het altijd doet: het produceert het meest waarschijnlijke antwoord, vloeiend geformuleerd, zonder voorbehoud.
De vier oplossingen die niet werken
Een groter contextvenster
De gedachte: gooi gewoon alles erin, dan ziet het model het volledige plaatje. In de praktijk betekent het dat het model méér tegenstrijdige bronnen tegelijk ziet. Het weet nog steeds niet welke wint, en de kans op een verkeerde keuze neemt eerder toe dan af.
Een beter model
Een sterker model redeneert beter over de informatie die het heeft. Als de informatie die nodig is om te kiezen ontbreekt, wordt het antwoord niet juister, alleen overtuigender geformuleerd. Dat is hier een verslechtering: een twijfelend antwoord had u nog kunnen waarschuwen.
Een kennisgraaf
Ik heb er zelf aan gebouwd, en ze zijn mooi. Ze ordenen wat er is: welk document hoort bij welke klant, welk product, welk proces. Maar een graaf van verouderde documenten is een keurig geordende verzameling verouderde documenten. Een CTO die ik ken vatte het samen met: de graaf werkt perfect, de informatie klopt nog steeds niet.
Betere prompts
"Antwoord alleen op basis van de meest recente bron." Klinkt logisch. Maar het model weet niet wat de meest recente bron is, tenzij dat als data in de tekst staat. En bij de meeste bedrijfsdocumenten staat er geen betrouwbare datum in, laat staan een goedkeuringsdatum.
Wat er ontbreekt is metadata, geen intelligentie
Om te bepalen welk van vier antwoorden geldt, heb je precies drie dingen nodig. Ze zijn saai, ze zijn niet technisch ingewikkeld, en ze staan bijna nooit ergens vast:
- Wie heeft dit goedgekeurd. Een naam, geen afdeling. Een afdeling kan niets goedkeuren.
- Wanneer. En daarbij: wanneer wordt het opnieuw bekeken? Zonder herzieningsmoment veroudert alles stilletjes.
- Waar komt het vandaan. Welke overeenkomst, welk besluit, welke afspraak, zodat het antwoord controleerbaar is.
Staan die drie velden bij elke regel, dan wordt het probleem opeens triviaal. Twee bronnen spreken elkaar tegen? Dan wint degene met de meest recente goedkeuring door de bevoegde eigenaar. Dat is geen AI-vraagstuk meer maar een sorteervraag.
Waarom dit niet automatisch kan
De voor de hand liggende vervolgvraag is of je die metadata niet gewoon door een model kunt laten genereren. Dat kan, en het is een slecht idee.
Een model kan raden wie iets waarschijnlijk heeft goedgekeurd. Die gok ziet er precies hetzelfde uit als een feit: dezelfde opmaak, dezelfde stelligheid. Daarna is hij niet meer van een feit te onderscheiden. Je hebt dan geen governance toegevoegd, je hebt een tweede laag onbetrouwbaarheid gemaakt en die er officieel uit laten zien.
Om die reden bouwen wij het andersom. Het model mag structureren, samenvatten en voorstellen doen. Het mag nooit een tegenstrijdigheid stilletjes oplossen. Vindt het systeem twee versies die elkaar tegenspreken, dan markeert het beide, citeert het beide, en legt het de keuze bij een mens. Die keuze wordt vastgelegd, inclusief wie hem maakte.
Dat is trager. Het is ook het enige waarmee je later kunt uitleggen waarom er stond wat er stond.
Waar de techniek dan wél voor is
Ik ben niet tegen retrieval. Ik gebruik het dagelijks. Het is uitstekend voor vinden: waar staat dit contract, welke versie van dit document is de laatste, waar hebben we het eerder over gehad.
Maar er is een categorie vragen waar geen document bij hoort. "Mag deze klant zestig dagen betalen." Die afspraak is gemaakt, niet geschreven. En je kunt niet indexeren wat nooit is opgeschreven, hoe goed je architectuur ook is.
Voor die categorie moet je eerst iets doen dat niet technisch is: het ophalen bij de mensen die het weten, laten bevestigen door degene die erover gaat, en vastleggen met eigenaar, datum en bron. Pas dan heeft je retrieval iets om op te werken dat een antwoord kan dragen.
Hoe u dit zelf test
Als u een chatbot op eigen documenten heeft draaien, stel hem dan een besluitvraag waar geld aan hangt. Niet "waar staat X", maar "mag X". Kijk daarna naar de bronnen die hij aanhaalt en vraag uzelf drie dingen af:
- Weet ik van elke bron wanneer hij is goedgekeurd?
- Weet ik wie ervoor verantwoordelijk is?
- Als twee bronnen elkaar tegenspreken, heeft het systeem mij dat verteld?
Beantwoord de drie vragen.
Is het antwoord drie keer nee, dan is uw probleem niet de architectuur. Dan is het wat eronder ligt.
Wilt u weten hoe dit bij u ligt?
Een half uur met twee van ons. Daarna krijgt u één A4: de afspraken die bij u het grootste risico lopen, en wie ze zou moeten bezitten. U houdt dat A4, ook als we niet verder gaan.
Plan de check →