Motorn som hade sex poler — Myten om de tio raderna kod

En undersökning i sex delar om varför den dokument-chatbot du blev såld på fortsätter att hitta på saker — och om den andra riktning som någon, i början av 2026, har börjat utforska.

En undersökning i sex delar om varför den dokument-chatbot du blev såld på fortsätter att hitta på saker — och om den andra riktning som någon, i början av 2026, har börjat utforska.

Intro — Motorn som hade åtta poler (men egentligen hade sex)

Milano, mars 2026. En chef öppnar företagets interna chatbot, en av dem som IT-avdelningen monterade "på två veckor" med stor entusiasm och liten misstänksamhet. En mycket enkel fråga: "Hur många poler har motorn CMP40M?". Chatboten svarar med all den självsäkerhet som stora språkmodeller kan uppvisa: "Motorn CMP40M har åtta poler."

Felaktigt. Den har sex. Det rätta svaret fanns inte i katalogen på 422 sidor som någon, månader tidigare, med full tillit hade hällt in i en vektor-databas, övertygad om att systemet "skulle veta allt" därifrån. Den informationen fanns inte alls i katalogen. Den fanns i en PDF-fil bifogad till ett e-postmeddelande från SEW:s tekniker, arkiverad i en mapp som ingen hade tagit sig tid att indexera.

Denna scen, med variationer i bransch och dialekt, upprepas i hundratals italienska kontor. Löftet var enkelt och lockande: ge din AI-assistent alla företagshandlingar, så kan den svara på alla frågor om dem. Verkligheten är mycket mer prosaisk: chatbotten läser men förstår inte, söker men hittar inte, och när den inte hittar – istället för att säga det – hittar den på. Den hittar på flytande, med perfekt grammatik, med trovärdiga siffror. Vilket är mycket värre än att inte svara.

Mellan slutet av 2024 och början av 2026 tillbringade vi månader med att obducera dessa misslyckanden. Inte för att underblåsa kontroverser, utan för att förstå en sak: varför en så linjär idé – "ge den dokumenten och fråga den sedan saker" – blir så svår när den lämnar demo-scenen och kommer in i rummet med riktiga servrar.

Denna utredning i sex kapitel berättar vad vi hittade: tysta buggar som raderade hela kataloger, moln-rerankers med felaktiga poäng, hallucinationer som inte uppstod från modellen utan från kontaminerade data år tidigare, utgående fakturor som gjorde varje fråga dyrare än dess värde, och "populära" ramverk som lovar allt på tio rader kod förutsatt att man inte kräver för mycket av dem. Och i det sista kapitlet, den annorlunda riktning som någon, i tysthet, började ta i början av 2026 — en arkitektur där sökstrategin slutar vara kod och blir ett dokument som alla i företaget kan läsa och ändra.

Varje kapitel står på egna ben. Om du vill börja med historien om de 342 försvunna tabellerna, eller den om den ljugande rerankern, är du fri att göra det. Men berättelsen som helhet har en moral som bara framträder i slutet: det företagsinterna RAG — det tekniska akronymet som står för Retrieval-Augmented Generation, det vill säga "generera svar baserat på dokument du hämtar först" — är ännu inte en färdig produkt. Det är en gräns. Och som alla gränser har den hittills berättats mest av säljare. Det är dags att lyssna på dem som har levt i den också.

Kapitel 1 — Myten om de tio kodraderna

Bilden är identisk på varje konferens om AI sedan 2023: "Din företagsdokumentassistent på 10 rader kod." Under rubriken, ett block av Python i pastellfärger som visar ett öppet källkodsbibliotek — typiskt ett av de berömda amerikanska, vars namn framkallar kedjor av träd eller tibetanska lamor — som laddar PDF-filer, fragmenterar dem, klistrar in dem i en vektordatabas och frågar dem med en språkmodell. På fem minuter har du en chatbot. På fem minuter, applåder. På fem minuter övertygas ett italienskt medelstort företag om att problemet är löst och att deras IT-avdelning kan klara det på två veckor.

Problemet — det som bilden inte säger — är att demon är byggd med tre välformaterade PDF-filer, en fråga skräddarsydd för att matcha innehållet, en scen utan reell latens och en presentatör som har provat allt tjugosju gånger innan han gick upp. I verkligheten är företagsdokument ett geologiskt kaos: skanningar av skanningar, tabeller som överlappar texten, fotnoter som tränger in i stycken, alfanumeriska koder som "RH1M" som chunkern halverar och tror är ord, bilder som innehåller sjuttio procent av den användbara informationen men som ingen extraherar, och layouter så kreativa att de kräver en arkeolog mer än en parser.

RAG – det är idén under huven – är en utmärkt idé. Ta användarens fråga, sök i ditt arkiv efter de mest relevanta dokumenten, skicka dem till språkmodellen och få ett svar baserat på dessa dokument. I teorin löser det elegant problemet med hallucinationer: modellen behöver inte längre "veta" svaret, den behöver bara "läsa" det i de bitar du har tillhandahållit. I praktiken har varje länk i kedjan – chunking, embedding, retrieval, reranking, den slutliga genereringen – sina egna sätt att gå sönder, och felet visar sig sällan som ett synligt fel. Det visar sig som ett svar som är lite fel. Sedan som ett helt felaktigt svar. Sedan som en chef som undrar varför han betalar för ett system som vet mindre än praktikanten.

De öppen källkodsramverk som populariserat RAG är gjorda för att demonstrera, inte för att producera. De är elegant sammanfogningar av abstraktioner där varje lager döljer ett outtalat antagande: att dina PDF-filer har en anständig OCR, att dina foton redan har beskrivits, att dina tabeller följer en konvention, att inbäddningsmodellen verkligen talar ditt språk (spoiler: många talar bara bra engelska), att ditt arkiv redan har rensats från dubbletter. När ett av dessa antaganden faller – och minst ett faller alltid, nästan alltid tre – slutar inte systemet att fungera. Värre: det slutar fungera bra, men fortsätter att ge svar. Flytande, säkra svar, och ofta frånkopplade från sanningen.

Det finns en fras som cirkulerar bland dem som bygger dessa system professionellt, och som du aldrig kommer att läsa i tutorials: "RAG är lätt att göra, och svårt att göra bra." Mellan den första demon och produktionsservicen finns ett gap som inte kan överbryggas genom att lägga till GPU:er eller byta modell. Det överbryggas genom att förstå något obekvämt: när du bygger en företags-RAG skriver du inte kod. Du designar en liten, envis sökmotor skräddarsydd för dina dokument, med alla redaktionella val det innebär – vad är brus, vad är signal, vad ska indexeras två gånger, vad ska kastas bort. I tutorials på tio rader tas dessa val åt dig, en gång, av någon som aldrig har sett dina dokument. Och de är nästan alltid fel för ditt fall.