Présentation du workflow Memdoor

Le projet team‑solve implémente un harness multi‑agents basé sur Memdoor. Cinq rôles – planificateur, deux idéateurs, solveur et manager – ainsi qu’un travailleur de réparation démarrent chacun avec un contexte vierge et n’échangent des informations que via des fichiers sur disque. Aucun appel n’est déclenché par un modèle pour déterminer le succès ; un script shell exécute les tests et renvoie un code de sortie.

Architecture et paramètres techniques

Chaque agent utilise le même modèle Qwen3.8‑27B avec une limite de réponse de 128 K tokens. Les températures sont fixées à 0.3 pour le planificateur, 0.4 pour les idéateurs et 0.2 pour le manager et le réparateur, tandis que top_p vaut 0.95 et top_k 20, reproduisant la configuration de l’étude originale (Lee 2026). Le système s’appuie sur OpenRouter, enchaînant les fournisseurs Modal, CoreWeave, Parasail et Wafer selon la disponibilité. Au total, 203 appels ont été servis par Modal, 27 par CoreWeave et 115 par Wafer, les appels FP8 étant exclusivement traités par Wafer.

curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter
git clone --depth 1 https://github.com/guregodevo/memdoor
memdoor workflow run team-solve --wait

Résultats quantitatifs

Sur les dix premiers problèmes de la catégorie Hard de LiveCodeBench, le pipeline a exécuté cinq passes chacune, soit 50 exécutions. Le score moyen atteint 9.8/10, contre 9.6 pour le même harness reproduit par les auteurs et 8.0 pour Fable 5 en mode mono‑appel. Le coût total s’élève à 35.79 $, correspondant à 15.3 M de tokens de sortie. Le temps médian d’inférence est de 40 minutes, le plus long atteignant quatre heures, avec un coût moyen de 0.39 $ par problème.

Analyse des limites et points d’amélioration

Deux défaillances récurrentes ont été identifiées. Dans la passe 5 du problème abc399_e, le manager a généré un contre‑exemple erroné, poussant l’équipe à réécrire un programme déjà correct pour les tests publics, mais qui échoue sur les tests cachés (32/44 réussis). Dans les passes 4 des problèmes arc196_c et arc196_d, le manager n’a pas indiqué « done », entraînant l’écrasement d’un programme valide et un coût supplémentaire de 3.44 $ et 4.24 $ respectivement. Ces scénarios pourraient être corrigés en validant les contre‑exemples du manager par une recherche exhaustive sur de petits jeux de données, ou en conservant le dernier programme qui a passé les échantillons.

Un autre facteur de risque est la possible contamination du modèle : les problèmes étudiés datent du 29 mars au 6 avril 2025, période pendant laquelle Qwen3.8‑27B aurait pu les voir en phase d’entraînement, ce qui rend difficile d’attribuer entièrement la performance à l’orchestration.

Enfin, la dépendance à un service externe (OpenRouter) introduit une variabilité de débit (Modal limité à 14 tokens/s) et un besoin de basculement d’hôte en cours d’exécution, comme le montre le fichier log/host-switch.txt. Une exécution locale via vLLM en FP8 éliminerait cette instabilité, mais augmenterait les exigences matérielles.