69 lines
2.7 KiB
Markdown
69 lines
2.7 KiB
Markdown
# Tolaria — Search Audit
|
||
|
||
**Datum:** 2026-08-24/25 · **Autor:** Red Queen · **Modus:** READ-ONLY
|
||
|
||
---
|
||
|
||
## 1. Befund (EVIDENCE)
|
||
|
||
Die Vault-Such-API (`/api/vault/search`) wurde mit verschiedenen `mode`-Parametern getestet:
|
||
|
||
| Mode | Ergebnis (Scores/Reihenfolge) | echte semantische Suche? |
|
||
|------|------------------------------|--------------------------|
|
||
| `exact` | identische Treffer wie unten | nein |
|
||
| `fuzzy` | gleiche Ranking-Logik | nein |
|
||
| `semantic` | **identisch** zu `exact`/`vector` | **nein** |
|
||
| `vector` | **identisch** zu `exact`/`semantic` | **nein** |
|
||
| `tags` / `filename` | Filter-/Namensvariante | — |
|
||
|
||
**Kernbefund:** `exact`, `semantic` und `vector` liefern **identische Ergebnisse** (gleiche Scores/Reihenfolge). Es gibt **kein Embedding, keinen Vector-Store, keine echte semantische Suche**.
|
||
|
||
- Die Suche ist eine **Rust-Substring-/Keyword-Suche** (`src-tauri/src/search.rs`): Titel-Wort +10, Titel-Substring +5, Content-Treffer ×0.5, Cap 20.
|
||
- Der `mode`-Parameter wird in `search_vault_with_options` **ignoriert**; alle Modi fallen auf dieselbe Implementierung zurück.
|
||
|
||
> **EVIDENCE:** Direkte API-Proben + Quelltext-Read (`search.rs`).
|
||
> **INFERENCE:** Die Suche ist eine schnelle Volltext-/Substring-Suche ohne Embeddings.
|
||
|
||
---
|
||
|
||
## 2. Suchgeschwindigkeit
|
||
|
||
| Query | elapsed_ms | Treffer |
|
||
|-------|-----------|---------|
|
||
| `Modul-15` | 1 | 15 |
|
||
| `Stop-Loss` | 1 | 2 |
|
||
| `backtesting` | 1 | 16 |
|
||
| `rabbitmq` | 1 | 20 |
|
||
|
||
**Befund:** Sehr schnell (1 ms) für 84 Dateien — reine In-Memory-Substring-Suche, kein Netzwerk-/Vector-Aufwand.
|
||
|
||
---
|
||
|
||
## 3. Was funktioniert / was fehlt
|
||
|
||
**Funktioniert:**
|
||
- Exakte/substring Keyword-Suche ✓
|
||
- Ranking nach Titel-Wort/Substring ✓ (heuristisch)
|
||
- Filter über `tags`/`filename` ✓
|
||
- Sehr niedrige Latenz ✓
|
||
|
||
**Fehlt (für Second-Brain-Ziel):**
|
||
- **Semantische Suche** (Begriffe ≠ exakte Wörter) ✗
|
||
- **Embeddings / Vector-Store** ✗
|
||
- **Hybrid-Suche** (Keyword + semantisch) ✗
|
||
- **Konzept-/Synonym-Auflösung** ✗
|
||
- Dafür kein ADR im Bestand (`docs/adr/`) ✓ (bestätigt)
|
||
|
||
---
|
||
|
||
## 4. Skalierung
|
||
|
||
- Bei 84 Dateien ist 1 ms unkritisch.
|
||
- Bei tausenden Dateien skaliert eine In-Memory-Substring-Suche linear; ohne Index/Embeddings wird sie bei großem Vault langsam und unpräzise.
|
||
- **Einschätzung (INFERENCE):** Für den aktuellen Umfang ausreichend; für ein langfristiges Second Brain (tausende Notes) nicht skalierbar ohne Index/Embeddings.
|
||
|
||
---
|
||
|
||
## 5. Fazit
|
||
|
||
Die Suche ist **technisch korrekt implementiert** (schnell, deterministisch), aber **semantisch eingeschränkt**. Die drei "semantisch" klingenden Modi sind funktional identisch und liefern keine Synonym-/Konzept-Treffer. Das ist die größte Suchlücke für das Second-Brain-Ziel.
|