Tootmis-RAG-i ehitamine: andmehõive, vektoresitused, otsing, ümberreastamine ja hindamine

Kui oled lihtsa RAG-süsteemi tootmisse viinud, tead tavapärast mustrit: dokumendid jagatakse tekstiosadeks ja teisendatakse vektoresitusteks, päringu jaoks otsitakse sobivaimad osad ning lisatakse need mudelile antavasse juhisesse. Demo võib toimida, kuid tootmises ei pruugi sellest piisata.

Demo-RAG-i ja tootmis-RAG-i vahel on suur erinevus. Tegelikud dokumendid on sageli ebaühtlased ning päringud mitmeti mõistetavad. Kvaliteet võib päringutüüpide kaupa suuresti erineda. Arvestada tuleb nii kulu ja latentsuse kui ka uuendamise ning versioonimisega.

Järgnev kirjeldab tootmiskõlbliku RAG-konveieri kuut etappi, iga etapi lahendusmustreid ja hindamiskorda, mis aitab eristada toimivat süsteemi ebausaldusväärsest.

Konveier

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

[Dokumendid]
    ↓
1. Sissevõtt (parsimine, puhastamine, metaandmete eraldamine)
    ↓
2. Tükeldamine (jaotamine otsinguühikuteks)
    ↓
3. Vektoresituste loomine ja salvestamine
    ↓
[Päring]
    ↓
4. Otsing (semantiline + leksikaalne + filtrid)
    ↓
5. Ümberreastamine (top-k → top-N)
    ↓
6. Genereerimine (LLM + kontekst)
    ↓
[Vastus]

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 korduv tüüpsisu:

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

Puhtast korpusest leiab asjakohase sisu paremini. Korduv tüüpsisu tekitab 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 kitsa küsimuse jaoks, kuid konteksti võib nappida.
• 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. Otsi väikeste tekstiosade seast, kuid anna keelemudelile kontekstiks vastav suurem lähtelõik.

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

Need metaandmed võimaldavad tulemusi filtreerida ja lõppvastuses allikatele viidata.

Etapp 3: vektoresituste loomine

Teisenda tekstiosad vektoriteks.

Vektoresitusmudeli valik.

Võimalike mudeliperede hulka kuuluvad OpenAI, Voyage’i ja Cohere’i vektoresitusmudelid ning avatud kaaludega BGE ja Nomicu mudelid. Nimed, mõõtmed, litsentsid, hinnad ja toetatud sisenditüübid muutuvad. Koosta kandidaatide nimekiri praeguse ametliku dokumentatsiooni ja avatud kaaludega mudelite mudelikaartide põhjal.

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

Vektoresituse mõõde. Mõõtmete arv mõjutab salvestus- ja indeksikulu, kuid suurem vektor ei taga paremat otsingut. Mõni API võimaldab vektorit lühendada, mõni mudel kasutab fikseeritud mõõdet. Võrdle toetatud mõõtmeid samadel märgendatud päringutel ning arvesta otsuses indeksi suurust ja latentsust.

Versioonimine. Vektoresitusmudelid uuenevad ja neid võib olla vaja vahetada. Planeeri see ette:

• Jälgi, milline vektoresitusmudeli versioon iga vektori tootis.
• Loo mudelivahetusel kõik vektoresitused uuesti või kasuta kahe indeksiga üleminekut.
• Ära sega erinevatest mudelitest vektoreid samas otsingus.

Kulu. Arvuta esmane indekseerimine ja muutuv maht mõõdetud tokenite, kuupäevaga pakkujahinna, korduskatsete, OCR-i ja parsimise arvutuskulu, vektorisalvestuse, koopiate ning taasindekseerimise sageduse põhjal. Hoia arvutustabelis ka allika URL ja hinna jõustumise kuupäev; universaalne hinnavahemik vananeb kiiresti.

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). Loo päringust vektoresitus ja leia lähimad naabrid. Nii saab tuvastada semantilist sarnasust.

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.”

Mitme rentnikuga süsteemides on oluline piirata iga päring selle rentniku jaoks lubatud dokumentidega.

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.
• Osadeks jaotamine. Mitmeosaline küsimus jagatakse alapäringuteks, mida otsitakse eraldi.

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

HyDE (Hypothetical Document Embeddings). Lase keelemudelil koostada hüpoteetiline ideaalvastus, loo sellest vektoresitus ja kasuta seda otsingupäringuna. Seda tasub võrrelda algse küsimuse vektoresitusega, sest hüpoteetiline vastus võib olla päris vastusedokumentidega sarnasem.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Kirjuta lõik, mis vastab küsimusele: " + 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, kus k = 20–50) kasuta kandidaatide täpsemaks hindamiseks ümberreastajat.

Miks ümber reastada?

Esialgne otsing on kiire, kuid ebatäpne. Vektorisarnasus on asjakohasuse ligikaudne näitaja. Ümberreastaja, tavaliselt ristkodeerija, hindab päringut ja iga kandidaati koos ning annab täpsema asjakohasushinnangu.

Ümberreastaja valikud:

• Cohere Rerank. Majutatud kommertsteenus.
• Voyage Rerank. Teine majutatud kommertsvalik.
• BGE Rerank-large. Avatud lähtekoodiga mudel, mida saab ise majutada.
• MiniLM-i ristkodeerijad. Väiksemad mudelid, mille kiirust ja kvaliteeti tuleb oma andmestikul mõõta.
• LLM-põhine ümberreastamine. Väike LLM hindab päringu ja kandidaadi paare; kvaliteet, latentsus ja kulu sõltuvad mudelist ning töökoormusest.

Mõju.

Ümberreastamine võib kandidaatide järjekorda parandada, kuid mõju sõltub esimese etapi otsingust, kandidaatide arvust, korpusest, päringute jaotusest ja mõõdikust. Jäta see kiht alles ainult siis, kui märgendatud hindamiskomplekt näitab, et kvaliteedivõit õigustab lisanduvat latentsust ja kulu.

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:

Sa oled assistent, kes vastab küsimustele antud konteksti põhjal.

Kontekst:
[Dokument 1 - pealkiri, URL]
[tüki 1 sisu]
[Dokument 2 - pealkiri, URL]
[tüki 2 sisu]
...

Kasutaja küsimus: {query}

Juhised:
- Vasta ainult antud konteksti põhjal.
- Kui kontekst ei sisalda vastust, ütle seda. Ära mõtle infot juurde.
- Viita allikatele kujul [Allikas N].
- Ole lühike, aga täielik.

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.

"Ettevõtte kaugtöö poliis lubab kuni 4 päeva nädalas kodust töötada [1].
[1]: https://wiki.company.com/policies/remote-work"

See muudab vastuse kontrollitavaks. Kasutajad usaldavad maandatud vastuseid rohkem.

Konteksti suuruse haldamine.

Pikad kontekstid võivad tulemusi halvendada. Enamik mudeleid töötab kõige paremini sihipärase kontekstiga, näiteks 5–10 väga asjakohase lõiguga, mitte kogu materjali kuhjamisega. Konteksti paisudes võib kvaliteet langeda.

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

Hindamine igal etapil

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

Sissevõtu hindamine. Kas dokumendid parsiti õigesti? Võta dokumentidest valim ja kontrolli, et võtmesisu oleks säilinud.

Tükeldamise hindamine. Kas tekstiosad on sobiva suurusega? Kas need säilitavad konteksti? Kas nende piirid on mõistlikud?

Vektoresituste hindamine. Kas sarnaste mõistete vektoresitused on lähestikku? Kas koosinussarnasus vastab tuntud sarnaste ja erinevate paaride hindamiskomplektil ootustele?

Otsingu hindamine. Kas päringu jaoks asjakohased tekstiosad on esimese K tulemuse seas? Levinud mõõdik on saagis K juures: kui suurel osal päringutest on esimese K tulemuse seas vähemalt üks asjakohane tekstiosa.

Ümberreastamise hindamine. Kas ümberreastaja asetab leitud kandidaatidest kõige asjakohasema esimeseks? Sobivad mõõdikud on NDCG (normaliseeritud diskonteeritud kumulatiivne kasu) ja MRR (keskmine pöördjärjekoht).

Genereerimise hindamine. Kas keelemudel annab konteksti ja päringu põhjal õige vastuse? Mõõda tõenditruudust, õigsust ja kasulikkust.

Terviksüsteemi hindamine. Kas süsteem annab tegelikule päringule õige vastuse? See on kõige olulisem hinnang ja 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ööriistadest sobivad näiteks Ragas, TruLens ja kohandatud hindamiskomplektid. Täpne tööriist on vähem tähtis kui hindamiste järjepidev käitamine.

Operatiivsed mured

Mõned tootmiskeskkonna praktilised nõuded:

Indekseerimiskonveierid. Uusi dokumente lisandub pidevalt. Loo muutunud sisust uued vektoresitused, värskenda indekseid ning töötle kustutamisi ja uuendusi. See konveier töötab pidevalt, mitte ainult algse seadistamise ajal. Ehita see süsteemina, mitte ühekordse skriptina.

Latentsus.

Mõõda eraldi päringu vektoresituse loomist, kandidaatide otsingut, ümberreastamist, genereerimise esimese tokeni ja lõpetamise aega ning võrguviivitust. Esita külma ja sooja tee jaotused kavandatud paralleelsusastmel; komponendi nimi ei määra selle latentsust.

Optimeerimine:

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

Kui tootel on latentsuseesmärk, jaga mõõdetud ajaeelarve päringu töötluse, otsingu, ümberreastamise, genereerimise ja võrgu vahel. Alla kahe sekundi jäämist ei saa komponentide nimetuste järgi eeldada; testi külma ja sooja teed eeldatava paralleelsusastmega.

Kulu.

Jaota iga hinnatud päringu kulu päringu vektoresituse, otsingu- ja indeksimahu, ümberreastamise, sisend- ja väljundtokenite, vahemälu oleku ning korduskatsete vahel. Seejärel arvuta prognoositava liikluse kulu vaadeldud jaotuse, mitte ühe keskmise põhjal. Miljoni päringu kulu võib erineda suurusjärgu võrra olenevalt dokumentide mahust, kandidaatide arvust, mudelist, vastuse pikkusest, vahemälu kasutusest ja taristulepingutest.

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 säilitatakse või kustutatakse reeglite kohaselt.
• Järkärguline uuendamine: uutest versioonidest luuakse tekstiosad ja vektoresitused uuesti ning vanad tekstiosad 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.

• Metaandmetel põhinev filtreerimine, mille puhul iga tekstiosa juures on lubatud kasutajad või rühmad.
• 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 ebaõnnestuvates RAG-süsteemides korduvad mustrid:

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 leke. Kasutajad näevad tekstiosi, millele neil ei tohiks olla juurdepääsu. Parandus: rakenda õiguste filtreerimine otsingu ajal ja logi pääsusündmused.

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

Näidisarhitektuur: ettevõtte teadmusbaasi RAG

See on seadistuse tööleht, mitte AI Experti juurutuse tulemus ega väide tüüpilise ettevõtte kohta. Kõik alltoodud mahud, tooted, ajakavad ja kandidaatide arvud on näitlikud hüpoteesid, mis tuleb asendada mõõdetud sisenditega.

Korpus: ligikaudu 50 000 dokumenti (vikilehed, põhimõtted, käitusjuhendid, koosolekumärkmed ja Slacki lõimed).

Konveier:

1. Sissevõtt:

   • Notion: API eksport.
   • Slack: arhiivieksport, filtreeritud asjakohastele kanalitele.
   • Google Drive: API eksport kinnitatud kaustadest.
   • Puhastamine: eemalda ainult emotikone sisaldavad teated ja korduvad allkirjad.

2. 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.

3. Vektoresitused:

   • Voyage-3 vektoresitused, 1024 mõõdet.
   • Salvestatud Pinecone’is (majutatud).
   • Muutunud dokumentide vektoresitused luuakse kord nädalas uuesti.

4. Otsing:

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

5. Ümberreastamine:

   • Cohere Rerank.
   • Top 30 → top 8.

6. Genereerimine:

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

Hindamiskava (sea lävendid ettevõtte lubatud veaeelarve põhjal):

• 100 käsitsi koostatud päring/vastuse paari.
• Otsingu saagis valitud kandidaatide arvul, esitatuna päringurühmade kaupa; nõutav tase määratakse enne häälestamist.
• Lõppvastuse õigsus ja otsingu saagis esitatakse eraldi ning nende erinevust uuritakse ilma eelduseta, kumb on madalam.
• Tõenditruudust ehk väljamõeldiste puudumist jälgitakse õigsusest eraldi.

Näitlik hooldusrütm (tegelik sagedus tuleta allikate muutumiskiirusest ja riskist):

• Igapäevane inkrementaalne sissevõtt.
  • Muutunud dokumentide vektoresituste iganädalane uuendamine.
• Iga päringu vaadeldavus.
• Hindamiste igakuine korduskäivitus ja trendide jälgimine.
• Kvartaalne päringulogi ülevaade uute läbikukkumismustrite leidmiseks.

Kulumudel (täida kuupäevastatud arvete või kehtivate hinnapakkumistega):

• Andmehõive: muutunud tokenite arv × vektoresituse hind, millele lisandub parsimise ja OCR-i arvutuskulu.
• Otsingu salvestus: indekseeritud baitide arv, koopiad, varundus ning reserveeritud või kasutuspõhine päringumaht.
• Päringu kohta: vektoresitus, otsing, ümberreastamine, mudeli sisend ja väljund ning võrgu- ja tööriistakulud.
• Haldus: arendus, hindamisandmete märgendamine, intsidentidele reageerimine ja andmeallikate hooldus.

Kiida kulu heaks alles siis, kui mõõdetud ülesandetulemus ja kokkuhoitud töö õigustavad terviklikku kulumudelit; ainult otsingumõõdikud ei tõesta tasuvust.

Etapiviisiline RAG-i ülesehituse plaan

Kui alustad nullist:

1. etapp: piiritletud prototüüp.

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

2. etapp: kvaliteeditõendid.

• Koosta märgendatud hindamiskomplekt, mis katab olulised päringu- ja riskirühmad.
• Tuvasta läbikukkumismustrid.
• Lisa ümberreastamine.
• Lisa hübriidotsing.
• Paranda tükeldamist.

3. etapp: käideldavuse heakskiit.

• Pidev sissevõtukonveier.
• Vaadeldavus.
• Hindamise automatiseerimine.
• Õigused/autentimine.
• Kulude seire.

Ära seo nende etappidega kalendrilubadust. Liigu edasi alles siis, kui praeguse etapi katsed on läbitud: esmalt allikatruudus ja õigused, seejärel otsingu- ja vastusekvaliteet ning lõpuks turvalisus, värskus, kustutamine, mahutavus, taaste ja käitusvastutus.

Kvaliteet elab igas etapis

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.
• Vektoresitused: kvaliteetne mudel, versioonimine ja ülemineku planeerimine.
• Otsing: võrdle leksikaalset, tihedat ja hübriidotsingut, filtreid ning päringu teisendamist märgendatud hindamiskomplektil.
• Ümberreastamine: lisa see ainult siis, kui mõõdetud kvaliteedivõit õigustab latentsust, kulu ja keerukust.
• Genereerimine: allikatele tuginemine, viitamine ja vastamisest hoidumine ebapiisava teabe korral.
• Hindamine: igal etapil ja pidevalt.

Nõutavad kontrollid sõltuvad töökoormusest ja riskist, kuid iga vahele jäetud etapp vajab selget põhjendust ja kompenseerivat katset. Avaldamis- või juurutusväide peab nimetama hinnatud korpuse, päringurühmad, mõõdikud, tõrkejuhtumid, õigusmudeli ja kuupäeva, mitte tuginema tõendamata eduprotsendile või tarnetähtajale.