KI ist längst Teil des Arbeitsalltags. Ein Meeting zusammenfassen, Daten aus einer Tabelle ziehen, eine E-Mail an einen Kunden schreiben – die Ergebnisse sind oft überraschend gut. Bis die Fragen konkreter werden.
Frag die KI nach der aktuellen Preispolitik deines Unternehmens, und sie zitiert vielleicht eine Version von vor zwei Jahren. Frag sie nach einer Fallstudie mit echten ROI-Zahlen, und sie erfindet dir vielleicht eine, die plausibel klingt, aber nicht existiert. Das nennt man eine Halluzination – oder Drift, wenn sich das Muster wiederholt.
Warum passiert das? Das Modell wurde mit Daten trainiert, die vor deiner Frage existiert haben. Es hat keinen Zugriff auf das, was du intern geschrieben, kürzlich aktualisiert oder in deinen Systemen gespeichert hast. Manche Modelle können zwar das Internet durchsuchen, um Lücken zu füllen – aber das ist weder zuverlässig noch effizient, wenn es um unternehmensspezifisches Wissen geht. Also füllt das Modell die Lücken mit der statistisch wahrscheinlichsten Antwort. Und die ist nicht immer die richtige.
RAG – kurz für Retrieval-Augmented Generation – ist die praktischste Lösung für dieses Problem. Anstatt sich auf das Gedächtnis des Modells zu verlassen, verbindet RAG es in Echtzeit mit deiner tatsächlichen Wissensdatenbank. Unternehmensrichtlinien, Verkaufsunterlagen, interne Handbücher, FAQs – wenn jemand eine Frage stellt, sucht das System zuerst die relevanten Passagen aus deinen Inhalten heraus, fügt sie als Kontext hinzu und generiert erst dann eine Antwort auf dieser Grundlage.
Das ist sehr effektiv. Deine interne Dokumentation kann so etwas wie ein operatives Orakel werden, das in klarer Sprache antwortet. Aber es ist keine Zauberei – und es ist nicht für jede Situation das richtige Tool.
Am Ende dieses Artikels weisst du, was RAG wirklich macht, wie du deine Inhalte dafür vorbereitest und wann es die richtige Wahl ist – und wann du strukturierter vorgehen solltest.
Wie RAG funktioniert (ohne Fachjargon)
RAG sitzt unsichtbar zwischen deiner Frage und der Antwort der KI. Das Modell antwortet nicht allein aus dem Gedächtnis (eigene Wissensbasis) – es ruft zuerst relevantes Material aus deiner Wissensdatenbank ab und nutzt das als Grundlage für seine Antwort.
So läuft der Prozess ab, auf das Wesentliche reduziert:
- Inhaltsvorbereitung: Du lädst deine Dokumente (Richtlinien, FAQs, Verfahren) in einem strukturierten, lesbaren Format ins System.
- Indizierung: Das System verarbeitet diese Inhalte mit zwei sich ergänzenden Ansätzen – klassischer Stichwortsuche (Keyword-Search) und semantischer Suche (mehr dazu weiter unten).
- Content-Retrieval: Wenn eine Frage eingeht, zieht der Index die relevantesten Passagen heraus.
- Generierung: Die KI erstellt eine Antwort auf Basis dieser abgerufenen Passagen sowie ihres Allgemeinwissens.
Das Ergebnis ist eine Antwort, die auf deinen tatsächlichen Inhalten basiert – nicht von Grund auf neu generiert.
Warum hybride Suche wichtig ist
Die Stichwortsuche (Keyword-Search) funktioniert gut, wenn jemand genau den Begriff verwendet, der in einem Dokument steht. Die semantische Suche geht einen Schritt weiter: Sie versteht die Bedeutung – nicht nur die Wörter.
Ein Beispiel: «Wie man die Unternehmensmarge steigert» und «Betriebskosten senken» meinen dasselbe Konzept, haben aber kaum gemeinsame Stichwörter. Die semantische Suche findet relevante Inhalte auch dann, wenn die Formulierung unterschiedlich ist. Gut aufgebaute RAG-Systeme nutzen in der Praxis beide Ansätze zusammen. Stichwörter greifen bei präzisen Verweisen, Produktcodes und Eigennamen. Die semantische Suche übernimmt alles, wo die Absicht wichtiger ist als die genaue Wortwahl.
RAG vs. Fine-Tuning
Diese beiden Begriffe werden oft durcheinandergebracht. RAG verändert das Modell selbst nicht – es nutzt ein fertiges LLM (wie Claude oder GPT) und übergibt ihm bei jeder Frage die passenden Ausschnitte aus deiner Wissensdatenbank. Aktualisierst du die Wissensdatenbank und indizierst sie neu, bleiben die Antworten aktuell.
Fine-Tuning funktioniert anders. Es passt das Verhalten oder den Stil des Modells dauerhaft an. Das ist sinnvoll, wenn du einen einheitlichen Tonfall oder domänenspezifisches Verhalten brauchst – nicht aber, wenn es hauptsächlich darum geht, präzise und aktuelle Antworten aus Dokumenten zu bekommen.
Ein wichtiger Punkt: RAG ist nur so gut wie sein Content-Retrieval. Falscher Kontext als Eingabe führt zu einer selbstbewussten, aber falschen Antwort. Mehr abgerufene Inhalte bedeuten auch mehr verarbeitete Tokens – und damit höhere Kosten. Dieses Gleichgewicht musst du bewusst gestalten. «Mehr Dokumente gleich bessere Antworten» stimmt eben nicht.
Bei what. entwickeln wir RAG nicht immer von Grund auf neu. Wir wählen den Ansatz, der zum tatsächlichen Bedarf passt – massgeschneidertes RAG, Managed-Search-Lösungen oder eine Kombination – damit du dort investierst, wo es sich wirklich lohnt.
| RAG ruft relevante Inhalte aus deiner KI-Wissensdatenbank ab und übergibt sie dem LLM als Kontext, bevor eine Antwort generiert wird. Es wird eine Kombination aus Stichwort- und semantischer Suche verwendet. Das Modell wird nicht neu trainiert – stattdessen wird ein Standard-LLM in Echtzeit mit deinen Dokumenten verknüpft. Die Qualität des Content-Retrievals bestimmt die Qualität der Antworten. |
Auch lesen: Warum brauchst du überhaupt KI-Automatisierung für deine Abläufe?
Deine KI-Wissensdatenbank vorbereiten: Warum das Format wichtiger ist, als du denkst
RAG greift auf das zurück, was du geschrieben hast. Wenn deine Dokumente unstrukturiert, fragmentiert oder schlecht aufgebaut sind, versteht das System dein Geschäft nicht wie von selbst – es findet nur schwache Stellen, und das Modell füllt die Lücken mit selbstsicherem Inhalt. Genau dann schleichen sich Halluzinationen wieder ein.
Die Qualität des Retrievals hängt fast genauso stark von deinen Inhalten ab wie vom Algorithmus dahinter.
Markdown vs. PDF
PDFs sind grossartig zum Lesen und Teilen. Für RAG sind sie oft ein Problem. Komplexe Layouts, fehlerhafte Tabellen, gescannte Seiten – all das braucht OCR oder einen Parsing-Schritt, bevor es indexiert werden kann. Das verursacht zusätzliche Kosten, verlängert die Verarbeitungszeit und birgt das Risiko, dass verzerrter Text in deiner Wissensdatenbank landet. Tools wie LlamaIndex werden häufig eingesetzt, um das zu handhaben, wenn PDF unvermeidbar ist – aber es ist immer aufwändiger als sauber strukturierter Text.
Markdown funktioniert besser, weil die Struktur eindeutig ist: Überschriften, Abschnitte und Listen sagen dem Indizierungssystem genau, wo ein Thema aufhört und ein anderes beginnt. Für ein KI-Modell, das den richtigen Abschnitt abrufen will, macht diese Klarheit einen grossen Unterschied.
Markdown ist ausserdem formatunabhängig. Es lässt sich sauber in HTML, Word, PDF und die meisten CMS-Exporte konvertieren – deine RAG-Pipeline ist also nicht an einen bestimmten Anbieter oder ein bestimmtes Tool gebunden. Und es ist seit Jahren Standard in der Software-Dokumentation, weil es Klartext ist, sich gut versionieren lässt und leicht zu pflegen ist.
Die Faustregel: Behalte PDFs für die Archivierung und Verteilung. Verwende Markdown (oder gleichwertigen strukturierten Text) als Arbeitsformat für alles, was in RAG einfliessen soll. Wenn du nur gescannte PDFs hast, plane Budget für die Extraktion ein – es ist machbar, kostet aber mehr und birgt ein höheres Fehlerrisiko.
So strukturierst du deine Dokumente für das Content-Retrieval
Ein paar einfache Gewohnheiten machen einen grossen Unterschied bei der Leistung von RAG:
- Ein Thema pro Abschnitt. Verwende klare Überschriften. Vermeide riesige Einzeldateien, die alles abdecken – bevorzuge themenbezogene Dokumente oder klar getrennte Abschnitte, damit das Retrieval zusammenhängende Blöcke liefert und nicht ein halbes Kapitel voller irrelevanter Inhalte.
- Beschreibende, spezifische Titel. «Einleitung» oder «Anhang» helfen bei der Suche nicht. «Richtlinien Remote-Work – Schweiz» oder «Umgang mit Preisvorbehalten – Unternehmenskunden» schon. Der Titel ist oft das Erste, das abgeglichen wird.
- Codes und Referenzen früh einbauen. Wenn du interne Verfahrenscodes, Modulnamen oder SKUs verwendest, füge sie in die Überschrift oder die erste Zeile ein. So trifft die Stichwortsuche sofort ins Schwarze.
- Nummerierte Listen für Prozesse verwenden. Schritt-für-Schritt-Anleitungen lassen sich besser abrufen und zitieren als dichte Textabschnitte. Wenn es eine Abfolge gibt, formatiere sie als Abfolge.
- Ballast rauswerfen. Wiederholte Kopf- und Fusszeilen, rechtliche Hinweise auf jeder Seite, doppelte Versionen desselben Dokuments – all das belastet deinen Index. Saubere Inhalte lassen sich sauber abrufen.
Ein Hinweis zum Chunking
Lange Dokumente werden zur Indizierung in kleinere Chunks aufgeteilt. Zu grosse Chunks bringen zu viel Rauschen mit sich; zu kleine verlieren den roten Faden. Das Aufteilen an Markdown-Überschriften hält verwandte Inhalte auf natürliche Weise zusammen und reduziert das Risiko, ein Konzept in zwei Hälften zu zerschneiden.
Gute Indizierungspipelines nutzen auch Überlappungen – ein paar Zeilen aus benachbarten Abschnitten werden in jeden Block aufgenommen, damit das Modell an den Grenzen nicht den Kontext verliert. Wenn ein Dokument kurz ist und in einem bestimmten Kontext immer relevant ist, funktioniert es manchmal besser, es vollständig einzubeziehen, als sich nur auf abgerufene Fragmente zu verlassen.
Die ehrliche Frage, die du dir stellen solltest, bevor du in ein teureres Modell oder eine teurere Plattform investierst: Ist deine Wissensdatenbank überhaupt auffindbar? Ein gut konzipiertes RAG mit sauberen Inhalten wird bei gleichen API-Kosten durchweg besser abschneiden als eine mittelmässige Konfiguration mit chaotischen PDFs.
Nicht alles gehört auf die gleiche Weise in RAG
Es lohnt sich, bewusst zu entscheiden, was wohin gehört. Drei Kategorien sind hilfreich:
| Typ | Beispiel | Wie man damit umgeht |
|---|---|---|
| Verbindliche Regeln | Markenstimme, rechtliche Vorgaben, Kernidentität | Immer in den Kontext einbinden – nicht dem zufälligen Retrieval überlassen |
| Geordnete Abläufe | Playbooks, Compliance-Schritte | Orchestrierung bevorzugen; RAG garantiert keine Schrittfolge |
| Unterstützendes Wissen | Frameworks, Fallstudien, ausführliche FAQs | Hier glänzt RAG – abrufen, wenn die Frage danach verlangt |
Ein häufiger Fehler ist es, kritische Schritt-für-Schritt-Anleitungen in RAG zu speichern und zu hoffen, dass das Modell sie der Reihe nach befolgt. Das funktioniert nicht zuverlässig. Das Content-Retrieval findet relevante Fragmente – es ersetzt keine Workflow-Engine mit erzwungener Reihenfolge.
| Das Format ist genauso wichtig wie der Algorithmus. Verwende nach Möglichkeit Markdown statt PDF. Schreibe klare, beschreibende Abschnittsüberschriften. Ein Thema pro Abschnitt. Entferne Unwichtiges und Duplikate. Nicht alles sollte auf die gleiche Weise in RAG einfliessen – kritische Regeln sollten immer eingefügt, nicht abgerufen werden. |
Zum Thema: Bevor du KI einsetzt, optimiere zuerst deine Workflows.
Wann RAG ausreicht – und wann du mehr brauchst
Das ist die Frage, die Teams davor bewahrt, zu viel oder zu wenig zu entwickeln.
RAG in Kombination mit einem LLM ist die richtige Konfiguration, wenn jemand eine Frage stellt und eine fundierte Antwort braucht. Es ist nicht die richtige Konfiguration, wenn die Interaktion einen Prozess mit obligatorischen Schritten erfordert, einen über Sitzungen hinweg verfolgten Status oder aufeinanderfolgende Entscheidungen, die nicht übersprungen werden können.
Zwei Denkmodelle:
| Nur RAG + LLM | Orchestrierung + RAG + LLM |
|---|---|
| Frage → Retrieval → Antwort | Prozessstatus + Retrieval → Antwort im richtigen Schritt |
| Am besten geeignet, um etwas zu wissen | Erforderlich, wenn du Dinge auch in der richtigen Reihenfolge erledigen musst |
Einfache Faustregel: eine Frage, eine Antwort, keine vorgeschriebene Abfolge über Sitzungen hinweg – fang mit RAG und einem LLM an. Gleicher Nutzer, mehrere Runden, Schritte, die nicht übersprungen werden können – füge Orchestrierung hinzu. RAG dient dann als unterstützende Bibliothek, nicht als Rückgrat des Prozesses.
Drei Fälle, in denen RAG + LLM die richtige Wahl ist
- Interne FAQ oder HR-Richtlinien. «Wie lauten unsere Richtlinien zur Remote-Arbeit für Mitarbeitende in der Schweiz?» – Ein gut indexierter Korpus, eine Antwort, die auf dem tatsächlichen Richtliniendokument basiert, kein mehrstufiger Prozess nötig. Finden, erklären, fertig.
- Sales Enablement. «Haben wir eine Logistik-Fallstudie mit ROI?» – Eine Bibliothek mit Geschäftsdokumenten, die Nutzende je nach Absicht durchsuchen, nicht nach einem festen Skript. RAG bewältigt das ganz natürlich.
- Produkt-Support (L1). «Wie setze ich die Verbindung auf Gerät X zurück?» – Eine Frage, eine Antwort, direkt mit dem Handbuch verknüpft. Wenn das Retrieval fehlschlägt, korrigiere das Dokument – nicht die gesamte Architektur.
Drei Fälle, in denen du eine stärkere Architektur brauchst
- Digitales Coaching oder Beratung mit einem Playbook. Mehrwöchige Projekte, bei denen du Ziele verfolgst, Optionen durcharbeitest und mit einem Plan abschliessen willst. Die aktuellen Schritt- und Sitzungsregeln müssen ausserhalb des Modells liegen – in einer Datenbank oder einer Zustandsmaschine. RAG bringt Frameworks und Beispiele ein, wenn dieser Schritt sie erfordert. Ohne Orchestrierung überspringt die KI Phasen oder vergisst, was vor zwei Sitzungen vereinbart wurde.
- Onboarding von Mitarbeitenden oder Partnern. Woche eins: Dokumente. Woche zwei: Schulung. Woche drei: Kompetenzcheck. Diese Reihenfolge kann vertraglich oder durch Compliance-Vorgaben festgelegt sein. Das richtige PDF zu finden reicht nicht – du kannst Modul drei erst öffnen, wenn Modul zwei abgeschlossen ist. RAG liefert den Inhalt; eine Zustandsmaschine steuert den Ablauf.
- Geführte Verkaufsanalyse. Qualifizierung, dann Bedarfsanalyse, dann Angebot – mit obligatorischen Fragen in jeder Phase. RAG ruft Preise, Battle Cards und Einwandbehandlungen ab. Ein Orchestrator sorgt für die Reihenfolge: «Keine Preisdiskussion, bevor der Bedarf nicht ermittelt wurde.» Ohne das gibt die KI zu früh Angebote ab oder erfindet ein Framework, das nicht deins ist.
| RAG + LLM reicht für Frage-und-Antwort-Anwendungsfälle: FAQs, Richtlinienabfragen, Sales Enablement, L1-Support. Füge Orchestrierung hinzu, wenn du festgelegte Abläufe, Sitzungsstatus oder mehrstufige Prozesse benötigst. RAG ist eine Retrieval-Bibliothek, keine Workflow-Engine. |
Verbessere deine Inhalte, bevor du dem Modell die Schuld gibst
Wenn RAG hinter den Erwartungen zurückbleibt, ist die Versuchung gross, das Modell zu aktualisieren oder auf eine teurere Plattform umzusteigen. Meistens ist das der falsche Schritt.
Die meisten Retrieval-Probleme lassen sich auf die Qualität der Inhalte zurückführen – nicht auf die Leistungsfähigkeit des Modells. Dokumente, die zu lang sind, schlechte Titel haben oder in verschiedenen Versionen doppelt vorhanden sind, verwirren selbst das beste Content-Retrieval-System. Die Lösung liegt in der redaktionellen Bearbeitung, nicht in der Architektur.
Bevor du in die Infrastruktur investierst, überprüfe drei Dinge:
- Sind die Inhalte bereit? Strukturiert, im eigenen Besitz, auf dem neuesten Stand – keine Mischung aus verstreuten PDFs und sechs Versionen desselben Richtliniendokuments.
- Handelt es sich um ein Such-und-Antwort-Problem oder ein Folge-einem-Pfad-Problem? FAQs und Richtlinien brauchen in der Regel RAG + LLM. Playbooks und mehrstufige Onboarding-Prozesse erfordern zusätzlich Orchestrierung.
- Ist der Erfolg klar definiert? «Nützliche Antworten, die mit Quellen verknüpft sind» ist ein Erfolgskriterium. «Es klingt clever» ist keines.
Ein schneller Weg, um herauszufinden, wo der eigentliche Engpass liegt: Wähle einen Bereich aus, stelle 20 bis 30 Dokumente zusammen und schreib 10 echte Fragen auf, die dein Team tatsächlich stellt. Lass es laufen. Innerhalb weniger Tage weisst du, ob das Problem beim Retrieval, bei der Inhaltsqualität oder bei der Architektur liegt – und hast dafür fast nichts ausgegeben.
Brauchst du KI-Automatisierungsworkflows, die von Anfang bis Ende zuverlässig sind – nicht nur beim Retrieval? Unsere Tool-Integration verbindet die Systeme, auf die deine RAG-Pipeline angewiesen ist – damit Daten sauber in deine Wissensdatenbank fliessen und ohne manuellen Aufwand aktuell bleiben.
| Schlechtes Retrieval ist meist ein Inhaltsproblem, kein Modellproblem. Überprüfe die Inhaltsqualität, bevor du die Infrastruktur aufrüstest. Führe zunächst ein kleines Pilotprojekt durch – 20–30 Dokumente, 10 echte Fragen –, um den tatsächlichen Engpass zu lokalisieren. |
Bereit, eine Wissensdatenbank aufzubauen, die wirklich funktioniert?
Die richtige Frage lautet nicht: «Welche KI-Plattform soll ich kaufen?» Sondern: «Habe ich eine Wissensdatenbank, die es wert ist, abgefragt zu werden – und einen Prozess, der weiss, wann man sich auf RAG verlassen sollte und wann nicht?»
Genau bei dieser Art von Fragen helfen wir Teams weiter. Als KI-Automatisierungsagentur arbeitet what. mit Unternehmen zusammen, um RAG-Setups zu entwickeln, die zum tatsächlichen Anwendungsfall passen – nicht komplexer als nötig, aber auch nicht zu schwach für die Aufgabe. Ob das nun ein schlankes RAG-only-Setup oder einen vollständig orchestrierten KI-Workflow bedeutet: Wir helfen dir, den richtigen Umfang zu ermitteln, bevor du irgendetwas entwickelst.
Melde dich für eine gezielte Beratung. Kein Verkaufsgespräch – nur ein ehrlicher Blick darauf, ob RAG das Richtige für dich ist und was es braucht, damit es gut funktioniert.
