ローカルLLMの「確信度」をどう測るか。Local Front Desk開発でつまずいた話。

Local Front Desk を実際に動かしてみて、一番難しかったのは「AIにどう答えさせるか」より、「どこまで確信が持てる時だけ返すか」でした。今回は、公開デモの裏側で詰まった判定ロジックと、その修正で見えてきた実務上の勘所をまとめます。

まず、候補全体との相対評価を見る。

Local Front Deskの仕組みは、質問文とあらかじめ用意した情報をベクトル化し、意味の近さで検索します。ただし、近いものが見つかったからといって、それをすぐ答えとして良いわけではありません。無関係な質問にも、候補の中の「一番近いもの」は必ず存在してしまうからです。

そこで使っているのが、1位の候補と候補全体の平均との差を見る、Local Front Desk独自のマージンです。1位の候補が、コーパス全体の「background noise」からどれだけ浮いているかを見て、浮いていなければ「十分な確信が持てない」として、人間に回します。

絞り込んだ後に測り直すと、正しい答えでも自信を失う。

このマージン判定に、実際に動かして初めて気づいた欠陥がありました。「この製品についての質問」のように、候補をあらかじめ絞り込んだ後にマージンを測り直すと、絞り込んだ候補同士がお互いに似ているせいで、平均が釣り上がってしまうのです。

具体的には、ある製品に関する問い合わせで、正しい候補が5件中5件ヒットしているにもかかわらず、絞り込んだ5件だけを母集団にしてマージンを計算すると0.02しか出ない、ということがありました。同じ候補を、絞り込む前の全体74件を母集団にして計算し直すと、0.2を超える明確な値になりました。

原因が分かれば対策は単純です。マージンは常に「絞り込む前の全体」に対して計算し、質問による絞り込みは「どれを候補として残すか」だけに使う。この2つの役割を混同しないことが大事でした。

相対評価だけでは、無関係な質問を弾ききれない。

もう一つ、別の落とし穴もありました。「御社の資本金はいくらですか」という、用意した資料のどれとも関係ない質問に対して、料金表の資料が自信満々に返されてしまったのです。

調べてみると、この時の類似度は0.37程度でした。正しく資料が見つかる時の類似度はだいたい0.6〜0.7なので、絶対値で見れば明らかに弱い一致です。しかしマージンだけを見ると、たまたま1位が他より浮いていたため、判定を通過してしまっていました。

相対指標は「他と比べてどうか」しか見ておらず、「そもそもどれくらい似ているか」という絶対的な下限を見ていなかったことが原因です。以後、絶対的な類似度の下限も追加し、二重にチェックするようにしました。

ここで紹介した0.37、0.6〜0.7といった数値は、使用した埋め込みモデルとデモ用データの組み合わせで得られた値です。別のモデルや資料へ、そのまま判定基準として流用できるものではありません。実際の導入では、お客様ごとの資料と質問例を使って調整します。

検索の「確信度」と、アクセス権限は別に考える。

資料との類似度が高いことは、その利用者へ情報を返してよいことを意味しません。閲覧権限、個人情報の扱い、回答してよい質問の範囲は、検索スコアとは別に判定します。検索で見つかった後に、権限や業務ルールを確認してから返す。この分離も、社内データを扱ううえで欠かせません。

外部メールでは負担をかけず、Answerでは評価を残す。

もう一つ工夫したのは、AIが選んだ答えが「外れ」だった場合の対応です。Guideなどの外部メールでは、AIは自分が送った答えが実際どう受け取られたかを知る手段を持ちません。かといって、お客様に毎回「合っていましたか？」とフィードバックを求めるのも負担になります。

• 一度送った答えへの返信は、内容を問わず必ず人間が確認する。
• 同じ相手から、短時間のうちに似た質問が再送されてきたら、「前回の答えは外れていたかもしれない」という印だけを記録する。

これらは月次・週次で人間が見返す前提の、控えめな仕組みです。一方、Answerの専用Web UIには、質問者が検索結果を評価する機能があります。公開デモでは一部を省略していますが、この評価もAIへ自動学習させるためではなく、人が資料や検索条件を見直すための記録として使います。

モデルを大きくするより、呼び出し回数を減らす方が効いた。

性能面でも発見がありました。判定の精度を上げるために、候補の絞り込み後にもう一段、AIによる再確認を挟む設計にしたのですが、これを候補1件ごとに逐次呼び出すと、応答に十数秒かかることがありました。

「モデルを大きくすれば速くなるのでは」と考えがちですが、実際には逆で、モデルが大きいほど1回あたりの応答は遅くなります。効いたのは、複数の候補をまとめて1回の呼び出しで判定させることでした。5件を1件ずつ判定していた時は16秒程度かかっていた処理が、まとめて1回にしたところ4秒程度まで縮みました。

処理時間は、当時のデモ環境、使用モデル、候補数での実測値です。機材やモデル、対象データによって変わるため、一般的な性能を保証する数値ではありません。

Guideは、送る・聞き返す・人へ回す、の三方向に分ける。

実装を確認すると、Local Front Desk Guideは単純に一番近い資料を送るだけではありません。資料との近さが弱い場合は人間へ回し、候補が近接している場合は候補を示して聞き返し、1件だけが明確に浮いている場合だけ資料送付に進む作りです。これは公開フォームとして見せている動きでもあり、製品説明上もこの三方向の分岐で理解してもらう方が実態に近いです。

たとえば「料金を知りたいです」という質問では、料金表と現地調査・見積り案内の両方が近く、即送付ではなく候補確認になります。一方で「御社の資本金はいくらですか」のような登録資料と関係の薄い質問は、類似度の絶対値が低いため人間確認へ回ります。ここは、誤送信を避けるための重要な分岐です。

実際に動かしてみないと、分からないことばかりだった。

ここに挙げた不具合は、どれも設計段階の想定問答では気づけないものばかりでした。「動くはずのケース」を確認して終わりにせず、意地悪な質問や無関係な質問を実際にぶつけてみて、初めて見つかったものです。

架空データでの試作段階ではありますが、この「実際に動かして、壊れる場所を見つけて、直す」というプロセス自体は、実際の導入でもそのまま活きると考えています。