Query-Rewriting und HyDE

Die Retrieval-Qualität ist durch die Query begrenzt. Rohe Benutzer-Queries sind oft kurz, mehrdeutig, voller Pronomen oder anders formuliert als die Dokumente. Query-Transformation formt die Query vor dem Retrieval um, um Recall und Präzision zu erhöhen.

Dies ist eine der kostengünstigsten Maßnahmen mit dem größten Hebel gegenüber naivem RAG: Wenn Sie die Query verbessern, profitieren alle nachgelagerten Stufen.

Die einfachste Transformation: Ein LLM schreibt die Benutzer-Query in eine klarere, in sich geschlossene und retrievalfreundliche Form um. Es korrigiert Tippfehler, erweitert Abkürzungen und entfernt Gesprächsrauschen.

Das ist besonders in Multi-Turn-Chats wichtig, in denen die letzte Nachricht ohne Kontext unverständlich ist („Wie sieht es mit dem zweiten aus?“).

Verdichten Sie bei Chat-RAG den Dialog und den neuen Gesprächsbeitrag zu einer einzigen eigenständigen Frage. Ohne diesen Schritt machen Pronomen und Auslassungen die Embedding-Repräsentation bedeutungslos und das Retrieval bricht zusammen.

Übergeben Sie die vorherigen Gesprächsbeiträge, damit der Umschreiber „es“, „das“ oder „das vorherige“ in explizite Entitäten auflösen kann, die der Retriever abgleichen kann.

Erweiterung erzeugt Synonyme, verwandte Begriffe oder alternative Formulierungen, um die lexikalische und semantische Abdeckung zu vergrößern. Sie wirkt einem Vokabular-Mismatch entgegen: Das Dokument sagt „invalidate“, der Benutzer sagt „revoke“.

Erweitern Sie für das Retrieval und führen Sie anschließend das Retrieval mit der Vereinigung durch. Zeigen Sie dem Benutzer die erweiterte Form nicht an. Achten Sie auf eine übermäßige Erweiterung, durch die themenfremde Ergebnisse abgerufen werden können.

Erzeugen Sie mehrere unterschiedliche Umformulierungen, führen Sie für jede ein Retrieval durch und führen Sie die Ergebnislisten zusammen (Reciprocal Rank Fusion). Unterschiedliche Formulierungen bringen unterschiedliche relevante Chunks zum Vorschein; die Zusammenführung vereint ihre Stärken und stabilisiert den Recall.

Dafür sind zusätzliche Retrieval-Aufrufe erforderlich, im Gegenzug wird das Verfahren robuster gegenüber jeder einzelnen ungünstigen Formulierung.

Komplexe Multi-Hop-Fragen müssen in Teilfragen zerlegt werden, für die jeweils ein eigenes Retrieval durchgeführt wird, bevor die Ergebnisse zusammengeführt werden. Die Frage, welcher CEO des Unternehmens, das X übernommen hat, älter ist als ..., kann nicht durch ein einziges Retrieval beantwortet werden.

Zerlegen Sie die Frage, führen Sie für jede Teilfrage ein Retrieval durch und lassen Sie den Generator die gesammelten Belege zusammenführen.

HyDE (Hypothetical Document Embeddings, Gao et al., 2022) stellt das Problem auf den Kopf. Statt die kurze Query einzubetten, bittet es das LLM, ein hypothetisches Antwortdokument zu generieren, bettet anschließend dieses ein und führt damit das Retrieval durch.

Das hypothetische Dokument verwendet dasselbe Sprachregister wie echte Dokumente. Daher liegt sein Embedding näher an echten Antworten, wodurch der Query-Dokument-Mismatch behoben wird.

Eine Frage und ihre Antwort sind unterschiedlich formuliert; eine Frage und eine erfundene, aber plausible Antwort ähneln in ihrer Formulierung der echten Antwort. HyDE nutzt das generative Vorwissen des LLM, um diese Lücke zu überbrücken, selbst wenn das hypothetische Dokument faktische Fehler enthält.

Die Korrektheit des hypothetischen Dokuments ist kaum entscheidend: Es benötigt lediglich das richtige Vokabular und die richtige Struktur, um im Embedding-Raum in die Nähe echter Dokumente zu gelangen.

HyDE fügt vor dem Retrieval eine LLM-Generierung hinzu, wodurch Latenz und Kosten steigen. Außerdem kann es ein halluziniertes hypothetisches Dokument erzeugen, das vom Thema abweicht. Das verschlechtert den Recall bei Nischen- oder Out-of-Distribution-Queries, über die das Modell nichts weiß.

Mindern Sie dieses Risiko, indem Sie HyDE-Vektor-Retrieval per Fusion mit Retrieval anhand der Roh-Query kombinieren, sodass ein schlechtes hypothetisches Dokument den Recall nicht vollständig zunichtemachen kann.

Diese Transformationen ergänzen sich. Verwenden Sie Verdichtung für Chat, Erweiterung/Multi-Query bei Vokabularlücken, Dekomposition für Multi-Hop-Fragen und HyDE bei einem Mismatch zwischen dem Sprachregister von Frage und Dokument. Viele Produktions-Stacks verketten zunächst die Verdichtung, wenden dann HyDE an, führen anschließend eine Fusion mit der Roh-Query durch und starten danach das Re-Ranking.

Jede zusätzliche Transformation verursacht einen LLM-Aufruf. Steuern Sie sie daher nach dem Query-Typ, statt immer alle auszuführen.

Messen Sie jede Transformation anhand ihres Zugewinns beim retrieval recall@k und bei der Genauigkeit der endgültigen Antwort gegenüber der unveränderten Suchanfrage auf einem leckagefreien Datensatz. Erfassen Sie die zusätzliche Latenz und die LLM-Kosten, damit Sie nur Transformationen behalten, die sich lohnen.

Achtung: Eine Transformation, die den Recall verbessert, aber Ablenkungen hinzufügt, kann die Antwortgenauigkeit verringern, wenn sie nicht mit Re-Ranking und Komprimierung kombiniert wird.

Überlegen Sie, warum HyDE trotz unvollkommener hypothetischer Antworten funktioniert.

Wichtigste Erkenntnisse:

• Die Retrieval-Leistung ist durch die Suchanfrage begrenzt; ihre Transformation ist ein kostengünstiges RAG-Upgrade mit großer Wirkung.
• Umschreiben und Kondensieren machen Chat-Anfragen eigenständig; Expansion und Multi-Query schließen Lücken im Vokabular.
• Dekomposition bewältigt Multi-Hop-Fragen, indem für jede Teilfrage separat abgerufen wird.
• HyDE bettet eine hypothetische Antwort ein, um die Diskrepanz zwischen dem sprachlichen Register der Frage und dem des Dokuments zu überbrücken; die hypothetische Antwort muss nicht korrekt sein.
• Kombinieren Sie Transformationen je nach Anfragetyp, fusionieren Sie sie für Robustheit mit der unveränderten Suchanfrage und bewerten Sie Recall, Antwortgenauigkeit, Latenz und Kosten.