AI-systemen: zelfgehoste assistenten, RAG en lokale infrastructuur

Inhoud

De meeste lokale AI-opstellingen beginnen met een model en een runtime.

Je downloadt een gekwantiseerd model, start het via Ollama of een andere runtime en begint met prompten. Voor experimenteel werk is dit meer dan genoeg. Maar zodra je verder gaat dan nieuwsgierigheid — zodra je ook rekening moet houden met geheugen, de kwaliteit van ophaling, routingbeslissingen of kostenbewustzijn — begint de eenvoud de grenzen te tonen.

Deze cluster verkent een andere aanpak: de AI-assistent behandelen niet als een enkel modelaanroep, maar als een gecoördineerd systeem.

Dat onderscheid lijkt op het eerste gezicht subtiel, maar het verandert volledig hoe je denkt over lokale AI.

Orkestratie van AI-systemen met lokale LLM’s, RAG en geheugenniveaus


Wat is een AI-systeem?

Een AI-systeem is meer dan alleen een model. Het is een orkestratieniveau dat inferentie, ophaling, geheugen en uitvoering verbindt tot iets dat zich gedraagt als een samenhangende assistent.

Lokaal een model draaien is infrastructuurwerk. Een assistent ontwerpen rondom dat model is systeemwerk.

Als je onze bredere gidsen hebt verkend over:

dan weet je al dat inferentie slechts één laag van de stack is.

De AI-systemen-cluster rust bovenop die lagen. Het vervangt ze niet — het combineert ze.

Voor een dwarsdoorsnede van hoe die lagen samenwerken in productie-assistenten — LLM, geheugen, gereedschap, routing en observabiliteit, met OpenClaw en Hermes als referentiesystemen — zie AI-assistentenarchitectuur: LLM, geheugen, gereedschap, routing, observabiliteit.


OpenClaw: Een zelfgehost AI-assistentsysteem

OpenClaw is een open-source, zelfgehoste AI-assistent die is ontworpen om te werken via verschillende berichtplatforms terwijl hij draait op lokale infrastructuur.

Praktisch gezien:

  • Maakt gebruik van lokale LLM-runtimes zoals Ollama of vLLM
  • Integreert ophaling van geïndexeerde documenten
  • Behoudt geheugen buiten een enkele sessie om
  • Voert gereedschappen en automatiseringstaken uit
  • Kan worden instrumenteerd en gemonitord
  • Werkt binnen hardwarebeperkingen

Het is niet slechts een wrapper rondom een model. Het is een orkestratieniveau dat inferentie, ophaling, geheugen en uitvoering verbindt tot iets dat zich gedraagt als een samenhangende assistent.

Aan de slag en architectuur:

Context en analyse:

OpenClaw uitbreiden en configureren:

Plugins breiden de OpenClaw-runtime uit — toevoegen van geheugenbackends, modelproviders, communicatiekanalen, webgereedschap en observabiliteit. Vaardigheden (skills) breiden agentgedrag uit — definiëren hoe en wanneer de agent die capaciteiten gebruikt. Productieconfiguratie betekent het combineren van beide, gevormd rondom wie het systeem daadwerkelijk gebruikt.


Hermes: Een persistente agent met vaardigheden en gereedschapssandboxing

Hermes Agent is een zelfgehoste, model-onafhankelijke assistent gericht op persistente operatie: hij kan draaien als een langlopend proces, gereedschap uitvoeren via configureerbare backends en workflows verbeteren door de tijd heen via geheugen en herbruikbare vaardigheden.

Praktisch gezien is Hermes nuttig als je wilt:

  • Een terminal-first assistent die ook kan bruggen naar bericht-apps
  • Providerflexibiliteit via OpenAI-compatibele endpoints en modelwisseling
  • Gereedschapuitvoeringsgrenzen via lokale en gesandboxde backends
  • Dag-twee operaties met diagnostiek, logs en configuratie-hygiëne

Hermes-profielen zijn volledig geïsoleerde omgevingen — elk met eigen configuratie, geheimen, geheugens, sessies, vaardigheden en status — waardoor profielen de echte eenheid van productie-eigendom vormen, niet de individuele vaardigheid.


Persistent kennis en geheugen

Sommige problemen worden niet opgelost door alleen maar een grotere contextvenster — ze hebben persistent kennis (grafieken, ingestiepipelines) en agentgeheugenplugins (Honcho, Mem0, Hindsight en vergelijkbare backends) nodig die zijn aangesloten op assistenten zoals Hermes of OpenClaw.


MCP: Model Context Protocol Servers

Het Model Context Protocol (MCP) is een open standaard geïntroduceerd door Anthropic voor het verbinden van AI-taalmodellen met externe gegevensbronnen, gereedschappen en systemen. Het lost het N×M-integratieprobleem op door een universele interface te bieden — denk er aan als een USB-C-poort voor AI-applicaties. Door MCP-servers te bouwen, kun je AI-assistenten uitbreiden met custom integraties voor bestanden, databases, API’s en aanroepbare gereedschappen, met behulp van een eenvoudig JSON-RPC-gebaseerd protocol over stdio of HTTP.

  • MCP Server in Go — protocolarchitectuur, JSON-RPC-berichtstructuur, capaciteitsonderhandeling, officiële Go SDK en een stap-voor-stap tutorial voor het bouwen van MCP-servers in Go
  • MCP Servers in Python Bouwen — praktische Python-implementatiegids die webzoek- en scraping-MCP-servers dekt, stdio- en SSE-transporten, en Claude Desktop-integratie

Wat AI-Systemen Verschillend Maakt

Verschillende kenmerken maken AI-systemen de moeite waard om nader te bestuderen.

Modelrouting als Ontwerpkeuze

De meeste lokale opstellingen standaardiseren op één model. AI-systemen ondersteunen het intentioneel selecteren van modellen.

Dat introduceert vragen:

  • Moeten kleine verzoeken kleinere modellen gebruiken?
  • Wanneer rechtvaardigt redeneren een groter contextvenster?
  • Wat is het kostenverschil per 1.000 tokens?

Deze vragen verbinden zich direct met de prestatieafwegingen besproken in de LLM-prestatiegids en de infrastructuurbeslissingen geschetst in de LLM-hostinggids.

AI-systemen maken die beslissingen zichtbaar in plaats van ze te verbergen.

Ophaling Wordt Behandeld als een Evoluerend Component

AI-systemen integreren documentophaling, maar niet als een simplistische “embed en zoek”-stap.

Ze erkennen:

  • Chunk-grootte beïnvloedt recall en kosten
  • Hybride zoektocht (BM25 + vector) kan beter presteren dan pure dense ophaling
  • Reranking verbetert relevantie ten koste van latentie
  • Indexeringsstrategie beïnvloedt geheugenconsumptie

Deze thema’s sluiten aan bij de diepere architectuurbezwaren besproken in de RAG-tutorial.

Het verschil is dat AI-systemen ophaling inbedden in een levende assistent in plaats van het te presenteren als een geïsoleerde demo.

Geheugen als Infrastructuur

Stateless LLM’s vergeten alles tussen sessies.

AI-systemen introduceren persistente geheugenniveaus. Dat roept onmiddellijk ontwerpvragen op:

  • Wat moet op lange termijn worden opgeslagen?
  • Wanneer moet context worden samengevat?
  • Hoe voorkom je token-explosie?
  • Hoe indexeer je geheugen efficiënt?

Deze vragen snijden direct door data-laagoverwegingen uit de data-infrastructuurgids. Voor Hermes Agent specifiek — begrensde twee-bestanden geheugen, prefix-caching, externe plugins — begin met Hermes Agent Geheugensysteem en de cross-framework vergelijking Agentgeheugenproviders vergeleken. De AI Systems Memory hub lijst gerelateerde Cognee- en kennislaaggidsen op.

Geheugen stopt met een feature te zijn en wordt een opslagprobleem.

Observabiliteit is Niet Optioneel

De meeste lokale AI-experimenten stoppen bij “het antwoordt”.

AI-systemen maken het mogelijk om te observeren:

  • Tokengebruik
  • Latentie
  • Hardwarebenutting
  • Doorstroompatronen

Dit sluit natuurlijk aan bij de monitoringsprincipes beschreven in de observabiliteitsgids.

Als AI op hardware draait, moet het meetbaar zijn als elke andere workload.


Hoe het Voelt om te Gebruiken

Van buitenaf kan een AI-systeem er nog steeds uitzien als een chatinterface.

Onder het oppervlak gebeurt er meer.

Als je het vraagt om een technisch rapport lokaal opgeslagen samen te vatten:

  1. Het haalt relevante documentsegmenten op.
  2. Het selecteert een passend model.
  3. Het genereert een antwoord.
  4. Het registreert tokengebruik en latentie.
  5. Het werkt persistent geheugen bij indien nodig.

De zichtbare interactie blijft eenvoudig. Het systeemgedrag is gelaagd.

Dat gelaagde gedrag is wat een systeem onderscheidt van een demo.


Waar AI-Systemen in de Stack Passen

De AI-Systemen-cluster bevindt zich op het snijpunt van verschillende infrastructuurlagen:

  • LLM Hosting: De rtlayer waar modellen worden uitgevoerd (Ollama, vLLM, llama.cpp)
  • RAG: De ophalingslaag die context en grondslag biedt
  • Prestaties: De meetlaag die latentie en doorstroom bijhoudt
  • Observabiliteit: De monitoringslaag die metrics en kostenvervolging biedt
  • Data Infrastructuur: De opslaglaag die geheugen en indexering afhandelt

Het begrijpen van dat onderscheid is nuttig. Zelf draaien maakt het verschil duidelijker.

Voor een minimale lokale installatie met OpenClaw, zie de OpenClaw quickstart handleiding, die doorloopt een Docker-gebaseerde setup met behulp van een lokaal Ollama-model of een cloudgebaseerde Claude-configuratie.

Als je opstelling afhankelijk is van Claude, dit beleidswijziging voor agentgereedschappen verklaart waarom API-facturatie nu vereist is voor third-party OpenClaw-workflows.


Gerelateerde Bronnen

MCP servers:

AI-assistenten gidsen:

Infrastructuurlagen:

Abonneren

Ontvang nieuwe berichten over systemen, infrastructuur en AI-engineering.