夜雨聆风背景说明
上一篇文章《APS 知识库搭建手记：数据清洗与结构化实践》记录了如何用 Claude Code 把八百多份"脏"文档治理干净——死链图片、HTML 标签、模板残留逐一清理，补上元数据标签，目录结构也理得整整齐齐。数据准备好之后，下一步自然是导入 Coze 建 Bot。建知识库、拖文件、配 Bot，操作很直观，两个 Bot（产品专家和项目专家）拉到飞书群里，心想这事应该差不多了。
真正用起来才发现，文档干净了，答案却不对。兜了一圈，最终的方案反而更简单也更可靠：让 AI 直接读完整文档。这一篇讲讲这段弯路。
翻车：文档是干净的，答案是错的
知识库和机器人构建好后在飞书中一试，问题就暴露了。问"MRP 在哪些项目中有做过"，机器人洋洋洒洒回答了一大段 MRP 的标准产品功能定义，最后加一句"未检索到相关项目案例"。
项目案例库里明明有五个项目的完整 MRP 方案——某电驱动企业的 MRP 五步流程、某电池企业的 MRP 采购审批、某玻璃企业的 MRP 发运计划——但机器人就是说找不到。
排查后发现原因不在 Prompt，在 Coze 的检索机制：产品文档里 MRP 是专题章节、文本密度高，五个召回槽位中占到四五个，项目案例的 MRP 文件排名挤不过。机器人拿到的检索结果里项目信息已经被稀释到几乎为零了。
同样的剧情反复上演：问"各项目的关键词"，只返回三四个项目（实际有十多个）；问"物料工艺路线导入接口存在吗"，明明文档里有，机器人说没有。每次都是同样的根因——Coze 的召回槽位只有八条，信息量一大就漏。
尝试过的补救措施——在 Prompt 里写路由规则、在文档里补检索关键词、增大匹配度——全部无效。Coze 的检索层是黑盒，Prompt 控制不了。
换思路：别让平台把文档切碎了
冷静下来想，问题的本质是什么？
Coze 平台中的知识库工作机制是：把文档按标题层级切成片段，用户提问时用语义搜索召回最相关的几个片段，发给大模型回答问题。这个流程有两个天生缺陷：
第一，碎片化导致信息不完整。 一份 API 文档会被切成好几个片段——接口名称在其中之一，参数表在另一个，访问地址在第三个。被召回的往往是其中一个片段，大模型看到的是不完整的上下文。
第二，召回槽位有限。 Coze 最大召回八条片段，但知识库有上千份文档。十一个项目竞争八个槽位，小项目永远排不进前三页。
相比之下，如果让大模型直接读完整文档呢？
用户问："物料工艺路线导入接口存在吗" ↓关键词匹配 → 命中该接口的完整文档 ↓整个文件喂给大模型（接口名称 + 功能说明 + 参数表 + 访问地址全在一起） ↓大模型回答：存在，并给出接口名称、功能说明和访问地址没有任何切分，没有任何槽位竞争。一个文件就是一个完整的知识单元。
落地：让大模型更好地找到和读懂文档
方案确定了，但"完整文件喂给大模型"不等于"把所有文件都喂给大模型"。几千个文件不可能一次全塞进去，得让搜索引擎精准定位到相关的那几份。这里需要做几件事。
打标签，让搜索引擎知道每个文件是什么
所有文档统一补充了元数据标签（即 Markdown 文件顶部的结构化标注）：
product: "APS" # 哪个产品线type: "API文档" # 哪种文档类型module: "需求计划" # 哪个功能模块这样搜索引擎可以用 product: APS 过滤出计划排程的文档，用 type: API文档 过滤出接口文档。多产品知识库里，一个 APS 顾问的问题不会搜出 MES 的结果。
建总览和索引，让搜索快速定位
创建了一个全局总览文件，包含：
• 四个产品线的介绍和覆盖的业务领域 • 跨产品共享模块的清单（组织建模、工厂建模等） • 易混淆功能速查（比如不良处置功能不在 QMS 产品说明文档中，实际在 MES 产品里） • 术语对照表（用户说"工单"→文档里叫"制造订单/MO"） • 检索策略建议
搜索引擎拿到问题后先读这份总览文件，等于有了一张完整的知识地图。
同时为每个产品目录创建了 API 速查表和功能文档索引。以 APS 的 API 接口平台为例，三百多个接口，每个接口的名称、功能、访问地址全部列在一份速查表里。用户问"APS 有哪些排产 API"时，一份文件就能覆盖全部答案，不需要在全库范围内海量搜索。
对比：不是 AI 不行，是方案不行
同样的文档、同样的大模型，不同方案的回答质量差别显著：
几点启发与反思
1. RAG 不是万能的
RAG（检索增强生成）不是在所有问答场景中都适用。它的核心假设——"切碎文档、语义检索片段、组合回答"——在处理开放域问答时效果很好，但在企业知识库场景中，问题往往是"这个 API 的参数是什么""这个项目怎么做的"，需要完整、精确、不丢失细节的上下文。RAG 的碎片化先天与此矛盾。
2. 打标签是给 AI 建基础设施
元数据标签中的产品线和文档类型字段，全局总览文件的产品线介绍和术语映射，易混淆功能速查——这些工作看起来和 AI 问答没有直接关系，但它们决定了搜索引擎能不能找到对的文件。
3. 当前方案的局限
完整文件方案有一个无法回避的瓶颈：大模型的上下文窗口是有限的。当前知识库中大多数文档在几十 KB 量级，单次检索返回五到十个文件，上下文总量还在可控范围。但如果未来出现单文件超过上下文上限，或者一个复杂问题需要同时参考几十份文档的情况，就需要额外的处理策略——比如对检索结果做相关性排序后截断、引入多轮对话让用户逐步缩小范围。
