前几篇文章讲了智能客服的整体工程化、知识库构建，以及 Trace 驱动的排障闭环。这一篇继续往下钻一个很常见、也很容易被误判的问题：知识库里明明有相关知识，为什么用户一问，系统就是召不回来？或者召回了，但质量很差，最后还是答错。很多人看到这类 bad case，第一反应是“向量检索不准”“embedding 不行”“模型不够聪明”。这些原因当然可能存在，但在真实客服系统里，召回问题通常不是单点问题，而是一条链路里某个环节发生了偏移。一句话概括：知识存在，不等于知识以正确形态、正确版本、正确表达进入了可召回范围。一、有知识，不代表可召回RAG 系统里的“有知识”，至少可以分成几层含义。第一层是原始资料里有。比如 Wiki 页面、FAQ 表格、公告原文里确实写过答案。第二层是构建产物里有。原始资料经过清洗、切分、结构化、embedding、索引构建之后，目标内容仍然存在于知识快照中。第三层是检索候选里有。用户提问时，正确 chunk 能进入 top-k 或候选池。第四层是最终证据里有。经过重排、过滤、阈值判断、业务门禁之后，正确内容仍被交给生成阶段。很多线上问题会卡在中间某一层。原文里有答案，但切块时丢了上下文；知识快照里有 chunk，但 query 表达和 chunk 表达对不上；候选池里有正确结果，但重排把它压到后面；top-k 里有相关资料，但因为阈值、时效或业务过滤，被后续门禁丢掉。所以排查召回问题时，不能只问“库里有没有”，而要问：它有没有进入当前线上版本？有没有被索引？有没有进候选？有没有通过重排和门禁？二、先把召回链路摊开一个生产级智能客服的检索链路，通常不是“query 进向量库，top-k 出来”这么简单。用户问题进入系统后，往往会经历路由、改写、别名增强、多路召回、重排和结果门禁。下面是一张简化后的链路图。
