torben
18ae28f918
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki: raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren Grenzen in Code durchgesetzt sind statt im Prompt. Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44 Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist. Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs. Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte. Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet - siehe NOTICE.
130 lines
5.0 KiB
Markdown
130 lines
5.0 KiB
Markdown
---
|
|
type: types/concept.md
|
|
concept_type: architecture
|
|
tags: [search, bm25, vector, graph, scalability]
|
|
created: 2026-07-26
|
|
modified: 2026-08-29
|
|
related: [LLM Wiki Pattern, BM25, Vector Search, Reciprocal Rank Fusion, Knowledge Graph, Graph Traversal]
|
|
sources: [Source - LLM Wiki v2]
|
|
confidence: 0.90
|
|
confidence_base: 0.90
|
|
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
|
|
|
|
- [[LLM Wiki Pattern]] - Gesamtmuster
|
|
- [[BM25]] - Schlüsselwortabgleich-Komponente
|
|
- [[Vector Search]] - Semantische Ähnlichkeits-Komponente
|
|
- [[Reciprocal Rank Fusion]] - Fusionsalgorithmus
|
|
- [[Knowledge Graph]] - Graph-Traversal-Komponente
|
|
- [[Graph Traversal]] - Der Graph-Suchmechanismus
|
|
- [[Agent Memory]] - Produktionsimplementierung
|
|
|
|
## Siehe auch
|
|
|
|
- [[Event-Driven Automation]] (für automatisierte Indizierung)
|
|
- Scalable Search (verwandtes Concept)
|