Verbesserung der RAG-Antworten: Eine gemessene Änderung nach der anderen

Eine erste RAG-Pipeline lässt sich leicht zusammenstellen: Dokumente laden, sie einbetten, die Vektoren speichern, einige Fragmente abrufen und diese an ein LLM übergeben. Sie läuft zwar, doch die Antworten sind oft falsch – selbst wenn das Dokument eindeutig die richtigen Informationen enthält. In den meisten Fällen liegt das Problem nicht am Modell; der Abrufschritt hat ihm nie den richtigen Kontext bereitgestellt. Diese Anleitung führt durch die wichtigsten Faktoren beim Abrufen von Informationen und vor allem durch eine systematische Methode, um herauszufinden, welche davon tatsächlich Ihrem System helfen.

Betrachten Sie schlechte Antworten zunächst als Abrufprobleme

Bevor Sie Prompts oder Modelle ändern, prüfen Sie, was für eine fehlerhafte Frage abgerufen wurde. Wenn der relevante Abschnitt im Kontext fehlt, wird keine Anpassung des Prompts die Antwort verbessern.

Trennen Sie die Inhalte an sinnvollen Grenzen

Die Größe der Blöcke hat eine überraschend große Auswirkung auf die Qualität der Extraktion. Zu große Blöcke vermischen mehrere Themen, wodurch ihre Embeddings vage werden und unverwandter Text mit eingebunden wird. Zu kleine Blöcke trennen Sätze vom Kontext, der ihnen Bedeutung verleiht. Anstatt blind alle 500 Zeichen zu teilen, sollten verwandte Absätze oder ganze Abschnitte zusammengehalten werden, und Überschriften sowie Absatzzeilen als natürliche Trennpunkte genutzt werden.

Tune top_k anstelle davon, es zu erraten

Viele Pipelines holen die fünf am ähnlichstenen Abschnitte ab, einfach weil fünf eine gängige Standardwert ist. Der richtige Abschnitt kann jedoch an Position sechs oder sieben liegen. Die Erhöhung von top_k kann die Trefferquote verbessern, doch jeder zusätzliche Abschnitt fügt dem Prompt auch mehr Rauschen und Token hinzu. Betrachten Sie top_k als Parameter, den Sie anhand Ihrer eigenen Fragen testen sollten, und nicht als konstanten Wert, den man einfach übernimmt. Relevanzschwellwerte sind eine weitere Option, die in „Beyond Top-K: Relevanzschwellwerte, hybride Suche und Neubewertung“ erläutert wird.

Eine Neubewertungsstufe hinzufügen

Die Vektorsuche ist schnell, aber grob: Sie eignet sich gut dazu, plausible Kandidaten zu finden, ist jedoch weniger geeignet, um festzustellen, welcher tatsächlich am besten ist. Ein Reranking-Modul führt eine zweite Durchlauf durch. Zunächst liefert die Vektorsuche eine größere Menge an Ergebnissen, vielleicht zehn Blöcke. Anschließend bewertet ein Reranking-Modell – in der Regel ein Cross-Encoder, der die Abfrage sowie jeden Block gemeinsam verarbeitet – diese und behält die drei oder vier besten. Das Modell erhält dadurch einen klareren Kontext, auf Kosten von zusätzlicher Latenz und höheren Kosten pro Abfrage.

Kombination von semantischer und Schlüsselwortsuche

Embeddings erfassen die Bedeutung gut, doch manchmal sind genaue Token wichtiger als die Bedeutung. Eine Abfrage wie ERROR_CODE_4291 weist kaum semantischen Inhalt auf, wodurch eine Ähnlichkeitssuche das einzige Dokument, das sie erwähnt, übersehen könnte. Eine Schlüsselwortsortierung wie BM25 bewältigt diesen Fall hervorragend. Viele Systeme führen daher sowohl eine Vektor- als auch eine Schlüsselwortsuche durch und fügen die Ergebnisse zusammen – ein Ansatz, der als hybride Suche bezeichnet wird.

Die Wortschatzlücke in Abfragen überbrücken

Benutzer formulieren ihre Fragen selten auf die gleiche Weise wie Dokumente geschrieben sind. Jemand könnte fragen, warum eine Zahlung fehlschlägt, während die entsprechende Seite von einer Kartenautorisierungsfehler spricht. Abfragen umformulieren, MultiQuery (mehrere Formulierungen erstellen und jeweils suchen) sowie HyDE (eine hypothetische Antwort erzeugen und mit deren Embedding suchen) können alle diese Lücke schließen. Allerdings führen sie zu zusätzlichen LLM-Aufrufen und erhöhter Komplexität, weshalb man sie nur nach den einfacheren Methoden oben verwenden sollte.

Jede Veränderung anhand einer Basislinie messen

Die wichtigste Gewohnheit ist, keine Voraussetzungen zu treffen. „Wir haben die Neubewertung hinzugefügt, daher ist das Suchergebnis besser“ ist eine Hypothese, solange sie nicht gemessen wurde. Erstellen Sie eine kleine Sammlung echter Fragen mit bekannten relevanten Abschnitten und verfolgen Sie anschließend Metriken wie:

• Recall@K: Ob die richtigen Informationen in den oberen K abgerufenen Abschnitten erscheinen.

Kontextgenauigkeit: Inwieweit der abgerufene Kontext tatsächlich nützlich war.

Getreue: Ob die Antwort auf dem abgerufenen Kontext beruht.

Relevanz der Antwort: Ob die Antwort die gestellte Frage beantwortet.

Erstellen Sie zunächst eine Baseline. In einem veranschaulichenden Beispiel könnte das so aussehen:

Baseline Recall@5: 68%

Anschließend wenden Sie jeweils eine Änderung nach der anderen an, führen die gleichen Fragen erneut aus und dokumentieren jedes Ergebnis. Eine Abfolge von Verbesserungen könnte wie folgt aussehen:

Better chunking: 74%
Hybrid search: 82%
Reranking: 89%

Diese Werte sind ein Beispiel und keine Vergleichsgröße; Ihre eigenen Daten werden sich anders verhalten. Der Sinn besteht darin, dass ein Protokoll pro Änderung zeigt, welche Schritte zu ihrer Komplexität geführt haben und welche nicht. Für eine ausführlichere Behandlung der Fehlerfindung siehe die Bewertung von RAG nach Fehlerstufe.

Zusammenfassung

Begonnen Sie mit dem einfachsten Pipeline-Verlauf – von der Abfrage über die Datenerfassung bis zum Kontext und schließlich zum LLM – und verbessern Sie nacheinander eine Stufe: Führen Sie eine Änderung durch, messen Sie deren Auswirkungen, bewerten Sie Latenz und Kosten und wiederholen Sie den Vorgang. Ein bescheidener RAG-System, das man versteht und messen kann, ist in der Regel wertvoller als ein komplexes System voller Techniken, die niemand mit Zahlen begründen kann.