Semantische Suche unvollständig: Vektorindex (ChromaDB) nur zu ~14 % / ~58 % gefüllt — mtime-Skip verhindert Nachholung #119

New issue

Closed

opened 2026-10-27 11:48:20 +00:00 by alf · 1 comment

alf commented

2026-10-27 11:48:20 +00:00

Owner

Problem

Die semantische Suche (RAG) im Vault und in der Chat-Historie liefert nur einen Bruchteil der möglichen Treffer, weil der Vektorindex (ChromaDB) deutlich kleiner ist als der Volltextindex (SQLite/FTS5). Gemessen am 2026-10-27 auf dem Produktivsystem:

Index	SQLite (Volltext)	ChromaDB (Vektoren)	Abdeckung
Vault (RAG)	7.022 Notizen	1.001 Notizen / 3.136 Chunks	~14 %
Chats + Workspaces (Memory)	31.493 Einträge	18.192 Chunks	~58 %

Auswirkungen im Live-Test

Vault: semantische Suche nach «flash-attn CUDA-Mismatch Dockerfile Build Abbruch» liefert thematisch falsche Treffer (Wing-Commander-III-Anleitungen, Patreon-Mails) mit für semantische Treffer untypisch hohen Abständen (0.14–0.17) — die tatsächlich passende Notiz (CLAUDE.md im Vault-Root) ist in SQLite indiziert, aber nicht im Vektorindex.
Chat: funktioniert subjektiv, aber ~42 % der Einträge sind für die semantische Suche unsichtbar.
Embedding-Modell ist korrekt konfiguriert und aktiv (mlx-community/multilingual-e5-large, lokal, MLX).

Wahrscheinliche Ursache

Der inkrementelle Index-Lauf ueberschreibt die SQLite-Zeile neu, ueberspringt das Embedding aber, wenn sich die Datei seit dem letzten Lauf nicht geaendert hat (mtime-Vergleich). Damit war der Vektorindex einmal weg (geloescht bzw. ein --full-Lauf abgebrochen), bauen sich die Vektoren fuer alle unveraenderten Notizen nie wieder auf.

Bestaetigt im Test: index --area "00 Kontext" meldet indexed: 1, unchanged: 9 — die Vektorabdeckung in dem Ordner bleibt danach bei 2 von 12 Notizen.

Der GUI-Button «Neu aufbauen» (Einstellungen -> Vault Wartung -> RAG-Index / Memory-Index) ruft korrekt index --full auf — er ist als Workaround geeignet, aber nicht die Wurzelbehebung.

Erwartetes Verhalten

Ein inkrementeller Index-Lauf erkennt, wenn zu einer als indiziert gefuehrten Datei kein Vektor im ChromaDB-Store existiert, und holt das Embedding nach — unabhaengig vom mtime-Status. Der Index heilt sich also selbst, statt dauerhaft unvollstaendig zu bleiben.

Reproduction

ChromaDB-Store loeschen (oder die Situation eines abgebrochenen --full-Laufs nachstellen).
Inkrementellen Index-Lauf ausloesen (Vault-Wartung oder index ohne --full).
Chunk-Zahl im Vektorstore mit der Notiz-/Eintragszahl in SQLite vergleichen — sie bleibt weit darunter.

Vorschlag

Beim inkrementellen Laufen die vorhandenen Vektor-IDs gegen die SQLite-Eintraege pruefen und fehlende Embeddings nachziehen (Selbstheilung).
Optional: In den Stats (Einstellungen -> Vault Wartung) Abdeckung als Verhaeltnis anzeigen (Vektor-Chunks vs. erwartete Chunks), damit eine solche Drift sofort sichtbar ist — eine Notiz erzeugt mehrere Chunks, die Chunk-Zahl muss also ueber der Notiz-Zahl liegen.

## Problem Die semantische Suche (RAG) im Vault und in der Chat-Historie liefert nur einen Bruchteil der möglichen Treffer, weil der Vektorindex (ChromaDB) deutlich kleiner ist als der Volltextindex (SQLite/FTS5). Gemessen am 2026-10-27 auf dem Produktivsystem: | Index | SQLite (Volltext) | ChromaDB (Vektoren) | Abdeckung | |---|---|---|---| | Vault (RAG) | 7.022 Notizen | 1.001 Notizen / 3.136 Chunks | ~14 % | | Chats + Workspaces (Memory) | 31.493 Einträge | 18.192 Chunks | ~58 % | ## Auswirkungen im Live-Test - Vault: semantische Suche nach «flash-attn CUDA-Mismatch Dockerfile Build Abbruch» liefert thematisch falsche Treffer (Wing-Commander-III-Anleitungen, Patreon-Mails) mit für semantische Treffer untypisch hohen Abständen (0.14–0.17) — die tatsächlich passende Notiz (CLAUDE.md im Vault-Root) ist in SQLite indiziert, aber nicht im Vektorindex. - Chat: funktioniert subjektiv, aber ~42 % der Einträge sind für die semantische Suche unsichtbar. - Embedding-Modell ist korrekt konfiguriert und aktiv (mlx-community/multilingual-e5-large, lokal, MLX). ## Wahrscheinliche Ursache Der inkrementelle Index-Lauf ueberschreibt die SQLite-Zeile neu, ueberspringt das Embedding aber, wenn sich die Datei seit dem letzten Lauf nicht geaendert hat (mtime-Vergleich). Damit war der Vektorindex einmal weg (geloescht bzw. ein --full-Lauf abgebrochen), bauen sich die Vektoren fuer alle unveraenderten Notizen nie wieder auf. Bestaetigt im Test: index --area "00 Kontext" meldet indexed: 1, unchanged: 9 — die Vektorabdeckung in dem Ordner bleibt danach bei 2 von 12 Notizen. Der GUI-Button «Neu aufbauen» (Einstellungen -> Vault Wartung -> RAG-Index / Memory-Index) ruft korrekt index --full auf — er ist als Workaround geeignet, aber nicht die Wurzelbehebung. ## Erwartetes Verhalten Ein inkrementeller Index-Lauf erkennt, wenn zu einer als indiziert gefuehrten Datei kein Vektor im ChromaDB-Store existiert, und holt das Embedding nach — unabhaengig vom mtime-Status. Der Index heilt sich also selbst, statt dauerhaft unvollstaendig zu bleiben. ## Reproduction 1. ChromaDB-Store loeschen (oder die Situation eines abgebrochenen --full-Laufs nachstellen). 2. Inkrementellen Index-Lauf ausloesen (Vault-Wartung oder index ohne --full). 3. Chunk-Zahl im Vektorstore mit der Notiz-/Eintragszahl in SQLite vergleichen — sie bleibt weit darunter. ## Vorschlag - Beim inkrementellen Laufen die vorhandenen Vektor-IDs gegen die SQLite-Eintraege pruefen und fehlende Embeddings nachziehen (Selbstheilung). - Optional: In den Stats (Einstellungen -> Vault Wartung) Abdeckung als Verhaeltnis anzeigen (Vektor-Chunks vs. erwartete Chunks), damit eine solche Drift sofort sichtbar ist — eine Notiz erzeugt mehrere Chunks, die Chunk-Zahl muss also ueber der Notiz-Zahl liegen.

alf added the

typ/bug

label

2026-10-27 11:48:20 +00:00

alf referenced this issue from iris/Iris

2026-10-27 12:34:42 +00:00

Semantische Suche unvollständig: Vektorindex (ChromaDB) nur zu ~14 % / ~58 % gefüllt — mtime-Skip verhindert Nachholung #196

alf closed this issue

2026-10-27 12:35:22 +00:00

alf commented

2026-10-27 12:35:43 +00:00

Author