RAG für Schweizer KMU: Setup, Eval, FADP — was Sie vorher wissen sollten

Was RAG eigentlich tut

Ein RAG-System ist kein „Chat mit Ihren Daten". Es ist eine Pipeline:

1. Chunking — Ihre Dokumente werden in semantisch sinnvolle Stücke zerlegt.
2. Embedding — jedes Stück bekommt einen Vektor, der seine Bedeutung repräsentiert.
3. Retrieval — bei einer Frage werden die relevantesten Chunks via Vektor-Ähnlichkeit gefunden.
4. Reranking — ein zweites Modell sortiert die Treffer nach Relevanz für die konkrete Frage.
5. Generation — das LLM bekommt die Frage plus die gefundenen Chunks als Kontext und antwortet mit Zitaten.

Die Versuchung ist, eine Stufe zu überspringen („wir brauchen kein Reranking, läuft auch ohne"). In der Praxis ist es genau die Reranking-Stufe, die zwischen „nett, aber halluziniert" und „verlässlich, mit nachvollziehbarer Quelle" entscheidet.

Wann RAG sich für ein KMU lohnt

Drei Kriterien:

• Volumen — Ihre Wissensbasis hat genügend Dokumente (Erfahrungswert: 100+), damit klassische Volltextsuche schon spürbar versagt. Bei 30 Dokumenten ist ein gut gepflegtes Confluence günstiger.
• Frequenz — Mitarbeitende stellen wiederkehrend dieselben Fragen. Wenn HR fünf Mal pro Woche „Wie viele Ferientage habe ich noch?" beantwortet, ist das ein RAG-Kandidat. Wenn die HR-Inbox vier Anfragen pro Monat hat, eher nicht.
• Eindeutigkeit — Ihre Dokumente sind grundsätzlich konsistent und versioniert. RAG kann sich nicht magisch zwischen zwei widersprechenden Policy-Versionen entscheiden — das müssen Sie vorher tun.

Wenn Sie zwei von drei Kriterien deutlich erfüllen, ist ein PoC sinnvoll. Wenn keines, ist die Antwort „Wiki und Glossar pflegen" oft günstiger und ehrlicher.

Setup: was wirklich gebaut werden muss

Eine produktionsreife RAG-Pipeline für ein KMU mit 200–400 Dokumenten umfasst typischerweise:

• Document-Pipeline — Anbindung an die Quellsysteme (SharePoint, Confluence, OneDrive, eigene File-Shares), inkrementelle Updates, Versionierung.
• Chunking-Strategie — nicht „1.000 Tokens pro Chunk und gut", sondern dokumenttyp-spezifisch. Eine Policy zerlegen wir anders als einen Vertrag.
• Embedding-Modell — text-embedding-3-large oder text-embedding-ada-002 über Azure OpenAI Switzerland sind die üblichen Defaults. Für DE/FR/IT funktionieren beide gut.
• Vector-Store — PostgreSQL mit pgvector, Azure AI Search oder Qdrant. Für Schweizer Datenresidenz: PostgreSQL/Qdrant on-premises oder Azure-Region Switzerland.
• LLM-Layer — Claude oder GPT-4 für die Antwortgenerierung. Beide stark in DE/FR/IT, mit leichtem Vorsprung für Claude bei Schweizer Höflichkeitsformen.
• Eval-Goldset und Monitoring — siehe nächster Abschnitt.

Eval: die drei Säulen, die KI von Bauchgefühl trennen

Eine RAG-Pipeline ohne Evaluation ist ein Bauchgefühl-Projekt. Mit Evaluation wird daraus ein Engineering-Projekt mit überprüfbarem Output. Standard sind drei Metriken:

Konkret: Wir bauen ein Goldset von 50–200 Fragen mit erwarteten Antworten. Bei jedem Index-Update, Modellwechsel oder Prompt-Anpassung läuft das Goldset durch — Frameworks wie RAGAS oder TruLens automatisieren das. Fällt Faithfulness unter einen Schwellenwert, ist das ein Pre-Production-Blocker, kein „kann man später optimieren".

FADP, EU AI Act und Datenresidenz

Drei Punkte, die wir bei jedem Schweizer RAG-Projekt explizit klären:

• Datenresidenz — Azure OpenAI Switzerland (Region North/West) hält Daten in der Schweiz. Microsoft trainiert nicht auf Ihren Inhalten (Default off, vertraglich zugesichert). Logs werden in begrenztem Zeitraum zur Missbrauchserkennung aufbewahrt, danach gelöscht. Für noch strengere Anforderungen: On-Premise-Variante mit Open-Source-Modellen (Llama, Qwen, Mistral) — mit Performance-Tradeoff, den wir offen kommunizieren.
• FADP-konforme Aufbewahrung — User-Queries und Agent-Antworten werden so geloggt, dass Auskunfts- und Löschungsersuchen erfüllbar sind. Sensible Themen (Personalfragen, Gesundheit, Konflikte) bekommen oft eigene Aufbewahrungs- und Eskalations-Regeln.
• EU AI Act — für ein internes HR-/IT-RAG fällt der Use Case meist unter „minimal risk", aber je nach Setup auch unter „limited" oder „high risk" mit Transparenz- und Dokumentationspflichten. Architektur-Reviews planen das von Anfang an mit ein.

Kosten-Realität

Konkrete Bandbreiten besprechen wir individuell, weil sie stark vom Dokumenten-Volumen, der Modell-Wahl, der gewünschten Eval-Tiefe und der Compliance-Stufe abhängen. Drei Treiber-Klassen:

• Setup-PoC (4–8 Wochen) — Eval-Goldset, Chunking-Pipeline, erstes Modell-Setup, Topic-Klassifikation, Integrations-Anbindung.
• Lauf-Kosten — Token-Verbrauch (skaliert mit Nutzungsfrequenz), Hosting und Vector-Store, plus interner Pflege-Aufwand (typischerweise 0.1–0.2 FTE für Dokumenten-Updates und quartalsweise Eval-Reviews).
• Tieferer Compliance-Layer — On-Premise-Stack, eigene Monitoring-Tools, externe Audits, wenn die Branche es verlangt.

Für ein KMU mit 50–150 Mitarbeitenden bewegen sich monatliche Lauf-Kosten in der Regel deutlich unter den Kosten einer einzelnen Vollzeit-Stelle. ROI lässt sich allerdings nicht vor dem PoC sauber berechnen — Sie testen, ob die Nutzungsfrequenz und der Zeitgewinn die Kosten rechtfertigen.

Wann RAG nicht die richtige Antwort ist

Drei Anti-Pattern, die wir regelmässig sehen:

Fazit

Ein gut gebautes RAG ist für viele Schweizer KMU der ehrlichste erste KI-Use-Case: konkret, messbar, mit nachvollziehbaren Quellen, FADP-konform. Ein schlecht gebautes RAG ist eine Demo, die nie produktiv geht. Die Unterschiede liegen in Setup-Disziplin, Eval-Konsequenz und einer ehrlichen Bewertung der Compliance-Anforderungen.

Mehr Details zur konkreten Anwendung: Use Case 06 — RAG über interne Wissensbasis. Verwandte Anwendungen: Compliance-/Vertragsreview-Agent für die kuratierte Variante mit Regelwerk. Häufige Fragen zur Modellwahl, Datenresidenz und Eval auf der FAQ-Seite.