LLM's kunnen maar een beperkte hoeveelheid tekst tegelijk "zien" (het contextvenster). Dit werkt voor kleine taken, maar schiet tekort wanneer een kennisbank duizenden pagina's omvat. Zelfs als het contextvenster groot genoeg is, kunnen de prestaties nog afnemen door het probleem van de "speld in een hooiberg".
RAG ('retrieval augmented generation') is uitgegroeid tot een veelgebruikt patroon: je beheert een kennisbank (documenten, wiki's, beleidsregels, transcripties enz.), voert voor een gebruikersvraag een semantische zoekopdracht uit om met embeddings de relevantste fragmenten op te halen en geeft die fragmenten vervolgens samen met de vraag door aan de LLM. Dit begrenst de context van het model en kan, mits goed uitgevoerd, de kwaliteit van antwoorden verbeteren en hallucinaties verminderen.
pgai is een opensource-uitbreiding voor Postgres (met bijbehorende tools) waarmee je workflows voor "AI-retrieval" kunt bouwen boven op de vertrouwde opensourcedatabase PostgreSQL.
Het belangrijkste idee is om een groter deel van de standaard-RAG-pijplijn naar de databaselaag te verplaatsen (inlezen → opdelen → embedden → embeddings synchroniseren), in plaats van de database als "alleen opslag" voor embeddings te behandelen.
Onze eerste indruk is dat het veelbelovend is, maar ongeschikt wordt zodra je RAG-pijplijn ook maar enigszins ingewikkeld is, vooral wat betreft de manieren waarop content wordt opgedeeld. We blijven dit project echter nauwlettend volgen.
Je kunt RAG op veel manieren bouwen. Lees voor een uitgebreidere bespreking van de verschillende benaderingen Praktische voorbeelden van RAG-oplossingen op maat. Zodra kwaliteit belangrijk wordt, blijken er verrassend veel ontwerpkeuzes te zijn. De gebruikelijke "standaardaanpak" ziet er ongeveer zo uit:
Neem een verzameling documenten.
Deel ze op in fragmenten. Daar zijn veel verschillende methoden voor, bijvoorbeeld op basis van alinea's of semantische groepen.
Zet elk fragment om in een embedding.
Sla embeddings op in een vectordatabase (Pinecone, Milvus enz.) of met pgvector in Postgres.
Zoek bij een query naar de meest overeenkomende fragmenten `en geef ze door aan de LLM (ook dit kan weer op veel manieren).
In veel technologiestacks vinden stap (1)–(3) buiten de database plaats, in applicatiecode of een datapijplijn. De database wordt vooral gebruikt voor:
embeddings opslaan
embeddings doorzoeken
pgai is een opensource-uitbreiding voor Postgres, ontwikkeld door Timescale, die deze scheidslijn probeert te vervagen.
In plaats van embeddings te behandelen als iets wat je applicatie handmatig beheert, maakt pgai er een databasefunctie van:
Je bepaalt welke tabel of documenten je wilt embedden.
Je geeft het embeddingmodel en een strategie voor het opdelen op.
pgai beheert de rest en houdt de embeddings onder meer actueel wanneer je brongegevens veranderen.
Dat klinkt aantrekkelijk:
Minder specifieke koppelcode die moet worden onderhouden.
Het wordt eenvoudiger om embeddings "actueel" te houden wanneer de onderliggende brondocumenten veranderen.
Postgres/pgai beheert nieuwe pogingen, frequentielimieten, mislukte taken enzovoort.
Opmerking voor de lezer: pgai bevat pgvector, een andere zeer populaire RAG-uitbreiding voor Postgres. pgvector voegt vectoropslag en zoeken op gelijkenis toe aan Postgres. pgai bouwt daarop voort en automatiseert stappen in de RAG-pijplijn, zoals opdelen, embedden en het actueel houden van embeddings.
1) Het is eenvoudig aan de praat te krijgen.
Het ideale scenario is vrij eenvoudig:
Haal de Docker-images van Timescale op (database + worker).
Geef de API-sleutel van je embeddingprovider op.
Voer een kleine hoeveelheid SQL uit om de vectoriser te definiëren: wat er moet worden geëmbed, hoe het moet worden opgedeeld en welk model moet worden gebruikt.
Daarna zorgt pgai ervoor dat een vectoriser-worker als afzonderlijk proces draait en asynchroon embeddings genereert, bijvoorbeeld elke vijf minuten of volgens een ander gewenst interval.
2) Het is prettig om de hele pijplijn "dicht bij" de database uit te voeren.
pgai kan content uit tabellen inlezen, maar ook documenten laden uit locaties zoals S3 en ze vervolgens parseren, opdelen en embedden. Het ondersteunt ook verschillende tekstdocumentindelingen, zoals pdf en Markdown.
1) Je verliest veel controle, terwijl RAG die soms juist nodig heeft.
RAG-systemen die kwalitatief hoogwaardige antwoorden moeten leveren, vereisen vaak pijplijnen op maat, zoals:
aangepaste regels voor opdelen (op koppen, pagina's, sprekerswisselingen enz.)
opdelen met inachtneming van metadata (sectietitels, tijdstempels, auteurs en documenttype behouden)
verschillende embeddingstrategieën per documenttype
Voor het bovenstaande biedt pgai minder flexibiliteit.
Momenteel zijn er twee belangrijke strategieën voor opdelen: een tekstsplitser op basis van tekens en een recursieve variant daarvan. Je kunt er ook voor kiezen om niets op te delen. Dat kan voor sommige toepassingen voldoende zijn, maar veel RAG-productiesystemen vereisen meer maatwerk.
Het zou geweldig zijn als Timescale enkele geavanceerdere strategieën voor het opdelen uit bibliotheken zoals Chonkie zou kunnen integreren en ook geavanceerde ontwerpen zoals contextual retrieval van Anthropic zou ondersteunen.
2) Tekstgericht, niet multimodaal.
Veel interessante RAG-problemen draaien niet langer uitsluitend om tekst:
Pdf's met diagrammen
schermafbeeldingen/afbeeldingen
audio-opnamen
videofragmenten
Zelfs als je uit deze bronnen "tekst kunt extraheren", is dat niet hetzelfde als een echte multimodale embeddingpijplijn.
Als pgai uiteindelijk multimodale modellen volledig zou ondersteunen (grote afbeeldingen en audio/video uit S3 laden → opdelen → embedden, met betrouwbare synchronisatie), zou dat overtuigend zijn. Momenteel is het echter een workflow voor tekstembeddings.
3) Als je alleen embeddings nodig hebt, heb je pgai misschien niet nodig.
Als je al een aangepaste pijplijn voor het inlezen hebt of nodig hebt, is "tekstfragmenten embedden" niet het moeilijkste onderdeel van RAG. In dat geval lost pgai het eenvoudigste deel van het probleem op.
Ook is automatische synchronisatie van embeddings minder waardevol als je kennisbank niet vaak wordt bijgewerkt.
Een bijzonder goede toepassing van pgai is een tekst-naar-SQL-interface boven op je databases. Dit kan vrij eenvoudig met de module semantic_catalog van pgai. Stel het eenvoudig als volgt in:
Bash
en laat de semantische catalogus je datawoordenboeken uitlezen met pgai semantic-catalog create. Dit genereert context uit je gegevensopslag die er ongeveer zo uitziet:
Plain Text
Deze context is nu op verschillende manieren beschikbaar voor pgai:
Via semantisch zoeken:
Deze query retourneert de tabellen, functies en andere objecten die mogelijk relevant zijn voor je query in natuurlijke taal:
Bash
Ruwe context ophalen:
Hiermee wordt de ruwe YAML-context weergegeven die verband houdt met je query in natuurlijke taal:
Bash
SQL genereren:
Je kunt ook rechtstreeks de ruwe SQL genereren die nodig is om je query te beantwoorden. De context uit de vorige stap wordt naar een LLM gestuurd, waarna een antwoord wordt gegenereerd:
Bash
Als je een relatief eenvoudig RAG-systeem bouwt, is pgai het proberen waard als je het volgende wilt:
Postgres als centraal registratiesysteem,
minimale koppelcode,
embeddings die automatisch gesynchroniseerd blijven,
een snelle manier om tekst-naar-SQL op je databases toe te passen,
experimenteren met nieuwe RAG-tools en uitbreidingen voor Postgres.
Je kunt waarschijnlijk beter nog even wachten met pgai als je RAG-pijplijn een van de volgende zaken vereist:
veel aangepaste logica voor het inlezen of opdelen
veel documenttypen met verschillende vereisten voor het parseren
multimodale embeddings
Tot slot is het duidelijk dat pgvector breed wordt gebruikt, maar niet of pgai op evenveel belangstelling en daarmee ondersteuning kan rekenen. Daarbij moet worden opgemerkt dat het pas ongeveer achttien maanden bestaat.
pgai is een interessante RAG-aanpak waarbij databases meer routinematige beheertaken uitvoeren, zodat je applicatiecode eenvoudiger kan blijven.
Op dit moment is het:
bruikbaar en bijzonder prettig voor eenvoudige RAG-configuraties
niet flexibel genoeg voor meer op maat gemaakte pijplijnen, vooral multimodale
Het is veelbelovend en absoluut de moeite waard om te volgen hoe het zich verder ontwikkelt.