RAG: Chatbot auf dem eigenen Firmenwissen

Das Grundproblem: Ein LLM kennt eure Firma nicht

Ein Sprachmodell wie ChatGPT, Claude oder Gemini wurde auf öffentlich verfügbaren Texten trainiert - Wikipedia, Bücher, Foren, Code-Repositories. Es kennt eure interne IT-Richtlinie nicht, weiss nichts über euer Produktportfolio von letztem Quartal und hat noch nie eure Kundendatenbank gesehen. Fragst du es trotzdem danach, passiert eines von zwei Dingen: Es sagt ehrlich “das weiss ich nicht”, oder - deutlich unangenehmer - es erfindet eine plausibel klingende Antwort (siehe Warum KI halluziniert).

Retrieval-Augmented Generation (RAG) löst genau dieses Problem, ohne das Modell selbst zu verändern. Die Grundidee ist simpel: Bevor das Modell antwortet, bekommt es die passenden Ausschnitte aus euren eigenen Dokumenten als Kontext mitgeliefert - quasi ein Spickzettel, der bei jeder Frage neu zusammengestellt wird. Das Modell liest diesen Spickzettel und formuliert die Antwort daraus, statt aus seinem antrainierten, aber unvollständigen Weltwissen zu raten.

Der Vergleich zu den beiden Alternativen macht den Charme von RAG deutlich. Fine-Tuning würde bedeuten, das Modell mit euren Daten nachzutrainieren - aufwendig, teuer, und das Wissen “verschwimmt” im Modellgewicht statt nachprüfbar zu bleiben. Ein riesiger Prompt mit allen Dokumenten würde am Kontextfenster scheitern (siehe Tokens & Kontextfenster) und wäre bei jeder Anfrage unnötig teuer. RAG holt stattdessen bei jeder einzelnen Frage nur die paar hundert Wörter, die wirklich relevant sind - dynamisch, aktuell und mit Quellenverweis.

Die Architektur: vier Phasen

Ein RAG-System lässt sich sauber in vier Phasen zerlegen. Die ersten beiden passieren einmalig (bzw. bei jeder Aktualisierung), die letzten beiden bei jeder einzelnen Nutzeranfrage.

Phase 1: INGEST (einmalig / bei Änderungen)
  Dokumente einsammeln (PDF, Word, SharePoint, Confluence, Tickets, ...)
    -> Text extrahieren, bereinigen
    -> in Chunks zerlegen (z. B. 300-800 Token pro Stück)

Phase 2: EMBED (einmalig / bei Änderungen)
  Jeder Chunk -> Embedding-Modell -> Vektor (z. B. 1536 Zahlen)
    -> Vektor + Chunk-Text + Metadaten in Vektordatenbank speichern

--- ab hier: bei jeder Anfrage ---

Phase 3: RETRIEVE (pro Anfrage)
  Nutzerfrage -> gleiches Embedding-Modell -> Frage-Vektor
    -> Vektordatenbank durchsucht nach ähnlichsten Chunks
    -> Top-Treffer (z. B. 5-10 Chunks) werden zurückgegeben

Phase 4: ANTWORT (pro Anfrage)
  Frage + gefundene Chunks -> Prompt zusammenbauen -> ans LLM senden
    -> LLM formuliert Antwort aus den Chunks, mit Quellenangabe

Ingest ist der unterschätzte Teil der Arbeit. Rohdaten liegen selten sauber vor - eingescannte PDFs ohne echten Text, Word-Dokumente mit wilder Formatierung, SharePoint-Seiten mit veralteten Duplikaten. Hier entscheidet sich oft schon, wie gut das gesamte System später wird: Müll rein, Müll raus, auch bei RAG.

Embed übersetzt Text in Zahlen. Ein Embedding-Modell wandelt jeden Textabschnitt in einen Vektor um - eine Liste von einigen hundert bis wenigen tausend Kommazahlen, die die Bedeutung des Texts in einem mathematischen Raum abbildet. Ähnliche Inhalte landen dabei nahe beieinander, unabhängig von der exakten Formulierung (mehr dazu unter Embeddings & Vektoren erklärt). Genau das macht die Suche im nächsten Schritt so viel schlauer als eine reine Stichwortsuche.

Retrieve ist der Moment der Wahrheit: Die Nutzerfrage wird mit demselben Embedding-Modell in einen Vektor verwandelt, und die Vektordatenbank sucht die Chunks, deren Vektoren am nächsten liegen - unabhängig davon, ob die Frage exakt dieselben Wörter benutzt wie das Originaldokument. Wer “Wie viele Ferientage habe ich?” fragt, findet so auch einen Abschnitt, der nur von “Urlaubsanspruch” spricht.

Antwort ist der einzige Schritt, in dem tatsächlich ein Sprachmodell zum Einsatz kommt. Es bekommt die gefundenen Chunks plus die Originalfrage in einem strukturierten Prompt und wird angewiesen, ausschliesslich daraus zu antworten - nicht aus seinem allgemeinen Trainingswissen.

Vereinfachter Prompt an das LLM (Antwort-Phase):

Beantworte die Frage NUR anhand der folgenden Auszüge.
Wenn die Antwort nicht in den Auszügen steht, sag das ehrlich.
Nenne am Ende die Quelle(n).

Auszüge:
[1] (Personalreglement.pdf, S. 4) "Mitarbeitende haben Anspruch auf
    25 Tage bezahlten Urlaub pro Kalenderjahr..."
[2] (Personalreglement.pdf, S. 5) "Nicht bezogene Urlaubstage können
    bis zum 31. März des Folgejahres übertragen werden..."

Frage: Wie viele Ferientage habe ich und kann ich sie übertragen?

Chunking: das unterschätzte Detail

Wie ein Dokument in Chunks zerlegt wird, entscheidet oft mehr über die Antwortqualität als die Wahl des Sprachmodells. Zu grosse Chunks verwässern die Relevanz (die Vektorsuche findet den Abschnitt, aber er enthält zu viel Unwichtiges drumherum). Zu kleine Chunks reissen Zusammenhänge auseinander (eine Tabelle wird mitten durchgeschnitten, eine Bedingung landet in einem anderen Chunk als ihre Ausnahme).

In der Praxis bewährt sich eine Chunk-Grösse von grob 300 bis 800 Token mit 10-15 % Überlappung zum Nachbar-Chunk als solider Startpunkt - und danach echtes Nachjustieren anhand der tatsächlichen Fragen, die gestellt werden.

Datenschutz: Wer darf was sehen?

Ein RAG-Chatbot ist nur so sicher wie die Zugriffsrechte auf seine Quelldaten - und das ist der Punkt, an dem viele Projekte in der Praxis stolpern. Die Vektordatenbank kennt von sich aus keine Berechtigungen; sie liefert den ähnlichsten Chunk, unabhängig davon, ob die fragende Person eigentlich Zugriff auf das Originaldokument hätte.

Drei Ansätze, damit umzugehen:

• Zugriffsfilter zur Abfragezeit. Jeder Chunk bekommt Metadaten (z. B. “nur HR-Team”, “nur Abteilung X”), und die Suche filtert automatisch nach den Rechten der anfragenden Person, bevor überhaupt Ergebnisse zurückkommen.
• Getrennte Indizes pro Berechtigungsstufe. Statt einer riesigen gemeinsamen Vektordatenbank gibt es mehrere kleinere, klar abgegrenzte - z. B. ein öffentlicher Index für alle, ein separater für die Geschäftsleitung.
• Live-Rechteprüfung gegen das Quellsystem. Vor jeder Antwort wird bei SharePoint, Confluence & Co. in Echtzeit geprüft, ob die Person das Originaldokument sehen dürfte (so funktioniert es z. B. bei personalisierten Wissensquellen in Copilot Studio) - technisch aufwendiger, aber am robustesten gegen veraltete Metadaten.

Zusätzlich stellt sich die Frage, wo die Daten überhaupt verarbeitet werden: Läuft die Vektordatenbank und das Sprachmodell in der EU/Schweiz oder in den USA? Wird bei der Anfrage an einen externen LLM-Anbieter tatsächlich Firmenwissen im Klartext übertragen? Wer maximale Kontrolle braucht, prüft lokale LLMs und Datenhoheit - also ein RAG-System, das komplett innerhalb der eigenen Infrastruktur läuft, ohne dass Anfragen oder Dokumentinhalte das Haus verlassen.

Build vs. Buy: drei Wege zum eigenen RAG-Chatbot

Die meisten KMU stehen vor derselben Grundsatzfrage: selbst bauen, eine Plattform konfigurieren, oder eine Fertiglösung einkaufen? Alle drei Wege sind legitim - die richtige Wahl hängt vom technischen Reifegrad, Budget und den Integrationsanforderungen ab.

Fertige Produkte sind der schnellste Einstieg: M365 Copilot mit angebundenen SharePoint-Bibliotheken liefert RAG “eingebaut”, ohne dass jemand eine Vektordatenbank aufsetzen muss. Der Preis dafür ist weniger Kontrolle über Chunking-Strategie, Modellwahl und Feinabstimmung.

Low-Code-Plattformen wie Copilot Studio (siehe Copilot Studio: eigene Agents fürs KMU bauen) liegen dazwischen: Wissensquellen anbinden per Klick, aber mit mehr Möglichkeiten für eigene Gesprächslogik, Actions und Kanäle. Für die meisten KMU-Anwendungsfälle - ein interner IT-Support-Bot, ein HR-Assistent, ein Kunden-FAQ-Bot - ist das der wirtschaftlichste Kompromiss.

Selbst gebaut bedeutet: eine eigene Vektordatenbank (z. B. Cloudflare Vectorize, pgvector auf Postgres, oder ein spezialisierter Dienst), ein Embedding-Modell und eine LLM-API, verbunden über eigenen Code. Das lohnt sich, wenn Standardlösungen an Grenzen stossen - etwa bei sehr grossen Datenmengen, ungewöhnlichen Datenquellen oder wenn maximale Kostenkontrolle bei hohem Anfragevolumen wichtiger ist als Entwicklungsgeschwindigkeit. Die konkrete technische Umsetzung dieses Wegs beschreibt RAG selbst bauen im Detail; die Grundlagen zu Vektordatenbanken findest du unter Vektordatenbanken.

Entscheidungshilfe:

Frage 1: Reicht Chat mit angebundenen Standard-Wissensquellen
         (SharePoint, Dokumente), ohne eigene Gesprächslogik?
   Ja  -> Fertiges Produkt (z. B. M365 Copilot + Wissensquellen).
   Nein -> Frage 2

Frage 2: Braucht ihr eigene Gesprächslogik, Aktionen (Tickets
         erstellen, Systeme abfragen) oder einen eigenen Kanal,
         aber kein eigenes Entwicklerteam?
   Ja  -> Low-Code-Plattform (z. B. Copilot Studio).
   Nein -> Frage 3

Frage 3: Sehr spezifische Anforderungen, eigene Infrastruktur,
         ungewöhnliche Datenquellen oder Kostenkontrolle bei
         hohem Volumen wichtiger als Entwicklungstempo?
   Ja  -> Selbst gebaute RAG-Pipeline.
   Nein -> Zurück zu Frage 2 - für die meisten KMU-Fälle reicht das.

Erfolgsfaktoren in der Praxis

• Datenqualität vor Technikwahl. Ein perfekt konfiguriertes RAG-System auf veralteten, widersprüchlichen Dokumenten liefert trotzdem schlechte Antworten. Aufräumen der Quelldaten (Duplikate entfernen, Veraltetes archivieren) bringt oft mehr als jede Modell- oder Datenbankwahl.
• Aktualität einplanen. Dokumente ändern sich - Ingest und Embed müssen regelmässig neu laufen, sonst beantwortet der Chatbot Fragen mit Stand von vor sechs Monaten. Eine klare Update-Routine (täglich, wöchentlich, ereignisgesteuert) gehört von Anfang an zum Konzept.
• Ehrliches “Ich weiss es nicht” einbauen. Ein gut konfigurierter RAG-Chatbot sagt aktiv, wenn die Wissensbasis keine Antwort liefert, statt trotzdem etwas zu erfinden. Das gehört explizit in den Antwort-Prompt, nicht dem Zufall überlassen.
• Messen statt vermuten. Eine kleine Testfrage-Sammlung mit bekannten richtigen Antworten zeigt objektiv, ob eine Änderung an Chunking oder Prompt tatsächlich hilft oder schadet.
• Governance nicht vergessen. Wer darf neue Dokumente in die Wissensbasis einspeisen? Wer prüft, ob sensible Inhalte versehentlich mit hochgeladen wurden? Ohne klare Zuständigkeit wächst die Wissensbasis unkontrolliert - Berührungspunkte dazu auch unter Shadow AI & Governance.

Kurz zusammengefasst

• RAG lässt ein Sprachmodell auf eigenen Firmendaten antworten, ohne es neu zu trainieren - durch Suche relevanter Textausschnitte vor der Antwortgenerierung.
• Die Architektur läuft in vier Phasen: Ingest (Dokumente aufbereiten), Embed (in Vektoren umwandeln), Retrieve (passende Chunks finden), Antwort (LLM formuliert aus den Chunks).
• Chunking-Strategie und die Aktualität der Wissensbasis beeinflussen die Antwortqualität oft stärker als die Modellwahl.
• Zugriffsrechte müssen VOR dem Indexieren geklärt sein - eine Vektordatenbank kennt von sich aus keine Berechtigungen.
• Build vs. Buy ist keine Alles-oder-nichts-Entscheidung: Fertigprodukt, Low-Code-Plattform und selbst gebaute Pipeline decken unterschiedliche Bedarfe ab.
• Erfolgreiche RAG-Projekte starten klein, mit sauberen Daten, klarer Update-Routine und einer ehrlichen “Ich weiss es nicht”-Option.

Weiterlernen

• AWS: Was ist Retrieval-Augmented Generation?
• Microsoft Learn: RAG und generative KI mit Azure AI Search
• Cloudflare: Vectorize - Vektordatenbank für KI-Anwendungen
• Microsoft Learn: Wissensquellen in Copilot Studio
• OWASP: Top 10 Risiken für LLM-Anwendungen (inkl. RAG-Aspekte)

Verwandte Themen: Embeddings & Vektoren erklärt · Vektordatenbanken · RAG selbst bauen · Fine-Tuning vs. RAG vs. Prompting · Copilot Studio: eigene Agents fürs KMU bauen