Erklärung eines grundlegenden RAG-Prozesses: Von Rohdokumenten zu fundierten Antworten

Sprachmodelle haben eine unangenehme Angewohnheit: Sie klingen selbstsicher, auch wenn sie keine Fakten haben. Fragt man nach einer internen Unternehmensrichtlinie, dem Handbuch für ein letztes Monat veröffentlichtes Produkt, einem selten genutzten Rechtsdokument oder dem Support-Ticket von gestern, weiß das Modell möglicherweise einfach nichts. Noch schlimmer: Es könnte etwas vortäuschen, das plausibel klingt, um die Lücke zu füllen.

Retrieval-augmented Generation, meist abgekürzt als RAG, ist die gängige Lösung. Ein RAG-Verfahren ermöglicht es einem Modell, zum Zeitpunkt des Bedarfs externe Kenntnisse abzurufen. Nicht alles muss im Gedächtnis des Modells gespeichert sein, denn das System durchsucht eine zuverlässige Wissensdatenbank, zieht die relevantesten Passagen heraus und erstellt eine auf ihnen basierende Antwort. Einfach ausgedrückt: Ein Assistent mit geschlossenem Buch wird zu einem mit offenen Buch.

Der Ansatz erhielt durch eine im Jahr 2020 veröffentlichte Forschungsarbeit über retrieval-augmented Generation für kennenzentrierte NLP-Aufgaben Aufmerksamkeit. In dieser Arbeit wurde ein generatives Modell mit einem Suchmechanismus kombiniert, der in einer externen Dokumentensammlung nach Informationen sucht. Die zentrale Erkenntnis war, dass das eingebaute Wissen eines Modells und externe Informationen sich gegenseitig ergänzen können. Das Modell liefert die sprachlichen Fähigkeiten, während der Suchmechanismus aktuelle, spezifische Details bereitstellt.

Ein grundlegender Pipeline läuft in zwei Phasen ab. Indexierung bereitet die Dokumente für die Suche vor. Antworten bezieht sich auf die Frage des Benutzers, holt relevante Materialien ab und gibt sie dem Modell als Kontext. Das klingt einfach, doch jede Phase birgt Entscheidungen, die das Ergebnis prägen. Ein schwaches System versagt selten wegen eines mangelhaften Modells selbst – viel häufiger werden falsche Dokumente abgerufen, die Ausschnitte sind unübersichtlich, die Anfrage ist vage oder das System kann nicht zugeben, dass es keine Antwort hat.

In den folgenden Abschnitten wird die Idee von Grund auf erläutert.

Was RAG in der Praxis leistet

Der grundlegende Ablauf umfasst vier Schritte. Der Benutzer stellt eine Frage. Das System durchsucht die Wissensdatenbank. Die am besten passenden Abschnitte werden in die Anfrage des Modells aufgenommen. Das Modell antwortet unter Verwendung dieses abgerufenen Kontexts.

Stellen Sie sich einen Kunden vor, der wissen möchte, ob ein aufbereiteter Laptop auch nach 20 Tagen zurückgegeben werden kann. Ein einfacher Chatbot könnte aufgrund allgemeiner Einzelhandelsgewohnheiten raten. Ein RAG-Chatbot kann die tatsächliche Rückgabepolitik abrufen, den Abschnitt zu aufbereiteten Produkten finden und daraufhin antworten. Wenn die Politik eine Frist von 14 Tagen für aufbereitete Laptops vorsieht, kann der Bot das bestätigen. Falls in der Politik nichts zu aufbereiteten Laptops steht, sollte der Bot keine Regeln erfinden.

Das ist das Wesentliche: Zuerst Abruf, dann Erstellung. Der Abruf reduziert die Menge an Informationen auf einige nützliche Belege, während die Erstellung daraus eine hilfreiche Antwort erstellt. Bei richtiger Anwendung verbessert RAG die faktische Genauigkeit, macht Antworten leichter überprüfbar und ermöglicht es, das Wissen des Systems ohne Neutraining eines Modells zu aktualisieren.

Auswahl der Wissensquelle

Jeder Pipeline beginnt mit einer Quelle an Material, das abgerufen werden soll. Typische Beispiele sind Unternehmensdokumentation, Produkthandbücher, Artikel aus dem Support-Zentrum, PDFs, Verträge, Forschungsarbeiten, Meeting-Notizen, Datenbankdaten, Code-Dokumentationen und Support-Tickets.

Die größte Quelle ist nicht immer die beste. Eine gezielte, ordentliche und aktuelle Sammlung von Dokumenten ist in der Regel besser als eine große Menge veralteter Dateien. RAG kann schlechtes Quellmaterial nicht verbessern, daher liefern veraltete, unklare oder widersprüchliche Dokumente ebenfalls veraltete, unklare oder widersprüchliche Antworten.

Vor dem Indizieren hilft es, sich einige praktische Fragen zu stellen:

• Ist die Information genau und aktuell?
• Wem gehört sie?
• Darf jeder Benutzer sie einsehen?
• Gibt es duplizierte oder widersprüchliche Versionen?
• Brauchen Tabellen, Bilder, Fußnoten oder rechtliche Klauseln eine besondere Behandlung?

Eine kleine, gut gepflegte Wissensdatenbank ist ein guter Ausgangspunkt. Für das erste Projekt sollten Sie einen klaren Anwendungsfall wählen, wie beispielsweise Fragen zum Mitarbeiterhandbuch oder zu einer Produkt-FAQ, und diesen erst erweitern, wenn das funktioniert.

Dokumente bereinigen und vorbereiten

Rohdateien sind selten sofort für die Suche geeignet. PDF-Dateien können fehlerhafte Zeilenumbrüche aufweisen. Webseiten enthalten Menüs, Cookie-Banner, Werbung sowie Fußzeilen, die auf jeder Seite wiederholt werden. Interne Dokumente können Überschriften mit zu wenig Kontext haben, und Tabellenkalkulationen können wichtige Details in Spalten verbergen, die im reinen Text schwer lesbar sind.

Durch die Reinigung wird dieser Unordnungstext in suchbaren Text umgewandelt. Dazu kann es gehören, Standardtexte zu entfernen, Überschriften beizubehalten, Tabellen auszuziehen, alles in ein einheitliches Format zu konvertieren und Metadaten hinzuzufügen. Metadaten sind besonders nützlich, denn ein Textabschnitt gewinnt viel an Wert, wenn er Felder wie den Titel des Dokuments, den Autor, das Datum, die zuständige Abteilung, die Produktversion, einen Link, das Zugriffslevel oder die Abschnittsüberschrift enthält.

Vergleichen Sie einen einfachen Textabschnitt wie „Rücksendungen müssen innerhalb von 14 Tagen beantragt werden“ mit einem beschrifteten: Der Titel lautet Rückgabepolitik für aufbereitete Laptops, der Abschnitt ist das Rückgabefenster, er wurde zuletzt im März 2026 aktualisiert, und im Text steht, dass eine Rücksendung eines aufbereiteten Laptops innerhalb von 14 Tagen nach Erhalt beantragt werden muss. Diese zweite Form gibt sowohl dem Suchalgorithmus als auch dem Modell mehr Informationen zur Verarbeitung und erleichtert später Zitierungen sowie das Filtern.

Dokumente in Abschnitte aufteilen

Sprachmodelle und Abrufsysteme handhaben in der Regel keine ganzen Bücher, Handbücher oder Richtliniensammlungen als Ganzes. Sie kommen besser mit kleineren Abschnitten zurecht, die als „Chunks“ bezeichnet werden.

Das Aufteilen in Chunks gehört zu den wichtigsten Schritten im Prozess, da der Abruf auf Chunk-Ebene erfolgt. Sind die Chunks zu groß, kann die Antwort im irrelevanten Text verloren gehen. Sind sie zu klein, könnte das System Fragmente ohne ausreichenden Kontext abrufen, um angemessen antworten zu können. Ein guter Chunk ist groß genug, um eine vollständige Idee zu enthalten, und klein genug, um die Konzentration beizubehalten.

Bei systemen mit viel Text beginnen Entwickler oft mit Chunks von einigen hundert Wörtern und passen diese anhand der Ergebnisse an. Einige verwenden überlappende Chunks, damit beim Übergang zwischen ihnen kein Kontext verloren geht – beispielsweise dort, wo ein Überschriftentext einen Chunk abschließt und der dazugehörige Richtlinientext den nächsten Chunk eröffnet.

Das Aufteilen in Blöcke sollte möglichst der Dokumentstruktur folgen. Eine Aufteilung nach Abschnitten, Überschriften, Absätzen oder Frage-Antwort-Paaren ist in der Regel besser als ein Schnitt nach einer festen Zeichenzahl, und verschiedene Dokumenttypen wie Rückerstattungspolitiken, Fehlerbehebungshilfen und wissenschaftliche Artikel benötigen möglicherweise jeweils einen eigenen Ansatz.

Genau hier scheitern oder erfolgreich funktionieren viele einfache Systeme. Das Modell kann nur auf der Grundlage dessen antworten, was es erhält, wodurch ein in Stücke gerissener Fragment ohne Kontext selbst ein leistungsstarkes Modell in Verlegenheit bringen kann.

Erstellung von Embeddings

Nach der Reinigung und dem Aufteilen in Blöcke wird jeder Block in ein Embedding umgewandelt, eine numerische Darstellung der Bedeutung. Technisch gesehen handelt es sich dabei um einen Vektor, eine Liste von Zahlen, die semantische Informationen über den Text erfassen. Texte mit ähnlicher Bedeutung liegen in der Regel in der Vektorraumstruktur nah beieinander, was es einem System ermöglicht, nach Bedeutung statt nur nach exakten Schlüsselwörtern zu suchen.

Nehmen wir nun an, die Frage lautet, wie lange jemand Zeit hat, einen aufgearbeiteten Computer zurückzusenden, obwohl in der Dokumentation steht, dass aufgearbeitete Laptops bei Anfrage innerhalb von 14 Tagen nach Lieferung zurückgegeben werden können. Eine herkömmliche Schlüsselwortsuche könnte den Zusammenhang zwischen „zurücksenden“ und „Rückgaben“ oder zwischen „Computer“ und „Laptop“ übersehen. Eine auf Embedding basierende Suche erkennt diesen Zusammenhang eher.

Diese Art der semantischen Abgleichung erklärt, warum dichte Repräsentationen bei der Beantwortung von Fragen in offenen Domänen wichtig wurden. Die im Jahr 2020 veröffentlichte Arbeit zu Dense Passage Retrieval zeigte, dass gelernte dichte Repräsentationen in mehreren Recherche-Benchmarks für die Beantwortung von Fragen in offenen Domänen eine leistungsstärkere Basis als BM25 darstellen konnten.

In einem einfachen Pipeline werden alle Fragmente in die Wissensdatenbank eingebettet. Wenn ein Benutzer eine Frage stellt, wird auch diese eingebettet, mit den gespeicherten Fragment-Embeddings verglichen und die am nächsten liegenden Ergebnisse abgerufen.

Speichern von Embeddings in einer Vektordatenbank

Die Embeddings benötigen einen Ort, der Suchfunktionen unterstützt – genau dafür dient eine Vektordatenbank oder ein Vektor-Speicher. Er speichert das Embedding jedes Fragments, den ursprünglichen Text sowie alle nützlichen Metadaten. Bei der Abfrage werden die Fragmente gefunden, deren Embeddings denjenigen der Frage am nächsten liegen.

Für ein Prototyp reicht ein lokaler oder im Arbeitsspeicher befindlicher Speicher aus. In der Produktion kann eine verwaltete Vektordatenbank, ein Suchmaschinen-System, das Vektoren unterstützt, oder eine Datenbankerweiterung, die Vektorabfragen ermöglicht, erforderlich sein. Die Wahl sollte durch Skalierbarkeit, Geschwindigkeit, Kosten, Filteranforderungen, Sicherheit sowie die Häufigkeit der Dokumentänderungen bestimmt werden.

Betrachten Sie es als Teil des Abrufmechanismus und nicht nur als Speicherkasten. Eine gute Filterung der Metadaten kann einen großen Unterschied machen. Eine Frage zur europäischen Rückerstattungspolitik sollte keine Richtlinien aus einer anderen Region abrufen. Wenn ein Benutzer nur die HR-Dokumente seines eigenen Bereichs ansehen darf, muss der Abrufmechanismus dies sicherstellen, bevor etwas das Modell erreicht.

Das ist wichtig, weil RAG Informationen durch schwache Zugriffskontrollen preisgeben kann. Man sollte dem Modell nicht trauen, dass es eingeschränkte Inhalte nach dem Abruf versteckt – es ist sicherer, solche eingeschränkten Materialien gar nicht erst abrufen zu lassen.

Abruf der relevanten Abschnitte

Die Beantwortung beginnt, wenn ein Benutzer eine Frage stellt. Das System fügt die Frage ein, durchsucht den Vektor-Speicher und gibt die am besten passenden Abschnitte zurück. Fachleute bezeichnen dies als Top-k-Abruf, wobei k angibt, wie viele Abschnitte zurückgegeben werden; Top-5 bedeutet die fünf am nächsten passenden.

Die Auswahl von k erfordert ein Gleichgewicht. Wenn zu wenig Informationen abgerufen werden, könnten wichtige Details übersehen werden. Wenn zu viele Informationen abgerufen werden, wird die Anfrage unübersichtlich, aufwendig oder verwirrend. Mehr Kontext ist nicht immer besser – aber besserer Kontext schon.

Viele grundlegende Systeme beginnen mit einer Vektorähnlichkeitssuche, die Fragen zum Sinn gut bewältigt, aber nicht perfekt ist. Einige Abfragen hängen von exakten Wörtern, IDs, Namen, Datumsangaben, Fehlercodes oder rechtlichen Formulierungen ab, und in solchen Fällen kann eine Schlüsselwortsuche allein der Vektorsuche überlegen sein.

Aus diesem Grund ist die hybride Suche beliebt. Sie kombiniert Vektorsuche mit einer Volltext-Schlüsselwortsuche und fügt die Ergebnisse zusammen. Azure AI Search beschreibt beispielsweise die hybride Suche als eine einzige Abfrage, bei der beide Suchmethoden gleichzeitig ausgeführt werden und die gerankten Ergebnisse mithilfe von Reciprocal Rank Fusion zusammengeführt werden. Einfach ausgedrückt: Das System hat zwei Wege zur Antwort – über den Sinn und über die genaue Wortwahl.

Die Vektorsuche ist ein sinnvoller Erstschritt. Wenn das Publikum häufig Produktcodes, Policentitel, rechtliche Formulierungen oder Fehlermeldungen eingibt, sollten Sie den hybriden Ansatz in Betracht ziehen.

Aufbau der Anweisung

Sobald die Fragmente abgerufen wurden, werden sie in die Anweisung des Modells eingefügt. Dabei sollte klar der Kontext, die Frage des Benutzers sowie die zu erledigende Aufgabe für das Modell angegeben werden. Eine einfache RAG-Anweisung kann dem Modell mitteilen, dass es auf Basis des bereitgestellten Kontexts antworten soll, sich ausschließlich auf dort gefundenen Informationen stützen soll, angeben soll, dass es die Antwort nicht kennt, wenn der Kontext fehlt, und gegebenenfalls den Quellentitel oder die entsprechende Abschnittsbezeichnung nennen soll. Anschließend folgen die abgerufenen Fragmente und die Frage.

Diese Anweisungen sind wichtig, weil das Modell über allgemeines Wissen verfügt. Ohne klare Richtlinien könnte es gesammelte Fakten mit eigenen Annahmen vermischen. Das ist manchmal akzeptabel, doch für einen Support-Bot, einen Rechtsassistenten, ein medizinisches Tool oder eine Hilfsmittel für Entscheidungsfindungen sollte das Modell sich eng an die ihm gegebenen Beweise halten.

In OpenAIs Dokumentation zur Prompt-Engineering-Technik wird RAG als Hinzufügen relevanter Kontexte aus einer Vektordatenbank oder einer Dateisuche zum Generierungsantrag beschrieben. Die Formulierung spielt eine Rolle: Sie stellt den abgerufenen Text als die Quelle dar, auf die sich das Modell stützen sollte.

Ein gut formulierter Prompt bewältigt auch Unsicherheiten, indem er dem Modell ermöglicht zu sagen, dass die bereitgestellten Dokumente die Frage nicht beantworten. Diese Antwort ist weniger spektakulär als eine selbstsichere Schätzung, aber weitaus nützlicher.

Antwort generieren

Nun schreibt das Sprachmodell die endgültige Antwort, den Teil, den die Nutzer tatsächlich sehen. Sie sollte klar, fundiert und angemessen spezifisch sein. Es sollte keinen rohen, abgerufenen Text ohne Anfrage bereitstellen. Stattdessen sollte es in natürlicher Sprache erklären, wichtige Einschränkungen nennen und dort, wo möglich, Quellen angeben.

Ein gutes Beispiel: „Refurbished-Laptops müssen innerhalb von 14 Tagen nach Lieferung zurückgegeben werden. Die Richtlinie erwähnt keine Ausnahmen für Rückgaben nach 20 Tagen, sodass auf der Grundlage dieser Richtlinie eine nach 20 Tagen beantragte Rückgabe nicht zulässig wäre.“ Das funktioniert, weil es die Regel darlegt, sie auf die Situation des Nutzers anwendet und nicht vorgibt, es gäbe eine Ausnahme, obwohl die Quelle keine vorsieht.

Außerdem bringen Zitate Wert, da sie es den Nutzern ermöglichen, eine Antwort zu überprüfen und nicht einfach dem Modell zu vertrauen. Die Nachvollziehbarkeit von KI-Antworten ist einer der größten praktischen Vorteile von RAG.

Bewertung des Pipelines

Ein RAG-System sollte getestet werden, bevor man sich darauf verlässt. Ein häufiger Fehler besteht darin, nur die endgültige Antwort zu überprüfen. Es ist besser, das Abrufen und Erstellen der Informationen getrennt zu bewerten: Zuerst prüfen, ob der Informationsabrufmechanismus die richtigen Abschnitte gefunden hat, anschließend, ob das Modell sie ordnungsgemäß verwendet hat.

Eine einfache Bewertungsmethode verknüpft tatsächliche Nutzerfragen mit den korrekten Quelltexten sowie den erwarteten Antworten. Für jede Frage sollte überprüft werden, ob das richtige Dokument unter den abgerufenen Ergebnissen enthalten ist. Wenn der richtige Abschnitt das Modell nie erreicht, sind zuverlässige Antworten unwahrscheinlich.

Anschließend sollte die erzeugte Antwort überprüft werden. Bleibt sie im Einklang mit dem Kontext? Enthält sie Behauptungen, die von niemandem gestützt werden? Beantwortet sie die eigentliche Frage und zitiert den richtigen Quelltext? Wenn die Dokumente unzureichend sind, wird das auch anerkannt?

Das Claude RAG-Kochbuch empfiehlt, den Abrufprozess sowie das Gesamtsystem getrennt voneinander zu bewerten und sich nicht von vagen Eindrücken zur Qualität der Antwort leiten zu lassen – ein Ratschlag, dem auch bei kleinen Projekten Folge geleistet werden sollte.

Ein grundlegender Bewertungslauf kann Folgendes überwachen:

• Abrufgenauigkeit, d.h. ob der richtige Abschnitt gefunden wurde.
• Aufrichtigkeit, d.h. ob die Antwort durch den abgerufenen Kontext gestützt wird.
• Vollständigkeit, d.h. ob wichtige Details enthalten sind.
• Zitatenqualität, d.h. ob die zitierten Quellen tatsächlich relevant sind.
• Verzögerung, die Zeit, die eine Antwort benötigt.
• Kosten, die verwendeten Tokens sowie Abrufanfragen.
• Nutzerzufriedenheit, d.h. ob das Problem gelöst wurde.

RAG ist selten beim ersten Mal perfekt. Die Bewertung zeigt an, wo Verbesserungen notwendig sind – sei es bei der Aufteilung in Abschnitte, den Metadaten, der Abruflogik, den Anfragen, der Neubewertung oder den Quelldokumenten selbst.

Wo grundlegende Pipelines versagen

Die erste Version einer Pipeline funktioniert in der Regel gut genug, um begeistert zu machen, und schlecht genug, um Demut zu erwecken. Typische Problempunkte:

• Schlechte Aufteilung in Abschnitte. Ein relevanter Abschnitt wird zurückgegeben, doch die gesamte Antwort ist nicht darin enthalten.
• Rauschen bei der Abruflogik. Abschnitte, die zwar relevant erscheinen, aber nicht auf die Frage antworten, werden zurückgegeben – oft dann, wenn die Anfrage allgemein gefasst ist, unklar oder voller Begriffe, die in vielen Dokumenten vorkommen.
• Veraltete Informationen. Aktualisierungen sind einfacher als ein Neutraining – vorausgesetzt, die Wissensdatenbank wird auf dem neuesten Stand gehalten. Alte Dokumente, die im Index verbleiben, können weiterhin abgerufen werden.

Metadatenfehler. Fehlende Daten zu Datumsangaben, Versionen, Regionen oder Berechtigungen führen dazu, dass technisch relevante, aber tatsächlich nutzlose Informationen übermittelt werden.

Übermäßiges Vertrauen. RAG verringert Halluzinationen, eliminiert sie jedoch nicht. Das Modell kann den Kontext weiterhin falsch interpretieren, übergeneralisieren oder Ausschnitte irreführend kombinieren. Eine fundierte Herleitung garantiert keine Wahrheit.

Sicherheitslücken. Prompt-Injection stellt ein echtes Risiko in LLM-Anwendungen dar. OWASP beschreibt sie als Manipulation des Modellverhaltens durch gezielte Eingaben, einschließlich solcher, die das System dazu bringen, Anweisungen zu ignorieren oder Informationen preiszugeben. Bei RAG können bösartige Anweisungen in den abgerufenen Dokumenten enthalten sein – und nicht nur in Benutzernachrichten. Eine Webseite, ein Support-Ticket oder ein gemeinsam genutztes Dokument könnte Text enthalten, der das Modell anweist, frühere Anweisungen zu ignorieren und den Systemprompt offenzulegen. Behandeln Sie alles, was abgerufen wird, als Daten – niemals als vertrauenswürdige Anweisungen.

Eine einfache Architektur

Ein für Anfänger geeignetes Design arbeitet in zwei Schritten. Auf der Indizierungsseite werden Dokumente gesammelt, aufbereitet, in Blöcke unterteilt, eingebettet und zusammen mit dem Originaltext sowie Metadaten in einem Vektorlagern gespeichert. Auf der Antwortseite wird die Frage des Benutzers eingebettet, die relevantesten Blöcke abgerufen und gegebenenfalls gefiltert oder neu rangiert, bevor sie in einen Prompt für das Sprachmodell eingefügt werden, um aus diesem Kontext eine Antwort zu geben.

Kurz gesagt: Dokumente werden zu Blöcken, dann zu Embeddings und schließlich in einem Vektorlagern gespeichert; eine Frage wird zu einem Abfragen-Embedding, durchläuft den Abrufmechanismus, um einen Kontext zu erzeugen, und das Sprachmodell wandelt diesen in eine Antwort um.

Frameworks wie LangChain und LlamaIndex bieten Werkzeuge zum Laden von Dokumenten, zum Erstellen von Indizes und Suchmechanismen sowie zur Verbindung dieser Suchmechanismen mit Sprachmodellen. In den Dokumentationen von LangChain wird die Datensuche als Nutzung eigener Wissensbasen über Loader und Vektorlagern dargestellt. LlamaIndex betrachtet RAG als Vorindizierung der Daten, sodass jede Abfrage bereits vor dem Aufruf des LLM relevante Kontexte abrufen kann.

Es ist kein komplexes System erforderlich, um dies zu erlernen. Ein kleines Prototyp benötigt lediglich fünf Komponenten: einige Dokumente in einer Datei, ein Embedding-Modell, einen Ort zum Speichern der Vektoren, einen Suchmechanismus und ein Chat-Modell. Entscheidend ist es, jeden Schritt zu verstehen und den gesamten Prozess nicht als schwarze Box zu betrachten.

Was einen guten Prozess ausmacht

Ein guter Pipeline-Algorithmus tut mehr als nur Text abrufen. Er findet den richtigen Text, präsentiert ihn dem Modell in einer nutzbaren Form und liefert eine Antwort, die den vorliegenden Belegen treu bleibt. Die besten Systeme weisen einige Gemeinsamkeiten auf: saubere, aktuelle Quellen, sorgfältiges Aufteilen in Abschnitte, aufbewahrte Metadaten, Abruf nach Bedarf sowohl anhand von Bedeutung als auch Präzision, klare Anweisungen, Quellenangaben, getrennte Bewertung des Abrufs und der Erstellung sowie Schutz sensibler Daten, bevor sie das Modell erreichen, und die Fähigkeit, Unwissenheit einzugestehen.

Gutes RAG ist daher mehr als nur eine KI-Funktion. Es vereint Wissensmanagement, Suchfunktionen, Produktdesign und Sicherheit.

Nächste Schritte

Sobald ein einfacher Pipeline-Algorithmus funktioniert, stehen mehrere Verbesserungen zur Verfügung:

• Fügen Sie eine hybride Suchfunktion hinzu, um sowohl anhand von Bedeutung als auch exakten Begriffen zu suchen.
• Fügen Sie einen Schritt zur Neubewertung hinzu, bei dem ein zweites Modell die abgerufenen Abschnitte überprüft und sortiert.

Teilen Sie den Inhalt nach der Dokumentstruktur auf, anstatt feste Längen vorzusehen.

Überschreiben Sie vage Abfragen zu klareren.

Verfeinern Sie Zitate, indem Sie Quelltitel, Abschnitte und Links aufzeichnen.

Erstellen Sie Dashboards, um die Qualität im Laufe der Zeit zu überwachen.

Erweiterte Einstellungen beinhalten den Einsatz von Agenten, die Suche in mehreren Schritten oder über Graphen, Abfragen an strukturierte Datenbanken, die Suche in Bildern und Texten oder Neubewertungsfunktionen, die auf einen bestimmten Bereich abgestimmt sind. Jüngste Umfragen deuten darauf hin, dass sich das Feld von einfachen RAG-Systemen hin zu modularen Systemen entwickelt, bei denen Suche, Erstellung und Erweiterung separate, flexible Komponenten sind und kein einheitlicher Prozess. Dennoch bleibt der grundlegende Ablauf die Basis: Relevante Belege finden, sie an das Modell weiterleiten und die Antwort anhand dieser Belege überprüfen.

Warum es sich lohnt, es zu lernen

RAG hat an Bedeutung gewonnen, weil es einen praktischen Bedarf adressiert. Unternehmen, Forscher, Entwickler und Teams speichern bereits wertvolles Wissen in Dokumenten, Datenbanken, Handbüchern, Tickets und Notizen – ein Sprachmodell allein kann dieses Wissen nicht zuverlässig erkennen. RAG gibt dem Modell die Möglichkeit, nach Informationen zu suchen.

Das Verfahren selbst ist einfach: Dokumente vorbereiten, sie aufteilen, die Teile einbetten und speichern, die richtigen Teile abrufen und anschließend das Modell dazu bringen, darauf zu antworten. Die Kunst liegt in den Details, wo Qualität der Quellen, Aufteilung in Abschnitte, Abrufverfahren, Gestaltung der Anfragen, Bewertung und Sicherheit entscheidend sind. Ein grundlegender Ablauf ist zwar nicht die endgültige Form eines intelligenten Assistenten, bleibt aber einer der einfachsten Wege zu einem nützlicheren, aktuelleren und besser fundierten KI-System. Anstatt vom Modell zu verlangen, ein allwissender Orakel zu sein, gibt RAG ihm eine Bibliothekskarte und lehrt es, die Bibliothek gut zu nutzen.