RAG ist einfacher als du denkst: 6 Architekturen ohne Over-Engineering
RAG Is Simpler Than You Think
Viele Teams überkomplizieren ihre RAG-Systeme mit Embeddings, Vektor-Datenbanken und Reranking-Pipelines, obwohl die Nutzer oft nur ein Dokument suchen, das erklärt, wie man das Passwort zurücksetzt. Dieser Artikel zeigt einen pragmatischen Ansatz: Sechs RAG-Architekturen, von einfacher Volltextsuche (BM25) über Query Rewriting mit LLMs bis hin zu Hybrid-Suche, On-the-fly-Embeddings, Hot/Cold-Tiers und vollständiger Vorab-Embedding. Für jede Architektur werden die passenden Bedingungen beschrieben – etwa Datenaktualität, Korpus-Eigenschaften, Query-Muster, Skalierung und Team-Fähigkeiten. Der Autor betont, dass man mit BM25 und Query Rewriting oft 90 % der Probleme löst, und warnt vor unnötiger Komplexität, wie sie bei Modell-Deprecations oder hoher Dokumentfluktuation entsteht.
Die meisten Probleme der 'semantischen Suche' sind eigentlich Probleme der Query-Formulierung.
- usernametaken29
Ich habe an großen RAG-Systemen gearbeitet und kann sagen, dass die Leute die Volltextsuche massiv unterschätzen und Embeddings massiv überschätzen. Volltextsuche ist wirklich einfach, portabel und skalierbar und bringt einen sehr weit – die 80/20-Regel gilt. Embeddings wirken nett und magisch, aber wenn man sich wirklich damit beschäftigt, merkt man: Semantische Ähnlichkeit ist nicht so gut, wie man denkt, und sie wird sicherlich nicht alle glücklich machen. Man landet unweigerlich dabei, mehr oder andere Textabschnitte neu zu embedden, um eine immer präzisere Embedding-Suche zu ermöglichen – und an dem Punkt geht man die letzte Meile und macht Reranking usw., während man die ganze Zeit den operativen Aufwand der Vektorsuche stemmen muss.
Dann dreht man sich um und baut eine Suchanfrage mit 500 Keywords – sicher, das ist mühsam, aber es funktioniert einfach, deckt alle Anwendungsfälle ab, skaliert und ist insgesamt weniger nervig zu warten.
- alansaber
Ich habe Systeme mit all diesen Ansätzen gebaut (alle parallel). Meistens ist der Aufwand den Nutzen nicht wert (eine hochoptimierte korpus-spezifische Informationsabrufstrategie zu bauen), abgesehen von einigen wenigen Randfällen. Die Menge an technischer Diskussion übersteigt den Anwendungsfall für RAG bei weitem.
- jillesvangurp
RAG ist im Grunde die gute alte Informationssuche, bei der LLMs die Abfrage übernehmen. Das kann Vektorsuche beinhalten, funktioniert aber auch ohne. Vektorsuche als magische Feenstaub zu behandeln, der die Suche ohne Aufwand großartig macht, wird nicht unbedingt gut funktionieren. Außerdem kann es viel Kosten und Komplexität in die Gleichung bringen. Und wenn es nicht richtig abgestimmt ist, bekommt man nicht unbedingt gute Ergebnisse.
Der Schlüssel bei RAG ist, die richtigen Informationen mit so wenigen Abfragen wie möglich in den Kontext zu bekommen. Das erfordert gute Recall (sicherstellen, dass, wenn es da ist, es mit einer vernünftigen Abfrage gefunden werden kann) und Präzision (sicherstellen, dass das Beste oben ist und falsch-positive Ergebnisse minimiert werden).
Bei der Suche, und damit auch bei RAG, gilt das Prinzip: Müll rein, Müll raus. Das meiste, was Suchteams vor KI und RAG gemacht haben, ist immer noch der beste Weg, die Erfahrung mit RAG zu optimieren. Und wenn man das vermasselt, wird die Suche nicht gut funktionieren, und keine Menge KI kann das ausgleichen – oder nur zu hohen Kosten in Tokens und Zeit. Daher sind eine ETL-Pipeline zur Vorverarbeitung des Indexierten, das Testen und Benchmarking der Suchqualität usw. alle hilfreich.
Die gute Nachricht ist, dass man nicht viel Können im agentischen Programmieren braucht, um etwas halbwegs Anständiges zu bauen. Dieser Code schreibt sich fast von selbst. Und selbst ein wenig Aufwand, um vor dem Indexieren Struktur zu extrahieren, kann einen großen Unterschied machen.
- jrochkind1
Mehr LLM-generierter Text über LLMs.
Findet sonst noch jemand, dass es immer schwerer wird, LLM-generierten Text zu lesen? Ich finde es ziemlich anstrengend, mein Gehirn will einfach nicht durchkommen.
- Angostura
Ich habe eine besondere Abneigung gegen Artikel, die zu faul sind, Akronyme bei der ersten Verwendung auszuschreiben.
Also: https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- yipinwong
Nur diejenigen, die das Handwerk beherrschen, lassen ihre Arbeit einfach aussehen.
Die KI, die das geschrieben hat, könnte der Meister sein, nicht der Autor, denn das sieht nach KI geschrieben aus.
Ich werde die Agenten des Autors nutzen, nicht seine Artikel lesen oder ihn für den Job engagieren.
- refactor_master
Hier ist ein noch einfacherer Ansatz: Einfach beim ersten Mal alles embedden und dann nachverfolgen, was geändert wurde. Verwende ein billiges Modell, um die Dokumente/Chats mit Zusammenfassung und Schlüsselwörtern zusammenzufassen und zu bereinigen. Es sei denn, du hast ganze Bibliotheken von Büchern zum Embedden – dann sind das ein paar hundert Dollar an API-Aufrufen.
Dann wirf alles in BigQuery. Das erledigt das gesamte Vektorzeugs nativ.
Setze eine agentische Bot-Oberfläche obendrauf, damit es allwissend und magisch wirkt.
Ich nehme an, andere Anbieter als Google haben einen ähnlichen Ansatz mit allem Drum und Dran, den man einfach einstecken kann.
- klm127
RAG steht für Retrieval Augmented Generation. Der Zweck ist, einen Textkorpus nach Bedeutung zu durchsuchen, nicht nach exakter Übereinstimmung.
Ich musste es nachschlagen.