LLM dokážu naraz „vidieť“ len obmedzené množstvo textu (kontextové okno). Pri menších úlohách to funguje, no pri znalostnej databáze s tisíckami stránok tento prístup zlyháva. Aj keď je kontextové okno dostatočné, výkon sa môže zhoršiť pre problém „hľadania ihly v kope sena“.
RAG („generovanie rozšírené o vyhľadávanie“) sa stalo veľmi rozšíreným vzorom: udržiavate znalostnú databázu (dokumenty, wiki, pravidlá, prepisy a pod.), pomocou embeddingov sémanticky vyhľadáte najrelevantnejšie úryvky k dopytu používateľa a tieto časti spolu s otázkou odošlete do LLM. Tým sa obmedzí kontext modelu a pri správnej implementácii sa môže zvýšiť kvalita odpovedí a znížiť počet halucinácií.
pgai je open-source rozšírenie pre Postgres (spolu so sprievodnými nástrojmi), ktoré pomáha vytvárať pracovné postupy „vyhľadávania pomocou AI“ nad dôveryhodnou open-source databázou PostgreSQL.
Hlavnou myšlienkou je presunúť väčšiu časť štandardného procesu RAG do databázovej vrstvy (načítanie → rozdelenie → vytvorenie embeddingov → synchronizácia embeddingov) namiesto toho, aby databáza slúžila „iba ako úložisko“ embeddingov.
Prvé dojmy sú sľubné, no len čo sa proces RAG čo i len mierne skomplikuje (najmä spôsoby delenia textu), pgai už nie je vhodné. Tento projekt však budeme pozorne sledovať.
RAG možno vytvoriť mnohými spôsobmi. Podrobnejší rozbor rôznych prístupov nájdete v článku Praktické príklady prispôsobených riešení RAG. Keď vám záleží na kvalite, možnosti návrhu sú prekvapivo rozsiahle. Bežný „predvolený“ prístup vyzerá približne takto:
Vezmite súbor dokumentov.
Rozdeľte ich na časti. Dá sa to urobiť mnohými spôsobmi (napr. podľa odsekov alebo sémantických skupín).
Z každej časti vytvorte embedding.
Embeddingy uložte do vektorovej databázy (Pinecone, Milvus a pod.) alebo do Postgresu pomocou pgvector.
Pri spracovaní dopytu vyhľadajte najpodobnejšie časti `a odošlite ich do LLM (aj to sa dá urobiť mnohými spôsobmi).
V mnohých technologických riešeniach prebiehajú kroky (1) až (3) mimo databázy, v aplikačnom kóde alebo dátovom procese, pričom databáza slúži najmä na:
ukladanie embeddingov
vyhľadávanie embeddingov
pgai je rozšírenie pre Postgres (open-source, vyvíjané spoločnosťou Timescale), ktoré sa snaží túto hranicu zotrieť.
Namiesto embeddingov, ktoré musí aplikácia spravovať manuálne, ich pgai mení na databázovú funkciu:
Určíte tabuľku alebo dokumenty, pre ktoré sa majú vytvoriť embeddingy.
Zadáte model embeddingov a stratégiu delenia.
O zvyšok sa postará pgai vrátane aktualizácie embeddingov pri zmenách zdrojových údajov.
Prísľub je lákavý:
Menej špecifického prepájacieho kódu, ktorý treba udržiavať.
Pri zmenách zdrojových dokumentov by malo byť jednoduchšie udržiavať embeddingy „aktuálne“.
Postgres/pgai spravuje opakované pokusy, limity požiadaviek, neúspešné úlohy a podobne.
Poznámka pre čitateľa: pgai obsahuje pgvector (ďalšie veľmi obľúbené rozšírenie RAG pre Postgres). pgvector pridáva do Postgresu vektorové úložisko a vyhľadávanie podľa podobnosti. pgai na ňom stavia a automatizuje kroky procesu RAG, ako sú delenie, vytváranie embeddingov a ich aktualizácia.
1) Uvedenie do prevádzky je jednoduché.
Základný scenár je pomerne jednoduchý:
Stiahnite obrazy Docker od Timescale (databázu a pracovný proces).
Zadajte kľúč API poskytovateľa embeddingov.
Pomocou niekoľkých príkazov SQL definujte vektorizátor (teda čo sa má spracovať, ako sa má obsah deliť a ktorý model sa má použiť).
pgai potom zabezpečí, aby pracovný proces vektorizátora bežal samostatne a asynchrónne vytváral embeddingy (napr. každých päť minút alebo v ľubovoľnom intervale).
2) Je praktické vykonávať celý proces „blízko“ databázy.
pgai dokáže načítať obsah z tabuliek aj dokumenty z úložísk, ako je S3, a následne ich analyzovať, rozdeliť a vytvoriť embeddingy. Podporuje aj rôzne formáty textových dokumentov, napríklad PDF či Markdown.
1) Strácate veľkú časť kontroly (a RAG ju niekedy potrebuje).
Vysokovýkonné systémy RAG (z hľadiska kvality odpovedí) často vyžadujú procesy na mieru, napríklad:
vlastné pravidlá delenia (podľa nadpisov, strán, striedania hovoriacich a pod.)
delenie zohľadňujúce metadáta (zachovanie názvov sekcií, časových značiek, autorov a typu dokumentu)
rôzne stratégie embeddingov pre jednotlivé typy dokumentov
V uvedených oblastiach ponúka pgai menšiu flexibilitu.
V súčasnosti existujú dve hlavné stratégie delenia: rozdeľovač textu podľa znakov a rekurzívny rozdeľovač podľa znakov. K dispozícii je aj možnosť obsah nedeliť. Niektorým prípadom použitia to môže stačiť, no mnohé produkčné systémy RAG vyžadujú väčšie prispôsobenie.
Bolo by skvelé, keby Timescale začlenil niektoré pokročilejšie stratégie delenia známe z knižníc, ako je Chonkie, a podobne podporoval pokročilé návrhy, napríklad kontextové vyhľadávanie od Anthropic.
2) Primárne textové, nie multimodálne.
Mnohé zaujímavé problémy RAG už nie sú výlučne textové:
PDF s diagramami
snímky obrazovky a obrázky
zvukové nahrávky
videoklipy
Aj keď z týchto zdrojov dokážete „extrahovať text“, nejde o plnohodnotný multimodálny proces embeddingov.
Ak bude pgai napokon komplexne podporovať multimodálne modely (načítanie → rozdelenie → vytvorenie embeddingov pre veľké obrázky, zvuk a video uložené v S3, so spoľahlivou synchronizáciou), bude to presvedčivé. Dnes však podporuje len proces textových embeddingov.
3) Ak potrebujete iba embeddingy, pgai možno nepotrebujete.
Ak je váš proces načítania už prispôsobený (alebo taký musí byť), „vytváranie embeddingov z častí textu“ nie je najťažšou súčasťou RAG. V takom prípade pgai rieši najjednoduchšiu časť problému.
Ak sa navyše vaša znalostná databáza aktualizuje len zriedka, automatická synchronizácia embeddingov neprináša až takú veľkú hodnotu.
Mimoriadne vhodným využitím pgai by bolo nasadenie rozhrania na prevod textu na SQL nad vašimi databázami. Dá sa to pomerne jednoducho dosiahnuť pomocou modulu semantic_catalog, ktorý ponúka pgai. Stačí ho nastaviť takto:
Bash
a príkazom pgai semantic-catalog create nechať sémantický katalóg načítať vaše dátové slovníky. Tým sa z vášho dátového úložiska vytvorí kontext, ktorý vyzerá približne takto:
Plain Text
Tento kontext má teraz pgai k dispozícii niekoľkými spôsobmi:
Prostredníctvom sémantického vyhľadávania:
Tento dopyt vráti tabuľky, funkcie a ďalšie objekty, ktoré môžu súvisieť s vaším dopytom v prirodzenom jazyku:
Bash
Získanie nespracovaného kontextu:
Zobrazí sa nespracovaný kontext YAML súvisiaci s vaším dopytom v prirodzenom jazyku:
Bash
Vygenerovanie SQL:
Prípadne môžete priamo vygenerovať nespracované SQL potrebné na zodpovedanie dopytu. Kontext z predchádzajúceho kroku sa odošle do LLM, ktorý vygeneruje odpoveď:
Bash
Ak vytvárate pomerne jednoduchý systém RAG, pgai stojí za vyskúšanie, ak chcete:
používať Postgres ako hlavný zdroj údajov,
minimum prepájacieho kódu,
automaticky synchronizované embeddingy,
rýchlo pridať do databáz prevod textu na SQL,
experimentovať s novými nástrojmi RAG a rozšíreniami pre Postgres.
S nasadením pgai sa zrejme oplatí počkať, ak váš proces RAG vyžaduje niečo z nasledujúceho:
výrazne prispôsobenú logiku načítania alebo delenia obsahu
množstvo typov dokumentov s rôznymi požiadavkami na analýzu
multimodálne embeddingy
Napokon, hoci je zrejmé, že pgvector sa výrazne rozšíril, nie je jasné, či pgai vzbudí rovnaký záujem, a teda získa aj porovnateľnú podporu (treba však dodať, že existuje len približne 18 mesiacov).
pgai predstavuje zaujímavý prístup k RAG: databáze zveruje viac bežnej prevádzkovej práce, čím zjednodušuje aplikačný kód.
V súčasnosti je:
použiteľné a skutočne príjemné pri jednoduchých riešeniach RAG
málo flexibilné pre viac prispôsobené procesy (najmä multimodálne)
Má potenciál a rozhodne sa oplatí sledovať jeho ďalší vývoj.