从医疗到金融：大模型幻觉在不同行业的真实危害案例与应对策略

从医疗到金融：大模型幻觉在不同行业的真实危害案例与应对策略

最近和几位在医疗科技和金融科技公司负责AI落地的朋友聊天，大家不约而同地提到了同一个词：“幻觉”。不是指人的幻觉，而是指他们正在部署的大语言模型（LLM）有时会“一本正经地胡说八道”。一位朋友提到，他们内部测试的医疗问答助手，在回答一个关于罕见病用药剂量的问题时，给出了一个看似专业、实则完全错误的数值，差点被测试医生当成参考。另一位在银行做风控的朋友则苦笑，说他们的模型在分析一份企业财报时，凭空“捏造”了几条不存在的负面新闻，导致风险评估出现了偏差。

这些并非孤例。当大模型从实验室走向真实的生产环境，其“幻觉”问题就不再是一个单纯的学术概念，而是可能带来真实业务风险、经济损失甚至法律纠纷的“定时炸弹”。对于AI产品经理和企业技术决策者而言，理解不同业务场景下模型幻觉的差异化表现，并掌握针对性的缓解策略，已成为确保AI项目成功落地的核心能力。本文将深入剖析医疗、金融等关键行业的幻觉危害案例，并探讨如何结合检索增强生成（RAG）等前沿技术，构建更可靠、更可控的AI应用。

1. 行业风险透视：当幻觉照进现实

模型幻觉，简单来说，就是模型生成的内容与事实不符，或与给定的指令、上下文不一致。在学术讨论中，我们常将其分为事实性幻觉（Factuality Hallucination）和忠实性幻觉（Faithfulness Hallucination）。但在商业实践中，这种分类需要被翻译成更具体的业务语言：前者关乎“对错”，后者关乎“是否按要求办事”。

1.1 医疗健康：误诊风险与责任边界

在医疗领域，AI的幻觉可能直接关乎生命健康。一个典型的案例是临床决策支持系统。假设一位医生向AI助手咨询：“针对一位65岁、患有中度肾功能不全的II型糖尿病患者，二甲双胍的起始剂量应如何调整？”

一个存在事实性幻觉的模型可能会这样回答：

“对于伴有肾功能不全的糖尿病患者，二甲双胍仍可作为一线用药。建议起始剂量为每次500mg，每日两次，随餐服用。”

这个回答听起来专业，但存在致命错误。根据多数临床指南，中度肾功能不全（eGFR 30-45 mL/min）是使用二甲双胍需要谨慎评估甚至禁用的指征，起始剂量通常需要大幅降低或避免使用。模型可能从海量文献中“学习”到二甲双胍是II型糖尿病一线用药，却未能准确关联“肾功能不全”这一禁忌症，导致了危险的“事实捏造”。

更隐蔽的是忠实性幻觉。例如，医生上传了一份包含患者病史、实验室检查和影像学报告的复杂病历，要求模型“总结当前最需要关注的三个潜在风险”。模型却可能忽略影像报告中提到的“新发微小肺结节”，转而总结了一些从病史中推断的、但并非当前急迫的风险。这种输出虽然不一定“错误”，但严重偏离了指令和上下文重点，可能导致医生错过关键预警。

医疗场景的幻觉特点：

• 危害性极高：直接关联诊断、治疗建议，错误可能导致患者伤害。
• 责任界定模糊：当AI给出错误建议时，责任在开发方、部署医院还是使用医生？这给产品合规带来巨大挑战。
• 数据敏感且专业：医学知识更新快，专业术语多，模型容易在长尾、前沿或跨模态（文本与影像结合）信息上产生幻觉。

1.2 金融与风控：合规漏洞与市场波动

金融行业对信息的准确性、及时性和一致性要求近乎苛刻。幻觉在这里可能引发连锁反应。

案例一：自动化财报分析与信用评估一家投资机构使用大模型自动解析上市公司年报，并生成投资摘要。模型在分析某科技公司财报时，可能“幻觉”出以下内容：

“该公司在报告中披露，其核心业务的毛利率同比提升了5个百分点，主要得益于原材料成本的有效控制。”

然而，实际财报中可能只提到“毛利率保持稳定”，甚至略有下降。这个凭空生成的“利好”信息，如果被交易员快速采纳，可能误导投资决策，引发市场不当波动。这属于典型的事实性幻觉（事实捏造）。

案例二：反洗钱（AML）警报调查在反洗钱场景中，分析师需要根据一系列复杂的交易记录，判断是否存在可疑行为。AI助手被要求“根据以下交易流水，列出与实体A相关的所有可疑交易模式”。如果模型产生了忠实性幻觉，它可能：

• 遗漏了指令中指定的“实体A”，转而分析了流水中的所有实体。
• 自行引入了未被提供的“地域风险标签”作为判断依据，导致分析偏离既定合规框架。

金融场景的幻觉特点：

• 经济后果直接：可能导致直接的投资损失、错误的信贷决策或合规罚款。
• 追溯与审计困难：模型的“黑箱”特性使得错误结论的产生路径难以追溯，不符合金融监管对可解释性的要求。
• 对实时外部数据依赖强：股价、政策、舆情等信息瞬息万变，模型内部静态知识极易过时，产生事实性幻觉。

1.3 法律与客服：信任崩塌与品牌损伤

在法律文件审阅或智能客服场景，幻觉同样致命。法律AI若在合同关键条款上“捏造”了不存在的免责声明，可能导致客户面临巨大法律风险。智能客服若对产品功能、价格政策给出错误回答（事实性幻觉），或对用户复杂问题答非所问（忠实性幻觉），将迅速消耗用户信任，损害品牌形象。

提示：评估行业风险时，一个实用的框架是考察幻觉的“可能性”与“影响度”。医疗幻觉的“影响度”极高，因此即使“可能性”较低，也需投入最严格的防控。客服幻觉“可能性”高但“影响度”相对较低，策略上可更侧重快速检测与纠正机制。

2. 幻觉的根源：不止于数据问题

要解决问题，必先理解其根源。网络上的综述常将幻觉归因于数据、训练和推理三大方面。但从工程落地视角，我们需要更结构化的理解。

以金融风控模型为例，其幻觉可能源于：

1. 数据缺陷：训练数据中，某些欺诈模式样本极少（长尾问题），模型无法准确识别。
2. 训练偏差：在人类反馈强化学习（RLHF）阶段，标注员可能更倾向于让模型输出“确定性高”的结论，导致模型在证据不足时也强行给出判断，而非承认信息有限。
3. 推理随机性：使用高温采样（high temperature）以增加报告多样性，但也提高了生成不相关或虚构细节的概率。

理解这些根源，有助于我们“对症下药”，而非盲目尝试所有缓解技术。

3. 构建防线：RAG作为核心缓解策略

面对幻觉，业界已探索出多种技术路径，如改进训练数据、模型微调（Fine-tuning）、提示工程（Prompt Engineering）等。但对于大多数企业而言，尤其是那些无法负担从头训练或大规模微调成本的组织，检索增强生成（Retrieval-Augmented Generation, RAG）是目前最实用、最有效的工程化解决方案。

RAG的核心思想很简单：不让模型完全依赖其参数化记忆（可能过时或不完整），而是在回答问题时，实时从外部、可信的知识库中检索相关信息，并将这些信息作为上下文提供给模型，引导其生成更准确、更忠实的答案。

3.1 RAG系统的基本架构与实战

一个典型的RAG系统包含两个核心阶段：检索（Retrieval）与生成（Generation）。

阶段一：检索

1. 知识库构建：将企业内部的文档、数据库、API实时数据等非结构化或结构化信息，通过嵌入模型（Embedding Model）转化为向量，存入向量数据库（如Chroma, Weaviate, Pinecone）。
2. 问题向量化：当用户提问时，使用相同的嵌入模型将问题转化为向量。
3. 相似性检索：在向量数据库中搜索与问题向量最相似的文本片段（通常返回top-k个）。

阶段二：增强生成将原始用户问题与检索到的相关文本片段，组合成一个增强的提示（Prompt），提交给大语言模型。例如：

你是一个专业的医疗信息助手。请严格根据以下提供的参考信息来回答问题。如果参考信息不足以回答问题，请明确告知“根据提供的信息无法确定”。 [参考信息开始] 1. 《中国2型糖尿病防治指南（2020年版）》指出：二甲双胍用于肾功能不全患者需谨慎。估算肾小球滤过率（eGFR）在45-59 ml/min/1.73m²时需减量；eGFR<45 ml/min/1.73m²时禁用。 2. 药品说明书：盐酸二甲双胍片说明书中明确，肾功能不全（男性血清肌酐≥1.5mg/dL，女性≥1.4mg/dL）患者禁用。 [参考信息结束] 问题：一位65岁、患有中度肾功能不全的II型糖尿病患者，二甲双胍的起始剂量应如何调整？ 请基于以上参考信息回答。

通过这种方式，模型被“锚定”在提供的可靠信息上，极大减少了依赖内部记忆产生事实性幻觉的可能，也确保了回答与指令（“根据参考信息”）的忠实性。

3.2 进阶RAG模式：应对复杂场景

基础的RAG（一次性检索）有时仍不足够，尤其是在处理多跳问题或需要迭代深化的任务时。

• 迭代检索/递归检索：模型在生成答案的过程中，可以判断当前信息是否充足，若不充足，则基于已生成的内容提出新的检索查询，循环往复，直到收集到足够信息。这适合复杂的分析性任务。
• 事后检索与修正：模型先生成一个初步答案，然后基于这个答案去检索相关事实进行验证，并对答案中无法验证的部分进行修正或标注。这为生成内容提供了事实核查的环节。

金融报告分析场景的RAG增强示例： 假设需要分析一份混合了文本、表格的复杂财报。

1. 预处理：将财报PDF通过OCR和解析工具，分割成结构化的文本块和表格数据，分别生成嵌入存入向量库。
2. 混合检索：用户提问“该公司2023年研发投入占营收比例是多少？”。系统同时进行：
   • 语义检索：在文本块中搜索“研发投入”、“营收比例”等相关描述。
   • 结构化查询：如果解析出了表格，可同时用SQL或类似查询语言在表格数据中直接定位相关数字。
3. 合成与生成：将检索到的文本描述和精确的表格数据一同放入提示词，要求模型计算并解释比例。

# 伪代码示例：一个简单的RAG检索步骤 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载并分割知识文档 with open("financial_report_2023.md", "r") as f: text = f.read() text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200) docs = text_splitter.create_documents([text]) # 2. 创建向量存储 embeddings = OpenAIEmbeddings() vectorstore = Chroma.from_documents(documents=docs, embedding=embeddings, persist_directory="./chroma_db") # 3. 检索（在实际应用中，此步骤在用户提问时触发） query = "2023年研发投入金额及营收总额" retrieved_docs = vectorstore.similarity_search(query, k=3) # retrieved_docs 即为检索到的相关文本片段，将用于构建增强提示

3.3 RAG的局限与互补方案

RAG并非银弹。它的效果严重依赖于：

• 检索质量：如果知识库不完整、更新不及时，或检索算法未能找到最相关片段，则“垃圾进，垃圾出”。
• 模型指令遵循能力：即使提供了正确参考，模型也可能忽视它，依然依赖固有知识生成答案（忠实性幻觉）。

因此，RAG需要与其他策略结合使用：

1. 提示工程优化：在提示词中明确要求模型“引用”检索到的片段，或先列出检索到的关键事实再综合。使用思维链（Chain-of-Thought）提示，让模型展示推理过程，便于人工复核。
2. 微调（Fine-tuning）：在特定领域数据上对基础模型进行微调，可以显著提升其理解领域术语、遵循领域格式和减少该领域内幻觉的能力。微调与RAG结合，效果往往最佳。
3. 输出后处理与验证：
   • 自我一致性（Self-Consistency）：让模型多次生成答案，选取最一致的答案作为最终输出。
   • 事实核查：对模型输出中的关键实体（如公司名、药物名、数据）进行二次检索验证。
   • 不确定性量化：让模型为其答案输出一个置信度分数，低置信度答案可转入人工审核流程。

4. 评估与监控：将幻觉控制在发生之前

部署了缓解策略后，如何评估其有效性？如何持续监控生产环境中的幻觉？这需要建立一套贯穿模型生命周期的评估体系。

4.1 构建领域特定的评估基准

通用的幻觉评估数据集（如TruthfulQA）不够用。企业需要构建自己的领域评估集。例如，一家医疗科技公司可以构建如下测试集：

• 构造样本：收集或构造一批“问题-标准答案-参考文档”三元组。
• 注入幻觉：人工修改或使用模型生成一些包含典型幻觉（如剂量错误、禁忌症遗漏、指令偏离）的答案作为负样本。
• 定义评估指标：
  • 事实准确性：答案中的关键事实（如数值、实体、关系）是否与标准答案一致？可采用基于NLI（自然语言推理）的自动评估，或关键信息抽取对比。
  • 忠实度：答案是否严格基于提供的“参考文档”？可计算答案与参考文档的ROUGE-L分数，或使用QA评估方式（针对答案生成问题，看能否从参考文档中找到支持）。
  • 实用性：在业务场景下，答案是否有用、无误导？这通常需要领域专家进行人工评估。

4.2 生产环境下的持续监控

线上监控是最后一道防线。可以设计以下监控点：

1. 输入-输出一致性检查：对于强调忠实性的任务（如摘要、问答），实时计算模型输出与输入源的语义相似度或事实重叠度，设置阈值告警。
2. 外部知识验证：对于涉及关键事实（如金融数据、医疗代码）的输出，建立自动化流程，将其与权威数据库或最新API进行比对。
3. 用户反馈闭环：在产品中设计便捷的“反馈”按钮（如“答案不准确”），将用户标记的疑似幻觉案例自动收集，用于后续模型迭代和评估集丰富。
4. 不确定性监控：记录模型生成时的token概率或通过多次采样计算答案的一致性分数，对低置信度、高不确定性的生成进行标记和人工复审。

一个简单的监控日志表设计：

通过这套评估与监控体系，团队不仅能量化幻觉缓解措施的效果，还能快速发现线上新出现的幻觉模式，形成“检测-分析-优化”的持续改进闭环。

在实际项目中，我们往往需要在“模型能力”、“响应速度”、“成本”和“准确性/忠实性”之间做权衡。RAG引入的检索步骤会增加延迟，复杂的验证流程会增加计算成本。我的经验是，在核心业务场景（如医疗诊断辅助、金融合同关键条款审查）必须追求最高的事实准确性，不惜以更高的延迟和成本为代价，采用“RAG + 精细提示 + 后验证”的组合拳。而在风险相对可控的辅助场景（如内部知识库问答、创意文案生成），则可以适当放宽要求，采用更轻量级的策略。关键在于，作为技术决策者，你必须清晰地定义每个应用场景的“幻觉容忍度”，并据此设计与之匹配的技术架构。