医疗问诊录音转写：Fun-ASR结合专业热词提升精度

医疗问诊录音转写：Fun-ASR结合专业热词提升精度

在三甲医院的呼吸科门诊，一位医生每天要接诊超过30名患者。每位患者的问诊时间平均为15分钟，全天累计产生近8小时的语音记录。这些录音原本需要护士或实习生逐字听写成电子病历，耗时费力且容易出错——尤其是面对“β受体阻滞剂”、“肺动脉楔压”这类专业术语时，非医学背景人员几乎无法准确识别。

这正是当前医疗信息化进程中的一个缩影：语音数据海量增长，但信息提取效率却严重滞后。直到最近，随着大模型驱动的定制化语音识别技术成熟，这一瓶颈才开始被真正打破。其中，钉钉联合通义推出的Fun-ASR系统，凭借其独特的“热词增强+ITN规整+批量处理”三位一体能力，在多个医院试点中实现了从“能听清”到“听得懂”的跨越。

---

传统通用语音识别系统在医疗场景下的表现往往令人失望。它们可以流畅地识别日常对话，但在遇到专科术语时频频“翻车”：“冠状动脉造影”变成“关壮动脑造影”，“阿司匹林肠溶片”被误识为“阿斯匹林长容片”。这种级别的错误不仅影响病历质量，更可能误导后续的临床决策支持系统。

根本原因在于，通用ASR的语言模型训练语料主要来自新闻、社交媒体和公开演讲，医学文本占比极低。而重新训练整个模型以适配医疗领域，成本高、周期长，且难以应对不同科室的专业差异。于是，一种无需微调即可实现快速领域迁移的技术路径变得尤为关键——这就是热词引导解码（Hotword Biasing）的价值所在。

Fun-ASR的核心突破之一，正是将热词机制深度集成到端到端模型的解码过程中。它不需要改动模型参数，而是通过在束搜索（beam search）阶段动态调整候选路径得分，使指定词汇获得更高的生成概率。比如，当系统检测到音频中出现类似“gao xue ya”的发音时，如果“高血压”已被设为热词，即使声学特征略有偏差，该词仍会被优先选中。

这个过程听起来简单，但在工程实现上却有不少门道。我们曾在某心血管科部署时发现，尽管已添加“青霉素”和“庆大霉素”作为热词，系统仍频繁混淆两者。排查后才发现，问题不在模型，而在热词列表本身——两个药物名称音节结构高度相似，若同时启用反而会相互干扰。最终解决方案是采用分阶段识别策略：先用宽泛热词（如“抗生素”）定位类别，再结合上下文进行细粒度区分。这也提醒我们，热词不是越多越好，精准控制才是关键。

实际应用中，一个典型的心血管科热词库可能包含以下内容：

血压 心率 心电图 冠状动脉 支架植入 β受体阻滞剂 房颤 射血分数 他汀类药物 随访

只需将这些词汇以纯文本格式上传至Fun-ASR的WebUI界面，系统即可在下次识别中自动强化这些术语的识别权重。整个过程无需编程，也不影响已有模型运行，非常适合医院信息科这类缺乏AI研发团队的单位快速落地。

当然，仅靠热词还不足以构建完整的医疗语音处理流水线。另一个常见问题是数字与日期的表达混乱。患者说“我今年二零二五年查出来血糖高的”，系统若原样输出“二零二五年”，虽然语义正确，却不利于后续结构化分析。理想情况是将其自动转换为“2025年”，并与年龄、检查时间等字段对齐。

这就引出了Fun-ASR的第二项关键技术：文本规整（Inverse Text Normalization, ITN）。ITN模块专门负责将口语化的数字、单位、缩写等还原为标准书写形式。例如：

口语表达	规整结果
两千零二十五年	2025年
六十八岁	68岁
三点五克	3.5g
下礼拜三	下周三

这项功能看似细微，实则极大提升了下游系统的可用性。我们在对接某医院HIS系统时就深刻体会到：数据库字段要求严格的数据类型匹配，若年龄字段填入“六十八”，会导致统计报表异常；而启用ITN后，所有数值均以阿拉伯数字输出，完全规避了此类问题。

更进一步的是，Fun-ASR支持通过API方式灵活调用这些功能。对于希望将语音识别嵌入自有平台的医疗机构，可以直接集成其服务接口。以下是一个典型的调用示例：

import requests response = requests.post( url="http://localhost:7860/api/transcribe", json={ "audio_path": "/data/patient_001.mp3", "language": "zh", "hotwords": ["高血压", "糖尿病", "复诊", "药物过敏"], "enable_itn": True } ) result = response.json() print("原始文本:", result["text"]) print("规整后文本:", result["itn_text"])

这段代码虽短，却构成了自动化语音处理流水线的基础。它可以部署在服务器端，定时扫描新录入的音频文件，完成识别后自动推送至电子病历系统，真正实现“无人值守”式运转。

然而，单个文件处理只是起点。真正的挑战在于规模化——如何高效处理数十甚至上百个问诊录音？手动一个个上传显然不现实。为此，Fun-ASR提供了完整的批量处理功能。

使用流程非常直观：运维人员只需将所有音频文件拖入WebUI的指定区域，选择统一的语言、热词配置和输出格式，点击“开始处理”即可。系统后台会自动建立任务队列，依次完成识别，并实时显示进度条和当前处理的文件名。全部完成后，结果可导出为CSV或JSON文件，便于导入数据库或做进一步分析。

在某三甲医院的实际测试中，60个平均长度为12分钟的门诊录音，在配备NVIDIA T4显卡的服务器上仅用不到2小时即全部处理完毕，整体吞吐率达到0.6x实时速度。相比之下，人工听写同样体量的内容至少需要10小时以上。更重要的是，批量模式确保了所有文件使用相同的识别参数，避免了因操作失误导致的结果不一致问题。

当然，要让这套系统稳定运行，还需注意一些细节设计。首先是文件命名规范。我们建议采用“患者ID_日期_科室.mp3”这样的格式，例如P20250401_20250401_Respiratory.mp3，这样不仅便于后期检索，也能防止重名覆盖。

其次是音频预处理。过长的录音（如超过30分钟）可能导致内存溢出或识别延迟。推荐的做法是先使用VAD（Voice Activity Detection）技术切分有效语音段，剔除长时间静音部分。Fun-ASR内置的VAD模块可自动完成这一任务，显著提升处理效率。

此外，本地部署模式也为数据安全提供了保障。所有音频和识别结果均存储于院内服务器，不会上传至公网，完全符合《个人信息保护法》和《医疗卫生机构网络安全管理办法》的要求。我们建议定期备份history.db数据库文件，并设置访问密码限制非授权操作。

从系统架构上看，Fun-ASR很容易融入现有的医疗信息化生态：

[医生手机录音] ↓ (MP3/M4A) [本地服务器 - Fun-ASR] ↓ (结构化文本) [EMR/HIS系统] ↓ [病历归档 / 临床分析]

前端由医生自由录制，中台集中处理，后台自动填充主诉、现病史、用药记录等字段。整个链条无需人工干预，大幅减轻医护人员文书负担。

值得一提的是，热词库的建设应具备科室针对性。内分泌科关注“胰岛素泵”、“糖化血红蛋白”，而骨科则更需要“椎间盘突出”、“关节置换术”等术语。我们建议各科室建立专属热词表，并根据临床指南更新动态维护。有医院甚至开发了“热词贡献系统”，鼓励医生上报识别失败案例，持续优化词库质量。

回头来看，Fun-ASR的价值远不止于“语音转文字”。它实质上是在构建一种新型的医疗语言理解基础设施——通过轻量级配置而非重型模型训练，快速适应不同专业场景的需求。这种思路尤其适合中国医疗体系：三级医院科室细分、基层机构资源有限，亟需低成本、高适配的技术方案。

未来，随着更多专科语料的积累，或许可以进一步引入上下文感知的动态热词机制。例如，在识别到“心脏”相关词汇后，自动激活心血管领域的子词库；或者结合电子病历中的既往诊断，提前加载患者常用药品名称。这些进阶功能将进一步缩小机器与人类医生在语义理解上的差距。

眼下，这项技术已在住院查房记录、远程会诊纪要、医学生教学录音等多个场景展开试点。它的意义不仅是提高效率，更是推动医疗服务从“经验驱动”向“数据驱动”转型的关键一步。当每一次问诊都能被精准捕捉并转化为结构化知识，智慧医疗的图景才真正有了落地的支点。