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

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.
Explore more design patterns and system architectures
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 KontaktRAG 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).
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.
text-embedding-3-large, Cohere embed-v4 eller open source-alternativer (BGE, E5). Batchbehandling til indtagelse, enkeltforespørgselsbehandling til søgning| Lag | Teknologier |
|---|---|
| Dokumentparsing | Unstructured, Apache Tika, LlamaParse, Docling, custom OCR (Tesseract, AWS Textract) |
| Embedding | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Vektordatabase | Milvus, Pinecone, Qdrant, Weaviate, pgvector (til mindre skala) |
| Søgeordssøgning | Elasticsearch, OpenSearch, PostgreSQL full-text search |
| Reranking | Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank |
| LLM | Claude (via AI Gateway), GPT-4, Gemini – udbyderuafhængig via AI SDK |
| Orkestrering | LangChain, LlamaIndex, eller brugerdefineret pipeline (MW-præference for produktion) |
| Brug når | Undgå når |
|---|---|
| Brugere har brug for svar baseret på din organisations specifikke dokumenter | Vidensbasen er < 50 sider – indsæt det blot i systemprompten |
| Dokumenter opdateres ofte, og AI'en har brug for aktuelle informationer | Du 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 |
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.
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.
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.