提到企业 RAG，很多讨论很快就会进入技术实现：文档怎么切片？Embedding 用哪个模型？向量数据库选什么？Top-K 设多少？要不要做 Hybrid Search？要不要加 Rerank？
这些问题当然重要。一个检索质量很差的 RAG 系统，不可能给出稳定可靠的回答。
但真正进入企业以后，我越来越觉得，向量数据库往往不是最难的问题，甚至不是决定项目成败的主要问题。
因为企业知识库面对的并不是一个单纯的“文档检索”问题。它真正要处理的是：
企业中什么信息可以被认为是知识，什么知识仍然有效，谁有权看到这些知识，以及这些知识之间究竟是什么关系。
而这背后，本质上是两个长期存在的问题：非结构化数据治理，以及结构化数据治理。
RAG 只是把这两个原本相对独立的问题，第一次同时推到了大模型面前。
一、很多企业把 RAG 理解得太“文档化”了
今天我们说企业知识库，最常见的想象是这样的：
Word / PDF / Excel / PPT
制度 / 手册 / 技术文档
↓
文档解析
↓
Chunk
↓
Embedding
↓
Vector Database
↓
Retrieval
↓
LLM
这确实是最经典的 RAG 架构，而且对于企业 AI 的第一阶段，它通常也是一个非常合理的起点。
因为企业中大量真正有价值的知识，原本就存在于非结构化文件中，例如管理制度、产品手册、技术规范、合同、SOP、设备说明书、故障记录、项目文档、邮件、会议纪要、OA 附件、培训资料。
这些内容过去的问题，是“有，但不好找”。
RAG 最直观的价值，就是让员工从：
我记得 somewhere 有一份文件。
变成：
我直接问企业知识库。
但当这个系统真正开始使用以后，很快就会发现另一个问题：
找得到，并不等于找得对。
因为企业内部真正困难的，往往不是“有没有文件”，而是哪一份才是最新版本、哪一份已经作废、哪一份是正式发布的、哪一份只是讨论稿、哪一份只适用于某个组织、哪一份员工有权查看。
到了这里，问题已经不再属于向量检索。
它属于：
非结构化数据治理。
二、非结构化数据最大的风险，是“看起来都像知识”
传统数据库至少还有表、字段、数据类型、主键、Schema 和约束。
但非结构化数据没有这么幸运。
一个共享目录里可能同时存在：
信息安全管理制度.docx、信息安全管理制度-最终版.docx、信息安全管理制度-最终修改版.docx、信息安全管理制度V2.docx、信息安全管理制度V2-李总意见.docx、信息安全管理制度V2-正式.docx、信息安全管理制度V2-正式(1).docx。
对人来说，这已经足够混乱。
对 RAG 来说，这七份文件都可能非常“相关”。如果全部进入知识库，它们都可能被召回，而大模型并不知道哪一个“最终版”才真的最终。
所以企业 RAG 第一个真正需要解决的问题，不是：
Chunk 应该切 500 token 还是 800 token？
而是：
这份内容到底有没有资格进入企业知识库？
我认为，这是企业 RAG 和个人知识库最大的区别。
个人知识库可以接受一定程度的混乱。
企业知识库不能。
因为一旦 AI 开始以企业名义回答问题，知识的“权威性”就变得非常重要。
三、企业知识首先要有“身份”
如果希望非结构化数据真正成为可治理的企业知识，那么每一份进入知识库的内容，都不应该只有正文。
它至少还应该拥有一组明确的元数据，例如：文档名称、文档编号、所属部门、知识分类、内容负责人、发布人、发布日期、生效日期、失效日期、版本号、状态、适用范围、密级、权限范围、源系统、原始文件地址、最后更新时间。
其中最重要的，可能不是标题，而是：
Owner、Status、Version、Effective Date、Access Scope。
也就是：谁负责？现在是否有效？当前是什么版本？从什么时候生效？谁可以看？
这几个字段决定了一份文件是不是“企业知识”。
没有这些信息，它最多只能算：
企业里存在的一份文件。
这两个概念不能混为一谈。
四、RAG 之前，企业其实应该先建立“可信知识源”
很多企业建设知识库时，第一步是：
把所有文档导进去。
我反而认为，这通常不是最好的第一步。
因为“全部导入”并不意味着“知识更完整”，它也可能意味着：
把企业历史上的全部混乱一次性放大。
更稳妥的做法，是先建立一个概念：
Authoritative Source，权威知识源。
例如，制度类知识只允许来自正式制度库；产品技术资料只允许来自业务部门确认后的正式资料；设备维修知识只允许来自经过验证的技术手册和已经关闭的正式工单；合同模板只允许来自法务确认的模板库；财务口径只允许来自正式的数据标准或财务制度。
这样做意味着，RAG 不应该是：
所有文件
↓
向量数据库
而应该是：
所有企业信息
↓
识别可信来源
↓
治理
↓
确认有效知识
↓
进入 RAG
这个过程看起来降低了知识库里的“文件数量”，但提高的是：
知识密度。
而对企业 AI 来说，知识密度往往比文件数量重要得多。
五、非结构化数据治理，真正要解决的是知识生命周期
企业知识不是静态的。
它会经历：产生、审核、发布、生效、更新、替代、归档、失效。
但很多 RAG 系统只处理了其中一步：
导入。
这会产生一个非常典型的问题。
例如一份制度 V1 已经被 V2 替代。如果只是把 V2 加进向量数据库，但没有把 V1 标记为失效，那么用户提问时，两个版本都有机会被召回。
这时模型可能会引用旧版本、同时引用新旧版本，甚至把两个版本合成一个现实中并不存在的规则。
所以一个成熟的企业知识库必须知道：
知识什么时候进入，也必须知道知识什么时候退出。
我甚至认为，企业 RAG 最容易被忽略的能力之一，就是：
知识失效机制。
如果知识只进不出，那么这个知识库最终一定会变成新的信息垃圾场。
六、真正进入企业以后，RAG 很快会遇到第二堵墙：结构化数据
如果企业知识库只是回答：
“公司的差旅制度是什么？”
传统 RAG 已经可以处理得很好。
但员工真正开始使用以后，问题很快会发生变化。
他们会开始问：
- 这个客户今年销售额是多少？
- 这个产品现在还有多少库存？
- 本月哪个销售区域毛利最低？
- 这台设备最近三个月发生过多少次故障？
- 某供应商过去一年的准时交货率是多少？
- 哪些客户超过信用额度？
这时，问题已经发生了本质变化。
答案不再存在于 PDF 或 Word 中，而存在于 ERP、CRM、MES、HR、WMS、财务系统、数据仓库和数据库中。
也就是说：
企业知识库最终一定会从非结构化知识，走向结构化数据。
而这时，仅靠向量数据库已经远远不够。
七、结构化数据真正困难的，也不是让 AI 会写 SQL
今天很多 Text-to-SQL 系统看起来非常惊艳。
用户问：
“今年华东地区销售额最高的五个客户是谁？”
模型生成 SQL，数据库执行，结果返回。
技术演示非常漂亮。
但企业真正落地以后，很快会发现，最大的问题并不是：
AI 会不会写 SQL？
而是：
销售额到底是什么？
这听起来似乎是一个很简单的问题，实际上可能并不简单。
销售额到底取订单金额、发货金额、开票金额、确认收入、含税金额、未税金额、本币金额，还是集团币种金额？
如果涉及退货怎么办？跨月订单怎么算？内部交易是否排除？取消订单是否计算？同一个客户的多个编码是否合并？
这就是结构化数据治理真正开始出现的地方。
模型可以非常聪明，SQL 也可以完全正确。
但如果业务口径本身没有统一，那么：
一个语法完全正确的 SQL，也可以得到一个业务上完全错误的答案。
八、结构化数据治理的核心，是“语义”
企业数据库中最容易被高估的是：
表里已经有数据了。
但“有数据”和“AI 能正确理解数据”之间，还有很长的距离。
数据库里可能存在：KNA1、VBAK、VBAP、BKPF、BSEG、MATNR、KUNNR、BUKRS、WERKS。
对系统来说，这些字段没有问题。对开发人员来说，也许也很熟悉。
但 AI 真正需要理解的是：客户、订单、产品、公司、工厂、销售收入、库存、毛利、应收账款。
也就是说，在原始数据和 AI 之间，还需要一个非常重要的层次：
Business Semantic Layer，业务语义层。
这一层告诉 AI：什么是客户、什么是订单、什么是有效订单、什么是销售额、什么是毛利、不同表之间是什么关系、哪些字段可以连接、时间应该使用哪个字段、指标应该如何计算。
所以我认为，未来企业 AI 的重要基础设施之一，并不只是向量数据库，而是：
数据目录、元数据、指标体系和业务语义层。
九、结构化数据首先要解决“一物多码、一数多义”
这其实也是传统数据治理里非常经典的问题。
例如同一个客户，在 CRM 里叫 ABC Trading，在 ERP 里叫 ABC Trading Ltd.，在财务系统里又可能叫 ABC Trading Co., Ltd.。
三套系统甚至可能有三个完全不同的客户编码。
那么当用户问：
ABC 客户今年总销售额是多少？
AI 到底应该查谁？
类似的问题还包括：一个产品多个编码、一个供应商多个主体、一个组织多个名称、一个指标多个定义、一个日期多个业务含义、一个“库存”可能同时包含可用库存、账面库存、在途库存、冻结库存。
传统报表时代，这些问题已经会造成数据口径争议。
到了 AI 时代，它会变得更加明显。
因为过去用户至少知道：
我正在看哪个报表。
以后用户只会问：
AI，告诉我库存是多少。
这意味着 AI 必须隐藏大量复杂性。
而要做到这一点，企业的数据治理必须比过去更加清楚。
十、所以，结构化数据不应该简单“全部 Embedding”
这里还有一个很常见的误区。
既然 RAG 可以检索知识，那么是否可以把数据库里的数据也全部转成文本，然后 Embedding 到向量库里？
某些场景当然可以。
但如果把它当成结构化数据的通用解决方案，我并不赞成。
例如库存数量：
产品 A，库存 1280。
今天是 1280，十分钟以后可能是 1260。
如果把这种高频变化的数据持续 Embedding，就会面临更新成本高、数据容易过期、精确计算能力变差、聚合能力有限、难以保证事务一致性等问题。
所以结构化数据更合理的方式，往往不是：
Database
↓
全部 Embedding
↓
Vector DB
而是：
User Question
↓
Intent Router
↓
┌─────────┴─────────┐
│ │
非结构化知识 结构化数据
│ │
RAG / Search SQL / API
│ Semantic Layer
└─────────┬─────────┘
↓
统一上下文
↓
LLM
这其实意味着：
企业知识库最终不是一个向量数据库，而是一个知识访问层。
这个区别非常重要。
十一、非结构化知识回答“规则是什么”，结构化数据回答“现在发生了什么”
如果用一句非常简单的话区分：
非结构化数据更擅长回答：
我们是怎么规定的？
例如差旅制度是什么、设备如何维护、合同审批规则是什么、信息安全制度有什么要求、某产品参数是多少。
而结构化数据更擅长回答：
现在到底发生了什么？
例如今天库存是多少、本月销售额是多少、哪个客户应收账款最高、哪台设备故障最多、哪个销售区域毛利最低。
但企业真正有价值的问题，往往会同时需要两者。
例如：
哪些客户已经超过信用政策规定的风险阈值？
这里至少包含两部分：
信用政策
→ 非结构化知识
客户应收账款、信用额度、逾期天数
→ 结构化数据
最后 AI 需要把两部分结合起来：
企业是怎么规定的？
以及：
当前哪些客户违反了这些规则？
这才是企业知识库真正开始产生价值的地方。
十二、真正困难的是把“知识”和“数据”连接起来
因此，我越来越不愿意把企业 RAG 简单理解为：
文档问答系统。
成熟的企业 AI 更可能面对的是这样的问题：
制度 / 合同 / 手册 / SOP / 会议纪要
↓
非结构化知识治理
↓
RAG
│
├──────────┐
│ │
ERP / CRM / MES / HR / 财务 / DW
↓ │
结构化数据治理 │
↓ │
语义层 / API / SQL ───┘
↓
企业 AI
这里真正困难的地方并不是哪一个技术组件。
而是：
两个世界使用的是不同的治理逻辑。
非结构化数据强调文档、版本、发布、生效、权限、内容负责人。
结构化数据强调表、字段、主数据、数据质量、指标、血缘、业务口径。
最终 AI 必须同时理解这两个世界。
十三、权限问题也必须同时跨越两个世界
当企业知识库只处理公开制度时，权限可能还比较简单。
但一旦同时接入非结构化与结构化数据，权限会迅速变复杂。
一个员工可能可以看销售制度，可以看自己负责客户的订单，不能看其他区域销售数据，不能看全公司的工资，可以看设备操作手册，但不能看董事会材料。
于是一个 AI 请求可能同时涉及：
文档权限、数据库行权限、字段权限、组织权限、知识分类权限。
这也是为什么我越来越认为：
企业 RAG 的权限不能只在向量数据库这一层做。
真正的权限应该尽量靠近源数据。
也就是说：
用户原来无权看到的数据，不能因为经过 AI 就突然变得可见。
AI 应该继承企业原有权限体系，而不是绕过它。
十四、企业知识库必须回答“这个答案从哪里来的”
还有一个我认为非常重要的问题：
可追溯性。
如果 AI 回答：
“根据公司政策，超过 90 天的应收账款需要进入重点风险管理。”
用户应该能够看到：这句话来自哪份制度、什么版本、哪一条、什么时候生效。
如果 AI 再回答：
“目前有 17 个客户符合这个条件。”
用户还应该能够知道：数据来自哪个系统、数据时间是什么时候、使用了什么指标口径、查询范围是什么。
这意味着成熟的企业 AI 输出，最好不是只有 Answer，而应该逐渐具备：
Answer、Source、Data Timestamp、Version、Scope、Permission Context。
这会极大提高员工对企业 AI 的信任，也会让错误更容易被发现。
十五、我更倾向于把企业 RAG 看成“知识治理的最后一公里”
传统数据治理经常给人一种距离业务很远的感觉。
数据标准、元数据、主数据、数据质量、数据血缘，很多员工并不会直接感受到这些工作。
但 AI 出现以后，情况正在发生变化。
因为所有治理问题最终都会变成一个非常直接的问题：
AI 为什么回答错了？
往下追以后，可能会发现：模型没有问题，RAG 也没有问题。真正的问题是制度版本错了、客户主数据没统一、指标口径没定义、权限没同步、文档已经过期，或者数据刷新延迟。
这时企业会第一次非常直观地感受到：
数据治理不是后台工作，它直接决定 AI 是否可信。
从这个角度看，企业 AI 可能反而成为数据治理最好的推动力之一。
十六、一个更现实的企业 RAG 架构
如果让我今天重新设计一套企业 RAG，我不会只画：
Document
↓
Embedding
↓
Vector DB
↓
LLM
我更愿意画成：
企业信息源
┌──────────────────────────┐
│ │
非结构化数据 结构化数据
│ │
制度 / PDF / Word ERP / CRM
手册 / 合同 / OA MES / HR
工单 / 邮件 / 知识文档 DW / Database
│ │
└──────────┬───────────────┘
↓
数据治理层
非结构化治理 结构化治理
文档分类 / 版本 数据标准 / 主数据
Owner / 权限 元数据 / 数据质量
生命周期 指标口径 / 血缘
↓
企业知识访问层
┌──────────────────────────┐
│ RAG / Search │
│ Semantic Layer │
│ SQL / API │
│ Permission Filter │
│ Metadata Filter │
│ Retrieval Router │
└──────────┬───────────────┘
↓
LLM
↓
企业 AI 应用
在这张架构图里：
向量数据库只是其中一个组件。
它很重要，但绝不是全部。
十七、企业 RAG 的建设顺序，也应该反过来
很多项目的建设顺序是：
先买模型
↓
选向量数据库
↓
把文件导进去
↓
做 Demo
↓
再想权限和治理
我更建议反过来。
第一阶段：选一个可信的非结构化知识域
例如 IT 制度、产品资料、设备技术手册、标准操作规程。
要求来源清晰、负责人明确、版本可控、权限简单。
先证明：
RAG 确实可以稳定帮助员工找到正确知识。
第二阶段：建立知识治理规则
开始补齐 Owner、Version、Status、Effective Date、Classification、Permission、Lifecycle。
把“文件”真正转成“可治理知识”。
第三阶段：接入结构化数据
选择一两个价值高、风险可控的场景，例如查询库存，或者查询销售数据。
但不要让 AI 直接自由访问整个生产数据库。
应该通过只读数据集、API、数据仓库、语义层、受控 SQL 逐步开放。
第四阶段：连接知识与数据
到这个阶段才开始真正做：
企业级问答。
例如：
根据公司的库存管理制度，目前哪些产品已经低于安全库存？
这里同时使用库存管理制度、安全库存规则、实时库存数据。
这已经远远不是传统“文档聊天”了。
十八、最终，企业需要治理的不是 RAG，而是“AI 能知道什么”
如果再往前走一步，我认为企业未来真正需要管理的，可能并不是：
RAG 平台。
而是：
AI Knowledge Boundary。
也就是：
AI 到底可以知道什么？
这个边界包括：什么知识可以进入 AI、什么数据可以被查询、谁可以问什么、AI 可以组合哪些数据、哪些结果可以输出、哪些行为必须记录、哪些知识必须失效、哪些数据必须实时。
到了这个层面，RAG 已经不再只是一个 AI 技术组件。
它实际上开始与数据治理、知识管理、IAM、信息安全、ITGC、企业架构逐渐汇合。
十九、结语：企业知识库真正缺的，往往不是一个更好的数据库
技术行业很容易把问题描述成产品选择。
哪一个向量数据库速度更快？哪一个 Embedding 模型效果更好？哪个 Rerank 模型排名更高？
这些当然值得研究。
但对大多数企业来说，真正决定 RAG 最终能不能长期使用的，可能是一些听起来并不那么“AI”的问题：
- 哪份文件是真的？
- 哪个版本有效？
- 谁对这份知识负责？
- 什么叫销售额？
- 哪个客户编码才是主数据？
- 谁可以看到这条数据？
- 这个答案什么时候会过期？
如果这些问题没有答案，那么再先进的检索技术，也只是在一个混乱的信息世界里更高效地寻找相似内容。
所以我越来越相信：
企业 RAG 知识库真正难的，从来不是向量数据库。
向量数据库解决的是：
怎么找到相似内容。
但企业真正需要解决的是：
什么内容值得被找到。
以及：
找到以后，我们能不能相信它。
而这背后，最终仍然回到了企业数字化最基本、也最难绕开的两件事：
把非结构化知识管起来。
把结构化数据讲清楚。
只有这两个基础真正建立起来以后，RAG 才不再只是一个漂亮的文档问答 Demo。
它才有机会真正成为：
企业知识与数据的统一入口。