Mange RAG-implementeringer ser stærke ud i demo. De kører, svarer hurtigt, og det hele virker ukompliceret. I produktion bliver samme design dyrt og skrøbeligt, især når alle tvetydigheder sendes til sprogmodellen. VentureBeat beskriver, hvordan en bevidst arkitekturprioritering – at afgøre hvad aldrig når LLM – skærer inferensregningen markant, i én case omkring seks gange lavere end en alt-til-LLM baseline (kildens tal afhænger af domæne og trafikmønster) [VentureBeat].
Problemformulering: Hvorfor teams sender alt til LLM'en
VentureBeat beskriver en udbredt praksis i RAG-setup: når noget er uklart, sendes det direkte til modellen, i tillid til at hentet kontekst vil bære afgørelsen. Det er fristende, fordi det reducerer antallet af komponenter og gør det let at komme i gang. Færre bevægelige dele, hurtig iteration, og modellen kan i princippet dække kanterne.
Det holder i demoer. Lav volumen, kort hukommelse og ingen revisor, der beder om forklaring på et udfald fra foråret. I drift rammer man tre vægge: audit, skaleringsomkostninger og inkonsistens på simple sager. VentureBeat beskriver alle tre — og mange teams opdager det først, når brugen vokser, og compliance begynder at spørge.
De skjulte omkostninger ved "alt til LLM"
Først auditability. “Modellen besluttede ud fra hentet kontekst” er ikke dokumentation. Ved revision eller regulatoriske forespørgsler skal beslutningsstien kunne genskabes uden at gentage en stokastisk inferens og håbe på samme svar. Uden deterministiske trin og solide logs ender man i et dårligt valg: genkør og kryds fingre, eller drop dokumentationen. Ingen af delene holder i regulerede miljøer.
Dernæst cost-at-scale. Hver forespørgsel, der rammer LLM med flere dokumenter i kontekst, øger både regning og latency næsten lineært med volumen. Ruter man alt gennem modellen, følger regningen trafikken; renser man først i et regelsæt, falder antallet af dyre kald. VentureBeat peger på, at gevinsten primært kommer herfra — ikke fra små forbedringer i tokenpriser.
Endelig modeldrift på de lette sager. LLM’er er stærke i gråzoner, men kan være inkonsistente på opgaver, der bør løses deterministisk: klare matches, strukturerede felter, faste kriterier. VentureBeat fremhæver risikoen ved at lade en probabilistisk motor afgøre noget, der kunne afgøres entydigt — så får man tilfældige afvigelser, hvor man mindst vil have dem.
Løsningen: Cascade-arkitektur i praksis
Opskriften er en tretrins-cascade. Første lag: deterministisk. Alt der kan afgøres med regler, lookups eller simple sammenligninger, afgøres her — uden modelkald. Hver afgørelse kan forklares, fordi den er en strukturel test, ikke en sprogmodelvurdering. Hvor stor en andel dette lag kan håndtere, afhænger af data og domæne.
Andet lag: retrieval og scoring. Her ligner det klassisk RAG, men pointen er, at kvaliteten af hentningen vejer tungere end selve genereringen. Hvis du henter forkert, producerer selv en stærk model et velargumenteret, men forkert svar. Retrieval-laget skal derfor have pålidelige scorer og klare beslutningspunkter: “høj nok score” går videre, “for lav score” eskaleres eller afvises.
Tredje lag: LLM som eskalation. Kun sager, som regler og retrieval ikke kan afklare, rammer modellen. Det er her, de dyre kald skaber værdi. VentureBeat beskriver, at routing af en mindre, tvivlsom restkategori til modellen i en case reducerede inference-udgiften omkring 6x sammenlignet med en alt-til-LLM baseline. Det er forfatterens erfaringsbaserede udsagn og bør læses med forbehold for generaliserbarhed.
Praktiske komponenter og implementeringstrin
Score-baseret routing. Systemet skal eksplicit afgøre, om en sag kan løses i lag 1, er tilstrækkeligt belyst i lag 2, eller bør eskalere til LLM. Krav: pålidelige usikkerhedsmål, mulighed for tærskel-tuning pr. domæne og driftsdashboard. Metrikker: andel løst i lag 1, eskalationsrate, konfidens/accuracy-korrelation. Værktøjer: egne scorere, VDB’er som Weaviate, Qdrant eller Milvus; søg med OpenSearch/Elasticsearch; orkestrering via fx LangChain eller Haystack.
Verifikationsmoduler. Når der hentes kontekst eller træffes afgørelse, verificér med en uafhængig regel eller simpel klassifikator. Krav: letvægtstests, der kan køre synkront uden markant latency. Metrikker: verifikations-hit-rate, fejl opdaget før LLM-kald, andel falske positive/negative. Værktøjer: små scikit-learn/XGBoost-modeller, schema-checks, regex/DSL-regler.
Fallback-regler. Når usikkerheden er høj, skal systemet kunne eskalere til human review eller vælge et konservativt udfald. Krav: klare forretnings-guardrails (hvad er “konservativt” her), SLA for manuel sagsbehandling. Metrikker: manual review-andel, ventetid, downstream-omkostning pr. fallback. Værktøjer: køsystemer som SQS/Kafka, simple kø-dashboards.
Menneske-i-loop. Kritiske flows bør have en tydelig exit til menneskelig vurdering, med gode værktøjer: begrundede forslag, visning af kilder og beslutningssti. Metrikker: tid til afgørelse, accept-rate af systemforslag, læringsfeedback tilbage til regler/retrieval. Krav: sporbar UI og rollebaseret adgang.
Audit-logs. Beslutningsstier skal kunne reproduceres uden at gentage LLM-inferens. Log kildedokumenter, scorer, regler, versioner af pipelinekomponenter og prompts (hash), samt tidsstempler. Metrikker: dækning af logs pr. sag, gennemsnitlig tid til audit-svar. Krav: WORM-lagring hvor påkrævet, dataretention-politik pr. regulatorisk zone.
Usikkerhedsmål og calibration. Ukalibreret konfidens kan vildlede. Brug temperaturskalering, isotonic regression eller hold-out-metoder til at sikre, at “0,8” faktisk omtrent betyder 80 procents korrekthed i produktion. Metrikker: Expected Calibration Error (ECE), Brier score, drift mellem test og produktion. Værktøjer: sklearn-calibration, egne post-hoc kalibreringsrør.
Løbende evaluering mod KPI’er. Det handler ikke kun om nøjagtighed. Mål cost per resolved case, P95/P99 latency, eskalationsrate, andel deterministic-resolved og audit-responstid. Opsæt SLO’er og alarmgrænser. Værktøjer: Prometheus/Grafana, OpenTelemetry-spans, event streaming til online evaluering.
Tradeoffs og risici
Kompleksitet. En cascade med flere lag er sværere at bygge og drifte end en ren LLM-pipeline. Der er flere moduler, flere fejlpunkter og større behov for observability. Det flytter kompleksitet fra model til system — et rimeligt bytte i high-stakes domæner.
Forkert routing. Falske positive/negative i routinglogikken kan enten sende for mange sager til LLM (dyrt) eller for få (fejl i afgørelser). Det kræver eksplicit test mod kanttilfælde og mulighed for hurtig threshold-justering. Kør gerne “shadow mode”, hvor nye tærskler evalueres parallelt før aktivering.
Vedligeholdelsesbyrde. Regelsæt og retrievers ældes. Dokumenter flytter sig. Indekser skal genopbygges. Budgettér løbende drift, ikke kun en lanceringsdag. Retrieval-ingeniørarbejde er en kompetence i sig selv.
Hvor meget kan ryddes i stage one. Andelen er domænespecifik. I nogle datasæt er felterne rene og regelsættet skarpt; i andre er alt halvstruktureret. Lav en indledende “rule potential”-analyse: hvor mange sager kan reduceres til deterministiske mønstre uden at miste forretningslogik.
Governance og reproducerbarhed. Audit-logs skal designes, så de ikke lækker følsomme outputs, men stadig dokumenterer beslutningsstier. Gem værdibærende mellemresultater og referencer (hashes, doc-IDs, scorer), ikke hele LLM-outputs. Versionér alt: regler, prompts, embeddings, indeks-builds.
Specielt om træning og reward-design i multi-turn opsætninger
Træning over flere trin — agentiske flows, tool-calls, små beslutningsstier — kan forstærke arkitekturfejl, hvis reward-funktionen er skæv. AWS’ Nova Forge-blog advarer om, at en subtil fejl i reward kan lære modellen uønsket adfærd, selv når træningskurver ser sunde ud.
Praktisk modtræk: BYOO-opsætninger, hvor reward-logikken kører i eget miljø, så den kan testes mod realistiske flows og edge cases. Derudover systematiske simuleringer af fejlscenarier (manglende dokument, modstridende kilder, ufuldstændige felter) og uafhængige eval-sæt med negative kontroller, så “gaming” opdages.
Etabler også overvågning i drift, der fanger afdrift: fordeling af actions per turn, andel af tool-calls der ikke flytter sagen fremad, stigning i eskalationer fra lag 2 til 3. Når de kurver glider, er det ofte et tidligt tegn på, at noget i reward eller routing er off. AWS fremhæver behovet for at evaluere hele forløbet, ikke blot det sidste output.
Handlingspunkter for tekniske ledere
- Auditér hvor ofte LLM kaldes, og med hvor mange tokens. Mål cost pr. sag og P95-latency pr. flow.
- Kortlæg deterministiske regler. Start med de 10 hyppigste, lav præcise tests og mål rensningsrate i lag 1.
- Indfør confidence-baseret routing i retrieval-laget. Definér tærskler, og kør shadow mode før go-live.
- Etabler audit-logs af beslutningsstier med versioner, scorer, dokument-ID’er og prompt-hashes.
- Planlæg menneske-i-loop for kritiske afgørelser med klare SLA’er og feedback tilbage til systemet.
- Test reward-funktioner i multi-turn scenarier med BYOO, negative kontroller og kantcases.
Der er huller i offentlig dokumentation. Det ville hjælpe med flere uafhængige benchmarks for, hvor stor en andel lag 1 kan rydde i forskellige domæner (support, finans, sundhed). VentureBeat’s 6x-case er oplysende, men tallene er case-specifikke. Der mangler også konkrete eksempler på retrieval-fejl (før/efter) og eksempler på audit-logformater, der bevarer sporbarhed uden at gemme hele LLM-outputtet.
Konklusion
Skift fra LLM som frontlinje til LLM som eskalation. Byg et deterministisk første lag, investér i retrieval-kvalitet, og lad modellen håndtere restkategorien. Resultatet er lavere omkostninger, lavere latency og bedre auditability.
Hvis der kun er ét næste skridt: mål, hvor mange sager I kan løse deterministisk i dag, og sæt en målsætning for at fordoble den andel.
