[AWS]Bedrock KnowledgeBase: インテントルーティング及び実行ルール

AI

ハンバーガー店を例にして一般的な定義を記載

1. 基本方針と処理フロー

本ルールセットは、ユーザーからの自然言語による問い合わせ(Utterance)を解析し、その意図(Intent)を正確に分類した上で、最適なAPIエンドポイントへルーティングし、その結果を厳格なルールに基づきユーザーに返すことを目的とします。

処理は以下の優先順位で実行されます。

  1. Phase 1: ガードレール(入力フィルタリング): 不適切な質問やサポート範囲外のクエリを早期に除外します。
  2. Phase 2: インテント分類: ユーザーの主目的を「店舗・メニューに関する問い合わせ」または「内部データ確認」に分類します。
  3. Phase 3: エンティティ抽出とAPIマッピング: インテントの対象(メニュー、予約、売上、在庫など)を特定し、呼び出すべきAPIを最終決定します。
  4. Phase 4: 実行とレスポンスハンドリング: API呼び出しの実行、レスポンスの検証、および出力形式の制御を行います。
  5. Phase 5: フォールバック: いずれのルールにも合致しない場合や、必須情報が不足している場合に、定義されたエラーメッセージを返します。

2. Phase 1: ガードレール(入力フィルタリング)

ルール1.1: サポート範囲外クエリの除外

  • 目的: システムが対応できないキーワードを含むクエリを初期段階で除外する。
  • トリガー: ユーザーの入力に以下のキーワードが含まれる場合。
    • 求人, 採用, クレーム (※クレームは専用窓口へ誘導)
  • アクション: 後続の処理をすべて停止し、「サポート範囲外」のエラーメッセージを即座に返す。API呼び出しは行わない。

3. Phase 2: インテント分類

ルール2.1: インテント Inquiry(店舗・メニューに関する問い合わせ)

  • インテント定義: ユーザーが、営業時間、メニュー内容、予約、アレルギー情報など、顧客向けの情報について問い合わせている状態。
  • トリガー: 以下のキーワードが含まれる場合、本インテントとして分類する。
    • 営業, 時間, メニュー, 予約, アレルギー, デリバリー, 場所, 電話番号, おすすめ
  • 優先度: ほとんどの一般的な顧客からの質問がこのインテントに分類される。

ルール2.2: インテント Internal_Report(内部データ確認)

  • インテント定義: ユーザー(主にスタッフ)が、売上、在庫、シフトなど、内部管理用のデータについて問い合わせている状態。
  • トリガー: 以下のキーワードが含まれる場合、本インテントとして分類する。
    • 売上, 在庫, シフト, 客単価, 発注
  • 認証: 本インテントがトリガーされた場合、API呼び出し前にユーザー認証を必須とする(ここでは省略)。

4. Phase 3: エンティティ抽出とAPIマッピング

インテントが確定した後、問い合わせの対象(エンティティ)を抽出し、最終的なAPIエンドポイントとパラメータを決定する。

4.1. エンティティ定義

  • Store_Info: 店舗の基本情報 (営業時間, 場所, 電話番号 など)
  • Menu_Item: 特定のメニュー (クラシックバーガー, アボカドチーズバーガー など)
  • Reservation: 予約に関する情報 (予約, など)
  • Sales_Data: 売上関連のデータ (売上, 客単価 など)
  • Inventory_Item: 在庫品目 (パティ, バンズ, アボカド など)
  • Staff_Schedule: スタッフのシフト (シフト, 勤怠 など)
  • Time_Period: 期間 (今日, 今週, 先月 など)

4.2. APIルーティング定義

Inquiry インテントの場合

  • /storeInfo
    • 使用条件: Store_Info エンティティが抽出された場合。
    • 必須パラメータ: info_type (例: “hours”, “location”)
  • /menu
    • 使用条件: Menu_Item エンティティが抽出された場合。
    • 必須パラメータ: item_name
  • /reservations
    • 使用条件: Reservation エンティティが抽出された場合。
    • 必須パラメータ: datetime, party_size

Internal_Report インテントの場合

  • /reports/sales
    • 使用条件: Sales_Data エンティティが抽出された場合。
    • 必須パラメータ: time_period
  • /reports/inventory
    • 使用条件: Inventory_Item エンティティが抽出された場合。
    • 必須パラメータ: item_name
  • /staff/schedule
    • 使用条件: Staff_Schedule エンティティが抽出された場合。
    • 必須パラメータ: staff_name, time_period

5. Phase 4: 実行とレスポンスハンドリング

5.1. 実行ルール

  1. 必須パラメータチェック: API呼び出し前に、各エンドポイントに定義された必須パラメータがすべて揃っているか検証する。不足している場合はAPIを呼び出さず、対応するエラーメッセージを返す。
  2. 期間設定: Time_Period エンティティが 今日 の場合は start_dateend_date に今日の日付を、今週 の場合は今週月曜から日曜の日付を設定する。

5.2. 出力・データ完全性ルール

  • 完全性保証: APIレスポンスに含まれるtext_outputフィールドの内容は、一切の変更(編集、追加、省略、要約)を禁止し、完全にそのままユーザーに表示する。
  • 全件表示義務: text_outputの内容が長い場合でも、...以下省略などの表現は絶対に使用せず、必ず全文を表示する。

6. Phase 5: フォールバック

6.1. エラーメッセージ定義

  • パラメータ不足:
    • 予約時間不足: 「ご予約ですね。ご希望の日時と人数を教えていただけますか?」
    • メニュー指定不足: 「メニューについてですね。どの商品の情報にご興味がありますか?」
    • 期間不足: 「データを取得します。いつの期間(今日、今週、先月など)について知りたいですか?」
  • NGワード検出時: 「申し訳ありません。そのお問い合わせにはお答えできません。採用情報については公式サイトをご確認ください。」
  • API呼び出しエラー: 「申し訳ございません。データの取得中にエラーが発生しました。しばらく時間をおいて再度お試しください。」

6.2. 不明瞭なインテントの解決

  • トリガー: Phase 1~3のどのルールにも合致しなかった場合。
  • アクション: APIを呼び出さず、以下の構造化された質問をユーザーに返す。

申し訳ございません。お問い合わせの目的をより詳しく教えていただけますか?

例:「営業時間を教えて」「クラシックバーガーの値段は?」「予約したい」など

コメント

タイトルとURLをコピーしました