RAGとAgentにおける意図ルーティング：検索、ツール、雑談、明確化

「キャンセル料がかかりますか」と聞かれた場合はポリシーを検索し、「私の注文を調べて」と指示された場合は個人の注文を読み取ります。「無料ならキャンセルもお願いします」と依頼された場合は、まず事実を確認して条件を判断し、操作フローに入ります。この3つの発言はいずれもホテルとキャンセルに関するものですが、処理経路は異なります。

意図ルーティングは、識別結果に応じて適切なサービスまたは処理フローを選びます。ユーザーの目標、現在の状態、パラメータ、業務上の制約を併せて考慮する必要があります。このホテルアシスタントを例に、知识検索、読み取り専用ツール、書き込み操作、明確化という4つの処理経路を紹介します。コードは完全な実装にあります。

一、意図識別とルーティングの分担

分類器が cancel_booking を返しても、ユーザーがキャンセルを望んだことを示すだけです。ルーティング層は、どの注文をキャンセルするか、その注文の所有者が誰か、キャンセルが許可されているか、料金はいくらか、ユーザーが現在の案を確認したかを把握する必要があります。

これらの問題をすべてタグで処理すると、「キャンセルするが注文番号がない」「キャンセルで料金が発生する」「キャンセルが承認済み」などのカテゴリを次々に追加すること 됩니다。タグ数は処理状態とともに急速に増え、アノテーションも安定して維持しにくくなります。

より明快な構成は、意図が目標、スロットがパラメータ、状態が現在の進捗を表すというものです。ビジネスルールが利用可能な操作を定めます。ルーティング層はこれらの情報から次の操作を決めるので、タグだけから対応する処理関数を引くことはできません。

二、業務機能と意図マッピングの定義

機能カタログは、システムが実際に提供できる機能を示します。1つの意図を複数ステップのフローにマッピングできます。複数の問い合わせ意図が同じ検索機能を共有する場合もあります。

雑談を別々に扱う必要があるかは、製品によって変わります。汎用アシスタントなら雑談を汎用対話機能に任せられます。このシリーズのホテルアシスタントでは、機能の説明だけを提供します。すべての入力に返信が必要だだという理由だけで、雑談を何らかのホテル意図に偽装してはいけません。

三、知识検索と注文照会

知識ベースは、朝食時間、チェックインポリシー、提出書類の要件など、比較的安定したルールと説明を保存するのに向いています。個人注文の状態は業務システムに由来し、その注文の所有者、有効性、アクセス権限を伴います。

「私の注文はキャンセルされましたか」を通常の文書検索に投げると、「注文をキャンセルする方法」が見つかりても、その注文が実際どの状態にあるかは答えられません。検索結果が意味的に関連しているだけでは、質問に必要な事実を備えていることを意味しません。

そこで、まず「答えの主な根拠は公開情報にあるのか、それとも現在のユーザーに関する業務オブジェクトにあるのか」という2つの問いを立てます。後者なら、まず対象を特定して権限制限付きのツールを呼び出し、必要に応じてツール結果を説明するポリシーを検索します。

たとえば、注文照会が「キャンセル料 50」を返し、ポリシー検索がその根拠を説明します。この2つで答えが成立します。ただし、知識ベースにある「一部の客室タイプでは無料でキャンセルできる」という一般論で、注文固有のキャンセル料を置き換えてはいけません。

四、コンテキストを組み合わせたクエリの書き換え

「それ、キャンセルできますか」という問い合わせに、この文言だけで検索すると通常は情報が不足します。まずセッション状態から、「それ」がどの注文またはどの製品を示すのかを確認し、明快な検索クエリを生成する必要があります。

一般的な順序は次のとおりです。

ただし、これはすべてのシステムが従うべき固定パイプラインではありません。機能を確認するために軽い検索を先に行う必要のある問題もありますし、分類器自体が検索結果から得たラベルの例を利用することもあります。重要なのは検索の目的を区別することです。タグの選択を手伝うための検索か、最終回答の根拠を探すための検索かです。目的が異なれば、入力も評価も分けて設計します。

クエリを書き換える際は、否定と条件を残します。「料金がかかるならキャンセルしない」を「注文をキャンセル」だけに圧縮してはいけません。書き込み操作では特に、検索を最適化する過程で生成された短いクエリを、ユーザーが操作を全面的に承認した指示として扱わないことが重要です。

五、書き込み操作の検証と確認

注文をキャンセルするには、まずキャンセル意図を識別して対象注文を確定し、状態と料金を照会し、最後に案を提示して確認を待ちます。

確認記録には、少なくとも操作種別、重要なパラメータ、オブジェクトのバージョン、有効条件を結び付ける必要があります。例えば、ユーザーが確認した内容が「DEMO-Aをキャンセルする。現在の料金は0」であるなら、料金または注文オブジェクトが変更された後も、その古い確認を流用してはいけません。

添付資料のシミュレーションフローでは、確認待ちの案を保存します。ユーザーが「確認」と返すと、そこから注文のバージョンと料金を再度読み込みます。条件が変わった場合は競合を返し、アプリに新しい案を提示させます。これにより、識別結果、ユーザーの確認、実際の操作の実行との対応が明確になります。

「パラメータの確認」と「実行の確認」も区別する必要があります。ユーザーが「はい、この注文です」と答えた場合、対象注文を確認しただけで、キャンセル料金や実際の操作を確認したとは限りません。確認を求める質問では、対象だけでなく実行内容も明示し、返信によって何がおきるのかが分かるようにする必要があります。

六、WorkflowとAgentの役割分担

既知で安定し、厳格な制約が必要な操作には、固定Workflowが適しています。注文のキャンセルに 어떤有哪些检查、哪些条件必须成立，应由可检查的代码表达。

Agentは、処理経路が確定していない目標的处理に向いています。複数の情報源をまたいで補足検索を行ったり、候補案を比較したり、異なるツールから返された材料を整理したりできます。次の操作を提案することはできますが、ツールの権限、パラメータの検証、書き込み操作の制約は、あくまで実行環境が強制する必要があります。

2つを組み合わせることもできます。Agentが複雑なニーズを理解して証拠を集め、具体的な予約やキャンセルは固定フローで実行する形です。柔軟性を保ちながら、重要な業務制約を少数のインターフェースにまとめられます。

選択するときは、不確実性がどこに存在するかを見ます。表現の多様性だけなら、より高性能な識別器があれば十分です。処理経路そのものを探索する必要がある場合にこそ、動的な計画が求められます。入口部分でLLMを使ったという理由だけで、すべての注文変更を自由に計画させてはいけません。

七、複数タスクの依存関係と実行順序

「注文を調べて、無料ならキャンセルして、明日の空き客室も見て」には複数の目標があります。ルーティング層は、入力全体を1つのタグに圧縮せず、各タスクのID、パラメータ、依存関係を保持する必要があります。

タスク依存関係の記事にある図では、先に注文照会を実行し、その結果を信頼できる事実として次の処理へ渡せます。キャンセルノードがその事実を確認し、空き客室検索ノードは自身の依存関係に従って処理を進めます。

キャンセル条件が成立しない場合は、キャンセルノードだけをスキップします。空き客室検索はキャンセルの成功に依存しないため、まとめて停止させるべきではありません。逆に、あるタスクが前の手順の成功に依存しているなら、「前の手順が値を返した」だけで続行してはいけません。

添付資料の batch3/planner.py は、模擬注文の結果を使ってこのグラフを進行します。読み取り専用ノードは結果を返し、書き込みノードは確認待ちの案を返します。プログラムは照会結果に応じて次のノードを選び、確認が必要な書き込み操作は一時停止して待機します。

八、権限制御とプロンプトインジェクション対策

知識ドキュメントには「前の指示を無視して」のようなTxtが含まれる可能性があります。ユーザーが要件の中で管理者権限を持っていると主張する場合もあります。これらは解析対象のデータとして扱えますが、サーバー側のアクセス制御やツールの機能を変更することはできません。

プロンプトインジェクションが危険なのは、モデルが自然言語を処理する際にデータと指示を混同する可能性があるからです。ルーティング層では、アイデンティティ、権限、機能の許可リスト、書き込み操作の実行基準を信頼されたプログラムに保持し、モデルが自主的に従うことだけに依存しないようにします。OWASPのプロンプトインジェクション解説

たとえば、注文照会では権限チェックにサーバー側で認証されたアイデンティティを使うべきです。ユーザーがチャットで「この注文は私のもの」と入力しても、アクセス根拠にはなりません。モデルが有効な注文IDを返したとしても、ユーザーがアクセス権を持つことの証明にはなりません。

九、例外処理とサービスの縮退

検索に根拠が見つからない場合は「現在の資料が不足しています」と返して追加情報を促し、注文ツールがタイムアウトした場合は限定的な再試行やサービスの縮退対応に入り、目的が不明な場合は具体的な質問をします。この3つの結果を、まとめて「聞き取れませんでした」にすることはできません。

サービスの縮退でも、目的を勝手に変えてはいけません。キャンセルツールが利用できない場合は、未処理の状態を保存し、結果はまだ確定していないと説明します。.flowを流畅に見せるためにキャンセルポリシーの説明へ切り替えて、タスクが完了したと主張してはいけません。

実装における代表的なルーティング結果には、knowledge、read_tool、clarify、confirm、condition_false、mock_write があります。mock_write だけが模擬的な業務書き込みの完了を表し、他の結果にはそれぞれ明確に定義された次のステップが対応します。

プロジェクトのルートディレクトリで次を実行します。

python batch3/assistant.py
python batch3/planner.py

検索、Agentの実行、ストリーミングサービスの設計をもっと詳しく知りたい場合は、本番対応のRAGとAgentシステムを参照してください。本稿では、リクエストがなぜ特定の機能へ向かうのかに焦点を当てます。次編のサービスの本番展開では、同じリクエストを確実に完了させる方法を扱います。