意図が不明なときの対応：未知意図の識別、拒否判定、明確化のための質問

意図識別器がカテゴリを確定できないまま、無理にラベルを選ぶと、誤処理につながる可能性があります。ユーザーが「請求書を発行してください」と求めても、システムに請求書発行機能がなければ、ホテル関連の語が含まれているという理由だけで注文照会へ回してしまいます。ユーザーが「そっちをキャンセルして」と言った場合も、どの注文なのかを確認せずに操作を進めてしまいます。システムでは、リクエストが業務の範囲外なのか、目標を特定するために必要な情報が欠けているのかを区別する必要があります。

本稿では、範囲外の要求、解釈の曖昧さ、パラメータ不足、サービスの temporary な利用不可を区分し、拒否するか確認質問をするかを判断する方法を示します。さらに、同じチュートリアル用データセットを使って実際に閾値を選び、カバレッジとエラーも確認します。完全なコードとデータはダウンロードして再現できます。

一、不確実性の原因を 구분する

最後の場合は、意図が不明なわけではありません。ツール障害を範囲外として分類すると、後続のエラー分析で理解失敗とサービス失敗を区別できません。

範囲外でも、意味がないわけではありません。ホテルでの請求書発行は合理的な要望ですが、現在の機能一覧に含まれていない可能性があります。CLINCは、既知クラスの分類と範囲外入力の検出を、それぞれ確認すべき課題として扱っています。評価設計の参考にできます。CLINC論文

二、候補スコアを理解する

分類器の候補が「照会」「予約」「キャンセル」の3クラスだけだと考えます。入力がどれであれ、最大スコアのクラスは必ずその3つのいずれかです。範囲外判定や拒否戦略がなければ、モデルは「適切な候補がない」ことを表現できません。

スコアの種類によって、示せることも異なるため、次のように整理します。

確率校正は、予測スコアと実際に観測された事象の頻度が一致しているかを調べる分野です。校正の効果はデータ分布に依存します。現在の入力が校正用データと大きく異なる場合は、見直しが必要です。scikit-learnの確率校正ドキュメント

三、最高スコア閾値と候補スコア差

単純で METHODS な方法としては、まず最高スコアが十分な水準にあるかを調べ、その次に上位2候補の差が小さすぎないかを調べます。

プロジェクトルートで実行すると、3つの結果は順にabstain、clarify、selectになります。これらの小数値は merely ポリシーの分岐をテストするためのもので、推奨する閾値ではありません。

最高スコアが低い場合は、現在のモデルが十分な根拠を得られていない可能性があります。範囲外の場合もあれば、モデル能力が不足しているだけの場合もあります。上位2候補のスコアが近い場合は、候補を区別しづらいことを示しますが、ユーザー表現そのものに曖昧さが含まれるとは限りません。そのため、このコードが返すのは「候補を選ぶことを拒否する」と「さらに区別が必要」という2つの結果です。スコアが低い入力を直ちに範囲外と判定することはありません。

スコアが同点の候補では、例のコードが明示的に質問の分岐に進むため、ラベルの並び順で結果が決まることはありません。非有限値も拒否します。NaNが比較に使われた際に、条件に意図せず通ってしまうのを防ぐためです。

四、エラーのコストに応じて閾値を選ぶ

今回のチュートリアル実験では、学習用データとは別に28件の検証サンプルを用意しました。21件は7つの既知クラスに属し、7件は現在の範囲外です。検証セットで閾値とスコア差を探索し、選んだパラメータを固定してから、別の21件のデモンストレーション用チェックサンプルで実行しました。

トレードオフを示すために、あらかじめ次の損失を用います。

损失 = 5 × 错误接收数 + 1 × 已知请求被拒绝选择的数量

誤受理には2種類あります。範囲外入力を受理した場合と、既知入力を誤ったラベルに割り当てた場合です。拒否も確認質問も、どちらもその回にはラベルを選んでいないものとして扱います。そのため、既知リクエストには1回分のコストが加わりますが、範囲外リクエストでラベルを選ばない場合はコストが加わりません。

5:1という設定は、誤受理を減らすくらいなら確認を1回追加してもよい、という優先順位を表しています。注文キャンセルを取り違えた誤りは、通常、メニュー照会を取り違えた誤りよりコストが高くなります。実サービスでは操作ごとにコストを設定し、確認質問による離脱や人手対応のコストも併せて考慮できます。

まず検証セットでパラメータを選び、別のデータで固定した方式を確認すれば、最終結果を見ながら閾値を何度も調整する事態を避けられます。具体的なグリッドと結果はダウンロードパッケージにあります。

最高スコア閾値を0にしたのは、無条件に受理することを意味しません。ルールは依然として、キーワードが一切一致しない場合や、最高スコアが同点の場合を拒否します。TF-IDFも候補スコア差の条件を通過する必要があります。最高スコア閾値とスコア差閾値の2条件は、併せて判断してください。

たとえば、この入力群ではTF-IDFが受理したのは6件だけでした。カバレッジが低いほど、より多くのリクエストが質問や別の処理経路に入ります。この戦略を評価する際は、誤分類のコストと後続処理のコストを同時に考え、単一指標だけを見てはいけません。

五、閾値方式の限界

高い閾値を使えば、弱い一致による誤受理の一部を減らせます。ただし、表現は自然でも、学習例から距離の遠い正しいリクエストまで拒否してしまいます。誤った入力と正しい入力のスコア分布が重なる部分が多い場合、1つの閾値だけで高いカバレッジと低い誤り率を両立することはできません。

同様に、候補スコア差は、既存クラス間の相対的な関係しか比較しません。範囲外のリクエストは、どのクラスにも合致しない一方で、ある1つのクラスには明らかに近いことがあります。ラベルの定義が重なっているため、既知のリクエストでもスコア差が小さくなることがあります。

このような場合は、ラベルの境界、ハードネガティブ、表現モデル、学習データを確認します。必要に応じて範囲判定モジュールを追加したり、ルーティングを変更したりしてください。閾値を細かく調整し続けても、検証セットを過学習するだけです。

六、具体的な確認質問を作る

「何がしたいんですか」という質問は、通常、すでに得た情報を無駄にします。確認するときは、すでに得た情報を活用し、まだ明確になっておらず、後続の処理に影響する内容だけを尋ねます。

質問で提示する選択肢は、必ず現在の状態や実際の候補から作らなければなりません。モデルが実在しない注文番号を作ると、質問そのものが誤解を招きます。

確認質問の後は、状態も更新する必要があります。たとえばユーザーが注文Aを選んだなら、注文スロットを現在のキャンセルタスクに紐付け、古い候補質問を無効化します。質問を出すときは、回答待ちの質問も保存し、次のターンで処理を続けられるようにします。

七、確認質問の上限を設ける

同じ情報不足を2回連続で解消できなかったら、同じ文面で質問し続けてもユーザー体験は改善しにくいでしょう。添付ファイルには、スロット不足、曖昧さ、支持度不足、未対応機能を見分ける小さなポリシー関数と、試行回数の上限の例が入っています。

この例では上限を2回に設定しています。ポリシーの分岐を示すためだけのものです。実サービスでは、情報不足やタスクごとに試行回数を記録し、問題が解決したらリセットする必要があります。また、ユーザーの状態に応じて、人手を介する窓口を案内するか、タスクを終了するかを決めます。この関数には、完全な会話カウンターと有人対応の仕組みは実装されていません。

ユーザーが現在のタスクを明確に放棄したときは、その意思を優先し、タスクのパラメータ収集を止めるべきです。「予約はもうやめます」という発言は、会話内の予約タスクを取り消すものです。実際の注文を自動的にキャンセルする処理へ変換してはいけません。

八、拒否判定の効果

evaluate

「受理されたサンプルの中での正答率」だけを報告すると、大量の拒否を隠してしまう可能性があります。カバレッジ、受理したものの誤り率、範囲外入力が誤って受理された件数を併せて示してください。

覆盖率 = 接收并选择标签的样本数 / 全部样本数
选择性错误率 = 错误接收数 / 接收样本数

受理サンプルが0件のときは、選択的誤り率には分母がないため、0%ではなく未定義とします。すべてを拒否するシステムは誤った動作を一件も行わなくても、使えるサービスを提供できたことにはなりません。

既知クラスの誤拒否率、高コストな操作ごとの誤受理、確認後の成功率、平均質問回数も個別に確認すべきです。単一ターンの閾値実験だけでは、複数ターンからなるタスク全体が完了するかどうかを評価できません。この部分は後続の評価記事に任せます。

九、注文キャンセルの確認例

ユーザーが「そっちをキャンセルして」と言い、システムに2件の注文があります。この場合、キャンセルする意図は明確でも、対象は一意に決まりません。「DEMO-AとDEMO-B、どちらをキャンセルしますか？」と確認します。ユーザーがAを選んだら、キャンセル料も確認します。「キャンセル料がかかるならやめます」と補足されたら、その条件をタスクに記録し、無条件のキャンセルを続けたままにしてはいけません。

キャンセル料の照会が失敗した場合は、問題がサービス利用不可に変わります。照会の結果、キャンセル料によると、問題は条件を満たさない状態に変わります。どちらの場合も、ユーザーに意図を説明し直すよう求めるべきではありません。確認質問では、現在不足している情報だけを補ってもらい、回答に基づいて状態を更新して、次の処理を選びます。

例は、確認質問の成功を「ユーザーが返事したかどうか」だけで測れないことも示しています。より有用な判断基準は、返答が元の曖昧さを解消したか、状態が正しく更新されたか、誤った動作が減ったかです。

拒否は、現時点ではカテゴリを信頼して選べないことを意味します。システムはその原因に応じて、追加で質問するか、対応範囲を説明するか、別のサービスへ引き渡すかを選びます。

さらに読む：基本手法の検証、ラベル設計、複数ターンの状態、シリーズ全体の概要。

発展記事

• 意図識別の評価方法：分類精度から複数ターンタスクの成功率まで。
• 意図識別サービスの本番展開：レイテンシ、コスト、監視、エラーのフィードバックループ。