屬性知識RAG模式：用於受監管AI代理的規範化檢索生成

在受監管企業中，構建RAG系統的團隊遲早會遇到一個共同的失敗模式：系統檢索到了正確的上下文（如臨牀指南、產品文檔、數據字典），但LLM卻生成了一段自信且流暢的響應，其中引用了實際數據模型中不存在的字段、閾值和標識符。在消費類應用中，這只是一個麻煩；但在銀行的信用承保流水線、醫療保健支付方的隊列識別系統或合規團隊的反洗錢查詢層中，這卻是一次治理失敗。LLM憑空創造了一個字段，而該字段從未經過數據治理，其輸出要麼毫無意義，要麼具有誤導性。

標準RAG並非為阻止這種情況而設計。它檢索文檔塊並將其作為上下文交給LLM，然後LLM根據這些上下文自由生成文本，包括任何字段名、標識符和閾值。沒有保證LLM生成的內容與數據目錄中實際存在的內容對應。提示級別的緩解措施——如僅使用來自所提供上下文的字段、少量示例、輸出驗證等——僅能起到邊際作用，無法解決結構性問題。問題在於檢索單元錯了。

屬性知識RAG（AK-RAG）是一種參考架構，它在檢索單元級別修復了這個問題。它不嵌入文檔，而是將你的治理屬性目錄作為獨立的知識對象進行索引——每個屬性一個嵌入，而不是每個文檔頁面一個嵌入。LLM的任務是短語提取和消歧對話，而不是字段名生成。最終輸出中可能出現的唯一標識符是存在於索引目錄中的attribute_id值。LLM無法發明字段，因為字段選擇是通過治理檢索和分類流水線完成的，而非通過自由生成。

架構

AK-RAG有兩個不同的流水線：一個構建屬性索引的攝取流水線，和一個將自然語言轉換為治理DSL的查詢流水線。兩者都圍繞一個核心原則設計：屬性目錄是知識層，而非文檔語料庫。

攝取流水線

攝取流水線獲取你的企業屬性元數據（通常以Excel、CSV或API形式維護），並將其轉換為可搜索、可版本化的索引。每個屬性變成一個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）結合兩個排序列表，由於它基於排名位置，因此在查詢類型、嵌入模型變化和索引重建中保持穩定。

對開發者的意義

AK-RAG參考實現是一個可工作的Python垂直切片。你可以使用本地搜索後端在本地運行，無需OpenSearch集羣。可插拔的提供者矩陣意味着你可以在開發時使用本地搜索和sentence-transformers，在生產環境中切換到OpenSearch+OpenAI嵌入，而無需更改任何應用程序代碼。同樣的流水線適用於任何企業領域——六個步驟（解析->檢索->分類->消歧->治理->發射DSL）在臨牀屬性、銀行風險因素、KYC字段或保險承保參數下都是相同的。

SuperML的看法

AK-RAG解決的是生產級企業AI中最常見但討論最少的問題之一：LLM自信地生成不存在的字段名。每個在結構化數據模型上交付RAG系統的人都見過這種情況。它被用提示工程、輸出驗證和重試邏輯修補，但它不斷出現，因為根本原因是架構層面的。標準RAG經過優化，適用於文檔檢索和自由形式合成，這對於知識庫聊天機器人、客户支持系統和研究助手來説非常出色，但對於任何需要將自然語言轉換為治理數據操作的系統來説，卻是錯誤的架構。

對於在銀行、醫療或保險領域構建AI系統的團隊，實際問題不是“我們應該使用AK-RAG嗎？”，而是“我們有屬性目錄可以索引嗎？”大多數受監管企業已經擁有目錄——它存在於數據字典、元數據管理工具或治理平台中。攝取流水線接受Excel、CSV或API輸入。在倉庫中定義了屬性文檔模式。讓原型針對你自己的目錄運行應該只需要一天，而不是一個衝刺。

開源參考實現位於github.com/crazyaiml/attribute-knowledge-rag，包括完整流水線：合同驗證、NDJSON生成、離線混合檢索、決策策略、治理檢查和DSL組裝。它在開發模式下無需集羣即可運行。生產部署將本地搜索替換為OpenSearch BM25+HNSW kNN，將嵌入式sentence-transformers替換為生產嵌入提供者。該架構採用提供者無關設計——LLM、嵌入模型和搜索後端都是可插拔的。

如果你的企業AI系統正在生成數據模型從未聽説過的字段名，解決方案不是更好的提示詞，而是更好的檢索單元。