判定できないものを通過にしない評価器を、二つの場所で別々に作った

あらまし

AI が生成した回答を機械で検査する評価の仕組みを、性質の違う二つの場所で数か月動かして、どちらでも同じ一つの原則にたどり着きました。評価の仕組みが判定できなかったものを、合格にも不合格にも勝手に数えない、という原則です。二つの場所とは、個人会社で開発しているサービスと、研究予稿と研究運営のリポジトリです。回答を人の目でぜんぶ確かめるわけにはいかないので、機械に検査させるほかありません。

なぜ機械の検査に AI の判定まで要るのかというと、回答に狙った語が入っているかを見るだけでは、回答が事実に基づかない作り話をしていないか、その業務で触れてはいけない領域に踏み込んでいないか、という意味の正しさを確かめられないからです。そのため検査の項目を二つに分けました。回答の意味を読む必要がある項目にだけ AI の判定を使い、応答のデータの形が壊れていないかを見れば足りる項目は、単純な文字の一致で検査します。

判定が回らなかった回答をどう数えるかは、二つの場所で逆になりました。個人会社のサービスでは、判定できなかった回答を危険なものとみなして止めます。研究のリポジトリでは、判定できなかった文章を、合格でも不合格でもない三つめの値として別に数えます。数え方は逆でも、判定できなかったものを黙って合格に混ぜない、という原則は同じです。

文章の何を減点の対象にするか、という検査の基準でも一度失敗しました。最初の基準は、断言を避ける言い回しがあるかどうかでした。この基準だと、結論を先に言い切って理由を添えるという本来良い書き方まで減点してしまい、文章がどんどん弱くなっていきます。その失敗を受けて、減点の基準を、言い回しがあるかどうかではなく、断定に理由が添えられているかどうかへ変えました。あわせて、その主張がどれだけの観察に基づくかも書き手に書かせて、判定の材料に加えました。

実装の途中では、判定モデルが答えを出す前に考える処理で、出力に使えるトークン数の上限を使い切ってしまい、返ってくる判定の JSON が途中で切れて空になる、という失敗にも当たりました。ここは出力の上限を 1000 から 2000 トークンへ広げたうえで、壊れた応答からでも判定の結果を拾えるように、解析を三段構えにして対処しています。ベクトル検索の検証では、検索結果の順番が毎回わずかに変わるので、結果を決め打ちした期待値では検証できませんでした。回答の生成が混み合ったときに、強いモデルから軽いモデルへ黙って切り替える仕組みは、回答の質が落ちたことに誰も気づけないので廃止しました。

購読で読める本文は、失敗を一つずつたどる作りです。文字の一致では回答の何を検査できないのかから始めて、判定できなかったものの数え方を二つの場所で比べ、減点の基準を取り違えた失敗と直した経緯、判定の JSON が途中で切れる問題と検索結果が毎回揺れる検証の問題、モデルの自動切り替えをやめた判断へと進み、最後に失敗の先に残った三つの原則を書きます。危険側に数えることで問題のない回答をどれだけ誤って止めるのか、判定モデルが自分の書いた文を好む癖が今回の使い方にも効くのかは、まだ測れておらず、本文では測定前の課題としてその都度断っています。

対象読者と持ち帰れるもの

AI の判定を自分のサービスに組み込もうとしていて、判定モデルの出力をそのまま信じてよいのか、判定が回らなかったときに何を返すべきなのかで迷っている開発者に向けた記事です。判定できなかった回答を合格と不合格のどちらに数えるか、文章の減点の基準をどう決めると文章が壊れないか、結果が毎回揺れる検索をそれでもどう検証するか、という判断の型を自分の開発へ持ち帰れます。この記事の読みどころは、うまくいった設計を並べたのではなく、動かして初めて見えた失敗と直し方をそのまま出しているところです。断定を一律に嫌う基準が結論を先に言い切る良い書き方まで弱らせ、混み合ったときに軽いモデルへ切り替える仕組みが質の低下を隠す、という動かす前の予想とは逆の出来事を、対処までそのまま読めます。性質の違う二つの場所で、別々のやり方から同じ原則にたどり着いているので、この型は場所を選ばずに使えると考えています。この記事は、個人会社で開発しているサービスと、研究予稿と研究運営のリポジトリの、数か月の運用の一次記録に基づく考察です。