RAG 不是把文档塞进去:小团队知识库的 4 个最小字段

你好，我是nine~

很多团队第一次做 RAG，流程都差不多：

文档上传、切片、Embedding、塞进向量库，然后接一个大模型。

Demo 很快就能跑起来。

但真正给同事用几天后，问题开始出现：

“这个报销流程怎么还是去年的？” “这份操作手册是给客服还是给技术的？” “这个答案从哪个系统来的？” “这份文档现在到底谁负责？”

这时候很多人第一反应是：是不是模型不够好？是不是要换 Embedding？是不是 chunk 太大了？

其实，问题可能更靠前。

你的知识库只有“内容”，没有足够的业务信息。

最近 Reddit 的 RAG、LangChain 社区里，依然有开发者在讨论同一个生产问题：系统语义上确实找到了“相关文档”，但拿到的却是旧版本，最后模型基于旧政策给出了一个非常自信的回答。

所以对小团队来说，我现在更建议：

先别急着调一堆 RAG 参数，先给每份文档补上几个最基本的字段。

第一个字段：文档负责人 owner

最容易被忽略的字段，就是：

这份文档谁负责？

比如：

owner: 财务部-张三

为什么这个字段重要？

因为企业知识不是静态百科。

报销规则会变，产品说明会改，客服 SOP 会更新。如果没人负责，那么一份已经失效的文档，很可能还在向量库里正常参与检索。

owner 的作用，不只是方便找人。

它实际上是在回答：

这条知识出了问题，最后谁来确认？

以后发现 AI 回答有争议，你至少能迅速回到责任人，而不是在群里问一圈：

“这份文档谁写的？”

第二个字段：适用对象 audience

假设知识库里同时存在两份退款说明：

一份给客服内部使用，一份给普通用户看。

里面可能都有：

退款、审核、到账、工单这些词。

单纯靠向量相似度，两份都可能被召回。

这时候可以增加：

audience: 客服

或者：

audience: 用户

甚至进一步细分：

audience: 销售department: 华东区

然后在检索时先限定范围，再做向量搜索。

这也是目前主流向量数据库已经支持得很成熟的一种思路。Pinecone 和 Weaviate 的官方文档都把 metadata filter 作为标准检索能力：先根据属性缩小候选范围，再在其中做语义检索。

换句话说：

不是让 AI 从整个公司知识库里“猜哪份更适合你”，而是先告诉系统，你现在应该在哪个范围里找。

第三个字段：最后验证时间 verified_at

我觉得这是内部知识库里非常值得加的字段。

不是：

created_at

也不是：

updated_at

而是：

verified_at: 2026-08-01

它代表的是：

这份内容最后一次被业务人员确认仍然有效是什么时候。

区别非常大。

一份文件可能两年没改过，但规则现在仍然有效。

另一份文件可能上个月刚上传，但里面复制的是去年政策。

所以“文件更新时间”并不一定等于“业务有效时间”。

微软目前关于 RAG 的官方资料也一直强调，RAG 的价值之一就是获取私有或者持续变化的信息，而检索出来的 grounding data 是否正确，直接决定后续回答能否被可靠引用。

实际项目里，我会直接给知识库加一个规则：

超过 90 天没有验证的文档，降低优先级，或者进入待复核列表。

这样比等用户发现 AI 答错了，再去查原因省事得多。

第四个字段：来源系统 source

最后一个字段：

source: 飞书知识库

或者：

source: CRMsource_url: xxx

为什么要留？

因为 RAG 最终不是为了给用户一个“看起来合理”的答案。

而是最好能够继续回答：

依据是什么？

Azure AI Search 的相关架构里，也专门支持把文档内容和 metadata 一起建立索引，从而按作者、类型以及其他业务字段查询；Pinecone 的数据模型同样建议把相关上下文作为 metadata 与记录一起保存。

一旦保留来源，你后面才能继续做：

答案引用、原文跳转、来源追踪、错误排查。

否则用户问一句：

“这条规定从哪里来的？”

系统只能继续生成一段解释。

这就很危险了。

先别追求几十个字段

看到这里，可能有人会开始设计一张二三十列的 metadata 表。

其实也没必要。

如果团队不大，我建议先从这四个字段开始：

owneraudienceverified_atsource

然后再根据业务慢慢增加：

versiondepartmentdocument_typepermissionproductregionstatus

2026 年一篇针对 metadata-aware RAG 的研究也发现，在大量内容高度相似、结构重复的文档中，仅靠文本相似度容易发生混淆，而引入 metadata 信息能够帮助检索系统更好地区分文档。

这其实很好理解。

用户问：

“退款多久到账？”

向量检索只能判断：

哪段话和退款比较像。

但业务真正需要判断的是：

哪个产品、哪个用户类型、哪个版本、哪套规则下的退款。

两者不是一回事。

所以做企业知识库时，我越来越觉得：

RAG 的上限，不只取决于模型，也取决于你有没有把知识整理成“可以被判断”的数据。

切片只是把文档拆开。

元数据，才是在告诉系统：

这段内容是谁的、给谁用、现在还算不算数、出了问题去哪里查。

先把这四件事补齐，再去调 Top K、Embedding、Rerank，往往更值得。