chemenu/kb/concepts/architectures/Hybrid Search.md

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary

type	concept_type	tags	created	modified	related	sources	confidence	confidence_base	provenance	summary
types/concept.md	architecture	search bm25 vector graph scalability	2026-07-26	2026-08-29	exemplifies LLM Wiki Pattern see-also BM25 composition Vector Search composition Reciprocal Rank Fusion rests-on Knowledge Graph see-also Graph Traversal	Source - LLM Wiki v2	0.90	0.90	sourced	Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen.

Hybrid Search

Typ: Architecture (Multi-Modal-Suchsystem)

Definition

Hybrid Search kombiniert drei komplementäre Suchansätze, um skalierbare und genaue Wissensbeschaffung in Wikis zu ermöglichen, die ~100-200 Seiten übersteigen. Dies adressiert die Einschränkung des ursprünglichen Musters, das sich ausschließlich auf index.md für die Entdeckung verlässt.

Kernpunkte

Das Problem

Der ursprüngliche index.md-Katalog funktioniert bis zu ~100-200 Seiten. Darüber hinaus:

• Der Index selbst wird zu lang, um vom LLM in einem Durchgang gelesen zu werden
• Schlüsselwortabgleich vermisst semantische Ähnlichkeit
• Flache Suche kann strukturelle Beziehungen nicht erfassen
• Unimodale Suche hat Blindstellen

Die Lösung: Drei-Stream-Fusion

1. BM25 (Schlüsselwortabgleich)

• Traditionelle Informationsbeschaffung mit Stammformreduktion und Synonymerweiterung
• Stärken: Findet genaue Begriffe, schnell, gut verstanden
• Schwächen: Vermisst semantische Ähnlichkeit, erfordert genaue Begriffsabgleiche
• Anwendungsfall: "Alle Seiten über Docker finden"

2. Vector Search (Semantische Ähnlichkeit)

• Nutzt Embeddings, um semantisch ähnliche Inhalte zu finden
• Stärken: Findet verwandte Konzepte, auch ohne genaue Begriffsabgleiche
• Schwächen: Kann präzise technische Begriffe verpassen, rechentechnisch teuer
• Anwendungsfall: "Informationen über Container-Plattformen finden" (passt Docker, Podman, etc.)

3. Graph Traversal (Strukturelle Verbindungen)

• Durchläuft den Knowledge Graph durch typisierte Beziehungen
• Stärken: Findet strukturelle Verbindungen, die Schlüsselwort- und Vector-Suche verfehlen
• Schwächen: Erfordert gut gepflegten Graph, findet nur verbundene Entitäten
• Anwendungsfall: "Was ist die Auswirkung eines Redis-Upgrades?" (findet alle abhängigen Services)

Fusion mit Reciprocal Rank Fusion (RRF)

Anstatt einen Ansatz zu wählen, alle drei mit RRF fusionieren:

1. Alle drei Suchen parallel ausführen
2. Jede gibt eine rangierte Liste von Ergebnissen zurück
3. RRF kombiniert die Rankings mit gegenseitigen Rang-Scores
4. Ergebnis: Bessere Gesamtrangierung als bei einem einzelnen Ansatz

Warum RRF?

• Einfach und effektiv
• Keine Notwendigkeit, Gewichte zwischen Modi zu tunen
• Robust gegen Unterschiede in der Ergebnisqualität
• Funktioniert auch, wenn ein Modus schlecht abschneidet

Implementierung

Architektur

Abfrage: "Wie funktioniert das Auth-System?"
       │
       ├── BM25-Suche → [Seiten mit "Auth", "Authentication", "Login"]
       │
       ├── Vector Search → [semantisch mit Authentication verbundene Seiten]
       │
       └── Graph Traversal → [Seiten, die mit Auth-Entitäten im Graph verbunden sind]
               │
               └── Reciprocal Rank Fusion → Kombinierte, rangierte Ergebnisse

Wann wechseln

Wiki-Größe	Primärer Suchmechanismus
< 100 Seiten	index.md (manuell)
100-200 Seiten	index.md + grundlegende Suche
200-1000 Seiten	Hybrid-Suche (BM25 + Vector)
1000+ Seiten	Hybrid-Suche (BM25 + Vector + Graph)

Empfehlung: index.md als für Menschen lesbaren Katalog auch mit Hybrid-Suche bewahren. Es dient verschiedenen Zwecken:

• index.md: Menschliche Navigation, Überblick
• Hybrid-Suche: LLM-Abfragelösung

Vorteile

• Skalierbarkeit: Funktioniert von 100 bis 10.000+ Seiten
• Genauigkeit: Jeder Modus erfasst, was andere vermissen
• Robustheit: Kein Single Point of Failure
• Flexibilität: Passt sich verschiedenen Abfragetypen an
• Zukunftssicher: Kann weitere Modi hinzufügen (z.B. Zeitsuche)

Wann zu verwenden

• Wikis, von denen erwartet wird, dass sie über 200 Seiten hinauswachsen
• Bereiche mit vielfältigen Abfragetypen
• Situationen, die hohen Recall erfordern
• Multi-modale Wissensdatenbanken

Wann NICHT zu verwenden

• Kleine Wikis (<100 Seiten) - index.md ist ausreichend
• Einfache, gleichmäßige Inhalte
• Situationen, in denen die Implementierungskomplexität nicht gerechtfertigt ist

Verwandte Concepts

• Agent Memory - Produktionsimplementierung

Siehe auch

• Event-Driven Automation (für automatisierte Indizierung)
• Scalable Search (verwandtes Concept)

Beziehungen

• exemplifies: LLM Wiki Pattern
• see-also: BM25
• composition: Vector Search
• composition: Reciprocal Rank Fusion
• rests-on: Knowledge Graph
• see-also: Graph Traversal