属性知識RAGパターン：管理されたAIエージェントのための規範的検索生成

規制された企業でRAGシステムを構築するチームは、遅かれ早かれ同じ失敗モードに遭遇します。システムは適切なコンテキスト（臨床ガイドライン、製品ドキュメント、データ辞書）を検索し、LLMは実際のデータモデルには存在しないフィールド、しきい値、識別子を参照した自信に満ちた流暢な応答を生成します。コンシューマアプリではこれは迷惑ですが、銀行の与信引受パイプライン、医療保険のコホート識別システム、コンプライアンスチームのAMLクエリレイヤーでは、ガバナンスの失敗です。LLMがフィールドを発明しました。そのフィールドはデータガバナンスを通過したことがありません。出力はせいぜい無意味で、最悪の場合誤解を招きます。

標準RAGはこれを防ぐよう設計されていません。ドキュメントチャンクを検索し、LLMにコンテキストとして渡します。LLMはそのコンテキストから推測したフィールド名、識別子、しきい値を含む自由形式のテキストを生成します。LLMが生成したものがデータカタログに実際に存在するものに対応する保証はありません。プロンプトレベルの緩和策（提供されたコンテキストのフィールドのみを使用する指示、少数ショットの例、出力検証）は限界的な効果しかなく、構造的な問題を解決しません。問題は検索単位が間違っていることです。

属性知識RAG（AK-RAG）は、検索単位レベルでこの問題を修正するリファレンスアーキテクチャです。ドキュメントを埋め込む代わりに、ガバナンスされた属性カタログを個別の知識オブジェクトとしてインデックス化します（ドキュメントページごとに1つの埋め込みではなく、属性ごとに1つの埋め込み）。LLMの役割はフレーズ抽出と明確化の対話であり、フィールド名の生成ではありません。最終出力に現れる可能性のある唯一の識別子は、インデックス化されたカタログに存在するattribute_id値です。LLMはフィールドを作り出すことができません。フィールド選択は、自由生成ではなく、ガバナンスされた検索と分類のパイプラインを通じて行われるからです。

アーキテクチャ

AK-RAGには、属性インデックスを構築する取り込みパイプラインと、自然言語をガバナンスDSLに変換するクエリパイプラインの2つの異なるパイプラインがあります。どちらも「属性カタログは知識層であり、ドキュメントコーパスではない」という中核原則に基づいて設計されています。

取り込みパイプライン

取り込みパイプラインは、企業の属性メタデータ（通常はExcel、CSV、またはAPI経由で維持）を取得し、検索可能でバージョン管理されたインデックスに変換します。各属性は1つのNDJSONドキュメントになり、attribute_id、タイプ、ビジネス名、技術フィールド、ドメイン、定義、同義語、演算子、しきい値条件から派生した派生属性のリストが含まれます。

クエリパイプライン（解析→検索→分類→明確化→ガバナンス→DSL）

アナリストが「高HbA1cで過去30日以内に再入院した糖尿病患者を表示」などの自然言語クエリを入力すると、パイプラインはまずフレーズ抽出と正規化を行います。次に、ハイブリッド検索（BM25+kNN+RRF）が各候補フレーズを属性インデックスに対して検索し、信頼度スコアを返します。分類器はフレーズを属性IDにマッピングし、低信頼度のマッチは明確化対話を通じてユーザーに確認します。ガバナンスチェッカーは、選択された属性がデータ権限、PHI制限、最小セルサイズなどのルールを満たしていることを検証します。最後に、DSLエミッターが検証済みの属性を組み合わせて実行可能なフィルター式を生成します。

ガバナンスのギャップ

標準RAGが規制された企業データで失敗する理由は、検索問題をドキュメント検索問題として扱うからであり、実際には属性選択問題だからです。アナリストが「糖尿病でHbA1cが高く、再入院した患者を表示」と尋ねると、正しいシステム動作は、カタログから適切な属性IDを選択し、あいまいなしきい値をユーザーに確認し、それらのフィールドのみを使用したフィルター式を生成することです。システムはこれを実行するために臨床ドキュメントの段落を検索する必要はありません。アナリストの自然言語フレーズに一致するガバナンスされた属性オブジェクトを検索する必要があります。

AK-RAGはこれを完全に回避します。検索単位がすでにガバナンスされた属性であるためです。システムはhba1c_highを生成できません。hba1c_highはカタログ内のattribute_idではないからです。システムは再入院時間枠を推測できません。フレーズが複数のガバナンス属性にマッピングされる場合、決定ポリシーが明確化を強制するからです。ガバナンスレイヤーは、DSLが発行される前に残りの違反をキャッチします。

なぜハイブリッド検索（BM25+kNN+RRF）か？

このパターンはハイブリッド検索を使用します。なぜなら、単独の字句検索も意味検索もエンタープライズ属性検索には十分ではないからです。BM25は正確なフィールド名の一致、頭字語、臨床略語に優れています。kNNベクトル検索は言い換えや意味的変異を処理します。相互ランク融合（RRF）は2つのランクリストを結合します。スコアを直接平均できないため、ランク位置に基づいて融合するため、クエリタイプ、埋め込みモデルの変更、インデックス再構築に対して安定しています。

開発者にとっての意味

AK-RAG参照実装は、動作するPython垂直スライスです。ローカル検索バックエンドを使用してOpenSearchクラスタなしでローカルで実行できます。プラグ可能なプロバイダマトリックスにより、開発時はローカル検索とsentence-transformersを使い、本番環境ではアプリケーションコードを変更せずにOpenSearch + OpenAI埋め込みに切り替えることができます。同じパイプラインはあらゆるエンタープライズドメインで機能します。6つのステップ（解析→検索→分類→明確化→ガバナンス→DSL発行）は、臨床属性、銀行リスク要因、KYCフィールド、保険引受パラメータのいずれでも同じです。

SuperMLの見解

AK-RAGが対処するのは、本番エンタープライズAIで最も一般的でありながら最も議論されていない問題の1つ、つまり存在しないフィールド名をLLMが自信を持って生成することです。構造化データモデルに対してRAGシステムを出荷したことのある人は誰でもこれを見たことがあります。プロンプトエンジニアリング、出力検証、リトライロジックで修正されますが、根本原因がアーキテクチャレベルにあるため、再発し続けます。標準RAGはドキュメント検索と自由形式合成に最適化されています。これはナレッジベースチャットボット、カスタマーサポートシステム、リサーチアシスタントには優れていますが、自然言語をガバナンスされたデータ操作（コホート定義、コンプライアンスクエリ、与信ポリシー評価、AMLルール検索など）に変換する必要があるシステムには間違ったアーキテクチャです。

銀行、医療、保険でAIシステムを構築するチームにとって、実際の問題は「AK-RAGを使うべきか？」ではなく、「インデックス化する属性カタログはあるか？」です。ほとんどの規制企業はすでにカタログを持っています。それはデータ辞書、メタデータ管理ツール、またはガバナンスプラットフォームにあります。取り込みパイプラインはExcel、CSV、またはAPI入力を受け入れます。属性ドキュメントスキーマはリポジトリで定義されています。独自のカタログに対してプロトタイプを動かすのに1日もかからないはずです。

オープンソースの参照実装はgithub.com/crazyaiml/attribute-knowledge-ragにあり、完全なパイプライン（コントラクト検証、NDJSON生成、オフラインハイブリッド検索、決定ポリシー、ガバナンスチェック、DSLアセンブリ）が含まれています。開発モードではクラスタなしで実行できます。本番デプロイでは、ローカル検索をOpenSearch BM25+HNSW kNNに、埋め込みsentence-transformersを本番埋め込みプロバイダに置き換えます。アーキテクチャはプロバイダに依存しない設計で、LLM、埋め込みモデル、検索バックエンドはすべてプラグ可能です。

もしあなたのエンタープライズAIシステムがデータモデルが聞いたこともないフィールド名を生成しているなら、修正方法はより良いプロンプトではなく、より良い検索単位です。