Publiziert: Zuletzt aktualisiert:

GenAI und RAG

RAG erdet das Sprachmodell in belegbarem Firmenwissen

Generative KI entfaltet im Unternehmen erst dann ihren vollen Wert, wenn sie Zugriff auf internes Wissen hat. Retrieval-Augmented Generation (RAG) ist die Architektur, die ein Sprachmodell mit firmenspezifischen Dokumenten verbindet, ohne dass diese zum Training des Modells verwendet werden. Das Muster allein garantiert keine Datenresidenz; eine souveräne RAG-Bereitstellung hält die Dokumente in der Schweiz, wenn jede Komponente (Embedding-Modell, Vektordatenbank, LLM-Aufrufe, Logs, Telemetrie, Backups, Support-Zugriff) entsprechend eingeschränkt ist.

Das Ergebnis sind präzise Antworten auf Basis aktueller Fakten, mit Quellenangabe und unter Einhaltung von Datenschutz und Geschäftsgeheimnissen.

Was RAG ist, und warum jetzt

Ein Sprachmodell formuliert sehr eloquent, weiss aber nur das, was beim Training in es hineingeflossen ist. Das interne Wissen einer Organisation (Verträge, Wikis, Code, das Handbuch von letzter Woche) ist da nicht enthalten. RAG gibt diesem Sprecher ein Nachschlagewerk: Vor jeder Antwort schlägt das System in den eigenen Dokumenten nach und reicht die passenden Stellen mit. Das Modell formuliert, die Fakten kommen aus der eigenen Quelle.

Die naheliegende Gegenfrage lautet: Braucht man das noch, wo Modelle inzwischen Millionen von Tokens Kontext verarbeiten? Die Antwort aus der Praxis ist klar, ja. RAG bleibt die zuverlässigste Technik, um ein Modell mit aktuellem, belegbarem Firmenwissen zu erden, unabhängig von Modellgrösse und Kontextfenster. Ein grosses Kontextfenster ersetzt weder die Aktualität der Daten noch die Nachvollziehbarkeit der Antwort.

Die Alternative wäre, ein Modell auf den eigenen Daten nachzutrainieren (Fine-Tuning). Für dynamisches Firmenwissen ist das der falsche Hebel: zu langsam und zu teuer für Inhalte, die sich täglich ändern, und ohne Quellenangabe. RAG aktualisiert sich, indem ein Dokument neu indexiert wird, oft deutlich schneller als ein erneutes Fine-Tuning, und jede Aussage bleibt auf das Originaldokument zurückführbar.

Die RAG-Pipeline: ingest, retrieve, augment, generate

RAG besteht aus zwei Phasen. Offline wird das Wissen aufbereitet (Ingest), online wird eine Frage beantwortet (Query). Beides läuft innerhalb derselben souveränen Infrastruktur ab. Die Ingest-Seite ist letztlich gelebte Datenarchitektur; wie diese Pipeline sauber gebaut wird, entscheidet über jede spätere Antwort.

flowchart TB
  subgraph SOV["Souveräne Infrastruktur (CH)"]
    direction TB
    subgraph ING["Offline: Ingest"]
      direction TB
      D["Dokumente:<br/>PDF, Wiki, Code"] --> C["Chunking"]
      C --> E["Embeddings"]
      E --> V[("Vektor-DB:<br/>pgvector")]
    end
    subgraph QRY["Online: Query"]
      direction TB
      Q["Nutzerfrage"] --> R["Retrieve:<br/>semantisch + BM25"]
      R --> A["Augment:<br/>Fakten + Frage"]
      A --> G["LLM:<br/>Open-Weights"]
      G --> O["Antwort<br/>mit Quellen"]
    end
    V -.-> R
  end

Das Diagramm zeigt den Kern: Offline werden Dokumente in Stücke (Chunks) zerlegt, in Vektoren (Embeddings) umgewandelt und in einer Vektordatenbank abgelegt. Online sucht das System bei einer Frage die passenden Stücke, reicht sie dem Sprachmodell als Kontext mit und lässt die Antwort daraus formulieren, alles innerhalb der Schweizer Grenze (gestrichelt: die Datenbank speist die Suche, ohne die Leserichtung zu brechen).

Im Detail:

  • Ingest. Dokumente werden in semantisch sinnvolle Abschnitte zerlegt (Chunking), in Embeddings umgewandelt und in einer Vektordatenbank gespeichert. Die Qualität dieses Schritts entscheidet über alles, was danach kommt: Wer hier an Sektions- und Tabellengrenzen schneidet statt blind nach Zeichenzahl, verbessert die spätere Trefferqualität und macht die Herkunft jeder Antwort nachvollziehbar. Welche Vektordatenbank dahinter sitzt, vertieft das Thema Moderne Datenbanken.
  • Retrieve. Zur Frage werden die semantisch passendsten Abschnitte gesucht. Die reine Bedeutungssuche hat eine Schwäche: Exakte Begriffe (Produktnamen, Fehlercodes, interne Kürzel) gehen manchmal unter. Eine zusätzliche, schlüsselwortbasierte Suche (BM25) fängt genau diese Fälle ab; die Kombination aus beiden (Hybrid-Search) liefert messbar bessere Treffer.
  • Augment. Die gefundenen Fakten werden zusammen mit der Frage in einen Prompt verpackt.
  • Generate. Das Modell wird angewiesen, seine Antwort in den mitgelieferten Fakten zu verankern, und zitiert sie. Es kombiniert dabei den abgerufenen Kontext mit seinem eigenen Modellwissen; RAG senkt das Halluzinationsrisiko deutlich, garantiert aber keine halluzinationsfreie Ausgabe. Genau die Quellenangabe macht den Unterschied: Für eine verankerte Aussage lässt sich nachprüfen, auf welcher Seite welches Dokuments sie steht. Das schafft Vertrauen und macht Abweichungen überprüfbar. Darum gehört eine Evaluation, die die Verankerung misst, von Anfang an dazu.

Datenresidenz als Architektur-Eigenschaft

Souveränität ist bei RAG keine nachträgliche Option, sondern eine Architektur-Entscheidung. Sie wird im Diagramm durch die umschliessende Box getragen: Vektordatenbank und Sprachmodell laufen innerhalb der Schweizer Infrastruktur. Wer regulatorisch festhalten will, warum das zählt, findet den Rahmen im revidierten Datenschutzgesetz (revDSG/nFADP) und in der Daten-Compliance des Themas Data Governance.

Konkret bedeutet das eine lokale Vektordatenbank (pgvector oder Weaviate) auf eigener oder Schweizer Cloud-Infrastruktur, kombiniert mit einem Open-Weights-Modell aus der Landschaft der Sprachmodelle (etwa aus der Llama- oder Mistral-Familie), das ohne Datenabfluss betrieben wird, oder, wo eine externe Schnittstelle nötig ist, mit vertraglichem Trainings-Opt-out. Beide Wege teilen dasselbe Prinzip: Sensible Dokumente verlassen die Schweiz nicht und werden nicht zum Training fremder Modelle verwendet.

Das ist der Punkt, an dem sich ein RAG-Pilot von "Daten in eine US-Cloud kippen" unterscheidet. Die belegbare Antwort und die kontrollierte Datenresidenz sind hier dieselbe Architektur, nicht zwei getrennte Anforderungen. Wie le dot das in der Praxis umsetzt, steht auf der Lösungsseite KI-Werkbank; dieser Primer erklärt das Konzept, die Lösungsseite zeigt die Umsetzung. Steht die Wahl eines CRM- oder ERP-Systems an, strukturiert die Unabhängige Software-Auswahl diesen Entscheid neutral und herstellerunabhängig.

Wo RAG bricht (Failure Modes)

Halluzination ist nur der bekannteste Fehlermodus, und in einem sauber gebauten RAG-System wird sie unwahrscheinlicher, weil die Antwort an mitgelieferte Fakten gebunden ist. Die teureren Fehler liegen woanders, und das Wichtigste vorweg: Ein falsches Ergebnis in RAG ist oft kein blosses statistisches Rauschen, sondern ein Fehler mit konkreter Ursache, nicht immer auf eine einzige Stelle reduzierbar, aber meist nachvollziehbar. Man kann die Kette rückwärts verfolgen und die kaputte Stelle finden.

  • Veralteter Index (Stale Index). Die Quelle hat sich geändert, der Index nicht, das System antwortet überzeugend mit gestern. Ein additiver, nur-ergänzender Crawl ohne Abgleich superseder Inhalte ist hier die häufigste Falle.
  • Schlechtes Retrieval (Bad Retrieval). Der falsche oder ein fehlender Abschnitt wird geholt, die Antwort wird falsch. Das ist ein Retrieval-Bug, kein Modellproblem.
  • Brüchiges Chunking / Parser-Fehler. Der teuerste Irrtum: Teams optimieren monatelang am Modell, an Embeddings und Rerankern, und der Bug sass die ganze Zeit im Parser, der das Dokument falsch zerlegt hat.
  • Stiller Fehlschlag. Der gefährlichste Modus: Klassisches RAG liefert auch dann eine Antwort, wenn das Retrieval versagt hat. Der Fehler ist nicht sichtbar, die Antwort liest sich plausibel. Darum gehört eine ehrliche Evaluation (welche Quelle stützte welche Aussage, hätte das System ablehnen sollen) von Anfang an dazu.

Die Werkzeug-Landschaft

Dieser Abschnitt altert schneller als der Rest der Seite, er ist bewusst eine Momentaufnahme, kein Versprechen auf bestimmte Versionen.

  • Frameworks. Etablierte Baukästen wie LangChain und LlamaIndex sowie integrierte Open-Source-Engines (zum Beispiel RAGFlow) decken den Pipeline-Aufbau ab. Eine breitere Übersicht über das aktuelle Feld liefern Sammlungen wie das LLM-Engineer-Toolkit.
  • Vektordatenbanken. Das Spektrum reicht von serverseitig (pgvector als Postgres-Erweiterung, Weaviate) bis zu eingebetteten, "SQLite-artigen" Engines wie Zvec, die On-Device- und Edge-RAG ohne separaten Dienst ermöglichen. Welche passt, hängt von Betriebsmodell und Datenmenge ab, nicht von der Popularität.
  • Evaluation. Produktionsreifes RAG braucht eine eigene Eval-Schicht: nicht ML-Metriken über Aggregate, sondern die Frage, ob die richtige Quelle die richtige Aussage gestützt hat, pro Frage, nachvollziehbar.

Ein Hinweis zur Einordnung: RAG sieht aus wie Machine Learning, ist es aber nicht. Das Embedding-Modell ist zwar ein Deep-Learning-Modell, aber es wird nicht trainiert, sondern konsumiert. Das System drumherum verbessert man durch besseres Indexieren, Parsen und Retrieven, durch Engineering, nicht durch Training. Wer das verwechselt, greift zum falschen Werkzeugkasten.

Wann RAG passt, und wann nicht

RAG passt, wenn aktuelles, belegbares Firmenwissen gebraucht wird und Compliance- oder Datenschutz-Druck besteht, also genau dort, wo Antworten nachvollziehbar und Daten residenzgebunden sein müssen. Steht zusätzlich der regulatorische Umgang mit KI selbst im Raum, ordnet das Thema EU AI Act die Pflichten ein. Ein abgegrenztes Erstprojekt der KI-Werkbank prüft, ob dieses Muster im konkreten Bestand hält.

Weniger nötig ist RAG bei statischem Allgemeinwissen, das das Modell ohnehin kennt, oder wenn ein einziger Lookup genügt und gar kein grosser Wissensbestand durchsucht werden muss.

Als nächste Stufe zeichnet sich agentisches RAG ab: Statt einer linearen Pipeline (einmal suchen, dann antworten) wird das Retrieve zu einer Schleife, suchen, prüfen, bei schwachem Ergebnis erneut suchen oder Werkzeuge aufrufen. Das erhöht die Anpassungsfähigkeit, kostet aber Vorhersagbarkeit und macht das Debugging anspruchsvoller. Für den Einstieg bleibt die klassische Pipeline der richtige, gut beherrschbare Ausgangspunkt.

Referenzen

Laufend gepflegte Werkzeuge und Plattformen:

Verwandte Themen