Die Destille: Warum ich mir eine eigene Wissensdatenbank gebaut habe

Die Destille ist meine persönliche Wissensdatenbank: Markdown-Dateien im Git, gepflegt und durchsucht von einem KI-Agenten. Ihr Kern ist die Trennung von Roharchiv und Destillat. Die Originalquelle bleibt unverändert als Belegkette liegen, während daraus verdichtete, verlinkte und widerspruchsgeprüfte Wiki-Seiten entstehen. Anders als ein Second Brain verlinkt sie nicht nur vorhandene Dateien, sondern extrahiert neues Wissen. Anders als eine RAG-Datenbank akkumuliert sie es über Jahre. Warum mir beides allein zu wenig war, steht in diesem Beitrag.

Ich lese viel. Ich schreibe viel. Und trotzdem habe ich mich jahrelang dabei ertappt, dieselbe Arbeit zweimal zu machen.

1. Warum ich eigentlich eine Destille haben möchte

Mein Arbeitsalltag hat vier Ströme. Ich schreibe wissenschaftliche Paper. Ich führe eigene Studien durch. Ich betreue Abschlussarbeiten und halte Lehrveranstaltungen. Und ich entwickle nebenher ein eigenes Produkt, für das ich Marktdaten und Entscheidungen dokumentiere.

Jeder dieser Ströme produziert Material. Keiner produziert von allein Wissen.

Das Ergebnis nach ein paar Jahren sieht bei den meisten von uns ähnlich aus: PDFs in Zotero, Notizen in irgendeiner App, Manuskripte in Dropbox, Gutachten im Mailpostfach, Marktdaten in einer Tabelle, dazu Chatverläufe mit einem Sprachmodell, in denen erstaunlich gute Gedanken stecken, die nie wieder auftauchen. Wenn ich ein neues Paper anfange, beginne ich faktisch bei null, obwohl ich vor zwei Jahren schon einmal genau diese Literatur gelesen habe.

Der Punkt, an dem mich das wirklich gestört hat, war nicht das Wiederfinden. Das kriegt man mit Suche halbwegs hin. Es war etwas anderes: Ich wollte, dass ein System meine Position kennt.

Ein Beispiel, das ich ständig brauche. Was ist eigentlich User Experience? In den USA wird UX häufig aus der Designperspektive gedacht: Usability plus Design. In Europa liegt der Schwerpunkt eher auf Usability plus der emotionalen Ebene. Und die DIN-Norm definiert es wieder anders: die Wahrnehmungen und Reaktionen einer Person vor, während und nach der Nutzung.

Keine dieser Sichtweisen ist falsch. Aber wenn ich eine Einleitung schreibe, schreibe ich eine davon, und zwar immer dieselbe, weil sie meine ist. Genau das soll ein System wissen. Nicht den Durchschnitt des Internets referieren, sondern meine Sicht auf die Welt reproduzieren, mit der Norm als Grundlage, der Faktorzerlegung als Operationalisierung und der UEQ-Familie als Instrument.

Das kann ein Ordner nicht. Und ein Suchindex auch nicht.

2. Der Auslöser: Sprachmodelle sind gut im Bewerten, wenn man ihnen die Kriterien gibt

Die eigentliche Idee kam nicht aus dem Wissensmanagement, sondern aus meiner eigenen Forschung.

Ich habe mich in mehreren Arbeiten damit beschäftigt, wozu große Sprachmodelle in der wissenschaftlichen und gestalterischen Arbeit taugen und wozu nicht. Wie ich sie in meinem eigenen Arbeitsalltag einsetze, habe ich in UX-AI#1 beschrieben. Ein Befund zieht sich durch: Frei formulierte Urteile sind unzuverlässig, Urteile entlang eines vorgegebenen Kriterienkatalogs sind es nicht.

Fragt man ein Modell offen „Ist dieser Text gut?", bekommt man Höflichkeit. Gibt man ihm dagegen einen festen Raster vor (welche Kriterien, welche Skala, welche Belegpflicht), dann wird die Bewertung erstaunlich stabil und, was wichtiger ist, nachvollziehbar. Nicht weil das Modell klüger wird, sondern weil die Aufgabe eine andere ist: nicht mehr „urteile", sondern „ordne dieses Material in diese vorgegebenen Fächer ein".

Das war der Moment, in dem ich das auf mein eigenes Problem übertragen habe.

Denn was mache ich, wenn ich ein fremdes Paper lese? Ich mache immer dasselbe, seit Jahren, ohne es je aufgeschrieben zu haben. Ich frage mich vier Dinge:

• Was sind die Kernaussagen? Das ist der Baustein: zitierfähige Ergebnisse, die ich später mit Fundstelle in mein Related Work übernehmen kann.
• Wie sind die vorgegangen? Das ist das Muster: Methodik, die ich auf eigene Arbeiten übertragen kann.
• Woran muss sich meine Arbeit messen lassen? Das ist die Messlatte: Baselines und Benchmarks.
• Wie gut ist das eigentlich? Die Bewertung: Qualität, Limitationen. Eine qualitative Studie mit drei Teilnehmenden ist nun einmal keine Validierung, auch wenn im Abstract etwas anderes steht.

Diese vier Fragen sind mein Kriterienkatalog. Ich hatte ihn immer im Kopf und nie auf Papier. Sobald ich ihn aufgeschrieben habe, wurde daraus eine Aufgabe, die ein Agent zuverlässig ausführen kann, und deren Ergebnis ich in fünf Minuten gegenprüfen kann, statt es in zwei Stunden selbst zu schreiben.

Das ist der Kern der Destille: Nicht das Modell denken lassen, sondern ihm ein Raster geben, in das es das Gelesene einsortiert. Der Rest ist Infrastruktur.

3. Warum mir „Second Brain" zu wenig ist

Zur selben Zeit lief auf YouTube die große Second-Brain-Welle. Ich habe mir das angesehen, und ich fand die Grundidee gar nicht schlecht. Nur habe ich mich innerlich dagegen gewehrt und eine Weile gebraucht, um zu benennen, warum.

Der typische Aufbau ist: Markdown-Dateien in Obsidian, ein Modell verlinkt sie automatisch, und am Ende gibt es einen hübschen Graphen. Ich hatte diese Version selbst gebaut. Das Ergebnis war eine nette Grafik ohne Nutzen.

Denn eine Kante in so einem Graphen sagt nur: Datei A hängt irgendwie mit Datei B zusammen. Sie sagt nicht, wie. Zitiert A die Datei B, oder widerspricht sie ihr? Ist B eine Norm, eine Methode oder eine flüchtige Notiz? Ist der Inhalt geprüft oder hat ihn gestern ein Modell hingeschrieben?

Und vor allem: Es wurde nichts Neues extrahiert. Die Dateien wurden nur miteinander in Beziehung gesetzt. Der Schritt, um den es mir eigentlich ging, nämlich aus vorhandenen Artefakten neues, verdichtetes Wissen zu destillieren, findet dort gar nicht statt.

Der zweite naheliegende Weg ist die reine RAG-Datenbank: alle PDFs vektorisieren, indexieren, per MCP-Server durchsuchbar machen. Das funktioniert gut, ich nutze es selbst als Baustein. Aber es löst zwei von vier Problemen:

Die unteren beiden sind Akkumulationsprobleme. Sie entstehen erst dadurch, dass Wissen über Jahre zusammengeführt und gepflegt wird. Ein Index, der bei jeder Anfrage frisch zusammensucht, akkumuliert nichts. Deshalb brauche ich beides: einen Suchindex über das Rohmaterial und eine gepflegte Wissensschicht darüber.

4. Anforderungen an die Destille

Daraus wurden sieben Anforderungen, die ich vorab festgelegt habe:

1. Aus Quellen soll neues Wissen entstehen, nicht nur eine Verlinkung vorhandener Dateien.
2. Jede Sache genau einmal. Eine Definition von UX, ein Profil je gelesenem Paper, eine Heimatseite je Begriff, auch wenn ich denselben Begriff in acht Papern verwende. Kopien driften auseinander und erzeugen Widersprüche, die keine sind.
3. Widersprüche werden markiert, nicht überschrieben. Wenn Quelle A etwas anderes sagt als Quelle B, will ich das sehen und selbst entscheiden.
4. Meine Position muss im System stehen, nicht nur die Quellenlage.
5. Der Mensch behält die Bewertungshoheit. Ein Modell, das seine eigene Arbeit als zitierfähig einstufen darf, erzeugt eine Datenbank, deren Qualitätsangaben nichts bedeuten.
6. Alles bleibt lokal und portabel. Markdown im Git. Kein Anbieter, der mir das Format wegnimmt.
7. Der Aufwand muss sich lohnen. Das ist die härteste Anforderung; dazu am Schluss mehr.

5. Das Grundgerüst

Die tragende Entscheidung ist eine Trennung: Roharchiv und Destillat.

Das Roharchiv enthält Originale und deren maschinelle Lesefassungen: unveränderlich, vollständig, ungewichtet. Das Destillat enthält, was daraus an Erkenntnis gewonnen wurde: verdichtet, verlinkt, gepflegt, widerspruchsgeprüft. Der Name beschreibt genau diesen Vorgang: Rohes kommt in den Kessel, das Konzentrat bleibt übrig. Und das Original wird nie angefasst, denn es ist die Belegkette.

Darüber liegt eine einfache Ordnung. Es gibt Collections: grundlagen/, paper/, studien/, lehre/, abschlussarbeiten/, sondierung/ und mein Produkt. In jeder Collection liegen Bundles; ein Bundle ist ein Vorhaben: ein Paper, eine Erhebung, ein Modul, eine betreute Arbeit.

Und jedes Bundle sieht von innen gleich aus:

<bundle>/
├── CLAUDE.md    Steckbrief: Was ist das für ein Vorhaben?
├── raw/         Originale. Unveränderlich. Nur ich lege hier ab.
├── sources/     Normalisierte Markdown-Fassungen. Maschinenprodukt.
├── assets/      Abbildungen, Datensätze, Exporte
├── wiki/        Das Destillat. Hier entsteht Wissen.
└── work/        Meine Werkbank: Manuskripte und Entwürfe

Diese Uniformität ist kein Ordnungsfetisch, sondern der Grund, warum dieselben Befehle überall funktionieren. Der Auftrag „Führe für dieses Bundle einen Ingest aus" bedeutet in einem Paper-Projekt dasselbe wie in einer Studie.

Zwei Dinge halten das Ganze zusammen.

Die Regeldateien. In jedem Bundle liegt eine CLAUDE.md. Sie erbt von der Collection, die von einer globalen Datei. Dort steht, was der Agent darf und was er ausdrücklich nicht darf. Das macht das System in der Struktur sehr hart und in der Anwendung trotzdem weich, weil ich mit normalen Sätzen damit arbeite, nicht mit Kommandos.

Der Reifegrad. Jede Seite trägt einen von vier Werten: keim, entwurf, belastbar, kanonisch. Der Agent darf höchstens entwurf vergeben. belastbar und kanonisch vergebe ausschließlich ich. Das ist die wichtigste Einzelregel im ganzen System, und sie ist absolut: Keine Bundle-Regel kann sie aufweichen.

6. Der Ablauf beim Schreiben eines Papers

So sieht das konkret aus.

Projekt anlegen. Vorlage kopieren, Steckbrief ausfüllen: Arbeitstitel, Zielvenue, Deadline, Forschungsfragen, Ko-Autoren. Das klingt nach Bürokratie und ist der wichtigste Schritt, denn daran erkennt der Agent bei jedem späteren Auftrag, worum es geht.

Recherche. Und zwar zuerst im eigenen Bestand: „Beantworte mit der Destille: Was wissen wir über Thema X?" Existiert bereits ein Paper-Profil zu einer Quelle, ist die Arbeit schon getan: Es wird verlinkt, nicht neu geschrieben. Erst danach ergänze ich von außen. Neue PDFs wandern in raw/.

Ingest. Der eigentliche Destillationsschritt: „Führe für dieses Projekt einen Ingest aus." Dann läuft ab:

1. Qualitätstor: Bei schlechtem OCR bricht es ab. Ein Ingest über Buchstabensalat erzeugt plausibel aussehenden Unsinn, und der ist schlimmer als gar keine Seite.
2. Normalisieren: Aus jeder PDF wird eine Markdown-Fassung in sources/.
3. Verwandtes suchen: im eigenen Bundle und in den übergeordneten.
4. Wiki-Seiten anlegen: typisch fünf bis fünfzehn je Quelle, darunter genau ein Paper-Profil nach dem Kriterienkatalog aus Abschnitt 2.
5. Querlinks setzen, mit getippten Beziehungen: zitiert, baut-auf, verwendet-methode, definiert.
6. Konflikte markieren, wo die neue Quelle einer bestehenden Aussage widerspricht.
7. Index auffrischen.

Der Vorgang ist inkrementell. Ob ich fünf oder fünfzig Dateien hineinwerfe, ändert nur die Laufzeit.

Schreiben. Das Manuskript entsteht in work/, und dort schreibt der Agent nur auf ausdrücklichen Auftrag. Das ist meine Werkbank. Der wertvollste Auftrag in dieser Phase ist übrigens nicht „schreib mir einen Abschnitt", sondern: „Lies Abschnitt 3 und prüfe, ob jede Aussage durch ein Paper-Profil gedeckt ist." Das findet unbelegte Behauptungen, bevor ein Reviewer sie findet.

Konflikte. Wenn Quelle A sagt, nachts ist es dunkel, und Quelle B sagt, nachts ist es hell, dann entsteht daraus kein stiller Überschreibvorgang, sondern eine Notiz mit beiden Positionen, sowohl in der betroffenen Seite als auch in einem zentralen Register. Aufgelöst wird sie von mir. Manchmal lautet die Auflösung: B ist mir zu dünn belegt, A gilt. B bleibt trotzdem im System, nur niedriger bewertet. Denn Wissenschaft ist selten eindeutig, und die Entscheidung darüber ist genau der Teil, den ich nicht delegieren will.

7. Der Abschluss: Promotion

Wenn ein Paper fertig ist, kommt der Schritt, der aus lauter Projekten mit der Zeit eine Wissensdatenbank macht.

Ich starte einen Promotion-Durchlauf. Der Agent geht durch, was im Projekt-Wiki entstanden ist, und schlägt vor: Was davon hat über dieses Vorhaben hinaus Bestand? Ein Paper-Profil einer fremden Arbeit, die ich sicher wieder brauche, steigt ins Collection-Wiki auf. Ein Begriff wie Vibe Coding, der inzwischen für alle Bereiche relevant ist, steigt zwei Ebenen höher in die Grundlagen.

Entschieden wird das von mir. Der Agent macht Vorschläge, ich sage „ja", „nein" oder „mehr davon".

Am alten Ort bleibt ein Stub zurück. Und das ist keine Kopie, sondern der Rest nach dem Herausziehen des Allgemeinen: die lokale Sicht, wie dieses Projekt den Begriff einsetzt, unter welcher Referenznummer das Paper im Manuskript steht. Er verweist auf die Heimat, damit die Verbindung nicht verlorengeht.

So wächst das Langzeitgedächtnis organisch, statt am Reißbrett geplant zu werden. Projekt-Bundles sind kurzlebiger Arbeitsspeicher. Die Collection-Wikis und die Grundlagen sind das, was bleibt.

Und weil das kein harter Abschluss ist, kann ich den Vorgang jederzeit wiederholen.

8. Der Viewer

Zum Schluss noch das, was am besten aussieht und am wenigsten die eigentliche Arbeit ist.

Aus den Regeldateien, den Frontmatter-Feldern, den Links und den Konfliktnotizen baut ein Indexer einen Wissensgraphen (aktuell 288 Knoten und 1702 Kanten). Der Viewer zeigt ihn zweispaltig: links die Karte, rechts die gerenderte Seite.

Vergrößern

Vier Darstellungskanäle tragen dabei Information:

• Farbe zeigt, zu welchem Bundle oder Typ ein Knoten gehört.
• Größe zeigt den Grad, also wie stark etwas vernetzt ist.
• Deckkraft zeigt den Reifegrad. Was blass ist, ist ungeprüft. Der Blick auf den Graphen sagt mir also sofort, wie viel meines Vaults noch auf mein Urteil wartet.
• Hohle Knoten sind Geisterknoten: verlinkt, aber nie geschrieben. Das ist keine Fehlermeldung, sondern eine Arbeitsliste.

Ehrlich gesagt arbeite ich nicht im Viewer. Ich arbeite auf der Kommandozeile mit dem Agenten. Aber der Viewer kann etwas, was die Kommandozeile nicht kann: explorativ stolpern.

Ein Beispiel. Ich bin dort über eine Notiz gelaufen, die ich selbst hatte anlegen lassen: „Kollaborationsverlust auf Teamebene". Der Befund dahinter war mir in dieser Zuspitzung nie aufgefallen: Beim Einsatz von KI in Entwicklungsteams steigt die individuelle Effizienz, während die kollektive Leistung sinkt, weil man den Kollegen nicht mehr fragt, sondern das Modell. Er stand verteilt in zwei Studien, die ich für verschiedene Vorhaben gelesen hatte. Ulfsnes et al. (2024) beschreiben in einer Interviewstudie mit 13 Personen, wie generative KI das individuelle Lernen beschleunigt und zugleich den Lernkreislauf im Team unterbricht. Wivestad et al. (2024) messen dasselbe Muster quantitativ: In einem Quasi-Experiment mit 115 Teilnehmenden arbeiten Copilot-Nutzende fokussierter und sind weniger auf Kolleginnen und Kollegen angewiesen, ein individueller Gewinn bei sinkender Teaminterdependenz.

Keine der beiden Arbeiten sagt das für sich genommen. Erst nebeneinander ergeben sie den Satz, der mir vorher nie so klar war: Der Gewinn wird auf Individualebene realisiert, der Verlust auf Teamebene. Auf der Karte lagen die beiden plötzlich nebeneinander.

Aus Einzelkämpfern statt Teamkämpfern kann man ein eigenes Paper machen. Genau dafür ist so ein System da. Die organisatorische Seite dieser Frage behandle ich in AI-Dev#1: Warum KI kein Tool-Problem ist, sondern ein Organisationsproblem.

9. Was es mir bringt

Ich habe schon einige Systeme gebaut und wieder verworfen. Der Grund war immer derselbe: Es entstand Arbeit, aber kein Mehrwert. Und ein System, in das man nur hineinsteckt, ohne etwas herauszubekommen, stirbt zu Recht.

Die Destille ist das erste, bei dem ich das umgekehrt erlebe. Wenn ich heute sage „Erkläre den Unterschied zwischen Usability und User Experience", dann bekomme ich nicht den Durchschnitt des Internets, sondern meine Position: Usability als Gebrauchstauglichkeit (Effektivität, Effizienz, Zufriedenheit, gemessen während der Nutzung); User Experience als das Subjektive, vor, während und nach der Nutzung, messbar nur am Menschen. Mit den Belegen, die ich selbst geprüft und freigegeben habe.

Das ist der Unterschied zwischen einer Materialsammlung und einer Wissensdatenbank.

Die entscheidende Einsicht war dabei nicht technischer Natur. Sie war: Die Arbeit mache ich mir ohnehin. Jedes Paper wird gelesen. Jede Studie wird ausgewertet. Jede Abschlussarbeit wird begutachtet. Der einzige Unterschied ist, ob das Ergebnis danach in einem Ordner verschwindet, oder ob es beim nächsten Mal von allein wieder auftaucht.

Nur Daten sammeln war mir zu wenig.

Quellen

• Ulfsnes, R. et al. (2024). Transforming Software Development with Generative AI. Springer.
• Wivestad, V. T. et al. (2024). Copilot's Island of Joy. Springer LNBIP.

Die Destille läuft vollständig lokal: Markdown-Dateien im Git, eine lokale Hybridsuche, ein Agent mit Dateizugriff und ein paar Regeldateien. Nichts davon ist an ein bestimmtes Werkzeug gebunden: Ausgetauscht wird der Motor, nicht der Vault.