Jei paskutinius metus sekate dirbtinio intelekto naujienas, tikrai jau girdėjote santrumpą RAG. Ji minima tokiu dažnumu, kad kartais net pradeda erzinti – panašiai kaip kadaise „blockchain” ar „big data”. Bet skirtingai nuo daugelio hype bangų, RAG tikrai išsprendžia realią, kasdienę problemą, su kuria susiduria beveik visi, kurie bando panaudoti didelius kalbos modelius (LLM) rimtiems, ne pramoginiams tikslams. Pabandykime išsiaiškinti, kas tai per technologija, kaip ji sudėta iš atskirų dalių ir kodėl ji tapo tokia svarbi statant realius produktus, o ne tik demo versijas.
Kas per žvėris tas RAG
RAG – Retrieval-Augmented Generation, arba lietuviškai dažnai vadinama „paieška papildytas generavimas” – tai architektūrinis principas, kai kalbos modelis prieš atsakydamas į klausimą, pirmiausia atlieka paiešką savo turimoje žinių bazėje ir tik tada, pasinaudodamas rastais fragmentais, formuluoja atsakymą. Skamba paprastai, tiesa? Iš esmės taip ir yra – idėja nėra ypač sudėtinga, sudėtingumas slypi implementacijoje.
Kodėl tai iš viso reikalinga? Didelis kalbos modelis, kad ir kokia jo parametrų yra daugybė, turi keletą fundamentalių trūkumų. Pirma, jo žinios „užšalusios” tam tikrame laiko momente – GPT-4 ar Claude tiesiog nežino, kas įvyko po jų mokymo datos. Antra, modeliai mielai „haliucinuoja” – sugeneruoja labai įtikinamai skambantį, bet faktiškai neteisingą atsakymą. Trečia, ir gal svarbiausia įmonių kontekste – LLM nežino jūsų vidinių dokumentų, jūsų klientų duomenų bazės ar praėjusio ketvirčio finansinės ataskaitos. Ir čia RAG įžengia į sceną – jis leidžia modeliui „pasiskolinti” faktus iš išorinio šaltinio realiu laiku, prieš generuojant atsakymą.
Kaip tai veikia po gaubtu
Techninis procesas suskirstomas į kelis etapus, ir verta juos suprasti bent iš aukšto lygio, nes kiekviename yra vietos klystamybei.
Pirmiausia dokumentai (PDF, Word failai, wiki puslapiai, duomenų bazės įrašai) yra suskaidomi į mažesnius gabalus – chunks. Tai nėra atsitiktinis proceso žingsnis, kaip kartais atrodo iš pirmo žvilgsnio. Chunk dydis, persidengimas (overlap), skaidymo strategija (pagal sakinius, paragrafus, semantinius blokus) – visa tai turi realią įtaką galutinio atsakymo kokybei. Per didelis gabalas – prarandi tikslumą, per mažas – prarandi kontekstą.
Toliau kiekvienas gabalas paverčiamas vektoriumi – skaičių sekos pavidalo reprezentacija, kurią sukuria embedding modelis (pvz., OpenAI text-embedding-3, Cohere embed, arba atviro kodo BGE, E5 modeliai). Šie vektoriai talpinami vektorinėje duomenų bazėje – Pinecone, Weaviate, Qdrant, Milvus, arba tiesiog pgvector plėtinyje ant PostgreSQL, jei norite kažko paprastesnio ir pigesnio.
Kai vartotojas užduoda klausimą, jis taip pat paverčiamas vektoriumi, ir sistema pagal panašumo metriką (dažniausiai kosinusinis panašumas) suranda tuos dokumentų gabalus, kurie semantiškai artimiausi klausimui. Šie fragmentai, kartu su originaliu klausimu, sudedami į vieną promptą ir siunčiami LLM. Modelis tada generuoja atsakymą, remdamasis konkrečiu, jam duotu kontekstu, ne tik savo „atmintimi” iš mokymo etapo.
Kodėl ne tiesiog fine-tuning
Šis klausimas kyla praktiškai visiems, kurie pirmą kartą susiduria su RAG koncepcija. Jeigu norime, kad modelis žinotų mūsų duomenis, kodėl tiesiog jo neapmokyti iš naujo su tais duomenimis?
Fine-tuning turi savo vietą, bet jis sprendžia kitokią problemą. Jis geras, kai norite pakeisti modelio stilių, toną, formatą ar išmokyti jį specifinės užduoties struktūros. Bet fine-tuning yra prastas būdas „įkalti” faktus į modelį – jis brangus, reikalauja pakartotinio treniravimo kaskart pasikeitus duomenims, ir svarbiausia – vis tiek nepašalina haliucinacijų rizikos. Modelis gali „pamiršti” senesnę informaciją mokymosi metu (catastrophic forgetting), o naujų faktų įtraukimas reikalauja visiško ciklo pakartojimo.
RAG tuo tarpu leidžia atskirti žinias nuo modelio „intelekto”. Jei rytoj pasikeičia jūsų kompanijos atostogų politika, tiesiog atnaujinate dokumentą duomenų bazėje – nereikia nieko treniruoti iš naujo. Tai milžiniškas praktinis pranašumas verslo aplinkoje, kur duomenys keičiasi kasdien, o ne kas kelis mėnesius.
Vektorinės duomenų bazės – širdis sistemos
Jei RAG būtų žmogaus kūnas, vektorinė duomenų bazė būtų jo atmintis. Pasirinkimas, kurią naudoti, dažnai priklauso nuo mastelio ir biudžeto, o ne nuo abstraktaus „geriausio” sprendimo egzistavimo.
- Pinecone – managed servisas, patogus, greitai paleidžiamas, bet mokamas ir uždarasis kodas.
- Weaviate – atviro kodo, turi gerą hibridinę paiešką (vektorinė + raktažodinė), patogus vidutinio dydžio projektams.
- Qdrant – lietuviškų šaknų turintis (pradėtas rusų programuotojų, bet gerai palaikomas Europoje), greitas ir efektyvus Rust pagrindu.
- pgvector – plėtinys PostgreSQL, jeigu jau turite Postgres infrastruktūrą ir nenorite pridėti dar vieno komponento į stack’ą. Idealu pradedantiems ar mažesniems projektams.
Svarbu neapsigauti – vektorinė paieška nėra magiškai tobula. Ji ieško semantinio panašumo, bet dažnai praleidžia tikslius atitikmenis, pavyzdžiui, konkretų produkto kodą ar sutartinį numerį. Todėl daugelis rimtų sistemų naudoja hibridinę paiešką – kombinuoja vektorinę paiešką su tradicine BM25 raktažodine paieška, ir po to rezultatus sujungia (re-ranking etapu).
Dažniausios klaidos statant RAG sistemą
Pabuvęs prie kelių tokių projektų, pastebi, kad klaidos kartojasi beveik identiškai skirtingose komandose.
Pirma klaida – ignoruoti chunking strategiją. Žmonės tiesiog padalija dokumentą į 500 simbolių blokus be jokios logikos ir tikisi stebuklo. Realybėje geriau skaidyti pagal natūralias dokumento struktūras – paragrafus, skyrius, antraštes – ir palikti šiokį tokį persidengimą, kad kontekstas nebūtų nutrauktas pusiaukelėje.
Antra – neįvertinti retrieval kokybės atskirai nuo generation kokybės. Jei atsakymas prastas, dažnai kaltinama LLM, bet realybėje problema slypi tame, kad paieška tiesiog neranda tinkamų dokumentų. Verta turėti atskirą metriką, pvz., recall@k, kuri parodo, ar teisingas dokumentas iš viso patenka į top-k rezultatų.
Trečia – per daug pasitikėti vienu embedding modeliu visiems atvejams. Skirtingi domenai (medicina, teisė, techninė dokumentacija) turi skirtingą žodyną, ir generic embedding modelis gali tiesiog neatpažinti specifinių terminų panašumo taip, kaip domenui pritaikytas modelis.
Ketvirta – pamiršti apie context window limitus. Jei sugrąžinate 20 dokumentų gabalų kiekvienai užklausai, modelis gali tiesiog „nuskęsti” informacijoje ir sumaišyti faktus arba ignoruoti dalį konteksto (lost in the middle problema, apie kurią daug rašyta akademinėje literatūroje).
Praktiniai įrankiai, su kuriais verta pradėti
Jei norite patys pabandyti pastatyti RAG sistemą, nereikia iš nulies rašyti visos infrastruktūros. Yra bibliotekų, kurios ženkliai sutrumpina kelią nuo idėjos iki prototipo.
- LangChain – populiariausias framework, turintis paruoštus komponentus visam pipeline’ui, nuo document loaderių iki retrieval chains. Kartais kritikuojamas dėl per didelio abstrakcijos sluoksnio, bet gerai tinka greitam prototipavimui.
- LlamaIndex – specifiškai orientuotas į duomenų indeksavimą ir retrieval, subtiliai lengvesnis ir aiškesnis nei LangChain daugeliu atvejų, kai tikslas tik RAG, o ne bendra LLM orkestracija.
- Haystack – nuo Deepset komandos, gerai tinka produkcinėms sistemoms, turi solidžią evaluacijos infrastruktūrą.
Jei norite tiesiog eksperimentuoti nedideliu mastu, galite pastatyti minimalią versiją be jokių framework’ų – embedding API + vektorinis pgvector + paprastas Python skriptas. Tai puikus pratimas, nes leidžia iš tikrųjų pamatyti, kas vyksta „po gaubtu”, vietoj to, kad viskas paslėpta abstrakcijose.
RAG receptas kepimui namuose
Jeigu turėtumėte išsinešti vieną mintį iš viso šito teksto, tai būtų tokia: RAG nėra vienas mygtukas, kurį paspaudi ir visos problemos išsprendžiamos. Tai kruopštus procesas, kur kiekvienas etapas – dokumentų parsinimas, chunking, embedding pasirinkimas, retrieval strategija, re-ranking, prompt konstrukcija – turi savo įtaką galutiniam rezultatui. Sistema, kuri veikia demo aplinkoje su penkiais dokumentais, nebūtinai veiks taip pat gerai su penkiais tūkstančiais, ir tai reikia turėti omenyje jau nuo pat pradžių.
Praktinis patarimas tiems, kas tik pradeda: nesistenkite iškart optimizuoti visko. Pastatykite paprastą baseline versiją – pgvector, standartinis embedding modelis, fiksuoto dydžio chunk’ai – ir tik tada, matydami, kur konkrečiai atsakymai prastėja, taisykite tas vietas. Turėkite testinį rinkinį klausimų-atsakymų porų, kad galėtumėte objektyviai matuoti pažangą, ne tik „atrodo, kad geriau” jausmą.
Dar viena mintis, kurios verta laikytis – neignoruokite žmogiškojo faktoriaus vertinime. Automatinės metrikos (BLEU, ROUGE ir panašios) dažnai netiksliai atspindi tikrąją atsakymo kokybę RAG kontekste. Geriausias vertinimo būdas vis dar yra žmogus, kuris peržiūri atsakymus ir sprendžia, ar jie faktiškai teisingi, ar tik skamba gražiai.
Ir galiausiai – RAG technologija dar vystosi labai sparčiai. Šiandien madingi agentiniai RAG variantai, kur modelis pats sprendžia, kada ir ką ieškoti, o ne tik pasyviai gauna kontekstą iš vieno paieškos žingsnio. Verta sekti šią sritį, nes tai, kas šiandien atrodo sudėtinga inžinerinė problema, rytoj gali būti sprendžiama jau paruoštu, iš dėžutės veikiančiu įrankiu. Bet fundamentalus principas – atskirti žinias nuo intelekto, leisti modeliui „pasiskolinti” faktus prieš generuojant atsakymą – tikriausiai išliks pagrindu ilgai, nepriklausomai nuo to, kokiais konkrečiais įrankiais tai bus įgyvendinama.
