LLM-id suudavad korraga „näha“ vaid piiratud hulka teksti (kontekstivaade). See toimib väikeste ülesannete puhul, kuid ei pea vastu, kui teadmusbaas hõlmab tuhandeid lehekülgi. Isegi piisava kontekstivaate korral võib jõudlus „nõela heinakuhjast otsimise“ probleemi tõttu halveneda.
RAG („otsinguga täiendatud genereerimine“) on muutunud väga levinud lahenduseks: hallatakse teadmusbaasi (dokumendid, vikid, eeskirjad, transkriptsioonid jne), kasutaja päringu põhjal tehakse manuste abil semantiline otsing kõige asjakohasemate lõikude leidmiseks ning need lõigud edastatakse koos küsimusega LLM-ile. See piirab mudeli konteksti ning võib korrektsel rakendamisel parandada vastuste kvaliteeti ja vähendada hallutsinatsioone.
pgai on avatud lähtekoodiga Postgresi laiendus (koos lisatööriistadega), mis aitab luua „AI-otsingu“ töövooge usaldusväärse avatud lähtekoodiga PostgreSQL-i andmebaasi peale.
Põhiidee on viia suurem osa tavapärasest RAG-konveierist andmebaasikihti (sisesta → tükelda → manusta → hoia manused sünkroonis), selle asemel et käsitleda andmebaasi manuste „pelgalt salvestusruumina“.
Esmamulje järgi on lahendus paljulubav, kuid niipea, kui RAG-konveier muutub vähegi keerukaks (eriti tükeldusviiside poolest), pole see enam sobiv. Hoiame sellel projektil siiski tähelepanelikult silma peal.
RAG-i saab luua mitmel viisil. Erinevate lähenemisviiside põhjalikuma ülevaate leiate artiklist „Praktilised näited kohandatud RAG-lahendustest“. Kui kvaliteet muutub oluliseks, osutub võimaluste ring üllatavalt laiaks. Levinud „vaikelahendus“ näeb üldiselt välja nii:
Võtke hulk dokumente.
Jagage need tükkideks. Selleks on palju meetodeid (nt lõikude või semantiliste rühmade alusel).
Teisendage iga tükk manuseks.
Salvestage manused vektorandmebaasi (Pinecone, Milvus jne) või pgvectori abil Postgresi.
Päringu ajal otsige lähimad tükid `ja edastage need LLM-ile (ka selleks on jällegi palju viise).
Paljudes tehnoloogiapinudes tehakse etapid (1)–(3) väljaspool andmebaasi, rakenduse koodis või andmekonveieris, ning andmebaasi kasutatakse peamiselt järgmiseks:
manuste salvestamine
manuste otsimine
pgai on Postgresi laiendus (avatud lähtekoodiga, arendaja Timescale), mis püüab seda piiri hägustada.
Selle asemel et käsitleda manuseid millegi rakenduses käsitsi hallatavana, muudab pgai need andmebaasi funktsiooniks:
Määrate, millise tabeli või millised dokumendid soovite manustada.
Määrate manustamismudeli ja tükeldusstrateegia.
Ülejäänu eest hoolitseb pgai, sealhulgas hoiab manused lähteandmete muutudes ajakohasena.
Lubadus on ahvatlev:
Vähem hooldust vajavat erilahendusena loodud siduskoodi.
Alusdokumentide muutudes peaks olema lihtsam manuseid ajakohasena hoida.
Postgres/pgai haldab korduskatseid, kiiruspiiranguid, nurjunud töid jne.
Märkus lugejale: pgai sisaldab pgvectorit (veel üht väga populaarset Postgresi RAG-laiendust). pgvector lisab Postgresile vektorite salvestamise ja sarnasusotsingu, pgai aga kasutab seda RAG-konveieri etappide automatiseerimiseks, sealhulgas tükeldamiseks, manustamiseks ja manuste ajakohasena hoidmiseks.
1) Seda on lihtne käivitada.
Ideaalstsenaarium on üsna lihtne:
Laadige alla Timescale’i Dockeri tõmmised (andmebaas + tööprotsess).
Sisestage manustamisteenuse pakkuja API-võti.
Käivitage veidi SQL-i, et määratleda vektoriseerija (põhimõtteliselt see, mida manustada, kuidas seda tükeldada ja millist mudelit kasutada).
Seejärel korraldab pgai vektoriseerija tööprotsessi käitamise eraldi protsessina ja manuste asünkroonse genereerimise (nt iga viie minuti järel või muu soovitud sagedusega).
2) Kogu konveierit on mugav käitada andmebaasi „lähedal“.
pgai saab sisu tabelitest sisse lugeda, aga ka laadida dokumente näiteks S3-st ning need seejärel sõeluda, tükeldada ja manustada. Samuti oskab see töödelda eri tekstidokumendivorminguid, näiteks PDF-i ja Markdowni.
1) Kaotate palju kontrolli (ja RAG vajab seda vahel).
Kvaliteetsete vastustega RAG-süsteemid vajavad sageli erilahendusena loodud konveiereid, näiteks:
kohandatud tükeldusreeglid (pealkirjade, lehekülgede, kõnelejate voorude jne alusel)
metaandmeid arvestav tükeldamine (säilitatakse jaotiste pealkirjad, ajatemplid, autorid ja dokumenditüüp)
eri dokumenditüüpide jaoks erinevad manustamisstrateegiad
Eeltoodu puhul pakub pgai vähem paindlikkust.
Praegu on kaks peamist tükeldusstrateegiat: tähemärgipõhine tekstijagaja ja rekursiivne tähemärgipõhine tekstijagaja. Lisaks saab tükeldamisest loobuda. Mõnel juhul võib sellest piisata, kuid paljud tootmiskeskkonna RAG-süsteemid vajavad rohkem kohandamist.
Oleks suurepärane, kui Timescale võtaks kasutusele mõne keerukama tükeldusstrateegia, mida leidub sellistes teekides nagu Chonkie, ning toetaks ka täiustatud lahendusi, nagu Anthropicu kontekstipõhine otsing.
2) Eeskätt tekstile, mitte multimodaalsusele.
Paljud huvitavad RAG-probleemid ei piirdu enam üksnes tekstiga:
diagrammidega PDF-id
kuvatõmmised/pildid
helisalvestised
videoklipid
Isegi kui neist allikatest saab „teksti eraldada“, ei ole see sama mis tõeline multimodaalne manustamiskonveier.
Kui pgai hakkaks lõpuks toetama multimodaalseid mudeleid algusest lõpuni (S3-s talletatud suurte piltide, heli ja video laadimine → tükeldamine → manustamine koos töökindla sünkroonimisega), oleks see väga ahvatlev. Praegu on tegu siiski teksti manustamise töövooga.
3) Kui vajate ainult manuseid, ei pruugi te pgaid vajada.
Kui teie sisestuskonveier on juba kohandatud (või peab seda olema), ei ole „tekstitükkide manustamine“ RAG-i kõige keerulisem osa. Sellisel juhul lahendab pgai probleemi lihtsaima osa.
Kui teie teadmusbaasi uuendatakse harva, pole ka manuste automaatsest sünkroonimisest nii palju kasu.
Üks eriti hea viis pgai kasutamiseks oleks luua oma andmebaaside peale tekstist SQL-i liides. Seda saab pgai pakutava mooduliga semantic_catalog üsna hõlpsasti teha. Seadistage see lihtsalt nii:
Bash
ja laske semantilisel kataloogil oma andmesõnastikud käsuga pgai semantic-catalog create läbi vaadata. See loob teie andmehoidla põhjal konteksti, mis näeb välja umbes nii:
Plain Text
Nüüd saab pgai seda konteksti kasutada mitmel viisil:
Semantilise otsingu kaudu:
See päring tagastab tabelid, funktsioonid ja muud objektid, mis võivad teie loomulikus keeles päringu jaoks asjakohased olla:
Bash
Toorkonteksti hankimine:
See kuvab teie loomulikus keeles päringuga seotud YAML-vormingus toorkonteksti:
Bash
SQL-i genereerimine:
Võite ka otse genereerida päringule vastamiseks vajaliku töötlemata SQL-i. Eelmises etapis saadud kontekst saadetakse LLM-ile, mis genereerib vastuse:
Bash
Kui loote suhteliselt lihtsat RAG-süsteemi, tasub pgaid proovida, kui soovite järgmist:
Postgres kui põhiandmeallikas,
minimaalselt siduskoodi,
automaatselt sünkroonis püsivad manused,
kiire viis rakendada oma andmebaasidele tekstist SQL-i lahendust,
katsetada uusi RAG-tööriistu ja Postgresi laiendusi.
pgai kasutuselevõtuga tasub ilmselt oodata, kui teie RAG-konveier vajab mõnda järgmistest:
ulatuslik kohandatud sisestus- või tükeldusloogika
palju eri sõelumisnõuetega dokumenditüüpe
multimodaalsed manused
Kuigi pgvector on selgelt laialdaselt kasutusele võetud, pole teada, kas pgai pälvib sama palju huvi ja seega ka tuge (ehkki see on olemas olnud alles umbes 18 kuud).
pgai pakub RAG-ile huvitavat lähenemist, kus andmebaasid teevad rohkem tavapärast käitustööd ja rakenduse kood saab olla lihtsam.
Praegu on see:
lihtsate RAG-lahenduste jaoks kasutatav ja tõeliselt mugav
erilahendusena loodud konveierite jaoks liiga vähe paindlik (eriti multimodaalsuse puhul)
See on paljulubav ja kindlasti tasub jälgida, kuidas lahendus edasi areneb.