判断の出発点
回答に必要な確かさと権限から方式を選びます。RAGは資料を検索して説明に使い、規則に沿った照会は構造化された事実を返します。ツール呼び出しは操作の要求であり、実行の検証と許可はアプリ側が行います。
具体例で考える
架空の窓口で「返品規定は」「返品は届いたか」「集荷を取り消して」と聞かれたとします。順に資料の引用、閲覧権限のある最新記録、適切な確認を伴う検証済みの更新操作が必要です。
選択肢とその負担
- 規定の説明は対話、取り消しは通常フォームでも構いません。チャットへ統合しても、権限、証拠、エラー対応を区別します。会話の便利さだけで確実な定型処理を置き換えないでください。
見落としやすい点
古い資料から現在の在庫を答えたり、モデルが作る無制限のデータベース照会を許したりしないことです。操作を狭く定義し、引数を検証し、不明な識別子は実行前に確認します。
回答を書く前に処理経路を決める
三つの質問に別々の回答条件を設けます。規程の説明は版と根拠箇所、状態照会は権限のある記録と読取り時刻、取消しは対象の集荷、許可された状態遷移、実行結果を示します。表現は会話でも、アプリ内の責任を混同しないことが重要です。
一つの文が料金の説明、状況確認、未開始なら取消しを求める場合があります。もっともらしい説明は書込み条件の成立を証明しません。正規の状態を読み、予定操作を示し、確認時に再検証します。状態が変われば説明して再判断を求めます。識別子が曖昧なら、都合のよい記録を選ばず確認します。
理解と実行の境界を試す
同名顧客の二つの集荷、完了済み集荷、権限のない利用者、取消し受付後に応答を失う外部サービスを試します。業務責任者と許容結果を定めます。正しいチャット返答は実行の証拠ではありません。完了、拒否、未解決を区別し、運用者が調べられる参照を残します。
実行機能はモデルなしでも使えるようにし、権限、引数、重複を独立して試します。規程更新は文書担当、未解決コマンドは運用、提供する操作は製品責任者が管理します。会話経路が不安定なら全業務を止めず、通常のフォームや照会を代替として残します。
依頼前に確認すること
説明、現在の事実、行動のどれを求めているか。正式な記録はどこか。重要な操作を利用者が実行前に確認できるか。これがAI連携方式の判断材料です。