1. 能力を伸ばしているのは、データを作る人手である

著者らの問題意識は冒頭の一文に集約されている。近年の言語モデルの能力向上は、モデルの構造よりもデータから来ている、という見立てである。最前線の研究機関やデータ事業者は、答えを検証できるエージェント向けの課題を作り、それを教師あり微調整や強化学習にかけて能力に変えている。

この生産の流れは、いまも人の労働と、人が途中に入る共同作業の上に成り立っている。課題づくりを自動化できれば、データの生産量は専門家の人数ではなく計算資源に比例して伸ばせる。対象の領域も広げられる。著者らはさらに、それが再帰的な自己改善、つまりモデルが自分を鍛えるデータを自分で作る循環の、鍵になる一段だと位置づけている。一次情報は arXiv に公開されたプレプリントであり、査読は経ていない。[1]

2. 提案の芯は「一件ずつ、受け入れ基準で判定する」評価

これまで、エージェントが作った課題の良し悪しは、その課題で学習させたモデルが後でどれだけ伸びたかで測られてきた。著者らは、これがデータ業界の実際のやり方と合っていないと指摘する。実務では、データは一件ずつ納品され、各件が決められた基準を満たすかどうかで受け入れを判断される。そのまま学習に流し込まれるわけではない。個々の課題がデータ生産の受け入れ基準を満たすかを問う評価は、これまで無かったという。

そこで作られたのが AutoDataBench である。エージェントには、元になるベンチマークの課題と、対象のモデルがその課題に取り組んだ記録が渡される。エージェントは、同じ課題群に入る新しい課題を書かなければならない。書かれた課題は、妥当性・新規性・難しさ・振る舞いの網羅という実務上の受け入れ基準で判定される。

従来の測り方

エージェントが作ったデータでモデルを学習させ、学習後の成績で良し悪しを判断する。学習の実行が必要で、どの一件が効いたのかは分からない。

AutoDataBench の測り方

書かれた課題を一件ずつ、データ生産の現場で使われる受け入れ基準に照らして判定する。学習を回さずに、課題を書く力そのものを直接測る。

3. abstract の範囲で示されたこと

評価は、実行して確かめられるエージェント向け課題からなる三つのベンチマークで行われた。既定の持ち時間である 45 分の条件では、評価したどのエージェントも、100 点満点で 20 点を超えなかったと報告されている。

一方、最も強いエージェントに四倍の時間を与えると、得点は大きく伸びた。それでも、使える課題を一件得るための費用はほとんど変わらなかったという。著者らはこれを、現在のエージェントは求められる品質の学習用課題を書くことはできるが、効率よくは書けない、とまとめている。

この結論は、あくまでこのベンチマークと、この受け入れ基準の上での読みである。「書ける」と「効率よく書けない」の両方が、同じ数字から引き出されている点には注意がいる。

4. 具体例で見る ── 資材審査を支援するエージェントの試験問題を作る

販売促進資材の審査を支援するエージェントを社内で評価していると想定する。評価には、答えを検証できる課題の集まりが要る。既存の課題の一つに「安全性情報の記載が欠けている資材を見つける」ものがあり、対象のモデルはそれを解いている。この記録をもとに、別のエージェントに新しい課題を書かせる。

受け入れを判断する担当者と、提出された課題

提出:「効能の記載が承認範囲を超えている資材を見つける課題。正解となる箇所と、判定の手順を添付」
妥当性:正解が一つに定まり、手順どおりに確かめられるか。確かめられる。
新規性:元の課題の言い換えにとどまっていないか。見る観点が違うので、言い換えではない。
難しさ:対象のモデルがすでに難なく解ける種類ではないか。記録を見ると、類似の箇所で見落としがある。
網羅:既存の課題群で試されていない振る舞いを試しているか。承認範囲との突き合わせは、まだ課題がない。
判定:受け入れ。

AutoDataBench が測っているのは、この判定を通る課題をエージェントが自力で書けるかどうかである。学習させてみて結果を待つのではなく、提出された一件をその場で基準に照らす。ここで効いているのは、対象のモデルが元の課題に取り組んだ記録が渡されている点である。難しさや網羅の判断は、その記録なしには成り立たない。

5. 何が新しくないか、abstract から読み取れない限界

言語モデルに学習用のデータや課題を作らせる試み自体は新しくない。合成データは広く使われている。この論文の新しさは生成の手法ではなく、生成物を学習後の成績ではなく一件ごとの受け入れ基準で評価する、という測り方にある。

そのうえで、abstract の範囲では分からないことが多い。第一に、四つの基準を誰が、どう判定しているのかが書かれていない。人手の審査なのか、別のモデルによる自動判定なのかで、この得点の意味は大きく変わる。100 点満点の得点が基準ごとにどう配分されているかも示されていない。

第二に、受け入れ基準を満たした課題が、実際に学習に使ったときにモデルの能力を伸ばすかどうかは、この評価の外にある。学習を回さずに測れることはこの方法の利点だが、同時に、受け入れ基準そのものの妥当性はこの論文の中では確かめられていない。

第三に、対象は実行して確かめられるエージェント向けの課題に限られている。正解を実行で検証できない領域、たとえば文章の妥当性を人が判断するような課題に、同じ枠組みがどこまで持ち込めるかは、abstract の範囲では条件が示されていない。「費用」が何を指すのか、得点が「大きく」伸びた幅がどれほどかも、abstract には数値として書かれていない。

6. この主題が今なぜ束になっているか

同じ時期に、Video-RSI という論文が arXiv に出ている。題名から読み取れる範囲では、動画理解のエージェントが、周辺の仕組みを進化させることで再帰的に自己改善する、という研究である。[2]AutoDataBench が「自己改善の循環に入れるデータを書けるか」を測り、Video-RSI が「自己改善の循環そのものを回す」側に立つ。どちらも、人の手を介さずにモデルが自分を伸ばす循環を、部品に分けて扱おうとしている。束の大きさは 2 である。

一方で、注目度を示す数字は小さい。論文共有の場での支持票は 3 件、コメントは 1 件、実装リポジトリの star は 20 件である。[4][3]今回この論文を取り上げたのは、別グループの論文が同じ主題に並んだという一点による。これらの数字は話題になっているかどうかの目安であり、主張の正しさや研究の重要さを示すものではない。

7. 製薬・規制の現場から見ると何が接続するか

製薬の品質保証では、作られたものを一件ずつ、あらかじめ定めた基準に照らして受け入れるかどうかを判断する。後からまとめて結果を見るのではなく、個々の出来を基準で判定する。AutoDataBench が持ち込んだ評価の形は、この運用と同じ向きを向いている。

実務に引き寄せると、接点は二つある。一つは、社内でエージェントを評価するための試験課題づくりである。審査の支援やコンピュータ化システムの検証に使う試験の事例は、専門家が時間をかけて作っており、その人数が評価の量を決めている。課題を書く作業をエージェントに任せる余地があるかは、実務的な関心事である。

もう一つは、受け入れ基準を誰が持つかという問題である。この論文では、基準は評価側があらかじめ定めている。自己改善の循環を自動化していくと、どこかで基準そのものまで自動で作りたくなる。しかし、何を妥当とし、何を新規とみなすかは、その業務に責任を負う人が決める事柄である。課題を書く作業は任せられても、受け入れの判断と基準の管理を手放してよいとは、この論文も主張していない。査読前の段階の研究として、評価の設計を読む材料にとどめるのが妥当である。