LLM dokážou najednou „vidět“ jen omezené množství textu (kontextové okno). U menších úloh to funguje, ale u znalostní báze o tisících stran už tento přístup selhává. I když je kontextové okno dostatečné, výkon může přesto klesat kvůli problému „hledání jehly v kupce sena“.
RAG („generování rozšířené o vyhledávání“) se stal velmi rozšířeným postupem: udržujete znalostní bázi (dokumentaci, wiki, zásady, přepisy atd.), pomocí embeddingů sémanticky prohledáte uživatelský dotaz, získáte nejrelevantnější úryvky a spolu s otázkou je předáte LLM. Tím se omezí kontext modelu, což při správném provedení může zvýšit kvalitu odpovědí a omezit halucinace.
pgai je open-source rozšíření Postgresu (s doprovodnými nástroji), které umožňuje vytvářet pracovní postupy „AI vyhledávání“ nad důvěryhodnou open-source databází PostgreSQL.
Hlavní myšlenkou je přesunout větší část standardní RAG pipeline do databázové vrstvy (příjem → dělení → embedding → průběžná synchronizace embeddingů), místo aby databáze sloužila jako „pouhé úložiště“ embeddingů.
První dojmy jsou slibné, ale jakmile se RAG pipeline byť jen trochu zkomplikuje (zejména způsob dělení), pgai už není vhodné. Tento projekt však budeme pozorně sledovat.
RAG lze vytvořit mnoha způsoby. Podrobnější rozbor různých přístupů najdete v článku Praktické příklady přizpůsobených řešení RAG. Jakmile vám začne záležet na kvalitě, možnosti návrhu jsou překvapivě rozsáhlé. Běžný „výchozí“ postup zpravidla vypadá takto:
Vezměte sadu dokumentů.
Rozdělte je na části. Existuje mnoho způsobů, jak to udělat (např. podle odstavců nebo sémantických celků).
Z každé části vytvořte embedding.
Embeddingy uložte do vektorové databáze (Pinecone, Milvus atd.) nebo pomocí pgvector do Postgresu.
Při dotazu vyhledejte nejbližší části `a předejte je LLM (i zde opět existuje mnoho možných postupů).
V mnoha technologických řešeních probíhají kroky (1)–(3) mimo databázi, v aplikačním kódu nebo datové pipeline. Databáze se používá hlavně k těmto účelům:
ukládání embeddingů
prohledávání embeddingů
pgai je open-source rozšíření Postgresu vyvíjené společností Timescale, které se snaží tuto hranici setřít.
Místo aby embeddingy musela ručně spravovat vaše aplikace, dělá z nich pgai databázovou funkci:
Určíte tabulku nebo dokumenty, pro které chcete vytvořit embeddingy.
Zadáte embeddingový model a strategii dělení.
O zbytek se postará pgai, včetně průběžné aktualizace embeddingů při změnách zdrojových dat.
Příslib je lákavý:
Méně pomocného kódu na míru, který je nutné udržovat.
Při změně zdrojových dokumentů by mělo být snazší udržovat embeddingy aktuální.
Postgres/pgai spravuje opakované pokusy, limity požadavků, neúspěšné úlohy atd.
Poznámka pro čtenáře: pgai v sobě zahrnuje pgvector (další velmi oblíbené rozšíření Postgresu pro RAG). pgvector přidává do Postgresu ukládání vektorů a vyhledávání podle podobnosti. pgai na něm staví a automatizuje kroky RAG pipeline, jako jsou dělení, vytváření embeddingů a jejich průběžná aktualizace.
1) Zprovoznění je snadné.
Ideální postup je poměrně jednoduchý:
Stáhněte si dockerové obrazy Timescale (databáze + pracovní proces).
Zadejte klíč API svého poskytovatele embeddingů.
Pomocí několika SQL příkazů deklarujte vektorizátor (tedy co se má převést na embeddingy, jak obsah rozdělit a který model použít).
pgai poté zajistí, aby pracovní proces vektorizátoru běžel jako samostatný proces a asynchronně vytvářel embeddingy (např. každých 5 minut nebo v libovolném jiném intervalu).
2) Je příjemné provozovat celou pipeline „poblíž“ databáze.
pgai dokáže načítat obsah z tabulek i dokumenty z úložišť, jako je S3, a následně je analyzovat, rozdělit a převést na embeddingy. Zvládá také různé formáty textových dokumentů, například PDF nebo Markdown.
1) Přicházíte o značnou část kontroly (a RAG ji někdy potřebuje).
Vysoce výkonné systémy RAG (měřeno kvalitou odpovědí) často vyžadují pipeline na míru, například:
vlastní pravidla dělení (podle nadpisů, stran, střídání mluvčích atd.)
dělení zohledňující metadata (zachování názvů oddílů, časových údajů, autorů a typu dokumentu)
různé strategie embeddingů pro jednotlivé typy dokumentů
V těchto oblastech nabízí pgai menší flexibilitu.
V současnosti existují dvě hlavní strategie dělení: dělení textu podle počtu znaků a rekurzivní dělení podle počtu znaků. K dispozici je také možnost text vůbec nedělit. Pro některé případy použití to může stačit, mnoho produkčních systémů RAG však vyžaduje větší míru přizpůsobení.
Bylo by skvělé, kdyby Timescale dokázal začlenit některé pokročilejší strategie dělení známé z knihoven, jako je Chonkie, a podobně podporoval i pokročilé návrhy, například kontextové vyhledávání od Anthropic.
2) Zaměřuje se na text, nikoli na multimodalitu.
Mnoho zajímavých problémů RAG už není čistě textových:
PDF s diagramy
snímky obrazovky / obrázky
zvukové nahrávky
videoklipy
I když z těchto zdrojů dokážete „extrahovat text“, není to totéž jako skutečně multimodální embeddingová pipeline.
Pokud bude pgai časem komplexně podporovat multimodální modely (načítání → dělení → embedding velkých obrázků, audia či videa uloženého v S3, včetně spolehlivé synchronizace), bude to velmi zajímavé. Dnes však jde o pracovní postup pro textové embeddingy.
3) Pokud potřebujete pouze embeddingy, pgai možná nepotřebujete.
Pokud už máte vlastní pipeline pro příjem dat (nebo ji potřebujete), není „vytváření embeddingů z částí textu“ tou nejtěžší částí RAG. V takovém případě pgai řeší tu nejsnazší část problému.
Pokud se navíc vaše znalostní báze aktualizuje jen zřídka, automatická synchronizace embeddingů nepřináší takovou hodnotu.
Jedním z obzvlášť vhodných způsobů využití pgai by bylo nasazení rozhraní pro převod textu na SQL nad vašimi databázemi. Toho lze poměrně snadno dosáhnout pomocí modulu semantic_catalog, který nabízí pgai. Stačí provést toto nastavení:
Bash
a pomocí pgai semantic-catalog create nechat sémantický katalog načíst vaše datové slovníky. Tím se z vašeho datového úložiště vygeneruje kontext, který vypadá přibližně takto:
Plain Text
Tento kontext je nyní v pgai dostupný několika způsoby:
Prostřednictvím sémantického vyhledávání:
Tento dotaz vrátí tabulky, funkce a další objekty, které mohou být relevantní pro váš dotaz v přirozeném jazyce:
Bash
Získání nezpracovaného kontextu:
Tím se vykreslí nezpracovaný kontext YAML související s vaším dotazem v přirozeném jazyce:
Bash
Generování SQL:
Nebo můžete přímo vygenerovat nezpracovaný SQL kód potřebný k zodpovězení dotazu. Kontext z předchozího kroku se odešle LLM, který vygeneruje odpověď:
Bash
Pokud vytváříte relativně jednoduchý systém RAG, stojí pgai za vyzkoušení, chcete-li:
používat Postgres jako hlavní zdroj pravdivých dat,
minimum pomocného kódu,
embeddingy, které se automaticky synchronizují,
rychle nasadit převod textu na SQL nad svými databázemi,
experimentovat s novými nástroji RAG a rozšířeními Postgresu.
S pgai se patrně vyplatí počkat, pokud vaše RAG pipeline vyžaduje něco z následujícího:
výrazně přizpůsobenou logiku příjmu nebo dělení dat
mnoho typů dokumentů s různými požadavky na analýzu
multimodální embeddingy
A konečně: pgvector se zjevně těší širokému využití, není však jasné, zda pgai vzbudí stejný zájem, a získá tedy i srovnatelnou podporu (přestože existuje teprve přibližně 18 měsíců).
pgai představuje zajímavý přístup k RAG, při kterém databáze přebírá více rutinní provozní práce, takže aplikační kód může být jednodušší.
V současnosti je:
použitelné a skutečně příjemné pro jednoduchá řešení RAG
málo flexibilní pro více přizpůsobené pipeline (zejména multimodální)
Má slibný potenciál a rozhodně stojí za to sledovat jeho další vývoj.