KI-Agenten auf dem Boden der Tatsachen halten: Kontext-Engineering-Strategien zur Verhinderung von Kontextverfälschung mit Milvus

Wenn Sie schon einmal mit langwierigen LLM-Gesprächen gearbeitet haben, kennen Sie wahrscheinlich diesen frustrierenden Moment: Nach der Hälfte eines langen Gesprächs beginnt das Modell abzudriften. Die Antworten werden vage, die Argumentation wird schwächer, und wichtige Details verschwinden auf mysteriöse Weise. Wenn Sie jedoch genau dieselbe Aufforderung in einem neuen Chat stellen, verhält sich das Modell plötzlich konzentriert, genau und geerdet.

Das liegt nicht daran, dass das Modell "müde" wird - es ist eine Kontextverfälschung. Je länger ein Gespräch dauert, desto mehr Informationen muss das Modell jonglieren, und seine Fähigkeit, Prioritäten zu setzen, nimmt langsam ab. Antropische Studien zeigen, dass die Abrufgenauigkeit um 15-30 % sinken kann, wenn sich die Kontextfenster von etwa 8K Token auf 128K Token ausdehnen. Das Modell hat immer noch Platz, aber es verliert den Überblick über das, was wichtig ist. Größere Kontextfenster helfen, das Problem zu verzögern, aber sie beseitigen es nicht.

Hier kommt das Context Engineering ins Spiel. Anstatt dem Modell alles auf einmal zu geben, formen wir das, was es sieht: Wir rufen nur die Teile ab, die wichtig sind, komprimieren das, was nicht mehr ausführlich sein muss, und halten die Eingabeaufforderungen und Werkzeuge so übersichtlich, dass das Modell darüber nachdenken kann. Das Ziel ist einfach: wichtige Informationen im richtigen Moment zur Verfügung stellen und den Rest ignorieren.

Das Retrieval spielt hier eine zentrale Rolle, insbesondere bei lang laufenden Agenten. Vektordatenbanken wie Milvus bilden die Grundlage, um relevantes Wissen effizient wieder in den Kontext einzubinden, so dass das System auch dann noch auf dem Boden der Tatsachen bleibt, wenn die Aufgaben an Tiefe und Komplexität zunehmen.

In diesem Blog befassen wir uns mit der Frage, wie es zur Kontextrotation kommt, mit den Strategien, die Teams zur Bewältigung dieses Phänomens einsetzen, und mit den Architekturmustern - von der Abfrage bis zum Prompt-Design -, die KI-Agenten über lange, mehrstufige Arbeitsabläufe hinweg fit halten.

Warum Kontextfäule auftritt

Oft wird angenommen, dass ein KI-Modell mit mehr Kontext zu besseren Antworten führt. Aber das stimmt nicht wirklich. Auch Menschen haben mit langen Eingaben zu kämpfen: Die Kognitionswissenschaft zeigt, dass unser Arbeitsgedächtnis etwa 7±2 Informationsblöcke speichert. Wenn wir darüber hinausgehen, beginnen wir, Details zu vergessen, zu verwischen oder falsch zu interpretieren.

LLMs zeigen ein ähnliches Verhalten - nur in einem viel größeren Maßstab und mit dramatischeren Fehlermöglichkeiten.

Das Grundproblem liegt in der Transformer-Architektur selbst. Jedes Token muss sich selbst mit jedem anderen Token vergleichen und paarweise Aufmerksamkeit über die gesamte Sequenz hinweg erzeugen. Das bedeutet, dass die Berechnung mit der Kontextlänge O(n²) wächst. Wenn Sie Ihre Eingabeaufforderung von 1K Token auf 100K erweitern, wird das Modell nicht "härter arbeiten" - es multipliziert die Anzahl der Token-Interaktionen um das 10.000-fache.

Dann gibt es noch das Problem mit den Trainingsdaten. Modelle sehen viel mehr kurze Sequenzen als lange. Wenn Sie also von einem LLM verlangen, in extrem großen Kontexten zu operieren, drängen Sie es in ein System, für das es nicht besonders trainiert wurde. In der Praxis ist das Denken in sehr langen Kontexten für die meisten Modelle oft nicht mehr möglich.

Trotz dieser Grenzen sind lange Kontexte heute unvermeidlich. Bei den frühen LLM-Anwendungen handelte es sich meist um Einzelaufgaben wie Klassifizierung, Zusammenfassung oder einfache Generierung. Heute verlassen sich mehr als 70 % der KI-Systeme in Unternehmen auf Agenten, die über viele Interaktionsrunden hinweg aktiv bleiben, oft stundenlang, und verzweigte, mehrstufige Arbeitsabläufe verwalten. Langlebige Sitzungen sind von der Ausnahme zum Standard geworden.

Die nächste Frage lautet also: Wie können wir die Aufmerksamkeit des Modells aufrechterhalten, ohne es zu überfordern?

Context Retrieval - Ansätze zur Lösung des Kontextproblems

Retrieval ist einer der wirksamsten Hebel, die wir haben, um Kontextfäule zu bekämpfen, und in der Praxis zeigt sich dies in komplementären Mustern, die Kontextfäule aus verschiedenen Blickwinkeln angehen.

1. Just-in-Time-Abruf: Unnötiger Kontext wird reduziert

Eine der Hauptursachen für Context Rot ist die Überfrachtung des Modells mit Informationen, die es noch nicht braucht. Claude Code - Anthropic's Coding Assistant - löst dieses Problem mit Just-in-Time (JIT) Retrieval, einer Strategie, bei der das Modell Informationen nur dann abruft, wenn sie relevant werden.

Anstatt ganze Codebasen oder Datensätze in seinen Kontext zu packen (was die Gefahr des Abdriftens und Vergessens stark erhöht), unterhält Claude Code einen winzigen Index: Dateipfade, Befehle und Dokumentationslinks. Wenn das Modell eine bestimmte Information benötigt, ruft es dieses spezifische Element ab und fügt es in dem Momentin den Kontext ein , in dem es von Bedeutung ist - nichtvorher.

Wenn Sie Claude Code z. B. bitten, eine 10-GB-Datenbank zu analysieren, versucht es nie, die ganze Datenbank zu laden. Er arbeitet eher wie ein Ingenieur:

1. Er führt eine SQL-Abfrage aus, um Zusammenfassungen des Datensatzes auf hoher Ebene zu erstellen.

2. Verwendet Befehle wie head und tail, um Beispieldaten anzuzeigen und ihre Struktur zu verstehen.

3. Behält nur die wichtigsten Informationen - wie z. B. Schlüsselstatistiken oder Beispielzeilen - im Kontext bei.

Durch die Minimierung der im Kontext gehaltenen Informationen verhindert die JIT-Abruffunktion die Anhäufung irrelevanter Token, die zu Fäulnis führen. Das Modell bleibt fokussiert, da es immer nur die Informationen sieht, die für den aktuellen Schlussfolgerungsschritt erforderlich sind.

2. Pre-retrieval (Vektorsuche): Verhindern von Kontextabweichungen, bevor sie beginnen

Manchmal kann das Modell nicht dynamisch nach Informationen "fragen" - Kundensupport, Q&A-Systeme und Agenten-Workflows benötigen oft das richtige Wissen , bevor die Generierung beginnt. An dieser Stelle wird die Vorabrecherche entscheidend.

Kontextverfälschungen treten häufig auf, weil dem Modell ein großer Haufen Rohtext vorgelegt wird und von ihm erwartet wird, dass es heraussortiert, was wichtig ist. Pre-Retrieval kehrt dies um: Eine Vektordatenbank (wie Milvus und Zilliz Cloud) identifiziert die relevantesten Teile vor der Inferenz und stellt sicher, dass nur hochwertiger Kontext das Modell erreicht.

In einer typischen RAG-Konfiguration:

• Dokumente werden eingebettet und in einer Vektordatenbank wie Milvus gespeichert.

• Bei der Abfrage findet das System durch Ähnlichkeitssuche eine kleine Menge hochrelevanter Teile.

• Nur diese Chunks werden in den Kontext des Modells aufgenommen.

Dies verhindert Fäulnis in zweierlei Hinsicht:

• Rauschunterdrückung: irrelevanter oder wenig verwandter Text wird gar nicht erst in den Kontext aufgenommen.

• Effizienz: Die Modelle verarbeiten viel weniger Token, wodurch die Gefahr, dass wesentliche Details verloren gehen, verringert wird.

Milvus kann Millionen von Dokumenten in Millisekunden durchsuchen, was diesen Ansatz ideal für Live-Systeme macht, bei denen Latenzzeiten eine Rolle spielen.

3. Hybrides JIT- und Vektor-Retrieval

Die auf der Vektorsuche basierende Vorabrecherche löst einen wesentlichen Teil der Kontextverfälschung, indem sie sicherstellt, dass das Modell mit Informationen mit hohem Signalgehalt und nicht mit rohem, übergroßem Text beginnt. Anthropic hebt jedoch zwei echte Herausforderungen hervor, die von den Teams oft übersehen werden:

• Aktualität: Wenn die Wissensbasis schneller aktualisiert wird, als der Vektorindex neu aufgebaut wird, kann das Modell auf veraltete Informationen zurückgreifen.

• Genauigkeit: Bevor eine Aufgabe beginnt, ist es schwierig, genau vorherzusagen, was das Modell benötigen wird - insbesondere bei mehrstufigen oder explorativen Workflows.

Bei realen Arbeitslasten ist daher eine hybride Anwendung die optimale Lösung.

• Vektorsuche für stabiles, zuverlässiges Wissen

• Agentengesteuerte JIT-Exploration für Informationen, die sich weiterentwickeln oder erst in der Mitte einer Aufgabe relevant werden

Durch die Kombination dieser beiden Ansätze erhalten Sie die Geschwindigkeit und Effizienz der Vektorsuche für bekannte Informationen und die Flexibilität des Modells, neue Daten zu entdecken und zu laden, sobald sie relevant werden.

Schauen wir uns an, wie dies in einem realen System funktioniert. Nehmen wir zum Beispiel einen Produktionsdokumentationsassistenten. Die meisten Teams entscheiden sich schließlich für eine zweistufige Pipeline: Milvus-gestützte Vektorsuche + agentenbasiertes JIT-Retrieval.

1. Milvus-gestützte Vektorsuche (Pre-retrieval)

• Konvertieren Sie Ihre Dokumentation, API-Referenzen, Änderungsprotokolle und bekannte Probleme in Einbettungen.

• Speichern Sie sie in der Milvus-Vektor-Datenbank mit Metadaten wie Produktbereich, Version und Aktualisierungszeit.

• Wenn ein Benutzer eine Frage stellt, führen Sie eine semantische Suche durch, um die wichtigsten K relevanten Segmente zu erfassen.

Auf diese Weise werden etwa 80 % der Routineanfragen in weniger als 500 ms gelöst, wodurch das Modell einen starken, kontextresistenten Ausgangspunkt erhält.

2. Agentengestützte Erkundung

Wenn die anfängliche Suche nicht ausreicht, z. B. wenn der Benutzer nach etwas sehr Speziellem oder Zeitkritischem fragt, kann der Agent Tools aufrufen, um neue Informationen zu beschaffen:

• Verwendung von search_code zum Auffinden bestimmter Funktionen oder Dateien in der Codebasis

• Verwenden Sie run_query, um Echtzeitdaten aus der Datenbank abzurufen.

• Verwenden Sie fetch_api, um den aktuellen Systemstatus abzurufen.

Diese Aufrufe dauern in der Regel 3 bis 5 Sekunden, stellen aber sicher, dass das Modell immer mit aktuellen, genauen und relevanten Daten arbeitet - selbst bei Fragen, die das System vorher nicht vorhersehen konnte.

Diese hybride Struktur stellt sicher, dass der Kontext zeitnah, korrekt und aufgabenspezifisch bleibt, wodurch das Risiko einer Kontextverfälschung in langlaufenden Agenten-Workflows drastisch reduziert wird.

Milvus ist in diesen hybriden Szenarien besonders effektiv, weil es Folgendes unterstützt:

• Vektorsuche + skalare Filterung, die semantische Relevanz mit strukturierten Beschränkungen kombiniert

• Inkrementelle Updates, so dass Einbettungen ohne Ausfallzeiten aktualisiert werden können

Dies macht Milvus zu einem idealen Rückgrat für Systeme, die sowohl ein semantisches Verständnis als auch eine präzise Kontrolle darüber benötigen, was abgerufen wird.

Sie könnten zum Beispiel eine Abfrage wie diese durchführen:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Wie wählt man den richtigen Ansatz für den Umgang mit Context Rot

Da es sowohl die Vektorsuche als auch die Just-in-Time-Suche und die hybride Suche gibt, stellt sich natürlich die Frage, welche Methode Sie verwenden sollten.

Hier ist ein einfacher, aber praktischer Weg zur Auswahl - je nachdem, wie stabil Ihr Wissen ist und wie vorhersehbar der Informationsbedarf des Modells ist.

1. Vektorsuche → Am besten für stabile Bereiche

Wenn sich der Bereich nur langsam ändert, aber Präzision erfordert - Finanzen, juristische Arbeit, Einhaltung von Vorschriften, medizinische Dokumentation - dann ist eine von Milvus betriebene Wissensdatenbank mit Pre-Retrieval in der Regel die richtige Lösung.

Die Informationen sind klar definiert, Aktualisierungen kommen selten vor und die meisten Fragen können durch das Abrufen semantisch relevanter Dokumente im Voraus beantwortet werden.

Vorhersehbare Aufgaben + stabiles Wissen → Pre-Retrieval.

2. Just-in-Time Retrieval → Am besten für dynamische, explorative Arbeitsabläufe

In Bereichen wie Software-Engineering, Debugging, Analytik und Datenwissenschaft ändern sich die Umgebungen schnell: neue Dateien, neue Daten, neue Bereitstellungszustände. Das Modell kann nicht vorhersagen, was es benötigt, bevor die Aufgabe beginnt.

Unvorhersehbare Aufgaben + sich schnell änderndes Wissen → Just-in-Time-Abfrage.

3. Hybrider Ansatz → Wenn beide Bedingungen erfüllt sind

Viele reale Systeme sind weder rein stabil noch rein dynamisch. Beispielsweise ändert sich die Entwicklerdokumentation nur langsam, während sich der Zustand einer Produktionsumgebung im Minutentakt ändert. Mit einem hybriden Ansatz können Sie:

• Laden von bekanntem, stabilem Wissen mittels Vektorsuche (schnell, geringe Latenz)

• Abrufen dynamischer Informationen mit Agententools bei Bedarf (genau, aktuell)

Gemischtes Wissen + gemischte Aufgabenstruktur → Hybrider Retrieval-Ansatz.

Was, wenn das Kontextfenster immer noch nicht ausreicht?

Kontext-Engineering hilft, die Überlastung zu reduzieren, aber manchmal ist das Problem grundlegender: Die Aufgabe passt einfach nicht, selbst bei sorgfältigem Zuschnitt.

Bestimmte Arbeitsabläufe - wie die Migration einer großen Codebasis, die Überprüfung von Architekturen mit mehreren Repositories oder die Erstellung umfangreicher Forschungsberichte - können mehr als 200.000 Kontextfenster umfassen, bevor das Modell das Ende der Aufgabe erreicht. Selbst wenn die Vektorsuche die Hauptarbeit leistet, erfordern einige Aufgaben einen beständigeren, strukturierten Speicher.

Vor kurzem hat Anthropic drei praktische Strategien angeboten.

1. Komprimierung: Signal bewahren, Rauschen entfernen

Wenn sich das Kontextfenster seiner Grenze nähert, kann das Modell frühere Interaktionen zu prägnanten Zusammenfassungen komprimieren. Eine gute Komprimierung erhält

• Wichtige Entscheidungen

• Beschränkungen und Anforderungen

• Offene Fragen

• Relevante Muster oder Beispiele

Und beseitigt:

• Ausführliche Werkzeugausgaben

• Irrelevante Protokolle

• Redundante Schritte

Die Herausforderung ist das Gleichgewicht. Wenn Sie zu stark komprimieren, gehen dem Modell wichtige Informationen verloren; wenn Sie zu wenig komprimieren, gewinnen Sie nur wenig Platz. Bei einer effektiven Komprimierung bleiben das "Warum" und das "Was" erhalten, während das "Wie wir hierher gekommen sind" weggelassen wird.

2. Strukturierte Notizen: Stabile Informationen aus dem Kontext herausnehmen

Anstatt alles innerhalb des Modellfensters zu speichern, kann das System wichtige Fakten in einem externen Speicherablegen - einerseparaten Datenbank oder einem strukturierten Speicher, den der Agent bei Bedarf abfragen kann.

Claudes Pokémon-Agent-Prototyp speichert zum Beispiel dauerhafte Fakten wie:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

In der Zwischenzeit bleiben flüchtige Details - Kampfprotokolle, lange Werkzeugausgaben - außerhalb des aktiven Kontexts. Dies spiegelt die Verwendung von Notizbüchern durch Menschen wider: Wir speichern nicht jedes Detail in unserem Arbeitsspeicher; wir speichern Referenzpunkte extern und schlagen sie bei Bedarf nach.

Die strukturierte Aufzeichnung von Notizen verhindert, dass der Kontext durch wiederholte, unnötige Details verfälscht wird, und gibt dem Modell eine zuverlässige Quelle der Wahrheit.

3. Unter-Agenten-Architektur: Aufteilung und Eroberung großer Aufgaben

Für komplexe Aufgaben kann eine Multi-Agenten-Architektur entworfen werden, bei der ein leitender Agent die Gesamtarbeit überwacht, während mehrere spezialisierte Sub-Agenten bestimmte Aspekte der Aufgabe bearbeiten. Diese Subagenten tauchen tief in große Datenmengen ein, die mit ihren Teilaufgaben zusammenhängen, liefern aber nur die knappen, wesentlichen Ergebnisse zurück. Dieser Ansatz wird häufig in Szenarien wie Forschungsberichten oder Datenanalysen verwendet.

In der Praxis ist es am besten, mit einem einzigen Agenten in Kombination mit einer Komprimierung zu beginnen, um die Aufgabe zu bewältigen. Externer Speicher sollte nur dann eingesetzt werden, wenn die Notwendigkeit besteht, den Speicher über Sitzungen hinweg beizubehalten. Die Multi-Agenten-Architektur sollte für Aufgaben reserviert werden, die tatsächlich eine parallele Verarbeitung komplexer, spezialisierter Teilaufgaben erfordern.

Jeder Ansatz erweitert den effektiven "Arbeitsspeicher" des Systems, ohne das Kontextfenster zu sprengen - und ohne einen Kontextwechsel auszulösen.

Bewährte Praktiken für das Entwerfen von Kontext, der tatsächlich funktioniert

Nach der Behandlung des Kontextüberlaufs gibt es einen weiteren, ebenso wichtigen Punkt: die Art und Weise, wie der Kontext überhaupt erstellt wird. Selbst mit Komprimierung, externen Notizen und Unteragenten wird das System Probleme haben, wenn die Eingabeaufforderung und die Tools selbst nicht für lange, komplexe Argumentationen ausgelegt sind.

Anthropic bietet eine hilfreiche Möglichkeit, dies zu betrachten - weniger als eine einzelne Übung zum Schreiben von Prompts, sondern vielmehr als die Konstruktion von Kontext auf drei Ebenen.

System-Eingabeaufforderungen: Finden Sie die Goldlöckchen-Zone

Die meisten Systemaufforderungen scheitern an den Extremen. Zu viele Details - Listen von Regeln, verschachtelte Bedingungen, fest kodierte Ausnahmen - machen den Prompt spröde und schwer zu pflegen. Zu wenig Struktur lässt das Modell raten, was es tun soll.

Die besten Prompts liegen in der Mitte: strukturiert genug, um das Verhalten zu lenken, und flexibel genug, damit das Modell logisch denken kann. In der Praxis bedeutet dies, dass man dem Modell eine klare Rolle, einen allgemeinen Arbeitsablauf und eine leichte Anleitung für das Werkzeug gibt - nicht mehr und nicht weniger.

Ein Beispiel:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Diese Eingabeaufforderung gibt die Richtung vor, ohne das Modell zu überwältigen oder es zu zwingen, mit dynamischen Informationen zu jonglieren, die hier nicht hingehören.

Werkzeug-Design: Weniger ist mehr

Sobald die Systemaufforderung das Verhalten auf hoher Ebene festlegt, übernehmen die Werkzeuge die eigentliche Betriebslogik. Ein überraschenderweise häufiger Fehler in werkzeugunterstützten Systemen besteht darin, dass einfach zu viele Werkzeuge vorhanden sind - oder Werkzeuge, deren Zwecke sich überschneiden.

Eine gute Faustregel ist:

• Ein Werkzeug, ein Zweck

• Explizite, unmissverständliche Parameter

• Keine sich überschneidenden Zuständigkeiten

Wenn ein menschlicher Ingenieur zögern würde, welches Werkzeug er verwenden soll, wird es auch das Modell tun. Ein sauberes Werkzeugdesign reduziert Mehrdeutigkeit, senkt die kognitive Belastung und verhindert, dass der Kontext mit unnötigen Werkzeugversuchen überladen wird.

Dynamische Informationen sollten abgerufen und nicht fest kodiert werden

Die letzte Ebene ist diejenige, die am leichtesten zu übersehen ist. Dynamische oder zeitkritische Informationen - wie Statuswerte, jüngste Aktualisierungen oder benutzerspezifische Zustände - sollten in der Systemeingabeaufforderung überhaupt nicht erscheinen. Das Einbinden in die Eingabeaufforderung garantiert, dass sie bei langen Aufgaben veraltet, aufgebläht oder widersprüchlich wird.

Stattdessen sollten diese Informationen nur bei Bedarf abgerufen werden, entweder durch Abruf oder über Agententools. Die Herausnahme dynamischer Inhalte aus dem Systemprompt verhindert das Verrotten des Kontexts und hält den Argumentationsraum des Modells sauber.

Schlussfolgerung

Mit dem Einzug von KI-Agenten in Produktionsumgebungen in verschiedenen Branchen übernehmen sie längere Arbeitsabläufe und komplexere Aufgaben als je zuvor. In diesen Umgebungen wird die Verwaltung von Kontext zu einer praktischen Notwendigkeit.

Ein größeres Kontextfenster führt jedoch nicht automatisch zu besseren Ergebnissen; in vielen Fällen bewirkt es sogar das Gegenteil. Wenn ein Modell überlastet ist, mit veralteten Informationen gefüttert wird oder durch massive Aufforderungen gezwungen wird, sinkt die Genauigkeit still und leise. Diese langsame, subtile Verschlechterung nennen wir heute Kontextfäule.

Techniken wie JIT-Retrieval, Pre-Retrieval, hybride Pipelines und vektorbasierte semantische Suche zielen alle auf dasselbe Ziel ab: sicherzustellen, dass das Modell die richtigen Informationen zum richtigen Zeitpunkt sieht - nicht mehr und nicht weniger -, damit es auf dem Boden der Tatsachen bleiben und zuverlässige Antworten liefern kann.

Als quelloffene, hochleistungsfähige Vektordatenbank bildet Milvus den Kern dieses Workflows. Sie bietet die Infrastruktur, um Wissen effizient zu speichern und die relevantesten Teile mit geringer Latenzzeit abzurufen. In Kombination mit JIT-Abrufen und anderen ergänzenden Strategien hilft Milvus den KI-Agenten, auch bei immer umfangreicheren und dynamischeren Aufgaben präzise zu bleiben.

Aber die Abfrage ist nur ein Teil des Puzzles. Ein gutes Prompt-Design, ein sauberes und minimales Toolset und sinnvolle Overflow-Strategien - ob Komprimierung, strukturierte Notizen oder Sub-Agenten - sorgen dafür, dass das Modell über lange Sitzungen hinweg konzentriert bleibt. So sieht echtes Context Engineering aus: keine cleveren Hacks, sondern eine durchdachte Architektur.

Wenn Sie möchten, dass KI-Agenten über Stunden, Tage oder ganze Arbeitsabläufe hinweg präzise arbeiten, verdient der Kontext die gleiche Aufmerksamkeit, die Sie auch jedem anderen Kernbestandteil Ihres Stacks widmen.

Haben Sie Fragen oder möchten Sie eine Funktion genauer kennenlernen? Treten Sie unserem Discord-Kanal bei oder stellen Sie Fragen auf GitHub. Sie können auch eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitungen und Antworten auf Ihre Fragen über die Milvus Office Hours zu erhalten.