RAG mit No-Code bauen: OpenAI + Supabase pgvector

Was RAG ist und warum es wichtig ist

Standard-GPT-4o kennt deine internen Unternehmensdokumente, deinen Produktkatalog oder deine Kundendaten nicht. RAG löst das: Du speicherst deinen Inhalt als Vektoreinbettungen in einer Datenbank, und bei einer Anfrage findest du die relevantesten Abschnitte und sendest sie als Kontext an das LLM.

Das Ergebnis: ein KI-Assistent, der Fragen über deine spezifischen Daten beantwortet, genau und mit Quellenangaben.

Für deutsche Unternehmen sind RAG-Anwendungen besonders wertvoll für: interne Wissensbasen (Mitarbeiterhandbücher, Prozessrichtlinien), Kundensupport-Chatbots basierend auf Produktdokumentation, und juristische oder regulatorische Q&A-Systeme. Da alle Daten in deiner Supabase-Instanz bleiben, erfüllst du einfach die DSGVO-Anforderungen an EU-Datenspeicherung.

Schritt 1: pgvector in Supabase aktivieren

Supabase wird mit pgvector eingebaut geliefert. Im Supabase SQL-Editor führst du aus: CREATE EXTENSION IF NOT EXISTS vector;

Dann erstellst du deine Dokumententabelle: CREATE TABLE documents ( id bigint primary key generated always as identity, content text, embedding vector(1536), metadata jsonb, created_at timestamptz default now() );

Erstelle einen Index für schnelle Ähnlichkeitssuche: CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops);

Das ist das einzige SQL, das du schreiben musst. Wähle die EU-Region beim Erstellen deines Supabase-Projekts (z.B. eu-central-1 in Frankfurt), um sicherzustellen, dass Vektordaten innerhalb der EU bleiben.

Schritt 2: Einbettungen mit Xano generieren

In Xano erstellst du einen Endpoint, der einen Text-String akzeptiert, die OpenAI Embeddings API (text-embedding-3-small) aufruft und das Ergebnis in deiner Supabase documents-Tabelle speichert.

Der Function Stack: (1) Text-Input abrufen, (2) OpenAI API POST /v1/embeddings aufrufen, (3) Einbettungs-Array aus der Antwort extrahieren, (4) In Supabase über den Supabase API-Connector einfügen.

Führe das für jedes Dokument, jeden Artikel oder jeden FAQ-Eintrag aus, den deine KI kennen soll. Für deutsche Unternehmen kann das sein: Produktblätter, Preisdokumente, Kundenservice-Skripte oder rechtliche Verträge.

Schritt 3: Semantische Suche in Xano

Erstelle einen zweiten Endpoint, der: (1) Einen Nutzer-Anfrage-String akzeptiert, (2) Eine Einbettung für die Anfrage generiert (gleicher OpenAI-Aufruf), (3) Eine Vektorähnlichkeitssuche in Supabase durchführt.

Die Supabase RPC-Funktion dafür: SELECT content, 1 - (embedding <=> query_embedding) as similarity FROM documents ORDER BY embedding <=> query_embedding LIMIT 5;

Das gibt die 5 semantisch relevantesten Abschnitte für die Nutzeranfrage zurück. Das System versteht Bedeutung, nicht nur Keyword-Matching, eine Frage über "Urlaubspolitik" findet den richtigen Abschnitt, auch wenn das genaue Wort nicht im Dokument vorkommt.

Schritt 4: Antwort mit GPT-4o generieren

Mit den abgerufenen Abschnitten rufst du die OpenAI Chat Completions API auf. Der System-Prompt:

"Du bist ein hilfreicher Assistent. Beantworte die Frage des Nutzers NUR mit dem unten angegebenen Kontext. Wenn die Antwort nicht im Kontext enthalten ist, sage das.

Kontext: [HIER ABGERUFENE ABSCHNITTE EINFÜGEN]"

Das verankert die LLM-Antworten in deinen tatsächlichen Daten und verhindert Halluzinationen. Für deutsche Unternehmen kannst du den System-Prompt anpassen, um standardmäßig auf Deutsch zu antworten, förmliches oder informelles "Sie/du" je nach Kontext zu verwenden, und deutsche Regulierungen oder Branchenterminologie zu referenzieren.

Schritt 5: Chat-UI in WeWeb bauen

In WeWeb erstellst du eine Chat-Oberfläche mit einer Nachrichtenliste und einem Eingabefeld. Beim Absenden: rufe deinen Xano-Such-Endpoint auf, streame dann die GPT-Antwort mit Xanos Streaming-Support oder einem direkten OpenAI-Aufruf aus WeWebs Custom Code.

Für die Produktion füge hinzu: Nachrichtenhistorie (in Supabase gespeichert), Quellenangaben (zeige, welche Dokumente abgerufen wurden) und einen Feedback-Mechanismus (Daumen hoch/runter zur Verbesserung der Abrufqualität).

Das gesamte System kann innerhalb von 2-3 Wochen live sein und echte Nutzer bedienen. Eine interne Wissensbasis-Chatbot ist ein ausgezeichnetes erstes RAG-Projekt, definierter Scope, messbarer Wert und geringes Risiko. <a href="/contact">App Studio</a> hat 50+ solcher Apps in Produktion.

Die richtige Embedding-Modellwahl

OpenAI bietet 2025 drei Embedding-Modelle an: text-embedding-3-small (1536 Dimensionen, 0,02 USD/1M Tokens), text-embedding-3-large (3072 Dimensionen, 0,13 USD/1M Tokens) und das ältere text-embedding-ada-002. Für die meisten RAG-Anwendungen ist text-embedding-3-small die richtige Wahl: Es balanciert Kosten, Geschwindigkeit und Abrufqualität für die Standard-Dokumentensuche.

text-embedding-3-large lohnt sich, wenn Abrufpräzision entscheidend ist, juristische Vertragsanalyse, medizinische Literatursuche oder Anwendungen, bei denen eine übersehene relevante Passage spürbare Konsequenzen hat. In unseren Projekten haben wir 3-small gegen 3-large an einer Wissensbasis mit 10.000 Dokumenten benchmarkt und festgestellt, dass 3-small 94 % der Abrufgenauigkeit von 3-large bei 15 % der Kosten erreicht.

Für mehrsprachige Anwendungen (üblich bei unserem europäischen Kundenstamm) verarbeiten beide OpenAI-Modelle Französisch, Deutsch, Schwedisch und Niederländisch angemessen gut. Für spezialisierte Branchenterminologie in nicht-englischen Sprachen solltest du jedoch als Benchmark einen Test gegen mehrsprachige Spezialmodelle wie Coheres multilingual-22-12 über die Cohere API in Betracht ziehen.

Chunking-Strategien: Die versteckte Variable in der RAG-Qualität

Wie du deine Dokumente in Abschnitte (Chunks) aufteilst, ist wohl die wichtigste Variable für die RAG-Qualität, wirkungsvoller als die Modellwahl bei den meisten Anwendungen. Zu groß, und deine abgerufenen Chunks enthalten irrelevanten Inhalt, der das LLM verwirrt. Zu klein, und du verlierst den Kontext, den das LLM braucht, um kohärent zu antworten.

In unseren produktiven RAG-Projekten verwenden wir eine hybride Chunking-Strategie: Zuerst an Absatzgrenzen teilen (natürliche semantische Einheiten), dann eine maximale Chunk-Größe von 512 Tokens und ein Minimum von 100 Tokens erzwingen. Zu kleine Chunks werden mit ihrem Nachbarn zusammengeführt. Das bewahrt die semantische Kohärenz und verhindert gleichzeitig überdimensionierte Chunks. Bei strukturierten Dokumenten (FAQ-Seiten, Produktspezifikationen) chunken wir auf Q&A- oder Abschnittsebene statt nach Token-Anzahl.

Eine oft übersehene Technik: Überlappung zwischen Chunks hinzufügen. Wenn Chunk N bei Satz 10 endet und Chunk N+1 bei Satz 11 beginnt, geht der Kontext verloren, der die Grenze überbrückt. Wir fügen eine Überlappung von 50 Tokens hinzu, die Sätze 9 bis 10 aus Chunk N werden am Anfang von Chunk N+1 wiederholt. Dieser Mehraufwand von 10 % verbessert den Abruf für Anfragen, die Konzepte referenzieren, die über Chunk-Grenzen hinweggehen, erheblich.

Vektor-Ähnlichkeitsschwellen und Retrieval-Tuning

Nicht alle abgerufenen Chunks sind gleich relevant. Der von pgvector zurückgegebene Kosinus-Ähnlichkeitswert reicht von 0 (keine Ähnlichkeit) bis 1 (identisch). In der Praxis liegen relevante Chunks typischerweise über 0,75, und du solltest alles unter 0,60 herausfiltern, um zu vermeiden, dass irrelevanter Kontext an das LLM geht.

Füge in deiner Supabase RPC-Funktion eine Ähnlichkeitsschwelle hinzu: WHERE 1 - (embedding <=> query_embedding) > 0.70 ORDER BY embedding <=> query_embedding LIMIT 5. Starte mit 0,70 und passe es basierend auf deinen Daten an. Wenn dein Assistent bei Anfragen, von denen du weißt, dass er sie beantworten können sollte, sagt "Ich habe dazu keine Informationen", senke die Schwelle. Wenn er Antworten aus schwach verwandten Chunks gibt, erhöhe sie.

Implementiere für fortgeschrittenes Retrieval eine hybride Suche, die Vektor-Ähnlichkeit mit Keyword-Suche (PostgreSQLs eingebauter Volltextsuche) kombiniert. Dieser hybride Ansatz, oft "Reciprocal Rank Fusion" genannt, verbessert die Präzision bei Anfragen mit spezifischen Eigennamen, Produktnamen oder Fachbegriffen, mit denen Embeddings manchmal schlecht umgehen. Supabase unterstützt sowohl Vektor- als auch Volltextsuche nativ, was hybrides Retrieval ohne benutzerdefinierte Infrastruktur ermöglicht.

Kostenoptimierung für produktives RAG

Die Hauptkostentreiber in einem RAG-System sind: Embedding-Generierung (beim Hinzufügen neuer Dokumente), Embedding von Anfragen (jede Nutzernachricht) und LLM-Inferenz (jeder GPT-4o-Aufruf). Für eine typische interne Wissensbasis mit 5.000 Dokumenten und 500 täglichen Anfragen sieht die monatliche Kostenaufschlüsselung ungefähr so aus: Embedding-Ingestion (einmalig) 0,20 USD, tägliche Anfrage-Embeddings 0,30 USD/Monat, GPT-4o-Antworten bei durchschnittlich 3.000 Tokens Kontext 45 USD/Monat. Gesamt: etwa 50 USD pro Monat für 500 tägliche Nutzer.

Implementiere zur Senkung der LLM-Kosten eine Caching-Ebene für häufige Anfragen. Speichere die Top 100 Fragen und ihre Antworten in Supabase. Prüfe vor dem GPT-4o-Aufruf, ob eine semantisch ähnliche Frage kürzlich beantwortet wurde (Kosinus-Ähnlichkeit > 0,95 zu einem gecachten Anfrage-Embedding). Cache-Treffer liefern die gespeicherte Antwort sofort, kein LLM-Aufruf nötig. In unseren produktiven RAG-Apps sind 30 bis 40 % der Anfragen Cache-Treffer, was die LLM-Kosten um ein Drittel senkt.

Erwäge bei sehr hohem Volumen, die Antwortgenerierung für Anfragen mit geringer Komplexität von GPT-4o auf GPT-4o-mini umzustellen. Implementiere eine Routing-Ebene, die Anfragen als einfach (faktischer Lookup, Antwort aus einer Quelle) oder komplex (Synthese aus mehreren Quellen, Analyse) klassifiziert und einfache Anfragen an das günstigere Modell weiterleitet. Dieser hybride LLM-Ansatz senkt die Inferenzkosten bei typischen Wissensbasis-Workloads um 60 bis 70 %.

Produktionsaspekte: Zuverlässigkeit, Monitoring und Datenaktualität

Produktive RAG-Systeme haben operative Anforderungen, die Prototyp-Tutorials ignorieren. Dokumentenaktualität ist entscheidend: Wenn deine Wissensbasis veraltet ist, gibt deine KI falsche Antworten in selbstbewusst klingender Sprache. Implementiere eine automatisierte Re-Ingestion-Pipeline, wenn ein Dokument in deinem CMS oder deiner Datenbank aktualisiert wird, löse einen Xano-Hintergrundjob aus, der die betroffenen Chunks neu einbettet und den Vektorindex aktualisiert.

Monitoring in der Produktion bedeutet, Folgendes zu verfolgen: Anfrage-Latenz (Embedding + Retrieval + LLM kombiniert, sollte für gute UX unter 3 Sekunden liegen), Abrufqualität (protokolliere die Ähnlichkeitswerte der abgerufenen Chunks, ein Rückgang des Durchschnittswerts signalisiert, dass dein Dokumentenbestand aktuelle Anfragen möglicherweise nicht abdeckt) und Nutzerzufriedenheit (Daumen-hoch/runter-Feedback, in Supabase gespeichert, wöchentlich überprüft). In unseren Projekten ist die wöchentliche Überprüfung schlecht bewerteter Antworten die wirksamste Aktivität zur Qualitätsverbesserung.

Füge für Datenisolierung in Multi-Tenant-RAG-Apps eine workspace_id-Spalte zu deiner documents-Tabelle hinzu und ergänze sie in jeder RLS-Policy und jeder Retrieval-Query. Die Wissensbasis jedes Mandanten ist vollständig isoliert, ein Nutzer kann nur Antworten aus seinen eigenen Dokumenten abrufen und erhalten. Das ist für jede App, die vertrauliche Geschäftsdaten verarbeitet, nicht verhandelbar, und Supabases RLS macht es einfach, das korrekt zu implementieren.