Bygg ett produktionsklart RAG-system: inläsning, inbäddning, hämtning, omrangordning och utvärdering

Om du har levererat ett enkelt system för hämtningsförstärkt generering (RAG) känner du igen mönstret: dela upp dokument, bädda in dem, lagra dem i en vektordatabas, hämta de k högst rankade träffarna för en fråga och stoppa in dem i prompten. Det fungerar för demonstrationer. I produktion gör det ofta användarna besvikna.

Skillnaden mellan ett RAG-system för demonstration och ett produktionsklart RAG-system är stor. Verkliga dokument är röriga. Verkliga frågor är tvetydiga. Kvaliteten varierar kraftigt mellan olika frågetyper. Kostnad och latens är reella begränsningar. Uppdateringar och versionshantering spelar roll.

Det här är en designchecklista för produktion: sex logiska steg och de mätningar som behövs i varje steg. Det är ingen reproducerbar benchmark från AIExpert. Börja med den ursprungliga RAG-artikeln, använd en heterogen hämtningsbenchmark som BEIR för att förstå valet av mätvärden, och bygg en egen utvärderingsmängd ur din egen korpus innan du väljer komponenter.

Pipelinen

Ett produktionsklart RAG-system har sex logiska steg:

[Dokument]
    ↓
1. Inläsning (parsning, rensning, extrahering av metadata)
    ↓
2. Segmentering (indelning i hämtningsenheter)
    ↓
3. Inbäddning (vektorer + lagring)
    ↓
[Fråga]
    ↓
4. Hämtning (semantisk + lexikal + filter)
    ↓
5. Omrangordning (topp-k → topp-N)
    ↓
6. Generering (LLM + kontext)
    ↓
[Svar]

Varje steg har sina egna kvalitetsaspekter. En förbättring av ett enskilt steg förbättrar helheten.

Vi går igenom dem ett i taget.

Steg 1: Inläsning

Skräp in, skräp ut. Kvaliteten på inläsningen sätter taket för allt som följer.

Källtyper du kommer att stöta på:

• PDF-filer (oftast värst).
• Word-dokument.
• HTML-sidor.
• Markdown.
• Kalkylblad.
• Presentationer (PowerPoint, Google Slides).
• E-post.
• Kod.
• Strukturerade data (CSV, JSON).

Varje typ har sina egna parsningsutmaningar.

Parsning av PDF. PDF är ett presentationsformat, inte ett dataformat. Det är ökänt svårt att parsa. Strategier:

• Textbaserade PDF-filer: pdfplumber, pymupdf, unstructured. Fungerar för ren text.
• Skannade PDF-filer: OCR med Tesseract, Google Cloud Vision eller AWS Textract.
• Layoutmedveten parsning: LayoutLM, Mathpix eller LLM-baserad parsning (GPT-4 vision) för komplexa layouter (tabeller, flera spalter).

En modern metod för svåra PDF-filer är att använda en LLM med bildförståelse för OCR och strukturering av innehållet. Kostnaden är högre, men kvaliteten är dramatiskt bättre än med traditionell OCR.

Hantering av tabeller. Tabeller i ostrukturerad text är besvärliga. Antingen:

• Konvertera dem till Markdown-tabeller (bevarar strukturen).
• Linjärisera dem till prosa (”Rad 1: kund A hade 50 beställningar …”).
• Behandla dem som separata hämtningsbara enheter med ett strukturerat schema.

Rätt val beror på vilka frågor du kommer att få.

Extrahering av metadata. Varje dokument har metadata som spelar roll:

• Titel, författare, datum, version.
• Ämne, kategori, taggar.
• Käll-URL eller plats.
• Behörigheter/synlighet.

Samla in detta vid inläsningen. Det blir filterparametrar vid hämtningen.

Rensning. Ta bort standardinnehåll:

• Sidhuvuden och sidfötter som upprepas på varje sida.
• Navigering, annonser och cookiebannrar.
• Sidor med ”innehållsförteckning”.
• Tomma eller duplicerade stycken.

En ren korpus ger bättre hämtning. Standardinnehåll orsakar falska träffar.

Kvalitetskontroller.

• Extraherade parsern faktiskt någon text? (Vissa PDF-filer returnerar tomma strängar.)
• Finns det kodningsproblem?
• Bevaras tabellerna?
• Har figurer bildtexter eller hoppas de över?

Bygg in rimlighetskontroller i inläsningspipelinen. Fånga trasiga parsningar innan de förorenar indexet.

Steg 2: Segmentering

Nu har du rena dokument. Därefter delar du upp dem i hämtningsenheter (textsegment).

Den grundläggande avvägningen:

• Små textsegment: exakt hämtning (fokuserad på frågan), men kontext saknas.
• Stora textsegment: mer kontext, men lägre precision (den relevanta delen ligger begravd).

Båda ytterligheterna kan försämra kvaliteten för vissa frågefördelningar. Välj segmentgränser och föräldrakontext utifrån märkta hämtnings- och svarsresultat, uppdelat per dokument- och frågesegment.

Vanliga strategier:

Textsegment med fast storlek och överlappning. Dela upp i segment om N token (300–800 token) med 50–100 tokens överlappning. Enkelt och fungerar som baslinje.

Meningsmedveten segmentering. Dela vid meningsgränser (med nltk, spaCy eller motsvarande). Undviker delning mitt i en mening.

Styckebaserad segmentering. Varje stycke är ett textsegment. Fungerar för dokument med välstrukturerade stycken.

Hierarkisk segmentering (små + stora). Två index:

• Små textsegment (300 token) för exakt hämtning.
• Stora textsegment (1 500 token) eller hela avsnitt för kontext. Vid hämtning hämtas de små segmenten, medan deras stora överordnade segment skickas till LLM-modellen.

Dokumentstrukturmedveten segmentering. Använd dokumentets struktur (rubriker, avsnitt) för att styra segmenteringen. Varje avsnitt blir ett textsegment och hierarkin bevaras.

Semantisk segmentering. Använd inbäddningar för att hitta naturliga brytpunkter (där ämnet skiftar). Dyrare, men ger bättre textsegment för vissa typer av innehåll.

LLM-baserad sammanfattningssegmentering. Långa dokument sammanfattas till hierarkiska textsegment på flera nivåer (styckes-, avsnitts- och dokumentsammanfattning). LLM-modellen genererar dessa en gång vid inläsningen.

Rätt strategi beror på innehållet. Artiklar och wikier: styckebaserad eller hierarkisk. Kod: funktionsnivå. Konversationer: turbaserad. Teknisk dokumentation: strukturmedveten.

Metadata för textsegment. Varje textsegment bör innehålla:

• Källdokumentets ID och URL.
• Avsnittssökväg (kapitel > avsnitt > underavsnitt).
• Sidnummer (för källhänvisning).
• Rubriker ovanför textsegmentet (för kontext).
• Metadata på dokumentnivå (datum, författare, typ).

Dessa metadata möjliggör filtrering och källhänvisningar i det slutliga svaret.

Steg 3: Inbäddning

Konvertera textsegment till vektorer.

Val av inbäddningsmodell.

Tänkbara familjer är OpenAI:s inbäddningsmodeller, Voyage-inbäddningar, Cohere Embed samt BGE- och Nomic-modeller med öppna vikter. Namn, dimensioner, licenser, priser och stödda indatatyper förändras. Bygg din kandidatlista utifrån den aktuella guiden för OpenAI-inbäddningar, Voyages dokumentation, dokumentationen för Cohere Embed och modellkortet för varje modell med öppna vikter.

Så väljer du modell: testa den mot din domän. Utgå inte från att modellen som toppar en jämförelsetabell är bäst för dina data.

Inbäddningsdimension. Dimensionen påverkar kostnaden för lagring och index, men en längre vektor garanterar inte bättre hämtning. Vissa API:er stöder förkortning, andra modeller har en fast dimension. Jämför de dimensioner som stöds på samma märkta frågor och väg in indexstorlek och latens i beslutet.

Versionshantering. Inbäddningsmodeller uppdateras och du kan vilja byta. Planera för detta:

• Spåra vilken version av inbäddningsmodellen som skapade varje vektor.
• Bädda in allt på nytt vid migrering (eller använd en övergång med dubbla index).
• Blanda inte vektorer från olika modeller i samma sökning.

Kostnad. Räkna fram initial indexering och förändringsvolym utifrån uppmätta token, leverantörens datummärkta pris, andelen omförsök, beräkningskraft för parsning och OCR, vektorlagring, repliker och hur ofta du bäddar in på nytt. Spara källans URL och giltighetsdatum bredvid kalkylen – den här artikeln kopierar medvetet inte in ett pris som kommer att förändras.

Lagring. Vektorer är stora. 1 miljon textsegment × 1 536 dimensioner × 4 byte = 6 GB. Planera lagringen därefter.

Steg 4: Hämtning

Frågan kommer in. Du måste hitta relevanta textsegment.

Vektorsökning (tät hämtning). Bädda in frågan och hitta de närmaste grannarna. Fångar semantisk likhet. Standardmetoden.

Nyckelordssökning (BM25/lexikal). Traditionell textsökning. Fångar exakta matchningar, sällsynta termer och specifika namn. Kompletterar ofta vektorsökning.

Hybridsökning. Kör båda och slå samman resultaten. Reciprocal Rank Fusion (RRF) är standardmetoden för sammanslagning.

def reciprocal_rank_fusion(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: -x[1])

I praktiken slår hybridsökning enbart vektorsökning eller enbart nyckelordssökning i de flesta jämförelser. Använd den som standard.

Metadatafiltrering. Filtrera hämtningen efter metadata före poängsättningen. ”Endast dokument från 2025 och framåt.” ”Endast dokument som användaren har åtkomst till.” ”Endast dokument av typen policy.”

Detta är avgörande i system med flera klientorganisationer: varje fråga begränsas till de dokument som klientorganisationen har åtkomst till.

Frågeförståelse. Förbehandla frågan:

• Stavningskorrigering. ”engineerin” → ”engineering.”
• Expansion av akronymer. ”MFA” → ”Multi-Factor Authentication MFA.”
• Synonymer/frågeexpansion. Generera alternativa formuleringar och sök med var och en.
• Dekomposition. Dela upp frågor med flera delar i underfrågor och hämta separat för var och en.

Dessa förbehandlingssteg förbättrar hämtningen avsevärt för verkliga frågor.

HyDE (Hypothetical Document Embeddings). Generera ett påhittat ”idealsvar” med en LLM. Bädda in det. Använd resultatet som hämtningsfråga. Detta fungerar ofta bättre än att bädda in frågan direkt, eftersom det påhittade svaret liknar faktiska svarsdokument mer.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Skriv ett avsnitt som besvarar: " + query)
    embedding = embed(hypothetical)
    return vector_search(embedding, k=k)

Avvägning: ett extra LLM-anrop per fråga (latens, kostnad). Värt det för svåra frågor, överdimensionerat för enkla.

Hämtning med flera vektorer. Använd flera vektorer per textsegment i stället för en (exempelvis en för textsegmentet, en för en sammanfattning och en för hypotetiska frågor). Ökar lagringsbehovet och komplexiteten, men förbättrar hämtningen för vissa typer av innehåll.

Steg 5: Omrangordning

Efter den inledande hämtningen (topp-k, k=20–50) använder du en omrangordningsmodell för att poängsätta kandidaterna mer noggrant.

Varför omrangordna?

Den inledande hämtningen är snabb men inexakt. Vektorlikhet är ett grovt mått på relevans. En omrangordningsmodell (vanligen en korsenkodarmodell) läser frågan och varje kandidat tillsammans och ger ett mer exakt poängvärde.

Alternativ för omrangordning:

• Cohere Rerank. Branschstandard. Bra kvalitet, driftad tjänst.
• Voyage Rerank. Stark konkurrent.
• BGE Rerank-large. Öppen källkod, kostnadsfri att drifta själv.
• MiniLM-korsenkodare. Mindre och snabbare, lägre kvalitet.
• LLM-baserad omrangordning. Använd en liten LLM för att poängsätta par av fråga och kandidat. Högst kvalitet, högst kostnad.

Effekten.

Omrangordning kan förbättra kandidaternas ordning, men vinsten beror på förstastegshämtaren, kandidatdjupet, korpusen, frågefördelningen och mätvärdet. Behåll steget bara när en märkt utvärdering visar att kvalitetsvinsten motiverar dess latens och kostnad.

Typisk konfiguration:

• Hämta 30–50 kandidater med hybridsökning.
• Omrangordna till de 5–10 bästa.
• Skicka toppresultaten till LLM-modellen.

Adaptiv omrangordning.

Hoppa över omrangordningen när det översta inledande resultatet har hög vektorlikhet (en tydlig matchning). Omrangordna offensivt för frågor med närliggande poängvärden (flera kandidater ligger lika).

Steg 6: Generering

LLM-modellen producerar svaret med hjälp av den hämtade kontexten.

Promptstruktur:

Du är en assistent som besvarar frågor utifrån den angivna kontexten.

Kontext:
[Dokument 1 - titel, URL]
[innehåll i textsegment 1]
[Dokument 2 - titel, URL]
[innehåll i textsegment 2]
...

Användarens fråga: {query}

Instruktioner:
- Svara enbart utifrån den angivna kontexten.
- Säg det om kontexten inte innehåller svaret. Hitta inte på information.
- Hänvisa till källor med notationen [Källa N].
- Var kortfattad men fullständig.

Promptmönstren som spelar roll:

• Källtaggning. Varje kontextsegment märks med sin källa för källhänvisning.
• Instruktioner om förankring. Säg uttryckligen åt modellen att endast använda kontexten.
• Krav på källhänvisning. Kräv källhänvisningar. Det fångar hallucinationer.
• Reservinstruktion. ”Säg det om kontexten inte innehåller svaret.” Förhindrar konfabulering.

Hantering av källhänvisningar.

Ett vanligt mönster är att inkludera källänkar i svaret. Användargränssnittet renderar dem som klickbara länkar.

"Företagets policy för distansarbete tillåter hemarbete upp till fyra dagar i veckan [1].
[1]: https://docs.example.invalid/policies/remote-work"

Detta gör källans placering synlig. Det bevisar inte att källan är aktuell, behörig eller rätt tolkad – applikationen bör öppna en verklig käll-URL som den aktuella användaren har rätt att se. Domänen .invalid ovan är medvetet exempeldata som inte går att slå upp.

Hantering av kontextstorlek.

Långa kontexter försämrar kvaliteten. De flesta modeller fungerar bäst med fokuserade kontexter (5–10 mycket relevanta textsegment) i stället för att allt dumpas in. Kvaliteten sjunker när kontexten sväller.

Om du måste ta med mycket kontext bör du sammanfatta mindre relevanta delar i stället för att inkludera dem i sin helhet.

Utvärdering i varje steg

Du kan inte optimera det du inte mäter. Varje steg behöver sina egna utvärderingar.

Utvärdering av inläsning. Parsades dokumenten korrekt? Ta stickprov på dokument och kontrollera att centralt innehåll har bevarats.

Utvärdering av segmentering. Har textsegmenten rätt storlek? Bevarar de kontexten? Bryts de vid rimliga gränser?

Utvärdering av inbäddning. Bäddas likartade begrepp in på likartade sätt? Motsvarar cosinuslikheten för en testuppsättning med par som man vet är lika respektive olika det förväntade utfallet?

Utvärdering av hämtning. Finns de relevanta textsegmenten bland de K högst rankade för en given fråga? Vanligt mätvärde: recall@K (hur stor andel av frågorna har minst ett relevant textsegment bland de K högst rankade).

Utvärdering av omrangordning. Placerar omrangordningsmodellen det mest relevanta resultatet först bland de hämtade kandidaterna? Mätvärde: NDCG (normalized discounted cumulative gain) eller MRR (mean reciprocal rank).

Utvärdering av generering. Producerar LLM-modellen ett korrekt svar utifrån kontexten och frågan? Mätvärden: trohet (använder svaret kontexten?), korrekthet (är svaret rätt?), hjälpsamhet (motsvarar det användarens avsikt?).

Utvärdering från början till slut. Producerar systemet rätt svar på en verklig fråga? Detta är viktigast och beror på alla steg.

Du behöver testuppsättningar för vart och ett. Ett vanligt sätt att komma igång:

• Skapa 50–100 frågor med kända, korrekta svar.
• Identifiera för varje fråga vilket eller vilka dokument som innehåller svaret.
• Använd detta för att utvärdera hämtningen (hämtas rätt dokument?) och genereringen (är svaret rätt?).

Verktyg: Ragas, TruLens, egna testsviter. Det exakta verktyget spelar mindre roll än att utvärderingarna faktiskt körs.

Operativa aspekter

Några realiteter i produktion:

Indexeringspipelines. Nya dokument tillkommer. Bädda in på nytt. Uppdatera index. Hantera borttagningar och uppdateringar. Denna pipeline körs kontinuerligt, inte bara vid konfigurationen. Bygg den som ett system, inte som ett engångsskript.

Latens.

Mät frågeinbäddning, kandidathämtning, omrangordning, genereringens tid till första token och till färdigt svar samt nätverksomkostnaden var för sig. Redovisa kalla och varma fördelningar vid den avsedda samtidigheten – komponenternas namn säger ingenting om ett latensintervall.

Optimering:

• Cachelagra inbäddningar för vanliga frågor.
• Cachelagra omrangordning för återkommande par av fråga och kandidat.
• Strömma genereringen.
• Parallellisera där det är möjligt.

Har produkten ett latensmål ska du fördela en uppmätt budget över frågebearbetning, hämtning, omrangordning, generering och nätverksomkostnad. Beteende ”under två sekunder” går inte att härleda ur komponenternas etiketter – testa både kalla och varma vägar vid förväntad samtidighet.

Kostnad.

Fördela, för varje utvärderad fråga, kostnaden för frågeinbäddning, hämtnings- och indexkapacitet, omrangordning, genererade och inmatade token, cachetillstånd och omförsök. Aggregera sedan den observerade fördelningen – inte ett enda medelvärde – vid prognostiserad trafik. En miljon frågor kan kosta radikalt olika beroende på dokumentstorlek, antal kandidater, modell, svarslängd, cachebeteende och infrastrukturåtaganden.

Kostnadsoptimering:

• Cachelagring.
• Använd billigare modeller där kvaliteten tillåter.
• Komprimera kontexten (sammanfattningar i stället för fullständiga textsegment).

Uppdateringar. Dokument förändras. Mönster:

• Versionshantering: varje dokument har en version; gamla versioner behålls eller tas bort enligt policy.
• Inkrementell: nya versioner delas upp och bäddas in på nytt; gamla textsegment tas bort.
• Differensmedveten: endast ändrade avsnitt behandlas på nytt.

Detta har stor betydelse i scenarier med många uppdateringar.

Behörigheter. RAG över privata data: dokument har åtkomstkontroller och hämtningen måste respektera dem.

• Metadatabaserad filtrering (varje textsegment har metadata om vilka som har åtkomst).
• Klientorganisationsisolerade index för strikt isolering.
• Revisionsloggning av vem som fick åtkomst till vad.

Lita inte på att LLM-modellen upprätthåller behörigheter. Genomdriv dem vid hämtningen.

Vanliga fellägen

Några mönster vi ser i RAG-system som misslyckas:

Fel 1: Dålig segmentering. Textsegment bryts mitt i ett resonemang, tabeller delas mellan textsegment och rubriker skiljs från sitt innehåll. Åtgärd: en bättre segmenteringsstrategi.

Fel 2: Hämtningen missar svaret. Det relevanta textsegmentet finns men hämtas inte. Orsaken är ofta att frågan och dokumentet inte matchar. Åtgärd: HyDE, frågeexpansion, bättre inbäddningar.

Fel 3: Rätt textsegment, fel ordning. Det relevanta textsegmentet hämtas men rankas lågt. LLM-modellen använder högre rankade irrelevanta segment. Åtgärd: omrangordning.

Fel 4: Rätt textsegment, hallucination. Textsegmenten är rätt, men LLM-modellen hittar på ytterligare information. Åtgärd: striktare förankringsprompt, krav på källhänvisningar, lägre temperatur.

Fel 5: Rätt textsegment, fel svar. Textsegmenten innehåller svaret, men LLM-modellen extraherar fel del. Åtgärd: bättre genereringsprompt, eventuellt en större modell.

Fel 6: Inaktuella data. Indexet har inte uppdaterats. Åtgärd: kontinuerlig inläsningspipeline.

Fel 7: Behörighetsläckor. Användare ser textsegment som de inte borde se. Åtgärd: genomdriv filtrering vid hämtningen och granska åtkomsten.

Fel 8: Skenande kostnader. Latens och kostnad ökade när korpusen och trafiken växte. Åtgärd: cachelagring, modellstyrning, eventuellt arkitekturändringar.

En modellerad design: RAG för företagets kunskapsbas

Det här är ett konfigurationsunderlag – inte ett driftsatt AIExpert-resultat och inte ett påstående om hur ett typiskt företag ser ut. Varje antal, produkt, tidsintervall och kandidatdjup nedan är en illustrativ hypotes som du ska ersätta med uppmätta värden.

Korpus: cirka 50 000 dokument (wikisidor, policyer, runbooks, mötesanteckningar, Slack-trådar).

Arbetsflöde:

1. Inläsning:

   • Notion: API-export.
   • Slack: arkivexport, filtrerad till relevanta kanaler.
   • Google Drive: API-export av godkända mappar.
   • Rensning: ta bort meddelanden som endast består av emojier och standardiserade signaturer.

2. Segmentering:

   • Hierarkisk: små textsegment på styckenivå, överordnade textsegment på avsnittsnivå.
   • Cirka 250 000 textsegment totalt på den lilla nivån.
   • Metadata: källa, avsnittssökväg, last_updated och accessible_to.

3. Inbäddning:

   • Voyage-3-inbäddningar, 1024 dimensioner.
   • Lagrade i Pinecone (hanterad tjänst).
   • Ändrade dokument bäddas in på nytt varje vecka.

4. Hämtning:

   • Hybrid: vektorsökning + BM25 (via Pinecones hybridfunktion).
   • HyDE för frågan.
   • Metadatafilter för åtkomst.
   • De 30 högst rankade hämtas.

5. Omrangordning:

   • Cohere Rerank.
   • Topp 30 → topp 8.

6. Generering:

   • Claude Sonnet 5.
   • De 8 högst rankade överordnade textsegmenten (inte de små segmenten) anges som kontext.
   • Källhänvisning krävs i svaret.

Utvärderingsplan (sätt tröskelvärdena utifrån verksamhetens felbudget):

• 100 handskrivna fråge- och svarspar.
• Hämtningens recall vid valt kandidatdjup, redovisat per frågesegment. Bestäm det krävda värdet innan du börjar trimma.
• Slutsvarets korrekthet och hämtningens recall: redovisa båda och granska gapet mellan dem utan att på förhand anta vilket som är lägst.
• Trohet (inga hallucinationer): följ separat från korrektheten.

Illustrativ driftkadens (härled den verkliga kadensen ur källornas förändringstakt och risk):

• Daglig inkrementell inläsning.
• Fullständig ny inbäddning varje vecka för ändrade dokument.
• Observerbarhet per fråga.
• Månatlig omkörning av utvärderingen och trendövervakning.
• Kvartalsvis granskning av frågeloggen för att hitta nya felmönster.

Kostnadsmodell (fyll i med datummärkta fakturor eller aktuella offerter):

• Inläsning: ändrade token × inbäddningspris, plus beräkningskraft för parsning och OCR.
• Lagring för hämtning: indexerade byte, repliker, säkerhetskopior och kapacitet för frågor, antingen reserverad eller förbrukningsbaserad.
• Per fråga: inbäddning + hämtning + omrangordning + modellens in- och utdata + nätverks- och verktygsavgifter.
• Drift: ingenjörstid, märkning för utvärdering, incidenthantering och underhåll av datakällorna.

Godkänn utgiften först när det uppmätta uppgiftsresultatet och det arbete som undviks motiverar hela kostnadsmodellen. Hämtningspoäng ensamma visar ingen avkastning.

En stegvis grindad plan för att bygga ut RAG

Om du börjar från noll:

Steg 1: avgränsad prototyp.

• Identifiera korpusen och det primära användningsfallet.
• Bygg grundläggande inläsning (en källa).
• Grundläggande segmentering (fast storlek med överlappning).
• Standardmodell för inbäddning.
• Endast vektorsökning (ingen omrangordning).
• Enkel genereringsprompt.

Steg 2: belägg för kvaliteten.

• Bygg en märkt utvärderingsmängd som är stor nog att bevara viktiga fråge- och risksegment.
• Identifiera fellägen.
• Lägg till omrangordning.
• Lägg till hybridsökning.
• Förbättra segmenteringen.

Steg 3: operativt godkännande.

• Kontinuerlig inläsningspipeline.
• Observerbarhet.
• Automatisering av utvärdering.
• Behörighet/autentisering.
• Kostnadsövervakning.

Koppla ingen kalenderutfästelse till de här stegen. Gå vidare först när det aktuella stegets tester går igenom: källtrohet och behörigheter först, sedan hämtnings- och svarskvalitet, därefter säkerhet, färskhet, radering, kapacitet, återställning och operativt ägarskap.

Kvaliteten finns i varje steg

Produktionsklar RAG är en pipeline i sex steg med kvalitetsaspekter i varje steg. Mönstren som skiljer fungerande system från system som gör användarna besvikna:

• Inläsning: grundlig parsning, bevarad struktur, insamling av metadata.
• Segmentering: lämplig strategi för innehållstypen, ofta hierarkisk.
• Inbäddning: kvalitetsmodell, versionshantering, planering för migrering.
• Hämtning: jämför lexikal, tät och hybrid hämtning, filter och frågeomskrivning på den märkta mängden.
• Omrangordning: lägg bara till steget när den uppmätta kvalitetsvinsten motiverar latens, kostnad och komplexitet.
• Generering: förankring, källhänvisningar, reservbeteende för okända uppgifter.
• Utvärdering: kontinuerligt i varje steg.

Vilka kontroller som krävs beror på arbetslasten och risken, men varje steg du utelämnar behöver ett uttalat skäl och ett kompenserande test. Påståenden du publicerar eller driftsätter bör redovisa den utvärderade korpusen, frågesegmenten, mätvärdena, felfallen, behörighetsmodellen och datumet – inte en ostödd andel lyckade svar eller en leveranstid.