Motoren med seks poler — Myten om de ti linjer kode

En undersøgelse i seks dele om årsagerne til, at den dokumentchatbot, du er blevet solgt, fortsætter med at opdigte – og om den anden retning, nogen begyndte at gå i starten af 2026.

En undersøgelse i seks dele om årsagerne til, at den dokumentchatbot, du er blevet solgt, fortsætter med at opdigte – og om den anden retning, nogen begyndte at gå i starten af 2026.

Intro — Motoren med otte poler (men den havde seks)

Milano, marts 2026. En manager åbner den interne virksomheds-chatbot, af dem der er blevet samlet "på to uger" af IT-afdelingen med stor entusiasme og lidt mistillid. Simpelt spørgsmål: "Hvor mange poler har CMP40M-motoren?" Chatbotten svarer med al den sikkerhed, som store sprogmodeller kan udvise: "CMP40M-motoren har otte poler."

Forkert. Den har seks. Det rigtige svar fandtes ikke i kataloget på 422 sider, som nogen måneder tidligere med fuld tillid havde hældt ind i en vektor database, overbevist om, at systemet herefter "ville vide alt". Den data var slet ikke i kataloget. Den lå i en PDF-fil vedhæftet en e-mail fra SEW-teknikere, arkiveret i en mappe, som ingen havde taget sig tid til at indeksere.

Denne scene, med variationer i branche og dialekt, gentager sig i hundreder af italienske kontorer. Løftet var simpelt og forførende: giv din AI-assistent alle virksomhedens dokumenter, og den vil kunne svare på ethvert spørgsmål om dem. Virkeligheden er meget mere prosaisk: chatbotten læser, men forstår ikke, søger, men finder ikke, og når den ikke finder noget – i stedet for at sige det – opfinder den. Den opfinder flydende, med perfekt grammatik, med plausible tal. Hvilket er meget værre end ikke at svare.

Mellem slutningen af 2024 og begyndelsen af 2026 tilbragte vi måneder på at foretage obduktioner af disse fiaskoer. Ikke for at fodre kontroverser, men for at forstå én ting: hvorfor en så lineær idé – "giv den dokumenterne og spørg den derefter ting" – bliver så vanskelig, når den forlader demo-scenen og træder ind i det virkelige serverrum.

Denne undersøgelse i seks kapitler fortæller, hvad vi har fundet: stille fejl, der slettede hele kataloger, cloud-rerankere med forkerte scores, hallucinationer, der ikke opstod fra modellen, men fra data, der var blevet forurenet år tidligere, udgående fakturaer, der gjorde hver forespørgsel dyrere end dens værdi, og "populære" frameworks, der lover alt på ti linjer kode, så længe man ikke beder dem om for meget. Og i det sidste kapitel, den anderledes retning, som nogen i stilhed begyndte at gå i starten af 2026 – en arkitektur, hvor søgestrategien holder op med at være kode og bliver et dokument, som enhver i virksomheden kan læse og redigere.

Hvert kapitel står for sig selv. Hvis du vil starte med historien om de 342 forsvundne tabeller, eller historien om den løgnagtige reranker, er du fri til at gøre det. Men fortællingen som helhed har en morale, der kun kommer frem til sidst: virksomhedens RAG – det tekniske akronym, der står for Retrieval-Augmented Generation, dvs. "generer svar baseret på dokumenter, du henter først" – er endnu ikke et færdigt produkt. Det er en grænse. Og som alle grænser er den indtil videre blevet fortalt mest af sælgere. Det er tid til også at lytte til dem, der har levet inde i den.

Kapitel 1 – Myten om de ti linjer kode

Slidet er identisk ved enhver konference om AI siden 2023: "Din virksomheds dokumentassistent i 10 linjer kode." Under titlen en blok af Python i pastelfarver, der viser et open source-bibliotek — typisk en af de berømte amerikanske, hvis navn fremkalder træer eller tibetanske lamaer — der uploader PDF'er, fragmenterer dem, indsætter dem i en vektor database og forespørger dem med en sprogmodel. På fem minutter har du en chatbot. På fem minutter, applaus. På fem minutter er en italiensk mellemstor virksomhed overbevist om, at problemet er løst, og at deres IT-afdeling kan klare det på to uger.

Problemet — det, som slidet ikke siger — er, at demoen er bygget med tre velformede PDF'er, et spørgsmål skræddersyet til at matche indholdet, en scene uden reel latens og en præsentator, der har prøvet det hele syvogtyve gange, før han gik på scenen. I virkeligheden er virksomhedsdokumenter en geologisk katastrofe: scanninger af scanninger, tabeller der overlapper teksten, fodnoter der sniger sig ind i afsnittene, alfanumeriske koder som "RH1M", som chunkeren halverer og tror er ord, billeder der indeholder syv procent af den nyttige information, men som ingen rigtigt udtrækker, og layouts så kreative, at de kræver en arkæolog mere end en parser.

RAG – det er ideen under motorhjelmen – er en fantastisk idé. Tag brugerens spørgsmål, søg i dit arkiv efter de mest relevante dokumenter, send dem til sprogmodellen og få et svar baseret på disse dokumenter. I teorien løser det elegant problemet med hallucinationer: modellen behøver ikke længere at "vide" svaret, den skal bare "læse" det i de stykker, du har givet den. I praksis har hvert led i kæden – chunking, embedding, retrieval, reranking, den endelige generering – sine egne måder at gå i stykker på, og bruddet manifesterer sig sjældent som en synlig fejl. Det manifesterer sig som et let forkert svar. Så som et helt forkert svar. Så som en leder, der spekulerer på, hvorfor han betaler for et system, der ved mindre end praktikanten.

De open source-frameworks, der har gjort RAG populær, er designet til at demonstrere, ikke til at producere. De er elegante kæder af abstraktioner, hvor hvert lag skjuler en underforstået antagelse: at dine PDF'er har en anstændig OCR, at dine billeder allerede er blevet beskrevet, at dine tabeller følger en konvention, at embedding-modellen rent faktisk taler dit sprog (spoiler: mange taler kun godt engelsk), at dit arkiv allerede er blevet renset for dubletter. Når en af disse antagelser brydes – og mindst én brydes altid, næsten altid tre – holder systemet ikke op med at fungere. Værre: det holder op med at fungere godt, men fortsætter med at give svar. Flydende, sikre svar, og ofte afkoblet fra sandheden.

Der er en sætning, der går blandt dem, der bygger disse systemer som profession, og som du aldrig vil læse i tutorials: "RAG er let at lave, og svært at gøre godt." Der er en afgrund mellem den første demo og tjenesten i produktion, som ikke kan udfyldes ved at tilføje GPU'er eller skifte model. Den udfyldes ved at forstå en ubehagelig ting: når du bygger en virksomheds-RAG, skriver du ikke kode. Du designer en lille, vedholdende søgemaskine skræddersyet til dine dokumenter, med alle de redaktionelle valg, det indebærer – hvad er støj, hvad er signal, hvad skal indekseres to gange, hvad skal smides væk. Bare i tutorials på ti linjer er disse valg truffet for dig én gang af nogen, der aldrig har set dine dokumenter. Og de er næsten altid de forkerte for din sag.