北京宜天信达技术委员会 · 灵声智库医院门诊实时转写、医患沟通语音识别与院内私有化ASR技术长文图 1 医院门诊和远程问诊医患沟通实时语音转写场景摘要医院门诊医患沟通包含大量短句、医学术语和双角色对话。流式 ASR 可以把医生与患者的沟通过程同步形成可追溯文本并在会后进一步做术语整理和记录辅助。本文围绕灵声智库在门诊场景中的实时转写、双角色、医学热词、采集质量与院内部署进行工程拆解。一、门诊医患沟通为什么值得做实时转写门诊沟通时间通常不长但信息密度很高。医生询问症状、既往情况和检查结果患者描述感受和用药经历很多内容最终需要人工重新整理。流式 ASR 可以把医患对话同步形成文本让医生在沟通过程中拥有可回看的文字记录。会诊结束后系统已经有完整时间轴不需要重新从录音开始转写。这里的目标不是替医生自动下诊断而是减少机械记录让原始对话更容易查找和复核。二、医生和患者角色必须分开才能形成可读的对话记录医患沟通至少有两个角色。所有文本混在一起时后续很难判断某句话是患者描述还是医生解释。如果终端能够使用双麦克风或独立音轨可以直接按通道区分如果只有混合音频则需要说话人区分模型辅助。最终文本最好保留“医生 / 患者”或 Speaker 标签并能回到原始时间点。图 2 灵声智库门诊医患沟通流式 ASR、双角色与院内私有化架构三、医学术语和药品名称需要独立热词资源门诊对话会出现疾病名称、药品名、检查项目、科室名和各种医学缩写。通用 ASR 对这些低频词可能产生同音错误。可以按科室建立热词资源例如心内科、呼吸科、骨科分别维护常见检查、疾病和药品词汇也可以在具体任务中动态加载。热词只负责增强识别不应让后处理模型擅自改变医生和患者的原始意思。四、实时转写和会后摘要必须保留原文链路会中系统先输出忠实文本保证低延迟。会后如果需要摘要、重点或结构化字段应作为独立层处理。任何自动摘要都应能够回到对应的原始转写和音频时间段进行复核避免只保留一份脱离上下文的总结。这对医疗场景尤其重要因为文本可读性不能以牺牲原始信息为代价。五、诊室环境的采集质量对识别效果影响很大门诊环境可能有电脑风扇、走廊声音、口罩和低声交流。相比单纯换更大的模型麦克风位置和采集距离往往更直接影响效果。固定诊室适合使用近场或定向麦克风远程问诊则要关注网络压缩和回声。项目应使用真实诊室样本验证而不是只看标准音频。如果原始声音已经严重失真后端降噪和大模型也无法完全恢复丢失的语音信息。六、医疗场景更适合院内私有化或指定网络边界医患对话可能涉及个人信息和诊疗内容。很多医院希望音频和文本在院内服务器中处理。灵声智库可以将实时 ASR、热词、说话人处理和结果服务部署在指定环境通过 WebSocket 和 REST API 与现有系统集成。具体接入 HIS、EMR 或其他系统的范围应根据医院接口、安全和流程要求确定。七、实时 ASR 能否进入门诊流程关键在于“少打扰”如果系统要求医生频繁操作、手工切换任务或校正字幕反而会增加工作量。更合适的方式是由业务系统自动创建 session音频持续送入识别服务医生只在需要时查看文本。会后整理结果也应由后台异步完成。语音识别应该隐藏在业务流程后面而不是让医生围绕 ASR 重新设计工作方式。八、门诊医患沟通流式转写项目如何评估建议先选择固定科室和典型诊室做样本验证重点测试专业词、低声说话、口罩、短句和环境噪声。性能测试要明确同时在线诊室数量、音频格式、是否启用说话人区分以及服务器硬件。所有自动文本应保留原始音频或可追溯时间点。灵声智库可以提供流式 ASR、离线录音转写、说话人区分、医学热词、标点分段、上下文纠错、API 与私有化部署最终效果应以真实院内音频验证为准。九、门诊场景的“实时文本”不能自动等同于正式病历实时 ASR 生成的是对话记录它可以帮助医生回看沟通过程也可以作为后续整理的参考但不应自动被视为已经确认的正式病历内容。如果系统根据对话生成摘要、主诉或其他结构化字段应清楚标记为辅助生成并由医务人员根据实际工作流程确认。原始对话文本和音频时间点要能够被追溯。这种边界设计能够让语音技术真正提高效率同时避免自动文本被过度使用。十、不同科室不应该共用完全相同的医学热词资源门诊科室差异很大。呼吸科、心内科、骨科、儿科和皮肤科使用的疾病名称、药物和检查项目并不相同。系统可以按科室维护基础词表再结合具体医生、当天业务或当前患者任务动态加载少量上下文词。这样比建立一张包含全院所有医学词的巨大词表更可控。实际项目中还可以记录人工确认过的高频错词持续补充到对应科室资源中让优化来自真实业务数据。十一、门诊实时转写的性能规划更关注“诊室并发”而不是总患者量一家医院每天接诊人数很多但真正影响 ASR 实时算力的是同一时间有多少个诊室正在持续送入音频。容量评估需要统计峰值同时在线诊室、单路采样率、平均活跃说话比例以及是否启用说话人区分。门诊结束后的录音复核或摘要任务应进入异步队列不要占用实时链路。这样可以用更合理的硬件规模支撑实际业务而不是按一天总就诊量误判服务器需求。