vector ping

vector ping prüft, ob der konfigurierte Embedding-Service erreichbar ist und ob das vorgesehene Modell dort geladen ist. Reine Diagnose — kein Index wird angefasst, keine Datei mutiert.

Wofür ist das?

Drei Szenarien sind die typischen Aufrufer:

Erst-Setup einer Apparat-Installation. Nachdem docker compose up -d durchgelaufen ist, sagt dir vector ping in einer Zeile, ob die Schicht-2-Pipe steht oder ob noch ein ollama pull … fehlt.
Diagnose eines stillen Ausfalls. Wenn die semantische Suche plötzlich keine Treffer mehr liefert, lokalisiert vector ping das Problem zuverlässig auf eine der drei Stellen — Service down, Modell weg oder beides okay.
Nicht-interaktive Skripte. Die Exit-Codes sind so geschnitten, dass ein Supervisor-Skript automatisch entscheiden kann, ob es retryen, warten oder abbrechen soll.

Aufruf

apparat vector ping

Das Kommando hat keine Optionen. Endpoint und Modellname kommen aus den Umgebungsvariablen APPARAT_EMBEDDING_ENDPOINT und APPARAT_EMBEDDING_MODEL.

Beispielausgaben

Alles in Ordnung:

✅ Service reachable.
  Available models:
    - jina/jina-embeddings-v2-base-de:latest
✅ Configured model is loaded.

Service erreichbar, Modell fehlt:

✅ Service reachable.
  Available models:
    - some-other-model:latest
⚠ Configured model is not loaded.
  Model "jina/jina-embeddings-v2-base-de" not loaded. Run: docker compose exec ollama ollama pull jina/jina-embeddings-v2-base-de

Service unerreichbar:

❌ Service unreachable.
  Connection to http://ollama:11434 failed: …

Exit-Codes

Code	Bedeutung
0	Service erreichbar und konfiguriertes Modell geladen.
1	Service unerreichbar (Container nicht gestartet, Netz blockiert, Endpoint fehlerhaft konfiguriert).
2	Service erreichbar, aber das konfigurierte Modell ist nicht geladen. Das Detail aus der Ausgabe enthält den passenden `ollama pull …`-Befehl.

Die Trennung zwischen 1 und 2 macht den Unterschied zwischen Infrastruktur-Problem (Code 1) und Setup-Lücke (Code 2) sichtbar — relevant für Monitoring-Skripte und für die Entscheidung, ob ein Pull oder ein Container-Neustart die Lösung ist.

Konfiguration

Umgebungsvariable	Bedeutung	Default
`APPARAT_EMBEDDING_ENDPOINT`	Basis-URL der Ollama-API. Wird intern um `/api/tags` ergänzt.	`http://ollama:11434` (im Container)
`APPARAT_EMBEDDING_MODEL`	Modellname, der erwartet wird. `:latest`-Suffix ist optional.	`jina/jina-embeddings-v2-base-de`
`APPARAT_EMBEDDING_TIMEOUT`	Timeout pro HTTP-Aufruf in Sekunden.	`30`

Auf dem Host (außerhalb des Containers) zeigt http://ollama:11434 ins Leere, weil dort kein DNS-Eintrag für ollama existiert. In einer lokalen .env setzt du den Endpoint dann auf http://localhost:11434, falls du Ollama direkt auf dem Host installiert hast.

Was nebenbei wichtig ist

vector ping ist eine reine Diagnose: es prüft Erreichbarkeit und Modell-Liste, lädt aber keine Modelle nach (der ollama pull-Befehl in der Ausgabe ist ein Vorschlag, kein Aufruf) und macht keinen echten Embedding-Aufruf. Ob das Modell tatsächlich Vektoren produziert, zeigt sich beim ersten produktiven Lauf — typischerweise vector rebuild oder entity search --semantic. Der Vault selbst wird nicht angefasst.