Mis on RAG-i arhitektuur? Täielik määratlus koos üksikasjalike praktiliste näidetega

RAG ehk otsinguga täiendatud genereerimine (ingl retrieval augmented generation) on protsess, mille käigus LLM-id kasutavad välist teavet, et oma väljundeid laiendada ja parandada. RAG-i arhitektuur on komponentide ja ühenduste kogum, mis teeb RAG-i võimalikuks.

RAG-il on mitu eri kategooriat ja igaüks neist põhineb oma ainulaadsel arhitektuuril. Sisuliselt määrab RAG-süsteemi arhitektuur selle, kuidas täpselt teavet talletatakse, otsitakse ja LLM-ile edastatakse.

Mis on RAG-i arhitektuur?

RAG-i arhitektuur on komponentide (ja nendega seotud võimekuste) aluskonfiguratsioon, mis paneb konkreetse RAG-süsteemi tööle. Kõik need arhitektuurid tuginevad põhimallile, mida nimetatakse sageli „lihtsaks“ või „naiivseks“ RAG-iks.

Siin on üldine ülevaade RAG-i põhiarhitektuurist:

• Teabeallikas: Siin talletatakse väline teave. See võib olla otsinguindeks, suurt hulka teavet esindav vektorandmebaas või töötlemata dokumentide hoidla.
• Otsingukomponent: See on mehhanism, mille abil teabeallikast päringuid tehakse. RAG-süsteem võib näiteks kasutada asjakohaste tekstitükkide leidmiseks lihtsat märksõnaotsingut või sarnasusotsingu tegemiseks keerukamaid vektorpäringuid.
• Orkestreerimiskomponent: See kiht on LLM-põhise rakenduse osa, mis käivitab kasutaja viiba jaoks RAG-i konveieri kas koos LLM-iga või iseseisvalt. Samuti koondab see leitud teabe laiendatud viibaks.

RAG-i arhitektuuri komponendid jaotatakse tavaliselt kaheks rajaks. Andmete sisselugemise rada võtab andmed ja korraldab need otsitavaks teabeallikaks. Vektorandmebaasid, milles suur hulk teksti teisendatakse vektormanuste otsitavaks hoidlaks, on üks enim kasutatavaid rakendusi.

Otsingurada võtab kasutaja viiba ja loob selle põhjal päringu, millega teabeallikast otsida. Seejärel lisab orkestreerija leitud teabe LLM-i kontekstisisendisse. Agentsete ja hübriidsete RAG-arhitektuuride puhul võib otsinguradu olla mitu.

RAG-i arhitektuuri tüübid

RAG-i on eksitav käsitleda täiesti eraldiseisvate arhitektuuride kaudu. Enamik insenere kasutab modulaarset lähenemist ja rakendab konkreetsete kasutusjuhtude jaoks eraldi komponente. Kuigi ligikaudseid piire on võimalik tõmmata, tuleb arvestada, et arhitektuurimudelid kattuvad märkimisväärselt.

1. Põhiline RAG

Põhiline RAG, mida nimetatakse ka „naiivseks“ või „lihtsaks“ RAG-iks, on teiste RAG-i tüüpide arhitektuuriline mall.

Aluseks olev protsess on suhteliselt lihtne: kasutaja sisestab viiba, orkestreerija otsustab (kas iseseisvalt või koos LLM-iga), kas on vaja välist teavet, ning koostab ja saadab vastavalt sellele otsingupäringu.

Väline teabeallikas on tavaliselt vektorandmebaas, kuid see võib olla ka SQL-andmebaas, veebi-API, teadmusgraaf või isegi „töötlemata“ dokumentide hoidla. Seejärel lisatakse see täiendav teave LLM-i sisendkonteksti.

Lisaks SQL-päringutele ja API-dele on otsingumeetodeid laias laastus kahte tüüpi:

• Leksikaalne otsing (märksõnaotsing): See on RAG-i lihtne vorm, mille puhul eraldatakse kasutaja päringust märksõnad ja võrreldakse neid tekstilõikudega, mis neid märksõnu sisaldavad. Tänapäevastes konveierites võib orkestreerija teha selleks nn hõreda vektori päringu, mis tähendust ei taba.
• Tiheda vektori otsing (semantiline otsing): Tihedad vektormanused tabavad tähendust. Orkestreerija saab teha tihedate vektorite andmebaasist päringuid viisil, mis tabab nii kasutaja viiba kui ka lähteteabe tähenduse.

Mälu kasutamine on samuti RAG-i arhitektuuri oluline osa. See tähendab, kuidas LLM kasutab otsingupäringu koostamiseks varasemate vestluste konteksti, sidudes päringu seeläbi arutelu (või mitme arutelu) laiema kontekstiga. Vestluspõhine RAG on enamiku vestlusrobotite puhul tavapärane, kuigi mõnel juhul, näiteks tugipiletitele vastamisel, võidakse kasutada üheküsimuselist RAG-i.

2. Hübriid-RAG

Hübriid-RAG ühendab kaks eri tüüpi otsingut, tavaliselt märksõna- ja semantilise otsingu. Märksõnaotsing leiab vastavad terminid ja vektoripõhine otsing leiab seotud tähendusega lõigud.

Kasutada võib ka muid otsinguvorme, näiteks teadmusgraafi läbimist või SQL-andmebaasi päringuid. Protsessi juhib sageli suunamisloogika kas programmeeritud reeglite või küsimuse mudelipõhise klassifitseerimise kujul (kuigi mitu konveierit võivad töötada ka samaaegselt).

Orkestreerija liidab tulemused ja võib need enne LLM-ile edastamist ümber järjestada. Ümberjärjestamine on protsess, mille käigus leitud tekstitükkidele määratakse asjakohasuse hinded, et LLM eelistaks kõige sobivamat teavet.

3. Adaptiivne RAG

Adaptiivse RAG-i puhul valib suunamiskomponent kasutaja viiba nõuete põhjal otsingustrateegia ning seejärel käivitab orkestreerija valitud töövoo.

Algses raamistikus (Adaptive-RAG) toimis väiksem mudel klassifikaatorina ja valis, kas otsingut ei tehta üldse või tehakse üheastmeline või mitmeastmeline otsing. Mõned arhitektuurid kasutavad nüüd selle asemel generatiivseid mudeleid või reeglipõhiseid heuristikaid.

See on populaarne arhitektuur, sest see jaotab töötlusvõimsust viiba keerukuse ja nõuete põhjal, vähendades lihtsamate viipade puhul tarbetuid otsinguetappe. See on levinud assistentides, mis tegelevad mitut tüüpi küsimustega.

4. Korrigeeriv RAG (CRAG)

Korrigeeriv RAG hindab leitud teavet enne selle lisamist LLM-i kontekstisisendisse. Otsinguhindaja kontrollib, kas leitud teave on asjakohane ja kasulik. Ainulaadne arhitektuuriline tunnus on selgesõnaline hindamis- ja parandusetapp enne vastuse genereerimist.

Kui teave osutub puudulikuks või viiba jaoks sobimatuks, käivitatakse täiendavad päringud. Need võivad kasutada algsest päringust erinevaid otsingumeetodeid, näiteks veebiotsingut või teadmusgraafi läbimist.

Korrigeeriv RAG on levinud valdkondades, kus täpsus on oluline, näiteks meditsiinis ja õiguses. Samas vajab see täiendavat teabeallikat, mis suudab algselt leitud lõike täiendada.

5. Self-RAG

Self-RAG-i puhul saab mudel pärast esialgse kontekstisisendi saamist ise päringuid algatada. Genereeritud vastuseid hinnatakse leitud tõendite põhjal peegeldusmärkide (ingl reflection tokens) abil ning vajaduse korral saadetakse orkestreerija kaudu täiendavaid päringuid. Teisalt võib LLM otsustada, et otsingut pole üldse vaja.

See erineb korrigeerivast RAG-ist selle poolest, et LLM hindab ise oma väljundeid, otsustab, kas otsingut on vaja ja kas leitud tekst on kasulik, ning jälgib oma vastuseid, muutes neid vajaduse korral. Korrigeeriv RAG seevastu hindab leitud teabe kvaliteeti enne genereerimist.

See arhitektuur on eriti kasulik keerukate, põhjaliku uuringu laadsete viipade puhul. Kuna see lõimib (leitud teabe) asjakohasuse hindamise vastuse genereerimisse, sobib see hästi viipadele, mis nõuavad tõenduspõhiseid vastuseid.

6. Agentne RAG

Agentne RAG tähistab mis tahes RAG-i vormi, mida täidetakse agentse platvormi kontekstis. Mudel kasutab oma arutlusvõimet, et teha kindlaks, millist tüüpi teavet on vaja, ja valib saadaolevate otsinguvõimaluste seast.

Otsingu saab vastavalt vajadusele käivitada mitu korda ning keerukamate päringute jaoks saab mudel määrata agente. Näiteks võib LLM tarnija tuvastamiseks taotleda andmebaasipäringut, käivitada asjakohaste lepingute leidmiseks dokumendiotsingu ja lõpetada veebiotsinguga, et kontrollida kontaktandmeid avalike allikate põhjal.

Agentne RAG on peamine arhitektuurilahendus levinud vestlusrobotites, nagu Perplexity, ChatGPT, Claude jt. Kuna need platvormid annavad põhimudelile juurdepääsu mitmele tööriistale ja RAG-konveierile, saab mudel valida, milline otsinguvorm viibale kõige paremini sobib.

7. Multimodaalne RAG

Multimodaalne RAG otsib konteksti eri tüüpi meediast. See on RAG-i oluline vorm, sest see teeb LLM-idele kättesaadavaks teabe, näiteks diagrammid ja helisalvestised, mis oleks muidu kättesaamatu.

Aluseks olev arhitektuur on sama mis mis tahes muus süsteemis. Näiteks võib indekseerimiskonveier valmistada pildid otsinguks ette, teisendades need otse manusteks. Agentne RAG-süsteem võiks seejärel need pildid koos semantiliselt asjakohase tekstiga leida ja edastada need nägemis-keelemudelile pildi ja teksti koostöötlemiseks.

8. GraphRAG

GraphRAG kasutab olemite kohta teabe leidmiseks vektorotsingu kõrval teadmusgraafe. Tavaliselt leiab orkestreerija asjakohased lähteolemid, mida nimetatakse ka sõlmedeks, märksõnade eraldamise või mõnikord esialgse vektorotsingu abil. Graafiotsija läbib teadmusgraafi, et luua laiem kontekst.

Näiteks võib LLM vastuseks päringule, milles soovitakse tootekategooria üksikasjalikku ülevaadet, käivitada vektorotsingu, et tuvastada konkreetsed olemid (tooted). Seejärel käivitab orkestreerija teadmusgraafi otsingu, et leida seotud olemeid, nagu tarnijad, jaemüügikohad, arvustused jne.

9. Hargnev RAG

Erinevalt hübriidsest RAG-i arhitektuurist, mis võimaldab kasutada teabe otsimiseks eri meetodeid, tähendab hargnev RAG mitme päringu, nn harude, samaaegset käitamist. Iga haru võib teha päringu eraldi teabeallikast või harud võivad samast allikast paralleelselt otsida eri päringute või filtritega. Agentse RAG-i arhitektuur kasutab sageli hargnevat RAG-i.

10. HyDE (Hypothetical Document Embeddings ehk hüpoteetiliste dokumentide manused)

HyDE on RAG-i uuenduslik vorm, mille puhul LLM loob hüpoteetilise tekstidokumendi selle kohta, milline võiks optimaalne vastus välja näha. Seda „hüpoteetilist dokumenti“ kasutatakse seejärel päringu koostamiseks, et otsing oleks täpsem. Kuigi asjakohased teadmised ei ole LLM-i parameetrites esindatud, põhineb meetod mõttel, et vastusesarnane lõik võib asjakohaste dokumentidega paremini kattuda kui lühike küsimus või mitmetähenduslik viip.

Lihtsa RAG-i arhitektuuri näide: vektorandmebaas

Põhiline RAG on keerukamate arhitektuuritüüpide alus. Vektorandmebaasi kasutava lihtsa RAG-süsteemi puhul jagatakse lähtedokumentatsioon väiksemateks osadeks (tükkideks) ja teisendatakse tihedateks manusteks. Kui kasutaja sisestab viiba, loob orkestreerija päringu, kodeerib selle ja teeb andmebaasist päringu, et leida asjakohaseid lõike.

Siin on protsessi samm-sammuline ülevaade:

1. Suur hulk teksti teisendatakse vektoriteks automatiseeritud sisselugemiskonveieri ja manustamismudeli, näiteks BERT-i, abil.
2. Andmebaasirakendus korraldab, indekseerib ja talletab vektorid kiire otsingu jaoks.
3. Kasutaja sisestab viiba vestlusrobotisse (näiteks Perplexity).
4. Rakenduse orkestreerija kodeerib viiba (manustamismudeli abil), et leida vektorandmebaasist asjakohast teavet.
5. Vektorandmebaas tagastab asjakohased tekstitükid ning orkestreerija lisab need sisendkonteksti („suurde viipa“) ja edastab selle LLM-ile.
6. LLM kasutab täiendavat konteksti, et genereerida vastus oma sisemiste teadmiste (mis on talletatud selle parameetrilistes kaaludes) abil.

Suurenda

Täiustatud RAG-i arhitektuuri näide: agentne RAG

Agentne RAG tähistab RAG-süsteemide aluseks olevat arhitektuuri agentsel platvormil. Agentse RAG-i vood on tavaliselt keerukad, sest tehisintellektiagendid saavad sõltuvalt viiba olemusest kasutada eri tööriistu ja konveiereid ning vajaduse korral rakendada mitut agenti.

Siin on protsessi praktiline näide:

1. Kasutaja sisestab keeruka küsimuse, mis nõuab teema kohta põhjalikku uuringut. Oletame selle näite puhul, et viip on: „Esita ettevõtte kasumi prognoos järgmiseks kuueks kuuks, võttes arvesse olulisi geopoliitilisi sündmusi.“
2. LLM järeldab arutluse põhjal, et vaja on eri sisutüüpe hõlmavate RAG-päringute kombinatsiooni.
3. Rakendatakse kolm eri agenti: (a) vektorotsinguks, (b) veebiallikatele tuginemiseks ja (c) pildiotsinguks (multimodaalseks otsinguks).
4. Agendid otsivad orkestreerija kaudu saadaolevate otsingutööriistade abil asjakohast teavet, näiteks uudislugusid ja ettevõttesiseseid finantsandmeid.
5. LLM võrdleb leitud tulemusi iga agendi uurimisküsimusega ja järjestab need asjakohasuse järgi.
6. LLM hindab teavet ja käivitab üksikute agentide kaudu täiendavaid otsinguid seal, kus teave puudub.
7. Kui piisavalt teavet on leitud, koostab LLM olemasolevate finantsnäitajate (mis on leitud sisedokumentatsioonist) põhjal stsenaariumiprognoosid ja kasutab kalkulaatoritööriista, et prognoosida iga stsenaariumi puhul kasumit.
8. LLM genereerib leitud teabe ja arvutuste põhjal lõpliku vastuse, viidates vajaduse korral allikatele.

Suurenda

Mis ootab RAG-i ees?

Praegused uuendused keskenduvad olemasolevate RAG-arhitektuuride sügavuse ja kiiruse suurendamisele, multimeediaotsingu täpsuse parandamisele ning süsteemide loomisele, mis suudavad töödelda kõige värskemat teavet.

Siin on kolm suundumust, mis praegu uuringute suunda kujundavad:

• Põhjalik uuring mitmes allikas: See on RAG-i arhitektuur, mis suudab otsinguid planeerida, käitada mitut haru eri allikates, hinnata leitud tõendeid ja genereeritud vastuseid ise optimeerida. Agentne RAG, mis suudab kõiki neid ülesandeid täita, muutub järjest kiiremaks ja kulutõhusamaks.
• Multimodaalsed rakendused: Otsingukonveierid tulevad piltide ja videoga üha paremini toime. Need suudavad keerukatest multimodaalsetest andmetest, nagu pikad videod ja detailsed diagrammid, üha täpsemalt leida konkreetset tüüpi teavet.
• Vastuste sidumine pidevalt muutuva teabega: LLM-põhised rakendused saavad sisendkonteksti loomiseks kasutada reaalajas teabeallikaid (näiteks videovooge ja andureid). Nende andmete tõlgendamiseks saavad süsteemid luua ka mitmetahulisi teabevõrgustikke, näiteks GraphRAG-i abil.

RAG on LLM-põhiste rakenduste toimimise alus. See võimaldab väga erinevatel kasutajatel, alates tavatarbijatest kuni spetsiifilistes valdkondades tegutsevate ettevõteteni, ületada probleeme, mis on seotud hallutsinatsioonide, puudulike treeningandmete ja spetsiifilistele sisemistele teadmistele juurdepääsu puudumisega.

Seetõttu on RAG-süsteemid ja nende aluseks olev arhitektuur üks kõige kiiremini arenevaid ja põnevamaid tehisintellekti uuringute valdkondi.