给AI喂了几万份文档,它为什么反而更会答偏?

▲ 资料越多，真正困难的越不是存进去，而是每次只拿出该看的那一部分。

一、AI不是档案室，它每次只能坐在一张有限的桌子前

很多人把长上下文理解成一张无限大的办公桌：文件尽管往上堆，模型总能从里面找到答案。

实际更像是一个人坐在桌前处理问题。桌子确实可以放得越来越大，但当制度、邮件、工具返回结果、历史对话和临时说明同时铺开时，注意力不会因此自动变得更好。模型也有同样的问题。

官方文档把上下文窗口解释为模型生成答案时能够参考的全部文本，连它准备输出的内容也算在里面。它不是一个永久仓库，而是一段正在工作的记忆。上下文变长，模型能看到的东西更多；但能不能把正确内容挑出来、放在恰当的位置使用，是另一回事。

Anthropic 在开发者文档中专门提醒：随着 token 数量增长，准确性和召回可能下降，并把这种现象称为 “context rot”。说白一点，资料堆得过满，关键信息反而可能被淹没。

二、真正让答案答偏的，通常不是缺资料，而是三种“混在一起”

第一种是新旧混在一起。制度更新后，旧版本仍留在知识库；检索系统找到了两份相似内容，却没带上明确的生效日期。模型最擅长把冲突信息组织成一段看似周全的话，它却不一定知道该替谁拍板。

第二种是权限和场景混在一起。给销售看的产品说明、给法务看的合同条款、给研发看的技术文档，可能都提到同一个产品名称。员工问的是“我现在能给客户承诺什么”，系统却没有先弄清他是谁、在问哪一类承诺。

第三种是问题和背景混在一起。一个人只是想查某次报销需要什么材料，系统却把整套财务制度、聊天历史和一长串相似案例都塞进来。回答更长了，答案未必更近。

这也是为什么 RAG 不等于“文档上传”。Google Cloud 的官方 RAG 文档把检索、重排序和元数据过滤都列为系统能力。它们听起来像后台细节，实际上决定了 AI 这一轮到底看到哪几页纸。

▲ 知识库不是一次性导入工程，而是文档版本、权限和检索规则的持续维护。

三、别先追求“全知道”，先规定“这次该知道什么”

知识库项目最容易犯的错误，是把目标写成“让 AI 理解公司所有资料”。这句话听上去很完整，落到实施时却没有边界。

一个更可执行的目标是：先挑出一个高频、结果可以核验、责任边界清楚的问题。例如，员工查询差旅报销规则，客服查询某款产品的当前配置，销售查询当前可用的合同条款。问题越清楚，系统越容易判断哪些资料应该进来，哪些资料应该留在外面。

这一步看似保守，反而更省钱。因为每一次被召回、被放进上下文、被模型反复处理的内容，都在消耗延迟和 token。更重要的是，范围收窄后，业务负责人能真的检查答案对不对，而不是只能说“感觉还行”。

好的知识库通常会先做三件不那么显眼的事：给文档标明版本和生效时间；给资料加上部门、产品、地区等元数据；为无法确认的问题设计“我不知道，请转人工”的出口。后者尤其重要。比起一本正经地给错答案，承认不知道往往更有用。

四、接下来比拼的不是谁有更长上下文，而是谁更会删

模型窗口会继续变长，企业也会继续积累更多文档。这并不意味着检索和整理会退出舞台，恰恰相反。

当 AI 开始连续执行任务时，它的上下文里不只有文档，还有系统提示词、工具说明、历史消息、工具返回结果和前一步的判断。Anthropic 把这件事称为“上下文工程”：从不断增长的信息里，持续挑出这一轮最有用的那一部分。

这件事的本质很像给一个新同事交接工作。你不会把公司网盘整个丢给他，然后要求他下午给出准确结论。你会先说清任务、给他最新版本、告诉他哪些资料不能外传、找不到时该问谁。企业给 AI 的上下文，也应该有同样的秩序。

未来知识库的竞争，不是谁收得更多，而是谁能更快地淘汰旧资料、更准确地识别当前场景、更坦诚地处理不知道的部分。把 AI 当搜索框，重点是“找得全”；把它当会参与决策的系统，重点就变成“少给一点，但每一条都对”。

觉得有收获？点个赞。