以前、書いた本人の文脈を消してAIにレビューさせる話を書きました。その工程はいまも回しています。今日はその続きで、そこに一つ足した話と、足した効果をどこまで言えるのかという話です。
借りたもの
担当している領域には、書いたものをレビューしてくれる人がいません。そこで、実装した文脈を渡さないAIに、成果物と要求仕様だけを渡して、粗を探して落とすつもりで読ませています。書いた本人には自分の間違いが見えないので、文脈を持たない目に見せる、という考え方です。
8月の初めにloglassの記事を読んで、なるほどと思いました。レビューに対して、さらに検証を当てるという形です。そこで、レビュアーの指摘を受け取る役をもう一体立てるように頼みました。指摘の一つ一つを、元のコードや資料に当てて確かめさせる役です。日付の足し算を検算して1日のずれを見つけたり、編集で位置が動いた箇所の参照が生きているかを確かめたりしています。人間が最も飽きる種類の作業なので、そこを任せられるのは助かります。
頼んでいない規則が入っていた
そうして出てきた指示書を読んだら、私が指示していない規則が入っていました。
却下には、原文またはコードの引用を必須とする。根拠を示せない却下は、却下として認めず要修正に残す。
要するに、捨てる時だけ証拠を要求するようになっていました。採用する方には求めていません。私が言っていたのは「誤検知と分類するなら理由を書け」までで、引用を必須にして、根拠のない却下は却下として認めない、という形にしたのはAIの側です。
読んだ時に、なるほどと思いました。二つの誤りは、見えやすさが違うからです。本物を誤って捨てると誰も気づけません。誤検知を誤って直すと、無駄な修正が増えます。悪くすれば、正しかったものを壊します。ただしどちらも目に見えます。見えない失敗を塞ぐために、見える失敗を引き受けている形になっています。iptables の既定を DROP にして、明示的に許可したものだけ通すのと同じで、壊れた時に安全な側へ落ちます。
指摘を採用するのは楽で、却下するのは楽であってはならない。追認する側が確かめられるのは示された根拠だけなので、根拠のない却下を通さないのは理に合っています。
この規則が効く場所は決まっています。出てきた指摘は「本物」「些細だが妥当」「誤検知」に仕分けてから処理することになるのですが、その仕分けをしているのもAIです。私は全部は確かめていません。引っかかったものだけを見ています。人間の側は、そうやって注意を節約しないと回りません。つまり、見なかった分類の中で本物が「誤検知」に置かれていても、誰も気づけません。危ないのはここなので、捨てる側にだけ証拠を要求するのは筋が通っています。
もっとも、この規則で見えない失敗が実際に減ったのかは、次に書くとおり分かりません。
拾えている。ただし、どれだけかは分からない
拾えるものはあります。文書の自己矛盾がよく出ます。前の工程が終わる前に次の工程が始まる日程になっていたり、手順書の完成予定日がその手順書を使う作業日より後になっていたりします。全部自分で書いたので、全部知っているつもりになっていて見えません。
私が確かめたものは実際に欠陥だったので、効果はあったと思っています。言えないのはその先で、効果がどれだけかが分かりません。ここは分けて考える必要がありました。
自然言語処理をやっていた頃に散々使った指標で言うと、precision と recall です。出てきた指摘のうち本物がどれだけかが precision で、実在する欠陥のうちどれだけ拾えたかが recall です。
precision は測れます。 出てきた指摘を一つずつ当たれば、本物か誤検知かは判定できます。誤検知として捨てた分のリストは手元に残るので、それを別のAIに当て直させれば「捨てた判断が正しかったか」は分かる話です。手間はかかりますが有限で、私がやっていないだけです。
recall は測れません。 分母に「実在する欠陥の総数」が要るのに、誰も指摘しなかった欠陥は、定義上こちらから見えていません。数えられないものを分母には置けません。
正解が分かっているなら、レビューは要りません。
測る手立てが無いわけではありません。既知の欠陥を意図的に仕込んで、それが拾われるかを見れば recall も出ます。ただそれは日々の仕事とは別の営みで、テストを意図的に失敗させて、失敗が検出されることを確かめる類の投資になります。私はそこまではやっていません。
そして仕込む方にも限界があります。仕込んだ欠陥の分布が、実際に出る欠陥の分布と違えば、出てくる数字は実運用の recall ではありません。自分が思いつく欠陥しか仕込めないので、思いつかない型の見落としは、仕込んでも測れません。
なので正確に言うと、こうなります。捨てた判断の正しさは測れるのに、測っていません。拾い漏れの方は、この営みからは測れません。 前者は怠慢で、後者は原理です。仕込む実験は、この営みの外側の話です。この二つを混ぜて「効果は測れない」と言うのも、「効果がなかった」と言うのも、たぶん違います。
測れている側
費用の方は測れています。手順書や記事のような成果物1本につき、レビューと検証を合わせて10分から15分、10万から14万トークンほどです。
減った側は測れていません。以前は誤検知の仕分けに時間を使っていて、いまは検証役に投げているので、体感としては楽になりました。ただ以前の時間を計っていないので、比較できる数字を持っていません。
続けている理由は、正直に言えば実測ではなく、拾われた指摘を見た時の「これは自分では気づけなかった」という感触の方です。
そのうえで、この切り分けから出てくる基準を書いておきます。効果を主張したいなら、precision は監査できるので監査すべきです。recall を主張するなら、欠陥を仕込む実験が要ります。 それをやらずに「効果があった」と書くのは、感触を数字の顔で語ることになります。私はいま、precision の監査を宿題として抱えたまま、recall は分からないと承知で回しています。
(下書きはうちのAIが書き、文責は私にあります)