ハルシネーションゼロのサポート向けRAG構成

エグゼクティブサマリー

大規模言語モデル（LLM）をカスタマーサポート領域へ導入する際、最大の運用リスクとなるのがハルシネーション（幻覚・事実誤認）です。サポートボットが存在しない返金規定をでっち上げたり、誤ったテクニカル指示を出したりすれば、顧客からの信頼を失うだけでなく、法的なリスクにも直結します。

標準的な既成のLLMプロンプトだけでハルシネーションを確実に防ぐことは困難です。エンタープライズレベルの正確性を獲得するには、ガードレールを備えたRetrieval-Augmented Generation（RAG）アーキテクチャの構築が不可欠となります。本プレイブックでは、ハルシネーション率を極限までゼロに近づけたサポートAIエージェントを実現するため、Isotope Blueで実践しているシステム設計、ベクトル検索戦略、ガードレールロジックを解説します。

1. コアアーキテクチャの設計指針

信頼性の高いサポート用RAGパイプラインでは、「ナレッジの検索（Retrieval）」と「言語生成（Generation）」を明確に分離します。LLMが事前学習した自身のメモリ（記憶）から直接回答することは許されず、検索・検証された文脈（Context）のみを元に要約・整理を行う編集エンジンとしてのみ機能させます。

flowchart TD
    UserQuery[ユーザーの質問] --> HybridSearch{ハイブリッド検索<br/>Dense + Sparse}

    subgraph Retrieval [ナレッジ検索層]
        Dense[Dense ベクトル検索<br/>Pinecone / Zep]
        Sparse[Sparse キーワード検索<br/>BM25]
        RRF[Reciprocal Rank Fusion<br/>RRFスコアリング]
        Dense --- RRF
        Sparse --- RRF
    end

    HybridSearch --> Retrieval
    Retrieval --> Gate{関連性スコア判定<br/>閾値: Cosine > 0.82}

    Gate -->|スコア未達| Fallback[フォールバック処理<br/>人間サポートへエスカレーション]
    Gate -->|スコア達成| Generation[LLM 生成層<br/>Claude 3.5 / GPT-4o<br/>Temperature = 0.0]

    subgraph Verification [事後検証ガード]
        Citation[引用トラッキング検証]
        Consistency[自己一貫性評価モデル]
        Citation --- Consistency
    end

    Generation --> Verification
    Verification -->|矛盾検出| HumanReview[フラグ立て / 人間によるレビュー]
    Verification -->|検証合格| FinalOutput[ユーザーへ回答を返信]

2. ハルシネーションゼロを実現する4つのエンジニアリング柱

柱 A: ハイブリッド検索（Dense ベクトル＋ Sparse キーワード検索）

純粋な意味的ベクトル検索だけでは、厳密な技術識別子、型番、特定の型番エラーコードを見落とす危険性があります。そのため、ハイブリッド検索エンジンを実装します。

Dense Retrieval（高次元ベクトル検索）： ベクトル埋め込み（PineconeやZep等）を用いて、対話の意図や概念的類似性を把握します。
Sparse Retrieval（疎ベクトル・キーワード検索）： 従来のBM25キーワードマッチングを用いて、コードスニペット、SKU番号、規約名等の完全一致精度を確保します。
Reciprocal Rank Fusion (RRF)： DenseとSparseの検索結果を単一の再ランク（Re-rank）されたコンテキストペイロードに結合してからプロンプトへ送出します。

柱 B: 厳格なコンテキスト境界とフォールバックの閾値

ハルシネーションの主因は、ナレッジベース内に根拠となる文脈が存在しないにもかかわらず、LLMに無理やり回答を生成させようとすることにあります。

関連性スコアリング・ゲート： 取得されたドキュメントチャンクごとにコサイン類似度／距離スコアを算出します。定義された信頼閾値（例: $0.82$）を超えるチャンクが存在しない場合、クエリは生成プロセスを迂回します。
決定論的フォールバック（自動退避）： コンテキストが不十分な場合、パイプラインは次のような自動応答を実行します：「このリクエストに正確にお答えするための十分な情報がありません。人間のサポート専門担当者へとおつなぎいたします…」

柱 C: 厳格なシステムプロンプトと Temperature のキャリブレーション

生成レイヤーは、確認済みの事実のみを翻訳・整形する役割へと純粋化します。

Temperature（温度パラメータ）の設定： トークンのランダム性や創造的ブレを排除するため、値を $0.0$ に固定します。
厳格なネガティブ制約： システム指示にて、提供された <context></context> ブロック外部の前提知識の適用や外部情報の参照を明示的に禁止します。

Markdown

### SYSTEM PROMPT EXCERPT

You are an enterprise support intelligence agent. Your job is to answer user queries EXCLUSIVELY using the facts provided in the u003ccontextu003e tags below.

RULES:

1. Do NOT use any prior knowledge or outside assumptions.

2. If the answer cannot be directly derived from the u003ccontextu003e, reply with: u0022UNRESOLVED_CONTEXTu0022.

3. Cite the exact Document ID for every factual claim made in your response.

柱 D: 生成後の根拠（Groundedness）自動検証

生成された回答がユーザーへ送信される前に、自動検証ガードによるチェックが行われます。

引用（Citation）マッチング： 出力内のすべての主張が、取得したコンテキストブロック内の特定の文と正しく紐付いているか検証します。
自己一貫性（Self-Consistency）評価： 軽量な二次評価モデルを用い、生成された出力がソースドキュメントと論理的に矛盾していないかを判断します。矛盾が検出された場合、メッセージはインターセプトされ、人間の確認用としてフラグが立てられます。

3. 推奨テクノロジースタック

パイプライン構成要素	推奨スタック
ベクトルデータベース	Pinecone (Serverless) または Zep (動的メモリ＋ハイブリッド検索)
エンベディングモデル	OpenAI `text-embedding-3-large` または Cohere Embed v3
オーケストレーション & ワークフロー	Python (FastAPI), n8n, または LangChain / LlamaIndex
LLM 実行エンジン	Claude 3.5 Sonnet / GPT-4o (低温 Temperature 設定)
データベース同期	Zendesk, Notion, カスタム PostgreSQL からの Webhook トリガー

4. 主要業績評価指標（KPI）

本アーキテクチャを本番環境へ導入した際、成功したハルシネーションゼロのサポートエンジンは以下の指標を達成します：

ハルシネーション発生率： 全カスタマー対話において $< 0.1%$ 未満。
自動対応完結率（Deflection Rate）： 1次サポート問い合わせの $60\% – 80\%$ を人間の介在なしで解決。
1秒未満のレイテンシ： 検索および生成パイプライン全体の応答時間を $1.2$ 秒以内に収める。
高精度なエスカレーション： 未解決の特殊事例（Edge Cases）について、全会話ログを添えて人間のサポートチームへ $100\%$ 正確にルーティング。