Tootmis-RAG-i ehitamine: sissevõtt, embeddingud, otsing, ümberreastamine, eval

Kui sa oled lihtsa RAG süsteemi shippinud, tead mustrit: tükelda dokumendid, embedi need, salvesta vektorandmebaasis, otsi päringule top-k, suru promptisse. Demodes töötab. Tootmises tihti pettumus.

Lõhe demo-RAG-i ja tootmis-RAG-i vahel on suur. Reaalsed dokumendid on sasipundard. Reaalsed päringud on mitmeti mõistetavad. Kvaliteet kõigub päringu-tüüpide lõikes meeletult. Kulu ja latentsus on päris piirangud. Värskendused ja versioonimine loevad.

See artikkel käsitleb, kuidas näeb välja tootmiskõlblik RAG-konveier — kuus etappi, mustrid igal etapil ja hindamisdistsipliin, mis eristab töötavad süsteemid pettumust valmistavatest.

Konveier

Tootmis-RAG-süsteemil on kuus loogilist etappi:

[Documents]
    ↓
1. Ingestion (parsing, cleaning, metadata extraction)
    ↓
2. Chunking (splitting into retrieval units)
    ↓
3. Embedding (vectors + storage)
    ↓
[Query]
    ↓
4. Retrieval (semantic + lexical + filters)
    ↓
5. Reranking (top-k → top-N)
    ↓
6. Generation (LLM + context)
    ↓
[Response]

Igal etapil on oma kvaliteediprobleemid. Ühe parandamine parandab tervikut.

Käime iga läbi.

Etapp 1: Sissevõtt

Prügi sisse, prügi välja. Sinu sissevõtu kvaliteet määrab kõige järgneva lae.

Allikatüübid, mida kohtad:

• PDF-id (enamasti halvim).
• Word-dokumendid.
• HTML-lehed.
• Markdown.
• Tabelarvutused.
• Slaidid (PowerPoint, Google Slides).
• E-kirjad.
• Kood.
• Struktureeritud andmed (CSV-d, JSON).

Igal on oma parsimise väljakutsed.

PDF-i parsimine. PDF on esitusvorming, mitte andmevorming. Neid on kurikuulsalt raske parsida. Strateegiad:

• Tekstipõhised PDF-id: pdfplumber, pymupdf, unstructured. Töötab puhta teksti puhul.
• Skannitud PDF-id: OCR Tesseractiga, Google Cloud Vision või AWS Textract.
• Paigutusteadlikud: LayoutLM, Mathpix või LLM-põhine parsimine (GPT-4 vision) keeruliste paigutuste jaoks (tabelid, mitmeveerulised).

Tänapäevane lähenemine raskete PDF-ide jaoks: kasuta visiooni-võimekat LLM-i, et sisu OCR-ida ja struktureerida. Kulu on kõrgem, aga kvaliteet on traditsioonilisest OCR-ist dramaatiliselt parem.

Tabelite käsitlemine. Tabelid struktureerimata tekstis on valus. Kas:

• Konverdi markdown-tabeliteks (säilitab struktuuri).
• Linearise proosaks ("Rida 1: kliendil A oli 50 tellimust...").
• Käsitle eraldi otsitavate ühikutena struktureeritud skeemiga.

Õige valik sõltub sellest, milliseid päringuid saad.

Metaandmete eraldamine. Igal dokumendil on metaandmed, mis loevad:

• Pealkiri, autor, kuupäev, versioon.
• Teema, kategooria, sildid.
• Allika URL või asukoht.
• Õigused / nähtavus.

Püüa need sissevõtul. Neist saavad filtri-parameetrid otsingu ajal.

Puhastamine. Eemalda klišee:

• Päised/jalused, mis kordevad igal leheküljel.
• Navigatsioon, reklaamid, küpsisteribad.
• "Sisukord" lehed.
• Tühjad või dubleeritud lõigud.

Puhas korpus otsib paremini. Klišee põhjustab valesid vasteid.

Kvaliteedikontrollid.

• Kas parser eraldas päriselt teksti? (Mõned PDF-id tagastavad tühjad stringid.)
• Kas on kodeerimisprobleeme?
• Kas tabelid on säilinud?
• Kas joonised on pildiallkirjadega või vahele jäetud?

Ehita mõistlikkuse kontrollid sissevõtukonveierisse. Püüa katkised parsingud, enne kui need indeksit reostavad.

Etapp 2: Tükeldamine

Sul on puhtad dokumendid. Nüüd jagad need otsinguühikuteks (tükkideks).

Põhiline vahetus:

• Väikesed tükid: täpne otsing (fokuseeritud küsimusele), aga puudub kontekst.
• Suured tükid: rohkem konteksti, aga vähem täpne (asjakohane osa on maetud).

Mõlemad äärmused kaotavad kvaliteeti. Kuldne kesktee varieerub sisutüübi järgi.

Levinud strateegiad:

Fikseeritud suurusega tükid kattuvusega. Jaga N-tokeniliste tükkidena (300–800 tokenit) 50–100 tokeni kattuvusega. Lihtne, töötab algjoonena.

Lauseteadlik tükeldamine. Jaga lausepiiridel (nltk, spaCy vms abil). Väldib lause keskel lõikamist.

Lõigupõhine. Iga lõik on tükk. Töötab hästi struktureeritud lõikudega dokumentide puhul.

Hierarhiline (väike + suur). Kaks indeksit:

• Väikesed tükid (300 tokenit) täpseks otsinguks.
• Suured tükid (1500 tokenit) või terved sektsioonid konteksti jaoks. Otsimisel leia väikene; serveeri LLM-ile suur vanem-tükk.

Dokumendistruktuuri teadlik. Kasuta dokumendi struktuuri (pealkirjad, sektsioonid) tükkide jaoks. Iga sektsioon on tükk, hierarhia säilinud.

Semantiline tükeldamine. Kasuta embeddinguid loomulike murdumiskohtade leidmiseks (kus teema vahetub). Kallim, aga toodab mõne sisu jaoks paremaid tükke.

LLM-põhine kokkuvõtte tükeldamine. Pikad dokumendid kokku võetakse hierarhilisteks tükkideks mitmel tasandil (lõigukokkuvõte, sektsioonikokkuvõte, dokumendikokkuvõte). LLM genereerib need ühe korra sissevõtul.

Õige strateegia sõltub sisust. Artiklid ja wiki: lõik või hierarhiline. Kood: funktsioonitasand. Vestlused: kõnekorra-põhine. Tehniline dokumentatsioon: struktuuriteadlik.

Tüki metaandmed. Iga tükk peaks kandma:

• Lähtedokumendi ID ja URL.
• Sektsiooni teekonna (peatükk > sektsioon > alasektsioon).
• Leheküljenumbri (viitamiseks).
• Pealkirjad selle tüki kohal (konteksti jaoks).
• Dokumenditasandi metaandmed (kuupäev, autor, tüüp).

See metaandmed võimaldab filtreerimist ja viitamist lõppvastuses.

Etapp 3: Embedding

Konverdi tükid vektoriteks.

Embedding-mudeli valik.

1. aastal:

• OpenAI text-embedding-3-large: tugev mitmekülgne, kallis.
• Voyage Voyage-3: konkurentsivõimeline, sageli parem tehnilisel sisul.
• Cohere embed-v4: tugev mitmekeelne.
• BAAI bge-large: tugev avatud lähtekoodiga.
• Nomic embed-text: hea avatud lähtekoodiga, tasuta enda peal majutada.
• Domeenispetsiifilised mudelid: koodile (Voyage Code, OpenAI text-embedding-3-large töötab ka koodile), juriidilisele, meditsiinilisele jne.

Mudeli valimine: testi oma domeenis. Ära eelda, et edetabeli võitja on sinu andmete jaoks parim.

Embedding-dimensioon. Mudelid pakuvad 256–3072 dimensiooni. Kõrgem dimensioon = parem kvaliteet, kõrgem kulu/salvestus. Enamiku kasutusjuhtude jaoks on 768–1536 kuldne kesktee.

Versioonimine. Embedding-mudelid uuenevad; võid soovida vahetada. Planeeri seda:

• Jälgi, milline embedding-mudeli versioon iga vektori tootis.
• Embedi kõik uuesti migreerimisel (või kasuta topelt-indeksiga üleminekut).
• Ära sega erinevatest mudelitest vektoreid samas otsingus.

Kulu. Miljonite tükkide embedimine maksab raha. €0,10–€0,50 miljoni tokeni kohta (sõltub pakkujast). Suurte korpuste jaoks tee arvutus ette ära.

Salvestus. Vektorid on suured. 1M tükki × 1536 dimensiooni × 4 baiti = 6 GB. Planeeri salvestust vastavalt.

Etapp 4: Otsing

Päring tuleb sisse. Pead leidma asjakohaseid tükke.

Vektorotsing (tihe otsing). Embedi päring, leia lähimad naabrid. Püüab semantilist sarnasust. Standard.

Märksõnaotsing (BM25 / leksikaalne). Traditsiooniline tekstiotsing. Püüab täpseid vasteid, haruldasi termineid, konkreetseid nimesid. Sageli täiendab vektorotsingut.

Hübriidotsing. Jooksuta mõlemad, ühenda tulemused. Reciprocal Rank Fusion (RRF) on standardne ühendamisviis.

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])

Praktikas lööb hübriid enamikus võrdlustestides ainult-vektori või ainult-märksõna. Kasuta seda vaikimisi.

Metaandmete filtreerimine. Filtreeri otsingut metaandmete järgi enne skoorimist. "Ainult 2025+ dokumendid." "Ainult kasutaja kättesaadavas komplektis dokumendid." "Ainult tüüpi policy dokumendid."

Kriitiline mitme-rentniku-süsteemides: iga päring on rentniku kättesaadavate dokumentideni ulatuv.

Päringu mõistmine. Eeltöötle päringut:

• Õigekirjaparandus. "engineerin" → "engineering."
• Akronüümide laiendamine. "MFA" → "Multi-Factor Authentication MFA."
• Sünonüümid / päringu laiendamine. Genereeri alternatiivseid sõnastusi; otsi igaühega.
• Lammutamine. Mitmeosalised küsimused jagatakse alapäringuteks, igaüks otsitakse eraldi.

Need eeltöötluse sammud parandavad oluliselt otsingut päris päringutel.

HyDE (Hypothetical Document Embeddings). Genereeri LLM-iga fiktiivne "ideaalne vastus". Embedi see. Kasuta tulemust otsingupäringuna. Töötab sageli paremini kui küsimuse otse embedimine, sest fiktiivne vastus on sarnasem päris vastusedokumentidele.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Write a passage answering: " + query)
    embedding = embed(hypothetical)
    return vector_search(embedding, k=k)

Vahetus: täiendav LLM-kõne päringu kohta (latentsus, kulu). Tasub raskete päringute jaoks; lihtsate jaoks ülemäärane.

Mitme-vektoriga otsing. Ühe vektori asemel tüki kohta mitu (nt üks tükile, üks kokkuvõttele, üks hüpoteetilistele küsimustele). Lisab salvestust ja keerukust, aga parandab otsingut osa sisu puhul.

Etapp 5: Ümberreastamine

Pärast esialgset otsingut (top-k, k=20–50) kasuta ümberreastajat (reranker), et kandidaate hoolikamalt skoorida.

Miks ümber reastada?

Esialgne otsing on kiire, aga ebatäpne. Vektorisarnasus on lokaarne relevantsuse näidik. Ümberreastaja (tüüpiliselt cross-encoder mudel) loeb päringut ja iga kandidaati koos, tootes täpsema skoori.

Ümberreastaja valikud:

• Cohere Rerank. Tööstuse standard. Hea kvaliteet, majutatud.
• Voyage Rerank. Tugev konkurent.
• BGE Rerank-large. Avatud lähtekoodiga, tasuta enda peal majutada.
• MiniLM cross-encoderid. Väiksemad, kiiremad, madalama kvaliteediga.
• LLM-põhine ümberreastamine. Kasuta väikest LLM-i, et skoorida päring-kandidaadi paare. Kõrgeim kvaliteet, kõrgeim kulu.

Mõju.

Meie kogemuses parandab ümberreastamise lisamine lõppülesande kvaliteeti enamikus RAG süsteemides 10–20%. Latentsus ja kulu on selle peaaegu alati seda väärt.

Tüüpiline ülesseadmine:

• Otsi 30–50 kandidaati hübriidotsinguga.
• Reasta ümber top 5–10-ni.
• Anna parimad tulemused LLM-ile.

Adaptiivne ümberreastamine.

Päringutele, kus esialgse top tulemuse vektorisarnasus on kõrge (selge vaste), jäta ümberreastamine vahele. Päringutele, kus skoorid on lähedased (mitu kandidaati viigis), reasta agressiivselt ümber.

Etapp 6: Genereerimine

LLM toodab vastuse leitud konteksti abil.

Prompti struktuur:

You are an assistant answering questions based on the provided context.

Context:
[Document 1 - title, URL]
[chunk 1 content]
[Document 2 - title, URL]
[chunk 2 content]
...

User question: {query}

Instructions:
- Answer based only on the provided context.
- If the context doesn't contain the answer, say so. Don't make up information.
- Cite sources using [Source N] notation.
- Be concise but complete.

Olulisemad prompti mustrid:

• Allikamärgistus. Iga konteksti-tükk on märgistatud allikaga viitamiseks.
• Maandamise juhised. Käsi mudelil selgesõnaliselt kasutada ainult konteksti.
• Viitamisnõue. Sunni viitama. Püüab hallutsinatsioone.
• Tagavaravariandi juhis. "Kui kontekstis vastust pole, ütle seda." Hoiab konfabulatsiooni ära.

Viitamise käsitlemine.

Levinud muster: lisa allikalingid vastusesse. UI renderdab need klikitavatena.

"The company's remote work policy allows up to 4 days/week from home [1].
[1]: https://wiki.company.com/policies/remote-work"

See muudab vastuse kontrollitavaks. Kasutajad usaldavad maandatud vastuseid rohkem.

Konteksti suuruse haldamine.

Pikad kontekstid halvenevad. Enamik mudeleid töötab kõige paremini fokuseeritud kontekstidega (5–10 väga asjakohast tükki), mitte kõike kuhjates. Kvaliteet langeb konteksti paisumisega.

Kui pead palju konteksti lisama, tee vähem-asjakohastest kokkuvõtted, mitte ära lisa neid tervikuna.

Eval igal etapil

Sa ei saa optimeerida, mida sa ei mõõda. Iga etapp vajab oma evale.

Sissevõtu eval. Kas dokumendid parsiti õigesti? Sämpli dokumente; kontrolli, et võtmesisu on säilinud.

Tükeldamise eval. Kas tükid on õige suurusega? Kas need säilitavad konteksti? Kas need lõikuvad mõistlikel piiridel?

Embeddingute eval. Kas sarnaseid mõisteid embeditakse sarnaselt? Tuntud-sarnaste ja tuntud-erinevate paaride testkomplektil — kas koosinussarnasus vastab ootustele?

Otsingu eval. Päringu jaoks, kas asjakohased tükid on top-K-s? Levinud mõõdik: recall@K (mitu % päringutest on top K-s vähemalt üks asjakohane tükk).

Ümberreastamise eval. Leitud kandidaatidele, kas ümberreastaja paneb kõige asjakohasema esimeseks? Mõõdik: NDCG (normalized discounted cumulative gain) või MRR (mean reciprocal rank).

Genereerimise eval. Konteksti ja päringu jaoks, kas LLM toodab õige vastuse? Mõõdikud: ustavus (kas vastus kasutab konteksti?), õigsus (kas vastus on õige?), abivalmidus (kas see vastab kasutaja kavatsusele?).

Otsast-otsani eval. Päris päringu jaoks, kas süsteem toodab õige vastuse? Olulisim; sõltub kõigist etappidest.

Sa vajad testkomplekte igaühele. Tavaline alustamine:

• Ehita 50–100 päringut tuntud-heade vastustega.
• Iga päringu jaoks tuvasta, milline dokument/dokumendid sisaldavad vastust.
• Kasuta seda otsingu hindamiseks (kas leiame õiged dokumendid?) ja genereerimiseks (kas vastus on õige?).

Tööriistad: Ragas, TruLens, kohandatud komplektid. Täpne tööriist loeb vähem kui evalide jooksutamine.

Operatiivsed mured

Paar tootmisreaalsust:

Indekseerimiskonveierid. Uued dokumendid saabuvad. Embedi uuesti. Värskenda indekseid. Käsitle kustutamisi ja värskendusi. See konveier jookseb pidevalt, mitte ainult ülesseadmise ajal. Ehita see süsteemina, mitte ühekordse skriptina.

Latentsus.

Tüüpiline jaotus:

• Embedding (päring): 50–200 ms.
• Vektorotsing: 50–200 ms.
• Ümberreastamine: 200–500 ms (sõltub K-st).
• Genereerimine: 1–5 s (sõltub kontekstist ja mudelist).
• Kokku: 1,5–6 s.

Optimeerimine:

• Vahemällu sagedaste päringute embeddingud.
• Vahemällu ümberreastamine korduvatele päring-kandidaadi paaridele.
• Vooga edasta genereerimist.
• Parallelliseeri kus võimalik.

Alla 2 s latentsuse jaoks vajad tavaliselt kiiret embedding-mudelit, kiiret vektorandmebaasi ja kas kiiret ümberreastajat või vahemällu salvestatud/lihtsate päringute puhul ümberreastamise vahelejätmist.

Kulu.

Päringu-kulu:

• Embedding: ~€0,0001.
• Vektorotsing: ~€0,0001 (infrastruktuurist sõltuv).
• Ümberreastamine: €0,001–0,01 (mudelist sõltuv).
• Genereerimine: €0,005–0,05 (mudel + kontekst-sõltuv).
• Kokku: ~€0,01–0,05 päringu kohta.

Skaalal koguneb see. Miljon päringut = €10K–50K.

Kulu optimeerimine:

• Vahemälu.
• Kasuta odavamaid mudeleid, kus kvaliteet lubab.
• Kompressi konteksti (kokkuvõtted vs täistükid).

Värskendused. Dokumendid muutuvad. Mustrid:

• Versioonimine: igal dokumendil on versioon; vanad versioonid hoitakse alles või kustutatakse poliisi alusel.
• Inkrementaalne: uued versioonid tükeldatakse ja embeditakse uuesti; vanad tükid kustutatakse.
• Diff-teadlik: ainult muutunud sektsioone töödeldakse uuesti.

Kõrge-värskenduse-sageduse stsenaariumides on see oluline.

Õigused. RAG era-andmete üle: dokumentidel on juurdepääsukontrollid; otsing peab neid austama.

• Metaandmete-põhine filtreerimine (igal tükil on kättesaadav-kelle metaandmed).
• Rentnikuga-isoleeritud indeksid kõva isolatsiooni jaoks.
• Audit-logimine, kes mida pääses.

Ära usalda LLM-i õigusi jõustama. Jõusta otsingul.

Levinud ebaõnnestumise mustrid

Mõned mustrid, mida me näeme ebaõnnestuvates RAG süsteemides:

Ebaõnnestumine 1: Halb tükeldamine. Tükid lõikuvad mõtte keskel, tabel katki üle tükkide, pealkirjad eraldatud sisust. Parandus: parem tükeldamise strateegia.

Ebaõnnestumine 2: Otsing ei leia vastust. Asjakohane tükk eksisteerib, aga ei leita. Sageli päring/dokumendi sobimatus. Parandus: HyDE, päringu laiendamine, paremad embeddingud.

Ebaõnnestumine 3: Õiged tükid, vale järjekord. Asjakohane tükk leitakse, aga reastatakse madalalt. LLM kasutab kõrgemalt reastatud ebaolulisi tükke. Parandus: ümberreastamine.

Ebaõnnestumine 4: Õiged tükid, hallutsinatsioon. Tükid on õiged, aga LLM mõtleb juurde lisainfot. Parandus: rangem maandamise prompt, viitamisnõuded, madalam temperatuur.

Ebaõnnestumine 5: Õiged tükid, vale vastus. Tükid sisaldavad vastust, aga LLM eraldab vale osa. Parandus: parem genereerimisprompt, võimalik et suurem mudel.

Ebaõnnestumine 6: Vananenud andmed. Indeksit pole värskendatud. Parandus: pidev sissevõtukonveier.

Ebaõnnestumine 7: Õiguste lekked. Kasutajad näevad tükke, mida ei tohiks. Parandus: jõusta filtreerimine otsingul; auditi.

Ebaõnnestumine 8: Kulu spiraal. Latentsus ja kulu kasvasid koos korpuse ja liiklusega. Parandus: vahemällu salvestamine, mudeli marsruutimine, võimalik et arhitektuuri muudatused.

Töötatud näide: ettevõtte teadmusbaasi RAG

Et see konkreetseks teha: tüüpiline ettevõtte-teadmusbaasi RAG-süsteem.

Korpus: ~50 000 dokumenti (wiki-lehed, poliisid, runbookid, koosolekumärkmed, Slacki lõimed).

Konveier:

1. Sissevõtt: - Notion: API eksport. - Slack: arhiivieksport, filtreeritud asjakohastele kanalitele. - Google Drive: API eksport kinnitatud kaustadest. - Puhastamine: eemalda ainult-emoji teated, klišee allkirjad.

1. Tükeldamine: - Hierarhiline: lõigu-tasandi väikesed tükid, sektsiooni-tasandi vanem-tükid. - ~250K tükki kokku väikesel tasandil. - Metaandmed: allikas, sektsiooni teekond, last_updated, accessible_to.

1. Embedding: - Voyage-3 embeddingud, 1024 dimensiooni. - Salvestatud Pinecone'is (majutatud). - Uuesti embeditud iganädalaselt muutunud dokumentidele.

1. Otsing: - Hübriid: vektorotsing + BM25 (Pinecone'i hübriidi kaudu). - HyDE päringule. - Metaandmete filter kättesaadavuse jaoks. - Top 30 leitakse.

1. Ümberreastamine: - Cohere Rerank. - Top 30 → top 8.

1. Genereerimine: - Claude 4 Sonnet. - Top 8 vanem-tükki (mitte väikesed tükid) antakse kontekstina. - Viitamine vastuses nõutud.

Eval:

• 100 käsitsi koostatud päring/vastuse paari.
• Otsingu recall@30: ~92%.
• Lõppvastuse õigsus: ~85%.
• Ustavus (pole hallutsinatsiooni): ~95%.

Operatsioonid:

• Igapäevane inkrementaalne sissevõtt.
• Iganädalane täielik uuesti-embedimine muutunud dokumentidele.
• Päringupõhine seire.
• Igakuine evali kordusjooks; trendi monitooring.
• Kvartaalne päringulogi ülevaade uute läbikukkumismustrite leidmiseks.

Kulud:

• Embedding: ~€500/kuus (stabiilses olekus).
• Vektor-DB majutus: ~€800/kuus (Pinecone).
• Otsing + genereerimine päringu kohta: ~€0,02.
• Kokku: ~€2 500/kuus + €0,02 × päringute maht.

Enamiku ettevõtete jaoks on see tööviljakuse tõusust täielikult õigustatud.

90-päevane RAG-i ülesehituse plaan

Kui alustad nullist:

Päevad 1–30: MVP.

• Tuvasta korpus ja peamine kasutusjuht.
• Ehita lihtne sissevõtt (üks allikas).
• Lihtne tükeldamine (fikseeritud suurusega kattuvusega).
• Standardne embedding-mudel.
• Ainult vektorotsing (pole ümberreastamist).
• Lihtne genereerimisprompt.

Päevad 31–60: Kvaliteet.

• Koosta käsitsi evali-komplekt (50–100 päringut).
• Tuvasta läbikukkumismustrid.
• Lisa ümberreastamine.
• Lisa hübriidotsing.
• Paranda tükeldamist.

Päevad 61–90: Operatsioonid.

• Pidev sissevõtukonveier.
• Seire.
• Eval-automatiseerimine.
• Õigused/autentimine.
• Kulude monitooring.

90 päeva pärast on sul süsteem, mis pole lihtsalt demoeeritav, vaid päriselt kasutatav. Päris kasutajad saavad sellele loota.

Kokkuvõte

Tootmis-RAG on kuue-etapiline konveier kvaliteedimuredega igal etapil. Mustrid, mis eristavad töötavaid süsteeme pettumust valmistavatest:

• Sissevõtt: põhjalik parsimine, struktuuri säilitamine, metaandmete püüdmine.
• Tükeldamine: sisutüübile sobiv strateegia, sageli hierarhiline.
• Embedding: kvaliteetne mudel, versioonimine, migratsiooni planeerimine.
• Otsing: hübriid vaikimisi, päringu mõistmine, metaandmete filtreerimine.
• Ümberreastamine: peaaegu alati seda väärt.
• Genereerimine: maandamine, viitamine, tagavaravariant teadmata juhtudeks.
• Eval: igal etapil, pidevalt.

Need pole valikuline lihv. Need on vahe RAG-i vahel, mis tabab 60% vastuse kvaliteeti, ja RAG-i, mis tabab 90%.

Investeering on päris — tootmis-RAG-i ülesehitus on kuud, mitte nädalad. Tasu on süsteem, mida sinu kasutajad päriselt usaldavad. See on lävi, mis loeb.