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

---
type: types/concept.md
concept_type: architecture
tags: [search, bm25, vector, graph, scalability]
created: 2026-07-26
modified: 2026-08-29
related:
  - exemplifies: LLM Wiki Pattern
  - see-also: BM25
  - composition: Vector Search
  - composition: Reciprocal Rank Fusion
  - rests-on: Knowledge Graph
  - see-also: Graph Traversal
sources: [Source - LLM Wiki v2]
provenance: sourced
summary: 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)

<!-- wikitool:links -->
## Beziehungen

- **exemplifies:** [[LLM Wiki Pattern]]
- **see-also:** [[BM25]]
- **composition:** [[Vector Search]]
- **composition:** [[Reciprocal Rank Fusion]]
- **rests-on:** [[Knowledge Graph]]
- **see-also:** [[Graph Traversal]]
<!-- /wikitool:links -->