那个所谓的“引用校验器”居然在骗我

我之前为了给研究型 Agent 做质量把控，专门写了一套校验逻辑：AI 给出结论时必须附带原句和链接，然后由一段纯代码（不走模型，纯确定性逻辑）去核对这个原句是否真的出现在网页源码里。结果跑了 20 个问题，47 个论点里竟然有 22 个被判定为“引用错误”。

当时我第一反应是：太好了，这套拦截机制简直无敌，直接刷掉了将近一半的幻觉。

结果我手动复核了一下，心态崩了。在被拦截的 18 个引用错误里，有 12 个其实是完全正确的，字符一个没差。模型抄得没错，是我的校验代码在睁眼说瞎话。

问题的根源极其低级，就在于 HTML 转文本的那个步骤。我的代码把所有标签都替换成了空格，导致网页上的 Doppler, who... 在缓存里变成了 Doppler , who...（逗号前多了一个空格）。模型是按人眼看到的正常文本引用的，而我的代码在拿它和那个被我弄脏的缓存对比，结果自然是匹配失败。更离谱的是，我的正则处理没考虑到 Wikipedia 属性里的 JSON 包含 > 符号，导致大量模板代码直接泄露到了句子中间。

为了修好这个坑，我把提取器重写了三遍：先删掉属性值再剔除标签，去掉无间隔的内联标签，并切掉了 Wiki 公式里的原始 TeX 代码。

为了证明这次修复不是因为我把校验标准调低了，我特意搞了一组对比实验，故意修改引用内容来测试：

• 原样对比： 通过（PASS）
• 改动一个数字： 拦截（REJECT）
• 加入否定词： 拦截（REJECT）
• 删掉一个词： 拦截（REJECT）
• 替换一个名词： 拦截（REJECT）
• 凭空捏造句子： 拦截（REJECT）

这次结果很稳，18 组干扰项全部被精准拦截。重新跑一遍同样的 20 个问题，53 个论点里 45 个通过，只有 8 个被拦截。这 8 个才是真正的幻觉——比如模型自己拼凑的句子，或者因为我的上下文窗口截断导致它没看到完整内容而产生的误读。

不过最讽刺的是，我在下游把引用校验搞得这么硬核，结果上游的 Agent 依然在一本正经地编造 URL。这次跑的链接里有 10 个是死链，我查了 Wiki 的日志和 Git 历史，其中 6 个链接在历史上根本就没存在过。

虽然过程有点曲折，但这种“代码兜底”的模式在公司推行时确实很有说服力，只要能证明校验逻辑是可靠的，老板对 AI 产出结果的信任度会高很多。