Monatsrückblick Oktober 2026 ist online!

[bloop]

Beitrag wurde mit KI erstellt und von Menschen korrigiert. Statistik und Zahlen sind aus KI Berichten.

Vor etwa einem halben Jahr hat @jey-cee sein iobroker-rag erstellt. Ich nutze den Ansatz seitdem regelmäßig in ioBroker sowie in VSCode und Claude zur Unterstützung bei der Adapter Entwicklung. In der Zwischenzeit habe ich das Projekt zu einer eigenen Implementierung weiterentwickelt.

ioBroker RAG

Zur Frage „Bringt RAG wirklich etwas?“

Ich „möchte“ zukünftig alles lokal verarbeiten: keine Frage, kein Skript und kein Log verlässt mein Netz. Dazu gehört, dass auch das ein Modell lokal läuft (mit Ollama auf einer RTX 4090). Lokale Modelle wissen über ioBroker deutlich weniger als die großen Cloud-Modelle, vor allem bei Skript-API, Rollen, io-package.json oder jsonConfig.
Genau diese Lücke soll das RAG schließen: Das Modell bekommt zu jeder Frage die passenden Stellen aus der offiziellen Doku und dem Quellcode.

• sources.json ist eine Allowlist. Nur die dort gelisteten öffentlichen Repos werden indexiert
• Indexierung läuft auf dem eigenen Rechner. Der Index wird nicht verteilt, jeder baut ihn selbst. Ergebnis sind derzeit rund 62.000 Dokument-Chunks.
• Bereitstellung als RAG-Server (REST + MCP).

Aufwand

	Wert
Index-Aufbau, Embeddings über Ollama auf RTX 4090	ca. 20 min
RAM / Disk für den Server	ca. 6Gb
Python	3.12
Antwortzeit Suche (mit Reranker)	ca. 3 s
Antwortzeit Suche (ohne Reranker)	ca. 0,2 s

Der Rebuild läuft bei mir wöchentlich per systemd-Timer nachts durch, damit die Doku aktuell bleibt.

Messung 1: Wie gut findet die Suche?

Gegen den laufenden Server habe ich zwei Fragesets ausgewertet. „Treffer@1“ heißt: Die erwartete Quelle steht auf Platz 1, „Treffer@5“: unter den ersten fünf. MRR ist die mittlere reziproke Rangposition (1,0 = immer Platz 1).

Set	Fragen	Treffer@1	Treffer@5	MRR	Median Antwortzeit
Doku-Fragen, mit Reranker	30	21	27	0,78	3,1 s
Doku-Fragen, ohne Reranker	30	14	27	0,63	0,2 s
Praxis-/Forumsfragen, mit Reranker	65	26	53	0,55	3,1 s

Erkenntnisse:

• Der Reranker verdoppelt fast die Top-1-Quote, kostet aber rund 3 Sekunden. Top-5 sortiert nur um.
• Bei typischen Forumsfragen gehen 12 von 65 komplett daneben.

Messung 2: Antworten mit und ohne RAG (lokales Modell)

Das ist der eigentlich interessante Teil. Setup:

• Antwortendes Modell: gemma4:26b-a4b-it-qat über Ollama auf der RTX 4090, einmal ohne und einmal mit den Top-5-Treffern aus dem RAG im Prompt.

• Bewertung: qwen3.8:27b als blinder Richter, bekam Frage, Antwort und die Doku-Referenz, ohne zu wissen, welche Variante er bewertet.
  Skala
  0 = falsch/erfunden,
  1 = teilweise richtig,
  2 = korrekt und vollständig.

• 12 Fragen, gemischt Deutsch/Englisch, aus Skript-Praxis und Adapter-Entwicklung.

#	Frage	ohne RAG	mit RAG
1	State in einem Skript mit ack setzen	1	2
2	subscribe auf State-Änderungen im JavaScript-Skript	0	2
3	Skript täglich zum Sonnenuntergang ausführen	1	2
4	Alle States eines Raums über $()-Selektor und enum	0	2
5	Eigenen Datenpunkt unter 0_userdata anlegen	0	2
6	Verzögertes setState und wieder abbrechen	0	2
7	Nachricht aus Skript an einen anderen Adapter senden	1	2
8	Bedeutung der Rolle level.temperature, welche Rollen gibt es	0	2
9	Pflichtfelder in io-package.json	0	2
10	Admin-Konfigseite mit jsonConfig definieren	0	2
11	Adapter im Latest-Repository veröffentlichen	0	2
12	Adapter mit VS Code debuggen	1	2
Zusammenfassung	ohne RAG	mit RAG
---	---	---
Punkte gesamt (max. 24)	4	24
korrekt (2)	0 von 12	12 von 12
falsch / erfunden (0)	8 von 12	0 von 12
Antwortzeit Median	21,2 s	9,5 s

Ohne RAG hat gemma4 keine einzige Frage vollständig richtig beantwortet, bei 8 von 12 hat es Funktionen oder Felder erfunden. Mit RAG waren alle 12 korrekt. Dass die Antworten mit RAG sogar schneller kamen, liegt daran, dass das Modell ohne Kontext deutlich länger „herumerzählt“.

Einschränkung, damit niemand das überinterpretiert: 12 Fragen sind keine große Studie, und die Fragen liegen alle im Bereich der offiziellen Doku. Bei den oben erwähnten Forumsthemen hilft das RAG weniger, weil die Quellen fehlen. Für meinen Alltag (Skripte, Adapter-Entwicklung, Objekt-Strukturen) ist der Unterschied aber genau so groß wie die Tabelle zeigt: Ohne RAG sind lokale Modelle für ioBroker-Fragen praktisch unbrauchbar, mit RAG sind sie auf Doku-Niveau.

Das anbinden an ein großes Cloud Modell bringt ebenfalls seine Vorteile.

Mich würde interessieren:

• Nutzt jemand noch ein lokales RAG für ioBroker?
• Gibt es Interesse an weiteren Quellen (z. B. Adapter-READMEs aus dem Latest-Repo)?
• Gibt es jemanden der mich bei dem Projekt unterstützen möchte?

[Bluefox]

@bloop Danke für die Vorstellung und vor allem für die Messungen. Dass gemma4 ohne Kontext bei 8 von 12 Fragen Funktionen erfindet, deckt sich mit dem, was ich bei kleinen lokalen Modellen sehe.

Hast du schon iobroker.ai-server + assistant + pi-agent ausprobiert? ai-server startet Ollama im Docker oder nutzt einen bestehenden Ollama-Server und stellt eine OpenAI-kompatible API bereit. Mit deiner 4090 wäre das Backend "External Ollama server" das richtige, NVIDIA im Docker-Container wird noch nicht unterstützt. Der assistant kann ein lokales LLM und pi-agent als Provider nutzen. Mich würde interessieren, ob dein RAG dort als zusätzliche Quelle über MCP Sinn ergibt und wie die Antworten damit im Vergleich aussehen.

Zu deiner Frage nach weiteren Quellen: Ja, die Adapter-READMEs halte ich für den wichtigsten nächsten Schritt. Die meisten Forumsfragen betreffen einen bestimmten Adapter und nicht die Skript-API oder io-package.json. Wahrscheinlich kommen deine 12 Fehlgriffe von 65 genau daher. Bei den Adaptern aus dem Latest-Repo sind die Lizenzen sehr unterschiedlich, das sollte in sources.json sauber mitlaufen. Interessant wären auch docs/ und die Changelogs, wo es sie gibt.

Zwei Fragen dazu:

• Wie lange braucht ein Rebuild, wenn du alle Adapter aus dem Latest-Repo aufnimmst? Ein inkrementelles Update (nur Repos mit neuem Commit) wäre dann vermutlich sinnvoller als ein wöchentlicher Komplett-Rebuild.
• Hast du einmal gemessen, wie groß der Unterschied bei einem großen Cloud-Modell mit und ohne RAG ist? Das wäre für viele hier interessanter, weil die meisten keine 4090 haben.

[bloop]

@Bluefox Die Punkte hab ich nun umgesetzt, Version 0.4.0: https://github.com/bloop-herbert-bot/ioBrokerRAG

• Adapter-Doku aus dem Latest-Repo: + Lizenz-Policy
• Inkrementeller Rebuild:

Adapter im Latest	indexiert	review (lokal)	nicht indexiert
839	819	24	20 (15 Lizenz, 5 bereits Kern)

Index und Build
(4 Kerne, 6 GB RAM, Embeddings über Ollama auf einer GPU)

	vorher (Kern)	nachher (Kern + Adapter)
Repositories	15	834
Chunks	61.903	67.660 (davon 28.494 aus Adapter-Repos)
Index auf Platte	551 MB	302 MB
Checkouts	2,3 GB	3,5 GB
Klonen + Chunken	–	29 min
Embedding	~20 min	27 min (42 Vektoren/s)
Vollbuild gesamt	–	59 min
RAM-Spitze	–	3,8 GB

Der Index wurde sogar kleiner, weil die englischen Adapter-READMEs vorher doppelt drin waren.

Die Tests folgen in den nächsten Tagen…

Wo bzw. in welchen Adapter würde deiner Meinung nach eine Anbindung Sinn machen?
Bisher hab ich die RAG hauptsächlich für die Adapterentwicklung mitlaufen lassen.
Die ganzen KI Anwendungen in ioBroker kommen für mich zu spät, hab ich auch ehrlicherweise nicht in aktiver Verwendung.

[Bluefox]

@bloop Das ging schnell, danke. 819 von 839 Adaptern bei einem Vollbuild unter einer Stunde ist gut. Mit dem inkrementellen Update ist das dann ja nur noch ein paar Minuten pro Nacht.

Eine Frage zu den Zahlen: Es sind mehr Chunks (67.660 statt 61.903), der Index ist aber von 551 auf 302 MB geschrumpft. Liegt das nur an den doppelten READMEs, oder hast du auch das Speicherformat bzw. das Embedding-Modell geändert?

Zur Anbindung: Am meisten bringt es meiner Meinung nach dort, wo Code entsteht, also im KI-Chat des javascript-Adapters. Dort hast du genau deinen Messfall: Skript-API, $()-Selektor, schedule, sendTo, Rollen. Gerade mit einem lokalen Modell erfindet der Chat dort sonst Funktionen. Wenn man vor der Anfrage die Top-5 aus deinem RAG in den Kontext gibt, wäre das wahrscheinlich die größte Verbesserung für die meisten Nutzer.

An zweiter Stelle kommt der KI-Assistent im Admin, bei Fragen wie "wie konfiguriere ich Adapter X" oder "was bedeutet dieser Logeintrag". Dafür sind jetzt die Adapter-READMEs wichtig.

Für die Adapterentwicklung bleibt dein bisheriger Weg (MCP in VS Code bzw. Claude) wohl der richtige. Dafür muss nichts in ioBroker passieren.

Was mir noch fehlt, um das einzuschätzen: Ist die REST-Schnittstelle stabil und dokumentiert (Request, Response, Felder wie Quelle und Lizenz)? Dann könnte man im javascript-Adapter eine optionale RAG-URL vorsehen. Wer keinen RAG-Server betreibt, merkt davon nichts.

Auf die Tests mit Cloud-Modell bin ich gespannt.