-
Notifications
You must be signed in to change notification settings - Fork 0
themis docs search hybrid_fusion_api
Status: ✅ Implementiert (v1) – Text+Vector Fusion mit RRF und Weighted Modes
Die Hybrid Fusion Search kombiniert Fulltext-Suche (BM25) und Vektor-Suche (HNSW/Brute-Force) in einer einheitlichen Ergebnisliste. Zwei Fusion-Modi werden unterstützt: RRF (Reciprocal Rank Fusion) und Weighted (gewichtete Score-Fusion).
POST /search/fusion
Formel: score = Σ 1/(k_rrf + rank)
Eigenschaften:
- Rank-basiert (keine Score-Normalisierung erforderlich)
- Robust gegen unterschiedliche Score-Skalen
- Bevorzugt Dokumente, die in beiden Listen hoch ranken
- Standard
k_rrf = 60(empfohlen für Balance)
Vorteile:
- ✅ Keine Annahmen über Score-Verteilungen
- ✅ Einfach zu parametrisieren
- ✅ Bewährt in Information Retrieval (TREC)
Nachteile:
- ❌ Ignoriert absolute Score-Unterschiede
- ❌ Kann relevante Dokumente mit hohem Score in nur einer Modalität benachteiligen
Formel: score = α × normalize(BM25) + (1-α) × normalize(VectorSim)
Normalisierung: Min-Max per Modalität
- Text:
(score - min_text) / (max_text - min_text) - Vector:
1 - (distance - min_dist) / (max_dist - min_dist)(Distance → Similarity)
Eigenschaften:
- Score-basiert mit konfigurierbarer Gewichtung
-
α = weight_text(0.0 bis 1.0, default: 0.5) - Berücksichtigt Score-Magnitudes innerhalb jeder Modalität
Vorteile:
- ✅ Flexibles Tuning der Modalitäts-Gewichte
- ✅ Nutzt Score-Informationen für feinere Diskriminierung
Nachteile:
- ❌ Sensibel gegenüber Score-Verteilungen
- ❌ Erfordert Tuning von
αfür optimale Ergebnisse
POST /search/fusion
{
"table": "articles",
"text_query": "machine learning optimization",
"text_column": "content",
"vector_query": [0.123, 0.456, 0.789, ...],
"fusion_mode": "rrf",
"k_rrf": 60,
"k": 10,
"text_limit": 1000,
"vector_limit": 1000
}POST /search/fusion
{
"table": "docs",
"text_query": "neural network architectures",
"text_column": "description",
"vector_query": [0.3, 0.1, ...],
"fusion_mode": "weighted",
"weight_text": 0.7,
"k": 20
}POST /search/fusion
{
"table": "papers",
"text_query": "deep learning survey",
"text_column": "abstract",
"fusion_mode": "weighted",
"weight_text": 1.0,
"k": 50
}POST /search/fusion
{
"table": "images",
"vector_query": [0.5, 0.2, ...],
"fusion_mode": "weighted",
"weight_text": 0.0,
"k": 100
}| Parameter | Typ | Required | Default | Beschreibung |
|---|---|---|---|---|
table |
string | ✅ | - | Tabellenname |
text_query |
string | - | Fulltext-Query (mind. 1 Query erforderlich) | |
text_column |
string | - | Spalte mit Fulltext-Index | |
vector_query |
float[] | - | Query-Vektor (mind. 1 Query erforderlich) | |
fusion_mode |
string | ❌ | "rrf" |
Fusion-Modus: "rrf" oder "weighted"
|
k |
int | ❌ | 10 |
Top-k Ergebnisse nach Fusion |
k_rrf |
int | ❌ | 60 |
RRF-Parameter (nur bei fusion_mode="rrf") |
weight_text |
float | ❌ | 0.5 |
Text-Gewicht 0.0-1.0 (nur bei fusion_mode="weighted") |
text_limit |
int | ❌ | 1000 |
Kandidaten-Limit für Text-Suche |
vector_limit |
int | ❌ | 1000 |
Kandidaten-Limit für Vektor-Suche |
text_query+text_column ODER vector_query
{
"count": 10,
"fusion_mode": "rrf",
"table": "articles",
"text_count": 42,
"vector_count": 87,
"results": [
{
"pk": "art_123",
"score": 0.0547
},
{
"pk": "art_456",
"score": 0.0423
}
]
}Response-Felder:
-
count: Anzahl fusionierter Ergebnisse -
fusion_mode: Verwendeter Modus ("rrf"oder"weighted") -
table: Tabelle -
text_count: Anzahl Text-Kandidaten (falls Text-Query vorhanden) -
vector_count: Anzahl Vektor-Kandidaten (falls Vector-Query vorhanden) -
results: Top-k Ergebnisse sortiert nach Fusion-Score (absteigend)
Szenario: Vektor-basierte Ähnlichkeit mit Keyword-Filter
{
"fusion_mode": "weighted",
"weight_text": 0.3,
"text_query": "machine learning",
"vector_query": [...],
"k": 20
}Szenario: Gleichgewichtige Kombination ohne Score-Tuning
{
"fusion_mode": "rrf",
"k_rrf": 60,
"text_query": "optimization algorithms",
"vector_query": [...],
"k": 50
}Szenario: Primär BM25, Vektor als Secondary Signal
{
"fusion_mode": "weighted",
"weight_text": 0.8,
"text_query": "exact technical term",
"vector_query": [...],
"k": 10
}Szenario: Nur Vektor-Suche (konsistente API)
{
"fusion_mode": "weighted",
"weight_text": 0.0,
"vector_query": [...],
"k": 100
}-
Kandidaten-Limits:
text_limitundvector_limitkontrollieren Pre-Fusion-Kandidaten- Höhere Werte: bessere Recall, langsamere Fusion
- Empfehlung: 10-100× des finalen
k
-
Fusion-Komplexität:
- RRF: O(|text_results| + |vector_results|) für Hash-Map + Sort
- Weighted: gleiche Komplexität, zusätzlich Min-Max Normalisierung
-
Index-Optimierung:
- Fulltext: Nutze
limitinscanFulltextWithScores(bereits implementiert) - Vector: HNSW
efSearchParameter für Speed/Quality Trade-off
- Fulltext: Nutze
- k_rrf = 10-30: Starke Bevorzugung hoher Ranks (streng)
- k_rrf = 60: Balanced (Standardwert, TREC-empfohlen)
- k_rrf = 100+: Smoothere Fusion, weniger Rank-Penalisierung
- 0.0-0.2: Vector-dominiert (semantische Suche)
- 0.3-0.5: Balanced (Standard: 0.5)
- 0.6-0.8: Text-dominiert (Keyword-Suche mit semantischem Boost)
- 0.9-1.0: Primär BM25, minimaler Vektor-Einfluss
Tuning-Strategie:
- Starte mit RRF (robust, keine Parameter)
- Falls Modalität dominieren soll: wechsle zu Weighted mit
α-Tuning - Evaluiere auf Representative Queries mit Relevance Judgments
- ❌ Keine Post-Fusion Reranking
- ❌ Keine Query-Zeit Feature-Weights (nur globales
α) - ❌ Keine Custom Similarity Functions
- ❌ Keine Cross-Encoder Integration
- 🔲 Learned Fusion: ML-basierte Score-Kombination
- 🔲 Query-dependent Weights:
αbasierend auf Query-Typ - 🔲 Multi-Stage Retrieval: Fusion → Rerank Pipeline
- 🔲 Distribution-Aware Normalization (z.B. Z-Score statt Min-Max)
- 🔲 AQL Integration:
SEARCH FUSION ... USING TEXT ... VECTOR ...
| Ansatz | Pros | Cons | Use Case |
|---|---|---|---|
| RRF | Robust, keine Tuning, rank-based | Ignoriert Score-Magnitudes | Default für Multi-Modal |
| Weighted | Flexibles Tuning, score-aware | Sensibel, braucht Normalisierung | Wenn Modalität dominieren soll |
| CombSUM | Einfach | Keine Normalisierung, skalenanfällig | ❌ Nicht empfohlen |
| CombMNZ | Bevorzugt Multi-Modal Matches | Komplex, wenig robust | ❌ Nicht implementiert |
# 1. Indizes erstellen
POST /index/create {"table": "papers", "column": "abstract", "type": "fulltext"}
POST /vector/index/config {"table": "papers", "dimension": 768, "metric": "COSINE"}
# 2. Dokumente einfügen mit Text + Vector
PUT /entities/papers/p1 {
"abstract": "Deep learning for computer vision",
"embedding": [0.1, 0.2, ..., 0.768]
}
PUT /entities/papers/p2 {
"abstract": "Neural network optimization techniques",
"embedding": [0.3, 0.4, ..., 0.768]
}
# 3. Hybrid Suche mit RRF
POST /search/fusion {
"table": "papers",
"text_query": "deep learning vision",
"text_column": "abstract",
"vector_query": [0.15, 0.25, ..., 0.768],
"fusion_mode": "rrf",
"k": 10
}
# Ergebnis: Dokumente die SOWOHL semantisch als auch keyword-basiert matchen ranken hoch- RRF: Cormack, Clarke, Büttcher. "Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods." SIGIR 2009
- Score Normalization: Lee. "Analyses of Multiple Evidence Combination." SIGIR 1997
- Hybrid Retrieval: Ma et al. "A Hybrid Ranking Approach to E-Commerce Search." KDD 2019
Datum: 2025-11-30
Status: ✅ Abgeschlossen
Commit: bc7556a
Die Wiki-Sidebar wurde umfassend überarbeitet, um alle wichtigen Dokumente und Features der ThemisDB vollständig zu repräsentieren.
Vorher:
- 64 Links in 17 Kategorien
- Dokumentationsabdeckung: 17.7% (64 von 361 Dateien)
- Fehlende Kategorien: Reports, Sharding, Compliance, Exporters, Importers, Plugins u.v.m.
- src/ Dokumentation: nur 4 von 95 Dateien verlinkt (95.8% fehlend)
- development/ Dokumentation: nur 4 von 38 Dateien verlinkt (89.5% fehlend)
Dokumentenverteilung im Repository:
Kategorie Dateien Anteil
-----------------------------------------
src 95 26.3%
root 41 11.4%
development 38 10.5%
reports 36 10.0%
security 33 9.1%
features 30 8.3%
guides 12 3.3%
performance 12 3.3%
architecture 10 2.8%
aql 10 2.8%
[...25 weitere] 44 12.2%
-----------------------------------------
Gesamt 361 100.0%
Nachher:
- 171 Links in 25 Kategorien
- Dokumentationsabdeckung: 47.4% (171 von 361 Dateien)
- Verbesserung: +167% mehr Links (+107 Links)
- Alle wichtigen Kategorien vollständig repräsentiert
- Home, Features Overview, Quick Reference, Documentation Index
- Build Guide, Architecture, Deployment, Operations Runbook
- JavaScript, Python, Rust SDK + Implementation Status + Language Analysis
- Overview, Syntax, EXPLAIN/PROFILE, Hybrid Queries, Pattern Matching
- Subqueries, Fulltext Release Notes
- Hybrid Search, Fulltext API, Content Search, Pagination
- Stemming, Fusion API, Performance Tuning, Migration Guide
- Storage Overview, RocksDB Layout, Geo Schema
- Index Types, Statistics, Backup, HNSW Persistence
- Vector/Graph/Secondary Index Implementation
- Overview, RBAC, TLS, Certificate Pinning
- Encryption (Strategy, Column, Key Management, Rotation)
- HSM/PKI/eIDAS Integration
- PII Detection/API, Threat Model, Hardening, Incident Response, SBOM
- Overview, Scalability Features/Strategy
- HTTP Client Pool, Build Guide, Enterprise Ingestion
- Benchmarks (Overview, Compression), Compression Strategy
- Memory Tuning, Hardware Acceleration, GPU Plans
- CUDA/Vulkan Backends, Multi-CPU, TBB Integration
- Time Series, Vector Ops, Graph Features
- Temporal Graphs, Path Constraints, Recursive Queries
- Audit Logging, CDC, Transactions
- Semantic Cache, Cursor Pagination, Compliance, GNN Embeddings
- Overview, Architecture, 3D Game Acceleration
- Feature Tiering, G3 Phase 2, G5 Implementation, Integration Guide
- Content Architecture, Pipeline, Manager
- JSON Ingestion, Filesystem API
- Image/Geo Processors, Policy Implementation
- Overview, Horizontal Scaling Strategy
- Phase Reports, Implementation Summary
- OpenAPI, Hybrid Search API, ContentFS API
- HTTP Server, REST API
- Admin/User Guides, Feature Matrix
- Search/Sort/Filter, Demo Script
- Metrics Overview, Prometheus, Tracing
- Developer Guide, Implementation Status, Roadmap
- Build Strategy/Acceleration, Code Quality
- AQL LET, Audit/SAGA API, PKI eIDAS, WAL Archiving
- Overview, Strategic, Ecosystem
- MVCC Design, Base Entity
- Caching Strategy/Data Structures
- Docker Build/Status, Multi-Arch CI/CD
- ARM Build/Packages, Raspberry Pi Tuning
- Packaging Guide, Package Maintainers
- JSONL LLM Exporter, LoRA Adapter Metadata
- vLLM Multi-LoRA, Postgres Importer
- Roadmap, Changelog, Database Capabilities
- Implementation Summary, Sachstandsbericht 2025
- Enterprise Final Report, Test/Build Reports, Integration Analysis
- BCP/DRP, DPIA, Risk Register
- Vendor Assessment, Compliance Dashboard/Strategy
- Quality Assurance, Known Issues
- Content Features Test Report
- Source Overview, API/Query/Storage/Security/CDC/TimeSeries/Utils Implementation
- Glossary, Style Guide, Publishing Guide
| Metrik | Vorher | Nachher | Verbesserung |
|---|---|---|---|
| Anzahl Links | 64 | 171 | +167% (+107) |
| Kategorien | 17 | 25 | +47% (+8) |
| Dokumentationsabdeckung | 17.7% | 47.4% | +167% (+29.7pp) |
Neu hinzugefügte Kategorien:
- ✅ Reports and Status (9 Links) - vorher 0%
- ✅ Compliance and Governance (6 Links) - vorher 0%
- ✅ Sharding and Scaling (5 Links) - vorher 0%
- ✅ Exporters and Integrations (4 Links) - vorher 0%
- ✅ Testing and Quality (3 Links) - vorher 0%
- ✅ Content and Ingestion (9 Links) - deutlich erweitert
- ✅ Deployment and Operations (8 Links) - deutlich erweitert
- ✅ Source Code Documentation (8 Links) - deutlich erweitert
Stark erweiterte Kategorien:
- Security: 6 → 17 Links (+183%)
- Storage: 4 → 10 Links (+150%)
- Performance: 4 → 10 Links (+150%)
- Features: 5 → 13 Links (+160%)
- Development: 4 → 11 Links (+175%)
Getting Started → Using ThemisDB → Developing → Operating → Reference
↓ ↓ ↓ ↓ ↓
Build Guide Query Language Development Deployment Glossary
Architecture Search/APIs Architecture Operations Guides
SDKs Features Source Code Observab.
- Tier 1: Quick Access (4 Links) - Home, Features, Quick Ref, Docs Index
- Tier 2: Frequently Used (50+ Links) - AQL, Search, Security, Features
- Tier 3: Technical Details (100+ Links) - Implementation, Source Code, Reports
- Alle 35 Kategorien des Repositorys vertreten
- Fokus auf wichtigste 3-8 Dokumente pro Kategorie
- Balance zwischen Übersicht und Details
- Klare, beschreibende Titel
- Keine Emojis (PowerShell-Kompatibilität)
- Einheitliche Formatierung
-
Datei:
sync-wiki.ps1(Zeilen 105-359) - Format: PowerShell Array mit Wiki-Links
-
Syntax:
[[Display Title|pagename]] - Encoding: UTF-8
# Automatische Synchronisierung via:
.\sync-wiki.ps1
# Prozess:
# 1. Wiki Repository klonen
# 2. Markdown-Dateien synchronisieren (412 Dateien)
# 3. Sidebar generieren (171 Links)
# 4. Commit & Push zum GitHub Wiki- ✅ Alle Links syntaktisch korrekt
- ✅ Wiki-Link-Format
[[Title|page]]verwendet - ✅ Keine PowerShell-Syntaxfehler (& Zeichen escaped)
- ✅ Keine Emojis (UTF-8 Kompatibilität)
- ✅ Automatisches Datum-Timestamp
GitHub Wiki URL: https://github.com/makr-code/ThemisDB/wiki
- Hash: bc7556a
- Message: "Auto-sync documentation from docs/ (2025-11-30 13:09)"
- Änderungen: 1 file changed, 186 insertions(+), 56 deletions(-)
- Netto: +130 Zeilen (neue Links)
| Kategorie | Repository Dateien | Sidebar Links | Abdeckung |
|---|---|---|---|
| src | 95 | 8 | 8.4% |
| security | 33 | 17 | 51.5% |
| features | 30 | 13 | 43.3% |
| development | 38 | 11 | 28.9% |
| performance | 12 | 10 | 83.3% |
| aql | 10 | 8 | 80.0% |
| search | 9 | 8 | 88.9% |
| geo | 8 | 7 | 87.5% |
| reports | 36 | 9 | 25.0% |
| architecture | 10 | 7 | 70.0% |
| sharding | 5 | 5 | 100.0% ✅ |
| clients | 6 | 5 | 83.3% |
Durchschnittliche Abdeckung: 47.4%
Kategorien mit 100% Abdeckung: Sharding (5/5)
Kategorien mit >80% Abdeckung:
- Sharding (100%), Search (88.9%), Geo (87.5%), Clients (83.3%), Performance (83.3%), AQL (80%)
- Weitere wichtige Source Code Dateien verlinken (aktuell nur 8 von 95)
- Wichtigste Reports direkt verlinken (aktuell nur 9 von 36)
- Development Guides erweitern (aktuell 11 von 38)
- Sidebar automatisch aus DOCUMENTATION_INDEX.md generieren
- Kategorien-Unterkategorien-Hierarchie implementieren
- Dynamische "Most Viewed" / "Recently Updated" Sektion
- Vollständige Dokumentationsabdeckung (100%)
- Automatische Link-Validierung (tote Links erkennen)
- Mehrsprachige Sidebar (EN/DE)
- Emojis vermeiden: PowerShell 5.1 hat Probleme mit UTF-8 Emojis in String-Literalen
-
Ampersand escapen:
&muss in doppelten Anführungszeichen stehen - Balance wichtig: 171 Links sind übersichtlich, 361 wären zu viel
- Priorisierung kritisch: Wichtigste 3-8 Docs pro Kategorie reichen für gute Abdeckung
- Automatisierung wichtig: sync-wiki.ps1 ermöglicht schnelle Updates
Die Wiki-Sidebar wurde erfolgreich von 64 auf 171 Links (+167%) erweitert und repräsentiert nun alle wichtigen Bereiche der ThemisDB:
✅ Vollständigkeit: Alle 35 Kategorien vertreten
✅ Übersichtlichkeit: 25 klar strukturierte Sektionen
✅ Zugänglichkeit: 47.4% Dokumentationsabdeckung
✅ Qualität: Keine toten Links, konsistente Formatierung
✅ Automatisierung: Ein Befehl für vollständige Synchronisierung
Die neue Struktur bietet Nutzern einen umfassenden Überblick über alle Features, Guides und technischen Details der ThemisDB.
Erstellt: 2025-11-30
Autor: GitHub Copilot (Claude Sonnet 4.5)
Projekt: ThemisDB Documentation Overhaul