Az LLM-ek egyszerre csak korlátozott mennyiségű szöveget képesek „látni” (ez a kontextusablak). Ez kisebb feladatoknál működik, de több ezer oldalnyi tudásbázis esetén már nem. Még elegendő méretű kontextusablak esetén is romolhat a teljesítmény a „tű a szénakazalban” probléma miatt.
A RAG („visszakereséssel támogatott generálás”) széles körben elterjedt megoldás: egy tudásbázisból (dokumentumokból, wikikből, szabályzatokból, átiratokból stb.) szemantikus kereséssel és beágyazások segítségével lekérik a felhasználói kérdéshez leginkább kapcsolódó részleteket, majd ezeket a kérdéssel együtt átadják az LLM-nek. Ez leszűkíti a modell kontextusát, és megfelelő megvalósítás esetén javíthatja a válaszok minőségét, valamint csökkentheti a hallucinációkat.
A pgai egy nyílt forráskódú Postgres-bővítmény és a hozzá tartozó eszközkészlet, amellyel „MI-alapú visszakeresési” munkafolyamatok építhetők a megbízható, nyílt forráskódú PostgreSQL adatbázisra.
A fő elgondolás az, hogy a szokásos RAG-folyamat minél nagyobb része az adatbázisrétegbe kerüljön (betöltés → darabolás → beágyazás → beágyazások szinkronban tartása), ahelyett, hogy az adatbázisra a beágyazások „puszta tárhelyeként” tekintenénk.
Első benyomásunk szerint ígéretes, de amint a RAG-folyamat kissé összetettebbé válik – különösen a darabolási módszerek terén –, már nem igazán alkalmas. Ennek ellenére szorosan követjük majd a projektet.
A RAG sokféleképpen megvalósítható; a különböző megközelítések részletesebb bemutatásáért olvassa el a Gyakorlati példák testreszabott RAG-megoldásokra című cikket. Ha fontos a minőség, a tervezési lehetőségek meglepően szerteágazóvá válnak. Az elterjedt „alapértelmezett” megközelítés általában így néz ki:
Gyűjtsön össze egy halom dokumentumot.
Darabolja fel őket. Erre számos különböző módszer létezik (például bekezdések vagy szemantikai csoportok szerint).
Minden darabból készítsen beágyazást.
Tárolja a beágyazásokat vektoradatbázisban (Pinecone, Milvus stb.), vagy a pgvector használatával Postgresben.
Lekérdezéskor keresse meg a legközelebbi darabokat, `és adja át őket az LLM-nek (ismét csak... erre is számos módszer létezik).
Sok technológiai rendszerben az (1)–(3) lépés az adatbázison kívül, alkalmazáskódban vagy adatfeldolgozási folyamatban történik, az adatbázist pedig főként a következőkre használják:
beágyazások tárolása
keresés a beágyazások között
A pgai egy nyílt forráskódú, a Timescale által fejlesztett Postgres-bővítmény, amely megpróbálja elmosni ezt a határvonalat.
Ahelyett, hogy az alkalmazásnak kellene kézzel kezelnie a beágyazásokat, a pgai adatbázis-funkcióvá teszi őket:
Ön határozza meg, hogy melyik táblát vagy dokumentumokat szeretné beágyazni.
Ön adja meg a beágyazási modellt és a darabolási stratégiát.
A többit a pgai kezeli, beleértve a beágyazások naprakészen tartását a forrásadatok változásakor.
Az ígéret vonzó:
Kevesebb karbantartandó, egyedi összekötő kód.
Könnyebb lehet „frissen” tartani a beágyazásokat az alapul szolgáló forrásdokumentumok változásakor.
A Postgres/pgai kezeli az újrapróbálkozásokat, a sebességkorlátokat, a sikertelen feladatokat stb.
Megjegyzés az olvasónak: a pgai magában foglalja a pgvectort, egy másik rendkívül népszerű RAG-bővítményt a Postgreshez. A pgvector vektortárolással és hasonlósági kereséssel egészíti ki a Postgrest, a pgai pedig erre építve automatizálja a RAG-folyamat olyan lépéseit, mint a darabolás, a beágyazás és a beágyazások naprakészen tartása.
1) Egyszerűen üzembe helyezhető.
Ideális esetben a folyamat meglehetősen egyszerű:
Töltse le a Timescale Docker-rendszerképeit (adatbázis + feldolgozó).
Adja meg a beágyazási szolgáltató API-kulcsát.
Néhány SQL-utasítással állítsa be a vektorizálót: mit kell beágyazni, hogyan kell darabolni, és melyik modellt kell használni.
Ezután a pgai gondoskodik arról, hogy egy vektorizáló feldolgozó külön folyamatként fusson, és aszinkron módon készítse el a beágyazásokat (például 5 percenként vagy bármilyen kívánt ütemezés szerint).
2) Kényelmes, hogy a teljes folyamat az adatbázis „közelében” zajlik.
A pgai táblákból is képes tartalmat betölteni, emellett például az S3-ból is beolvashat dokumentumokat, majd feldolgozhatja, feldarabolhatja és beágyazhatja őket. Különböző szöveges dokumentumformátumokat, például PDF-et és Markdownt is képes kezelni.
1) Jelentősen csökken az irányítás lehetősége – márpedig a RAG-nál erre néha szükség van.
A válaszminőség alapján nagy teljesítményűnek számító RAG-rendszerekhez gyakran egyedi folyamatokra van szükség, például:
egyedi darabolási szabályok (címsorok, oldalak, beszélőváltások stb. alapján)
metaadatokat figyelembe vevő darabolás (szakaszcímek, időbélyegek, szerzők és dokumentumtípus megőrzése)
dokumentumtípusonként eltérő beágyazási stratégiák
A pgai a fentiekben kevesebb rugalmasságot kínál.
Jelenleg két fő darabolási stratégia létezik: a karakteralapú szövegfelosztó és a rekurzív karakteralapú szövegfelosztó, emellett a darabolás ki is kapcsolható. Ez bizonyos felhasználási esetekhez elegendő lehet, de sok éles RAG-rendszer nagyobb mértékű testreszabást igényel.
Nagyszerű lenne, ha a Timescale beépítene néhányat az olyan könyvtárakban látható, kifinomultabb darabolási stratégiákból, mint a Chonkie, és támogatná az olyan fejlett megoldásokat is, mint az Anthropic kontextuális visszakeresése.
2) Elsősorban szöveges, nem multimodális.
Sok érdekes RAG-probléma már nem kizárólag szöveges:
ábrákat tartalmazó PDF-ek
képernyőképek/képek
hangfelvételek
videoklipek
Még ha ezekből a forrásokból „ki is nyerhető a szöveg”, az nem ugyanaz, mint egy valóban multimodális beágyazási folyamat.
Meggyőző lenne, ha a pgai idővel teljes folyamatukban támogatná a multimodális modelleket – vagyis az S3-ban tárolt nagyméretű képek, hang- és videófájlok betöltését → darabolását → beágyazását, megbízható szinkronizálással –, jelenleg azonban csak szövegbeágyazási munkafolyamatot kínál.
3) Ha csak beágyazásokra van szüksége, lehet, hogy nincs szüksége a pgai-ra.
Ha a betöltési folyamat már eleve egyedi – vagy annak kell lennie –, akkor a „szövegdarabok beágyazása” nem a RAG legnehezebb része. Ebben az esetben a pgai a probléma legegyszerűbb részét oldja meg.
Ha pedig a tudásbázis ritkán frissül, az automatikus beágyazásszinkronizálás értéke is kisebb.
A pgai egyik különösen jó felhasználási módja egy szövegből SQL-t előállító felület telepítése az adatbázisok fölé. Ez meglehetősen egyszerűen megvalósítható a pgai semantic_catalog moduljával. Egyszerűen állítsa be így:
Bash
majd a pgai semantic-catalog create paranccsal olvastassa be az adatszótárakat a szemantikai katalógussal. Ez az alábbihoz hasonló kontextust hoz létre az adattárból:
Plain Text
Ez a kontextus mostantól többféleképpen is elérhető a pgai számára:
Szemantikus kereséssel:
Ez a lekérdezés visszaadja azokat a táblákat, függvényeket és egyéb objektumokat, amelyek kapcsolódhatnak a természetes nyelvű lekérdezéshez:
Bash
Nyers kontextus lekérése:
Ez megjeleníti a természetes nyelvű lekérdezéshez kapcsolódó nyers YAML-kontextust:
Bash
SQL generálása:
Közvetlenül is előállíthatja a lekérdezés megválaszolásához szükséges nyers SQL-t. Az előző lépésben létrehozott kontextust elküldi egy LLM-nek, amely választ generál:
Bash
Ha viszonylag egyszerű RAG-rendszert épít, érdemes kipróbálnia a pgai-t, ha a következőket szeretné:
a Postgres legyen a hiteles adatforrás,
minimális mennyiségű összekötő kód,
automatikusan szinkronban maradó beágyazások,
a szövegből SQL-t előállító megoldás gyors alkalmazása az adatbázisokra,
új RAG-eszközök és Postgres-bővítmények kipróbálása.
Valószínűleg érdemes még várni a pgai-jal, ha a RAG-folyamatnak az alábbiak bármelyikére szüksége van:
nagymértékben testreszabott betöltési vagy darabolási logika
sokféle, eltérő feldolgozást igénylő dokumentumtípus
multimodális beágyazások
Végezetül: bár a pgvector egyértelműen széles körben elterjedt, nem tudni, hogy a pgai hasonló érdeklődésre és így támogatásra számíthat-e – igaz, csak körülbelül 18 hónapja létezik.
A pgai érdekes RAG-megközelítés: a rutinszerű üzemeltetési feladatok nagyobb részét az adatbázisra bízza, így egyszerűbbé teheti az alkalmazáskódot.
Jelenleg:
egyszerű RAG-rendszerekhez jól használható és kifejezetten kellemes
egyedibb folyamatokhoz nem elég rugalmas, különösen multimodális esetekben
Ígéretes, és mindenképpen érdemes figyelemmel kísérni a fejlődését.