- RAG, wie es in KI-Systemen auf Basis von Arbeitswissen genutzt wird, kann beim Aufteilen von Dokumenten in kleine Chunks Kontext wie Unternehmensnamen oder Zeitpunkte verlieren und dadurch relevante Informationen verpassen
- Anthropics Contextual Retrieval stellt jedem Chunk eine kurze Beschreibung auf Basis des gesamten Dokuments voran und erstellt anschließend Embeddings und einen BM25-Index, um die Fehlerrate bei der Suche zu senken
- In Experimenten senkten Contextual Embeddings die Fehlerrate bei der Suche nach Top-20-Chunks um 35% von 5,7% auf 3,7%; die Kombination aus Contextual Embeddings und Contextual BM25 senkte sie um 49% auf 2,9%
- Ergänzt man Reranking, werden die Top-150-Kandidaten erneut bewertet und nur die Top-20 an das Modell übergeben; die Fehlerrate bei der Suche sinkt dadurch um 67% von 5,7% auf 1,9%
- Wenn die Wissensbasis 200.000 Tokens oder weniger umfasst, kann man sie auch vollständig in den Prompt aufnehmen; bei größeren Wissensbasen sollte die Kombination aus Contextual Retrieval und Reranking je nach Use Case evaluiert werden
Der Dokumentkontext, den RAG verliert
- Damit ein KI-Modell in einer bestimmten Aufgabe nützlich ist, muss es auf Hintergrundwissen zugreifen können
- Ein Chatbot für den Kundensupport benötigt Wissen über das jeweilige Unternehmen
- Ein Bot für juristische Analysen benötigt Wissen über frühere Präzedenzfälle
- Entwickler erweitern das Wissen von Modellen meist mit Retrieval-Augmented Generation (RAG)
- Relevante Informationen werden aus einer Wissensbasis abgerufen
- Die abgerufenen Informationen werden an den Nutzer-Prompt angehängt, um die Modellantwort zu verbessern
- Klassisches RAG kann beim Aufteilen von Dokumenten in Chunks Kontext entfernen und dadurch relevante Informationen nicht finden
- Contextual Retrieval ist eine Methode zur Verbesserung der Suchphase von RAG; zwei Untertechniken können gemeinsam eingesetzt werden
- Contextual Embeddings: Embeddings werden aus Chunks erzeugt, denen Kontext vorangestellt wurde
- Contextual BM25: Ein BM25-Index wird aus Chunks erstellt, denen Kontext vorangestellt wurde
- Diese Kombination reduziert die Zahl der Suchfehler um 49% und in Verbindung mit Reranking um bis zu 67%
- Für die Bereitstellung von Contextual Retrieval mit Claude gibt es ein Cookbook
Bei kleinen Wissensbasen sind auch lange Prompts möglich
- Wenn eine Wissensbasis 200.000 Tokens oder weniger umfasst, also kleiner ist als etwa 500 Seiten, kann die gesamte Wissensbasis ohne RAG in den Prompt aufgenommen werden
- Claudes Prompt Caching macht diesen Ansatz schneller und kosteneffizienter
- Häufig verwendete Prompts können zwischen API-Aufrufen zwischengespeichert werden
- Die Latenz kann um mehr als das 2-Fache reduziert werden
- Die Kosten können um bis zu 90% sinken
- Die Funktionsweise ist im Prompt-Caching-Cookbook beschrieben
- Wenn die Wissensbasis wächst, ist ein skalierbareres Retrieval-Verfahren nötig; hier kommt Contextual Retrieval zum Einsatz
Klassisches RAG und die Rolle von BM25
- Wenn eine große Wissensbasis nicht in das Kontextfenster passt, ist die übliche Lösung RAG
- Der Preprocessing-Ablauf von RAG sieht wie folgt aus
- Der Dokumentkorpus wird in kleine Text-Chunks aufgeteilt, meist mit jeweils höchstens einigen Hundert Tokens
- Ein Embedding-Modell wandelt die Chunks in Vektor-Embeddings um, die ihre Bedeutung enthalten
- Die Embeddings werden in einer Vektordatenbank gespeichert, die semantische Ähnlichkeitssuche ermöglicht
- Zur Laufzeit werden in der Vektordatenbank die Chunks gesucht, die semantisch am ähnlichsten zur Nutzeranfrage sind; relevante Chunks werden dem Prompt des generativen Modells hinzugefügt
- Embedding-Modelle erfassen semantische Beziehungen gut, können aber exakte String-Übereinstimmungen übersehen
- BM25 (Best Matching 25) ist eine Ranking-Funktion auf Basis lexikalischer Übereinstimmungen und ist besonders effektiv bei Anfragen mit eindeutigen Identifikatoren oder Fachbegriffen
- BM25 basiert auf dem Konzept von TF-IDF
- TF-IDF misst, wie wichtig ein bestimmtes Wort für ein Dokument innerhalb einer Sammlung ist
- BM25 berücksichtigt die Dokumentlänge und wendet eine Sättigungsfunktion auf die Term Frequency an, damit häufige Wörter die Ergebnisse nicht dominieren
- Sucht man beispielsweise in einer technischen Support-Datenbank nach
"Error code TS-999", kann ein Embedding-Modell allgemeine Dokumente zu Fehlercodes finden, aber die exakte Übereinstimmung mit "TS-999" verpassen
- BM25 findet diesen String direkt und identifiziert die relevanten Dokumente
RAG mit Embeddings und BM25 gemeinsam
- RAG kann Embeddings und BM25 kombinieren, um präzisere Chunks abzurufen
- Die Wissensbasis wird in kleine Chunks aufgeteilt
- Für jeden Chunk werden eine TF-IDF-Codierung und ein semantisches Embedding erzeugt
- BM25 findet die Top-Chunks auf Basis exakter Übereinstimmungen
- Embeddings finden die Top-Chunks auf Basis semantischer Ähnlichkeit
- Die Ergebnisse werden mit Rank-Fusion-Verfahren kombiniert und dedupliziert
- Die Top-K-Chunks werden in den Prompt aufgenommen, um die Antwort zu generieren
- Dieser Ansatz schafft ein Gleichgewicht zwischen exakter Begriffsübereinstimmung und breiterem semantischem Verständnis
- Er kann kosteneffizient bis zu riesigen Wissensbasen skalieren, die nicht in einen einzelnen Prompt passen
- Klassische RAG-Systeme haben jedoch die Einschränkung, dass sie beim Aufteilen von Dokumenten in Chunks Kontext zerstören
- Ein typisches Beispiel ist die Frage
"What was the revenue growth for ACME Corp in Q2 2023?" in einer Wissensbasis auf Basis von SEC-Filings
- Ein relevanter Chunk enthält möglicherweise nur
"The company's revenue grew by 3% over the previous quarter."
- Aus diesem Chunk allein ist nicht ersichtlich, um welches Unternehmen und welchen Zeitraum es geht
- Dadurch wird es sowohl beim Retrieval als auch bei der Nutzung schwierig, die richtige Information zu verwenden
Wie Contextual Retrieval funktioniert
- Contextual Retrieval stellt jedem Chunk einen chunkspezifischen Beschreibungskontext voran, bevor Embeddings erstellt und der BM25-Index aufgebaut werden
- Auf Embeddings angewendet heißt das Contextual Embeddings
- Auf den BM25-Index angewendet heißt das Contextual BM25
- Im Beispiel mit SEC-Filings lautet der ursprüngliche Chunk wie folgt
The company's revenue grew by 3% over the previous quarter.
- Der kontextualisierte Chunk wird dann etwa so
This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter.
- Auch früher wurden Methoden vorgeschlagen, die Kontext zur Verbesserung von Retrieval nutzen
- Diese Methoden unterscheiden sich vom Ansatz von Contextual Retrieval, bei dem jedem Chunk eigener Kontext hinzugefügt wird
Chunk-Kontext mit Claude erzeugen
- Tausende oder Millionen Chunks manuell zu annotieren ist nicht praktikabel
- Anthropic formuliert einen Prompt, damit Claude auf Basis des gesamten Dokumentkontexts für jeden Chunk einen kurzen, chunkspezifischen Kontext erstellt
- Der für Claude 3 Haiku verwendete Prompt lautet
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
- Der generierte Kontexttext umfasst meist 50 bis 100 Tokens und wird dem Chunk vorangestellt, bevor Embeddings und BM25-Index erzeugt werden
- Mit Prompt Caching muss das Referenzdokument nicht für jeden Chunk erneut übergeben werden
- Das Dokument wird einmal in den Cache gelegt, anschließend wird auf die zuvor gecachten Inhalte verwiesen
- Unter der Annahme von 800-Token-Chunks, einem 8k-Token-Dokument, einer 50-Token-Kontextanweisung und 100 Tokens Kontext pro Chunk betragen die einmaligen Kosten für die Erzeugung kontextualisierter Chunks 1,02 US-Dollar pro 1 Million Dokument-Tokens
Experimentelles Vorgehen und Retrieval-Leistung
- Die Experimente wurden über mehrere Wissensbereiche, Embedding-Modelle, Retrieval-Strategien und Bewertungsmetriken hinweg durchgeführt
- Codebasen
- Romane
- ArXiv-Paper
- Wissenschaftliche Paper
- Beispiele für Fragen und Antworten aus jedem Bereich sind in Appendix II enthalten
- Die Grafik zeigt die durchschnittliche Leistung über alle Wissensbereiche hinweg und nutzt Gemini Text 004, die beste Embedding-Konfiguration, sowie die Suche nach Top-20-Chunks
- Die Bewertungsmetrik ist 1 - recall@20
- Sie misst den Anteil, bei dem relevante Dokumente nicht unter den Top-20-Chunks gefunden wurden
- Über alle Ergebnisse hinweg verbesserte sich die Leistung bei allen getesteten Embedding-Source-Kombinationen durch Kontextualisierung
- Die Leistungsverbesserungen lauten
- Contextual Embeddings: senken die Fehlerrate bei der Suche nach Top-20-Chunks um 5,7% → 3,7%, also um 35%
- Contextual Embeddings + Contextual BM25: senken die Fehlerrate um 5,7% → 2,9%, also um 49%
Aspekte bei der Implementierung
- Chunk-Grenzen können die Retrieval-Leistung beeinflussen
- Chunk-Größe
- Chunk-Grenzen
- Chunk-Überlappung
- Contextual Retrieval verbesserte die Leistung bei allen getesteten Embedding-Modellen, der Umfang der Verbesserung kann sich jedoch je nach Modell unterscheiden
- Gemini-Embeddings und Voyage-Embeddings waren besonders effektiv
- Der bereitgestellte allgemeine Prompt funktioniert gut, bessere Ergebnisse können jedoch mit einem angepassten Contextualizer-Prompt erzielt werden, der auf Domain oder Use Case zugeschnitten ist
- Beispiel: Ein Glossar zentraler Begriffe einbeziehen, die nur in anderen Dokumenten der Wissensbasis definiert werden
- Wenn mehr Chunks in das Kontextfenster aufgenommen werden, steigt die Wahrscheinlichkeit, dass relevante Informationen enthalten sind
- Zu viele Informationen können das Modell jedoch ablenken; es gibt also Grenzen
- Beim Test mit 5, 10 und 20 übergebenen Chunks war die Leistung mit 20 Chunks am besten
- In realen Use Cases sind Experimente erforderlich
- Bei der Antwortgenerierung kann es hilfreich sein, kontextualisierte Chunks zu übergeben und zu unterscheiden, was Kontext ist und was der ursprüngliche Chunk ist
- Evaluationen sollten immer durchgeführt werden
Weitere Verbesserung durch Reranking
- Reranking ist eine Filtertechnik, die bei großen Wissensbasen aus den zunächst abgerufenen Kandidaten-Chunks nur die relevantesten Chunks an das Modell übergibt
- Dieser Schritt reduziert die Informationsmenge, die das Modell verarbeiten muss, und kann Antwortqualität, Kosten und Latenz beeinflussen
- Der Ablauf ist wie folgt
- Durch eine erste Suche werden potenziell relevante Top-Chunks abgerufen
- In den Experimenten wurden Top 150 verwendet
- Die Top-N-Chunks und die Nutzeranfrage werden an ein Reranking-Modell übergeben
- Das Reranking-Modell vergibt für jeden Chunk Relevanz- und Wichtigkeitsscores
- Die Top-K-Chunks werden ausgewählt
- In den Experimenten wurden Top 20 verwendet
- Die ausgewählten Chunks werden als Modellkontext eingebracht, um das Endergebnis zu generieren
- Die Experimente wurden mit dem Cohere Reranker durchgeführt
- Es gibt auch den Voyage Reranker, für einen Test blieb jedoch keine Zeit
- In verschiedenen Domains optimiert ein zusätzlicher Reranking-Schritt das Retrieval weiter
- Reranked Contextual Embedding + Contextual BM25 senkt die Fehlerrate bei der Suche nach Top-20-Chunks um 5,7% → 1,9%, also um 67%
Abwägung zwischen Kosten und Latenz
- Da Reranking zur Laufzeit einen zusätzlichen Schritt einführt, fügt es zwangsläufig eine geringe Latenz hinzu
- Auch wenn das Reranking-Modell alle Chunks parallel bewertet, müssen Auswirkungen auf Latenz und Kosten berücksichtigt werden
- Werden mehr Chunks rerankt, kann die Leistung steigen, aber Kosten und Latenz nehmen zu
- Werden weniger Chunks rerankt, sinken Kosten und Latenz, aber die Leistungsverbesserung kann geringer ausfallen
- Das passende Gleichgewicht muss durch Experimente mit mehreren Einstellungen im konkreten Use Case gefunden werden
Ergebnisse in Kombination
- Verglichen wurden über mehrere Dataset-Typen hinweg Kombinationen aus Embedding-Modell, BM25-Nutzung, Contextual-Retrieval-Nutzung, Reranking-Nutzung und Top-K-Anzahl beim Retrieval
- Die Ergebnisse lassen sich wie folgt zusammenfassen
- Embeddings + BM25 ist besser als Embeddings allein
- Unter den getesteten Embeddings waren Voyage und Gemini am besten
- Dem Modell Top-20-Chunks zu übergeben ist effektiver als Top-10 oder Top-5
- Das Hinzufügen von Kontext zu Chunks verbessert die Retrieval-Genauigkeit deutlich
- Reranking ist besser als kein Reranking
- Um die Leistungsverbesserung zu maximieren, lassen sich Contextual Embeddings auf Basis von Voyage oder Gemini, Contextual BM25, ein Reranking-Schritt und das Hinzufügen von 20 Chunks zum Prompt kombinieren
- Entwickler können diesen Ansatz mit dem Contextual-Retrieval-Cookbook ausprobieren
1 Kommentare
Meinungen auf Hacker News
Wir bauen ein Enterprise-RAG für Behörden. Bei experimentellen A/B-Tests mit RAGAS-Metriken zeigte sich, dass nach einer hybriden Suche (semantische Suche + Vektoren) ein LLM-basiertes Reranking gemessen an synthetischen Evaluierungsfragen kaum etwas verändert hat; HyDE hat die Antwortqualität und die Suchqualität deutlich verschlechtert.
RAGAS-Evaluierungen mit Expertenfragen und echten Nutzerfragen müssen wir noch weiter durchführen.
Deshalb ist es im Produktions-/Enterprise-RAG zwar nichts Neues, dass hybride Suche oft gut ist, aber eine Methode gewinnt nicht immer. In unserem Fall reichte als zweites Verfahren neben der Vektorähnlichkeit allein die semantische Suche von Azure AI Search aus. Anderswo könnten BM25 oder ein feinabgestimmtes kleines Sprachmodell für Query-Postprocessing besser sein; letztlich muss man also je nach Use Case fortlaufend testen.
Als Nächstes wollen wir RAPTOR, SelfRAG, agentisches RAG, Query-Verbesserung (Erweiterung und Sub-Queries) sowie GraphRAG ausprobieren.
Die bisherige Lehre ist, dass man mit Baseline und Experimentalgruppe versuchen sollte, die Nullhypothese anhand von Metriken wie RAGAS zu widerlegen, und dass man für Evaluierungsfragen/-antworten drei Arten verwenden sollte: von Experten erstellte Q&A, echte Nutzerfragen aus Logs und synthetische Q&A, die aus den Originaldokumenten generiert wurden.
Was mir an diesem Ansatz am besten gefällt, ist, dass er Prompt Caching gut ausnutzt.
Gecachte Prompts kosten in der Regel nur etwa 1/10 der normalen Kosten; Tricks wie jeden Chunk zusammen mit dem gesamten Originaldokument durchlaufen zu lassen, waren früher aus Kostengründen unsinnig, sind jetzt aber möglich.
Durch die Kostensenkung beim Caching dürften sich mehr solche brauchbaren Techniken eröffnen.
Notiz zu Contextual Retrieval: https://simonwillison.net/2024/Sep/20/introducing-contextual... und Notiz zu Prompt Caching: https://simonwillison.net/2024/Aug/14/prompt-caching-with-cl...
Das wäre hilfreicher Kontext, um ein Gefühl dafür zu bekommen, wie viel man ausgeben muss, um bei aktuellen Modellen und Features dranzubleiben.
Aus Sicht eines klassischen Suchhintergrunds wirkt es ziemlich naiv, RAG auf fertige Embedding-Modelle und Vektorsuche zu beschränken. Vektorsuche ist für sich genommen nicht besonders gut; um den Kontext zu verbessern, den man dem LLM liefert, braucht man zusätzliche Information-Retrieval-Strategien. Genau das passiert hier im Grunde auch.
Microsoft hat früher ein Paper zu Graph RAG veröffentlicht, das RAG und Vektorsuche auf Basis eines Konzeptgraphen kombiniert, der durch Entity Extraction aus Indexdaten erstellt wird. So lassen sich kontextuell relevante Informationen zu den gematchten Chunks heranziehen.
Ich habe das Gefühl, dass man auch ohne Vektorsuche ziemlich weit kommen kann. Die Kosten werden ebenfalls deutlich niedriger. Es reicht eine klassische Suchmaschine mit gut abgestimmten Queries. Der Kern ist natürlich Query-Tuning, und das passt vielleicht nicht gut für allgemeine Fälle, kann aber bei spezialisierteren Fällen funktionieren.
Als Kontext: Dieser Ansatz ist nicht wirklich neu. Eine gängige Methode zur Verbesserung von RAG-Ergebnissen besteht darin, die zugrunde liegenden Chunks per LLM zu „erweitern“, um die semantische Oberfläche zu vergrößern, auf die gematcht werden kann.
Mit Query Expansion über HyDE[1] kann man es weiter verbessern, aber es wird nicht immer besser; ich nutze es daher als alternativen Pfad.
Ich bin mir nicht sicher, was Anthropic hier Neues vorgestellt hat. Auch der Cookbook-Code zeigt lediglich den Prozess zur Erstellung dieses Kontexts; an der API hat sich für „Contextual Retrieval“ tatsächlich nichts geändert.
Neu ist das vor einem Monat eingeführte Prompt Caching, das es ermöglicht, das gesamte lange Dokument als Kontext bereitzustellen und einzelne Chunks sehr günstig mit besserem Kontext anzureichern. Caching ist ein großartiges Feature, das man Entwicklern gut zugänglich machen kann, und seinen Wert erkenne ich an.
Abgesehen davon scheint es aber nur ein Cookbook zu sein, das einen bestimmten RAG-Workflow zeigt.
Nebenbei: Cohere gehört zu den APIs, die mir von den ausprobierten am besten gefallen haben. Ich habe keine Verbindung zu ihnen, aber die Cohere RAG API war im Gegensatz zu anderen Anbietern sehr gut. Klare Empfehlung.
1: https://arxiv.org/abs/2212.10496
Wenn die Daten zehntausende Chunks enthalten, muss man das für alle machen, was teuer ist. Wenn man die Dokumente cached, kann man diese Kosten senken.
Für meine RAG-Anforderungen passt das nicht gut, und vermutlich gilt das für die meisten. Denn eine Query kann im nächsten Monat oder in einem Jahr ausgeführt werden. Diese Policy scheint sich auch nicht geändert zu haben, daher finde ich es etwas überraschend, im Zusammenhang mit RAG über Prompt Caching zu sprechen.
Wir machen etwas Ähnliches. Zuerst zerlegen wir Dokumente anhand der h1-, h2- und h3-Überschriften in Chunks und hängen die Header am Anfang des Chunks als Kontext an.
Als fiktives Beispiel: Wenn der ursprüngliche Chunk „Die übliche Dosis für Erwachsene beträgt 1–2 Tabletten oder Kapseln à 200 mg dreimal täglich“ lautete, steht nun
# Fever,## Treatment, dann eine Trennlinie und danach derselbe Inhalt.Scheint ziemlich gut zu funktionieren, und beim Indexieren der Dokumente braucht man auch kein LLM.
Das könnte auch der Ursprung der Debatte gewesen sein, dass „ChatGPT im Dezember langsamer wurde“: Diese „Datums“-Metadaten könnten ChatGPT signalisiert haben, weniger hilfreich zu sein.
Zuerst fasse ich jede Seite zusammen, versehe sie mit einem Titel und extrahiere eine Liste der Unterabschnitte. Dann füge ich alle Zusammenfassungen zusammen und bitte das Modell, einen hierarchischen Index zu erstellen. Das Modell organisiert die gesamte Sammlung als Baum, und zum Zeitpunkt der Anfrage wird der Pfad im Baum als zusätzlicher Kontext kombiniert.
Mir gefällt diese Technik nicht besonders. Ich stimme zu, dass das beschriebene Szenario ein häufiges Problem ist, aber die vorgeschlagene Lösung wirkt unbeholfen.
Vektor-Embeddings haben Eigenschaften wie eine Bag-of-Words-Kompression und können übermäßig stark auf den ersten Textblock nach dem Zeilenumbruch indexiert werden. Dadurch rücken bestimmte Indizes des Vektors viel näher an 0 heran, als sie ursprünglich waren. Nach der Quantisierung werden sie am Ende zu 0, wodurch bei Dense Vectors viel Präzision verloren gehen kann. IDF-Suche gleicht das bis zu einem gewissen Grad aus, aber nicht ausreichend.
Wenn man Embeddings „semantisch boostet“, sodass sie näher an Dokumenttitel, Zusammenfassung, Abstract usw. heranrücken, erhält man den Recall-Vorteil dieses „Kontext“-Präfixes, ohne den zugrunde liegenden Vektor zu verunreinigen. Implementiert ist das im Grunde eine gewichtete Summe. In der Augmentierungsphase kann man beim Einfügen ins Kontextfenster, wenn ein Dokument gematcht wird, auch den Zusammenfassungs-Chunk mit injizieren. Für mich ist das eine deutlich sauberere Lösung.
Beschreibung von „semantic boost“ in der Trieve API[1]:
semantic_boost: Nützlich, um den Embedding-Vektor eines Chunks in Richtung einer Distanz-Phrase zu verschieben. Wenn zum Beispielchunk_htmleines Chunksiphoneist, kann man ihn mitflagshipalsdistance_phraseund0.25alsdistance_factorum 25 % näher an den Begriff „flagship“ schieben. Konzeptionell zieht man eine euklidische/L2-Distanzlinie zwischen deminnerText-Vektor vonchunk_htmlund dem Vektor vondistance_phraseund bewegt denchunk_html-Vektor entlang dieser Linie umdistance_factorL2Distancenäher heran oder weiter weg.[1]:https://docs.trieve.ai/api-reference/chunk/create-or-upsert-...
Wenn das so ist, heißt das dann nicht, dass eine Vektor-DB an ein einzelnes LLM gebunden ist, sogar an eine einzelne Version wie Claude-3.5 Sonnet, und man sie nicht einmal zu 3.5 Haiku oder Opus verschieben kann, während für ChatGPT oder Llama eine Neuindexierung nötig wäre?
Die Technik, die ich für am nützlichsten halte, besteht darin, eine Linked-List-Strategie zu implementieren, bei der ein Chunk mehrere Pointer auf Elemente hat, die auf ihn verweisen. Ich mache das manuell, aber dadurch steigt die Vielfalt der Möglichkeiten, einen bestimmten Knoten zu referenzieren, erheblich.
Anders betrachtet ist es wie bei Kommentaren. Alle Kommentare unter diesem Beitrag lassen sich als Pointer auf den ursprünglichen Beitrag verstehen. Manche Kommentare liegen semantisch nahe am Original, andere entfernen sich wegen der Wahrnehmung des Autors weiter davon. Aber wenn jeder Kommentar eine
parent_idbekommt, gibt es mehr Wege, zum Originalbeitrag zu gelangen.Ein Beispiel für diese Technik ist hier zu sehen [1]. Man versucht nicht vorherzusagen, welche Anfrage Endnutzer stellen werden, sondern lässt die Nutzer einfach sprechen und indexiert das dann als Pointer. Die Möglichkeiten, ein Objekt auszudrücken, sind endlich, aber manche Ausdrücke liegen semantisch sehr, sehr, sehr weit vom Kernobjekt entfernt.
[1] - https://x.com/yourcommonbase/status/1833262865194557505
Die Aussage, dass man bei kleinen Datensätzen einfach 200.000 Tokens hineinwerfen könne, um die beste Antwort zu bekommen, deckt sich nicht mit meiner Erfahrung.
Ich sehe häufig, dass mit wachsendem Prompt die Konsistenz der Ausgabe abnimmt und auch das Befolgen von Anweisungen schlechter wird. Das scheint sogar schon in Bereichen deutlich unter 25k Tokens zu passieren. Ich frage mich, ob andere das auch erleben und ob es bekannte Methoden gibt, das zu vermeiden.
Interessant. Das Problem, das ich habe: Mit RAG suche ich nicht nach Wissens-Chunks, sondern nach anwendbaren Regeln. Nur Regeln, die auf den Kontext angewendet werden können, sollten in den Kontext injiziert werden.
Experimentiert habe ich damit noch nicht, aber ich denke, ein kleiner Klassifikator, der darauf trainiert ist zu beurteilen, ob eine bestimmte Regel anwendbar sein könnte, könnte funktionieren. Das Haupt-LLM übernimmt dann die Aufgabe zu entscheiden, ob diese Regel im aktuellen Kontext tatsächlich gilt.
Nehmen wir zum Beispiel an, man spielt mit einem LLM ein Mehrbenutzer-Dungeon-Spiel. Eine Figur hat früher im Zusammenhang mit Taxis etwas Schlechtes getan, woraufhin das Spiel die Regel erzeugt hat: „Jedes Mal, wenn sie versucht, in ein Taxi zu steigen, wird sie hinausgeworfen. ‚Wir wissen, wer du bist, und werden dich nicht als Kunden akzeptieren, bis du dich offiziell beim Direktor des Taxiunternehmens entschuldigt hast.‘“ Wenn sie sich entschuldigt, wird die Regel entfernt. Der Direktor des Taxiunternehmens könnte auch ein anderer Spieler sein oder die Person, die die Regel ursprünglich ausgelöst hat, die dann von ihrer NPC-Taxiflotte durchgesetzt wird.
Ich frage mich, wie gut das mit der Zahl aktiver Regeln skaliert und in welchem Maße sich klassisches RAG anwenden lässt. Zu beurteilen, ob eine Regel gilt, wirkt wie ein abstrakteres und schwierigeres Problem als zu beurteilen, ob ein Wissens-Chunk relevant ist.
Der entscheidende Punkt, der es besonders schwierig macht, ist eine Abhängigkeitsschleife, die es bei der Wissenssuche nicht gibt. Um festzustellen, ob eine Regel gilt, muss man diese Regel zuerst abrufen. Wie könnte man dieses Problem lösen?
Eine Beispielanfrage könnte man mit Hilfe von LLama 3.1 8B hinreichend detailliert formulieren: Eine Armee von Dunkelelfen rückt näher, Grimgold Ironfist steckt in einer verzweifelten Lage, er war früher stolzes Mitglied der Zwergenmiliz, hat jetzt aber nur noch 35 % Gesundheit, im Inventar befinden sich eine abgenutzte Spitzhacke, ein Wasserschlauch, altes Brot und 17 Goldmünzen, und trotz seiner „problematischen Vergangenheit“ mit der Taxi Guild versucht er, am Straßenrand ein Taxi anzuhalten.
Die Beispielregel, die aus dem Vektorspeicher geholt würde, dürfte wegen der Erwähnungen von Name/Eigenschaften der Figur sowie Taxi und Taxi Guild per Vektornähe gefunden werden.
Etwa eine Regel wie: „Die Taxi Guild hat Grimgold eine strenge Strafe auferlegt. Jedes Mal, wenn er versucht, ein Taxi anzuhalten, wird er sofort aus dem Fahrzeug geworfen. Im Erlass der Guild steht: ‚Grimgold Ironfist, ein bärtiger Zwerg mit schlechtem Ruf, darf in kein von Mitgliedern betriebenes Taxi einsteigen, bis er sich offiziell bei Thorgrim Stonebeard, dem Direktor der Golden Horse Cab Company, entschuldigt hat. Bei Nichtbefolgung wird er dauerhaft von unseren Diensten ausgeschlossen.‘“
Es heißt: „Wenn die Wissensbasis kleiner als 200.000 Tokens ist (etwa 500 Seiten)“ – ich wünschte, Anthropic würde einfach den Tokenizer veröffentlichen. Dann müsste man nicht raten.
Ich warte auf den Tag, an dem die gesamte KI-Branche einmal im Kreis gelaufen ist und am Ende wieder bei TF-IDF landet.