Standard RAG-diagrammet har blitt liturgi. Embed. Chunk. Lagre i vektordatabase. Hent via cosine similarity. Dytt inn i kontekst. Generer.

Rimelig utgangspunkt. Ogsa, for de fleste systemene folk faktisk bygger, feil arkitektur.

Ikke feil i teori -- feil i praksis. Feil i hva det koster a drifte, feil i hvor det plasserer intelligens, og feil i hva det krever at du vedlikeholder.

Vi bygget et dokumentgjenfinningssystem for styrearbeidet i et norsk borettslag. Korpuset: 48 dokumenter, 3 800 tekstbiter, en 800 siders juridisk referanse, 86 styrevedtak over tre ar. Stakken: SQLite FTS5, fem MCP-verktoy, null embeddings, null vektordatabaser. Totalt fotavtrykk: 50 MB. Oppstart: under 100 millisekunder. Sok: under 10 millisekunder.

Det slar vektoralternativet vi evaluerte. Ikke pa benchmarks -- pa det som betyr noe: korrekte, siterte svar pa reelle sporsmal, hver gang en bruker apner en sesjon.

Her er arkitekturen, resonnementet og grensene.

I. RAG-kostnadsstakken

Den kanoniske pipelinen:

Dokumenter --> Chunking --> Embedding-modell --> Vektor-DB --> Top-K --> LLM --> Svar

Hver boks er en avhengighet. Hver avhengighet har en kostnad:

  • Embedding-modell: 2-3 GB (PyTorch pluss vekter), GPU-driverkompatibilitet, CUDA-versjonsrulett
  • Vektordatabase: 500 MB-2 GB, med egne feilmoduser -- indekskorrupsjon, minnepress, kaldstart
  • Chunking-strategi: Uker med tuning. For sma biter dreper kontekst, for store utvanner relevans
  • Embedding-kvalitet: De fleste modeller er English-first. Norsk, dansk, finsk far systematisk darligere resultater
  • Driftsoverhead: Embedding-drift nar modeller oppdateres, reindekseringskostnader, overvaking av vektorkvalitet over tid

For 50 000 flerspraklige dokumenter er disse kostnadene berettiget. Vektordatabasen tjener inn investeringen.

Men de fleste team bygger ikke det. De bygger interne kunnskapsbaser, complianceverktoy, styringsarkiver, juridiske forskningsassistenter, teknisk dokumentasjonssok. Hundrevis eller noen fa tusen dokumenter. Spesifikke domener.

Og konsumenten i enden av pipelinen er en LLM.

Det siste punktet endrer alt.

II. Nar konsumenten er en LLM

Tradisjonelt sok betjener et menneske. Ett sporsmal, ti resultater, reformuler om ingenting stemmer. Systemet ma vaere smart fordi brukeren har begrenset talmodighet og ingen evne til a prosessere femti resultater samtidig.

En LLM er en fundamentalt annerledes konsument.

Den reformulerer autonomt. Hvis "varmtvannssituasjonen" ikke gir treff, proever den "varmvannsberedere", deretter "varmtvann", deretter "beredere" -- i samme tur, uten menneskelig intervensjon. Et menneske trenger semantisk sok for a bygge bro over ordforradsgap. En LLM gjor dette naturlig.

Den syntetiserer bredt. Gi den femten biter fra ulike dokumenter, og den vever et sammenhengende svar med kildehenvisninger. Et menneske trenger perfekt rangering. En LLM trenger bred recall.

Den resonnerer over metadata. Gi den datoer, dokumenttyper, vedtaksnumre, og den filtrerer, kryssrefererer og utleder sammenhenger som ingen embedding fanger.

Den tolererer stoy. En irrelevant bit pa plass tre forvirrer et menneske. En LLM leser alle ti resultatene og forkaster det som ikke passer. Feiltoleransenm er fundamentalt forskjellig.

Dette gir et kontraintuitivt designprinsipp:

Nar konsumenten er en LLM, optimaliser for hastighet, palitelighet og bredde i recall -- ikke rangerings-presisjon.
LLM-en handterer presisjon. Du handterer rorleggerarbeidet. Slutt a gjore rorleggerarbeidet smart.

III. Bibliotekarmonsteret

Vi kaller dette Bibliotekarmonsteret: et raskt, palitelig, bevisst enkelt gjenfinningslag. Det finner dokumenter fort. Det oppsummerer ikke, tolker ikke, validerer ikke. LLM-en gjor alt det.

[Inntak]
  Dokumenter --> Ekstraktorer --> Biter + Strukturert metadata --> SQLite FTS5


[Kjoring]
  LLM --> MCP-verktoyskall --> SQLite-sporsmal (<10ms) --> Siterte biter --> LLM-resonnering

SQLite FTS5 handterer fulltekstsok med BM25-rangering. Innebygd i Pythons standardbibliotek. Ingen ekstern database, ingen serverprosess, ingen connection pool. Apner pa millisekunder.

Strukturerte metadatatabeller filtrerer etter dokumenttype, dato, kategori, forfatter. Styreprotokoller har rik YAML-frontmatter: motedatoer, saksnumre, vedtak, deltakerlister, dokumentstatus. Ved vart korpusstorrelse er denne metadataen mer verdifull for gjenfinning enn vektorlikhet.

MCP-verktoy utgjor grensesnittet mellom LLM-en og sok. Modellen kaller search(query="vedlikeholdsplikt", doc_type="reference") og far tilbake JSON med siterte passasjer.

Separate sokeintensioner er kodet i verktoysbeskrivelsene. Den juridiske referanseboken svarer pa framoverrettede sporsmal: "Hva sier loven om X?" Styreprotokollene svarer pa bakoverrettede: "Hva vedtok vi om X?" LLM-en griper naturlig til riktig kilde.

Hva vi ikke bygget:

  • Ingen embedding-modell (sparte 2-3 GB avhengigheter)
  • Ingen vektordatabase (sparte driftskompleksitet)
  • Inget semantisk matchinglag
  • Ingen valideringsmotor
  • Inget anbefalingssystem
  • Ingen confidence scoring

Hver komponent vi ikke bygget er en komponent som ikke kan knekke, ikke kan drifte, og ikke kan overraske oss klokken to pa natten.

IV. Sporsmalet om semantisk sok

Den opplagte innvendingen: ordbasert sok mister semantiske koblinger. "Varmeproblemer" matcher ikke "varmvannsberedere." Sant -- nar et menneske skriver ett sporsmal og stirrer pa resultatene.

I Bibliotekarmonsteret bygger LLM-en bro naturlig:

Tur 1: search("varmeproblemer")        --> 0 resultater
Tur 2: search("varmvannsberedere")      --> 3 resultater
Tur 3: search("varmtvann")              --> 5 resultater
Tur 4: Syntetiser alle resultater med kildehenvisninger

En samtaletur. Forti millisekunder for tre sok. Bedre dekning enn et enkelt semantisk sok -- fordi LLM-en utforsker ordforradet med domenekunnskap som ingen 384-dimensjonal embedding fanger.

Vi la til en forbedring: automatisk OR-fallback. Nar en flerords AND-sporsmal returnerer null resultater, proever motoren igjen med OR-logikk. Seks kodelinjer. Sporsmal som tidligere ga null treff returnerer na relevante seksjoner.

Nar du faktisk trenger vektorer: korpus over rundt 10 000 dokumenter der BM25-rangering bryter ned, systematisk ordforradsmismatch som LLM-en ikke kan bygge bro over, flerspraklig gjenfinning der embeddings handterer sprakskifte naturlig, eller menneskerettede resultater der rangeringspresisjon er kritisk.

For alt annet -- og det er de fleste interne kunnskapssystemer -- vinner Bibliotekaren.

V. Metadata som arkitektur

Vektorlikhet behandler all tekst som geometri. Et styrevedtak og et lovkrav er begge punkter i embedding-rommet. Forholdet mellom dem -- at det ene er et vedtak og det andre er dets rettslige grunnlag -- er usynlig for cosine similarity.

Strukturert metadata gjor disse relasjonene sporbare:

-- "Hva vedtok vi om vedlikehold i 2025?"
SELECT * FROM decisions
WHERE description LIKE '%vedlikehold%'
AND date BETWEEN '2025-01-01' AND '2025-12-31';


-- "Hva sier loven om vedlikeholdsplikt?"
SELECT * FROM chunks_fts
WHERE chunks_fts MATCH 'vedlikeholdsplikt'
AND doc_type = 'reference';

Presist, raskt, deterministisk. Ingen probabilistisk rangering, ingen temperatur, ingen "modellen henter noen ganger feil ting." LLM-en bestemmer hvilket sporsmal som skal kjores. Databasen utforer trofast.

Vare styreprotokoller har frontmatter med motedatoer, deltakerlister, vedtaks-IDer, dokumentstatus. Dette er rikere enn noen embedding. LLM-en kan svare "List alle vedtak fra 2025 som nevner budsjett" pa ti millisekunder. Ingen vektordatabase matcher denne presisjonen pa strukturerte sporringer.

VI. Tallene

Metrikk Bibliotekar (FTS5) Standard RAG
Avhengigheter ~50 MB 2-3 GB
Kaldstart <100ms 5-15 sekunder
Sokelatens <10ms 50-200ms
Minnefotavtrykk <50 MB 500 MB-1 GB
Bakgrunnstjenester Ingen Embedding-modell + vektor-DB
Reindeksering Sekunder Minutter til timer
Feilmoduser Disk full + embedding-drift, indekskorrupsjon, OOM

Oppstartsforskjellen er ikke akademisk. En MCP-server som bruker femten sekunder pa a starte er et verktoy som blir deaktivert. En som starter pa 100 millisekunder blir brukt hver sesjon.

VII. Beslutningsrammeverket

Lite korpus (<5K)     Stort korpus (>10K)
                   +--------------------+--------------------+
  LLM-konsument   |   BIBLIOTEKAR      |   HYBRID           |
                   |   FTS5 + metadata  |   FTS5 + vektorer  |
                   +--------------------+--------------------+
  Menneskelig     |   FASETTERT SOK    |   FULL RAG         |
  konsument       |   FTS5 + UI        |   Standard pipeline |
                   +--------------------+--------------------+

Bibliotekarmonsterets oppgraderingssti: legg til en embedding-kolonne i samme SQLite-skjema, sla sammen BM25- og vektorscorer. En til to timers arbeid, ikke en omskriving.

Forlat dette monsteret nar korpuset passerer 10K dokumenter og ordbasert sok gir for mye stoy. Forlat det nar flerspraklig gjenfinning er primaerbehovet. Forlat det nar mennesker -- ikke modeller -- konsumerer resultater direkte og trenger polert rangering pa forste forsok.

For alt annet, start med Bibliotekaren. Du kan alltid legge til vektorer senere. Du kan ikke enkelt fjerne dem.

VIII. Hvor intelligens bor leve

RAG-industrien brukte tre ar pa a bygge stadig mer sofistikert gjenfinning: re-rankere, hypotetiske dokumentembeddings, sporsmalsekspansjon, flertrinnskjeder. Hvert lag legger til intelligens i pipelinen.

Men LLM-en i enden er allerede den mest kapable resonneringsmotoren tilgjengelig. Hvert intelligenslag du legger til oppstroms konkurrerer med -- og taper vanligvis mot -- tingen som konsumerer resultatene.

Bibliotekarmonsteret inverterer dette. Gjor pipelinen enkel, rask og palitelig. Gi LLM-en rene data, god metadata og raske verktoy. La den resonnere.

Dette er den samme arkitektoniske klarheten som sier "plasser forretningslogikk i applikasjonslaget, ikke i databasen" eller "plasser rendering i klienten, ikke i serveren." Hver komponent gjor det den gjor best. Databasen lagrer og henter. LLM-en resonnerer og syntetiserer.

Nar du slutter a gjore gjenfinningspipelinen smart, far du noe bedre: et system som er raskt, forutsigbart, debuggbart og billig a drifte. Et system der den smarteste komponenten har full tilgang til alt den trenger, levert pa millisekunder, uten probabilistiske mellomledd mellom sporsmalet og svaret.

En bibliotekar. Ikke en kollega. Rask, palitelig, og akkurat sa smart som den trenger a vaere.

Produksjonsvalidert. 48 dokumenter, 3 800 biter, 86 vedtak, en 800 siders juridisk referanse. Null embeddings. 50 MB totalt. Svar pa under 100 millisekunder.