De tabeller, der ikke eksisterede

Kapitel 2 — De tabeller, der ikke eksisterede

En tekniker fra en mekanisk virksomhed i Norditalien fortalte os det over en espresso, med den ro, der er typisk for folk fra Veneto, og som varsler en katastrofe: "Vores chatbot vidste alt om motoren. Bortset fra motordataerne." Derefter forklarede han. Deres interne AI-assistent kunne beskrive produktsortimenter, anvendelseskontekster, brandhistorie, konkurrencefordele. En vidunderlig fortælling. Men når en kunde spurgte om det nominelle drejningsmoment for modellen CMP50L — altså det tekniske data, folk slår op i kataloget, det nummer, man køber en motor for — svarede chatbotten vagt, nogle gange plausibelt, nogle gange ikke. Fem måneders udvikling, en stadig mere forvirret driftsdirektør, og ingen, der kunne forklare hvorfor.

Diagnosen kom ved et tilfælde, næsten af kedsomhed, ved manuel inspektion af databasen efter endnu et resultatløst møde. PDF-kataloget indeholdt 342 tekniske tabeller. I databasen var der ankommet nul. Ikke en håndfuld: nul. Ingen. Koden, der udvandt tabellerne fra PDF'erne, gemte dataene i felter kaldet columns og data, mens koden, der efterfølgende indekserede dem, forventede felter kaldet headers og rows. En ikke-respekteret "synonym". En intern konvention, der var blevet sprunget over i en glemt refaktorering. Resultatet, i fem stille måneder: hele katalogets numeriske intelligens – par, potenser, diametre, vægte, ordrekoder, forsyningsspændinger – var løbet ud af hanen uden nogensinde at blive hældt i glasset. Trehundrede og toogfyrre tabeller, mistet én efter én i stille liturgisk form.

Dette er den slags fejl, der ikke råber op. De udløser ikke undtagelser, får intet til at crashe, og de dukker ikke op i nogen logfiler. Simpelthen ophører en del af verden med at eksistere for dit system, og ingen bemærker det, indtil en bruger – typisk en vred bruger – stiller tilstrækkeligt insisterende spørgsmål for at afsløre afgrunden. Og det er et symbol på et meget større problem end feltnavne: generiske RAG-frameworks er optimeret til løbende tekst – artikler, websider, afsnit af fiktion – og behandler tabeller som andenklasses borgere, når de overhovedet behandler dem. Men italienske virksomhedsdokumenter *er* ofte tabeller. Tekniske kataloger, prislister, produktspecifikationer, sikkerhedsdatablade, ordrebekræftelser: den værdifulde del for dem, der konsulterer disse dokumenter, er den tabelformede. Den der går i stykker først, og som ingen bemærker.

Lektionen er ikke "vær opmærksom på feltnavnene". Den er mere besværlig: i et seriøst RAG har enhver type indhold – tabeller, billeder, alfanumeriske koder, afsnitsoverskrifter, fodnoter – brug for en dedikeret, designet, testet behandling. Og funktionalitetstesten er ikke "chatbotten svarer på trivielle spørgsmål" – det gør selv defekte systemer, fordi der er tilstrækkeligt med flydende data til at konstruere noget plausibelt. Den ægte test er "chatbotten svarer på spørgsmål, der tvinger den til at berøre hvert eneste stykke af pipelinen". Specifikke, numeriske, verificerbare spørgsmål. Spørgsmål, hvor der findes ét korrekt svar, og hvis systemet tager fejl, ved du det straks.

Hvis du ikke foretager denne test, ved du ikke, om dit RAG fungerer. Du ved kun, at det ikke klager. Og "klager ikke" er et meget lavt kvalitetskriterium for et system, som folk vil bruge til at træffe beslutninger.