LLM 幻觉问题与解决方案
理解大模型为什么会一本正经地胡说八道，掌握检测和缓解方法
- 理解幻觉的本质和成因
- 掌握幻觉检测方法
- 学会用 RAG/约束/验证减少幻觉
- 了解工业级防幻觉架构
LLM 幻觉问题与解决方案
大模型最被诟病的问题就是「幻觉」（Hallucination）——它会非常自信地给出错误答案。接下来咱们聊幻觉的本质、成因和工业级解决方案。
什么是幻觉？
幻觉是指 LLM 生成了看似合理但实际上不真实、错误或无意义的内容。分为两类：
模型说「Python 是由 James Gosling 在 1995 年发明的」，这是事实性幻觉，James Gosling 是 Java 的发明者。
忠实性幻觉：模型的回答和给定上下文矛盾，比如让它总结一篇文章，它编造了文章里没有的内容。
幻觉示例：问 LLM 一个不存在的问题User: "Python 3.14 引入了什么新语法？"LLM 可能会编造: "Python 3.14 引入了 match-case 模式匹配的重大增强..."实际上 match-case 早在 Python 3.10 就已引入，所谓“3.14 重大增强”是模型张冠李戴编出来的 幻觉不是 bug，是 LLM 的本质特性LLM 是「下一个 token 预测器」，它追求的是「看起来合理」而非「事实正确」
理解 LLM 的本质是理解幻觉的关键：LLM 不是知识库，它是一个概率模型。它根据训练数据中的统计规律生成文本，回答「最可能出现的下一个词」，而不是「最正确的答案」。当训练数据不足或问题超出分布时，它就会编造。永远不要假设 LLM 的输出是事实——在关键场景中必须验证。
幻觉的成因
训练数据噪声：互联网数据包含大量错误信息，模型照单全收。
知识截止：模型的知识有截止日期，之后的事件它不知道。
概率解码：temperature > 0 时模型会采样，可能跳到低概率但错误的路径。
对齐不足：RLHF训练让模型乐于助人，有时它宁愿编答案也不说不知道。
长上下文里的矛盾信息，会误导模型。
解决方案一：RAG（检索增强生成）
防幻觉最直接的办法：别让模型靠记忆答，先搜权威资料，让它基于搜到的内容回答。
Prompt 里明确说了不知道就说不知道给用户提供引用来源让他们自己验证检索质量直接影响回答质量，垃圾进垃圾出只把和问题相关的检索结果塞进上下文，不相关的文档别加进去
解决方案二：约束解码与结构化输出
要让模型输出JSON这类结构化格式，用JSON Schema约束它的输出空间就行，能减少模型的自由发挥。
解决方案三：自我验证与多轮检查
工业级防幻觉架构
豆包这类亿级用户产品里，防幻觉是系统工程，不是单一技术能搞定的。核心做法：高风险场景（医疗/法律/金融）必须 RAG + 人工审核给答案附引用来源，让用户自己判断对模型输出做后置校验（正则/规则/二次调用）监控幻觉率，建 bad case 库持续优化接受模型会犯错，产品设计上做容错。
幻觉评估指标
如何量化幻觉率？学术界和工业界常用：
FactScore：把答案拆成单个原子事实，逐个核对对错
TruthfulQA：专门测试模型是否会模仿常见误解，共817个问题
RAGAS：RAG 系统的评估框架，含 faithfulness（忠实度）指标
# FactScore 计算示例
def factscore(answer, reference_facts):
"""答案中正确事实的比例"""
answer_facts = answer.split("。")
correct = sum(1 for f in answer_facts if f.strip() in str(reference_facts))
return correct / len(answer_facts) if answer_facts else 0
# 例：答案包含5个事实声明，4个正确 -> FactScore = 0.8以下哪种方法最有效减少事实性幻觉？
LLM 产生幻觉的根本原因是什么？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
同步是发起后一直等结果；并发是「同时在推进」，靠切换让多个任务在等待期交错前进；并行是「同一刻真的在多核同时执行」。I/O 任务大部分时间在等，单线程并发就能拿到高吞吐；只有真正吃 CPU 的计算才需要多核并行。面试时能结合场景讲清「瓶颈是等 I/O 还是算」，比背定义更得分。
挑战任务
防幻觉问答系统
写个问答函数，要带置信度评分，还要有答不上就直接说不知道的机制。
课后作业
幻觉检测器
写一个函数，检查 LLM 回答里有没有「可能」「大概」这类不确定词，有的话就标记成低置信度。