Was ist RAG? Retrieval Augmented Generation

Retrieval Augmented Generation (RAG) ist eine Architektur, die Generative AI mit Unternehmensdaten verbindet. Statt ein Large Language Model (LLM) nur mit allgemeinem Wissen antworten zu lassen, durchsucht ein RAG-System zuerst die eigenen Dokumente – und gibt dem Modell die relevanten Informationen als Kontext mit.

Das Ergebnis: Das LLM antwortet nicht aus dem Bauch heraus, sondern auf Basis Ihrer Wartungsprotokolle, Normen, Verträge, Prozessdokumentationen oder Betriebshandbücher. Mit Quellenangaben, nachprüfbar, unternehmensspezifisch.

RAG löst damit das grösste Problem von LLMs im Unternehmenseinsatz: Sie wissen sehr viel über die Welt – aber nichts über Ihr Unternehmen. Ein LLM kann brillant erklären, wie Predictive Maintenance funktioniert. Aber es weiss nicht, dass Ihre Fräse CNC-07 seit drei Wochen ungewöhnliche Vibrationen zeigt und beim letzten Mal ein Lagerschaden die Ursache war. RAG schliesst genau diese Lücke.

Wie RAG funktioniert – Schritt für Schritt

RAG ist kein einzelnes Tool, sondern eine Architektur aus mehreren Komponenten, die zusammenspielen. Die vier Phasen:

1. Indexierung: Dokumente vorbereiten

Bevor das System antworten kann, müssen die Unternehmensdaten aufbereitet werden. Dokumente (PDFs, Word-Dateien, Wartungsprotokolle, E-Mails, SharePoint-Inhalte) werden in kleine Abschnitte zerlegt – sogenannte Chunks. Diese Chunks werden von einem Embedding-Modell in numerische Vektoren umgewandelt: mathematische Repräsentationen des Textinhalts, die semantische Ähnlichkeit abbilden.

Die Vektoren werden in einer Vektordatenbank gespeichert. Dieser Schritt passiert einmal im Voraus und wird regelmässig aktualisiert, wenn neue Dokumente hinzukommen.

2. Retrieval: Relevante Informationen finden

Wenn ein Benutzer eine Frage stellt, wird diese ebenfalls in einen Vektor umgewandelt. Das System sucht dann in der Vektordatenbank nach den Chunks, die semantisch am ähnlichsten sind. Das ist der entscheidende Unterschied zur klassischen Volltextsuche: «Wann wurde die Spindel zuletzt getauscht?» findet auch Dokumente, die von «Spindelwechsel» oder «Austausch der Hauptspindel» sprechen – ohne dass exakt diese Wörter vorkommen müssen.

Moderne RAG-Systeme nutzen Hybridsuche: eine Kombination aus semantischer Suche (Vektoren) und klassischer Schlüsselwortsuche. Das verbessert die Trefferquote erheblich, besonders bei Fachbegriffen und Teilenummern.

3. Augmentation: Kontext an das LLM übergeben

Die gefundenen Chunks werden zusammen mit der ursprünglichen Frage als Prompt an das LLM geschickt. Der Prompt sagt dem Modell sinngemäss: «Beantworte diese Frage ausschliesslich auf Basis der folgenden Dokumente. Wenn die Informationen nicht ausreichen, sage das.»

Das ist der Mechanismus, der Halluzinationen reduziert: Das LLM generiert seine Antwort nicht aus dem allgemeinen Training, sondern aus den konkret bereitgestellten Quelldokumenten.

4. Generation: Antwort mit Quellenangaben

Das LLM formuliert eine natürlichsprachliche Antwort und verweist auf die Quellen (Dokumentname, Seitenzahl, Abschnitt). Der Benutzer kann die Antwort verifizieren – ein fundamentaler Unterschied zu einem LLM ohne RAG, das einfach «behauptet».

RAG vs. Fine-Tuning vs. reines Prompting

RAG ist nicht der einzige Weg, ein LLM mit Unternehmenswissen zu verbinden. Die drei Ansätze im Vergleich:

Die wichtigste Erkenntnis: RAG ist der Sweet Spot für die meisten Unternehmens-Use-Cases. Reines Prompting stösst bei mehr als 10–20 Seiten Kontext an Grenzen. Fine-Tuning lohnt sich nur, wenn das Modell ein grundlegend anderes Verhalten lernen soll (z.B. eine andere Sprache oder einen sehr spezifischen Schreibstil). Für den häufigsten Anwendungsfall – «Ich will mein LLM auf unsere Dokumente zugreifen lassen» – ist RAG die richtige Architektur.

Praxisbeispiele: Wo RAG in Industrie, Verkehr und Verwaltung Sinn ergibt

RAG ist keine abstrakte Technologie – es löst konkrete Probleme in den Branchen, in denen wir arbeiten:

Industrie: Wartungswissen erschliessen

Problem: Ein Instandhaltungsteam betreut 200 Maschinen. Die Wartungshistorie liegt in SAP, die Handbücher als PDF auf dem Fileshare, die Erfahrungsberichte im Kopf des Senior-Technikers, der nächstes Jahr in Pension geht.

RAG-Lösung: Alle Quellen werden indexiert. Ein Techniker fragt: «Welche Massnahmen wurden bei Vibrationsproblemen an CNC-Fräsen des Typs X in den letzten 2 Jahren ergriffen?» Das System durchsucht Wartungsprotokolle, Handbücher und Erfahrungsberichte und liefert eine zusammengefasste Antwort mit Quellenverweisen.

Warum das funktioniert: Das Wissen verlässt nicht das Unternehmen, wenn Mitarbeitende gehen. Neue Techniker finden Antworten in Minuten statt Stunden. Und das System wird besser, je mehr Dokumente indexiert sind.

Dieses Muster ergänzt unsere Arbeit im Bereich Predictive Maintenance: Wo ein klassisches ML-Modell die Anomalie erkennt (z.B. ungewöhnliche Vibrationswerte an einer Sortieranlage der Post), kann RAG den dazugehörigen Kontext liefern – was beim letzten Mal geholfen hat, welche Ersatzteile benötigt wurden und welche Sicherheitsvorschriften gelten.

Verkehr: Störungsmeldungen analysieren

Problem: Ein Verkehrsunternehmen generiert hunderte Störungsmeldungen pro Monat. Disponenten und Betriebsleiter müssen Muster erkennen: Häufen sich bestimmte Störungen auf bestimmten Strecken? Gibt es saisonale Muster? Was wurde bei früheren, ähnlichen Vorfällen unternommen?

RAG-Lösung: Störungsmeldungen, Betriebsprotokolle und Massnahmenberichte werden indexiert. Ein Disponent fragt: «Was sind die häufigsten Ursachen für Weichenstörungen auf der Linie 6 im Winter?» Das System durchsucht historische Meldungen und liefert eine Analyse mit Quellenangaben.

Verwaltung: Reglemente und Vorschriften durchsuchen

Problem: Sachbearbeiter in öffentlichen Verwaltungen müssen für jede Entscheidung Reglemente, Verordnungen, Weisungen und Bundesrecht konsultieren. Die Dokumente sind komplex, zahlreich und ändern sich regelmässig. Die Suche in PDF-Sammlungen ist mühsam und fehleranfällig.

RAG-Lösung: Alle relevanten Dokumente werden indexiert. Ein Sachbearbeiter fragt: «Welche Vorschriften gelten für die Beschaffung von IT-Dienstleistungen über 250'000 CHF im Kanton Bern?» Das System findet die relevanten Paragraphen aus Vergaberecht, kantonalem Gesetz und internen Weisungen.

Warum das für öffentliche Verwaltungen besonders attraktiv ist: Quellenangaben sind keine Option, sondern Pflicht. RAG liefert genau das – und ist damit die einzige GenAI-Architektur, die in regulierten Umgebungen vertretbar ist.

Voraussetzungen: Was Sie brauchen, bevor Sie mit RAG starten

RAG scheitert selten am LLM. Es scheitert an den Daten. Die wichtigsten Voraussetzungen:

Saubere, auffindbare Dokumente

RAG ist nur so gut wie die Dokumente, die indexiert werden. Wenn Ihre Wartungsprotokolle als eingescannte, handschriftliche PDFs auf einem Fileshare liegen, wird das Retrieval schlecht funktionieren. Die Dokumente müssen digital vorliegen, durchsuchbar sein und eine minimale Struktur haben (Titel, Datum, Kategorisierung).

Das ist der Punkt, an dem sich die meisten Unternehmen überschätzen: Sie denken, sie haben «alle Daten digital» – und entdecken dann, dass 40% der relevanten Informationen in E-Mail-Anhängen, persönlichen Ordnern und Teams-Chats liegen. Eine Datenlandkarte macht dieses Problem sichtbar.

Eine Datenplattform als Fundament

RAG funktioniert am besten, wenn es nicht nur unstrukturierte Dokumente durchsucht, sondern auch auf strukturierte Daten zugreifen kann: Stammdaten aus dem ERP, Messwerte aus dem Data Warehouse, Sensor-Historien aus dem Data Lake. Das Zusammenspiel sieht typischerweise so aus:

Data Pipeline → sammelt und transformiert strukturierte Daten

Microsoft Fabric / Snowflake → speichert und verarbeitet die Daten

Dokumentenspeicher (SharePoint / OneLake) → enthält unstrukturierte Dokumente

Vektordatenbank → indexiert alles für semantische Suche

LLM (GPT-4, Claude, Llama) → generiert Antworten auf Basis der gefundenen Quellen

Power BI / Custom UI → zeigt Ergebnisse an oder triggert Workflows

Unternehmen, die bereits eine Datenplattform betreiben (z.B. mit dbt + Fabric), haben den idealen Ausgangspunkt: Die strukturierten Daten sind bereits sauber, dokumentiert und versioniert. RAG ergänzt diesen Stack um die unstrukturierte Dimension.

Data Governance

Welche Dokumente dürfen indexiert werden? Wer darf welche Antworten sehen? Gibt es vertrauliche Inhalte, die nicht in den Index gehören? Data Governance ist bei RAG nicht optional – sie entscheidet darüber, ob das System vertrauenswürdig ist.

Datenschutz und Datensouveränität

Wenn vertrauliche Dokumente an ein Cloud-LLM geschickt werden, stellen sich Fragen: Wo werden die Daten verarbeitet? Werden sie für Training verwendet? Gerade für Unternehmen im öffentlichen Verkehr und in der öffentlichen Verwaltung ist das zentral.

Lösungsansätze: Azure OpenAI Service mit Schweizer Datenresidenz (Daten verlassen die EU/CH nicht, werden nicht für Training verwendet), On-Premise-LLMs wie Llama oder Mistral (komplette Kontrolle, höherer Betriebsaufwand), oder hybride Architekturen, bei denen das Retrieval on-premise läuft und nur anonymisierte Chunks an das LLM gehen.

Typische Stolpersteine bei RAG-Projekten

Aus unserer Erfahrung und der Branchenpraxis sind das die häufigsten Fehler:

Zu grosse Chunks. Wenn ein Chunk eine ganze 20-seitige Dokumentation enthält, findet das Retrieval zwar das Dokument – aber das LLM bekommt zu viel irrelevanten Kontext und die Antwortqualität sinkt. Optimale Chunk-Grösse hängt vom Anwendungsfall ab (typisch: 200–500 Tokens), muss aber getestet werden.

Kein Re-Ranking. Die Vektordatenbank liefert die semantisch ähnlichsten Chunks – aber «ähnlich» heisst nicht «relevant». Ein Re-Ranking-Schritt (z.B. mit einem Cross-Encoder-Modell) sortiert die Ergebnisse nach tatsächlicher Relevanz für die spezifische Frage. Das verbessert die Antwortqualität dramatisch.

Fehlende Metadaten. Wenn Chunks keinen Kontext mitbringen (Dokumentname, Erstelldatum, Abteilung, Maschinentyp), kann das System nicht filtern. «Zeig mir nur Wartungsprotokolle der letzten 6 Monate für Fräsen» ist mit Metadaten trivial – ohne unmöglich.

Keine Evaluation. Viele Teams bauen ein RAG-System und «testen» es, indem sie drei Fragen stellen. Das reicht nicht. Ein systematisches Evaluationsset (50–100 Fragen mit erwarteten Antworten und Quellen) ist nötig, um die Qualität zu messen und gezielt zu verbessern.

Zu hohe Erwartungen. RAG reduziert Halluzinationen, eliminiert sie aber nicht. Wenn die Antwort auf eine Frage nicht in den indexierten Dokumenten steht, kann das System entweder «Ich weiss es nicht» sagen (gut konfiguriert) oder eine plausible, aber falsche Antwort generieren (schlecht konfiguriert). Die Konfiguration und das Prompt Engineering machen den Unterschied.

Wie Sie starten

Ein RAG-Projekt braucht keine 6-monatige Planungsphase. Unser empfohlener Weg:

1. Use Case definieren. Nicht «wir wollen RAG», sondern: «Unser Instandhaltungsteam soll Wartungshistorien in Sekunden statt Stunden finden.» Je konkreter, desto besser.

2. Dokumentenbasis prüfen. Welche Dokumente sind relevant? In welchem Format liegen sie vor? Wie aktuell sind sie? Eine Datenlandkarte hilft, den Überblick zu gewinnen.

3. Proof of Concept (4–6 Wochen). Einen begrenzten Dokumentensatz indexieren, ein einfaches RAG-System aufsetzen, mit echten Fragen testen. Ziel: beweisen, dass die Antwortqualität ausreicht – und messen, wie viel Zeit es spart.

4. Architektur entscheiden. Cloud oder On-Premise? Welches LLM? Welche Vektordatenbank? Wie wird re-indexiert? Diese Fragen klären wir im Rahmen einer Datenstrategie.

5. Produktiv setzen und verbessern. RAG-Systeme werden besser über Zeit: mehr Dokumente, bessere Chunking-Strategien, optimierte Prompts, Feedback-Loops von Benutzern. Der Go-live ist der Anfang, nicht das Ende.

Wie wir Sie unterstützen

RAG ist kein isoliertes KI-Projekt – es sitzt auf einer Datenplattform. Und genau das ist unsere Kernkompetenz: Daten integrieren, Pipelines bauen, Datenqualität sicherstellen und KI-Modelle in Produktion bringen.

Unsere Erfahrung aus Projekten wie der Defekterkennung mittels Computer Vision, der Predictive Maintenance für Sortieranlagen der Post, der automatisierten Serviceklassifikation bei V-ZUG und dem Aufbau von Datenplattformen auf Microsoft Fabric fliesst direkt in unsere RAG-Beratung ein.

Sie möchten wissen, ob RAG für Ihren Use Case Sinn ergibt? Kontaktieren Sie uns – wir finden es gemeinsam heraus.

Weiterführende Glossar-Einträge

• Was ist Generative AI? – GenAI für Unternehmen verstehen
• Supervised vs. Unsupervised Learning – Klassische ML-Verfahren als Ergänzung
• Was ist eine Data Pipeline? – Daten automatisiert von A nach B
• dbt + Microsoft Fabric – Modernes Data Engineering
• Was ist ein Data Warehouse? – Strukturierte Daten für Analysen
• Was ist ein Data Lake? – Rohdatenspeicher für KI-Projekte
• Data Governance – Datenqualität sicherstellen
• Datenlandkarte erstellen – Der erste Schritt zu jedem Datenprojekt
• Federated Learning – KI trainieren, ohne Daten zu teilen
• Vom Shopfloor zum Insight – Produktionsdaten analysierbar machen

‍