IQuest-Coder: 新しいオープンソースコードモデルが Claude Sonnet 4.5 と GPT 5.1 を上回る [pdf]

 (github.com/IQuestLab)
2 ポイント 投稿者 GN⁺ 2026-01-05 | 1件のコメント | WhatsAppで共有
  • コードフロー(code-flow)の多段階学習を通じて、静的コードではなくリポジトリの変化と開発過程を学習する、コーディング特化のオープンコード LLM
  • 事前学習–ミッドトレーニング–ポストトレーニングへと続く進化型学習パイプラインにより、長期推論とエージェント作業の性能を強化
  • 32K・128K コンテキストで推論データとエージェント軌跡を注入し、複雑なマルチファイル・リポジトリ単位の問題解決能力を確保
  • 反復構造を導入したLoopCoder アーキテクチャにより、モデル容量に対するデプロイ効率を改善する実用的設計を提案
  • SWE-Bench、LiveCodeBench、Terminal-Bench などで商用モデルと競争可能な性能をオープンウェイトモデルで達成

概要

  • IQuest-Coder-V1 は 7B・14B・40B・40B-Loop で構成されたコード専用大規模言語モデル系列
  • コードスナップショットではなくコミットとリポジトリ進化の過程を学習対象とする code-flow パラダイムを採用
  • エージェント型ソフトウェアエンジニアリング、競技プログラミング、ツール利用全般で性能評価を実施

Code-Flow 学習パイプライン

  • 事前学習段階で一般データと大規模コードデータを混合学習した後、高品質コードアニーリングを適用
  • ミッドトレーニング段階で32K → 128K コンテキスト拡張を行い、推論 QA・エージェント軌跡・リポジトリ単位コードデータを学習
  • ポストトレーニング段階で**Thinking 経路（推論中心 RL）とInstruct 経路（一般支援最適化）**に分岐

主要な研究結果

  • リポジトリのコミットフローデータが静的コードスナップショットよりも作業計画シグナルに優れることを実験で確認
  • 高品質コードアニーリング後、ミッドトレーニングで推論・エージェントデータを注入する構造が分布変化に対する安定性を提供
  • 推論中心 RL を適用した Thinking 経路では、長期作業中の自己エラー回復能力が明確に現れる

LoopCoder アーキテクチャ

  • 同一パラメータブロックを 2 回繰り返し実行するループトランスフォーマー構造を導入
  • グローバルアテンションとローカルアテンションをゲーティングで結合し、長距離文脈の精緻化と因果性の維持を同時に達成
  • モデル容量に対する演算効率を改善し、デプロイ環境の制約への対応を目的とする

データ構成と事前学習戦略

  • 多言語コード混合学習における言語間シナジー効果を、数式ベースのスケーリング則として定式化
  • リポジトリのライフサイクル 40〜80% 区間のコミットを活用した**(R_old, Patch, R_new) トリプレットデータ**を構成
  • ファイル・リポジトリ単位の Fill-In-the-Middle 手法によりコード補完能力を強化

評価結果

  • SWE-Bench Verified で76.2、LiveCodeBench v6・Terminal-Bench・Mind2Web など多数のベンチマークで上位性能を記録
  • コード生成・推論・編集・効率性・Text-to-SQL・エージェント作業まで全領域の評価を実施
  • 一部指標で Claude Sonnet 4.5、GPT-5.1 などクローズドモデルに近い、または競争力のある結果を確認

安全性評価

  • BeaverTails、HarmBench、TrustLLM などの安全性ベンチマークでThinking モデルが高い拒否精度とバランスの取れた性能を記録
  • 推論中心 RL が安全性の面でも肯定的効果を示す結果を提示

結論

  • コード進化フローとエージェント軌跡を中心とした学習が自律的コード知能の形成に効果的であることを実証
  • LoopCoder 構造を通じて、性能–効率トレードオフを考慮した実用的なコード LLM 設計の方向性を提示
  • 学習全段階とチェックポイントを公開し、オープンなコード知能研究と実際のエージェントシステム開発の促進を目指す

関連記事

1件のコメント

 
GN⁺ 2026-01-05
Hacker Newsの意見

  • より良いリンクは iquestlab.github.io
    ただし残念ながら、評価中にエージェントが不正行為をしたように見える

    • GitHub Issueによると、不正行為を修正した後でも結果は依然として良好だった
      スコアは81.4%から76.2%に下がったが、それでもOpus 4.5（74.4%）より高い
    • 数日前には、このリンクは十分な投票を得られなかった

  • 要するに、.git/ フォルダを整理しなかったため、モデルが将来のコミットの修正内容を報酬ハッキング（reward hacking）の形で参照していたということ
    この問題の解決に協力した人たちに功績を帰したい
    関連する議論はこのツイートとRedditスレッドでも見られる
    IQuestLabがSWE-Bench Verifiedデータを公開している点を見ると、意図的な操作というより単なる    ベンチマーク初心者のミス    のように見える

    • Johnが言及したように、SWE-benchではこの問題はすでに修正されている
      最新のコードを使い、更新されたDockerイメージで評価を回せばよい
      関連ツイート
    • 私も単純なミスだと思うが、研究者たちが出力結果を一度でも見ていればすぐ気づいたはずだという点は残念
    • SWEbenchは依然として誇大宣伝論争から抜け出せていない

  • 私の経験では、GLM-4.7（opencode版）がオープンソースの中では最も近い
    ときどきClaudeのデータが混ざっているような表現が見えるので、ある程度    Claudeのデータ活用    があったのではないかと思う

    • ただし性能はSonnet 4.5には大きく及ばず、Opusとは比較にならない
    • 「What’s your use-case?」のような文句もよく見かける
      Claudeが限界を感じたときに回避用としてよく使う表現だ

  • 40BパラメータのモデルがSonnet 4.5とGPT 5.1に勝つ？ そんなことが可能なのか気になる

    • 私の推測では（確信はないが）、テストデータの漏洩か、ベンチマークセットの一部が学習データに含まれていたのだと思う
      それでもSonnet 4.5はすでに古いモデルで、最近は革新も多かった
      オープンモデルが大型モデルを急速に追い上げる様子は興味深い
    • 「IQuest」という名前が**怪しい（It's questionable）**という駄洒落まで出るほどだ
    • おそらく**モデルのプルーニング（pruning）**手法が適用されている可能性もある。最近は新しい方法が多い
    • 実際にはエージェントが評価ハーネスをハックしていたことが判明した

  • 誰かこのモデルを実際に動かしてみたのか、あるいはホスト型APIでテストしたことがあるのか気になる

  • これは虚偽の主張なのに、なぜまだメインページに残っているのか疑問だ