Enamik õppematerjale näitab RAG-i lihtsas koosluses: valitud LLM, embeddings-teenus ja üks vektoriandmebaas. Tootmiskeskkonnas lisanduvad aga küsimused skaleerumise, latentsuse, kulude, andmete uuendamise ja monitooringu kohta.
Vektoriandmebaasi valik on strateegiline otsus
Tükeldamisstrateegia määrab ära, mida üldse kätte saad
Hübriidotsing: vektor + märksõna, mitte kumbki üksi
Embeddings-mudeli valik ja kulude dünaamika
Embeddings on iga RAG-süsteemi alus, kuid pikema aja jooksul muutub just see kiht tihti suurimaks kulukohaks. Lisaks kvaliteedile tuleb arvestada andmesuveräänsuse ja läbilaskevõimega.
Millal piisab „riiulil olevast“ mudelist ja millal peenhäälestada
Caching ja korduvkasutus
Sama sisu embedditakse tihti mitu korda, kui puudub hea cache-strateegia. Praktikaline muster:
arvuta sisu räsi (hash)
enne uue embeddingu loomist vaata, kas sama hash juba eksisteerib
hoia vektoreid vahekihis (nt Redis, KV) või samas andmebaasis
Eriti kasulik on see dünaamilise, kuid korduva sisuga süsteemides (nt artiklid, KKK, dokumentatsioon), kus sama tekst satub pidevalt uuesti töötlemisse.
LLM-i valik ja prompti disain tootmises
LLM ei ole RAG-süsteemi ainus komponent, aga ta on sageli kõige kallim. Seetõttu tasub läbi mõelda, millal kasutada suurimat ja kallimat mudelit ning millal saab töö ära teha väiksema ja kiirema variandiga.
Mitme mudeli kasutamine kulude optimeerimiseks
Struktureeritud väljund ja skeemid
Vabateksti põhine väljund sobib hästi lugemiseks, aga mitte alati edasi töötlemiseks. Kui soovid:
märkida riskitaset,
väljade kaupa välja võtta infot (nt „mis klausleid siin mainitakse?“),
teha automaatseid tegevusi,
tasub kasutada skeemiga defineeritud JSON-väljundeid (JSON mode, function calling jms). Siis saad panna LLM-i vastuse kenasti TypeScripti tüübi alla ja vältida n-ö „stringi parsimise õudusunenägusid“.
Kontekstiakna nutikas kasutamine
Jälgitavus ja kvaliteedi monitooring
RAG-süsteem ei katki nagu klassikaline API, mis viskab ühe hetkega 500 veakoode. Pigem „vähendab tasapisi kvaliteeti“: andmed vananevad, indekseerimine logiseb, uued servajuhud tekivad. Kui kvaliteeti ei mõõda, saad sellest teada alles siis, kui kliendid kurdavad.
Olulisemad mõõdikud
Tagasiside ja parendamise tsükkel
Kokkuvõte
Soovid ehitada RAG-lahendust, mis töötab ka tootmises?
Kui vajad tuge arhitektuuri, implementatsiooni või optimeerimise juures, saame aidata nii tehnilise poole kui ärilise mõju läbi mõtestamisel.
Retrieval-Augmented Generation ehk RAG on lühikese ajaga liikunud „huvitavast trikist“ kriitilise arhitektuurimustrini paljudes AI-rakendustes. 2025. aasta lõpu seisuga kasutab märkimisväärne osa suurettevõtete AI-süsteemidest RAG-i selleks, et siduda suured keelemudelid oma sisemise andmevaraga ja vähendada hallutsinatsioone.
Samas tuleb demost tootmiskeskkonda liikudes välja terve rida praktilisi probleeme: jõudlus, kulud, andmete elutsükkel, kvaliteedi jälgimine. Allolev on kokkuvõte Acceli õppetundidest - eelkõige sellest, millised arhitektuursed ja operatiivsed otsused määravad, kas RAG-toega süsteem on äriliselt jätkusuutlik või mitte.
Paljud proof-of-concept’id kasutavad esimesena ettejuhtuvat SaaS-vektoriandmebaasi. Tootmises tasub aga mõelda:
kui suur on andmemaht (tänane ja tuleviku)
kas soovid hoida vektoreid koos relatsiooniandmetega
millised on latentsuse ja kulude eesmärgid
Keskmise mahuga süsteemides (kuni ~100M vektorit) on PostgreSQL koos pgvectoriga üllatavalt tugev kandidaat. Eriti siis, kui sama andmebaas hoiab ka metaandmeid - nii väldid eraldi teenuste vahel pendeldamist ning saad kasutada SQL-i jõudu (nt kombinatsioonid täistekstiotsingu, filtrite ja vektoriotsingu vahel). Suuremates mahtudes tulevad mängu spetsiaalsed mootorid nagu Qdrant või Weaviate.
Lihtne „iga X tokenit eraldi tükiks“ lähenemine töötab ainult lihtsate tekstide puhul. Domeenispetsiifilistes lahendustes (lepingud, tehniline dokumentatsioon, juhendid) tasub:
säilitada dokumendi loogiline struktuur (peatükid, alapeatükid)
siduda väiksemad tükid vanema kontekstiga (nt vanem-laps suhe)
arvestada eri sisutüüpidega (koodiblokid, tabelid, selgitav tekst)
Hea praktika on hoida LLM-i poole liikuv kontekst nii, et mudel saab nii konkreetse lõigu kui ka selle ümbrise - muidu võivad vastused muutuda liiga kitsaks või kontekstituks.
Puhas vektoriotsing jookseb tihti ummikusse nimede, lühendite ja viidete peale (nt juriidilised juhtumid, tootekoodid). Seetõttu kasutavad tootmisküpsed lahendused enamasti hübriidset lähenemist:
vektoriotsing annab „semantilise lähedusastme“
BM25 või muu täistekstiotsing aitab püüda kinni täpse süntaksi ja märksõnad
Kaalude sättimine (nt 70% vektor, 30% märksõna) sõltub domeenist ning seda tasub häälestada mõõdetavate kvaliteedimetriete järgi.
Üldkeelelised embeddings-mudelid töötavad üllatavalt hästi paljudes tavakasutustes. Kuid kui tegeled väga spetsiifilise sõnavaraga (finantsinstrumendid, meditsiiniterminid, ettevõttesisesed lühendid), siis:
võib taastustäpsus jääda madalaks, sest mudel ei „näe“ seoseid
vektorkaugused ei kajasta päris seda, mis inimesest eksperdile oluline on
Sellisel juhul tasub koguda märgendatud näidiseid (päring + sobiv dokument) ja peenhäälestada embeddings-mudelit. See ei pea olema hiiglaslik maht - tihti piisab kümnetest tuhandetest paaridest, et kvaliteet tõuseks tuntavalt.
Üks levinud muster on „kolmetasandiline“ lähenemine:
lihtsad, lühikesed küsimused → väike ja odav mudel (nt GPT-5o-mini tüüpi)
keskmise keerukusega analüüs → tugev üldotstarbeline mudel
väga tundlikud või keerukad juhtumid → kõige võimekam mudel või oma hostitud mudel
Enne lõpliku mudeli valikut kasutatakse tavaliselt väikest klassifitseerijat, mis hindab päringu keerukust ja tundlikkust. See lisab küll veidi latentsust, kuid võimaldab kokku hoida märkimisväärse osa kulust.
Pikad kontekstiaknad on ahvatlevad - „paneme kõik sisse ja las mudel otsustab“. Praktikas tähendab see:
kõrgemaid kulusid igal päringul,
mõnikord ka halvemini fokusseeritud vastuseid.
Parema tulemuse annab sageli:
esmalt suurem hulk kandidaattükke,
seejärel re-rank (nt teine, odavam mudel otsustab, mis on kõige olulisem),
LLM-ile saadetakse ainult parimad tükid (nt top 5-8).
Taustinfo (mida vaja harvemini) võib enne veel kokku võtta lühemaks kokkuvõtteks, et hoida konteksti kompaktsemana.
Mõõtmine võiks hõlmata vähemalt:
kui tihti on õige dokument top-k hulgas (precision@k)
kui hästi vastus vastab päringule (LLM kui hindaja)
milline on latentsuse jaotus (embedding, retrieval, generation eraldi)
kui palju maksab keskmine päring
kui tihti vastus põhineb kontekstist väljas oleval infol (hallutsinatsioonid)
Hea lähenemine on luua väike automaatne testpäringute komplekt (sajane-kahesajane), mida jooksutad regulaarselt ning jälgid, kas täpsus ja kulud hakkavad ajas muutuma.
Kasutajate „meeldib/ei meeldi“ nupp igal vastusel on lihtne, aga väga väärtuslik signaal. Kõiki negatiivseid vastuseid ei jõua käsitsi läbi vaadata, kuid:
võid keskenduda näiteks 5% kõige halvema skooriga juhtumitele
kasutada neid peenhäälestamiseks (nii embeddings- kui LLM-kihi jaoks)
täiendada nende põhjal indekseeritavat andmestikku (nt lisada puuduvaid dokumente)
Kriitiline detail: iga päringu puhul logi ära, millised tükid RAG tegelikult tagastasid ja milline prompt LLM-ile läks. Ilma selleta ei saa sinuni jõudnud „halb vastus“ olla korduv ja reprodutseeritav juhtum, millest midagi õppida.
Tootmisküps RAG-lahendus ei ole ainult „LLM + vektoriandmebaas“ - see on terviklik süsteem, kus andmemudel, embeddings, otsing, LLM, cache, monitooring ja kulude juhtimine peavad koos töötama. Kui võtta neid osi sama tõsiselt kui põhitransaktsioonisüsteeme, on tasu sageli märkimisväärne: väiksem manuaalse töö maht, kiirem infoleidmine ning uued tootefunktsioonid, mida ilma AI-ta oleks raske või võimatu pakkuda.
Enamiku projektide puhul kulub demost kuni tootmisküpse lahenduseni 3-6 kuud - see aeg ei kulu ainult koodi kirjutamisele, vaid ka andmete korrastamisele, turva- ja ligipääsukihtidele ning monitooringule. Hästi tehtud RAG-kiht tasub end tagasi mitte ainult kulude kokkuhoius, vaid ka selles, kuidas sinu tiim ja kliendid infot leiavad ja kasutavad.
