一家大型企业有几十万份文档，究竟应该怎样交给AI？

国庆节前帮助上海一家大型国企客户完成了几十万份文档的入库，期间当然也出现过一些问题，把大量文档导入知识库并不是想象的那么简单。所以我想统一来回答一下最近几个月和大型企业交流 AI 项目的时候，经常会碰到一个看起来很简单的问题：

“我们公司已经积累了几十万份文档，能不能全部放进知识库，让AI直接使用？”

如果只是从技术上回答，当然可以。

现在无论文档解析、向量数据库、RAG还是大模型，都已经相当成熟。几十万份文档导进去，从存储和计算能力上来说，并不是什么特别困难的事情。但这两年做过越来越多大型企业的知识库项目以后，我反而越来越觉得：

“导进去”，可能恰恰是整件事情里最容易的一步。

因为几十万份文档放进去之后，真正麻烦的问题才刚刚开始。

这些文档都是有效的吗？比如常见的问题就有：

• 同一份制度有三个版本，AI应该相信哪个？
• 正式发布的制度和某次会议纪要里的说法不一样，哪个才是权威知识？
• 一个员工原本没有权限查看的文件，他使用的Agent能不能看到？
• 今天花几个月整理好的几十万份文档，半年以后又新增了几万份、修改了几万份，谁来保证AI拿到的还是正确的知识？

所以，当一家企业的知识从几百份、几千份增长到几十万甚至上百万份（我们的客户里面，最多的已经突破550万份文档）的时候，我觉得问题的性质已经完全变了。

企业真正要解决的是建立一套机制，持续把正确的知识，在正确的时间，以正确的权限交给AI。

换句话说，我们需要的可能不是一个更大的“AI知识库”，而是一条具备知识工程能力的，能够持续运转的企业知识供应链。

一、几十万份文档，首先不是“大”，而是“散”

很多人第一次听到“几十万份文档”，首先想到的是规模。

向量数据库能不能存得下？检索会不会变慢？

Embedding需要多久？需要多少服务器？

这些当然都是问题。

但我们实际进入大型企业以后，会发现另外一个问题往往更早出现：

这几十万份文档到底在哪里？

一家几十人、几百人的公司，可能把主要资料放在飞书、企业微信或者一个共享网盘里。

但是到了大型企业，完全不是这样。

• OA里面有大量制度和流程文件；

• ERP里面有采购、供应链和生产相关的数据；

• CRM里面有客户和销售资料；

• 企业微信/钉钉/飞书里又沉淀了一批文档和知识库；

• 还有NAS、FTP、对象存储、数据库，以及大量已经运行了十几年甚至更久的业务系统。

集团型企业还会更复杂。

所以我们进入一个大型企业做知识库项目时，真正需要先搞清楚的，往往不是RAG怎么做，而是：

• 企业的知识到底分布在哪里？

• 哪些是权威来源？

• 哪些还在持续更新？

• 谁负责维护？

• 访问权限怎么规定？

这也是为什么我现在越来越觉得，对于大型企业来说，“上传文件”其实是一个很容易让人产生误解的产品概念。

因为上传是一种一次性动作，今天把10万份文件上传完了，看起来任务完成了。

但一个月以后呢？OA里新增了3000份文件，钉盘里修改了500份，某个制度废止了，一个子公司的产品手册更新了。

如果这些变化不能持续进入AI，那么你在上线那一天建立的知识库，从第二天开始其实就已经在逐渐变旧。

所以，大型企业真正需要的不是：

“

Upload

而是：

“

Connect + Sync

不是把文件搬进来，而是把AI知识平台和企业原来的知识源连接起来，让知识能够持续流动。

这也是我们这段时间为什么越来越重视 Connector的开发。

企业微信、钉钉、飞书、OA、NAS、数据库、对象存储、各种业务系统……它们不应该只是项目上线之前进行一次“数据迁移”，而应该成为企业AI持续获取知识的来源。

AIS现在也在沿着这个方向建设，包括自动同步、定时增量、Webhook、失败重试，以及NAS、API、S3/OSS等不同接入方式。我觉得这里真正重要的并不是我们支持了多少个Connector，因为随着一个个项目地交付，Connector也会越来越多。

但这里真正重要的是背后的思路变了：

“

小型知识库解决的是“把文件放进来”。

企业级知识平台解决的是“让知识持续流进来”。

这两件事情看起来很像，实际上完全不是一个工程。

二、企业拥有的几十万份“知识”，很多其实只是几十万份“文件”

知识接进来以后，下一个问题可能更麻烦。

我们经常会说：

“这家企业有30万份知识。”

但如果真的打开这些所谓的“知识”，你会发现情况可能完全不是想象中的样子。

有的是扫描PDF，有的是几十年前留下来的Word，有的是三四百页的制度，有的是PPT，真正有价值的信息都在图里面。有的是Excel，而且一个工作簿里面十几个Sheet，各种合并单元格。有些PDF一半是文字，一半是扫描图片。有些文件页眉页脚占了很大比例。有些带水印。有些是同一个文件复制了七八份，只是文件名不同。有些文档完全没有标题结构。有些表格甚至人看起来都很费劲。还有音频、视频、图片、XMind，以及大量企业内部非常特殊的文档格式。

这时候一个很有意思的问题就出现了：

如果一个人打开这些资料都会觉得乱，我们为什么会认为，把它们全部丢给AI以后，它们就会自动变成高质量知识？

其实不会。

这也是我们这几年做企业AI知识库项目一个越来越深的感受：

大家很容易把注意力集中在“检索”上。

• Embedding选哪个？

• 向量数据库选哪个？

• 还有很多很多...

这些当然重要。

但是很多问答效果的问题，根本不是发生在检索阶段。它可能在文件刚刚进入系统的时候，就已经发生了。比如一个表格解析错了，表头和数据的关系丢失了。一个PDF的章节结构没有识别出来，原本属于第三章的内容被错误地拼到了第二章。或者一个300页的制度被按照固定字符数机械切成几百块，原来完整的业务语义被切碎了。

后面再强的Embedding、Rerank和大模型，都只能在已经被破坏的知识上继续工作。所以我们后来把越来越多的精力放到了一个以前很容易被忽略的环节：

“

知识工程

原始文件进来以后，不应该直接进入向量数据库，它应该先经过一个加工过程。

“

解析—清洗—结构化—切片—抽取—分类—打标签—校验

必要的时候还要经过人工审核，最后才是准入。

在AIS里，我们现在把知识校验、智能预标注、文本预处理、内容审核、知识抽取和知识准入都放在知识正式进入生产环境之前。这有点像工厂。原材料运到工厂门口，并不代表它已经可以直接装到最终产品上。它需要清洗、加工、质检。

知识也是一样。

所以我现在甚至觉得：

“

RAG的上限，很多时候不是由检索决定的，而是在知识进入RAG之前就已经决定了。

一个知识库里面如果本身充满了错误、残缺、重复、过期的知识，再好的检索算法也没有办法从根本上解决问题。

它最多只是更准确地找到那些有问题的知识。

三、真正危险的不是AI找不到，而是AI找到了错误的知识

这是我们在大型企业项目里越来越重视的另一个问题,知识库刚开始做的时候，大家最担心的是：

“资料明明有，AI为什么找不到？”

所以大家不断优化召回率。

但是系统真正进入生产以后，我觉得还有一种风险其实更加危险：

AI找到了。

而且找得非常准,但它找到的是一份已经失效的文件。

举一个非常简单的例子。

一家企业有一份2024年的差旅管理办法，2025年修改了一版，2026年又重新发布了一版。三个版本可能都还存在企业的文件系统里面。

现在员工问：

“我去北京出差，住宿标准是多少？”

如果RAG非常准确地召回了2024年的制度，然后大模型基于这份制度给出了一个非常完整、语言也非常自然的答案，这个答案到底算不算“准确”？

从RAG技术角度看，它可能非常准确。

文件找对了，内容引用对了，模型也没有幻觉。但是从企业业务角度看，它就是错的。而且这种错误比“没有找到答案”更加危险。

而版本只是其中一种情况，大型企业里面还会存在更多复杂的问题。

这个案例后来也让我对“企业知识”有了更多理解。

一份文件的正文，只是知识的一部分。

它的来源是谁？哪个部门发布？什么时间生效？现在是否有效？适用于什么范围？谁是Owner？有没有更高优先级的知识？

这些东西同样是知识的一部分，甚至在企业场景里面，它们有时候比正文还重要。

所以，当企业有几十万份文档以后，我们真正要管理的，其实已经不是几十万个文件。

而是几十万个带着来源、版本、权限、状态、责任和业务语义的知识对象。

这也是为什么我觉得，企业AI做到一定规模以后，知识治理一定会变成一个绕不开的问题。

四、还有一个问题，到了Agent时代会突然变得很严重：它到底能看什么？

以前做企业知识库，权限问题其实就已经很重要，但是进入Agent以后，我觉得这个问题会被进一步放大。

举一个很简单的场景。

员工A没有权限查看公司的薪酬数据，这件事情大家都很好理解，但现在员工A不是自己去知识库搜索。

他告诉一个Agent：

“帮我分析一下公司最近的人力成本变化，然后写一份报告。”

Agent开始自主执行任务。它可能先拆解任务，然后搜索知识库，再查询数据库，再读取几份文件，最后把这些信息组合起来生成报告。

那么问题来了：

这个Agent到底是谁？它应该拥有什么权限（穿透还是不穿透）？是Agent自己的权限？是员工A的权限？还是这个业务应用被预先配置好的权限？

如果Agent调用了三个不同系统，而这三个系统的权限模型又不一样，该怎么办？这已经不是传统知识库里“这个用户能不能打开这个文件”那么简单了。更麻烦的是，Agent不仅会读，它还可能会写。

比如一个Agent分析完售后问题以后，把新的维修经验写回知识库。另一个Agent生成了一份制度草稿，然后提交审核。还有Agent可能自动修改某些知识标签，或者触发一个知识治理任务。

这时候就又会出现新的问题：

谁允许它写？写进去以后是不是直接生效？需不需要审核？出了问题以后能不能知道是哪一个Agent、代表哪一个用户、在什么任务里修改的？

所以我觉得，Agent时代的权限模型需要比传统知识库再往前走一步。

它至少要回答：

“

这个Agent代表谁？

它现在在执行什么任务？

它被允许获取什么上下文？

它可以执行哪些动作？

整个过程能不能被审计？

我比较喜欢用一句话来概括：

“

Agent获得的企业上下文，不应该取决于“它能找到什么”，而应该取决于“它代表谁、正在做什么、被允许知道什么”。

这也是为什么我们现在在AIS里越来越强调“检索前权限过滤”。不是先把所有内容召回来，再看看哪些不能给用户看。而是在检索发生之前，就根据用户、组织、知识库和文档权限确定它到底能够进入哪个知识范围。

同时，Agent通过Skill、MCP或者API访问AIS的时候，也需要有不同的权限边界。现在我们的MCP已经区分readonly、write和admin等不同等级。系统里面的操作、问答、引用、配置变化以及完整执行链路也需要能够留下记录。

因为当Agent只是回答一个问题的时候，错误的代价可能只是一句话答错。但当Agent真正开始参与企业业务、调用工具甚至执行动作以后，权限错误带来的就可能是真正的业务风险。

这也是为什么我一直觉得：

“

企业Agent和个人Agent，其实是两个非常不同的问题。

个人使用AI的时候，可以把自己的资料全部交给它，但企业不行，企业的知识从来都是有边界的。

五、还有一个经常被低估的问题：今天整理好了，半年以后怎么办？

假设前面的问题全部解决了，企业花了几个月时间把几十万份文件全部梳理完成。知识源接好了，文档解析好了，重复文件清掉了，版本理顺了，权限也配置好了，然后经过几轮测试，准确率也达到要求。

项目正式上线，是不是终于可以松一口气了？

我这两年越来越强烈的一个感受是：

“

企业级AI知识库真正困难的部分，很多时候是从上线以后才开始的。

因为企业不是静止的，假设上线的时候有30万份知识，半年以后可能新增了3万份，修改了2万份，几百份制度发生变化。我们现在文档最多的一个客户已经超过了550万份。

另外，一批产品下线，一批新产品发布，有人调岗，有人离职，部门组织架构调整，业务流程变化，新的监管政策出台。你看看这些都是问题。

与此同时，AI自己也在产生新的问题。

所以一个企业AI系统的效果，不可能靠上线前那一次“知识整理”永久保持。这也是我们为什么越来越重视知识运营。

以前做传统软件项目，大家习惯一个思路：

开发 → 测试 → 验收 → 上线。

项目上线，意味着建设阶段基本结束，但是AI知识系统不是这样。我甚至觉得它更像一个长期运行的业务系统：上线只是开始。

比如用户问了一个问题，AI回答错了。以前我们可能只是记录一个“点踩”。

但现在我们会继续追为什么错：

• 是没有理解用户的业务表达？

• 是知识根本不存在？

• 还是知识存在，但是已经过期？

• 是两份知识发生了冲突？

• 还是检索召回错了？

• 又或者因为权限和合规要求，系统不能回答？

不同原因，后面的处理动作完全不同。然后重新审核，重新入库。

然后拿原来的问题再测一次。确认问题真的解决了以后，才关闭这个任务。

于是一个原来很简单的：

“

用户点踩

慢慢变成了一条：

“

问题反馈 → AI归因 → 责任人处理 → 知识更新 → 审核 → 回归验证

的闭环。AIS目前也在按照这条路径持续完善。

我们最近在给大型银行做知识库运营管理规范的时候，也越来越清楚地看到这一点。当知识规模足够大以后，不可能靠某一个管理员“有空的时候整理一下”，它需要真正的运营机制。关于运营管理规范会单独写一篇文章，这里就不展开了。

企业知识库真正的质量，不应该看上线那一天有多准，而应该看运行一年以后还能不能保持可信。

如果一个知识库上线的时候95分，一年以后因为大量过期、冲突和无人维护的知识只剩70分，那么上线时的95分其实没有太大意义。

企业需要的不是一次高分，而是一套让它长期维持高质量的机制。

六、所以，几十万份文档究竟应该怎样交给AI？

写到这里，我们可以重新回到文章最开始的问题。

一家大型企业有几十万份文档，到底应该怎么交给AI？

如果是两年前，我可能会比较自然地回答：

“

建一个企业级AI知识库。

但今天我越来越觉得，这个答案还不够，因为“知识库”这个词太容易让人想到一个容器。

而AI时代发生了一个很大的变化：

“

知识开始真正进入生产过程。

过去员工自己搜索一份制度，看完以后做判断；现在Agent会自动获取制度，然后基于制度完成下一步任务。

过去工程师自己找到维修手册，再决定怎么处理设备；现在Agent可能会读取手册、历史维修案例、设备状态，然后直接给出诊断建议。

过去研究人员自己找十几份报告进行分析；未来Agent可能自主搜索、比较、推理，然后生成研究结果。

所以知识不再只是“被人阅读”，它开始成为AI执行任务时实时消耗的一种生产资料。

这时候，企业真正需要的东西其实更像一条供应链。

我把它简单画成这样：

我现在很喜欢用“企业知识供应链”这个词来理解这件事情。

因为它和现实世界的供应链其实很像，企业的各种系统和文件，是原材料来源，Connector负责把原材料持续送进来，知识工程负责加工，知识准入相当于质检。权限、版本、知识健康和生命周期管理负责保证整个供应体系的质量和安全，RAG、API、Skill、MCP负责把最终可用的知识送到需要它的AI和Agent手里，而用户反馈、评测和业务结果，又不断反向告诉这条供应链：哪里出了问题，哪里需要改进。所以：

大型企业真正需要建设的，不是一个存放几十万份文档的“AI仓库”，而是一条能够持续向AI供应可信知识的“企业知识供应链”。

这个区别，我觉得非常重要。

仓库关心的是：

“

我有多少东西。

供应链关心的是：

“

正确的东西，能不能在正确的时间，到达正确的地方。

这可能也是企业知识库进入Agent时代以后，一个非常重要的变化。

七、文件不是知识，知识也不是上下文

如果再往前走一步，我觉得还有一个概念需要区分。

“

文件、知识和上下文，其实是三件不同的事情。

一个PDF，是文件。

经过解析、清洗、结构化、版本确认、权限确认以后，它才逐渐变成可以被企业使用的可信知识。

但是即使变成了可信知识，也不代表应该把它全部塞给大模型。因为一个Agent在完成具体任务的时候，只需要其中和当前任务相关的那一部分。

比如一个售后Agent处理某台设备故障。

它需要的可能是：

• 这台设备的型号；

• 当前故障码；

• 对应版本的维修手册；

• 过去三个月相似故障的维修案例；

• 客户当前的维保状态；

• 以及公司规定的处理流程。

企业可能有100万份知识，但是这个Agent此时真正需要的上下文，也许只有其中几十条。

所以企业AI真正需要解决的最后一道题，不是：

“

“我们有多少知识？”

而是：

“

“面对当前这个人、这个任务、这个时间点，AI究竟应该获得什么？”

我觉得这才是企业上下文真正有意思的地方，它不是把企业所有资料都塞进Prompt。而是在一个具体任务发生的时候，从庞大的企业知识和业务数据中，动态找到最合适、最可信、当前用户又有权使用的那一部分，然后交给AI。

所以我们过去一直讲RAG，现在开始讲Agent，但再往后，我认为越来越多企业最终会发现：

“

RAG和Agent中间，其实还需要一个很重要的层——企业上下文层。

它向下连接企业的文档、数据库、业务系统和知识资产。向上服务各种RAG应用、Agent和未来不断出现的AI应用。

它负责的不只是“搜索”，还包括来源、版本、权限、质量、语义、生命周期和可追溯性。

这也是为什么我一直认为：

“

模型越来越强，并不会让企业知识基础设施变得不重要。

恰恰相反。

“

模型越强，Agent能做的事情越多，企业就越需要保证它拿到的上下文是可信的。

否则一个能力很弱的AI拿到错误知识，可能只是答错一个问题。一个能力很强、又可以自主执行任务的Agent拿到错误知识，反而可能把错误放大成一个真实的业务动作。

八、回头看AIS这几年的变化，其实也是被这些问题一步步推着走过来的

TorchV刚开始做企业AI知识库的时候，我们关注最多的，其实也是RAG。

怎么解析得更好？怎么切片？怎么提高召回？怎么让答案更准确？怎么引用原文？

这些问题直到今天依然非常重要。但随着接触的客户越来越大，进入银行、大型集团、制造企业、专业服务机构以后，我们发现问题开始不断往外扩。

客户会问：

• 企业微信、钉钉、NAS里的资料怎么自动进来？

• 扫描PDF和复杂表格怎么办？

• 一份知识有多个版本怎么办？

• 两个部门知识冲突怎么办？

• 知识过期了怎么发现？

• 不同部门权限怎么继承？

• Agent怎么使用这些知识？

• 出了错误以后怎么知道是知识问题、检索问题还是模型问题？

• 系统上线以后谁来持续运营？

于是AIS也被这些问题一步一步推着往前走。

从最早关注RAG，到知识接入。从知识接入，到知识工程。从知识工程，到知识治理。再到知识健康、生命周期、反馈评测，以及现在我们越来越关注的Agent上下文供给。

所以今天我们把TorchV AIS定义为：

“

企业级AI知识引擎，而且正在往知识中台的路上狂飙。

它现在覆盖的也已经不是一个单独的问答链路，而是知识接入、知识工程、知识治理、知识应用和反馈优化这样一条完整链路。

但如果抛开产品名字，我觉得我们真正想解决的问题其实一直没有变：

“

怎样让企业自己的知识，可以被AI长期、安全、准确地使用。

这也是为什么我们现在越来越少把AIS仅仅理解成一个“RAG知识库”。

我们更希望它成为：

“

大模型和Agent使用企业知识之前的那一层基础设施。

向下，把散落在企业各处的知识接进来。中间，把它加工好、治理好、持续维护好。向上，再通过检索、API、Skill、MCP等方式，把可信的企业上下文提供给各种AI应用和Agent。最终企业不需要为每一个Agent重新建设一套知识库。

同一套经过治理的企业知识，可以成为越来越多AI应用共同使用的底座。这也是我们现在对AIS的定位：

“

让企业知识成为大模型与Agent可靠使用的上下文。

最后

回到文章开头那个问题。

如果现在再有一家大型企业问我：

“我们公司有几十万份文档，能不能全部交给AI？”

我的答案依然是：

当然可以。

但我可能会紧接着问一句：

“然后呢？”

• 谁告诉AI哪些知识是对的？哪个版本有效？

• 谁决定什么人可以看到什么？谁负责这些知识持续更新？

• 半年以后，怎么保证今天这几十万份知识仍然可信？

如果这些问题没有答案，那么把几十万份文件导进向量数据库，只是完成了一次规模很大的文件搬家。

它还没有真正变成企业AI可以长期依赖的知识基础设施。

所以我现在越来越相信：

AI时代的企业知识建设，最终不会只是建设一个越来越大的知识库。

而是需要为企业建立一条新的供应链，过去企业有资金供应链、人才供应链、数据供应链，未来可能还会有一条越来越重要的：

“

企业知识供应链。

这条链路一旦真正建立起来，企业积累几十年的制度、经验、产品资料、项目案例和专业判断，才不再只是躺在文件服务器里的历史资料。它们会开始真正进入每一次AI推理、每一个Agent任务和越来越多的业务流程。

我觉得这才是“把企业知识交给AI”真正的含义。

最近我们也在和银行、大型集团、制造企业以及专业服务机构不断讨论类似的问题，大家的知识规模、IT环境和组织方式差别很大，但最后碰到的问题却越来越相似：知识在哪里？怎么接？怎么加工？谁负责？哪个版本有效？AI能看什么？怎么保证半年、一年以后仍然可信？

如果你的企业也已经积累了大量文档，正在考虑怎么把这些知识真正交给大模型和Agent，我也很愿意交流。

不一定先聊产品。我们可以先把一件事情做清楚：把你们企业的“知识如何流向AI”画成一张图。

很多时候，这张图真正画完以后，你会发现：企业AI的知识问题到底卡在哪里，其实已经清楚了一半。