De tabellen die er niet waren

Hoofdstuk 2 — De tabellen die er niet waren

Een technicus van een mechanisch bedrijf uit het noordoosten vertelde het ons bij een espresso, met die kalmte die kenmerkend is voor de Venetianen en die een ramp aankondigt: "Onze chatbot wist alles over de motor. Behalve de gegevens van de motor." Vervolgens legde hij uit. Hun interne AI-assistent kon productreeksen, gebruiksscenario's, de geschiedenis van het merk en de concurrentievoordelen beschrijven. Een wonderbaarlijke prestatie op narratief vlak. Maar toen een klant de nominale koppel van het CMP50L-model vroeg - dus de technische data waarvoor mensen de catalogus openslaan, het nummer waarvoor een motor wordt gekocht - antwoordde de chatbot vaag, soms plausibel, soms niet. Vijf maanden ontwikkeling, een steeds verwardere operationeel directeur, en niemand die kon zeggen waarom.

De diagnose kwam per toeval, bijna uit verveling, toen ik handmatig de database inspecteerde na de zoveelste bijeenkomst zonder resultaat. De PDF-catalogus bevatte 342 technische tabellen. In de database waren er nul binnengekomen. Niet een handvol: nul. Geen enkele. De code die de tabellen uit de PDF's extraheerde, slaagde de gegevens op in velden met de naam columns en data, terwijl de code die ze vervolgens indexeerde, velden met de naam headers en rows verwachtte. Een niet-gerespecteerde "synoniem". Een interne conventie die was geschonden tijdens een vergeten refactoring. Het resultaat, gedurende vijf stille maanden: de gehele numerieke intelligentie van de catalogus — paren, vermogens, diameters, gewichten, bestelcodes, voedingsspanningen — stroomde uit de kraan zonder ooit in het glas te worden gegoten. Driehonderd tweeënveertig tabellen, één voor één verloren in stil liturgisch ritme.

Dit is het soort bug dat niet schreeuwt. Het roept geen uitzonderingen op, laat niets crashen, verschijnt in geen enkele log. Simpelweg, een deel van de wereld stopt met bestaan voor jouw systeem, en niemand merkt het op totdat een gebruiker — meestal een boze gebruiker — genoeg hardnekkige vragen stelt om de afgrond te laten zien. En het is exemplarisch voor een veel groter probleem dan de namen van de velden: generieke RAG-frameworks zijn geoptimaliseerd voor lopende tekst — artikelen, webpagina's, alinea's fictie — en behandelen tabellen als tweederangsburgers, wanneer ze ze behandelen. Maar Italiaanse zakelijke documenten zijn vaak tabellen. Technische catalogi, prijslijsten, productspecificaties, veiligheidsbladen, bestelbulletins: het waardevolle deel, voor wie deze documenten raadpleegt, is dat tabellair. Datgene dat het eerst kapot gaat en waarvan niemand het merkt.

De les is niet "let op de veldnamen". Het is ingewikkelder: in een serieuze RAG (Retrieval-Augmented Generation) heeft elk type inhoud – tabellen, afbeeldingen, alfanumerieke codes, paragraaftitels, voetnoten – een speciale behandeling nodig, die ontworpen en getest moet worden. En de functionaliteitstest is niet "de chatbot beantwoordt triviale vragen" – daarop antwoorden zelfs defecte systemen, omdat er genoeg drijvende data is om iets plausibels te construeren. De echte test is "de chatbot beantwoordt vragen die hem dwingen elk afzonderlijk onderdeel van de pipeline aan te raken". Specifieke, numerieke, verifieerbare vragen. Vragen waarvoor er één juist antwoord is, en als het systeem het fout heeft, weet je het meteen.

Als je deze test niet uitvoert, weet je niet of je RAG werkt. Je weet alleen dat hij niet klaagt. En "niet klagen" is een zeer lage kwaliteitsnorm voor een systeem dat mensen zullen gebruiken om beslissingen te nemen.