对话式诊断系统AMIE：从主诉到鉴别诊断的对话机制与评测体系

医学问诊这件事，长期以来有个尴尬的现实：患者描述症状是模糊的、跳跃的、带情绪的，而医生的诊断推理是结构化的、收敛的、讲证据的。这两者之间的鸿沟，靠一个医学院读八年的人去填，成本极高。大模型进来之后，很多人第一反应是"让模型直接回答医学问题"，但真正难的不是答题，是问诊——也就是在信息不完整的情况下，主动追问、逐步收敛、最后给出鉴别诊断思路。AMIE 这个项目瞄准的正是后者。它不是一个"医学知识问答机器人"，而是一个面向诊断对话的对话式诊断系统，核心能力是模拟临床问诊的完整流程：采集病史、追问细节、形成鉴别诊断、给出检查建议。这篇文章我会从它的设计动机、对话机制、评测方式、落地边界几个角度拆开讲，适合对大模型在垂直领域落地感兴趣的开发者、医疗信息化从业者，以及想理解"对话式诊断"到底难在哪的读者。

1. 为什么"会答题"的模型做不了问诊

1.1 医学问答和诊断对话是两件不同的事

先把一个常见误解掰开。市面上大量所谓"医疗大模型"，本质是在做静态问答：给一段病例描述，让模型输出诊断或建议。这类任务的数据形态是"输入完整信息、输出结论"，模型只需要在已有信息上做归纳。但真实问诊是动态信息采集过程——患者一开始给你的信息往往只有三成，剩下的七成要靠医生一轮轮追问挖出来。

这个差别决定了能力要求完全不同。静态问答考的是知识覆盖和推理准确性；诊断对话考的是主动提问的策略：什么时候该问伴随症状，什么时候该问既往史，什么时候该问用药情况，什么时候该建议做检查而不是继续问。问错方向，后面全盘皆输。AMIE 的设计出发点就是把"提问策略"当成一等公民来建模，而不是把问诊简化成一次性的文本生成。

我在实际接触这类系统时有个很深的体会：一个模型能背下整本内科学，不代表它能在一个只说"我肚子疼"的患者面前问出有价值的东西。前者是检索，后者是决策。

1.2 诊断对话的三个硬约束

把问诊拆开看，它至少受三重约束，这也是 AMIE 这类系统必须正面处理的难点。

第一是信息不对称。患者不知道什么信息对诊断有用，所以不会主动提供。模型必须承担"信息引导者"的角色，用患者能听懂的话去问，而不是甩专业术语。

第二是对话长度与效率的平衡。问得越细，信息越全，但患者耐心有限，真实门诊平均问诊时间也就十几分钟。系统不能无限追问，必须在有限轮次内收敛到有意义的鉴别诊断。

第三是安全边界。诊断对话的输出直接影响人的健康决策，模型不能给出确定性结论式的诊断，只能给"可能性排序 + 建议进一步检查"这种留有余地的表达。这个约束不是技术问题，是产品红线。

提示：任何面向真实用户的诊断对话系统，输出层都必须做"不确定性表达"的强制约束，把"你得了X病"改写成"这些症状提示需要排查X，建议做Y检查"。这不是保守，是基本要求。

1.3 AMIE 想解决的核心问题定位

综合来看，AMIE 的定位可以概括成一句话：在模拟的临床对话环境中，完成从主诉到鉴别诊断的完整推理链。它要证明的不是"模型懂医学知识"，而是"模型能像医生一样组织一次问诊"。这个定位决定了它的技术路线必须围绕对话策略、诊断推理、评测体系三块来搭，而不是单纯堆医学语料做继续预训练。

理解了这层定位，后面看它的对话机制和评测设计就顺了——所有设计都是为"问诊"这个动作服务的。

2. AMIE 的对话机制拆解：从主诉到鉴别诊断

2.1 诊断对话的状态机模型

要理解 AMIE 怎么工作，最直观的方式是把它看成一个带状态的对话系统。整个问诊过程可以抽象成几个阶段的状态迁移：起始（接收主诉）→ 信息采集（追问）→ 假设生成（形成候选诊断）→ 假设验证（针对性追问或建议检查）→ 收敛（输出鉴别诊断与建议）。

关键在于，这个状态机不是线性的。模型在采集信息的过程中会不断生成和推翻假设，某个追问可能让原本排在前面的诊断被排除，也可能让一个没被考虑的罕见病浮上来。AMIE 的对话策略本质上是在这个状态空间里做搜索：每一步选择"问什么"或"建议什么"，都要最大化对当前鉴别诊断集合的信息增益。

用生活化的类比：这就像一个侦探办案，手头有几个嫌疑人（候选诊断），每问一个问题都是为了排除或锁定某个嫌疑人。问"你最近有没有发烧"可能一下子排除掉一半嫌疑人，问"你家里养不养猫"可能只对某一个罕见病有意义。好的问诊就是每一步都问"性价比最高"的那个问题。

2.2 追问策略：信息增益优先还是流程优先

这里有个设计上的取舍值得展开。真实医生的问诊往往遵循系统化流程：先问现病史（起病时间、部位、性质、程度、诱因、缓解因素），再问伴随症状，再问既往史、用药史、家族史。这套流程是医学院训练出来的，好处是不容易漏项，坏处是效率不一定最优。

另一种思路是信息增益优先：每一步都问当前最能区分候选诊断的那个问题。这种策略效率高，但可能显得跳跃，患者体验上会觉得医生"东问一句西问一句"。

AMIE 这类系统通常会在两者之间做混合：用系统化流程保证不漏关键项，用信息增益排序决定同一阶段内问题的优先级。我在看这类系统的对话日志时发现，纯信息增益策略在模拟环境里表现很好，但一旦面对真实用户，流程感缺失会让人产生不信任——患者会觉得"这医生怎么不按套路来"。所以实际落地时，流程骨架不能丢，优化的是骨架内的填充顺序。

2.3 鉴别诊断的生成与排序逻辑

鉴别诊断是问诊的产出物。AMIE 在这一步的做法，通常不是让模型直接"生成"一个诊断列表，而是先构建候选集，再对候选集做排序和证据标注。

候选集的来源有两块：一是模型内部医学知识召回的常见病，二是基于当前症状组合触发的"红旗征"关联（比如某些症状组合提示必须排查的急重症）。排序则依赖证据匹配度——每个候选诊断对应一组典型表现，模型把已采集到的患者信息和这组表现做匹配打分，得分高的排前面。

这个过程中有个容易被忽略的细节：阴性证据的价值。患者说"没有发烧"，这不是没信息，而是排除了大量感染性疾病。好的诊断系统必须能利用阴性发现做排除，而不是只盯着阳性症状。AMIE 在对话中会显式记录"已确认不存在"的信息，用于后续排除逻辑，这一点在实现上很关键——很多简易系统只记阳性，导致鉴别诊断列表臃肿。

2.4 对话中的不确定性处理

医学对话里到处都是不确定："有点疼"、"大概三四天"、"好像有点烧"。模型必须能处理这种模糊表达，而不是要求患者给出精确数值。

处理方式一般分两层。第一层是容忍模糊：把"有点疼"映射到一个疼痛等级区间，把"三四天"映射到时间范围，继续往下问，不卡在这里。第二层是主动澄清：当模糊信息影响关键判断时，用患者能回答的方式追问，比如"这个疼是像针扎一样，还是像被压着那种闷疼"，把主观描述转成可分类的选项。

这个能力看着不起眼，实际是诊断对话能不能跑通的分水岭。我见过不少系统在模拟数据上表现很好，一上真实对话就崩，原因就是模拟数据里的症状描述太"标准"了，真实患者不会那么说话。

3. 评测体系：怎么判断一个模型"会问诊"

3.1 为什么传统医学QA benchmark不够用

判断模型医学能力，常见做法是跑医学考试题。但考试题考的是"给定完整题干选答案"，和问诊能力几乎正交。一个模型医学考试满分，完全可能在患者说"我头晕"的时候直接开始背头晕的鉴别诊断清单，而不会先问"是天旋地转的晕还是昏昏沉沉的晕"——这一个问题就能把鉴别方向劈成两半。

所以 AMIE 这类项目必须自建评测体系，核心是把"问诊"这个动作拆成可打分的维度。这也是我认为这个项目最有参考价值的部分：它示范了怎么给一个开放式对话任务设计评测。

3.2 模拟患者与自动评分的设计

主流做法是引入模拟患者（由另一个模型扮演），给定一个隐藏的"真实病例"，让被测系统通过对话去采集信息、给出诊断，最后比对诊断结果和问诊过程质量。

评分维度通常包括几块：

这套体系里，模拟患者的设计是难点。模拟患者要足够"像人"——会模糊描述、会答非所问、会有情绪，否则测出来的分数虚高。同时它又要足够"可控"——必须严格守住隐藏病例的信息边界，不能自己编造症状。这两个要求本身就有张力，实际实现时通常要给模拟患者加严格的角色约束和事实校验。

3.3 自动评分的可靠性边界

自动评分能解决规模化评测的问题，但它的可靠性有边界，这点必须说清楚。用模型给模型打分，存在评分漂移和偏好同质化的风险：评分模型可能偏爱某种表达风格，导致被测系统去迎合评分器而不是提升真实能力。

比较稳妥的做法是自动评分加人工抽检双轨。自动评分负责大样本筛选和回归测试，人工抽检负责校准评分标准和发现系统性偏差。我在类似项目里见过一个典型问题：自动评分对"问诊轮次少"给了高分，结果系统学会了少问问题直接猜诊断，短期分数好看，实际能力退化。这类指标间的博弈，必须靠人工介入才能发现。

注意：任何用模型做评分的评测体系，都要定期做"评分器与被测系统解耦"的检查，防止两者形成共谋式的分数虚高。

4. 落地边界：AMIE 能做什么、不能做什么

4.1 它擅长的是"结构化问诊"而非"自由聊天"

把能力边界划清楚很重要。AMIE 这类系统在有明确问诊目标的结构化对话里表现最好：患者有明确主诉，系统按诊断逻辑推进，最后产出鉴别诊断。这种场景下它的优势是稳定、不漏项、能利用阴性证据。

但它在开放式健康咨询里就没那么从容了。比如用户上来问"我最近总觉得累，是不是身体出问题了"，这既可能是问诊起点，也可能是情绪表达，还可能是想聊生活方式。系统如果强行进入问诊状态机，会显得机械。真实产品里，这类模糊入口需要先做意图澄清，再决定是否进入诊断流程。

4.2 真实临床环境里的合规与责任问题

技术之外，落地最大的门槛是责任界定。诊断对话系统的输出如果被用户当成诊断结论，出了问题是系统性风险。所以实际部署时，输出层必须明确"这是辅助信息，不替代面诊"，并且对高风险症状（胸痛、意识改变、剧烈头痛等）设置强制转诊提示。

这块没有技术捷径，只能靠产品设计兜底：把系统定位成"问诊信息整理与鉴别方向提示工具"，而不是"AI医生"。定位清楚了，功能设计和话术设计才有依据。

4.3 从研究原型到可用产品的差距

研究环境里的 AMIE 是在模拟对话中评测的，模拟患者再像人，也和真实患者有差距。真实场景里的噪声包括：方言、错别字、语音转文字的误差、患者中途换话题、多轮之后忘记前面说过的信息。这些在评测集里很难完全覆盖。

我的判断是，这类系统从原型到产品，中间最大的一块工作是对话鲁棒性工程：处理输入噪声、维护长对话的上下文一致性、在用户跑题时优雅地把话题拉回问诊主线。这些工作不性感，但决定了产品能不能用。

5. 给想复现或借鉴这套思路的人几点实操建议

5.1 先搭评测，再调模型

如果你要做一个类似的诊断对话系统，我的建议顺序是反直觉的：先把模拟患者和评分体系搭起来，再去优化对话策略。原因很简单，没有评测，你根本不知道改一个追问策略是变好还是变坏。诊断对话的优化空间太大，凭感觉调参必然迷失。

搭评测时，模拟患者的病例库要覆盖常见病、多发病、以及少量必须识别的急重症。每个病例配一份"关键信息清单"，明确哪些信息是诊断必需的，这样信息采集完整性才有得打分。

5.2 对话策略从规则骨架起步

不要一上来就指望模型自己学会最优问诊策略。更稳的做法是先写一个规则骨架：按现病史、伴随症状、既往史的顺序定义问诊阶段，每个阶段内用模型做问题生成和优先级排序。规则骨架保证不漏项和流程感，模型负责灵活性和表达自然度。等评测体系跑顺了，再逐步让模型接管更多决策。

5.3 阴性证据和红旗征要单独建模

前面提过阴性证据的价值，这里再强调一次实现层面的事：对话状态里要显式维护三张表——已确认阳性发现、已确认阴性发现、待确认项。鉴别诊断排序时三张表都要用上。红旗征则要单独做一套触发规则，一旦命中就跳出常规问诊流程，直接给转诊建议。这两块是安全性和准确性的关键，不能指望模型隐式处理。

5.4 输出层的不确定性表达要模板化

最后一点，输出鉴别诊断时，别让模型自由发挥措辞。用固定模板："根据目前信息，需要排查的方向包括A、B、C，其中A的可能性相对较高，建议进一步做X检查以明确。"模板化的好处是表达可控、不会越界、用户理解成本低。模型负责填内容，模板负责守边界。

我在实际做这类系统时最深的一个体会是：诊断对话的难点从来不在"模型知不知道"，而在"模型会不会问"。知识可以灌，问诊策略得靠评测驱动一点点磨出来。AMIE 这类项目的价值，与其说是展示了一个能问诊的模型，不如说是把"怎么评测问诊能力"这件事摆到了台面上——后者对整个垂直领域大模型的落地，参考意义更大。