1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@mennt

PoC止まりを防ぐ：日本語RAG／Agentic RAGを本番運用するための評価・監視設計

1
Posted at

exec-d91075c6-a3fa-4b62-9708-16a3cb7e85dd.png

社内マニュアル、規程、仕様書、議事録などを検索し、その内容を根拠として回答を生成するRAG（Retrieval-Augmented Generation）は、企業における生成AI活用の代表的なアーキテクチャです。

最近では、質問への回答だけでなく、AIエージェントが社内情報を取得し、判断や業務処理につなげるための知識基盤としてもRAGが利用されています。

しかし、PoCでは期待通りに動作していても、本番環境では次のような問題が起こり得ます。

  • 必要な文書が検索結果に含まれない
  • 自然な回答だが、参照文書の内容と一致していない
  • 廃止済み、または古いバージョンの文書を参照する
  • ユーザーの権限外にある情報が検索される
  • 文書更新後に検索・回答品質が低下する
  • AIエージェントが誤った情報を基に処理を実行する
  • 応答時間やLLM利用コストが想定を超える

本記事では、日本語RAGおよびAgentic RAGをPoCで終わらせず、本番運用につなげるための評価・監視設計を整理します。

本記事で紹介する構成や指標は一般的な設計例です。実際の合格基準は、対象業務、データ特性、セキュリティ要件、許容リスクに応じて決定してください。

RAGとAgentic RAGの違い

一般的なRAGでは、あらかじめ設計された検索処理によって質問に関連する文書を取得し、その結果をLLMへ渡して回答を生成します。

一方、本記事でいうAgentic RAGとは、AIエージェントが質問やタスクの内容に応じて、検索対象、検索手順、利用するツールなどを動的に選択する構成を指します。

項目 一般的なRAG Agentic RAG
検索処理 あらかじめ定義したフローを実行 エージェントが状況に応じて手順を選択
検索回数 通常は固定、または少数回 必要に応じて再検索や追加検索を実行
データソース 文書、検索インデックス、ベクトルDBなど 文書、DB、API、業務システムなど
主な目的 質問に対する根拠付き回答 情報取得、判断、業務実行の支援
主なリスク 検索漏れ、根拠のない回答 誤回答に加え、誤操作や権限逸脱

Agentic RAGでは、最終回答だけでなく、エージェントが「なぜそのツールを選び、どのような引数で、何を実行したか」という実行過程も評価対象になります。

本番環境を想定した基本構成

企業向けRAG／Agentic RAGは、概念的には次のような構成になります。

ユーザー
  ↓
認証・ユーザー属性の取得
  ↓
質問／タスクの解析
  ↓
検索対象・検索方法・ツールの選択
  ↓
権限条件を含む検索
  ↓
キーワード検索＋ベクトル検索
  ↓
Reranking
  ↓
LLMによる回答／実行計画の生成
  ↓
ポリシー・権限・出力内容の確認
  ↓
回答、またはHuman Approval
  ↓
業務システムへの反映

重要なのは、LLMの最終出力だけで品質を判断しないことです。

検索、回答生成、ツール選択、アクセス制御、業務実行を分け、それぞれに評価項目とログを設計します。

評価を4つのレイヤーに分ける

1. Retrieval：正しい情報を検索できたか

最初に評価するのは、回答を生成する前の検索品質です。

代表的な指標には次のものがあります。

指標 確認できること
Recall@K 正解文書のうち、上位K件に含まれた割合
Precision@K 上位K件のうち、正解文書だった割合
Hit@K 正解文書が上位K件に1件以上含まれたか
MRR 最初の正解文書がどの順位に現れたか
NDCG@K 関連度と順位の両方を考慮した検索品質

例えば、一つの質問に対して正解文書が複数存在する場合、Recall@5は次のように計算できます。

def recall_at_k(retrieved_ids, relevant_ids, k=5):
    retrieved = set(retrieved_ids[:k])
    relevant = set(relevant_ids)

    if not relevant:
        raise ValueError("relevant_ids must not be empty")

    return len(retrieved & relevant) / len(relevant)

一方、「正解文書が上位5件に一つでも含まれている質問の割合」を測りたい場合は、Recall@5ではなくHit@5またはHit Rate@5として区別します。

def hit_at_k(retrieved_ids, relevant_ids, k=5):
    return int(bool(set(retrieved_ids[:k]) & set(relevant_ids)))

複数の質問に対するHit Rate@Kは、各質問のhit_at_kの平均として計算できます。

日本語文書で確認したいポイント

日本語文書では、次の要素が検索品質に影響します。

  • 全角・半角、大文字・小文字の違い
  • 漢字、ひらがな、カタカナの表記揺れ
  • 送り仮名の違い
  • 社内略語、部門名、製品コード
  • 複合語の分割方法
  • PDF内の表、図、画像に含まれる情報
  • 見出しと本文の関係
  • チャンクのサイズとオーバーラップ
  • 文書の版、施行日、更新日、失効日

ベクトル検索だけで十分な品質が得られない場合は、キーワード検索と組み合わせるHybrid Searchや、検索結果を並べ替えるRerankingを検討します。

ただし、方式を追加すれば必ず改善するわけではありません。同じ評価データセットを使い、変更前後のRecall、Precision、順位、応答時間、コストを比較する必要があります。

2. Generation：根拠に基づいて回答できたか

次に、検索した文書と生成された回答の整合性を評価します。

主な確認項目は次の通りです。

  • ユーザーの質問に直接回答しているか
  • 必須情報を漏れなく含んでいるか
  • 数値、日付、固有名詞が正しいか
  • 参照文書にない情報を事実として追加していないか
  • 回答を支える出典を提示できているか
  • 出典と回答内容が正しく対応しているか
  • 根拠が不足している場合に、無理に回答せず確認を求められるか
  • 複数文書に矛盾がある場合、勝手に一方を正しいと判断していないか

回答の流暢さと正確性は別の評価軸です。自然な日本語で書かれているだけでは、正しい回答とは判断できません。

AWSのRAG評価機能でも、Correctness、Completeness、Faithfulness、Citation Precision、Citation Coverageなどが別々の指標として扱われています。

自動評価にはルールベース評価やLLM-as-a-Judgeを利用できますが、評価モデル自体も誤る可能性があります。重要な業務では、業務担当者によるレビューと組み合わせることが必要です。

3. Agent：適切なツールと処理を選択できたか

AIエージェントを利用する場合は、回答だけでなく実行トレースも評価します。

  • 適切なデータソースを選択したか
  • 不要なツールを呼び出していないか
  • ツールに渡した引数や検索条件は正しいか
  • 同じ検索や処理を不必要に繰り返していないか
  • 適切な条件で処理を終了できたか
  • 参照だけでよい場面で更新処理を実行していないか
  • 承認が必要な処理を自動実行していないか
  • ツールの失敗時に、安全な状態で停止できたか

例えば、社内規程の内容を確認するだけの質問に対して、顧客管理システムを更新するツールが呼び出されるべきではありません。

ツールごとに、少なくとも次のようなポリシーを定義します。

区分 例 制御方針
参照系 文書検索、在庫照会 権限内で自動実行可能
低リスク更新 下書き保存、社内通知案の作成 実行結果を記録
高リスク更新 顧客情報変更、発注、支払い Human Approval必須
禁止操作 権限変更、監査ログ削除 エージェントから実行不可

最終的な実行権限はプロンプトだけで制御せず、アプリケーションやAPI側でも検証します。

4. Operation：本番環境で安定して運用できるか

本番運用では、精度以外の指標も継続して監視します。

  • 応答時間のp50、p95、p99
  • タイムアウト率
  • 1リクエスト当たりのトークン数とコスト
  • ユーザー、部門、ユースケース別の利用量
  • 検索結果が0件だった割合
  • 回答拒否率
  • ユーザーからの低評価率
  • Human Approvalの発生率と却下率
  • ツール実行の成功率と再試行回数
  • エージェントのステップ数
  • 文書更新後の検索・回答品質
  • モデルや外部APIのエラー率

最大応答時間だけでは、一時的な異常値に影響されやすいため、p95やp99などのパーセンタイルも確認します。

モデル、プロンプト、Embedding、チャンク分割、検索設定、Reranker、文書のいずれかを変更した場合は、同じ評価データセットで回帰テストを実施します。

評価データセットの作り方

評価データは、開発チームだけで作るのではなく、規程や業務の正解を判断できる担当者と共同で準備します。

以下は構造を説明するための架空データです。記載されている規程名や申請期限は、実在する企業のルールを示すものではありません。

{
  "question": "国内出張費の申請期限を教えてください",
  "expected_documents": [
    "国内出張規程_v3.pdf"
  ],
  "expected_answer_points": [
    "出張終了後5営業日以内",
    "経費精算システムから申請"
  ],
  "user_role": "employee",
  "allowed_action": "read_only"
}

データセットには、通常の質問だけでなく、次のパターンも含めます。

  • 曖昧な質問
  • 誤字、脱字、口語表現を含む質問
  • 社内略語を含む質問
  • 複数文書の参照が必要な質問
  • 根拠文書が存在しない質問
  • 古い版を明示的に要求する質問
  • 最新版と旧版で回答が異なる質問
  • 権限外の情報を要求する質問
  • プロンプトインジェクションを狙った入力
  • 業務システムの更新を伴う依頼
  • 外部APIや検索ツールが失敗するケース

PoCでは対象範囲を限定して開始できます。ただし、本番移行を判断する前には、主要な業務パターンだけでなく、重大な事故につながるリスクパターンも評価する必要があります。

評価用データの一部は開発・調整用、別の一部は最終確認用として分離しておくと、特定のテストケースへの過度な最適化を防ぎやすくなります。

アクセス制御はLLMへ文書を渡す前に実施する

企業向けRAGでは、ユーザーが閲覧できない文書をLLMのコンテキストへ含めないことが重要です。

ユーザー認証
  ↓
所属・役職・グループ・プロジェクトを確認
  ↓
権限条件を検索クエリへ適用
  ↓
検索・Reranking
  ↓
許可された文書だけをLLMへ渡す
  ↓
回答生成

文書をインデックスへ登録する際に、閲覧可能なユーザー、グループ、テナント、機密区分などのメタデータを保持し、検索時にACLやセキュリティフィルターを適用します。

回答生成後に機密情報らしい文字列を削除するだけでは不十分です。権限外の文書がLLMへ渡る前に検索結果から除外される必要があります。

また、AIエージェントが更新系APIを実行する場合は、検索時の権限確認とは別に、実行直前にも対象データと操作内容に対する権限を再確認します。

ログに記録する情報

障害調査と品質改善のため、可能な範囲で次の情報を記録します。

  • 誰が、いつ、どのユースケースを利用したか
  • どの文書やチャンクが検索されたか
  • 検索結果のスコアと順位
  • 使用したモデルとEmbeddingモデル
  • プロンプト、検索設定、インデックスのバージョン
  • エージェントが選択したツールと引数
  • ツールの実行結果とエラー
  • Human Approvalが行われたか
  • 最終的にどの処理が実行されたか
  • 応答時間、トークン数、推定コスト

ただし、ログ自体が情報漏えいの原因になる可能性があります。

入力内容や機密情報を保存する場合は、保存期間、保存場所、暗号化、閲覧権限、マスキング、削除方法を事前に定義します。認証情報、APIキー、アクセストークンなどはログへ保存しない設計が必要です。

PoCから本番へ進むための判定基準

PoCの開始時点で、本番移行の条件を決めておくことが重要です。

評価項目 判定内容
検索品質 正しい根拠文書を必要な順位内で取得できる
回答品質 必須情報を正しく含み、根拠のない内容を追加しない
出典表示 利用者が回答の根拠を確認できる
回答拒否 根拠がない場合に無理に回答しない
権限制御 権限外の文書を検索結果やLLMの入力へ含めない
ツール実行 許可された処理だけを実行する
Human Approval 重要な処理の前に承認を要求する
応答性能 想定する利用環境で許容時間内に応答する
コスト 想定ユーザー数と利用回数で予算内に収まる
運用性 文書、モデル、プロンプト、検索設定を追跡・更新できる
監査性 質問から最終処理までの履歴を確認できる

すべてのユースケースに同じ数値目標を設定する必要はありません。

FAQ検索と、契約判断や発注処理を支援するエージェントでは、誤りが発生した場合の影響が異なります。リスクが高い処理ほど、厳しい品質基準、権限制御、Human Approvalが必要です。

基準に達しない場合は、すぐに大規模開発へ移行せず、次の対策を検討します。

  • 元文書やメタデータを改善する
  • OCRや表データの抽出方法を見直す
  • チャンク分割を変更する
  • 検索方式やクエリ生成を変更する
  • Hybrid SearchやRerankingを追加する
  • モデルやプロンプトを変更する
  • 自動化する範囲を縮小する
  • Human Approvalを追加する
  • ユースケース自体を見直す

本番リリース後も評価を継続する

RAGの品質は、リリース時点で固定されるものではありません。

文書の追加・更新、組織や権限の変更、モデルの更新、ユーザーの利用方法の変化によって、検索結果や回答品質も変化します。

そのため、本番環境では次の改善サイクルを継続します。

利用ログとフィードバックの収集
  ↓
低品質な回答・失敗した処理の抽出
  ↓
原因の分類
  ↓
文書・検索・プロンプト・ツール設計の改善
  ↓
評価データセットによる回帰テスト
  ↓
段階的に本番環境へ反映

原因を「LLMの性能不足」だけで片付けないことも重要です。

実際には、文書の版管理、OCRの失敗、チャンク分割、権限メタデータ、検索条件、ツール引数など、LLM以外の部分が原因となる場合もあります。

ユーザーフィードバック、定期的な自動評価、業務担当者によるレビューを組み合わせ、継続的に品質を確認します。

まとめ

RAGは、社内検索や質問回答だけでなく、AIエージェントが企業データを安全に利用するための知識基盤としても活用できます。

PoCから本番運用へ進むためには、次の項目を分けて評価することが重要です。

  • 検索品質
  • 回答の正確性と完全性
  • 参照文書に対するFaithfulness
  • 出典の正確性
  • ツール選択と実行結果
  • アクセス制御
  • Human Approval
  • 応答性能とコスト
  • 監査ログ
  • 本番環境での監視と継続改善

評価すべきなのは、単に「回答できるか」ではありません。

「正しい根拠を取得し、許可された範囲で、安全かつ継続的に業務利用できるか」までを評価基準に含めることが、PoC止まりを防ぐポイントです。

参考資料

BAPについて

株式会社BAP Solution Japanは、ベトナムの開発チームと連携し、生成AI、RAG、AIエージェントに関するユースケース整理、PoC、本番開発、既存システムとの連携、運用改善を支援しています。

詳細は、BAPの生成AI・AIエージェント開発支援サービスをご覧ください。

本記事は株式会社BAP Solution Japanが、企業向けRAG／AIエージェント開発における一般的な設計観点を整理したものです。特定のクラウドサービスや製品の利用を推奨するものではありません。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?