Veliki jezikovni modeli lahko hkrati »vidijo« le omejeno količino besedila (kontekstno okno). To deluje pri manjših nalogah, vendar odpove, ko zbirka znanja obsega več tisoč strani. Tudi če je kontekstno okno dovolj veliko, se lahko učinkovitost poslabša zaradi težave »iskanja igle v senu«.
RAG (»generiranje, podprto s pridobivanjem podatkov«) je postal zelo razširjen vzorec: vzdržujete zbirko znanja (dokumente, wikije, pravilnike, prepise itd.), s semantičnim iskanjem po uporabnikovi poizvedbi in vdelavami poiščete najustreznejše odlomke ter jih skupaj z vprašanjem posredujete velikemu jezikovnemu modelu. S tem omejite kontekst modela, kar lahko ob pravilni izvedbi izboljša kakovost odgovorov in zmanjša halucinacije.
pgai je odprtokodna razširitev za Postgres (s spremljevalnimi orodji), ki omogoča izdelavo potekov dela za »pridobivanje podatkov z UI« na podlagi zaupanja vredne odprtokodne podatkovne zbirke PostgreSQL.
Glavna zamisel je, da se več običajnega cevovoda RAG prenese v podatkovno plast (zajem → razdelitev → vdelava → sinhronizacija vdelav), namesto da bi podatkovno zbirko obravnavali kot »zgolj shrambo« vdelav.
Prvi vtis je obetaven, vendar rešitev ni primerna, takoj ko postane cevovod RAG vsaj nekoliko zapleten, zlasti glede načinov razdeljevanja. Kljub temu bomo ta projekt pozorno spremljali.
RAG je mogoče zgraditi na številne načine. Za podrobnejšo razčlenitev različnih pristopov preberite Praktične primere prilagojenih rešitev RAG. Ko postane pomembna kakovost, je nabor možnosti presenetljivo obsežen, običajni »privzeti« pristop pa je videti približno tako:
Zberite dokumente.
Razdelite jih na odseke. Za to obstaja veliko različnih načinov (npr. po odstavkih ali pomenskih skupinah).
Vsak odsek pretvorite v vdelavo.
Vdelave shranite v vektorsko podatkovno zbirko (Pinecone, Milvus itd.) ali v Postgres z uporabo pgvector.
Ob poizvedbi poiščite najbližje odseke `in jih posredujte velikemu jezikovnemu modelu (tudi to je mogoče narediti na številne načine).
V številnih tehnoloških skladih se koraki (1)–(3) izvedejo zunaj podatkovne zbirke, v aplikacijski kodi ali podatkovnem cevovodu, podatkovna zbirka pa se uporablja predvsem za:
shranjevanje vdelav
iskanje po vdelavah
pgai je odprtokodna razširitev za Postgres, ki jo razvija Timescale in poskuša zabrisati to mejo.
Namesto da bi vdelave obravnaval kot nekaj, kar mora aplikacija upravljati ročno, jih pgai spremeni v funkcijo podatkovne zbirke:
Določite tabelo oziroma dokumente, ki jih želite vdelati.
Določite model za vdelave in strategijo razdeljevanja.
Za vse drugo poskrbi pgai, vključno s posodabljanjem vdelav ob spremembah izvornih podatkov.
Obljuba je privlačna:
Manj namenske povezovalne kode, ki jo je treba vzdrževati.
Vdelave naj bi bilo lažje ohranjati posodobljene ob spremembah izvornih dokumentov.
Postgres/pgai upravlja ponovne poskuse, omejitve hitrosti, neuspele naloge itd.
Opomba za bralce: pgai vključuje pgvector, še eno zelo priljubljeno razširitev RAG za Postgres. pgvector Postgresu doda shranjevanje vektorjev in iskanje po podobnosti, pgai pa to nadgradi z avtomatizacijo korakov cevovoda RAG, kot so razdeljevanje, ustvarjanje vdelav in njihovo posodabljanje.
1) Zagon je preprost.
Najpreprostejši potek je razmeroma preprost:
Prenesite slike Docker podjetja Timescale (podatkovna zbirka in delovni proces).
Vnesite ključ API ponudnika vdelav.
Z nekaj ukazi SQL določite vektorizator (kaj naj vdela, kako naj vsebino razdeli in kateri model naj uporabi).
pgai nato poskrbi, da se delovni proces vektorizatorja izvaja ločeno in asinhrono ustvarja vdelave (npr. vsakih pet minut oziroma v želenem intervalu).
2) Priročno je, da celoten cevovod deluje »blizu« podatkovne zbirke.
pgai lahko zajema vsebino iz tabel ali naloži dokumente iz virov, kot je S3, nato pa jih razčleni, razdeli in vdela. Obravnava lahko tudi različne oblike besedilnih dokumentov, kot so PDF, Markdown itd.
1) Izgubite veliko nadzora, RAG pa ga včasih potrebuje.
Visoko zmogljivi sistemi RAG, merjeni po kakovosti odgovorov, pogosto zahtevajo namenske cevovode, na primer:
prilagojena pravila razdeljevanja (po naslovih, straneh, menjavah govorcev itd.)
razdeljevanje, ki upošteva metapodatke (ohrani naslove razdelkov, časovne oznake, avtorje in vrsto dokumenta)
različne strategije vdelav za posamezne vrste dokumentov
pgai je pri zgoraj navedenem manj prilagodljiv.
Trenutno sta na voljo dve glavni strategiji: razdeljevalnik besedila po znakih in rekurzivni razdeljevalnik besedila po znakih, poleg tega pa še možnost brez razdeljevanja. Za nekatere primere uporabe je to morda dovolj, vendar številni produkcijski sistemi RAG zahtevajo več prilagajanja.
Odlično bi bilo, če bi Timescale vključil naprednejše strategije razdeljevanja, kakršne ponujajo knjižnice, kot je Chonkie, in podprl napredne zasnove, kot je Anthropicovo kontekstualno pridobivanje podatkov.
2) V ospredju je besedilo, ne večmodalnost.
Številne zanimive težave RAG niso več izključno besedilne:
datoteke PDF z diagrami
posnetki zaslona in slike
zvočni posnetki
videoposnetki
Tudi če lahko iz teh virov »izvlečete besedilo«, to ni enako pravemu večmodalnemu cevovodu za vdelave.
Če bo pgai nekoč celovito podpiral večmodalne modele (nalaganje → razdelitev → vdelava velikih slik, zvoka in videa, shranjenih v S3, z zanesljivo sinhronizacijo), bo to zelo privlačno. Danes pa je namenjen besedilnim vdelavam.
3) Če potrebujete le vdelave, pgai morda ni potreben.
Če je vaš cevovod za zajem že prilagojen vašim potrebam oziroma mora biti, potem »ustvarjanje vdelav iz odsekov besedila« ni najtežji del RAG. V takem okolju pgai rešuje najlažji del težave.
Če se zbirka znanja redko posodablja, je tudi samodejna sinhronizacija vdelav manj koristna.
Posebej dober način uporabe pgai bi bila uvedba vmesnika za pretvorbo besedila v SQL nad vašimi podatkovnimi zbirkami. To je mogoče precej preprosto doseči z modulom semantic_catalog, ki ga ponuja pgai. Nastavite ga takole:
Bash
Nato naj semantični katalog pregleda vaše podatkovne slovarje z ukazom pgai semantic-catalog create. S tem se iz podatkovne shrambe ustvari kontekst, ki je videti približno takole:
Plain Text
Ta kontekst je zdaj pgai na voljo na več načinov:
S semantičnim iskanjem:
Ta poizvedba vrne tabele, funkcije in druge predmete, ki bi lahko bili pomembni za vašo poizvedbo v naravnem jeziku:
Bash
Pridobivanje neobdelanega konteksta:
To prikaže neobdelani kontekst YAML, povezan z vašo poizvedbo v naravnem jeziku:
Bash
Ustvarjanje SQL:
Lahko pa neposredno ustvarite neobdelani SQL, potreben za odgovor na poizvedbo. Kontekst iz prejšnjega koraka se pošlje velikemu jezikovnemu modelu, ki ustvari odgovor:
Bash
Če razvijate razmeroma preprost sistem RAG, je pgai vredno preizkusiti, če želite:
Postgres kot osrednji sistem evidenc,
čim manj povezovalne kode,
vdelave, ki se samodejno sinhronizirajo,
hiter način uporabe pretvorbe besedila v SQL v svojih podatkovnih zbirkah,
preizkušanje novih orodij RAG in razširitev za Postgres.
S pgai je verjetno bolje počakati, če vaš cevovod RAG zahteva kaj od naslednjega:
obsežno prilagojeno logiko zajema ali razdeljevanja
veliko vrst dokumentov z različnimi zahtevami za razčlenjevanje
večmodalne vdelave
Čeprav je pgvector očitno zelo razširjen, ni jasno, ali bo pgai deležen enakega zanimanja in s tem podpore, vendar obstaja šele približno 18 mesecev.
pgai je zanimiv pristop k RAG, saj podatkovnim zbirkam prepusti več rutinskega operativnega dela in tako poenostavi aplikacijsko kodo.
Trenutno je:
uporaben in resnično prijeten za preproste postavitve RAG
premalo prilagodljiv za bolj namenske cevovode, zlasti večmodalne
Kaže veliko potenciala in vsekakor je vredno spremljati njegov razvoj.