- Details
- Geschrieben von: Moritz Conjé
- Kategorie: Homelab
- Zugriffe: 11
Ein Plausibilitätstest an einem einzelnen Beispiel zeigt, dass ein Werkzeug funktionieren kann. Ob es im Alltag trägt, zeigt erst ein echter Lauf. Genau den hat der Redakteur mit dem neuen Suchwerkzeug absolviert. Das Ergebnis enthielt zwei Überraschungen: einen plausibel wirkenden Themencluster, den das Werkzeug verwarf, und eine Zahl, die die schöne Demo relativierte.
Der Testlauf
Seit dem letzten Lauf waren keine neuen Notizen hinzugekommen. Also nahm der Redakteur die 140 Eingangsnotizen, die noch nie von einem Lauf erfasst worden waren: ein alter Rest aus der Zeit des Umzugs von Notion. Den Abgleich mit Bestehendem erledigte er dabei ausschließlich über das Werkzeug, nicht mehr durch Lesen der Volltexte.
Ein Cluster, der nicht bestand
Ein Cluster ist eine Gruppe thematisch zusammengehörender Notizen, die der Redakteur als Vorschlag bündelt. Im Lauf fiel eine Gruppe von vier Notizen mit Gaming-Bezug auf. Nach Tags und Titeln wirkte sie stimmig. Die Kohärenzprüfung über die Ähnlichkeitswerte zeigte etwas anderes: Nur zwei der vier Notizen hingen inhaltlich zusammen (Ähnlichkeit 0,83), zu den beiden anderen lag der Wert nur zwischen 0,35 und 0,41. Der Redakteur hat den Cluster verworfen, statt ihn zusammenzuzwingen. Damit kam die Regel "kein künstliches Rauschen" erstmals real zur Anwendung. Genau diesen Fehler, Notizen nach Etikett statt nach Inhalt zu gruppieren, hätte ein Abgleich per Tags und Titeln vermutlich durchgewinkt.
Insgesamt entstanden vier neue Cluster. Zu einem bereits offenen Thema fand das Werkzeug eine passende Ergänzung (Ähnlichkeit 0,824), sodass eine Doppelung vermieden wurde. Außerdem tauchten mehrere Duplikat-Kandidaten auf. Von 140 Notizen wurden 23 verarbeitet, 117 blieben bewusst liegen, weil kein erkennbares Muster vorlag. Ein direkter Vergleich mit der alten Methode ist nicht möglich, denn eine parallele Runde per Volltext gab es nicht. Die beiden Fälle zeigen aber, wo das Werkzeug den Unterschied macht.
Die unbequeme Beobachtung
Beim Durchsehen fiel etwas anderes auf: Fast alle 140 Notizen bestanden nur aus Titel und Link, ohne erfassten Inhalt. Von gut 30 gesichteten Notizen hatte eine einzige echten Text oder ein Transkript. War das ein Sonderfall des alten Backlogs oder der Normalfall? Ein Scan über alle 1.665 Eingangsnotizen sollte es klären. Als ausreichend zählte eine Notiz, wenn sie ein Transkript enthielt oder mehr als 150 Zeichen eigenen Text.
Das Ergebnis: 72,6 Prozent, also 1.208 von 1.665 Notizen, hatten keinen ausreichenden Inhalt. Der Testbatch war der Normalfall. Es betraf sogar Notizen, die schon in früheren Läufen geclustert worden waren. Sie waren damit allein auf Basis des Titels eingeordnet worden. Das ist kein Fehler des neuen Werkzeugs, sondern eine Eigenschaft des Bestands, die vorher nie jemand gemessen hatte. Für eine Suche über Bedeutung ist sie trotzdem gewichtig: Ein Embedding aus einem Titel ist ein deutlich schwächeres Signal als eines aus dem vollen Text.
Die Reaktion
Für Artikel und Bookmarks entstand ein Web-Crawl-Skript, das den Inhalt der verlinkten Seiten nachträgt. LinkedIn-Notizen sitzen hinter einer Login-Wand und werden von Hand nacherfasst. Das Skript für YouTube-Transkripte, das ich in der Serie zu den Erfassungswegen beschrieben habe, läuft nun über den gesamten Bestand statt nur über drei Themenfelder. Die Embeddings habe ich bewusst noch nicht neu berechnet. Solange die Crawls laufen, würde das nur mit schwachen Titel-Werten weiterarbeiten. Dank der Prüfsummen aus dem Ingestion-Service ist der Nachlauf später billig, weil nur die geänderten Notizen neu anstehen.
Fazit
Das Werkzeug hat im ersten Praxistest gezeigt, was es kann: Es verwarf einen Cluster, der nur nach Etikett stimmte, und fand die Ergänzung zu einem offenen Thema. Zugleich hat es unbeabsichtigt die größte Schwachstelle des Systems sichtbar gemacht. Ein Suchsystem ist nur so gut wie der Text, den es kennt.
Ausblick
Im nächsten Teil geht es um die Zahl nach dem Nachtragen: Wie viel hat sich in wenigen Tagen verändert, und was ändert die Suche gegenüber dem bisherigen Lesen nach Gefühl tatsächlich? Auch ein zweites Grundproblem bleibt offen: wie mit sehr langen Texten umzugehen ist, die sich nicht mit einer einzelnen Zahlenreihe erfassen lassen.
- Details
- Geschrieben von: Moritz Conjé
- Kategorie: Homelab
- Zugriffe: 22
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.
- Details
- Geschrieben von: Moritz Conjé
- Kategorie: Homelab
- Zugriffe: 33
Mit dem Embedding-Modell steht die Übersetzung von Text in Zahlenreihen. Jetzt braucht es zwei Dinge: einen Ort, an dem diese Zahlenreihen leben, und ein Skript, das sie für den gesamten Notizbestand erzeugt und dorthin schreibt. Dieser Teil beschreibt das Schema der Datenbank, den sogenannten Ingestion-Service, den ersten vollen Lauf über 1.740 Notizen und einen Kompromiss, den eine unscheinbare Netzwerkfreigabe erzwang.
Was in die Datenbank kommt
Die Suche soll drei Arten von Notizen abdecken: die rohen Eingangsnotizen aus den Erfassungswegen, bereits verarbeitete Notizen und die Zusammenfassungen der Themencluster aus den Übergabe-Artefakten. Sie unterscheiden sich in ihren Metadaten: Tags und Themenbereich heißen je nach Quelle anders und stehen an anderer Stelle. Das Skript muss sie deshalb erst vereinheitlichen, bevor alle in dieselbe Tabelle passen.
Das Schema: eine Tabelle, ein Index
Pro Notiz gibt es genau eine Zeile in einer Tabelle. Sie enthält den Pfad der Notiz als eindeutige Kennung, den Quelltyp, Tags und Themenbereich, eine Prüfsumme des Inhalts, die 768 Zahlen des Embeddings und einen Zeitstempel. Dazu kommt ein spezieller Index vom Typ HNSW. Ohne ihn müsste die Datenbank bei jeder Suche die Anfrage mit jeder einzelnen Zahlenreihe vergleichen. Der Index legt stattdessen eine Art Navigationskarte an und findet den nächsten Nachbarn unter Tausenden Einträgen in Millisekunden. Man kann ihn sich wie ein Inhaltsverzeichnis vorstellen, das man nicht Seite für Seite durchblättern muss. Als Ähnlichkeitsmaß nutzt er dieselbe Cosine-Similarity wie der Modelltest.
Der Einleser mit Gedächtnis
Der Ingestion-Service liest alle Notizen, schickt jede an Ollama zum Embedding und schreibt das Ergebnis in die Datenbank. Damit nicht bei jedem Lauf alles neu berechnet werden muss, speichert er zu jeder Notiz eine Prüfsumme über ihren Inhalt (SHA-256). Beim nächsten Lauf wird nur neu berechnet, was sich tatsächlich geändert hat. Das ist wichtig, weil jede Berechnung Zeit kostet und der Bestand weiter wächst. Ein Test bestätigte es: Ein zweiter Lauf über dieselben 20 Notizen ergab null neue, null aktualisierte und 20 unveränderte Einträge.
Der Stolperstein: eine Netzwerkfreigabe
Eigentlich sollte auch der Ingestion-Service als Container laufen, als vierter Dienst im Stack. Der Vault liegt aber auf einer Netzwerkfreigabe des NAS, die unter Windows als Laufwerk eingebunden ist. Docker Desktop kann solche an die Windows-Sitzung gebundenen Freigaben nicht in einen Container durchreichen: Der Ordner im Container blieb leer, obwohl alles richtig konfiguriert schien. Ich habe mich für einen Kompromiss statt einer Verzögerung entschieden. Der Ingestion-Service läuft in der Entwicklungsphase direkt auf dem Windows-Rechner und spricht die containerisierten Dienste über localhost an. Auf einem Linux-Host lässt sich die Freigabe dagegen wie in der Claude-Remote-LXC auf dem Host einbinden und per Bind-Mount durchreichen. Dort wird die Containerisierung wie geplant nachgeholt.
Der erste volle Lauf
Der Lauf über den gesamten Bestand umfasste 1.740 Notizen: 1.665 Eingangsnotizen, 40 verarbeitete Notizen und 35 Cluster-Zusammenfassungen. Er dauerte knapp drei Minuten. Das ist deutlich schneller als der Modelltest erwarten ließ (0,92 Sekunden pro Notiz, hier rund 0,10). Im Test fiel das Laden des Modells bei jeder kleinen Stichprobe stärker ins Gewicht, im Dauerlauf entfällt dieser Aufwand. Danach habe ich die Zählung nach Quelltyp mit den Dateien im Vault abgeglichen: Es fehlte nichts. Eine Sicherung der Datenbank ist als Dump angelegt, und ein erster Stichproben-Check ergab thematisch plausible Nachbarschaften über alle drei Quelltypen hinweg.
Fazit
Zum Modell aus dem letzten Teil gehört jetzt der Ort, an dem seine Ergebnisse liegen: eine Tabelle mit Index, ein Skript mit Gedächtnis und eine gefüllte Datenbank. Befüllt heißt aber noch nicht nutzbar. Bisher kann niemand eine Frage stellen.
Ausblick
Der nächste Teil macht die Datenbank abfragbar und stellt sie dem Redakteur als Werkzeug zur Verfügung, samt einer Überraschung bei der Software-Version. Zwei Fragen bleiben bewusst offen: Jede Notiz hat bisher genau eine Zahlenreihe, ob das auch bei sehr langen Texten reicht, zeigt ein späterer Teil. Und wie viel echter Inhalt tatsächlich hinter den Notizen steckt, ist eine eigene Geschichte.
- Details
- Geschrieben von: Moritz Conjé
- Kategorie: Homelab
- Zugriffe: 44
Welches Modell die Bedeutung der Notizen in Zahlenfolgen übersetzt, entscheidet darüber, wie gut die Suche später trifft und welche Hardware der Stack braucht. Zwei Kandidaten standen zur Wahl: nomic-embed-text und bge-m3. Statt nach Bauchgefühl oder Beliebtheit zu entscheiden, habe ich beide mit echten Notizen aus dem Vault gemessen. Das Ergebnis hing überraschend stark davon ab, ob dabei eine Grafikkarte im Spiel war.
Was ein Embedding-Modell macht
Ein Embedding-Modell liest einen Text und übersetzt seine Bedeutung in eine lange Zahlenreihe. Bei nomic-embed-text sind es 768 Zahlen pro Text. Man kann sich diese Reihe wie Koordinaten auf einer Landkarte der Bedeutung vorstellen: Texte zu ähnlichen Themen landen dicht beieinander, Texte zu fernen Themen weit auseinander. Entscheidend ist, dass dabei nicht die Wörter zählen, sondern der Sinn. Eine Notiz über die "Sicherung auf dem NAS" und eine über das "Backup-Konzept für den Fileserver" teilen kaum ein Wort und liegen trotzdem nah beieinander. Eine klassische Stichwortsuche würde diese Verbindung verpassen.
Wie gut ein Modell diese Landkarte zeichnet, unterscheidet sich von Modell zu Modell. Genau das macht die Wahl wichtig: Das Modell bestimmt, was die Suche später überhaupt als ähnlich erkennen kann.
Wie das Ergebnis in die Suche einfließt
Das Modell kommt an zwei Stellen zum Einsatz. Beim Einlesen bekommt jede Notiz ihre Zahlenreihe und wird damit in der Datenbank gespeichert. Bei einer Suche wird die Anfrage vom selben Modell ebenfalls in eine Zahlenreihe übersetzt, und die Datenbank liefert die Notizen, deren Reihen am nächsten liegen. Das Maß dafür ist dieselbe Cosine-Similarity, die ich im Test genutzt habe: Werte nahe 1 bedeuten große inhaltliche Nähe, Werte nahe 0 kaum Verwandtschaft.
Daraus folgen zwei Konsequenzen. Erstens muss für Notizen und Anfragen dasselbe Modell verwendet werden, sonst sind die Landkarten nicht vergleichbar. Ein späterer Wechsel hieße, den gesamten Bestand neu zu berechnen. Zweitens zahlt die Qualität des Modells direkt auf die Trefferqualität ein, während seine Geschwindigkeit bestimmt, wie lange das Einlesen dauert. Beides floss in den Vergleich ein.
Ein Testaufbau mit echten Notizen
Beide Modelle liefen über Ollama, den Dienst aus dem Compose-Stack. Als Testmaterial dienten sechs echte Notizen: mehrere thematisch verwandte aus der Hardware-Dokumentation, dazu eine bewusst fernliegende Kontrollnotiz. Für die Qualität habe ich die Cosine-Similarity genutzt: Verwandte Notizen sollten hohe Werte erreichen, die Kontrollnotiz einen niedrigen.
Die Geschwindigkeit habe ich zweimal gemessen: einmal mit Grafikkarte, einmal in einem temporären Container ganz ohne. Der zweite Test war der wichtigere, denn die NUCs im Homelab haben keine Grafikkarte.
Qualität: beide bestehen
- nomic-embed-text: 0,91 für die verwandten Notizen, 0,58 für die Kontrollnotiz.
- bge-m3: 0,79 für die verwandten Notizen, 0,40 für die Kontrollnotiz. Der Abstand ist mit 0,39 etwas größer als bei nomic-embed-text (0,33), das Modell trennt also etwas schärfer.
Beide Modelle erkannten außerdem korrekt, dass die Einrichtungsnotiz für Home Assistant zur Hardware-Dokumentation des passenden Geräts gehört. Ein kleiner Qualitätsvorteil bei bge-m3, aber nichts, was den Ausschlag geben musste.
Geschwindigkeit: der GPU-Test täuscht
Mit Grafikkarte war bge-m3 das schnellere Modell: 0,61 Sekunden pro Notiz gegen 0,92 Sekunden bei nomic-embed-text. Hätte ich nur diesen Wert genommen, wäre die Wahl in die falsche Richtung gegangen. Ohne Grafikkarte kehrte sich das Bild um:
- nomic-embed-text: 0,67 Sekunden pro Notiz.
- bge-m3: 1,97 Sekunden pro Notiz, also fast das Dreifache.
Hochgerechnet auf die rund 1.740 Notizen der ersten Befüllung sind das etwa 20 Minuten gegenüber gut 57 Minuten. Dabei lief auch der Test ohne Grafikkarte auf einem stärkeren Prozessor als in den NUCs. Die Werte sind daher eine optimistische Untergrenze, auf der Zielhardware dürfte es eher länger dauern.
Die Entscheidung
Die Wahl fiel auf nomic-embed-text: fast dreimal schneller ohne Grafikkarte, deutlich kleiner (274 MB statt 1,2 GB) und mit nur einem geringen Qualitätsnachteil. bge-m3 bleibt als Option im Hintergrund, falls sich im Alltag zeigt, dass die Trennschärfe nicht ausreicht.
Fazit
Die Ausgangsfrage war, welches Modell besser ist. Die Antwort lautet: das, das in der Zielumgebung besser läuft. Ein Vergleich auf der falschen Hardware hätte hier das falsche Modell gekürt.
Ausblick
Mit dem Modell steht die Grundlage. Im nächsten Teil wird daraus die erste befüllte Datenbank, in der jede Notiz ihre Zahlenreihe bekommt, samt einem Stolperstein, der auf einer unscheinbaren Netzwerkfreigabe wartete. Ob die Modellwahl auch im Alltag trägt oder bge-m3 doch noch zum Zug kommt, zeigt sich in den späteren Teilen mit der praktischen Nutzung.
- Details
- Geschrieben von: Moritz Conjé & Claude
- Kategorie: Homelab
- Zugriffe: 54
Nach dem Konzept für die Suchschicht steht die erste Umsetzungsentscheidung an: Wo und wie soll das Ganze laufen? Die Antwort war schnell gefunden, der Weg dorthin nicht. Zwei Stolpersteine kosteten Zeit, und keiner davon war ein Programmierfehler. Beide beruhten auf falschen Annahmen: dass die eigene Dokumentation den aktuellen Zustand zeigt und dass sich durch Aufräumen Arbeitsspeicher freischaufeln lässt.
Keine Dienste roh auf dem Rechner
Meine Vorgabe lautete, keine einzelnen Dienste direkt auf einem NUC zu installieren. Die Lösung soll sich auf andere Hardware übertragen lassen, ohne dass etwas neu aufgebaut werden muss. Daraus wurde ein Docker-Compose-Stack aus vier Diensten:
- Postgres mit pgvector: die Datenbank, die neben normalen Daten auch die Zahlenfolgen zur Bedeutung der Notizen speichert und durchsuchbar macht.
- Ollama: stellt das Modell bereit, das diese Zahlenfolgen, die Embeddings, lokal berechnet, ganz ohne Cloud-Anbindung.
- Ingestion-Service: liest die Notizen aus dem Vault und schreibt sie samt Embedding in die Datenbank.
- MCP-Server: die Schnittstelle, über die der Redakteur die Suche als Werkzeug aufrufen kann.
Alle Dienste laufen mit fest gepinnten Versionen, nie mit latest, und zwar in einer eigenen, neu angelegten LXC statt auf der vorhandenen Docker-VM. Dort laufen bereits andere sicherheitskritische Dienste, die ich nicht mit einem neuen Experiment koppeln wollte. Der eigentliche Portabilitätsgewinn liegt im Stack selbst: Der Host bleibt austauschbar, weil sich alles per docker compose up neu starten lässt.
Welcher Host? Die Doku widersprach sich
Für die Platzierung kamen zwei Maschinen in Frage. Die Hardware-Spezifikation führte den dritten NUC, eine GMKtec NucBox G11, als "frei". Der Name eines bereits eingerichteten Claude-Connectors deutete dagegen auf Home-Assistant-Nutzung auf genau diesem Gerät hin. Bevor die LXC entstand, habe ich das gezielt nachgeprüft. Ergebnis: Die Spezifikation stammte aus der Zeit vor dem Umzug von Home Assistant. Der NUC lief seit dem 20. Juli produktiv mit einer Home-Assistant-VM und einer zweiten Docker-VM für Grafana und InfluxDB. Auch die zentrale Infrastruktur-Übersicht war an dieser Stelle nicht mehr aktuell. Beide Dokumente habe ich korrigiert, als Ziel-Host blieb der ASUS-Hauptserver (NUC 2). Wie sich die Geräte im Homelab verteilen, beschreibt der Beitrag zum Aufbau des Homelabs.
Die RAM-Jagd, die keine war
Auf dem NUC 2 waren nur etwa 6 GB Arbeitsspeicher frei, knapp für den Stack samt Embedding-Modell. Zwei Kandidaten zum Aufräumen standen fest: eine ungenutzte WireGuard-LXC, die längst durch Tailscale abgelöst ist (wie der Zugriff von unterwegs heute läuft, steht im Beitrag zu Claude Remote auf der LXC), und eine gestoppte Superset-VM, deren Projekt aktuell pausiert. Ich habe die LXC entfernt und den Status der VM geprüft, in der Erwartung, mehrere Gigabyte zurückzugewinnen.
Der Gewinn lag bei null. Beide Gäste liefen bereits nicht mehr, und ein gestoppter Proxmox-Gast belegt keinen Host-Arbeitsspeicher. Aufräumen schafft nur dann Platz, wenn das Entfernte vorher tatsächlich lief. Diese Erwartung war ein Denkfehler über die Ressourcenverwaltung, kein Zufall.
Kurswechsel: erst der Prototyp
Statt den NUC weiter auszuquetschen, läuft der Prototyp vorerst auf dem deutlich stärkeren Gaming-PC (i7-14700KF, 64 GB RAM, RTX 4070 Super), und der Stack stand dort binnen weniger Minuten, samt verifizierter GPU-Durchreichung. Welcher NUC am Ende die LXC bekommt, ist bewusst vertagt. Genau dafür war der portable Stack gedacht.
Fazit
Der Ausgangspunkt war eine einfache Frage: Wohin mit dem Stack? Die vorläufige Antwort ist der leistungsstärkere Gaming-PC, und der portable Compose-Stack macht diesen Umweg ohne Aufwand möglich; die Entwicklung kann später einfach auf anderen Geräten integriert werden.
Ausblick
Die vier Dienste sind hier nur kurz vorgestellt und bekommen in den nächsten Teilen ihren eigenen Auftritt: erst das Embedding-Modell, von dem die Hardware-Entscheidung abhängt (zwei Kandidaten treten gegeneinander an, und ein Ergebnis fiel anders aus, als der erste Messwert vermuten ließ), danach Datenbank und Ingestion und schließlich die Suche als Werkzeug. Wo der Stack am Ende produktiv läuft und ob dafür ein Umzug nötig wird, kommt in einem späteren Teil.