Auswahl einer Vektor-Datenbank für RAG: Vergleich von acht Optionen
Vergleichen Sie Chroma, Milvus, Qdrant, Weaviate, pgvector, Pinecone, Turbopuffer und TiDB hinsichtlich Skalierbarkeit, Filterfunktionen, Kosten und Betrieb, sowie der Schwächen von Vector RAG.
Quellen: Vector Database for RAG (The Top 10 to Know in 2026)
Die Auswahl einer Vektordatenbank für RAG reduziert sich auf einige wichtige Fragen bezüglich der Größe, des Filterns, der Verwaltung sowie der Anzahl der Operationen, die Ihr Team bewältigen kann. Hier ist die kurze Zusammenfassung vor den Details: Chroma und pgvector eignen sich für kleine Projekte. Qdrant und Milvus sind die üblichen Wahlmöglichkeiten für selbst gehostete Produktionsumgebungen. Pinecone ist die vollständig verwaltete Option. Wenn Postgres bereits in Ihrem Stack vorhanden ist, kostet pgvector nichts zusätzlich, und wenn Sie einfach eine lokale Einrichtung innerhalb weniger Minuten haben möchten, lässt sich Chroma mit einem einzigen pip-Befehl installieren.
Open-Source-Engines wie Qdrant, Milvus und Weaviate können in Bezug auf Recall und Latenz mit bezahlten Plattformen mithalten, wobei jede Variante neben einer optionalen kostenpflichtigen Cloud-Lösung auch eine kostenlose, selbst gehostete Variante anbietet. Eine weitere Zahl, die man sich merken sollte: Die Kombination aus dichter Vektorabrufung und spärlicher BM25-Suchfunktion hat den Recall@10 in Produktivitätsbenchmarks von etwa 78 % auf etwa 91 % erhöht – deshalb kommt die hybride Suche in so vielen der unten aufgeführten Optionen vor.
Vektordatenbanken bilden die Abrufschicht hinter den meisten generativen KI-Apps. Sie ermöglichen es einem Unternehmen, ein Sprachmodell in eigenen Daten zu verankern, sodass die Antworten präzise und auf den jeweiligen Bereich zugeschnitten bleiben. Da die Menge an unstrukturierten Daten zunimmt, wird die Abruffunktion zum Hauptengpass für die Qualität – eine gute Wahl setzt daher voraus, dass man Indexierungsalgorithmen, Filterverhalten sowie die Kosten der Infrastruktur versteht.
Was eine Vektordatenbank tatsächlich leistet
Eine Vektordatenbank speichert hochdimensionale Embeddings und ordnet die gespeicherten Zeilen danach, wie nah sie einem Abfragenvektor liegen, wobei Cosinus-Ähnlichkeit, Skalarprodukt oder L2-Distanz verwendet werden. Ein relationales Suchsystem vergleicht exakte Token, während BM25 die Überschneidung von Begriffen bewertet. Eine Vektorsuche kann Dokumente zu „preiswerten Autos“ für die Abfrage „günstiges Automobil“ zurückgeben, da die beiden Phrasen im Embedding-Raum nah beieinander liegen.
Doch es gibt einen Haken: Die exakte k-nächsten-Nachbarn-Suche kostet pro Abfrage O(N·d), was ab einigen hunderttausend Vektoren nicht mehr praktikabel ist. Vektordatenbanken umgehen dieses Problem, indem sie einen geringen Verlust bei der Trefferquote in Kauf nehmen, um annähernde nächste-Nachbarn-Indizes zu erhalten, die in etwa logarithmischer Zeit antworten.
Was vor der Auswahl gemessen werden sollte
Teams, die die Bewertung überspringen, stoßen in der Praxis oft auf Engpässe. Vier Bereiche verdienen eine genaue Prüfung.
Qualität der Ergebnisabrufung und Latenz. Recall@K gibt an, wie oft das System die wirklich besten Ergebnisse unter seinen Top K Ergebnissen findet. Ein höherer Recall bedeutet, dass das Modell die besten verfügbaren Informationen erhält. Die Latenz in Millisekunden ist genauso wichtig, weshalb Ingenieure auf p95 oder p99 achten, da diese die langsamsten Fälle widerspiegeln, die Nutzer erleben.
Filtern von Metadaten. Oft muss eine Abfrage durch strukturierte Attribute eingegrenzt werden. Eine Suche nach „Unternehmensrichtlinien“ könnte beispielsweise nur Dokumente ab einem bestimmten Datum oder für eine bestimmte Abteilung umfassen. Ein gutes Filtern sorgt dafür, dass irrelevante oder nicht autorisierte Einträge nicht in den Ergebnissen erscheinen. Datenbanken mit Vorfiltern sind in der Regel besser, da sie unerwünschte Einträge bereits vor Beginn der Vektorsuche ausschließen und so die Genauigkeit gewährleisten.
Ökologische Passform. Eine Datenbank wird nützlicher, wenn sie gut mit dem Rest des AI-Stacks zusammenarbeitet. Connector für LangChain und LlamaIndex verkürzen die Zeit bis zur Funktionsfähigkeit eines RAG-Pipelines. Client-Bibliotheken in mehreren Sprachen sowie Unterstützung für AWS, GCP und andere Cloud-Anbieter bestimmen, wie reibungslos die Lösung in vorhandene Unternehmenssoftware integriert werden kann.
Betriebsbereitschaft. Dazu gehört, ob das System in einer anspruchsvollen Produktionsumgebung funktioniert:
- Skalierbarkeit, also die Fähigkeit, mit Milliarden von Vektoren und hohem Abfragenverkehr umzugehen.
- Isolation der Benutzer in Multi-Tenant-Anwendungen.
- Conformität mit Standards wie SOC 2, HIPAA und GDPR.
- Überwachbarkeit, damit Leistung der Suche und Ressourcennutzung kontrolliert werden können.
Kostenlose und open-source Optionen
Open-Source-Engines ermöglichen es Ihnen, Ihre eigene Infrastruktur zu betreiben und wiederkehrende Abonnementgebühren zu vermeiden. Die unten aufgeführten Engines sind grob von leichtesten bis zu schweresten geordnet.
Chroma
Chroma ist eine Embedding-Datenbank, die für Geschwindigkeit bei Entwicklern entwickelt wurde. Sie bietet den kürzesten Weg von einem leeren Repository zu einem funktionsfähigen RAG-Prototyp, und viele Nutzer verwenden sie als ihre erste Vektordatenbank. Sie eignet sich für Hackathons, lokales Entwickeln sowie schnelle Experimente, bei denen die Benutzerfreundlichkeit wichtiger ist als die verteilte Skalierbarkeit.
Was sie bietet: eine kleine Python-API, die von vorübergehenden lokalen Tests zu einem persistenten Client-Server-Modus übergeht, lokale Speicherung mit Unterstützung von SQLite, sodass kein Datenbankserver bereitgestellt werden muss, sowie eingebaute Embedding-Funktionen, die Rohtext bei der Eingabe in Vektoren umwandeln – standardmäßig mit Algorithmen wie all-MiniLM-L6-v2. Sie kann mit LangChain, LlamaIndex, OpenAI und Hugging Face verbunden werden.
Positiv ist, dass die Installation einfach mit pip install chromadb erfolgt, die Umwandlung von Text in Vektoren ohne zusätzlichen Code möglich ist und eine lokale Ausführung volle Kontrolle über Daten und Infrastruktur bietet. Negativ ist hingegen, dass es an den Sicherheitsfunktionen sowie den Multi-Tenancy-Eigenschaften fehlt, die strenge Unternehmensumgebungen benötigen, und es mit speziell entwickelten verteilten Systemen nicht mithalten kann, sobald die Anzahl der Vektoren einige Millionen überschreitet.
Die Kerndatenbank ist unter Apache 2.0 kostenlos verfügbar, und es gibt mittlerweile eine gehostete Cloud-Version für die Skalierung in der Produktion.
Milvus
Milvus ist eine cloud-native, hochverteilte Vektordatenbank, die Rechenleistung von Speicher getrennt hat. Sie richtet sich an Organisationen, die mit extremen Datenvolumina umgehen müssen – mit Hunderten Millionen bis Milliarden von Vektoren –, bei denen eine horizontale Skalierung unverzichtbar und keine Option ist.
Seine Architektur trennt Datenknoten, Abfragenknoten und Indexknoten voneinander. Er unterstützt viele Indextypen, darunter HNSW, IVF und DiskANN, sodass Sie ihn an spezifische Hardware anpassen können. Zudem bietet er eine leistungsstarke, durch GPU beschleunigte Indexierung und Suche. Knoten können ohne Ausfallzeiten dynamisch hinzugefügt oder entfernt werden.
Stärken: Datensätze im Milliardenmaßstab verhalten sich vorhersagbar, ohne starke Anstiege der p99-Latenzzeit. Die strenge Trennung der Knoten ermöglicht es, Rechenleistung genau dorthin zu leiten, wo sie benötigt wird. Zudem gibt es eine große Open-Source-Community mit umfangreicher Dokumentation und Plugins. Schwächen: Die Einrichtung, Anpassung und Nutzung des auf Kubernetes basierenden Systems erfordert erhebliche ingenieurtechnische Anstrengungen. Für einfache RAG-Anwendungen sind zusätzliche Komponenten wie etcd und Kafka unnötiger Overhead.
Der Engine ist unter Apache 2.0 kostenlos verfügbar. Zilliz, das Unternehmen hinter ihm, bietet managed Hosting ab 155 US-Dollar pro Monat an.
Qdrant
Qdrant ist eine Open-Source-Vektorsuchmaschine, die in Rust geschrieben wurde, und ihre Schwerpunkte liegen in der Speichersicherheit, der Durchsatzleistung sowie einer sehr guten Filterung der übertragenen Daten. Teams, die Geschwindigkeit und Zuverlässigkeit benötigen, wenden sich in der Regel an Qdrant – insbesondere für RAG mit umfangreichen Metadatenfiltern, individuellen Bewertungsmethoden sowie engen Latenzvorgaben.
Hinter den Kulissen kommt ein in Rust entwickelter Speichelmotor namens Gridstore zum Einsatz, der speziell für Vektorarbeiten optimiert ist. Ein komponierbares Suchdesign ermöglicht es, in einer einzigen Abfrage dichte Vektoren, spärliche Vektoren sowie Metadatenfilter zu kombinieren. Die Filterung erfolgt während des HNSW-Abgriffs direkt im Graphen, wodurch Rückrufratenverluste vermieden werden, die bei der Filterung nach der Suche auftreten. Zudem gibt es Qdrant Edge, eine leichte, eingebettete Version für Mobilgeräte und Robotik.
Die typische p50-Latenz liegt bei etwa 4 bis 5 ms, das Filtern bleibt unter strengen Einschränkungen präzise, und die Lizenz (Apache 2.0) ist permissiv. Die Kompromisse: Der Beitrag zum Rust-Kern bedeutet eine steilere Lernkurve, und um das beste HNSW-Verhalten zu erzielen, sind sorgfältige Einstellungen für Speicher und Index erforderlich.
Die Open-Source-Version ist kostenlos. Qdrant Cloud bietet eine kostenlose verwaltete Ebene mit 1 GB Speicher sowie bezahlte, nutzungsbasierte Cluster.
Weaviate
Weaviate ist eine auf KI ausgelegte Open-Source-Datenbank, die um graphähnliche Objekte organisiert ist und mehrere Suchmethoden sowie Datentypen in einer einzigen Abfragerfahrung kombiniert. Sie eignet sich, wenn Sie eine ausgereifte hybride Suche, komplexe Beziehungen zwischen Objekten sowie einen in die Datenbank integrierten AI-Workflow benötigen.
Es verbindet dichte Ähnlichkeitsbetrachtung und BM25-Schlüsselwort-Ranking nativ miteinander. Vectorisierungsmodule stellen Verbindungen zu OpenAI, Cohere und Hugging Face her und vectorisieren den Text für Sie. Die Daten befinden sich in einem klassenbasierten Schema, das auf Beziehungen ausgelegt ist, und es sind Multi-User-Isolation sowie Replication enthalten.
Die Vorteile sind weniger Boilerplate-Code, da die Umwandlung von Text in Vektoren innerhalb der Datenbank stattfindet, anpassbare hybride Parameter, die präzise Schlüsselwortgenauigkeit mit umfassender semantischer Erinnerung in Einklang bringen, sowie stabile Reaktionszeiten in Millisekunden auch bei Hunderten Millionen von Objekten. Die Nachteile sind die anfängliche Eingewöhnung an das klassenbasierte Schema sowie ein höherer Ressourcenverbrauch im Vergleich zu eingebetteten Lösungen.
Die Software ist unter BSD-3 kostenlos verfügbar. Weaviate Cloud bietet serverlose, verwaltete Tarife ab 45 US-Dollar pro Monat an.
pgvector für PostgreSQL
Die pgvector-Erweiterung verwandelt PostgreSQL in einen leistungsstarken Vektor-Speicher, der Embeddings neben herkömmlichen transaktionalen Daten speichert. Sie ist die natürliche Wahl für Teams, die sich bereits auf Postgres konzentrieren und keine weitere Datenbank einrichten möchten.
Sie fügt einem regulären SQL-Schema einen nativen Vektor-Spaltentyp hinzu, unterstützt Kosinusähnlichkeit, L2-Distanz und Skalarprodukt, erstellt HNSW- sowie IVFFlat-Indizes und führt Ähnlichkeitsabfragen innerhalb standardmäßiger ACID-Transaktionen aus.
Der große Vorteil ist die Vermeidung der Betriebskosten, Sicherheitsüberprüfungen sowie der Wartung eines separaten Systems. Die vorhandenen Postgres-Überwachungsfunktionen, Backups und Replikationen bleiben erhalten, und das Filtern von Metadaten erfolgt einfach über eine vertraute WHERE-Klausel zusammen mit einer Entfernungsfunktion. Die Nachteile sind ein höherer Speicherverbrauch sowie eine geringere Skalierbarkeit im Vergleich zu Engines, die ausschließlich für Vektoren entwickelt wurden, sowie ein bemerkbarer Anstieg der Latenz ab etwa 50 Millionen Vektoren, es sei denn, es wird etwas wie pgvectorscale hinzugefügt.
Die Erweiterung ist kostenlos und open source. Was Sie ausgeben, hängt davon ab, wie Sie Postgres hosten.
Kaufbare und verwaltete Optionen
Verwaltete Datenbanken bieten eine wartungsarme Lösung, sodass das Team sich auf die Anwendung statt auf die Server konzentrieren kann.
Pinecone
Pinecone hat mehr oder weniger die Kategorie der verwalteten Vektordatenbanken definiert – mit einem serverlosen, zero-ops-Design, das alle Backend-Infrastrukturen versteckt. Sie ist für Teams gedacht, die schnell in die Produktion gelangen möchten, ohne Server, Clustern oder Indexparameter verwalten zu müssen.
Es läuft ausschließlich als Cloud-SaaS, teilt die Lese-, Schreib- und Speicherschichten so auf, dass jede unabhängig skaliert werden kann, hostet Embedding- und Reranking-Modelle über Pinecone Inference und unterstützt dichte Vektoren, spärliche Vektoren sowie effektives Metadatenfiltern. Im Gegenzug entfallen alle Infrastrukturarbeiten, Patches oder Indexumbauten, es gibt eine breite Kompatibilität mit Frameworks und Cloud-Diensten sowie hohe Verfügbarkeit bei vorhersehbarer Leistung unter Last.
Die Nachteile sind, dass es sich um geschlossene Quellcode handelt, was zu einem echten Anbieterbindungseffekt führt, und dass die Verbrauchspreise bei Workloads mit vielen Lese- und Schreibvorgängen schnell ansteigen.
Die angegebenen Preise: ein kostenloser Starter-Tarif (2 GB, 1 M Lesevorgänge, nur AWS us-east-1); Standard mit einem monatlichen Mindestbetrag von 50 US-Dollar zu 0,33 US-Dollar pro GB-Monat plus etwa 4 bis 4,50 US-Dollar pro Million Schreibvorgänge und 16 bis 18 US-Dollar pro Million Lesevorgänge; Enterprise mit einem monatlichen Mindestbetrag von 500 US-Dollar; sowie ein HIPAA-Add-on für 190 US-Dollar pro Monat.
Turbopuffer
Turbopuffer ist ein serverloser Suchmaschinenanbieter, der direkt auf Cloud-Objektspeicherbasis aufgebaut ist, wobei Kosteneffizienz im Vordergrund steht. Er ist der beste Kandidat für multi-tenant-basierte SaaS- und KI-Produkte mit einer großen Anzahl von Namensräumen, bei denen die Ausgaben unter Kontrolle gehalten werden müssen.
Es überspringt herkömmliche Festplatten und sucht direkt in der Objektspeicherung, kann Milliarden von Vektoren verarbeiten ohne Obergrenzen für Namensräume, verwendet einen für Suchvorgänge optimierten SPFresh-Index und macht Schreibvorgänge sofort in den Ergebnissen sichtbar. Die Kosten für Speicherung und Abfragen sind im Vergleich zu älteren Managed-Services deutlich niedriger, es werden Preisfallen pro Pod vermieden, die mehrfach genutzte Designs bestrafen, und SOC 2 sowie HIPAA-Konformität sind bereits in den Standardplänen enthalten.
Andererseits ist es geschlossene Quelle mit einer kürzeren Erfolgsgeschichte als etablierte Konkurrenten, und sein Plugin-Ökosystem sowie seine Integrationen sind schwächer ausgeprägt. Die Abrechnung erfolgt ausschließlich nach Verbrauch, wobei in den Standardplänen ein monatliches Mindestbetrag von 64 US-Dollar anfällt, und große Namensräume erhalten Rabatte auf Abfragen aufgrund des hohen Volumens.
TiDB Vector Search
PingCAPs TiDB Vector Search verbindet eine verteilte SQL-Datenbank mit einem eigenen Embedding-Engine, sodass große transaktionale Arbeitslasten sowie semantische Suchvorgänge in einem einzigen skalierbaren System abgewickelt werden können. Dies ist sinnvoll, wenn man eine sehr große horizontale Skalierbarkeit zusammen mit komplexen SQL-Filtern und Vektorabfragen an denselben Daten gleichzeitig benötigt.
Die Plattform kombiniert Embedding-Speicherung mit verteiltem SQL, erstellt neben HNSW-Vektorindizes auch reguläre SQL-Indizes, verteilt Abfragen auf mehrere Knoten zur Gewährleistung hoher Verfügbarkeit und unterstützt neben Vektorähnlichkeitsabfragen auch hybride Suchverfahren sowie präzises Schlüsselwortabgleichen. Dadurch entfallen Synchronisierungsprobleme sowie Pipelines zwischen einer Anwendungsdatenbank und einem separaten Vektorlagern, es wird eine stark gefilterte, mehrfach genutzte Datenabfrage durch SQL-Joins ermöglicht, und die Skalierbarkeit beeinträchtigt die Abfragen nicht.
Das ist übertrieben für einen leichten RAG-Pipeline-Ansatz, der ausschließlich Vektoren verwendet, und die vollständige Optimierung der Leistung erfordert ein tiefes Verständnis von verteiltem SQL.
Auf TiDB Cloud Starter ist die kostenlose Stufe die großzügigste in dieser Kategorie: 5 GiB für die Zeilenlagerei, 5 GiB für die spaltenbasierte Lagerei sowie 50 M Anfragen pro Cluster, wobei pro Organisation bis zu 5 Cluster möglich sind. Insgesamt stehen somit monatlich kostenlos 25 GiB für Zeilen, 25 GiB für Spalten und 250 M RUs zur Verfügung. Darüber hinaus fallen Kosten in Höhe von 0,10 US-Dollar pro Million RUs sowie 0,20 US-Dollar pro GiB-Monat für die Zeilenlagerei in us-east an.
Wo vectorbasierte RAG-Systeme nachlassen
Die Vektorsuche ist leistungsstark, weist aber immer noch Schwächen auf, die die Genauigkeit im Unternehmensumfeld beeinträchtigen können.
- Verlorener Kontext. Standardmäßige Vektor-RAG-Methoden teilen Dokumente in kleine Abschnitte auf, um sie in die Kontextfenster zu passen. Dieser mechanische Vorgang zerstört die Struktur komplexer Dokumente, und ein kleiner Abschnitt verliert leicht den Zusammenhang mit den Überschriften oder Abschnitten, die ihm Bedeutung verliehen haben.
- Ungenauigkeit. Die Suche beruht auf der Nähe im Vektorraum, wodurch ähnliche Begriffe oder Produktbezeichnungen mit ähnlicher Formulierung verwechselt werden. Falsche Fakten gelangen in die Anfrage, was zu Halluzinationen führt.
- Kostenintensive Aktualisierungen. Der Wechsel auf ein besseres Embedding-Modell bedeutet, den gesamten Korpus erneut einzubetten und große Indizes von Grund auf neu aufzubauen, was die Rechenkosten und Ausgaben erhöht.
Graph RAG ist eine Alternative. Dabei werden Datensätze als Knoten und Beziehungen als Kanten dargestellt, und Tools wie der Writer Knowledge Graph bewahren explizite Verbindungen zwischen Dokumenten auf. Das ermöglicht mehrstufiges Reasoning, verringert Halluzinationen und lässt ein Team eine einzige Tatsache aktualisieren, ohne alles erneut einbetten zu müssen.
Eine praktische Entscheidungshilfe
Fangen Sie mit dem an, was Sie bereits nutzen. Bei Postgres mit etwa weniger als 10 M Vektoren erledigt pgvector die Aufgabe ohne zusätzliche Abhängigkeiten, und pgvectorscale erweitert diese Funktionalität auf 50 M und mehr. Bei MongoDB sollten Sie Atlas Vector Search verwenden. Bei Elastic oder OpenSearch bleibt alles unverändert, da OpenSearch 3.0 den größten Teil der Lücke geschlossen hat. Bei Redis kommt die native Vektorunterstützung von Redis 8 mit FT.HYBRID zum Einsatz.
Wenn Sie von Grund auf anfangen, sollten Sie drei Faktoren berücksichtigen:
- Skalierbarkeit und Leistungsfähigkeit.** Prototyping mit weniger als 1 Mio. Vektoren spricht für Chroma. Selbst gehostete Produktionen mit hoher Filterleistung eignen sich für Qdrant. Arbeiten im Milliardenmaßstab oder mit GPU-Beschleunigung sind besser mit Milvus umsetzbar. Gemanagte Produktionen mit Compliance-Anforderungen sind am besten mit Pinecone oder Weaviate Cloud geeignet.
- Kostenstruktur.** Bei intensiver Nutzung durch mehrere Nutzer, wobei die meisten Nutzer inaktiv sind, erzielt Turbopuffer tatsächlich Einsparungen von 10 bis 100 Mal, allerdings dauern „kalte“ Abfragen etwa 500 ms. Für kostensensible Umgebungen mit mehr als 50 Mio. Vektoren und vorhersehbarer Last eignet sich pgvector in Kombination mit pgvectorscale.
- Anforderungen an die Logikverarbeitung.** Bei mehrstufigen Abfragen oder bei Bedarf an Erklärbarkeit sowie relationeller Struktur sollte ein Wissensgraph wie Neo4j, Memgraph oder FalkorDB hinzugefügt werden, und Graph RAG sollte zusammen mit Vektoren genutzt werden – nicht anstelle davon.
Häufig gestellte Fragen
Wie erstellt man eine Vektordatenbank für RAG? Teilen Sie die Dokumente in Blöcke auf, erstellen Sie mit einem Modell wie OpenAI oder BGE Embeddings und speichern Sie sowie indizieren Sie anschließend die Vektoren in Systemen wie Qdrant, Milvus oder pgvector. Für eine vollständig lokale Einrichtung können Chroma oder FAISS auf einem Rechner ohne Cloud-Einsatz genutzt werden.
Welche Rolle spielt sie? Sie ist der Abrufmechanismus, der zwischen Ihren Dokumenten und dem LLM steht. Sie speichert die Embeddings und gibt bei Abfragen die relevantesten Blöcke zurück, sodass das Modell aus einem fundierten Kontext antworten kann und nicht nur aus dem Gedächtnis.
Welche Datenbank sollten Sie verwenden? Das hängt von der Skala und der Technologieauswahl ab. Chroma und pgvector eignen sich am besten kostenlos für kleine bis mittelgroße Projekte, Qdrant und Milvus sind führend bei selbst gehosteten Produktionsumgebungen, und Pinecone ist die beste verwaltete Option, wenn Sie keinerlei Betriebsaufwand wünschen.
Wie werden Vektoren im Pipeline verwendet? Ein Embedding-Modell wandelt Textabschnitte in hochdimensionale Vektoren um. Die Datenbank speichert sie, und wenn eine Frage eintrifft, findet sie durch eine ANN-Suche die dem Abfragen-Vektor am nächsten liegenden Vektoren und gibt diese Abschnitte in die Anfrage ein.
Ist eine Vektordatenbank immer erforderlich? Nein, obwohl sie weiterhin der Branchenstandard bleibt. Vektorlose Systeme wie PageIndex verzichten ganz auf Embeddings. Sie wandeln Dokumente in hierarchische Bäume um und ermöglichen es dem LLM, über den Inhaltstext Antworten zu finden. Viele Unternehmensteams nutzen außerdem Graphdatenbanken für GraphRAG, um über explizite Verbindungen statt über räumliche Ähnlichkeit Kontexte abzurufen.
Welche sind die sieben Arten von RAG? Naives RAG (einfache Abruf- und Erstellungsphase), retrieve-and-rerank (der übliche Produktionsansatz), hybrides RAG (Gleichzeitige Nutzung dichter und spärlicher Suchmethoden), multimodales RAG (Text, Bilder und Audio in einem Prozess), Graph RAG (Durchquerung von Wissensgraphen für relationale Abfragen), aggressives RAG (ein LLM-Agent wählt für jede Abfrage die beste Abrufstrategie) sowie HyDE RAG (das Modell erstellt zunächst einen hypothetischen Antwortentwurf und sucht anschließend entsprechend).
Verwandte Literatur
- Praktische Hinweise: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr — Detaillierte Anleitung zu den Praktischen Hinweisen: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.
- Praktische Anmerkungen: RAG in die Produktion bringen – End-to-End-Probleme aus der Praxis — Detaillierte Anleitung zu den praktischen Anmerkungen „RAG in die Produktion bringen – End-to-End-Probleme aus der Praxis“, einschließlich Verträgen, Überprüfungen sowie Code-Blöcken für Teams, die dieses Muster einsetzen.
- Den Empfehlungssystemen mitteilen, wo die Menschen leben möchten: Geo-Embeddings — Wie eine Wohnplattform Rohdaten von Breiten- und Längengraden durch gelernte H3-Geo-Embeddings in einem Zwei-Türme-Empfehlungssystem ersetzte, zusammen mit den Offline- und A/B-Test-Ergebnissen.
- pgvector oder SQL Server 2025 als RAG-Vektorlager: Einrichtung, Abfragen und zu beachtende Aspekte — Verwendung von PostgreSQL mit pgvector sowie den nativen Vektoren von SQL Server 2025 für RAG: Einrichtung, Kosinus-Abfragen, Verknüpfungen mit Geschäftsdaten sowie sechs zu vermeidende Probleme in den SQL Server-Vorabversionen.
- Praktische Hinweise: Wo man 2026 RAG von Grund auf lernen kann: Die Kurse und — Detaillierte Anleitung zu den Praktischen Hinweisen: Wo man 2026 RAG von Grund auf lernen kann: Die Kurse und: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.