Hybride Suche: BM25 vs. Vektor (und warum Sie beides brauchen)

Hybride Suche: BM25 vs. Vektor (und warum Sie beides brauchen)

Ein Support-Mitarbeiter tippt „SKU-4471" in Ihren RAG-Chatbot. Vier Ergebnisse kommen zurück. Alle selbstbewusst falsch. Ein Allzweck-Embedding-Modell hat keinen Grund, genau diese Zeichenkette im Vektorraum in ihrer eigenen Nähe zu platzieren. Dieser eine Ausfallmodus ist der Grund, warum es hybride Suche gibt, und warum Teams immer wieder dieselbe Frage stellen: Wie kombiniert man BM25 und Vektorsuche, ohne dauerhaft einen Tuning-Regler zu betreuen?

Wenn Sie RAG-Tooling breiter evaluieren, deckt unsere Übersicht der besten RAG-Tools das gesamte Umfeld ab.

Die wichtigsten Erkenntnisse

• BM25 findet exakte Schlüsselwort-Treffer (SKUs, Fehlercodes); Vektorsuche findet konzeptionell ähnlichen Text, keine identischen Zeichenketten.
• Hybride Suche kombiniert beides, meist über Reciprocal Rank Fusion (RRF), und schlägt bei gemischten Query-Workloads jedes einzelne Verfahren.
• Im WANDS-Benchmark erreicht pures RRF 0.7068 NDCG (gegenüber 0.6983 bei BM25); Tuning hebt den Wert auf 0.7497, ein Plus von 7,4 %.
• Postgres/pgvector kann hybride Suche nativ ausführen, über ts_rank + pgvector, ganz ohne dedizierte Vektordatenbank.

Was ist hybride Suche? (BM25 + Vektor kombiniert)

Hybride Suche führt BM25 und Vektorsuche als zwei getrennte Retrieval-Durchläufe über dieselbe Query aus und verschmilzt die beiden Ranglisten anschließend mit einem Fusionsalgorithmus zu einer einzigen Ausgabe, am häufigsten mit Reciprocal Rank Fusion. Sie ist keine dritte Retrieval-Methode, sondern eine Orchestrierungsschicht über zwei bestehenden.

Diese Unterscheidung zählt, weil ein guter Teil des Suchtraffics rund um das Thema BM25 und Vektorsuche so behandelt, als wären sie dasselbe. Sind sie nicht. BM25 ist eine sparse, schlüsselwortbasierte Scoring-Funktion mit Wurzeln in der Information-Retrieval-Forschung der 1970er. Vektorsuche ist dichte, embedding-basierte Ähnlichkeitssuche, die erst im letzten Jahrzehnt in großem Maßstab praktikabel wurde. Hybride Suche behandelt beide als komplementäre Eingaben, nicht als konkurrierende Techniken, und fusioniert ihre Ausgaben, statt vorab einen Sieger zu küren.

BM25 vs. Vektor vs. Hybrid: Schnellvergleich

Im WANDS-E-Commerce-Benchmark erzielte BM25 allein 0.6983 NDCG und Vektorsuche allein 0.6953 (nahezu gleichauf). Die pure RRF-Fusion, ganz ohne korpusbezogenes Tuning, erreichte 0.7068, ein moderates Plus von 1,2 % gegenüber BM25 allein. Doug Turnbulls Benchmark testete außerdem eine getunte Variante, die einen Produktnamen-Boost auf RRF aufsetzt, und diese Version erreichte 0.7497, ein Plus von 7,4 %. Hier lohnt sich Ehrlichkeit, welche Zahl Sie gerade zitieren: RRF allein liefert ab Werk einen kleinen, realen Vorsprung; die größeren 7,4 % erforderten zusätzliches domänenspezifisches Tuning, das die meisten Teams am ersten Tag auslassen. Weder BM25 noch Vektorsuche dominieren für sich; sie decken unterschiedliche Ausfallmodi ab, und ihre Fusion schließt beide Lücken zugleich.

BM25-Mechanik: Wie die Schlüsselwortsuche Relevanz bewertet

BM25 bewertet Dokumente nach Termfrequenz, gewichtet gegen die Seltenheit des Terms im gesamten Korpus und anschließend normalisiert auf die Dokumentlänge. Robertson und Zaragoza legten diese Formalisierung 2009 in ihrem Paper "The Probabilistic Relevance Framework: BM25 and Beyond" dar. Es ist eine Verfeinerung von TF-IDF, kein Ersatz.

Zwei Parameter steuern den Großteil des BM25-Verhaltens. k1 (typischerweise 1.2-2.0) steuert die Termfrequenz-Sättigung: Er deckelt, wie stark die Wiederholung eines Wortes den Score anhebt, damit ein Dokument, das 40-mal „invoice" sagt, nicht automatisch über einem steht, das es 4-mal in einer strafferen, relevanteren Passage nennt. b (Standard 0.75) steuert die Dokumentlängen-Normalisierung: Er legt fest, wie hart BM25 lange Dokumente dafür abstraft, dass sie naturgemäß mehr Term-Treffer enthalten.

Ein falsches b ist ein echter, häufiger Tuning-Fehler. Kurze technische Dokumente (Fehlerprotokolle, Produkttitel) verlangen ein niedrigeres b, weil die Längenvarianz gering ist; bei Langformen (Dokumentationsseiten, Artikel) liegt b meist besser nahe dem Standard. Die Kernschwäche von BM25 ist der Vokabular-Mismatch: Fragt ein Nutzer „how do I get my money back" und das Dokument sagt nur „refund policy", findet BM25 null gemeinsame Tokens und liefert nichts Brauchbares.

Mechanik der dichten Vektorsuche (und wo sie versagt)

Vektorsuche bildet Text mit einem Modell auf Embeddings fester Dimension ab und findet dann benachbarte Vektoren über Kosinusähnlichkeit oder Skalarprodukt, meist beschleunigt durch einen approximativen Nearest-Neighbor-Index. HNSW ist der dominierende Algorithmus bei Weaviate, Qdrant und Milvus und tauscht einen kleinen Teil Recall gegen erhebliche Tempo-Gewinne im großen Maßstab.

Genau das behebt das Vokabular-Mismatch-Problem von BM25: „get my money back" und „refund policy" landen im Embedding-Raum dicht beieinander, selbst bei null gemeinsamen Tokens, weil das Modell Bedeutung erfasst, nicht Oberflächenform. Die Wahl des richtigen Modells zählt hier sehr. Siehe unser Leitfaden zur Wahl des richtigen Embedding-Modells und unser Vergleich von Voyage-, OpenAI- und Cohere-Embeddings, wenn Sie Optionen abwägen.

Doch das dichte Retrieval hat seinen eigenen blinden Fleck, und er ist das Spiegelbild der BM25-Schwäche. Wenn wir RAG-Systeme für Kunden bauen, ist der Exact-Match-Ausfall, der uns am häufigsten begegnet, nicht exotisch. Es ist ein Support-Mitarbeiter, der nach einer konkreten Bestellnummer oder SKU fragt, und der Vektorindex liefert selbstbewusst etwas semantisch Ähnliches, aber Falsches. Ein Allzweck-Embedding-Modell hat keinen Grund, „SKU-4471" oder „ERR_CONN_RST" im Vektorraum näher an sich selbst zu platzieren als an einem verwandten, aber falschen Token, weil solche Zeichenketten in Trainingsdaten selten als eigenständige, isolierte Konzepte vorkommen. BigData Boutique dokumentiert genau dieses Ausfallmuster mit eigenen SKU- und Fehlercode-Beispielen. Es ist ein gut belegtes, unabhängig bestätigtes Phänomen quer durch RAG-Deployments, kein einmaliger Ausrutscher.

BM25 und Vektorsuche kombinieren: RRF vs. Alpha-gewichtete Fusion

Es gibt zwei echte Wege, BM25- und Vektor-Ergebnisse zu fusionieren, und kaum jemand, der über hybride Suche schreibt, stellt sie klar gegenüber. Reciprocal Rank Fusion (RRF), aus dem SIGIR-Paper von Cormack, Clarke und Buettcher (2009), arbeitet mit Rängen: score = sum(1 / (k + rank_i)) über jede Ergebnisliste, wobei k typischerweise auf 60 gesetzt wird. Weil nur die Position zählt, nicht der Roh-Score, verkraftet RRF die Skalenunterschiede zwischen den unbegrenzten BM25-Scores und dem 0-bis-1-Bereich der Kosinusähnlichkeit klaglos und braucht kein korpusbezogenes Tuning.

Alpha-gewichtete (konvexe) Fusion funktioniert anders: final = alpha * dense_score + (1 - alpha) * sparse_score, auf normalisierten Scores statt auf Rängen. Sie kann die Größenordnung der Konfidenz besser abbilden (ein Vektor-Treffer mit 0.95 Ähnlichkeit sieht tatsächlich stärker aus als einer mit 0.61), verlangt aber ein Tuning von alpha pro Korpus, und dieses Tuning bricht lautlos, wenn sich Ihre Score-Verteilungen verschieben (neues Embedding-Modell, neu indexierter Korpus, andere Query-Mischung).

In der Praxis läuft die Wahl darauf hinaus, wie sehr Sie Ihrer Score-Kalibrierung trauen. Läuft pures BM25 gegen ein einzelnes, stabiles Embedding-Modell, kann Alpha-Gewichtung eine etwas bessere Rangfolge herausholen, weil sie den tatsächlichen Score-Abstand nutzt, nicht nur die Position. Aber diese Kalibrierung driftet stärker, als viele erwarten. Tauschen Sie eine neue Embedding-Modellversion ein, chunken Sie Ihre Dokumente neu oder schalten Sie einen Reranking-Durchgang vor, und Ihre Dense-Score-Verteilung verschiebt sich. Niemand wird gepagt, wenn alpha=0.6 nicht mehr der richtige Wert ist; die Rangfolge wird einfach still etwas schlechter, und das geht leicht unter, wenn Sie nicht regelmäßig Retrieval-Evals fahren. RRF umgeht das komplett, weil es nie auf Roh-Scores schaut, nur auf die Rangposition, sodass ein Reindex oder Modelltausch es nicht lautlos brechen kann, wie es bei Alpha-Gewichtung passiert.

RRF braucht kein Tuning pro Korpus; Alpha-Gewichtung verlangt ständige Betreuung, sobald sich Ihre Daten ändern.

Die Engines setzen unterschiedliche Standards. Weaviate bietet sowohl RRF als auch einen explizit setzbaren alpha-Parameter. Elasticsearch liefert natives RRF über seine retriever-API (prüfen Sie die exakte Versionsfreigabe in Ihrem Deployment; das landete in der 8.x-Linie). Qdrant unterstützt RRF nativ über die Query API. Das Hybrid-Feature von Pinecone stützt sich meist auf die Alpha-gewichtete konvexe Kombination, statt RRF direkt offenzulegen. Wenn Sie unsicher sind, womit Sie starten: Nehmen Sie RRF. Es ist die wartungsärmere Standardeinstellung.

RRF von Grund auf: Ein herstellerneutrales Python-Beispiel

Jedes RRF-Codebeispiel, das wir in konkurrierenden Guides gefunden haben, ist an das SDK eines Herstellers gebunden: Weaviates Client, Qdrants Client, Pinecones Client. Hier ist eine framework-freie Version, die in jeden Stack passt, mit k=60 als Standard:

def reciprocal_rank_fusion(result_lists, k=60):
    """
    result_lists: list of ranked lists, each a list of document IDs
                  ordered from most to least relevant.
    k: RRF constant (60 is the standard default from Cormack et al., 2009).
    Returns: list of (doc_id, fused_score) sorted descending by score.
    """
    scores = {}
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]

fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
    print(f"{doc_id}: {score:.4f}")

Das ist der gesamte Algorithmus. Kein SDK, kein Vendor-Lock-in, und er funktioniert, egal ob Ihre beiden Ranglisten aus Elasticsearch und einem Faiss-Index kamen oder aus Postgres ts_rank und pgvector. Wenn Sie Modelle selbst hosten, statt eine API aufzurufen, siehe Embedding-Modelle lokal mit Ollama ausführen.

Postgres + pgvector: Hybride Suche ohne dedizierte Vektordatenbank

Sie brauchen keine dedizierte Vektordatenbank für hybride Suche. Laut einem pg_textsearch/pgvector-Benchmark des Entwicklers Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, nomic-embed-text-Embeddings, BEIR-SciFact-Datensatz) erreichte eine einzelne Postgres-Instanz mit nativem ts_rank nur 0.07 NDCG@10, weit hinter BM25 mit 0.69, pgvector mit 0.66 und Hybrid mit 0.70, alles in einer Instanz, wobei die hybride RRF-Variante bei rund 11,5 ms im Median landete.

Die 0.07 ist der verräterische Wert: Das eingebaute ts_rank von Postgres ist ein Cover-Density-Ranker, kein echtes BM25. Wenn Sie echtes BM25-Scoring in Postgres wollen, brauchen Sie eine Erweiterung. pg_textsearch, VectorChord und ParadeDB liefern alle ein ordentliches Ranking im BM25-Stil, das natives ts_rank nicht bietet. Kombinieren Sie eine davon mit pgvector für dichte Ähnlichkeit, fusionieren Sie die beiden Ranglisten mit der RRF-Funktion oben, und Sie haben hybride Suche in einer einzigen Postgres-Instanz, ohne zusätzliche Infrastruktur.

Grob sieht diese Paarung in einer einzigen Query so aus, mit einem lexikalischen Rang aus einer BM25-fähigen Erweiterung und einer Vektordistanz aus pgvector:

WITH lexical AS (
  SELECT id, ts_rank_cd(body_tsv, query) AS rank
  FROM documents, plainto_tsquery('english', 'refund policy') query
  WHERE body_tsv @@ query
  ORDER BY rank DESC LIMIT 50
),
semantic AS (
  SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
  FROM documents
  ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);

Führen Sie beide Ergebnismengen in die RRF-Funktion oben, und Sie haben hybride Suche in einer Postgres-Instanz. Die ehrliche Grenze: Das trägt gut bis in den niedrigen Millionenbereich an Zeilen, aber Postgres wurde nicht als dedizierte Retrieval-Engine gebaut. Sie verantworten Ihr Index-Tuning selbst, pures ts_rank_cd ist ohne Erweiterung noch immer kein echtes BM25, und das eingebaute Reranking oder die Multi-Vektor-Unterstützung, die Weaviate oder Milvus nativ mitbringen, bekommen Sie nicht. Ist Ihr Korpus klein bis mittelgroß und Sie fahren bereits Postgres, spart das ein komplettes zweites Stück Infrastruktur. Ab zig Millionen Dokumenten oder wenn Sie fortgeschrittenes Reranking brauchen, verdient eine dedizierte Engine ihren Unterhalt.

Wenn Sie Qdrant, Chroma oder pgvector breiter für Ihren Stack abwägen, ist das eine eigene Entscheidung, getrennt von der Fusionsmethode. Siehe unseren Vergleich von Qdrant, Chroma und pgvector für die Trade-offs.

Welche Vektordatenbanken unterstützen native hybride Suche?

Die meisten modernen Vektordatenbanken liefern hybride Suche heute ab Werk, aber die Fusionsmethode im Standard unterscheidet sich deutlich.

Prüfen Sie die exakte Versionsfreigabe, bevor Sie sich festlegen. Hybrid-Features landeten 2026 schnell über diese Engines, und die API-Formen ändern sich von Release zu Release. Für eine breitere Kaufentscheidung jenseits der Fusionsmechanik siehe unsere Gesamtübersicht der besten Vektordatenbanken.

Lohnt sich hybride Suche trotz der Komplexität?

Hybride Suche ist architektonisch korrekt, wenn Ihr Korpus sowohl Exact-Match-Muster (SKUs, IDs, seltene Terme) als auch konzeptionelle, paraphrasierte Queries enthält. Hat Ihr Korpus weder noch (purer Fließtext, keine Identifier, nach denen jemand per wörtlicher Zeichenkette sucht), fügen Sie womöglich Fusionskomplexität für einen Zuwachs hinzu, den Sie kaum bemerken.

Überlegen Sie, was „nur Fließtext" konkret heißt: ein Firmenblog-Archiv, ein internes Engineering-Wiki voller prosalastiger Runbooks, eine Doku-Seite, die niemand per Produkt-ID oder Ticketnummer durchsucht. In solchen Korpora holt Vektorsuche allein meist den Großteil des Werts, und der Fusionsschritt addiert nur einen zweiten Retrieval-Durchlauf und einen Parameter, den nun jemand verantwortet, für einen Zuwachs, der auf Rundungsrauschen hinausläuft. Halten Sie das gegen ein Support-Ticket-System oder einen E-Commerce-Katalog, wo SKUs, Bestellnummern und Modellcodes ständig in echten Nutzer-Queries auftauchen. Das ist der eigentliche Test: Ziehen Sie zehn echte Queries aus Ihren eigenen Logs und zählen Sie, wie viele einen exakten Identifier enthalten, den ein paraphrasenbasiertes Embedding-Modell nie korrekt platzieren würde. Null: hybride Suche auslassen. Mehr als ein oder zwei: bauen.

Hybride Suche ist kein universelles Upgrade; enthält Ihr Korpus keine SKUs, IDs oder Abfragen seltener Terme, fügen Sie vielleicht Fusionskomplexität für einen Zuwachs hinzu, den Sie nie bemerken.

Die Kosten sind real, aber begrenzt: ein zweiter Retrieval-Durchlauf, ein Fusionsschritt und ein Gewichtungsparameter, den nun jemand verantwortet. Wir zitieren hier bewusst keine Latenzzahl, denn die kursierenden Werte stammen von ungenannten Setups auf ungenannter Hardware, und Ihre werden abweichen. Messen Sie an Ihrem eigenen Korpus, bevor Sie entscheiden. Zwei Hacker-News-Threads fangen die echte Praktiker-Spannung hier ein: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" und "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Beide Threads wehren sich dagegen, Hybrid als Cargo-Kult-Best-Practice zu übernehmen, ohne vorher zu prüfen, ob Ihr Korpus die Query-Muster überhaupt hat, die es lösen soll. Bevor Sie bauen, lohnt sich das Verständnis, wie man Retrieval-Qualität tatsächlich misst: NDCG- und recall@k-Werte bedeuten nur etwas gegen Ihren eigenen Korpus, nicht gegen ein Benchmark-Dataset.

Unsere Position: Standard auf hybrid für jedes RAG-System, das nutzerseitigen Support, E-Commerce oder Ticket-Queries bedient. Diese Workloads mischen fast immer Identifier mit natürlicher Sprache. Lassen Sie es aus bei reinen Fließtext-Korpora (Langform-Dokus, narrative Wikis), bis Sie eine echte Lücke gemessen haben, die Single-Method-Retrieval offenlässt.

Häufig gestellte Fragen

Was ist hybride Suche in RAG?

Hybride Suche führt BM25 (Schlüsselwort) und Vektor (semantisch) als getrennte Durchläufe über dieselbe Query aus und verschmilzt die beiden Ranglisten dann mit einem Fusionsalgorithmus, meist Reciprocal Rank Fusion. Sie fängt sowohl Exact-Match-Queries als auch paraphrasierte konzeptionelle ab, was keine der beiden Methoden allein bewältigt.

Ist BM25 dasselbe wie Vektorsuche?

Nein. BM25 ist sparse lexikalische Suche, die exakte Term-Überschneidung und Seltenheit bewertet. Vektorsuche ist dichte semantische Suche mit Embeddings und Ähnlichkeitsmathematik. Es sind zwei verschiedene Retrieval-Methoden mit entgegengesetzten Stärken; hybride Suche kombiniert sie, statt eine zu ersetzen.

Wie kombiniert man BM25 und Vektorsuche?

Führen Sie beide Retrieval-Methoden unabhängig auf derselben Query aus und fusionieren Sie dann die beiden Ranglisten, am häufigsten mit Reciprocal Rank Fusion, das 1 / (k + rank) über jede Liste aufsummiert. Die Alpha-gewichtete Score-Kombination ist die Alternative, braucht aber korpusbezogenes Tuning, das RRF nicht verlangt.

Was ist Reciprocal Rank Fusion (RRF)?

RRF ist ein Fusionsalgorithmus aus dem SIGIR-Paper von Cormack, Clarke und Buettcher (2009), der mehrere Ranglisten kombiniert, indem er 1 / (k + rank) pro Dokument aufsummiert, wobei k typischerweise auf 60 gesetzt wird. Er arbeitet auf der Rangposition, nicht auf Roh-Scores, und bleibt damit stabil über Skalenunterschiede zwischen Retrieval-Methoden hinweg.

Worin liegt der Unterschied zwischen RRF und Alpha-gewichteter Fusion?

RRF kombiniert Ränge und braucht kein korpusbezogenes Tuning. Alpha-gewichtete Fusion kombiniert normalisierte Scores über einen einstellbaren alpha-Parameter, was die Konfidenz-Größenordnung besser abbilden kann, aber laufendes Nachstimmen verlangt, sobald sich Score-Verteilungen verschieben, etwa nach einem Reindex oder Modellwechsel.

Wann sollte ich hybride Suche statt reiner Vektorsuche einsetzen?

Setzen Sie hybride Suche ein, wenn Ihre Queries exakte Identifier (SKUs, Bestellnummern, Fehlercodes) mit natürlichsprachlichen, konzeptionellen Fragen mischen; Support, E-Commerce und Ticket-Systeme tun das meist. Lassen Sie sie aus bei reinem Fließtext ohne Identifier, wo die zusätzliche Fusionskomplexität wahrscheinlich keinen messbaren Zuwachs bringt.

Warum übersieht Vektorsuche exakte Treffer wie SKUs oder Fehlercodes?

Embedding-Modelle lernen aus allgemeinen Sprachmustern, und Zeichenketten wie „SKU-4471" oder „ERR_CONN_RST" kommen in Trainingsdaten selten als eigenständige, isolierte Konzepte vor. Das Modell hat keinen starken Grund, genau diese Zeichenkette näher an sich selbst zu platzieren als an einem semantisch verwandten, aber falschen Token.

Welche Vektordatenbanken unterstützen hybride Suche nativ?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa und Milvus liefern 2026 alle native hybride Suche, wobei ihre Standard-Fusionsmethoden differieren (RRF vs. Alpha-gewichtet vs. Normalisierung). Postgres mit pgvector kann ebenfalls hybride Suche fahren, braucht aber eine BM25-Erweiterung, da natives ts_rank kein echtes BM25 ist.

Lohnt sich hybride Suche angesichts der zusätzlichen Komplexität?

Für Korpora, die Exact-Match- und konzeptionelle Queries mischen, ja. Pures RRF schlägt im WANDS-Benchmark bereits jede einzelne Methode (0.7068 gegen 0.6983 bei BM25), und eine getunte Variante erreicht ein Plus von 7,4 % (0.7497). Bei reinen Fließtext-Korpora ohne Identifier können der zweite Retrieval-Durchlauf und das nötige Fusions-Tuning einen Zuwachs aufwiegen, den Sie nicht bemerken. Messen Sie vor der Festlegung.

Kann Postgres/pgvector hybride Suche ohne dedizierte Vektordatenbank?

Ja. Kombinieren Sie pgvector für dichte Ähnlichkeit mit einer echten BM25-Erweiterung wie pg_textsearch, VectorChord oder ParadeDB (natives ts_rank allein erreichte nur 0.07 NDCG@10 in Pedro Alonsos pg_textsearch/pgvector-Benchmark, gegen 0.70 bei Hybrid) und fusionieren Sie dann die beiden Ranglisten mit RRF, alles in einer Postgres-Instanz.

Beide Retrieval-Methoden hinterlassen allein echte Lücken: BM25 verpasst Paraphrasen, Vektorsuche verpasst exakte Identifier, und ihre Fusion mit RRF ist der wartungsärmere Weg, beide zu schließen. Wenn Sie abwägen, ob Sie selbst bauen oder ein Team holen, das bereits RAG-Retrieval geliefert hat, deckt unser Gesamtleitfaden zum Bau einer RAG-Anwendung den nächsten Schritt ab, oder nehmen Sie Kontakt auf, wenn Techsy es lieber gemeinsam mit Ihnen bauen soll.