KI-Systeme: Selbstgehostete Assistenten, RAG und lokale Infrastruktur

Inhaltsverzeichnis

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

Sie laden ein quantisiertes Modell herunter, starten es über Ollama oder eine andere Laufzeitumgebung und beginnen mit der Eingabe von Prompts. Für Experimente ist das mehr als ausreichend. Doch sobald Sie über reine Neugier hinausgehen – sobald Sie sich um Speicher, die Qualität der Abrufung, Routing-Entscheidungen oder Kostentransparenz kümmern –, beginnen die Grenzen dieser Einfachheit sichtbar zu werden.

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

Diese Unterscheidung mag zunächst subtil erscheinen, verändert jedoch grundlegend, wie Sie über lokale KI nachdenken.

Orchestrierung von KI-Systemen 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, Abrufung, Speicher und Ausführung zu etwas verbindet, das sich wie ein kohärenter Assistent verhält.

Ein Modell lokal auszuführen ist Infrastrukturarbeit. Einen Assistenten um dieses Modell herum zu gestalten, ist Systemarbeit.

Wenn Sie unsere umfassenderen 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 selbst gehostetes KI-Assistenten-System

OpenClaw ist ein quelloffener, selbst gehosteter KI-Assistent, der darauf ausgelegt ist, über Messaging-Plattformen hinweg zu arbeiten, während er auf lokaler Infrastruktur läuft.

Auf praktischer Ebene bedeutet dies:

  • Nutzt lokale LLM-Laufzeitumgebungen wie Ollama oder vLLM
  • Integriert die Abrufung über indizierte Dokumente
  • Verwaltet Speicher über eine einzelne Sitzung hinaus
  • Führt Tools und Automatisierungsaufgaben aus
  • Kann instrumentiert und beobachtet werden
  • Arbeitet innerhalb von Hardwarebeschränkungen

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

Einstieg und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeitumgebung – durch Hinzufügen von Speicher-Backends, Modell-Providern, Kommunikationskanälen, Web-Tools und Beobachtbarkeit. Skills erweitern das Agenten-Verhalten – sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beide zu kombinieren, geformt um die tatsächlichen Nutzer des Systems.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

Der Hermes Agent ist ein selbst gehosteter, modellagnostischer Assistent, der auf persistenter Operation fokussiert ist: Er kann als lang laufender Prozess ausgeführt werden, Tools über konfigurierbare Backends ausführen und Workflows über Zeit durch Speicher und wiederverwendbare Skills verbessern.

Auf praktischer Ebene ist Hermes nützlich, wenn Sie Folgendes wünschen:

  • Einen terminal-first-Assistenten, der auch eine Brücke zu Messaging-Apps schlagen kann
  • Provider-Flexibilität durch OpenAI-kompatible Endpunkte und Modellwechsel
  • Tool-Ausführungsgrenzen via lokalen und gesandwichteten Backends
  • Day-Two-Betrieb mit Diagnostik, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen – jedes mit eigener Konfiguration, Geheimnissen, Speichern, Sitzungen, Skills und Status – was Profile zur eigentlichen Einheit des Produktionsbesitzes macht, nicht den einzelnen Skill.

Persistente Kenntnisse und Speicher

Einige Probleme werden nicht allein durch ein größeres Kontextfenster gelöst – sie benötigen persistente Kenntnisse (Graphen, Ingestion-Pipelines) und Agenten-Speicher-Plugins (Honcho, Mem0, Hindsight und ähnliche Backends), die in Assistenten wie Hermes oder OpenClaw integriert sind.

Was KI-Systeme unterscheidet

Mehrere Merkmale machen KI-Systeme wert, genauer untersucht zu werden.

Modell-Routing als Design-Entscheidung

Die meisten lokalen Setups standardisieren auf ein Modell. KI-Systeme unterstützen die bewusste Auswahl von Modellen.

Dadurch entstehen Fragen:

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

Diese Fragen hängen direkt mit den in dem LLM-Leistungsleitfaden diskutierten Leistungskompromissen und den in dem LLM-Hosting-Leitfaden umrissenen Infrastruktur-Entscheidungen zusammen.

KI-Systeme machen diese Entscheidungen sichtbar, statt sie zu verstecken.

Abrufung wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren die Dokumentabrufung, aber nicht als simplen Schritt des „Einbetten und Suchens“.

Sie erkennen an:

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

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

Der Unterschied besteht darin, dass KI-Systeme die Abrufung in einen lebendigen Assistenten einbetten, anstatt sie 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 Design-Fragen auf:

  • Was sollte langfristig gespeichert werden?
  • Wann sollte Kontext zusammengefasst werden?
  • Wie verhindern Sie Token-Explosion?
  • Wie indizieren Sie Speicher effizient?

Diese Fragen überschneiden sich direkt mit den Daten-Schicht-Überlegungen aus dem Daten-Infrastruktur-Leitfaden. Für den Hermes Agent speziell – begrenzter 2-Datei-Speicher, Prefix-Caching, externe Plugins – beginnen Sie mit Hermes Agent Speicher-System und dem cross-framework Vergleich Vergleich der Agenten-Speicher-Provider. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Kenntnis-Schicht-Leitfäden auf.

Speicher hört auf, ein Feature zu sein, und wird zu einem Speicherproblem.

Beobachtbarkeit ist keine Option

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

KI-Systeme ermöglichen die Beobachtung von:

  • Token-Nutzung
  • Latenz
  • Hardware-Auslastung
  • Durchsatzmustern

Dies verbindet sich natürlich mit den Monitoring-Prinzipien, die in dem Beobachtbarkeits-Leitfaden beschrieben werden.

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

Wie es sich anfühlt, sie zu nutzen

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

Unter der Oberfläche passiert jedoch mehr.

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

  1. Es ruft relevante Dokumentsegmente ab.
  2. Es wählt ein geeignetes Modell aus.
  3. Es generiert eine Antwort.
  4. Es zeichnet Token-Nutzung und Latenz auf.
  5. Es aktualisiert den persistenten Speicher, falls erforderlich.

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 sitzt 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 Grounding bereitstellt
  • Leistung: Die Messschicht, die Latenz und Durchsatz verfolgt
  • Beobachtbarkeit: Die Monitoring-Schicht, die Metriken und Kostentracking bereitstellt
  • Daten-Infrastruktur: Die Speicherschicht, die Speicher und Indizierung handhabt

Das Verständnis dieser Unterscheidung ist nützlich. Selbst das Ausführen macht den Unterschied klarer.

Für eine minimale lokale Installation mit OpenClaw sehen Sie den OpenClaw Quickstart-Leitfaden, der eine Docker-basierte Einrichtung entweder mit einem lokalen Ollama-Modell oder einer cloud-basierten Claude-Konfiguration durchgeht.

Wenn Ihr Setup von Claude abhängt, klärt diese Richtlinie für Agent-Tools, warum API-Abrechnung nun für dritte OpenClaw-Workflows erforderlich ist.

Verwandte Ressourcen

KI-Assistenten-Leitfäden:

Infrastrukturschichten:

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.