AMIE如何让大模型学会主动问诊：从答题到对话诊疗的技术拆解

医学问诊这件事，长期以来被认为是人工智能最难啃的骨头之一。不是因为它需要多深的算力，而是因为它同时要求模型具备长程对话记忆、多模态信息整合、鉴别诊断推理，以及在信息不完整时主动追问的能力。过去几年里，各类模型在静态医学考试题上刷分刷得飞起，但一旦进入真实的多轮问诊场景，往往撑不过三个回合就露怯——要么过早下诊断，要么把患者说的关键线索漏掉，要么在追问时问了一堆无关紧要的问题。AMIE 这个项目之所以在圈内引起讨论，恰恰是因为它把评测场景从"答题"拉回到了"对话诊疗"本身。我花了一段时间梳理它的技术路径、评测设计和落地边界，下面把这些拆解分享出来，适合对医疗 AI 落地感兴趣的开发者、产品设计者，以及想搞清楚"大模型问诊到底靠不靠谱"的从业者参考。

1. 先搞清楚 AMIE 到底在解决什么问题

1.1 从"考试型 AI"到"诊疗型 AI"的范式切换

要理解 AMIE 的价值，得先明白传统医学 AI 评测的病灶在哪。静态题库（比如各类执业考试选择题）本质上是单轮映射：给一段病例描述，选一个答案。模型可以靠模式匹配、关键词联想甚至记忆训练数据拿到高分，但它完全不需要"问"——所有信息都已经喂到嘴边了。真实诊疗恰恰相反，患者走进来第一句话往往是"我肚子不舒服"，信息极度稀疏且噪声极大，医生必须通过一轮轮追问把症状的时间线、诱因、伴随症状、既往史逐步补齐，才能收敛到鉴别诊断。

AMIE 的核心设计目标就是模拟这个"主动获取信息"的过程。它被定位为一个诊断对话系统，输入是患者的主诉，输出不是一句话结论，而是一整套包含追问、鉴别诊断排序、下一步检查建议的诊疗方案。这个定位的转变意味着评测指标也得跟着变：不能只看最终诊断对不对，还要看它问的问题有没有价值、有没有遗漏关键红旗症状、给出的建议是否符合临床路径。

我在实际拆解这类系统时有个习惯：先看它把"什么算成功"定义清楚了没有。AMIE 在这点上做得比较扎实，它把评测拆成了诊断准确性、问诊质量、安全性三个维度，而不是单一准确率。这个拆分本身就说明团队理解临床场景的复杂性——一个诊断对了但漏问了药物过敏史的系统，在真实场景里是危险的。

1.2 目标用户与真实使用边界

需要明确一点：AMIE 这类系统的定位是辅助与分诊，不是替代医生。它的合理使用场景包括基层医疗机构的初步分诊、慢病随访中的症状采集、以及患者教育层面的健康咨询。在这些场景里，系统承担的是"把信息结构化、把风险筛出来、把该转诊的标红"的工作，最终决策权仍在执业医师手里。

这个边界意识非常重要。我见过不少团队在 demo 阶段把系统吹成"AI 医生"，结果一进真实场景就翻车——因为真实患者会描述矛盾信息、会情绪化、会隐瞒病史，而系统如果没有明确的"何时该停下来建议就医"的机制，就容易给出过度自信的错误建议。AMIE 在设计上强调了不确定性表达和转诊触发条件，这是它区别于普通问答机器人的关键。

1.3 为什么这个方向现在才被认真对待

多轮诊疗对话对模型能力的要求是复合的：长上下文记忆（要记住十轮前患者说的"最近在吃某种降压药"）、状态追踪（症状是加重还是缓解）、主动提问策略（下一个问题问什么信息增益最大）、以及医学知识 grounding（鉴别诊断不能瞎编）。这几个能力在过去两年里才逐步成熟到可用的程度。尤其是主动提问策略，它不是简单的"把清单上的问题挨个问一遍"，而是要根据已有信息动态决定下一个最有区分度的问题——这背后涉及信息论里的信息增益思路，也是 AMIE 技术含量最高的部分之一。

2. 核心技术拆解：AMIE 是怎么把问诊做起来的

2.1 长程对话状态管理：别让关键线索在第十轮丢掉

多轮问诊最怕的就是"失忆"。患者第一轮说"我有糖尿病"，到第八轮系统开检查建议时却推荐了含碘造影剂，这就是典型的状态丢失。AMIE 处理这个问题的思路是维护一个结构化的患者状态表示，而不是单纯依赖原始对话历史。

具体来说，系统在对话过程中持续抽取并更新一个类似病历摘要的结构，包含：主诉、现病史时间线、伴随症状、既往史、用药史、过敏史、社会史（吸烟饮酒等）。每一轮新信息进来，先做信息抽取，合并进这个结构化状态，再基于更新后的状态决定下一步问什么。这个设计的妙处在于，它把"记忆"从模型的隐式上下文变成了显式的、可检查的数据结构——出问题时你能定位到底是哪条信息没抽出来，而不是对着黑箱干瞪眼。

实操中这里有个坑：信息抽取本身也会出错，尤其是患者用口语化、模糊表述的时候（"就是那种一阵一阵的疼"）。所以状态更新需要设计冲突检测与确认机制——当新抽取的信息和已有状态矛盾时（比如前面说"没发烧"，后面又说"烧了三天"），系统应该主动澄清而不是默默覆盖。这个细节在论文里不一定写得很细，但落地时是必须补的。

2.2 主动提问策略：下一个问题问什么最值钱

这是 AMIE 最值得研究的部分。传统做法是把某类症状的标准问诊清单（比如腹痛的"部位、性质、程度、诱因、缓解因素、伴随症状"）做成模板挨个问，缺点是机械、冗长，患者体验差且效率低。AMIE 采用的是基于鉴别诊断概率分布的动态提问：先根据主诉生成一个候选诊断列表及其初始概率，然后评估每个候选问题对区分这些诊断的信息增益，优先问区分度最高的那个。

举个具体例子。患者主诉"胸痛"，初始鉴别列表里可能同时有心源性、肺源性、消化道源性、肌肉骨骼源性几大类。此时问"疼痛是否与活动相关"的信息增益远高于问"疼痛具体几分"——因为前者能快速把心源性和肌肉骨骼源性分开，后者对鉴别帮助有限。系统就是靠这种"每次问最能把候选集劈开的问题"来压缩问诊轮次。

这里涉及一个参数设计问题：信息增益的计算需要先验概率，而先验从哪来？常见做法是用流行病学数据做初始先验，再根据患者年龄性别等特征调整。我在复现类似逻辑时发现，先验设置对问诊路径影响很大——如果先验偏得离谱，系统会一直问一些临床上很罕见的方向，浪费轮次。所以实际部署时，先验分布最好能按目标人群（比如社区门诊 vs 三甲急诊）做校准。

2.3 鉴别诊断推理与不确定性表达

问诊收敛之后，系统要输出鉴别诊断排序。AMIE 的做法不是给一个确定答案，而是给一个带概率的排序列表，并对每个候选给出支持证据和反对证据。这个设计在临床上更实用——医生看到"心源性胸痛 0.35，支持：活动后加重、有高血压史；反对：疼痛可自行缓解"这样的输出，比看到一句"可能是心绞痛"有价值得多。

不确定性表达是安全性的关键。系统需要能识别"信息不足以判断"的状态，并明确建议线下就诊或进一步检查，而不是硬凑一个诊断。我特别看重这一点，因为过度自信的错误建议在医疗场景里是有实际危害的。实现上，可以设置一个置信度阈值：当最高候选诊断的概率低于阈值，或前两名概率接近时，触发"建议就医"分支。

2.4 医学知识 grounding：别让模型自由发挥

大模型最大的风险是幻觉，在医学场景里幻觉可能直接导致错误建议。AMIE 在知识 grounding 上做了几层约束：一是把鉴别诊断和检查建议锚定在权威临床指南的知识库上，模型输出需要与知识库条目对齐；二是对药物剂量、禁忌症这类高风险信息做专门校验；三是在生成建议时引用来源依据，方便人工复核。

这套约束的工程实现通常是 RAG（检索增强生成）加规则校验的组合。检索负责把相关指南片段拉进来，规则校验负责拦截明显违规的输出（比如给孕妇推荐禁忌药物）。这里要注意，RAG 的检索质量直接决定 grounding 效果，医学知识库的切分粒度、embedding 模型的选择、召回后的重排序，每一步都得调。我踩过的坑是切分太粗导致检索到的片段包含大量无关信息，反而干扰模型判断。

3. 评测体系：怎么证明它真的"会问诊"

3.1 为什么静态题库不够用

前面提过，静态题库测不出问诊能力。AMIE 的评测采用了模拟患者对话的方式：由另一个模型（或经过训练的标准病人）扮演患者，根据预设的病例脚本回应系统提问，评测系统在有限轮次内能否收敛到正确诊断并给出合理建议。这个设计能同时考察提问质量、信息整合和诊断准确性。

模拟患者的设计本身也有讲究。如果模拟患者太"配合"，有问必答且表述规范，系统会显得很强；但真实患者往往答非所问、表述模糊。所以高质量的评测会让模拟患者带上一定的"噪声"——比如对某些问题给出模糊回答，或主动提供无关信息，看系统能不能处理。这个细节决定了评测结果的可信度。

3.2 评测维度的拆解

我把 AMIE 类系统的评测维度整理成下面这张表，方便对照理解：

需要强调的是，这几个维度不能简单加权成一个总分。一个诊断准确率很高但红旗症状漏检的系统，总分再高也不能上线。实际评估时应该采用"一票否决"式的安全门槛：安全性不达标，其他维度再好也不通过。

3.3 人工评估不可省略

自动评测再完善，也替代不了临床医生的人工评审。AMIE 的评测里包含了执业医师对问诊过程的盲评，重点看几个自动指标测不出来的东西：提问顺序是否符合临床思维习惯、鉴别诊断的排序是否合理、建议的检查是否过度或不足。我个人的经验是，人工评审里最容易暴露的问题是"过度检查"——系统为了保险起见建议一堆检查，看似稳妥，实则增加患者负担和医疗资源浪费。这个倾向在自动指标里往往体现不出来，只有医生一眼能看出"这个检查根本没必要"。

4. 落地实操：从 demo 到可用系统的关键环节

4.1 数据准备与病例脚本设计

要让这类系统跑起来，第一步是准备高质量的病例脚本。脚本需要覆盖常见病、多发病，也要包含一定比例的疑难和急症病例（用于测试红旗识别）。每个脚本应包含：标准主诉表述、完整的现病史要素、既往史用药史、以及标准诊断和推荐处置。

脚本设计的一个实操心得是：主诉表述要多样化。同一个病，不同患者的主诉措辞差异很大（"胸口闷" vs "心口疼" vs "喘不上气"），如果脚本主诉太单一，系统会过拟合到特定表述。我建议每个病例至少准备三到五种不同的主诉变体，覆盖口语化、方言化、模糊化的表达。

4.2 对话流程的状态机设计

虽然底层是大模型，但对话流程最好有一层显式的状态机做兜底。基本状态包括：信息采集、鉴别收敛、建议生成、转诊触发。状态迁移的触发条件要写清楚，比如"当红旗症状命中任一条件，立即迁移到转诊触发状态，跳过后续问诊"。这层状态机的作用是给大模型的自由发挥套上缰绳，保证关键路径不会跑偏。

下面是一个简化的状态迁移伪代码，展示核心逻辑：

def next_state(current_state, patient_state, red_flags): # 红旗优先，任何阶段命中都直接转诊 if red_flags.any_hit(): return "referral" if current_state == "info_gathering": # 关键信息覆盖率达标且鉴别列表收敛，进入建议生成 if patient_state.coverage() > 0.8 and patient_state.ddx_converged(): return "recommendation" return "info_gathering" if current_state == "recommendation": # 生成建议后进入结束或追问澄清 return "closing"

这段逻辑看着简单，但"覆盖率"和"收敛"的判定阈值需要根据实际病例调。阈值设太高会导致问诊轮次爆炸，设太低会漏信息。我的经验是从 0.75 起步，用一批标注病例做网格搜索找平衡点。

4.3 安全护栏的具体实现

安全护栏不是一句口号，得落到具体规则上。我梳理了几类必须硬编码的护栏：

• 红旗症状清单：胸痛伴大汗、突发剧烈头痛、意识改变、持续高热不退等，命中即触发紧急就医建议。
• 药物禁忌校验：输出任何用药建议前，对照患者过敏史和禁忌症表做校验，冲突则拦截并改写。
• 置信度门槛：最高诊断概率低于阈值时，禁止输出确定性结论，改为"建议就医进一步评估"。
• 免责与边界声明：每轮对话结束附上"本建议不能替代面诊"的提示，且系统不处理急危重症的自行处置指导。

这些护栏的实现成本不高，但对系统安全性影响巨大。我见过一些团队把精力全放在提升诊断准确率上，护栏做得敷衍，结果在评审时被一票否决——医疗 AI 的评审逻辑就是这样，安全是入场券，不是加分项。

4.4 参数调优的实操记录

调这类系统时，有几个参数值得重点关注。第一个是问诊轮次上限，设得太高患者不耐烦，太低信息不全，一般建议 8 到 12 轮作为软上限，超过则强制收敛并提示信息可能不足。第二个是鉴别列表长度，输出 Top-5 比较合适，太短可能漏掉正确诊断，太长则稀释重点。第三个是信息增益的折扣因子，用于平衡"问区分度高的问题"和"问临床必问的基础问题"（比如过敏史，信息增益可能不高但必须问）。

我在一次内部测试里把折扣因子调得过于偏向信息增益，结果系统为了区分诊断疯狂追问细节，却漏问了用药史，被评审医生指出"不符合临床习惯"。后来把基础必问项做成硬约束（无论增益高低都必须覆盖），才解决这个问题。这个教训说明，纯优化指标的做法在临床场景里行不通，必须把临床规范作为约束条件嵌进去。

5. 常见问题与排查实录

5.1 系统过早下结论怎么办

这是最常见的毛病。表现是问了两三轮就给出诊断，信息明显不全。排查思路：先看状态机的收敛判定是不是太松（覆盖率阈值太低），再看鉴别列表的初始概率是不是过于集中（先验设置问题）。解决办法通常是提高收敛门槛，并在提示词里明确要求"在关键鉴别信息缺失时不得给出确定性诊断"。

5.2 追问的问题重复或跑偏

重复提问往往是因为结构化状态没更新成功，系统"忘了"已经问过。排查时打印每轮的状态快照，看信息抽取有没有把患者的回答正确合并进去。跑偏则多半是信息增益计算出了问题，或者候选诊断列表本身就不对——如果初始鉴别方向就错了，后面问的问题自然全歪。这时候要回头检查主诉解析和初始鉴别生成环节。

5.3 患者表述模糊时系统卡壳

真实场景里患者经常说"就是不舒服""说不上来"。系统如果只会按模板追问，就会陷入僵局。解决办法是设计引导式追问：当开放性问题得不到有效信息时，转为封闭式选项（"是胀痛、刺痛还是烧灼痛？"），降低患者表达门槛。这个技巧在老年患者和低健康素养人群里尤其管用。

5.4 常见问题速查表

5.5 几个容易被忽视的坑

第一个坑是多语言和方言适配。主诉表述的地域差异极大，同一症状在不同地区有完全不同的说法，如果训练和测试数据集中在标准表达上，真实场景的召回会明显下降。第二个坑是对话中断恢复。真实问诊可能被患者中途打断、离开再回来，系统需要支持从结构化状态恢复对话，而不是从头再来。第三个坑是隐私与数据合规，问诊数据涉及敏感健康信息，存储、传输、脱敏的每个环节都得按规范来，这块在 demo 阶段最容易被忽略，上线前补起来代价很大。

6. 我对这类系统落地的一点判断

AMIE 代表的方向是对的——把医学 AI 从"答题机器"推向"会问诊的助手"，这个转变抓住了临床场景的真实需求。但从技术成熟度看，它目前更适合做分诊和结构化采集，而不是独立诊断。我在实际接触类似系统的过程中体会最深的一点是：决定这类系统能不能用的，往往不是模型多强，而是护栏做得多细、评测做得多严、边界划得多清。一个诊断准确率 85% 但红旗漏检率 5% 的系统，在医疗场景里是不合格的；反过来，一个准确率 75% 但从不漏红旗、从不给危险建议的系统，反而有落地价值。

后续如果要在这个方向上继续深挖，我觉得有两个值得关注的点：一是个性化问诊策略，不同年龄、不同健康素养的患者需要不同的提问方式，一刀切的策略体验和效果都受限；二是与真实临床工作流的整合，系统输出的结构化病历能不能直接进电子病历系统、能不能减少医生的录入负担，这才是决定它能不能被真正用起来的关键。技术指标再漂亮，如果嵌不进工作流，最终也只是论文里的数字。