RAG-Architektur für Unternehmen: Technischer Leitfaden

RAG (Retrieval-Augmented Generation) ist ein Systemdesign, das ein grosses Sprachmodell mit einem externen Abruf-Layer koppelt: Statt auf eingefrorenem Trainingswissen zu antworten, zieht das System zur Laufzeit relevante Dokumente aus einem Index und bettet diese als Kontext in den Prompt ein. Das Ergebnis sind aktuelle, belegbare Antworten ohne ständiges Neutraining des Modells.

Wann lohnt sich RAG für Ihr Projekt?

Grosse, sich ändernde Wissensbasen: Regulatorische Dokumente, interne Richtlinien, Produktdaten, die sich laufend ändern.
Nachprüfbarkeit ist Pflicht: Jede Antwort muss auf eine konkrete Quelle zurückgeführt werden können, etwa für Compliance-Audits.
Kostenkontrolle: Häufiges Fine-Tuning eines LLM ist teuer. RAG hält das Modell stabil und aktualisiert nur den Index.
Latenztoleranz vorhanden: Eine RAG-Pipeline braucht typischerweise mehrere Schritte; Systeme mit Sub-100-ms-Anforderungen sollten die Architektur sorgfältig abwägen.

Passt keiner dieser Punkte, ist ein einfaches Prompt-Engineering oder ein kleineres Fine-Tuning oft die bessere Wahl.

Inhaltsverzeichnis

Welche Kernkomponenten bilden eine RAG-Architektur?
Wie funktioniert die RAG-Pipeline von Anfang bis Ende?
Wie wählt man das richtige Embedding-Modell und Index-Design?
Wann lohnen sich hybride Retrieval-Strategien und Reranking?
Was sind die echten Vorteile und Grenzen von RAG?
Welche Konstruktionsfehler zerstören RAG-Projekte in der Praxis?
Wie planen Sie Latenz, Skalierung und Kosten im Produktionsbetrieb?
Was müssen Schweizer Unternehmen bei Datenschutz und Compliance beachten?
Wie wählen Sie die richtige Architektur für Ihr Schweizer Unternehmen?
Was zeigt das Zürcher KMU-Projekt über RAG in der Praxis?
Wie starten Sie Ihr erstes RAG-Projekt konkret?
Wichtige Erkenntnisse
RAG in Schweizer Unternehmen: Was wirklich zählt
Outwork begleitet Ihr RAG-Projekt von der Idee bis zum Betrieb
Nützliche Quellen und weiterführende Lektüre

Welche Kernkomponenten bilden eine RAG-Architektur?

Eine RAG-Architektur besteht aus mehreren klar abgrenzbaren Modulen. Jedes lässt sich unabhängig austauschen, was Flexibilität in der Weiterentwicklung schafft.

Ingest und Chunking

Dokumente aus SharePoint, S3, OneDrive oder Datenbanken werden geparst, bereinigt und in Abschnitte (Chunks) zerlegt. Chunk-Grösse und Overlap-Strategie beeinflussen direkt, wie viel Kontext der Retriever später liefert.

Embeddings und Embedding-Modelle

Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt. Die Wahl des Modells bestimmt die semantische Qualität des Abrufs: Transformer-basierte Modelle wie text-embedding-3-large liefern hohe Qualität, kosten aber mehr Rechenzeit als leichtere Modelle.

Vektor-Datenbank und Index

Die erzeugten Vektoren landen in einem Vektor-Store. Gängige Optionen sind Milvus, FAISS oder verwaltete Dienste. Der Index (meist HNSW) ermöglicht schnelle Näherungssuche (ANN). Lineage-Anforderungen, also die Rückverfolgbarkeit von Chunk zu Quelldokument, müssen beim Speicherdesign von Anfang an berücksichtigt werden.

Retriever, Reranker und Generator

Der Retriever holt die Top-K ähnlichsten Chunks. Ein optionaler Cross-Encoder-Reranker sortiert diese Kandidaten nach semantischer Relevanz neu. Der Generator (LLM) erhält den aufbereiteten Kontext über den Prompt-Builder und produziert eine Antwort, idealerweise als strukturiertes JSON mit eingebetteten Quellenverweisen.

Orchestrierung, Caching und Monitoring

Eine Produktionspipeline braucht mehr als Retrieval und Generierung. Orchestrierungsschichten wie Dagster koordinieren Ingest, Embedding und Upsert. Caching reduziert Kosten bei wiederkehrenden Anfragen. Eine Evaluationseinheit misst laufend Faithfulness, Kontext-Recall und Antwortlatenz.

Profi-Tipp: Bauen Sie die Evaluationseinheit nicht nachträglich ein. Wer Metriken wie Faithfulness und Kontext-Precision von Anfang an misst, erkennt Qualitätsprobleme, bevor sie in der Produktion sichtbar werden.

Wie funktioniert die RAG-Pipeline von Anfang bis Ende?

Die folgende Schrittfolge beschreibt den Weg vom Rohdokument bis zur verifizierten Antwort. Jede Stufe hat eigene Risiken und Metriken.

Dokumentenerfassung: Quellen (SharePoint, S3, Datenbanken) werden per Connector eingelesen. Prüfen Sie Vollständigkeit und Aktualität der Quellen, bevor der nächste Schritt beginnt.
Parsing und Chunking: PDFs, Word-Dokumente oder HTML werden in Text umgewandelt und in Chunks aufgeteilt. Falsche Chunk-Grenzen zerstören Kontext; testen Sie Chunk-Grösse und Overlap an repräsentativen Dokumenten.
Embedding: Jeder Chunk wird vektorisiert. Metrik: Embedding-Latenz und Upsert-Throughput. Asynchrone Pipelines verhindern Engpässe bei grossen Dokumentmengen.
Index und Storage: Vektoren werden in den Vektor-Store geschrieben. Achten Sie auf Lineage-Felder (Dokument-ID, Version, Zeitstempel), damit spätere Audits möglich sind.
Retrieval: Bei einer Nutzeranfrage wird diese ebenfalls vektorisiert und gegen den Index gesucht. Metrik: Kontext-Recall und Retrieval-Latenz. Over-retrieval (zu viele irrelevante Chunks) erhöht Kosten und Rauschen.
Re-Ranking: Ein Cross-Encoder bewertet die Kandidaten neu und wählt die präzisesten Passagen aus. Dieser Schritt ist optional, aber bei regulatorischen Use-Cases oft entscheidend.
Prompt-Konstruktion: Der Prompt-Builder fügt Systemanweisung, Kontext-Chunks und Nutzerfrage zusammen. Zu langer Kontext erhöht Tokenkosten und kann die Antwortqualität senken.
Generierung: Das LLM erzeugt die Antwort. Strukturiertes JSON mit Quellenfeldern erleichtert die Weiterverarbeitung und Auditierbarkeit.
Zitierung und Verifikation: Quellenverweise werden geprüft und in der Antwort sichtbar gemacht. Faithfulness-Metriken messen, ob die Antwort tatsächlich durch die abgerufenen Passagen gedeckt ist.

Wie wählt man das richtige Embedding-Modell und Index-Design?

Die Qualität des Retrievals steht und fällt mit drei Entscheidungen: Embedding-Modell, Indexstruktur und Chunking-Strategie.

Embedding-Typen und ihre Abwägungen

Transformer-basierte Dense-Modelle (z. B. OpenAI text-embedding-3-large, Cohere Embed, oder offene Modelle wie multilingual-e5-large) liefern hohe semantische Qualität, brauchen aber mehr Rechenzeit und Speicher. Leichtere Modelle wie all-MiniLM-L6-v2 sind schneller, verlieren aber bei domänenspezifischen Texten an Präzision. Für Schweizer Unternehmen mit mehrsprachigen Dokumenten (Deutsch, Französisch, Italienisch) sind mehrsprachige Modelle oft die bessere Wahl.

Die Wahl des Embedding-Modells beeinflusst semantische Abrufqualität und Latenz direkt: Höhere Qualität erhöht die Relevanz, treibt aber Rechenkosten und Latenz nach oben.

Dimensionen, Normalisierung und Distanzmaße

Höhere Dimensionen (z. B. 3.072 statt 1.536) verbessern die Trennschärfe, erhöhen aber Speicherbedarf und Suchlatenz. Cosinus-Ähnlichkeit ist für normalisierte Vektoren die Standardwahl; Dot-Product ist schneller, setzt aber voraus, dass Vektoren normalisiert sind. Wählen Sie das Distanzmaß konsistent mit dem Indextyp.

Indexdesign: HNSW, FAISS und Milvus

Index	Stärken	Schwächen
HNSW	Sehr schnelle ANN-Suche, gute Recall-Werte	Hoher RAM-Bedarf, langsame Upserts bei grossen Mengen
FAISS	Flexibel, gut für Batch-Workloads	Kein nativer Cluster-Betrieb, manuelles Sharding
Milvus	Produktionsreif, Replikation, Lineage-Support	Höhere Betriebskomplexität

Chunking-Strategien

Zu kleine Chunks verlieren Kontext; zu grosse Chunks erhöhen Rauschen und Tokenkosten. Overlap von 10–20 % der Chunk-Grösse reduziert Kontextverluste an Grenzen. Für strukturierte Dokumente (Verträge, Normen) lohnt sich hierarchisches Chunking: Abschnitte als übergeordnete Einheiten, Absätze als Retrieval-Einheiten.

Profi-Tipp: Messen Sie Kontext-Recall und Kontext-Precision auf einem repräsentativen Evaluationsset, bevor Sie Chunk-Parameter in der Produktion festlegen. Bauchgefühl ist hier ein schlechter Ratgeber.

Kontext-Recall: Anteil der relevanten Passagen, die tatsächlich abgerufen wurden.
Kontext-Precision: Anteil der abgerufenen Passagen, die tatsächlich relevant sind.
Retrieval-Latenz: P95-Latenz der Vektorsuche unter Last.
Upsert-Throughput: Dokumente pro Sekunde, die der Index aufnehmen kann.

Wann lohnen sich hybride Retrieval-Strategien und Reranking?

Dense Retrieval allein hat eine bekannte Schwäche: Exakte Schlüsselwörter, Produktcodes oder Eigennamen werden oft schlechter gefunden als semantisch ähnliche Formulierungen. Sparse Retrieval (BM25) ist hier stärker, verliert aber bei paraphrasierten oder konzeptuellen Anfragen.

Hybride Ansätze kombinieren BM25-Scores mit Dense-Vektoren und erhöhen so Präzision und Abdeckung gleichzeitig. Reciprocal Rank Fusion (RRF) ist eine einfache, robuste Methode, um die Ranglisten beider Systeme zu einem gemeinsamen Score zusammenzuführen.

Typische Retrieval-Strategien im Vergleich:

Dense Retrieval: Gut für semantische, konzeptuelle Anfragen. Schwächer bei exakten Begriffen.
Sparse Retrieval (BM25): Stark bei Schlüsselwörtern, Codes, Namen. Schwächer bei Paraphrasen.
Hybrid (BM25 + Dense + RRF): Beste Abdeckung für gemischte Anfragen; empfohlen für Unternehmens-Use-Cases.
Cross-Encoder Reranking: Zweite Stufe nach dem First-Pass-Retrieval. Teurer, aber deutlich präziser bei der finalen Passageauswahl.

Mehrstufige Pipelines folgen dem Muster: schnelle lexikale Vorselektion, dann dichte Vektorsuche, dann Cross-Encoder für die finale Auswahl. Der Reranker läuft nur auf den Top-N-Kandidaten des First-Pass, was die Kosten begrenzt. Trigger-Bedingungen für Reranking sind sinnvoll: Aktivieren Sie ihn nur, wenn der Retrieval-Score unter einem Schwellenwert liegt oder die Anfrage als komplex klassifiziert wird.

Was sind die echten Vorteile und Grenzen von RAG?

RAG löst drei konkrete Probleme, die reine LLM-Deployments haben: veraltetes Wissen, fehlende Quellenangaben und das Risiko, proprietäre Daten ins Modelltraining zu geben.

Aktualität ist der offensichtlichste Vorteil. Der Index lässt sich täglich oder stündlich aktualisieren, ohne das Modell anzufassen. Belegbarkeit ist für regulierte Branchen in der Schweiz oft nicht verhandelbar: Jede Antwort trägt einen Quellenlink, der auditiert werden kann. Datensicherheit ist der dritte Punkt: Firmendaten bleiben im eigenen Index und werden nicht in Modellgewichte eingebrannt.

Profi-Tipp: RAG ist kein Ersatz für Fine-Tuning, wenn das Modell domänenspezifisches Verhalten lernen soll, etwa einen bestimmten Schreibstil oder spezialisierte Reasoning-Fähigkeiten. Beide Ansätze lassen sich kombinieren.

Die Grenzen sind real. Eine mehrstufige Pipeline aus Embedding, Vektorsuche, Reranking und LLM-Aufruf summiert sich auf messbare Latenz. Wer Sub-200-ms-Antwortzeiten braucht, muss Caching und selektives Retrieval einplanen. Der Betrieb eines Vektor-Stores, einer Embedding-API und eines LLM-Endpoints erzeugt Kosten und Komplexität, die bei sehr kleinen, statischen Wissensbasen schlicht nicht gerechtfertigt sind. Für ein Unternehmen mit 50 unveränderlichen FAQ-Einträgen ist ein einfaches Prompt-Template die bessere Lösung.

Welche Konstruktionsfehler zerstören RAG-Projekte in der Praxis?

Die meisten Produktionsprobleme entstehen nicht durch falsche Modellwahl, sondern durch Fehler in Chunking, Evaluation und Betrieb.

Die häufigsten Fehler:

Falsches Chunking: Chunks, die mitten in einem Satz oder Absatz enden, zerstören den Kontext. Tabellen und Listen werden oft falsch aufgeteilt.
Over-retrieval: Zu viele Chunks im Kontext erhöhen Tokenkosten, verwässern die Antwort und können das LLM verwirren.
Fehlendes Reranking: Ohne zweite Bewertungsstufe landen irrelevante Passagen im Prompt.
Keine Evaluationsmetriken: Wer nicht misst, weiss nicht, ob das System gut oder schlecht ist. Faithfulness und Kontext-Recall sollten von Tag eins an laufen.
RAG als einmaliges Setup: Dokumente ändern sich. Ein Index ohne Upsert-Strategie veraltet still und leise.

Best-Practice-Checkliste für produktionsreife Systeme:

Evaluationsset mit einer angemessenen Anzahl repräsentativer Fragen und Referenzantworten anlegen.
Faithfulness, Kontext-Recall und Kontext-Precision als automatisierte Tests in die CI/CD-Pipeline integrieren.
Strukturierte Antworten (JSON mit Quellenfeldern) als Standardformat festlegen.
Drift-Erkennung einbauen: Wenn sich die Qualitätsmetriken verschlechtern, muss ein Alert ausgelöst werden.
Lineage-Felder (Dokument-ID, Version, Zeitstempel) in jedem Chunk-Datensatz speichern.
Caching für häufige Anfragen implementieren, um Kosten zu senken.
Rollback-Mechanismus für Index-Snapshots vorbereiten.

Wie planen Sie Latenz, Skalierung und Kosten im Produktionsbetrieb?

Ein RAG-System in der Produktion ist ein verteiltes System mit mehreren Latenzquellen. Jede Stufe addiert sich.

Komponente	Typische Latenz	Hauptkostentreiber
Embedding-API (extern)	50–200 ms	Token-Volumen, Modellgrösse
Vektorsuche (HNSW)	5–50 ms	Indexgrösse, RAM
Cross-Encoder Reranking	—	Kandidatenzahl, Modellgrösse
LLM-Generierung	500 ms	Kontext-Länge, Modell
Gesamt P95	—	Abhängig von Konfiguration

Skalierungsmuster für hohe Last: horizontale Replikation des Vektor-Indexes, Sharding nach Dokumentkategorie oder Mandant, asynchrone Embedding-Pipelines für Ingest-Spitzen. Automatisierte Ingest-Pipelines auf Basis von Dagster-Assets materialisieren Upserts zuverlässig und machen Lineage-Probleme sichtbar, bevor sie in der Produktion eskalieren.

Monitoring-Metriken, die Sie täglich beobachten sollten:

P95/P99-Latenz pro Pipeline-Stufe
Kontext-Recall und Faithfulness (automatisiert)
Kosten pro Anfrage (Embedding + LLM-Token)
Upsert-Fehlerrate und Index-Freshness
Audit-Log-Vollständigkeit für Compliance-Nachweise

Kostenoptimierung beginnt mit Caching: Häufige Anfragen, die denselben Kontext benötigen, müssen nicht jedes Mal den vollen Retrieval-Pfad durchlaufen. Selektives Retrieval, also das Überspringen des Rerankers bei einfachen Anfragen, spart weitere Ressourcen.

Was müssen Schweizer Unternehmen bei Datenschutz und Compliance beachten?

Für Schweizer Unternehmen gelten das revidierte Datenschutzgesetz (revDSG) und, bei Verarbeitung von Daten aus dem EU-Raum, die DSGVO. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) ist die zuständige Aufsichtsbehörde. RAG-Architekturen berühren Datenschutz auf mehreren Ebenen.

Compliance-Checkliste für RAG in Schweizer Unternehmen:

Datenminimierung: Nur Dokumente indexieren, die für den Use-Case tatsächlich benötigt werden. Kein „alles rein, schauen wir mal“.
Datenresidenz: Sensible personenbezogene Daten und vertrauliche Geschäftsunterlagen sollten in der Schweiz oder im EWR gespeichert werden. On-Premises oder private Cloud sind für regulierte Branchen oft Pflicht.
Verschlüsselung: Vektoren und Quelldokumente verschlüsselt speichern (AES-256 oder gleichwertig) und Übertragungen via TLS absichern.
Lineage und Versionierung: Jeder Chunk muss auf sein Quelldokument zurückführbar sein. Index-Snapshots versionieren, damit bei Audits der Zustand zu einem bestimmten Zeitpunkt rekonstruiert werden kann.
Zugriffskontrolle: Rollenbasierte Zugriffsrechte auf den Vektor-Store und die Quelldokumente. Nicht jeder Nutzer darf alle Dokumente abrufen.
Protokollierung und Prüfpfade: Jede Anfrage, jeder Retrieval-Vorgang und jede generierte Antwort sollte mit Zeitstempel und Nutzer-ID geloggt werden.
Quellenverweise in Antworten: Strukturierte Antworten mit Quellenfeldern ermöglichen es, im Streitfall nachzuweisen, auf welcher Grundlage eine Aussage gemacht wurde.
Auftragsverarbeitung: Bei Cloud-Diensten (Embedding-APIs, LLM-Endpoints) Auftragsverarbeitungsverträge nach revDSG/DSGVO abschliessen.

Für Schweizer Unternehmen ist Auditierbarkeit oft wichtiger als minimale Kostenoptimierung. Architekturentscheidungen sollten dies von Anfang an priorisieren, nicht nachträglich einbauen.

Wie wählen Sie die richtige Architektur für Ihr Schweizer Unternehmen?

Die Entscheidung zwischen On-Premises, privater Cloud und Public Cloud sowie zwischen verwalteten Diensten und Open-Source-Stacks hängt von fünf Achsen ab.

Profi-Tipp: Definieren Sie Ihr Evaluationsset, bevor Sie Architekturentscheidungen treffen. Wer nicht weiss, wie er Qualität messen will, kann keine fundierte Entscheidung zwischen Milvus und einem verwalteten Dienst treffen.

Bewertungsachsen:

Datenhaltung und Compliance: Müssen Daten die Schweiz nicht verlassen? Dann scheiden viele Public-Cloud-Optionen aus oder erfordern spezifische Regionen.
Latenz: Welche P95-Latenz ist akzeptabel? Unter 500 ms erfordert lokale Infrastruktur oder Edge-Caching.
Betriebskosten: Verwaltete Dienste (z. B. Azure AI Search, Pinecone) reduzieren Betriebsaufwand, erhöhen aber laufende Kosten. OSS-Stacks wie Milvus oder FAISS sind günstiger im Betrieb, brauchen aber Fachkompetenz.
Teamkompetenz: Fehlt internes ML-Ops-Wissen, ist ein verwalteter Dienst mit klaren SLAs oft die risikoärmere Wahl.
Time-to-MVP: Für einen ersten Proof of Concept reicht oft ein einfacher Stack aus FAISS, einem Open-Source-Embedding-Modell und einem LLM-API-Aufruf.

Checkliste für RFP und Proof of Concept:

Datenvolumen und erwartete Änderungsrate dokumentieren.
SLA-Anforderungen (Verfügbarkeit, Latenz) schriftlich festhalten.
Evaluationsset mit Testfragen und Referenzantworten erstellen.
Metriken definieren: Faithfulness, Kontext-Recall, Latenz, Kosten pro Anfrage.
Datenschutz-Folgenabschätzung nach revDSG durchführen, wenn personenbezogene Daten verarbeitet werden.

Das Swiss AI Hub-Ökosystem bietet Open-Source-Vorlagen für SharePoint-, OneDrive- und S3-Quellen, die direkt in einen Vektor-Store schreiben. Das senkt die Einstiegshürde für Schweizer Unternehmen erheblich.

Was zeigt das Zürcher KMU-Projekt über RAG in der Praxis?

Das Open-Source-RAG-Projekt des Swiss Data Science Center ist eines der konkretesten Schweizer Beispiele für produktionsnahe RAG-Architektur. Neun Schweizer KMUs haben gemeinsam eine modulare Referenzarchitektur für Compliance-Use-Cases entwickelt, konkret für die Verarbeitung heterogener regulatorischer Dokumente.

Die Pipeline folgte fünf Kernstufen: Chunking, Embedding, Storage, Retrieval und Antwortgenerierung. Zusätzlich gab es separate Tracks für Evaluation, strukturierte Antwortformate, Retrieval-Strategien und agentische Workflows. Strukturierte JSON-Antworten mit eingebetteten Quellenverweisen waren von Anfang an Pflicht, nicht nachträgliche Ergänzung.

Die wichtigsten Learnings aus dem Projekt: Evaluationsmetriken (Faithfulness, Relevanz, Kontext-Precision und Kontext-Recall) müssen von Beginn an in die Pipeline integriert sein. Hybride Retrieval-Strategien lieferten bessere Ergebnisse als Dense Retrieval allein. Die Trennung von starker und schwacher Evidenz in den Antworten verbesserte die Auditierbarkeit erheblich. Agentische Workflows, bei denen das System mehrere Retrieval-Schritte selbst plant, zeigten Potenzial für komplexe Compliance-Fragen.

Das kollaborative Format war dabei kein Zufall und zeigt am Beispiel von HVAC Pro, wie Fachdaten-Retrieval und dokumentengebundene Assistenzsysteme in der Praxis umgesetzt werden können. Mehrere KMUs gemeinsam identifizieren Governance-Anforderungen früher und entwickeln wiederverwendbare Architekturbausteine, die ein einzelnes Unternehmen allein nicht so schnell gebaut hätte.

Profi-Tipp: Nutzen Sie das Open-Source-Repo des Swiss Data Science Center als Ausgangspunkt für eigene Projekte. Die Architektur ist auf Schweizer Compliance-Anforderungen ausgelegt und spart erhebliche Entwicklungszeit.

Wie starten Sie Ihr erstes RAG-Projekt konkret?

Ein erster Proof of Concept braucht keinen perfekten Stack. Er braucht einen klar definierten Scope und ein Evaluationsset.

Datenquelle wählen: Eine einzige, gut definierte Quelle (z. B. internes Regelwerk, Produktdokumentation). Nicht mehrere Quellen gleichzeitig.
Ingest und Chunking aufbauen: Dokumente parsen, Chunk-Grösse und Overlap festlegen, Lineage-Felder definieren.
Embedding-Modell auswählen: Für deutschsprachige Dokumente ein mehrsprachiges Modell testen. Qualität auf dem Evaluationsset messen, nicht schätzen.
Einfachen Retriever einrichten: FAISS oder ein verwalteter Dienst für den PoC. Kein Reranking in der ersten Iteration.
LLM mit Quelleneinbettung verbinden: Prompt-Template mit Kontext-Chunks und Quellenfeldern im JSON-Output.
Evaluationsset anlegen: Mindestens 30–50 Testfragen mit Referenzantworten. Faithfulness und Kontext-Recall automatisiert messen.
Latenz-Budget prüfen: P95-Latenz unter Last messen. Wenn das Budget überschritten wird, Caching oder selektives Retrieval einführen.
Nutzer-Feedback-Loop einbauen: Einfaches Daumen-hoch/runter-Feedback in der UI speichern und auswerten.
Pilot mit echten Nutzern: Kleiner Nutzerkreis, kontrollierte Umgebung, Monitoring aktiv.
Governance und Skalierung: Datenschutz-Folgenabschätzung abschliessen, Zugriffskontrolle einrichten, Index-Snapshots versionieren. Erst dann skalieren.

Für die Orchestrierung von Ingest bis Upsert bieten sich Dagster-basierte Pipelines an, die Materialisierung und Lineage-Tracking automatisieren. Das reduziert Time-to-Production erheblich.

Wichtige Erkenntnisse

Eine produktionsreife RAG-Architektur steht und fällt mit drei Entscheidungen: Evaluationsmetriken von Anfang an, hybrides Retrieval für Unternehmens-Use-Cases und Compliance-by-Design für Schweizer Anforderungen.

Thema	Details
Evaluation von Anfang an	Faithfulness und Kontext-Recall früh messen verhindert teure Neuentwicklungen in der Produktion.
Hybrides Retrieval bevorzugen	BM25 plus Dense Retrieval mit Reciprocal Rank Fusion liefert bessere Abdeckung als Dense allein.
Compliance by Design	Lineage-Felder, verschlüsselte Speicherung und Quellenverweise in Antworten sind für Schweizer Unternehmen unverzichtbare Optionen.
Chunking sorgfältig testen	Chunk-Grösse und Overlap direkt auf dem Evaluationsset messen, nicht schätzen.
Outwork als Partner	Outwork begleitet RAG-Projekte von PoC bis Produktivbetrieb mit Fokus auf Auditierbarkeit und Schweizer Datenresidenz.

RAG in Schweizer Unternehmen: Was wirklich zählt

Es gibt eine Lücke zwischen dem, was RAG verspricht, und dem, was in der Praxis scheitert. Die Technologie ist ausgereift. Das Problem liegt fast immer woanders.

Schweizer Unternehmen, die RAG einführen, unterschätzen regelmässig zwei Dinge. Erstens: den Aufwand für sauberes Chunking und Datenaufbereitung. Ein Vektor-Store, der mit schlecht geparsten PDFs gefüllt ist, liefert schlechte Ergebnisse, egal wie gut das Embedding-Modell ist. Zweitens: die Notwendigkeit, Evaluation als kontinuierlichen Prozess zu verstehen, nicht als einmaligen Test vor dem Go-Live.

Was hingegen oft unterschätzt wird, ist der Wert von Auditierbarkeit als Wettbewerbsvorteil. Wer seinen Kunden oder Regulatoren zeigen kann, auf welcher Grundlage eine KI-Antwort entstanden ist, baut Vertrauen auf, das reine Genauigkeitszahlen nicht leisten. Strukturierte JSON-Antworten mit Quellenfeldern sind kein technisches Detail, sondern ein Governance-Instrument.

Für Unternehmen, die generative KI-Systeme produktiv einsetzen wollen, ist RAG der pragmatischste Einstieg: kein Modelltraining, keine Datenweitergabe an Dritte, klare Quellenverweise. Aber „pragmatisch“ bedeutet nicht „einfach“. Eine produktionsreife Pipeline braucht Monitoring, Drift-Erkennung und eine klare Upsert-Strategie. Wer das von Anfang an einplant, spart sich sechs Monate Nacharbeit.

Outwork begleitet Ihr RAG-Projekt von der Idee bis zum Betrieb

Viele Unternehmen starten mit einem guten Konzept und scheitern an der Umsetzung: falsche Chunk-Strategie, kein Evaluationsset, Compliance-Anforderungen zu spät bedacht. Outwork baut RAG-Pipelines, die von Anfang an auf Schweizer Datenresidenz, Auditierbarkeit und produktionsreife Qualität ausgelegt sind.

Das Angebot umfasst PoC- und MVP-Entwicklung, Aufbau von Datenpipelines (Ingest, Chunking, Embedding), Integration von Vektor-Stores wie Milvus oder FAISS, Monitoring-Infrastruktur und Governance-Konzepte nach revDSG. Für Teams, die interne Ressourcen ergänzen wollen, steht auch Developer Outsourcing zur Verfügung. Der nächste Schritt ist konkret: Nehmen Sie Kontakt auf für einen technischen Workshop oder einen PoC-Kickoff. Alle Leistungen von Outwork sind auf der Website dokumentiert.

Nützliche Quellen und weiterführende Lektüre

Zum Einstieg empfohlen: Das Open-Source-RAG-Projekt des Swiss Data Science Center dokumentiert eine produktionsnahe Referenzarchitektur für Schweizer KMUs mit Compliance-Fokus. Die Kombination aus Evaluation-Track, strukturierten JSON-Antworten und hybriden Retrieval-Strategien macht es zum nützlichsten Schweizer Praxisbeispiel für Enterprise-RAG.

Theorie und Grundlagen:

RAG-Glossar, Schweizer KI-Akademie — kompakte Definition mit Architekturübersicht
Was ist RAG? Databricks — praxisnahe Einführung mit Unternehmens-Fokus
RAG-Architektur, Google Cloud — modularer Ansatz und Empfehlungen für Enterprise-Use-Cases

Implementierung und Praxis:

Swiss AI Hub Pipeline (PyPI) — Dagster-basierte Pipeline für Ingest bis Upsert in Milvus
aihub-core (GitHub) — Open-Source-Vorlagen für SharePoint, OneDrive und S3
TrueFoundry: RAG-Architektur — technische Details zu Chunking, Embedding und Retrieval
Business Automatica: RAG und Vektordatenbanken — hybrides Retrieval und Reranking

Schweizer Fallstudie:

Open-Source RAG for Zurich SMEs, Swiss Data Science Center — Referenzarchitektur und Lessons Learned aus neun KMUs

Outwork-Leistungsseiten:

Softwareentwicklung und KI-Integration — technische Umsetzung von RAG-Projekten
Leistungsübersicht Outwork — vollständiges Dienstleistungsportfolio