知识库型 AI 客服回答错误时，最常见的误判是直接更换模型。实际上，问题可能发生在两个不同阶段：系统没有找到正确资料，或者已经找到了资料，却在组织答案时遗漏、误解或补写了内容。
把这两个阶段混成一个“答案好不好”的总分，会让排查变成猜测。更有效的验收方式是先看检索结果，再看最终回答；只有知道错误发生在哪一段，才能决定该修改文档、检索配置、提示词，还是模型。
为什么要拆成两段测试
检索增强生成（RAG）通常先根据用户问题从知识库取回相关片段，再把问题与这些片段一起交给语言模型。Microsoft 的 RAG 架构指南把搜索结果评估与语言模型端到端评估分成连续阶段，并要求在进入回答评估前，先确认系统能返回相关的依据。
这一区分对客服场景尤其重要：
- 资料没被找到：正确答案可能已经写在帮助中心，却没有进入模型上下文。
- 资料找到了但不完整：机器人只拿到退款条件，没有拿到例外或时限。
- 资料完整但回答错误：模型混淆了主体、数字或条件。
- 资料不足却回答得很流畅：模型用常识或猜测填补空白，表面体验好，实际风险最高。
因此，最终答案正确并不能证明检索可靠；一次偶然答对也不能替代可重复测试。
第一步：建立带“预期依据”的问题集
不要只保存标准答案。每个测试问题至少记录以下内容：
- 用户可能使用的真实问法，包括简称、口语和常见错别字。
- 应当支持答案的文档、章节或段落。
- 资料的版本、适用地区、产品套餐和生效日期。
- 预期结论，以及必须出现的条件和限制。
- 如果知识库无法回答，机器人应当拒绝猜测、要求补充信息，还是转交人工。
Amazon Bedrock 的 RAG 评估文档同样要求测试数据包含查询及预期检索文本或回答，用于判断知识库是否符合预期。对小团队来说，不必先搭建自动化平台；一份结构清楚的表格就可以成为第一版基准集。
题目应覆盖不同难度，而不是只挑最常见的 FAQ：
- 高频单点问题，例如营业时间或基础套餐区别。
- 同一意图的不同说法，用来发现关键词依赖。
- 需要组合两个章节才能回答的问题。
- 带日期、地区、账号类型或订单状态等条件的问题。
- 知识库明确没有答案的问题。
- 新旧政策并存、但只有一份仍然有效的问题。
负面问题很重要。Microsoft 的检索评估指南建议同时测试正例和负例：应该命中资料的问题要能找到正确内容，不应该由知识库回答的问题则不应返回看似相关却实际无关的片段。
第二步：只检查检索，不先评价文笔
对每道题保存系统返回的前几个知识片段，并先隐藏最终答案。逐项检查：
- 相关性：片段是否真正回答问题，而不是只出现相同词语。
- 覆盖度：所有关键条件是否都被找到，还是只找到了一部分。
- 排序：最有用的资料是否靠前，过时或次要资料是否挤占位置。
- 范围：结果是否来自正确产品、套餐、地区和版本。
- 冲突：新旧政策同时出现时，是否有日期或状态帮助系统判断。
AWS 将检索阶段的常用指标概括为“上下文相关性”和“上下文覆盖度”；Microsoft 还介绍了 Precision@K、Recall@K 与 MRR 等方法。日常人工验收不一定要计算所有公式，但应该保留同样的判断逻辑：返回的内容有多少是真的相关，应该找到的证据有没有遗漏，第一条有效证据排在什么位置。
如果正确片段完全没有出现，先检查知识库内容是否存在、是否已经同步，以及标题、术语、分段和元数据是否清楚。若正确片段出现但排名很低，再考虑搜索方式、过滤条件、重排或返回片段数量。此时改写回答提示词通常治标不治本。
第三步：固定检索结果，再检查回答
确认依据可用后，再评价语言模型如何使用它。AWS 的官方指标把这一步拆成正确性、完整性、有帮助程度、逻辑连贯性、忠实度，以及引用精度和覆盖度等维度。
客服验收可以把它们转成六个问题：
- 结论是否正确，数字、日期和主体有没有写错？
- 用户问题的每一部分是否都得到回答？
- 回答是否明确给出下一步，而不是重复文档原话？
- 条件、例外与步骤之间是否自洽？
- 每个事实能否在检索片段中找到依据？
- 引用或链接是否真的支持旁边的结论？
“忠实于资料”与“事实正确”不能互相替代。Microsoft 的端到端评估指南指出，回答可能忠实复述了上下文，但源文档本身过期或模型从正确材料中得出了错误结论。因此，验收记录里应同时保留来源版本和人工确认的业务结论。
用四种结果快速定位问题
把每次测试归入四类，通常比一个总分更容易行动：
- 检索正确，回答正确：作为回归测试基准保留。
- 检索错误，回答错误：优先修复知识覆盖、同步、分段、元数据或搜索配置。
- 检索正确，回答错误：重点检查提示词、回答模板、模型选择和引用约束。
- 检索错误，回答看似正确：标记为高风险；答案可能来自模型记忆或巧合，知识库更新后很容易失效。
修复后只重跑一两道题还不够。文档分段或搜索配置的变化可能改善一个问题，却破坏另一个问题。应当重跑完整基准集，并记录问题、检索片段、最终答案、配置版本和人工评分。
上线前的最小验收清单
在把知识库接入真实客服流量前，至少确认：
- 测试集来自真实支持问题，而不是产品宣传文案。
- 每道题都有预期依据、适用范围和无法回答时的处理方式。
- 检索与回答分别评分，能追踪到具体失败阶段。
- 过期资料已经删除、归档或标明失效日期。
- 无答案、资料冲突和条件不足的情况都经过测试。
- 高风险问题仍有人工复核或转人工路径。
- 文档、模型、提示词或检索配置变化后会重跑回归测试。
YourCopilot 的定位是基于知识库回答 Telegram 私聊、群聊与 Telegram Business 消息。本文提供的是适用于知识库负责人的人工验收方法，并不表示产品内置了上述自动评估指标或测试平台。实际能力与配置应以当前产品页面和管理界面为准。
参考资料
- Microsoft Azure Architecture Center，Develop a RAG Solution on Azure - Information-Retrieval Phase，最后更新于 2026 年 7 月 2 日。
- Microsoft Azure Architecture Center，Develop a RAG Solution on Azure - Large Language Model End-to-End Evaluation Phase，最后更新于 2025 年 11 月 21 日。
- Amazon Web Services，Use metrics to understand RAG system performance，持续维护文档，本次查阅于 2026 年 10 月 4 日。