Retrieval Augmented Generation (RAG) ist ein überlasteter Begriff. Es verspricht die Welt, aber nach der Entwicklung einer RAG-Pipeline fragen sich viele von uns, warum sie nicht so gut funktioniert, wie wir es erwartet hatten.
Wie bei den meisten Werkzeugen ist RAG einfach zu bedienen, aber schwer zu meistern. Die Wahrheit ist, dass bei RAG mehr dazu gehört, Dokumente in eine Vektordatenbank zu legen und dann einen LLM hinzuzufügen. Das kann funktionieren, aber es klappt nicht immer.
Dieses E-Book soll Ihnen sagen, was zu tun ist, wenn die Out-of-the-Box-RAG nicht funktioniert. In diesem ersten Kapitel werden wir uns ansehen, was oft die einfachste und schnellste Lösung für suboptimale RAG-Pipelines ist – wir werden etwas über Neusortierer lernen.
Video-Begleiter für dieses Kapitel.
Rückruf vs. Kontextfenster
Bevor wir zur Lösung übergehen, wollen wir über das Problem sprechen. Mit RAG führen wir eine semantische Suche in vielen Textdokumenten durch – diese könnten zehntausende bis zu zehn Milliarden Dokumente sein.
Um schnelle Suchzeiten im großen Maßstab zu gewährleisten, verwenden wir in der Regel die Vektorsuche - das heißt, wir transformieren unseren Text in Vektoren, platzieren sie alle in einem Vektorraum und vergleichen ihre Nähe zu einem Abfragevektor mithilfe einer Ähnlichkeitsmetrik wie der Kosinus-Ähnlichkeit.
Um die Vektorsuche zu ermöglichen, benötigen wir Vektoren. Diese Vektoren sind im Wesentlichen Kompressionen der 'Bedeutung' eines Textes in (typischerweise) 768 oder 1536-dimensionale Vektoren. Es tritt ein gewisser Informationsverlust auf, da wir diese Informationen in einen einzigen Vektor komprimieren.
Aufgrund dieses Informationsverlusts sehen wir oft, dass die drei besten (zum Beispiel) Vektorsuchdokumente relevante Informationen verpassen. Leider kann die Abfrage relevante Informationen unterhalb unseres top_k-Grenzwerts zurückgeben.