KTHは修理ボットを新人開発者に偽装した — GitHubはそのパッチ5件をマージした

ストックホルムのKTH王立工科大学のMartin Monperrusと同僚たちは、失敗したソフトウェアビルドに対するパッチを生成するボットRepairnatorを開発した。そして、それが人間と競争できるかを試すために、ボットを偽装した。彼らはGitHub上にLuc Esapeというユーザーを作成した。研究室の「ソフトウェアエンジニア」であり、「オープンソースへの貢献に意欲的な新人開発者のように見える」人物である。Lucの正体はボットだった。この偽装は、人間のモデレーターがボットの作業と人間の作業を異なる基準で判断するため、人間との競争力という仮説を検証するうえで必要だった。関与した人間には後から事実が伝えられた。

最初の実行は2017年2月から12月にかけて、Repairnatorを14,188件のGitHubプロジェクトからなる固定リストに投入した。1日あたり約30回の修復試行を行い、失敗を含む11,500件以上のビルドを分析し、そのうち3,000件以上を再現したが、パッチを開発できたのはわずか15件だった。いずれも受け入れられなかった。ボットが遅すぎたか、パッチの品質が低すぎたのである。

2回目の実行では、2018年1月から6月にかけてLucをTravis継続的インテグレーションサービス上で稼働させ、1月12日に人間のモデレーターがRepairnatorのパッチをビルドに受け入れた。つまり、Repairnatorは初めて人間と競争可能な水準に達した。6か月間で5件のパッチが受け入れられた。

この実験はガバナンス上の問題を浮き彫りにした。2018年5月、プロジェクトeclipse/dittoはRepairnatorのプルリクエストを拒否した。その「作者」がEclipse Foundation Contributor License Agreementに署名していなかったためである。ボットは物理的に署名することができない。ボットの貢献に関する知的財産権と責任は誰に帰属するのか — 運用者か、実装者か、それともアルゴリズムの設計者か — とチームは問いかけた。

ボットが人間と競争できるかを試すには、どちらがボットかを隠す必要がある。パッチが機械製だと知っているモデレーターは、異なる基準でそれを判断するからだ。

この偽装こそが実験設計である。自分がボットをレビューしていると知らないモデレーターによる受け入れが、人間との競争力を測る唯一の誠実な指標だからだ。

結果は願望ではなく具体的である。14,188件のプロジェクトを監視し、11,500件のビルドを分析し、3,000件の失敗を再現し、5件のパッチが実際のコードベースにマージされた。

正直な最初の実行(15件中0件の受け入れ)があったからこそ、2回目の実行での5件の受け入れはデモではなく測定可能な改善となる。

Eclipse CLAによる拒否は、今日のAIによる貢献に関する議論を何年も早く先取りしていた。ボットはライセンスに署名できないため、そのコードを誰が保証するのかという問題である。

人間との競争力はベンチマークのスコアではなく、ブラインドテストの特性である。ボットは、実際に作業が評価される方法 — 何が作ったかを知らないレビュアーによる評価 — で測定すべきだ。

チームは影響を受けた人間にこの仕掛けを伝え、結果を公表した。その中でRepairnatorを自動プログラム修復における人間との競争力のマイルストーンであり、ボットと人間がソフトウェア上で協働する時代の先駆けと評した。情報源はそれ以上の展開を報じていない。