幻觉与可靠性
一句话理解
大模型的目标是生成高概率文本，不是天然验证事实。幻觉不是偶发现象，而是生成式模型机制、训练数据和上下文限制共同导致的可靠性风险。
什么是幻觉
幻觉指模型生成了看似合理但实际错误、无法验证或凭空捏造的内容。
常见表现：
- 编造不存在的论文、链接、API 或命令参数。
- 混淆相近概念。
- 给出过时信息。
- 对不确定问题表现得过度肯定。
- 写出看起来正确但不能运行的代码。
- 在长上下文中漏掉关键限制。
为什么会幻觉
1. 训练目标不是事实验证
模型训练目标主要是预测下一个 token。它会倾向于生成在上下文中“像正确答案”的文本，但这不等于答案被验证过。
2. 参数不是数据库
模型参数保存的是压缩后的统计结构，不是结构化、可精确查询、可实时更新的数据库。
因此它可能：
- 记错细节。
- 混合多个相似事实。
- 无法知道训练后发生的新变化。
3. 上下文有限
模型只能基于当前上下文和参数知识回答。如果关键信息不在上下文里，它可能根据相似模式补全。
4. 用户问题有歧义
当问题缺少条件时，模型可能默认补全隐含前提。这些前提如果不成立，答案就会偏离。
5. 后训练会鼓励“有帮助”
助手模型通常被训练成尽量回答问题。如果拒绝、不确定或追问的行为没有被充分强化，模型可能倾向于给出看似完整的答案。
哪些场景风险更高
- 最新新闻、价格、政策、版本、依赖库 API。
- 医疗、法律、财务、安全等高风险建议。
- 冷门项目、内部系统、私有代码。
- 长日志、长表格、长需求文档。
- 需要精确计算或严格证明的问题。
- 需要真实执行环境验证的代码。
使用原则
越是高风险、强时效、强事实、强执行后果的问题，越不能只依赖模型单次生成。
如何提高可靠性
1. 给足上下文
把约束、版本、目标、输入输出样例放进上下文，减少模型自行猜测。
2. 使用 RAG 或搜索
对时效性知识、内部文档、项目资料，优先让模型基于检索结果回答。
3. 使用工具验证
代码类任务应该尽量运行：
- 单元测试。
- 编译。
- Linter。
- 类型检查。
- SQL explain。
- 小样本脚本。
4. 要求标注不确定性
让模型明确区分：
- 已知事实。
- 基于上下文的推断。
- 需要验证的猜测。
5. 拆小任务
复杂任务拆成多个步骤：
理解需求 -> 找相关文件 -> 修改 -> 运行测试 -> 复查差异比一次性生成完整方案更可靠。
6. 人工审查关键决策
权限、安全、资金、生产变更、隐私数据相关内容，需要人工审查或自动化策略兜底。
RAG、工具调用和 Agent 的位置
| 方法 | 解决的问题 | 不能解决的问题 |
|---|---|---|
| RAG | 补充外部知识、减少过时和缺失 | 检索错了仍会误导模型 |
| 搜索 | 获取最新信息 | 来源质量需要判断 |
| 工具调用 | 让模型执行和验证 | 工具结果也可能被误读 |
| Agent 循环 | 多步观察、执行、修正 | 规划错误会放大成本 |
| 人工审查 | 兜底关键风险 | 成本高，不能覆盖所有细节 |
小结
核心结论
大模型可靠性来自“模型能力 + 上下文质量 + 外部验证 + 风险控制”的组合。不要把 LLM 当成事实数据库或形式化证明器，更适合把它当成一个需要工具和审查配合的概率生成系统。