Bewertung von Retrieval-Augmented Generation (RAG): Alles, was Sie wissen sollten
Einführung
Retrieval Augmented Generation (RAG) ist zu einem weit verbreiteten Ansatz für die Implementierung von Generative-AI-Anwendungen geworden, die von Large Language Models (LLMs) unterstützt werden. Durch die Integration externer Wissensquellen verbessert RAG die Fähigkeit des Modells, genauere und kontextuell relevantere Antworten auf spezifische Anfragen zu liefern. Trotz seines Potenzials sind von RAG generierte Antworten nicht immer vollständig korrekt oder konsistent mit dem abgerufenen Wissen.
In einem kürzlich durchgeführten Webinar untersuchte Stefan Webb, Developer Advocate bei Zilliz, Evaluierungsstrategien für RAG-Anwendungen, mit Schwerpunkt auf Methoden zur Bewertung der Leistung von LLMs sowie auf aktuellen Herausforderungen und Einschränkungen in diesem Bereich.
In diesem Blog fassen wir Stefans wichtigste Erkenntnisse zusammen, darunter einen Überblick über verschiedene RAG-Pipeline-Architekturen, Retrieval- und Evaluierungs-Frameworks sowie Beispiele für Verzerrungen und Fehlschläge in LLMs.
RAG-Architektur
Stefan begann den Vortrag mit der Einführung des grundlegenden Konzepts der semantischen Suche, einer entscheidenden Komponente von RAG-Anwendungen. Semantische Suche nutzt Vektordatenbanken wie Milvus oder Zilliz als Wissensspeichersysteme für Vektoreinbettungen. Diese Datenbanken ermöglichen eine effiziente Suche in unstrukturierten Daten, um semantisch ähnliche Kontexte abzurufen, die für die Anfrage eines Benutzers relevant sind. Diese Fähigkeit bildet das Rückgrat von RAG-Systemen und stellt sicher, dass das abgerufene Wissen eng mit der Eingabefrage übereinstimmt, wodurch die Qualität der generierten Antworten verbessert wird.
Abbildung 1 unten veranschaulicht eine grundlegende, naive RAG-Architektur. In diesem Aufbau ruft das System die relevantesten Dokumente basierend auf ihrer semantischen Ähnlichkeit zur Frage des Benutzers ab. Die abgerufenen Informationen werden anschließend in einen strukturierten Prompt mit Anweisungen formatiert und an das LLM übergeben. Das Modell verwendet diesen Kontext, um eine fundierte Antwort zu generieren.
Abbildung 1: Naive RAG
Abbildung 1: Naive RAG
Während die grundlegende RAG-Pipeline relevante Dokumente abrufen und Antworten generieren kann, ist ihre Leistung nicht immer optimal. Einige Ausgaben können an Genauigkeit oder Relevanz mangeln. Um diese Herausforderungen zu bewältigen, ermöglicht ein modularer Ansatz beim Aufbau der RAG-Pipeline schrittweise Verbesserungen in jeder Phase.
Nachfolgend (wie in Abbildung 2 dargestellt) sind zentrale Techniken aufgeführt, die die Effektivität der Pipeline verbessern können.
Abbildung 2: Modulare RAG-Architektur
Abbildung 2: Modulare RAG-Architektur (Quelle)
Query Translation
Dieser Schritt konzentriert sich darauf sicherzustellen, dass die Anfrage des Benutzers vom System richtig verstanden wird. Er übersetzt Anfragen in ein Format oder eine Darstellung, die mit dem zugrunde liegenden Retrieval-Mechanismus übereinstimmt.
Multi-query: Teilt die Hauptanfrage in mehrere fokussierte Unteranfragen auf, um vielfältige, aber relevante Informationen abzurufen.
Step-back: Kehrt zu vorherigen Schritten in der Pipeline zurück, wenn unzureichende Ergebnisse gefunden werden, und verfeinert die Anfrage für ein besseres Retrieval.
RAG Fusion: Führt Ergebnisse aus mehreren Abfragen zusammen, um einen kohärenten und umfassenden Kontext für das LLM bereitzustellen.
Hypothetische Dokumente (HyDE): Beinhaltet das Generieren synthetischer Dokumente oder hypothetischer Kontexte, die dabei helfen können, semantisch ähnliche Dokumente aus der Wissensdatenbank abzurufen, wodurch der Abruf bei abstrakten oder schlecht formulierten Abfragen verbessert wird.
Query Routing
Der Query-Routing-Ansatz leitet die Abfrage an den am besten geeigneten Abrufmechanismus oder die passende Wissensquelle weiter.
Logisches Routing: Leitet Abfragen basierend auf vordefinierten Regeln oder logischen Operatoren weiter, z. B. durch Filtern nach Metadaten oder Domäne.
Semantisches Routing: Leitet Abfragen basierend auf ihren semantischen Eigenschaften an die Datenbank oder das System weiter, das am besten für ihre Verarbeitung geeignet ist.
Query Construction
Query Construction verfeinert, wie Abfragen formuliert werden, damit sie zur Struktur der zugrunde liegenden Datenbanken passen.
Relational DB: Erstellt SQL-ähnliche Abfragen für traditionelle relationale Datenbanken.
Graph DB: Verwendet Graph-Traversal-Cypher-Abfragen, um Knoten und Beziehungen in Graphdatenbanken zu untersuchen.
Vector DB: Nutzt Embeddings, um vektorisierte Abfragen für Suchen nach semantischer Ähnlichkeit zu erstellen.
Indexing
Indexing verbessert die Organisation und Zugänglichkeit der Wissensdatenbank.
Chunk-Optimierung: Zerlegt Dokumente in sinnvolle, abrufbare Chunks und bewahrt dabei den Kontext.
Multi-Representation Indexing: Erstellt mehrere Repräsentationen (z. B. semantische, syntaktische) von Daten für unterschiedliche Abrufanforderungen.
Spezialisierte Embeddings: Verwendet domänenspezifische Embeddings, um den Abruf hochspezialisierter oder technischer Informationen zu verbessern.
Hierarchisches Indexing: Strukturiert den Index hierarchisch für schnellere und genauere Suchvorgänge.
Retrieval
Ruft die relevantesten Dokumente oder Kontexte für eine gegebene Abfrage mithilfe fortgeschrittener Techniken ab.
Ranking: Bewertet abgerufene Dokumente anhand ihrer Relevanz und stellt sicher, dass die besten Treffer priorisiert werden.
Corrective RAG: Passt das Ranking basierend auf Feedback oder zusätzlichen Kriterien an, um die Ergebnisse dynamisch zu verbessern.
Re-retrieval: Ruft Dokumente iterativ erneut ab, wenn die ursprünglichen Ergebnisse die Qualitätsanforderungen nicht erfüllen, und verfeinert den Prozess, bis ein akzeptables Ergebnis gefunden wird.
Dieser modulare Ansatz zum Aufbau einer RAG-Pipeline optimiert jede Komponente unabhängig. Durch die Bewältigung spezifischer Herausforderungen in jeder Phase wird die Pipeline robuster, genauer und anpassungsfähiger, was letztendlich die Qualität der generierten Ausgaben verbessert.
Bewertung von Foundation Models
Unabhängig davon, ob ein naiver oder fortgeschrittener RAG-Ansatz verwendet wird, ist die Bewertung der Leistung jeder RAG-Anwendung unerlässlich. Diese Bewertung hilft dabei, Stärken und Schwächen zu identifizieren und die Zuverlässigkeit und Relevanz des Systems sicherzustellen. Alle LLMs, unabhängig von ihrer Komplexität, erfordern eine gründliche Leistungsbewertung, um potenzielle Einschränkungen, Verzerrungen und Ungenauigkeiten zu adressieren.
Leistungsbewertung
Aber wie messen und bewerten wir die Leistung des Modells? Die Messung der Leistung einer RAG-Anwendung erfordert einen differenzierten Ansatz, da verschiedene Aspekte der Pipeline bewertet werden müssen. Nachfolgend finden sich zentrale Überlegungen und Methoden für eine effektive Leistungsmessung:
Bewertung anhand einer Aufgabe vs. Bewertung anhand seiner selbst
Aufgabenbewertung: Misst die Leistung des Modells anhand eines vordefinierten Satzes von Aufgaben, die häufig Multi-Turn- (z. B. MT-Bench) oder Multi-Task-Szenarien (z. B. MMLU) umfassen. Jede Aufgabe ist mit spezifischen Ground-Truth-Fragen und Referenzantworten verbunden.
Selbstevaluation: Konzentriert sich auf interne Leistungsmetriken, etwa darauf, wie effektiv das Modell Informationen abruft und verarbeitet, ohne dies notwendigerweise mit einem praktischen Anwendungsfall zu verknüpfen. Dies ist nützlich, um die Pipeline-Leistung zu diagnostizieren.
Vergleich von Antworten mit Ground Truth vs. Kontext
Ground-Truth-Vergleich: Bewertet, wie genau die generierte Antwort mit einer vordefinierten, korrekten Antwort (Ground Truth) übereinstimmt. Dieser Ansatz eignet sich gut für objektive Aufgaben wie faktenbasierte Abfragen.
Kontextueller Vergleich: Untersucht, wie gut die Antwort mit dem durch abgerufene Dokumente bereitgestellten Kontext übereinstimmt. Dies ist besonders wichtig für Aufgaben, bei denen Ground Truth nicht verfügbar oder subjektiv ist, wobei Kohärenz und Relevanz betont werden.
Bewertung des Retrievals vs. Bewertung der LLM-Ausgabe
Retrieval-Bewertung: Konzentriert sich auf die Qualität der von der Pipeline abgerufenen Dokumente. Metriken könnten Recall und Precision zwischen den abgerufenen Dokumenten und der Abfrage umfassen.
LLM-Ausgabebewertung: Untersucht die Qualität der endgültigen Ausgabe, die vom Sprachmodell generiert wurde, und berücksichtigt dabei Faktoren wie faktische Konsistenz sowie Relevanz für die Abfrage und den abgerufenen Kontext.
Menschliche Evaluation als der „Goldstandard“
- Menschliche Evaluation bleibt die zuverlässigste Methode zur Bewertung der Leistung, insbesondere bei subjektiven oder komplexen Aufgaben. Menschen können nuancierte Aspekte wie logische Konsistenz, Tonalität und Kreativität beurteilen. Dieser Ansatz lässt sich jedoch aufgrund seines Zeit- und Ressourcenbedarfs nicht gut skalieren.
Verwendung von LLMs zur Bewertung von LLMs (LLM-as-a-Judge)
- Fortschrittlichere und effizientere LLMs (LLM-as-a-Judge) können eingesetzt werden, um die Ausgaben anderer LLMs zu bewerten, insbesondere wenn Ground Truth nicht verfügbar ist. Diese Modelle können Antworten anhand vordefinierter Kriterien wie Relevanz und Korrektheit bewerten und bieten damit eine skalierbare Alternative zur menschlichen Evaluation. Es muss jedoch darauf geachtet werden, keine Verzerrungen durch das bewertende Modell selbst einzuführen.
Stefan setzte die Diskussion fort, indem er zwei Ansätze zur Evaluation ansprach: aufgabenbasierte Evaluation und Selbstevaluation. Aufgabenbasierte Evaluation stützt sich typischerweise auf öffentlich verfügbare Benchmarks, während Selbstevaluation sich stärker auf interne Messgrößen oder Introspektion konzentriert, etwa auf die Untersuchung der Qualität der generierten Antworten und der Relevanz der abgerufenen Informationen.
Aufgabenbasierte Evaluation: Der Benchmark-Ansatz
Aufgabenbasierte Evaluation basiert auf der Verwendung standardisierter, öffentlich verfügbarer Benchmarks, die die Modellleistung über eine Vielzahl von Aufgaben hinweg bewerten. Diese Benchmarks decken häufig verschiedene Wissensdomänen, Frage-Antwort-Fähigkeiten und Konversationsfähigkeiten ab. Einige Beispiele sind:
Wissensbasierte Benchmarks: Diese Benchmarks konzentrieren sich auf Allgemeinwissen und faktenbasierte Fragebeantwortung.
MMLU: Ein vielfältiger Benchmark, der Sprachmodelle über mehrere Domänen hinweg testet, darunter Mathematik, Naturwissenschaften und Geschichte.
HellaSwag: Ein Benchmark, der zur Messung des Common-Sense-Reasoning entwickelt wurde.
ARC: Ein Benchmark, der sich auf Fragebeantwortung mit Schlussfolgerungsfähigkeiten konzentriert.
Benchmarks zur Befolgung von Anweisungen: Diese Benchmarks bewerten die Fähigkeit des Modells, Anweisungen zu befolgen und relevante Antworten zu generieren.
Flan: Eine Reihe von Aufgaben, die die Fähigkeiten zur Befolgung von Anweisungen in LLMs bewerten.
Self-instruct: Bewertet die Fähigkeit des Modells, selbst generierte Anweisungen zu erzeugen und zu befolgen.
NaturalInstructions: Ein groß angelegter Benchmark, der sich auf die Fähigkeit des Modells konzentriert, Anweisungen in natürlicher Sprache zu befolgen.
Konversations-Benchmarks: Diese Benchmarks bewerten die Fähigkeit des Modells, kohärente und relevante Dialoge zu führen.
CoQA: Ein Datensatz für konversationelle Fragebeantwortung, der Modelle anhand von mehrstufigen Dialogen testet.
MMDialog: Ein Konversations-Benchmark, der sich auf die Qualität von Dialogen in verschiedenen Szenarien konzentriert.
OpenAssistant: Ein Benchmark für konversationelle KI, der die Fähigkeit des Modells bewertet, natürliche Gespräche zu führen.
Während Benchmarks standardisierte Bewertungskriterien bieten, erfassen sie häufig nicht die Nuancen menschlicher Interaktion, wie emotionale Intelligenz, Gesprächsfluss und Kontextsensitivität. Beispielsweise könnte eine Antwort gemäß einem Benchmark faktisch korrekt sein, aber dennoch in Bezug auf Natürlichkeit oder Empathie zurückbleiben – zentrale Elemente, die Menschen in realen Gesprächen schätzen. Darüber hinaus spiegeln Benchmarks möglicherweise nicht immer die Komplexität menschlicher Präferenzen wider, die je nach Kontext, Nutzerabsicht und emotionalem Ton variieren können. Deshalb bleibt die menschliche Evaluation ein "Goldstandard" bei der Bewertung konversationeller KI, da sie menschliche Präferenzen berücksichtigt, die Benchmarks häufig übersehen. Aufgrund der kosten- und ressourcenintensiven Natur menschlicher Evaluation können jedoch alternative Methoden, wie etwa introspektionsbasierte Evaluation, als skalierbarere Optionen in Betracht gezogen werden.
Introspektionsbasierte Evaluation
Die introspektionsbasierte Evaluation konzentriert sich auf die Bewertung der Qualität der vom Modell generierten Antworten und ihrer Übereinstimmung mit dem Kontext, mit dem Ziel zu messen, wie gut die Ausgaben des Modells den durch die Eingabe gesetzten Erwartungen entsprechen. Diese Art der Evaluation kann in zwei Hauptkategorien unterteilt werden: Generierungsbasierte Evaluation und Retrieval-basierte Evaluation. Nachfolgend finden sich einige Beispiele relevanter Metriken:
Generierungsbasierte Evaluation
Faithfulness (Groundedness): Diese Metrik misst die faktische Konsistenz der generierten Antwort im Vergleich zum gegebenen Kontext. Wenn das Modell Behauptungen generiert, die durch den abgerufenen Kontext nicht gestützt werden können, werden diese Behauptungen penalisiert. Faithfulness stellt sicher, dass die Ausgabe des Modells sowohl konsistent als auch in den bereitgestellten Informationen verankert ist.
Answer Relevancy: Diese Metrik bewertet, wie gut die Antwort direkt auf die Frage des Nutzers oder den gegebenen Kontext eingeht. Eine hochrelevante Antwort ist sowohl korrekt als auch kontextuell angemessen und liefert die nützlichste Antwort auf die Anfrage.
Retrieval-basierte Evaluation
Context Relevance: Misst, wie relevant die abgerufenen Dokumente oder Kontexte für die Anfrage sind. Idealerweise sollte der abgerufene Kontext nur Informationen enthalten, die zur Beantwortung der Frage notwendig sind. Irrelevante oder überflüssige Informationen können die Qualität der generierten Antwort mindern.
Context Recall: Diese Metrik bewertet, wie gut der abgerufene Kontext mit der Ground Truth übereinstimmt, wobei häufig annotierte Antworten als Referenz verwendet werden. Sie hilft zu bewerten, ob die relevanten Dokumente überhaupt abgerufen wurden, und stellt sicher, dass das Modell über ausreichende Informationen verfügt, um eine sinnvolle Antwort zu generieren.
Für die Metriken Faithfulness, Answer Relevancy und Context Relevance stellt das Fehlen einer Ground Truth eine Herausforderung für die direkte Evaluation dar. In Abwesenheit einer Ground Truth besteht jedoch eine alternative Methode darin, ein LLM-as-a-Judge einzusetzen. Ein starkes LLM kann verwendet werden, um diese Aspekte zu bewerten, indem es die Kohärenz, Relevanz und faktische Verankerung der Antwort analysiert. Durch den Vergleich der generierten Antworten mit seinem eigenen Verständnis von Kontext und Relevanz kann das Modell eine automatisierte Evaluation bereitstellen.
Herausforderungen und Einschränkungen von LLM-as-a-Judge
Während die Verwendung eines LLM-as-a-Judge eine nützliche Alternative zur Bewertung von Metriken sein kann, wenn keine Ground Truth verfügbar ist, bringt dieser Ansatz bestimmte Herausforderungen und Einschränkungen mit sich, die adressiert werden müssen. Das bewertende Modell selbst kann Verzerrungen einführen, die die Qualität und Fairness der Evaluation beeinflussen können. Nachfolgend sind einige häufige Verzerrungen und Herausforderungen aufgeführt, die berücksichtigt werden müssen.
Positionsverzerrung
Positionsbias bezeichnet die Tendenz des bewertenden Modells, Antworten aufgrund ihrer Position im Ranking oder der Reihenfolge, in der sie erscheinen, zu bevorzugen. In vielen Fällen kann das Modell annehmen, dass die erste oder am höchsten eingestufte Antwort relevanter oder genauer ist, unabhängig von ihrer tatsächlichen Qualität. Dies kann zu ungenauen Bewertungen führen, insbesondere in Fällen, in denen die richtige Antwort aufgrund der Voreingenommenheit des Modells zugunsten von Spitzenpositionen niedriger eingestuft wird.
Abbildung 3: Positionsbias
Abbildung 3: Positionsbias (Quelle)
Ausführlichkeitsbias
Ausführlichkeitsbias tritt auf, wenn das bewertende Modell dazu neigt, längere, detailliertere Antworten zu bevorzugen, selbst wenn diese nicht unbedingt genauer oder relevanter sind. In einigen Fällen kann das Modell Ausführlichkeit fälschlicherweise mit Qualität gleichsetzen und längeren Antworten, die unnötige Informationen enthalten, höhere Bewertungen zuweisen. Dies kann den Bewertungsprozess verzerren, insbesondere in Kontexten, in denen prägnante, klare Antworten wünschenswerter sind.
Abbildung 4: Ausführlichkeitsbias
Abbildung 4: Ausführlichkeitsbias (Quelle)
Falsche Beurteilung
Eine weitere Einschränkung ist die Möglichkeit falscher Beurteilungen. Ein LLM-as-a-Judge kann, wie jedes Modell, Fehler bei der Bewertung der Qualität oder Relevanz einer Antwort machen. Beispielsweise kann es den Kontext falsch interpretieren, subtile Details übersehen oder Nuancen in der Antwort nicht erkennen, was zu falschen oder irreführenden Bewertungsergebnissen führt
Abbildung 5: Falsche Beurteilung
Abbildung 5: Falsche Beurteilung (Quelle)
Falsche Beurteilung mit Chain-of-Thought
Chain-of-Thought (CoT)-Reasoning in LLM-basierter Bewertung führt komplexe Mechanismen der Fehlerfortpflanzung ein, die die Bewertungsgenauigkeit erheblich beeinträchtigen können. Jeder Zwischenschritt der Schlussfolgerung fungiert als potenzieller Fehlerpunkt, an dem selbst eine geringfügige Fehlinterpretation oder logische Inkonsistenz zu zunehmend erheblichen Fehlern im endgültigen Urteil eskalieren kann. Wenn beispielsweise ein früher Schritt in der Schlussfolgerungskette eine wichtige kontextuelle Nuance missversteht oder einen bestimmten Aspekt der Antwort falsch gewichtet, bauen die nachfolgenden Schlussfolgerungsschritte auf dieser fehlerhaften Grundlage auf und verstärken den anfänglichen Fehler exponentiell.
Abbildung 6: Falsche Beurteilung mit Chain-of-thought
Abbildung 6: Falsche Beurteilung mit Chain-of-thought (Quelle)
Diese Verzerrungen unterstreichen die Bedeutung der Einführung von Bewertungsstrategien, die die Einschränkungen von LLM-as-a-Judge-Ansätzen adressieren. Eine Lösung besteht darin, LLM-Modelle zu verwenden, die speziell für Bewertungszwecke feinabgestimmt wurden, wie GroundedAI oder Flow-Judge-v0.1. Eine weitere Strategie besteht darin, LLM-as-a-Judge-Bewertungen nach Möglichkeit mit menschlichen Bewertungen zu kombinieren. Menschliche Bewerter bringen ein nuanciertes Verständnis und Kontextbewusstsein mit, das automatisierten Modellen möglicherweise fehlt. Regelmäßige Audits und iterative Verbesserungen an bewertenden Modellen sind ebenfalls unerlässlich, um Verzerrungen zu minimieren und die Zuverlässigkeit zu erhöhen.
Open-Source-Evaluierungsframeworks
Zusätzlich zu LLM-as-a-Judge-Techniken werden mehrere Open-Source-Evaluierungsframeworks auf dem Markt häufig verwendet, um RAG-Anwendungen zu bewerten. Diese Frameworks bieten strukturierte Methoden und Werkzeuge, um die Retrieval- und Generierungsleistung effektiv zu bewerten:
RAGAS: Ein Framework zur Bewertung von RAG-Systemen mit Metriken, die auf RAG-Anwendungen zugeschnitten sind.
DeepEval: Ein flexibles und robustes Tool zur Evaluierung von RAG- oder Fine-Tuning-Systemen anhand mehrerer Evaluierungsmetriken.
ARES: Entwickelt für die Evaluierung von RAG-Modellen, mit Schwerpunkt auf Kontextrelevanz, Antworttreue und Antwortrelevanz.
HuggingFace Lighteval: Bietet leichtgewichtige, erweiterbare Tools zur Evaluierung von RAG-Anwendungen über mehrere Backends hinweg (z. B. transformers, tgi, vllm oder nanotron).
Diese Frameworks vereinfachen den Evaluierungsprozess und helfen dabei, Leistungsmetriken über verschiedene Systeme hinweg zu standardisieren, wodurch Vergleichbarkeit und Verbesserung gefördert werden.
Fazit
Retrieval-Augmented Generation (RAG) ist ein transformativer Ansatz zur Erweiterung der Fähigkeiten von Large Language Models (LLMs). Sein Erfolg hängt jedoch von robuster Evaluierung und kontinuierlicher Verfeinerung ab. Wie Stefan im Webinar hervorhob, ist die RAG-Pipeline komplex und umfasst mehrere Phasen von der Abfrageübersetzung bis zur Generierung der finalen Antwort. Die Herausforderungen sind erheblich – von der Minderung von Verzerrungen bei LLM-as-a-Judge-Evaluierungen bis hin zur Sicherstellung präziser Abrufe und der Generierung von Antworten, die den Erwartungen der Nutzer entsprechen.
Die wichtigste Erkenntnis ist, dass es keine Einheitslösung für die RAG-Evaluierung gibt. Erfolg erfordert einen nuancierten, vielschichtigen Ansatz, der verschiedene Evaluierungstechniken kombiniert: aufgabenbasierte Benchmarks, introspektive Metriken, Open-Source-Evaluierungsframeworks und – wenn möglich – menschliche Bewertung. Tools wie RAGAS, DeepEval und ARES bieten wertvolle Unterstützung, sind aber keine endgültigen Antworten. Stattdessen stellen sie sich weiterentwickelnde Werkzeuge in der sich ständig fortentwickelnden Landschaft der generativen KI dar.
Mit Blick nach vorn liegt die Zukunft von RAG in seiner Anpassungsfähigkeit und kontinuierlichen Verfeinerung. Da KI-Systeme immer ausgefeilter werden, wird die Fähigkeit, ihre Leistung zu evaluieren und zu verbessern, entscheidend sein, um ihr volles Potenzial auszuschöpfen. Durch die Behebung aktueller Einschränkungen und die Nutzung innovativer Evaluierungsmethoden können RAG-Anwendungen konsequent genaue, kontextuell relevante und vertrauenswürdige Informationen liefern und so den Fortschritt im Bereich der KI vorantreiben.
Weiterführende Literatur
Weiterlesen
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.