RAG für Kleinunternehmen: Kostengünstiger Wettbewerbsvorteil oder IT-Falle?

Seitdem generative Künstliche Intelligenz breit verfügbar geworden ist, haben sich in vielen Unternehmen hohe Erwartungen in Hinblick auf eine enorme Effizienzsteigerung herausgebildet. Gleichzeitig wächst vor dem Hintergrund von Datenschutzbelangen sowie der digitalen Souveränität in Europa Unmut gegenüber etablierten KI-Anbietern wie OpenAI oder Anthropic. Laut einer Bitkom-Umfrage von 2025 gaben 93 % der teilnehmenden Unternehmen an, dass sie deutsche KI-Anbieter bevorzugen würden. Während laut dieser Studie generative KI im Kundenkontakt sowie in Marketing und Kommunikation bereits überwiegend Alltag geworden ist, bringen die reinen, generischen KI-Modelle Probleme mit sich, die sie für den Einsatz in anderen Unternehmensbereichen wie Forschung und Entwicklung oder Controlling nur bedingt nutzbar machen. Eine Lösung solcher Nachteile reiner LLms verspricht Retrieval-Augmented Generation (RAG), das unternehmenseigene Dokumente als Wissensspeicher verwendet, um zugeschnittenere Antworten zu liefern:

• Massive Reduktion von Halluzinationen: Normale LLMs neigen dazu, plausible, aber falsche Fakten zu erfinden, wenn sie eine Antwort nicht wissen. RAG zwingt die KI, ihre Aussagen in abgerufenen Dokumenten zu verankern. Findet das System keine passenden Infos, kann die KI ehrlich antworten: „Dazu liegen mir keine Informationen vor.“
• Das eigene Unternehmenswissen wird nutzbar: Ein Standard-Modell weiß viel über das Internet, aber absolut nichts über Ihr Unternehmen, wie beispielsweise die neuen HR-Richtlinien oder das streng geheime Produkthandbuch von letzter Woche. RAG macht die KI zum Experten für Ihre proprietären Daten.
• Aktualität ohne teures Neutrainieren: Wenn sich intern ein Prozess ändert, muss dies der KI nicht mühsam neu beigebracht werden. Man tauscht nur das entsprechende Dokument in der Datenbank aus. Bei der nächsten Anfrage greift das System sofort auf den neuesten Stand zu. Das spart enorme Rechenkosten im Vergleich zum klassischen „Fine-Tuning“ eines LLMs.
• Saubere Zugriffskontrolle: RAG ermöglicht es, Berechtigungen auf Dokumentenebene zu respektieren. Stellt beispielsweise ein Praktikant eine Frage an den internen Chatbot, durchsucht das RAG nur Dokumente, die für ihn freigegeben sind. Dieselbe Frage einer Geschäftsführerin, berücksichtigt auch vertrauliche Management-Daten, die in die Antwort einfließen.

Man stelle sich also einen KI-Assistenten vor, der nicht nur das halbe Internet auswendig gelernt hat, sondern exakt Ihr Firmenwissen kennt. Anstatt sich nur auf antrainiertes Allgemeinwissen zu verlassen, schlägt die KI bei jeder Anfrage zuerst in Ihren eigenen, internen Dokumenten (PDFs, Handbüchern, Datenbanken) nach. Erst auf Basis dieser konkreten Fakten formuliert sie dann ihre Antwort. Spezialwissen auf Knopfdruck, keine oder kaum Halluzinationen und volle Datenkontrolle – das klingt nach einem vollmundigen Versprechen. 

Doch mit welchem Aufwand und in welcher Güte lässt sich ein solches RAG umsetzen und welche Ressourcen und Kenntnisse werden dafür benötigt? Können auch kleine Unternehmen in den Genuss dieser Technologie kommen? Softwareseitig werden in Fachkreisen meist frei zugängliche Open-Weight-Sprachmodelle in Verbindung mit kostenlosen Low-Code- oder No-Code-Automatisierungslösungen wie N8N (aus Berlin) oder make (aus Tschechien) verwendet. ‚Also kann ich das selbst umsetzen‘, wird sich so mancher Mensch denken. Genau das hat den Autor dieses Beitrags motiviert herauszufinden, ob er als technikaffiner Mensch mit nur wenig Programmiererfahrung ein RAG-System für ein Wissensmanagement am Beispiel eines Hotels aufsetzen kann. Wenn es ihm gelänge, dann könnte man dies auch einem Kleinunternehmen mit ähnlichen Voraussetzungen zutrauen. Das würde diese vielversprechende Technologie tatsächlich auch für Kleinunternehmen zugänglich machen.

Die kurze Antwort ist: Der Teufel liegt im Detail und um einen echten Mehrwert für ein Unternehmen zu erzielen, ist sehr viel Feinarbeit nötig, was es am Ende zu einem durchaus anspruchsvolleren Projekt macht. Bei entsprechend vorhandenen Ressourcen sollte man sich davon jedoch nicht unbedingt abschrecken lassen. 

Die lange Antwort finden Sie im Folgenden. Sie ist weniger als Anleitung denn als Erfahrungsbericht zu lesen. Eine detaillierte Anleitung würde den Rahmen dieses Blogbeitrags sprengen. 

Nun setzen wir uns einmal an die Rezeption eines Hotels – hinter den Tresen. Fortwährend laufen unterschiedliche Anfragen von Gästen, Personal, Lieferanten und anderen Dienstleistern zusammen, die unmittelbar beantwortet werden möchten. Als Rezeptionist:innen greifen wir dafür auf eine Vielzahl unterschiedlicher Datenquellen aus statischem Hotelwissen wie Regeln im Hotelhandbuch (Check-in/out Zeiten, Late-Check-out, Frühstück, TV, Klimaanlage, Safe, Reklamations- und Kulanzrichtlinien, Notfallplänen etc.) sowie dynamischen Daten aus dem ERP-System (An-/Abreise, Verpflegung, Storno, Zahlungsstatus, Verfügbarkeit/Upgrade-Möglichkeiten, Personalplan etc.) zurück. Für den Umgang mit diesen Quellen müssen wir ausführlich geschult werden, damit uns diese Informationen im Handumdrehen zur Verfügung stehen. 

Wie werden in einem RAG-System Informationen verarbeitet?

In einem RAG-System hingegen verarbeitet ein generisches KI-Modell (Chat-Modell oder LLM) unsere Anfragen in natürlicher Sprache und leitet diese an seine angeschlossenen Datenquellen weiter. Eine genaue Kenntnis über den Speicherort sowie die Verwendung der jeweiligen Datenquelle ist keine Voraussetzung mehr. Statische unternehmenseigene Dokumente wie das Hotelhandbuch werden zuvor in für ein Chat-Modell verarbeitbarer Form in einem Wissensspeicher (Vektordatenbank) abgespeichert. Dynamische Datenquellen wie das ERP-System können per Schnittstelle (API) angebunden. Ein Chat-Modell wird demzufolge nicht mit den unternehmenseigenen Wissensquellen nachtrainiert, sondern wird per Systemprompt angewiesen, eingehende Fragen ausschließlich mit den ihm angeschlossenen Datenquellen zu beantworten bzw. Abfragen an diese zu stellen. Wenn sich eine Anfrage damit nicht beantworten lässt, kann es beispielsweise eine Meldung wie ‚Die Datenbank enthält keine Informationen zur Beantwortung der Frage.‘ ausgeben. 

Um das Hotelbeispiel wieder aufzugreifen, wurden wir beispielsweise von einem Gast gefragt, ob er eine zusätzliche Wolldecke bekommen kann. Wir chatten wie gewohnt in natürlicher Sprache mit einem Chat-Modell (z.B. Qwen3.8-27B), das die gewünschte Information aus dem Hotelhandbuch aus der Vektordatenbank bezieht.

Die Vektordatenbank liefert dem Chat-Modell die relevantesten Einträge, die der Anfrage statistisch am nächsten kommen. Ein Beispiel für die ersten 3 wahrscheinlichsten Treffer aus der Vektordatenbank könnte sein:

1. „Zusätzliche Kissen, Handtücher, Bademäntel oder extra Wolldecken können Gäste jederzeit über die Rezeption (Durchwahl 100) anfordern. Der Service ist kostenlos. Die Lieferung auf das Zimmer erfolgt in der Regel innerhalb von 15 Minuten.“
2. „Ausstattung der Kleiderschränke: In allen Superior-Zimmern und Suiten befindet sich standardmäßig eine in Folie verpackte Ersatz-Wolldecke im oberen Schrankfach. In den Standard-Zimmern ist aus Platzgründen keine extra Decke hinterlegt. Ein Bügelbrett und Bügeleisen sind in allen Kategorien vorhanden.“
3. „Allergiker-Information: Unsere Standard-Bettwäsche besteht aus Baumwolle, unsere bereitgestellten Wolldecken aus 100 % Schurwolle. Für Gäste mit Allergien halten wir auf Anfrage spezielle, wärmende Synthetik-Decken und Kissen bereit.“

Doch wie kann die Vektordatenbank überhaupt berechnen, welche in ihr gespeicherte Informationen für die Beantwortung der Frage relevant sind?

Die Vektordatenbank

Das Stichwort ist Datenorganisation. Große Sprachmodelle brauchen eine besondere Hilfestellung für die Verarbeitung von Dokumenten, da sie in der Größe ihres Kontextfensters und den ihnen zur Verfügung stehenden Ressourcen wie Rechenleistung und Arbeitsspeicher stark eingeschränkt sind. Ohne eine ordentliche Aufteilung der Dokumente in kleine Texteinheiten oder Textschnipsel (sog. chunks), die inhaltlich zusammengehören, würde das System schnell wichtige Zusammenhänge verlieren und Probleme haben, relevante Informationen wiederzufinden. Wie die Inhalte der Dokumente, z. B. Texte und Tabellen, in solche chunks zerlegt werden, hat einen entscheidenden Einfluss auf die Qualität der dem Chat-Modell zur Verfügung gestellten relevantesten Informationen. Wenn ein Text beispielsweise satzweise zerschnitten oder gechunkt wird, gehen möglicherweise wichtige Informationen verloren, weil das Chat-Modell nur eine vorher definierte Menge an chunks aufgrund seines eingeschränkten Kontextfensters von der Vektordatenbank zurückbekommt. In einfachen RAG-Systemen sind beispielsweise nur die ersten 3 wahrscheinlichsten chunks üblich. Dies könnte im Beispiel folgendermaßen aussehen:

1. „Zusätzliche Kissen, Handtücher, Bademäntel oder extra Wolldecken können Gäste jederzeit über die Rezeption (Durchwahl 100) anfordern.“
2. „In allen Superior-Zimmern und Suiten befindet sich standardmäßig eine in Folie verpackte Ersatz-Wolldecke im oberen Schrankfach.“
3. „Unsere Standard-Bettwäsche besteht aus Baumwolle, unsere bereitgestellten Wolldecken aus 100 % Schurwolle.“

Das Wort „Wolldecke“ kommt zwar in allen drei chunks vor, aber nur die erste Information ist mit einer Einschränkung hilfreich, weil keine Information über die Kosten einer zusätzlichen Wolldecke vorhanden ist Der zweite chunk ist nur für Gäste hilfreich, die ein Superior-Zimmer gebucht haben. Der dritte chunk hat keinerlei Informationsgehalt zur Beantwortung der Frage. 

Erschwerend kommt hinzu, dass zu kleine chunks oft nicht genug Kontext haben, und zu große chunks mehr Zeit zur Verarbeitung benötigen und ggf. zu viel unwichtige Informationen enthalten. Das Beispiel zeigt eindrücklich, dass die richtige chunking-Strategie einen wesentlichen Einfluss auf die Qualität das RAG-Systems hat. Demzufolge ist das Verstehen und das Anwenden von effektiven Chunking-Strategien eine Voraussetzung für das Entwickeln von RAG-Systemen und sollte in diesem weiterführenden Blogbeitrag vertieft werden. 

Im vorliegenden Beispiel habe ich mich aufgrund der Struktur des generierten Hotelhandbuchs für ein semantisches chunking entschieden, bei dem ein Text nicht nach einer starren Zeichen- oder Tokenanzahl unterteilt wird, sondern dynamisch anhand von inhaltlichen Zusammenhängen und Bedeutungsumbrüchen gruppiert wird, um den logischen Kontext für das KI-Modell bestmöglich zu bewahren (siehe unten).

Sobald ein gechunkter Text vorliegt, muss dieser für eine Künstliche Intelligenz durchsuchbar gemacht werden. Dies geschieht im zweiten Schritt (embedding), in dem die chunks aus natürlicher Sprache in Maschinensprache übersetzt werden. Diese Maschinensprache besteht aus einer langen Liste von Zahlen, einem sogenannten Vektor. Hierfür werden Embedding-Modelle verwendet. Das sind spezielle generative KI-Modelle, die darauf trainiert wurden, die Bedeutung von Wörtern, Sätzen oder ganzen Dokumenten zu „verstehen“ und in ein mathematisches Format zu übersetzen. Das bedeutet: Zwei Chunks, die inhaltlich dasselbe ausdrücken, aber völlig unterschiedliche Wörter verwenden (z.B. „Hund“ und „Golden Retriever“), erhalten Vektoren, die sich sehr ähnlich sind. Je nach Embedding-Modell besteht ein Vektor aus hunderten oder tausenden Dimensionen (Zahlenwerten). Das folgende Bild veranschaulicht diesen Prozess:

Quelle: KI generiert mit Google Gemini

Die Vektordatenbank speichert nun embeddings ab. Ein embedding besteht immer aus:

• Dem eigentlichen Text-Chunk (den man später als Antwort-Beleg anzeigen will).
• Dem dazugehörigen Zahlen-Vektor (der für die mathematische Suche verwendet wird).
• Optionalen Metadaten (z.B. Seitenzahl, Dokumentenname).

Danach sortiert das Embedding-Modell die darin enthaltenen Informationen nach ähnlichen oder zusammengehörenden Inhalten und indexiert sie als Zahlenvektoren. Die Vektordatenbank kann man sich wie eine Landkarte mit Ortsangaben mittels Koordinaten vorstellen, welche die darin verzeichneten Inhalte repräsentieren. Nah beieinander liegende Orte sind zusammengehörende Inhalte. Im Bild ist dies als farbiger Bereich dargestellt.

Quelle: KI generiert mit ChatGPT

Wenn ein Nutzer nun eine Frage im Chat-Fenster stellt, passiert Folgendes: Die Frage wird durch dasselbe Embedding-Modell geschickt und ebenfalls in einen Vektor verwandelt. Die Vektordatenbank vergleicht nun den Frage-Vektor mit allen gespeicherten Chunk-Vektoren. Sie berechnet die mathematische Distanz (die statistische Nähe) zwischen ihnen. Die Chunks, deren Vektoren dem Frage-Vektor am nächsten liegen, sind inhaltlich am relevantesten und werden in einer Rangfolge an das Chat-Modell zurückgegeben, das daraus seine Antwort formuliert.

Wie setze ich ein RAG-System nun selbst um?

Die Umsetzung eines eigenen RAG-Systems besteht im Wesentlichen aus vier Bereichen:

• Daten vorbereiten 
• geeignete Hardware auswählen 
• die Unternehmensdaten für die Suche aufbereiten 
• die einzelnen Software-Komponenten miteinander verbinden und automatisieren 
  

  a) Daten vorbereiten und digitalisieren 

Die Grundlage jedes RAG-Systems sind konsistente, aktuelle und widerspruchsfreie Daten, in die bestehende Zugriffsrechte zwingend integriert werden müssen. Ein Mitarbeiter mit eingeschränkten Zugriffsrechten sollte selbstverständlich keine Controlling-Daten abfragen können. 

Zudem beeinflusst die Qualität der Digitalisierung der Dokumente die Qualität des RAG-Systems. Sie bestimmt maßgeblich, wie gut ein RAG-System die Inhalte später „verstehen“ und wiedergeben kann. Liegen Dokumente z. B. als Bild-Scans vor, muss der Text zunächst mittels OCR-Software (wie Docling von IBM oder der Open-Source-Software Tesseract) extrahiert werden. Dabei lässt sich nicht jedes Dateiformat gleich gut maschinell auslesen. Grundsätzlich gilt: Je näher ein Format an reinem Text ist, desto verlustfreier und ressourcenschonender funktioniert die Verarbeitung. Die folgende Übersicht zeigt, welche Formate sich gut eignen und wo die typischen Hürden bei der Datenaufbereitung liegen:

Kategorie	Dateiformate	Besonderheiten bei der Verarbeitung
Sehr gut	TXT, MD (Markdown), JSON, CSV	Lassen sich direkt und fehlerfrei einlesen. Markdown strukturiert Überschriften und Listen nativ für das System.
Gut	DOCX, HTML, XML	Enthalten Formatierungen, die von gängigen Software-Bibliotheken gut erkannt und bereinigt werden können.
Herausfordernd	PDF, PPTX	Layouts, Spaltensätze, eingebettete Bilder und Tabellen erschweren es der Software, die korrekte Lesereihenfolge zu erkennen.
Aufwendig	JPG, PNG, TIFF	Reine Bilddateien oder gescannte Dokumente erfordern zwingend eine optische Zeichenerkennung (OCR), die fehleranfällig ist.

Dabei reicht es nicht aus, einfach nur den Text aus einer Datei zu kopieren. Das System muss die logische Struktur des Dokuments erfassen, damit das spätere chunking sauber funktioniert. 

• Strukturerhalt: Tabellen und Aufzählungen müssen intakt bleiben, da sich hier oft die wichtigsten Fakten (wie Preislisten oder Spezifikationen) befinden. Wenn eine PDF-Tabelle beim Auslesen zu einem unstrukturierten Fließtext verschmilzt, verliert das System den Kontext.
• Rauschen entfernen: Kopf- und Fußzeilen, Seitenzahlen, Wasserzeichen oder Werbebanner auf Webseiten sollten herausgefiltert werden. Sie stören das spätere embedding und verschlechtern die Suchergebnisse.
• Metadaten sichern: Informationen wie Autor, Erstellungsdatum oder das Quellformat müssen beim Auslesen erhalten bleiben und als Metadaten an den Text-Chunk angehängt werden, um spätere Zugriffskontrollen oder Quellenangaben zu ermöglichen.

Für das Hotelbeispiel habe ich mithilfe generativer KI ein umfassendes Hotelhandbuch von knapp 200 DIN-A4-Seiten generieren lassen. Von Notfallmaßnahmen und Telefonnummern über die Müllentsorgung bis zum Wartungsplan von Minigolf- und Außenanlagen beinhaltet das Handbuch sämtliche Belange eines Hotels. Der Einfachheit halber ist dieses Dokument die einzige Datenquelle des RAG-Systems. Ich habe es im Markdown-Format gespeichert. Markdown ist ein einfaches textbasiertes Dateiformat, bei dem beispielsweise Überschriften und Listen klar gekennzeichnet sind. Dadurch lässt sich der Inhalt besonders gut maschinell verarbeiten.

b) Hardware-Auswahl

Die lokale Ausführung eines Large Language Models (LLM) erfordert dedizierte Grafikkarten mit ausreichend VRAM (Video Random Access Memory). Eine weitere Möglichkeit sind Endanwender-PCs mit sogenanntem gemeinsamen Arbeitsspeicher (CPU und GPU teilen sich besonders schnellen RAM-Speicher). Alternativ können Cloud-Dienste genutzt werden, wobei hier zwingend auf DSGVO-Konformität geachtet werden muss. 

Welche Hardware benötigt wird, hängt vor allem von der Größe des eingesetzten Sprachmodells (LLM) ab. Größere Modelle benötigen in der Regel mehr Speicher und damit leistungsfähigere beziehungsweise teurere Hardware. Die folgende Tabelle gibt eine grobe Orientierung:

Leistungsklasse	Beispiel-Hardware	VRAM	Empfohlene Modellgröße	Kosten (ca.)
Einstieg	RTX 4070 Ti / 4080	12 – 16 GB	3B – 8B Parameter	850 € – 1.150 €
Gute Balance	NVIDIA RTX 5090 / 5080 / 4090	16 – 32 GB	8B – 24B Parameter	1.200 € – 2.800 €
High-End (Privatanwender) High-End (Privatanwender) High-End (Unternehmen)	AMD Ryzen AI Max+ 395 (unified memory) Mac Studio (M2 / M3 Ultra) (unified memory) NVIDIA H100 (PCIe / SXM)	bis zu 112 GB zugewiesen 96 GB – 512 GB   80 GB	32B – 70B Parameter   32B – 70B+ Parameter   70B+ Parameter	3.500 € – 4.000 €   4.500 € – 9.000 € +   30.000 € – 40.000 € +

Die Grafikkarte allein reicht allerdings nicht aus. Das Mittelstand-Digital Zentrum Hannover empfiehlt neben einer oder mehrerer leistungsfähigen GPUs, die den Großteil der Modellberechnungen übernehmen, auch eine leistungsstarke PC-Ausstattung (Stand 2025):

• Beispielhafte CPUs: AMD Ryzen 9 7950X, Intel Core i9-13900K
• RAM: Für optimale Leistung werden mindestens 64 GB RAM empfohlen
• Speicher: Schneller SSD-Speicher ist essenziell. Für einfache Sprachmodelle können mehrere TB erforderlich sein.

Für die Umsetzung des RAG-Systems stand mir folgende Ausstattung zur Verfügung:

• CPU: Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz (Serverprozessor mit 20 Kernen)
• RAM: 128 GB (gesamt), 48 GB (für VM nutzbar)
• GPU: NVIDIA A30, 48 GB VRAM
• SSD-Speicher: 1 TB (gesamt) 400 GB (für VM nutzbar)

Bis auf die GPU wurden die Komponenten bereits im Jahr 2018 angeschafft und sind nicht mehr auf dem aktuellen Leistungsstand. Zudem ist zu erwähnen, dass es sich um eine Serverarchitektur mit Virtualisierungen handelt, die für ein Kleinunternehmen in den allermeisten Fällen nicht notwendig ist. Die GPU wurde 2024 angeschafft. Die Gesamtkosten des Setups lagen bei ca. 10.000 Euro.

c) Daten durchsuchbar machen und Abläufe automatisieren 

Die Funktionsweise der Vektordatenbank, des Embedding-Modells sowie des Chat-Modells (LLM) wurde oben erklärt. Wie diese Komponenten zusammenspielen, verdeutlicht nun die folgende Grafik. 

Jegliche im Folgenden eingesetzte Software ist Opensource und kostenfrei verfügbar. Für einen kommerziellen Einsatz beachten Sie bitte die jeweiligen Lizenzbedingungen. 

Die einzelnen Bausteine

Um das RAG-System und die sensiblen Unternehmensdaten bestmöglich abzuschirmen, bietet sich die Docker-Container-Technologie an. Hierbei werden alle benötigten Komponenten in isolierten,

virtuellen Behältern (Containern) ausgeführt. Auf die Einrichtung der Docker-Umgebung gehe ich hier nicht näher ein, da sie sich mit Unterstützung eines KI-Chatbots Ihrer Wahl Schritt für Schritt nachvollziehen lässt.

Als Vektordatenbank verwende ich Qdrant. Dort werden die Textabschnitte des Hotelhandbuchs zusammen mit ihren mathematischen Repräsentationen gespeichert. Qdrant kann sehr viele dieser Zahlenreihen (Vektoren) schnell miteinander vergleichen und eignet sich aufgrund des vergleichsweise geringen Bedarfs an Arbeitsspeicher und Rechenleistung für den lokalen Betrieb. Als Vektordatenbank wähle ich Qdrant, weil damit Informationen nach ihrer semantischen Bedeutung organisiert werden können. Die Datenbank ist darauf spezialisiert, riesige Mengen an Vektoren (die von den Embedding-Modellen generierten Zahlenreihen) in Millisekunden zu vergleichen. Sie benötigt verhältnismäßig wenig Arbeitsspeicher und CPU-Leistung, was sie ideal für den lokalen Betrieb macht.

Als Embedding-Modell verwende ich nomic-embed-text-v2-moe, das sich für lokale RAG-Systeme eignet. Eine Besonderheit dieses Modells ist die Architektur, die es zulässt, die ausgegebenen Vektoren im Nachhinein zu verkleinern. So lässt sich die Länge der Vektoren (z. B. von 768 auf 256 Dimensionen) reduzieren, um massiv Speicherplatz und Rechenleistung in der Vektordatenbank einzusparen, ohne dabei nennenswert an Suchgenauigkeit zu verlieren. Nomic erzielt in Benchmarks regelmäßig Ergebnisse, die mit proprietären, kostenpflichtigen Modellen (wie OpenAIs text-embedding-ada-002) konkurrieren, behält die Daten dabei aber komplett auf der eigenen Hardware. Die neueren Iterationen des Modells (ab Version 2) sind explizit für Mehrsprachigkeit trainiert und liefern auch bei deutschen Texten eine sehr saubere semantische Zuordnung. Zudem lässt es sich nahtlos mit meinem lokal gehostetem Chat-Modell über Ollama integrieren.

Als eigentliches Chat-Modell kommt in meinem Beispiel Qwen 3.8 27B zum Einsatz. Das Modell läuft lokal über Ollama. Dadurch werden die verarbeiteten Daten nicht an externe KI-Anbieter wie OpenAI weitergeleitet. 

Die Automatisierung des gesamten Ablaufs übernimmt n8n. Das Programm verbindet die verschiedenen Komponenten miteinander: vom Einlesen eines Dokuments über seine Aufbereitung und Speicherung in der Vektordatenbank bis zur späteren Beantwortung einer Nutzerfrage. Dies ermöglicht eine nahtlose, automatisierte Brücke zwischen meinen lokalen Wissensquellen und dem Chat-Modell. Dabei habe ich zwei Abläufe voneinander getrennt:

• Neue Dokumente in das System aufnehmen 
• Fragen über den RAG-Chatbot beantworten 

Das hat einen praktischen Vorteil: Die aufwendige Verarbeitung eines neu hochgeladenen Dokuments kann im Hintergrund stattfinden, ohne dass die Benutzeroberfläche dadurch blockiert wird.

Neue Dokumente in das System aufnehmen 

Ein Nutzer lädt zunächst über ein Formular ein neues Dokument hoch. Im Hintergrund laufen anschließend mehrere Schritte ab, die im Schaubild als miteinander verbundene Bausteine (Knoten) dargestellt sind: 

Quelle: ©Karsten Jahn

• Webhook (GET): Dieser Knoten startet den Workflow, sobald ein Nutzer das Upload-Formular im Browser aufruft. Der Browser sendet dazu eine HTTP-GET-Anfrage an n8n. 
• HTTP Request (http://qdrant:6333/collections…): Anschließend fragt n8n über die interne Schnittstelle von Qdrant ab, welche Sammlungen (Collections) und Metadaten dort bereits vorhanden sind. Diese Informationen werden für die Darstellung des Formulars benötigt. 
• Code in JavaScript: Die von Qdrant gelieferten Rohdaten werden nun für das Formular aufbereitet. Das Skript erstellt daraus beispielsweise eine Auswahlliste für ein Dropdown-Menü und erzeugt das HTML-Formular. 
• Respond to Webhook: Abschließend wird das fertige Formular an den Browser zurückgegeben. Lädt der Nutzer darüber ein Dokument hoch, werden die Datei und die eingegebenen Informationen an den Webhook des eigentlichen Ingestion-Workflows weitergeleitet. Dieser übernimmt anschließend die Verarbeitung des Dokuments (rot und gelb markierte Bereiche in der folgenden Grafik).

Quelle: ©Karsten Jahn

Hochgeladene Dokumente verarbeiten (Ingestion Process)

• Webhook (POST): Dieser Knoten startet den Verarbeitungsprozess. Er nimmt das vom Nutzer hochgeladene Dokument sowie die im Formular ausgewählten Metadaten entgegen 

• Respond to Webhook: Direkt nach dem Upload erhält der Browser eine Erfolgsmeldung. Dadurch ist das Formular für den Nutzer sofort wieder verfügbar, während die eigentliche und rechenintensive Verarbeitung des Dokuments im Hintergrund weiterläuft.
• Code in JavaScript: Anschließend werden die eingegangenen Daten bereinigt und so strukturiert, dass sie von den folgenden Knoten weiterverarbeitet werden können.
• Switch & Extract: Nun prüft ein Weichen-Knoten (Switch) das Dateiformat. Je nachdem, ob es sich beispielsweise um ein PDF oder ein Textdokument handelt, wird der Inhalt über den jeweils passenden Extraktions-Knoten ausgelesen.
• HTTP Request, Data Loader & Text Splitter: Im nächsten Schritt wird der ausgelesene Text für die spätere Suche aufgeteilt. Über einen HTTP Request wird dafür ein in Python geschriebenes Skript zur semantischen Zerlegung des Textes aufgerufen. Der Data Loader übernimmt den Text, anschließend teilt ihn der Text Splitter anhand dieser Logik in kleinere, verarbeitbare Textabschnitte (Chunks) auf. Anders als bei einer starren Aufteilung nach einer festen Anzahl von Zeichen oder Tokens orientiert sich das semantische Chunking an inhaltlichen Zusammenhängen und Bedeutungsumbrüchen. Dadurch soll der logische Kontext innerhalb eines Chunks möglichst erhalten bleiben. Für diesen Zweck stellt LangChain unter der freien MIT-Lizenz einen SemanticChunker zur Verfügung. 
• Embeddings Ollama & Qdrant Vector Store: Anschließend wandelt das lokal über Ollama ausgeführte embedding-Modell die chunks in mathematische Vektoren um, welche anschließend mitsamt dem Originaltext in der Qdrant-Vektordatenbank gespeichert werden.

Fragen über den RAG-Chatbot beantworten (Nutzerinteraktion)

Der zweite Teil des Workflows beginnt, sobald ein Nutzer eine Frage in das Chat-Fenster eingibt. Anschließend läuft die Anfrage durch mehrere miteinander verbundene Knoten:

• Chat Message Received: Dieser Knoten startet den Ablauf, sobald der Nutzer seine Frage im Chat absendet.
• AI Agent & Memory: Der Agent fungiert als intelligente Steuerzentrale. Er entscheidet, ob externes Wissen benötigt wird. Gleichzeitig kann er über das Simple Memory auf vorherige Nachrichten des Gesprächs zugreifen und dadurch den bisherigen Kontext berücksichtigen. Über den Systemprompt lässt sich festlegen, wie sich der Agent dabei verhalten soll.
• Vector Store Tool: Benötigt der Agent Informationen aus dem Hotelhandbuch, greift er auf dieses Werkzeug zu. Die Nutzerfrage wird zunächst vom Embedding-Modell in einen Vektor umgewandelt. Anschließend sucht Qdrant nach den gespeicherten Textabschnitten (Chunks), deren Vektoren der Frage am ähnlichsten sind. Auf diese Weise werden die inhaltlich wahrscheinlich relevantesten Informationen aus dem Hotelhandbuch gefunden.
• Ollama Chat Model: Die gefundenen Textabschnitte werden schließlich an das lokal über Ollama ausgeführte Sprachmodell übergeben. Es verarbeitet die darin enthaltenen Informationen und formuliert daraus eine natürliche Antwort für den Nutzer.

Fazit: Leistungsfähigkeit und lokaler Betrieb

Die Implementierung eines lokalen RAG-Systems bietet für die Erschließung eines 200-seitigen Hotelhandbuchs im Markdow-Format enormes Potenzial. Der Erfolg der Architektur hängt jedoch maßgeblich von der korrekten Datenaufbereitung und den vorhandenen IT-Ressourcen ab.

Für unstrukturierte Fließtexte ist das semantische chunking eine gute Wahl. Es durchtrennt komplexe Richtlinien nicht nach starrer Zeichenanzahl, sondern bewahrt den logischen Zusammenhang. Dies garantiert vollständigen Kontext und minimiert Halluzinationen. Die gravierendste Schwäche des rein semantischen Ansatzes liegt in der Verarbeitung stark formatierter Daten. Komplexe PDF-Layouts oder tabellarische Preislisten verlieren durch die eindimensionale Leseweise des embedding-Modells ihren entscheidenden zweidimensionalen Bezug (Zeile zu Spalte). Zudem ignoriert die semantische Zerteilung die wichtige Kapitelhierarchie des Gesamtdokuments. Die bessere Wahl für solche Abschnitte bildet das hierarchische chunking. Durch die vorherige Umwandlung in strukturierte Formate bleiben Tabellen als intakte Textblöcke erhalten. Das Handbuch wird exakt an seinen Überschriften getrennt, sodass jeder Daten-chunk seinen übergeordneten Kapitel-Kontext als Metadaten behält. In der Praxis kann deshalb eine Kombination verschiedener Chunking-Strategien sinnvoll sein. 

Eine weitere Herausforderung sind Änderungen an den Daten. In meinem Beispiel habe ich noch nicht berücksichtigt, wie einzelne Einträge später gezielt geändert oder gelöscht werden können. Dies sollte mit Blick auf zukünftige Aktualisierungen vorab bei der Architekturplanung der Vektordatenbank berücksichtigt werden. Hierfür ist eine saubere Architektur essenziell, die Rohdaten und Vektoren strikt voneinander trennt. Jeder chunk in der Vektordatenbank muss zwingend mit eindeutigen Metadaten (wie einer Dokumenten-ID und einem Hash-Wert des Inhalts) verknüpft werden. Nur so lassen sich veraltete, fehlerhafte oder datenschutzrechtlich bedenkliche Informationen später gezielt identifizieren und entfernen, ohne den gesamten Index zu beeinträchtigen. 

Ebenso sollte die Infrastruktur auf einen möglichen Wechsel des embedding-Modells vorbereitet sein, welcher den vollständigen Verlust der Gültigkeit aller bestehenden Vektoren nach sich zieht. Hierfür empfiehlt sich eine Versionierung auf Ebene der Datenbank-Kollektionen. Anstatt den bestehenden Index live zu überschreiben, werden die gesicherten Rohdaten durch das neue embedding-Modell verarbeitet und in einer neuen Kollektion abgelegt. Sobald dieser Prozess abgeschlossen ist, wird der RAG-Workflow in n8n nahtlos auf den neuen Vektorraum umgeleitet und der alte Index kann sicher gelöscht werden.

Technisch kann ein separater lokaler Server die gleichzeitigen Anfragen mehrerer Hotel-Arbeitsplätze bedienen. Die eigentliche Herausforderung für ein Kleinunternehmen ist jedoch der dauerhafte Betrieb. Ein lokales RAG-System ist keine Lösung, die einmal eingerichtet wird und anschließend ohne weitere Arbeit läuft. Sicherheitsupdates, Anpassungen der Prompts sowie die regelmäßige Aktualisierung der Wissensdatenbank verursachen dauerhaft Aufwand. Die sichere Einrichtung erfordert eine hohe IT-Affinität, während fortlaufende Wartungen, das Einspielen von Sicherheitsupdates, Prompt-Anpassungen und die kontinuierliche Aktualisierung der Vektordatenbank bei neuen Versionen des Handbuchs dauerhaft Ressourcen binden.

Trotz dieser Hürden zeigt dieser Erfahrungsbericht, dass die Umsetzung eines leistungsfähigen RAG-Systems für Kleinunternehmen in Eigenarbeit heute mit etwas IT-Kenntnis technisch absolut realisierbar ist. Ob sich dieser Aufwand lohnt, hängt jedoch nicht nur von den Anschaffungskosten ab. Ebenso wichtig ist die Frage, ob dauerhaft genügend Zeit und personelle Kapazitäten für Betrieb und Pflege vorhanden sind. 

 

Autor des Artikels: Karsten Jahn

Ansprechpartner:
Constance Möhwald
Modellfabrik Virtualisierung
Telefon: +49 3641 205-128
E-Mail: moehwald@kompetenzzentrum-ilmenau.de