屬性知識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系統正在生成資料模型從未聽說過的欄位名，解決方案不是更好的提示詞，而是更好的檢索單元。