> ## 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.

# SWE-bench

> Exécutez des évaluations SWE-bench à l’aide de sandboxs CoreWeave.

Exécutez des évaluations SWE-bench en parallèle à l’aide de sandboxs sur CoreWeave. Ce guide s’adresse aux praticiens et chercheurs en ML qui souhaitent évaluer à grande échelle les performances des modèles de langage en matière de correction de code. À la fin de ce guide, vous disposerez d’une configuration opérationnelle qui exécute des évaluations SWE-bench simultanément sur de nombreux sandboxs CoreWeave, et qui enregistre les résultats en local en vue de leur analyse.

<h2 id="what-this-does">
  Fonctionnement
</h2>

[SWE-bench](https://www.swebench.com/) évalue la capacité des modèles de langage à corriger de vrais bugs dans de vrais dépôts. Chaque tâche applique un patch, exécute la suite de tests et vérifie si le correctif fonctionne.

Vous pouvez exécuter SWE-bench localement avec Docker, mais vous êtes alors limité par les ressources de votre machine. Les sandboxs CoreWeave vous permettent d’exécuter des évaluations à grande échelle sur l’infrastructure CoreWeave. Lancez simultanément des dizaines, voire des centaines de sandboxs, sans avoir à vous soucier de leur gestion. Le script récupère des images prêtes à l’emploi depuis le registre d’Epoch AI sur GHCR : aucune étape de compilation Docker locale n’est donc nécessaire.

<h2 id="setup">
  Configuration
</h2>

Suivez les étapes ci-dessous pour installer les outils requis et configurer l’authentification avant d’exécuter des évaluations.

1. Installez le SDK Python et les dépendances nécessaires aux évaluations :

   ```bash theme={"system"}
   uv pip install cwsandbox swebench datasets
   ```

2. Clonez le dépôt contenant les exemples de scripts d’évaluation :

   ```bash theme={"system"}
   git clone https://github.com/coreweave/cwsandbox-client.git
   cd cwsandbox-client
   ```

3. Définissez `CWSANDBOX_API_KEY` sur un [jeton d’accès à l’API CoreWeave](/security/authn-authz/manage-api-access-tokens). Remplacez `[API-ACCESS-TOKEN]` par votre jeton :

   ```bash theme={"system"}
   export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"
   ```

Par défaut, le script d’évaluation utilise l’authentification CoreWeave. Pour utiliser une clé API Forge, configurez explicitement l’authentification comme décrit dans [Premiers pas](/fr/products/sandboxes/get-started), puis transmettez la valeur `auth` obtenue à `SandboxDefaults(...)` dans `examples/swebench/run_evaluation.py`.

<h2 id="quick-start">
  Démarrage rapide
</h2>

Avant de passer à l’échelle, commencez par un run sur une seule instance afin de vérifier que votre environnement, vos identifiants d’authentification et votre accès réseau à GHCR fonctionnent correctement. L’option `gold` utilise le correctif du dataset dont on sait qu’il est correct :

```bash theme={"system"}
uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids astropy__astropy-12907 \
    --run-id test
```

Ce run réussit, ce qui confirme que votre sandbox peut récupérer l’image, appliquer le patch et exécuter la suite de tests de bout en bout.

<h3 id="run-in-parallel">
  Exécuter en parallèle
</h3>

Exécutez plusieurs instances simultanément :

```bash theme={"system"}
uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids \
        astropy__astropy-12907 \
        django__django-11039 \
        django__django-11099 \
        django__django-11283 \
        matplotlib__matplotlib-23476 \
        scikit-learn__scikit-learn-13142 \
        sympy__sympy-13031 \
        sympy__sympy-13647 \
    --run-id parallel-test \
    --max-workers 8
```

Cette commande lance huit sandboxs et les exécute en parallèle. Tous réussissent, car les patchs de référence (gold patches) sont les correctifs attendus.

<h3 id="evaluate-model-predictions">
  Évaluer les prédictions du modèle
</h3>

Pour tester la sortie d’un modèle personnalisé :

```bash theme={"system"}
uv run python examples/swebench/run_evaluation.py \
    --predictions-path predictions.json \
    --instance-ids django__django-11039 scikit-learn__scikit-learn-13142 \
    --run-id eval-run-1 \
    --max-workers 10
```

Le fichier de prédictions associe chaque ID d’instance à un patch :

```json theme={"system"}
[
  {
    "instance_id": "django__django-11039",
    "model_name_or_path": "gpt-4",
    "model_patch": "diff --git a/..."
  }
]
```

<h2 id="options">
  Options
</h2>

| Option | Par défaut | Description |
| - | - | - |
| `--predictions-path` | Requis | Chemin vers le fichier JSON des prédictions, ou `gold` pour utiliser les patchs de référence |
| `--instance-ids` | Requis | ID d’instances, séparés par des espaces |
| `--run-id` | Requis | Identifiant de ce run |
| `--max-workers` | 10 | Nombre maximal de sandboxs exécutés en parallèle |
| `--timeout` | 1800 | Délai d’expiration par instance, en secondes (30 minutes) |
| `--output-dir` | `logs/swebench` | Répertoire de destination des journaux et des rapports |
| `--dataset` | `princeton-nlp/SWE-bench_Lite` | Nom du dataset Hugging Face |
| `--force` | false | Réexécuter les instances même si report.json existe déjà |

<h3 id="adjust-resources">
  Ajuster les ressources
</h3>

Par défaut, chaque sandbox dispose de 2 CPU et de 4Gi de mémoire. Modifiez ces valeurs dans `run_evaluation.py` :

```python theme={"system"}
defaults = SandboxDefaults(
    tags=(f"swebench-{run_id}",),
    resources={"cpu": "4", "memory": "8Gi"},
)
```

<h2 id="how-it-works">
  Fonctionnement
</h2>

Cette section présente les rouages du script afin que vous puissiez l’adapter à vos propres flux de travail d’évaluation.

<h3 id="container-images">
  Images de conteneur
</h3>

Epoch AI héberge des images préconstruites sur GHCR. Chaque instance dispose de sa propre image, avec le dépôt extrait au bon commit, les dépendances installées et l’environnement de test prêt.

Format de l’image : `ghcr.io/epoch-research/swe-bench.eval.x86_64.{instance_id}:latest`

Les Sandbox récupèrent ces images directement depuis GHCR, sans qu’aucune compilation locale soit nécessaire.

<h3 id="evaluation-flow">
  Flux d’évaluation
</h3>

Chaque instance passe par les étapes suivantes :

| Étape | Emplacement | Déroulement |
| - | - | - |
| 1. Charger le dataset | Local | Récupérer les métadonnées de l’instance depuis Hugging Face |
| 2. Créer la sandbox | Sandbox | Démarrer la sandbox avec l’image de l’instance |
| 3. Écrire le patch | Sandbox | Écrire le patch dans `/tmp/patch.diff` |
| 4. Appliquer le patch | Sandbox | Exécuter `git apply` (repli sur `patch` si nécessaire) |
| 5. Exécuter les tests | Sandbox | Exécuter `/root/eval.sh` |
| 6. Noter les résultats | Local | Analyser la sortie avec `swebench.harness.grading` |
| 7. Écrire le rapport | Local | Enregistrer les résultats dans `logs/swebench/` |
| 8. Nettoyage | Sandbox | Arrêter la sandbox |

Les étapes 2 à 5 et 8 s’exécutent à distance, les étapes 1, 6 et 7 sur votre machine.

<h3 id="parallel-execution">
  Exécution parallèle
</h3>

Le script utilise `ThreadPoolExecutor` pour exécuter en parallèle les flux de travail des instances. Chaque thread fait avancer une instance tout au long de son flux de travail. Pendant qu’une instance exécute des tests, une autre peut appliquer son patch, une troisième effectuer l’évaluation en local et une quatrième démarrer. C’est ce chevauchement qui permet de gagner en rapidité.

Les résultats sont renvoyés via `as_completed()` au fur et à mesure que les flux de travail se terminent.

<h3 id="cleanup">
  Nettoyage
</h3>

Le script utilise une `Session` de sandbox pour suivre les sandboxs. Lorsque la session se termine (fin normale, exception ou `Ctrl+C`), elle nettoie tous les sandboxs.

```python theme={"system"}
with cwsandbox.Session(defaults=defaults) as session:
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        # À sa fermeture, la session nettoie les bacs à sable créés ici
```

<h2 id="output">
  Sortie
</h2>

Les résultats sont enregistrés dans `{output-dir}/{run-id}/{model-name}/{instance-id}/` :

| Fichier | Contenu |
| - | - |
| `report.json` | Statut de résolution, ID de la sandbox, durée |
| `test_output.txt` | Sortie complète des tests |
| `patch.diff` | Le patch appliqué |

<h3 id="report-format">
  Format du rapport
</h3>

```json theme={"system"}
{
  "instance_id": {
    "resolved": true,
    "tests_status": {
      "PASSED": ["test_foo", "test_bar"],
      "FAILED": []
    }
  },
  "sandbox_id": "sb-abc123",
  "duration_seconds": 45.2
}
```

Ce format est compatible avec les outils standard de SWE-bench.

<h2 id="troubleshooting">
  Dépannage
</h2>

<h3 id="patch-application-fails">
  Échec de l’application du patch
</h3>

Si `APPLY_PATCH_FAIL` apparaît dans les journaux, le patch est probablement mal formé, cible le mauvais commit ou contient des erreurs de caractères d’espacement. Exécutez `git apply --check` en local pour identifier le problème. Vérifiez que l’ID d’instance correspond bien à celui de la prédiction.

<h3 id="test-timeouts">
  Délais d’expiration des tests
</h3>

Certaines suites de tests durent plus de 30 minutes. Le code généré par le modèle peut aussi contenir des boucles infinies. Si nécessaire, augmentez la valeur de `--timeout` ou consultez la sortie des tests pour identifier l’endroit où ils bloquent.

<h3 id="image-pull-errors">
  Erreurs de récupération d’image
</h3>

Si le conteneur ne démarre pas en raison d’une erreur de récupération d’image, soit l’ID d’instance n’existe pas dans le registre d’Epoch AI, soit un problème réseau empêche d’accéder à `ghcr.io`. Vérifiez que l’ID d’instance figure bien dans le dataset SWE-bench.

<h2 id="see-also">
  Voir aussi
</h2>

* [Guide d’exécution des commandes](/fr/products/sandboxes/client/guides/execution) : informations détaillées sur les modèles d’utilisation de `exec()`.
* [Modèles de nettoyage](/fr/products/sandboxes/client/guides/cleanup-patterns) : gestion du cycle de vie des sandboxes.