Was ist RAG? So arbeitet KI mit Ihren Firmendokumenten

Was ist RAG?

RAG (Retrieval Augmented Generation) ist ein Verfahren, bei dem ein KI Modell zuerst passende Abschnitte in den eigenen Dokumenten Ihres Unternehmens sucht und erst danach antwortet. Das Modell verlässt sich also nicht allein auf sein Gedächtnis. Es stützt sich auf Quellen, die man ihm vorlegt, deshalb bleiben Antworten aktuell, firmenspezifisch und nachvollziehbar.

Die Idee ist einfach. Denken Sie zum Beispiel an eine gute Mitarbeiterin: Kommt eine Frage, öffnet sie zuerst die Akte und antwortet dann. RAG gibt einem Sprachmodell genau diese Gewohnheit.

Die Forschung dahinter beschreibt die Verbindung aus dem gelernten Wissen eines Modells und einer externen Wissensquelle. Das Originalpapier finden Sie im arXiv Beitrag von Lewis und Kollegen.

In diesem Ratgeber erklären wir, wie RAG arbeitet und worin der Unterschied zu Fine Tuning liegt. Außerdem behandeln wir Datenvorbereitung, Berechtigungen, Bewertung, typische Fehler und den Datenschutz. Wir sind Talha Aslan und Team und betrachten das Thema aus der Praxis von Software und Marketing.

Warum kennt ein Sprachmodell Ihre Firmendokumente nicht?

Ein großes Sprachmodell lernt aus allgemeinen Texten, die es im Training gesehen hat. Ihr internes Handbuch, Ihre Preisliste oder Ihre Vertragsvorlage gehört nicht dazu. Deshalb gibt das Modell bei einer firmenspezifischen Frage entweder zu, dass es nichts weiß, oder es erfindet eine plausible Antwort.

Diese Erfindung nennen wir Halluzination. Denn das Modell will flüssigen Text schreiben, es prüft keine Fakten. Zudem friert sein Wissen zum Zeitpunkt des Trainings ein. Eine Rückgabe Regel, die sich gestern geändert hat, kennt es nicht.

Das Modell selbst erklären wir hier nicht noch einmal, weil es dazu schon einen eigenen Beitrag gibt. Die Grundlagen finden Sie in unserem Ratgeber zu großen Sprachmodellen (LLM).

In Unternehmen sehen wir drei wiederkehrende Probleme:

• Wissen veraltet. Preise, Abläufe und Produktdetails ändern sich ständig, das Modell kennt aber nur den alten Stand.
• Wissen ist vertraulich. Interne Dokumente in ein öffentliches Modell zu laden, ist oft nicht angemessen.
• Es fehlt die Quelle. Wenn das Modell nicht zeigt, woher eine Antwort stammt, vertraut Ihr Team ihr nicht.

RAG löst alle drei Probleme mit einem Zug. Statt Wissen ins Modell zu packen, legt es dem Modell im Moment der Frage den passenden Text vor.

Was ist RAG und welche Probleme löst es im Unternehmen?

Aus Sicht des Unternehmens lautet die Antwort auf die Frage "was ist RAG": eine Schicht, die Ihr Dokumentenarchiv abfragbar macht. Mitarbeitende oder Kunden stellen eine Frage in normaler Sprache. Das System findet die passenden Absätze, und das Modell schreibt daraus die Antwort.

Die Vorteile lassen sich in vier Gruppen fassen:

• Aktualität: Sobald Sie ein Dokument ändern, ändert sich auch die Antwort. Ein neues Training brauchen Sie nicht.
• Firmenwissen: Abläufe, Kataloge, technische Spezifikationen und Support Verläufe liefern den Rohstoff für Antworten.
• Quellenangabe: Sie können zeigen, aus welchem Dokument und Abschnitt eine Antwort stammt. Nutzer klicken und prüfen selbst.
• Weniger Halluzinationen: Das Modell bleibt bei dem Text, den man ihm vorlegt. Steht dort keine Antwort, soll es das sagen.

Allerdings müssen wir ehrlich sein: RAG verringert Halluzinationen, es beseitigt sie nicht. Ein schlecht gefundener Abschnitt kann dennoch zu einer schlechten Antwort führen. Deshalb sollten Sie den Abschnitt zur Bewertung weiter unten nicht überspringen.

Zum Beispiel sind typische Einsatzfelder ein interner Wissensassistent, ein Support Bot für Kunden, die Produktsuche für den Vertrieb, Fragen zu Richtlinien und Compliance sowie die Suche in technischer Dokumentation.

Wie funktioniert RAG Schritt für Schritt?

RAG hat zwei Phasen. Zunächst bereiten Sie die Dokumente vor, das nennen wir Indexierung. Danach suchen Sie bei jeder Frage und erzeugen eine Antwort. Die Indexierung läuft einmal, danach aktualisiert sie sich bei Änderungen. Die Abfragephase läuft dagegen bei jeder Frage.

So läuft die Indexierung ab:

1. Zunächst sammeln Sie die Dokumente: PDFs, Word Dateien, Wiki Seiten, E-Mail Archive, Produktkataloge.
2. Dann bereinigen Sie den Text und teilen ihn in sinnvolle Abschnitte (Chunks).
3. Danach wandeln Sie jeden Chunk in ein Embedding um, also in eine Zahlenreihe, die seine Bedeutung abbildet.
4. Schließlich speichern Sie die Vektoren samt Quelle des Chunks in einer Vektordatenbank.

Die Abfrage läuft dann so ab:

1. Zunächst stellt der Nutzer eine Frage.
2. Dann wandelt das System auch die Frage in ein Embedding um.
3. Danach holt es die Chunks aus der Datenbank, die der Frage inhaltlich am nächsten liegen.
4. Außerdem schickt es diese Chunks zusammen mit der Frage an das Modell.
5. Schließlich schreibt das Modell die Antwort und nennt die Quellen.

Auf den ersten Blick wirkt dieser Ablauf komplex. In der Praxis hat jedoch jeder Schritt genau eine Aufgabe. Deshalb finden Sie bei Problemen auch schneller die Stelle, an der es hakt.

Warum teilt man Dokumente in Chunks und wie groß sollten sie sein?

Ein Modell kann nur begrenzt viel Text auf einmal lesen. Zudem wäre es teuer und unruhig, bei jeder Frage ein ganzes Handbuch mit 200 Seiten mitzuschicken. Deshalb zerlegen Sie jedes Dokument in kleine Chunks. Kommt eine Frage, gehen nur die passenden Chunks an das Modell.

Die Chunk Größe ist eine der wichtigsten Qualitätsstellschrauben, deshalb sollten Sie sie messen statt schätzen. Zu kleine Chunks verlieren nämlich den Zusammenhang, denn ein einzelner Satz sagt oft wenig. Zu große Chunks tragen dagegen Unwichtiges mit und machen die Suche unscharf.

Unsere praktischen Tipps:

• Schneiden Sie an Überschriften und Absatzgrenzen, nicht nach einer zufälligen Zeichenzahl.
• Lassen Sie zwischen benachbarten Chunks eine kleine Überlappung, damit Sätze nicht mitten drin abbrechen.
• Hängen Sie an jeden Chunk den Dokumenttitel, die Abschnittsüberschrift und das Datum als Zusatzdaten.
• Halten Sie Tabellen und Listen zusammen, denn eine halbe Tabelle führt zu einer falschen Antwort.

Der Beitrag von Anthropic zu Contextual Retrieval beschreibt genau dieses Problem. Ein Chunk mit dem Satz "der Umsatz stieg" verliert, um welche Firma und welchen Zeitraum es geht. Als Lösung schlägt der Beitrag vor, jedem Chunk eine kurze Erklärung voranzustellen.

Die Länge Ihrer Chunks messen Sie schnell mit unserem Wörter Zähler.

Was sind Embeddings und eine Vektordatenbank?

Ein Embedding übersetzt die Bedeutung eines Textes in eine Zahlenreihe. Zwei Texte mit ähnlicher Bedeutung liegen in diesem Zahlenraum nah beieinander. "Rückgabefrist" und "Bedingungen für die Rücksendung" teilen kaum Wörter, ihre Embeddings sind trotzdem Nachbarn.

Eine Vektordatenbank speichert diese Zahlenreihen und findet schnell die, die einer Frage am nächsten liegen. Beispiele sind pgvector, Qdrant, Chroma, FAISS und OpenSearch. Das sind nur Beispiele, denn die Wahl hängt von Ihrer Infrastruktur und Ihrem Team ab.

Eine wichtige Regel: Nutzen Sie beim Indexieren und beim Abfragen dasselbe Embedding Modell. Wechseln Sie das Modell, dann müssen Sie alle Dokumente neu indexieren.

Bei der Wahl des Embedding Modells helfen diese Fragen:

• Wie gut versteht es Deutsch und Ihre anderen Sprachen? Brauchen Sie ein mehrsprachiges Modell?
• Passen Kosten und Geschwindigkeit zu Ihrem Budget?
• Schickt es Ihre Daten nach außen oder läuft es auf Ihrem eigenen Server?

Modellnamen und Versionen ändern sich schnell. Prüfen Sie aktuelle Optionen und Preise deshalb auf der offiziellen Seite des Anbieters.

Reicht die reine Vektorsuche aus?

Meistens nicht, denn die Vektorsuche erfasst Bedeutung gut, sie übersieht aber Anfragen, die eine genaue Übereinstimmung brauchen, etwa einen Produktcode, eine Fehlernummer oder einen Eigennamen. Zum Beispiel kann eine Suche nach "Fehler 4032" hinter einer Seite mit einem ähnlichen, aber anderen Fehler verschwinden.

Produktive Systeme setzen deshalb oft auf hybride Suche. Das heißt, sie kombinieren die Bedeutungssuche mit der klassischen Stichwortsuche (etwa BM25). So gleicht jedes Verfahren die Schwächen des anderen aus.

Die nächste Verbesserung ist das Reranking. Zunächst holt das System eine recht breite Kandidatenliste. Dann bewertet ein weiteres Modell jeden Kandidaten gegen die Frage und behält die besten. So verringert sich das Rauschen und verkürzt den Text, der an das Modell geht.

Kurz gesagt sieht die Suchkette so aus:

• Kandidaten holen: Bedeutungssuche und Stichwortsuche gemeinsam laufen lassen.
• Filtern: nach Metadaten wie Datum, Abteilung oder Dokumenttyp eingrenzen.
• Neu sortieren: die wenigen relevantesten Chunks auswählen.
• Antwort erzeugen: die ausgewählten Chunks dem Modell geben.

Auch die Retrieval Anleitung von OpenAI beschreibt semantische Suche, Vektorspeicher und Metadatenfilter in einem ähnlichen Rahmen.

Wie schreibt das Modell die Antwort und nennt Quellen?

Die gefundenen Chunks gehen zusammen mit der Frage des Nutzers in den Prompt des Modells. Der Prompt enthält kurze, klare Regeln: "Stütze dich nur auf den gegebenen Text. Steht die Antwort nicht darin, sage, dass du es nicht weißt. Nenne zu jeder Aussage die Quellennummer."

Diese Regeln beeinflussen deshalb die RAG Qualität direkt. Mehr zum Schreiben von Anweisungen finden Sie in unserer Anleitung für Custom GPTs.

Für Quellenangaben speichern Sie zu jedem Chunk Dokumenttitel, Abschnitt und Link. Das Modell gibt diese Angaben bei der Antwort weiter. In der Oberfläche zeigen Sie dann unter der Antwort eine Liste "Quellen".

Legen Sie außerdem das Antwortformat fest. Zum Beispiel können Sie eine kurze Zusammenfassung, danach Schritte als Liste und zuletzt die Quellenliste verlangen. So sehen Nutzer jedes Mal dasselbe Layout, und die Antworten lesen sich leichter.

Zwei Details sind hier besonders wichtig, weil sie das Vertrauen prägen:

• Das Recht auf "Ich weiß es nicht": Erlauben Sie dem Modell, nicht zu antworten, wenn die gefundenen Chunks schwach sind. Sonst füllt es die Lücke mit Allgemeinwissen.
• Widersprüchliche Quellen: Sagen zwei Dokumente Verschiedenes, bevorzugen Sie das neuere oder zeigen dem Nutzer den Widerspruch.

Jede Anfrage verbraucht Tokens, also die Texteinheiten, die ein Modell liest, im Verhältnis zum gefundenen Text. Zur Kostenrechnung lesen Sie unseren Beitrag zu Tokens und API Kosten.

Was ist RAG im Vergleich zu Fine Tuning, und was brauchen Sie?

Beim Fine Tuning stellen Sie die Gewichte eines Modells mit eigenen Beispieldaten neu ein. RAG verändert das Modell nicht, es lässt das Modell bei jeder Frage das passende Dokument lesen. Beides sind keine Konkurrenten, sondern Werkzeuge für verschiedene Aufgaben.

Als Faustregel gilt bei der Frage, was ist RAG und was ist Fine Tuning: Wollen Sie Wissen hinzufügen, nehmen Sie RAG. Wollen Sie Verhalten oder Stil beibringen, prüfen Sie Fine Tuning. Die Tabelle fasst den Unterschied zusammen:

In der Praxis starten viele Teams mit RAG. Es ist günstiger, lässt sich leicht ausprobieren, und Sie sehen, wo Fehler entstehen. Fine Tuning kommt also erst dann ins Spiel, wenn ein Verhaltensproblem bleibt, das RAG nicht löst. Manche Systeme kombinieren auch beides.

Wie bereiten Sie Ihre Daten vor dem Aufbau vor?

Die Qualität von RAG kann nicht besser sein als die Qualität Ihrer Dokumente. Unordentliche, veraltete und widersprüchliche Dateien liefern schlechte Antworten, egal wie gut das Modell ist. Deshalb geht es in den ersten Wochen eines Projekts meist um Inhaltspflege und weniger um Technik.

Hier unsere Startliste:

1. Grenzen Sie den Umfang ein. Wählen Sie zuerst ein Gebiet, zum Beispiel Wissen für den Kundensupport.
2. Benennen Sie Verantwortliche. Jedes Dokument braucht jemanden, der es aktuell hält.
3. Entfernen Sie alte Versionen. Dateien wie "Kopie", "final" und "final2" erzeugen Widersprüche.
4. Wandeln Sie gescannte PDFs in Text um. Prüfen Sie die Texterkennung (OCR) stichprobenartig auf Fehler.
5. Entscheiden Sie, wie Sie Tabellen, Bilder und Screenshots behandeln.
6. Ergänzen Sie Metadaten zu jedem Dokument, etwa Datum, Abteilung, Sprache und Zugriffsstufe.

Diese Schritte wirken trocken. Dennoch beeinflussen sie das Ergebnis am stärksten. Brauchen Sie bei den Dokumenten Unterstützung, dann schauen Sie sich unsere Lösung zur KI Dokumentenverarbeitung an.

Wer darf welches Dokument sehen? Wie richten Sie Berechtigungen ein?

Dieses Thema übersehen Teams in RAG Projekten am häufigsten. Legt das System alle Firmendokumente in einen Index, kann auch ein Praktikant nach der Gehaltsrichtlinie fragen. Die Zugriffskontrolle muss deshalb bei der Suche greifen und nicht erst nach der Antwort.

Der richtige Ansatz funktioniert so: Sie hängen an jeden Chunk eine Zugriffsinformation (welche Gruppe, welche Abteilung). Stellt ein Nutzer eine Frage, liest das System zuerst Identität und Gruppen des Nutzers. Danach begrenzt es die Suche auf die Chunks, die dieser Nutzer sehen darf.

Beachten Sie diese Punkte:

• Verlangen Sie die Zugriffskontrolle nicht vom Modell. Der Satz "zeige keine geheimen Dokumente" ist keine Sicherheit, denn Modelle lassen sich umstimmen.
• Übernehmen Sie die Rechte des Quellsystems (Laufwerk, Wiki) in den Index und gleichen Sie sie regelmäßig ab.
• Verliert ein Nutzer sein Recht, aktualisieren Sie auch die Zugriffsdaten im Index.
• Protokollieren Sie außerdem Zugriffsversuche.

Denken Sie außerdem an die Teamstruktur. Zum Beispiel darf der Vertrieb Rabattgrenzen sehen, aber keine Gehaltsabrechnungen. Diese Trennung auf Dokumentebene festzulegen, ist also viel günstiger als eine spätere Reparatur.

Bedenken Sie auch die Angriffsseite. Anweisungen, die in einem Dokument versteckt sind, können das Modell in die Irre führen. Lesen Sie dazu unseren Ratgeber zu Prompt Injection.

Wie bewerten Sie ein RAG System?

"Es antwortet anscheinend gut" ist kein Maßstab. Sie müssen RAG in zwei Teilen messen: Hat es den richtigen Chunk gefunden, und hat es aus diesem Chunk eine korrekte Antwort geschrieben? Wo der Fehler liegt, dort beginnen Sie mit der Korrektur.

Bauen Sie dafür ein eigenes Testset. Sammeln Sie zunächst etwa hundert echte Nutzerfragen. Danach notieren Sie zu jeder Frage die richtige Antwort und das Dokument, aus dem sie stammt. Beispielszenario: Bei der Frage "Wie viele Tage habe ich für die Rückgabe?" ist der richtige Chunk der passende Absatz der Rückgabe Richtlinie.

Drei Kernfragen helfen:

• Trefferqualität: Taucht der richtige Chunk unter den ersten Ergebnissen auf?
• Treue zur Quelle: Stützt sich die Antwort nur auf den gefundenen Text, oder ergänzt das Modell eigenes Wissen?
• Nutzen: Löst die Antwort das Problem wirklich, oder muss der Nutzer nachfragen?

Lassen Sie das Testset nach jeder Änderung neu laufen. So sehen Sie, wie sich der Wert verschiebt, wenn Sie Chunk Größe, Embedding Modell oder Prompt ändern. Im Live Betrieb ergänzen Sie zudem einen Button "War das hilfreich?" und lesen negatives Feedback regelmäßig.

Welche typischen Fehler passieren bei RAG?

Wir sehen in Projekt um Projekt dieselben Fehler. Die meisten entstehen durch fehlende Vorbereitung und Messung, nicht durch die Modellwahl. Hier die häufigsten:

• Ein unordentliches Archiv unverändert laden. Alte und widersprüchliche Dokumente führen zu widersprüchlichen Antworten.
• Die Chunk Größe nie testen. Die Standardeinstellung passt vielleicht nicht zu Ihren Dokumenten.
• Nur der Vektorsuche vertrauen. Codes, Namen und Nummern rutschen durch.
• Ohne Testset live gehen. Sie wissen nicht, ob eine Änderung geholfen oder geschadet hat.
• Berechtigungen ans Ende schieben. Nachträglich sind sie sehr schwer, planen Sie sie von Anfang an.
• Keine Quellen zeigen. Können Nutzer Antworten nicht prüfen, vertrauen sie dem System nicht.
• Keinen Aktualisierungsablauf bauen. Der Index füllt sich einmal und veraltet dann.
• Jedes Problem mit RAG lösen wollen. Manche Fragen brauchen eine Berechnung oder eine Datenbankabfrage.

Den letzten Punkt erläutern wir kurz, weil er oft Fragen aufwirft. "Wie viele Bestellungen hatten wir letzten Monat?" ist keine Dokumentensuche. Dafür muss das Modell dann eine Datenbankabfrage ausführen. RAG ist stark bei Textwissen, für Zahlenanalysen brauchen Sie andere Werkzeuge.

Mit welchen Szenarien starten Teams typischerweise?

Teams beginnen meist mit ähnlichen Szenarien. Gemeinsam ist ihnen, dass die Antwort bereits in einem Dokument steht. Die folgenden Beispiele sind Beispielszenarien und keine echten Kundenergebnisse.

• Interner Support Assistent: Eine neue Kollegin fragt: "Wie stelle ich einen Urlaubsantrag?" Der Assistent holt die Schritte aus der Personalrichtlinie. Dadurch beantwortet das Personalteam nicht mehr ständig dieselbe Frage.
• Produktsuche für den Vertrieb: Ein Vertriebsmitarbeiter prüft vor dem Kunden: "Passt dieses Zubehör zu jenem Modell?" Das System liefert Antwort und Seitenzahl aus dem Datenblatt.
• Support Bot für Kunden: Ein Kunde fragt nach Versand und Rückgabe. Der Bot stützt sich nur auf die veröffentlichte Richtlinie und übergibt bei Bedarf an einen Menschen.
• Suche in technischer Dokumentation: Ein Entwicklungsteam sucht, wie eine alte Schnittstelle funktioniert. Wiki, Code Kommentare und Besprechungsnotizen sind an einer Stelle durchsuchbar.

In all diesen Fällen müssen Nutzer nicht mehr das richtige Stichwort erraten. Außerdem vertrauen sie der Antwort stärker, weil sie die Quelle daneben sehen. Das heißt, in der Praxis macht RAG aus Ihrem Dokumentenarchiv einen Helfer, mit dem man sprechen kann.

Wann brauchen Sie kein RAG?

Nicht jede KI Aufgabe braucht RAG. Manchmal funktioniert eine einfachere Lösung besser. In den folgenden Fällen sollten Sie vor dem Aufbau zweimal nachdenken.

Ist die Dokumentenmenge winzig, etwa wenige Seiten, können Sie den Text direkt in den Prompt legen. So sparen Sie sich Aufbau und Pflege einer Suchschicht. Wächst die Dokumentenzahl allerdings, wird dieser Weg langsam und teuer.

Ist Ihre Frage numerisch, etwa Umsatzsummen oder Lagerbestände, ist eine Datenbankabfrage das richtige Werkzeug. Das Modell kann diese Abfrage schreiben und ausführen. Die Antwort kommt dann aber nicht aus einer Dokumentensuche.

Ist die Regel fest und eindeutig, zum Beispiel "schicke jede Buchung über diesem Betrag zur Freigabe", ist eine Software Regel verlässlicher als KI. Eine Regel Engine liefert jedes Mal dasselbe Ergebnis.

Wollen Sie schließlich Tonfall oder Ausgabeformat des Modells ändern, fehlt kein Wissen. Dann schauen Sie zuerst auf das Prompt Design und danach auf Fine Tuning.

Welche Pflege braucht ein RAG System nach dem Start?

Ein RAG System ist kein Projekt zum Bauen und Vergessen. Denn Dokumente ändern sich, Nutzer stellen neue Fragen, und Modelle bekommen Updates. Der Start ist deshalb der Anfang der Arbeit und nicht ihr Ende.

Wir empfehlen diese Routinen:

• Aktualisierungsablauf: Ändert sich ein Quelldokument, indexieren Sie nur die betroffenen Chunks neu. So vermeiden Sie, das ganze Archiv neu zu verarbeiten.
• Löschablauf: Entfernen Sie ausgemusterte oder abgelaufene Dokumente auch aus dem Index. Sonst lebt veraltetes Wissen in den Antworten weiter.
• Überwachung: Sehen Sie sich unbeantwortete Fragen und Fragen mit negativem Feedback wöchentlich an. Oft zeigen sie ein fehlendes Dokument.
• Regressionstests: Lassen Sie das Testset neu laufen, sobald sich Modell oder Embedding ändern.

Bei den Kosten gibt es drei Hebel. Erstens: Erhöhen Sie die Zahl der Chunks, die an das Modell gehen, nicht ohne Grund. Zweitens: Speichern Sie Antworten auf häufige Fragen zwischen. Drittens: Nutzen Sie für einfache Fragen ein leichteres Modell und für schwere ein stärkeres. Aktuelle Preise prüfen Sie daher auf der offiziellen Seite des jeweiligen Anbieters.

Was müssen Sie bei DSGVO und Datenschutz beachten?

Enthalten Ihre Dokumente personenbezogene Daten (Personalakten, Kundenkorrespondenz, Verträge), ist ein RAG Aufbau eine Verarbeitung personenbezogener Daten. Dann gilt die DSGVO. Dieser Abschnitt ist keine Rechtsberatung, bitte besprechen Sie Ihre Entscheidung mit Ihrer Juristin oder Ihrem Juristen.

Fragen für den Anfang:

• Welche personenbezogenen Daten landen im Index? Ist wirklich alles nötig?
• Wer verarbeitet die Daten? Modellanbieter, Cloud Dienst und Anbieter der Vektordatenbank können Auftragsverarbeiter sein.
• Nutzt der Anbieter die gesendeten Daten für das Modelltraining? Prüfen Sie Vertrag und offizielle Dokumentation.
• Verlassen die Daten die EU? Wenn ja, was ist Ihre Rechtsgrundlage?
• Können Sie bei einem Löschverlangen die Daten der Person auch aus dem Index entfernen?

Maskieren Sie personenbezogene Daten vor der Indexierung, wo es geht, oder lassen Sie sie ganz weg. Außerdem sollten Sie festhalten, aus welchem Quelldokument jeder Chunk stammt, damit Sie Lösch- und Berichtigungsverlangen erfüllen können.

Den offiziellen Rahmen finden Sie im Text der DSGVO im Rechtsportal der EU. Für die Website Seite hilft unser Leitfaden zur datenschutzkonformen Website.

Datenstandort: Cloud oder eigener Server?

Bei RAG liegen Daten an zwei Orten: im Speicher für Dokumente und Vektoren und im Modell, das die Antworten schreibt. Beide können Sie zudem getrennt platzieren. Die Entscheidung hängt von der Sensibilität der Daten, Ihrem Budget und der Betriebskraft Ihres Teams ab.

Die häufigsten Varianten im Überblick:

Für sensible Daten wirkt die dritte Variante attraktiv. Wollen Sie offene Modelle auf dem eigenen Server betreiben, lesen Sie unsere Ollama Anleitung und sehen Sie sich unsere Lösung für ein lokales LLM an.

Ein lokaler Aufbau ist allerdings nicht automatisch sicherer. Updates, Backups und Zugriffskontrolle liegen dann bei Ihnen. Wägen Sie das Risiko deshalb realistisch ab.

Was ist RAG im Unternehmen und mit welchen Werkzeugen baut man es?

Fragen Sie im Unternehmenskontext, was ist RAG, lautet die Antwort: die verpackte Version der obigen Teile, also Dokumentleser, Chunking, Embeddings, Vektorspeicher, Suche, Modell, Berechtigungen und Messung. Frameworks wie LangChain und LlamaIndex verbinden diese Teile, und Cloud Anbieter bieten zudem verwaltete Suchdienste an.

Vergleichen Sie die beiden Wege. Ein verwalteter Dienst startet schnell, begrenzt allerdings Flexibilität und Transparenz. Eine Eigenentwicklung kostet mehr Aufwand, gibt Ihnen aber volle Kontrolle über Berechtigungen, Datenstandort und Messung.

Unser Rat ist, fertige Werkzeuge in einem kleinen Pilot auszuprobieren. Der Pilot zeigt, welche Dokumente taugen und welche Fragen durchrutschen. Danach wechseln Sie auf Basis Ihrer Erfahrung zu einer eigenen Architektur.

Werkzeugnamen und Versionen ändern sich schnell, die Namen hier sind nur Beispiele. Wir bezeichnen keines davon als "das beste". Aktuelle Funktionen und Preise prüfen Sie auf der offiziellen Seite des Anbieters.

In welcher Reihenfolge starten Sie ein RAG Projekt?

Beginnen Sie nicht mit einem riesigen Assistenten, der alles weiß. Denn ein kleiner, messbarer Pilot lehrt schneller. Wir empfehlen diese Reihenfolge:

1. Wählen Sie eine Nutzergruppe und eine Fragenart.
2. Bereinigen Sie die Dokumente dieses Bereichs und benennen Sie ihre Verantwortlichen.
3. Bauen Sie ein Testset aus etwa hundert echten Fragen.
4. Bauen Sie ein einfaches RAG: Chunking, Embedding, Suche, Antwort.
5. Messen Sie mit dem Testset und probieren Sie dann nacheinander Chunk Größe, hybride Suche und Reranking.
6. Ergänzen Sie Berechtigungen und Quellenangaben.
7. Gehen Sie mit einer kleinen Nutzergruppe live und sammeln Sie Feedback.
8. Richten Sie Aktualisierung und Überwachung ein, und erweitern Sie danach den Umfang.

Fragen Sie bei jedem Schritt: "Wie messe ich das?" Was Sie nicht messen, können Sie nicht verbessern. Schreiben Sie außerdem das Erfolgskriterium des Piloten vorab auf. Ein einfaches Ziel genügt, etwa wie oft das Team schon mit der ersten Antwort beim richtigen Dokument landet.

Steuern Sie also auch die Erwartungen von Anfang an. Führungskräfte und Nutzer erwarten vielleicht, dass das System alles weiß, doch RAG findet nur, was in Ihren Dokumenten steht. Die erste Version ist nicht perfekt, entscheidend ist deshalb ein Aufbau, in dem Sie die Ursache jedes Fehlers finden.

Wie unterstützen Talha Aslan und Team bei diesem Thema?

Wir sind Talha Aslan und Team und arbeiten seit 2012 in Projekten für digitales Marketing und Software. Im Bereich KI bauen wir dokumentenbasierte Assistenten, Workflow Automatisierungen und Integrationen. Zahlen oder Fallergebnisse versprechen wir hier nicht. Stattdessen beschreiben wir unser Vorgehen.

Zunächst klären wir mit Ihnen Umfang und Daten. Dann bauen wir einen kleinen Pilot und messen ihn mit einem Testset. Fragen zu Berechtigungen, Datenstandort und Datenschutz legen wir außerdem von Anfang an auf den Tisch.

Passende Seiten:

• Unser Wissensassistent für Unternehmen
• KI Integration
• KI Beratung

Hinweis: Dieser Beitrag dient der allgemeinen Information und ist keine Rechts oder Finanzberatung. Prüfen Sie aktuelle Modell und Werkzeugdetails auf den offiziellen Seiten der Anbieter.