RAG (Retrieval-Augmented Generation) Revisited

Woran sind wir gewöhnt, wenn wir LLM-basierte Anwendungen implementieren?

Mit dem schnellen Fortschritt von KI - insbesondere Large Language Models (LLMs) - haben sich einige Designmuster als Standard für die Entwicklung von KI-Anwendungen etabliert. Eines der populärsten ist RAG (Retrieval-Augmented Generation). Falls du mit RAG nicht vertraut bist (was heutzutage eher unwahrscheinlich ist), hier eine kurze Zusammenfassung:

RAG ist eine Technik, um relevante externe Informationen in LLMs einzubringen und so die Genauigkeit und Fundierung ihrer Antworten zu verbessern.

LLMs werden auf öffentlich verfügbaren Daten trainiert, was bedeutet, dass ihnen typischerweise Wissen über interne oder private Informationen fehlt. Ein gut implementiertes RAG-System schließt diese Lücke, indem es dem Modell relevante Ausschnitte solcher Daten bereitstellt und damit seine Fähigkeit erhöht, präzise, kontextbezogene und quellengestützte Ausgaben zu erzeugen.

Als RAG seinen Wert bewiesen hatte, übernahmen Entwickler:innen es schnell als Standard für LLM-basierte Apps.

Die sich rasant entwickelnde LLM-Landschaft brachte zahlreiche Frameworks und Tools hervor, die Teams häufig zu individuellen „DIY“-RAG-Systemen kombinierten. Frühe Prototypen sehen meist großartig aus - aber sie in die Produktion zu bringen? Das ist eine andere Geschichte.

In diesem Beitrag sehen wir uns an, warum individuelle RAG-Systeme oft enttäuschen und welche einfacheren, modernen Alternativen schneller Wert liefern können.

Warum können individuelle RAG-Systeme enttäuschen?

Ein RAG-System zu starten, wirkt täuschend einfach. Man wählt eine Vektordatenbank, einen LLM-Anbieter für Embedding- und Chat-Completion-Modelle sowie ein Framework, das alles verbindet. Nach ein wenig Code hat man einige Testdokumente geladen, und das Endprodukt - vielleicht ein Chatbot - kann Fragen zu diesen Dokumenten beantworten.

Wenn das dein mentales Bild von RAG in der Praxis ist, lohnt es sich, einige typische Fallstricke zu betrachten:

• Datenextraktion und -aufbereitung: Einige wenige Dokumente zu laden, ist einfach; viele unordentliche, inkonsistente hingegen nicht. Dein Input kann voller irrelevanter Inhalte sein, die das System verlangsamen und die Antwortqualität verschlechtern. Jeder Edge Case wird zu einem Problem, das individuelle Parsing-Logik erfordert. Die Unterstützung verschiedener Dateiformate - insbesondere nicht-textbasierter wie Bilder - erhöht die Komplexität zusätzlich. Selbst wenn das alles funktioniert, musst du weiterhin mit Chunking-Strategien und Embedding-Modellen experimentieren.

  
  

• Veraltete Daten: Sobald dein System live ist, müssen die zugrunde liegenden Daten ständig aktualisiert werden. Eine robuste, effiziente und zuverlässige Ingestion-Pipeline ist entscheidend. Sie erfordert starke Data-Engineering-Skills und fortlaufende Wartung. Viele Teams unterschätzen diesen Aufwand, besonders wenn organisatorische Daten schlecht strukturiert sind oder nicht für automatisierte Verarbeitung bereitstehen.

  
  

• Kosten: Über Infrastruktur- und Betriebskosten hinaus erfordern RAG-Projekte oft spezielles Fachwissen, um Qualität und Leistung aufrechtzuerhalten. Mit der Größe und Komplexität deiner Daten steigen die Kosten schnell.

Gibt es einfachere Wege?

Wie wir gesehen haben, ist der Bau eines individuellen RAG-Systems von Grund auf selten einfach. Es braucht Zeit, Expertise und viele Iterationen, um es richtig hinzubekommen.

Sehen wir uns einige Alternativen an, die helfen können, kontextbewusste Anwendungen schneller und mit weniger Aufwand zu entwickeln.

RAG as a Service

Große Cloud- und KI-Anbieter bieten inzwischen verwaltete RAG-Services an. Diese rechnen typischerweise auf Basis des Datenvolumens ab (z. B. verarbeitete Tokens oder API-Aufrufe). Auch wenn sie zunächst teurer wirken mögen, erweisen sie sich langfristig oft als kosteneffizienter, da sie viele der Integrations- und Wartungsprobleme eliminieren.

Moderne Angebote sind vollgepackt mit Funktionen und Flexibilität, sodass Teams Anpassbarkeit mit Einfachheit kombinieren können. Entwickler:innen können Out-of-the-Box-Tools mit eigenen Komponenten mischen - basierend auf einer fertigen RAG-Engine. Solche Services automatisieren die Datenaufnahme, optimieren Chunking und Embeddings und stellen APIs für das Abfragen der Daten bereit. Plattformen sind zum Beispiel:

• Amazon Bedrock oder Google Vertex AI für nahtlose Cloud-Integration

• OpenAI’s Assistants API oder Google Gemini File Search für direkten Zugriff auf LLM-native RAG-Fähigkeiten

  
  

Diese Lösungen ermöglichen es dir, dich auf Wertschöpfung statt Infrastruktur zu konzentrieren.

Live-Websuche als Kontextquelle

Um Datenveraltung entgegenzuwirken, ist eine wirksame Option, Live-Websuche zu nutzen, um LLM-Antworten zu erweitern. Suchmaschinen sind exzellente und bewährte Werkzeuge für Informationsabruf und bieten - entscheidend - Zugang zu den neuesten Informationen. Das Web enthält riesige Mengen relevanter Dokumente (einschließlich weniger offensichtlicher Perlen wie PDFs auf Webseiten).

Du könntest dir Sorgen machen, dass dies neue Probleme wie Rauschen oder unstrukturierte Ergebnisse bringt, aber spezialisierte APIs können helfen. Zum Beispiel liefert die Perplexity Search API strukturierte Textausschnitte mit Metadaten für eine bestimmte Anfrage. Entwickler:innen können sogar Domain-Einschränkungen oder Zeitbereiche konfigurieren, um Ergebnisse zu filtern.

Dieser Ansatz lässt sich leicht in bestehende RAG-Systeme integrieren, entweder als Ersatz für die Vektordatenbanksuche oder als Ergänzung für aktuellere Ergebnisse. Ein noch einfacherer Ansatz kann sein, grounded LLM model responses zu verwenden, bei denen der Anbieter Suche und Kontextanreicherung im Hintergrund übernimmt. Die Antwort ist das LLM-Ergebnis, ergänzt durch Metadaten zu den verwendeten Quellen. Beispiele dafür sind Gemini Grounding mit Google Search oder Perplexity Chat API.

Hybride Ansätze

Beide Ansätze haben Stärken und Schwächen.

• RAG auf Basis interner Daten bleibt essenziell für sensible oder proprietäre Informationen.

• Managed Services beschleunigen die Time-to-Market und reduzieren Wartungsaufwand.

• Live-Webkontext hält Ausgaben aktuell und vielfältig.

  
  

Die Kombination kann kosteneffiziente, hochwertige Ergebnisse liefern. Auch wenn sich dieser Beitrag auf praktische, schnelle Verbesserungen für traditionelle RAG-Systeme konzentriert, ist es erwähnenswert, dass es fortschrittlichere Methoden gibt - wie das Abfragen relationaler Datenbanken, Tabellen oder sogar den Einsatz autonomer Agenten, die Code oder SQL ausführen. Diese Techniken haben großes Potenzial, bringen jedoch auch ihre eigenen Komplexitäten und Risiken mit sich.

Fazit

In diesem Beitrag haben wir untersucht, warum individuelle RAG-Implementierungen oft enttäuschen und wie verwaltete RAG-Services und Live-Websuche die Entwicklung vereinfachen und gleichzeitig die Ergebnisse verbessern können. Probiere neue Tools aus, experimentiere mit modernen APIs und entdecke, wie viel schneller du Kontext in echten Wert verwandeln kannst.