お題に答えを書くと測定にならない

AI に API を使わせたのは godoc だけだった の実験は、最初に流した版 (runs-v1/) が 35/35 で 天井に張り付き、条件差がまったく出なかった。原因はお題の書き方にあった。 最初のお題には「この存在チェックを3つのハンドラに重複して書きたくない。 1箇所にまとめてください」と書いていた。これは事実上、答え (Transformer を使って 共通化する) を教えてしまっている指示であり、全条件が同じ実装に収束するのは 当然だった。

一般化

お題に「重複して書きたくない」「1箇所にまとめて」と書いた時点で、それは 答えの指定であって能力の測定ではなくなる。「AI がある API を選ぶかどうか」を 測りたいなら、お題は成果物の要件だけを書き、設計方針を一切書かない必要がある。 実際にヒントを抜いてお題を作り直したところ、35/35 の天井から条件差がはっきり 出る状態 (0/5 と 5/5 に二極化する) に変わった。あわせて、実際の開発現場では ここまで親切な設計指示が事前に与えられることはまずない、という実務との 対応の観点からも、ヒントを抜いた版のほうが測定として妥当である。

実験設計上の付随知見

• 因子は1つのテンプレートから生成する。gen_api.py で条件別の API リファレンスを機械生成し、diff で条件間の差分が意図した因子 (API 形状 / ネーミング / godoc) だけになっていることを確認してから実験に流した。 5条件を手で書くと、書き方の揺れがどこかに紛れ込んで交絡要因になる。
• 判定は文字列マッチで十分だった。今回は結果が 0/5 か 5/5 に振り切れたため、 「到達したかどうか怪しい境界事例」の判定に悩む必要がなかった。逆に言えば、 もっと微妙な差 (例えばコンパイルは通るが要件を満たしていない、といった段階) まで測りたい場合は、コンパイル通過や意味的な正しさの検証まで踏み込む必要がある。
• codex 側は stdout に出力させて正規表現で抽出する方式にした。サンドボックスの 書き込み権限に依存したくなかったため。ハーネス (run_codex.sh) は出力済みの 試行をスキップする作りなので、中断・再開・部分再実行ができる。

出典

Go Release Party 1.27 の発表資料リポジトリ experiment/README.md「実験1」節、 memo.md §6。