Interlock apprend aux agents à mener leurs tâches jusqu'au bout : jusqu'à +6,64 points sur JobBench

Les auteurs d'Interlock proposent une méthode pour synthétiser, à l'intention des agents LLM, des tâches longues où il ne suffit pas de donner la bonne réponse à chaque étape : il faut mener à terme toute la chaîne de dépendances. Deux modèles de la famille Qwen3.6, affinés sur leurs propres trajectoires sélectionnées, progressent sur trois benchmarks externes : +4,00–4,50 pp de tâches résolues sur AutomationBench, +3,20–6,64 points au score pondéré de JobBench et +3,89–4,16 pp sur les critères de Harvey LAB.

Le problème : localement correct, mais inachevé

Les agents travaillent de plus en plus dans des environnements où les éléments de preuve sont dispersés entre des fichiers et des systèmes, où l'état de la tâche n'est que partiellement atteint, et où les ressources et les artefacts dépendent les uns des autres. Une défaillance typique se présente ainsi : l'agent remplit soigneusement chaque exigence prise isolément, mais perd les liens qui les unissent. Le résultat paraît plausible sur la forme, mais reste incomplet. Les auteurs parlent d'un écart de complétion (completion gap) et l'expliquent ainsi : l'achèvement d'une tâche se définit par les relations entre les faits de l'environnement, les décisions prises et les effets que ces décisions doivent produire.

D'où leur reproche aux données d'entraînement existantes. Si les tâches synthétiques n'encodent pas ces relations, l'agent ne reçoit aucun signal lui indiquant qu'un gouffre sépare le « presque fini » du « fini ».

Comment fonctionne Interlock

Chaque tâche est représentée par un graphe de complétion typé, avec trois types de liens. Les arêtes d'ancrage (grounding) relient les preuves publiques aux décisions. Les hyperarêtes de couplage (coupling) imposent des contraintes conjointes à plusieurs composants à la fois. Les arêtes de réalisation (realization) relient une décision à tous les effets en aval obligatoires.

Le graphe est compilé en trois artefacts : un espace de travail réinitialisable, une requête publique et une grille d'évaluation. Deux contrôles qualité interviennent ensuite. La source-coverage review vérifie que les exigences initiales ne se sont pas perdues pendant la génération. La public-input review vérifie que la grille s'appuie sur des matériaux réellement accessibles à l'exécutant, c'est-à-dire que l'agent n'a pas à deviner ce qui lui est caché.

Un agent-juge évalue chaque exécution : il examine les artefacts produits et lance des scripts de vérification. Seules les trajectoires qui remplissent toutes les exigences obligatoires entrent dans le jeu d'entraînement.

• Structure de la tâche : un graphe typé avec des arêtes d'ancrage, des hyperarêtes de couplage et des arêtes de réalisation
• Sortie de la compilation : un workspace réinitialisable, une requête publique, une grille d'évaluation
• Filtres : source-coverage review et public-input review
• Sélection : un agent-juge avec des scripts de vérification, uniquement les trajectoires satisfaisant toutes les exigences obligatoires
• Modèles : deux bases Qwen3.6, affinées sur leurs propres trajectoires acceptées
• Gain : AutomationBench +4,00–4,50 pp, JobBench +3,20–6,64 points, Harvey LAB +3,89–4,16 pp

Ce que disent les chiffres

Le schéma s'apparente à de l'autodistillation avec un tri sévère : le modèle résout des tâches synthétiques, le juge ne garde que les exécutions irréprochables, et le fine-tuning se fait sur celles-ci. Ce n'est pas la mécanique qui compte, mais l'endroit où l'effet se transfère. AutomationBench, JobBench et Harvey LAB n'ont pas participé à la génération des tâches : le gain est donc obtenu dans des environnements externes, et non sur la distribution propre aux auteurs.

Le résultat a ses limites. Les gains sont modérés, les fourchettes sont larges (de 3,20 à 6,64 pour JobBench) et il n'y a que deux modèles de base. La description ne permet pas de savoir combien coûtent la génération et la vérification d'une tâche, dans quelle mesure le juge-LLM se trompe, ni comment la méthode passe à l'échelle avec un plus grand nombre de trajectoires. Ces questions sont à chercher dans le texte complet de l'article.

Ce qu'il faut en retenir

Même sans reproduire tout le pipeline, ces idées s'appliquent directement. Décrivez les tâches des agents comme un graphe de dépendances, où chaque décision énumère les effets ultérieurs obligatoires, et vérifiez précisément ces effets, pas le texte de la réponse finale. Soumettez la grille à un test de « déductibilité à partir des matériaux publics » : cela écarte les tâches où l'agent échoue à cause de conditions cachées. Rendez les environnements réinitialisables pour que les trajectoires soient reproductibles. Enfin, au moment de sélectionner les données de fine-tuning, exigez que tous les points obligatoires soient remplis, plutôt qu'un score moyen élevé : sinon, le modèle continuera d'apprendre à partir de résultats « localement corrects » mais incomplets.