LLM-ovi odjednom mogu „vidjeti” samo ograničenu količinu teksta (kontekstni prozor). To funkcionira za manje zadatke, ali ne i kada baza znanja obuhvaća tisuće stranica. Čak i kada je kontekstni prozor dovoljno velik, rezultati se mogu pogoršati zbog problema „traženja igle u plastu sijena”.
RAG („generiranje prošireno dohvaćanjem”) postao je vrlo čest obrazac: održavate bazu znanja (dokumente, wikije, pravila, transkripte itd.), semantički pretražujete korisnički upit kako biste pomoću ugradnji dohvatili najrelevantnije isječke, a zatim te dijelove zajedno s pitanjem šaljete LLM-u. Time se ograničava kontekst modela, a uz pravilnu izvedbu mogu se poboljšati odgovori i smanjiti halucinacije.
pgai je proširenje otvorenog koda za Postgres (uz pripadajuće alate) koje omogućuje izradu tijekova rada za „AI dohvaćanje” na pouzdanoj bazi podataka otvorenog koda PostgreSQL.
Glavna je zamisao premjestiti veći dio standardnog RAG procesa u sloj baze podataka (unos → podjela → ugradnja → sinkronizacija ugradnji), umjesto da se baza smatra „samo spremištem” ugradnji.
Prvi su dojmovi obećavajući, no alat više nije prikladan čim se RAG proces iole zakomplicira, osobito u pogledu podjele sadržaja. Ipak, pomno ćemo pratiti ovaj projekt.
RAG se može izraditi na mnogo načina. Za detaljniji pregled različitih pristupa pročitajte Praktične primjere prilagođenih RAG rješenja. Kada vam je važna kvaliteta, mogućnosti dizajna postaju iznenađujuće složene, a uobičajeni „zadani” pristup uglavnom izgleda ovako:
Prikupite dokumente.
Podijelite ih na dijelove. To se može učiniti na mnogo načina (npr. prema odlomcima ili semantičkim skupinama).
Svaki dio pretvorite u ugradnju.
Pohranite ugradnje 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 to postoji mnogo načina).
U mnogim tehnološkim sustavima koraci (1)–(3) odvijaju se izvan baze podataka, u aplikacijskom kodu ili podatkovnom procesu, dok se baza uglavnom koristi za:
pohranu ugradnji
pretraživanje ugradnji
pgai je proširenje otvorenog koda za Postgres koje razvija Timescale, a cilj mu je izbrisati tu granicu.
Umjesto da ugradnje budu nešto čime vaša aplikacija ručno upravlja, pgai ih pretvara u značajku baze podataka:
Odredite koju tablicu ili dokumente želite pretvoriti u ugradnje.
Odredite model ugradnji i strategiju podjele.
pgai upravlja svime ostalim, uključujući ažuriranje ugradnji pri promjeni izvornih podataka.
Obećanje je privlačno:
Manje namjenskog poveznog koda koji treba održavati.
Trebalo bi biti lakše održavati ugradnje ažurnima dok se izvorni dokumenti mijenjaju.
Postgres/pgai upravlja ponovnim pokušajima, ograničenjima učestalosti, neuspjelim zadacima itd.
Napomena čitateljima: pgai u sebi sadrži pgvector, još jedno vrlo popularno proširenje za RAG u Postgresu. pgvector Postgresu dodaje pohranu vektora i pretraživanje sličnosti, dok pgai na tome gradi automatizaciju koraka RAG procesa, kao što su podjela, stvaranje ugradnji i njihovo ažuriranje.
1) Jednostavno ga je pokrenuti.
U idealnim uvjetima postupak je prilično jednostavan:
Preuzmite Timescaleove Docker slike (baza podataka + radni proces).
Unesite API ključ pružatelja ugradnji.
Izvršite nekoliko SQL naredbi kako biste definirali vektorizator: što pretvoriti u ugradnje, kako podijeliti sadržaj i koji model upotrijebiti.
Nakon toga pgai pokreće radni proces vektorizatora kao zaseban proces koji asinkrono stvara ugradnje, primjerice svakih pet minuta ili u bilo kojem željenom ritmu.
2) Praktično je cijeli proces izvoditi „blizu” baze podataka.
pgai može unositi sadržaj iz tablica, ali i učitavati dokumente sa servisa poput S3, a zatim ih raščlaniti, podijeliti i pretvoriti u ugradnje. Podržava i različite formate tekstnih dokumenata, poput PDF-a, Markdowna i drugih.
1) Gubite velik dio kontrole, a RAG je katkad zahtijeva.
RAG sustavi visokih performansi, mjereno kvalitetom odgovora, često zahtijevaju prilagođene procese, kao što su:
prilagođena pravila podjele sadržaja (prema naslovima, stranicama, izmjenama govornika itd.)
podjela koja uzima u obzir metapodatke (zadržavanje naslova odjeljaka, vremenskih oznaka, autora i vrste dokumenta)
različite strategije ugradnji za svaku vrstu dokumenta
pgai pruža manje fleksibilnosti za navedene mogućnosti.
Trenutačno postoje dvije glavne strategije podjele: djelitelj teksta prema broju znakova i rekurzivni djelitelj prema broju znakova, uz mogućnost da se sadržaj ne dijeli. To bi moglo biti dovoljno za neke slučajeve upotrebe, ali mnogi produkcijski RAG sustavi zahtijevaju veću prilagodbu.
Bilo bi sjajno kada bi Timescale ugradio neke od naprednijih strategija podjele dostupnih u bibliotekama poput Chonkieja te podržao napredne pristupe kao što je Anthropicovo kontekstualno dohvaćanje.
2) Prvenstveno za tekst, a ne za multimodalni sadržaj.
Mnogi zanimljivi problemi RAG-a više nisu isključivo tekstni:
PDF-ovi s dijagramima
snimke zaslona / slike
audiosnimke
videoisječci
Čak i ako iz tih izvora možete „izvući tekst”, to nije isto što i pravi multimodalni proces stvaranja ugradnji.
Kada bi pgai jednog dana podržavao multimodalne modele od početka do kraja — učitavanje, podjelu i stvaranje ugradnji za velike slike, audiozapise i videozapise pohranjene na S3 uz pouzdanu sinkronizaciju — bio bi vrlo privlačan. Danas je ipak riječ o procesu tekstnih ugradnji.
3) Ako trebate samo ugradnje, pgai vam možda nije potreban.
Ako je vaš proces unosa već prilagođen ili to mora biti, „pretvaranje dijelova teksta u ugradnje” nije najteži dio RAG-a. U takvom okruženju pgai rješava najlakši dio problema.
Osim toga, ako se vaša baza znanja rijetko ažurira, automatska sinkronizacija ugradnji nije toliko vrijedna.
Posebno dobar način upotrebe pgai-ja bila bi implementacija sučelja za pretvaranje teksta u SQL nad vašim bazama podataka. To se može prilično jednostavno postići modulom semantic_catalog koji nudi pgai. Jednostavno ga postavite ovako:
Bash
Zatim naredbom pgai semantic-catalog create omogućite semantičkom katalogu da prikupi podatke iz vaših rječnika podataka. Time se iz spremišta podataka stvara kontekst koji izgleda otprilike ovako:
Plain Text
Taj je kontekst sada pgai-ju dostupan na nekoliko načina:
Semantičkim pretraživanjem:
Ovaj upit vraća tablice, funkcije i druge objekte koji bi mogli biti relevantni za vaš upit na prirodnom jeziku:
Bash
Dohvaćanje neobrađenog konteksta:
Time će se prikazati neobrađeni YAML kontekst povezan s vašim upitom na prirodnom jeziku:
Bash
Generiranje SQL-a:
Možete i izravno generirati neobrađeni SQL potreban za odgovor na upit. Kontekst iz prethodnog koraka šalje se LLM-u, koji zatim generira odgovor:
Bash
Ako izrađujete razmjerno jednostavan RAG sustav, pgai vrijedi isprobati ako želite:
Postgres kao primarni sustav evidencije,
što manje poveznog koda,
ugradnje koje automatski ostaju sinkronizirane,
brz način primjene pretvaranja teksta u SQL na svoje baze podataka,
isprobavanje novih RAG alata i proširenja za Postgres.
S pgai-jem vjerojatno vrijedi pričekati ako vaš RAG proces zahtijeva nešto od sljedećeg:
opsežnu prilagođenu logiku unosa ili podjele sadržaja
mnogo vrsta dokumenata s različitim zahtjevima za raščlanjivanje
multimodalne ugradnje
Naposljetku, jasno je da je pgvector široko prihvaćen, no nije jasno hoće li pgai privući jednaku razinu interesa, a time i podrške, premda postoji tek oko 18 mjeseci.
pgai je zanimljiv pristup RAG-u koji bazama podataka prepušta više rutinskih operativnih poslova, čime se pojednostavljuje aplikacijski kod.
Trenutačno je:
upotrebljiv i doista ugodan za jednostavne RAG sustave
nedovoljno fleksibilan za prilagođenije procese, osobito multimodalne
Obećava i svakako vrijedi pratiti kako će se razvijati.