api Schnittstelle

Eine gespeicherte Konfiguration mit einem Kommentar aufrufen und ihr Urteil zurückbekommen.

terminal Controller-API

Andere Systeme rufen eine gespeicherte Konfiguration über den Controller auf, ohne diese Oberfläche zu öffnen. Die Adressen folgen der Basis-URL, die unter Infrastruktur gesetzt ist.

open_in_new Swagger UI öffnen Den Aufruf ausprobieren, Schemas lesen, Antworten direkt im Browser sehen. data_object OpenAPI-Beschreibung Die maschinenlesbare Beschreibung als JSON, etwa für einen Client-Generator.

Der Controller muss dafür laufen (run_api.ps1 / run_api.sh).

Der Aufruf

POST

Im Rumpf steht nur der Kommentar:

{"comment": "Text des Kommentars"}

Modell und Sampling werden nicht mitgeschickt: Sie gehören zum ausführenden Baustein, dem Baustein der Konfiguration, der das Moderationsergebnis speist, und werden unter Konfiguration in seinem Editor gewählt. Ein Standardmodell gibt es nicht: Hat die Konfiguration keinen solchen Baustein oder nennt er kein Modell, antwortet der Aufruf mit 409 (no_exec_baustein bzw. exec_no_model). Klassifiziert wird mit Standard-Provider, eingerichtet unter Infrastruktur; läuft der ausführende Baustein über ein anderes Backend, antwortet der Aufruf mit 409 (exec_not_gateway). Ausgeführt wird dabei, was die Test-Suite für einen einzelnen Eintrag ausführt: Vorprüfungen, Prompt, strukturierte Ausgabe und Urteilsfindung. Die Schnittstelle klassifiziert einen einzelnen Kommentar ohne Verlauf.

Die Antwort

verdict: true Hassrede, false keine Hassrede, null Antwort nicht lesbar.
score: Wert von 0 bis 1, wenn die Urteilsfindung mit Score arbeitet, sonst null.
level: Die Moderationsstufe zu diesem Score, sonst null.
blocked: true, wenn eine Vorprüfung sofort entschieden hat; das Modell wurde dann nicht gefragt.
pre_checks: Die Vorprüfungen, die angeschlagen haben, je mit rule, action und reason.
answer: Die Antwort des Modells: ein Objekt bei strukturierter Ausgabe, sonst Text.

Dazu config_id, config_name, baustein (der ausführende Baustein mit id, name und type, sonst null), model, model_called, finish_reason und latency_ms.

Mit curl

Auf dem Server liegt der Controller hinter einer Anmeldung: -u BENUTZER nennt den Benutzernamen, curl fragt dann selbst nach dem Passwort.

Ein Skript meldet sich mit einem eigenen persönlichen GitLab-Token an (GitLab: Einstellungen → Zugriffstoken, Scope read_api), hier aus der Umgebungsvariable GITLAB_TOKEN, damit er nicht im Befehl steht. Die Rolle dieses Kontos im GitLab-Projekt legt fest, was der Aufruf darf: Klassifizieren und Lesen gehen ab Guest.

Welche Konfigurationen es gibt

GET

Listet jede abrufbare Konfiguration mit Kennung, Name, ausführendem Baustein, den Modellen je Baustein und Eckdaten, die neueste zuerst; dieselbe Liste steht im Katalog daneben.

inventory_2 Katalog

Das sind alle unter Konfiguration gespeicherten Konfigurationen. Eine Konfiguration erscheint hier von selbst, sobald sie gespeichert ist, und ist unter ihrer Kennung abrufbar; Speichern aktualisiert ihren Eintrag, Duplizieren legt eine Variante mit eigener Kennung an. Die Kennung wird unter Konfiguration im Feld Id vergeben und geändert, die Tags daneben.

Konfigurationen werden geladen…