LLM zinaweza “kuona” kiasi kidogo tu cha maandishi kwa wakati mmoja (dirisha la muktadha). Hili linafaa kwa kazi ndogo, lakini hushindwa wakati hazina ya maarifa ina maelfu ya kurasa. Hata dirisha la muktadha linapotosha, utendaji bado unaweza kudhoofika kutokana na tatizo la “kutafuta sindano kwenye rundo la nyasi”.
RAG (‘uzalishaji ulioboreshwa kwa urejeshaji’) imekuwa mbinu ya kawaida sana ambapo unadumisha hazina ya maarifa (hati, wiki, sera, nakala za mazungumzo, n.k.), unafanya utafutaji wa kisemantiki kwa hoja ya mtumiaji ili kurejesha vijisehemu vinavyohusika zaidi kwa kutumia embeddings, kisha unaingiza vipande hivyo kwenye LLM pamoja na swali. Hili hudhibiti muktadha wa muundo na, likifanywa vizuri, linaweza kuboresha ubora wa majibu na kupunguza uzushi.
pgai ni kiendelezi huria cha Postgres (pamoja na zana zake) kinachokusaidia kuunda michakato ya “urejeshaji wa AI” juu ya hifadhidata huria inayoaminika ya PostgreSQL.
Wazo kuu ni kuhamishia sehemu kubwa zaidi ya mchakato wa kawaida wa RAG kwenye safu ya hifadhidata (ingiza → gawanya → unda embedding → sawazisha embeddings), badala ya kuichukulia hifadhidata kama “hifadhi tu” ya embeddings.
Maoni yetu ya awali ni kwamba ina matumaini, lakini haifai pindi tu mchakato wako wa RAG unapokuwa tata hata kidogo (hasa katika mbinu za kugawanya maudhui). Hata hivyo, tutafuatilia mradi huu kwa karibu.
Kuna njia nyingi za kuunda RAG. Kwa ufafanuzi mpana wa mbinu mbalimbali za RAG, soma Mifano Halisi ya Suluhisho Maalumu za RAG. Unapozingatia ubora, chaguo za usanifu huwa nyingi na tata zaidi ya inavyotarajiwa, na mbinu ya kawaida ya “chaguomsingi” kwa ujumla huwa hivi:
Kusanya hati nyingi.
Zigawanye katika vipande. Kuna mbinu nyingi tofauti za kufanya hivi (k.m. aya au makundi ya kisemantiki).
Geuza kila kipande kuwa embedding.
Hifadhi embeddings katika hifadhidata ya vekta (Pinecone, Milvus, n.k.) au katika Postgres kwa kutumia pgvector.
Wakati wa kushughulikia hoja, tafuta vipande vinavyokaribiana zaidi `na uvipitishe kwenye LLM (tena...kuna njia nyingi za kufanya hili pia).
Katika mifumo mingi, hatua za (1)–(3) hufanyika nje ya hifadhidata, katika msimbo wa programu au mchakato wa data, huku hifadhidata ikitumiwa hasa kwa:
kuhifadhi embeddings
kutafuta embeddings
pgai ni kiendelezi huria cha Postgres kilichotengenezwa na Timescale ambacho kinajaribu kuondoa mpaka huo.
Badala ya kuchukulia embeddings kama kitu ambacho programu yako inadhibiti mwenyewe, pgai huzifanya kuwa kipengele cha hifadhidata:
Unabainisha jedwali au hati unazotaka ziundwe embeddings.
Unabainisha muundo wa embedding na mkakati wa kugawanya maudhui.
pgai hushughulikia mengine, ikiwa ni pamoja na kusasisha embeddings kadiri data chanzo inavyobadilika.
Ahadi yake inavutia:
Msimbo maalumu wa kuunganisha vipengele unaohitaji kudumishwa unapungua.
Inapaswa kuwa rahisi zaidi kudumisha embeddings zikiwa ‘mpya’ kadiri hati za msingi zinavyobadilika.
Postgres/pgai hudhibiti majaribio yako ya kurudia, vikomo vya kasi, kazi zilizoshindwa, n.k.
Dokezo kwa msomaji: pgai inajumuisha pgvector (kiendelezi kingine maarufu sana cha Postgres kwa RAG). pgvector huongeza uhifadhi wa vekta na utafutaji wa ufanano kwenye Postgres, huku pgai ikitumia msingi huo kuendesha kiotomatiki hatua za RAG kama kugawanya maudhui, kuunda embeddings na kuzisasisha.
1) Ni rahisi kuanza kuitumia.
Mchakato unapokwenda vizuri ni rahisi kwa kiasi:
Pakua picha za Docker za Timescale (hifadhidata + worker).
Toa ufunguo wa API wa mtoa huduma wako wa embedding.
Tekeleza kiasi kidogo cha SQL ili kubainisha vectoriser (kimsingi: maudhui ya kuundia embedding, jinsi ya kuyagawa na muundo wa kutumia).
Baada ya hapo, pgai huwezesha worker ya vectoriser kufanya kazi kama mchakato tofauti na kuzalisha embeddings bila kusubiri (k.m. kila baada ya dakika 5, au kwa ratiba yoyote unayotaka).
2) Ni vizuri kutekeleza mchakato mzima “karibu” na hifadhidata.
pgai inaweza kuingiza maudhui kutoka kwenye majedwali na pia kupakia hati kutoka maeneo kama S3, kisha kuzichanganua, kuzigawanya na kuziundia embeddings. Pia inaweza kushughulikia miundo mbalimbali ya hati za maandishi kama PDF, Markdown, n.k.
1) Unapoteza udhibiti mwingi (na wakati mwingine RAG huhitaji udhibiti).
Mifumo ya RAG yenye utendaji wa juu (unapopimwa kwa ubora wa majibu) mara nyingi huhitaji michakato maalumu, kama vile:
kanuni maalumu za kugawanya maudhui (kwa vichwa, kurasa, zamu za wazungumzaji, n.k.)
kugawanya maudhui kwa kuzingatia metadata (hifadhi vichwa vya sehemu, mihuri ya muda, waandishi na aina ya hati)
mikakati tofauti ya embedding kwa kila aina ya hati
pgai ina unyumbufu mdogo zaidi katika mambo hayo.
Kwa sasa kuna mikakati miwili mikuu ya kugawanya maudhui: kigawanyaji cha maandishi kwa herufi na kigawanyaji rejeshi cha maandishi kwa herufi, pamoja na chaguo la kutogawanya. Hilo linaweza kutosha kwa baadhi ya matumizi, lakini mifumo mingi ya RAG ya uzalishaji huhitaji ubinafsishaji zaidi.
Ingependeza kuona Timescale ikijumuisha baadhi ya mikakati ya hali ya juu zaidi ya kugawanya maudhui inayopatikana katika maktaba kama Chonkie, na vilevile kuwezesha miundo ya kina kama urejeshaji wa kimuktadha wa Anthropic.
2) Inatanguliza maandishi, si modi nyingi.
Matatizo mengi ya kuvutia ya RAG hayahusu maandishi pekee tena:
PDF zenye michoro
picha za skrini / picha
rekodi za sauti
vipande vya video
Hata ukiweza “kutoa maandishi” kutoka kwenye vyanzo hivi, hiyo si sawa na mchakato halisi wa embedding wa modi nyingi.
Iwapo hatimaye pgai itawezesha miundo ya modi nyingi kuanzia mwanzo hadi mwisho (kupakia → kugawanya → kuunda embedding kwa picha kubwa, sauti au video zilizohifadhiwa kwenye S3, kwa usawazishaji thabiti), hilo litavutia; lakini leo ni mchakato wa embedding za maandishi.
3) Ikiwa unahitaji embeddings pekee, huenda usihitaji pgai.
Ikiwa mchakato wako wa kuingiza data tayari ni maalumu (au unahitaji kuwa hivyo), basi “kuunda embeddings za vipande vya maandishi” si sehemu ngumu zaidi ya RAG. Katika hali hiyo, pgai inatatua sehemu rahisi zaidi ya tatizo.
Pia, ikiwa hazina yako ya maarifa husasishwa mara chache, manufaa ya kusawazisha embeddings kiotomatiki si makubwa sana.
Njia moja nzuri sana ya kutumia pgai ni kuweka kiolesura cha text-to-SQL juu ya hifadhidata zako. Hili linaweza kufanywa kwa urahisi kwa kutumia moduli ya semantic_catalog inayotolewa na pgai. Isanidi tu hivi:
Bash
kisha ruhusu semantic catalog ichukue kamusi zako za data kwa kutumia pgai semantic-catalog create. Hii huzalisha muktadha kutoka kwenye hifadhi yako ya data unaofanana na huu:
Plain Text
Sasa pgai inaweza kutumia muktadha huu kwa njia mbalimbali;
Kupitia utafutaji wa kisemantiki:
Hoja hii itarejesha majedwali, vitendaji na vitu vingine vinavyoweza kuhusiana na hoja yako ya lugha asilia:
Bash
Pata muktadha ghafi:
Hii itaonyesha muktadha ghafi wa YAML unaohusiana na hoja yako ya lugha asilia:
Bash
Zalisha SQL:
Au unaweza kuzalisha moja kwa moja SQL ghafi inayohitajika kujibu hoja yako. Muktadha kutoka hatua iliyotangulia hutumwa kwa LLM, kisha jibu huzalishwa:
Bash
Ikiwa unaunda mfumo rahisi wa RAG, inafaa kujaribu pgai iwapo unataka:
Postgres iwe mfumo wako rasmi wa kuhifadhi rekodi,
msimbo mdogo wa kuunganisha vipengele,
embeddings zinazosawazishwa kiotomatiki,
njia ya haraka ya kutumia text-to-SQL kwenye hifadhidata zako,
kujaribu zana mpya za RAG na viendelezi vya Postgres.
Huenda ikafaa kusubiri kabla ya kutumia pgai ikiwa mchakato wako wa RAG unahitaji mojawapo ya yafuatayo:
mantiki nyingi maalumu za kuingiza au kugawanya maudhui
aina nyingi za hati zenye mahitaji tofauti ya uchanganuzi
embeddings za modi nyingi
Mwisho, ingawa ni wazi kuwa pgvector imetumiwa kwa kiwango kikubwa, haijulikani ikiwa pgai itapata kiwango sawa cha kuvutiwa na hivyo kuungwa mkono (licha ya kwamba imekuwapo kwa takribani miezi 18 pekee).
pgai ni mbinu ya kuvutia ya RAG inayoruhusu hifadhidata kufanya zaidi ya kazi za kawaida za uendeshaji, ili msimbo wa programu yako uwe rahisi zaidi.
Kwa sasa:
inaweza kutumika na inapendeza kwa mifumo rahisi ya RAG
haina unyumbufu wa kutosha kwa michakato maalumu zaidi (hasa ya modi nyingi)
Inaonyesha matumaini na bila shaka inafaa kufuatiliwa ili kuona jinsi itakavyoendelea.