LLM-të mund të «shohin» njëherësh vetëm një sasi të kufizuar teksti (dritare konteksti). Kjo funksionon për detyra të vogla, por jo kur një bazë njohurish përfshin mijëra faqe. Edhe kur dritare konteksti është e mjaftueshme, performanca mund të bjerë për shkak të problemit të «gjilpërës në kashtë».
RAG («gjenerimi i përforcuar nga kërkimi») është bërë një model pune shumë i zakonshëm: mirëmbani një bazë njohurish (dokumente, wiki, politika, transkripte etj.), kryeni një kërkim semantik për pyetjen e përdoruesit që të merrni fragmentet më të rëndësishme përmes embedding-eve dhe më pas ia jepni ato LLM-së bashkë me pyetjen. Kjo kufizon kontekstin e modelit dhe, kur zbatohet siç duhet, mund të përmirësojë cilësinë e përgjigjeve dhe të pakësojë halucinacionet.
pgai është një shtesë me burim të hapur për Postgres (bashkë me mjetet shoqëruese), që ju ndihmon të ndërtoni flukse pune të «kërkimit me AI» mbi bazën e besuar të të dhënave me burim të hapur PostgreSQL.
Ideja kryesore është që një pjesë më e madhe e procesit standard RAG të kalojë në shtresën e bazës së të dhënave (marrje → ndarje në fragmente → embedding → sinkronizim i embedding-eve), në vend që baza e të dhënave të trajtohet «vetëm si hapësirë ruajtjeje» për embedding-et.
Përshtypjet e para janë premtuese, por sapo procesi juaj RAG bëhet sadopak kompleks, veçanërisht për mënyrat e ndarjes në fragmente, pgai nuk është më i përshtatshëm. Megjithatë, do ta ndjekim nga afër këtë projekt.
Ka shumë mënyra për të ndërtuar RAG. Për një analizë më të hollësishme të qasjeve të ndryshme, lexoni Shembuj praktikë të zgjidhjeve RAG të personalizuara. Kur cilësia ka rëndësi, mundësitë e projektimit bëhen çuditërisht të ndërlikuara, ndërsa qasja e zakonshme «e parazgjedhur» është përgjithësisht kjo:
Merrni një grumbull dokumentesh.
Ndajini në fragmente. Ka shumë mënyra të ndryshme për ta bërë këtë (p.sh. sipas paragrafëve ose grupimeve semantike).
Kthejeni çdo fragment në një embedding.
Ruajini embedding-et në një bazë të dhënash vektoriale (Pinecone, Milvus etj.) ose në Postgres duke përdorur pgvector.
Kur bëhet një pyetje, kërkoni fragmentet më të afërta `dhe ia kaloni LLM-së (sërish... edhe kjo mund të bëhet në shumë mënyra).
Në shumë arkitektura, hapat (1)–(3) kryhen jashtë bazës së të dhënave, në kodin e aplikacionit ose në një proces të dhënash, ndërsa baza e të dhënave përdoret kryesisht për:
ruajtjen e embedding-eve
kërkimin në embedding-e
pgai është një shtesë me burim të hapur për Postgres, e zhvilluar nga Timescale, që përpiqet ta zbehë këtë ndarje.
Në vend që embedding-et të trajtohen si diçka që aplikacioni juaj e administron manualisht, pgai i bën ato një funksion të bazës së të dhënave:
Përcaktoni tabelën ose dokumentet për të cilat dëshironi të krijohen embedding-e.
Përcaktoni modelin e embedding-ut dhe një strategji për ndarjen në fragmente.
pgai administron pjesën tjetër, duke përfshirë përditësimin e embedding-eve sa herë që ndryshojnë të dhënat burimore.
Premtimi është tërheqës:
Më pak kod lidhës i personalizuar për t’u mirëmbajtur.
Duhet të jetë më e lehtë që embedding-et të mbeten «të freskëta» kur ndryshojnë dokumentet burimore.
Postgres/pgai administron riprovimet, kufijtë e kërkesave, detyrat e dështuara etj.
Shënim për lexuesin: pgai përfshin pgvector (një tjetër shtesë shumë të përdorur për RAG në Postgres). pgvector i shton Postgres-it ruajtjen e vektorëve dhe kërkimin sipas ngjashmërisë, ndërsa pgai mbështetet tek ai për të automatizuar hapa të procesit RAG, si ndarja në fragmente, krijimi i embedding-eve dhe përditësimi i tyre.
1) Vihet lehtësisht në punë.
Rasti tipik është relativisht i thjeshtë:
Shkarkoni imazhet Docker të Timescale (bazën e të dhënave + worker-in).
Jepni çelësin API të ofruesit të embedding-eve.
Ekzekutoni pak kod SQL për të deklaruar vectoriser-in (në thelb: çfarë të kthehet në embedding, si të ndahet në fragmente dhe cili model të përdoret).
Më pas, pgai cakton një worker të vectoriser-it që të ekzekutohet si proces më vete dhe të krijojë embedding-e në mënyrë asinkrone (p.sh. çdo 5 minuta ose me çfarëdo intervali që dëshironi).
2) Është praktike që i gjithë procesi të kryhet «pranë» bazës së të dhënave.
pgai mund të marrë përmbajtje nga tabelat, si edhe të ngarkojë dokumente nga vende si S3, e më pas t’i analizojë, t’i ndajë në fragmente dhe të krijojë embedding-et e tyre. Mund të përpunojë edhe formate të ndryshme dokumentesh tekstuale, si PDF, Markdown etj.
1) Humbni shumë kontroll (dhe RAG ndonjëherë kërkon kontroll).
Sistemet RAG me performancë të lartë, matur sipas cilësisë së përgjigjeve, shpesh kërkojnë procese të personalizuara, si:
rregulla të personalizuara për ndarjen në fragmente (sipas titujve, faqes, radhës së folësve etj.)
ndarje në fragmente që merr parasysh metadatat (ruan titujt e seksioneve, vulat kohore, autorët dhe llojin e dokumentit)
strategji të ndryshme embedding-u për çdo lloj dokumenti
pgai ofron më pak fleksibilitet për sa më sipër.
Aktualisht ka dy strategji kryesore për ndarjen në fragmente: ndarësi i tekstit sipas karaktereve dhe ndarësi rekursiv sipas karaktereve, si edhe mundësia për të mos bërë fare ndarje. Kjo mund të mjaftojë për disa raste përdorimi, por shumë sisteme RAG në prodhim kërkojnë më tepër personalizim.
Do të ishte fantastike nëse Timescale do të përfshinte disa nga strategjitë më të sofistikuara të ndarjes në fragmente që shohim në biblioteka si Chonkie dhe të mbështeste gjithashtu modele të avancuara si kërkimi kontekstual i Anthropic.
2) Në radhë të parë për tekst, jo multimodal.
Shumë probleme interesante të RAG nuk kufizohen më vetëm te teksti:
PDF me diagrame
pamje ekrani/imazhe
regjistrime audio
videoklipe
Edhe nëse mund të «nxirrni tekst» nga këto burime, kjo nuk është njësoj si një proces i mirëfilltë multimodal embedding-u.
Nëse pgai do të mbështeste në të ardhmen modelet multimodale nga fillimi në fund (ngarkim → ndarje në fragmente → embedding për imazhe të mëdha, audio dhe video të ruajtura në S3, me sinkronizim të besueshëm), kjo do të ishte tërheqëse; por sot është një proces embedding-u për tekst.
3) Nëse ju duhen vetëm embedding-e, mund të mos ju nevojitet pgai.
Nëse procesi juaj i marrjes së të dhënave është tashmë i personalizuar (ose duhet të jetë), atëherë «krijimi i embedding-eve nga fragmentet e tekstit» nuk është pjesa më e vështirë e RAG. Në këtë rast, pgai zgjidh pjesën më të lehtë të problemit.
Gjithashtu, nëse baza juaj e njohurive përditësohet rrallë, sinkronizimi automatik i embedding-eve nuk ka aq shumë vlerë.
Një mënyrë veçanërisht e mirë për ta përdorur pgai do të ishte vendosja e një ndërfaqeje text-to-sql mbi bazat tuaja të të dhënave. Kjo mund të realizohet mjaft lehtë me modulin semantic_catalog që ofron pgai. Mjafton ta konfiguroni kështu:
Bash
dhe ta bëni katalogun semantik të mbledhë fjalorët tuaj të të dhënave me pgai semantic-catalog create. Kjo gjeneron kontekst nga depoja juaj e të dhënave, i cili duket afërsisht kështu:
Plain Text
Ky kontekst tani është i disponueshëm për pgai në disa mënyra:
Përmes kërkimit semantik:
Kjo kërkesë do të kthejë tabelat, funksionet dhe objektet e tjera që mund të lidhen me pyetjen tuaj në gjuhë natyrore:
Bash
Merrni kontekstin e papërpunuar:
Kjo do të paraqesë kontekstin e papërpunuar YAML që lidhet me pyetjen tuaj në gjuhë natyrore:
Bash
Gjeneroni SQL:
Ose mund të gjeneroni drejtpërdrejt kodin e papërpunuar SQL që nevojitet për t’iu përgjigjur pyetjes suaj. Konteksti nga hapi i mëparshëm i dërgohet një LLM-je dhe gjenerohet përgjigjja:
Bash
Nëse po ndërtoni një sistem relativisht të thjeshtë RAG, ia vlen ta provoni pgai nëse dëshironi:
Postgres si sistemin tuaj zyrtar të të dhënave,
sa më pak kod lidhës,
embedding-e që sinkronizohen automatikisht,
një mënyrë të shpejtë për të zbatuar text-to-SQL në bazat tuaja të të dhënave,
të eksperimentoni me mjete të reja RAG dhe shtesa për Postgres.
Ndoshta ia vlen të prisni ende për pgai nëse procesi juaj RAG kërkon ndonjërën nga këto:
logjikë shumë të personalizuar për marrjen ose ndarjen e të dhënave në fragmente
shumë lloje dokumentesh me kërkesa të ndryshme për analizimin
embedding-e multimodale
Së fundi, ndonëse pgvector është përdorur gjerësisht, nuk dihet nëse pgai do të tërheqë të njëjtin interes e, rrjedhimisht, të njëjtën mbështetje (duke pasur parasysh se ekziston vetëm prej rreth 18 muajsh).
pgai është një qasje interesante ndaj RAG, që u lejon bazave të të dhënave të kryejnë më shumë nga puna rutinë operative, duke e bërë më të thjeshtë kodin e aplikacionit.
Aktualisht është:
i përdorshëm dhe vërtet praktik për konfigurime të thjeshta RAG
jo mjaftueshëm fleksibël për procese më të personalizuara (sidomos multimodale)
Duket premtues dhe patjetër ia vlen të ndiqet për të parë si do të zhvillohet.