Inhalt
In unserem vorherigen Blogartikel „Geschäftspotenziale mit LLMs und KI-Agents nutzen“ haben wir uns mit Large Language Models (LLMs) und ihrem wachsenden Einfluss auf Geschäftsprozesse beschäftigt. Heute gehen wir einen Schritt weiter und betrachten einen spezifischen und hochgradig praxisnahen Anwendungsfall: Retrieval-Augmented Generation RAG (Abrufgestützte Generierung). RAG verbindet das Sprachverständnis von LLMs mit einer gezielten Abfrage Ihrer eigenen Daten und ermöglicht so schnellere, präzisere und kontextbewusste Antworten.
Warum RAG?
Wie wir bereits besprochen haben, sind LLMs leistungsstarke Werkzeuge, wenn es um die Arbeit mit Textinformationen geht. Dennoch gibt es in geschäftlichen Kontexten mehrere Einschränkungen:
Statisches Wissen
LLMs sind „eingefrorene“ Objekte. Mit „eingefroren“ ist gemeint, dass das Modell seinen Trainingsdatensatz nicht eigenständig aktualisieren kann. Das bedeutet, dass der Wissensstand statisch ist und sich immer auf einen bestimmten Zeitpunkt in der Vergangenheit bezieht. Das lässt sich leicht überprüfen, indem man ein beliebtes LLM nach einem kürzlich eingetretenen Ereignis fragt – mit hoher Wahrscheinlichkeit erhält man die Antwort, dass das Modell darüber keine Informationen besitzt oder nur bis zu einem bestimmten Datum trainiert wurde (es sei denn, das LLM verfügt über Web-Suchfunktionen). Ein regelmäßiges Neutraining, beispielsweise jede Woche, ist sehr aufwendig, da es Zeit, erhebliche Rechenressourcen und ein großes Budget erfordert.
Halluzinationen (KI)
Wie wir bereits im Artikel über LLMs erwähnt haben, neigen Sprachmodelle aufgrund ihrer stochastischen Natur und der begrenzten Kontextlänge (ein bei modernen State-of-the-Art-Modellen weniger relevantes, aber bei vielen kleineren bis mittelgroßen Modellen weiterhin bestehendes Problem) manchmal zu sogenannten Halluzinationen. Von einer „Halluzination“ spricht man, wenn ein LLM beginnt, fiktive Inhalte zu erfinden, die zu einer unzuverlässigen Antwort auf die Eingabe des Nutzers führen. Selbst wenn man eine große Menge Text in das Modell kopiert, wird es nach einer Weile beginnen, frühere Informationen zu „vergessen“ und zu halluzinieren.
Eingeschränkter Zugriff auf private Daten
Zuletzt ist zu erwähnen, dass die Trainingsdaten bzw. die Wissensbasis eines LLMs aus öffentlich zugänglichen Quellen wie dem Internet oder spezifischen Datensätzen bestehen. Das bedeutet, dass ein LLM keine Antworten geben kann, wenn man es zu Inhalten befragt, die nicht öffentlich verfügbar sind (zum Beispiel ein Dokument, das nur lokal auf Ihrem Laptop gespeichert ist).
RAG mindert diese Probleme, indem es die Textverarbeitungsleistung des Modells mit relevantem, dynamischem Kontext aus Ihren eigenen Datenquellen ergänzt.
Was ist RAG und wie unterscheidet es sich von einem einfachen LLM?
Ein typischer Ablauf bei der Nutzung eines LLM sieht folgendermaßen aus:
Frage → Antwortgenerierung
RAG integriert hingegen einige zusätzliche Schritte:
Frage → Abruf relevanten Kontexts → Generierung → Antwort mit Quelle
Ein praktisches Beispiel für RAG:
Benutzerfrage
- Eine Person fragt die KI etwas, zum Beispiel: „Wie lautet unsere Elternzeitregelung im Unternehmen?“
Retrieval (Abruf)
- Das System durchsucht die Wissensdatenbank des Unternehmens und zieht die relevantesten Passagen heraus (z. B. das HR-Policy-Dokument).
Generierung
- Die KI kombiniert die abgerufenen Informationen mit ihren Sprachfähigkeiten und formuliert eine klare, kontextbezogene Antwort (z. B.: „Unsere Elternzeitregelung sieht 16 Wochen bezahlte Freistellung für Hauptbetreuungspersonen und 8 Wochen für sekundäre Betreuungspersonen vor.“).
Antwort mit Kontext
- Die KI antwortet und zeigt die Quelle an (z. B. Link zum HR-Policy-Dokument).
Dieser Ansatz gewährleistet Genauigkeit, Relevanz, Effizienz und Transparenz.
Lassen Sie uns nun Schritt für Schritt das RAG-Framework betrachten und herausfinden, wie es funktioniert.
Alles beginnt mit einer Retrieval-Komponente, also dem Festlegen der Daten, die für die Beantwortung einer Anfrage herangezogen werden sollen. Der erste Schritt besteht darin, unsere Datenquelle vorzubereiten. Wie bereits erwähnt, müssen wir nur die relevanten Informationen aus der Quelle extrahieren. Das bedeutet, dass wir das gesamte Dokument in kleinere Teile aufteilen müssen. In der RAG-Terminologie wird dies Chunking genannt. Es gibt verschiedene Strategien, wie Chunking durchgeführt werden kann. Der Einfachheit halber teilen wir die Dokumentation hier in Absätze auf.
Nach dem Chunking folgt der sogenannte Embedding-Prozess. Anders als beim Token-Embedding in LLMs betten wir dabei ganze Textstücke (Chunks) ein und kodieren deren semantische Bedeutung. Dieser Schritt ermöglicht es dem Framework, zu einer Benutzeranfrage passende Textstücke zu finden. Wenn ein Benutzer also eine Eingabe an RAG stellt, wird diese ebenfalls durch dasselbe Embedding-Modell geleitet. Die Idee der kontextbezogenen Suche ist recht einfach: Die Frage und die passende Antwort sollten ähnliche Embeddings haben (ähnlich kodierte Texte beschreiben verwandte Informationen). Sobald der benötigte Kontext gefunden ist, kann der Augmentation-Prozess beginnen.
Die Augmentation ist unkompliziert: Man übergibt dem LLM ein einziges Prompt, das sowohl die Anfrage des Benutzers als auch die abgerufenen Inhalte enthält, und fordert es auf, mit Hilfe dieser kontextbezogenen Informationen zu antworten.
Im letzten Schritt erfolgt die Antwortgenerierung – ein Routineprozess eines LLM. Das Modell nimmt das Eingabe-Prompt und erstellt eine kohärente Antwort in natürlicher Sprache. Zusätzlich kann es auch die verwendeten Quellen in der Antwort angeben.
Die Vorteile von RAG
Die Implementierung von RAG bringt für Unternehmen zahlreiche Vorteile:
- Genauigkeit: Indem nur kontextbezogene Informationen an das LLM weitergegeben werden, verringert sich das Risiko falscher Antworten und Halluzinationen.
- Relevanz: Antworten basieren auf Ihren spezifischen Inhalten statt auf allgemeinem Web-Wissen.
- Effizienz: Nutzer sparen Zeit, da sie nicht mehr manuell Dokumente durchsuchen müssen.
- Vertrauen: Quellenangaben erleichtern die Überprüfung der Richtigkeit von Antworten.
- Datenschutz: Selbst gehostete RAG-Pipelines können sensible interne Daten schützen und eine Weitergabe an Dritte verhindern.
Best Practices und technische Überlegungen
Sicherstellen einer hohen Datenqualität
Moderne RAG-Systeme arbeiten mit unterschiedlichen Arten von Informationen. Das können Textdaten sein, die als Microsoft-Office-Dokumente, Präsentationen, Excel-Tabellen, PDFs oder Markdown-Dateien gespeichert sind – in manchen Fällen sogar Bilder. Unabhängig von der Art der Quelle gilt jedoch ein Grundprinzip: „Garbage in, garbage out“.
Ihre Organisation kann ein hochmodernes RAG-System implementieren – doch wenn die Kontextdaten von schlechter Qualität sind, ist eine gute Performance kaum möglich. Deshalb ist es wichtig, schon vor dem Einsatz von KI-Tools die Datenlage zu prüfen. Schritte wie Preprocessing, das Anreichern von Datenfeldern und das Zusammenführen von Informationen aus mehreren Quellen können die Leistung Ihrer RAG-Pipeline erheblich verbessern. Zusätzlich ist es hilfreich, die Daten mit Metadaten zu versehen, die Eigenschaften beschreiben – etwa Erstellungsdatum, Titel oder weitere beschreibende Merkmale.
Im vorherigen Abschnitt haben wir nur den semantischen Suchprozess mittels Embeddings behandelt. In modernen RAG-Systemen ist es jedoch üblich, dies mit zusätzlichen Suchmechanismen wie Metadaten-Abfragen oder sogar Volltextsuche zu kombinieren. Es ist von Vorteil, mehrere Wege zu nutzen, um relevanten Kontext zu finden.
Eine gute Suche mit einem mittelmäßigen Modell ist besser als eine mittelmäßige Suche mit einem guten Modell
Wenn Sie in Erwägung ziehen, Open-Source-LLMs als Alternative zu API-Anbietern einzusetzen, sollten Sie Ihre Zeit und Ressourcen lieber in die Verbesserung des Retrieval-Teils von RAG investieren als in den Generierungsteil.
Schon kleine (<7B Parameter) und mittelgroße (7B–20B Parameter) Sprachmodelle sind in der Lage, bei gut aufbereitetem Kontext qualitativ hochwertige Ergebnisse zu liefern. Doch selbst das beste Modell kann das Fehlen relevanten Kontexts nicht kompensieren.
Entwicklung einer Response-Policy
Natürlich kann es Situationen geben, in denen Ihre RAG-Pipeline keine Antwort auf die Benutzeranfrage findet. Dafür kann es mehrere Gründe geben – von einem schlichten Fehlen der Information in den Quellen bis hin zu Problemen innerhalb der Retrieval-Pipeline. Zunächst ist es sinnvoll, ein Monitoring-System zu haben, das solche Fälle identifiziert. Darüber hinaus sollte man jedoch auch an die Benutzererfahrung denken. So können beispielsweise benutzerfreundliche Fallback-Nachrichten implementiert werden, wie etwa: „Wir konnten keine exakte Antwort finden. Bitte wenden Sie sich an unser Support-Team.“
Use Cases
SAP Joule
SAP Joule bietet mit Document Grounding eine auf RAG basierende Funktion, die den Joule Assistant mit Unternehmensdaten verbindet. Mit Document Grounding können Sie beispielsweise Microsoft SharePoint als Datenquelle einbinden und verschiedene Textdateien wie DOCX, PDF, TXT oder JSON nutzen. Zudem ist es möglich, reinen Text aus Formaten wie PNG, JPG oder TIFF zu extrahieren (wichtig: Tabellen und Bilder innerhalb von Dokumenten werden derzeit noch nicht unterstützt). Darüber hinaus lässt sich auch SAP Build Work Zone als Datenquelle konfigurieren – mit ähnlichen Dateiformaten sowie Blogartikeln und Knowledge-Base-Beiträgen. Insgesamt können bis zu 2.000 Dokumente hochgeladen werden.
Mit Document Grounding können Unternehmen interne Dokumente mit einer RAG-gestützten KI abfragen und so schnelle, relevante und präzise Antworten innerhalb des SAP-Ökosystems sicherstellen.
Einen Einblick in die Funktionsweise von SAP Joule Document Grounding finden Sie hier:
https://www.sap.com/assetdetail/2024/09/10718415-d97e-0010-bca6-c68f7e60039b.html
NotebookLM
Ein weiteres prominentes Beispiel für eine RAG-gestützte Anwendung ist NotebookLM. Entwickelt von Google, handelt es sich dabei um einen KI-Forschungsassistenten, der individuell an die eigenen Informationsquellen angepasst werden kann. Mit dieser Anwendung lassen sich relevante Dokumente hochladen und anschließend mit den LLMs von Google interagieren. Das Tool liefert direkte Referenzen aus den hochgeladenen Dokumenten, wodurch die Präzision steigt und das Vertrauen in die Antworten des LLMs gestärkt wird.
Darüber hinaus bietet NotebookLM zusätzliche Funktionen wie die Erstellung von Mindmaps, Berichten, Audio-Podcasts, Videoübersichten und vieles mehr.
Fazit
Large Language Models (LLMs) beeindrucken mit ihrer generativen Leistungsfähigkeit, sind jedoch durch statische Trainingsdaten und das Risiko von Ungenauigkeiten eingeschränkt. Retrieval-Augmented Generation (RAG) gleicht diese Schwächen aus, indem es LLMs mit dynamischen, aktuellen Wissensquellen anreichert – und so präzisere, verlässlichere und nachvollziehbarere Ergebnisse ermöglicht. In der Praxis sollten LLMs und RAG nicht als Konkurrenten, sondern als komplementäre Ansätze betrachtet werden: Während LLMs in Kreativität und Sprachfluss überzeugen, sorgt RAG für Genauigkeit und Relevanz in wissensgetriebenen Kontexten.
Bei PIKON unterstützt Sie unser Data-Science-Team dabei, den richtigen Ansatz für Ihren individuellen Anwendungsfall zu finden. Ob Sie RAG einsetzen, die Nutzung von LLMs optimieren oder eine maßgeschneiderte KI-Lösung entwickeln möchten – wir helfen Ihnen, diese Technologien in echten Geschäftswert zu verwandeln.
Kontakt
