「オチが成立しているか」の判定を機械化するPoCで揺れを測る
今回やったこと
記事素材の採否を助ける判定処理で、「オチが成立しているか」を評価項目に分け、判定の揺れを観測できる形にした。ここでいうオチは、目立つ一言があることではない。必要な議論を経て、課題を解消するレスが存在するかを指す。判定結果に加えて、根拠となるレス番号が実在するかも確認する。
この題材が難しいのは、分類と評価が違う仕事だからだ。話題の型を分類する処理は、同じ入力を繰り返し見た時に比較的安定していた。一方、特定のレスを「オチとして成立」と認めるかは二値の判断で揺れが出た。そこで、単一の回答だけで決める設計と、複数回の観測を集約する設計の影響を調べた。
判定基準を操作に落とす
判定プロンプトでは、課題と解消の対応を見る。解決にあたるレスがない場合に、番号を作って補うことはしない。レス番号が出力された場合は、その番号が入力中に存在するかを機械で確かめる。これにより、「オチらしい雰囲気」という抽象的な評価から、検証できる要素へ寄せられる。
ただし、構造化しても判断そのものが安定するとは限らない。この評価で同一スレッドを複数回判定した時、型の判定は15回中15回一致した。一方、オチの成立判定は同じ題材でも反転することがあった。判定の揺れは、単にモデルへ強く考えさせれば消える問題とは限らない。
多数決は測定手段として扱う
複数回の回答を集約する方法は、1回の揺れが最終結果を左右しにくくする。しかし、実行回数を増やせば入力トークンも増える。3回観測時は過半数にあたる2票以上の肯定でまとめる。同時に、現在の既定観測回数は1回で、3回の多数決は測定用オプションとして残されている。
| 観点 | 1回判定 | 複数回の集約 |
|---|---|---|
| 呼び出し数 | 少ない | 観測回数に応じて増える |
| 単回の揺れ | そのまま結果に出る | 票の分布として見える |
| 適した用途 | 運用時の低コスト判定 | 揺れの測定や基準の評価 |
ここで重要なのは、多数決を入れたことを、そのまま本番品質の向上と見なさないことだ。評価コードのコメントには、判定結果だけでは自動ゲートに使うには不十分だった経緯も記録されている。また、このモジュールは現在の本番処理から呼び出されていない。つまり、ここで説明するのは完成した自動採否機能ではなく、評価設計とその限界である。
次に評価するときの手順
まず正例と負例を用意し、人が根拠となるレスを確認する。次に、同じ入力に対する反復結果を保存し、型・候補番号・成立判定を別々に集計する。型が安定していても成立判定が揺れるなら、ひとつの総合点にまとめず、どの判断が不安定かを残す。最後に、呼び出し回数を増やした場合の費用と誤判定率を比べる。
運用へつなぐには、観測セットを固定し、正例・負例ごとの結果を追跡できるようにする必要がある。人が採否を決める補助として使うのか、後段を止めるゲートとして使うのかで、必要な精度と失敗時の扱いは異なる。判定の実験結果だけでなく、「どの経路で実際に使われているか」も記事や運用記録に明記する。
この実験から得られること
曖昧な評価を機械へ渡す時は、問いを小さな判定に分け、根拠を入力データへ結びつけると、揺れの場所を調べやすくなる。ただし、繰り返し回数を増やすことは一つの対策候補にすぎない。観測結果が改善しているか、追加コストに見合うか、現行の処理経路へ接続されているかをそれぞれ確かめて初めて、運用上の判断に使える。
更新履歴
- 2026-10-12: 初稿を作成。
訂正履歴
- なし。