LLM-er kan bare «se» en begrenset mengde tekst om gangen (kontekstvinduet). Dette fungerer for små oppgaver, men bryter sammen når en kunnskapsbase omfatter tusenvis av sider. Selv når kontekstvinduet er stort nok, kan ytelsen svekkes på grunn av «nålen i høystakken»-problemet.
RAG («gjenfinningsutvidet generering») har blitt et svært vanlig mønster der du vedlikeholder en kunnskapsbase (dokumenter, wikier, retningslinjer, transkripsjoner osv.), utfører et semantisk søk basert på brukerens spørring for å hente de mest relevante utdragene ved hjelp av embeddings, og deretter sender disse delene til LLM-en sammen med spørsmålet. Dette avgrenser modellens kontekst og kan, når det gjøres riktig, gi bedre svar og færre hallusinasjoner.
pgai er en Postgres-utvidelse med åpen kildekode (og tilhørende verktøy) som hjelper deg med å bygge arbeidsflyter for «KI-gjenfinning» oppå den anerkjente databasen PostgreSQL med åpen kildekode.
Hovedideen er å flytte mer av den vanlige RAG-prosessen til databaselaget (hent inn → del opp → opprett embeddings → hold embeddings synkronisert), i stedet for å behandle databasen som «bare lagring» for embeddings.
Førsteinntrykket er at løsningen er lovende, men at den blir uegnet så snart RAG-prosessen blir bare litt komplisert, særlig når det gjelder oppdelingsmetoder. Vi kommer likevel til å følge prosjektet nøye.
RAG kan bygges på mange måter. Du finner en mer omfattende gjennomgang av ulike RAG-metoder i Praktiske eksempler på skreddersydde RAG-løsninger. Mulighetene blir overraskende omfattende når kvalitet er viktig, men den vanlige «standardmetoden» ser stort sett slik ut:
Ta en bunke dokumenter.
Del dem opp i mindre deler. Dette kan gjøres på mange måter, for eksempel etter avsnitt eller semantiske grupper.
Gjør hver del om til en embedding.
Lagre embeddings i en vektordatabase (Pinecone, Milvus osv.) eller i Postgres ved hjelp av pgvector.
Når en spørring mottas, søker du etter de nærmeste delene `og sender dem til LLM-en (også dette kan gjøres på mange måter).
I mange teknologistakker utføres trinn (1)–(3) utenfor databasen, i programkode eller en dataprosess, mens databasen hovedsakelig brukes til å:
lagre embeddings
søke i embeddings
pgai er en Postgres-utvidelse (med åpen kildekode, utviklet av Timescale) som forsøker å viske ut dette skillet.
I stedet for å behandle embeddings som noe appen må administrere manuelt, gjør pgai dem til en databasefunksjon:
Du angir hvilken tabell eller hvilke dokumenter du vil opprette embeddings for.
Du angir embedding-modellen og en oppdelingsstrategi.
pgai håndterer resten, inkludert å holde embeddings oppdatert når kildedataene endres.
Dette høres fristende ut:
Mindre skreddersydd integrasjonskode som må vedlikeholdes.
Det bør bli enklere å holde embeddings «ferske» når de underliggende kildedokumentene endres.
Postgres/pgai håndterer nye forsøk, hastighetsbegrensninger, mislykkede jobber osv.
Merknad til leseren: pgai inkluderer pgvector (en annen svært populær RAG-utvidelse for Postgres). pgvector gir Postgres vektorlagring og likhetssøk, mens pgai bygger videre på dette for å automatisere trinn i RAG-prosessen, som oppdeling, oppretting av embeddings og løpende oppdatering av disse.
1) Det er enkelt å komme i gang.
Standardoppsettet er rimelig enkelt:
Hent Docker-avbildningene fra Timescale (database + arbeidsprosess).
Oppgi API-nøkkelen til embedding-leverandøren.
Kjør litt SQL for å definere vektorisereren (altså hva som skal bygges inn, hvordan det skal deles opp, og hvilken modell som skal brukes).
Deretter sørger pgai for at en vektoriseringsarbeider kjører som en separat prosess og genererer embeddings asynkront, for eksempel hvert femte minutt eller med ønsket intervall.
2) Det er praktisk å kjøre hele prosessen «nær» databasen.
pgai kan hente inn innhold fra tabeller og laste dokumenter fra steder som S3, før de analyseres, deles opp og gjøres om til embeddings. Den kan også håndtere ulike tekstdokumentformater som PDF, Markdown osv.
1) Du mister mye kontroll (og RAG krever av og til kontroll).
RAG-systemer med høy ytelse, målt etter svarkvalitet, krever ofte skreddersydde prosesser, for eksempel:
egendefinerte oppdelingsregler (etter overskrifter, sider, bytte av taler osv.)
metadatabevisst oppdeling (behold seksjonstitler, tidsstempler, forfattere og dokumenttype)
ulike embedding-strategier for hver dokumenttype
pgai gir mindre fleksibilitet på disse områdene.
For øyeblikket finnes det to hovedstrategier for oppdeling: tegnbasert tekstdeling og rekursiv tegnbasert tekstdeling, i tillegg til et alternativ uten oppdeling. Det kan være nok for enkelte bruksområder, men mange RAG-systemer i produksjon krever mer tilpasning.
Det ville vært svært nyttig om Timescale kunne innlemme noen av de mer avanserte oppdelingsstrategiene vi finner i biblioteker som Chonkie, og samtidig støtte avanserte løsninger som Anthropics kontekstuelle gjenfinning.
2) Tekst først, ikke multimodalt.
Mange interessante RAG-problemer handler ikke lenger bare om tekst:
PDF-er med diagrammer
skjermbilder/bilder
lydopptak
videoklipp
Selv om du kan «trekke ut tekst» fra disse kildene, er det ikke det samme som en reell multimodal embedding-prosess.
Hvis pgai etter hvert støtter multimodale modeller gjennom hele prosessen (last inn → del opp → opprett embeddings for store bilder samt lyd og video lagret i S3, med robust synkronisering), ville det vært attraktivt. I dag er det imidlertid en arbeidsflyt for tekst-embeddings.
3) Hvis du bare trenger embeddings, trenger du kanskje ikke pgai.
Hvis innhentingsprosessen allerede er skreddersydd, eller må være det, er ikke «å opprette embeddings fra tekstdeler» den vanskeligste delen av RAG. I et slikt miljø løser pgai den enkleste delen av problemet.
Hvis kunnskapsbasen sjelden oppdateres, er verdien av automatisk synkronisering av embeddings dessuten mindre.
En spesielt god måte å bruke pgai på er å legge et tekst-til-SQL-grensesnitt over databasene. Dette kan enkelt gjøres med modulen semantic_catalog, som tilbys av pgai. Konfigurer det slik:
Bash
La deretter den semantiske katalogen hente inn dataordbøkene dine med pgai semantic-catalog create. Dette genererer kontekst fra datalageret som ser omtrent slik ut:
Plain Text
Denne konteksten er nå tilgjengelig for pgai på flere måter:
Gjennom semantisk søk:
Denne spørringen returnerer tabellene, funksjonene og de andre objektene som kan være relevante for spørringen din i naturlig språk:
Bash
Hent råkontekst:
Dette viser den rå YAML-konteksten som er knyttet til spørringen din i naturlig språk:
Bash
Generer SQL:
Du kan også generere SQL-koden som kreves for å besvare spørringen, direkte. Konteksten fra forrige trinn sendes til en LLM, som genererer et svar:
Bash
Hvis du bygger et relativt enkelt RAG-system, er pgai verdt å prøve dersom du ønsker:
Postgres som primær datakilde,
minimalt med integrasjonskode,
embeddings som automatisk holdes synkronisert,
en rask måte å bruke tekst-til-SQL på databasene dine,
å eksperimentere med nye RAG-verktøy og Postgres-utvidelser.
Det er trolig best å vente med pgai hvis RAG-prosessen krever noe av dette:
omfattende skreddersydd logikk for innhenting eller oppdeling
mange dokumenttyper med ulike krav til analyse
multimodale embeddings
Til slutt er det tydelig at pgvector har fått stor utbredelse, men det er uklart om pgai vil oppnå samme interesse og dermed støtte, selv om løsningen bare har eksistert i rundt 18 måneder.
pgai er en interessant RAG-tilnærming som lar databaser håndtere mer av det rutinemessige driftsarbeidet, slik at programkoden blir enklere.
Akkurat nå er løsningen:
brukbar og svært behagelig å arbeide med i enkle RAG-oppsett
ikke fleksibel nok for mer skreddersydde prosesser, særlig multimodale
Den virker lovende og er absolutt verdt å følge med på videre.