스크립트
00:00:00Hallo zusammen. Danke, dass Sie heute gekommen sind. Willkommen zu einem Vortrag über nichts. Entschuldigung, zu einem Vortrag über
00:00:21Retrieval. Mein Name ist Yuval. Ich arbeite bei AI21, im Grunde einem KI-Forschungslabor. Und heute
00:00:29möchte ich mit Ihnen über etwas sprechen, worüber die meisten Leute nicht sprechen wollen, nämlich über Chunking.
00:00:37Und ich hoffe, Sie am Ende davon zu überzeugen, dass Chunking nicht tot ist und dass es da noch einiges zu tun gibt.
00:00:45Und wenn Sie sich auf X, LinkedIn oder sonst wo umsehen, haben Sie wahrscheinlich schon gesehen, dass RAG tot ist, oder?
00:00:53Ich glaube, die Leute haben neulich auch MCP umgebracht. Und RAG ist schon wieder tot. Lang lebe das organische Retrieval,
00:01:00die organische Suche. Und irgendwann muss man sich einfach fragen: Wie oft kann RAG eigentlich sterben?
00:01:07Nicht wahr? Und selbst wenn jemand sagt, nun, RAG ist nicht tot – wie Jerry, der CEO von LlamaIndex –,
00:01:14müssen sie trotzdem irgendetwas töten. Und anscheinend ist dieses Etwas das Chunking. Nach dem Motto: Investiert bloß nicht hinein.
00:01:23Tut es nicht. Und das ist der Grund, warum die Leute meinten, Chunking sei tot, weil jetzt ja jeder
00:01:30agentische Suche nutzt, oder? Man hat grep, man hat ls, man hat find. Die sind alle toll,
00:01:36aber das reicht immer noch nicht aus, wenn man eine Menge Daten und verschiedenste Arten von Abfragen hat.
00:01:46Nur eine Sekunde. Okay. Und ich denke, der Hauptgrund, warum viele Leute nicht gerne
00:01:51über Chunking sprechen, ist der, dass es nicht der spaßige Teil ist, oder? Bei jedem RAG- oder Dateisystem
00:02:00haben wir zwei Phasen. Die erste Phase ist die langweilige, wenn man so will. Die, die man am Anfang macht:
00:02:07Man hat eine Menge Daten. Man muss sie vorverarbeiten. Man muss die Chunk-Größe festlegen. Und dann muss man
00:02:13alles in einer Vektordatenbank speichern. Der andere Teil ist der Retrieval-Teil, im Wesentlichen der Teil,
00:02:20der pro Abfrage stattfindet. Das ist etwas, das viel einfacher zu handhaben ist, oder? Es ist viel leichter
00:02:25zu optimieren. Man kann alle seine Abfragen nutzen und dann mit dem max K, dem Top K spielen, Entschuldigung, man kann mit
00:02:32der hybriden Suche herumspielen und solchen Dingen. Retrieval-Tuning macht eben viel mehr Spaß, nicht wahr?
00:02:40Ich behaupte also: Wenn wir schon etwas töten müssen, wenn etwas tot sein soll, dann ist es wahrscheinlich
00:02:47das Retrieval-Tuning. Und ja, die agentische Suche hat das vermutlich erledigt. Aber dennoch – selbst wenn wir
00:02:55akzeptieren, dass sie das Retrieval-Tuning getötet hat, ist sie immer noch nicht gut genug, wenn man eine riesige Menge an
00:03:02Daten hat. Es kostet eine Menge Geld. Ich glaube, das muss ich nicht mehr extra erwähnen. Token-Maximierung
00:03:09ist ja so ein Thema, über das alle reden. Und die zugrundeliegende Sache ist die: Wenn die Daten selbst
00:03:17nicht richtig in Ihren Ordnern und Verzeichnissen sortiert ist, erhalten Sie nach wie vor etwas, das
00:03:25ineffizient ist. Versuchen wir also, uns ein zeitliches Beispiel zu überlegen, richtig? Die FIFA-Weltmeisterschaft ist
00:03:33vor, wir hätten einen Datensatz, der alle FIFA-Weltmeisterschaften enthält. Jedes Verzeichnis entspricht also sagen wir
00:03:40dem Turnier von 98, dem von 2002 und so weiter. Wenn Ihre Abfrage aber lautet: „Welches Team hat die meisten Weltmeisterschaften gewonnen?“,
00:03:50können Sie nicht einfach in einen Ordner gehen und darauf zugreifen. Sie müssen jeden Ordner durchgehen, nachsehen, wer gewonnen hat, und
00:03:57das Ganze dann zusammenfassen, was äußerst ineffizient ist. Die Antwort lautet natürlich sofort Brasilien, hoffe ich zumindest,
00:04:03zumindest zum Zeitpunkt dieses Gesprächs. Das Retrieval ist also eigentlich nicht gestorben. Wir bringen in diesem Vortrag
00:04:13nichts um. Es hat sich lediglich zu reiner Kleinarbeit gewandelt. Und ich denke, jeder, der an irgendeinem
00:04:21RAG-System gearbeitet hat, kennt dieses Gefühl. Am ersten Tag, in der ersten Woche oder vielleicht sogar im ersten Monat, wenn man sehr gründlich ist,
00:04:29wählt man irgendeine Chunk-Größe aus. Sagen wir 512. Und baut wahrscheinlich noch eine Überlappung ein,
00:04:36oder? 10 %, 20 %, und so weiter, indexiert alles und vergisst die Sache komplett. Und das kann man tun, richtig?
00:04:43Wir reden viel über feste Chunking-Strategien: Wenn Ihr Chunk zu groß ist,
00:04:49erhalten Sie zwar das Gesamtbild, was nett ist, aber Sie verlieren eine Menge Nuancen. Und all die
00:04:54Chunks erhalten keine aussagekräftigen Embeddings. Wenn Sie Ihre Chunks dagegen zu klein wählen,
00:05:00geht das große Ganze verloren. Und wirklich effizient ist das auch nicht. Was uns das also zeigt, ist,
00:05:07dass Chunking im Wesentlichen eine verlustbehaftete Komprimierung ist. Egal, was wir tun, wir verlieren immer etwas.
00:05:15Und ich behaupte, es gibt keine richtige Chunk-Größe. Viele von Ihnen, die mit Daten gearbeitet haben, werden jetzt sagen:
00:05:23„Nein, aber wir haben dieses Korpus, wir haben diesen Datensatz, und wir haben unser System wirklich so eingesetzt und optimiert,
00:05:29dass es mit diesen Daten extrem gut funktioniert.“ Das dachten wir auch. Wir hatten reichlich Erfahrung damit,
00:05:35mit vielen verschiedenen Arten von Agenten, Systemen und Workflows, bei denen man wirklich –
00:05:40ja, wenn man an Benchmarks denkt, wie leicht es ist, sein Modell auf einen Benchmark zu überfitten.
00:05:48Aber eben nicht bei RAG. Da passiert das nicht. Und man kann es eben nicht pro Datensatz optimieren. Und ich werde
00:05:54Ihnen zeigen, wie Sie sicherstellen, dass es abfrageabhängig ist. Und wie kann ich mir da so sicher sein? Wie kann ich so etwas
00:06:00behaupten? Weil wir Experimente durchgeführt und es getestet haben, und das werde ich Ihnen jetzt präsentieren. Was wir also taten:
00:06:06Anstatt zu fragen, was die beste Chunk-Größe pro Daten ist, wollten wir es herausfinden. Wir haben einen Datensatz genommen
00:06:14und diesen mehrfach dupliziert. In diesem Fall sechsmal. Bei jeder Duplikation,
00:06:23in jeder Instanz ist die Chunk-Größe anders. Wir haben also eine Datenbank mit einer Chunk-Größe von 2000,
00:06:28eine Datenbank mit einer Chunk-Größe von 1000 und so weiter und so fort. Und das haben wir mit mehreren Datensätzen gemacht:
00:06:36QMSUM, einem Datensatz mit Besprechungstranskripten; Narrative QA, einer Frage-Antwort-Sammlung zu
00:06:41Romanen; und dem Seinfeld-Datensatz, bei dem es um Trivia über das Nichts geht. Nicht wirklich. Es sind Trivia-Fragen
00:06:49zu den Transkripten von Seinfeld. Das ist quasi ein Trolling-Datensatz, den wir intern gebaut haben. Wir haben ihn auch
00:06:56veröffentlicht, falls am Ende jemand den Link möchte. Und wir haben ihn mit allen getestet, um zu sehen, was passiert.
00:07:03Zunächst wollten wir einfach für jeden Datensatz sehen, welche Chunk-Größe am besten abschneidet. Und was
00:07:10wir hier sehen, ist ein Beispiel aus dem Seinfeld-Datensatz, bei dem im Grunde zwei Abfragen,
00:07:16die von Natur aus unterschiedlich sind, je nach Chunk-Größe zu verschiedenen Ergebnissen führen. Die erste Frage lautet also: Wie heißt
00:07:24Jerrys Lieblingshemd? Sie sehen, das ist eine sehr fokussierte, eine sehr spezifische Frage.
00:07:28Die Antwort darauf ist wahrscheinlich sehr kompakt. Und das ist etwas, bei dem eine kleinere Chunk-Größe
00:07:33am besten abschneidet. Und Sie sehen: Rang 1 im Vergleich zu einem Rang schlechter als 50 bei einer festen Chunk-Größe
00:07:43von 100. Eine Frage wie: „Wen beschreibt Jerry als seinen Erzfeind und die pure Finsternis?“ –
00:07:50wobei ich nicht einmal so ein großer Seinfeld-Fan bin und trotzdem weiß, dass es Newman ist. Aber wenn man sich das Transkript ansieht,
00:07:56ist das nicht so leicht zu finden. Und man sieht, dass sich das stark ändert, oder? Wenn man eine
00:08:02kleine Chunk-Größe verwendet, bekommt man die Antwort nicht. Und was wir getan haben, um das – nachdem wir
00:08:10das alles durchgespielt hatten –, wir haben uns gefragt: Was wäre, wenn wir ein Orakel hätten, oder einen Dschinn, wenn man so will,
00:08:19der uns für jede Abfrage verrät, welches die beste Chunk-Größe für das Retrieval ist? Das ist im Wesentlichen das
00:08:25Orakel-Experiment. Das wollten wir wissen, um das Potenzial zu sehen. Das ist nicht – wir haben bereits die
00:08:33Fähigkeit, hier ein System aufzubauen. Wir wollen nur sehen, welches Potenzial hier schlummert. Und was man
00:08:38hier in diesem Diagramm sehen kann: All die blauen – erstens zeigt die y-Achse den Recall. Höher ist besser. Die
00:08:46x-Achse ist die Anzahl der abgerufenen Chunks. Es ist also Recall bei k im Verhältnis zu k. Man sieht, dass alle blauen Linien
00:08:52wahrscheinlich kaum voneinander zu unterscheiden sind, aber jede von ihnen stellt die Leistung für eine feste Chunk-Größe dar. Die orangefarbene Linie hingegen
00:09:01ist die Orakel-Linie. Das ist – für jede Abfrage haben wir die jeweils beste davon herausgegriffen. Und man sieht, dass das
00:09:09über mehrere Datensätze hinweg passiert. Bei vielen von ihnen kann man tatsächlich beobachten, dass sich die blauen Linien
00:09:16schneiden, was bedeutet, dass bei vielen Datensätzen tatsächlich keine Chunk-Größe dominiert. Und was noch
00:09:24viel interessanter ist: Es gibt ein enormes Potenzial. Die Lücke, die man zwischen der orangefarbenen Linie
00:09:30und allen blauen Linien sieht, ist groß. Und wenn ich groß sage, meine ich etwa 20 bis 40 Prozent allein dadurch,
00:09:38dass man eine Strategie beim Chunking anwendet. Und zwar eine ganz einfache Strategie, muss ich hinzufügen. Und das – diese Lücke, das ist es,
00:09:47was Sie die Wahl von 512 oder 1000 oder was auch immer kostet, oder? Diese Zahl ist völlig willkürlich. Das ist der Preis, den Sie zahlen. Und ich
00:09:56denke, das Problem dabei ist folgendes – es ist ein bisschen knifflig, weil es sich im Grunde um ein Informationsproblem handelt, bei dem wir
00:10:07nicht in jeder Phase über die Informationen verfügen, die wir brauchen. Und was meine ich damit? Wenn ich mir den Indexierungsteil ansehe,
00:10:12in dem ich sehr wohl die Kontrolle über die Chunk-Größe habe, weiß ich nicht, wie die Abfragen aussehen werden.
00:10:18Ich kann raten. Ich kann sie vielleicht schätzen. Ich kann es versuchen. Aber ich weiß nicht, was für Abfragen kommen, also kann ich
00:10:25meine Chunk-Größe nicht entsprechend anpassen. Und beim Retrieval-Teil, wo ich meine Abfragen vorliegen habe,
00:10:31kann ich die Chunk-Größe nicht mehr steuern, richtig? Die ist bereits festgelegt. Und ich werde offensichtlich nicht den gesamten
00:10:37Prozess pro Abfrage von vorne beginnen. Also haben wir uns frühere Arbeiten angesehen, namentlich vor allem Entropy,
00:10:47Contextual Retrieval, wo jeder Chunk angereichert wird, sowie andere, die im Wesentlichen versuchen, den latenten
00:10:54Raum jedes Chunks zu verbessern. Aber das ist nicht der Weg, den wir eingeschlagen haben. All diese Ansätze blieben einfach bei dem Modell
00:11:01„Lass uns mit einer festen Chunk-Größe arbeiten“, während wir einen anderen Ansatz gewählt haben. Und zwar sagten wir: Warum auf eine festlegen,
00:11:08wenn wir uns auf mehrere festlegen können? Wir nennen das Multi-Scale-Indexing. Im Grunde machen wir einfach
00:11:16das, was wir zuvor gesehen haben. Wir nehmen also die Datenbank, duplizieren sie und unterteilen sie in Chunks mit verschiedenen
00:11:26Chunk- oder Fenstergrößen. Das ist also das, was bei der Indexierung geschieht. Und zum Zeitpunkt des Retrievals
00:11:34fragen wir alle davon ab. Wenn wir also n Duplikate der Datenbank und Fenstergrößen hatten, müssen wir jetzt
00:11:43sechs verschiedene Retrieval-Aufrufe pro Abfrage ausführen. Entschuldigung, sechs als n. Und wie kombinieren wir sie? Wir können
00:11:52offensichtlich nicht das Orakel verwenden, oder? Das Orakel existiert nur für das Potenzial. Im echten Leben
00:11:57kennen wir die Antwort nicht. Aber was wir tun können, ist, eine Art Zusammenführungsalgorithmus zu finden. Nun würden Sie sagen:
00:12:06Wenn wir das so betrachten, wo liegt das Problem? Die Tatsache, dass wir n Rankings haben,
00:12:13die sich jedoch auf Chunks beziehen. Und Chunks unterschiedlicher Größe sind nicht wirklich vergleichbar,
00:12:19oder? Daher haben wir uns stattdessen für etwas entschieden, das heutzutage ziemlich beliebt ist. Und viele der
00:12:25RAG-Systeme tatsächlich so funktionieren, dass wir statt nur den Chunk abzurufen – wenn wir einen
00:12:30Chunk bekommen – das gesamte Dokument abrufen, oder? Wenn das Kontextfenster wächst, wollen wir immer mehr
00:12:35Kontext bereitstellen. Und in diesem Fall haben wir nun n Rankings derselben Dokumente, weil es eben
00:12:44keine Chunks mehr sind. Und das können wir vergleichen. In diesem Fall kann man sich den Abruf im Wesentlichen
00:12:50als eine Art Abstimmung vorstellen. Alles klar? Es ist also nicht rein auf Rankings basierend. Wir haben nicht ein Ranking und machen dann
00:12:56Wir haben n verschiedene Rankings der relevanten Dokumente und wollen sie alle zu einem
00:13:03alle zu einem zusammenführen. Deshalb verwenden wir etwas namens RRF, Reciprocal Rank Fusion, was im Grunde
00:13:11eine einfache Formel ist. Wir haben verschiedene Dinge ausprobiert. Das hat am besten funktioniert. Und wie man sieht, ist es kein
00:13:17Modell. Es ist nichts, was man speziell machen müsste. Insbesondere ist das einfach ein
00:13:23simples Skript, das praktisch keine Zeit beansprucht. Und so sieht das Gesamtsystem aus. Wir haben also die
00:13:32n-fache Indizierung, fragen dann jede Datenbank mit jeder Abfrage ab und verwenden RRF, um alles
00:13:40zu kombinieren. Und man kann sich denken, dass die Ergebnisse gut sind. Andernfalls würde ich jetzt hier nicht stehen und
00:13:48viel zu selbstbewusst sein. Alles klar? Aber wie man sieht, haben wir es über mehrere Datensätze hinweg getestet, QMSum,
00:13:56Narrative QA, Seinfeld und auch Finance Bench. Wir haben sie alle herangezogen, und es schlägt unsere Ansätze mit fester Größe
00:14:05am besten. Schauen wir uns das in einem Diagramm an. Hier ist es etwas schwer zu erkennen, daher gehe ich es langsam durch. Jede Zeile
00:14:12hier ist eine Chunk-Größe. Man sieht also 50, 100 und so weiter. Die untere Zeile ist unsere Methode. Diese hier, diejenige,
00:14:21bei der man alle nimmt und dann kombiniert. Und jede Spalte ist Recall bei irgendetwas. Also Recall bei 1,
00:14:312, 3 bis hin zu 10. Was man hier sehen kann, sind zwei Dinge, oder? Erstens, dass über
00:14:39Recall hinweg unsere Methode nach wie vor gewinnt, was man für sehr einfach halten könnte, aber die Tatsache, dass man
00:14:46alle kombinieren muss, ist nicht ganz trivial. Und man sieht auch, dass die Qualität
00:14:53tatsächlich zunimmt. Die Heatmap wird merklich grüner. Und nochmal, das war einfach nur
00:14:58etwas, das ich in groß zeigen wollte. Hier sieht man alle vier Datensätze, bei denen wir
00:15:06bessere Ergebnisse erzielen. Wirklich um etwa 20, 30, 40 Prozent bei vielen Dingen. Es gibt auch Ergebnisse,
00:15:14die ich Ihnen hier nicht gezeigt habe, die auf MTab basieren. Wie Sie in unserem Blog sehen können – den Link werde ich später teilen –, erzielen wir
00:15:22auch dort viele Verbesserungen irgendwo zwischen 10 und 40 Prozent, je nach Datensatz.
00:15:30Nun, ich bin nicht naiv. Ich behaupte hier nicht, dass das nichts kostet. Offensichtlich gibt es Kosten,
00:15:36oder? Kein kostenloses Mittagessen. Alles hat seinen Preis. Und ja, das kostet zusätzlichen Speicher.
00:15:43Es kostet etwas zwischen dem 2- bis 5-Fachen, O(1), oder? Eine Konstante an zusätzlichem Speicher, bei der man
00:15:51all diese Kopien der Datenbank vorhalten muss. Wenn man jedoch darüber nachdreht, wirkt sich das Latenz-technisch nicht wirklich
00:15:59darauf aus, weil man den gesamten Abrufteil parallel ausführen kann. Und auch der RRF-Teil nimmt nicht viel Zeit in Anspruch.
00:16:10Ich möchte sagen, dass dies ein sehr schönes Forschungsprojekt war, das wir durchgeführt haben und bei dem wir wirklich tolle Ergebnisse erzielt haben.
00:16:16Es gibt noch Dinge zu tun, oder? Es gibt Bereiche, die man verbessern kann. Es gibt zukünftige Arbeit. Genauer gesagt,
00:16:23wollen wir verstehen, wie viele Chunk-Größen wir eigentlich wollen und welche, oder? Die Tatsache, dass wir mit 50, 100,
00:16:32200 usw. gearbeitet haben, war ziemlich willkürlich, um ehrlich zu sein. Wir müssen also herausfinden, wie man das berechnet und
00:16:40wie viele Kopien man genau benötigt. Außerdem sollten wir über RRF hinausgehen, oder? Dass wir
00:16:46RRF verwenden, liegt daran, dass es von den verwendeten Methoden am besten abgeschnitten hat, aber das bedeutet nicht, dass es
00:16:52keine bessere Methode gibt. Und wenn ich Ihnen etwas mit auf den Weg geben soll, dann würde ich sagen, dass Agenten den
00:16:59Abruf nicht getötet haben. Nichts ist gestorben. Ach komm schon. Es ist nur Infrastruktur. Und das Schlimme ist, dass es
00:17:07Infrastruktur aus dem Jahr 2022 ist. Und mit wirklich einfachen Methoden kann man sein RAG-System oder alles, was mit
00:17:17dem Speichern von Daten und deren Abrufen zu tun hat, um 20 bis 40 Prozent verbessern, und zwar ganz ohne etwas allzu
00:17:26Sophisticatedes. Wenn Sie also mehr darüber lesen möchten, können Sie den Blog lesen. Dort gibt es auch ein Beispielcode
00:17:34sowie den Seinfeld-Datensatz. Das war's. Ich bin Yuval. Vielen Dank, dass Sie dabei waren.
00:17:47Bis zum nächsten Mal.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기