Wissensbasis

Die Wissensbasis ist, was die Antworten des Agenten fundiert anfühlen lässt — das LLM muss nicht aus Trainingsdaten raten, weil es bei jedem Turn Ihre Runbooks, Ihre vergangenen Postmortems und Ihre Team-Dokumente durchsuchen kann.

Speicherform

Ein Vektor-Store, drei Quelltypen.

Quelltyp	Woher er kommt	Read-Only?
vault	Die eingebaute ongridio/vault Playbook-Sammlung (96 Markdown-Dokumente Stand 2026-05-29)	Ja
repo	Git-URLs, die Sie registrieren — öffentliche HTTPS oder SSH via Per-Repo-Identität	Nein (Settings editieren + Re-Sync)
upload	Direkte Uploads (md / txt / pdf / docx) via die /knowledge-Seite der SPA	Nein (Zeile editieren / löschen)
manual	Markdown via den Inline-Editor einfügen	Nein

Alle vier Typen teilen eine Qdrant-Collection (ongrid_knowledge) und ein Embedding-Modell. Suchtreffer geben das source_type-Payload-Feld zurück, damit die UI das richtige „aus Vault" / „aus Ihren Repos" Badge rendern kann.

ADR-028 — Wissensquellen, gestaffelt

Warum eine Collection: die Alternative (eine Collection pro Quelltyp) zwang das LLM, N Suchen pro Frage aufzurufen, um Abdeckung zu erhalten, und sprengte das Tool-Aufruf-Budget. Eine Collection + source_type-Filter erhält die gleiche Isolation mit einer Abfrage.

Der Qdrant-Client

Schmale Oberfläche, in internal/manager/biz/knowledge/usecase.go:62:

type QdrantClient interface {
    EnsureCollection(ctx context.Context, name string, dim int) error
    EnsurePayloadIndex(ctx context.Context, collection, field, schema string) error
    Upsert(ctx context.Context, collection string, points []qdrantx.Point) error
    DeleteByFilter(ctx context.Context, collection string, mustMatch map[string]any) error
    DeleteByID(ctx context.Context, collection string, id uint64) error
    GetPoints(ctx context.Context, collection string, ids []uint64) ([]qdrantx.SearchHit, error)
    Search(ctx context.Context, collection string, vector []float32, opts qdrantx.SearchOpts) ([]qdrantx.SearchHit, error)
    Scroll(ctx context.Context, collection string, opts qdrantx.ScrollOpts) (*qdrantx.ScrollResult, error)
}

In Produktion durch internal/pkg/qdrantx gestützt, in Tests fake-bar. Qdrant wird in der docker-compose ausgeliefert; externes Qdrant wird via ONGRID_QDRANT_URL unterstützt.

Der Vault

Der Vault ist ein öffentliches Git-Repository (keine Auth), das vorkuratierte Diagnose-Playbooks ausliefert. Abgedeckte Themen (Stand 2026-05-29):

• Netzwerk: DNS- / TCP- / TLS- / HTTP-Debugging-Rezepte.
• Kubernetes: Pod- / Node- / Kubelet-Symptom-zu-Ursache-Karten.
• Linux: Prozess- / Speicher- / Disk- / journald-Untersuchungspfade.
• Datenbank: MySQL Slow-Log-Triage, PostgreSQL Replication-Lag.
• Diagnose: 70+ symptom-gekeyte Playbooks.

ADR-029 fügte Cloud-Sync hinzu: der Manager pullt den neuesten Vault auf einem Schedule (Default 24h, konfigurierbar via die SPA-Settings) und re-embedded bei Änderungen. Der On-Disk-Checkout liegt unter /var/lib/ongrid/repos/<vault_id>/; die qdrant-Punkte sind source=vault getaggt, sodass ein Sync nur Vault-Punkte löscht, nie Ihre eigenen.

Behandeln Sie Vault nicht als Ihr Repo

Der Vault ist eine eingebaute Quelle — er erscheint nie auf der /knowledge/repos-CRUD-Seite. Der Code verwendet isBuiltinVault() / is_builtin, um dies zu gaten; substring-matchen Sie ongridio/vault nicht (siehe das wiederkehrende-Fallen-Feedback).

Eigene Repos

POST /v1/knowledge/repos mit einem { url, name }-Body registriert ein Git-Repository. Auf dem nächsten Sync-Tick:

1. git clone --depth=1 (oder git pull, wenn das Verzeichnis bereits existiert) in /var/lib/ongrid/repos/<id>/.
2. Durchläuft den Baum nach .md- / .txt- / .rst- / .yaml- / .yml- / .toml- / .json-Dateien.
3. Embedded jede Datei mit dem konfigurierten Embedding-Modell.
4. Ersetzt das Point-Set für dieses Repo (source=repo, repo_id=<id>) atomar.

SSH-Auth

Per-Repo-Identität, verwaltet über die ssh_identities-Tabelle und die /knowledge/identities-Seite der SPA. Die Repository-Zeile trägt KEIN Provider-Feld — die Identity-Tabelle ist die einzige Quelle der Git-Credentials (ADR-023).

GIT_SSH_COMMAND wird pro-Sync gesetzt, um auf die Schlüsseldatei der Identität zu zeigen, sodass jeder Repo-Clone seinen eigenen Schlüssel verwendet, ohne $HOME/.ssh/ zu verschmutzen.

HTTPS-Auth

Öffentliche HTTPS-Repos klonen unauthentifiziert. Private HTTPS-Auth ist geparkt: der ursprüngliche GitHub-PAT-Pfad wurde entfernt, als SSH die realistischen Use-Cases abdeckte. Bis ADR-018s RepoFetcher landet, verwenden Sie SSH für private.

Uploads

Die /knowledge/upload-Seite akzeptiert:

Format	Extraktor
.md, .txt	Roh-Lesen + Chunk
.pdf	docextract (internal/pkg/docextract)
.docx	docextract

Jeder Upload wird eine Zeile in knowledge_docs und ein Punkt in qdrant mit source=upload. Inline-Edit und Delete funktionieren pro Zeile aus dem „Organization knowledge"-Baum.

Suche

Das LLM bekommt ein query_knowledge-BaseTool — Schema in query_knowledge_basetool.go. Args: query, optionaler source_type-Filter, optionales top_k. Returns: eine Liste von {score, source, title, snippet, url?}-Treffern.

Der Coordinator-Persona wird angewiesen, dies früh für jede „wie mache ich"- / „warum passiert X"- / „was ist das Runbook für Y"-Frage aufzurufen — die Kosten einer Wissenssuche sind viel niedriger als die einer 5-Tool-Untersuchung, die auf derselben Antwort landet, die das Playbook bereits hatte.

Die Chat-UI exponiert auch einen Quick-Action-Button „Search knowledge", damit Operatoren denselben Index treffen können, ohne durch den Chat zu gehen.

Siehe auch

• Skills — query_knowledge ist eines der 18 gebridgten BaseTools, die in der Skill-Registry sichtbar gemacht werden.
• RCA — die Investigator-Persona, die Wissenssuche als First-Resort-Tool aufruft.
• Architektur — wo Qdrant im L1-Stack sitzt.