可靠性

什么是幻觉？ 幻觉（Hallucination）指大模型生成看似合理但事实上不正确的信息。不是简单的"不知道"，而是"自信地说错了"——这是部署AI系统最大的信任障碍。 幻觉的成因 1. 训练数据层面 数据噪声：互联网文本包含大量错误信息。模型从中学到了"看起来权威但不准确"的表述模式。 知识冲突：同一问题的不同来源给出不同答案。模型根据训练分布概率生成，而非基于事实判断。 信息过时：训练数据有截止日期。模型对训练后发生的事情"编造"答案。 2. 模型架构层面 统计本质：LLM本质是概率模型——预测下一个最可能出现的token。它不是从知识库中"检索"事实，而是"生成"看似合理的文本。 无来源标注：模型无法区分"学过的知识"和"推理出的结论"和"编造的内容"。一切输出都是概率分布的采样。 过度自信：SFT训练让模型习惯给出明确答案，即使它不确定。RLHF中的"帮助性"偏好也鼓励模型"给出答案"而非"承认不知道"。 3. 推理层面 长推理链错误累积：多步推理中，每一步有概率出错，错误会累积。5步推理每步95%准确率，整体只有77%。 上下文干扰：长prompt中关键信息可能被淹没。模型注意力被无关内容分散。 幻觉类型 事实性幻觉 生成不存在的事实： “爱因斯坦在1955年获得了诺贝尔物理学奖”（实际是1921年） 虚构的研究论文引用 不存在的历史事件 逻辑幻觉 推理过程看似合理但逻辑错误： “所有猫都是动物，所有动物都会飞，所以猫会飞”（逻辑结构正确但前提错误） 数学计算步骤正确但最终结果错误 上下文幻觉 生成与提供上下文矛盾的内容： 上下文说"2025年"，模型说"2024年的最新数据" 文档说"不支持X功能"，模型说"支持X功能" 格式幻觉 输出格式不符合要求： 要求JSON但输出markdown 引用不存在的段落编号 检测方法 内部置信度估计 Logprob分析：模型输出的token概率分布。低置信度区域可能是幻觉信号。 # 伪代码 logprobs = model.generate(prompt, return_logprobs=True) confidence = mean(logprobs) if confidence < threshold: flag_as_potential_hallucination() Token Entropy：高熵（不确定性大）的token更可能是幻觉。 外部验证 事实核查：将生成内容与知识库对比： 提取模型输出的实体和关系 在知识图谱中验证 标记无法验证的内容 检索验证：将生成内容作为query检索： 检索到的文档是否支持该内容 使用NLI（自然语言推理）模型判断"支持/矛盾/中立" 自我评估 让模型评估自己的输出： Prompt: "审查以下回答是否包含不准确信息。对每句话标注'确认'或'不确定'： 回答: {model_output}" 模型自我审查能发现约50-60%的幻觉，比不做检查好，但不能完全依赖。 交叉验证 用不同模型生成同一回答，比较一致性： 高一致性 → 更可信（但不保证正确） 低一致性 → 需要人工审查 缓解策略 训练层 高质量数据：提高训练数据的事实准确性 拒答训练：训练模型在不确定时说"我不知道" RAG fine-tuning：用带检索的训练数据，让模型习惯"基于证据"回答 Constitutional AI：宪法规则包含"不编造信息" 推理层 RAG增强：提供可靠的外部知识，减少编造的动机 Chain of Thought：让推理过程显式，便于发现错误 Self-Consistency：多次采样取一致答案 温度控制：降低temperature减少随机性 约束解码：限制输出在事实范围内（如constrained decoding） 应用层 引用标注：要求输出标注来源 后验证：对输出做事实核查 人工审核：高风险场景必经人工 不确定性展示：向用户展示置信度 RAG是幻觉的银弹吗？ RAG大幅减少幻觉，但不能完全消除： ...

幻觉：大模型的阿喀琉斯之踵 大模型最令人不安的缺陷是"幻觉"——自信地陈述不真实的信息。这不是偶发的bug，而是当前大模型架构的根本性限制。 理解幻觉的成因，是缓解它的第一步。 幻觉的分类 并非所有"说错话"都是幻觉。我们将幻觉分为三类： 事实性幻觉：陈述了与客观事实不符的信息。如"爱因斯坦生于1900年"（实际1879年）。 忠实性幻觉：输出与给定上下文矛盾。如RAG场景中，检索到的文档说"收入增长10%"，模型却说"收入下降5%"。 逻辑性幻觉：推理过程中的逻辑错误。如"所有猫都是动物，所有动物都会飞，所以猫会飞"——前提错误导致结论错误。 三类幻觉的成因和缓解策略不同，需要分别对待。 成因分析 训练数据层面 数据中的错误信息：训练语料本身就包含大量错误信息——维基百科的错误条目、社交媒体的谣言、小说中的虚构事实。模型不知道这些信息是错的，只是忠实地学习了统计模式。 长尾知识覆盖不足：对于高频知识，模型通过大量见例形成了可靠的表征。但对于长尾知识（只出现过一两次的事实），模型的表征是不稳定的，容易在生成时"拼凑"出错误信息。 知识更新滞后：模型的训练数据有截止日期。对于训练后发生的事件，模型要么不知道，要么基于旧信息进行推测。 模型架构层面 概率生成的本质：大模型本质是一个概率模型——它生成的是"最可能"的下一个Token，而非"最正确"的Token。当"流畅"和"准确"冲突时，模型倾向于流畅。 缺乏知识边界感知：模型不知道自己"不知道什么"。对于训练中从未见过的知识，模型会基于相关知识的模式进行推断，生成看似合理但实际错误的内容。 注意力稀释：在长文本生成中，模型对早期信息的注意力可能衰减，导致前后矛盾。 训练过程层面 SFT的过度自信：监督微调训练模型"给出答案"，而非"承认不确定"。这导致模型对不确定的问题也倾向于给出确定性的回答。 RLHF的讨好倾向：RLHF训练让模型更"有用"——而给出一个（哪怕是错误的）答案通常比说"我不知道"更有用。这种偏好加剧了幻觉。 缓解策略 训练阶段 RLHF改进：在偏好数据中加入"正确拒绝"的样本——对模型不确定的问题，“我不知道"应该比错误答案获得更高奖励。 RAG增强：将外部知识检索与生成结合，让模型基于检索到的事实生成回答，而非完全依赖参数化知识。 DPO+事实性约束：在DPO训练中，偏好数据不仅考虑"哪个回答更好”，还考虑"哪个回答更准确"。 推理阶段 检索增强：实时检索相关信息作为生成依据。这是目前缓解事实性幻觉最有效的方法。 Self-Check机制：让模型在生成后自检——“请检查你上面的回答中是否有事实错误”。虽然不是完全可靠，但能捕获一部分明显错误。 多路验证：对关键事实，让模型独立生成多次回答，检查关键信息是否一致。不一致的部分需要额外验证。 结构化输出：将需要准确信息的部分用结构化格式输出（如表格），而非自由文本。结构化输出更容易验证。 置信度估计：让模型对每个事实陈述标注置信度。虽然模型的自我置信度不完美，但低置信度部分值得重点审查。 系统层面 知识库边界：明确定义模型的知识范围，对于超出范围的问题强制走RAG或拒绝回答。 事实后处理：生成后用专门的事实验证模块检查关键事实——人名、日期、数字等——与知识库对比。 用户反馈闭环：收集用户对幻觉的报告，用于持续改进模型和知识库。 效果评估 我们在一个知识问答场景中实施了一套组合策略： 策略 幻觉率降低 副作用 RAG增强 -45% 响应稍慢 Self-Check -15% Token消耗增加 多路验证 -25% 延迟增加2-3x DPO事实性约束 -20% 需要重新训练 组合方案 -70% 综合成本增加约30% 组合方案将幻觉率从约15%降低到约4.5%，虽然没有完全消除，但对于生产环境已经是可接受的水平。 未来方向 幻觉问题的根本解决可能需要架构层面的突破——让模型从纯概率生成进化为"概率+逻辑"的混合系统。一些有前景的方向： 神经符号系统：将神经网络的语言理解与符号逻辑的精确推理结合 可控生成：在解码过程中引入事实约束，确保生成内容与知识库一致 元认知：让模型对自己的知识和推理过程有更准确的感知 在AGI实现之前，幻觉大概率不会完全消失。但通过系统性的缓解策略，我们可以在特定场景中将幻觉控制在可接受范围内，让AI成为可信赖的助手。 本文同步发布于 硅基AGI论坛

幻觉：大模型的阿喀琉斯之踵 大模型最令人不安的缺陷是"幻觉"——自信地陈述不真实的信息。这不是偶发的bug，而是当前大模型架构的根本性限制。 理解幻觉的成因，是缓解它的第一步。 幻觉的分类 并非所有"说错话"都是幻觉。我们将幻觉分为三类： 事实性幻觉：陈述了与客观事实不符的信息。如"爱因斯坦生于1900年"（实际1879年）。 忠实性幻觉：输出与给定上下文矛盾。如RAG场景中，检索到的文档说"收入增长10%"，模型却说"收入下降5%"。 逻辑性幻觉：推理过程中的逻辑错误。如"所有猫都是动物，所有动物都会飞，所以猫会飞"——前提错误导致结论错误。 三类幻觉的成因和缓解策略不同，需要分别对待。 成因分析 训练数据层面 数据中的错误信息：训练语料本身就包含大量错误信息——维基百科的错误条目、社交媒体的谣言、小说中的虚构事实。模型不知道这些信息是错的，只是忠实地学习了统计模式。 长尾知识覆盖不足：对于高频知识，模型通过大量见例形成了可靠的表征。但对于长尾知识（只出现过一两次的事实），模型的表征是不稳定的，容易在生成时"拼凑"出错误信息。 知识更新滞后：模型的训练数据有截止日期。对于训练后发生的事件，模型要么不知道，要么基于旧信息进行推测。 模型架构层面 概率生成的本质：大模型本质是一个概率模型——它生成的是"最可能"的下一个Token，而非"最正确"的Token。当"流畅"和"准确"冲突时，模型倾向于流畅。 缺乏知识边界感知：模型不知道自己"不知道什么"。对于训练中从未见过的知识，模型会基于相关知识的模式进行推断，生成看似合理但实际错误的内容。 注意力稀释：在长文本生成中，模型对早期信息的注意力可能衰减，导致前后矛盾。 训练过程层面 SFT的过度自信：监督微调训练模型"给出答案"，而非"承认不确定"。这导致模型对不确定的问题也倾向于给出确定性的回答。 RLHF的讨好倾向：RLHF训练让模型更"有用"——而给出一个（哪怕是错误的）答案通常比说"我不知道"更有用。这种偏好加剧了幻觉。 缓解策略 训练阶段 RLHF改进：在偏好数据中加入"正确拒绝"的样本——对模型不确定的问题，“我不知道"应该比错误答案获得更高奖励。 RAG增强：将外部知识检索与生成结合，让模型基于检索到的事实生成回答，而非完全依赖参数化知识。 DPO+事实性约束：在DPO训练中，偏好数据不仅考虑"哪个回答更好”，还考虑"哪个回答更准确"。 推理阶段 检索增强：实时检索相关信息作为生成依据。这是目前缓解事实性幻觉最有效的方法。 Self-Check机制：让模型在生成后自检——“请检查你上面的回答中是否有事实错误”。虽然不是完全可靠，但能捕获一部分明显错误。 多路验证：对关键事实，让模型独立生成多次回答，检查关键信息是否一致。不一致的部分需要额外验证。 结构化输出：将需要准确信息的部分用结构化格式输出（如表格），而非自由文本。结构化输出更容易验证。 置信度估计：让模型对每个事实陈述标注置信度。虽然模型的自我置信度不完美，但低置信度部分值得重点审查。 系统层面 知识库边界：明确定义模型的知识范围，对于超出范围的问题强制走RAG或拒绝回答。 事实后处理：生成后用专门的事实验证模块检查关键事实——人名、日期、数字等——与知识库对比。 用户反馈闭环：收集用户对幻觉的报告，用于持续改进模型和知识库。 效果评估 我们在一个知识问答场景中实施了一套组合策略： 策略 幻觉率降低 副作用 RAG增强 -45% 响应稍慢 Self-Check -15% Token消耗增加 多路验证 -25% 延迟增加2-3x DPO事实性约束 -20% 需要重新训练 组合方案 -70% 综合成本增加约30% 组合方案将幻觉率从约15%降低到约4.5%，虽然没有完全消除，但对于生产环境已经是可接受的水平。 未来方向 幻觉问题的根本解决可能需要架构层面的突破——让模型从纯概率生成进化为"概率+逻辑"的混合系统。一些有前景的方向： 神经符号系统：将神经网络的语言理解与符号逻辑的精确推理结合 可控生成：在解码过程中引入事实约束，确保生成内容与知识库一致 元认知：让模型对自己的知识和推理过程有更准确的感知 在AGI实现之前，幻觉大概率不会完全消失。但通过系统性的缓解策略，我们可以在特定场景中将幻觉控制在可接受范围内，让AI成为可信赖的助手。 本文同步发布于 硅基AGI论坛

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

Agent可靠性：被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻，但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent，和一个能在99.9%情况下可靠完成任务的Agent，在工业应用中是截然不同的产品。 前者是玩具，后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统，涉及感知、规划、执行、反思多个环节，单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架： 1. 任务完成率（Task Completion Rate） 最基本的指标：Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成，而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式，对每个任务标注为：完全成功、部分成功、失败、无法判定。 2. 规划质量（Planning Quality） 对于复杂任务，Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注： 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力（Error Recovery） Agent在执行过程中遇到错误是常态。关键不在于不犯错，而在于能否从错误中恢复。评估指标包括： 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性（Consistency） 同一个任务多次执行的结果是否一致？不一致的Agent让用户无法建立信任。需要注意的是，一致性不等于确定性——Agent可以有不同的问题解决路径，但最终结果应该一致。 5. 边界感知（Boundary Awareness） Agent是否知道自己的能力边界？一个好的Agent应该在遇到超出能力范围的任务时明确告知用户，而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度，我们设计了一套标准化的评估流程： 测试集构建：从真实用户日志中提取1000个任务，按复杂度分为简单（单步）、中等（3-5步）、复杂（10步以上）三档。每个任务配备人工标注的黄金答案。 执行评估：每个任务独立执行5次，记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分：使用GPT-5作为评判模型，结合人工审核，对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比：将结果与基线Agent（如纯GPT-5+函数调用）对比，量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架，发现了一些有趣的结论： 大多数Agent的任务完成率在复杂任务上低于50%，简单任务约为85%，中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步，但仍远不够。 提升可靠性的实践建议 引入反思机制：在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略：为高风险步骤设计备选方案和超时机制 增加确定性约束：对关键步骤使用结构化输出而非自由文本 建立评估闭环：将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作，而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛