LLM-Kontext-Bereinigung: Ein Leitfaden für Entwickler für bessere RAG- und AgentenkI-Ergebnisse

Die Kontextfenster in LLMs sind in letzter Zeit riesig geworden. Einige Modelle können eine Million Token oder mehr in einem einzigen Durchgang verarbeiten, und jede neue Version scheint diese Zahl noch zu erhöhen. Das ist aufregend, aber wenn Sie schon einmal etwas gebaut haben, das langen Kontext verwendet, wissen Sie, dass es eine Lücke zwischen dem, was möglich ist, und dem, was nützlich ist, gibt.

Nur weil ein Modell ein ganzes Buch in einer Eingabeaufforderung lesen kann, heißt das nicht, dass man ihm eine geben sollte. Die meisten langen Eingaben sind voll von Dingen, die das Modell nicht braucht. Sobald man anfängt, Hunderttausende von Token in eine Eingabeaufforderung zu packen, erhält man in der Regel langsamere Antworten, höhere Rechnungen und manchmal auch Antworten von geringerer Qualität, weil das Modell versucht, alles auf einmal zu berücksichtigen.

Auch wenn die Kontextfenster immer größer werden, stellt sich die Frage: Was sollen wir da eigentlich reinschreiben? An dieser Stelle kommt Context Pruning ins Spiel. Dabei handelt es sich um einen Prozess, bei dem die Teile des abgerufenen oder zusammengestellten Kontexts entfernt werden, die dem Modell nicht helfen, die Frage zu beantworten. Wenn es richtig gemacht wird, bleibt Ihr System schnell, stabil und viel berechenbarer.

In diesem Artikel werden wir darüber sprechen, warum sich langer Kontext oft anders verhält als erwartet, wie Pruning hilft, die Dinge unter Kontrolle zu halten, und wie Pruning-Tools wie Provence in echte RAG-Pipelines passen, ohne Ihr Setup komplizierter zu machen.

Vier häufige Fehlermöglichkeiten in Systemen mit langem Kontext

Ein größeres Kontextfenster macht das Modell nicht auf magische Weise intelligenter. Sobald man anfängt, eine große Menge an Informationen in die Eingabeaufforderung zu packen, eröffnen sich ganz neue Möglichkeiten, wie etwas schief gehen kann. Hier sind vier Probleme, die bei der Erstellung von Systemen mit langem Kontext oder RAGs immer wieder auftreten können.

1. Context Clash

Context Clash tritt auf, wenn Informationen, die über mehrere Runden hinweg angesammelt wurden, in sich widersprüchlich sind.

Zum Beispiel könnte ein Benutzer zu Beginn eines Gesprächs sagen: "Ich mag Äpfel" und später: "Ich mag kein Obst". Wenn beide Aussagen im Kontext verbleiben, hat das Modell keine zuverlässige Möglichkeit, den Konflikt aufzulösen, was zu inkonsistenten oder zögerlichen Antworten führt.

2. Kontext-Verwirrung

Kontextverwirrung entsteht, wenn der Kontext eine große Menge irrelevanter oder wenig zusammenhängender Informationen enthält, was es dem Modell erschwert, die richtige Aktion oder das richtige Werkzeug auszuwählen.

Dieses Problem tritt besonders bei werkzeugunterstützten Systemen auf. Wenn der Kontext mit unzusammenhängenden Details überladen ist, kann das Modell die Absicht des Benutzers falsch interpretieren und das falsche Werkzeug oder die falsche Aktion auswählen - nicht weil die richtige Option fehlt, sondern weil das Signal unter Rauschen begraben ist.

3. Ablenkung durch den Kontext

Kontextabhängige Ablenkung tritt auf, wenn übermäßige Kontextinformationen die Aufmerksamkeit des Modells dominieren und es sich weniger auf vorher gelerntes Wissen und allgemeine Schlussfolgerungen verlassen kann.

Anstatt sich auf allgemein erlernte Muster zu verlassen, gewichtet das Modell aktuelle Details im Kontext über, selbst wenn diese unvollständig oder unzuverlässig sind. Dies kann zu oberflächlichen oder spröden Schlussfolgerungen führen, die den Kontext zu genau widerspiegeln, anstatt ein übergeordnetes Verständnis anzuwenden.

4. Kontext-Vergiftung

Context Poisoning tritt auf, wenn falsche Informationen in den Kontext einfließen und über mehrere Runden hinweg wiederholt referenziert und verstärkt werden.

Eine einzige falsche Aussage, die zu Beginn des Gesprächs eingeführt wird, kann zur Grundlage für die weitere Argumentation werden. Im weiteren Verlauf des Dialogs baut das Modell auf dieser fehlerhaften Annahme auf, wodurch sich der Fehler vergrößert und das Modell weiter von der richtigen Antwort abdriftet.

Was ist Context Pruning und warum ist es so wichtig?

Sobald man anfängt, sich mit langen Kontexten zu beschäftigen, merkt man schnell, dass man mehr als einen Trick braucht, um die Dinge unter Kontrolle zu halten. In realen Systemen kombinieren Teams in der Regel eine Reihe von Taktiken - RAG, Tool Loadout, Zusammenfassung, Quarantäne bestimmter Nachrichten, Auslagerung alter Historien und so weiter. Sie alle helfen auf unterschiedliche Weise. Aber Context Pruning ist diejenige, die direkt entscheidet, was tatsächlich in das Modell eingespeist wird.

Context Pruning ist, einfach ausgedrückt, der Prozess des automatischen Entfernens irrelevanter, geringwertiger oder widersprüchlicher Informationen, bevor sie in das Kontextfenster des Modells gelangen. Im Grunde handelt es sich dabei um einen Filter, der nur die Textstücke behält, die für die aktuelle Aufgabe am wahrscheinlichsten sind.

Andere Strategien reorganisieren den Kontext, komprimieren ihn oder schieben einige Teile für später beiseite. Pruning ist direkter: Es beantwortet die Frage: "Soll diese Information überhaupt in den Prompt aufgenommen werden?"

Aus diesem Grund ist Pruning in RAG-Systemen besonders wichtig. Die Vektorsuche ist großartig, aber sie ist nicht perfekt. Sie liefert oft eine große Wundertüte von Kandidaten - manche nützlich, manche lose verwandt, manche völlig daneben. Wenn man sie einfach alle in die Eingabeaufforderung einträgt, kommt es zu den bereits erwähnten Fehlermöglichkeiten. Das Pruning sitzt zwischen dem Abruf und dem Modell und entscheidet als Gatekeeper, welche Chunks behalten werden sollen.

Wenn Pruning gut funktioniert, zeigen sich die Vorteile sofort: sauberer Kontext, konsistentere Antworten, geringere Verwendung von Token und weniger seltsame Nebeneffekte durch irrelevanten Text, der sich eingeschlichen hat. Selbst wenn Sie nichts an Ihrem Abruf-Setup ändern, kann das Hinzufügen eines soliden Pruning-Schrittes die Gesamtleistung des Systems spürbar verbessern.

In der Praxis ist Pruning eine der wirksamsten Optimierungen in einer Long-Context- oder RAG-Pipeline - einfache Idee, große Wirkung.

Provence: Ein praktisches Context Pruning Modell

Bei der Untersuchung von Ansätzen zum Context Pruning bin ich auf zwei überzeugende Open-Source-Modelle gestoßen, die bei Naver Labs Europe entwickelt wurden: Provence und seine mehrsprachige Variante, XProvence.

Provence ist eine Methode zum Trainieren eines leichtgewichtigen Context Pruning Modells für Retrieval-augmentierte Generierung, mit besonderem Fokus auf die Beantwortung von Fragen. Ausgehend von einer Benutzerfrage und einer abgerufenen Passage werden irrelevante Sätze identifiziert und entfernt, wobei nur die Informationen erhalten bleiben, die zur endgültigen Antwort beitragen.

Durch das Ausschneiden geringwertiger Inhalte vor der Generierung reduziert Provence das Rauschen in der Eingabe des Modells, verkürzt die Eingabeaufforderungen und verringert die LLM-Inferenzlatenz. Es ist außerdem Plug-and-Play-fähig und kann mit jedem LLM- oder Retrievalsystem verwendet werden, ohne dass eine enge Integration oder architektonische Änderungen erforderlich sind.

Provence bietet mehrere praktische Funktionen für reale RAG-Pipelines.

1. Verstehen auf Dokumentenebene

Provence betrachtet Dokumente als Ganzes, anstatt Sätze isoliert zu bewerten. Dies ist wichtig, da reale Dokumente häufig Verweise wie "es", "dies" oder "die obige Methode" enthalten. Isoliert betrachtet, können diese Sätze mehrdeutig oder sogar bedeutungslos sein. Betrachtet man sie im Kontext, wird ihre Relevanz deutlich. Durch die ganzheitliche Modellierung des Dokuments führt Provence zu genaueren und kohärenteren Bereinigungsentscheidungen.

2. Adaptive Satzauswahl

Provence bestimmt automatisch, wie viele Sätze aus einem abgerufenen Dokument übernommen werden sollen. Anstatt sich auf feste Regeln wie "die ersten fünf Sätze behalten" zu verlassen, passt es sich an die Anfrage und den Inhalt an.

Manche Fragen können mit einem einzigen Satz beantwortet werden, während andere mehrere unterstützende Aussagen erfordern. Provence geht mit dieser Variation dynamisch um, indem es einen Relevanzschwellenwert verwendet, der in allen Domänen gut funktioniert und bei Bedarf angepasst werden kann - in den meisten Fällen ohne manuelle Anpassung.

3. Hohe Effizienz mit integriertem Reranking

Provence wurde entwickelt, um effizient zu sein. Es ist ein kompaktes, leichtgewichtiges Modell, das deutlich schneller und kostengünstiger ist als LLM-basierte Pruning-Ansätze.

Noch wichtiger ist, dass Provence Reranking und Context Pruning in einem einzigen Schritt kombinieren kann. Da Reranking bereits ein Standardschritt in modernen RAG-Pipelines ist, werden durch die Integration von Pruning an dieser Stelle die zusätzlichen Kosten des Context Pruning gegen Null tendieren, während gleichzeitig die Qualität des an das Sprachmodell übergebenen Kontexts verbessert wird.

4. Mehrsprachige Unterstützung durch XProvence

Provence hat auch eine Variante namens XProvence, die die gleiche Architektur verwendet, aber auf mehrsprachigen Daten trainiert wird. Dies ermöglicht die Auswertung von Anfragen und Dokumenten in verschiedenen Sprachen, wie z. B. Chinesisch, Englisch und Koreanisch, und eignet sich daher für mehrsprachige und sprachübergreifende RAG-Systeme.

Wie Provence trainiert wird

Provence verwendet ein sauberes und effektives Trainingsdesign, das auf einer Cross-Encoder-Architektur basiert. Während des Trainings werden die Abfrage und jede abgefragte Passage zu einer einzigen Eingabe verkettet und gemeinsam kodiert. Dadurch kann das Modell den gesamten Kontext der Frage und des Textes auf einmal erfassen und direkt auf deren Relevanz schließen.

Diese gemeinsame Kodierung ermöglicht es Provence, aus feinkörnigen Relevanzsignalen zu lernen. Das Modell ist auf DeBERTa als leichtgewichtigem Kodierer abgestimmt und optimiert, um zwei Aufgaben gleichzeitig zu erfüllen:

1. Relevanzbewertung auf Dokumentenebene (rerank score): Das Modell sagt eine Relevanzbewertung für das gesamte Dokument voraus, die angibt, wie gut es mit der Anfrage übereinstimmt. Ein Wert von 0,8 steht beispielsweise für hohe Relevanz.

2. Relevanzkennzeichnung auf Token-Ebene (binäre Maske): Parallel dazu weist das Modell jedem Token ein binäres Label zu, das angibt, ob es für die Suchanfrage relevant (1) oder irrelevant (0) ist.

Auf diese Weise kann das trainierte Modell die Gesamtrelevanz eines Dokuments beurteilen und feststellen, welche Teile beibehalten oder entfernt werden sollten.

Zum Zeitpunkt der Inferenz sagt Provence die Relevanzkennzeichnungen auf Token-Ebene voraus. Diese Vorhersagen werden dann auf Satzebene aggregiert: Ein Satz wird beibehalten, wenn er mehr relevante als irrelevante Token enthält; andernfalls wird er gestrichen. Da das Modell mit Überwachung auf Satzebene trainiert wird, sind die Token-Vorhersagen innerhalb desselben Satzes tendenziell konsistent, was diese Aggregationsstrategie in der Praxis zuverlässig macht. Das Pruning-Verhalten kann auch durch Anpassung der Aggregationsschwelle eingestellt werden, um ein konservativeres oder aggressiveres Pruning zu erreichen.

Entscheidend ist, dass Provence den Reranking-Schritt wiederverwendet, den die meisten RAG-Pipelines bereits enthalten. Das bedeutet, dass Context Pruning mit wenig bis gar keinem zusätzlichen Overhead hinzugefügt werden kann, was Provence besonders praktisch für reale RAG-Systeme macht.

Evaluierung der Context Pruning Performance über verschiedene Modelle hinweg

Bis jetzt haben wir uns auf das Design und das Training von Provence konzentriert. Der nächste Schritt besteht darin, die Leistung von Provence in der Praxis zu evaluieren: wie gut es den Kontext bereinigt, wie es im Vergleich zu anderen Ansätzen abschneidet und wie es sich unter realen Bedingungen verhält.

Um diese Fragen zu beantworten, haben wir eine Reihe von quantitativen Experimenten entwickelt, um die Qualität der Kontexterkennung zwischen verschiedenen Modellen in realistischen Bewertungsumgebungen zu vergleichen.

Die Experimente konzentrieren sich auf zwei Hauptziele:

• Effektivität des Pruning: Wir messen, wie genau jedes Modell relevante Inhalte beibehält, während irrelevante Informationen entfernt werden, wobei wir Standardkennzahlen wie Precision, Recall und F1-Score verwenden.

• Verallgemeinerung außerhalb der Domäne: Wir bewerten, wie gut jedes Modell bei Datenverteilungen abschneidet, die sich von den Trainingsdaten unterscheiden, und bewerten die Robustheit in Szenarien außerhalb der Domäne.

Verglichene Modelle

• Provence

• XProvence

• OpenSearch Semantic Highlighter (Ein Pruning-Modell, das auf einer BERT-Architektur basiert und speziell für semantische Hervorhebungsaufgaben entwickelt wurde)

Datensatz

Wir verwenden WikiText-2 als Evaluierungsdatensatz. WikiText-2 stammt aus Wikipedia-Artikeln und enthält unterschiedliche Dokumentstrukturen, in denen relevante Informationen oft über mehrere Sätze verteilt sind und semantische Beziehungen nicht trivial sein können.

WikiText-2 unterscheidet sich wesentlich von den Daten, die normalerweise zum Trainieren von Context Pruning-Modellen verwendet werden, ähnelt aber dennoch realen, wissensintensiven Inhalten. Dies macht es gut geeignet für die Evaluierung außerhalb der Domäne, was ein Hauptaugenmerk unserer Experimente ist.

Abfragegenerierung und Beschriftung

Um eine Out-of-Domain Pruning-Aufgabe zu konstruieren, generieren wir automatisch Frage-Antwort-Paare aus dem rohen WikiText-2-Korpus mit GPT-4o-mini. Jedes Bewertungsbeispiel besteht aus drei Komponenten:

• Abfrage: Eine natürlichsprachliche Frage, die aus dem Dokument generiert wurde.

• Kontext: Das vollständige, unveränderte Dokument.

• Ground Truth: Annotationen auf Satzebene, die angeben, welche Sätze die Antwort enthalten (die beibehalten werden sollen) und welche irrelevant sind (die entfernt werden sollen).

Dieser Aufbau definiert natürlich die Aufgabe des Context Pruning: Bei einer Anfrage und einem vollständigen Dokument muss das Modell die Sätze identifizieren, die tatsächlich wichtig sind. Sätze, die die Antwort enthalten, werden als relevant eingestuft und sollten beibehalten werden, während alle anderen Sätze als irrelevant eingestuft und gestrichen werden sollten. Mit dieser Formulierung kann die Qualität des Prunings quantitativ anhand von Precision, Recall und F1-Score gemessen werden.

Entscheidend ist, dass die generierten Fragen nicht in den Trainingsdaten eines bewerteten Modells erscheinen. Daher spiegelt die Leistung eher eine echte Generalisierung als ein Auswendiglernen wider. Insgesamt generieren wir 300 Beispiele, die von einfachen faktenbasierten Fragen über Multi-Hop-Reasoning-Aufgaben bis hin zu komplexeren analytischen Aufforderungen reichen, um reale Nutzungsmuster besser widerzuspiegeln.

Evaluierungs-Pipeline

Optimierung der Hyperparameter: Für jedes Modell führen wir eine Rastersuche über einen vordefinierten Hyperparameterraum durch und wählen die Konfiguration aus, die die F1-Punktzahl maximiert.

Ergebnisse und Analyse

Die Ergebnisse zeigen deutliche Leistungsunterschiede zwischen den drei Modellen.

Provence erzielt mit einer F1-Punktzahl von 66,76 % die beste Gesamtleistung. Seine Präzision(69,53 %) und sein Wiedererkennungswert(64,19 %) sind gut ausgeglichen, was auf eine robuste Verallgemeinerung außerhalb der Domäne hindeutet. Die optimale Konfiguration verwendet einen Pruning-Schwellenwert von 0,6 und α = 0,051, was darauf hindeutet, dass die Relevanzwerte des Modells gut kalibriert sind und dass das Pruning-Verhalten intuitiv und in der Praxis leicht einzustellen ist.

XProvence erreicht eine F1-Punktzahl von 58,97 %, gekennzeichnet durch eine hohe Wiederauffindbarkeit (75,52 %) und eine geringere Genauigkeit (48,37 %). Dies spiegelt eine konservativere Beschneidungsstrategie wider, die der Beibehaltung potenziell relevanter Informationen Vorrang vor der aggressiven Entfernung von Rauschen einräumt. Ein solches Verhalten kann in Bereichen wünschenswert sein, in denen falsch-negative Ergebnisse kostspielig sind - z. B. im Gesundheitswesen oder bei juristischen Anwendungen -, aber es erhöht auch die Anzahl der falsch-positiven Ergebnisse, was die Genauigkeit verringert. Trotz dieses Kompromisses ist XProvence durch seine Mehrsprachigkeit eine gute Option für nicht-englische oder sprachübergreifende Umgebungen.

Im Gegensatz dazu schneidet OpenSearch Semantic Highlighter mit einem F1-Ergebnis von 46,37% (Precision 62,35%, Recall 36,98%) wesentlich schlechter ab. Der Rückstand gegenüber Provence und XProvence deutet auf Einschränkungen sowohl bei der Kalibrierung der Ergebnisse als auch bei der Verallgemeinerung außerhalb der Domäne hin, insbesondere unter Bedingungen außerhalb der Domäne.

Semantische Hervorhebung: Ein weiterer Weg, um zu finden, was im Text wirklich wichtig ist

Nachdem wir nun über das Context Pruning gesprochen haben, lohnt es sich, einen Blick auf ein verwandtes Puzzleteil zu werfen: die semantische Hervorhebung. Technisch gesehen erfüllen beide Funktionen fast dieselbe Aufgabe - sie bewerten Textteile auf der Grundlage ihrer Relevanz für eine Suchanfrage. Der Unterschied besteht darin, wie das Ergebnis in der Pipeline verwendet wird.

Die meisten Leute hören "Hervorhebung" und denken an die klassischen Keyword-Highlighter, die man in Elasticsearch oder Solr sieht. Diese Tools suchen im Wesentlichen nach wörtlichen Schlüsselwortübereinstimmungen und verpacken sie in etwas wie <em>. Sie sind billig und vorhersehbar, aber sie funktionieren nur, wenn der Text genau die gleichen Wörter wie die Abfrage verwendet. Wenn das Dokument Umschreibungen enthält, Synonyme verwendet oder den Begriff anders formuliert, wird er von den herkömmlichen Hervorhebungsprogrammen völlig übersehen.

Die semantische Hervorhebung geht einen anderen Weg. Anstatt nach exakten Übereinstimmungen zu suchen, wird ein Modell verwendet, um die semantische Ähnlichkeit zwischen der Suchanfrage und verschiedenen Textabschnitten zu schätzen. Dadurch können relevante Inhalte auch dann hervorgehoben werden, wenn der Wortlaut völlig unterschiedlich ist. Für RAG-Pipelines, Agenten-Workflows oder jedes KI-Suchsystem, bei dem die Bedeutung wichtiger ist als die Token, bietet die semantische Hervorhebung ein viel klareres Bild davon, warum ein Dokument abgerufen wurde.

Das Problem ist, dass die meisten vorhandenen Lösungen zur semantischen Hervorhebung nicht für KI-Arbeitslasten in der Produktion ausgelegt sind. Wir haben alle verfügbaren Lösungen getestet, und keine von ihnen bot den Grad an Präzision, Latenz oder mehrsprachiger Zuverlässigkeit, den wir für echte RAG- und Agentensysteme benötigten. Also haben wir stattdessen unser eigenes Modell trainiert und zur Verfügung gestellt: zilliz/semantic-highlight-bilingual-v1

Auf einer hohen Ebene lösen Context Pruning und semantische Hervorhebung dieselbe Kernaufgabe: Bei einer Anfrage und einem Textstück muss herausgefunden werden, welche Teile wirklich wichtig sind. Der einzige Unterschied ist, was als nächstes passiert.

• Beim Context Pruning werden die irrelevanten Teile vor der Generierung entfernt.

• Beider semantischen Hervorhebung bleibt der gesamte Text erhalten, aber die wichtigen Abschnitte werden visuell hervorgehoben.

Da der zugrunde liegende Vorgang so ähnlich ist, kann oft dasselbe Modell für beide Funktionen verwendet werden. Das erleichtert die Wiederverwendung von Komponenten im gesamten Stack und macht Ihr RAG-System insgesamt einfacher und effizienter.

Semantische Hervorhebung in Milvus und Zilliz Cloud

Die semantische Hervorhebung wird nun vollständig von Milvus und Zilliz Cloud (dem vollständig verwalteten Service von Milvus) unterstützt und erweist sich bereits als nützlich für alle, die mit RAG oder KI-gesteuerter Suche arbeiten. Die Funktion löst ein sehr einfaches, aber schmerzhaftes Problem: Wenn die Vektorsuche eine Menge Chunks liefert, wie findet man dann schnell heraus, welche Sätze innerhalb dieser Chunks wirklich wichtig sind?

Ohne Hervorhebung müssen die Benutzer ganze Dokumente lesen, nur um zu verstehen, warum etwas gefunden wurde. Mit der integrierten semantischen Hervorhebung markieren Milvus und Zilliz Cloud automatisch die spezifischen Abschnitte, die in semantischem Zusammenhang mit Ihrer Anfrage stehen - selbst wenn der Wortlaut unterschiedlich ist. Sie müssen nicht mehr nach übereinstimmenden Schlüsselwörtern suchen oder raten, warum ein Abschnitt auftaucht.

Das macht die Suche viel transparenter. Anstatt nur "relevante Dokumente" zu liefern, zeigt Milvus , wo die Relevanz liegt. Für RAG-Pipelines ist dies besonders hilfreich, da Sie sofort sehen können, worauf das Modell achten soll, was die Fehlersuche und die Erstellung von Eingabeaufforderungen erheblich erleichtert.

Wir haben diese Unterstützung direkt in Milvus und Zilliz Cloud integriert, so dass Sie keine externen Modelle hinzufügen oder einen anderen Dienst ausführen müssen, um eine brauchbare Attribution zu erhalten. Alles läuft innerhalb des Retrievalpfads: Vektorsuche → Relevanzbewertung → hervorgehobene Spans. Die Lösung ist sofort einsatzbereit und unterstützt mehrsprachige Workloads mit unserem Modell zilliz/semantic-highlight-bilingual-v1.

Ein Blick in die Zukunft

Context Engineering ist noch ziemlich neu, und es gibt noch viel herauszufinden. Selbst wenn Pruning und semantische Hervorhebung in Milvus und Zilliz Cloud gut funktionieren, sind wir noch lange nicht am Ende der Geschichte angelangt. Es gibt eine Reihe von Bereichen, in denen noch echte Entwicklungsarbeit geleistet werden muss - genauere Pruning-Modelle, ohne die Abläufe zu verlangsamen, besserer Umgang mit seltsamen oder domänenfremden Abfragen und die Verknüpfung aller Teile miteinander, damit sich Retrieval → Rerank → Prune → Highlight wie eine einzige saubere Pipeline anfühlt und nicht wie eine Reihe von zusammengeklebten Hacks.

Da die Kontextfenster immer größer werden, werden diese Entscheidungen nur noch wichtiger. Eine gute Kontextverwaltung ist kein "netter Bonus" mehr, sondern wird zu einem Kernbestandteil der Zuverlässigkeit von Systemen mit langen Kontexten und RAGs.

Wir werden weiter experimentieren, Benchmarks durchführen und die Teile ausliefern, die für Entwickler tatsächlich einen Unterschied machen. Das Ziel ist klar: Es soll einfacher werden, Systeme zu erstellen, die bei unordentlichen Daten, unvorhersehbaren Abfragen oder großen Arbeitslasten nicht zusammenbrechen.

Wenn Sie etwas davon besprechen möchten - oder einfach nur Hilfe beim Debuggen benötigen - können Sie in unseren Discord-Kanal einsteigen oder eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitung und Antworten auf Ihre Fragen über die Milvus-Sprechstunde zu erhalten.

Wir freuen uns immer über einen Chat und den Austausch mit anderen Entwicklern.