Appearance
3.3.5 为什么很多企业 RAG 效果差，本质上是 Metadata 设计不完整？
先给结论：很多企业 RAG 效果差，看起来像模型问题或检索问题，但往前追根因，最后经常会落到 metadata 设计不完整。
因为企业场景真正难的，往往不是“有没有文本”，而是：
- 文本属于谁
- 什么时候有效
- 哪个版本优先
- 谁有权限用
- 当前问题应该在哪个业务边界里检索
而这些信息，大多都要靠 metadata 承载。
为什么企业场景特别依赖 metadata
企业 RAG 和公开资料问答最大的不同之一，是它很少只有“语义相关”这一层判断。
企业里经常还会同时存在：
- 租户边界
- 权限边界
- 组织边界
- 时间边界
- 版本边界
- 产品线边界
如果这些边界没有通过 metadata 清楚表达出来，系统就很容易进入一种状态：
看起来知识很多，但实际很难稳定检索、过滤和治理。
企业 RAG 效果差时，最常见的几类症状
1. 新旧版本经常一起出现
这通常说明：
- 没有
version - 没有
status - 或者有字段，但后面的检索和排序没真正用起来
2. 不同租户或不同部门内容互相干扰
这通常说明：
- 没有稳定的
tenant_id - 没有组织和权限边界字段
- 或者字段进入了存储，但没进入检索 filter
3. 同一问题在不同用户下回答不该一样，却经常一样
这通常说明：
- metadata 不足以表达访问边界
- 或者边界信息没有贯穿到检索和 Prompt 构造
4. 来源和引用解释不清
这通常说明：
- 没有稳定
doc_id - 没有标题、章节、来源字段
- chunk 和原文的结构关系没有保留
5. 文档更新后，系统还长期答旧内容
这通常说明：
- 更新时间和状态字段不完整
- 更新链路没有按 metadata 做增量处理
- 缓存和索引没有跟着当前 metadata 状态一起切换
这些问题表面上很分散，但底层常常都能追到 metadata。
一个更直接的理解方式
企业 RAG 里，chunk 文本解决的是：
- 这段话说了什么
metadata 解决的是：
- 这段话到底算不算当前应该被使用的知识
如果只有前者，没有后者，系统就会很容易出现：
- 语义相关，但业务上不该用
- 文本正确，但版本不对
- 内容有用，但用户无权看
所以很多企业 RAG 的难点，根本不在“文本不够多”，而在“文本的边界信息不够完整”。
一个最常见的误判
很多团队一看到效果差，会先想：
- 是不是 embedding 模型不够强
- 是不是 rerank 不够好
- 是不是 Prompt 没写对
这些当然也可能有问题，但企业场景里有一种更常见的情况是：
系统根本还没有把 metadata 设计成一个完整可执行的边界体系。
这时你即使换更强模型，也只是让系统在错误边界上回答得更流畅一点。
一个更实用的自查方式
如果你想快速判断当前问题是不是 metadata 设计不完整，可以先问：
- 当前 chunk 除了文本，还有没有清楚的来源、版本、状态、边界信息？
- 这些字段有没有真正进入索引和检索 filter？
- 排序、引用、权限、更新链路里有没有真的用到这些字段？
- 如果用户问“为什么用了这段内容”，系统能不能解释清楚？
如果这些问题里有几个答不上来，那问题很可能已经不再是“模型效果”层面，而是 metadata 层面。
一个更工程化的判断
可以把企业 RAG 常见问题粗略分成两类：
更像文本问题
- 召回文本本身就不相关
- 正文质量差
- 清洗和切块明显有问题
更像 metadata 问题
- 版本打架
- 权限串边界
- 多租户混召回
- 来源和引用不清
- 更新后旧内容长期不退场
很多企业系统真正难受的，往往是第二类。
一句话总结
很多企业 RAG 效果差，本质上不是模型不够强，而是 metadata 设计不完整。因为企业场景真正难的，不只是理解文本，而是理解文本在当前版本、当前权限、当前租户和当前业务边界下到底能不能被使用。