Hvorfor vektorsøg alene ikke rækker i produktion
En enkel RAG-pipeline kan bevise en idé: indlæs dokumenter, lav embeddings, læg dem i en vektorbase, hent et par bidder og lad modellen svare. Dave R gennemgår på Towards AI, hvorfor det typisk kun rækker til et proof-of-concept, ikke til produktionsarkitektur [3099]. Når korpuset vokser, spørgsmålene bliver mindre forudsigelige, og svar afhænger af flere kilder, falder ren vektorsøgning ofte i præcision og forklarbarhed [3099]. En samlet gennemgang af operationelle krav peger desuden på behov for hybrid retrieval, versionsstyring og evaluering for at holde støj nede og styrbarheden oppe [3100].
Hvorfor vektorsøg ofte fejler i drift
Vektorsøg finder semantisk lignende bidder, men enkeltstående vektorforespørgsler rammer muren, når et spørgsmål kræver relationer på tværs af dokumenter eller præcis matchning af navne, tal og termer. Towards AI beskriver, hvordan aggressiv chunking kan tabe kontekst, og hvordan multi-dokument-forespørgsler risikerer plausible, men ufuldstændige svar [3099]. Der er heller ikke automatisk dækning mellem hele brugerens informationsbehov og de bidder, der hentes, hvilket gør hullerne synlige i strengere miljøer [3099].
Hybrid søgning, grafer og re-ranking
Hybrid søgning kombinerer keyword-søgning (fx BM25) og vektorsøg. Towards AI beskriver også Reciprocal Rank Fusion, der fusionerer kandidatlister for at løfte recall uden at smadre præcisionen [3099]. Pointen er arbejdsdeling: nøgleord fanger entiteter og faste udtryk, mens vektorer fanger semantik og parafraser. Operationelle noter omhandler, at denne kombination typisk koster lidt mere infrastruktur og ventetid, men betaler sig i færre fejl og bedre kontrol i drift [3099][3100].
Når relationer styrer sandheden, bliver knowledge graphs relevante. Artiklen viser, hvordan grafretrieval kan trække sammenhænge på tværs af kilder og give et stærkere grundlag for svaret ved relationstunge spørgsmål [3099]. Semantisk re-ranking indgår som et ekstra lag, der prioriterer de mest relevante bidder før generering [3099].
Agenter og flertrins planlægning
Ved komplekse forespørgsler peger Towards AI på agent-baseret orkestrering, hvor systemet kan planlægge flere trin: hente yderligere kilder, kalde et API, sortere i resultater eller validere mod en anden datakilde, før svaret samles [3099]. Det introducerer flere komponenter og potentielle fejltilstande, som til gengæld kan reducere fejlslutninger ved at eksplicitere søge- og valideringsskridt [3099].
En arkitektur der kan måles og styres
Towards AI skitserer en tredelt arkitektur: offline ingestion, online retrieval/generation og en feedback-loop [3099]. Offline-delen dækker parsing, chunking, metadata-udtræk, vektorisering og versionering. Uden versionering af data og modeller er det svært at forklare ændringer i svar over tid [3099]. En supplerende driftsvinkel er at sikre datakvalitet i ingestion med validering af friskhed, deduplikering og adgangshåndtering [3100].
Online-laget samler værktøjer som hybrid-indeks, semantisk re-ranker, eventuelt et graph store og selve genereringen [3099]. Disse valg påvirker centrale driftsmål som latenstid og omkostninger pr. forespørgsel samt, indirekte, antallet af tokens der bruges, når retriever ikke rammer præcist [3099]. Kilderne er sammenfaldende om, at en smule ekstra arbejde i retrieval og re-ranking kan føre til sikrere svar og mere effektiv samlet kørsel [3099][3100].
Observability og evaluering i praksis
Towards AI foreslår at adskille tre metrikfamilier: retrieval-kvalitet (fx precision/recall på dokumentniveau), groundedness (i hvilken grad svaret kan forankres i kilderne) og svarrelevans [3099]. Den operationelle vinkel lægger lag på med driftstunge KPI’er som latenstid, fejlrate, omkostning pr. succesfuld session samt ændringsspor for data og modeller [3100]. Forbedringer ét sted kan påvirke et andet; derfor hører metrikkerne hjemme i løbende overvågning og review-processer, ikke kun i statiske noter [3099][3100].
Citationsstøtte i UI og logning af kildehenvisninger kan understøtte fejlfinding og compliance. Towards AI viser et reference-UI, hvor struktureret output og citationer præsenteres side om side, så brugeren kan kontrollere kildedækning [3099]. Det giver et bedre grundlag for validering i selve grænsefladen [3099].
UI der gør svaret nemmere at kontrollere
Referenceimplementeringen i .NET og Blazor fremhæver to greb: struktureret output (felter, lister, tabeller) og synlige citationer [3099]. Struktureret output reducerer formatvariation og letter integration med andre systemer. Synlige citationer gør det muligt at klikke ned i kilden og vurdere dækning [3099].
En gennemgang af driftsprincipper peger i samme retning og kobler det til governance: når faglige interessenter kan se kilde og version, kan dialogen i højere grad føres på objektive kriterier [3100].
Organisatorisk forankring og datakvalitet
Teknisk arkitektur uden processer ender sjældent godt. En operationel gennemgang argumenterer for en datakvalitetsstrategi, evalueringsgovernance, menneske-i-løkken og klare KPI’er fra start [3100]. AWS’ blog om knowledge management peger samtidig på, at organisationer på tværs af brancher kæmper med at fastholde institutionel viden, og at AI-understøttede systemer kan hjælpe med at bevare og levere viden via cloud-baserede tjenester [3101].
Adgangskontrol og sporbarhed hører hjemme i ingestion, ikke som eftertanke. Kilderne berører behovet for styring og compliance, men leverer ikke en færdig opskrift på audit trails eller GDPR-specifikke målepunkter i RAG-pipelines; det kræver særskilt implementeringsarbejde [3099][3101].
Konsekvenser for prioriteringer
Tre spor går igen i kilderne. For det første: planlæg for hybrid søgning, re-ranking og ved behov et graph store for relationstunge domæner [3099][3100]. For det andet: implementér observability og en evalueringspipeline tidligt, så ændringer kan dokumenteres og styres [3099][3100]. For det tredje: forankr ejerskab af datakvalitet og KPI’er organisatorisk, så forbedringer kan fastholdes over tid [3100].
Det har praktiske følger i projektarbejdet, som kilderne også adresserer: ingestion fungerer som en egentlig pipeline med versionering og kvalitetstjek; retrieval får plads til hybridteknikker og re-ranking; UI lægger sig op ad struktureret output og citationer; og driften læner sig op ad synlige målepunkter for kvalitet og omkostning [3099][3100]. Konkrete tærskler og mål (fx præcision/recall og latenstid) er ikke givet i kilderne og bør fastsættes via pilotmålinger i det pågældende miljø [3099][3100].
Hvad der mangler at blive dokumenteret
Kilderne leverer stærke principper, men ikke hårde tal. Der er ingen kvantitative benchmarks for omkostninger eller latenstid ved overgangen fra ren vektor til hybrid/graf. Effekten af caches og andre optimeringer er heller ikke tallessat i materialet [3099]. Det fremstår som en åben implementeringsopgave.
Kontekst betyder noget
Kilderne beskriver mønstre og byggeklodser. Valget af teknikker afhænger af domæne, krav til svar- og kildesikkerhed samt de tilgængelige ressourcer. Anbefalingerne peger retning, men implementeringen skal afvejes i forhold til data, brugsscenarier og compliancekrav i den konkrete organisation [3099][3100][3101].
Kort konklusion
RAG i produktion kræver mere end vektorsøg. Kilderne fremhæver hybrid søgning, grafretrieval, re-ranking og, når det behøves, agentisk planlægning – bundet sammen af løbende evaluering og observability [3099][3100]. De organisatoriske rammer om datakvalitet, metrikker og menneske-i-løkken er en del af leverancen, ikke et add-on [3100]. Der mangler stadig bredt tilgængelige benchmarks, så projekter må måle centralt selv [3099].
