- BACKUP_ARCHITECTURE, STORAGE_MAP, RECOVERY_RUNBOOK - TRANSFORMATION_BASELINE, DUPLICATE_RESOLUTION_PLAN - CANONICAL_KNOWLEDGE_PRINCIPLE, SEARCH_ARCHITECTURE_PROPOSAL - KNOWLEDGE_GRAPH_PRINCIPLE, FORGEJO_TOLARIA_SYNC_PRINCIPLE - HOST_CONTAINER_DISCOVERY Fresh Checker PASS (deleg_a19028bc). No productive vault mutation.
2.4 KiB
2.4 KiB
SEARCH ARCHITECTURE PROPOSAL — Tolaria Second Brain v1 (Mission 002)
Datum: 2026-08-25 · Red Queen · Status: NUR VORBEREITUNG — NICHT IMPLEMENTIERT
Langfristig gewünscht: HYBRID SEARCH für Tolaria. Dieses Dokument analysiert die Architektur für die spätere B5-Phase. Noch nichts bauen.
Ziel: HYBRID SEARCH
KEYWORD / FULL TEXT + SEMANTIC / VECTOR + METADATA + RELATIONSHIPS
Ist-Zustand (EVIDENCE, Mission 001)
- Aktuelle Suche = Substring/Keyword (~1 ms),
exact/semantic/vectorModi identisch → keine echte semantische Suche. - Kein Embedding-Modell, kein Vector-Store, keine ADR für Vektoren.
Architektur-Optionen (INFERENCE / RECOMMENDATION)
| Aspekt | Empfehlung |
|---|---|
| Embedding-Modell | Lokal, klein (z.B. all-MiniLM-L6-v2 / bge-small) — datenschutzfreundlich, kein externer Call |
| Vector Storage | Lokal embedded (SQLite-VSS / LanceDB / Qdrant lokal); kein externer Service |
| Rebuildbarkeit | Vector Index = DERIVED DATA — vollständig aus kanonischem Wissensstand rebuildbar |
| Incremental Updates | Bei Änderung nur betroffene Chunks neu embedden (Diff-basiert) |
| Chunking | Markdown-aware: nach Heading/Paragraph, nicht blind nach Zeichen |
| Markdown Awareness | Frontmatter, Code-Blöcke, Wikilinks, Header-Struktur verstehen |
| Metadata Filtering | Über Frontmatter (type, tags, created) filtern |
| Ranking | Hybrid-Scoring: Keyword-Exaktheit + semantische Ähnlichkeit + Metadaten-Boost |
| Hybrid Scoring | Gewichtete Kombination (z.B. 60% semantic + 30% keyword + 10% metadata) |
| Lokale vs externe Modelle | Lokal bevorzugt (Datenschutz, kein Vendor-Lock) |
| Ressourcenbedarf | Gering (84 Dateien); ein Mini-Embedding-Modell reicht |
| Datenschutz | Lokale Inferenz → kein Datenabfluss |
| Latenz | Lokal <100 ms für kleine Korpus; gut |
Kernregel
Vector Index = DERIVED DATA. Er muss vollständig aus dem kanonischen Wissensbestand rebuildbar sein. Er ist nie die Source of Truth.
Voraussetzungen (für B5)
- Kanonischer Wissensbestand (B3-Bereinigung) als stabile Basis.
- Pfad-Stabilität + Frontmatter-Konsistenz.
- Human-in-the-Loop vor produktiver Einführung (Schema-/Index-Freigabe).
Nicht jetzt
- Kein Embedding erzeugen, kein Vector-Store produktiv einführen, keine Suche ersetzen — bis B5 und ausdrückliche Freigabe.