paint-brush
Benötigen Sie relevantere LLM-Antworten? Bewältigen Sie diese Herausforderungen im Bereich Retrieval Augmented Generation (Teil 1)by@datastax
1,017
1,017

Benötigen Sie relevantere LLM-Antworten? Bewältigen Sie diese Herausforderungen im Bereich Retrieval Augmented Generation (Teil 1)

DataStax10m2024/01/04
Read on Terminal Reader

Wir untersuchen, wie suboptimale Einbettungsmodelle, ineffiziente Chunking-Strategien und mangelnde Metadatenfilterung es schwierig machen können, relevante Antworten von Ihrem LLM zu erhalten. So meistern Sie diese Herausforderungen.
featured image - Benötigen Sie relevantere LLM-Antworten? Bewältigen Sie diese Herausforderungen im Bereich Retrieval Augmented Generation (Teil 1)
DataStax HackerNoon profile picture
0-item

Im ersten Teil dieser zweiteiligen Serie untersuchen wir, wie suboptimale Einbettungsmodelle, ineffiziente Chunking-Strategien und mangelnde Metadatenfilterung es schwierig machen können, relevante Antworten von Ihrem LLM zu erhalten. So meistern Sie diese Herausforderungen.


Erstellen generativer KI-Anwendungen, die Folgendes verwenden: Abruf erweiterte Generation (RAG) kann eine Vielzahl von Herausforderungen mit sich bringen. Schauen wir uns die Fehlerbehebung bei RAG-Implementierungen an, die auf Vektordatenbanken basieren, um relevanten Kontext abzurufen, der dann in eine Eingabeaufforderung für ein großes Sprachmodell einbezogen wird, um relevantere Ergebnisse bereitzustellen.


Wir werden diesen Prozess in zwei Hauptteile unterteilen. Die erste, die wir in diesem ersten Artikel der Serie behandeln werden, ist die Einbettungspipeline, die die Datei füllt Vektordatenbank mit Einbettungen:

Hier betrachten wir drei Hauptbereiche, die zu schlechten Ergebnissen führen können: suboptimale Einbettungsmodelle, ineffiziente Chunking-Strategien und mangelnde Metadatenfilterung. (Im kommenden Artikel werfen wir einen Blick auf die tatsächliche Interaktion mit dem LLM und untersuchen einige häufige Probleme, die dort auftauchen und zu schlechten Ergebnissen führen können.)

Auswahl eines geeigneten Einbettungsmodells

Die Wahl eines Einbettungsmodells hat erhebliche Auswirkungen auf die Gesamtrelevanz und Benutzerfreundlichkeit Ihrer RAG-Anwendung. Daher ist ein differenziertes Verständnis der Fähigkeiten jedes Modells und eine Analyse erforderlich, wie diese Fähigkeiten mit den Anforderungen Ihrer Anwendung übereinstimmen.


Wenn Sie mit RAG und Einbettungen im Allgemeinen noch relativ neu sind, ist die eine der besten Ressourcen, die Sie kennen sollten MTEB (Massive Text Embedding Benchmark) Einbettungs-Bestenliste . Wir konzentrieren uns in diesem Beitrag auf Abruf-Anwendungsfälle, aber Einbettungen können natürlich auch für viele andere Anwendungen verwendet werden, einschließlich Klassifizierung, Clustering und Zusammenfassung.


Mithilfe der Bestenliste können Sie die Modelle identifizieren, die für Ihren spezifischen Anwendungsfall die beste Leistung erbringen.


Einer der häufigsten Gründe für eine schlechte RAG-Leistung ist, dass Entwickler, die neu in diesem Bereich sind, eine Google-Suche durchführen, um Beispiele für die Einbettungsgenerierung zu finden. Sie finden oft Beispiele, die Einbettungsmodelle wie Word2Vec, sBERT und RoBERTa verwenden, die für Abruf-Anwendungsfälle eine schlechte Wahl sind.


Wenn Sie diesen Artikel gefunden haben, weil Sie schlechte Relevanzergebnisse debuggen und zum Generieren Ihrer Einbettungen etwas wie sBERT verwendet haben, haben wir wahrscheinlich die Ursache Ihrer Relevanzprobleme identifiziert.


Wenn ja, werden Sie wahrscheinlich als nächstes die Frage haben, welche Einbettungsmodelle Sie verwenden können, um Ihre Ähnlichkeitssuchergebnisse zu verbessern. Ohne die Einzelheiten Ihres Anwendungsfalls zu kennen, würden wir folgende drei empfehlen:

text-embedding-ada-002 (Ada v2)

Ada v2 von OpenAI ist wahrscheinlich der häufigste Ausgangspunkt für die meisten RAG-Anwendungen, einfach weil so viele Entwickler mit den APIs von Open AI beginnen. Ada v2 schneidet in Anwendungsfällen beim Abrufen hervorragend ab und wurde für die Verarbeitung verschiedener Arten von Inhalten, einschließlich Text und Code, entwickelt.


Mit einer maximalen Eingabesequenzlänge von bis zu 8.192 Token ermöglicht es Ihnen auch die Erstellung von Einbettungen für viel längere Textteile als bei alternativen Modellen. Das ist Segen und Fluch zugleich.


Eine große Sequenzgröße vereinfacht das Erstellen von Einbettungen für einen größeren Teil Ihres Textinhalts und ermöglicht es dem Einbettungsmodell, Beziehungen zwischen Wörtern und Sätzen in einem größeren Textkörper zu identifizieren.


Dies führt jedoch auch zu Ähnlichkeitssuchen, die beim Vergleich der Ähnlichkeit zweier langer Dokumente unschärfer werden können, wenn Sie nach relevanten Kontextabschnitten suchen, um den Generierungsprozess zu erleichtern.


Es gibt zwei große Nachteile von Ada v2. Der erste ist, dass es nicht lokal ausgeführt werden kann. Sie müssen die API von OpenAI verwenden, um die Einbettung zu erstellen. Dies kann nicht nur zu Engpässen führen, wenn Sie Einbettungen für viele Inhalte erstellen möchten, sondern es fallen auch Kosten in Höhe von 0,0001 US-Dollar pro 1.000 Token an.


Der zweite Grund ist, dass die aus dem Open AI-Modell erstellten Einbettungen jeweils 1.536 Dimensionen haben. Wenn Sie eine Cloud-Vektordatenbank verwenden, kann dies Ihre Vektorspeicherkosten erheblich erhöhen.


Wann Sie sich entscheiden sollten: Sie möchten eine einfache Lösung, die nur einen API-Aufruf erfordert, Sie müssen möglicherweise große Dokumente vektorisieren und die Kosten stellen kein Problem dar.

jina-embeddings-v2 (Jina v2)

Jina v2 ist ein neues Open-Source-Einbettungsmodell, das Ihnen die gleiche 8.000-Eingabesequenz-Unterstützung wie Ada v2 bietet und bei Abruf-Anwendungsfällen tatsächlich etwas besser abschneidet.


Jina v2 bietet ein Gegenmittel für die Probleme von Ada v2. Es ist Open Source unter der Apache-Lizenz 2.0 und kann lokal ausgeführt werden, was natürlich auch ein Nachteil ist, wenn Sie dafür keinen eigenen Code ausführen möchten. Es erzeugt außerdem einen Einbettungsvektor mit halb so großen Abmessungen wie Ada v2.


Sie erhalten also nicht nur eine etwas bessere Abrufleistung bei Benchmark-Anwendungsfällen, sondern auch bessere Ergebnisse bei geringeren Speicher- und Rechenanforderungen aus Sicht einer Vektordatenbank.


Wann Sie sich entscheiden sollten: Sie möchten eine Open-Source-Lösung verwenden und müssen möglicherweise große Dokumente vektorisieren und sind mit der lokalen Ausführung von Einbettungspipelines vertraut. Sie möchten die Kosten für Vektordatenbanken durch Einbettungen in niedrigeren Dimensionen senken.

bge-large-en-v1.5

bge-large-en-v1.5 steht unter der MIT-Lizenz als Open-Source-Lösung und ist derzeit das bestplatzierte Einbettungsmodell auf der MTEB-Bestenliste für Abruf-Anwendungsfälle. Bei einer kleineren Eingabesequenz müssen Sie sich mehr Gedanken über Ihre Chunking-Strategie machen, bietet aber letztlich die beste Gesamtleistung für Abruf-Anwendungsfälle.


Wann Sie sich entscheiden sollten: Sie möchten eine Open-Source-Lösung verwenden und sind bereit, mehr Zeit in Chunking-Strategien zu investieren, um die Beschränkungen der Eingabegröße einzuhalten. Sie können Einbettungspipelines problemlos lokal ausführen. Sie möchten das leistungsstärkste Einbettungsmodell für Abrufanwendungsfälle.


Obwohl dies nicht Gegenstand dieses Artikels ist, möchten Sie vielleicht tiefer in die 15 Benchmarks in der MTEB-Rangliste eintauchen, um den Benchmark zu finden, der Ihrer spezifischen Situation am ähnlichsten ist.


Zwar gibt es definitiv Muster hinsichtlich der Leistung verschiedener Einbettungsmodelle in den verschiedenen Benchmarks, doch oft gibt es bestimmte Modelle, die in jedem einzelnen Modell herausstechen. Wenn Sie Ihre Einbettungsauswahl weiter verfeinern müssen, ist dies ein möglicher Bereich für weitere Untersuchungen.

Optimieren Sie Ihre Chunking-Strategie

Die Segmentierung oder „Chunking“ des Eingabetextes ist ein entscheidender Faktor, der die Relevanz und Genauigkeit der generierten Ausgabe erheblich beeinflusst. Verschiedene Chunking-Strategien bieten einzigartige Vorteile und eignen sich für bestimmte Aufgabentypen. Hier gehen wir näher auf diese Methoden ein und stellen Richtlinien für ihre Anwendung bereit, wobei wir einige wichtige Überlegungen einbeziehen:


  1. Chunking mit fester Länge
    • Verwendungszweck : Sofern Ihr Inhalt selbst nicht stark strukturiert ist und eine feste Länge hat, möchten Sie normalerweise auf eine nützlichere Chunking-Strategie wie die folgenden zurückgreifen.


    • Technische Überlegungen : Diese Chunking-Strategie ist zwar sehr einfach zu implementieren, führt jedoch im Allgemeinen zu schlechten Ergebnissen bei RAG-Anwendungen.


    • Zusätzliche Erkenntnisse Wenn Sie mit Ihrer RAG-Anwendung eine Strategie mit fester Länge verwenden und Probleme beim Abrufen des relevanten Kontexts haben, sollten Sie einen Wechsel zu einem anderen Chunking-Ansatz in Betracht ziehen.


  2. Chunking auf Satzebene
    • Verwendungszweck : Diese Strategie ist effektiv, wenn jeder Satz im Eingabetext reich an Bedeutung und Kontext ist. Dadurch kann sich das Modell auf die Feinheiten in jedem Satz konzentrieren und so kohärentere und kontextbezogenere Antworten generieren. Bei RAG-Anwendungsfällen werden Sie sich selten auf das Chunking auf Satzebene verlassen.


    • Technische Überlegungen : Chunking auf Satzebene beinhaltet häufig eine Tokenisierung auf der Grundlage von Satzgrenzen, die mithilfe von NLP-Bibliotheken (Natural Language Processing) erreicht werden kann.


    • Zusätzliche Erkenntnisse Die Aufteilung auf Satzebene kann besonders nützlich sein, wenn Sie nach bestimmten Aussagen suchen, beispielsweise in einer Abschrift einer Besprechung, bei der Sie semantisch ähnliche Aussagen zu einem bestimmten Textabschnitt finden möchten.


  3. Chunking auf Absatzebene
    • Verwendungszweck : Wenden Sie diese Strategie an, wenn der Eingabetext in verschiedene Abschnitte oder Absätze unterteilt ist, von denen jeder eine eigene Idee oder ein eigenes Thema zusammenfasst. Dadurch kann sich das Modell auf die relevanten Informationen in jedem Absatz konzentrieren.


    • Technische Überlegungen : Die Identifizierung von Absatzgrenzen umfasst in der Regel die Erkennung von Zeilenumbrüchen oder anderen Trennzeichen, die das Ende eines Absatzes kennzeichnen.


    • Zusätzliche Erkenntnisse Die Aufteilung auf Absatzebene kann nützlich sein, wenn Sie über Dokumente verfügen, die viele verschiedene Aspekte desselben Themas abdecken. Beispielsweise könnte eine Seite der Produktdokumentation eine Produktfunktion vorstellen, erklären, wann sie verwendet werden soll, darüber sprechen, wie sie konfiguriert wird, und Beispiele für verschiedene Konfigurationen geben.


      Mithilfe der Aufteilung auf Absatzebene können Sie den relevantesten Teil des Dokuments identifizieren, um ihn dem LLM als Kontext bereitzustellen.


  4. Inhaltsbewusstes Chunking
    • Verwendungszweck Entscheiden Sie sich für diese Strategie, wenn die Relevanz bestimmter Abschnitte im Text von größter Bedeutung ist. Beispielsweise kann in juristischen Dokumenten die Segmentierung des Textes nach Klauseln oder Abschnitten zu kontextspezifischeren Antworten führen.


    • Technische Überlegungen Dieser Ansatz erfordert möglicherweise fortgeschrittene NLP-Techniken, um die semantischen Grenzen innerhalb des Textes zu verstehen.


    • Zusätzliche Erkenntnisse Content-Aware Chunking ist besonders nützlich beim Umgang mit strukturierten oder halbstrukturierten Daten, da bestimmte Chunks mit Metadatenfilterung kombiniert werden können, um einen präziseren Abruf zu ermöglichen.


      Beispielsweise möchten Sie in einem Rechtsdokument möglicherweise alle Gewährleistungs- oder Entschädigungsklauseln extrahieren, und wenn Sie Einbettungen für Blöcke in einer Vektordatenbank speichern, können Sie Metadaten verwenden, um die Suche nach Inhalten eines bestimmten Typs beim Erstellen eines Dokuments zu erleichtern RAG-Anwendungsfall.


  5. Rekursives Chunking
    • Verwendungszweck : Rekursives Chunking unterteilt Daten mithilfe eines hierarchischen Ansatzes in immer kleinere Teile. Wenn Sie beispielsweise ein Textdokument in Blöcke aufteilen, können Sie den Text zunächst in Absätze, dann in Sätze und schließlich in Wörter unterteilen.


      Sobald die Daten in den ersten Satz von Blöcken unterteilt wurden, können Sie den Chunking-Prozess rekursiv auf jeden der kleineren Blöcke anwenden und diesen Vorgang wiederholen, bis Sie die kleinste gewünschte Blockgröße erreicht haben.


    • Technische Überlegungen Die Implementierung von rekursivem Chunking könnte eine mehrstufige Parsing-Strategie beinhalten, bei der Chunks anhand zusätzlicher Kriterien weiter in Unterchunks unterteilt werden. Wenn Sie verwenden LangChain , seine rekursive Implementierung ist etwas einfacher als das, was hier beschrieben wird.


    • Zusätzliche Einblicke Dieser Ansatz ermöglicht es dem Modell, den Kontext auf mehreren Ebenen zu verstehen, von übergeordneten Themen bis hin zu detaillierten Nuancen, was ihn besonders nützlich für komplexe Dokumente wie wissenschaftliche Arbeiten, technische Handbücher oder rechtliche Verträge macht. Dies bringt Flexibilitätsvorteile mit sich, da Ähnlichkeitssuchen ähnliche Texte sowohl für umfassendere als auch für kürzere Abfragen identifizieren können.


      Dies bedeutet jedoch auch, dass die Möglichkeit besteht, dass ähnliche Abschnitte aus demselben Quelldokument auch bei Ähnlichkeitssuchen überrepräsentiert sind, insbesondere wenn Sie sich in Ihrer Textsplitterkonfiguration für eine längere Überlappung zwischen Abschnitten entscheiden.


Generell gilt: Bevor Sie versuchen, einen großen Korpus aufzuteilen und zu vektorisieren, sollten Sie darüber nachdenken, mit Ihren Daten spontan zu experimentieren.


Überprüfen Sie manuell die Dokumente, die Sie für eine bestimmte Abfrage abrufen möchten, identifizieren Sie die Blöcke, die den idealen Kontext darstellen, den Sie dem LLM bereitstellen möchten, und experimentieren Sie dann mit Chunking-Strategien, um herauszufinden, welche Ihnen die Blöcke liefert, die Ihrer Meinung nach am relevantesten sind für den LLM zu haben.

Überlegungen zum Kontextfenster

Das verfügbare Kontextfenster eines LLM ist ein wichtiger Faktor bei der Auswahl einer Chunking-Strategie. Wenn das Kontextfenster klein ist, müssen Sie bei den Abschnitten, die Sie in das Modell einspeisen, selektiver vorgehen, um sicherzustellen, dass die relevantesten Informationen enthalten sind.


Umgekehrt ermöglicht ein größeres Kontextfenster mehr Flexibilität und ermöglicht die Einbeziehung von zusätzlichem Kontext, der die Ausgabe des Modells verbessern kann, auch wenn nicht alles unbedingt erforderlich ist.


Indem Sie mit diesen Chunking-Strategien experimentieren und diese Überlegungen berücksichtigen, können Sie deren Auswirkungen auf die Relevanz der generierten Ausgaben bewerten. Der Schlüssel besteht darin, die gewählte Strategie an den spezifischen Anforderungen Ihrer RAG-Anwendung auszurichten, die semantische Integrität der Eingabe zu wahren und ein umfassendes Verständnis des Kontexts zu bieten.


Dadurch können Sie den richtigen Chunking-Prozess für optimale Leistung finden.

Metadatenfilterung

Wenn die Anzahl der Einbettungen in Ihrem Suchindex zunimmt, werden die ungefähren nächsten Nachbarn (ANN) weniger hilfreich, wenn Sie nach relevantem Kontext suchen, den Sie in Ihre Eingabeaufforderungen einbeziehen können. Nehmen wir an, Sie haben Einbettungen für 200 Artikel in Ihrer Wissensdatenbank indiziert.


Wenn Sie den nächstgelegenen Nachbarn mit einer Genauigkeit von 1 % identifizieren können, werden Sie wahrscheinlich ziemlich relevante Ergebnisse finden, da 1 % die beiden ersten Artikel dieser 200 darstellt und Sie einen dieser beiden erhalten.


Stellen Sie sich nun einen Suchindex vor, der jeden Artikel auf Wikipedia enthält. Das wären etwa 6,7 Millionen Artikel. Wenn Ihr nächster Nachbar zu den oberen 1 % der ähnlichsten Artikel gehört, bedeutet das, dass Sie einen der 67.000 ähnlichsten Artikel erhalten.


Bei einem Korpus wie Wikipedia bedeutet das, dass man am Ende immer noch sehr weit vom Ziel entfernt sein könnte.


Mit der Metadatenfilterung können Sie die Inhalte eingrenzen, indem Sie zunächst die Dokumente filtern und dann den Algorithmus für den nächsten Nachbarn anwenden. In Fällen, in denen Sie es mit einer großen Anzahl möglicher Übereinstimmungen zu tun haben, kann Ihnen diese anfängliche Vorfilterung dabei helfen, die möglichen Optionen einzugrenzen, bevor Sie die nächsten Nachbarn abrufen.


Als nächstes werden wir uns mit der Interaktion mit dem LLM befassen und einige häufige Probleme untersuchen, die zu schlechten Ergebnissen führen können.


Versuchen DataStax Astra DB , die einzige Vektordatenbank zum Erstellen von KI-Anwendungen auf Produktionsebene auf der Grundlage von Echtzeitdaten .


Von Chris Latimer, DataStax


Auch hier veröffentlicht