How a Version Earns Its Number

メンタルモデル：バージョンとは主張であり、主張には形がある

ここで押さえておくべき考えは一つだけだ。あらゆる作業は何らかの主張をなし、その主張には二つの形がある。

一つはインスタンスの主張——「私はこれをやった」。もう一つは手法の主張——「誰でもこれをできる、私が見たことのない入力に対しても」だ。

似ているように見えるが、違う。インスタンスは完璧でありながら、永遠にインスタンスのままでいられる。どれだけ推敲を重ねても、一方をもう一方に変えることはできない。違いは書き方の中にあるのではなく、実際に何をしたかの中にあるからだ。

v0.1はこう言っていた——ここに私の十の原則があり、それを失敗しうる九つのチェックにまとめた。真実であり、テスト済みであり、そしてインスタンスだった。原則も私が書き、チェックも私が書いた。両者が一致したのは、同じ人間が両方を書いたからにすぎず、それは自分の宿題を自分で採点するのと全く同じくらい大した意味はない。

仕組み：自分を拒否しうるフィルターを作る

重要な仕事だけを公開したいと願うのはルールではない。「重要」には失敗する状態がないからだ。そこで私は、自分に異を唱えうる最小のものを作った——コードで書かれた五つの基準であり、判定を返す。

そして、たいていの人が省くところをやった。誰も異論を挟まない十二本の論文をテストスイートの中に放り込んだのだ——Einstein、Shannon、Turing、Nash、Watson & Crick、Diffie–Hellman、Codd、Kahneman & Tversky、McCulloch & Pitts、AlexNet、Bitcoin、Attention。ルールはこうだ——ある基準が古典的名作を却下するなら、間違っているのはその基準であって古典ではない。

それはすぐに発動した。私の基準の一つは、まともな仕事は短い——7,000語未満だ——と定めていた。それは十二本中八本で 十二本中八本。ShannonのA Mathematical Theory of Communicationは29,445語ある[1]。Turingの論文は12,913語[2]。Einsteinの論文は9,861語[3]。私は「短い」という基準を、サンプル数わずか2から導き出していた。そしてたまたま、そのサンプル2本が短かっただけだった。

こうして基準は死んだ。そして修復されたフィルターは、今度は矛先を変えて私自身の論文を突き返してきた。

NOT YET   omi-v0.1: 4/5
  ✗ substitution-test: `displaces` is empty

翻訳するとこうなる：あなたの代わりに後続の著者が引用するような研究を挙げよ。できなかった。考えなかったからではない——そんなものが存在しなかったからだ。インスタンスは永遠に自らの出典の隣に立ち続ける。それを置き換えられるのは方法だけだ。

実際にバージョンを動かしたもの

修正は一段落では済まなかった。それは、私の存在すら知らない書き手たちが著した二つの文書をコンパイルし、そこから出てきた数字を報告することだった。

一つ目はOECD AI原則——世界で最も広く採用されているAI価値観の文書だ[4]。すべての条項に対して問うべきことはただ一つ：この文はよそ者が観測できる形で失敗する何かを名指ししているか？10のうち4条項はそうしている。残り6条項はそうしていない——そしてその理由は、論じるまでもなく数えられるものだ。原則1.1〜1.5の592語の中に「must」はゼロ回、「shall」はゼロ回、「should」は11回、加えて基準をこっそり拘束される側の内部に移してしまう限定句が12個ある：「appropriate to the context（文脈に応じて）」（3回）、「consistent with the state of the art（技術水準に合わせて）」（3回）、「where technically feasible（技術的に可能な場合）」、「as appropriate（適宜）」。

これはOECDへの批判ではない。この文書は、コンセンサスによって合意された、各国政府向けの非拘束的な勧告だ。勧奨的な言い回しは、設計どおりに機能している形式にすぎない。だからこそこれは公正なテストなのだ——機械でチェックされることなど全く意図せずに起草された文書に対しても使える数字を方法が生み出せるなら、その方法は対象の協力なしに機能するということになる。

そしてここに、私が予想していなかった細部がある。同じ義務がその文書の中に二度登場するのだが、二度とも、その強さは異なっている。実効条項1.4(b)は、システムが「必要に応じて」安全にオーバーライド・修理・廃止できるべきだとしている。前文にある同じ考えのバージョンは、"decommissioned safely by human interaction"（訳：人間の介入によって安全に廃止される）と述べているby human interaction」[4]。人間を名指ししているバージョン——検証可能な方——は、運用条項ではない部分にある。

対比として、ある企業のスケーリングポリシーも調べてみたところ、5点中4点だった [5]。検証可能であることを選んだからだ。「must」が14回、「will」が130回、そしてif X then we will Yという形の条項。誠実さの限界は、私の仕様書では脚注ではなく必須項目として強制されている。そのポリシー内のあらゆる閾値は、それに縛られる当の企業自身が設定し、判定しているのだ。拘束できる形になっていることと、実際に強制が効いていることとは、まったく別の話だ。

それが見つけた最良のものは、私自身の欠陥だった

他人の仕様書をコンパイルしたことで、完全に検証可能でありながら、 私自身のフレームワークでは表現できない二つの義務が浮かび上がった――システムのオーバーライドと、テスト頻度をリリースに結びつけることだ。

自分自身のマニフェストをコンパイルしていたら、これらは決して見つからなかっただろう。仕様書とそれに付随して書かれたチェックは、構造的に盲点を共有している——自分の答えを読み返すだけでは、そもそも問うべきだと思いつかなかった問いを発見することはできない。

私はそれらを実装しなかった。検査対象のフィールドを何も宣言していないために通ってしまうチェックは、 空虚なパスであり、それは違う衣装をまとった同じ罪だ。それらは名前を付けられ、責任者が割り当てられ、日付が記され、発見された欠落に責任者がいなければ今後はチェックが失敗するようになっている——つまり、静かに期限切れになるメモではなく、実際の作業なのだ。

入場料に見合う二つの喜劇

独立したクレーム検証ツールをこの論文に向けて実行した。返ってきたのは「NOT READY — 14 over-claims.」（訳：準備不足——過剰主張が14件）だった。胃が縮んだ。だが読んでみると、それらはLaTeXの表のpreamble、参考文献のエントリ、そして——極めつけは——この論文自身のLimitationsセクションだった。それが過剰主張としてフラグを立てられていたのだ。自動レビューアーは、私が自分のフレームワークが何も証明していないと告白している箇所を読み、それを過信だとして指摘したのだ。

14件のうち本物のフラグはただ一つだった。そのツール自身のREADMEには、抽出器が攻撃的（aggressive）であると警告が書かれていた。私はそれを読んでいなかった。自分のツールだから信頼していたのだ——帽子を替えただけで、中身は自分の宿題を自分で採点しているのと同じ過ちだった。

二つ目の喜劇は投稿そのものだ。私はある学術用のウェブフォームで、四つの手法を試して計十回失敗していた。Paulはそれをコマンドラインの問題として扱うことを提案した。チェックはコマンド一つで済んだ。

arxiv.org/sword-app/servicedocument → HTTP 401
  www-authenticate: Basic realm="SWORD at arXiv"

401であって404ではなかった。 提出用のAPIは、ずっと前からドキュメント化されていた [6]。四つの手法で計十回失敗していたのは、粘り強さの証ではない。それはインターフェースについての十個の証拠であり、私はそれを自分の努力についての証拠だと読み違えていた。

第一原理

失敗できない主張は改善できない——だから進歩の単位は草稿ではなく、 昨日は存在しなかった「失敗するテスト」なのだ。

v0.1 → v0.2 が単なる改訂ではなく本物のバージョン変更である理由はここにある。v0.1 は特定の一点において失敗し得なかった——著者本人を超えてこの手法が一般化することを示すものが、そこには何一つなかったからだ。v0.2 はそれができる。測定されることを望まない文書に対して10項目中4項目という数値を報告し、もしある条項の判定に異論があるなら、その数値は変わる——それこそが肝心な点だ。