用AI干活的人迟早会撞上这么一幕:它说得头头是道,你去核对发现根本没这回事。这时候真正要判断的不是「它错了没有」,而是「这是哪种错、会不会反复、我该不该继续用它干这类活」。这篇不讲玄学,只把两边的生成机制摊开对比,再给一套可照着走的判断流程。
用AI干活的人迟早会撞上这么一幕:它说得头头是道,你去核对发现根本没这回事。这时候真正要判断的不是「它错了没有」,而是「这是哪种错、会不会反复、我该不该继续用它干这类活」。很多人卡在这里,是因为把两种完全不同的问题塞进了一个筐里。
这篇不讲玄学,只把两边的生成机制摊开对比,再给一套可照着走的判断流程。看完你至少能做到两件事:拿到一段可疑输出时知道先查什么,以及知道什么情况下这套解释根本帮不上忙。
你遇到的其实不是一个问题,而是两个
第一种是输出里出现了事实性错漏,比如编了个不存在的文件、条款、人名。第二种是答得不算错,但漏了关键前提,导致你按它做踩了坑。前者是「它编了」,后者是「你问的方向让它默认了一个不该默认的前提」。
这两种场景的应对完全不一样:前者要看它有多容易复现,后者要先回头看自己的提问里缺了什么约束。先分清是哪一种,这一步做错,后面全是白忙。下面这张表可以先帮你快速归类。
| 你看到的现象 | 大概率属于哪一类 | 先动哪个手 |
|---|---|---|
| 提到一个查不到的文件、接口、条款 | 机器编的 | 换一种问法重问同一件事 |
| 答案本身没错,但你没注意到它默认的前提 | 提问缺约束 | 回看原提问,补上边界条件 |
| 数字、比例、时间点对不上 | 两种都可能 | 先把问题缩到具体事实点再问 |
| 同一件事问两次,说法不一样 | 机器侧不稳定 | 别再靠单次答案下结论 |
- 遇到事实性错漏,先别急着骂模型或换工具,先做一次换问法复测
- 遇到「答对了但坑了我」,先翻自己的原始提问,看是不是少了限定条件
- 两类问题混在一份记录里,事后根本分不清是工具问题还是流程问题
- 判断顺序建议:先归类,再复测,再决定要不要升级核对强度
机器这一侧:为什么会顺口编出不存在的东西
大模型的输出是在按概率挑下一个词,它追求的是「接得像」而不是「确实如此」。所以在没有把握的地方,它也会给出流畅、完整、语气笃定的答案,因为它本来就不是在检索事实,而是在续写文本。
训练语料里同一件事有大量相似表述时,它容易把不同来源的细节拼接成一个看起来完整的新说法。这就像一个只读过很多摘要、没读过原文的人,把几份摘要拼在一起复述,逻辑通顺,细节全是缝出来的。
- 概率续写
- 它每次挑的是「最像下一句」的内容,不是「最可能是真的」内容
- 细节缝合
- 多份来源里的相近表述容易被混成一个新说法,读起来完整但经不起逐条核对
- 不发卡
- 它不会因为「不知道」而停下来,除非你的流程里显式要求它说不知道
- 复现性差
- 同一个问题换个问法,结论可能就变了,这恰恰是判断它有没有底的关键线索
温度、上下文长度这类参数会影响发散程度,具体名词和取值含义去 /ai-dict/category/tips 对照,不用背。你只需要记住一个判断动作:同一件事换两三种问法问它,如果结论飘,说明它本来就没有这方面的稳定认知,这时候它给你的任何笃定表述都不该被当作依据。
人这一侧:犯错往往带着知道自己不知道的信号
人答错通常有可追溯的原因:记混了、看漏了、被上游材料坑了,追问下去能定位到源头。而且人有「心里没底」这种体感,会在语气、措辞上露出犹豫,机器默认不会,它连不确定都能说得跟确定一样。
人出错还有稳定性:同一个人在同一个知识点上,要么一直错要么改掉。机器的错可能这次对下次错,取决于你怎么措辞、上下文里塞了什么。这个差别直接决定了你该用什么策略去防。
| 维度 | 人的错 | 机器的错 |
|---|---|---|
| 原因能不能追问 | 能,能定位到记混、看漏、被坑 | 只能靠输入输出对照推断,问不出动机 |
| 有没有不确定的体感 | 有,语气和措辞会露怯 | 默认没有,不确定也说得笃定 |
| 错得稳不稳定 | 相对稳定,改一次能改掉 | 随措辞和上下文漂移 |
| 防的办法 | 培训、复核、流程约束 | 改提示、加约束、外挂可查资料 |
所以「人也会犯错」不能当成「AI犯错可以接受」的理由。人犯错你大概知道该找谁、查哪个环节;机器犯错你只能靠你设计的核对流程兜住。凡是涉及要对外发布的正式文件,这个对照表只能帮你定位原因,不能帮你免责。
一张对照表:把两边放在同一维度上看
前面零散说了几个点,这里把它们收拢到同一组维度上,方便你在具体场景里快速对号。判断时别只看「错得严重不严重」,要看「这个错可不可控、能不能提前发现」。
| 判断维度 | 看人的时候 | 看机器的时候 |
|---|---|---|
| 复现性 | 多半能重演,改一次就稳定 | 换个问法可能消失,也可能换个问法才出现 |
| 可解释性 | 能追问依据和动机 | 只能靠输入输出对照,推不出内部原因 |
| 纠错方式 | 培训、检查、流程约束 | 改提示、加约束、外挂可查资料 |
| 担责归属 | 有明确责任人 | 责任在你设计的流程上 |
纠错成本这一栏要单独说一句:人靠培训和流程,机器靠改提示、加约束、外挂资料。相关做法可以到 /guides/hallucination-knowledge-base 看整理好的思路,这里不重复。记住一点:对机器来说,「让它下次别犯」往往不是靠讲道理,而是靠改你给它的输入和约束。
排查顺序:拿到一段可疑输出,按这四步走
这套顺序的核心思想是:先判断它有没有稳定认知,再决定要不要投入核对成本。跳步的代价是,你可能把大量时间花在核对一个本来就是随机拼接出来的结论上。
- 换一种问法重问同一件事看结论是否一致。不一致,说明它本来就没有稳定认知,这时不用再追问细节,直接把这部分标为不可信。
- 把问题缩小到具体事实点比如从「这个政策怎么规定」改成「哪一条、规定了什么」。如果它开始含糊、绕开、改口,基本可以确认它没有可靠依据。
- 用你手头的原始材料交叉验证别用另一个模型来验证,那只是两个可能同时出错的来源互相点头。用你能追溯到出处的材料,哪怕只是一份内部文档。
- 给这类任务归档判断它属于「可以验」「必须验」「不能交给AI」哪一档,把结论记下来。下次同类任务直接按这档处理,不用每次重新纠结。
这四步做完,你手里应该有一句明确结论,比如「这类具体条款必须人工核对」或者「这类改写类任务可以放行」。没有结论的排查等于没查。
哪些情况下「机制差异」这套解释帮不上忙
这套解释有明确边界,越界使用反而会让你放松警惕。下面几种情况要单独拎出来,别硬套前面的框架。
- 当你没法验证输出时,机制讲得再清楚也没用,因为你判不出对错,只能选择不采信
- 当错误来自你给的上下文本身有误,这不是幻觉问题,是输入问题,先查自己塞进去的材料
- 当输出涉及对外承诺、合规表述、账目数字时,不要用「它平时挺准」来降低核对强度
- 当你只是凭单次印象判断某个模型或站点靠不靠谱,结论基本不可靠,需要持续观察而不是一次性打分
需要长期跟踪一个模型或一个站点表现时,别凭单次印象下结论,去 /tools/quality-monitor 看怎么持续观察,把「偶发」和「稳定」分开。这两者的应对策略完全不同。
留痕:怎么把「我核对过」变成能拿出来的东西
核对这件事,很多人做了但留不下痕迹,出事时说不清自己查没查。留痕不需要很复杂,记三样就够:当时的提问原文、它给的答案、你核对用的来源。三者缺一,事后都说不清。
- 标注清楚哪部分是AI产出、哪部分是你改的,别把两者混在一份文档里不留痕
- 如果输出要给别人看,把「已核对」和「未核对」分开写,不要让读者自己猜
- 对高损失档的内容,在记录里写明核对了哪个来源、核对到什么程度
- 涉及纠纷时怎么留证据,参考 /guides/dispute-evidence-keep 的口径,这里不重复
留痕的另一层价值是给你自己复盘用。隔一段时间回看这些记录,你会发现某些类型的错反复出现,那这类任务就该从「直接采信」降级,而不是靠记忆提醒自己多留个心眼。
落到日常:四条可以直接照做的习惯
不指望你记住前面所有细节,能落下这四条,日常就够用了。这些都是动作,不是心态。
- 凡是涉及具体数字、条款、人名的输出,一律先当成未核实状态,核完再采信
- 把任务按「错了会怎样」分档,高损失档必须有人复核,低损失档可以放宽
- 换模型或换站点时,用同一组老问题重测一遍,看结论有没有漂移,方法可看 /tools/verify
- 定期回看自己的核对记录,哪类错反复出现,就把这类任务从「直接采信」降级为「必须复核」
分档这一步建议写下来,别只放在脑子里。写下来之后你和同事对「什么必须核」才有一致标准,否则每个人凭感觉松紧不一,出错的时候互相扯皮。
如果你还想知道不同模型、不同中转站在这类错上的表现差异,别靠听来的结论,去站内页面看当时的横向对比数据,数字会变,判断方法不会。
下一步想先把「哪些站点值得长期用、哪些表现飘」这件事摸清楚,可以到中转站目录和可信度检测页面看当时的评估口径和记录,再决定要不要把某类任务长期交给它。→常见问题
AI幻觉是不是就是它在撒谎?
不是。撒谎需要知道真相并有意隐瞒,模型没有这个步骤;它只是在你没给足依据的地方按概率补了一个最像答案的说法。理解成「它在补全」比理解成「它在骗你」更贴近实际,也更能指导你怎么改提问方式。
人能犯错,为什么对AI要求这么严?
因为两边错误的形状不同。人犯错通常会露出犹豫、能追问出原因、还能通过流程改掉;模型的错误可能这次对下次错,且语气一样自信。要求严是因为你没法从它的语气里读出可靠性,只能靠外部核对补上这个缺口。
换个更强的模型就能避免吗?
不能完全避免,只能降低某些类型问题的发生率。这个判断别只看宣传,去 /benchmarks 和 /rankings 看当时的横向对比结果,再结合你实际要做的任务类型挑。换模型前先想清楚你要它干哪类活,别拿综合印象代替任务适配判断。
我怎么知道这次是幻觉还是我上下文给错了?
把上下文减到最小重问一次:如果加上你给的资料就错、去掉就对,问题多半出在输入;如果无论怎么问它都给出同一个错答案,那更接近模型自身的认知缺口。这个测试不保证结论唯一,但能帮你先分方向。
有没有必要每次都记核对过程?
看用途。自己随手查资料可以简化;凡是输出会进入对外文档、合同、报表、公告的,都建议留下提问原文、答案和你核对的来源。等真出问题时,能拿出这条链比事后解释有用得多。