LLM-ovi mogu odjednom „vidjeti“ samo ograničenu količinu teksta (kontekstni prozor). To funkcionira za male zadatke, ali ne i kada baza znanja obuhvata hiljade stranica. Čak i kada je kontekstni prozor dovoljan, performanse se mogu smanjiti zbog problema „traženja igle u plastu sijena“.
RAG („generiranje potpomognuto pretraživanjem“) postao je vrlo čest obrazac: održavate bazu znanja (dokumente, wikije, pravila, transkripte itd.), pokrećete semantičko pretraživanje korisničkog upita kako biste pomoću embeddinga pronašli najrelevantnije isječke, a zatim te dijelove zajedno s pitanjem prosljeđujete LLM-u. Time se ograničava kontekst modela te se, uz pravilnu izvedbu, može poboljšati kvalitet odgovora i smanjiti broj halucinacija.
pgai je Postgres ekstenzija otvorenog koda (uz prateće alate) koja pomaže u izradi tokova rada za „AI pretraživanje“ na pouzdanoj bazi podataka otvorenog koda PostgreSQL.
Glavna je ideja premjestiti veći dio standardnog RAG procesa u sloj baze podataka (unos → podjela → embedding → sinhronizacija embeddinga), umjesto da se baza tretira kao „samo spremište“ embeddinga.
Prvi utisci su obećavajući, ali čim RAG proces postane iole složeniji, naročito kada je riječ o pristupima podjeli sadržaja, pgai više nije prikladan. Ipak, pažljivo ćemo pratiti ovaj projekt.
RAG se može izraditi na mnogo načina. Za detaljniji pregled različitih pristupa pročitajte Praktični primjeri prilagođenih RAG rješenja. Kada je kvalitet važan, mogućnosti dizajna postaju iznenađujuće složene, a uobičajeni „zadani“ pristup uglavnom izgleda ovako:
Prikupite dokumente.
Podijelite ih na dijelove. Postoje brojne metode za to (npr. prema odlomcima ili semantičkim grupama).
Pretvorite svaki dio u embedding.
Pohranite embeddinge u vektorsku bazu podataka (Pinecone, Milvus itd.) ili u Postgres pomoću pgvectora.
Pri obradi upita pronađite najsličnije dijelove `i proslijedite ih LLM-u (i za ovo, opet, postoji mnogo načina).
U mnogim tehnološkim sistemima koraci (1)–(3) odvijaju se izvan baze podataka, u aplikacijskom kodu ili podatkovnom procesu, dok se baza uglavnom koristi za:
pohranu embeddinga
pretraživanje embeddinga
pgai je Postgres ekstenzija otvorenog koda koju je razvio Timescale) i koja pokušava izbrisati tu granicu.
Umjesto da embeddinge tretira kao nešto čime aplikacija mora ručno upravljati, pgai ih pretvara u funkciju baze podataka:
Odredite koju tabelu ili dokumente želite pretvoriti u embeddinge.
Odredite model za embedding i strategiju podjele sadržaja.
pgai upravlja svime ostalim, uključujući ažuriranje embeddinga kada se izvorni podaci promijene.
Obećane prednosti zvuče privlačno:
Manje namjenskog poveznog koda koji treba održavati.
Embeddinge bi trebalo biti lakše održavati „svježima“ dok se izvorni dokumenti mijenjaju.
Postgres/pgai upravlja ponovnim pokušajima, ograničenjima učestalosti, neuspjelim poslovima itd.
Napomena za čitaoce: pgai u sebi sadrži pgvector, još jednu vrlo popularnu Postgres ekstenziju za RAG. pgvector Postgresu dodaje vektorsku pohranu i pretraživanje po sličnosti, dok pgai na tome gradi automatizaciju koraka RAG procesa, poput podjele sadržaja, izrade embeddinga i njihovog ažuriranja.
1) Jednostavno ga je pokrenuti.
U idealnim uvjetima postupak je prilično jednostavan:
Preuzmite Timescale Docker slike (baza podataka + izvršni proces).
Unesite API ključ pružaoca embeddinga.
Pokrenite nekoliko SQL naredbi za definiranje vektorizatora (odnosno: šta pretvoriti u embeddinge, kako podijeliti sadržaj i koji model koristiti).
Nakon toga pgai organizira pokretanje izvršnog procesa vektorizatora kao zasebnog procesa koji asinhrono generira embeddinge (npr. svakih 5 minuta ili u ritmu koji odaberete).
2) Praktično je provoditi cijeli proces „blizu“ baze podataka.
pgai može unositi sadržaj iz tabela, ali i učitavati dokumente s lokacija poput S3 te ih analizirati, podijeliti i pretvoriti u embeddinge. Može obrađivati i različite formate tekstualnih dokumenata, kao što su PDF, Markdown itd.
1) Gubite mnogo kontrole, a RAG je ponekad zahtijeva.
RAG sistemi visokih performansi, mjereno kvalitetom odgovora, često zahtijevaju namjenske procese, kao što su:
prilagođena pravila podjele sadržaja (prema naslovima, stranicama, promjenama govornika itd.)
podjela sadržaja koja uzima u obzir metapodatke (zadržava naslove odjeljaka, vremenske oznake, autore i vrstu dokumenta)
različite strategije embeddinga za svaku vrstu dokumenta
pgai nudi manje fleksibilnosti za navedene potrebe.
Trenutno postoje dvije glavne strategije podjele sadržaja: razdjelnik teksta prema broju znakova i rekurzivni razdjelnik prema broju znakova, kao i opcija bez podjele. To može biti dovoljno za neke slučajeve upotrebe, ali mnogi produkcijski RAG sistemi zahtijevaju veću prilagodbu.
Bilo bi sjajno kada bi Timescale mogao uvesti neke od naprednijih strategija podjele sadržaja kakve nalazimo u bibliotekama poput Chonkieja te podržati napredne koncepte poput Anthropicovog kontekstualnog pretraživanja.
2) Prvenstveno za tekst, a ne za multimodalni sadržaj.
Mnogi zanimljivi RAG problemi više nisu isključivo tekstualni:
PDF dokumenti s dijagramima
snimci ekrana / slike
audiosnimci
videoisječci
Čak i ako iz tih izvora možete „izvući tekst“, to nije isto što i istinski multimodalni proces izrade embeddinga.
Ako pgai s vremenom uvede sveobuhvatnu podršku za multimodalne modele (učitavanje → podjela → embedding velikih slika te audiozapisa i videozapisa pohranjenih u S3, uz pouzdanu sinhronizaciju), to bi bilo vrlo privlačno. Danas je, međutim, riječ o procesu za tekstualne embeddinge.
3) Ako su vam potrebni samo embeddingi, pgai vam možda nije potreban.
Ako je vaš proces unosa već prilagođen ili to mora biti, „pretvaranje dijelova teksta u embeddinge“ nije najteži dio RAG-a. U takvom okruženju pgai rješava najlakši dio problema.
Osim toga, ako se baza znanja rijetko ažurira, automatska sinhronizacija embeddinga nije toliko vrijedna.
Posebno dobar način upotrebe pgai-ja bio bi postavljanje interfejsa za pretvaranje teksta u SQL iznad vaših baza podataka. To se prilično jednostavno može postići pomoću modula semantic_catalog koji nudi pgai. Jednostavno ga postavite ovako:
Bash
zatim omogućite semantičkom katalogu da pregleda vaše rječnike podataka naredbom pgai semantic-catalog create. Time se iz vašeg spremišta podataka generira kontekst koji izgleda otprilike ovako:
Plain Text
Ovaj kontekst sada je dostupan pgai-ju na više načina:
Putem semantičkog pretraživanja:
Ovaj će upit vratiti tabele, funkcije i druge objekte koji bi mogli biti relevantni za vaš upit na prirodnom jeziku:
Bash
Dohvatanje sirovog konteksta:
Time će se prikazati sirovi YAML kontekst povezan s vašim upitom na prirodnom jeziku:
Bash
Generiranje SQL-a:
Možete i direktno generirati sirovi SQL potreban za odgovor na upit. Kontekst iz prethodnog koraka šalje se LLM-u, nakon čega se generira odgovor:
Bash
Ako izrađujete relativno jednostavan RAG sistem, vrijedi isprobati pgai ako želite:
Postgres kao glavni sistem evidencije,
što manje poveznog koda,
embeddinge koji automatski ostaju sinhronizirani,
brz način primjene pretvaranja teksta u SQL na baze podataka,
eksperimentiranje s novim RAG alatima i Postgres ekstenzijama.
Vjerovatno vrijedi pričekati s pgai-jem ako vaš RAG proces zahtijeva nešto od sljedećeg:
opsežnu prilagođenu logiku unosa ili podjele sadržaja
mnoštvo vrsta dokumenata s različitim zahtjevima za analizu
multimodalne embeddinge
Na kraju, iako je jasno da je pgvector široko prihvaćen, nije jasno hoće li pgai privući isti nivo interesa, a time i podrške, bez obzira na to što postoji tek oko 18 mjeseci.
pgai je zanimljiv pristup RAG-u koji bazama podataka prepušta veći dio rutinskih operativnih poslova, čime aplikacijski kod postaje jednostavniji.
Trenutno je:
upotrebljiv i zaista ugodan za jednostavne RAG postavke
nedovoljno fleksibilan za prilagođenije procese, naročito multimodalne
Obećava i svakako vrijedi pratiti njegov daljnji razvoj.