LVM vienlaikus var „redzēt“ tikai ierobežotu teksta apjomu (konteksta logu). Ar to pietiek nelieliem uzdevumiem, taču šī pieeja vairs nedarbojas, ja zināšanu bāze aptver tūkstošiem lapu. Pat ja konteksta logs ir pietiekams, veiktspēja tik un tā var pasliktināties tā dēvētās „adatas siena kaudzē“ problēmas dēļ.
RAG („ģenerēšana ar informācijas izgūšanu“) ir kļuvusi par ļoti izplatītu pieeju: tiek uzturēta zināšanu bāze (dokumenti, vikivietnes, politikas, transkripti u. c.), lietotāja vaicājumam tiek veikta semantiskā meklēšana, ar iegultņu palīdzību atrodot atbilstošākos fragmentus, un šie fragmenti kopā ar jautājumu tiek nodoti LVM. Tas ierobežo modelim nodoto kontekstu un, ja izdarīts pareizi, var uzlabot atbilžu kvalitāti un samazināt halucinācijas.
pgai ir atvērtā pirmkoda Postgres paplašinājums (un pavadošo rīku kopums), kas palīdz veidot „MI informācijas izgūšanas“ darbplūsmas uz uzticamās atvērtā pirmkoda datubāzes PostgreSQL pamata.
Galvenā ideja ir lielāku daļu standarta RAG konveijera pārcelt uz datubāzes slāni (ielāde → sadalīšana fragmentos → iegulšana → iegultņu sinhronizēšana), nevis izmantot datubāzi „tikai iegultņu glabāšanai“.
Sākotnējais iespaids ir daudzsološs, taču, tiklīdz RAG konveijers kļūst kaut nedaudz sarežģīts, īpaši fragmentu veidošanas ziņā, šis risinājums vairs nav piemērots. Tomēr mēs rūpīgi sekosim šā projekta attīstībai.
RAG var veidot daudzos veidos. Plašāku dažādu RAG pieeju apskatu skatiet rakstā Praktiski pielāgotu RAG risinājumu piemēri. Kad svarīga kļūst kvalitāte, iespējamo risinājumu klāsts izrādās pārsteidzoši plašs, bet ierastā „noklusējuma“ pieeja parasti ir šāda:
Paņemiet dokumentu kopumu.
Sadaliet tos fragmentos. To var izdarīt daudzos veidos, piemēram, dalot rindkopās vai semantiskās grupās.
Pārvērtiet katru fragmentu iegultnī.
Glabājiet iegultņus vektoru datubāzē (Pinecone, Milvus u. c.) vai Postgres, izmantojot pgvector.
Vaicājuma izpildes laikā atrodiet tuvākos fragmentus `un nododiet tos LVM (arī to var izdarīt daudzos veidos).
Daudzās tehnoloģiju kopās 1.–3. darbība notiek ārpus datubāzes — lietotnes kodā vai datu konveijerā —, bet datubāzi galvenokārt izmanto, lai:
glabātu iegultņus
meklētu iegultņus
pgai ir Postgres paplašinājums (atvērtā pirmkoda, ko izstrādā Timescale), kura mērķis ir mazināt šo nošķīrumu.
Tā vietā, lai iegultņus manuāli pārvaldītu lietotne, pgai tos padara par datubāzes funkciju:
Jūs norādāt, kuru tabulu vai dokumentus vēlaties iegult.
Jūs norādāt iegulšanas modeli un fragmentu veidošanas stratēģiju.
Par pārējo parūpējas pgai, tostarp atjaunina iegultņus, kad mainās avota dati.
Ieguvumi šķiet vilinoši:
Mazāk īpaši pielāgota integrācijas koda, kas jāuztur.
Mainoties avota dokumentiem, iegultņus vajadzētu būt vieglāk uzturēt aktuālus.
Postgres/pgai pārvalda atkārtotus mēģinājumus, ātruma ierobežojumus, neizdevušos uzdevumus u. c.
Piezīme lasītājam: pgai komplektācijā ir iekļauts pgvector — vēl viens ļoti populārs RAG paplašinājums sistēmai Postgres. pgvector papildina Postgres ar vektoru glabāšanu un līdzības meklēšanu, savukārt pgai uz tā pamata automatizē tādas RAG konveijera darbības kā fragmentu veidošana, iegulšana un iegultņu atjaunināšana.
1) To ir vienkārši palaist.
Standarta scenārijs ir samērā vienkāršs:
Lejupielādējiet Timescale Docker attēlus (datubāzi un darbinātāju).
Norādiet iegulšanas pakalpojuma sniedzēja API atslēgu.
Izpildiet nelielu SQL koda apjomu, lai definētu vektorizētāju — ko iegult, kā sadalīt fragmentos un kuru modeli izmantot.
Pēc tam pgai atsevišķā procesā palaiž vektorizētāja darbinātāju, kas asinhroni ģenerē iegultņus, piemēram, ik pēc piecām minūtēm vai citā izvēlētā intervālā.
2) Ir ērti visu konveijeru darbināt datubāzes „tuvumā“.
pgai var uzņemt saturu no tabulām, kā arī ielādēt dokumentus no tādiem avotiem kā S3 un pēc tam tos parsēt, sadalīt fragmentos un iegult. Tas atbalsta arī dažādus teksta dokumentu formātus, piemēram, PDF un Markdown.
1) Jūs zaudējat lielu daļu kontroles, bet RAG dažkārt tā ir vajadzīga.
RAG sistēmām ar augstu veiktspēju — vērtējot pēc atbilžu kvalitātes — bieži nepieciešami īpaši pielāgoti konveijeri, piemēram:
pielāgoti fragmentu veidošanas noteikumi (pēc virsrakstiem, lapām, runātāju maiņas u. c.)
metadatus ņemoša vērā fragmentu veidošana (saglabājot sadaļu virsrakstus, laikspiedolus, autorus un dokumenta tipu)
atšķirīgas iegulšanas stratēģijas katram dokumentu tipam
Iepriekš minētajās jomās pgai piedāvā mazāku elastību.
Pašlaik ir divas galvenās fragmentu veidošanas stratēģijas: teksta dalītājs pēc rakstzīmēm un rekursīvs teksta dalītājs pēc rakstzīmēm. Var izvēlēties arī tekstu nedalīt. Dažiem lietojumiem ar to varētu pietikt, taču daudzām ražošanas RAG sistēmām nepieciešamas plašākas pielāgošanas iespējas.
Būtu lieliski, ja Timescale varētu iekļaut sarežģītākas fragmentu veidošanas stratēģijas, kādas atrodamas tādās bibliotēkās kā Chonkie, un līdzīgi atbalstīt progresīvus risinājumus, piemēram, Anthropic kontekstuālo informācijas izgūšanu.
2) Vispirms teksts, nevis multimodalitāte.
Daudzas interesantas RAG problēmas vairs nav saistītas tikai ar tekstu:
PDF dokumenti ar diagrammām
ekrānuzņēmumi un attēli
audioieraksti
videoklipi
Pat ja no šiem avotiem var „izvilkt tekstu“, tas nav tas pats, kas īsts multimodāls iegulšanas konveijers.
Ja pgai nākotnē pilnā ciklā atbalstītu multimodālus modeļus — S3 glabātu lielu attēlu, audio un video ielādi, sadalīšanu fragmentos un iegulšanu ar uzticamu sinhronizāciju —, tas būtu pārliecinošs risinājums. Taču pašlaik tā ir teksta iegulšanas darbplūsma.
3) Ja jums vajadzīgi tikai iegultņi, pgai var nebūt nepieciešams.
Ja jūsu datu uzņemšanas konveijers jau ir pielāgots vai tādam jābūt, „teksta fragmentu iegulšana“ nav RAG sarežģītākā daļa. Šādā situācijā pgai atrisina problēmas vienkāršāko daļu.
Turklāt, ja zināšanu bāzi atjaunina reti, automātiska iegultņu sinhronizēšana nav tik vērtīga.
Īpaši labs pgai lietojums būtu teksta pārveidošanas par SQL saskarnes izvietošana virs jūsu datubāzēm. To var diezgan vienkārši panākt ar pgai piedāvāto semantic_catalog moduli. Vienkārši konfigurējiet to šādi:
Bash
Pēc tam lieciet semantiskajam katalogam nolasīt jūsu datu vārdnīcas ar pgai semantic-catalog create. Tādējādi no jūsu datu krātuves tiek ģenerēts aptuveni šāds konteksts:
Plain Text
Tagad šis konteksts pgai ir pieejams vairākos veidos:
Izmantojot semantisko meklēšanu:
Šis vaicājums atgriezīs tabulas, funkcijas un citus objektus, kas varētu būt saistīti ar jūsu dabiskās valodas vaicājumu:
Bash
Iegūstot neapstrādāto kontekstu:
Tiks atveidots ar jūsu dabiskās valodas vaicājumu saistītais neapstrādātais YAML konteksts:
Bash
Ģenerējot SQL:
Varat arī tieši ģenerēt neapstrādāto SQL kodu, kas vajadzīgs atbildes iegūšanai uz jūsu vaicājumu. Iepriekšējā darbībā iegūtais konteksts tiek nosūtīts LVM, kas ģenerē atbildi:
Bash
Ja veidojat samērā vienkāršu RAG sistēmu, pgai ir vērts izmēģināt, ja vēlaties:
izmantot Postgres kā galveno datu avotu;
iztikt ar minimālu integrācijas koda apjomu;
automātiski sinhronizēt iegultņus;
ātri ieviest teksta pārveidošanu par SQL savās datubāzēs;
izmēģināt jaunus RAG rīkus un Postgres paplašinājumus.
Ar pgai, visticamāk, ir vērts nogaidīt, ja jūsu RAG konveijeram vajadzīgs kaut kas no tālāk minētā:
plaši pielāgota datu uzņemšanas vai fragmentu veidošanas loģika
daudzi dokumentu tipi ar atšķirīgām parsēšanas prasībām
multimodāli iegultņi
Visbeidzot, lai gan pgvector nepārprotami ir guvis plašu popularitāti, nav skaidrs, vai pgai izraisīs tikpat lielu interesi un attiecīgi saņems līdzvērtīgu atbalstu, ņemot vērā arī to, ka tas pastāv tikai aptuveni 18 mēnešus.
pgai piedāvā interesantu RAG pieeju, ļaujot datubāzēm veikt vairāk ikdienas operatīvā darba un tādējādi vienkāršojot lietotnes kodu.
Pašlaik tas ir:
lietojams un patiešām ērts vienkāršām RAG konfigurācijām
nepietiekami elastīgs īpaši pielāgotiem konveijeriem, sevišķi multimodāliem
Tas ir daudzsološs, un noteikti ir vērts sekot līdzi tā attīstībai.