Strategien som dokument — Det syvende kapitel

Kapitel 6 — Strategien som dokument, ikke som kode

Vi kommer til den indsigt, der mere end nogen anden, i fortællingen om dem, der har bygget RAG siden 2023, vender tilbage som "det, jeg ville ønske, jeg havde forstået fra dag ét".

Traditionelle frameworks behandler søgestrategien som Python-kode. Vil du, for tekniske kataloger, søge først efter produktkode, derefter efter nøgleord, derefter efter semantiske vektorer og først som det sidste generere svaret? Skriv en funktion. Vil du, for fotoalbummer, helt springe traditionel semantisk søgning over og stole på en specialiseret reranker til billeder? Skriv en anden funktion. Vil du, for virksomhedsvideoer, adskille lyden fra det visuelle spor, transkribere dem separat, behandle dem som separate kilder og derefter sammensætte dem i det endelige svar? Endnu en funktion. Hver type indhold, hvert domæne, hver kunde ender med at generere en kodeforgrening, der afviger fra de andre, indtil det punkt, hvor ændring af en strategi kræver en softwareudgivelse, en kodegennemgang, en testcyklus, en implementering. Tiden mellem "Jeg har en idé til, hvordan man forbedrer søgningen i tekniske manualer" og "Ideen er i produktion" måles i uger. For hver idé.

Den alternative indsigt er banal at sige og dyb i sine konsekvenser: søgestrategien er ikke kode. Det er et dokument. En JSON – et struktureret tekstformat, som enhver redaktør med en halv times træning kan læse – der siger: "prøv først dette, derefter det, hvis det første fejler, gå til det tredje, omranger således, svar med denne model." Dette dokument lever i en database, ikke i et repository. Det ændres fra en brugergrænseflade, ikke fra en pull request. Det versionsstyres, kopieres, specialiseres efter domæne. En strategi for tekniske kataloger, en for fotoalbum, en for installationsvejledninger, en for videoer, en for lyd, en for juridiske kontrakter, en for regnskaber. Alle eksisterer side om side i det samme system. Alle kan ændres i realtid.

Dem, der har arbejdet med denne tilgang – lad os kalde den, uden for meget fantasi, Meta-RAG – fortæller om et skift i hastighed, der går ud over ingeniørarbejdet. En typisk kundeanmodning "tilføj en specifik søgning efter produktkoder, der indeholder forkortelser som CMP40M eller RH1M" er ikke længere en udviklingsopgave, der tager to uger. Det er et nyt trin, der er tilføjet til en JSON-procedure, testet på et staging-miljø og promoveret til produktion på en eftermiddag. Spørgsmålet "hvad ændrer sig, hvis vi bruger en anden reranker til billeder og beholder den nuværende til tekst?" besvares ved at ændre en linje i konfigurationen. Eksperimentet koster ingenting, rollback koster ingenting (bare gendan den tidligere version af dokumentet), og den akkumulerede viden – hvad der fungerer godt for en bestemt type indhold – bliver en versioneret og overførbar aktiv, ikke den tavse viden hos den, der har skrevet den pågældende kode og er på ferie i dag.

Der er også en interessant social effekt, der opstår i organisationer, der adopterer denne tilgang. Med strategier som dokumenter flyttes grænsen mellem "udvikler" og "ekspertbruger". En digital bibliotekar, en virksomhedsarkivar, en domæneekspert – chef for det tekniske kontor, dokumentationsansvarlig, produktchef, der kender kundernes reelle spørgsmål bedre end nogen anden – kan læse en strategi, forstå hvad den gør, foreslå ændringer, nogle gange skrive dem direkte. De behøver ikke at gå gennem udviklings-ticket-funnelen, de behøver ikke at forklare en udvikler ting, som udvikleren ikke ved (fordi det ikke er en del af deres job at vide dem). RAG holder op med at være et produkt, du forbruger, og bliver et værktøj, du former efter din organisatoriske viden. Dette, ifølge erfaringerne fra dem, der har prøvet det, ændrer projektets moral, før tallene i målingerne overhovedet gør det.

Det er ikke magi, og det har sine omkostninger. Der skal en motor til, der udfører disse strategier-som-dokumenter effektivt og sikkert. Der skal et beskrivelsessprog til, der er rigt nok til at dække reelle tilfælde, men fattigt nok til ikke at blive endnu en Turing-komplet forkædning. Der skal værktøjer til versionering, test og rollback. Men alt dette er et problem for dem, der bygger motoren – én gang, og for alle brugere. Den enkelte slutkunde ser kun én ting: muligheden for at udvikle sin søgestrategi med tankens hastighed i stedet for med hastigheden af softwareudgivelsescentret. Og for dem, der er med, er det en stille revolution, der endnu ikke har fundet sit navn i branchemagasinerne.

Afslutning — Det syvende kapitel, om et par måneder

I begyndelsen af 2026, efter at have opsummeret lektionerne fra de foregående kapitler – tabeller der gik tabt, vildledende rerankere, arvede hallucinationer, cloud-regninger der voksede hurtigere end værdien, lovende men stive frameworks – begyndte nogen i Italien at bygge en anden type RAG-server. Skrevet i Python, designet til at køre på tilgængelig hardware, i stand til at kommunikere med cloud-modeller, når det er fordelagtigt, og med lokale modeller, når privatlivets fred kræver det, eller omkostningerne ikke stemmer. En server, hvor søgestrategier er redigerbare dokumenter, rerankeren er en lokal GPU-proces, tabeller ikke går tabt, fordi de behandles som førsteklasses borgere, billeder ikke arver objekter fra støvede arkiver fra andre epoker, og omkostningerne pr. forespørgsel – både i penge og i data, der lækkes til tredjeparter – er kendte og kan kontrolleres ned til øret.

Vi nævner ikke projektets navn. Det er ikke formålet med denne artikel, og vi ønsker ikke at gøre en undersøgelse til en reklame. Men hvis de foregående kapitler har fået dig til at genkende en situation, du oplever – en virksomheds chatbot, der svarer selvsikkert på forkerte spørgsmål, et RAG-projekt, der ikke kommer i gang i månedsvis, en cloud-regning, der vokser hurtigere end den værdi, den producerer, en voksende tvivl om, at dine fortrolige dokumenter rejser til steder, du ikke kender – så er det værd at vide, at der er en anden vej, som nogen i Italien har fulgt, og som i 2026 begyndte at give de første svar, man forventede i 2023.

Den gode nyhed er, at virksomheds-AI endelig er ved at forlade demofasen. Den dårlige nyhed er, at den tager alle arrene fra rejsen med sig: oppustede frameworks, afhængighed af udbydere, monolitiske arkitekturer, beskidte data, stille fejl og en vis tendens i branchen til at sælge løsninger, før man overhovedet har forstået problemet. Vi har fortalt om dem i seks kapitler. Det syvende – historien om, hvad der sker, når nogen endelig gør tingene rigtigt, med tålmodighed, på italiensk og i open source – vil vi skrive snart, med mindre forsigtighed omkring navne og flere tal på bordet.

I mellemtiden, hvis du er nået hertil, har du allerede foretaget en mere grundig analyse end 90% af de beslutningstagere, der i øjeblikket underskriver en kontrakt for en virksomheds chatbot uden at stille nogen af de spørgsmål, du har stillet dig selv ved at læse disse kapitler. Det er et bedre udgangspunkt, end de startede fra. Og i de kommende måneder vil forskellen mellem dem, der har stillet disse spørgsmål, og dem, der ikke har, blive meget tydelig på fakturaerne – og på de svar, din AI vil give dine kunder.

Denne undersøgelse blev udarbejdet i april 2026 på baggrund af atten måneders erfaring med design, konstruktion og optimering af virksomheds-RAG-systemer fra slutningen af 2024 til begyndelsen af 2026.