Retrieval-Augmented Generation: Warum KI manchmal erst nachschlagen muss
Retrieval-Augmented Generation (RAG) erweitert generative KI um den Zugriff auf aktuelle oder spezifische Informationsquellen. Das kann deutlich nützlichere Antworten liefern als das alleinige Vertrauen auf das Trainingswissen des Modells.
Erkundung von Retrieval-Augmented Generation (RAG), wie es funktioniert und warum es nuetzlicher sein kann, einer KI den Zugriff auf die richtigen Informationen zu geben, als sich allein auf das zu verlassen, was sie bereits weiss.
Generative AI · Applied AI · Software Engineering
Haben Sie ChatGPT schon einmal eine Frage gestellt und eine Antwort erhalten, die unglaublich ueberzeugend klang, nur um spaeter festzustellen, dass sie voellig falsch war?
Interessant ist, dass eine KI etwas mit bemerkenswerter Sicherheit erklaeren kann, selbst wenn die Informationen nicht korrekt sind.
Anfangs dachte ich, die Loesung sei einfach: Man nehme einfach ein schlaueres oder neueres KI-Modell.
Doch als ich mich mehr mit Generative AI befasste, wurde mir klar, dass das Problem nicht so einfach lag.
Es gibt einen Unterschied zwischen einer KI, die gut darin ist, Antworten zu generieren, und einer KI, die tatsaechlich die richtigen Informationen besitzt, um eine Frage zu beantworten.
Genau da stiess ich auf einen Ansatz namens Retrieval-Augmented Generation, kurz RAG.
Sie verstehen viele Themen, koennen komplizierte Konzepte erklaeren und sind grossartig darin, Probleme zu loesen.
Aber es gibt eine Einschraenkung: Sie wissen nicht alles ueber Ihr Unternehmen.
Wie viele Tage Urlaub stehen den Beschaeftigten gemaess der neuesten Richtlinie unseres Unternehmens zu?
Diese Person versteht vielleicht allgemeine arbeitsrechtliche Bestimmungen. Sie wuesste aber nicht unbedingt die internen Richtlinien Ihres Unternehmens, zumal, wenn diese erst letzte Woche aktualisiert wurden.
Dasselbe passiert mit Large Language Models (LLMs).
Modelle wie GPT lernen beim Training Muster, Konzepte und Informationen. Dieses Wissen umfasst jedoch nicht automatisch interne Unternehmensdokumente, interne Richtlinien oder Informationen, die erst nach der Erhebung ihrer Trainingsdaten verfuegbar wurden.
Wenn ein Modell nicht ueber genuegend Informationen verfuegt, kann es manchmal eine falsche Antwort generieren, die dennoch voellig plausibel klingt.
Dieses Phaenomen ist allgemein als Halluzination bekannt.
Was waere also, wenn wir der KI die Richtliniendokumente des Unternehmens geben koennten, bevor wir sie auffordern, eine Antwort zu geben?
RAG ist ein Ansatz, der es einer KI-gestuetzten Anwendung ermoeglicht, relevante Informationen aus externen Quellen abzurufen, bevor diese Informationen als zusaetzlicher Kontext zur Generierung einer Antwort verwendet werden.
Das Konzept wurde 2020 in einer Forschungsarbeit von Patrick Lewis und seinen Kollegen vorgestellt.
Der Name klingt vielleicht kompliziert, aber wir koennen ihn in drei einfache Teile zerlegen:
Es gibt zwei Arten von Pruefungen: geschlossene Buecher und offene Buecher.
Bei einer Pruefung mit geschlossenen Buechern verlaesst man sich ausschliesslich auf das, was man gelernt und behalten hat.
Bei einer Pruefung mit offenen Buechern darf man vor dem Antworten nachschlagen.
Der Unterschied besteht darin, dass die KI nicht magisch weiss, wo jede Information gespeichert ist. Die Anwendung, die wir entwickeln, ist dafuer verantwortlich, die relevanten Informationen zu finden und bereitzustellen.
RAG bedeutet nicht, das KI-Modell neu zu trainieren.
Wir fuegen dem Modell kein neues Wissen dauerhaft hinzu. Wir geben ihm lediglich zusaetzliches Lesematerial, wenn es benoetigt wird.
Stellen wir uns vor, wir bauen einen internen Chatbot, der Beschaeftigten dabei hilft, Informationen aus Unternehmensdokumenten zu finden.
Das Unternehmen verfuegt ueber mehrere Dokumente zu Themen wie Jahresurlaub, Erstattungsrichtlinien und Richtlinien fuer die Arbeit von zu Hause.
Wie viele Tage Urlaub habe ich?
Ein vereinfachter RAG-Prozess wuerde ungefaehr so aussehen:
Die Anwendung erhaelt die Frage zum Jahresurlaub.
2. Das System sucht nach relevanten Informationen.
Statt sofort das LLM eine Antwort generieren zu lassen, durchsucht die Anwendung die Wissensbasis des Unternehmens.
3. Das System ruft relevante Inhalte ab.
Es findet einen Abschnitt der Urlaubsrichtlinie des Unternehmens, der besagt:
Festangestellte haben Anspruch auf 12 Tage Jahresurlaub pro Jahr.
4. Die Informationen werden dem LLM bereitgestellt.
Die Anwendung sendet sowohl die urspruengliche Frage des Beschaeftigten als auch die abgerufenen Richtlinieninformationen an das Modell.
Mithilfe des bereitgestellten Kontexts antwortet das Modell moeglicherweise:
Gemaess der Urlaubsrichtlinie des Unternehmens haben Festangestellte Anspruch auf 12 Tage Jahresurlaub pro Jahr.
Die oben genannte Richtlinie und die Zahlen sind fiktive Beispiele.
Woher weiß die Anwendung, welcher Teil der Unternehmensdokumente für die Frage des Mitarbeiters relevant ist?
An dieser Stelle wird es etwas technischer.
Nehmen wir an, das Unternehmen hat 500 PDF-Dokumente.
Es wäre offensichtlich keine gute Idee, jedes Mal alle 500 Dokumente an die KI zu senden, wenn jemand eine Frage stellt.
Das wäre ineffizient, teuer und würde möglicherweise die Menge an Informationen überschreiten, die das Modell in einer einzelnen Anfrage verarbeiten kann, was üblicherweise als Kontextfenster bezeichnet wird.
Stattdessen bereitet ein typisches RAG-System die Dokumente so auf, dass sie effizient durchsucht werden können.
Dahinter stecken einige wichtige Konzepte.
Wenn jemand nach something Jahresurlaub fragt, würde man ihm nicht das gesamte Buch in die Hand drücken und erwarten, dass er alles liest.
Man würde die relevante Seite oder den relevanten Absatz heraussuchen.
Das ist im Wesentlichen die Idee hinter Chunking.
Große Dokumente werden in kleinere Informationseinheiten unterteilt, die als Chunks bezeichnet werden.
Kleiner bedeutet jedoch nicht immer besser.
Wenn wir einen Absatz an der falschen Stelle aufteilen, könnten wir wichtigen Kontext verlieren.
Andererseits könnte ein Chunk, wenn er zu groß ist, viele unnötige Informationen enthalten.
Wie wir Dokumente also aufteilen, spielt tatsächlich eine Rolle.
Sobald Dokumente in Chunks unterteilt sind, können wir ein Embedding-Modell verwenden, um jeden Textabschnitt in eine numerische Darstellung umzuwandeln.
Denn Computer können diese numerischen Darstellungen vergleichen, um abzuschätzen, wie eng zwei Textabschnitte inhaltlich verwandt sind.
Betrachten wir zum Beispiel diese beiden Sätze:
"Wie viele Urlaubstage erhalten Mitarbeitende?"
"Anspruch auf Jahresurlaub für Mitarbeiter."
Sie verwenden unterschiedliche Wörter, aber sie sprechen über fast dasselbe.
Embeddings können einem System helfen, diese Beziehung zu erkennen, ohne sich vollständig auf exakte Stichwortübereinstimmungen zu verlassen.
Diese numerischen Darstellungen können in einer Datenbank oder einem Suchindex gespeichert werden, der Vektorähnlichkeitssuche unterstützt.
Wenn ein Nutzer eine Frage stellt, wird auch die Frage in ein Embedding umgewandelt.
Das System vergleicht dieses Embedding mit den gespeicherten Dokument-Embeddings, um die relevantesten Chunks zu finden.
Anschließend wird der Originaltext aus diesen Chunks dem LLM als Kontext übergeben.
Eine Sache, die erwähnenswert ist: RAG erfordert nicht immer eine Vektordatenbank.
Auch eine traditionelle Stichwortsuche oder eine Kombination aus Stichwort- und Vektorsuche, oft als hybride Suche bezeichnet, kann verwendet werden.
Das Ziel ist dasselbe: Informationen abrufen, die tatsächlich für die Beantwortung der Frage nützlich sind.
Das war eines der interessantesten Dinge, die ich gelernt habe.
Anfangs ging ich davon aus, dass die Übergabe der richtigen Dokumente an eine KI automatisch zu korrekten Antworten führen würde.
Stellen wir uns vor, jemand soll mithilfe eines Nachschlagewerks eine Frage beantworten.
Möglicherweise findet die Person die richtige Seite, versteht aber die Erklärung falsch.
Oder das Buch selbst enthält veraltete Informationen.
Dieselben Probleme können in einem RAG-System auftreten.
Stellen wir uns zum Beispiel vor, ein Mitarbeiter fragt nach der Urlaubsrichtlinie des Unternehmens für 2026, aber das Retrieval-System liefert ein Dokument aus dem Jahr 2024.
Die KI könnte eine Antwort generieren, die das abgerufene Dokument korrekt wiedergibt.
Diese Antwort könnte dennoch falsch sein, weil die Informationen veraltet sind.
Das bedeutet, dass die Qualität eines RAG-Systems nicht ausschließlich davon abhängt, wie leistungsstark das LLM ist.
Es hängt auch von der Qualität der Daten ab, davon, wie Dokumente aufbereitet werden, wie relevante Informationen abgerufen werden und wie das Modell angewiesen wird, diese Informationen zu nutzen.
RAG kann dazu beitragen, Halluzinationen zu reduzieren, aber es beseitigt sie nicht.
Als Webentwickler finde ich RAG besonders spannend, weil es uns ermöglicht, die Fähigkeiten von LLMs mit Daten zu verbinden, die bereits in einer Anwendung vorhanden sind.
Ein Unternehmen mit hunderten internen Dokumenten möchte beispielsweise möglicherweise einen Chatbot bauen, damit Mitarbeiter nicht manuell darin suchen müssen.
Ein Software-Engineering-Team möchte vielleicht einen Assistenten, der Fragen zur API-Dokumentation, zur Systemarchitektur oder zu Deployment-Richtlinien beantworten kann.
Eine Anwendung für den Kundensupport könnte Produktdokumentation abrufen, bevor sie Fragen von Kunden beantwortet.
Das sind Situationen, in denen der Zugriff auf externe Informationen die KI deutlich nützlicher machen kann.
Wenn wir etwas bauen, das Grammatik verbessert, Sätze umformuliert oder kreative Ideen generiert, könnte das Abrufen von Dokumenten wenig Mehrwert bieten.
RAG bringt zudem zusätzliche Komplexität mit sich.
Wir müssen unsere Daten aufbereiten und pflegen, einen Suchindex verwalten, Dokumentaktualisierungen behandeln und Informationen abrufen, wenn sie benötigt werden.
All dies kann sich auf die Komplexität der Anwendung, die Kosten und die Antwortzeiten auswirken.
Statt also sofort zu fragen: "Können wir RAG für dieses Projekt verwenden?"
sollte man eher fragen: "Muss unsere Anwendung tatsächlich dynamisch externe Informationen abrufen, um hilfreiche Antworten zu erzeugen?"
Wenn die Antwort ja lautet, könnte RAG gut passen.
Wenn nicht, könnte das Hinzufügen von RAG das System schlicht unnötig komplizierter machen.
Nachdem ich verstanden habe, wie RAG funktioniert, habe ich mir einige weitere Fragen gestellt.
Was, wenn die Dokumente gar nicht so groß sind?
Was, wenn Nutzer immer wieder Fragen zu denselben Informationen stellen?
Müssen wir wirklich jedes einzelne Mal, wenn jemand eine Frage stellt, nach relevanten Dokumenten suchen?
Diese Fragen führten mich zu einem anderen Ansatz namens Cache-Augmented Generation (CAG).
Während RAG darauf fokussiert ist, relevante Informationen abzurufen, wenn sie benötigt werden, verfolgt CAG die Idee, Kontext im Voraus vorzubereiten und ihn über Caching-Mechanismen wiederzuverwenden.
Beide Ansätze haben ihre eigenen Vorteile, Einschränkungen und Kompromisse.
Ich finde den Vergleich interessant, weil es nicht einfach darum geht, welche Technologie besser ist.
Es geht darum zu verstehen, wie unterschiedliche Ansätze zu unterschiedlichen Dateneigenschaften und Anwendungsanforderungen passen.
Das möchte ich im nächsten Artikel genauer untersuchen.
Das Lernen über RAG hat verändert, wie ich über den Bau KI-gestützter Anwendungen denke.
Zuvor neigte ich dazu anzunehmen, dass die Qualität einer KI-Anwendung hauptsächlich vom Modell dahinter abhängt.
Ein intelligenteres Modell sollte doch bessere Ergebnisse liefern, oder?
RAG zeigt, dass die Qualität eines KI-Systems auch davon abhängt, wie wir dem Modell Informationen bereitstellen.
Selbst ein leistungsfähiges Modell kann eine schlechte Antwort liefern, wenn der Kontext falsch ist.
Umgekehrt kann der Zugriff auf relevante, gut strukturierte Informationen die Chancen eines Modells auf eine hilfreiche Antwort deutlich verbessern.
Als Softwareentwickler kommt mir diese Idee überraschend vertraut vor.
Wir bauen bereits gewohnt Systeme, die Daten abrufen, verarbeiten und Nutzern hilfreiche Ergebnisse zurückgeben.
RAG überträgt ein ähnliches Muster auf Generative AI, wobei das LLM als Komponente fungiert, die Kontext interpretiert und Antworten in natürlicher Sprache erzeugt.
Letztlich geht es beim Bau einer KI-Anwendung nicht nur darum, ein Modell fähig zu machen, Fragen zu beantworten. Es geht auch darum sicherzustellen, dass das Modell die richtigen Informationen hat, um sie zu beantworten.
Für mich ist das eine der wichtigsten Erkenntnisse aus dem Verständnis von RAG.
Dies ist der erste Artikel meiner RAG-vs.-CAG-Explorationsreihe, geschrieben aus der Perspektive eines Softwareentwicklers, der mehr über Generative und Applied AI lernen möchte.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Exploring Retrieval-Augmented Generation (RAG), how it works, and why giving AI access to the right information can be more useful than relying solely on what it already knows.
Generative AI · Applied AI · Software Engineering
Have you ever asked ChatGPT a question and received an answer that sounded incredibly convincing, only to discover later that it was completely wrong?
What's interesting is that AI can explain something with remarkable confidence, even when the information isn't accurate.
At first, I thought the solution was simple: just use a smarter or newer AI model.
But as I started learning more about Generative AI, I realized the problem wasn't that straightforward.
There's a difference between an AI that's good at generating answers and an AI that actually has the right information to answer a question.
That's when I came across an approach called Retrieval-Augmented Generation, or simply RAG.
They understand many subjects, can explain complicated concepts, and are great at solving problems.
But there's one limitation: they don't know everything about your company.
"How many days of annual leave are employees entitled to under our company's latest policy?"
That employee might understand general labor regulations. However, they wouldn't necessarily know your company's internal policies, especially if those policies were updated last week.
The same thing happens with Large Language Models (LLMs).
Models like GPT learn patterns, concepts, and information during training. However, that knowledge doesn't automatically include private company documents, internal policies, or information that became available after their training data was collected.
When a model doesn't have enough information, it may sometimes generate an incorrect answer that still sounds perfectly reasonable.
This phenomenon is commonly known as hallucination.
So, what if we could give AI the company's policy documents before asking it to answer?
RAG is an approach that allows an AI-powered application to retrieve relevant information from external sources before using that information as additional context to generate a response.
The concept was introduced in a 2020 research paper by Patrick Lewis and his colleagues.
The name might sound complicated, but we can break it down into three simple parts:
There are two kinds of exams: closed-book and open-book.
In a closed-book exam, you rely entirely on what you've studied and remembered.
In an open-book exam, you're allowed to look things up before answering.
The difference is that the AI doesn't magically know where every piece of information is stored. The application we build is responsible for finding and providing the relevant information.
RAG doesn't mean retraining the AI model.
We're not permanently adding new knowledge to the model. We're simply giving it additional reading material when it needs it.
Imagine we're building an internal chatbot that helps employees find information from company documents.
The company has several documents covering things like annual leave, reimbursement policies, and work-from-home guidelines.
"How many days of annual leave do I get?"
A simplified RAG process would look something like this:
The application receives the question about annual leave.
2. The system searches for relevant information.
Instead of immediately asking the LLM to generate an answer, the application searches the company's knowledge base.
3. The system retrieves relevant content.
It finds a section of the company's leave policy that says:
"Permanent employees are entitled to 12 days of annual leave per year."
4. The information is provided to the LLM.
The application sends both the employee's original question and the retrieved policy information to the model.
Using the supplied context, the model might respond:
"According to the company's leave policy, permanent employees are entitled to 12 days of annual leave per year."
The policy and numbers above are fictional examples.
How does the application know which part of the company's documents is relevant to the employee's question?
That's where things get a little more technical.
Let's say the company has 500 PDF documents.
Obviously, sending all 500 documents to the AI every time someone asks a question wouldn't be a great idea.
It would be inefficient, expensive, and potentially exceed the amount of information the model can process in a single request, commonly known as its context window.
Instead, a typical RAG system prepares documents so they can be searched efficiently.
There are a few important concepts behind this.
If someone asks about annual leave, you wouldn't hand them the entire book and expect them to read everything.
You'd find the relevant page or paragraph.
That's essentially the idea behind chunking.
Large documents are divided into smaller pieces of information called chunks.
However, smaller doesn't always mean better.
If we split a paragraph in the wrong place, we might lose important context.
On the other hand, if a chunk is too large, it might contain lots of unnecessary information.
So, how we divide documents actually matters.
Once documents are divided into chunks, we can use an embedding model to convert each piece of text into a numerical representation.
Because computers can compare these numerical representations to estimate how closely related two pieces of text are in meaning.
For example, consider these two sentences:
"How many vacation days do employees get?"
"Annual leave entitlement for staff members."
They use different words, but they're talking about nearly the same thing.
Embeddings can help a system recognize this relationship without relying entirely on exact keyword matches.
Those numerical representations can be stored in a database or search index that supports vector similarity search.
When a user asks a question, the question is also converted into an embedding.
The system compares that embedding with the stored document embeddings to find the most relevant chunks.
Then, the original text from those chunks is passed to the LLM as context.
One thing worth mentioning: RAG doesn't always require a vector database.
Traditional keyword search or a combination of keyword and vector search, often called hybrid search, can also be used.
The goal is the same: retrieve information that's actually useful for answering the question.
This was one of the most interesting things I learned.
Initially, I assumed that giving an AI the correct documents would automatically produce correct answers.
Imagine asking someone to answer a question using a reference book.
They might find the correct page but misunderstand the explanation.
Or the book itself might contain outdated information.
The same problems can happen in a RAG system.
For example, imagine an employee asks about the company's leave policy for 2026, but the retrieval system returns a document from 2024.
The AI might generate an answer that accurately reflects the retrieved document.
However, that answer could still be wrong because the information is outdated.
This means the quality of a RAG system doesn't depend entirely on how powerful the LLM is.
It also depends on the quality of the data, how documents are prepared, how relevant information is retrieved, and how the model is instructed to use that information.
RAG can help reduce hallucinations, but it doesn't eliminate them.
As a web developer, I find RAG particularly interesting because it allows us to connect the capabilities of LLMs with data that already exists inside an application.
For example, a company with hundreds of internal documents might want to build a chatbot so employees don't have to search through them manually.
A software engineering team might want an assistant that can answer questions about API documentation, system architecture, or deployment guidelines.
A customer support application could retrieve product documentation before answering customer questions.
These are situations where having access to external information can make AI significantly more useful.
If we're building something that improves grammar, rewrites sentences, or generates creative ideas, retrieving documents might not provide much value.
RAG also introduces additional complexity.
We need to prepare and maintain our data, manage a search index, handle document updates, and retrieve information when it's needed.
All of these can affect application complexity, cost, and response time.
So instead of immediately asking, "Can we use RAG for this project?"
"Does our application actually need to retrieve external information dynamically to produce useful answers?"
If the answer is yes, RAG might be a good fit.
If not, adding RAG could simply make the system more complicated than necessary.
After learning how RAG works, I started thinking about a few other questions.
What if the documents aren't that large?
What if users repeatedly ask questions about the same information?
Do we really need to search for relevant documents every single time someone asks a question?
These questions led me to another approach called Cache-Augmented Generation (CAG).
While RAG focuses on retrieving relevant information when it's needed, CAG explores the idea of preparing context ahead of time and reusing it through caching mechanisms.
Both approaches have their own benefits, limitations, and trade-offs.
And I think comparing them is interesting because it's not simply about choosing which technology is better.
It's about understanding how different approaches fit different data characteristics and application requirements.
That's what I plan to explore in the next article.
Learning about RAG changed the way I think about building AI-powered applications.
Previously, I tended to assume that the quality of an AI application mostly depended on the model behind it.
A smarter model should produce better results, right?
RAG shows that the quality of an AI system also depends on how we provide information to that model.
Even a powerful model can produce a poor answer when the context is wrong.
On the other hand, giving a model access to relevant, well-organized information can significantly improve its chances of generating a useful response.
As a software developer, this idea feels surprisingly familiar.
We're already used to building systems that retrieve data, process it, and return useful results to users.
RAG brings a similar pattern into Generative AI, with the LLM acting as a component that interprets context and generates natural-language responses.
Ultimately, building an AI application isn't just about making a model capable of answering questions. It's also about making sure the model has the right information to answer them.
And for me, that's one of the most important lessons from understanding RAG.
This is the first article in my RAG vs. CAG exploration series, written from the perspective of a software developer learning more about Generative and Applied AI.