LLM:er kan bara ”se” en begränsad mängd text åt gången (kontextfönstret). Det fungerar för mindre uppgifter, men inte när en kunskapsbas omfattar tusentals sidor. Även när kontextfönstret är tillräckligt stort kan prestandan försämras på grund av problemet med att ”hitta en nål i en höstack”.
RAG (”retrieval augmented generation”) har blivit ett mycket vanligt mönster där man underhåller en kunskapsbas (dokument, wikier, policyer, transkriptioner osv.), gör en semantisk sökning utifrån användarens fråga för att hämta de mest relevanta utdragen med hjälp av inbäddningar och sedan skickar dessa segment till LLM:en tillsammans med frågan. Det begränsar modellens kontext och kan, när det görs rätt, förbättra svarskvaliteten och minska hallucinationerna.
pgai är ett Postgres-tillägg med öppen källkod (och tillhörande verktyg) som hjälper dig att bygga arbetsflöden för ”AI-hämtning” ovanpå den betrodda databasen PostgreSQL med öppen källkod.
Grundidén är att flytta mer av RAG-standardflödet till databaslagret (läs in → segmentera → bädda in → håll inbäddningarna synkroniserade), i stället för att behandla databasen som ”bara lagring” för inbäddningar.
Vårt första intryck är att det verkar lovande, men att det inte passar när RAG-flödet blir ens måttligt komplicerat, särskilt när det gäller segmenteringsmetoder. Vi kommer dock att följa projektet noga.
RAG kan byggas på många olika sätt. En utförligare genomgång av olika RAG-metoder finns i Praktiska exempel på skräddarsydda RAG-lösningar. När kvaliteten är viktig blir designmöjligheterna förvånansvärt omfattande, men den vanliga standardmetoden ser i allmänhet ut så här:
Samla ihop en mängd dokument.
Dela upp dem i segment. Det finns många olika metoder för detta (t.ex. stycken och semantiska grupperingar).
Omvandla varje segment till en inbäddning.
Lagra inbäddningarna i en vektordatabas (Pinecone, Milvus osv.) eller i Postgres med pgvector.
När en fråga ställs söker du efter de närmaste segmenten `och skickar dem till LLM:en (även detta kan göras på många olika sätt).
I många teknikstackar sker steg (1)–(3) utanför databasen, i programkod eller ett dataflöde, medan databasen främst används för att:
lagra inbäddningar
söka bland inbäddningar
pgai är ett Postgres-tillägg (med öppen källkod, utvecklat av Timescale) som försöker sudda ut denna gräns.
I stället för att behandla inbäddningar som något programmet hanterar manuellt gör pgai dem till en databasfunktion:
Du anger vilken tabell eller vilka dokument som ska bäddas in.
Du anger inbäddningsmodell och segmenteringsstrategi.
pgai sköter resten, inklusive att hålla inbäddningarna uppdaterade när källdatan ändras.
Det låter lockande:
Mindre specialskriven integrationskod att underhålla.
Det bör bli enklare att hålla inbäddningarna aktuella när de underliggande källdokumenten ändras.
Postgres/pgai hanterar nya försök, hastighetsbegränsningar, misslyckade jobb osv.
Anmärkning till läsaren: pgai innehåller pgvector (ett annat mycket populärt Postgres-tillägg för RAG). pgvector tillför vektorlagring och likhetssökning i Postgres, medan pgai bygger vidare på detta för att automatisera steg i RAG-flödet, såsom segmentering, inbäddning och uppdatering av inbäddningarna.
1) Det är enkelt att komma igång.
I normalfallet är det förhållandevis enkelt:
Hämta Timescales Docker-avbildningar (databas + worker).
Ange API-nyckeln för din inbäddningsleverantör.
Kör en liten mängd SQL för att definiera vektoriseraren (i princip vad som ska bäddas in, hur det ska segmenteras och vilken modell som ska användas).
Därefter ser pgai till att en vektoriseringsworker körs som en separat process och genererar inbäddningar asynkront (t.ex. var femte minut eller med valfritt intervall).
2) Det är praktiskt att köra hela flödet ”nära” databasen.
pgai kan läsa in innehåll från tabeller och även hämta dokument från exempelvis S3 för att sedan tolka, segmentera och bädda in dem. Det kan även hantera olika textdokumentformat, såsom pdf och Markdown.
1) Du förlorar mycket kontroll (och RAG kräver ibland kontroll).
RAG-system med hög prestanda (mätt som svarskvalitet) kräver ofta skräddarsydda flöden, såsom:
anpassade segmenteringsregler (efter rubrik, sida, talarbyte osv.)
metadataanpassad segmentering (behåll avsnittsrubriker, tidsstämplar, författare och dokumenttyp)
olika inbäddningsstrategier för varje dokumenttyp
pgai ger mindre flexibilitet för ovanstående.
För närvarande finns två huvudsakliga segmenteringsstrategier: teckenbaserad textdelning och rekursiv teckenbaserad textdelning, samt ett alternativ utan segmentering. Det kan räcka för vissa användningsfall, men många RAG-system i produktion kräver mer anpassning.
Det vore fantastiskt om Timescale kunde införliva några av de mer avancerade segmenteringsstrategier som finns i bibliotek som Chonkie och även stödja avancerade upplägg som Anthropics kontextuella hämtning.
2) Text i första hand, inte multimodalt.
Många intressanta RAG-problem handlar inte längre enbart om text:
PDF-filer med diagram
skärmbilder/bilder
ljudinspelningar
videoklipp
Även om du kan ”extrahera text” från dessa källor är det inte samma sak som ett verkligt multimodalt inbäddningsflöde.
Om pgai så småningom får heltäckande stöd för multimodala modeller (läs in → segmentera → bädda in stora bilder samt ljud- och videofiler som lagras i S3, med robust synkronisering) vore det övertygande. I dag är det dock ett arbetsflöde för textinbäddning.
3) Om du bara behöver inbäddningar behöver du kanske inte pgai.
Om ditt inläsningsflöde redan är skräddarsytt (eller behöver vara det) är det inte ”att bädda in textsegment” som är den svåraste delen av RAG. I det fallet löser pgai problemets enklaste del.
Om kunskapsbasen dessutom uppdateras sällan är automatisk synkronisering av inbäddningar inte lika värdefull.
Ett särskilt bra sätt att använda pgai vore att lägga ett text-till-SQL-gränssnitt ovanpå databaserna. Det kan göras ganska enkelt med modulen semantic_catalog som pgai tillhandahåller. Konfigurera det så här:
Bash
och låt den semantiska katalogen läsa av dina dataordlistor med pgai semantic-catalog create. Det genererar kontext från ditt datalager som ser ut ungefär så här:
Plain Text
Kontexten är nu tillgänglig för pgai på flera olika sätt:
Genom semantisk sökning:
Den här frågan returnerar tabeller, funktioner och andra objekt som kan vara relevanta för din fråga på naturligt språk:
Bash
Hämta rå kontext:
Det här återger den råa YAML-kontext som hör till din fråga på naturligt språk:
Bash
Generera SQL:
Du kan också generera den råa SQL som behövs för att besvara frågan direkt. Kontexten från föregående steg skickas till en LLM, som genererar ett svar:
Bash
Om du bygger ett förhållandevis enkelt RAG-system är pgai värt att prova om du vill ha:
Postgres som primär datakälla,
minimalt med integrationskod,
inbäddningar som automatiskt hålls synkroniserade,
ett snabbt sätt att lägga till text-till-SQL i dina databaser,
möjlighet att experimentera med nya RAG-verktyg och Postgres-tillägg.
Det är förmodligen klokt att avvakta med pgai om ditt RAG-flöde kräver något av följande:
omfattande specialanpassad inläsnings- eller segmenteringslogik
många dokumenttyper med olika tolkningskrav
multimodala inbäddningar
Slutligen är det tydligt att pgvector har fått stor spridning, men det är oklart om pgai kommer att väcka lika stort intresse och därmed få samma stöd (även om det bara har funnits i cirka 18 månader).
pgai är en intressant RAG-metod som låter databaser sköta mer av det rutinmässiga driftarbetet, så att programkoden kan bli enklare.
Just nu är det:
användbart och genuint smidigt för enkla RAG-konfigurationer
inte tillräckligt flexibelt för mer skräddarsydda flöden (särskilt multimodala)
Det verkar lovande och är definitivt värt att följa för att se hur det utvecklas.