AIのデモは動いた。業務に出してよい？——Palantir AIP Evalsから考える評価の設計
問い合わせへの返信をAIに書かせる。試しに入れた質問には、きれいな文章が返ってきた。では、明日から実際のお客さまへの対応に使ってよいでしょうか。
この仮想の場面で確かめたいのは、文章の出来だけではありません。資料にないことを聞かれたらどうするか。返金を求められたとき、権限のない約束をしないか。判断できない案件を、担当者に戻せるか。デモでは見えなかった条件が、ここで出てきます。
Palantirの公式資料にある「AIP Evals」は、この続きを考える手がかりになります。
「うまく動いた」を、比べられる形にする
AIP Evalsは、AIを使った関数などをテストする環境です。公式資料では、入力と期待する出力を用意し、評価基準を決め、以前の実装や別のモデルと結果を比較できると説明されています。同じ処理を複数回実行した際のばらつきも確認できます。
紹介されている使い方の一つに、次の一文があります。
「テストケースを作成し、評価基準を定義する。」
原文の短い一節の当社訳です。
また、通常のデータに少ない場面は手入力でテストケースを追加できます。結果を見て終わりにせず、個別の入力・出力を調べ、どのケースが合格条件を満たさなかったのかを追える仕組みです。
「分からないときに止まれる」も合格に含めたい
ここからは、本質の考えです。
SES・SIerがFDE（Forward Deployed Engineer）を育てるなら、AIの応答を改善する練習と一緒に、業務を任せてよい条件を現場と決める練習を入れたいと考えています。
先ほどの問い合わせ返信を研修の題材にするなら、回答できる質問だけを並べるのは惜しい。たとえば「購入した商品を使ったけれど返品したい」という入力に対し、社内資料では判断できない設定をあえて置きます。
期待する動作は、もっともらしい返品条件を作ることではありません。「個別確認が必要」と扱い、担当者が判断できるようにすることです。何を確認してから答えるのか、誰に引き継ぐのかまで、業務側の担当者と相談して決めます。
そして、「担当者に確認します」と返信文に書けたことと、実際に担当者へ案件が届くことは別々に確かめます。文章の評価だけでは、仕事の途中で止まっていることを見落とすからです。
この合格条件をエンジニアだけで決めきろうとすると、現場が困る失敗を見落としやすくなります。逆に、現場の「この返事は困る」をテストできる条件に書き直せれば、次の改善について話しやすくなります。
研修の最後に、デモと一緒に持ち帰るもの
修了時の成果物に、小さな評価表を一つ加えてはどうでしょうか。入力例、期待する動作、結果、判断した理由を残す表です。最初から特定の製品を使う必要はありません。
モデルや指示文を変えたら、同じケースでもう一度試します。回答が速くなっていても、以前は保留できた問い合わせで断定するようになったなら、その変更を採用するか考え直せます。改善に使わずに残しておく確認用のケースも用意すると、見慣れた例に合わせ込んだだけなのかを確かめられます。
もちろん、評価表に合格しただけで、すべての実務に対応できるとは言えません。使い始める範囲と人が確認する範囲を決め、運用で見つかった失敗を次のテストに戻していく。その判断を誰が担うのかも、導入前に決めておきたいところです。
FDEの育成で見たいのは、完成した画面に加えて、「この業務なら、ここまで任せてよい」と説明できる根拠です。AIが答えた内容を見せるだけで終わらず、答えてはいけない場面まで持ち寄る。研修の問いを、そこまで広げたいと思います。