Zum Inhalt springen
Wie man NotebookLM selbst baut: RAG-System mit PostgreSQL + OpenAI

Wie man NotebookLM selbst baut: RAG-System mit PostgreSQL + OpenAI

Einführung

NotebookLM zeigt sehr gut, wohin moderne KI-Systeme gehen: weg von generischen Antworten, hin zu kontextbasierten Antworten auf Basis eigener Quellen. Technisch steckt dahinter meist kein „magisches Spezialmodell“, sondern ein sauber gebautes RAG-System (Retrieval-Augmented Generation). :contentReference[oaicite:2]{index=2}

Die gute Nachricht: Man kann sich ein ähnliches System selbst bauen – mit einem überschaubaren Stack:

  • PostgreSQL als zentrale Datenbank
  • pgvector für semantische Suche
  • OpenAI Embeddings für die Vektorrepräsentation
  • OpenAI Responses API für die Antwortgenerierung

Gerade für Teams, Intranets, Verträge, Wissensdatenbanken, Support-Dokumentation oder branchenspezifische KI ist das oft sinnvoller als ein generischer Chatbot. OpenAI empfiehlt für aktuelle Text-Embeddings die Modelle text-embedding-3-small und text-embedding-3-large; aktuelle Textmodelle werden über die Responses API bereitgestellt. :contentReference[oaicite:3]{index=3}

Was du eigentlich baust

Das Ziel ist kein „allwissendes Modell“, sondern ein System mit vier klaren Schichten:

Dokumente
→ Parsing & Chunking
→ Embeddings
→ PostgreSQL + pgvector
→ Retrieval
→ LLM-Antwort mit Quellenkontext

Der entscheidende Unterschied zu einem normalen Chatbot: Die Antwort kommt nicht primär aus dem Modellwissen, sondern aus deinen eigenen Dokumenten, die semantisch gesucht und dann als Kontext an das Modell übergeben werden. Genau dafür sind Embeddings gedacht: Sie verwandeln Text in numerische Vektoren, damit semantisch ähnliche Inhalte einander nahe liegen. :contentReference[oaicite:4]{index=4}

Architektur: Die pragmatische Version

1) Dokument-Ingestion

Zuerst importierst du Quellen wie PDFs, Markdown, HTML, Verträge, Wikis oder CMS-Inhalte. Danach extrahierst du reinen Text und Metadaten:

  • Dateiname / Quelle
  • Dokumenttyp
  • Sprache
  • Kapitel / Abschnitt
  • Zeitstempel / Version

Wichtig: Ein gutes RAG-System speichert nicht nur Text, sondern auch Herkunft und Struktur. Sonst kannst du später keine sauberen Quellen anzeigen.

2) Chunking

Danach zerlegst du Dokumente in kleinere Einheiten, sogenannte Chunks. Diese sollten groß genug sein, um Bedeutung zu tragen, aber klein genug, damit Retrieval präzise bleibt.

Praxisregel:

  • keine riesigen Volltextblöcke
  • thematisch saubere Abschnitte
  • leichte Überlappung zwischen Chunks

Schlechtes Chunking ist einer der häufigsten Gründe, warum RAG-Systeme „unpräzise“ wirken.

3) Embeddings erzeugen

Für jeden Chunk erzeugst du ein Embedding. OpenAI stellt dafür aktuelle Embedding-Modelle bereit, darunter text-embedding-3-small als effiziente Standardwahl und text-embedding-3-large für höhere Qualität. Das große Modell unterstützt bis zu 3072 Dimensionen; OpenAI dokumentiert außerdem das Kürzen der Embeddings über den Parameter dimensions, um Speicher- und Kostenbedarf zu reduzieren. :contentReference[oaicite:5]{index=5}

Für viele Business-Systeme ist text-embedding-3-small ein sehr guter Startpunkt. Wenn Qualität wichtiger ist als Speicher und Kosten, kann text-embedding-3-large sinnvoll sein. :contentReference[oaicite:6]{index=6}

4) Speicherung in PostgreSQL

pgvector erweitert PostgreSQL um Vektor-Suche direkt in der Datenbank. Laut Projekt unterstützt es exakte und approximate nearest neighbor search, mehrere Distanzmaße sowie HNSW- und IVFFlat-Indizes. Das macht PostgreSQL attraktiv, wenn du relationale Daten, Metadaten und Vektoren in einem System halten willst. :contentReference[oaicite:7]{index=7}

Ein typisches Schema sieht so aus:

documents
- id
- title
- source
- language
- created_at
- updated_at

document_chunks
- id
- document_id
- chunk_index
- content
- token_count
- embedding vector(...)
- metadata jsonb

Der große Vorteil: Du kannst klassische SQL-Filter mit semantischer Suche kombinieren, z. B. nur deutschsprachige Verträge oder nur Artikel aus einer bestimmten Kategorie. pgvector positioniert sich genau für diesen Anwendungsfall: Vektoren im selben Postgres-System wie der Rest deiner Daten. :contentReference[oaicite:8]{index=8}

Retrieval: Der wichtigste Teil

Viele Entwickler fokussieren zu stark auf das Modell. In der Praxis ist aber oft das Retrieval der Engpass.

Der Ablauf sieht typischerweise so aus:

  1. User-Frage kommt herein
  2. Frage wird ebenfalls embedded
  3. Ähnlichste Chunks werden per Vektor-Suche gefunden
  4. Top-Treffer werden gerankt / gefiltert
  5. Diese Chunks gehen als Kontext in den Prompt

OpenAI zeigt dieses Prinzip auch im eigenen Embeddings/Cookbook-Flow: Query embedden, per Distanz passende Texte suchen, dann mit diesen Treffern arbeiten. :contentReference[oaicite:9]{index=9}

Wichtige Verbesserungen in echten Systemen:

  • Metadaten-Filter vor oder nach Vektor-Suche
  • Hybrid Search (Keyword + Vector)
  • Deduplication ähnlicher Chunks
  • Re-Ranking der Top-Treffer
  • Kontextbudget sauber begrenzen

Antwortgenerierung mit OpenAI

Nachdem die relevantesten Chunks gefunden wurden, gibst du sie zusammen mit der Nutzerfrage an ein Modell weiter. Die aktuellen Textmodelle sind laut OpenAI über die Responses API verfügbar; wenn man nicht weiß, wo man starten soll, verweist die Model-Übersicht auf gpt-5.4 als starkes Modell für komplexes Reasoning und Coding. :contentReference[oaicite:10]{index=10}

Für ein sauberes RAG-System sollte der Prompt klar trennen zwischen:

  • System-Regeln
  • User-Frage
  • retrieved context

Beispielhaft:

Du beantwortest Fragen nur auf Basis des bereitgestellten Kontexts.
Wenn etwas nicht im Kontext steht, sage das klar.
Zitiere die Quelle mit Dokumentname und Abschnitt.

Damit reduzierst du Halluzinationen zwar nicht auf null, aber deutlich.

Warum PostgreSQL statt externer Vector DB?

Für viele Projekte ist PostgreSQL die pragmatischere Wahl:

  • ein System statt zusätzlicher Infrastruktur
  • SQL + Metadaten + Relationen + Vektoren an einem Ort
  • einfachere Backups, Replikation und Betrieb
  • guter Fit für CMS-, SaaS- und Business-Anwendungen

Wenn du bereits Postgres einsetzt, ist pgvector oft der schnellste Weg zu einem produktiven RAG-Prototypen. Das Projekt nennt ausdrücklich JOINs, ACID und point-in-time recovery als Vorteile gegenüber separaten Speziallösungen. :contentReference[oaicite:11]{index=11}

Praxis-Stack für ein MVP

Ein sehr brauchbarer MVP-Stack könnte so aussehen:

  • Backend: Next.js, Node.js oder Go
  • Datenbank: PostgreSQL + pgvector
  • Embedding: text-embedding-3-small
  • Antwortmodell: aktuelles Textmodell via Responses API
  • Storage: S3 / Object Storage für Dateien
  • Queue: für Parsing und Re-Embedding
  • UI: Chat + Quellenpanel + Dokumentansicht

Gerade das Quellenpanel ist wichtig. Ein NotebookLM-ähnliches System wirkt nur dann vertrauenswürdig, wenn Nutzer nachvollziehen können, woher eine Antwort kommt.

Was oft schiefläuft

  • Chunks sind zu groß oder zu klein
  • Keine Metadaten-Struktur
  • Vektor-Suche ohne Re-Ranking
  • Keine Quellenanzeige im Frontend
  • Prompt ist zu offen formuliert
  • Keine Re-Indexierung bei Dokument-Updates

RAG wirkt dann „schlecht“, obwohl meist nicht das Modell das Problem ist, sondern die Pipeline.

Fortgeschrittene Features

Wenn das Grundsystem steht, kannst du es Richtung NotebookLM weiterentwickeln:

  • Notizen pro Dokument
  • automatische Zusammenfassungen
  • Themen-Cluster
  • Fragen-vorschlagen
  • Cross-document reasoning
  • Audio-Zusammenfassungen
  • Rechte- und Rollenmodell pro Datenraum

Ab diesem Punkt wird aus einem simplen Chatbot ein echtes Wissenssystem.

Fazit

Ein eigenes NotebookLM zu bauen ist heute deutlich realistischer, als viele denken. Mit OpenAI-Embeddings, der Responses API und PostgreSQL plus pgvector lässt sich ein solides, nachvollziehbares RAG-System umsetzen, das auf den eigenen Daten arbeitet statt nur generische Antworten zu liefern. :contentReference[oaicite:12]{index=12}

Die eigentliche Herausforderung ist nicht nur das Modell – sondern die Qualität von Ingestion, Chunking, Retrieval und Quellenführung.

Wer diese vier Bausteine sauber baut, kommt sehr nahe an die Nutzererfahrung von NotebookLM heran:

  • eigene Quellen
  • semantische Suche
  • kontextbasierte Antworten
  • mehr Vertrauen durch klare Quellenbezüge