庭审笔录离线转写翻车实录：法院信息科最不想看到的 5 个坑_灵声智库_语音识别本地部署

上周接到一个电话，是某中级人民法院信息科的老张，语气里带着那种混合了委屈和愤怒的疲惫感：

"我们花了半年搞这套庭审转写系统，上线第一天，审判长就拿着一份转写稿找我——'被告人'变成了'被告任'，'质证'转成了'致证'，就这个水平，你让我怎么给院长交代？"

这不是孤例。我走访过的几家地市级法院，庭审 ASR 项目的上线后投诉率，普遍比医疗和金融场景高。原因很简单：庭审场景的语音条件，比任何教科书上的测试集都要糟糕。

坑一：把"说话人分离"当开箱即用功能

法庭里同时说话的人，少则 3 人（审判长、公诉人、辩护人），多则超过 8 人。法庭吊顶麦克风阵列收进来的是混响严重的全场混音，而不是一条条干净的单声道。

很多厂商演示时用的是两人对话的"理想双声道录音"。但在法庭实战中，这个差距足以让说话人标注（Speaker Diarization）从 90% 的演示准确率直接跌到 60% 以下——也就是说，笔录里近一半发言搞不清楚是谁说的。

建议动作： 选型时强制要求厂商使用你们真实庭审录音的前 10 分钟片段做现场测试，直接看说话人分离结果，不接受"线下优化后再测"的说辞。

通用大模型在司法词汇上的识别率，远低于厂商宣传的"99% 准确率"——因为那个数字是在普通话对话数据集上测出来的。法律词汇的词频极低，模型对它们的权重天然不足。

建议动作： 部署前必须要求厂商提供针对司法场景的专有热词库（至少涵盖《刑法》《民事诉讼法》核心词汇），且支持法院本地二次扩展。

各地法院用的庭审管理系统（TMS）版本差异极大，有的是最近两年采购的云平台，有的是十年前定制开发、基于 WebService + SQL Server 中间表的"古董"。

我见过最离谱的情况：某法院的 TMS 输入框每次只能接收 50 个汉字的字符串，ASR 一次性推送长句直接溢出，页面崩溃，书记员还以为是电脑病毒。

系统对接风险评级：

建议动作： 实施前必须向院方索要 TMS 的接口文档或数据库表结构，不要轻信厂商"我们对接过很多法院，没问题"的口头承诺。

大量地市级法院目前正处于"信创改造"周期，服务器要求采购国产 ARM 芯片（如飞腾、鲲鹏）或 x86 国产替代（如海光、兆芯）。

同一套 ASR 模型，在 Intel Xeon 上运行实时率（RTF）可能达到 0.3，但迁移到飞腾 2000+ 之后，RTF 直接跌到 1.5 以上——也就是说，转写速度比实际庭审更慢，完全无法满足"同步记录"的要求。

原因在于：模型的底层算子（Operator）是否针对 ARM 指令集（特别是 NEON/SVE 扩展）进行过专项编译优化。 这不是简单安装一下软件能解决的问题。

建议动作： 必须要求厂商在你们实际采购的信创服务器型号上做 RTF 基准测试，数值 < 0.5 才算基本可用。

这是信息科最痛的一刀，但也是最容易被忽视的。

庭审系统上线半年后，ASR 引擎厂商"技术支持"的响应时间从两小时变成了两天，从两天变成了"等我们排期"。而法院信息科人员少，对 ASR 引擎内部没有排查能力，一旦出问题，书记员只能手工记录，系统形同虚设。

合同条款必须明确的 3 条： 1. 本地化交付后，法院信息科人员是否能独立完成热词库更新，无需厂商介入。 2. 模型版本升级时，是否提供超过 3 个月的老版本过渡期，防止接口变更破坏已有对接。 3. 服务器宕机时，是否提供 48 小时内到场的驻场支持承诺。

不适合上马离线庭审 ASR 的情况： - 法院 TMS 未完成信创改造，对接接口完全不透明。 - 全院日均庭审不足 5 场，人工书记员效率仍然可以覆盖。 - 没有 1 名具备基本 Linux 运维能力的信息科技术人员，后期无人维护。

如果你现在就要启动项目，建议的第一步不是招标，而是先用 3 个真实庭审录音片段，找 2 家以上厂商做盲测对比，把结果带回来再做决策。