KI-Stack 2.13.0 – Was sich seit Version 2.7.0 verändert hat
Mit KI-Stack 2.7.0 war ein wichtiger Punkt erreicht: Die grundlegende Architektur stand, die Installation war weitgehend reproduzierbar und mit RAG war erstmals auch eigenes Wissen fest in den lokalen KI-Stack integriert. Seitdem hat sich allerdings deutlich mehr verändert, als die Versionsnummern auf den ersten Blick vermuten lassen.
Zwischen 2.7.0 und 2.13.0 ging es weniger darum, ständig neue Anwendungen hinzuzufügen. Der Schwerpunkt verlagerte sich zunehmend auf Reproduzierbarkeit, sichere Updates, konsistente Zustände und die Frage, wie sich aus den einzelnen Komponenten tatsächlich ein verlässliches Gesamtsystem bauen lässt.
Mit 2.13.0 ist dieser Umbau an einem weiteren wichtigen Punkt angekommen. Besonders RAG, Open WebUI, SearXNG und die Agentenprofile arbeiten inzwischen wesentlich enger zusammen.
Von der Installation zum verwalteten System
Die frühen Versionen des KI-Stacks konzentrierten sich vor allem darauf, die benötigten Komponenten zuverlässig auf einem Windows-System mit WSL2 bereitzustellen.
Das bleibt weiterhin die Grundlage. Inzwischen betrachtet der Installer eine bestehende Installation jedoch nicht mehr einfach als eine Sammlung von Programmen, die auf eine bestimmte Version gebracht werden müssen.
Stattdessen wird zwischen mehreren Zuständen unterschieden.
Eine installierte Version beschreibt den tatsächlich vorhandenen Stand. Die im KI-Stack hinterlegte Version definiert den getesteten Referenzstand. Zusätzlich kann geprüft werden, ob upstream bereits eine neuere Version existiert.
Diese Unterscheidung ist wichtig, weil ein verfügbares Update nicht automatisch bedeutet, dass KI-Stack dieses Update installieren sollte.
Ein bereits vorhandenes und unterstütztes neueres ComfyUI oder Open WebUI darf deshalb bestehen bleiben. Der Installer versucht nicht mehr, ein solches System auf eine ältere Referenzversion zurückzustufen.
Gerade bei einer Installation, die über längere Zeit genutzt und individuell erweitert wird, ist das wesentlich sinnvoller als ein klassisches „Soll-Version überschreibt Ist-Version“-Verfahren.
Updates werden zu einem eigenen Lifecycle
Mit den späteren Versionen kam deshalb auch ein zentraler Update-Mechanismus hinzu.
Update-KIStack-All.cmd beziehungsweise die zugehörige PowerShell-Logik prüft die vom KI-Stack verwalteten Komponenten und trennt dabei bewusst zwischen:
- tatsächlich installierter Version,
- vom KI-Stack getesteter beziehungsweise gepinnter Version,
- verfügbarer Upstream-Version.
Eine verfügbare neue Version ist zunächst nur eine Information.
Automatisch verändert wird ein System nur dann, wenn innerhalb des KI-Stack-Vertrags tatsächlich eine notwendige Abweichung festgestellt wird.
Das reduziert eines der größten Risiken komplexer lokaler KI-Installationen: Ein Update einer Einzelkomponente darf nicht unbemerkt andere Teile des Systems beschädigen.
RAG wird vom Zusatz zum festen Bestandteil
Eine der größten Änderungen seit 2.7.0 betrifft RAG.
Retrieval Augmented Generation war bereits damals Bestandteil des Systems. Inzwischen wurde daraus jedoch ein wesentlich klarer definierter und reproduzierbarer Prozess.
Dokumente werden nicht einfach nur in eine Wissensdatenbank importiert. Der Import besitzt inzwischen einen nachvollziehbaren Vertrag für Dokumente und Suchanfragen.
Beim eingesetzten Nomic-Embeddingmodell werden Dokument- und Query-Präfixe korrekt unterschieden. Gleichzeitig werden zusätzliche Metadaten wie
source_file
und
chunk_index
gespeichert.
Damit kann später nachvollzogen werden, aus welcher Datei und welchem Dokumentabschnitt ein Treffer stammt.
Auch wiederholte Importe wurden abgesichert. Ein SHA-256-basierter Mechanismus erkennt bereits importierte Inhalte und verhindert, dass derselbe Dokumentbestand bei jedem Lauf erneut dupliziert wird.
Projektwissen lässt sich zudem voneinander trennen. Damit wird aus einer einzelnen Wissenssammlung schrittweise eine Grundlage für mehrere voneinander unabhängige Knowledge-Bereiche.
Der Import kann inzwischen auch unbeaufsichtigt und reproduzierbar ausgeführt werden.
Wichtig ist dabei besonders das Zusammenspiel mit dem restlichen Installer: Eine bereits eingerichtete RAG-Konfiguration bleibt auch bei späteren Reconcile- beziehungsweise Integrationsläufen erhalten.
RAG ist damit keine nachträglich angehängte Funktion mehr, sondern Bestandteil des Lifecycle-Modells des KI-Stacks.
Aus Profilen werden spezialisierte Agenten
Parallel dazu hat sich Open WebUI verändert.
Neben den bisherigen Profilen steht inzwischen mit KI-Stack Research ein spezialisierter Research Agent zur Verfügung.
Seine Aufgabe besteht nicht darin, einfach nur ein weiteres Prompt-Profil bereitzustellen. Er kombiniert mehrere Informationsquellen:
lokales Wissen aus RAG beziehungsweise Open-WebUI-Knowledge und aktuelle Informationen aus dem Web.
Die Websuche erfolgt weiterhin lokal kontrolliert über SearXNG.
Damit entsteht ein interessanter Mittelweg: Das eigentliche Sprachmodell läuft lokal über LM Studio, eigenes Wissen bleibt im lokalen RAG-System und für aktuelle Informationen kann gezielt eine Websuche durchgeführt werden.
Zusätzlich kann der isolierte Code Interpreter von Open WebUI verwendet werden.
Terminalzugriffe oder beliebige Extension-Tools gehören dagegen bewusst nicht zum Vertrag dieses Agenten.
Damit wird erstmals deutlicher zwischen einem allgemeinen Chatmodell und einem Agenten mit definierten Fähigkeiten und Grenzen unterschieden.
Knowledge-Binding ohne Konfigurationsverlust
Eine unscheinbare, technisch aber wichtige Änderung betrifft die Art, wie KI-Stack Open WebUI konfiguriert.
Frühere Provisioning-Ansätze haben häufig ein grundsätzliches Problem: Der Installer kennt einen gewünschten Zustand und schreibt diesen vollständig zurück. Einstellungen, die ein Benutzer anschließend direkt in der Oberfläche vorgenommen hat, können dadurch verschwinden.
Der aktuelle Agent-Pack-Ansatz unterscheidet deshalb zwischen verwalteten, zusammengeführten und zu erhaltenden Eigenschaften.
Vom Benutzer beziehungsweise von Open WebUI verwaltete Metadaten werden nicht einfach überschrieben.
Gleichzeitig kann der Research Agent dynamisch mit der vorgesehenen Knowledge Base verbunden werden.
Existiert diese Knowledge Base noch nicht, wird der Vorgang kontrolliert übersprungen, statt eine fehlerhafte oder halbfertige Konfiguration zu erzeugen.
Bei einem späteren Reconcile kann die Bindung anschließend hergestellt werden.
Das klingt zunächst nach einem Detail. Für einen Installer, der nicht nur einmal ausgeführt wird, sondern ein bestehendes System langfristig verwalten soll, ist genau dieses Verhalten jedoch entscheidend.
Die Websuche des Research Agents ist jetzt nachgewiesen
Mit 2.13.0 wurde ein Punkt abgeschlossen, der nach 2.12.0 noch offen war: der vollständige Nachweis der Websuche des Research Agents.
Dabei stellte sich heraus, dass weder SearXNG noch die Agentenkonfiguration oder das verwendete Sprachmodell die eigentliche Ursache der zuvor beobachteten Probleme waren.
Das Agentenprofil enthielt bereits die korrekten Fähigkeiten für Web Search. Auch Native Function Calling funktionierte.
Direkte Tool-Aufrufe über LM Studio konnten ebenfalls erfolgreich durchgeführt werden und SearXNG lieferte reale Suchergebnisse und Quellen.
Der entscheidende Unterschied lag in Open WebUI selbst.
Die interne Tool-Injektion für die eingebaute Websuche benötigt bei diesem Ausführungspfad eine nicht leere session_id. Fehlt sie, wird search_web dem Modell gar nicht erst als verfügbares Werkzeug angeboten.
Dadurch entstand ein Fehlerbild, das zunächst wie ein Problem des Agent Packs, des Modells oder der SearXNG-Anbindung aussah.
Tatsächlich waren diese Komponenten korrekt.
Der Research-Agent-Web-Search-Execution-Test konnte deshalb schließlich mit GO abgeschlossen werden.
Das ist für das Projekt ein wichtiger Unterschied: Die Websuche ist nicht nur konfiguriert oder anhand einzelner Komponenten theoretisch plausibel, sondern die komplette Kette wurde mit realen Quellen nachvollzogen.
Eigener Regressionstest für den Research Agent
Damit dieser Zustand nicht nur einmal funktioniert, gehört inzwischen auch ein eigener Test zum Projekt:
Test-KIStackResearchAgentWebSearch.ps1
Der Test überprüft die für die Research-Funktion relevanten Verträge und enthält neben den positiven Tests auch negative Kontrollfälle.
Zusätzlich wird geprüft, ob die Knowledge-Bindung mehrere Reconcile-Läufe übersteht.
Damit wird genau die Fehlerklasse abgedeckt, die bei einem weiterentwickelten KI-System besonders problematisch wäre: Einzelne Funktionen funktionieren nach der Installation, verschwinden aber nach einem späteren Update oder erneuten Integrationslauf.
Open WebUI und ComfyUI werden nicht mehr blind zurückgestuft
Auch beim Umgang mit den großen Anwendungen ist der Installer vorsichtiger geworden.
Für Open WebUI wurde der Greenfield-Referenzstand inzwischen auf 0.11.1 angehoben.
Bei ComfyUI bleibt der Greenfield-Referenzstand weiterhin bei v0.28.0. Gleichzeitig wurde ein vorhandenes v0.34.0 erfolgreich als unterstützte neuere Installation validiert.
Das bedeutet:
Die Referenzversion ist die Version, mit der eine neue Installation aufgebaut werden kann. Sie stellt aber keine künstliche Obergrenze dar.
Eine vorhandene neuere Version wird geprüft und – sofern sie weiterhin mit dem KI-Stack-Vertrag kompatibel ist – erhalten.
Genau diese Trennung ist notwendig, damit ein lokaler KI-Stack langfristig betreibbar bleibt.
Auch der Installer selbst wird reproduzierbar
Ein weiterer Schwerpunkt der letzten Versionen liegt weniger sichtbar unterhalb der eigentlichen Anwendungen.
Der Complete Installer wird inzwischen deterministisch gebaut.
Zum Release gehören neben dem eigentlichen ZIP auch eine SHA-256-Prüfsumme sowie eine SPDX-2.3-SBOM.
Dabei wird geprüft, dass die Prüfsummen innerhalb dieser Artefakte tatsächlich auf denselben Build verweisen.
Damit lässt sich nicht nur feststellen, welche Version installiert werden soll, sondern auch, ob das veröffentlichte Paket exakt dem getesteten Artefakt entspricht.
Diese Entwicklung ist mindestens genauso wichtig wie eine neue Benutzerfunktion.
Denn je mehr Komponenten ein Installer verwaltet, desto wichtiger wird die Frage, ob sich ein bestimmter Zustand später noch nachvollziehen und reproduzieren lässt.
Robustere Transaktionen und Rollback
Auch die Transaktionslogik wurde weiter verbessert.
Fehlgeschlagene Installations- oder Updatevorgänge sollen einen späteren Lauf nicht dauerhaft blockieren, sofern der vorherige Vorgang sauber zurückgerollt wurde und das Zielsystem wieder konsistent ist.
Mehrere Rollback- und Readback-Prüfungen wurden deshalb erweitert.
Das gilt unter anderem für Knowledge-Bindings.
Ein Rollback darf nicht nur melden, dass er erfolgreich war. Der anschließend gelesene Zustand muss diesen Erfolg ebenfalls bestätigen.
Damit verschiebt sich die Definition von „erfolgreich“ zunehmend von „das Skript lief ohne Fehler durch“ zu „der erwartete Zustand wurde anschließend tatsächlich nachgewiesen“.
Was 2.13.0 gegenüber 2.7.0 eigentlich verändert
Die sichtbarsten Anwendungen des KI-Stacks sind weitgehend dieselben geblieben:
LM Studio stellt lokale Sprachmodelle bereit.
Open WebUI bildet die zentrale Benutzeroberfläche.
ComfyUI übernimmt Bild- und Videogenerierung.
SearXNG stellt die lokale Websuche bereit.
RAG verbindet eigene Dokumente mit den Sprachmodellen.
Die eigentliche Veränderung liegt zwischen diesen Komponenten.
Aus einzelnen Installationsschritten ist zunehmend ein System mit definierten Zuständen, Abhängigkeiten, Reconcile-Regeln, Rollback-Verhalten und Tests entstanden.
2.7.0 konnte bereits einen funktionierenden lokalen KI-Stack bereitstellen.
2.13.0 beschäftigt sich stärker mit der schwierigeren Frage:
Wie bleibt dieser Stack auch nach Änderungen, Updates und erneuten Installationsläufen konsistent und reproduzierbar?
Genau darin liegt für mich derzeit der größte Fortschritt des Projekts.
Der aktuelle KI-Stack
Der grundlegende Aufbau bleibt weiterhin vollständig lokal:
Windows 11 → WSL2/Debian → LM Studio → Open WebUI → ComfyUI → SearXNG → RAG
Darauf entstehen inzwischen spezialisierte Funktionen und Agenten.
Der Research Agent kann eigenes Wissen aus dem RAG-System mit aktueller Webrecherche kombinieren. Bild- und Videogenerierung bleiben über ComfyUI angebunden. Gleichzeitig versucht der Installer zunehmend, vorhandene und funktionierende Installationen zu erhalten, anstatt sie bei jedem Versionswechsel neu aufzubauen.
Damit bewegt sich das Projekt langsam weg von einem reinen „KI-Installer“.
Das Ziel ist zunehmend ein lokal betreibbarer KI-Stack mit reproduzierbarer Installation, kontrollierten Updates und nachvollziehbaren Integrationsverträgen.
Und genau dieser Teil wird vermutlich auch die nächsten Versionen bestimmen.