Strategi som dokument — Det syvende kapittelet

Kapittel 6 — Strategi som dokument, ikke som kode

Vi kommer til innsikten som oftest, i fortellingen om de som har bygget RAG fra 2023 og fremover, dukker opp som "den tingen jeg skulle ønske jeg forsto fra dag én".

Tradisjonelle rammeverk behandler søkestrategien som Python-kode. Ønsker du, for tekniske kataloger, å søke først etter produktkode, deretter etter nøkkelord, deretter etter semantiske vektorer, og bare som en siste utvei generere svaret? Skriv en funksjon. Ønsker du, for fotoalbum, å hoppe over tradisjonell semantisk søking og stole på en spesialisert reranker for bilder? Skriv en annen funksjon. Ønsker du, for bedriftsvideoer, å dele lyden fra videosporet, transkribere dem separat, behandle dem som separate kilder og deretter sette dem sammen i det endelige svaret? Enda en funksjon. Hver type innhold, hvert domene, hver kunde ender opp med å generere en kodebranch som divergerer fra de andre, til det punktet hvor endring av en strategi krever en programvareutgivelse, en kodegjennomgang, en testsyklus, en distribusjon. Tiden mellom "Jeg har en idé om hvordan jeg kan forbedre søket på tekniske manualer" og "Ideen er i produksjon" måles i uker. For hver idé.

Den alternative innsikten er enkel å si, men dyp i sine konsekvenser: søksstrategien er ikke kode. Det er et dokument. En JSON – et strukturert tekstformat som enhver redaktør, med en halvtimes opplæring, kan lese – som sier: "Prøv først dette, deretter det, hvis det første mislykkes, gå til det tredje, ranger om slik, svar med denne modellen." Dette dokumentet lever i en database, ikke i et depot. Det redigeres fra et grensesnitt, ikke fra en pull request. Det versjoneres, kopieres og spesialiseres per domene. En strategi for tekniske kataloger, en for fotoalbum, en for installasjonsmanualer, en for videoer, en for lyd, en for juridiske kontrakter, en for regnskap. Alle eksisterer side om side i samme system. Alle kan redigeres i sanntid.

De som har jobbet med denne tilnærmingen – la oss kalle det, uten for mye fantasi, Meta-RAG – forteller om en hastighetsendring som går utover ingeniørkunsten. En typisk forespørsel fra en kunde "legg til et spesifikt søk etter produktkoder som inneholder forkortelser som CMP40M eller RH1M" er ikke lenger en utviklingsoppgave som tar to uker. Det er et nytt trinn lagt til en JSON-prosedyre, testet på et staging-miljø, promotert til produksjon på en ettermiddag. Spørsmålet "hva endres hvis vi bruker en annen reranker for bilder, mens vi beholder den nåværende for tekst?" besvares ved å endre en konfigurasjonslinje. Eksperimentet koster ingenting, tilbakerullingen koster ingenting (bare gjenopprett den forrige versjonen av dokumentet), og kunnskapen som er samlet – hva som fungerer bra for en viss type innhold – blir en versjonert og overførbar ressurs, ikke den stille kunnskapen til den som skrev den spesifikke kodefilen og er på ferie i dag.

Det er også en interessant sosial effekt som kommer frem i organisasjoner som adopterer denne tilnærmingen. Med strategier som dokument, forskyves grensen mellom "utvikler" og "erfaren bruker". En digital bibliotekar, en bedriftsarkivar, en domeneekspert – lederen av det tekniske kontoret, dokumentasjonsansvarlig, produktleder som kjenner kundens reelle spørsmål bedre enn noen andre – kan lese en strategi, forstå hva den gjør, foreslå endringer, og noen ganger skrive dem direkte. De trenger ikke å gå gjennom utviklings-ticket-funnelen, de trenger ikke å forklare en utvikler ting som utvikleren ikke vet (fordi det ikke er en del av deres fagfelt). RAG slutter å være et produkt du konsumerer og blir et verktøy du former etter din organisatoriske kunnskap. Dette, ifølge de som har prøvd det, endrer prosjektmoralen før tallene i metrikken endres.

Dette er ikke magi, og det har sine kostnader. Du trenger en motor som utfører disse strategiene-som-dokumenter på en effektiv og sikker måte. Du trenger et beskrivelsesspråk som er rikt nok til å dekke reelle tilfeller, men fattig nok til å ikke bli en annen Turing-komplett forkledning. Du trenger verktøy for versjonskontroll, testing og tilbakerulling. Men alt dette er et problem for de som bygger motoren – én gang, og for alle brukere. Den enkelte sluttkunde ser bare én ting: muligheten til å utvikle sin søkestrategi i tankens hastighet, i stedet for i hastigheten til programvareutgivelsessyklusen. Og for de som er involvert, er dette en stille revolusjon som ennå ikke har fått sitt navn i fagpressen.

Avslutning – Det syvende kapittelet, om noen måneder

I begynnelsen av 2026, etter å ha summert lærdommen fra de foregående kapitlene – tabellene som forsvant, de løgnaktige rerankerne, de arvede hallusinasjonene, skyregningene som vokste raskere enn verdien, de lovende, men rigide rammeverkene – begynte noen i Italia å bygge en annen RAG-server. Skrevet i Python, designet for å kjøre på tilgjengelig maskinvare, i stand til å snakke med skybaserte modeller når det er fordelaktig og med lokale modeller når personvern krever det eller kostnadene ikke stemmer. En server der søkestrategier er redigerbare dokumenter, rerankeren er en lokal prosess på GPU, tabellene ikke går tapt fordi de behandles som førsteklasses borgere, bilder ikke arver objekter fra støvete arkiver fra andre epoker, og kostnaden per spørring – både i penger og i data som lekkes til tredjeparter – er kjent og kontrollerbar ned til øret.

Vi kommer ikke til å nevne prosjektet. Dette er ikke stykket for det, og vi ønsker ikke å gjøre en undersøkelse til en reklame. Men hvis de foregående kapitlene har fått deg til å gjenkjenne en situasjon du opplever – en bedriftschatbot som svarer selvsikkert på feil spørsmål, et RAG-prosjekt som ikke kommer i gang på måneder, en skyfaktura som vokser raskere enn nytten den produserer, en økende tvil om at dine konfidensielle dokumenter reiser til steder du ikke kjenner til – så er det verdt å vite at det finnes en annen vei, som noen i Italia har gått, og som i 2026 begynte å gi de første svarene man forventet i 2023.

Den gode nyheten er at bedrifts-AI endelig er i ferd med å forlate demofasen. Den dårlige er at den kommer ut med alle arrene fra reisen: oppblåste rammeverk, avhengighet av leverandører, monolittiske arkitekturer, skitne data, stille feil og en viss tendens i bransjen til å selge løsninger før man i det hele tatt har forstått problemet. Vi har fortalt om dem i seks kapitler. Det syvende – historien om hva som skjer når noen endelig gjør ting riktig, med tålmodighet, på italiensk og i åpen kildekode – vil vi skrive snart, med mindre forsiktighet rundt navn og flere tall på bordet.

I mellomtiden, hvis du har kommet så langt, har du allerede gjort mer grundig analyse enn 90 % av beslutningstakerne som akkurat nå signerer en kontrakt for en bedriftschatbot uten å stille noen av spørsmålene du har stilt ved å lese disse kapitlene. Det er et bedre utgangspunkt enn der de startet. Og i løpet av de neste månedene vil forskjellen mellom de som har stilt disse spørsmålene og de som ikke har det, bli svært synlig på fakturaene – og på svarene AI-en din gir kundene dine.

Denne undersøkelsen ble utarbeidet i april 2026, basert på erfaring fra atten måneders design, konstruksjon og optimalisering av bedrifts-RAG-systemer mellom slutten av 2024 og begynnelsen av 2026.