Exécutions gérées

Une exécution gérée lance votre suite sur les workers d'Oloproof plutôt que sur votre machine, et vous la suivez depuis la page Jobs ou votre terminal. Il vous suffit de oloproof login ; ni connexion à une base de données, ni runner à vous.

Ce qu'un worker exécutera

Un worker appelle votre système en HTTP. Déclarez-le avec http: dans oloproof.yaml (Référence de configuration) :

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

Un worker refuse :

• Un système callable: ou rag:, avant que le job soit mis en file. C'est votre code, et les workers d'Oloproof n'exécutent pas le code des clients ; lancez-le sur votre machine (oloproof run) et poussez l'exécution, ou sur un runner que vous opérez.
• Un fichier de réponses recorded:. Il reste sur votre machine ; lancez-le en local avec oloproof run.
• Une adresse qui n'est pas sur l'internet public : localhost, un nom à une seule étiquette, une adresse privée, link-local ou de métadonnées cloud. Chaque appel est vérifié au moment où il est fait, si bien qu'un tel cas échoue en erreur au lieu de l'atteindre ; un worker ne peut atteindre que ce que n'importe qui sur internet peut atteindre.
• Les cas d'attaque générés, sauf si oloproof.yaml déclare adversarial: {sandboxed: true} (Générer des attaques). --allow-adversarial ne couvre qu'une exécution locale.

En lancer une

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

run --cloud envoie les cas de votre suite à l'espace de travail (une exécution gérée ne peut pas exécuter des cas qu'elle n'a pas), puis met le job en file et indique où le suivre. Une suite que l'espace de travail détient déjà en entier n'est pas renvoyée.

Le worker vérifie chaque cas contre son digest avant de conserver la suite, et refuse celle qui ne correspond pas. run --cloud calcule donc les digests des cas sans clé, comme le fait le worker, même dans un projet qui utilise des digests à clé pour retenir le contenu (egress:, Résultats et exécution) : les cas sont de toute façon envoyés en entier, une clé ne cacherait donc rien. La suite de l'exécution gérée est par conséquent une autre suite que celle qu'enregistre une exécution locale du même projet. Un projet dont l'espace de travail détient déjà des preuves à clé (issues d'un push) est refusé : exécutez-le avec oloproof run et poussez l'exécution.

--max-runtime est l'échéance du job en secondes, jusqu'à un jour, ou la limite de votre offre si elle est plus courte. Un budget: dans oloproof.yaml s'applique sur un worker comme en local.

Qui peut en lancer une : un Owner, Admin ou Member de l'espace de travail. Un Reviewer ne le peut pas.

La suivre

La page Jobs du projet affiche les cas de chaque job à mesure qu'ils arrivent : combien ont été exécutés et jugés, un décompte de réussites et d'échecs par vérification, et les derniers cas. Le décompte est un total provisoire, pas un résultat. Les décisions sont prises une fois l'exécution entière stockée, et sa page les affiche alors.

Dans le terminal :

oloproof job JOB_ID --follow

affiche les mêmes décomptes toutes les quelques secondes, puis la porte de l'exécution, et se termine avec le code de sortie de la porte, si bien qu'un pipeline peut attendre une exécution gérée comme une exécution locale (Exécution en CI). Sans --follow, job rend compte une seule fois ; un job encore en cours se termine avec 2, car ce n'est pas encore une décision. --cancel arrête aussitôt un job en file, et un job en cours avant son prochain appel, en gardant les cas terminés.

Clés pour un juge

Un juge ou un système qui appelle un fournisseur de modèles a besoin de sa clé sur le worker. Stockez-la une fois :

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

La clé est lue depuis l'environnement ou l'entrée standard, jamais depuis la ligne de commande. Elle est chiffrée par le worker et lisible seulement par un worker qui exécute les jobs de cet espace de travail ; personne ne peut la relire, et credentials list n'affiche que les noms. Le api_key_env: OPENAI_API_KEY d'un évaluateur la trouve alors. Un job géré ne lit aucune autre variable d'environnement. Seul un Owner ou un Admin peut stocker une clé.

Ce que cela ne peut pas vous dire

• Si votre système se comporte de la même façon depuis le réseau d'Oloproof que depuis le vôtre. Un worker appelle votre point d'accès depuis l'internet public ; les limites de débit, les régions et les listes d'autorisation qui le traitent différemment changent ce qu'il mesure.
• Quoi que ce soit sur du code qu'un worker n'a pas exécuté. Une exécution gérée mesure le point d'accès que vous avez nommé, pas le code derrière lui.

Toutes les autres limites de Ce qu'une évaluation ne peut pas vous dire valent aussi ici.