Moritz Conjé
Nach dem letzten Teil war die Datenbank gefüllt, aber es konnte noch niemand eine Frage stellen. Dieser Teil schließt die Lücke in zwei Schritten: erst eine Abfragefunktion, die zu einer Suchanfrage die passendsten Notizen findet, dann ein Werkzeug, das der Redakteur selbst aufrufen kann. Unterwegs wartete eine Überraschung bei der Software-Version.
Die Abfrage: die nächsten Nachbarn finden
Eine Suchanfrage läuft in drei Schritten ab. Zuerst übersetzt dasselbe Modell, das die Notizen eingelesen hat, den Suchtext in eine Zahlenreihe. Dann sucht die Datenbank die gespeicherten Zahlenreihen, die dieser am nächsten liegen. Zurück kommen die besten Treffer mit einem Ähnlichkeitswert zwischen 0 und 1. Die Fachsprache nennt das Top-k-Abfrage: die k ähnlichsten Einträge, wobei k die gewünschte Trefferzahl ist.
Die Funktion lässt sich zusätzlich eingrenzen, etwa auf einen Quelltyp oder auf Cluster, die noch offen sind. Der Redakteur kann so gezielt fragen: "Gibt es zu dieser Notiz schon einen offenen Cluster?" Die dafür nötigen Felder fehlten im ersten Schema und wurden beim Bau nachgetragen. Danach kam ein Plausibilitätstest an einem Fall, den der Redakteur bereits real geclustert hatte. Die Anfrage "Proxmox Backup Server, TrueNAS Storage und ZFS für Homelab-Infrastruktur" lieferte auf Platz 1 die passende Cluster-Zusammenfassung mit einem Wert von 0,849, dahinter sieben thematisch treffende Eingangsnotizen.
Vom Skript zum Werkzeug: MCP
Damit der Redakteur die Abfrage nutzen kann, braucht er einen Zugang, der nicht direkt in die Datenbank führt. Dafür dient MCP, das Model Context Protocol. Es ist ein Standard, über den KI-Agenten externe Werkzeuge ansprechen, vergleichbar mit einer genormten Steckdose: Egal, was dahintersteckt, der Agent sieht nur das fertige Werkzeug. Der MCP-Server im Stack bietet genau eines an, search_homelab_knowledge. Es nimmt eine Suchanfrage samt Filtern entgegen, lässt sie berechnen, fragt die Datenbank und gibt die Treffer mit ihrem Ähnlichkeitswert zurück.
Der Server läuft als eigener Dienst im Compose-Stack und braucht keine Grafikkarte, denn er führt nur eine Datenbankabfrage und eine einzelne Embedding-Berechnung pro Anfrage aus. Im lokalen Netz erreichbar ist er für die Claude-Remote-LXC, die ihn als Client eingetragen hat. Die Statusmeldung "Connected" bestätigte die Verbindung. Ich habe das Werkzeug bewusst für den ganzen Benutzer registriert und nicht nur für ein Projekt, es steht damit jeder Claude-Remote-Sitzung zur Verfügung, nicht nur dem Redakteur.
Die Überraschung: eine neue Version
Beim Bau des Servers zeigte sich, dass das offizielle Python-Paket für MCP inzwischen in der Version 2.0.0 vorlag, deutlich neuer als gängige Anleitungen. Die dort übliche Klasse FastMCP gab es in dieser Version nicht mehr. Sie war durch MCPServer ersetzt worden, mit anderem Aufbau und anderem Startbefehl. Die Anpassung war schnell erledigt. Ein Test mit einem echten MCP-Client lieferte danach identische Ergebnisse wie die direkte Abfrage, und ein zweiter Test nach dem Verpacken in einen Container ebenfalls. Die Lehre: Bei schnelllebiger Software zählt die Dokumentation der installierten Version, nicht das Tutorial aus dem Netz.
Was sich für den Redakteur ändert
Der Abgleich mit Bestehendem läuft jetzt über das Werkzeug. Der breite Lesezugriff auf verarbeitete Notizen und offene Cluster früherer Läufe ist für diesen Schritt gestrichen. Damit ist eine Regel, die im Konzept noch eine bloße Konvention war, technisch erzwungen: Der Redakteur verarbeitet Batches und kann gar nicht mehr alles auf einmal einlesen.
Fazit
Aus der gefüllten Datenbank ist ein Werkzeug geworden, das ein KI-Agent selbstständig nutzen kann. Aus einer Absprache ("nur Batches lesen") wurde eine Grenze, die das System selbst zieht.
Ausblick
Ob das Werkzeug im Alltag hält, was der Plausibilitätstest verspricht, zeigt erst ein echter Lauf. Genau darum geht es im nächsten Teil, samt einer unbequemen Zahl hinter der schönen Demo. Die Frage, wie sich sehr lange Texte in der Suche verhalten, bleibt für einen späteren Teil offen.
