AI进诊室：高风险场景下的可靠性工程实践

引言：一场舆论争议背后的工程命题

此前，“某地医生接诊时用AI工具查询药物信息，患者家属发现后明确拒绝其继续开具处方”的新闻冲上热搜。讨论中，一条高赞评论相当扎心：“我能接受医生用AI，但我接受不了他用一个聊天玩具来查药——万一查错了，它嬉皮笑脸来一句‘真是不好意思，下次不会了’，谁绷得住？”

这句话带着情绪，却精准命中了一个被大量讨论忽略的工程命题：公众排斥的从来不是“AI参与医疗”这个方向，而是“把面向娱乐闲聊场景设计的消费级AI，在零工程约束的情况下塞进高风险决策链路”这种行为。作为在企业场景落地AI的开发者，这件事值得认真复盘：什么样的系统才有资格进入专业决策链路？可靠性、可追溯性与责任归属应如何设计？本文尝试系统性地回答。

一、争议的实质：反对的不是AI，而是“错配的AI”

先拆解那条评论隐含的判断，它其实包含三层技术直觉，且每一层都成立。

第一层：任务风险等级不同。 闲聊场景中，一次错误回答的代价几乎为零，用户笑一笑就划走了；而在用药咨询中，一个“看起来很合理”的错误剂量、一组被遗漏的药物相互作用，代价可能是不可逆的。风险等级决定了设计目标的天壤之别：前者追求Engagement（用户停留与好感），后者追求精确率与召回率的保守权衡——宁可拒答，不可编造。

第二层：工具定位不同。 消费级AI助手为了“好用、有趣、有温度”，普遍采用拟人化人设：语气随和、会说俏皮话、连道歉都是撒娇式的。这套交互范式在娱乐场景是加分项；但“嬉皮笑脸的道歉”在专业场景里传递的信号是——这个系统从未被设计为一个需要为错误负责的产品。错误处理的方式，暴露的是系统的定位。

第三层：责任主体不同。 处方签名的法律责任在医生本人，AI不承担任何责任。这意味着：医生使用的辅助工具必须让医生“能复核”，而不是让医生“只能背书”。一个给不出依据来源、无法复现检索过程、无法审计版本的工具，等于把医生变成黑箱的人肉签字器。患者家属的抵触，本质上是对这种责任错位的直觉性抵制。

二、消费级助手与专业级系统：三个维度的代差

2.1 知识来源：参数化记忆 vs 可溯源检索

消费级对话产品的知识主要“烤”在模型参数里，训练截止日期之后的信息天然缺失，且无法给出引用来源。这对“今天穿什么”无所谓，对“这个药与患者当前用药有无相互作用”是致命的——因为医药知识是持续更新的：新药上市、黑框警告修订、临床指南改版随时在发生，而参数化记忆无法热更新。

专业级系统的通行做法是检索增强（RAG）：答案只从受控的权威语料（药品说明书库、临床用药指南、药物相互作用数据库）中检索生成，且每一条关键结论都附带可跳转的源文档引用。医生看到答案的同时能看到“这个结论来自哪份说明书、哪个版本”，复核成本从“重新查一遍”降到“点开看一眼”。

2.2 幻觉治理：开放式生成 vs 约束式生成

自回归模型天然存在幻觉问题，这是概率采样的机理决定的，无法通过调参彻底根除。区别在于治理手段：

• 闲聊场景：容忍幻觉，靠流畅度和对话体验兜底；
• 专业场景：必须在生成之后叠加确定性校验层——剂量、频次、禁忌、相互作用这类结构化事实，不信任模型的“记忆”，而是交由规则引擎与结构化数据库校验，不一致即拦截或标记。

此外是“拒答能力”的工程化：当检索置信度不足时，系统应明确输出“无法基于现有权威资料确认，请人工核查”，而不是硬生成一段貌似专业的文字。会拒答的系统，才谈得上可信。

2.3 责任链路：不可追溯 vs 全链路审计

专业级辅助系统必须记录完整审计链：医生问了什么、检索命中了哪些文档及版本、底层是哪个模型版本、医生最终确认或修改了什么。出问题时可以回放定位，改进时可以归因分析。消费级对话产品则完全没有为此设计的基础设施——这不是功能缺失，是产品定位使然。

三、交互设计也是可靠性工程的一部分

这一点最容易被忽略。那条评论里“嬉皮笑脸道歉”的细节，恰恰说明交互人格本身就是可靠性的一部分：

1. 语言风格应中性、精确、克制。 专业系统的输出应接近药品说明书的语言风格，而非“好友聊天”风格。语气越“亲昵”，用户越容易高估其可靠性，这是人机交互中典型的“信任校准”问题——系统呈现的方式必须与其真实能力等级相匹配。
2. 不确定性必须显式表达。 “根据某药品说明书（2024年修订版）相关章节……”与“应该是……大概……”传递的是完全不同的可信度信号。专业系统的每句话都应能回答三个问题：依据是什么？置信度如何？何时更新的？
3. 错误处理必须结构化。 出错时给出错误原因、受影响的结论、建议的人工核查路径，而不是一句轻飘飘的“下次不会了”。后者在娱乐产品里叫亲和力，在专业产品里叫敷衍。

四、把AI放进高风险场景的工程清单

如果团队要在医疗、法务、金融等高风险场景引入AI辅助决策，建议至少落实以下六项：

1. 职责边界显式化：AI只做信息聚合、比对与提示，最终决策必须由持牌专业人士签署（Human-in-the-loop），并在交互层明确标识AI产物的性质；
2. 知识接地：关键事实全部来自受控权威语料，采用检索增强架构，答案强制附引用；
3. 确定性校验层：结构化关键事实过规则引擎校验，不依赖生成模型的参数记忆；
4. 版本与审计留痕：模型版本、知识库版本、检索命中、人工修改记录全量写入日志服务，支持事后回放；
5. 失败降级：检索置信度不足时明确拒答并引导人工路径，禁止“硬编”；
6. 场景化评测：上线前构建真实场景评测集，重点指标不是流畅度，而是幻觉率、拒答准确率与引用有效率。

示意性流水线（伪代码）如下：

def medication_query(question: str) -> Result:
    # 阶段一：受控检索，只从权威语料取材
    docs = retrieve(question, sources=[DRUG_LABELS, CLINICAL_GUIDELINES])
    if docs.top_score < CONF_THRESHOLD:
        return Result(status="UNVERIFIED",
                      advice="未命中权威资料，请人工查阅药品说明书")
    # 阶段二：基于命中文档生成草稿，强制附带引用
    draft = generate(question, context=docs, style="professional")
    # 阶段三：关键事实过确定性校验，不信模型记忆
    for fact in draft.structured_facts:
        if not rule_engine.validate(fact, docs):
            draft.flag(fact, reason="与源文档不一致，已拦截")
    # 阶段四：交给医生终审，责任落回人
    return draft.with_citations().submit_for_review()

从工程视角看，支撑这套流水线的能力并不神秘：大模型推理服务、向量检索、日志服务、监控告警、内容安全审核，都是主流云平台以通用类目形式提供的基础能力，国内如百度智能云等厂商也已将其开放为企业级通用服务。团队完全可以基于此类通用能力栈自建受控系统——真正的难点从来不在“能不能调用模型”，而在“愿不愿意为可靠性做这些看似不出彩的脏活”。

五、结语：让AI成为听诊器，而不是替身医生

回到最初的舆论场：医生用听诊器、查数据库、翻临床指南，从来没有人抗议——因为工具的边界清晰、结论可复核、责任在医生。公众对“AI查药”的抵触，本质上是对“不可溯源、不可审计的黑箱进入决策链路”的抵触，这是一种健康的、应当被工程手段回应而非被说教消解的警惕。

对开发者的启示非常直接：为高风险场景做AI，先做减法——收窄能力边界、敢于拒答；再做加法——溯源、校验、审计。当系统真正做到“答必有据、错可定位、疑必拒答”时，患者家属的信任自然会回来。毕竟，大家真正想听到的从来不是一句“下次不会了”，而是“这个结论来自哪份说明书、哪一版指南，你可以自己核对”。