【論文解説】「RAG」で検索前に整理する！語彙衝突を防ぐ「KB Cataloging」アプローチと実運用の考察

この記事の要点（30秒版）

• RAGは、社内の複数サービスで同じ単語（例: Offer）が別の意味で使われると、別サービスの似たルールを拾って間違える（語彙の衝突）
• 論文の解決策は KB Cataloging。文章の意味ではなく、ファイルの出処（サービス名・ドメイン・機能）で先に検索範囲を絞ってからベクトル検索する
• 競合するルールは「順位が下がる」のではなく、最初から候補に入らない
• ただし論文は検索精度の数値評価を載せていない（運用実績ベースの報告）。この記事でも「効いた」とは言い切らず、仕組みの理解メモとして読む

1. はじめに

社内ドキュメントやコードから情報を引き出すために RAG（Retrieval-Augmented Generation） を導入する例が増えています。ところがサービスが増えると、次の問題が出ます。

同じ単語（例: Offer）が複数のサービスで別の意味で使われ、RAGが間違ったサービスの文章を取ってきてしまう

これが 語彙の衝突（Vocabulary Collision） です。

今回読んだのは、Cognizantの研究チームによる次の論文です。

• タイトル: Reimagining Enterprise RAG for Multi-Agent Systems: A Knowledge Layer That Organizes Before It Retrieves
• 論文: arXiv:2610.32851（HTML版）

この記事は、自分が後で見返したときに「何が新しくて、どう動いて、何が未検証か」をすぐ思い出せることを目的にしたメモです。

想定読者: RAGの基本（ベクトル検索でチャンクを探してLLMに渡す）を知っている人

2. 解決したい課題：Flat RAGの限界

例：Offer という単語

論文の例では、Offer は3つのサービスでそれぞれ別のルールを指します。

サービス	Offer が指すルール
注文（Ordering）	適用資格（Eligibility）
カタログ（Catalog）	有効期限（Validity）
請求（Billing）	割引ルール（Discount）

3つとも書き方（構造）がそっくりなので、ベクトル検索では「注文」の質問に「請求」のルールが高スコアで返ってきます。エージェントは間違いに気づかず、そのまま誤ったルールでコード生成やバグ解析をしてしまいます。

図書館でたとえると

「Offer と書いてある本」が3つの棚（サービス）に1冊ずつあるのに、棚を決めずに全部の本から一番タイトルが似ている本を探している状態です。先に棚を決めれば間違いようがありません。KB Catalogingはこれを仕組みにしたものです。

3. 全体像（論文 Figure 1）

まず論文の全体図を見ておきます。5つの層が上から下に流れます。

出典: 論文 Figure 1（arXiv:2610.32851）。画像が小さい場合は論文HTML版で拡大できます。

図の読み方：

層	内容	この記事での扱い
1. Knowledge production	241リポジトリ・18サービスのコードを、7エージェントで仕様書（JSON）に逆生成	前提（4章）
2. Knowledge layer	取り込み時に名前・出処を整理（ここが主役）	4-1
3. Identifier-constrained retrieval	絞ってから検索（ここも主役）	4-2
4. Role-aware composition	役割ごとに知識の粒度を変えて提供	触れない
5. Consumption	障害分析・テスト・要件整理などのエージェントが利用	5章

実線の枠は本番稼働中、破線は開発中・設計段階です。

4. 仕組み

前提：仕様書は「AIが自動生成したもの」

この手法は、事前にAI（リバースエンジニアリングのパイプライン）がソースコードを解析し、出処情報付きの仕様書（JSON）を大量に生成している環境が前提です。人間が書いた野良のWordやConfluenceにそのまま当てるものではありません。

4-1. 取り込み時：中身を読まずに「整理」する（4ステップ）

取り込み時の処理は、ルールどおりに決まる決定的な処理で、文書の中身は読みません。

命名規則

{service}_{domain}_{feature}_{artifact_type}_v{version}.{ext}

ファイル名そのものが「どのサービスの、どの機能の、何の成果物か」を表します。メタデータの例は次のとおりです。

service: OrderingService
domain: Checkout
feature: OfferEligibility

出処メタデータは生成した側（エージェント）がもともと持っているので、後から推論で付け足す必要がありません。これが「構築が安い」理由です。

論文の構成要素は3つです。

構成要素	役割
自己記述型カタログ（Artifact catalog）	パス自体が「名前・分類・場所」を兼ねる
疎なメタデータレジストリ（Metadata registry）	ID・出処・系譜などを保存。未知の項目は null ではなく「存在しない」扱いなので、スキーマ変更なしでサービスを足せる
ナビゲーション・ハイパーグラフ	ノード＝あるサービスの1機能の成果物置き場。ハイパーエッジ＝複数サービスを跨ぐ業務ワークフロー（例: 注文送信フロー）をn対nで束ねる

レジストリのフィールドは、作成時に分かるものと、使われながら貯まるものに分かれます。

種類	フィールド例
作成時に判明	artifact_id, artifact_type, service, domain, feature, file_path, version, confidence, derived_from（系譜）
利用に伴い蓄積	used_for, query_intents, co_retrieved_with, usefulness_scores, access_count, superseded_by

4-2. 検索時：5ステージ

ステージ	やること	ポイント
1. 意図分類	軽量モデルが質問の種類・対象サービス・ドメインを判定	コーパスの中身には触れない
2. ナビゲーション	エイリアス索引で業務用語を候補ノードと経路に対応づける	「Offer」→ 3ノード候補
3. 絞り込み	ノードから成果物のIDを取得	通常、コーパスの小さな部分集合
4. 制約付き検索	そのID集合だけにハイブリッド検索（dense＋BM25）	論文の核心
5. 信頼度ゲート	結果が十分かLLMが評価。不十分なら全コーパスに拡大	絞り込みの失敗を自己検知する保険

番号に注意: 取り込みは4ステップ、検索は5ステージです。「Stage 4」と言ったら検索側の制約付き検索のことです。

ポイント: 別サービスの酷似したルールは、スコアで負けるのではなく最初から候補セットに入らない。だから「類似度の計算ミス」が構造的に起きにくい。

4-3. 具体例で追う（論文 Figure 3 のイメージ）

質問「注文送信時に Offer の適用資格はどう判定される？」の場合：

1. 意図分類: 対象は注文サービス、ドメインは Checkout
2. ナビゲーション: 「Offer」が3ノード（注文・カタログ・請求）に対応づく。ただし意図に合うのは注文のノード
3. 絞り込み: 注文ノードの成果物IDだけを取得（例: Order_Rule_001 など）
4. 制約付き検索: そのIDのベクトルだけでハイブリッド検索 → カタログ・請求の Offer 規定はそもそも比較対象にならない
5. 信頼度ゲート: 結果が十分ならそのまま回答。足りなければ全体検索に拡大

論文のFigure 3（合成データ）では、候補ノード3件のうち対象1件、候補アーティファクト9件、という絞り込み例が示されています。

5. 既存手法との比較

	Flat RAG	GraphRAG（エンティティグラフ）	KB Cataloging
絞り込みの根拠	テキストの類似度	文章中の言葉の関係	ファイルの出処メタデータ
語彙の衝突	起きる	グラフ構築の段階で混ざりうる（※自分の解釈）	検索前の絞り込みで回避
構築コスト	低	高（エンティティ抽出が必要）	低（論文では1週間未満）
サービス追加	再インデックス	グラフ再構築	命名規則に従ってファイルを置くだけ（スキーマ変更不要）
前提	なし	なし	出処付きの仕様書が自動生成されていること

※ 論文は「エンティティ抽出もテキスト由来のグラフも作らない」と明言しています。GraphRAGが語彙衝突で混乱する、という部分は私の解釈です。

6. 論文が報告している数値と、ないもの

後で見返すときに一番忘れやすいので分けて書きます。

報告されている（運用実績）

項目	値
対象	241リポジトリ / 18サービス
生成された成果物	数千件
業務ワークフロー	14件
1回の実行で参照されるエンドポイント要件文書	最大112件
本番障害の分析・解決（開発者が検証）	100件超
リリース時の回帰テスト失敗の帰属	35件
知識レイヤーの構築期間	1週間未満（18サービスいずれもスキーマ変更なし）

報告されていない（評価中・未測定）

• 検索精度（under evaluation）
• 既存RAGとの定量比較（ベースラインなし）
• 絞り込み失敗率（widening rate）
• 正式なレイテンシ測定

「効果が数値で証明された」手法ではありません。設計思想と運用事例の報告として読むのが正確です。Figure 3 の数値も説明用の合成例です。

7. 個人メモ・疑問点と実運用の考察

疑問1：どんな状況で活きる？

• 大前提: AIが出処タグ付きの仕様書を大量に自動生成してある環境
• 人間が書いた野良のWord・Confluence資料には、そのままは適用できない（前処理が必要）
• 向く場面: レガシーコードからAIで仕様書を何千枚も作った後の「AI生成ドキュメントの受け皿」

疑問2：このパイプラインは公開されている？自作できる？

• 結論: Cognizantの商用IPで未公開
• 自作の方針:
  • Claude Code や LangGraph などでコードを静的解析させ、出力時に統一メタデータをJSONで強制付与するプロンプトを組めば近い形にできそう
  • ID絞り込み検索（検索のStage 4）は、ベクトルDBのメタデータフィルタで実現できる

メタデータフィルタのイメージ（Qdrantの例。動作未検証のスケッチ）:

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

hits = client.query_points(
    collection_name="artifacts",
    query=query_vector,  # 質問の埋め込み
    query_filter=Filter(
        must=[
            FieldCondition(key="service", match=MatchValue(value="OrderingService")),
            FieldCondition(key="domain", match=MatchValue(value="Checkout")),
        ]
    ),
    limit=5,
)

ここで大事なのは service の値を誰が決めるかです。Stage 1（意図分類）で決めます。

実運用できそうかの感触

• ボトルネック: 前段のAIエージェントがコードを読み解くときのサービス割り当て精度。ここを間違えると、後段の検索にずっと引っかからなくなる
• 保険: 信頼度ゲートで全体検索に広げられるが、「間違ったサービスに割り当てたが、そこそこ十分そうに見える」ケースは防ぎにくそう（※自分の懸念）
• 評価: 質実剛健なアプローチ。「類似度という確率に賭ける前に、IDと構造（決定論）で絞る」という思想は、社内開発ツールやAgentic workflowを作るときの参考になる

8. まとめ

• KB Catalogingの本質は「RAGの検索性能を上げる」ことではなく、データ生成時にIDとメタデータを整えて、検索範囲を物理的に削ること
• 競合ルールは順位が下がるのではなく、候補から消える。ただし絞り込みを間違えたときのために信頼度ゲートで全体検索へ拡大する
• 精度の定量評価は論文にない。運用実績（障害分析100件超など）ベースの報告
• AIに仕様書を作らせるワークフローを組むなら、最初から出処情報（プロバナンス）を付ける設計にしておく

見返し用チェック（自分用）

• 取り込み4ステップ（Rename → Register → Place → Write）を言える
• 検索5ステージ（意図 → ナビ → 絞り込み → 制約付き検索 → 信頼度ゲート）を言える
• 「順位が下がる」ではなく「候補に入らない」の違いを説明できる
• 「精度の数値評価は論文にない」を覚えている

---

参考

• Reimagining Enterprise RAG for Multi-Agent Systems: A Knowledge Layer That Organizes Before It Retrieves（Cognizant, 2026）
• 図は論文 Figure 1 を出典明記のうえ掲載しています