Mitarbeitende chatten mit HR-Handbuch, IT-Policies und Vertragsmustern — Antworten mit Quellenangabe, sensible Themen sauber eskaliert.
Kurz gesagt: Mitarbeitende chatten mit HR-Handbuch, IT-Policies, Vertragsmustern und Q&A aus dem Confluence. Antworten kommen mit Quellenangabe. Stack: Azure OpenAI Switzerland (Daten bleiben in CH-Region), Embeddings und Retrieval, Reranking, kontinuierliche Eval auf einem Goldset. Setup als PoC dauert vier bis acht Wochen, danach läuft die Pflege durch ein internes RAG-Team oder durch uns. Anti-Hype: kein „AI-Strategie-Reset", sondern eine konkrete Funktion, die ein konkretes Problem löst — interne Wissenssuche, die tatsächlich funktioniert.
Wissen ist in PDFs, SharePoint, Confluence und Outlook-Mails verteilt. Mitarbeitende suchen länger als sie arbeiten — und finden oft veraltete Versionen. Die klassische Volltext-Suche scheitert an einer simplen Sache: Sie findet das Wort, aber nicht die Antwort. Wer „Ferien" sucht, bekommt 47 Treffer; die eigentliche Regelung steht in einem Abschnitt, in dem das Wort gar nicht vorkommt. Wikis werden nicht gepflegt, weil Pflege niemandem zugewiesen ist — und sobald ein Wiki einmal als veraltet gilt, schaut niemand mehr rein.
Das Ergebnis sieht in jedem KMU gleich aus: HR und IT bekommen dieselben fünf bis zehn Fragen pro Woche — Ferienanspruch, Spesenrichtlinie, VPN-Zugang, Onboarding-Checkliste, Krankmeldung — weil die Antworten zwar in den Dokumenten stehen, aber nicht auffindbar sind. Die Folge sind unterbrochene Arbeit auf beiden Seiten, Wissensinseln und ein Onboarding, das immer länger dauert. Eine RAG-Lösung löst nicht „alles", aber genau diesen Engpass: konkrete Frage in den Chat, konkrete Antwort mit Quelle.
Die Pipeline ist konzeptionell einfach, in der Pflege aber anspruchsvoll. Dokumente aus den verschiedenen Quellen (SharePoint, Confluence, Fileshare) werden chunkweise aufbereitet — typisch 300 bis 800 Tokens pro Chunk, mit Überlapp, damit Kontext nicht an einer Grenze abreisst. Jeder Chunk wird in einen Embedding-Vektor übersetzt und in einem Vector-Store abgelegt (Azure AI Search, pgvector oder ähnlich). Eine Nutzer-Frage durchläuft denselben Embedding-Schritt, die Top-K relevanten Chunks werden semantisch abgerufen, ein Reranker (kleines Cross-Encoder-Modell) sortiert nach echter Relevanz, und der LLM bekommt die Top-N Chunks als Kontext plus die Frage. Die Antwort wird mit Quellenlinks und Confidence-Hinweis ausgeliefert.
Modellseitig läuft das Ganze auf Azure OpenAI Switzerland — die Daten bleiben in der CH-Region, Microsoft macht kein Training auf Ihren Daten. Für besonders strenge Compliance gibt es eine On-Premise-Variante mit Open-Source-Modellen (Llama, Qwen) auf Ihrer Hardware, mit Performance-Tradeoff. Guardrails: Topic-Klassifikation vor der LLM-Antwort (sensible Themen werden eskaliert, dazu unten mehr), Cost-Caps pro Nutzer und Tag, Confidence-Schwellwert (unter dem Schwellwert sagt das System „weiss ich nicht" statt zu raten), und ein laufendes Eval-Goldset.
Wichtig: Das Setup ist nur die Hälfte der Arbeit. Eine RAG ohne kontinuierliche Eval verfällt — jede Dokumenten-Änderung, jedes Modell-Update, jede neue Chunking-Strategie kann die Qualität spürbar verändern. Wer das nicht messen kann, merkt nicht, wenn das System schlechter wird, bis Nutzer aufhören zu fragen. Genau hier sitzt die Engineering-Disziplin: ein Goldset mit 50 bis 100 Fragen, das bei jedem Index- oder Modell-Wechsel automatisiert durchläuft.
Ein Schweizer KMU mit rund 80 Mitarbeitenden — Komposit, kein realer Klient — hat über die Jahre 400 HR-, IT- und Vertrags-Dokumente angesammelt. Mischung aus Markdown, PDF und Word, primär in Deutsch mit einigen englischen Tech-Policies. Vor dem RAG-Rollout: HR-Inbox mit 15 bis 20 Standardfragen pro Woche, dazu eine IT-Inbox mit ähnlichem Volumen. Die Antworten existieren — irgendwo. Nach dem Rollout, in einer typischen Szenario-Annahme: rund 70 % der Standardfragen werden direkt von der RAG vorab beantwortet, mit Quellenlink zum Originaldokument. HR und IT sehen nur noch die echten Spezialfälle — die, bei denen Erfahrung und Kontext zählen. Wichtig: die 70 % sind eine illustrative Szenario-Zahl, nicht eine gelieferte Benchmark; das tatsächliche Verhältnis hängt von Dokumentenqualität, Frage-Verteilung und kontinuierlicher Pflege ab.
Typischer Effekt: Standardfragen werden in Sekunden mit Quellenangabe beantwortet, das HR- und IT-Inbox-Volumen sinkt spürbar, und Mitarbeitende gewöhnen sich daran, zuerst zu fragen statt zu suchen. Wichtig ist aber die zweite Hälfte der Geschichte: das Setup ist der Anfang, nicht das Ende. Kontinuierliche Eval — Faithfulness, Context Precision, Answer Relevance auf einem 50-100-Fragen-Goldset — hält die Qualität stabil, sonst verfällt das System mit jeder Dokumenten-Änderung. Ohne diese Disziplin sinkt die Trefferquote unbemerkt, Nutzer hören auf zu fragen, das Projekt gilt intern als „naja, hat halt nicht funktioniert". Mit dieser Disziplin bleibt die RAG ein Werkzeug, das tatsächlich genutzt wird. Direktional ist die Wirkung: weniger Routine-Tickets, schnellere Onboarding-Phase, geringere Wissensinsel-Bildung — keine veröffentlichte Benchmark, aber ein wiederkehrendes Muster aus realen RAG-Projekten.
Drei Metriken sind Standard: Faithfulness (gibt die Antwort wirklich nur wieder, was in den Quellen steht — oder halluziniert sie?), Context Precision (sind die abgerufenen Chunks tatsächlich relevant für die Frage?), Answer Relevance (beantwortet die Antwort die gestellte Frage, oder weicht sie aus?). Konkret läuft das so: ein 50- bis 100-Fragen-Goldset wird einmal kuratiert und gepflegt, jede Frage mit einer kanonischen Antwort und den korrekten Quell-Chunks markiert. Automatisiertes Scoring per RAGAS oder einem ähnlichen Framework misst pro Metrik. Bei jedem Index-Update, jedem Modell-Wechsel und jeder Chunking-Änderung läuft der Goldset-Run — fällt Faithfulness unter den Schwellwert, ist das ein Pre-Production-Blocker. Ohne dieses Goldset fliegt die RAG blind.
Standard-Setup: Azure OpenAI Switzerland (Region North/West). Embeddings und Vector-Store liegen in derselben Region, die Daten verlassen die Schweiz nicht. Wichtig zu wissen: Azure OpenAI macht kein Training auf Ihren Daten — Opt-In ist Default-off, vertraglich von Microsoft zugesichert. Logs werden 30 Tage zur Abuse-Monitoring aufbewahrt und danach gelöscht. Wer noch strengere Anforderungen hat (etwa bei besonders sensiblen Vertragsdaten oder Branchen-Compliance), kann auf eine On-Premise-Variante umschwenken: Open-Source-Modelle wie Llama oder Qwen auf Ihrer eigenen Hardware, mit Performance-Tradeoff bei Antwortqualität und Latenz. Welche Variante passt, hängt vom Schutzbedarf — das klären wir vor dem PoC.
Eine Topic-Klassifikation läuft vor der LLM-Antwort. Definierte sensible Themen — Kündigung, Krankheit, Konflikt am Arbeitsplatz, Gehaltsfragen — lösen einen Eskalations-Pfad aus: keine RAG-Antwort, sondern eine direkte Weiterleitung an HR, mit kontextuellem Briefing („Person X hat eine Frage zu Y, hier der bisherige Verlauf"). Begründung: bei sensiblen Themen ist richtige Beratung wichtiger als schnelle Auskunft, und HR muss wissen, dass die Frage gestellt wurde — nicht nur in einem Chat-Log versinken. Klingt offensichtlich, wird in der Praxis trotzdem oft vergessen. Welche Themen als sensibel gelten, definieren wir gemeinsam mit HR vor dem Rollout.
Zwei Kostenblöcke. Setup-PoC mit 200 bis 400 Dokumenten umfasst Eval-Goldset, Chunking-Pipeline, erstes Modell-Setup, Topic-Klassifikation und vier bis acht Wochen Lieferung — die Aufwand-Bandbreite hängt vom Dokumenten-Volumen, der Format-Vielfalt (PDF/Word/HTML/Konfluenz-Exports) und der gewünschten Eval-Tiefe ab. Lauf-Kosten setzen sich aus Azure-OpenAI-Token-Kosten (skalieren mit Nutzungsfrequenz), Hosting und Vector-Store sowie interner Pflege-Zeit zusammen (typischerweise 0.1 bis 0.2 FTE für Dokumenten-Updates und quartalsweise Eval-Reviews). Für ein KMU mit 50 bis 150 Mitarbeitenden bewegen sich monatliche Lauf-Kosten in der Regel deutlich unter den Kosten einer einzelnen Vollzeit-Stelle. Hinweis: ROI lässt sich nicht vor dem PoC sauber berechnen — Sie testen, ob die Nutzungsfrequenz und der Zeitgewinn die Kosten rechtfertigen. Konkrete Zahlen besprechen wir individuell anhand Ihres Dokumenten-Volumens und Nutzer-Setups; kein PoC, keine ehrliche Aussage.
Dieser Use Case sitzt in der Praktik KI-Engineering und greift in mehrere benachbarte Wissens- und Dokumenten-Use-Cases.
Praktik: LLM-Anwendungen in Produktion — RAG-Architekturen, Document Intelligence, Evaluation, Guardrails, Plattformwahl.
Strukturierte Daten aus PDFs, Rechnungen und Verträgen ziehen — mit Validierung, Confidence und Eskalation.
Agentisches Review von Verträgen und Compliance-Dokumenten gegen interne Policies — mit nachvollziehbarer Begründung.
Kundensupport in DE, EN, FR, IT — über dieselbe Wissensbasis, mit Quellenangabe und Eskalation an Tier-2.
RAG lohnt sich, wenn die Wissensbasis substanziell ist (über 200 Dokumente) und die Suchfrequenz spürbar. Bei unter 50 Dokumenten und seltener Nutzung ist ein gepflegtes Wiki plus Glossar oft günstiger und ehrlicher. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir, ob Ihr Wissensbestand und Ihre Nutzung den Aufwand rechtfertigen.
Discovery-Call anfragen