Motoren som hadde seks poler — Myten om de ti linjene med kode

Enquête i seks delene om hvorfor dokumentasjons-chatboten du ble solgt fortsetter å fabrikkere — og om den andre retningen noen begynte å følge tidlig i 2026.

Enquête i seks deler om hvorfor dokumentasjons-chatboten du ble solgt fortsetter å fabrikkere — og om den andre retningen noen begynte å følge tidlig i 2026.

Introduksjon — Motoren som hadde åtte poler (men hadde seks)

Milano, mars 2026. En manager åpner det interne bedrifts-chatbotet, en av de som ble satt sammen "på to uker" fra IT-avdelingen med stor entusiasme og liten skepsis. Et veldig enkelt spørsmål: "Hvor mange poler har CMP40M-motoren?" Chatboten svarer med all den sikkerheten store språkmodeller kan fremvise: "CMP40M-motoren har åtte poler."

Feil. Den har seks. Det riktige svaret lå ikke i katalogen på 422 sider som noen, måneder tidligere, hadde overført med full tillit inn i en vektor-database, overbevist om at systemet deretter "ville vite alt". Den dataen var ikke i katalogen i det hele tatt. Den lå i en PDF-fil som var vedlagt en e-post fra SEW-teknikere, arkivert i en mappe som ingen hadde tatt bryet med å indeksere.

Denne scenen, med variasjoner i bransje og dialekt, gjentar seg i hundrevis av kontorer i Italia. Løftet var enkelt og forlokkende: gi din AI-assistent alle bedriftsdokumentene, og den vil kunne svare på alle spørsmål om dem. Virkeligheten er mye mer prosaisk: chatbotten leser, men forstår ikke, søker, men finner ikke, og når den ikke finner – istedenfor å si det – finner den opp. Den finner opp flytende, med perfekt grammatikk, med plausible tall. Og det er mye verre enn å ikke svare.

Mellom slutten av 2024 og begynnelsen av 2026 brukte vi måneder på å obdusere disse feilene. Ikke for å skape kontroverser, men for å forstå én ting: hvorfor en så lineær idé – "gi den dokumentene og spør den deretter om ting" – blir så vanskelig når den forlater demo-scenen og kommer inn i rommet med ekte servere.

Denne undersøkelsen i seks kapitler forteller hva vi fant: stille feil som slettet hele kataloger, sky-rerankere med feil score, hallusinasjoner som ikke stammet fra modellen, men fra data som var kontaminert år tidligere, fakturaer som gjorde hver spørring dyrere enn den var verdt, og "populære" rammeverk som lover alt på ti linjer kode, forutsatt at du ikke ber dem om for mye. Og i det siste kapittelet, den forskjellige retningen noen begynte å gå i stillhet tidlig i 2026 – en arkitektur der søkestrategien slutter å være kode og blir et dokument som alle i bedriften kan lese og endre.

Hvert kapittel står for seg selv. Hvis du vil begynne med historien om de 342 forsvunnede tabellene, eller den om den løgnaktige rerankeren, er du fri til å gjøre det. Men fortellingen som helhet har en moral som bare kommer frem på slutten: bedrifts-RAG – det tekniske akronymet som står for Retrieval-Augmented Generation, det vil si "generer svar basert på dokumenter du henter først" – er ennå ikke et ferdig produkt. Det er en grense. Og som alle grenser har den så langt blitt fortalt mest av selgere. Det er på tide å lytte til de som har levd inne i den også.

Kapittel 1 – Myten om de ti linjene kode

Sliden er identisk i enhver konferanse om AI fra og med 2023: "Din bedrifts dokumentassistent på 10 linjer kode." Under tittelen, en blokk med Python i pastellfarger som viser et åpen kildekode-bibliotek – typisk en av de kjente amerikanske, hvis navn fremkaller kjeder av trær eller tibetanske lamaer – som laster opp PDF-filer, fragmenterer dem, limer dem inn i en vektor-database og spør dem med en språkmodell. På fem minutter har du en chatbot. På fem minutter, applaus. På fem minutter overbevises en italiensk bedrift av middels størrelse om at problemet er løst og at deres IT-avdeling kan klare det på to uker.

Problemet – det sliden ikke sier – er at demoen er bygget med tre godt formaterte PDF-filer, et spørsmål skreddersydd for å matche innholdet, en scene uten reell latens, og en presentatør som har prøvd alt tjuesju ganger før de gikk på scenen. I virkeligheten er bedriftsdokumenter et geologisk katastrofeområde: skanninger av skanninger, tabeller som overlapper teksten, fotnoter som sniker seg inn i avsnittene, alfanumeriske koder som "RH1M" som chunkeren halverer og tror er ord, bilder som inneholder sytti prosent av den nyttige informasjonen, men som ingen trekker ut, og layouter så kreative at de krever en arkeolog mer enn en parser.

RAG – dette er ideen under panseret – er en god idé. Ta brukerens spørsmål, søk i arkivet ditt etter de mest relevante dokumentene, send dem til språkmodellen og få et svar basert på disse dokumentene. I teorien løser det elegant problemet med hallusinasjoner: modellen trenger ikke lenger å "vite" svaret, den trenger bare å "lese" det i delene du har gitt den. I praksis har hver lenke i kjeden – chunking, embedding, retrieval, reranking, endelig generering – sine egne måter å feile på, og feilen manifesterer seg sjelden som en synlig feil. Den manifesterer seg som et litt feil svar. Deretter som et helt feil svar. Deretter som en leder som lurer på hvorfor han betaler for et system som vet mindre enn praktikanten.

De åpen kildekode-rammeverkene som har popularisert RAG er laget for å demonstrere, ikke for å produsere. De er elegante kjeder av abstraksjoner der hvert lag skjuler en underforstått antakelse: at PDF-filene dine har en anstendig OCR, at bildene dine allerede er beskrevet, at tabellene dine følger en konvensjon, at embedding-modellen faktisk snakker språket ditt (spoiler: mange snakker bare godt engelsk), at arkivet ditt allerede er renset for duplikater. Når en av disse antakelsene svikter – og minst én svikter alltid, nesten alltid tre – slutter ikke systemet å fungere. Verre: det slutter å fungere bra, men fortsetter å gi svar. Flytende, sikre svar, og ofte frakoblet sannheten.

Det er en setning som går igjen blant de som bygger disse systemene profesjonelt, og som du aldri vil lese i opplæringsmateriell: "RAG er lett å lage, og vanskelig å gjøre bra." Det er en stor forskjell mellom den første demoen og tjenesten i produksjon som ikke kan overvinnes ved å legge til GPU-er eller bytte modell. Den overvinnes ved å forstå noe ubehagelig: når du bygger en bedrifts-RAG, skriver du ikke kode. Du designer en liten, vedvarende søkemotor skreddersydd for dine dokumenter, med alle redaksjonelle valg dette innebærer – hva er støy, hva er signal, hva skal indekseres to ganger, hva skal kastes. Bare i ti-linjers opplæringsprogrammer tas disse valgene for deg, én gang, av noen som aldri har sett dokumentene dine. Og de er nesten alltid feil for din sak.