MicrocosmWorksInnovere og Arkitektere Digitale Kosmos
OmKontakt
MicrocosmWorksInnoverer og arkitekterer digitale kosmos

Leverer IT-løsninger, der betyder noget. Vi brænder for teknologi, sikkerhed og at hjælpe virksomheder med at vokse gennem pålidelig, innovativ IT-infrastruktur.

[email protected]
+91 7011868196
New Delhi, India

AI Væksthub

AI HubStartup-innovationVirksomhedsaccelerator

Løsninger

Alle løsningerSundhed & Fitness AppsAI VideoplatformAI Agentudvikling

Ressourcer

IndsigterIndustri GuiderBrugssag BlueprintsArkitektur MønstreCase Studier

Virksomhed

Om OsKontaktVores Arbejde

Tjenester

Digital RådgivningCloud InfrastrukturSaaS UdviklingAI UdviklingVideo Teknologi
ERP UdviklingZoho TilpasningOdoo UdviklingSalesforce IntegrationTilpasset CRM Udvikling
QuickBooks IntegrationIoT LøsningerBlockchain Udvikling
Cybersikkerhed RådgivningIT-support - L3

© 2026 MicrocosmWorks. Alle rettigheder forbeholdes.

PrivatlivspolitikServicevilkår
Tilbage til arkitekturmønstre
AI / DataAdvanced

RAG Pipeline Arkitektur

Giv din LLM adgang til dine data uden finjustering. RAG bygger bro mellem generelle sprogmodeller og domænespecifik viden.

June 22, 2026
|
2 topics covered
Diskuter denne arkitektur
rag-pipeline-architecture.webp
AI / Data
Category
Advanced
Complexity
Juridisk, Sundhedssektoren
Industries
2+
Technologies

Hvornår du har brug for dette

Du ønsker at bygge en AI-assistent, der besvarer spørgsmål om din organisations dokumenter – kontrakter, politikker, vidensbaser, produktdokumentation, medicinske journaler. Finjustering af en LLM på dine data er dyrt, langsomt og skaber en model, der er fastfrosset på træningstidspunktet. Du har brug for en arkitektur, hvor LLM'en kan få adgang til opdateret, domænespecifik information på forespørgselstidspunktet, citere sine kilder og undgå at hallucinere fakta, der ikke findes i dine dokumenter. RAG (Retrieval-Augmented Generation) er vejen dertil.

Related Architecture Patterns

Explore more design patterns and system architectures

ai-ml-pipeline-architecture.webp
AI / Data

AI/ML Pipeline Arkitektur

Modeller kører ikke sig selv. Den pipeline, der træner, validerer, implementerer og overvåger dine modeller, er det egentlige produkt – modellen er blot ét artefakt.

EnterpriseView
scalable-vector-database-architecture.webp

Har du brug for hjælp til at implementere denne arkitektur?

Vores arkitekter kan hjælpe dig med at designe og bygge systemer ved hjælp af dette mønster til dine specifikke krav.

Kom i Kontakt

Mønsteroversigt

RAG forbedrer LLM-generering med hentet kontekst fra en vidensbase. Ved forespørgselstidspunktet konverterer systemet brugerens spørgsmål til en embedding, søger i en vektordatabase efter semantisk lignende dokumentsegmenter og inkluderer de mest relevante segmenter som kontekst i LLM-prompten. Dette baserer modellens svar på faktiske dokumenter, muliggør kildehenvisning og holder vidensbasen opdaterbar uden gentiltræning. En produktions-RAG-pipeline håndterer indtagelse (parsing, chunking, embedding), genfinding (vektorsøgning, reranking, hybrid søgning) og generering (promptkonstruktion, streaming, guardrails).

Referencearkitektur

Arkitekturen har to pipelines. Indtagelsespipelinen behandler dokumenter gennem parsing (PDF, DOCX, HTML-udtræk), chunking (semantisk eller fast størrelse med overlap), embedding (via embedding-model) og lagring (vektordatabase + dokumentlager). Forespørgselspipelinen tager et brugerspørgsmål, genererer en forespørgselsembedding, henter kandidatsegmenter fra vektordatabasen, omrangerer dem for relevans, konstruerer en prompt med de øverste segmenter som kontekst og streamer LLM-svaret med kildehenvisninger.

Kernekkomponenter
  • Dokumentindtagelsespipeline: Multiformat-parser (Apache Tika, Unstructured, eller brugerdefineret), der udtrækker tekst fra PDF'er, DOCX, HTML, Markdown og scannede billeder (OCR). Chunking-strategien opdeler dokumenter i genfindelige enheder – MW standardiserer til semantisk chunking (opdeling ved afsnits-/sektionsgrænser) med en målrettet størrelse på 512 tokens og 50 tokens overlap
  • Embedding-tjeneste: Konverterer tekstsegmenter til vektor-embeddings. Bruger modeller som OpenAI text-embedding-3-large, Cohere embed-v4 eller open source-alternativer (BGE, E5). Batchbehandling til indtagelse, enkeltforespørgselsbehandling til søgning
  • Vektordatabase: Gemmer embeddings med metadata til filtreret søgning. Understøtter Approximate Nearest Neighbor (ANN) søgning i stor skala. Se Skalerbar Vektordatabasearkitektur for overvejelser om produktionsskala
  • Genfinding & Reranking: To-trins genfinding – hurtig ANN-søgning returnerer top-50 kandidater, derefter en cross-encoder reranker (Cohere Rerank, BGE Reranker eller ColBERT), der scorer hver kandidat mod forespørgslen for præcis relevansrangering. Top-5 segmenter sendes til LLM'en
  • Hybrid søgning: Kombinerer vektor (semantisk) søgning med søgeord (BM25) søgning. Dette fanger tilfælde, hvor vektorsøgning misser præcis terminologi (produktkoder, juridiske klausuler, medicinske termer), som søgeordssøgning håndterer godt. Reciprocal rank fusion fletter de to resultatsæt

Designbeslutninger & Kompromiser

Chunking-strategi: Fast størrelse vs. semantisk vs. dokumentstruktur
Chunking med fast størrelse (opdeling for hver N tokens) er simpelt, men bryder midt i sætninger og mister dokumentstrukturen. Semantisk chunking (opdeling ved naturlige grænser – afsnit, sektioner, overskrifter) bevarer kontekst, men producerer segmenter af variabel størrelse. Dokumentstruktur-chunking (respekterer dokumentets hierarki – kapitler, sektioner, undersektioner) er bedst til strukturerede dokumenter som juridiske kontrakter eller tekniske manualer. MW standardiserer til semantisk chunking og skifter til dokumentstruktur for stærkt formaterede kilder.
Vektorsøgning vs. hybrid søgning
Ren vektorsøgning fungerer godt til samtalebaserede forespørgsler ("hvordan håndterer jeg refusioner?"), men fejler ved eksakte match-forespørgsler ("hvad er klausul 7.3.2?"). Hybrid søgning (vektor + BM25 søgeord) håndterer begge dele. MW anbefaler hybrid søgning for ethvert domæne med specifik terminologi, koder eller identifikatorer – hvilket er de fleste virksomhedsdomæner. Den 10-15% yderligere kompleksitet er den betydelige relevansforbedring værd.
Reranking: Cross-Encoder vs. Ingen
Cross-encoder reranking tilføjer 100-300 ms latenstid, men forbedrer dramatisk genfindelsespræcisionen – vi har målt 15-25% forbedring i top-5 relevans inden for juridiske og sundhedsmæssige domæner. MW inkluderer reranking som standard for ethvert RAG-system, hvor svarkvalitet er vigtigere end latenstid under et sekund. For chatbots, hvor hastighed er kritisk, springer vi reranking over og kompenserer med bedre chunking og prompt engineering.
Enkeltvektor vs. Multivektor (ColBERT-stil)
Enkeltvektor-embeddings er enklere og billigere at lagre/søge i. Multivektor-repræsentationer (én vektor pr. token, sen interaktionsscoring) fanger mere nuance, men kræver specialiseret infrastruktur. MW bruger enkeltvektor til de fleste implementeringer og forbeholder multivektor til domæner, hvor genfindelseskvaliteten er flaskehalsen, og dokumentkorpuset overstiger 100K segmenter.

Teknologivalg

LagTeknologier
DokumentparsingUnstructured, Apache Tika, LlamaParse, Docling, custom OCR (Tesseract, AWS Textract)
EmbeddingOpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2
VektordatabaseMilvus, Pinecone, Qdrant, Weaviate, pgvector (til mindre skala)
SøgeordssøgningElasticsearch, OpenSearch, PostgreSQL full-text search
RerankingCohere Rerank, BGE Reranker, ColBERT v2, FlashRank
LLMClaude (via AI Gateway), GPT-4, Gemini – udbyderuafhængig via AI SDK
OrkestreringLangChain, LlamaIndex, eller brugerdefineret pipeline (MW-præference for produktion)

Hvornår skal bruges / Hvornår skal undgås

Brug nårUndgå når
Brugere har brug for svar baseret på din organisations specifikke dokumenterVidensbasen er < 50 sider – indsæt det blot i systemprompten
Dokumenter opdateres ofte, og AI'en har brug for aktuelle informationerDu har brug for, at modellen lærer en ny færdighed/adfærd, ikke at få adgang til nye fakta (finjuster i stedet)
Kildehenvisning og auditabilitet er krav (juridisk, compliance, sundhedspleje)Spørgsmålene er rent samtalebaserede og kræver ikke faktuel forankring
Flere brugergrupper har brug for adgang til forskellige dokumentundermængder (tilladelsesfiltreret RAG)Du bygger et kreativt skriveværktøj, hvor faktuel nøjagtighed ikke er målet

Vores tilgang

MW bygger RAG-pipelines ud fra genfindelseskvaliteten – vi benchmark’er genfindelsespræcisionen, før vi rører ved LLM-prompten. Et RAG-system med middelmådig genfinding og en fantastisk LLM producerer selvsikre, men forkerte svar. Vores standardpipeline inkluderer en genfindelsesevalueringsmekanisme: et sæt testforespørgsler med kendte relevante dokumenter, målt ved MRR@5 og NDCG@10. Vi itererer på chunking, embedding-model og reranking, indtil genfindelsesmålinger rammer måltærskler, før vi optimerer genereringen. Vi har bygget RAG-systemer inden for juridisk dokumentgennemgang, sundhedsvidensbaser og flersproget kundesupport – og den fælles lektie er, at genfindelseskvaliteten står for 80% af svarkvaliteten.

Relaterede blueprints

  • AI Kundesupportagent — RAG-drevet supportagent med genfinding fra vidensbase
  • AI Dokumentbehandlingspipeline — Dokumentindtagelse, parsing og AI-drevet udtrækning

Relaterede brancheguides

  • AI for Legal — RAG-applikationer inden for kontraktgennemgang og juridisk forskning

Relaterede casestudier

  • Dokumentintelligens — Lokal RAG-pipeline til regnearks- og dokumentanalyse
  • AI Chat Platform — Multimodel-chat med dokumentgenfinding og GDPR-kompatibel datahåndtering
Related Technologies
AI UdviklingSaaS Udvikling
AI / Data

Skalerbar vektordatabasearkitektur

Embedding-søgning er nemt ved 10K vektorer. Ved 100M vektorer med sub-100ms P99 er det et infrastrukturproblem – og det er præcis, hvad dette mønster løser.

EnterpriseView
multi-tenant-saas-architecture.webp
Application

Multi-Tenant SaaS-arkitektur

Én kodebase, hundredvis af tenants, ingen datalækage — fundamentet for enhver skalerbar SaaS-virksomhed.

AdvancedView

Ofte stillede spørgsmål

MicrocosmWorks implementerer konfliktløsning i RAG-pipelines gennem rangering af kildeautoritet, tidsstempelbaseret nyhedsvægtning og tillidsscoring, der evaluerer, hvor stærkt hvert hentet passage understøtter sin påstand. Når modstridende passager hentes, præsenterer vores pipeline det svar med højeste autoritet, samtidig med at uenigheden og kildehenvisningerne gøres gennemsigtige, så brugere kan træffe informerede beslutninger. Vi bygger også feedback-loops, hvor domæneeksperter kan markere ukorrekte løsninger, hvilket forbedrer søgerangering over tid.

MicrocosmWorks bruger indholdsbevidst chunking, der anvender forskellige strategier baseret på dokumentstruktur—semantisk afsnitsopdeling for prosa, række-niveau eller sektions-niveau chunking til tabeller med bevaret header-kontekst, og funktions-niveau chunking til kode med tilhørende import statements. Vi beriger hver chunk med metadata inkluderende dokumenttitel, sektionshierarki og content type, så retrieval-fasen kan anvende type-specifik scoring. Denne tilgang overgår konsekvent naiv fixed-size chunking med 25-40% på retrieval relevance benchmarks i vores klientprojekter.

MicrocosmWorks bygger evalueringsplatforme, der tester RAG-pipelines på tværs af tre dimensioner: retrieval-relevans (findes de rette 'chunks'), svarets troværdighed (afspejler det genererede svar faktisk det hentede indhold) og svarets fuldstændighed (besvarer det hele spørgsmålet). Vi skaber 'golden test sets' med domæneeksperter, der inkluderer forespørgsler med kendte svar, modstridende 'edge cases' og spørgsmål, der kræver syntese fra flere dokumenter. Denne evaluering kører automatisk i CI/CD, så enhver pipeline-ændring benchmarkes mod grundlæggende kvalitetsmålinger før implementering.

MicrocosmWorks vælger vektordatabaser baseret på jeres skala, forespørgselsmønster og operationelle krav – Pinecone for administreret enkelhed, Weaviate for hybrid nøgleords-vektor-søgning, pgvector for teams, der allerede har investeret i PostgreSQL, og Qdrant til selvhostede implementeringer med høj gennemstrømning. Ved skalaer under 10 millioner vektorer leverer de fleste muligheder en forespørgselsforsinkelse på under 100 ms, men forskellene bliver markante ved hundredvis af millioner af vektorer, hvor indekstype, kvantisering og sharding-strategi betyder utrolig meget. Vi benchmark'er jeres faktiske embedding-dimensioner og forespørgselsmønstre mod udvalgte muligheder under vores arkitekturdesignfase.

MicrocosmWorks bygger inkrementelle indlæsningspipelines, der overvåger kildedokumentdepoter for ændringer, kun genopdeler og genindkapsler de modificerede sektioner og opdaterer `vector store` uden at kræve en fuld `reindex`. Vi implementerer `document fingerprinting`, der detekterer indholdsændringer på sektionsniveau, så en enkelt paragrafredigering ikke udløser genbehandling af et helt 200-siders dokument. For kunder med realtidsfriskhedskrav tilføjer vi et `live retrieval layer`, der forespørger kildesystemet direkte efter nyligt modificerede dokumenter og fletter disse resultater med `vector search`-træffere.