3. November 2025

Ein RAG Chatbot ohne Coding - so einfach ist es!

Ein KI Assistent für Immobilienmakler, das war mein Sonntags-Projekt. Ich wollte sehen, ob ich einen Chatbot bauen kann der Immobilienmaklern bei Rechtsfragen hilft und dabei ausschließlich auf geprüfte Inhalte zurückgreift. Keine Halluzination, sondern gezielte Recherche in juristischen Dokumenten.

Wichtig! Dies ist kein fertiges Produkt und natürlich auch keine Rechtsberatung! Es handelt sich um ein Proof of Concept ohne vollständige Fehlerbehandlung, ohne systematisches Testkonzept, ohne Security und ohne Evaluierung mehrerer Sprachmodelle.

Die Idee

Die Grundidee war ein RAG Chatbot, RAG steht für Retrieval Augmented Generation. Dahinter steckt ein recht pragmatischer Gedanke. Ein Sprachmodell kennt die Welt aus seinem Training. Dieses Wissen ist breit aber nicht unbedingt aktuell, nicht unbedingt korrekt und oft nicht spezifisch genug für reale Anwendungsszenarien. Ein Immobilienmakler braucht aber klare Aussagen zu aktuellen Rechtsfragen und genau hier soll das Modell nicht spekulieren sondern Fakten benennen und Quellen benennen.

Die Antwort muss aus einer verlässlichen und kontrollierten Quelle stammen, in diesem Fall durch zuvor zur Verfügung gestellte PDF Dokumente. Hier wurde mein Beispiel auch davon bestimmt, ob ich frei verfügbare und eindeutig korrekte Informationen bekommen kann. Gesetzestexte sind hier ein praktisches Beispiel, in der Realität ist die Beschaffung, Kontrolle, Aufbereitung und Governance der Lerndaten der wichtigste und umfassendste Schritt für jede KI Anwendung.

Wie funktioniert RAG ?

RAG verwendet gängige Sprachmodelle um die Fragen im Chatbot zu analysieren und die Antwort zu formulieren, die fachliche Grundlage wird aber nur durch die hinzugefügten und zur Frage passenden Informationen aus dem sicheren und überwachten Wissenspeicher gestellt.

Statt sich auf das Wissen aus einem riesigen Modell, mit eventuell widersprüchlichen oder falschen Daten, zu verlassen, holt man bei jeder Anfrage gezielt die passenden Textstellen aus einem definierten Wissenskorpus und stellt diese dem Sprachmodell für die Antwort zur Verfügung.

Warum brauchen wir RAG ?

Es gibt mehrere Gründe, zu den wichtigsten gehören:

• Kontextfenster: Ein Sprachmodell kann pro Anfrage nur eine begrenzte Menge Text verarbeiten. Wenn ich versuche die komplette Rechtslage zum Thema Erbbaurecht bei jedem Prompt mitzugeben, laufe ich sofort in diese Grenze. Ich muss also auswählen, was wirklich relevant ist.
• Verlässlichkeit: Ein Immobilienmakler kann sich nicht auf unspezifisches Wissen aus einem generischen KI Modell verlassen, sodern will nachweisen können, aus welcher Quelle die Information stammt.
• Zugriff auf nicht öffentliche Inhalte: Bestimmte interne Leitfäden oder juristische Stellungnahmen sind nicht frei im Netz verfügbar und sollen auch nicht in öffentliche Sprachmodelle integriert werden. Über RAG lassen sie sich aber interne Informationen sicher einbinden. Wenn nötig, könnte der beschriebene Setup mit einem lokalen frei verfügbaren Sprachmodell auch komplett lokal betrieben werden.
• Kostenkontrolle: Große Kontextfenster und jede Abfrage kosten Geld. Wenn ich aber ein schlankes RAG mit einem effizienten Sprachmodell und gezielter Retrieval Logik nutze, sinken die Kosten und der CO2 Fußabdruck deutlich.

Noch etwas Tech-Wissen, bevor es losgeht

Ein häufiger Irrtum, RAG bedeutet nicht automatisch, dass eine Vektordatenbank und Embeddings verwendet werden, aber meistens schon. Das Grundprinzip ist immer gleich, erst werden relevante Information aus einer externen Quelle herausgesucht. Dann wird diese Information zusammen mit der eigentlichen Frage an das Modell übergeben. Diese externe Quelle kann eine Vektordatenbank sein, aber auch ein Ordner in Google Drive, eine SQL Tabelle, ein Satz oder strukturierte PDF Dateien. Wichtig ist nur, dass nicht blind das ganze interne Wissen in jeden Prompt mitgegeben wird, sondern dass selektiv nur die passenden Informationen.

Das klassische RAG Setup arbeitet allerdings tatsächlich oft mit Embeddings und einer Vektordatenbank. Man nimmt die Quelldokumente, z.B. mehrere Gesetzestexte oder interne Leitfäden, und zerlegt sie in kleinere Abschnitte. Jeder dieser Abschnitte wird dann durch ein Embedding Modell in einen Vektor im mehrdimensionalen Raum umgewandelt und in der Vektordatenbank abgelegt.

Wenn der Benutzer eine Frage stellt, wird auch diese Frage zerteilt, in Vektoren übersetzt. Dann werden zu den Vektoren der Frage passende Textteile in der Vektordatenbank gesucht und extrahiert. Die dahinterliegenden Textabschnitte gelten als potenziell relevante Fundstücke. Diese Text-Abschnitte wandern zusammen mit der ursprünglichen Frage in das verwendete Sprachmodell, dass seine Antwort ausschließlich auf die Frage und die mitgegebenen Fundstücke stützt.

Neben dieser einfachsten Form, ein Vanilla RAG, gibt es aber noch weitere Ansätze:

• Adaptives RAG optimiert die Anfrage bevor gesucht wird, d.h. dass zunächst ein Sprachmodell versucht, zu verstehen was eigentlich gefragt ist, entscheidet welche Quelle am besten geeignet sind und formuliert ggf. die Suchfrage um.
• Hybrid RAG kombiniert die semantische Suche mit der klassischen Stichwortsuche und kann auch Ergebnisse aus verschiedenen Quellen zusammenführen. Solche Verfahren machen Systeme robuster gerade bei vagen oder mehrdeutigen Fragen.

Ansatz und Tech-Stack

Der Tech Stack im Proof of Concept war bewusst Low Code und so einfach wie möglich gehalten:

• Die Oberfläche des Chatbot habe ich mit Lovable gebaut.
• Die Orchestrierung der einzelnen Schritte läuft über n8n.
• Das Large Language Model hinter der Antwort ist GPT 4o mini von OpenAI, welches im Betrieb vergleichsweise günstig ist.
• Für die semantische Suche beziehungsweise die Vektorisierung der Texte kam das Modell "text embedding 3 small", ebenfalls von OpenAI, zum Einsatz.
• Die Vektoren habe ich in Pinecone gespeichert.
• Die Lern-Dokumente werden über ein Google Drive bereitgestellt.

Umsetzung in vier Schritten

1. Anlegen der Vektordatenbank in Pinecone.
2. Workflow in n8n erstellen, der neue Dokumente in Google Drive erkennt, das Dokument zerlegt, Embeddings erzeugt und in Pinecone speichert.
3. Workflow in n8n für die eigentliche RAG Abfrage, der für jede Benutzeranfrage Embeddings erstellt, in Pinecone nach den ähnlichsten Textabschnitten sucht und diese Treffer plus die Frage an das Sprachmodell weitergibt. Wichtig: Das Prompt für die Antwort stellt sicher, dass das Sprachmodell ausschließlich aus den mitgegeben Textabschnitten eine Antwort erzeigen darf, oder ansonsten zurückmelden muss, dass es nicht genug Informationen hat.
4. Eine Oberfläche in Lovable als Chat UI, erstellt mit weniger als 5 Prompts.

In der Praxis tauchen genau hier die echten Herausforderungen auf. Die genannten Schritte sind technisch schnell gebaut, aber der Rest dauert dafür um so länger. Qualitätssicherung, Evaluierung von Sprachmodellen, Testabdeckung, Edge Cases, Zugriffsschutz oder die Versionierung und Gonvernance der Inhalte. Dazu kommt das kontinuierliche und automatisierte Messen der Ergebnisse des Systems, um auf Veränderungen schnell zu reagieren.

Was kann der Prototyp?

Zu Beginn hatte ich die Vektordatenbank nur mit dem Dokument "Gewerberechtliche Berufspflichten für Erlaubnisinhaber nach § 34c" angelernt. Eine passende Testfrage aus diesem Bereich benantwortet das System einwandfrei, eine Frage zum Erbbaurecht kann aber nicht gelöst werden.