知识库答错，很多团队的第一反应是：换更强的模型、改提示词、再加一层重排。
但有一种问题，模型再强也救不回来：文件在入库时就被读坏了。
最近看到一位开发者复盘 7 个商业 RAG 项目，帖子有 732 赞、122 条评论。大家反复讨论的痛点，不只是“模型会不会幻觉”，还有入库管道重复搭建、向量库拼接，以及没有日志时根本不知道错误从哪一层开始。
这也是很多知识库产品最容易被忽略的一段。人看到 PDF，会自然理解标题层级、双栏顺序、表格行列、脚注和跨页关系；解析器却可能把它们压成一串文字。金额、城市和规则都还在，但对应关系已经丢了。后面做 embedding、rerank，再换大模型，也只是让它基于错误证据更流畅地回答。
如果你在做企业知识库，我建议先别急着测聊天效果，先做一套“入库抽检”。
第一，挑 20 页最难的真实样本：表格、扫描件、图文混排、跨页表格、旧版本、水印和低清图片都要有。不要只拿排版干净的制度文件做演示。
第二，逐页对照原文和解析结果，看四件事：有没有漏字，阅读顺序是否正确，表格行列是否对齐，答案还能不能定位到原页码或章节。
第三，把产品状态拆开。“上传成功”只代表系统收到了文件；“解析完成”代表程序跑完；“可以入库”则应该代表结构与出处通过验收。三个状态不要混成一个绿色对勾。
第四，PRD 里补上解析路线、异常原因、原文与结果预览、人工复核、重试和版本替换。错误必须可见，团队才有机会修。
所以知识库答错时，排查顺序应该是：原文件 → 解析 → 切分 → 检索 → 生成。先确认模型拿到的证据是不是完整、正确、可追溯，再讨论提示词和模型升级。
AI 产品经理真正要设计的，不只是一个上传入口，而是一条让“文件可被可靠理解”的工作流。
