Recall
読み: リコール
リコールとは見逃しを測るAI指標
Recallは、AIが本来見つけるべき正解データの中から、実際にどれだけの割合を正しく抽出できたかを示す網羅性の評価指標である。見逃しをどれだけ防げたかを測るための重要な基準となる。
かんたんに言うと
砂浜に落とした100個のコンタクトレンズを探すとき、ゴミを拾ってでも99個見つけ出す能力のこと。
本来見つけるべきデータをAIがどれだけ拾えたかを測るRecallの仕組み
Recallの計算式はシンプルである。True Positiveを、True PositiveとFalse Negativeの和で割る。要するに、本当に正解であるもののうち、AIがどれだけ正解と予測できたかを示す。
混同行列を眺めていると、現場の悲鳴が聞こえてくることがある。
False Negative、つまり本当は正解なのにAIが見逃したデータ。これがゼロに近づくほどRecallは1.0に張り付く。
だが、数字遊びに陥ってはいけない。Recallが1.0のモデルを作るのは世界一簡単である。すべてのデータを正解と予測すればいい。当然、実務では使い物にならないゴミの山が生成される。
営業や法務の現場で直面する見逃しの代償
なぜ我々はRecallにこだわるのか。見逃しが致命傷になる業務があるからである。
例えば営業部門でSalesforce Einsteinを使って離反リスクのある顧客を予測する場合。離反しそうな顧客を見逃せば、売上は確実に吹き飛ぶ。誤検知して余計なフォローの電話をかけるコストより、見逃しのダメージのほうが遥かに大きい。
法務の契約書審査でも同じである。Kira SystemsのようなAIで不利な条項を抽出する際、一つでも見落とせば訴訟リスクに直結する。Zendesk AIで激怒している顧客のクレームチケットを分類する時も、優先度高を見逃すわけにはいかない。
Amazon Personalizeでレコメンドを出すのとは訳が違う。あちらは多少的外れな商品が出ても誰も死なない。
適合率との終わらないシーソーゲーム
Recallを上げようと閾値を下げると、今度はPrecisionが急降下する。
これがトレードオフの呪いである。
網羅性を高めれば高めるほど、AIは自信のないデータまで正解として拾い上げてくる。結果として、現場の担当者は大量の誤検知アラートの確認に追われることになる。
F1スコアという調和平均をとってバランスを見る手法もある。だが、現場の運用設計においてバランスが良いモデルが常に正解とは限らない。
どちらの指標を犠牲にするか。この決断をAIベンダーに丸投げするマネージャーは後を絶たないが、それはビジネスの責任放棄である。実運用を考えると非常に悩ましい。私は常に現場の運用コストを計算して決めている。
評価軸を決定するための泥臭い判断基準
AIのPoCを始める前、必ずKPIの算定を行うはずである。
その際、Recallを優先すべきかPrecisionを優先すべきか、ROIの観点からシビアに計算しなければならない。
製造ラインの不良品検知でRecallを99%に設定した結果、正常な製品の半分を不良品として弾くようになったらどうなるか。歩留まりは最悪になり、再検査の人件費でプロジェクトは赤字に転落する。
見逃しの損失額と、誤検知を人間がカバーする人件費。この二つを天秤にかける作業は、AIのアルゴリズムをチューニングするよりよほど骨が折れる。
結局のところ、モデルの精度指標は経営の意思決定そのもの。現場の運用に落とし込んだとき、誰がそのアラートの山を処理するのか。そこまで想像できているだろうか。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。