Praxisprojekt Second Brain · Fehlerbehebung
Der Vault ist zu groß geworden
Lernziele
- Du unterscheidest mit den Kennzahlen einen großen, gesunden Vault von einem, der schlecht verlinkt ist.
- Du nennst die Abhilfen in der Reihenfolge, in der du sie einsetzt: Zusammenfassungsebenen, Archivieren, erst spät Aufteilen.
- Du lässt
index.mdaus dem tatsächlichen Inhalt vonwiki/neu aufbauen und prüfst das Ergebnis.
Symptome
Die Antworten werden langsamer und vager. Der Agent liest zwanzig Seiten und liefert etwas Allgemeines. Die Graphansicht ist ein Knäuel. Du weißt nicht mehr, ob ein Thema schon im Vault steht, und das Nachsehen dauert länger als eine Websuche.
Was es meist nicht ist
Die Festplatte, die Suchgeschwindigkeit und Obsidian skalieren gut. Wie schnell ripgrep über zehntausend Dateien sucht, haben wir in Suchwerkzeuge gemessen.
Knapp wird der Kontext beim Abrufen. Der Index ist so lang, dass ihn zu lesen spürbar Kontextfenster · engl. context windowAlles, was das Modell bei einem Aufruf liest: Anweisungen, Verlauf, Dateien, Tool-Ergebnisse. Was dort fehlt, existiert für das Modell nicht.Im Glossar kostet. Der Agent überspringt ihn dann oder verbraucht sein Budget dort statt bei den Seiten. Wie sich das Budget verteilt, zeigt Kontextbudget.
Erst prüfen: Größe oder Verfall
Lass zuerst die Kennzahlen laufen, beschrieben in Kennzahlen, die sich lohnen. Ein Vault mit zwanzig Prozent Waisen hat ein Problem mit der Verlinkung. Ihn aufzuteilen hilft dann nicht.
Ein wirklich großer und gesunder Vault hat diese vier Merkmale:
- eine niedrige Waisenquote,
- eine große Insel, die fast alle Seiten hält,
- einen durchschnittlichen Grad im üblichen Bereich,
- einen Index mit mehr als einigen hundert Einträgen.
Größe oder Verfall?
Spricht der Befund für einen Vault, der einfach groß ist, oder für einen, der schlecht verlinkt ist?
Noch offen (5)
- Waisenquote 3 %, index.md hat 640 Einträge.
- Waisenquote 21 %.
- Die größte Insel hält 55 % der Seiten.
- Durchschnittlicher Grad 5, stabil, während sich die Seitenzahl verdoppelt hat.
- Der Grad ist in drei Monaten von 4 auf 1,6 gefallen.
Groß und gesund (0)
Schlecht verlinkt (0)
Zusammenfassungsebenen
Das ist die erste Abhilfe und reicht meistens. Zwischen Hauptindex und Seiten liegt ein Index pro Themengebiet. Der Agent macht dann drei billige Lesevorgänge statt eines teuren. Wie du die Ebenen anlegst und warum zwei genügen, steht in Über tausend Seiten.
Aufteilen
Teile nach Fachgebiet. Ein Schnitt nach Datum trennt altes von neuem Material, und gerade diese Verbindungen sind der Wert des Vaults. Aufteilen lohnt sich nur bei zwei Bereichen, die sich wirklich nicht gegenseitig informieren.
Nimm in Kauf, dass Verbindungen über Fachgrenzen dann nicht mehr entstehen. Gerade die sind oft die spannenden. Deshalb ist Aufteilen ein später Schritt und kommt nach den anderen.
Archivieren
Kaltes Material wandert nach archive/, außerhalb von wiki/. Dort bleibt es durchsuchbar, steht aber nicht mehr im Index, und du kannst es jederzeit zurückholen.
Das ist besser als Löschen, denn ob etwas kalt ist, schätzt du nur. Archiviertes Material kann zurückkommen. Damit es auch aus der Graphansicht von Obsidian verschwindet, trägst du archive/ unter den ausgeschlossenen Dateien ein. Die Einstellung zeigt Über tausend Seiten.
Den Index neu aufbauen
Manchmal ist der Index einfach abgedriftet. Einträge zeigen auf Seiten, die verschoben wurden. Seiten aus Läufen, die mittendrin abgebrochen sind, fehlen.
Baue index.md aus dem tatsächlichen Inhalt von wiki/ neu auf.
Gruppiere nach Typ und Thema, eine Zeile Beschreibung pro Eintrag,
Lücken stehen unten.
Das kostet wenig und behebt nach unserer Einschätzung einen überraschend großen Teil der Fälle, in denen sich der Vault „kaputt anfühlt“.
Wir haben den Auftrag in einem kleinen Test-Vault ausprobiert. Der Index hatte vier Abweichungen. „Interleaving“ war nach archive/ verschoben, für „Pomodoro“ gab es keine Seite, und zwei Seiten aus einem abgebrochenen Lauf fehlten im Index.
- DuBaue index.md aus dem tatsächlichen Inhalt von wiki/ neu auf. Gruppiere nach Typ und Thema, eine Zeile Beschreibung pro Eintrag, Lücken stehen unten.
Der Agent hat jede Abweichung gefunden und den abgebrochenen Lauf aus log.md erschlossen. Keine Seite wurde verändert. Prüf trotzdem den Diff von index.md, bevor du committest: Gruppen und Beschreibungen hat der Agent selbst gewählt.
Merksätze
- Ein zu großer Vault zeigt sich an vagen, langsamen Antworten. Platte, Suche und Obsidian sind meist nicht die Ursache.
- Knapp wird der Kontext, weil der Index zu lang zum Lesen wird.
- Eine hohe Waisenquote heißt Verfall. Dagegen hilft Verlinken.
- Die Reihenfolge der Abhilfen: Zusammenfassungsebenen, Archivieren, erst spät Aufteilen. Einen veralteten Index baust du jederzeit billig neu auf.
- Einen abgedrifteten Index baut der Agent für wenige Cent aus
wiki/neu auf.
Prüf dich selbst
Denkfrage
Dein Vault hat 1.200 Seiten und eine Waisenquote von 18 %. Du überlegst, ihn in zwei Vaults aufzuteilen. Was spricht dagegen?
Bei 18 % Waisen ist jede fünfte bis sechste Seite unerreichbar. Das ist ein Problem mit der Verlinkung, und beide Teil-Vaults hätten es weiter. Verlinke zuerst die Waisen und prüf, ob der Import vorher den Index liest. Aufteilen kostet dich außerdem die Verbindungen zwischen den Fachgebieten.
Denkfrage
Warum ist Archivieren besser als Löschen?
Ob Material kalt ist, ist eine Schätzung. Im Archiv bleibt es durchsuchbar und kann zurück ins Wiki, wenn ein Thema wieder wichtig wird. Gelöschtes müsstest du aus Git oder einem Backup holen.
Prüf dich selbst