エージェントの報告は12だった。実際は13だった。

ローカルで動作するコーディングエージェントを構築しています。 計画にはClaudeを、コード生成にはローカルモデルを使用しています。 最近、エージェントに簡単なタスク、つまり特定のログのカウントを任せました。

エージェントは12と報告しました。 手作業での記録に疲れを感じていたので、そのまま受け入れてしまいそうになりました。 しかし、ターミナルで手動チェックを行ってみました。 実際のカウントは13でした。

1つのエントリがイレギュラーな形式だったため、エージェントは見落としていました。 エージェントはハルシネーションを起こしていたわけではありません。 ただ「惜しい」状態だったのです。 これこそが最も危険な種類のエラーです。 信じてしまいそうなほど、もっともらしく見えるからです。

さらに悪いことに、最終的な要約メトリクスは正しく見えました。 丸め処理やグルーピングのステップが、その間違いを隠してしまったのです。 もし最終報告書だけを見ていたら、エラーには気づかなかったでしょう。 しかし、生データは間違っていました。 一度生データの測定が間違ってしまうと、その後のすべての報告にそのエラーが引き継がれてしまいます。

信頼と測定について、手痛い教訓を得ました。

作業を行うシステムに、その作業の判定まで任せてしまうと、問題が発生します。 受験者に試験官を兼任させているようなものです。 確率的なモデルを、唯一の「真実のソース（正解）」にしてはいけません。

現在、私は2つの新しいルールに従っています：

  • まず、人間が自動化のプロセスを目撃しなければならない。 自己測定システムを信頼する前に、自分自身で決定論的なカウントを実行します。 ターミナルに数字が表示されるのを監視します。 機械と人間の結果が、何度も実行して完全に一致するようになって初めて、このルールを緩めます。

  • 測定対象を、観察可能な単位に固定する。 エージェントが、人間が見ることができるものと全く同じものをカウントするようにします。 母集団の定義が曖昧だと、数値はドリフトしていきます。 母集団が厳密であれば、結果を実際に比較することができます。

このアプローチは時間がかかります。 無限にスケールさせることもできません。 しかし、これこそが信頼の基盤を築く方法なのです。

AIにコードを書かせることもできます。 AIに分析を行わせることもできます。 しかし、重要な数値に関しては、決定論的なプロセスが最終的な「証人」でなければなりません。

あなたなら、どこで線を引きますか？ どの程度の数値であれば、手動でチェックすべきだと判断しますか？

Source: https://dev.to/josephyeo/my-agent-reported-12-the-real-number-was-13-5864

Optional learning community: https://t.me/GyaanSetuAi