Strategin som ett dokument — Det sjunde kapitlet

Kapitel 6 — Strategin som ett dokument, inte som kod

Vi kommer till insikten som, mer än någon annan i berättelsen om dem som byggde RAG från 2023 och framåt, återkommer som "det jag önskade jag hade förstått från första dagen".

Traditionella ramverk behandlar sökstrategin som Python-kod. Vill du, för tekniska kataloger, söka först efter produktkod, sedan efter nyckelord, sedan efter semantiska vektorer och bara i sista hand generera svaret? Skriv en funktion. Vill du, för fotoalbum, helt hoppa över traditionell semantisk sökning och förlita dig på en specialiserad omrankerare för bilder? Skriv en annan funktion. Vill du, för företagsvideor, dela ljudet från den visuella spåret, transkribera dem separat, behandla dem som distinkta källor och sedan sätta ihop dem i det slutliga svaret? Ännu en funktion. Varje typ av innehåll, varje domän, varje kund slutar med att generera en kodgren som avviker från de andra, till den punkt där det krävs en programvaruutgåva, en kodgranskning, en testcykel, en driftsättning för att ändra en strategi. Tiden mellan "jag har en idé om hur man förbättrar sökningen i tekniska manualer" och "idén är i produktion" mäts i veckor. För varje idé.

Den alternativa insikten är banal att säga och djupgående i sina konsekvenser: forskningsstrategin är inte kod. Den är ett dokument. En JSON – ett strukturerat textformat som vilken redaktör som helst, med en halvtimmes utbildning, kan läsa – som säger: ”först testa detta, sedan det, om det första misslyckas gå till det tredje, ranka om så här, svara med denna modell.” Detta dokument lever i en databas, inte i en repository. Det ändras från ett gränssnitt, inte från en pull request. Det versionshanteras, kopieras, specialiseras per domän. En strategi för tekniska kataloger, en för fotoalbum, en för installationsmanualer, en för videor, en för ljud, en för juridiska avtal, en för balansräkningar. Alla samexisterar i samma system. Alla kan ändras i realtid.

De som har arbetat med detta tillvägagångssätt – låt oss kalla det, utan alltför mycket fantasi, Meta-RAG – berättar om en hastighetsförändring som går utöver ingenjörskonsten. En typisk kundförfrågan "lägg till en specifik sökning efter produktkoder som innehåller förkortningar som CMP40M eller RH1M" är inte längre en utvecklingsuppgift som tar två veckor. Det är ett nytt steg som läggs till en JSON-procedur, testat direkt i en staging-miljö, och som driftsätts på en eftermiddag. Frågan "vad händer om vi använder en annan reranker för foton, samtidigt som vi behåller den nuvarande för text?" besvaras genom att ändra en rad i konfigurationen. Experimentet kostar ingenting, återställningen kostar ingenting (det räcker med att återställa den tidigare versionen av dokumentet), och den ackumulerade kunskapen – vad som fungerar bra för en viss typ av innehåll – blir en versionerad och överförbar tillgång, inte den tysta kunskapen hos den som skrev den specifika grenen av koden och som nu är på semester.

Det finns också en intressant social effekt som framträder i organisationer som anammar detta tillvägagångssätt. Med strategier som dokument flyttas gränsen mellan "utvecklare" och "expertanvändare". En digital bibliotekarie, ett företagsarkiv, en domänexpert – chefen för det tekniska kontoret, dokumentationsansvarig, produktchefen som känner kundernas verkliga frågor bättre än någon annan – kan läsa en strategi, förstå vad den gör, föreslå ändringar och ibland skriva dem direkt. De behöver inte gå igenom utvecklingsärendet, de behöver inte förklara för en utvecklare saker som utvecklaren inte vet (eftersom det inte ingår i deras yrke att veta dem). RAG slutar vara en produkt som du konsumerar och blir ett verktyg som du formar efter din organisations kunskap. Detta, enligt de som har provat det, förändrar projektets moral innan ens mätvärdena påverkas.

Det är ingen magi, och det har sina kostnader. Det krävs en motor som kör dessa strategier-som-dokument effektivt och säkert. Det krävs ett beskrivningsspråk som är tillräckligt rikt för att täcka verkliga fall och tillräckligt fattigt för att inte bli ännu en Turing-komplett förklädd. Det krävs verktyg för versionshantering, testning och återställning. Men allt detta är ett problem för den som bygger motorn – en gång, och för alla användare. Den enskilda slutanvändaren ser bara en sak: möjligheten att utveckla sin sökstrategi i tankens hastighet, istället för i hastigheten för programvaruutgivningscykeln. Och det, för den som är involverad, är en tyst revolution som ännu inte fått sitt namn i branschtidningarna.

Avslutning — Det sjunde kapitlet, om några månader

I början av 2026, efter att ha summerat lärdomarna från de föregående kapitlen – tabellerna som försvann, de ljugande rerankerna, de ärvda hallucinationerna, molnfakturorna som växte snabbare än värdet, de lovande men rigida ramverken – började någon i Italien att bygga en annan RAG-server. Skriven i Python, tänkt att köras på tillgänglig hårdvara, kapabel att prata med molnmodeller när det är fördelaktigt och med lokala modeller när integriteten kräver det eller kostnaden inte stämmer. En server där sökstrategierna är modifierbara dokument, rerankern är en lokal process på GPU, tabellerna inte försvinner eftersom de behandlas som medborgare av första klass, foton inte ärver objekt från dammiga arkiv från andra epoker, och kostnaden per fråga – både i pengar och i data som läcker till tredje part – är känd och kontrollerbar till öret.

Vi kommer inte att nämna projektet. Det är inte rätt tillfälle för det, och vi vill inte förvandla en undersökning till en reklam. Men om de föregående kapitlen fått dig att känna igen en situation du befinner dig i – en företagschatbot som svarar säkert på felaktiga frågor, ett RAG-projekt som inte lyfter på flera månader, en molnfaktura som växer snabbare än den nytta den ger, ett växande tvivel om att dina konfidentiella dokument reser till platser du inte känner till – då är det värt att veta att det finns en annan väg, som någon i Italien har vandrat, och som 2026 började ge de första svar som man förväntade sig 2023.

De goda nyheterna är att företags-AI, äntligen, lämnar demodfasen. De dåliga är att den gör det och tar med sig alla ärr från resan: uppblåsta ramverk, beroenden av leverantörer, monolitiska arkitekturer, smutsig data, tysta buggar och en viss tendens i branschen att sälja lösningar innan man ens har förstått problemet. Vi har berättat om dem i sex kapitel. Det sjunde – historien om vad som händer när någon äntligen gör rätt saker, med tålamod, på italienska och i öppen källkod – kommer vi att skriva snart, med mindre försiktighet när det gäller namn och mer siffror på bordet.

Under tiden, om du har kommit så här långt, har du redan gjort mer självrannsakan än 90 % av de beslutsfattare som just nu skriver på ett kontrakt för en företagschatbot utan att ställa några av de frågor du ställt när du läst dessa kapitel. Det är en bättre utgångspunkt än den de startade från. Och under de kommande månaderna kommer skillnaden mellan dem som ställt dessa frågor och dem som inte gjort det att bli mycket tydlig på fakturorna – och i de svar din AI kommer att ge dina kunder.

Denna undersökning skrevs i april 2026, baserat på erfarenheten av arton månaders design, konstruktion och optimering av företags-RAG-system mellan slutet av 2024 och början av 2026.