Kas ir RAG arhitektūra? Pilna definīcija ar detalizētiem praktiskiem piemēriem

RAG jeb izguvē papildināta ģenerēšana (retrieval augmented generation) ir process, kurā LLM izmanto ārēju informāciju, lai paplašinātu un uzlabotu savus rezultātus. RAG arhitektūra ir komponentu un savienojumu kopums, kas padara RAG iespējamu.

Pastāv vairākas dažādas RAG kategorijas, un katrai no tām ir sava unikāla arhitektūra. Būtībā RAG sistēmas arhitektūra nosaka unikālo veidu, kādā informācija tiek glabāta, izgūta un nodota LLM.

Kas ir RAG arhitektūra?

RAG arhitektūra ir komponentu (un ar tiem saistīto iespēju) pamatā esošā konfigurācija, kas nodrošina konkrētas RAG sistēmas darbību. Visas šīs arhitektūras balstās uz pamata veidni, ko bieži dēvē par „vienkāršo” vai „naivo” RAG.

Lūk, vispārīgs pamata RAG arhitektūras pārskats:

• Informācijas avots: Šeit tiek glabāta ārējā informācija. Tas var būt meklēšanas indekss, vektoru datubāze, kurā attēloti lieli informācijas apjomi, vai neapstrādātu dokumentu repozitorijs.
• Izguves komponents: Tas ir mehānisms, ar kura palīdzību tiek veikti vaicājumi informācijas avotam. Piemēram, RAG sistēma var izmantot vienkāršu atslēgvārdu meklēšanu, lai atrastu atbilstošus teksta fragmentus, vai sarežģītākus vektoru vaicājumus, lai veiktu līdzības meklēšanu.
• Orķestrēšanas komponents: Šis slānis ir tā LLM balstītās lietotnes daļa, kas uzsāk RAG konveijeru lietotāja uzvednei — kopā ar LLM vai neatkarīgi no tā. Tas arī apkopo izgūto informāciju paplašinātā uzvednē.

RAG arhitektūras komponenti parasti ir sakārtoti divos ceļos. Uzņemšanas ceļš paņem datus un sakārto tos meklējamā informācijas avotā. Vektoru datubāzes, kurās lieli teksta apjomi tiek pārveidoti par meklējamu vektoru iegulumu repozitoriju, ir viens no visplašāk izmantotajiem risinājumiem.

Izguves ceļš paņem lietotāja uzvedni un ģenerē vaicājumu, ar kuru meklēt informācijas avotā. Pēc tam orķestrētājs pievieno izgūto informāciju LLM ievades kontekstam. Aģentiskajās un hibrīdajās RAG arhitektūrās var būt vairāki izguves ceļi.

RAG arhitektūras veidi

Būtu maldinoši uzskatīt RAG par pilnīgi nošķirtām arhitektūrām. Lielākā daļa inženieru izmanto modulāru pieeju, ieviešot atsevišķus komponentus konkrētiem lietojuma gadījumiem. Lai gan ir iespējams novilkt aptuvenas robežas, svarīgi ņemt vērā, ka arhitektūras modeļi ievērojami pārklājas.

1. Pamata RAG

Pamata RAG, ko dēvē arī par „naivo” vai „vienkāršo” RAG, ir arhitektūras veidne citiem RAG veidiem.

Pamatā esošais process ir salīdzinoši vienkāršs: lietotājs ievada uzvedni, orķestrētājs nosaka, vai ir nepieciešama ārēja informācija (neatkarīgi vai kopā ar LLM), un attiecīgi formulē un nosūta izguves vaicājumu.

Ārējās informācijas avots parasti ir vektoru datubāze, taču tas var būt arī SQL datubāze, tīmekļa API, zināšanu grafs vai pat „neapstrādātu” dokumentu repozitorijs. Šī papildu informācija pēc tam tiek pievienota LLM ievades kontekstam.

Neskaitot SQL vaicājumus un API, pastāv divi plaši izguves metožu veidi:

• Leksiskā meklēšana (atslēgvārdu meklēšana): Šī ir vienkārša RAG forma, kurā no lietotāja vaicājuma tiek izgūti atslēgvārdi un salīdzināti ar teksta fragmentiem, kas satur šos atslēgvārdus. Mūsdienu konveijeros orķestrētājs šim nolūkam var izmantot tā saukto retināto vektoru vaicājumu, kas neuztver nozīmi.
• Blīvo vektoru meklēšana (semantiskā meklēšana): Blīvie vektoru iegulumi uztver nozīmi. Orķestrētājs var veikt vaicājumu blīvo vektoru datubāzē tā, lai tiktu uztverta gan lietotāja uzvednes, gan avota informācijas nozīme.

Atmiņas izmantošana arī ir svarīga RAG arhitektūras daļa. Tā attiecas uz to, kā LLM izmanto kontekstu no iepriekšējām tērzēšanām, lai izveidotu izguves vaicājumu, tādējādi sasaistot to ar plašāku sarunas (vai vairāku sarunu) kontekstu. Sarunu RAG ir norma lielākajai daļai tērzēšanas robotu, lai gan dažos lietojuma gadījumos, piemēram, atbildot uz atbalsta pieteikumiem, var izmantot viena jautājuma RAG.

2. Hibrīdā RAG

Hibrīdā RAG apvieno divus dažādus izguves veidus, parasti atslēgvārdu un semantisko izguvi. Atslēgvārdu meklēšana atrod atbilstošus terminus, bet vektoru meklēšana atrod fragmentus ar saistītu nozīmi.

Var izmantot arī citus izguves veidus, piemēram, zināšanu grafa šķērsošanu vai SQL datubāzes vaicājumus. Procesu bieži vada maršrutēšanas loģika — vai nu ieprogrammētu noteikumu veidā, vai arī modelim klasificējot jautājumu (lai gan vairāki konveijeri var darboties arī vienlaikus).

Orķestrētājs apvieno rezultātus un var tos pārranžēt, pirms tos nodod LLM. Pārranžēšana ir process, kurā izgūtajiem fragmentiem tiek piešķirti atbilstības vērtējumi, lai LLM piešķirtu prioritāti visatbilstošākajai informācijai.

3. Adaptīvā RAG

Adaptīvajā RAG maršrutēšanas komponents izvēlas izguves stratēģiju, pamatojoties uz lietotāja uzvednes prasībām, un pēc tam orķestrētājs izpilda izvēlēto darbplūsmu.

Sākotnējā ietvarā (Adaptive-RAG) mazāks modelis darbojās kā klasifikators un izvēlējās starp izguves neveikšanu, vienas darbības izguvi vai vairāku darbību izguvi. Dažās arhitektūrās tagad tā vietā izmanto ģeneratīvos modeļus vai uz noteikumiem balstītu heiristiku.

Šī ir populāra arhitektūra, jo tā piešķir apstrādes jaudu atbilstoši uzvednes sarežģītībai un prasībām, samazinot nevajadzīgas izguves darbības vienkāršākām uzvednēm. Tā ir izplatīta asistentos, kuriem jāapstrādā vairāku veidu jautājumi.

4. Koriģējošā RAG (CRAG)

Koriģējošā RAG novērtē izgūto informāciju, pirms to pievieno LLM ievades kontekstam. Izguves vērtētājs izvērtē, vai izgūtā informācija ir atbilstoša un noderīga. Unikālā arhitektūras iezīme ir skaidri nodalīts novērtēšanas un labošanas posms pirms atbildes ģenerēšanas.

Ja informācija izrādās nepilnīga vai neatbilst uzvednei, tiek aktivizēti papildu pieprasījumi. Tie var ietvert citas izguves metodes, piemēram, tīmekļa meklēšanu vai zināšanu grafa šķērsošanu, nekā tika izmantotas sākotnējā pieprasījumā.

Koriģējošā RAG ir izplatīta jomās, kurās svarīga ir precizitāte, piemēram, medicīnā un tiesību jomā. Tomēr tai ir nepieciešams papildu informācijas avots, kas var papildināt sākotnēji izgūtos fragmentus.

5. Self-RAG

Self-RAG pieejā modelis var uzsākt pieprasījumus pēc sākotnējās konteksta ievades saņemšanas. Ģenerētās atbildes tiek salīdzinātas ar izgūtajiem pierādījumiem, izmantojot refleksijas marķierus, un pēc vajadzības caur orķestrētāju tiek nosūtīti papildu pieprasījumi. Un otrādi — LLM var nolemt, ka izguve nemaz nav nepieciešama.

Tā atšķiras no koriģējošās RAG ar to, ka LLM pats vērtē savus rezultātus, nosaka, vai ir nepieciešama izguve un vai izgūtais teksts ir noderīgs, kā arī uzrauga savas atbildes un pēc vajadzības tās pārveido. Savukārt koriģējošā RAG novērtē izgūtās informācijas kvalitāti pirms ģenerēšanas.

Šī arhitektūra ir īpaši noderīga sarežģītām uzvednēm padziļinātas izpētes stilā. Tā kā tā integrē (izgūtās informācijas) atbilstības novērtējumus atbildes ģenerēšanā, tā ir laba izvēle uzvednēm, kurām nepieciešamas uz pierādījumiem balstītas atbildes.

6. Aģentiskā RAG

Aģentiskā RAG apzīmē jebkuru RAG formu, kas tiek izpildīta aģentiskas platformas kontekstā. Modelis izmanto savu spriestspēju, lai noteiktu nepieciešamās informācijas veidu, un izvēlas kādu no pieejamajām izguves iespējām.

Izguvi var aktivizēt vairākas reizes pēc vajadzības, un modelim ir iespēja piešķirt aģentus sarežģītākiem vaicājumiem. Piemēram, LLM varētu pieprasīt uzmeklēšanu datubāzē, lai identificētu piegādātāju, aktivizēt dokumentu meklēšanu, lai atrastu attiecīgos līgumus, un noslēgumā veikt tīmekļa meklēšanu, lai pārbaudītu kontaktinformāciju, izmantojot publiskus avotus.

Aģentiskā RAG ir galvenā arhitektūras implementācija populāros tērzēšanas robotos, piemēram, Perplexity, ChatGPT, Claude un citos. Tā kā šīs platformas nodrošina pamatmodelim piekļuvi vairākiem rīkiem un RAG konveijeriem, tas var izvēlēties, kurš izguves veids vislabāk atbilst konkrētajai uzvednei.

7. Multimodālā RAG

Multimodālā RAG izgūst kontekstu no dažāda veida multivides. Tā ir svarīga RAG forma, jo padara LLM pieejamu informāciju, piemēram, diagrammas un audioierakstus, kas citādi būtu nepieejama.

Pamatā esošā arhitektūra ir tāda pati kā jebkurā citā sistēmā. Piemēram, indeksēšanas konveijers var sagatavot attēlus meklēšanai, pārveidojot tos tiešos iegulumos. Pēc tam aģentiskā RAG sistēma var izgūt šos attēlus kopā ar semantiski atbilstošu tekstu un nodot tos redzes un valodas modelim divējādai apstrādei.

8. GraphRAG

GraphRAG izmanto zināšanu grafus kopā ar vektoru meklēšanu, lai izgūtu informāciju par entītijām. Parasti orķestrētājs atrod atbilstošās sākuma entītijas, ko dēvē arī par mezgliem, izmantojot atslēgvārdu izgūšanu vai dažkārt sākotnēju vektoru meklēšanu. Grafa izguvējs šķērso zināšanu grafu, lai izveidotu plašāku kontekstu.

Piemēram, atbildot uz pieprasījumu sniegt detalizētu produktu kategorijas analīzi, LLM var aktivizēt vektoru meklēšanu, lai identificētu konkrētas entītijas (produktus). Pēc tam orķestrētājs aktivizēs meklēšanu zināšanu grafā, lai atrastu saistītās entītijas, piemēram, piegādātājus, tirdzniecības vietas, atsauksmes un tā tālāk.

9. Sazarotā RAG

Kamēr hibrīdajai RAG arhitektūrai ir iespēja izmantot dažādas izguves metodes, sazarotā RAG apzīmē procesu, kurā vienlaikus tiek izpildīti vairāki vaicājumi, ko dēvē par zariem. Katrs zars var veikt vaicājumu atsevišķā informācijas avotā, vai arī zari var paralēli veikt vaicājumus vienā un tajā pašā avotā, izmantojot dažādus vaicājumus vai filtrus. Aģentiskajā RAG arhitektūrā bieži tiek izmantota sazarotā RAG.

10. HyDE (Hypothetical Document Embeddings — hipotētisko dokumentu iegulumi)

HyDE ir inovatīva RAG forma, kurā LLM izveido hipotētisku teksta dokumentu, kas atspoguļo, kā varētu izskatīties optimāla atbilde. Šis „hipotētiskais dokuments” pēc tam tiek izmantots, lai izveidotu vaicājumu precīzākai izguvei. Lai gan attiecīgās zināšanas nav atspoguļotas LLM parametros, pamatojums ir tāds, ka atbildei līdzīgs fragments var labāk atbilst attiecīgajiem dokumentiem nekā īss jautājums vai neskaidra uzvedne.

Vienkāršas RAG arhitektūras piemērs: vektoru datubāze

Pamata RAG kalpo par pamatu sarežģītākiem arhitektūras veidiem. Vienkāršā RAG sistēmā, kas izmanto vektoru datubāzi, avota dokumentācija tiek sadalīta mazākās daļās (fragmentos) un pārveidota blīvos iegulumos. Kad lietotājs ievada uzvedni, orķestrētājs ģenerē vaicājumu, to kodē un veic vaicājumu datubāzē, lai atrastu atbilstošus fragmentus.

Lūk, procesa izklāsts soli pa solim:

1. Lieli teksta apjomi tiek pārveidoti vektoros, izmantojot automatizētu uzņemšanas konveijeru un iegulšanas modeli, piemēram, BERT.
2. Datubāzes lietotne sakārto, indeksē un glabā vektorus ātrai meklēšanai.
3. Lietotājs ievada uzvedni tērzēšanas robotā (piemēram, Perplexity).
4. Lietotnes orķestrētājs kodē uzvedni (izmantojot iegulšanas modeli), lai izgūtu atbilstošu informāciju no vektoru datubāzes.
5. Vektoru datubāze atgriež atbilstošos fragmentus, un orķestrētājs pievieno tos ievades kontekstam („lielajai uzvednei”) un nodod to LLM.
6. LLM izmanto papildu kontekstu un savas iekšējās zināšanas (kas glabājas tā parametriskajos svaros), lai ģenerētu atbildi.

Izvērst

Uzlabotas RAG arhitektūras piemērs: aģentiskā RAG

Aģentiskā RAG apzīmē RAG sistēmu pamatā esošo arhitektūru aģentiskā platformā. Aģentiskās RAG plūsmas mēdz būt sarežģītas, jo MI aģenti atkarībā no uzvednes rakstura var izsaukt dažādus rīkus un konveijerus, vajadzības gadījumā izvietojot vairākus aģentus.

Lūk, praktisks procesa piemērs:

1. Lietotājs ievada sarežģītu jautājumu, kas prasa padziļinātu tēmas izpēti. Šajā piemērā pieņemsim, ka uzvedne ir: „Sniedz uzņēmuma peļņas prognozi nākamajiem sešiem mēnešiem, ņemot vērā nozīmīgākos ģeopolitiskos notikumus.”
2. LLM secina, ka būs nepieciešama RAG vaicājumu kombinācija dažādiem satura veidiem.
3. Tiek izvietoti trīs dažādi aģenti: (a) vektoru meklēšanai, (b) pamatošanai ar tīmekļa datiem un (c) attēlu (multimodālajai) meklēšanai.
4. Aģenti caur orķestrētāju, izmantojot pieejamos izguves rīkus, meklē atbilstošu informāciju, piemēram, ziņu rakstus un iekšējos finanšu datus.
5. LLM salīdzina izgūtos rezultātus ar katra aģenta pētījuma jautājumu un sarindo tos pēc atbilstības.
6. LLM izvērtē informāciju un, ja tās trūkst, aktivizē papildu meklēšanu ar atsevišķu aģentu starpniecību.
7. Kad ir izgūts pietiekami daudz informācijas, LLM ģenerē scenāriju prognozes, pamatojoties uz esošajiem finanšu rādītājiem (kas izgūti no iekšējās dokumentācijas), un izsauc kalkulatora rīku, lai prognozētu peļņu katram scenārijam.
8. LLM ģenerē galīgo atbildi, izmantojot izgūto informāciju un aprēķinus, un pēc vajadzības norāda avotus.

Izvērst

Kas RAG sagaida nākotnē?

Pašreizējās inovācijas ir vērstas uz to, lai esošajām RAG arhitektūrām piešķirtu dziļumu un ātrumu, uzlabotu multivides izguves precizitāti un veidotu sistēmas, kas spēj strādāt ar pašu jaunāko informāciju.

Lūk, trīs tendences, kas pašlaik nosaka pētniecības virzienu:

• Padziļināta izpēte vairākos avotos: Tā ir RAG arhitektūra, kas spēj plānot meklēšanu, izpildīt vairākus zarus dažādos avotos, izvērtēt izgūtos pierādījumus un pašoptimizēt ģenerētās atbildes. Aģentiskā RAG, kas spēj izpildīt visus šos uzdevumus, turpina kļūt ātrāka un izmaksu ziņā efektīvāka.
• Multimodāli lietojumi: Izguves konveijeri arvien labāk strādā ar attēliem un video. Tie arvien precīzāk spēj atrast konkrētus informācijas veidus sarežģītos multimodālos datos, piemēram, garos video un detalizētās diagrammās.
• Atbilžu pamatošana nepārtraukti mainīgā informācijā: LLM balstītas lietotnes var izmantot reāllaika informācijas avotus (piemēram, video plūsmas un sensorus), lai nodrošinātu ievades kontekstu. Sistēmas var arī veidot daudzpusīgus informācijas tīklus, piemēram, ar GraphRAG, lai interpretētu šos datus.

RAG ir LLM balstītu lietotņu darbības pamatā. Tā ļauj ļoti dažādiem lietotājiem — no ikdienas patērētājiem līdz uzņēmumiem, kas darbojas specializētās jomās, — pārvarēt problēmas, kas saistītas ar halucinācijām, nepilnīgiem apmācības datiem un piekļuves trūkumu specializētām iekšējām zināšanām.

Tāpēc RAG sistēmas un to pamatā esošā arhitektūra ir viena no visstraujāk mainīgajām un aizraujošākajām MI pētniecības jomām.