> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Évaluer les modèles avec AutomationBench > Exécutez AutomationBench avec Harbor, CoreWeave Sandboxes et un point de terminaison de modèle configurable. Exécutez [AutomationBench](https://github.com/zapier/AutomationBench) dans des sandboxes CPU afin d’évaluer un modèle capable d’appeler des outils sur des flux de travail d’entreprise simulés. Ce tutoriel s’appuie sur Harbor pour planifier les tâches indépendamment les unes des autres, relancer certaines défaillances d’infrastructure et conserver les résultats. Commencez par une seule tâche, puis augmentez la simultanéité dans la limite de vos quotas de sandbox et d’inférence. L’exemple utilise [CoreWeave Serverless Inference](/fr/products/inference/serverless). Pour évaluer un autre modèle, il vous suffit de modifier le point de terminaison Chat Completions compatible avec OpenAI, l’ID du modèle et la clé d’inférence.

Flux de travail d’évaluation

La [recette AutomationBench](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/automationbench) exécute Harbor sur votre machine locale. Chaque essai dispose d’une sandbox CPU dans laquelle AutomationBench installe sa boucle d’agent, ses applications simulées et son évaluateur fondé sur des assertions. Le modèle s’exécute sur votre point de terminaison d’inférence. La sandbox ne nécessite ni GPU ni identifiants d’authentification d’applications réelles. La recette implémente les interfaces `BaseAgent` et `BaseEnvironment` de Harbor et s’appuie sur des appels publics du kit de développement logiciel (SDK) CoreWeave Sandboxes. Elle exécute l’évaluateur natif `auto-bench` tel quel et ne nécessite aucun adaptateur Harbor pour AutomationBench en amont. Les versions de Harbor, d’AutomationBench et du SDK `cwsandbox` sont épinglées dans la recette.

Prérequis

Avant de commencer, préparez les éléments suivants : * [`uv`](https://docs.astral.sh/uv/getting-started/installation/) et Git sur votre machine locale. La recette nécessite Python 3.13 ou une version ultérieure. Si Python n’est pas installé, `uv` [télécharge une version compatible](https://docs.astral.sh/uv/concepts/python-versions/). * Un [jeton d’accès à l’API CoreWeave](/fr/products/sandboxes/get-started#choose-a-credential) disposant d’un accès aux sandbox. * Un [quota de sandbox simultanées](/fr/products/sandboxes/reference/limits-and-quotas) suffisant pour le niveau de simultanéité choisi, ainsi que des stratégies de ressources autorisant 2 vCPU et 4 Gio de mémoire par sandbox. * Un point de terminaison d’inférence prenant en charge l’appel d’outils, une clé API et un quota d’inférence suffisant. Pour cet exemple, créez une clé API [Serverless Inference](/fr/products/inference/serverless). * Un accès réseau depuis votre machine vers l’API des sandbox et les dépôts de paquets, ainsi que depuis les sandbox vers GitHub, les dépôts de paquets Debian et Python, et votre point de terminaison d’inférence. La vérification initiale crée une sandbox CPU. Les ressources des sandbox et l’inférence sont facturées séparément. Avant d’étendre l’évaluation à plus grande échelle, consultez la [tarification des sandbox](https://www.coreweave.com/forge-pricing/inference-agents) ainsi que les [limites d’utilisation et la tarification](https://docs.coreweave.com/products/inference/serverless/usage-limits) de votre fournisseur d’inférence.

Installer la recette

Clonez le dépôt des recettes et installez les dépendances aux versions figées : ```bash theme={"system"} git clone https://github.com/coreweave/cwsandbox-recipes.git cd cwsandbox-recipes/recipes/automationbench uv sync --frozen cp .env.example .env ``` Exécutez les commandes suivantes depuis le répertoire de cette recette. L’environnement local contient Harbor et le SDK Sandbox. Chaque sandbox installe AutomationBench à partir de son checkout épinglé, en s’appuyant sur le lockfile figé du benchmark.

Configurer le modèle et les identifiants d’authentification

Chargez les identifiants d’authentification depuis votre gestionnaire de secrets dans l’environnement du processus. Définissez `CWSANDBOX_API_KEY` sur votre identifiant d’authentification de sandbox CoreWeave, et `MODEL_API_KEY` sur votre identifiant d’authentification d’inférence. N'enregistrez pas de clés dans le fichier `.env`. Dans le fichier `.env`, définissez uniquement le point de terminaison du modèle, le nom du modèle et, éventuellement, le projet. Pour l’exemple Serverless Inference, utilisez les paramètres suivants. Remplacez `[WANDB-TEAM]` et `[WANDB-PROJECT]` par des noms auxquels vous avez accès : ```bash theme={"system"} MODEL_BASE_URL="https://api.inference.wandb.ai/v1" MODEL_NAME="openai/gpt-oss-120b" MODEL_PROJECT="[WANDB-TEAM]/[WANDB-PROJECT]" ``` `MODEL_PROJECT` définit l’en-tête `OpenAI-Project` pour le suivi de l’utilisation de Serverless Inference. L’ID du modèle est donné à titre d’exemple et n’a rien d’obligatoire. Choisissez un modèle compatible avec l’appel d’outils parmi les [modèles disponibles](https://docs.coreweave.com/products/inference/serverless/models). Si vous utilisez un autre fournisseur compatible ou un modèle que vous servez vous-même, remplacez les paramètres du modèle dans le fichier `.env`. Remplacez `[INFERENCE-HOST]` et `[MODEL-ID]` par les valeurs de votre fournisseur : ```bash theme={"system"} MODEL_BASE_URL="https://[INFERENCE-HOST]/v1" MODEL_NAME="[MODEL-ID]" ``` Chargez la clé de ce fournisseur dans `MODEL_API_KEY` dans l'environnement du processus, sans retirer la définition de `CWSANDBOX_API_KEY`. Si le fournisseur n'utilise pas l'en-tête de projet, supprimez `MODEL_PROJECT` du fichier `.env` et annulez la définition de toute variable d'environnement `MODEL_PROJECT` héritée avant d'exécuter la commande. Le point de terminaison doit être accessible depuis la sandbox. `localhost` désigne la sandbox elle-même, et non votre machine. Pour les autres protocoles d'API, vous devez adapter les options de l'évaluateur natif. La recette utilise explicitement l'authentification CoreWeave pour les opérations sur la sandbox. Le jeton de la sandbox reste sur l'hôte. Seules la configuration du modèle et la clé d'inférence sont injectées dans la sandbox lors de sa création. La configuration de la tâche ne contient aucun identifiant d'authentification. Pour des conseils plus généraux sur la gestion des identifiants d'authentification, consultez [variables d'environnement et secrets](/fr/products/sandboxes/client/guides/environment-variables). Protégez les journaux et les traces téléchargés, car ils peuvent contenir des données de tâche et des messages d'erreur du fournisseur.

Lancer une vérification de la configuration

Évaluez une tâche simple avec une seule sandbox : ```bash theme={"system"} uv run --env-file .env python run.py \ --task simple.email_sf_contact_phone_update \ --concurrency 1 \ --output results-smoke ``` Le répertoire de sortie ne doit pas déjà exister. Harbor démarre la sandbox, installe AutomationBench, exécute la tâche, récupère les résultats, puis supprime la sandbox. Une fois la tâche terminée, la sortie suivante s’affiche : ```text theme={"system"} Harbor job finished; inspect job-result.json and archived attempts. ``` Consultez le fichier `results-smoke/job-result.json` pour connaître le nombre d’essais terminés et en erreur. Un code de sortie nul signifie qu’aucun essai n’est en erreur ni manquant, et non que le modèle a satisfait les assertions de la tâche. L’export natif `agent/automationbench.json` enregistre `passed`, `score`, les durées et l’utilisation des jetons. Le vérificateur associe `passed` et `score` à des récompenses Harbor nommées `pass` et `partial_credit`. Dans `job-result.json`, l’entrée `stats.evals` indique sous `metrics` la moyenne de chaque récompense sur l’ensemble des essais. Les essais sans récompense comptent pour zéro. `reward_stats` liste les essais pour chaque valeur de récompense. L’agent utilise l’ensemble d’outils `api`, un maximum de 50 étapes de réponse, une tâche à la fois par sandbox et le paramètre de raisonnement par défaut du fournisseur. L’autoréparation native à l’échelle de la tâche entière est désactivée afin que Harbor gère les nouvelles tentatives d’essais. Le client du modèle peut néanmoins relancer en interne des requêtes individuelles.

Augmenter le parallélisme

Une fois la vérification de la configuration réussie, commencez par un petit sous-ensemble : ```bash theme={"system"} head -n 8 tasks-scored.txt > tasks-small.txt uv run --env-file .env python run.py \ --tasks-file tasks-small.txt \ --concurrency 4 \ --output results-small ``` Chaque essai requiert 2 vCPU et 4 Gio de mémoire ; quatre essais simultanés requièrent donc jusqu’à 8 vCPU et 16 Gio. Harbor affecte chaque tâche indépendamment : dès qu’une tâche se termine, une autre peut prendre sa place. La configuration propre à chaque tâche entraîne une surcharge, car chaque sandbox installe l’évaluateur. La recette inclut deux listes de tâches pour la révision épinglée du benchmark : | Liste de tâches | Tâches | Objectif | | - | -: | - | | `tasks-scored.txt` | 600 | 100 tâches pour chacun des domaines suivants : ventes, marketing, opérations, assistance, finance et RH | | `tasks-simple.txt` | 200 | Tâches de référence simples, distinctes | Pour évaluer l’ensemble noté, sélectionnez sa liste de tâches et un niveau de simultanéité compatible avec vos quotas : ```bash theme={"system"} uv run --env-file .env python run.py \ --tasks-file tasks-scored.txt \ --concurrency 16 \ --output results-scored ``` Seize essais simultanés demandent au total jusqu’à 32 vCPU et 64 Gio. Il s’agit d’un exemple de configuration, et non d’un objectif de débit validé. Augmentez la simultanéité progressivement et surveillez les limites d’inférence ainsi que la capacité des sandboxes. Exécutez les tâches de référence en écrivant leurs résultats dans un répertoire de sortie distinct. N'incluez pas les 200 tâches simples dans le dénominateur de l’ensemble évalué. Ces tâches sont publiques. Le leaderboard officiel d’AutomationBench s’appuie sur un ensemble distinct de tâches privées ; les scores ne sont donc pas directement comparables.

Nouvelles tentatives en cas d’échecs liés à la capacité et aux limites d’inférence

La recette configure le `RetryConfig` de Harbor pour autoriser cinq nouvelles tentatives après la tentative originale, avec des délais d’attente de 30, 60, 120, 240 et 300 secondes. La liste d’autorisation des nouvelles tentatives inclut les exceptions suivantes : * `SandboxResourceExhaustedError` * `SandboxUnavailableError` * `SandboxRequestTimeoutError` * `EnvironmentStartTimeoutError` * `ApiRateLimitError` * `ApiUsageLimitError` Par défaut, Harbor exclut `ApiUsageLimitError`. La recette la retire de cet ensemble d’exclusions et l’ajoute à la liste d’autorisation. L’adaptateur fait correspondre les messages d’erreur terminale reconnus de l’évaluateur natif, relatifs aux quotas d’inférence et aux rate-limits, aux exceptions Harbor correspondantes. Ce mappage dépend du texte d’erreur du fournisseur. Consultez les journaux si un fournisseur renvoie un format différent. En cas d’épuisement persistant de la capacité ou des crédits, il faut toujours attendre que de la capacité ou des crédits redeviennent disponibles. Si des erreurs subsistent après les nouvelles tentatives, le script se termine avec un code de sortie non nul et conserve la dernière erreur. Les échecs d’assertion ordinaires, les refus, le JSON d’appel d’outil mal formé et les délais d’expiration d’exécution de l’agent ne déclenchent pas la politique de nouvelles tentatives. Harbor supprime les répertoires des essais échoués avant de relancer. Le hook de fin d’essai de la recette archive au préalable chaque tentative, y compris son résultat et les journaux disponibles. Conservez ces tentatives et signalez toute récupération d’infrastructure lorsque vous publiez des scores. Ne remplacez pas discrètement les échecs du modèle par de meilleurs résultats obtenus lors de nouvelles tentatives.

Inspecter les résultats et les essais lents

Chaque répertoire de sortie contient les artifacts suivants : | Chemin | Contenu | | - | - | | `job-config.json` | Configuration de la tâche Harbor, sans les valeurs des identifiants d’authentification | | `job-result.json` | Statistiques finales et erreurs de la tâche | | `jobs/automationbench/` | Essais finaux, exports natifs, journaux et récompenses du vérificateur | | `attempts/` | Tentatives d’essai archivées, y compris les échecs | | `sandbox-ids.jsonl` | ID des sandboxes enregistrés pour le nettoyage | Utilisez les exports natifs pour connaître la durée des tâches et l’utilisation des jetons. L’adaptateur ne renseigne pas les champs agrégés de jetons et de coût de l’agent dans Harbor. Consignez avec les résultats le modèle, le point de terminaison, la révision du benchmark, la liste des tâches, les paramètres de raisonnement, la concurrence et la politique de nouvelles tentatives. Si vous arrêtez un run, ne présentez comme évaluations terminées que les tâches exportées et signalez que les résultats sont partiels. Le temps de réponse du modèle peut représenter l’essentiel de la durée d’une tâche, même avec peu d’étapes ou de jetons de sortie. Comparez `model_time_s` à `tool_time_s` et examinez le fichier `agent/eval.log` avant d’imputer des retards aux ressources de la sandbox. Si le fournisseur rejette un JSON d’appel d’outil mal formé, il s’agit d’une défaillance du modèle ou du protocole, et non d’un signe d’épuisement du quota de sandboxes. AutomationBench répertorie les enregistrements de session interrompus en cours de tour de conversation dans le champ `summary.aborted_tasks` de l’export. Leurs tableaux `errors` par tâche peuvent être vides : vérifiez donc ce champ et les journaux, en plus des erreurs des tâches. La configuration est soumise à un délai d’expiration de 11 minutes. L’exécution de l’agent dispose d’un délai d’expiration distinct de 45 minutes, au sein duquel la commande d’évaluation native dispose de son propre délai de 40 minutes. Chaque sandbox est soumise à un plafond de durée de vie d’une heure, qui y met fin même si aucun délai d’expiration n’est écoulé. Cette politique ne prévoit pas de nouvelle tentative lorsque l’exécution de l’agent dépasse son délai d’expiration.

Arrêter et nettoyer

Pour arrêter un run au premier plan, appuyez sur Ctrl+C et laissez Harbor se fermer. La tâche définit `delete=True` pour la suppression des ressources. Si le processus est arrêté de force ou si le nettoyage échoue, arrêtez l'exécuteur local avant de supprimer les bacs à sable restants, afin qu'il ne puisse pas en recréer de nouveaux. Une fois l'exécuteur arrêté, utilisez son répertoire de sortie pour vérifier le nettoyage : ```bash theme={"system"} uv run --env-file .env python cleanup.py results-smoke ``` Remplacez `results-smoke` par le répertoire de la tâche que vous avez arrêtée. Le script supprime uniquement les ID de sandbox enregistrés et affiche leurs états terminaux. Une sandbox déjà absente est signalée comme `not_found`. Examinez tout code de sortie non nul, qui signale un échec de la suppression ou de la vérification de l'état terminal. Si le processus hôte disparaît, le plafond de durée de vie configuré borne également la durée de vie de la sandbox.

Portée de la validation

Pendant le développement de la recette, l’évaluateur natif a exporté les résultats de 730 des 800 tâches publiques sur huit sandboxes CPU en parallèle, avec `openai/gpt-oss-120b` sur Serverless Inference. Ce run a été arrêté avant son achèvement : ses résultats ne constituent donc pas un score de benchmark. L’ordonnancement des nouvelles tentatives de Harbor a été vérifié séparément : une erreur `SandboxResourceExhaustedError` injectée, un délai d’attente de 30 secondes, puis une tâche réelle qui s’est achevée, a exporté ses résultats et a été nettoyée. La recette remplace les hooks d’environnement de l’expérience initiale par une implémentation de `BaseEnvironment` qui s’appuie sur des appels du SDK public. Cette refactorisation est couverte par des tests hors ligne, mais n’a pas encore été exécutée sur le service réel. L’exécution d’un dataset complet avec une concurrence Harbor élevée n’a pas été validée. Pour les tests hors ligne et une vérification contrôlée facultative des nouvelles tentatives, consultez le [README de la recette](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/automationbench#test-and-compatibility).