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 dem Prompting. Für Experimente reicht das mehr als aus. Doch sobald Sie über reine Neugier hinausgehen – sobald Ihnen Speicher, Abrufqualität, Routing-Entscheidungen oder Kostenbewusstheit wichtig werden –, zeigen sich die Grenzen dieser Einfachheit.

Dieser Cluster erkundet einen anderen Ansatz: Die KI-Assistentin nicht als einzelne Modellaufrufe zu behandeln, sondern als koordiniertes System.

Diese Unterscheidung mag anfangs subtil erscheinen, aber sie verändert Ihre Sicht auf lokale KI grundlegend.

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 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:

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

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

OpenClaw: Ein selbst gehostetes KI-Assistenten-System

OpenClaw ist ein Open-Source, 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:

  • Nutzt lokale LLM-Laufzeiten wie Ollama oder vLLM
  • Integriert den Abruf über indizierte Dokumente
  • Behält 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, Abruf, Speicher und Ausführung zu etwas verbindet, das sich wie ein kohärenter Assistent verhält.

Erste Schritte und Architektur:

Kontext und Analyse:

Erweiterung und Konfiguration von OpenClaw:

Plugins erweitern die OpenClaw-Laufzeit – sie fügen Speicher-Backends, Modellprovider, Kommunikationskanäle, Web-Tools und Observability hinzu. Skills erweitern das Agenten-Verhalten – sie definieren, wie und wann der Agent diese Fähigkeiten nutzt. Produktionskonfiguration bedeutet, beides zu kombinieren, geformt um die Personen, die das System tatsächlich nutzen.

Hermes: Ein persistenter Agent mit Skills und Tool-Sandboxing

Hermes Agent ist ein selbst gehosteter, modellagnostischer Assistent, der auf persistentem Betrieb fokussiert ist: Er kann als langlebiger Prozess laufen, Tools über konfigurierbare Backends ausführen und Workflows im Laufe der Zeit durch Speicher und wiederverwendbare Skills verbessern.

Auf praktischer Ebene ist Hermes nützlich, wenn Sie möchten:

  • Einen terminalbasierten Assistenten, der auch in Messaging-Apps überbrücken kann
  • Provider-Flexibilität durch OpenAI-kompatible Endpunkte und Modellschaltung
  • Tool-Ausführungsgrenzen via lokaler und sandboxter Backends
  • Day-Two-Betrieb mit Diagnosen, Logs und Konfigurationshygiene

Hermes-Profile sind vollständig isolierte Umgebungen – jedes mit eigener Konfiguration, Geheimnissen, Speichern, Sitzungen, Skills und Status – wodurch Profile die echte Einheit des Produktionsbesitzes sind, nicht der einzelne 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 eingewoben sind.

  • KI-Systeme Speicher-Hub — Umfang des Speicher-Subclusters plus Links zu Cognee-Leitfäden und Stack-Kontext
  • Agenten-Speicher-Provider im Vergleich — vollständiger Vergleich von Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover und Supermemory für Hermes-ähnliche Integrationen

Was KI-Systeme unterscheidet

Mehrere Merkmale machen KI-Systeme näher wert, genauer zu untersuchen.

Modell-Routing als Design-Entscheidung

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

Das führt zu Fragen:

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

Diese Fragen verbinden sich direkt mit den in dem LLM-Leistungsleitfaden diskutierten Performance-Kompromissen und den in dem LLM-Hosting-Leitfaden umrissenen Infrastruktur-Entscheidungen.

KI-Systeme bringen diese Entscheidungen an die Oberfläche, statt sie zu verstecken.

Abruf wird als sich entwickelnde Komponente behandelt

KI-Systeme integrieren den Dokumentenabruf, aber nicht als simplen „embed and search“-Schritt.

Sie erkennen an:

  • Chunk-Größe beeinflusst Recall und Kosten
  • Hybrid Search (BM25 + Vektor) kann reinem Dense Retrieval überlegen sein
  • Reranking verbessert die Relevanz auf Kosten der Latenz
  • Indexierungsstrategie beeinflusst den Speicherverbrauch

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

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

Zustandslose LLMs vergessen zwischen 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 indexieren Sie Speicher effizient?

Diese Fragen überschneiden sich direkt mit datenschichtbezogenen Überlegungen aus dem Dateninfrastruktur-Leitfaden. Für Hermes Agent speziell – begrenzter zwei-Datei-Speicher, Prefix-Caching, externe Plugins – beginnen Sie mit Hermes Agent Speichersystem und dem cross-framework Vergleich Agenten-Speicher-Provider im Vergleich. Der KI-Systeme Speicher-Hub listet verwandte Cognee- und Knowledge-Layer-Leitfäden auf.

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

Observability ist keine Option

Die meisten lokalen KI-Experimente hören bei „es antwortet“ auf.

KI-Systeme ermöglichen es zu beobachten:

  • Token-Nutzung
  • Latenz
  • Hardware-Nutzung
  • Throughput-Muster

Dies verbindet sich natürlich mit den in dem Observability-Leitfaden beschriebenen Monitoring-Prinzipien.

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

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 mehr.

Wenn Sie 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 nötig.

Die sichtbare Interaktion bleibt einfach. Das Systemverhalten ist geschichtet.

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

Wo KI-Systeme im Stack sitzen

Der KI-Systeme-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
  • Performance: Die Messschicht, die Latenz und Throughput verfolgt
  • Observability: Die Monitoring-Schicht, die Metriken und Kostenverfolgung bietet
  • Dateninfrastruktur: Die Speicherschicht, die Speicher und Indizierung handhabt

Dieses Unterscheidungsmerkmal zu verstehen ist nützlich. Es selbst auszuführen macht den Unterschied klarer.

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

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

Verwandte Ressourcen

KI-Assistenten-Leitfäden:

Infrastrukturschichten:

Abonnieren

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