Hybrid søgning er gået fra pæn idé til krav for teams, der vil gøre RAG driftsklar. Det lyder tørt. I praksis er det forskellen på et demo og et system, der kan overleve en mandag kl. 09. Tencent har samtidig frigivet en firelags agent‑memory under MIT‑licens, og den rammer ned i samme problem: hvordan vi holder styr på lange forløb uden at drukne modellen i støj. Vi har set det i flere kundeforløb, og konklusionen er klar: uden hybrid søgning og et skarpt driftsregime holder RAG ikke i virkeligheden.
To hurtige fodnoter før vi folder det ud. 1) MachineLearningMastery og vores egen praksis peger på det samme: hybrid semantisk‑leksikal retrieval er afgørende ved overgang til produktion. 2) Succesraten afhænger ofte mere af opsætning, cache og eval end af en ny model. 3) Tencents Agent Memory er interessant, fordi den kører lokalt oven på SQLite med sqlite‑vec og lægger en klar struktur på agenters langtidshukommelse. Det gør længere workflows mere realistiske uden cloud‑bindinger.
Hvad kilderne siger
MachineLearningMastery fremhæver, at hybrid search er kritisk ved skiftet fra prototype til produktionsparat RAG. Det understøtter vi som Snilld med egne erfaringer og vores manual brief, hvor vi ser den samme pointe igen og igen: kombinationen af vektorbaseret semantik og leksikalsk BM25 forbedrer både præcision og robusthed over for domænespecifikke udtryk. Når man lægger reranking, kontekstuel filtrering og feedback‑loops ovenpå, stabiliserer man relevansen i skala.
Praktiske driftsgreb fylder mere, end mange håber. Caching, latency‑optimering, cost‑bevidst embedding‑opsætning og løbende evaluering er ofte det, der afgør, om noget kører i produktion og ikke bare på en bærbar. Vores interne cases og briefet afspejler det samme. Og ja, rerankere samt BM25 er centrale her.
Hvorfor hybrid search
Semantisk retrieval er stærk til synonymer, parafraser og koncepter, men den kan glide på skarpe domæne‑tokens. Leksikal søgning med BM25 er omvendt bogstavelig og robust. Hybriden giver et sikkerhedsnet. Når juraen siger paragraf 19, stk. 2, eller medicinen nævner HLA‑B27, er det ofte BM25, der sikrer, at de rigtige dokumenter overhovedet er med. Omvendt kan vektorlaget fange, at en patientvejledning omhandler kontraindikationer, selv om ordet ikke står der.
Vi så det i en juridisk POC: En semantisk top‑k gav pæne kandidater, men missede afgørende dokumenter med en bestemt paragrafformulering. BM25‑laget trak dem konsekvent ind. Først da vi lagde en cross‑encoder‑reranker ovenpå, landede rækkefølgen rigtigt. Det virker, fordi præcision og recall balanceres bedre end med et enkelt lag.
Arkitektur i praksis
En typisk produktionspipeline er ikke fancy, bare disciplineret: ingestion med robust parsing og chunking. Embedding af dokumenter. En vektor‑database til semantik. Et separat BM25‑indeks. Kandidatekstraktion: top‑k fra vektor, top‑k fra BM25. Fletning. Reranking med en lille, men skarp model. Kontekstuel filtrering før prompt. Til sidst caching og grundige logs.
Teknologivalg er tradeoffs. Lokal SQLite med sqlite‑vec giver enkel drift og datalokalisering men kræver omtanke for concurrency og backup. En hosted vektor‑DB aflaster DevOps og skalerer lettere, men har data‑hensyn og omkostninger, især ved høj QPS. Vi har set SQLite‑baserede opsætninger give fin latency i små til mellemstore deployments; uden ordentlig connection‑pooling og WAL‑tuning får de dog problemer under last. Det kan løses, men kræver ingeniørarbejde.
Skalering og drift
Latency forsvinder ofte i små optimeringer. Batch jeres embedding‑jobs. Kvantiser embeddings, hvor modellen understøtter det med minimalt præcisionstab. Caches: en varm query‑cache nær rerankeren og en dokument‑cache før prompten. Og flyt alt ikke‑kritisk ud af request‑banen med asynkronisering.
Evaluer løbende. A/B‑test retrieval‑kandidater og mål MRR og nDCG på interne queriesets. Overvåg p99‑latency, cache hit rate og ingestion‑fejl. Vores erfaringer, anonymiseret: i tre klientprojekter gik p99 fra cirka 1,2 sekunder til 0,45 sekunder efter cache og batching. MRR steg cirka 12–18 procent. Det er håndværk, ikke held.
Reranking, filtrering og feedback
Rerankeren er stødpuden mod støj. En lille cross‑encoder er ofte nok. Den koster mere pr. kandidat end en bi‑encoder, men rydder op. Filtrering på kontekstlængde, kildeprioritet og recency hjælper yderligere. Hvis nylig dokumentation skal vægte højere, så kod det eksplicit i pipeline‑logikken og i rerankerens features.
Feedback‑loops kræver systematik. Log alle queries, kandidater, valgt kontekst og brugerens outcome. Etabler en annotation‑pipeline, hvor et lille panel mærker kvalitet ugentligt. Træn eller finjuster retriever eller reranker på den strøm. En simpel kadence kan være ugentlig prøveudtagning til mærkning og månedlig retrain. Vi sprang det over én gang og så relevansen falde i løbet af tre uger.
Tencents agent‑memory
Tencent har open‑sourcet TencentDB Agent Memory under MIT‑licens, ifølge MarkTechPost. Målet er at løse long‑horizon‑problemer som kontekst‑oppustning og dårlig genkaldelse. Arkitekturen er lagdelt i fire niveauer, L0 til L3, og kombinerer symbolsk korttidshukommelse med lagret langtid. Det er ikke bare endnu en flad vektorbutik; det er en struktureret pyramide.
Integrationerne er praktiske. Der findes et plugin til OpenClaw og en gateway‑adapter til Hermes Agent. Standard‑backend er lokal SQLite med sqlite‑vec, så man kan køre uden ekstern API. Ifølge kilden er lagene L0 Conversation, L1 Atom, L2 Scenario og L3 Persona. Overordnet bruger systemet Persona først, dykker til Scenario og derefter til Atom eller rå samtale, når detaljen kræver det.
Når hybrid RAG og agent‑memory mødes
En lagdelt memory gør det muligt at trække den rigtige slags viden ind i retrieval, før man bruger tokens. Persona‑laget kan styre tone og præferencer, mens Scenario og Atom giver konkrete fakta. Hvis man samtidig henter dokumenter via hybrid søgning, kan man balancere mellem brugerens historik og kold dokumentation.
Use cases, vi ser som mest oplagte nu: kundeservice med lang historik, hvor Persona‑laget forhindrer gentagelsesfejl, mens BM25 sikrer, at SKU‑koder og versionsnumre ikke udvandes. Teknisk support, hvor kontekst fra sidste fejlsøgning kan ligge i Scenario, og retrieveren finder de rigtige patch‑notes via både vektor og token. Compliance‑samtaler, hvor persona‑laget markerer restriktioner, og hybrid retrieval sikrer citater fra de rigtige paragraffer.
Risici og begrænsninger
Kompleksitet er en reel risiko. To retrievere, en reranker, caches og en memory‑pyramide giver flere fejlpunkter. Driftomkostningerne kan stige, især hvis man vælger hosted løsninger til alt. Modelbias i rerankeren kan slå skævt, hvis træningsdata ikke dækker jeres nicher. Og privatliv: lokale backends hjælper, men kræver governance, audit‑logs og adgangskontrol.
Hvor kilderne tier, bør man teste. Der mangler hårde benchmarks for sqlite‑vec mod hosted vektor‑DB under realistisk last. Sikkerhedsdetaljer for sqlite‑vec default‑setup er ikke beskrevet i dybden. Reranker‑modellers konkrete latency‑profiler og modenheden af OpenClaw‑ og Hermes‑adapters i store, heterogene miljøer er også underbelyst. Anbefalingen er enkel: kør egne loadtests og piloter, før I integrerer bredt.
Anbefalinger fra Snilld
Start med et prototype‑checkpoint. Mål baseline for p99‑latency, MRR og cache hit rate, før I rører noget. Vælg hybrid design tidligt: vektor + BM25 som standard, også hvis semantik ser god ud i demo. Læg en lille, effektiv reranker ind og en simpel kontekstfiltrering.
Definer målepunkter før rollout: p99 under en halv sekund for interaktive flows, MRR‑tærskel fastsat og overvåget, cache hit over 70 procent ved steady state. Etabler driftspakken: logging af kandidater og valgte kontekster, daglige eval‑jobs og månedlig retrain af reranker. Om agent‑memory: test Tencents lagdelte model i et lokalt miljø først, især hvis I allerede kører SQLite i jeres stack. Vi tilbyder et kompakt standardforløb med arkitektur, implementering og pilot for teams, der vil accelerere, men det er ikke en forudsætning for at lykkes.
Case fra felten
I en anonymiseret implementering gav et teknisk supportflow sære svar. Opsætningen brugte kun semantisk retrieval, ingen reranker og ingen cache. Vi lagde et BM25‑lag ind, justerede chunking, tilføjede en let cross‑encoder‑reranker og en varm cache. P99‑latency faldt fra cirka 1,2 til 0,45 sekunder, og MRR steg cirka 15 procent. Hallucinationer faldt især i sager med produktkoder, hvor det leksikale lag bar svarene hjem.
En praktisk detalje: ofte stillede spørgsmål brugte interne forkortelser, som embeddings ikke fangede stabilt. BM25 gjorde. Det ser man først, når man lytter til supporten og kigger i logs.
Implementering i hverdagen
Valget mellem hosted vektor‑DB og lokal sqlite‑vec koger ned til tre ting: compliance, latency nær brugeren og driftsbudget. Hvis data ikke må ud af huset, er lokal drift med SQLite oplagt, men kræver plan for backup, kryptering i hvile, opdateringsvinduer og pool‑styring. Hosted giver skaleringsro og bedre failover ud af boksen, men prisen løber, hvis jeres query‑mønster er snakkesaligt.
Supportorganisationen ændrer sig også. Hav en klar rollback‑procedure for retrievers og rerankers, en annotation‑kanal med ejerskab og en forudsigelig retrain‑kadence. Uden det bliver hver fejl en brand. Til produktchefer: prioriter hybrid, hvis jeres domæne er rigt på faste tokens, eller hvis kontekstlængden svinger meget.
Om Tencent i praksis
Den lagdelte agent‑memory er lovende for samtaler, der løber over uger. Persona sætter rammer, mens beviserne ligger i Atom og Conversation. For RAG betyder det, at man kan styre, hvor meget historik der trækkes ind i hver prompt, og at retrieval kan spørge forskelligt alt efter opgaven. MarkTechPost beskriver integrationsstien via OpenClaw og Hermes, og default‑backenden uden ekstern API gør den egnet til lokale set‑ups.
Men der er huller i dokumentationen set fra driftens side. Der er ikke feltdata på, hvor meget hallucination reelt falder over tid med lagdelt memory. Og integrationsomkostninger i heterogene agent‑stacks er ikke beskrevet i dybden. Det er fair — test det på egne flows med et lille team og en stram måleplan.
Fremtid og trends
Vector‑databaser bevæger sig mod mere hybride kerner, hvor BM25‑varianter sameksisterer tæt med vektorindeks. On‑device memory og lokale backends vinder på compliance og end‑to‑end‑kontrol. Standardisering af agent‑memory er stadig ung, men Tencents MIT‑licens kan presse på for fælles mønstre, især hvis OpenClaw‑miljøet vokser.
Forvent mere målrettet værktøj: små, hurtige rerankers tæt på API‑laget og bedre tooling til feedback‑loops. En simpel læring for os: gode log‑dashboards afslører de reelle problemer.
Konklusion
Hvad gør du i næste uge: Læg BM25 ved siden af jeres vektorlag. Sæt en lille reranker på. Mål MRR, p99 og cache hit i en uge. Overvej Tencents Agent Memory i et afgrænset lokalsetup, hvis jeres flows lider af kontekst‑oppustning. Udpeg en ansvarlig for feedback‑loopet som en fast driftsopgave.
Hvornår stopper man optimeringen og deployer: Når p99 er under jeres mål, MRR er stabilt, og supporten ikke ringer om de samme fejl. Resten kan justeres i drift.
