KI-Systeme: Self-Hosted Assistants, RAG und lokale Infrastruktur

Inhaltsverzeichnis

Die meisten lokalen KI-Einrichtungen beginnen mit einem Modell und einer Laufzeitumgebung.

Sie laden ein quantisiertes Modell herunter, starten es über Ollama oder eine andere Laufzeitumgebung und beginnen mit dem Prompting. Für experimentelle Zwecke ist dies mehr als ausreichend. Sobald Sie jedoch die reine Neugier überwinden – sobald Ihnen Speicher, Abrufqualität, Routing-Entscheidungen oder Kostentransparenz wichtig werden –, offenbart sich die Einfachheit dieser Herangehensweise als limitierend.

Dieser Cluster erkundet einen anderen Ansatz: Die Behandlung des KI-Assistenten nicht als einzelne Modellaufrufe, sondern als koordiniertes System.

Diese Unterscheidung mag auf den ersten Blick subtil erscheinen, verändert aber die Art und Weise, wie Sie über lokale KI nachdenken, vollständig.

KI-System-Orchestrierung mit lokalen LLMs, RAG und Speicherschichten

Was ist ein KI-System?

Ein KI-System ist mehr als nur ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung miteinander verbindet, um etwas zu schaffen, das sich wie ein kohärenter Assistent verhält.

Lokale Ausführung eines Modells ist Infrastrukturarbeit. Die Gestaltung eines Assistenten um dieses Modell herum ist Systemarbeit.

Wenn Sie unsere umfassenden Leitfäden zu folgenden Themen erkundet haben:

dann wissen Sie bereits, dass Inferenz nur eine Schicht des Stacks ist.

Der KI-System-Cluster sitzt auf diesen Schichten. Er ersetzt sie nicht – er kombiniert sie.

OpenClaw: Ein selbstgehostetes KI-Assistentensystem

OpenClaw ist ein Open-Source, selbstgehostetes KI-Assistentensystem, das darauf ausgelegt ist, über Messaging-Plattformen hinweg zu operieren, während es auf lokaler Infrastruktur läuft.

Auf praktischer Ebene:

  • Nutzt lokale LLM-Laufzeitumgebungen wie Ollama oder vLLM
  • Integriert den Abruf über indizierte Dokumente
  • Verwaltet Speicher über einzelne Sitzungen hinaus
  • Führt Werkzeuge und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Operiert innerhalb von Hardwarebeschränkungen

Es ist nicht nur eine Hülle um ein Modell. Es ist eine Orchestrierungsschicht, die Inferenz, Abruf, Speicher und Ausführung miteinander verbindet, um etwas zu schaffen, das sich wie ein kohärenter Assistent verhält.

Um es lokal auszuführen und die Einrichtung selbst zu erkunden, sehen Sie den OpenClaw-Quickstart-Leitfaden, der eine Docker-basierte Installation beschreibt, die entweder ein lokales Ollama-Modell oder eine cloud-basierte Claude-Konfiguration verwendet.

Für eine tiefere architektonische Erkundung, wie sich OpenClaw von einfacheren lokalen Einrichtungen unterscheidet, lesen Sie den OpenClaw-Systemüberblick.

Was KI-Systeme anders macht

Mehrere Eigenschaften machen KI-Systeme genauerer Betrachtung wert.

Modell-Routing als Designentscheidung

Die meisten lokalen Einrichtungen standardmäßig auf ein einzelnes Modell. KI-Systeme unterstützen die absichtliche Auswahl von Modellen.

Das wirft Fragen auf:

  • Sollten kleine Anfragen kleinere Modelle verwenden?
  • Wann rechtfertigt das Reasoning ein größeres Kontextfenster?
  • Was ist der Kostenunterschied pro 1.000 Tokens?

Diese Fragen verbinden sich direkt mit den Leistungskompromissen, die in dem LLM-Leistungsleitfaden diskutiert werden, und den Infrastrukturentscheidungen, die in dem LLM-Hosting-Leitfaden dargelegt sind.

KI-Systeme machen diese Entscheidungen sichtbar, anstatt sie zu verbergen.

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren den Dokumentabruf, aber nicht als einen simplen Schritt des „Einbettens und Suchens".

Sie erkennen an:

  • Die Chunk-Größe beeinflusst Recall und Kosten
  • Hybrid-Suche (BM25 + Vektor) kann reine dichte Abrufe übertreffen
  • Reranking verbessert die Relevanz auf Kosten der Latenz
  • Die Indexierungsstrategie beeinflusst den Speicherverbrauch

Diese Themen stimmen mit den tieferen architektonischen Überlegungen überein, die in dem RAG-Tutorial diskutiert werden.

Der Unterschied besteht darin, dass KI-Systeme den Abruf in einen lebendigen Assistenten einbetten, anstatt ihn als isolierte Demo zu präsentieren.

Speicher als Infrastruktur

Stateless-LLMs vergessen zwischen den Sitzungen alles.

KI-Systeme führen persistente Speicherschichten ein. Das wirft sofort Designfragen auf:

  • Was sollte langfristig gespeichert werden?
  • Wann sollte Kontext zusammengefasst werden?
  • Wie verhindert man eine Token-Explosion?
  • Wie indiziert man Speicher effizient?

Diese Fragen überschneiden sich direkt mit den datenbezogenen Überlegungen aus dem Dateninfrastruktur-Leitfaden.

Speicher hört auf, eine Funktion zu sein, und wird zu einem Speicherproblem.

Observability ist nicht optional

Die meisten lokalen KI-Experimente enden bei „es antwortet".

KI-Systeme machen es möglich zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardware-Auslastung
  • Durchsatzmuster

Dies verbindet sich natürlich mit den Überwachungsprinzipien, die in dem Observability-Leitfaden beschrieben werden.

Wenn KI auf Hardware läuft, sollte sie wie jede andere Arbeitslast messbar sein.

Wie sich die Nutzung anfühlt

Von außen mag ein KI-System immer noch wie eine Chat-Schnittstelle aussehen.

Unter der Oberfläche geschieht jedoch mehr.

Wenn Sie es bitten, einen lokal gespeicherten technischen Bericht zusammenzufassen:

  1. Es holt relevante Dokumentsegmente ab.
  2. Es wählt ein geeignetes Modell aus.
  3. Es generiert eine Antwort.
  4. Es protokolliert die Token-Nutzung und Latenz.
  5. Es aktualisiert den persistenten Speicher, falls notwendig.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist geschichtet.

Dieses geschichtete Verhalten ist das, was ein System von einer Demo unterscheidet.

Wo KI-Systeme im Stack passen

Der KI-System-Cluster befindet sich an der Schnittstelle mehrerer Infrastrukturschichten:

  • LLM-Hosting: Die Laufzeitschicht, in der Modelle ausgeführt werden (Ollama, vLLM, llama.cpp)
  • RAG: Die Abrufschicht, die Kontext und Verankerung liefert
  • Leistung: Die Messschicht, die Latenz und Durchsatz verfolgt
  • Observability: Die Überwachungsschicht, die Metriken und Kostenverfolgung bereitstellt
  • Dateninfrastruktur: Die Speicherschicht, die Speicher und Indexierung handhabt

Das Verständnis dieser Unterscheidung ist nützlich. Die eigene Ausführung macht den Unterschied deutlicher.

Für eine minimale lokale Installation mit OpenClaw, sehen Sie den OpenClaw-Quickstart-Leitfaden, der eine Docker-basierte Einrichtung beschreibt, die entweder ein lokales Ollama-Modell oder eine cloud-basierte Claude-Konfiguration verwendet.

Verwandte Ressourcen