「適当にまとめて」「少し短くして」「いつものように処理して」。人間同士では通じることがあっても、必要な条件が言葉にされていない指示です。

AIが足りない情報を勝手に補えば、軽微な好みの違いで済む場合もあれば、安全や金額に関わる事故になる場合もあります。重要なのは、何でも質問することではなく、確認が必要な曖昧さを見分けることです。

曖昧さには種類がある

AmbiKは曖昧な指示と明確な指示を対にした

AmbiKには、キッチン環境の曖昧な指示1,000件と、対応する明確な指示1,000件が収録されています。確認質問、回答、利用者の本来の意図、作業計画まで一組になっています。

質問しすぎるAIも使いにくい

すべてを確認すれば安全に見えますが、利用者は毎回細かく答えなければなりません。常識的に補える条件、過去の設定から推定できる条件、その場で聞かなければならない条件を区別します。

確認質問のデータでは、「何を聞くか」だけでなく「この時点で聞く必要があるか」を評価します。誤って推定した場合の影響や、質問によって処理結果が変わるかも判断材料です。

正解は質問文だけではない

「何を確認すべきか」「どのように聞くか」「回答後に計画をどう変えるか」を一続きで評価します。丁寧な質問を生成できても、その回答を実行へ反映できなければ問題は解決しません。

不足した条件を規則文から発見する

制度や業務ルールには、複数の条件と例外が含まれています。ShARCでは、規則と利用者の状況を照合し、結論を出せるなら回答し、情報が足りなければ追加質問を行います。

質問の根拠となる規則と、確認後の最終判断を対応させることで、AIが勝手な条件を追加していないか確認できます。

日本語特有の省略を集める

日本語では主語や目的語を省き、共有知識へ依存することが多くあります。「例の件」「前と同じ」「いい感じに」など、職場や家庭で使われる表現を領域別に集める必要があります。

「少し」「適当に」のような程度表現は、単純に禁止したり一つの数値へ置き換えたりできません。変更幅を確認できる指示と、見本や比較候補を示さなければ共有できない好みを分けて扱います。

実務データは失敗例から作れる

問い合わせ履歴、差し戻し、作業者からの質問には、仕様のどこが曖昧だったかが現れます。個人情報や機密情報を除き、実際に確認が必要だった事例を抽象化すれば、現場に近い評価データを作れます。

修正前の指示、作業者の処理、差し戻し理由、確認質問、修正後の指示を一組にすると、曖昧さの検出と明確な書き換えを同時に評価できます。