Zum Inhalt springen

Anleitungen

Verwaltete Läufe

Ein verwalteter Lauf führt Ihre Suite auf den Workern von Oloproof statt auf Ihrem Rechner aus, und Sie verfolgen ihn auf der Seite Jobs oder in Ihrem Terminal. Sie brauchen nur oloproof login; keine Datenbankverbindung und keinen eigenen Runner.

Was ein Worker ausführt

Ein Worker ruft Ihr System über HTTP auf. Deklarieren Sie es mit http: in oloproof.yaml (Konfigurationsreferenz):

system:
  name: support-bot
  version: v3
  http:
    url: https://support-bot.example.com/answer
    output_path: answer

Ein Worker lehnt ab:

  • Ein System callable: oder rag:, bevor der Job in die Warteschlange kommt. Das ist Ihr Code, und die Worker von Oloproof führen keinen Kundencode aus; führen Sie es auf Ihrem eigenen Rechner aus (oloproof run) und pushen Sie den Lauf, oder auf einem Runner, den Sie betreiben.
  • Eine Antwortdatei recorded:. Sie bleibt auf Ihrem Rechner; führen Sie sie lokal mit oloproof run aus.
  • Eine Adresse, die nicht im öffentlichen Internet liegt: localhost, ein Name mit nur einem Label, eine private, Link-Local- oder Cloud-Metadaten-Adresse. Jeder Aufruf wird geprüft, während er erfolgt, sodass ein solcher Fall mit einem Fehler endet, statt sie zu erreichen; ein Worker erreicht nur, was jeder im Internet erreichen kann.
  • Generierte Angriffsfälle, sofern oloproof.yaml nicht adversarial: {sandboxed: true} deklariert (Angriffe generieren). --allow-adversarial gilt nur für einen lokalen Lauf.

Einen starten

oloproof login
oloproof run --cloud --max-runtime 900

run --cloud sendet die Fälle Ihrer Suite an den Workspace (ein verwalteter Lauf kann keine Fälle ausführen, die er nicht hat), stellt dann den Job in die Warteschlange und gibt aus, wo Sie ihn verfolgen. Eine Suite, die der Workspace bereits vollständig hat, wird nicht erneut gesendet.

Der Worker prüft jeden Fall gegen seinen Digest, bevor er die Suite behält, und weist eine zurück, die nicht übereinstimmt. Deshalb bildet run --cloud die Digests der Fälle ungeschlüsselt, wie der Worker es tut, auch in einem Projekt, das seine Digests verschlüsselt, um Inhalte zurückzuhalten (egress:, Ergebnisse und Ausführung): Die Fälle werden ohnehin vollständig gesendet, ein Schlüssel würde also nichts verbergen. Die Suite des verwalteten Laufs ist daher eine andere Suite als die, die ein lokaler Lauf desselben Projekts aufzeichnet. Ein Projekt, dessen Workspace bereits verschlüsselte Evidenz hält (aus einem Push), wird abgewiesen: Führen Sie es mit oloproof run aus und pushen Sie den Lauf.

--max-runtime ist die Frist des Jobs in Sekunden, bis zu einem Tag, oder das Limit Ihres Tarifs, wenn es kleiner ist. Ein budget: in oloproof.yaml bindet auf einem Worker wie lokal.

Wer einen starten darf: ein Owner, Admin oder Member des Workspace. Ein Reviewer darf es nicht.

Ihn verfolgen

Die Seite Jobs des Projekts zeigt die Fälle jedes Jobs, sobald sie eintreffen: wie viele ausgeführt und bewertet wurden, eine Zählung von Bestanden und Nicht bestanden je Prüfung und die neuesten Fälle. Die Zählung ist ein Zwischenstand, kein Ergebnis. Die Entscheidungen fallen, sobald der ganze Lauf gespeichert ist, und seine Seite zeigt sie dann.

Im Terminal:

oloproof job JOB_ID --follow

gibt alle paar Sekunden dieselben Zählungen aus, dann das Gate des Laufs, und endet mit dem Exit-Code des Gates, sodass eine Pipeline auf einen verwalteten Lauf wie auf einen lokalen warten kann (In CI ausführen). Ohne --follow berichtet job einmal; ein noch laufender Job endet mit 2, weil er noch keine Entscheidung ist. --cancel stoppt einen wartenden Job sofort und einen laufenden vor seinem nächsten Aufruf, wobei die fertigen Fälle erhalten bleiben.

Schlüssel für einen Judge

Ein Judge oder ein System, das einen Modellanbieter aufruft, braucht seinen Schlüssel auf dem Worker. Speichern Sie ihn einmal:

export OPENAI_API_KEY=...
oloproof credentials set OPENAI_API_KEY
oloproof credentials list

Der Schlüssel wird aus der Umgebung oder der Standardeingabe gelesen, nie von der Befehlszeile. Er wird vom Worker verschlüsselt und ist nur für einen Worker lesbar, der die Jobs dieses Workspace ausführt; niemand kann ihn zurücklesen, und credentials list zeigt nur Namen. Das api_key_env: OPENAI_API_KEY eines Evaluators findet ihn dann. Ein verwalteter Job liest keine andere Umgebungsvariable. Nur ein Owner oder Admin darf einen Schlüssel speichern.

Was das nicht sagen kann

  • Ob sich Ihr System aus dem Netz von Oloproof genauso verhält wie aus Ihrem. Ein Worker ruft Ihren Endpunkt aus dem öffentlichen Internet auf; Ratenlimits, Regionen und Zulassungslisten, die ihn anders behandeln, ändern, was er misst.
  • Irgendetwas über Code, den ein Worker nicht ausgeführt hat. Ein verwalteter Lauf misst den Endpunkt, den Sie genannt haben, nicht den Code dahinter.

Jede andere Grenze unter Was eine Evaluation nicht sagen kann gilt auch hier.