Moritz Conjé
Der Second-Brain-Redakteur aus dieser Serie liest neue Notizen im Batch, ordnet sie ein und gleicht sie mit dem ab, was im Second Brain bereits steht. Bei überschaubarem Bestand funktionierte das gut. Inzwischen liegen dort über 1.600 Notizen (Wege, auf denen sie ins Second Brain gelangen, beschreibt dieser Beitrag), und das Vorgehen hat einen Konstruktionsfehler, der mit jeder weiteren Notiz schwerer wiegt: Der Redakteur hat kein Gedächtnis und liest den Vergleichsstoff bei jedem Lauf neu ein. Dieser Beitrag beschreibt, warum das nicht skaliert, weshalb eine Suchschicht dafür die passende Antwort ist und warum sie das bewährte Übergabe-Artefakt trotzdem nicht ersetzt.
Das Problem: Abgleich per Volltext
Zu den Aufgaben des Redakteurs gehört der Abgleich mit Bestehendem: Passt eine neue Notiz zu einem Thema, das schon erfasst ist? Lässt sie sich einem offenen Cluster aus einem früheren Lauf zuordnen? Bisher hieß das, dass der Redakteur die aktuellen Notizen zusammen mit Teilen des Bestands vollständig einliest und im Sprachmodell selbst gegeneinander hält. Mit wachsendem Bestand kippt das in zwei Richtungen. Pro Lauf muss immer mehr Text gelesen werden. Und ein überfülltes Kontextfenster, also die Textmenge, die ein Modell gleichzeitig im Blick behalten kann, verschlechtert erfahrungsgemäß die Qualität der Ergebnisse. Für diesen Effekt hat sich der Begriff Context Rot eingebürgert.
Bislang hält eine Konvention dagegen: nur Batches lesen, nicht alles auf einmal. Das mildert das Problem, löst es aber nicht. Im Kern ist der Abgleich nämlich gar keine Entscheidungsaufgabe, sondern ein Suchproblem: Welche vorhandenen Notizen sind der neuen inhaltlich am ähnlichsten? Genau dafür braucht es kein vollständiges Lesen, sondern gezieltes Nachschlagen.
Ersetzen oder ergänzen?
Die naheliegende Frage lautete zuerst, ob das Übergabe-Artefakt dann überhaupt noch gebraucht wird. Es ist das Dokument, in dem der Redakteur seine Cluster-Erkenntnisse festhält, samt Reifegrad, Einordnung und Routing an mich oder den Prozess-Agenten. Die Analyse kam zu einem klaren Ergebnis: Es bleibt. Nur die Arbeit teilt sich sauber in zwei Schichten:
- Entscheidungsschicht (bleibt unverändert): Übergabe-Artefakt, Reifegrad-Einschätzung, Routing und Status-Workflow. Der Engpass im Second Brain ist meine Aufmerksamkeit, nicht die Rechenkapazität. Ob eine Notiz für eine Aufgabe reicht oder ob es sich um neues Potenzial oder nur um eine Ergänzung handelt, bleibt eine Einschätzung des Sprachmodells mit meiner Freigabe.
- Retrieval-Mechanik (wird ersetzt): Wie der Redakteur an den passenden Kontext kommt. Statt Volltexte zu lesen, fragt er eine Suche nach den ähnlichsten Kandidaten. Die Suche liefert Vorschläge, keine Entscheidungen.
Als Suche kommt eine Vektorsuche in Frage. Jede Notiz wird dabei in eine Zahlenfolge übersetzt, die ihre Bedeutung abbildet, ein sogenanntes Embedding. Inhaltlich ähnliche Notizen liegen dann rechnerisch nah beieinander, auch ohne gemeinsame Stichwörter. Wichtig ist eine Nebenbedingung: Die Suche liest nur, sie schreibt nichts. An den Schreibrechten des Redakteurs ändert sich also nichts, der Grundsatz "je autonomer eine Rolle, desto enger das Schreibrecht" bleibt erhalten. Die Retrieval-Schicht wird damit Unterbau, kein Parallelsystem.
Ein Vorbehalt: keine externe Bestätigung
Zur Ehrlichkeit gehört, dass es für genau diesen Anwendungsfall kein belegtes Best-Practice-Muster gibt. Eine begleitende Recherche zu vergleichbaren Setups fand weder Belege dafür noch dagegen, ein persönliches Wissenssystem mit einem KI-Redakteur zu betreiben, der per Vektorsuche gegen den eigenen Bestand abgleicht. Der Vorschlag ist in sich stimmig und leitet sich aus dem eigenen Engpass ab, extern validiert ist er nicht. Deshalb ist der Plan so angelegt, dass sich jeder Schritt einzeln abbrechen lässt.
Enger Zuschnitt statt großer Vision
Im Konzept stand bereits länger eine deutlich größere Idee: eine Wissensschicht, die auch rohe Gesprächsverläufe mit der KI, Konfigurationsdateien und PDFs durchsuchbar macht. Das habe ich bewusst zurückgestellt. Der Startpunkt ist ein enger Zuschnitt, der nur das löst, was den Redakteur akut bremst, nämlich den Abgleich mit Bestehendem. Alles Weitere, etwa zusätzliche Quellen oder eine Graph-Ebene über die vorhandenen Wikilinks, bleibt Teil der größeren Vision und kommt erst dazu, wenn die Basis stabil läuft.
Vier Phasen mit Gate
Für die Umsetzung entstand ein Plan in vier Phasen:
- Prüfung und Vorbereitung: Läuft die benötigte Technik überhaupt auf der vorhandenen Hardware, die keine Grafikkarte hat?
- Schema und Ingestion: Wie werden Notizen gespeichert, und wie gelangen sie in die Suche?
- Retrieval und Integration: Die eigentliche Abfrage, angebunden als Werkzeug für den Redakteur.
- Testlauf und Review: Ein realer Lauf, danach meine Entscheidung, ob die Schicht bleibt.
Zwischen den Phasen gilt ein Gate-Prinzip: Es geht nur weiter, wenn die vorherige Phase ohne größere Hürden gelaufen ist. Scheitert schon die erste, geht es zurück auf die Konzeptebene, statt auf einer wackligen Grundlage weiterzubauen.
Fazit
Ausgangspunkt war ein Redakteur, der mit jeder neuen Notiz mehr lesen muss, um denselben Abgleich zu leisten. Die Antwort darauf ist keine zweite Instanz, die ihm die Arbeit abnimmt, sondern eine saubere Trennung: Die Suche liefert Kandidaten, das Übergabe-Artefakt und meine Freigabe halten die Entscheidung. Ob das in der Praxis trägt, ist damit noch nicht bewiesen. Das klärt erst die Umsetzung.
Ausblick
Der nächste Teil beschreibt die erste Umsetzungsentscheidung: warum die Lösung als portabler Container-Stack entsteht statt als lose Sammlung von Diensten auf einem einzelnen Rechner, und wie eine veraltete Dokumentation die Wahl des richtigen Hosts erschwerte. Weitere Fragen bleiben bewusst offen und kommen in späteren Teilen dran: welches Modell die Zahlenfolgen für die Bedeutung erzeugt, ob jede Notiz als Ganzes oder in Abschnitten gespeichert wird und ob sich zusätzlich die Verlinkungsstruktur des Wikis als Signal für die Suche nutzen lässt.
