大模型幻觉问题属于模型算法风险吗

你在做模型评测、写风险清单，或者给团队解释「幻觉算不算算法问题」时，很容易被一句话绕住：明明模型没坏，为什么编得像真的？这篇不讨论幻觉怎么治，只解决归类问题——幻觉在什么情况下算算法风险，什么情况下该划到数据、提示或应用层，以及按什么顺序去判断。

做评测、写风险清单，或者被同事追着问「幻觉到底算不算算法问题」的时候，最容易卡在一个直觉上：模型明明没崩，为什么编得跟真的一样？这篇不聊幻觉怎么治，只解决归类——哪部分该记到算法头上，哪部分其实该划给数据、提示和业务链路。

先把结论放前面：幻觉不天然等于算法风险。它是现象，归类取决于可复现性、输入干净度和解码策略三件事。同一个现象，给算法团队看是模型行为，给合规看是输出质量，给运维看是可用性问题，受众不同口径就该不同。

先把「算法风险」这个词的边界划清楚

算法风险一般指模型结构、训练目标、解码策略本身带来的固有倾向——换台机器、换段时间、加一段提示词也不会消失的那种。它跟其他几类风险经常同时冒头，但记账时必须拆开，否则排查和整改都会互相甩锅。

算法风险

模型结构与训练/解码策略导致的固有倾向，可复现、不随环境变化消失

数据风险

语料缺失、过时、错误，或知识库本身没有覆盖到

部署风险

版本差异、量化、并发限流等运行环境因素导致的表现波动

应用风险

检索召回错、提示词误导、业务兜底缺失，换个前端可能就没了

• 归类前先问受众：算法团队关心行为是否稳定复现，合规关心输出能不能被追责，运维关心可用性，口径别混用
• 同一现象允许在不同报表里归不同类，但同一份材料内必须自洽，前后口径要能对上
• 不适用的情况：如果错误只出现在某一条业务链路、换个入口就消失，先别往算法上写，先查应用层

按三个问题判断：这条幻觉是不是算法风险

判断顺序比结论重要。把顺序固定下来，团队里不同人得出的归类才可能一致；跳步最危险，最容易把运维或检索问题写成算法问题，然后算法团队花两周找不到原因。

1. 先看可复现性同一模型、同一输入，换环境换时间多跑几次。错误稳定复现，偏向算法与训练侧；偶发且跟某次检索结果强相关，先划给应用链路。
2. 再简化输入把提示词压到最短，去掉上下文、知识库、系统指令，问题还在不在。还在，说明模型自带倾向；不在，先查提示层和检索层。
3. 再动解码参数调低随机性相关参数、限制输出长度，看错误是否明显减少。会明显改善的属于解码策略层风险，仍算算法侧，但是可控的那部分。
4. 最后才定性前两步排除掉数据、检索、提示和部署之后，再给结论。定性时写清依据哪几步判断，别只写「疑似算法问题」。

这套顺序不保证结论永远对，但保证可复盘。如果团队只有一两条样本，或问题只在单次对话里出现过一次，先记为观察项，别急着定性。

分场景对照表：哪些归算法，哪些不归

同样是编造内容，在不同任务类型下的归口差别很大。下面这张表可以直接拿去对齐口径，遇到争议先查表，再补足证据。

• 写合规或选型材料时，一句话标清分层：算法记「模型固有倾向」，其余各自归口
• 别把所有错误都装进算法一个篮子，篮子太满反而没人认领
• 不适用的情况：如果业务只要求「有兜底就行」，那归类优先级应该让给应用层，算法风险只做记录

落地动作与自查清单

归类要能落地，就得变成可打标签的记录动作，而不是每次开会现场争论。建议出错样本一进来就带标签，归类时直接看标签分布。

• 每条幻觉记录打四个标签：是否可复现、输入是否干净、解码参数是否影响、涉及哪一层
• 出错样本攒够一批后，到站内模型库对照同类模型的表现，看是这家独有还是普遍现象
• 要出结论时到站内测评榜单核对当时的评测口径，别自己造数字；口径不一致的榜单结论不能直接拼起来用
• 不适用的情况：样本量太少或只在单次对话里出现过一次的错，先记为观察项，别定性为算法风险
• 涉及成本判断时，到价格与追踪页面核对当时的数字，不要凭印象下结论

最后提醒一点：判断标准要能解释「什么情况下不适用」。声称某类错误永远属于算法风险的说法，基本都会在真实项目里被打脸——口径写死，比写错更麻烦。