ARTICLE · 1292429
把文档都塞进 AI,为什么仍然搭不好一个知识库?
摘要：上下文窗口越来越长，向量数据库越来越便宜，很多团队以为"把文档喂给 AI"就等于有了知识库。但过去两年的研究反复指向同一个结论：模型能"读到"，不代表能"用好"；文档存进去了，也不代表知识存在。知识库真正的难点，从来不在 AI 那一侧。
一个几乎每家公司都见过的场景
先看一个典型场景（为说明问题而概括的假设情形，不对应某家具体公司）。
某公司决定搭一个 AI 内部知识库。 IT 部门把共享盘里三千多份文档——制度、流程、产品手册、会议纪要、历年方案——一股脑导入，接上大模型，做了个对话框。
演示那天效果很好。问"报销流程是什么"， AI 对答如流，还附上了出处。
上线一个月后，抱怨开始出现：
慢慢地，员工又回到了老办法：在群里问"有谁知道……"。
这不是某个模型不够聪明的问题。换更大的模型、更长的上下文，大多数症状依然存在。
原因在于一个很常见的误会：把"存进去"当成了"知道了"。
这篇文章想把这个误会拆开讲清楚。它至少有四层：模型读长文本的能力有边界；把文档切碎检索会丢失意义；有些问题根本不是"找到一段话"能回答的；以及最深的一层——很多知识压根就不在文档里。
第一道坎：塞得越多，读得越差
最省事的方案是"全塞进去"。现在主流模型动辄宣称支持几十万甚至上百万 token 的上下文，一整套制度文件放进去绰绰有余。既然放得下，为什么还要费劲做检索？
问题在于，"放得下"和"读得好"是两件事。
2023 年，斯坦福等机构的研究者发表了一篇后来被大量引用的论文《 Lost in the Middle 》（迷失在中间）。他们把一个问题的答案藏在一堆文档里的不同位置，观察模型的表现。结果呈现出一条 U 形曲线：答案在开头或结尾时，模型表现最好；答案在中间时，表现显著下降——即使是专门标榜长上下文的模型也是如此。
如果你觉得这是早期模型的问题，后来的研究并不乐观：
最后这一点，对知识库尤其要命。
想想企业的文档库是什么样子：同一份制度有三个版本，同一个项目有五份方案稿，同一个问题在不同会议纪要里有不同说法。企业文档天然就是一个充满"干扰项"的环境。把它们全部塞给模型，等于在考场上发给考生一份混着往年错误答案的参考资料。
Chroma 的报告里还有一个反直觉的发现：把背景文本的句子随机打乱后，模型找信息的表现反而比读通顺连贯的文章更好。研究者自己也说这个结果令人意外。一种可能的解释是，连贯的文本更容易"吸住"模型的注意力，让它更难把目标信息从语境中剥离出来。这一点目前还是推测，但它至少提醒我们：模型读长文本的方式，和人类读文件的方式并不一样。
所以，"全塞进去"不是知识库，它只是把检索的难题，原封不动地转交给了模型的注意力机制——而后者并不擅长处理这个问题。何况，每次提问都塞进几十万 token ，成本和响应速度也会让这个方案很难规模化。
第二道坎：切碎之后，意思丢了
切块时丢失的上下文，需要通过文档身份与元数据补回来。
于是更主流的方案登场： RAG ，检索增强生成。
它的原理可以用一个类比来理解。与其让 AI 每次都把整座图书馆读一遍，不如先建一个索引：把文档切成几百字一段的小块（ chunk ），把每块转换成一串代表"语义"的数字（向量），存进数据库。用户提问时，先找出和问题最相似的几块，再交给模型作答。
这套方法很聪明，也确实是当前企业知识库的基本架构。但它有一个天生的软肋：切块的时候，上下文被切掉了。
Anthropic 在 2024 年 9 月的一篇技术文章里举过一个很好的例子。假设文档里有这样一段：
"公司营收比上一季度增长了 3%。"
单独看这一块，它没说是哪家公司、哪个季度。在原文里，这些信息写在几页之前的标题和段落里；可一旦被切成独立的小块，这句话就成了"无主之言"。用户问"某公司 2023 年二季度营收增长多少"，检索系统很可能找不到它，即使找到了，模型也无法确认它是不是答案。
Anthropic 的改进方法叫"上下文检索"（ Contextual Retrieval ）：在切块之后，先让模型给每一块补上一句简短说明——"这段出自某公司 2023 年 Q2 财报，讲营收情况"——再去建索引。在他们的测试中：
这组数字说明两件事。第一，检索失败是真实且可观的，并非偶发。第二，每一步改进靠的都不是"换个更强的模型"，而是把文档原本隐含的结构和语境重新补回来。
还有一个更隐蔽的问题：相似，不等于相关。
向量检索找的是"语义上最像"的内容。可是"像"和"对"之间差得很远。用户问"现在的年假怎么算"， 2021 年旧制度和 2025 年新制度在语义上几乎一样像——向量模型分不清哪个是现行有效的。决定答案对错的，恰恰是"版本""生效日期""是否已废止"这类不在文字语义里、而在文档身份里的信息。
澳大利亚迪肯大学的研究者在 2024 年发表过一篇工程经验论文，总结了 RAG 系统的七个典型失败点，基于他们在科研、教育、生物医学三个领域的实际项目。如果把它们翻译成普通话，大致是这样的：
注意，这七个失败点里，只有后面几个和模型"聪不聪明"直接相关。前四个，本质上是信息组织问题。
第三道坎：有些问题，根本不是"找一段话"
RAG 的隐含前提是：每个问题的答案都藏在某一两段文字里，找到它就行。
但真实工作中，大量有价值的问题不是这样的。
比如：
这些问题的答案不在任何一段文字里，而是分散在几十上百份文档之间的关系里。检索最相似的五段话交给模型，模型只能基于这五段做总结——它看到的是树叶，被问的却是森林。
微软研究院 2024 年提出的 GraphRAG 正是针对这个问题。论文作者明确指出：像"这个数据集的主要主题是什么"这类面向整个语料库的"全局性问题"，本质上是归纳总结任务，而不是检索任务，传统 RAG 不擅长。他们的做法是先用模型从文档里抽取实体和关系，构建一张知识图谱，再把关系紧密的实体聚成"社区"并预先生成摘要；回答全局问题时，先让每个社区摘要各自给出部分答案，再汇总。在百万 token 量级的数据集上，这种方法回答的全面性和多样性明显优于传统 RAG 。
GraphRAG 有它自己的代价——建索引成本高，图谱质量依赖抽取质量。但它揭示的道理比具体方法更重要：
知识不只存在于一段段文字中，更存在于文字之间的关系里。谁影响了谁，哪个决定推翻了哪个，哪条规定是对哪条的补充。这些关系，文档通常不会明写，而人类专家之所以是专家，很大程度上就是因为他们脑子里有这张"关系图"。
最深的一坎：知识本来就不在文档里
前面三道坎都还是技术问题，多少有工程方法可以缓解。最后这一道，是技术解决不了的。
1958 年，哲学家迈克尔·波兰尼（ Michael Polanyi ）提出了"默会知识"（ tacit knowledge ）的概念，后来他用一句话概括："我们知道的，比我们能说出来的多。"
一个资深销售知道哪个客户"嘴上说再考虑，其实已经定了"；一个老工程师知道某个参数"文档写的是 80 ，但实际调到 75 才稳"；一个财务主管知道某类报销"按制度可以，但最好先跟老板打个招呼"。这些知识真实存在、极其有价值，却几乎不会出现在任何文档里。
20 世纪 90 年代，日本学者野中郁次郎（ Ikujiro Nonaka ）和竹内弘高在《创造知识的企业》中进一步提出了知识转化的 SECI 模型：组织里的知识要在"默会"和"显性"之间不断转化——通过共事传递经验（社会化），把经验说出来、写下来（外显化），把零散的显性知识整合成体系（组合化），再让人在实践中吸收内化（内隐化）。
用这个框架回看"把文档都塞进 AI"，问题就很清楚了：AI 极大地加速了"组合化"这一个环节——把已有文字检索、拼接、总结——但它对另外三个环节帮助有限。尤其是"外显化"：如果没人把经验写下来， AI 就无从读起。
更现实的情况是，企业文档本身就有几个结构性缺陷：
第一，文档记录的是结论，不是理由。会议纪要写着"决定采用方案 B"，但为什么不选 A 、当时考虑了哪些风险，往往不写。 AI 能告诉你"选了 B"，却答不了"现在情况变了，还该选 B 吗"。
第二，文档会过期，但不会自己说。一份三年前的流程文件，可能早已不再执行，却依然安静地躺在共享盘里，和新文件拥有同样的"权威"。人类员工靠口口相传知道它过时了， AI 不知道。
第三，没有人对文档负责。谁是这份文件的负责人？什么时候该更新？两份文件冲突时以谁为准？在大多数公司，这些问题没有答案。
这三个缺陷，叠加上前面提到的"库里没有答案时 AI 仍然会自信作答"，就构成了企业 AI 知识库最危险的形态：它不是答不上来，而是用一种权威的口吻，给出过期的、片面的、甚至编造的答案。比起一个搜不到东西的搜索框，这种系统对组织的伤害更大，因为它会悄悄侵蚀人们对"官方信息"的信任。
老话叫"垃圾进，垃圾出"。到了大模型时代，更准确的说法也许是：垃圾进，体面的垃圾出。
那么，知识库应该怎么搭？
知识库需要持续运转：真实问题、专家确认、有效知识、使用反馈。
如果上面的分析成立，那么搭建 AI 知识库的重心，应该从"选哪个模型""用哪个向量库"，转移到下面这些更朴素的问题上。
1. 先定问题，再建库。
与其先导入所有文档，不如先收集一两百个员工真实会问的问题，并请业务专家写出标准答案。这份"问题集"既是需求清单，也是评测标准：每次调整切块方式、检索策略或换模型，都用它来测，看准确率是升了还是降了。没有评测集的知识库，优化只能靠感觉。
2. 给文档"上户口"。
每份进入知识库的文档，至少应该带上这几项信息：负责人、生效日期、有效期或复审日期、适用范围、权威等级（正式制度、部门惯例还是个人笔记）。这些元数据让检索可以先过滤再排序——"只看现行有效的正式制度"——从根本上解决新旧版本打架的问题。这件事技术含量不高，但需要管理上的投入。
3. 检索要"组合拳"，而不是单靠向量。
前面 Anthropic 的数据已经说明：语义向量检索、关键词检索、上下文补充、重排序叠加使用，效果显著好于任何单一方法。产品型号、合同编号、人名这类精确信息，关键词检索往往比语义检索更靠谱。面向全局性问题，可以考虑预先生成主题摘要或构建关系图谱。
4. 让系统学会说"我不知道"。
在提示词和产品设计上，明确要求模型只依据检索到的材料作答，找不到就说找不到，并且每个回答都附上可点击的出处和文档日期。让用户能核对，比让回答显得流畅更重要。一个诚实说"库里没有相关规定，建议咨询人事部"的系统，远比一个什么都能答的系统可信。
5. 把"外显化"变成日常动作。
知识库最好的原料，往往不是正式文档，而是工作中自然产生的问答。当 AI 答不上来、员工最终在群里问到了答案时，这个问答应该被沉淀回去，并经过负责人确认。久而久之，知识库就会从"文档仓库"变成"组织记忆"。
6. 把知识库当产品运营，而不是当项目交付。
项目有上线日，产品没有完工日。需要有人看日志：大家在问什么，哪些问题答错了，哪些文档从来没被用过，哪些领域总是空白。知识会过期，组织会变化，知识库必须有人持续维护。
这些做法，最近被业界概括为一个新词——"上下文工程"（ context engineering ）：与其琢磨怎么写一句完美的提示词，不如想清楚在模型回答之前，应该把哪些信息、以什么结构、按什么优先级放到它面前。知识库，正是上下文工程在组织层面的形态。
结语： AI 改变的是检索成本，不是知识的归属
回到开头的问题：把文档都塞进 AI ，为什么仍然搭不好一个知识库？
因为文档不等于知识。文档是知识留下的痕迹——有的是结论没有理由，有的过期了没人标注，有的互相矛盾没人裁决，还有更多知识从来就没被写下来过。
大模型确实带来了一次真正的跃迁：过去需要人逐份翻阅、记忆和比对的工作，现在可以在几秒内完成。检索和整合的成本，被压低了几个数量级。
但它没有改变知识管理里那几个最古老的问题：谁来把经验说出来？谁来判断哪个版本有效？谁对答案负责？
这些问题，在有 AI 之前就存在，只是过去我们可以靠"问问老张"来绕过去。现在，当企业想让 AI 替代"老张"时，才第一次发现：老张脑子里的那些东西，从来没被好好整理过。
从这个意义上说， AI 知识库最大的价值，也许不是它能回答多少问题，而是它逼着组织第一次认真回答：我们到底知道什么。
