属性知识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系统正在生成数据模型从未听说过的字段名，解决方案不是更好的提示词，而是更好的检索单元。