LLMs können nur eine begrenzte Textmenge gleichzeitig „sehen“ (das Kontextfenster). Das funktioniert bei kleinen Aufgaben, stößt aber an Grenzen, wenn eine Wissensdatenbank Tausende Seiten umfasst. Selbst bei einem ausreichend großen Kontextfenster kann die Leistung durch das „Nadel-im-Heuhaufen“-Problem sinken.
RAG („Retrieval-Augmented Generation“, abrufgestützte Generierung) ist ein weitverbreitetes Verfahren: Du pflegst eine Wissensdatenbank (Dokumente, Wikis, Richtlinien, Transkripte usw.), suchst anhand einer Anfrage semantisch nach den relevantesten Textausschnitten, indem du Embeddings verwendest, und übergibst diese Abschnitte zusammen mit der Frage an das LLM. Das begrenzt den Kontext des Modells und kann bei korrekter Umsetzung die Antwortqualität verbessern und Halluzinationen reduzieren.
pgai ist eine Open-Source-Erweiterung für Postgres samt ergänzenden Werkzeugen. Damit kannst du auf Basis der bewährten Open-Source-Datenbank PostgreSQL Workflows für den „KI-Abruf“ entwickeln.
Die Grundidee besteht darin, mehr Schritte der üblichen RAG-Pipeline in die Datenbankschicht zu verlagern (einlesen → aufteilen → einbetten → Embeddings synchron halten), statt die Datenbank lediglich als „Speicher“ für Embeddings zu behandeln.
Unser erster Eindruck: Der Ansatz ist vielversprechend, eignet sich aber nicht mehr, sobald deine RAG-Pipeline auch nur etwas komplexer wird, insbesondere bei der Aufteilung in Abschnitte. Wir werden das Projekt dennoch aufmerksam verfolgen.
RAG lässt sich auf viele Arten umsetzen. Eine ausführlichere Erläuterung verschiedener Ansätze findest du unter Praktische Beispiele für individuelle RAG-Lösungen. Wenn Qualität wichtig ist, werden die Gestaltungsmöglichkeiten überraschend komplex. Der übliche Standardansatz sieht ungefähr so aus:
Stelle eine Sammlung von Dokumenten zusammen.
Teile sie in Abschnitte auf. Dafür gibt es viele verschiedene Methoden, etwa eine Aufteilung nach Absätzen oder semantischen Gruppen.
Wandle jeden Abschnitt in ein Embedding um.
Speichere die Embeddings in einer Vektordatenbank (Pinecone, Milvus usw.) oder mithilfe von pgvector in Postgres.
Suche bei einer Anfrage nach den ähnlichsten Abschnitten `und übergib sie an das LLM (auch dafür gibt es viele Möglichkeiten).
In vielen Technologieumgebungen finden die Schritte (1)–(3) außerhalb der Datenbank im Anwendungscode oder in einer Datenpipeline statt. Die Datenbank dient hauptsächlich dazu:
Embeddings zu speichern
Embeddings zu durchsuchen
pgai ist eine Open-Source-Erweiterung für Postgres, die von Timescale entwickelt wird und versucht, diese Trennung aufzuheben.
Statt Embeddings manuell über deine Anwendung zu verwalten, macht pgai sie zu einer Datenbankfunktion:
Du legst fest, für welche Tabelle oder Dokumente Embeddings erstellt werden sollen.
Du gibst das Embedding-Modell und eine Strategie zur Aufteilung an.
pgai übernimmt den Rest und hält die Embeddings unter anderem auf dem neuesten Stand, wenn sich deine Quelldaten ändern.
Das Versprechen klingt überzeugend:
Weniger individueller Verbindungscode, der gepflegt werden muss.
Die Embeddings sollten sich leichter aktuell halten lassen, wenn sich die zugrunde liegenden Quelldokumente ändern.
Postgres/pgai verwaltet Wiederholungsversuche, Ratenbegrenzungen, fehlgeschlagene Aufträge usw.
Hinweis: pgai enthält pgvector, eine weitere sehr beliebte RAG-Erweiterung für Postgres. pgvector ergänzt Postgres um Vektorspeicherung und Ähnlichkeitssuche. Darauf baut pgai auf und automatisiert Schritte der RAG-Pipeline wie Aufteilung, Einbettung und Aktualisierung der Embeddings.
1) Die Inbetriebnahme ist unkompliziert.
Im Regelfall ist die Einrichtung recht einfach:
Lade die Docker-Images von Timescale herunter (Datenbank und Worker).
Gib den API-Schlüssel deines Embedding-Anbieters an.
Führe einige wenige SQL-Anweisungen aus, um den Vektorisierer zu definieren, also was eingebettet, wie es aufgeteilt und welches Modell verwendet werden soll.
Anschließend sorgt pgai dafür, dass ein Vektorisierungs-Worker als separater Prozess läuft und asynchron Embeddings erzeugt, beispielsweise alle fünf Minuten oder in einem beliebigen anderen Intervall.
2) Es ist praktisch, die gesamte Pipeline „nahe“ an der Datenbank auszuführen.
pgai kann Inhalte aus Tabellen einlesen und Dokumente beispielsweise aus S3 laden, um sie anschließend zu analysieren, aufzuteilen und einzubetten. Auch verschiedene Textdokumentformate wie PDF und Markdown werden unterstützt.
1) Du verlierst viel Kontrolle, obwohl RAG diese mitunter erfordert.
Leistungsfähige RAG-Systeme, gemessen an der Antwortqualität, erfordern häufig individuelle Pipelines, zum Beispiel:
individuelle Regeln zur Aufteilung, etwa nach Überschriften, Seiten oder Sprecherwechseln
metadatenbewusstes Aufteilen, bei dem Abschnittsüberschriften, Zeitstempel, Namen der Verfassenden und Dokumenttypen erhalten bleiben
unterschiedliche Embedding-Strategien je Dokumenttyp
Bei diesen Punkten bietet pgai weniger Flexibilität.
Derzeit gibt es zwei zentrale Strategien zur Aufteilung: einen Textteiler nach Zeichen und einen rekursiven Textteiler nach Zeichen. Daneben kann auf eine Aufteilung verzichtet werden. Das kann für einige Anwendungsfälle ausreichen, doch viele RAG-Systeme im Produktivbetrieb müssen stärker angepasst werden.
Es wäre sehr hilfreich, wenn Timescale einige der anspruchsvolleren Aufteilungsstrategien aus Bibliotheken wie Chonkie integrieren und ähnlich fortschrittliche Konzepte wie den kontextbezogenen Abruf von Anthropic unterstützen könnte.
2) Text steht im Mittelpunkt, nicht Multimodalität.
Viele interessante RAG-Probleme betreffen längst nicht mehr ausschließlich Text:
PDFs mit Diagrammen
Screenshots/Bilder
Audioaufnahmen
Videoclips
Selbst wenn du aus diesen Quellen „Text extrahieren“ kannst, entspricht das keiner echten multimodalen Embedding-Pipeline.
Falls pgai künftig multimodale Modelle durchgängig unterstützt, also große in S3 gespeicherte Bilder, Audio- und Videodateien lädt, aufteilt und einbettet sowie zuverlässig synchronisiert, wäre das überzeugend. Derzeit handelt es sich jedoch um einen Workflow für Text-Embeddings.
3) Wenn du nur Embeddings benötigst, brauchst du pgai möglicherweise nicht.
Wenn deine Pipeline zum Einlesen bereits individuell angepasst ist oder sein muss, ist das „Einbetten von Textabschnitten“ nicht der schwierigste Teil von RAG. In diesem Fall löst pgai den einfachsten Teil des Problems.
Wenn deine Wissensdatenbank nur selten aktualisiert wird, bietet die automatische Synchronisierung der Embeddings außerdem einen geringeren Mehrwert.
Eine besonders gute Verwendungsmöglichkeit für pgai wäre eine Text-to-SQL-Oberfläche für deine Datenbanken. Das lässt sich recht einfach mit dem von pgai angebotenen Modul semantic_catalog umsetzen. Richte es einfach wie folgt ein:
Bash
Lass dann den semantischen Katalog mit pgai semantic-catalog create deine Datenverzeichnisse auslesen. Dadurch wird aus deinem Datenspeicher ein Kontext erzeugt, der ungefähr so aussieht:
Plain Text
Dieser Kontext steht pgai nun auf verschiedene Arten zur Verfügung:
Über die semantische Suche:
Diese Abfrage gibt die Tabellen, Funktionen und weiteren Objekte zurück, die für deine natürlichsprachliche Anfrage relevant sein könnten:
Bash
Rohkontext abrufen:
Damit wird der YAML-Rohkontext zu deiner natürlichsprachlichen Anfrage ausgegeben:
Bash
SQL erzeugen:
Alternativ kannst du direkt den SQL-Rohtext erzeugen, der zur Beantwortung deiner Anfrage erforderlich ist. Der Kontext aus dem vorherigen Schritt wird an ein LLM gesendet, das daraufhin eine Antwort erzeugt:
Bash
Wenn du ein relativ einfaches RAG-System entwickelst, lohnt sich ein Test von pgai, falls du Folgendes möchtest:
Postgres als maßgebliches Datensystem,
möglichst wenig Verbindungscode,
automatisch synchronisierte Embeddings,
eine schnelle Möglichkeit, Text-to-SQL auf deine Datenbanken anzuwenden,
neue RAG-Werkzeuge und Postgres-Erweiterungen ausprobieren.
Du solltest mit pgai wahrscheinlich noch warten, wenn deine RAG-Pipeline Folgendes benötigt:
stark angepasste Logik für das Einlesen oder Aufteilen
viele Dokumenttypen mit unterschiedlichen Anforderungen an die Analyse
multimodale Embeddings
Schließlich hat sich pgvector eindeutig stark verbreitet. Ob pgai ein ähnliches Maß an Interesse und damit Unterstützung erhalten wird, ist dagegen unklar, auch wenn es das Projekt erst seit rund 18 Monaten gibt.
pgai ist ein interessanter RAG-Ansatz, bei dem Datenbanken einen größeren Teil der routinemäßigen Betriebsaufgaben übernehmen, sodass dein Anwendungscode einfacher bleibt.
Derzeit ist pgai:
bei einfachen RAG-Konfigurationen gut nutzbar und angenehm in der Anwendung
nicht flexibel genug für stärker angepasste Pipelines, insbesondere multimodale
Der Ansatz ist vielversprechend. Es lohnt sich auf jeden Fall, seine weitere Entwicklung zu verfolgen.