> bits_and_friends _

$ cat /blog/2026-05-27-rag-einfach-erklaert.de.md

RAG einfach erklärt: Unternehmenswissen mit KI nutzbar machen

[de] [en]

„Wo liegt eigentlich der Test-Bericht von 2018?” — diese Frage gibt es in jedem Unternehmen. Die Antwort kennt selten jemand, immer dieselben drei Senior-Kolleg:innen, deren Urlaub gefährlich nah ist. Genau hier setzt RAG an: Retrieval Augmented Generation. Dieser Artikel erklärt, was RAG ist, was es nicht ist, und wann es sich für Sie lohnt.

Was RAG bedeutet

RAG steht für Retrieval Augmented Generation. In drei Schritten:

  1. Retrieval: Der Nutzer fragt etwas. Das System sucht in Ihren Dokumenten nach passenden Stellen — semantisch, nicht nur per Volltextsuche.
  2. Augmented: Die gefundenen Textstellen werden in den Prompt eines Sprachmodells eingefügt.
  3. Generation: Das Sprachmodell formuliert eine Antwort, die sich auf diese Textstellen stützt.

Resultat: eine Antwort, die nicht aus dem Modell-Gedächtnis kommt („wie es klingen muss”), sondern aus Ihren tatsächlichen Dokumenten („wie es bei Ihnen wirklich steht”).

Was RAG NICHT ist

Damit Missverständnisse gar nicht erst entstehen:

  • RAG ist keine Volltextsuche. Eine Volltextsuche findet das Wort „Skonto” in Dokument 3. RAG findet auch „Frühzahler-Rabatt” in Dokument 17, weil semantisch ähnlich.
  • RAG ist kein Modell-Training. Ihre Dokumente fließen nicht in die Modell-Gewichte. Sie bleiben bei Ihnen; bei jeder Anfrage werden sie frisch gelesen.
  • RAG ist kein magisches Wissen. Was in keinem Dokument steht, findet RAG auch nicht. Lücken in Ihrer Dokumentation werden durch RAG sichtbar — nicht behoben.

Wann RAG sich lohnt

Konkrete Szenarien, in denen unsere Kunden RAG produktiv nutzen:

Service-Desk-Assistent. „Wie behebe ich Problem X bei Kunde Y?” — der Agent durchsucht Tickets, Runbooks, Wissensartikel, schlägt die historisch passende Lösung vor. Die Service-Desk-Auflösung wird konsistenter.

Onboarding-Begleiter. Neue Mitarbeitende fragen „Wie funktioniert unser Urlaubsantragsprozess?” oder „Welche Tools brauche ich für meine Rolle?” — der Agent zieht aus Onboarding-Doku, HR-Wiki, internen Anleitungen die passende Antwort.

Vertriebs-Vorbereitung. „Was haben wir bei Kunde Z zuletzt geliefert?” — der Agent durchsucht CRM-Notizen, Angebote, alte Lieferscheine, generiert eine Zusammenfassung für das nächste Gespräch.

Compliance-Recherche. „Welche NIS-2-Anforderungen gelten für unsere Kategorie?” — der Agent zieht aus Ihrer internen Compliance-Doku + öffentlichen Quellen die relevanten Passagen, mit Verweis auf Originalstellen.

Was Sie technisch dafür brauchen

  • Quellen mit lesbaren APIs: Confluence, SharePoint, Nextcloud, Filesystem, E-Mail-Postfächer, Ticket-Histories — alle haben Schnittstellen.
  • Eine Indexierungs-Pipeline: Dokumente werden gechunkt (in ~500-Token-Stücke), per Embedding-Modell in Vektoren übersetzt, in einer Vektor-Datenbank gespeichert (pgvector, Qdrant, Weaviate, Chroma).
  • Hybrid-Search: Beste Ergebnisse kommen aus der Kombination von BM25 (Volltext) + Vector-Search + Re-Ranking. Wir setzen das standardmäßig auf, weil Vector allein häufig zu viel verpasst.
  • Ein Sprachmodell für die Antwort-Synthese: Lokal (Gemma, Llama, Mistral via vLLM oder Ollama) oder API (OpenAI, Anthropic), je nach Datenklasse.

Die drei harten Punkte: Zugriff, Versionen, Halluzination

Zugriffsmodell. Der Agent muss respektieren, was die fragende Person sehen darf. Wer keinen Zugriff auf das HR-Wiki hat, bekommt auch keine RAG-Antwort aus dem HR-Wiki. Wir implementieren ACL-Respekt direkt in der Retrieval-Phase.

Versions-Awareness. Wenn Dokument X im Jahr 2018 sagt „Wir nutzen Tool A” und Dokument Y im Jahr 2024 „Wir nutzen Tool B”, muss der Agent das jüngere bevorzugen oder beide markieren. Versions-Awareness durch Metadaten + Recency-Scoring im Re-Ranking.

Halluzinations-Schranken. Der Agent muss jede Aussage mit einer Quelle belegen. Findet er keine, sagt er das (statt zu erfinden). Confidence-Schwellen mit Antwort-Verweigerung sind Pflicht.

Wo Sie pragmatisch starten

Mit dem Use-Case, in dem Daten reichlich vorhanden und Datenklasse niedrig ist. Service-Desk ist meist der beste Einstieg: viele Tickets, viele Lösungen in der Historie, klar dokumentierte Eskalationspfade. Onboarding ist Zweitwahl: weniger Volumen, dafür hoher Wert pro Anfrage.

Plattform-Empfehlung von uns: pgvector wenn Sie schon PostgreSQL haben (eine Komponente weniger), Qdrant wenn Sie skalieren wollen.

Nächste Schritte

Wenn Sie wissen wollen, ob RAG bei Ihnen passt, besprechen wir das gerne. Schildern Sie uns, welche Quellen Sie haben und welche Fragen Ihr Team täglich mehrfach stellt.

KI-Readiness-Check starten

Detailseite RAG & Unternehmenswissen