RAG 也可能答非所问：一次「引文正确、语义错误」的踩坑复盘

在基于检索增强生成（RAG）的问答系统里，「引文真实」并不等于「答案正确」。AI 基础设施团队 ZettaVector 最近复盘了自家产品中一个隐蔽的故障：用户询问「如何联系」，系统给出了一个真实存在、并配有合规引文的邮箱地址——但那是页面里某条 demo 数据，而非公司真实的联系方式。

这一案例揭示了一个被普遍忽视的工程问题：当检索结果里同时出现「业务联系信息」和「示例数据」时，仅靠相似度排序和正则匹配，会把示例内容当成正式答案返回。

故障现场：答案、引文、上下文三者并不等价

ZettaVector 的智能体在被问到「如何联系」时，返回了 demo 表格里的 email@joes.com。该邮箱确实出现在被引用的网页中，引文校验自然通过。然而，真实的公司邮箱出现在同一页面的页脚版权区（wchisasa@outlook.com），却被忽略。

失败发生在检索之后。原本的恢复逻辑大致如下：

• 遍历检索到的证据片段
• 用正则提取第一个看起来合法的邮箱
• 直接作为答案返回

问题在于，正则只能识别「这是不是一个邮箱」，无法判断「这个邮箱是不是官方联系方式」。页面里 demo 表格的相似度更高，且优先被命中，邮箱提取随即完成，系统没有进一步追问语义角色。

修复思路：从「匹配」升级为「打分 + 排序」

团队放弃了「找到第一个合法字符串就返回」的策略，改为对所有候选邮箱打分排序，仅在分数相同时退回到来源顺序作为兜底。打分依据来自候选邮箱周围的文本信号。

加分信号包括：

• 显式标签：「contact」「email」「support」「sales」等
• 联系意图：「get in touch」「reach us」等
• 业务上下文：「enterprise」「feedback」等
• 页脚信号：版权符号、「all rights reserved」等

减分信号包括：

• 「demo」「sample」「prospect」「lead」等示例标记
• 「dashboard」「results table」「outreach hook」等界面元素
• 表格表头出现「business」「score」「website quality」
• 同一片段内出现多个邮箱

同时设置了最低分数阈值：当所有候选都偏向示例数据时，系统返回「无可用联系方式」，而不是把「最不坏的那个」勉强暴露给用户。

测试与边界：拒绝回答也是正确行为

团队为这次故障新增了两条回归测试：

• 当页脚真实邮箱被多个逼真的示例邮箱包围时，页脚邮箱必须胜出
• 当页面里只有示例邮箱时，系统应明确表示「无法确定官方邮箱」，而不是强行给一个答案

第二条尤其关键：当证据模糊时，让系统学会说「我不知道」，比给一个看似合理的字符串更可靠。

工程启示与遗留问题

此次复盘提炼出几条对 RAG 系统建设者有参考价值的经验：

• 检索顺序不等同于权威顺序：相似度衡量的是「文本相关性」，不是「页面中哪一段更权威」
• 示例内容是高风险证据：demo 表、用户案例、模板截图容易被自动化流程误读为业务事实
• 确定性代码也需要语义保护：故障来自一段完全确定的恢复逻辑，而非模型本身的随机性，但同样需要理解「这段文本在表达什么」
• Grounding 是一条流水线：检索、引文校验、文本绑定、上下文判别、安全拒答缺一不可；任一环节通过都不代表最终答案正确

不过，团队也明确指出，本次修复仅针对「页面里有多个邮箱候选」这一类问题。涉及电话号码、句段片段、相同问题重复稳定性等场景仍需独立的测试用例覆盖。一个更稳健的 Grounding 系统，需要把语义判断、引用校验与拒答策略作为同等重要的工程模块来对待。