Klokken 06.14. Slack lyste. En on‑call ingeniør spurgte agenten, hvorfor et pipeline‑job stod stille. Svaret kom roligt: fire timers responsvindue. Det rigtige var 30 minutter. Jobbet havde stået i 90. Og en PagerDuty‑ticket lå der allerede med ordet “igen” i titlen. Det er en konkret hændelse fra en produktion (Sudip P., 27/5/2026).
Historien er enkel og sammensat på samme tid: En RAG+MCP‑agent fungerede fint på en laptop med få tests. I produktion, med ~80 brugere der kopierede Slack‑tråde ind, blev den en belastning (Sudip P., 27/5/2026). Fem ting brød: retrieval forvekslede nærliggende tekster, routeren klassificerede forkert, MCP‑værktøjer returnerede null eller fejlede tavst, modellen tabte kontekst og hallucinerede, og observability var tynd. Vi har set mønsteret før hos kunder.
Arkitekturen kort
Pipeline‑designet er klassisk: En lille LLM‑router deler forespørgsler i Knowledge (hybrid BM25+vektor → cross‑encoder rerank) og Action (validate → MCP‑værktøj med timeouts/retries). Begge veje mødes i en frontier‑model, som sammensætter svaret, efterfulgt af logging og evals (Sudip P., 27/5/2026). På papir ser det solidt ud. I drift bliver kanterne synlige.
Hvorfor både RAG og MCP? Brugere spørger både til regler og vil trigge handlinger. RAG trækker fra et indeks; MCP kalder levendesystemer og kan lave bivirkninger, hvis kontrakter og sporbarhed ikke er skarpe (Sudip P., 27/5/2026). De to strømme kræver cache, sporbarhed og stramme schemaer. Det overses let i en demo. Jeg har selv prøvet det i et internt POC: problemfrit – indtil virkelige Slack‑spørgsmål ramte.
Fejl 1 — Retrieval gav forkert SLA
Her var problemet ikke fri fantasi, men forkerte bidder. “Tier‑1 for streaming” lå for tæt på “Tier‑2 for batch” i vektorrummet. Embeddings udglatter sprog og kan slette små, vigtige ord. Resultatet blev et fejlciteret SLA‑udsnit og et svar, der skabte falsk ro – og så alarm (Sudip P., 27/5/2026).
Modgiften: hybrid søgning + rerank. BM25 for de hårde ord (Tier‑1, streaming, 30 minutter), vektor for semantik, og en cross‑encoder til parvis relevans. Dertil stramme metadatafiltre, mindre præcise chunks, og versionerede indekser, så man kan reproducere fejl. Det sidste mangler ofte; vi har to gange i år sporet en produktionsfejl til en natlig genindeksering. Lærerigt.
Fejl 2 — Routeren klassificerede forkert
Keyword‑routere knækker på virkelige inputs: lange Slack‑tråde, screenshots, blandet dansk‑engelsk. Casen beskriver netop fejlroute, der enten skærer for meget kontekst væk eller kører et ubegrundet tool‑kald (Sudip P., 27/5/2026). En lille LLM‑router virkede bedre i casen, og det matcher vores erfaring – med cache ovenpå.
Tradeoffs er klare: LLM‑router koster latency og penge. Løs det med aggressiv caching og en simpel fallback: hvis selvtilliden er lav, kør begge strømme i small‑mode og lad synthesis vælge. Dyrere end ingenting; billigere end en pager kl. 06.14.
Fejl 3 — MCP‑værktøjer fejlede eller returnerede null
I demoer svarer værktøjer pænt. I drift får du null, tomme felter og uens fejlformater. Casen anbefaler validering, timeouts, retries og ensartede fejlobjekter som {ok, error, detail}. Vi anbefaler også et transaction‑id‑lag, så svar kan spores på tværs af systemer (Sudip P., 27/5/2026; Snilld‑brief, internt).
Antag fejl først: valider input, begræns sideeffekter, og mål succeshyppighed pr. værktøj. Et praktisk greb: værktøjer må kun svare i et minimalt schema – alt andet er fejl. Rigidt, men det forkorter fejlsøgning markant, når noget brænder.
Fejl 4 — Hallucinationer og konteksttab
Når retrieval lover for meget og leverer for lidt, eller når for mange MCP‑resultater presses ind i for lille kontekst, stiger risikoen for fejlbindinger. Miseren her blev forstærket af et forkert SLA‑bid, men mønsteret er generelt. Frontier‑modellen kan ikke kompensere for tynde eller modstridende input.
Løsningen er ikke et enkelt prompt‑trick. Brug guardrails i prompten sammen med output‑validering. For SLA, priser, kontrakter: kræv citerbare kilder i svaret (gerne med chunk‑id), og lad en simpel validator afvise svar uden kilde. Små checks, stor effekt.
Fejl 5 — Manglende observability
Uden eval‑harness aner man ikke, om fejlraters udvikling går den rette vej. Casen siger det direkte, og vi bliver ofte tilkaldt præcis dér: der manglede en eval‑pakke fra dag nul, så forkerte svar gik under radaren, indtil brugeren opdagede det (Sudip P., 27/5/2026). Det koster tillid.
Mål det, der styrer adfærd: router accuracy på rigtige brugersamples, retrieval precision@k for definerede queries, tool success/error‑rate, p95/p99 tail‑latency og et end‑to‑end SLO. Log IDs for alle mellemled, kør natlige evals mod et fast sæt, og læg tallene i et dashboard, on‑call rent faktisk kigger på.
Hvor arkitektur møder drift og governance
Et forkert SLA‑svar er ikke bare en flov Slack‑tråd. Det risikerer kontraktbrud og eskaleringer. Incident‑runbooks og klare fallback‑flows er derfor kerne. Lad agenten sige “jeg ved det ikke” med kilde og rute til menneske inden for SLA ved høj usikkerhed. Brug transaction‑ids i alle tool‑svar for sporbarhed.
Tillid bygges langsomt og tabes hurtigt. Ét forkert svar om en 30‑minutters SLA kan give uger med skepsis. Transparens hjælper: vis kildeuddrag, indeksversion og tidsstempler. Tørt – men virksomt.
Router‑design som første hårdning
Prioritér routeren tidligt. Slack/e‑mail indeholder rod, emojis, citater, sidespor. En keyword‑router går i knæ. En lille LLM‑router med cache rammer bedre (også i casen). Cache bør ramme semantiske varianter, ikke kun eksakte strenge – fx på en normaliseret udgave af spørgsmålet plus rute‑label – for at reducere pris og ventetid.
Når routeren er i tvivl, så degradér elegant: kør small RAG og et let tool‑kald med no‑op, og lad modellen vælge. Vi har set en halvering af forkerte “Action”‑svar i en beta med den strategi. Ikke akademi – bare målinger.
Retrieval der tåler virkelighed
Hybrid + rerank er baseline. Casen viser hvorfor, og vores erfaring matcher (Sudip P., 27/5/2026; Snilld‑brief, internt). Supplér med: domænefelter i indekset (fx produktnavn, kontrakt‑tier), kortere chunking for mindre semantisk læk, og versionsstyring på indekser, så fejl kan reproduceres. Uden versioner gætter man – og det duer ikke under et incident.
Der mangler tal i casen: hvor præcis var retrieval før/efter, og hvor ofte blev SLA‑typerne forvekslet? Ukendt, indtil der foreligger evals med precision@k. Et hul mange teams deler – og som kan lukkes på få dage med et eval‑sæt og et par scripts.
Modeller, benchmarks og virkelighed
Leaderboards kan vildlede. Nye data fra DeepSWE peger på, at modeller divergerer mere i praksis end offentlige tavler antyder, og at automatiske verifikatorer kan ramme ved siden af. VentureBeat omtaler en verifikationsfejlrate omkring en tredjedel i en audit af SWE‑Bench Pro (VentureBeat, DeepSWE‑dækning). Konklusionen her: vælg model på domæneevals – ikke kun på placeringer.
Og husk: en frontier‑model redder ikke en svag pipeline. RAG og MCP skal levere de rigtige byggesten, ellers bliver huset pænt – men skævt. Vi ser ofte teams skifte model, før router og retrieval er fikset. Det er bagvendt.
Snillds handlingsplan fra workshop til hårdning
Vi starter typisk med en fokuseret analyse af den eksisterende pipeline: de 5‑10 vigtigste målinger og overblik over rutevalg, retrieval‑kvalitet og værktøjsfejl. Herfra følger rækkefølgen: router → retriever → caching/fallback → observability med realtime dashboards. Automatiske evals kører natligt. Versionering og governance dækker indekser, prompts og tool‑schemaer. Det har holdt i praksis hos os (Snilld‑brief, internt).
De hurtige gevinster: hybrid + rerank på få dage, lille LLM‑router med cache næsten lige så hurtigt. De tungere: versionsstyring og retrieval‑regressionstests. De betaler sig, når nye dokumenter eller prompts rulles ind og gamle fejl ellers genopstår.
Implementeringsnoter og tradeoffs
Der er altid en pris. LLM‑router øger latency og omkostning – svar med caching og simpel confidence‑degradering. Hybrid søgning øger kompleksitet – men uden den slipper semantisk nære, fagligt forkerte svar igennem. Cross‑encoders kræver GPU eller trimmede CPU‑noder; budgettér for det. Hellere få, gode komponenter end mange middelmådige.
To skabeloner, der virker: Minimum viable hårdning: 1) LLM‑router med cache, 2) hybrid søgning + let reranker og metadatafiltre, 3) basismetrics (router accuracy, retrieval precision@k, tool success rate, tail‑latency), 4) stramme tool‑schemaer med validering/timeouts, 5) simple evals med 30‑50 repræsentative queries. Enterprise hårdning: ovenstående plus 1) versionsstyring af indeks og prompts, 2) cross‑encoder rerank, 3) canary‑gates og smoke‑tests, 4) audit‑kæde med transaction‑ids, 5) automatiske regressionstests for retrieval og hallucinationer. Vælg i rigtig rækkefølge.
Hvad vi stadig mangler at vide
Casen er ærlig, men der er huller: ingen kvantificeret fejlrate pr. komponent i produktion, ukendt router‑misklassifikation, ingen precision@k før/efter hybrid+rerank, ingen fordeling af frontend‑inputtyper. Også uklart hvordan videnindekset er versioneret, og hvilke MCP‑fejltyper (timeouts/null/malformed) der dominerede. Et anonymiseret trace (routerbeslutning, top‑k‑hits med ids, værktøjsresponser med tidsstempler) ville gøre læringen skarpere. Indtil da er de punkter uoplyste.
Konklusion — hvad teams skal gøre i morgen
Kort, prioriteret: 1) Byg et eval‑sæt og en lille harness før næste release. 2) Skift fra vektor‑kun til hybrid søgning og tilføj en reranker. 3) Indfør en lille LLM‑router med caching og tvivls‑degradering. 4) Strukturer MCP‑værktøjer med validering, timeouts, retries og standardiserede fejlobjekter med transaction‑id. 5) Tænd for observability: router accuracy, retrieval precision@k, tool success, tail‑latency og et end‑to‑end SLO i et dashboard, nogen faktisk ser. Det er nok til at undgå de værste faldgruber.
Og en lille menneskelig note: Man opdager forskellen, når telefonen ringer kl. 06.14, og en kollega spørger, hvorfor agenten sagde fire timer. Jeg har stået i køkkenet med en kold espresso og et tomt dashboard. Det gør man kun én gang.
(Kilder: Sudip P., “5 Things Broke When I Shipped a RAG + MCP Agent to Production”, 27/5/2026. Snilld‑brief, internt. VentureBeat om DeepSWE og benchmark‑divergens.)
