RAG und Knowledge

Stand: 2026-05-20

Zielbild

Das Wissen für Codex, Claude Code, OpenCode und Open WebUI soll aus nachvollziehbaren Quellen kommen:

1. Gitea als versionierte Quelle.
2. MkDocs/Wiki als menschlich lesbares Frontend.
3. NetBox als produktives IPAM/DCIM.
4. Open WebUI Knowledge für Chat-RAG.
5. OpenCode Memory und Skills für Arbeitsregeln.

Projektordner

Gescannt wurde:

/Users/vinc32/Library/Mobile Documents/com~apple~CloudDocs/Codex Projekte

Dabei wurden .git, node_modules, virtuelle Umgebungen, __pycache__, Backups, temporäre Ordner und offensichtliche Secret-Dateien ausgeschlossen.

Projektordner	RAG-relevante Textdateien
Lanstyle	805
TecMed	654
TecMed_Enterprise Architecture	20
SMS	1455
SGJ	1682
SGO	71
Radius Server Schulen	2
Hauck	4
Metze	60
DRK_MTL	0
Speed	0
Netzwerkdiagram	238
Netzwerktester	197
Lanstyle_Intern_Website	92
Lexware Automation	14
Smarthome_Allerstedt	187
Privat	35

Empfohlene Struktur

Pro Kunde sollte ein eigenes Repository entstehen:

• dokumentation
• automationen
• configs
• optional reports

RAG-tauglich sind vor allem Markdown, YAML, JSON, CSV, PowerShell und Shell-Skripte. Binärdateien, Exporte, Backups und temporäre Artefakte sollten nicht direkt indexiert werden.

Zugriffsmodell

• Maximilian Eberhardt darf alle Kundenorganisationen bearbeiten.
• Andere bestehende Benutzer bearbeiten nur eigene Unternehmen.
• Marcel Hampel, René Kulcsar und Max Rothe sollen Zugriff auf Schulorganisationen erhalten.
• Marcel Hampel soll zusätzlich Zugriff auf TecMed erhalten.

Bis E-Mail-Adressen und Gitea-Usernamen der neuen Benutzer feststehen, werden keine Konten erzeugt.

Open WebUI Knowledge

Empfohlen:

• pro Kunde eine Knowledge Collection
• keine Secrets, Passwörter, private Keys oder vollständigen Dumps hochladen
• bevorzugt aus Gitea/MkDocs generierte, bereinigte Markdown-Dokumente verwenden
• Embeddings über nomic-embed-text:latest

OpenCode

OpenCode nutzt lokale Memory-Dateien und Skills. Für produktive Kundenarbeit gilt:

• erst Kundenkontext erkennen
• dann Gitea/NetBox/Wiki prüfen
• danach Änderungen mit Backup und Git-Diff durchführen
• keine Kundenkontexte vermischen

Knowledge-Pipeline

Vorbereitete maschinenlesbare Konfiguration:

• agent-runtime/configs/knowledge-pipeline.yaml

Grundregeln:

• Quelle ist bevorzugt Gitea/MkDocs.
• NetBox wird fuer technische Fakten referenziert, nicht blind in RAG kopiert.
• Vaultwarden-Inhalte werden nie indexiert.
• Kundenkontexte werden getrennt verarbeitet.
• Binarys, Backups, Dumps, .env, Keys und Token-Dateien werden ausgeschlossen.

Hermes Memory Integration

Seit 2026-05-30 gibt es zusätzlich eine kuratierte Obsidian-Quelle:

• Vault: obsidian/lanstyle-vault
• Indexer: agent-runtime/scripts/ingest-obsidian-to-qdrant.py
• Query-Test: agent-runtime/scripts/query-obsidian-memory.py
• Qdrant Collection: lanstyle_obsidian_memory
• Embedding-Modell: lanstyle/embed über LiteLLM

Der Lanstyle AI Gateway nutzt diese Collection als Retrieval-Kontext für den Nous Hermes Core. Obsidian bleibt menschlich pflegbar, Qdrant ist nur die semantische Suchschicht. Secrets werden weder in Obsidian noch in Qdrant abgelegt.

Details: Hermes Knowledge und Memory