从GPT-5发布来分析LLM大模型幻觉收敛(一)
GPT-5 号称在任何领域都有博士级别能力。在医疗健康领域,能够对专业的癌症诊断报告做通俗易懂的解读。对复杂的放射治疗方案决策,也能提供详细的分析报告,帮助病人权衡利弊。一位癌症患者的家属在发布会上表示,“ 真正鼓舞人心的是看着她通过使用 GPT-5 重新获得自主权,病人很容易感到无助,因为知识差距太大了。
但是也有人使用后反馈,GPT-5 “ 变蠢了 ”、“ 没创造力了 ”、“ 不灵动了 ”、“ 回答很干瘪 ”。
实际上,这并不是一个让人意外的结果。
为什么会变成这样?这是不是说明GPT-5能力并没有说的那么强,其实不是,因为 GPT-5 的其中一个特性是幻觉率显著降低,而降低模型幻觉率的一个主要代价就是模型的输出会显得更严谨,更缺少让你意外的回答。
如果我们理解LLM大语言模型的运行原理就能知道GPT-5为什么要这么处理了,大模型生成的内容是概率产物,模型本质意义上是一个条件概率分布的近似器,它的创造力来自于更宽松的概率分布,而当你想让它答案更精准、低幻觉时,它的概率分布必然收紧,这样的收紧减少了有更多创造力的可能。
我们一直在吐槽各家大模型的幻觉率太高并且愈演愈烈,认为这是一种 “ 病 ”,厂商们也使出浑身解数来治这个 “ 病 ”,微调、RAG、MCP 等新 “ 药方 ” 一个接一个。
现在,高幻觉率的问题被一定程度解决,大家又吐槽模型回答的不够好,不够圆润,这就陷入了一种无法打破的死循环
大语言模型理论上不可能完全消除幻觉。还有研究表明,越抑制幻觉,大语言模型的泛化性越差,也就是能够适用的场景越受限,这与业界希望全方位推广 AI 的愿景显然是相悖的。
这其实也反映出,幻觉带来的影响并非永远都是负面的,需要辩证看待。
幻觉是不是幻觉、幻觉的影响是不是负面、幻觉的负面影响有多大,都是相对的,和使用者的能力和需求、场景的特性和需求、使用前后效率对比、现实世界的变化等因素都有关。
一、大模型实际应用中常见的幻觉类型
大模型的 “ 幻觉 ” 指的是 AI 系统生成或推断出与人类经验不符的内容或结论。
这里 “ 人类经验 ” 必须是 “ 正确 ” 的,限于个人认知的差异,所以必须认识到 “ 幻觉 ” 也是相对的。
在大模型应用中,幻觉无法完全避免。
可以将幻觉分为 5 个类别:
语言生成中的幻觉
推理与逻辑错误
过度简化与常识错误
数据错误或无依据推理
时效性错误
语言生成中的幻觉是大模型最常见的一种幻觉,尤其是在内容生成类的应用中。例如在生成代码时,AI 可能会编造 Library 或 API 来完成代码的生成。
大模型还可能在进行逻辑推理时产生错误。例如在使用 Roo Code 插件进行代码生成时,经常遇到指定上下文后,大模型仍然会根据项目中其它上下文做出错误的推理。
关于过度简化与常识错误,AI 虽然能够处理大量信息,但它在应对一些需要深度常识、实际经验的场景时,容易出现过度简化的情况。例如 AI 可能会说 “ 为了快速减肥,可以不吃任何食物 ”,这显然是不科学的。
关于数据错误或无依据推理,在某些场景下,AI 模型可能会基于不完全或者错误的数据生成答案( 尤其当训练样本中掺杂大模型生成的幻觉内容时更甚 )。例如,在医疗应用中,AI 根据患者的症状生成诊断建议,但如果这些症状与训练数据不匹配,或者训练数据本身存在偏差( 如某些相同指标数据指向不同病症,从而需要医生以个人理解进行具体判断的情况 ),模型就可能给出错误的诊断结果。
最后,幻觉很多时候来源于模型训练时知识和概念在时间上的局限性。
二、大模型的幻觉会在企业应用中带来哪些负面影响与成本损耗
关于幻觉可能产生的 “ 成本损耗 ”,需要代入到具体应用场景分析。
用户差异会带来巨大的成本评估差异。假设生产效率的影响小于大模型应用前的历史效率,总体上并不会产生 “ 成本损耗 ”。
比如。一个行政人员使用 Cursor 生产一个表格信息收集工具,即便生产效率低下错误频出,生产效率仍然可能大于:找产品提需求、找研发开发、找测试评估、找运维部署。因此,Cursor 虽然经常犯错误,仍然有大量用户,因为用户认为 Cursor 的效率是大于自身的。
但若这个场景的用户是研发人员,错误频出带来的效率降低,显著大于:安装依赖、查找文档、编写代码,那么 Cursor 在这个场景大概率会被研发人员抛弃。
所以,成本损耗和效率的影响都是相对的。
进一步看,幻觉的负面影响还可以分为两类:
预测错误,如果“错误”易于识别,则影响的是生产效率;
如果 “ 错误 ” 难以识别(例如预测错误发生在使用者不熟悉的领域),则影响的是应用效果。
三、如何根据幻觉率高低进行产品落地可行性决策
如果大模型的幻觉率过高,特别是在关键决策领域( 如医疗、金融、法律等 ),则这些产品的应用将面临严重的挑战。对于这类应用,企业的目标是尽量减少错误和幻觉,因为一个错误的决策可能导致巨大的财务损失或法律责任。
对于一些风险容忍度较高的应用场景( 如内容推荐、广告投放等 ),企业会接受一定程度的幻觉,毕竟这些应用的目的是提升用户体验和增加商业效益,而不完全是做出精准决策。
通常,企业会设置一个 “ 安全边界 ” 来限定幻觉率,确保在可接受范围内。过高的幻觉率会增加企业的风险和成本,过低的幻觉率则可能意味着模型的复杂度和计算成本过高,导致收益无法覆盖成本。
四、解决LLM大模型幻觉有哪些方法,具体效果怎么样
常用的方案有三种:合适的模型、In-Context-Learning、微调。
首先,海量参数的大模型因为 “ Scaling Law ” 会缓解幻觉出现的概率;其次,借助各种提示词工程和 RAG 等技术,“ In Context Learning ”( 在不进行参数更新的情况下,通过在输入中提供示例来学习和完成新任务 )被实践证明能够大幅降低幻觉出现的概率;最后,使用 “ 继续训练 ” 的微调技术,在一些场景中可以一定程度降低幻觉。
为缓解语言生成幻觉和过度简化幻觉,一般采用扩大训练样本和模型参数来解决,即采用更合适的模型。
为缓解逻辑推理错误,在 MCP 生态出来后,最火的就是:Sequential Thinking MCP Server,帮助大模型把复杂问题降级为诸多微任务,以期待降低大模型出现幻觉的概率。这属于 In-Context Learning 方法。
缓解数据错误或无依据推理幻觉一般也是采用 In-Context Learning 方法。
为缓解时效性局限带来的幻觉,比如编程领域,现在行业里有很多人在用 Context Server,也就是 MCP 的 Server,当调用 API 时,它能帮我检查这个 API 的最新版本文档和接口参数说明,避免使用了老版本的 API,保证生成代码的准确性,这属于 In-Context Learning 方法。
医疗、金融、法务等行业对精度要求非常高,使用 RAG 最多的就是这些行业。但是,由于 RAG 需要向量存储、检索服务,且会大幅度增加计算成本,某些行业的特定领域使用大模型微调技术,降低 RAG 带来的成本,也能找到成本与效果的平衡点。
对于内容推荐、广告投放等可以容忍一定程度错误的应用场景,AI 的幻觉率可以稍高一些,同时开发成本也会降低。最典型的例子就是 “ mini-gpt ” 开源项目,仅用几个小时训练一个几百兆大小的小模型,就可以很好的生成儿童绘本级别的小故事。
中低精度要求和更低成本的情况下,小尺寸模型也是能接受的,比如 Qwen3-0.6B,In-Context-Learning 可以不使用或简单使用,可以使用少量( 数百、千条数据即可 )行业优秀的案例数据进行微调,因为基础模型参数量小,微调的成本也不会太高。
但总体而言,微调的效果和风险还是普遍存在。模型通过微调从通用模型过渡到领域特定模型时,是有可能丢失原有的通用知识的。
而对于所谓垂直领域大模型,在我个人实践中发现,由于大部分场景都需要跨领域知识,反而使垂直领域大模型的应用效果受到限制,实际效果和微调技术基本持平。
最近行业里有一些论文在研究怎么让大语言模型实现 Self Learning,也就是说它能在服务过程中对自己的参数进行微调,随着使用不断学习和提升,克服时效性的局限。比如,麻省理工( MIT )最近提出的 Self Adapting Language Models( SEAL )是一种模型能够 “ 自行学习 ” 的技术:模型通过生成自己的合成训练数据并用于自我更新,迎向 “ 终生学习 ” 之路。但该方法仍存在 “ 灾难性遗忘 ”、计算资源高、学习调度复杂等挑战 。
当下,由于大模型的基础框架局限于 Transformer 和 Diffusion,并且在基础框架层面并没有显著的技术突破,上述方案应该在大模型基础框架技术变革前是有效的。
五、垂直领域大模型效果受限,还是垂域模型比通用模型能力更强
垂直领域大模型虽然掌握了行业知识,在特定任务上表现更好,比如在医疗这种病种类目极多、具备极强专业深度的领域。但在复杂推理或跨领域理解上仍显不足,尤其在任务更复杂、数据稀缺时更明显。
如果数据多样性有限而规则复杂,比如材料科学,训练出的模型往往倾向于 “ 记忆 ” 而不是建立泛化机制。只有当数据多样性足够高,才可能促进泛化。
最后,成本与收益不匹配。相比训练一个垂直大模型,微调已有模型 + 机制( 如 RAG )往往更低成本,效果也更稳健。
总体而言,只要是涉及到标准化流程或比较依赖规则、先验的工作,RAG 都会用得比较多。
其实 RAG 有不少局限性,不同行业使用 RAG 的场景需求也不同。
在法律行业,有时候应用中不只涉及法律法规,还包括案例、法律解释、政策等。这就比一般的 RAG 难度高一些,主要是时效性要求高,因为法律是在不断建设中的,各地对法律法规也可能有不同的解释。
在医疗行业,现在大语言模型在时序理解上的局限性,会限制 RAG 应用的效果。当前的 RAG 更多是对概念背后所代表的含义进行理解和解释。但是在医疗行业里,通常要解释的是临床数据和病例。
比如一个病人有一系列的检查、体检数据,包含各项指标在一定时间段比如一年内的变化情况。这些变化的含义不是简单通过 RAG 就能查询出来的。因为它有很大的个体性差异,比如性别、地域、年龄等各种因素的影响,也可能要结合上次检查和这次检查的对比,以及和其他类似患者的的对比。
不像其它领域,比如医疗领域可以直接生成病例、诊断书等,或者法律领域可以生成诉状、裁决书等,金融行业在应用 AI 时,最终产生的结果更多是偏向建议或者辅助性的。因为使用 AI 会产生的一些问题和风险,目前用 RAG 加大语言模型的方式是难以规避的。因此金融行业倾向于更严谨的方式,比如在里面穿插一些传统的机器学习算法,用来对决策背后可能产生的问题和风险进行估计。
六、幻觉缓解的技术路径探索过,关于微调和效果和风险深入了解
对模型做微调,或训练自己的 LoRA。比如轻办公领域,针对用户场景识别和服务推荐场景做微调或 LoRA。但我们发现,等花了半年甚至一年的时间训练并上线后,大语言模型自身更新带来的收益,往往已经超过了我们做这些工作的收益。
通过微调技术调整模型参数的时候,最大的问题在于参数调整可能带来一些无法预期的后果。比如模型本身是无法处理 “ 冲突 ” 的,如果新数据与模型原有知识发生了冲突,经常会发生 “ 正确 ” 的数据遮蔽了 “ 正确 ” 的知识,甚至会导致 “ 灾难性遗忘 ” 的情况发生。“ 灾难性遗忘 ”( Catastrophic Forgetting,也称 catastrophic interference)是指模型在学习新任务或新知识时,严重遗忘先前所学能力的现象,尤其在顺序训练或持续微调中表现突出。即便是 AI 产品在服务过程中不断更新权重,即 Continual Learning,也只是一种微调,传统微调具备的缺点它都有。
在大型语言模型中,这种现象尤为关键:模型的知识分布式存储于权重中,当在新领域训练时,部分权重被重写,导致模型原有的广泛语言能力或事实知识退化。
在研究中,1B 到 7B 大小的 LLM 在持续微调后普遍出现灾难性遗忘,甚至随着模型规模增大( 但仍在这一范围内 ),遗忘现象反而更严重。
举个例子:一个针对医疗诊断微调的模型,可能会 “ 忘记 ” 基础的数学能力或一般写作能力。这个问题和大语言模型本身的技术特点相关,除非整个大语言模型技术发生本质性的革新,否则短期内这个问题比较难解决。
现在的大语言模型权重参数非常多,而且缺乏可解释性。更新某些权重时,会对哪些权重或者什么情况下的推理产生负面影响,目前很难评估。所以,灾难性遗忘或者权重冲突的具体原因,目前只能通过最终结果的评估来检验。
在实际测试对比下,In-Context Learning、RAG 往往比微调模型具有更好的泛化能力和稳定性。
总体来说,模型微调或者 LoRA 的效果,通常小于 RAG 的效果,因为 RAG 可以去修改数据,灵活性更强。而通过很多论文和行业数据都能看到,RAG 的效果一般又小于 In-Context Learning,因为后者是实时地把必要的知识或辅助信息当做 context 注入模型。
所以,后来我们更倾向于做 RAG、 In-Context Learning 这类优化。而实际上相比之下,目前我们 In-Context Learning 的应用还比较少。
原因在于 In-Context Learning 需要更丰富、结构化且准确的 context,而这些 context 比较难获取。比如现在要帮产品经理写一个新项目的产品文档,来做产品策划。产品的用户定位、功能定义、用户流程、UI 交互等,涉及多个领域。这些领域的知识和内容,要决定哪些需要提炼放入 context,去做 In-Context Learning,实际上有很大挑战。从目前实践效果来看,用工程或编程手段去解决,效果不如用 RAG 好。
但很多服务中,比如用户完成一件事后还会接着做下一件事,也就是当用户有连续性任务时,In-Context Learning 的应用门槛会相对低一些,因为可以知道用户当前场景变化和上一件事情的结果。
七、相比RAG、In-Context Learning,为什么微调的工程周期长很多
模型微调的工程周期很长,影响因素很多。
首先,构建微调模型需要高质量、标注良好的领域数据,耗费的精力往往占真实训练的绝大部分。有人直接指出微调 90% 的精力花在 “ 提升数据质量 ” 上 。
其次,微调 LLM 不像一般模型那么轻松。需要性能强劲的基础设施和优化、维护能力。训练本身往往耗时数周,甚至更久。
再次,微调往往不是一次搞定的。需要反复调参、验证、修复 bug、对比多个模型版本。
最后也是最关键的是,LLM 这个基础模型可能每隔几个月就会迎来新版本,原来的微调成果很快就可能被 “ 超越 ”。社区反馈也提到,每次基础模型更新后,几乎都得从头再来一次微调 。
相比之下,RAG 通常只需数天甚至数小时即可部署,尤其用 Hugging Face 的 RAG-Token 示例几行代码搞定。
并且,RAG 整体工程流程简单,门槛低于深度培训。知识库变更最快,只需重新 embed 文档,完全无需重训模型。因此,可以实时响应信息变化。
社区普遍反馈道,相比代价高耗时的微调,RAG 简便且性价比更高。
对于 In-Context Learning ( ICL ),本质上只需构造好 prompt,可能还需要加入若干示例( few-shot ),基本不需要训练过程。工程实现几乎是几分钟到几小时搞定 prompt 设计、示例选取、效果验证。
对比微调,ICL 可谓 “ 立刻见效 ”。
未完待续........