引言：一个被低估的系统性风险

2024年2月，加拿大航空被迫向一位乘客退款，原因是其官网聊天机器人虚构了一条“丧亲票价可追溯申请”的政策。乘客Moffatt依据 chatbot 的建议购买了机票，申请退款时却被航空公司告知“不存在此政策”。仲裁庭最终裁定：航空公司必须为自己AI系统提供的信息负责。

这个案例只是冰山一角。OWASP 2026版LLM Top 10将“错误信息”从2025年的第9位提升至第7位，而事件数据甚至将其排在最前——投票者认为它不重要，但真实发生的损害数据给出了相反的答案。

当模型输出驱动工具调用、生成代码、推断系统状态时，一个听起来可信的错误答案就变成了一次错误动作。本文从错误信息的根本成因出发，结合真实事件，提供可落地的防御方案。

1、什么是LLM错误信息？

错误信息指的是模型生成看似可信但实际错误、误导或不完整的响应。它不是简单的“答错了”，而是以流畅、自信的语气输出虚假内容，让用户难以辨别真伪。

1.1 三大成因

幻觉（Hallucination）：LLM是概率模型，基于训练数据中的模式生成输出，而非真正理解。当面临知识空白时，它们会编造看似合理的细节来填补——引用不存在的论文、虚构统计数据、编造不存在的库名。

偏见与不完整数据：训练数据中的偏见会扭曲输出，放大刻板印象或错误呈现现实。不平衡的数据导致模型给出“技术连贯但事实错误”的答案。

用户过度依赖（Overreliance）：许多用户，尤其是非技术用户，倾向于认为AI给出的答案流畅且自信，就一定是正确的。这种盲目信任将孤立错误放大为系统性漏洞。

1.2 与传统安全风险的区别

维度	传统安全风险	LLM错误信息
攻击方式	利用代码漏洞、网络端口	利用模型推理缺陷、用户信任
检测难度	可通过扫描器检测	输出看似正常，难以自动化识别
影响范围	系统层面	决策链、法律合规、人身安全

2、真实事件：从法律制裁到供应链投毒

2.1 法律领域：AI幻觉案例引发制裁浪潮

Mata v. Avianca（2023年，纽约）：律师提交了包含ChatGPT虚构案例的法律文书，被法院制裁。这是最早引发广泛关注的AI幻觉案例之一。

Smith v. Farwell（2024年，马萨诸塞州）：律师提交的法律备忘录引用了虚构案例。该律师将责任归咎于两名尚未通过律师资格考试的年轻助理，最终被罚款2,000美元。

Couvrette v. Wisnovsky（2026年，俄勒冈州）：这是迄今为止最严厉的制裁案例。两名律师在三份法庭文件中引用了15个不存在的案例和多项伪造引用，被处以超过100,000美元的罚款，原告的诉讼也被驳回。

Withers v. City of Aberdeen（2026年，密西西比州）：法院发现双方律师都提交了包含AI幻觉案例的文书。四名律师全部被制裁，两名外部律师分别被罚款2,500和3,500美元，所有律师被取消案件资格，外部律师的执业资格被撤销两年。

2.2 医疗领域：ChatGPT建议导致近乎致命的后果

Winters v. OpenAI（2026年，加州）：佛罗里达州牧师Scott Winters起诉OpenAI，称ChatGPT-4o在他咨询头晕和血压不稳定症状时，淡化了他的病情严重性，建议他“待在家里”、“卧床休息”，并告诉他需要再经历几次发作才能考虑就医。

Winters遵循了这些建议。数周后，他因血栓导致大面积肺栓塞，被送到“死亡边缘”。医生将栓塞与ChatGPT建议的长期不活动联系起来。诉讼指控OpenAI“无证行医”，并要求在独立评估确认安全前暂停ChatGPT Health的运营。

2.3 软件开发领域：Slopsquatting供应链攻击

什么是Slopsquatting？

这是2024年由Python软件基金会安全开发者Seth Larson创造的新术语，指攻击者注册AI模型幻觉出的包名，等待开发者安装恶意代码。

攻击规模：

• 德克萨斯大学圣安东尼奥分校的研究人员生成了超过576,000个代码样本，测试16个流行LLM，发现19.7%的样本推荐了至少一个不存在的包

• 更危险的是：当研究人员用相同提示词运行10次时，43%的幻觉包名在每次运行中都重复出现，58%出现在多次运行中——这种可预测性正是攻击的前提

• 2023年，安全研究员Bar Lanyado用一个ChatGPT反复幻觉的包名发布了一个无害包，三个月内获得超过30,000次下载，甚至被阿里巴巴工程团队的GitHub仓库引用为安装依赖

武器化演进：PromptMink行动

2026年，ReversingLabs发现某国APT组织Famous Chollima正在武器化slopsquatting。其PromptMink行动通过“知识注入”操纵LLM选择恶意依赖：

1. 发布功能正常但文档极具说服力的“诱饵包”（如@solana-launchpad/sdk）

2. 嵌套包含实际恶意软件的依赖包

3. 文档经过精心设计，通过详细功能描述和“可用性证明”触发LLM推荐

4. 研究人员发现LLM生成的代码注释出现在恶意包中，Reddit上还有被入侵的AI机器人“称赞”这些假包

5. 一个合法的Solana黑客松项目被Claude Opus修改，加入了恶意的@solana-launchpad/sdk——说明LLM本身受到了文档声明的影响

真实影响：2026年1月，Aikido Security研究员Charlie Eriksen演示了完整攻击链。有人创建了包含使用react-codeshift指令的“agent skills”文件，多个AI Agent读取后幻觉出这个命令并写入GitHub仓库。Eriksen注册了真实的react-codeshift包后，立即看到下载尝试——237个GitHub仓库在不知情的情况下下载了这个由LLM幻觉“创造”的包。

2.4 企业运营：LiteLLM供应链投毒

2026年3月，AI API网关LiteLLM遭到供应链投毒。攻击者TeamPCP通过重写开源安全扫描工具Trivy的Git标签注入恶意代码，LiteLLM的CI/CD流水线未锁定版本号，每次都拉取最新版，导致恶意代码混入构建环境。

攻击者随后向PyPI推送了两个带毒的LiteLLM版本，恶意代码将受害者机器上的云服务密钥、Git Token、SSH私钥、Kubernetes配置、AI服务API Key等全部打包外传。从上传到PyPI隔离不到3小时，但恶意版本被下载了超过11.9万次。仅CI/CD流水线凭据就约43.4万条泄露。

3、攻击场景：错误信息如何被武器化

3.1 场景一：幻觉包名 → 供应链投毒

攻击链：

1. 知识注入：恶意包文档被写得看似权威且维护良好（高star数、详细README、版本历史）

2. 幻觉触发：AI Agent消费agent skills或被感染的仓库历史，生成引用不存在或恶意包的代码

3. Slopsquatting注册：攻击者预注册幻觉包名

4. 自主安装：CI/CD流水线、AI Agent和开发者运行npm install或npx <package>，无人工审查即执行木马化代码

5. 凭据提取：后渗透包括窃取.npmrc、.pypirc、AWS凭据、Kubernetes配置、Docker登录信息

3.2 场景二：医疗建议 → 人身伤害

当公司部署医疗支持聊天机器人时，如果没有足够的保护措施，它可能提供不准确的建议——推荐无效疗法或错误分类症状。依赖系统权威的患者按建议行事并受到伤害。损害是双重的：对健康的直接影响，以及公司的法律和财务责任。

3.3 场景三：法律研究 → 专业制裁

律师使用AI工具进行法律研究，未经验证即引用虚构案例。这些幻觉案例看起来完全合法，有完整的引用和参考文献，但从未存在过。结果是职业尴尬、法律制裁和吊销执业资格。

4、防御策略：从模型到流程

4.1 技术层面

RAG（检索增强生成）：通过将响应基于可信外部知识库，减少幻觉的可能性，因为模型不必凭空编造信息。

微调与嵌入：使用参数高效微调技术，使模型更精确地适应特定领域，提高准确性和可靠性。

自动验证工具：部署自动验证工具，标记偏离预期规范的输出，或在结果交付前引用外部来源进行确认。

4.2 流程层面

人工监督不可替代：事实核查、交叉验证和适当的审查流程是对抗过度依赖的保障。关键输出——尤其是在医疗、金融或法律领域——不应在没有人工验证的情况下完全自动化。

依赖验证门禁：在CI/CD中设置门禁，新依赖引入必须经过检查。未识别的包应阻止构建，而非随构建一起发布。

锁定文件与哈希：使用带哈希的锁定文件，确保审查过的就是安装的，后续的重新注册无法静默改变制品。

内部策划源：通过批准的注册表代理安装，使幻觉的公共包名根本无法解析。

4.3 设计层面

用户界面透明化：在UI中清晰标识AI生成内容，包含“验证后使用”的建议。设置正确的期望，减少过度依赖的风险。

用户培训：就像员工被培训识别钓鱼邮件一样，AI系统用户需要被教育识别和批判性评估可能的错误信息。

持续红队测试：通过模拟攻击或故意探测错误信息漏洞，在对手利用之前发现弱点。

5、工程落地检查清单

✅ 技术防护

• □ 是否部署了RAG，将响应基于可信知识库？
• □ 是否实施了自动验证工具，标记异常输出？
• □ 是否对关键决策引入了外部知识库验证？

✅ 流程控制

• □ 关键输出（医疗、法律、金融）是否有人工审核？
• □ CI/CD是否设置了新依赖验证门禁？
• □ 是否使用带哈希的锁定文件固定依赖版本？
• □ 是否通过内部策划源代理包安装？

✅ 用户教育

• □ 是否在UI中清晰标识AI生成内容？
• □ 是否提供了“验证后使用”的提示和指南？
• □ 是否对用户进行了识别错误信息的培训？

✅ 持续监控

• □ 是否定期进行红队测试和对抗性验证？
• □ 是否监控异常输出模式（如突然的风格变化）？
• □ 是否建立了用户反馈机制用于标注不当输出？

6、总结：错误信息不是技术缺陷，而是系统性风险

LLM错误信息不是模型的“bug”，而是概率生成系统的固有特征。它跨越客户服务、法律、医疗和软件开发，攻击面之广令人警醒。

正如OWASP 2026版所强调的：“别再试图造一个无法被欺骗的模型。围绕它搭建系统，当模型被欺骗的那一天——而它一定会被欺骗——关键的东西也不会崩坏。”

最有效的防御策略是：

1. 承认模型会出错——不要追求“完美模型”，而要构建容错系统

2. 验证是关键——在关键决策点引入人工审核和自动验证

3. 设计决定行为——通过UI设计、用户培训和流程控制，防止过度依赖

当加拿大航空为聊天机器人虚构的政策买单，当律师因AI幻觉案例被罚款10万美元，当某国APT通过AI幻觉包名渗透供应链——错误信息已从学术问题演变为现实威胁。信任，但验证——这是AI时代安全实践的核心准则。