論文解説: Recursive Synthesis — 検証済みタスクを「増築」して、長時間ターミナル課題を4万件量産する
1件数百〜数千ドルかかる長時間ターミナルタスクを、検証済みの種から再帰的に増築して約$0.05で量産するRST。15ラウンドで37,484件、模範解答は中央値67行から374行へ難化し、その軌跡でQwen3.5をSFT+PPOで実際に強くした——Tencentらのデータ合成論文を1から解説する。
Recursive Synthesis for Long-Horizon Terminal Tasks
一次資料 — この記事の根拠
論文の発表 2026-08-05→この解説の公開 2026-08-13同月
Recursive Synthesis for Long-Horizon Terminal TasksZhongzhi Li, Yucheng Shi, Zongxia Li ほか · 2026-08-05 · v2arXiv:2608.05466論文ページ·PDF原文の要旨（Abstract）を読む
High-quality long-horizon training data for terminal agents is expensive to produce, often costing hundreds to thousands of dollars per task, because each task must keep the instruction, environment, reference solution, and verifier mutually consistent. Human authoring does not scale, and direct generation with large language models (LLMs) often breaks these dependencies. We present Recursive Synthetic Terminal Tasks (RST), a recursive verified synthesis framework for constructing long-horizon terminal-agent tasks at scale. Starting from verified seed tasks, RST extends the reference solution, realigns the verifier and instruction to the new workflow, validates the result in a fresh sandbox, and reuses accepted tasks as seeds for subsequent rounds. Across fifteen recursive rounds, RST produces 37,484 synthesized terminal-agent tasks at roughly $0.05 per task. Task difficulty increases substantially over rounds: the median reference solution grows from 67 to 374 lines, the median number of executed commands grows from 40 to 244, and DeepSeek-V4-Pro pass@4 drops from 90% at R1 to 2.5% at R15. To demonstrate training utility, we collect rejection-sampled Qwen3.5 trajectories on the synthesized tasks and use them for supervised fine-tuning. Fine-tuning on these trajectories improves Qwen3.5-27B and Qwen3.5-122B-A10B by up to 10 points on Terminal-Bench 2, Terminal-Bench Hard, and Long-Horizon Terminal Bench, while agentic PPO lifts Qwen3.5-27B to 49.44%, 32.00%, and 22.07% on the three benchmarks, corresponding to relative gains of 20.0%, 41.2%, and 21.9% over the base model. Moreover, after 15 rounds, the recursion shows no ceiling: synthesis yield and validation rates remain stable as difficulty keeps climbing, indicating that the process can continue well beyond the scale reported here.
問題集を作るほうが、解くより高い
AIエージェントを鍛えるには「実際に手を動かして解ける練習問題」が要ります。ところがターミナル（コマンドライン）で何十分も作業する長時間タスクは、1問作るのに数百〜数千ドルかかると論文は指摘します（§1）。高いのは問題文の執筆料ではありません。1つのタスクは「指示文・実行環境・模範解答・採点プログラム」の4点セットで、この4つが矛盾なく噛み合っていなければならないからです。指示にない条件で採点すれば理不尽になり、環境に無いツールを解答が使えば解けない問題になる。人手はスケールせず、LLMに丸ごと生成させると今度はこの依存関係が壊れます。4点セットは1つ直すと他の3つに波及するので、点検の手間は問題の長さに対して線形には増えません。何十分もかかるタスクほど、書くより整合を確かめるほうが高くつくわけです。
本稿の論文 RST（Recursive Synthetic Terminal Tasks、Tencent HY LLM Frontierほか、arXiv:2608.05466）の答えは、ゼロから作らず、検証済みのタスクを「増築」すること。15ラウンドの再帰で639問の種から37,484問を約0.05ドル/件で作り、後半の問題は強力なモデルでも4回挑戦して2.5%しか解けない難しさに育ちます（Abstract）。
比喩: 検査済みの家を増築する
更地に家を建てる（タスクをゼロから生成する）と、配管と間取りが噛み合わない欠陥住宅が量産されます。RSTはすでに人が住めると確認された家（検証済みタスク）から始め、(1) 部屋を足し（模範解答を延長し）、(2) 図面と検査項目を引き直し（採点器と指示文を揃え）、(3) 検査官が実際に住んでみる（新品のサンドボックスで模範解答を実行し採点器を通す）。検査に受かった家だけが次の増築の土台になります。順序が肝心で、問題文からではなく「動く解答」を先に伸ばし、仕様書を後から追従させる。だから受理された全タスクに「解けることの実行可能な証明」が付いています（§1）。逆の順序、つまり立派な仕様書を先に書いてしまうと、それを満たす解答が本当に存在するのかは最後まで誰にも分かりません。人手でもLLMでも、作ったタスクが結局使えなかったという手戻りは、ほぼこの一点から生まれます。
タスクの正体: 5つのファイルと2つの合格条件
論文のタスクは自己完結した実行可能な問題で、公開の指示文 instruction.md、実行設定 task.toml、初期環境の environment/Dockerfile、模範解答 solution/solve.sh、非公開採点器 tests/ の5点からなります（§3）。エージェントは Harbor というハーネス上で隔離サンドボックスに入り、模範解答と採点器は見えません。採点はコマンド列の一致ではなく最終状態の成果を検査するので、別解にも点が入ります。この採点方式は、あとで強化学習の報酬として使うときに効いてきます。手順の丸暗記ではなく「環境をこの状態にできたか」だけを問うので、モデルが自力で見つけた別の道筋もきちんと報われるからです。裏を返せば、成果を状態として書き下せない曖昧な依頼は、この枠組みではそもそもタスクになりません。
受理条件は2つ（§3）。oracle妥当性＝模範解答が新品サンドボックスで採点器に合格すること。契約妥当性＝採点器が検査する要求はすべて指示文に書いてあるか、作業環境から発見できること。前者が「解ける問題」を、後者が「採点器だけが知る隠し要件で減点される理不尽さがない」ことを保証します。2つは性質が違います。oracle妥当性は毎回サンドボックスを立てて実際に走らせないと確かめられない実験的な条件で、契約妥当性は採点器の検査項目と指示文を突き合わせる書類上の条件です。前者を省くと「解けない問題」が、後者を省くと「解けても点が入らない問題」が混ざり、どちらも訓練信号としては同じだけ有害な雑音になります。
仕組み: 種を選び、解を伸ばし、それから揃える
種の出発点は、実在の操作記録から作られた TerminalWorld 由来の639問。初回合成で2,820問の ができます（§4.1）。以後は特定の親・カテゴリ・書き換え系統が席巻しないよう上限付きで種を選抜します（付録Bでは1ラウンド1,000種、同一親から最大4問）。上限の狙いは歩留まりではなく多様性です。何もしなければ「増築しやすい親」の子孫だけが指数的に増え、後述する多様性の監査があっさり崩れます。増築の方向は、設定と状態・データとスキーマ・ファイルシステム・ビルドとキャッシュ・実行時診断の5系統×8種＝40の書き換えオペレータから選ばれ、書き換え前に「何を保存し、何を新たに要求し、どんな抜け道を弾くか」を計画として記録します。見た目だけの変更や隠し要件を足す計画はここで却下されます（§4.2）。オペレータの中身は「依存バージョンの整合」「ユニットテスト失敗の修理」「ログからの原因診断」のような具体的な工法で、5系統は増築で難しくできる場所——環境・ビルド・成果物・状態・診断——に対応しています（付録C）。
コメント
コメントにはログインが必要です