属性知识 RAG：为受监管场景重写检索单元

在银行信贷审核、医疗人群识别、反洗钱查询等受监管场景中，标准 RAG 架构暴露出了一个结构性的治理风险：检索到的上下文是准确的临床指南或产品文档，但 LLM 生成的回复却常常引用实际数据模型中并不存在的字段名、阈值或标识符。提示工程、少样本示例、输出校验等手段只能缓解问题，无法根治——因为问题出在检索单元本身。

核心思路：把属性目录当作知识层

属性知识 RAG（Attribute Knowledge RAG，简称 AK-RAG）是一种参考架构，其核心主张是：知识层不是文档语料，而是经过治理的属性目录。在 AK-RAG 中，系统索引的对象不再是文档分块，而是数据目录中的一个个属性（attribute），每个属性生成独立的 embedding。LLM 的职责被收窄为「短语抽取」与「澄清对话生成」，最终输出中出现的标识符只能是属性目录中真实存在的 attribute_id，从结构上切断幻觉字段的路径。

摄取管线：从元数据到可检索属性

摄取管线接收企业属性元数据（通常来自 Excel、CSV 或 API），经合同校验与归一化后，将每条属性序列化为独立的 NDJSON 文档。关键字段包括：

attribute_id：全局唯一标识，是最终输出中唯一允许出现的字段引用。
business_name / technical_field：业务名与技术字段名。
synonyms：同义词列表，提升自然语言检索召回。
governance：HIPAA 类别、最小单元格数、是否需要去标识化、允许的调用渠道等治理元数据。
embedding_text：手工拼接的检索优化文本，将类型、业务名、技术字段、同义词、定义关键词、领域标签串接起来，而非简单摘要。

索引支持多后端：开发环境使用本地 BM25 + token 向量 + RRF 融合，无需集群；生产环境推荐 OpenSearch BM25 + HNSW kNN + RRF；也可选用 FAISS 或 Chroma 等纯向量方案。索引按日期版本化，通过原子别名切换上线：

attributes_v2026_06_26（旧版）
attributes_v2026_07_06（新版）
attributes_current → 指向当前版本

这种机制保证元数据更新不会部分写入在线索引，部署后冒烟测试失败时回滚只需修改一个别名指针。

查询管线：六步确定性流程

查询管线包含六个步骤，LLM 仅参与其中两步（短语抽取、澄清对话），其余均为确定性逻辑：

短语抽取（LLM）：从用户自然语言中只抽取属性相关短语，不做字段名生成。例如「65 岁以上、HbA1c 偏高的糖尿病患者」被分解为 ["diabetic", "over 65", "elevated HbA1c"]。
混合检索：对每个短语独立执行 BM25 词项检索与 kNN 向量检索，通过 RRF 融合得到 Top-k 候选。
决策策略：按相似度阈值分级处理——
- score ≥ 0.92：精确匹配，直接采用；
- score ≥ 0.75：近邻匹配，向用户展示候选；
- 多个近邻且无明显最优：歧义，要求用户选择；
- 低于阈值：无匹配，请用户换一种说法。
澄清对话（LLM）：针对近邻或歧义短语生成澄清话术，用户从受治理的候选列表中选择。
DSL 生成：将解析后的短语映射为属性引用与运算符，组装成受治理的领域特定语言表达式。
执行：在确定性的查询引擎中执行 DSL，返回结果。

适用边界

AK-RAG 解决的是「LLM 必须引用真实存在字段」这一结构性约束，对金融授信、医疗质量报告、合规查询等需要审计可追溯的强治理场景尤为契合。其代价是引入额外的属性目录维护流程与索引治理机制，且要求业务方提前定义好属性元数据契约。对于消费级问答、内容生成等容忍幻觉的场景，标准文档 RAG 仍是更轻量的选择。