04. RAG / Knowledgeをどう設計したか

Semantic Similarityは回答資格ではない

RAGで問い合わせに似た文書を検索できても、その文書を回答根拠として使ってよいとは限りません。類似機種の障害情報、古い版の手順、調査中の内部情報は、意味的には近くても顧客への回答には不適切です。

Semantic Similarity ≠ Business Validity

そこで検索を「似ている文書を探す処理」だけで終わらせず、業務上利用できるKnowledgeへ絞り込む処理として設計します。

情報は、文書管理、問題管理、問い合わせ管理など複数の既存システムへ分散しています。各システムが異なる機種名や分類を使っていると、検索対象を安全に限定できません。

このケースでは、次の属性を共通化する考え方を採ります。

同じ文書基盤へ格納できても、用途は同じではありません。

例えば顧客向けマニュアルと確認済みFAQは回答根拠になり得ますが、調査中の障害メモは担当者の調査候補には使えても、顧客向け回答の確定根拠にはできません。

情報源	検索対象	顧客回答の根拠	必要な制御
公開マニュアル・仕様	可	対象機種と版が適合すれば可	版数、有効期間、公開状態
確認済みFAQ	可	適用条件が一致すれば可	対象条件、確認者、更新日
確定した障害情報	可	公開承認された範囲のみ可	影響範囲、回避策、公開可否
調査中メモ・社内記録	担当者支援に限定	不可	アクセス権、用途、状態
過去の会話	改善分析に利用	そのまま根拠にしない	個人情報、正誤、再利用目的

この区別により、「検索できる文書」と「顧客への回答根拠として使用してよい文書」を同一視しません。

回答に使える根拠を絞る

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

気になる項目を選ぶと、その役割や判断理由を確認できます。

問い合わせと対話で得たContext。次の工程：対象機種で絞る。

対象機種で絞る。次の工程：有効な版で絞る。

有効な版で絞る。次の工程：顧客へ公開可能な情報へ絞る。

顧客へ公開可能な情報へ絞る。次の工程：意味検索 / キーワード検索。

意味検索 / キーワード検索。次の工程：回答根拠として十分か。

回答根拠として十分か。次の工程：Yes：生成AIへGrounding Contextを渡す／No：人間へ引き継ぐ。

生成AIへGrounding Contextを渡す。この工程の位置と前後のつながりを確認します。

人間へ引き継ぐ。この工程の位置と前後のつながりを確認します。

メタデータによる絞込みは、Vector Searchの結果を補う後処理ではありません。検索してよい母集団を先に決めるGuardrailです。

その上で意味検索やキーワード検索を使います。

一定文字数だけで分割すると、手順の前提と操作、警告と対象条件が別Chunkへ分かれることがあります。このケースでは、見出し、手順単位、注意事項、対象機種の境界を優先し、前提条件を失わない単位でChunkを作る設計とします。表や箇条書きも、行だけを切り出して意味が変わらないかを確認します。

Rankingでは意味的類似度だけでなく、対象機種・版の完全一致、文書種別、公開状態、更新状態を組み合わせます。上位に来たという理由だけで採用せず、回答に必要な条件が一つの根拠内で満たされるか、複数根拠を併用するときに矛盾がないかを判定します。

回答には、利用した文書ID、版、該当箇所をEvidenceとして結び付けます。引用表示は装飾ではなく、顧客または担当者が回答の根拠を確認し、後から同じ判断を再現するための参照です。

新旧文書が同時に検索対象へ残る、FAQと仕様書で説明が異なる、といった状態を例外的なデータ不備だけとして扱いません。矛盾を検知した場合は生成AIに統合させず、回答を停止してKnowledge Ownerへ返します。

廃止文書は削除だけでなく、後から回答時点を追跡できるよう状態と有効期間を保持します。

文書を登録して終わりにはしません。新機種、版更新、公開状態の変更、FAQの追加、障害情報の確定に合わせて、属性と検索条件を更新する必要があります。

また、検索に失敗した問い合わせを記録すれば、文書が存在しないのか、分類が誤っているのか、機種の対応付けが不足しているのかを切り分けられます。RAGの品質はモデルだけでなく、Knowledgeの状態と運用で決まります。

この責務分離は、Instruction・Knowledge・EvidenceとKnowledge / Context設計で詳しく扱っています。