🔒 RAGが医療・金融で壊れる理由、Attribute Knowledge RAGという解き方

「糖尿病患者で、直近30日以内に再入院した人」——この手の質問に答えるRAGを医療機関で組んだことがあるだろうか。ないなら、たぶんまだ幸せなうちだ。

うちも案件でクライアントの構造化データ(スプレッドシートの項目一覧・CRMのフィールド定義)を扱うことがあるが、LLMに自由に検索させると、存在しないフィールド名を平気で作文してくることがある。hba1c_high のような、いかにもありそうな名前を。実在するかどうかはLLMにとってどうでもいいのだ、そこにもっともらしい単語があれば。

標準RAGが構造化データで壊れる理由

読んだ記事は、この問題を「アーキテクチャの選び方が根本的に間違っている」と言い切っていた。

標準的なRAGは、ドキュメント全体をチャンクに割って埋め込み、テキストの断片を検索結果として返す。そのテキストからLLMがフィールド名を生成する工程が、どうしても自由生成になる。ここが壊れる場所だ。

Attribute Knowledge RAG(AK-RAG)は発想を変える。検索対象をドキュメントではなく、属性オブジェクトそのものにする。1つの属性(たとえば「HbA1cが9%以上」)を1つのNDJSONドキュメントとして埋め込み、検索結果として返すのは「属性IDの候補群」だけにする。LLMは検索されたID以外を出力できない仕組みだ。

6ステップのクエリパイプライン

仕組みはこう動く。

1. LLM解析      → ユーザーの質問から属性フレーズを抽出
2. ハイブリッド検索 → BM25 + kNN + RRFで候補を取得
3. 決定ポリシー   → スコア0.92ならEXACT確定、0.75ならNEAR(要確認)
4. LLM生成      → ユーザー向けの確認ダイアログを作る
5. ガバナンスチェック → PHI・HIPAA・最小セルサイズを検証
6. DSL出力      → attribute_idのみを返す

BM25とkNNを両方使っているのが地味に効いている。BM25は「A1C」のような略語や正確なフィールド名に強く、kNNは「先月の再入院」→「30日再入院」のような言い換えを拾う。片方だけでは足りない、という設計判断がちゃんと書かれていた。

曖昧な場合(HbA1cの閾値が複数解釈できるとき)は、システムが黙って推測せず、ユーザーに選ばせる。ここも刺さった。うちのcontext.mdの[未確認]ファクトの扱いと発想が近い。確信が持てないものを、確信ありげに出力させない。

ガバナンス層が属性ドキュメントに埋め込まれている

もう一つ面白かったのが、PHI(個人健康情報)やHIPAAカテゴリ、最小セルサイズといったコンプライアンス要件を、属性ドキュメント自体に持たせている点だ。

phi: true
hipaa_category: clinical
minimum_cell_size: 11
consent_required: true

検索結果にガバナンス情報がくっついてくるので、後段のチェックが「属性を引いたついでにできる」構造になっている。これを後付けのフィルタでやろうとすると、絶対どこかで漏れる。設計の初期段階でここを組み込んでおくべきだったと、自分のプロジェクトを思い返しながら読んだ。

日本語では見当たらなかった

Zenn・Qiitaを検索したが、この属性カタログ方式のRAGパターンを扱った記事はまだ見つからなかった。GraphRAGやナレッジグラフ×LLMの記事は多いが、あれは「関係性」を軸にした話で、AK-RAGの「実在するフィールドしか返さない」という制約の掛け方とは狙いが違う。

規制業界(銀行・医療・保険)でLLMエージェントを組む機会は日本でも増えていくはずで、そのときに「LLMに自由記述させない」設計をどう作るかは、案外まだ誰も書いていない領域なんだと思う。

全部のRAGに要る話ではないけれど

うちの案件ボールトのように「正解のフィールドが決まっている」データを扱うなら、この考え方はそのまま使えそうだ。逆に、答えが定型化できない自由記述の検索には向かない。使いどころを見極める必要はある。

構造化データの上でLLMを安全に動かしたい人は、一度原文を読んでおいて損はない。あなたのプロジェクトでも、LLMに「実在しないフィールド」を生成された経験、ないだろうか。