让大模型自己找证据验真假，事实证明防不住胡说八道

在用大模型提取招聘岗位的结构化画像时，工程师最大的心病就是：模型幻觉。

比如一段 JD 明明写的是“配合算法团队做数据清洗”，模型脑子一抽，可能就给打上了“算法工程师”的标签；或者任职要求里只字未提学历，它却自作聪明地脑补出“本科以上”。

为了防范这种风险，第一版设计里我加上了一个看似无比严谨的字段——evidence（证据）。

我要求模型在给出每个结论时，都必须交出一份带引用原文的“证据链”：不仅要交代判定结果，还得把它是从哪句话看出来的原文片段给摘录出来。

页面上不仅能展示漂亮的分类标签，旁边还挂着“来源引用”，看起来可解释性拉满，排查 bug 也一目了然。

但随着处理的数据突破数千条，当我真正坐下来复盘那些跑偏的 Bad Case 时，一个荒谬的事实浮出了水面：这些让模型自己给自己找的“证据”，根本起不到任何防伪作用。

堂下何人，状告本官？

我们当初之所以花大代价保留 evidence，无非是寄希望于三点：

1. 思维链约束（CoT 效应）： 逼模型引用原文，觉得它有据可依就不会瞎猜；
2. 辅助排错： 抽错了能快速定位模型哪根筋搭错了；
3. 前端高亮： 给用户展示“这句话证明了该岗位需要三年经验”。

然而，这三点在单次生成的概率黑盒面前，全成了自欺欺人。

为什么模型找的证据不能当“防伪标识”？

因为**“判定结论”与“提取证据”来自同一次推理会话**。 当模型在注意力权重中已经先入为主地把岗位错判为“算法岗”时，在接下来的自回归生成中，它会极其自然地在原文里抓取带有“机器学习”、“模型”字眼的句子为自己辩护； 甚至在某些情况下，模型为了让证据和结论咬合得更紧密，还会悄悄在引用里篡改几个字！

这就好比在法庭上，你让被告人自己给自己开具无罪证明——这根本不是独立的三方验真，而是同一个嫌疑人在合情合理地编造不在场证明。

举个真实的翻车例子

原文写道：“负责大模型评测平台的数据流转与工程基建，需与算法算法团队密切配合。”

• 模型分类： 岗位方向: AI/算法
• 模型给出的 Evidence： 引用: "负责大模型评测...需与算法算法团队密切配合"

看上去字字有据，但稍微一读就知道，这分明是个标准的后端/大数据工程岗！所谓“证据存在”，根本无法推导出“分类正确”。

账单上的沉重代价

如果说心理上的安全感只是虚妄，那账单上的开销可是实打实的肉疼。

为了这个虚幻的“自我证明”，模型每输出一个字段（行业、方向、学历、经验、技术栈、英语要求……），都得像复读机一样把原文引用、字符起止位置、上下文片段完整敲一遍。

此外，第一版还顺手让它生成了一份几百字的“核心职责总结”。

把 Token 用量拆开一看，结果惊人：

• 数据库里早就完完整整存着一份干净的官网原版 JD；
• 结构化字段本身只需要几十个 Token；
• 而这些模型自己抄自己的 evidence 和冗余总结，硬生生霸占了 40% 以上的输出 Token！

实验版本	抽取字段完整度	平均单次输出 Token	相对节省
带 Evidence + 全文摘要	结构化标签 + 引用段落 + 总结	1,706 Token	基线
剥离 Evidence + 纯标签输出	仅保留业务真正消费的标签	616 Token	暴降 64%

在大模型 API 的计费体系里，输出 Token 的单价比输入 Token 贵出整整 3 到 4 倍。

我们花着最昂贵的单价，买回来的却是一堆既不参与 SQL 筛选、又不被前端高亮组件消费、更无法用来校验正误的“废话文学”。

剥掉伪证之后，如何做真正的可解释性？

既然模型自述的证据是伪命题，那该怎么防范幻觉？

答案是：把校验权从大模型手里夺回来，交给外部规则和独立流程。

1. 确定性的算术与枚举归代码： 枚举值是否合法、工作年限下限是否大于上限、学历是否符合阶梯逻辑，用 Pydantic / 脚本一秒卡死，不要在 Prompt 里跟模型讲道理；
2. 可解释性直连原始文本： 既然数据库本来就存着完整的招聘正文，前端需要展示上下文时，直接通过分词高亮在原版 JD 里呈现，根本用不着模型中间商当“二手搬运工”；
3. 评测集代替自我吹嘘： 挑出 200 个最具迷惑性的真实边缘岗位（比如算法工程、售前技术支持、全栈运维），建立黄金标注集（Ground Truth），每次改动 Prompt 时用测试脚本一键跑准确率对比。

真正的“可解释性”属于系统，不属于模型

真正健康的工程系统，排查问题靠的是：当时的 Prompt 模板版本 + 模型型号及版本号 + 当时的温度与参数 + 完整的请求响应日志。有了这四样东西，任何一次错误都能 100% 本地复盘重现，这比模型吐出来的一两句狡辩管用一万倍。

字段删减的“蝴蝶效应”

在砍掉 evidence 的重构过程中，还发生了一个极其有趣的意外插曲：

当我从 JSON Schema 中把 evidence 和摘要字段删掉后，原本表现很稳定的一个受控分类字段，突然有大批岗位开始返回 null！

排查后发现，大模型的输出依赖自回归概率转移。之前模型在被迫先输出一段 evidence 时，实际上无意中获得了一次**“思维缓冲（Scratchpad）”**的机会；一旦把缓冲拿掉，直接要求它在最前排做出高度抽象的分类决策，它的上下文注意力来不及聚焦，就倾向于保守地吐出空值。

消除隐式 CoT 影响的对策

字段可以删，但不能破坏模型的推理节奏。 针对这类极度依赖深层语义抽象的字段，我们调整了 JSON 键值的输出顺序：先让模型提取具体的“核心技能词”（相当于低成本的锚点定位），再让它输出更高层级的“岗位方向归类”。这样既省去了长篇引用的 Token，又保住了模型的分类准确率。

总结

在 LLM 应用架构设计中，我们很容易被某些“看起来很像最佳实践”的直觉带偏：

• “让模型附带思考过程”在复杂逻辑推理中是有效的；
• 但**“让模型为简单抽取提供自我证明”，在大多数工程场景下只是沉重的自欺欺人**。

没有下游独立校验器消费的字段，多留一个就是多交一份税。

面对大模型生成的结果，请永远保持怀疑。把省下来的 64% 的输出 Token 和计算延迟，用来做更扎实的前置清洗和更严格的后置规则校验，你的系统才会真正变得坚固。