LLM vienu metu gali „matyti“ tik ribotą teksto kiekį (konteksto langą). Mažoms užduotims to pakanka, tačiau kyla problemų, kai žinių bazę sudaro tūkstančiai puslapių. Net kai konteksto langas pakankamas, našumas vis tiek gali suprastėti dėl „adatos šieno kupetoje“ problemos.
RAG (paieška papildyta generacija) tapo labai paplitusiu metodu: prižiūrite žinių bazę (dokumentus, vikius, taisykles, išrašus ir kt.), pagal naudotojo užklausą atliekate semantinę paiešką, naudodami įterpinius gaunate aktualiausias ištraukas ir kartu su klausimu pateikiate jas LLM. Taip apribojamas modelio kontekstas, o tinkamai įgyvendinus galima pagerinti atsakymų kokybę ir sumažinti haliucinacijų.
pgai yra atvirojo kodo „Postgres“ plėtinys (ir papildomi įrankiai), padedantis kurti DI paieškos procesus patikimoje atvirojo kodo duomenų bazėje „PostgreSQL“.
Pagrindinė idėja – daugiau įprasto RAG proceso perkelti į duomenų bazės sluoksnį (įkelti → suskaidyti → įterpti → sinchronizuoti įterpinius), užuot DB laikius „tik įterpinių saugykla“.
Pirmasis įspūdis – sprendimas perspektyvus, tačiau RAG procesui tapus nors kiek sudėtingesniam (ypač dėl skaidymo metodų), jis nebetinka. Vis dėlto atidžiai stebėsime šį projektą.
RAG galima kurti įvairiai. Išsamesnį skirtingų metodų aptarimą rasite straipsnyje „Praktiniai individualizuotų RAG sprendimų pavyzdžiai“. Siekiant kokybės, galimų sprendimų erdvė tampa stebėtinai plati, o įprastas numatytasis metodas paprastai atrodo taip:
Paimkite dokumentų rinkinį.
Suskaidykite juos į dalis. Tai galima padaryti įvairiais būdais (pvz., pagal pastraipas ar semantines grupes).
Kiekvieną dalį paverskite įterpiniu.
Įterpinius saugokite vektorinėje duomenų bazėje („Pinecone“, „Milvus“ ir kt.) arba „Postgres“ duomenų bazėje, naudodami pgvector.
Gavę užklausą, raskite artimiausias dalis `ir perduokite jas LLM (vėlgi... tai galima padaryti įvairiai).
Daugelyje technologijų rinkinių 1–3 veiksmai atliekami už duomenų bazės ribų – programos kode arba duomenų apdorojimo procese, o duomenų bazė daugiausia naudojama:
įterpiniams saugoti
įterpinių paieškai
pgai yra atvirojo kodo „Postgres“ plėtinys, kurį sukūrė „Timescale“ ir kuriuo siekiama ištrinti šią ribą.
Užuot vertus programą pačią tvarkyti įterpinius, pgai paverčia juos duomenų bazės funkcija:
Nurodote, kurią lentelę ar dokumentus norite paversti įterpiniais.
Nurodote įterpinių modelį ir skaidymo strategiją.
Visa kita tvarko pgai, įskaitant įterpinių atnaujinimą pasikeitus šaltinio duomenims.
Pažadai viliojantys:
Mažiau specialiai pritaikyto jungiamojo kodo, kurį reikia prižiūrėti.
Keičiantis šaltinio dokumentams turėtų būti lengviau išlaikyti įterpinius aktualius.
„Postgres“ ir pgai tvarko pakartotinius bandymus, dažnio apribojimus, nepavykusias užduotis ir kt.
Pastaba skaitytojui: pgai viduje pateikiamas pgvector – kitas labai populiarus RAG skirtas „Postgres“ plėtinys. pgvector papildo „Postgres“ vektorių saugykla ir panašumo paieška, o pgai tuo remiasi automatizuodamas tokius RAG proceso veiksmus kaip skaidymas, įterpinių kūrimas ir jų atnaujinimas.
1) Pradėti naudoti nesudėtinga.
Įprastas scenarijus gana paprastas:
Atsisiųskite „Timescale“ „Docker“ atvaizdžius (duomenų bazės ir darbinio proceso).
Pateikite įterpinių paslaugos teikėjo API raktą.
Įvykdykite šiek tiek SQL kodo ir apibrėžkite vektorizatorių (iš esmės – ką paversti įterpiniais, kaip skaidyti ir kurį modelį naudoti).
Tada pgai pasirūpina, kad vektorizatoriaus darbinis procesas veiktų atskirai ir asinchroniškai generuotų įterpinius (pvz., kas 5 minutes ar kitu norimu dažniu).
2) Patogu visą procesą vykdyti „arti“ duomenų bazės.
pgai gali gauti turinį iš lentelių, taip pat įkelti dokumentus iš tokių vietų kaip S3, tada juos išanalizuoti, suskaidyti ir paversti įterpiniais. Jis taip pat gali apdoroti įvairius tekstinių dokumentų formatus, pvz., PDF, „Markdown“ ir kt.
1) Prarandate daug kontrolės (o RAG jos kartais reikia).
Aukštos kokybės atsakymus teikiančioms RAG sistemoms dažnai reikia individualizuotų procesų, pavyzdžiui:
individualių skaidymo taisyklių (pagal antraštes, puslapius, kalbėtojų pasikeitimus ir kt.)
į metaduomenis atsižvelgiančio skaidymo (išsaugant skyrių pavadinimus, laiko žymas, autorius, dokumento tipą)
skirtingų įterpinių strategijų kiekvienam dokumentų tipui
Šiose srityse pgai yra mažiau lankstus.
Šiuo metu siūlomos dvi pagrindinės skaidymo strategijos: teksto skaidymas pagal simbolius ir rekursinis teksto skaidymas pagal simbolius; taip pat galima visai neskaidyti. Kai kuriais naudojimo atvejais to gali pakakti, tačiau daugeliui eksploatuojamų RAG sistemų reikia daugiau individualizavimo galimybių.
Būtų puiku, jei „Timescale“ įdiegtų sudėtingesnes skaidymo strategijas, naudojamas tokiose bibliotekose kaip „Chonkie“, ir panašiai palaikytų pažangius sprendimus, pvz., „Anthropic“ kontekstinę paiešką.
2) Pirmiausia tekstas, o ne daugiarūšis turinys.
Daugelis įdomių RAG uždavinių jau nebėra vien tekstiniai:
PDF failai su diagramomis
ekrano kopijos ir vaizdai
garso įrašai
vaizdo įrašų ištraukos
Net jei iš šių šaltinių galima „išgauti tekstą“, tai nėra tas pats, kas tikras daugiarūšių įterpinių procesas.
Jei pgai galiausiai visapusiškai palaikytų daugiarūšius modelius (įkėlimą → skaidymą → įterpinių kūrimą dideliems S3 saugomiems vaizdams, garso ir vaizdo įrašams bei patikimą sinchronizavimą), tai būtų patrauklu, tačiau šiandien tai tėra tekstinių įterpinių procesas.
3) Jei reikia tik įterpinių, pgai gali būti nereikalingas.
Jei duomenų įkėlimo procesas jau individualizuotas (arba toks turi būti), „teksto dalių pavertimas įterpiniais“ nėra sunkiausia RAG dalis. Tokiu atveju pgai sprendžia lengviausią problemos dalį.
Be to, jei žinių bazė atnaujinama retai, automatinio įterpinių sinchronizavimo vertė mažesnė.
Vienas ypač geras būdas naudoti pgai – įdiegti teksto vertimo į SQL sąsają savo duomenų bazėms. Tai gana lengva padaryti naudojant pgai siūlomą semantic_catalog modulį. Tiesiog nustatykite taip:
Bash
ir nurodykite semantiniam katalogui nuskaityti duomenų žodynus komanda pgai semantic-catalog create. Taip iš duomenų saugyklos sugeneruojamas maždaug toks kontekstas:
Plain Text
Dabar pgai gali įvairiais būdais naudoti šį kontekstą:
Atliekant semantinę paiešką:
Ši užklausa grąžins lenteles, funkcijas ir kitus objektus, kurie gali būti aktualūs jūsų užklausai natūralia kalba:
Bash
Gauti neapdorotą kontekstą:
Bus pateiktas neapdorotas YAML kontekstas, susijęs su jūsų užklausa natūralia kalba:
Bash
Generuoti SQL:
Arba galite iš karto sugeneruoti neapdorotą SQL kodą, reikalingą atsakyti į užklausą. Ankstesnio veiksmo kontekstas siunčiamas LLM ir sugeneruojamas atsakymas:
Bash
Jei kuriate gana paprastą RAG sistemą, pgai verta išbandyti, jei norite:
naudoti „Postgres“ kaip pagrindinį duomenų šaltinį,
turėti kuo mažiau jungiamojo kodo,
automatiškai sinchronizuojamų įterpinių,
greitai pritaikyti teksto vertimą į SQL savo duomenų bazėms,
išbandyti naujus RAG įrankius ir „Postgres“ plėtinius.
Tikriausiai verta dar palaukti, jei jūsų RAG procesui reikia bent vieno iš šių dalykų:
itin individualizuotos duomenų įkėlimo ar skaidymo logikos
daugybės dokumentų tipų, kuriems taikomi skirtingi analizės reikalavimai
daugiarūšių įterpinių
Galiausiai, nors pgvector akivaizdžiai plačiai naudojamas, neaišku, ar pgai sulauks tokio pat susidomėjimo, taigi ir palaikymo (nors jis egzistuoja tik apie 18 mėnesių).
pgai – įdomus RAG metodas, leidžiantis duomenų bazėms atlikti daugiau įprastų techninių darbų, kad programos kodas būtų paprastesnis.
Šiuo metu jis yra:
tinkamas naudoti ir išties patogus paprastoms RAG konfigūracijoms
nepakankamai lankstus labiau individualizuotiems procesams (ypač daugiarūšiams)
Jis atrodo perspektyvus, todėl tikrai verta stebėti tolesnę jo raidą.