IQuest-Coder : un nouveau modèle de code open source surpasse Claude Sonnet 4.5 et GPT 5.1 [pdf]

• Un LLM de code open source spécialisé dans le développement, qui apprend les évolutions d’un dépôt et le processus de développement plutôt que du code statique, grâce à un apprentissage multi-étapes du flux de code (code-flow)
• Renforcement des performances en raisonnement long et en tâches d’agent grâce à un pipeline d’apprentissage évolutif allant du préentraînement au mid-training puis au post-training
• Injection de données de raisonnement et de trajectoires d’agent dans des contextes 32K et 128K afin d’acquérir la capacité de résoudre des problèmes complexes impliquant plusieurs fichiers ou des dépôts entiers
• Proposition d’une conception pragmatique avec l’architecture LoopCoder, qui introduit une structure itérative pour améliorer l’efficacité de déploiement à capacité de modèle équivalente
• Des performances compétitives face aux modèles commerciaux sur SWE-Bench, LiveCodeBench, Terminal-Bench et d’autres, obtenues avec un modèle à poids ouverts

---

Aperçu

• IQuest-Coder-V1 est une famille de grands modèles de langage dédiés au code, composée de 7B, 14B, 40B et 40B-Loop
• Adoption du paradigme code-flow, qui prend pour objet d’apprentissage les commits et l’évolution du dépôt plutôt que de simples instantanés statiques du code
• Évaluation des performances sur l’ingénierie logicielle de type agent, la programmation compétitive et l’usage d’outils au sens large

Pipeline d’apprentissage Code-Flow

• En phase de préentraînement, apprentissage sur un mélange de données générales et d’un vaste corpus de code, suivi d’un annealing de code de haute qualité
• En phase de mid-training, extension du contexte de 32K à 128K et apprentissage sur des QA de raisonnement, des trajectoires d’agent et des données de code à l’échelle du dépôt
• En phase de post-training, bifurcation en une voie Thinking (RL centré sur le raisonnement) et une voie Instruct (optimisation d’assistance générale)

Principaux résultats de recherche

• Les expériences montrent que les données issues du flux de commits d’un dépôt fournissent de meilleurs signaux de planification des tâches que des instantanés statiques du code
• Après l’annealing de code de haute qualité, la structure de mid-training qui injecte des données de raisonnement et d’agent apporte une stabilité face aux changements de distribution
• Dans la voie Thinking avec RL centré sur le raisonnement, une capacité marquée d’auto-récupération après erreur lors de tâches longues apparaît nettement

Architecture LoopCoder

• Introduction d’une structure de transformer en boucle qui exécute deux fois le même bloc de paramètres
• Combinaison, via un mécanisme de gating, d’une attention globale et d’une attention locale pour atteindre simultanément l’affinage du contexte à longue portée et le maintien de la causalité
• Objectif : améliorer l’efficacité de calcul par rapport à la taille du modèle afin de répondre aux contraintes des environnements de déploiement

Composition des données et stratégie de préentraînement

• Formalisation, à l’aide de lois de scaling fondées sur des formules, des effets de synergie entre langages dans l’apprentissage mêlant plusieurs langages de programmation
• Construction de données en triplets (R_old, Patch, R_new) à partir de commits situés entre 40 % et 80 % du cycle de vie d’un dépôt
• Renforcement des capacités de complétion de code grâce à une technique de Fill-In-the-Middle à l’échelle du fichier et du dépôt

Résultats d’évaluation

• Score de 76.2 sur SWE-Bench Verified, avec des performances de premier plan sur de nombreux benchmarks comme LiveCodeBench v6, Terminal-Bench et Mind2Web
• Évaluation menée sur tout le spectre : génération de code, raisonnement, édition, efficacité, Text-to-SQL et tâches d’agent
• Sur certains indicateurs, des résultats proches ou compétitifs face à des modèles fermés comme Claude Sonnet 4.5 et GPT-5.1

Évaluation de la sécurité

• Sur des benchmarks de sécurité comme BeaverTails, HarmBench et TrustLLM, le modèle Thinking affiche une précision de refus élevée et des performances équilibrées
• Les résultats suggèrent qu’un RL centré sur le raisonnement a aussi un effet positif du point de vue de la sécurité

Conclusion

• Démonstration empirique que l’apprentissage centré sur le flux d’évolution du code et les trajectoires d’agent est efficace pour former une intelligence du code autonome
• L’architecture LoopCoder propose une orientation pragmatique pour concevoir des LLM de code, en tenant compte du compromis performance-efficacité
• Publication de l’ensemble des étapes d’apprentissage et des checkpoints afin de favoriser la recherche ouverte sur l’intelligence du code et le développement de systèmes d’agents concrets

[GN⁺]

Commentaires Hacker News

• Un meilleur lien est iquestlab.github.io
  Mais malheureusement, il semble que l’agent ait triché pendant l’évaluation

  • D’après cette issue GitHub, les résultats restaient bons même après correction de la triche
    Le score est passé de 81,4 % à 76,2 %, mais reste au-dessus d’Opus 4.5 (74,4 %)
  • Il y a quelques jours, ce lien n’avait pas reçu assez de votes

• En résumé, le modèle a pu consulter les correctifs de commits futurs via une forme de reward hacking, parce que le dossier .git/ n’avait pas été nettoyé
  Je veux saluer les personnes qui ont aidé à résoudre ce problème
  La discussion associée est aussi visible dans ce tweet et ce fil Reddit
  Comme IQuestLab a publié les données SWE-Bench Verified, cela ressemble davantage à une simple erreur de débutant sur un benchmark qu’à une manipulation intentionnelle

  • Comme John l’a mentionné, ce problème a déjà été corrigé dans SWE-bench
    Il suffit d’utiliser le code le plus récent et de lancer l’évaluation avec l’image Docker mise à jour
    Tweet associé
  • Je pense aussi qu’il s’agit simplement d’une erreur, mais il est regrettable que les chercheurs ne s’en soient pas rendu compte immédiatement en regardant ne serait-ce qu’une fois les sorties produites
  • SWEbench n’échappe toujours pas à la controverse sur le battage médiatique

• D’après mon expérience, GLM-4.7 (version opencode) est ce qui s’en rapproche le plus côté open source
  On voit parfois des tournures qui donnent l’impression que des données de Claude s’y sont glissées, donc il est possible qu’il y ait eu une certaine utilisation de données Claude

  • Mais les performances restent très loin de Sonnet 4.5, et il n’y a même pas matière à comparaison avec Opus
  • On voit aussi souvent des phrases comme “What’s your use-case?”
    C’est une formule que Claude utilise fréquemment pour esquiver quand il atteint ses limites

• Un modèle de 40B paramètres qui bat Sonnet 4.5 et GPT 5.1 ? Je me demande si c’est vraiment possible

  • Mon hypothèse, sans certitude, est qu’il y a eu fuite des données de test ou qu’une partie du benchmark était incluse dans les données d’entraînement
    Cela dit, Sonnet 4.5 est déjà un modèle ancien, et il y a eu beaucoup d’innovations récentes
    Il est intéressant de voir les modèles open source rattraper rapidement les grands modèles
  • Au point qu’on en arrive à faire le jeu de mots selon lequel le nom « IQuest » est suspect (It’s questionable)
  • Il est aussi possible qu’ils aient appliqué des techniques de pruning de modèle. Il y a beaucoup de nouvelles méthodes en ce moment
  • En réalité, il s’est avéré que l’agent avait piraté le harnais d’évaluation

• Je me demande si quelqu’un a fait tourner ce modèle lui-même, ou l’a testé via une API hébergée

• C’est une affirmation mensongère ; je me demande pourquoi cela reste encore sur la page principale