医疗信息化圈子里最近大半年聊得最多的必然是“大模型在医疗场景里到底怎么落地”。很多人第一反应是做个对话机器人可真放进生产环境才发现聊天只是最外层的东西真正的难点是把它接入到门诊、住院、随访的主流程里同时还要保证回答质量、数据安全和一线医护的使用体验。我做过的某三甲妇儿专科医院数字医生项目属于比较典型的人机共智方案让模型处理预问诊、知识查询、随访触达这类高重复、标准化的工作让医生继续掌握诊疗决策的最终解释权。它没有追求全自动而是把人和机器的能力边界划得很清楚。这套数字医生上线后日活咨询量稳定在几千人次其中大量是孕产妇和儿童家长的常规问题。模型实时调取院内知识库回答遇到超出范围的提问自动转人工。医生工作台每天收到AI生成的预问诊结构化摘要和可能的诊断线索整条流程有一层人机互认的校验环节。下面我把这个项目的设计思路、技术选型、功能落地和踩坑过程逐一拆开说清楚。1. 第一刀先切在哪里场景与需求的取舍1.1 门诊数据倒逼出来的选择启动这个项目之前团队最常被问的一句话是大模型在医院能做什么。市面上能想到的答案很多辅助诊断、病历生成、患者教育、科研检索样样听起来都很有价值但样样都铺开做结果大概率是什么都做不成。所以我们定了一个原则不按功能去找场景而是按业务痛点去切场景。当时院方给出的核心痛点是门诊咨询量太大、重复度太高。妇幼专科有一个典型特点就是孕产妇和儿童家属的常规问题特别多“产检报告这个指标是不是偏高”“孩子发烧要不要立刻来医院”“出院后黄疸怎么观察”这些问题占掉分诊台和医生诊间大量时间。很多问题临床指南里有明确答案只是患者不知道去哪查、查到了也看不懂。这类需求天然适合大模型来做因为它的表达能力强、可以多轮追问、能把专业内容翻译成普通患者听得懂的话同时又能把回答来源挂到知识库里避免凭空发挥。另一个倒逼因素是夜间和节假日咨询的缺口。不少患者晚上突然焦虑打电话不方便在线又没人即时回应。传统聊天机器人只能给固定话术遇到复杂问题就卡死。大模型最大的增量价值在于它能处理开放式提问同一个问题换个问法也接得住。于是项目范围很快收敛成三块智能预问诊、诊后随访、基于知识的患者咨询再加一块辅助医生决策的线索提示。前三块面向患者最后一块面向医生构成人机共智的完整闭环。1.2 人机共智不等于AI全自动很多甲方一上来就希望AI能自己完成问诊、自己给诊断结论这样医生就轻松了。这个想法听起来很美好但放在医疗场景里非常危险。疾病的诊断依赖体征、检验、影像和医生的临床经验光靠对话很难覆盖所有变量而且一旦AI给出错误判断责任归属也说不清楚。所以我们把“人机共智”定义成三层协同第一层是机器接管信息采集和普及性解释。患者跟数字医生对话AI负责收集主诉、既往史、过敏史、用药情况然后生成结构化病历摘要患者问“这个药饭后吃还是饭前吃”AI直接从药品知识库调取说明并做通俗化解释不需要医生介入。第二层是机器提供线索医生负责确认。AI根据预问诊结果生成初步考虑方向和下一步建议但系统里所有带“可能诊断”的内容都要经过医生确认后才出现在正式记录中。推送形式类似“AI工作台提醒”医生可以一键采纳、修改或忽略操作成本很低但决策权始终在医生手里。第三层是机器做全量随访和提醒医生只处理异常反馈。系统按病种规则生成随访任务定时触达患者回收恢复情况只有出现智能预警指标时才把病例推送给医生。这样既扩大了随访覆盖面又不会给医生增加额外负担。这三层关系明确了后面所有设计和开发都不会跑偏。2. 支撑数字医生的架构设计与模型选型2.1 分层架构里每层解决什么问题整个系统分成四层来搭数据层、模型层、应用层和交互层。数据层是基础也是最花时间的部分。医院的知识源很分散临床指南、诊疗规范、药品说明书、院内自制的健康宣教手册、既往病历脱敏样本。这些材料格式不统一有PDF、Word、Excel还有扫描图片必须先做清洗和结构化。我们把材料按科室、病种、内容类型打上标签切成适合检索的片段再同步到向量数据库和搜索引擎里。这一步做到什么程度直接决定后续回答质量的天花板。模型层是核心跑了两类模型一类是大语言模型负责对话理解、意图识别、文本生成和结构化输出另一类是Embedding模型负责把知识片段和用户问题转换成向量供检索使用。另外还接入了语音识别模型为不方便打字的家长提供语音输入能力。这里要特别强调Embedding模型的质量经常被忽略但它在RAG链路里和主模型同样重要选不好检索出来的知识就是驴唇不对马嘴。应用层承上启下封装了统一问诊引擎、知识检索服务、结构化输出服务和人工复核接口。所有对话请求先经过问诊引擎判断当前对话阶段再决定调用检索还是直接生成。人工复核接口连接医生工作台AI生成的内容不会直接落库而是要等医生确认或修改后才变成有效记录。交互层相对简单包括患者端的微信小程序、医生工作台的插件、随访短信链接等。这块的难点不在技术而在产品细节比如字号、颜色、按钮位置错误提示语气都会影响患者愿不愿意用下去。2.2 RAG让模型先查再说医疗场景里最不能接受的就是模型胡编。大模型虽然知识面广但训练语料和院内真实规定之间一定存在偏差更别说很多院内规范更新后模型根本不知道。所以我们从一开始就确定所有涉及诊疗和用药的回答必须先走检索增强生成也就是RAG不允许模型仅凭自身记忆直达答案。RAG的基本链路是用户输入问题、系统把问题转成向量、从知识库检索TopK相关内容、把检索结果和原始问题一起塞进提示词、模型基于这些材料生成回答。实际使用中我们还会在检索前加一步查询改写。因为患者说话比较口语化“娃儿拉肚子两天了要不要吃蒙脱石”这种问题直接拿去检索效果不好要先把关键词补全成“儿童腹泻 蒙脱石散 用药建议”再做向量检索。检索结果还要加相关性判断不能拿到什么就用什么。我们设置了一个相关性打分阈值分数不够就认为知识库没有覆盖系统会走兜底话术回答说“这个问题需要更专业判断建议预约门诊或咨询在线医生”。这一步看似简单却把幻觉大幅降下来。后来统计走了RAG的回答引用来源可追溯的比例接近九成剩下的二重Biz部分主要靠兜底和人工接管来解决。2.3 模型选型和部署上的安全碰撞模型选型是整个项目里争议最多的事。选项大致有两个方向调用外部成熟大模型接口或者本地私有化部署。外部接口的效果确实更好、迭代更快但医疗数据出院的合规压力、网络依赖和成本模型都让人犹豫。本地部署的优势是数据可以全程留在院内方便做审计也能按业务需求灵活调整劣势是初期硬件投入高且模型能力需要自己调优。我们最后采用的是“本地化部署为主外部接口兜底”的混合模式。面向患者的主流程全部走院内集群保证医疗数据不出院一些非敏感的场景比如健康科普文案生成允许调用外部接口来提高生成质量。模型选择上主对话模型用了开源的中大型模型Embedding模型和语音识别模型也都选了开源版本。这么做不是因为开源一定更好而是院内团队能拿到模型权重推理过程出了问题有地方排查也不会被单一供应商绑住。推理部署上用的容器化加多副本平时跑4到8卡高峰期自动扩容到16卡。模型推理的并发能力和响应速度是一对矛盾控制并发数才能避免显存溢出但排队时间又会变长。我们通过一个简单的滑动窗口控制在患者体感不明显的前提下把单次请求响应时间压在一到三秒。这里有一个经验别把大模型当成普通API来压测它的Token输出是逐步生成的实际并发能力比预估低很多必须预留资源余量。3. 三个核心功能从设计到落地3.1 智能预问诊从混乱对话到结构化病历智能预问诊是第一个上线的功能目标很明确患者进入诊间之前系统已经把主诉、现病史、既往史、过敏史、月经婚育史这些信息收集完整医生坐下来只看摘要就能开始判断。设计上难点在对话管理。患者陈述症状时往往没逻辑先说最难受的又跳到几天前的事中间还可能夹杂情绪。模型要能在这种混乱对话里做两件事一是多轮追问补全关键信息比如“阵痛大概是几分钟一次”“昨天最高体温多少”二是自动把对话内容映射到预设的病历字段。这两件事都需要用结构化的方式定义清楚。我们在提示词里放了明确的输出格式要求让模型以JSON格式输出结构化结果避免自由发挥。给一个简化的示例{ chief_complaint: 发热伴咳嗽3天最高体温38.5℃, present_illness: 3天前无明显诱因出现发热以夜间为著…, past_history: 既往体健否认手术外伤史, allergy_history: 否认药物及食物过敏史, followup_needed: [ 咳嗽是否伴有痰液, 近期接触过发热人群吗, 是否服用过退热药物 ], initial_impression: [ 急性上呼吸道感染可能, 需排查流感等传染病 ] }这里面的“followup_needed”就是模型自己判定的待追问问题程序解析后会继续发起下一轮对话。返回的“initial_impression”不会直接出现在病历里只是推送给医生作参考。临床医生前期比较排斥AI生成的判断但当他们发现AI的定向其实只是一个引导思路、不替代结论时接受度反而逐渐高了。预问诊的另一个细节是退出机制。患者可能在对话中途不耐烦或者已经挂完号从线上转到线下。系统要在每一轮对话结束都保留草稿患者随时可以退出下一次进来继续也能选择直接跳过不给患者制造必须做完的压力。3.2 诊后随访和健康宣教让知识跑在正确的时间点上如果说预问诊是“诊前”那随访就是“诊后”。做完检查或者出院的患者后续恢复情况没人跟踪一直是医院的痛点。传统人工随访根本覆盖不了全部患者只能抽查高风险人群。数字医生把这个空白补上了。随访流程是这样设计的医生开单时选择随访模板系统当天生成第一版随访任务按时间线自动给患者发消息。以产科出院后的随访为例第一天询问出血量、体温、精神状态第三天提醒新生儿黄疸观察方法第七天推送产后恢复注意事项和情绪自评量表。每一条随访消息都是从院内知识库生成并由对应科室医生审核过模板之后才上线的。这里面的技术难点不是推送本身而是异常识别。患者在回复里说“今天伤口有点红”、系统不能只回复一句“建议保持清洁”就结束要能判断这可能是感染征兆自动把对话升级到紧急提醒并提示患者尽快就诊同时把这条记录标记为黄色标签推送给护士站人工关注。我们用了一套分级响应规则轻度问题由知识库回答中度问题给出观察建议并预约复诊入口重度异常直接触发人工电话联系。这套机制把大模型的判断能力和医学规则很好地结合了起来比单纯让模型自己处理更稳。3.3 辅助决策线索医生工作台里的“AI提示”外科医生听感最敏感的莫过于让他用AI做诊断。所以这块功能的定位不是替代医生写诊断而是帮医生扫一遍AI生成的提示把有用的留下、没用的删掉。整个交互做得非常克制医生打开病历页右侧栏出现一条“AI参考”列出患者主诉、关键症状、可疑诊断方向和鉴别要点每条参考都挂着知识来源医生可以展开看原文也可以一键收藏到自己的专属学习库。实现上这条侧边栏内容由大模型基于预问诊结构化结果加检验数据生成再用规则引擎过滤掉明显不合理的建议。规则引擎里有几条硬性红线比如未成年人不开成人口径的用药建议、孕产妇不推荐无循证依据的检查、急性重症倾向必须急诊就诊。这些规则不是模型学出来的是临床专家手工配置的属于“机器跑得再快也不能越界”的护栏。这个功能上线后意外地提升了医生满意度。原因是它帮医生省下了阅读长预问诊摘要的时间同时把容易遗漏的鉴别诊断放在眼前。实际口径上我们也做得很清楚AI参考只出现在医生本人工作台不出现在患者端不作为最终诊断依据所有记录的采纳和修改都可追溯。4. 试点、评估与迭代的真实玩法4.1 选科室先看场景不只看人情项目最怕一开始就铺到全院所以我们第一波只在两个门诊科室试点一个是产科门诊一个是儿童内科门诊。为什么选这两个因为它们的患者咨询重复度最高、标准临床路径最明确而且模型早期只做预问诊和宣教不碰高风险诊断风险相对可控。试点科室选完还要做一件事跟科室主任和一线医生深度访谈把他们的顾虑提前消解掉。医生最常问的问题是“这系统出错谁负责”我们统一口径AI只是辅助正式医疗行为由医生完成系统所有输出都带“供参考”字样的标识再问就是“会不会增加我工作量”我们用数据说话预问诊摘要直接填充到病历模板里医生只要确认修改整体时间是节约而不是增加。试点阶段还有一个容易被忽略的凶险点用真实患者数据做模型优化必须格外小心。我们所有用于构建评估集的病历都做了脱敏姓名、身份证、手机号、地址全部替换成模拟信息而且只在脱敏后的样本上做模型调优绝不拿原始数据直接喂提示词。4.2 回归测试集锁住模型质量的下限医疗场景不能拿“感觉还行”来评判模型必须有一套可量化的验收标准。我们组织临床专家和算法工程师一起构建了一个“黄金评估集”包含一千多对问答和对应的评分标准。每对包含输入问题、标准答案、参考答案来源和评分维度评分维度分为准确性、完整性、安全性、表达友好度四个方向。每次升级模型、调整提示词或者扩充知识库都要先跑一遍这个评估集。用脚本批量请求数字医生接口再把回答导出交给标注团队打分准确率超过阈值才允许上线。这个流程后来成了项目组的雷打不动制度虽然每次跑全量要花一两个小时但拦下了很多看似微小实则致命的问题。重点说一个指标安全性。准确率再高也不能容忍一条可能误导患者用药的回答出现。我们专设了一个高危问题集里面只放容易出事的题目比如“孕妇能吃不”“儿童用量多少”“是不是癌”。这些题目的正确率必须满分否则整个版本上线就得叫停。这套高标准也反过来逼着团队不断优化检索逻辑和兜底策略。4.3 运营指标不能只看“AI答了多少”评估模型是一回事评估整个数字化服务又是另一回事。团队在立项时就定下来看四类运行指标服务覆盖率、解决率、转人工率、人工介入成本。服务覆盖率看的是有多少门诊量走了预问诊流程一开始只有三成稳定后推到八成以上解决率看的是患者咨询里有多少能由数字医生完成闭环完成闭环的定义是患者不再追问或者追问转化成预约挂号而不是系统里聊两句就丢转人工率是安全红线观察是否出现了模型不能处理的场景人工介入成本则统计医生每份病历因为AI摘要节省出来的时间。对比组设计上我们用同一科室同一病种做前后对照而不是随机分患者组因为随机分组涉及患者体验不均医院伦理审查会难过。前后对比虽然会引入一些干扰因素但从运营视角看已经足够说明趋势数字医生上线后科室平均预问诊填写时间从五分钟缩短到两分钟随访完成率提升了一倍以上医护团队的线上重复咨询量明显下降。4.4 迭代的节奏算法、知识库、产品三位一体系统上线后不是结束反而是迭代工作的开始。每周会有一轮回溯例会临床人员、产品经理和算法工程师坐在一起看上周的badcase。每次筛选出大概两三种典型问题比如某个回答过于保守、某个药品说明改版后知识库没跟上再决定是改提示词、改知识库、还是调模型。知识库更新频率比想象中要高得多。院内制度、药品说明书、门诊流程一调整知识库就得同步。我们建了一个知识库发布管理系统更新内容先走临床审核审核通过后形成新版本部署推送到检索服务旧版本自动归档。所有回答里的引用来源都是知识库里的具体片段ID一旦版本更新引用也会跟着回溯后续如果出现纠纷可以精准定位到是哪一版知识造成的。模型本身的迭代反而不需要太频繁。预训练模型每半年升级一次但日常质量提升主要靠提示词模板和检索策略的调整。这两者的调优成本低、见效快适合小步快跑。5. 这些坑我替大家先踩过了5.1 幻觉不是玄学是没有兜底机制最开始测试时模型确实会在回答里混入“看起来合理但没依据”的内容。有次患者问“一岁孩子能不能喝蜂蜜水”模型居然顺着上下文回答“适量可以”实际上婴幼儿摄入蜂蜜有肉毒杆菌风险这是明确的禁忌。这个case当时把团队吓出一身冷汗。后来把所有回答都改成了“先检索再回答”的模式并且加了三层兜底第一层是知识库检索相关性过滤查不到相关内容就不许回答第二层是高危问题强制转人工自动识别包括“孕妇、儿童、中毒、急救”这类高危关键词直接给预案第三层是回答末尾固定展示“以上信息仅供科普参考不能替代面诊建议”。三层兜底上了以后再没出现类似的高危错误。这个教训可以一句话总结大模型本身并不可怕可怕的是你把所有信任都交给它。5.2 患者情绪复杂时要让它学会慢下来还有一类问题不是医疗知识性的而是情绪性的。一些患者反复追问并不是想得到一个标准答案他真正需要的是“有人重视我这件事”。那个阶段我们发现模型如果单纯追求效率会在几次问答之后就给出“请及时就诊”的终止话术给患者的感受非常冷漠容易变成投诉来源。针对这个问题我们在提示词里加入了共情引导要求让模型先确认患者感受比如“听起来您比较担心宝宝的黄疸情况”再给出处理建议。同时增加了一道情绪识别服务模型判断患者表述中包含焦虑、恐惧、情绪激动等信号时会切换成更温和的表达并主动询问是否需要转到人工在线客服。这个细节看上去很小对患者满意度的影响却很大。5.3 审计与权限不能等出了事再补医疗系统里最难的不是算法而是权限和审计。刚开始我们觉得数字医生只是信息服务访问控制简单做就行结果信息科在验收时提了一长串整改意见所有AI调用要记录完整日志、问题文本要先脱敏再作为优化样本、不同角色只能访问不同功能模块、模型后台要屏蔽session关联信息。这些需求一开始没设计的话后期返工成本极高。整改后我们落地了一套权限体系患者端只能访问自己的对话记录医生端能看到患者授权后的数据运营分析人员只拿到脱敏统计结果模型优化工程师仅能访问Quota脱敏样本库。所有对话的请求参数、返回内容、处理状态全部落日志保留周期按院内数据管理规定执行。这套体系虽然增加了开发量但它让数字医生项目在合规审查时真正站得住脚。5.4 并发和延迟的控制要留足余地技术上线前的压测数据很好看并发两百没问题但真到门诊高峰期模型推理服务经常被老百姓的咨询量打成热点。后来分析原因是患者访问有明显的高峰期集中在早上九到十一点和下午二到四点并发模型预估完全失准。我们重新做了按时间段的扩缩容策略高峰期前二十分钟预热扩容门诊结束后自动缩容同时给模型推理服务加了队列长度告警太长就直接让前端弹“当前咨询量大建议稍后再试”避免用户傻等超时。另一个容易踩的坑是流式输出和超时控制。患者端使用打字机式逐字输出体验好但超时出错的概率也高我们最后做了折中按句输出不按字输出也就是检测到模型生成了一个标点符号就推送一句这样既保留了流畅感又减少了前端频繁渲染的压力。这个细节做与不做的差异技术人员在真机上一试就知道。6. 最后的一点私货体会把这个项目做完我的体会是医院场景做AI其实是在跟“安全感”打交道。患者要安全感医生要安全感信息科要安全感。大模型能力再强如果不能让系统里每个角色都感觉到边界清晰、责任明确、退路充足项目就很难走远。所以我在每次面对新技术都会问一个问题它到底在帮人做决策还是帮人做选择人机共智的意义不在于用AI替代任何人而在于把人的时间和注意力释放出来放到真正需要人的地方。如果你也在筹划类似的项目我会建议从预问诊和随访这种低风险、高重复的场景切入先跑通数据链路和协作机制再往里走。千万别一上来就做一个“万能AI医生”那样只会让所有人都害怕它。技术选型上优先考虑本地化部署和RAG这能解决一半以上的合规和幻觉问题。迭代上把评估集建好比调一万次模型参数都管用。我自己最满意的一个设计其实是那条“AI参考只出现在医生侧并且永远可以被一键删除”的规则。因为它让医生这张专业王牌始终握在自己手里。