九大ASR模型方言场景实战横评

引言

ASR（Automatic Speech Recognition）在标准普通话场景下早已"卷无可卷"，各家模型的准确率都在 95% 以上。但一旦进入真实的生产场景——方言、多人对话、情绪起伏、背景音乐、歌唱片段交织——模型之间的差距便暴露无遗。

本文选取一段 128 秒的四川方言剧集音频，同时调用 9 个主流 ASR 服务（豆包、Fish Audio、FunASR、Gemini、OpenAI Whisper、Paraformer、Qwen、腾讯云、讯飞），再加上一个自研的多模型融合方案，从识别准确率、说话人分离、情感检测、方言适应性、输出结构化程度五个维度进行实战对比。

一、评测设计

1.1 测试音频

属性	描述
来源	四川方言剧集片段
时长	128.85 秒
说话人数	3-4 个主要角色（男性旁白/男主、女性摊贩、男性路人）+ 歌曲演唱
语言特征	四川方言为主，含普通话、歌唱片段
内容场景	知青返乡叙事 → 街边买蛋烘糕 → 警察追逐 → 歌曲穿插

这段音频几乎集齐了 ASR 的所有难点：

方言词汇："知青返乡"、"蛋烘糕"、"半托半托"、"老汉儿"、"好久到"
快速说话人切换：买蛋烘糕场景中买卖双方的密集对话
情绪变化：从伤感叙事到欢快讨价、再到紧张逃跑
混合内容：对话与歌唱交替出现，模型需区分语音和音乐

1.2 测试框架

我们搭建了统一的 ASR 测试 CLI，通过 Provider 抽象屏蔽各厂商 API 差异：

class ASRProvider(ABC):
    name: str = "base"
    input_type: str = "url"  # url / file / gcs

    @abstractmethod
    def transcribe(self, audio_input: str, **kwargs) -> dict:
        ...

所有 Provider 实现 transcribe() 接口，返回各自原始 JSON 结果。本次测试使用的模型版本如下：

模型	具体版本/预设
豆包	`asr_spk_semantic` preset
Fish Audio	默认模型
Gemini	`gemini-3.1-pro-preview` *
OpenAI	`gpt-4o-transcribe-diarize`
Qwen	`qwen3-asr-flash-filetrans`
腾讯云	`16k_zh` 引擎
讯飞	转写 API，`speaker_number=0`（盲分）
Paraformer	`paraformer-v2`（DashScope 云端）
FunASR	`paraformer-zh` + `fsmn-vad` + `ct-punc` + `cam++`

* Gemini 3.1 Pro 是 Google 2026 年 3 月最新版本，官方称推理能力大幅升级（ARC-AGI-2 得分翻倍至 77.1%），但未专门提及音频/语音识别方面的改进。

通过 CLI 一键切换模型：

python test_asr.py -m doubao  -i audio.wav  # 豆包
python test_asr.py -m fish    -i audio.wav  # Fish Audio
python test_asr.py -m gemini  -i audio.wav  # Gemini
python test_asr.py -m qwen    -i audio.wav  # Qwen

1.3 评测维度

维度	说明
识别准确率	核心指标，以方言关键词和整体语义通顺度衡量
说话人分离	能否正确区分多个说话人（Speaker Diarization）
情感检测	是否支持语音情感识别及准确度
输出结构化	字级/句级时间戳、置信度、语言检测等元信息丰富度
方言适应性	对四川方言特有词汇、语气词的处理能力
歌曲/BGM 处理	对话与歌唱交替时的区分和处理能力

1.4 评判方法论

Ground Truth 来源

本文没有使用学术界常见的 WER（Word Error Rate）指标——因为这段方言音频不存在标准转写文本。我们的 Ground Truth 通过以下方式建立：

人工反复听写：由熟悉四川方言的人员对照原片（含视频画面上下文）逐句听写，确定"知青返乡"、"蛋烘糕"、"半托半托"等关键词的正确性
多模型交叉验证：当多个独立模型对同一片段输出一致文本时，可信度更高（如"大学生有机会回城"被 6 个模型一致输出）
人工确认三个基准事实：豆包在覆盖区间内文本最准（方言词命中率最高）、Fish 综合文本质量最高（覆盖最全且方言词准确）、腾讯云时间轴精度最高（与豆包一致且覆盖更广）

这三个基准事实是后续所有对比和融合策略的前提。

多样本验证

本文以第 6 集作为主要分析样本展开详细拆解。同时我们在其他多集（均为豆包存在大段空白的集数）上做了同样的多模型对比，核心结论一致：

豆包方言最准但覆盖不全的模式稳定复现
Fish 覆盖率始终最高，时间戳后段漂移在不同集均出现
腾讯云时间轴精度始终可靠

单集深度拆解 + 多集一致性验证，确保本文结论不是"恰好在这一段上成立"的偶然现象。

二、各模型详细评测

2.1 豆包（Doubao）— 字节跳动

调用方式：火山引擎 API，preset=asr_spk_semantic

功能矩阵：说话人分离 ✓ | 情感检测 ✓ | 性别识别 ✓ | 字级时间戳 ✓ | 语言检测 ✓

豆包是本次评测中功能最丰富的模型。每个 utterance 附带 speaker ID、emotion（含 degree 和 score）、gender（含 score）、字级时间戳：

{
  "additions": {
    "emotion": "sad",
    "emotion_degree": "weak",
    "emotion_score": "0.709",
    "gender": "male",
    "gender_score": "0.997",
    "speaker": "1"
  },
  "text": "三年前的时候，我知青返乡，我那个大学生有机会回城。"
}

准确率分析：

方言核心词识别准确：

原文	豆包识别	判定
知青返乡	知青返乡	✓
蛋烘糕	—（未覆盖）	—
老汉儿	老汉儿	✓
肚皮都要饿瘪了	肚皮都要饿瘪了	✓
职工抓到要遭处分	职工抓到要遭处分	✓

识别了 6 个说话人，情感标注覆盖 sad、happy、neutral、angry、surprise 五种。全局语言检测结果为 lid_lang: "singing_mand"（歌唱普通话），说明模型意识到了音频中的歌唱内容。

关键缺陷：豆包在 22s～68s 的蛋烘糕购买场景完全空白，丢失了近 46 秒的内容。这是一段快速对话、多人交叉说话的片段——正是实际业务中最需要的高信息密度区间。

小结：豆包"能力全面但覆盖不全"——在它识别到的区间内表现优异，但长段落的空白是致命硬伤。

2.2 Fish Audio

调用方式：Fish Audio SDK，本地文件输入

功能矩阵：说话人分离 ✗ | 情感检测 ✗ | 字级时间戳 ✓

Fish Audio 输出结构极简——全文 text + 字级 segments，没有说话人、情感等元信息。但它在内容覆盖率上表现最佳：

能不能买半个？
哎，你这跟出去耍两个样！
我恁个便宜蛋烘糕，半托半托卖呀！
走嘛！
哎，你不买嘛，你早点说嘛！
弄都弄好了，都卖不出去了，来收！

豆包完全空白的蛋烘糕购买场景，Fish 捕获了完整的讨价还价对话。方言关键词识别也相当准确：

原文	Fish 识别	判定
蛋烘糕	蛋烘糕	✓
半托半托	半托半托	✓
知青返乡	自己返乡	✗
快了	坏了	✗

关键缺陷：

无说话人分离、无情感信息。对于需要区分"谁在说话"的业务场景，Fish 无法独立使用。
时间戳后半段严重漂移。逐句对比发现，Fish 在前 17 秒与豆包时间戳一致，但 20 秒后开始漂移，越往后偏差越大：

句子	Doubao 时间	Fish 时间	偏差
好多钱一个呀	0:20-0:21	0:20-0:24	Fish end +3s
五分钱一个	0:21-0:22	0:24-0:28	Fish +3s
谢谢你啊	1:16-1:17	1:08-1:10	Fish 早 7s
你叫啥子名	1:20-1:20	1:10-1:10	Fish 早 10s
警察来了…处分	1:20-1:23	1:12-1:22	Fish 单字跨 8.6s

这意味着 Fish 的时间戳只在前段可信，后半段不可用，融合时只能取文本不能信时间戳。

小结：Fish 是"内容覆盖之王"——几乎不漏句，方言词准确率高，但缺少结构化元信息，且时间戳后半段严重失准。

2.3 Gemini — Google

调用方式：Gemini 多模态 API（gemini-3.1-pro-preview），通过 prompt 引导输出 JSON

功能矩阵：说话人分离 ✓ | 情感检测 ✓ | 性别识别 ✓

Gemini 的调用方式最为特殊——不是传统的 ASR 服务，而是将音频作为多模态输入，通过 prompt 让大模型"听写"：

response = self.client.models.generate_content(
    model=self.model_name,
    contents=[
        types.Content(parts=[
            types.Part.from_uri(file_uri=audio_input, mime_type="audio/wav"),
            types.Part.from_text(text=prompt.user),
        ])
    ],
    config=types.GenerateContentConfig(
        system_instruction=prompt.system,
        response_mime_type="application/json",
    ),
)

文本准确率：灾难级

Gemini 在转写文本上产生了严重的幻觉（Hallucination）：

实际内容	Gemini 输出
我知青返乡	我四处犯相
老汉儿，好久到奶奶家哦	老汉儿早就断了来往
吃啥子？想吃啥子味道的？	在这，在这，在这，喂点点
好多钱一个呀？五分钱一个	好香哦 / 我喂狗狗
蛋烘糕	大红高粱
能不能买半个	怎么没得包包肉

Gemini 不仅内容错误，还虚构了完整的对话情节——把买蛋烘糕的场景"理解"成了喂狗抢食。LLM 的"补全"本能在这里成了毒药。

但 Speaker Diarization 意外优秀

Gemini 在文本上全面失败，但在说话人分离和情感标注上反而是所有模型中最好的：

维度	Gemini 表现	对比
说话人数	3 人（男主=0, 女摊贩=1, 路人=2）	最准确——实际主要角色就是 3 人
人物一致性	Speaker 0 始终是男主旁白，Speaker 1 始终是女摊贩	豆包 6 人体系存在过度分裂
情感粒度	neutral / sad / happy / annoyed / surprised / angry	唯一有"annoyed"细粒度的模型
输出段数	30 个 utterance，语义完整	分段边界最合理

这揭示了 LLM-as-ASR 的一个有趣特性：LLM 的"语言理解"能力让它在语义层面的标注（谁在说话、什么情绪、句子边界）上优于纯声学模型，但它的"听写"能力（将声音准确转为文字）远不如专业 ASR。

小结：Gemini 是一个矛盾体——文本转写不可用（幻觉严重），但说话人分离和情感标注是全场最佳。在融合方案中，它的价值不在文本，而在 speaker 映射和情绪标签（详见第四章）。

2.4 不推荐组：OpenAI / Paraformer / FunASR

将这三个模型归为一组的原因很明确：方言关键词命中率均为 0/5（判定标准为完全一致，音近但语义不同的如"蛋很糕"不计入），且各自在功能上都无法弥补准确率的短板。简要列出关键问题：

OpenAI Whisper（gpt-4o-transcribe-diarize）— 无标点、无时间戳、无说话人信息，输出仅裸文本。方言关键词几乎全错："辞职返乡"、"大秋生"、"蛋红糕"、"五文钱"。需要说明的是，OpenAI Whisper 在英文和中英混读场景通常表现优秀，本文的结论仅限纯方言场景。

Paraformer v2（阿里云百炼，paraformer-v2）— FunASR 的云端版本。有字级时间戳和说话人分离（2人），但方言词错误严重："芒果啊"(半个)、"蛋很糕"(蛋烘糕)、"啊，警跑抓"(警察来了)。后半段出现乱码"从没告。诉候起不及你当"。更关键的问题是时间戳是均匀插值（word 间隔恒定~264ms），不反映真实语速，在配音场景不可用。

FunASR（阿里开源，本地部署）— 完全离线，paraformer-zh + fsmn-vad + ct-punc + cam++ 四件套。方言识别最差："自制返箱"、"蛋黄糕"、"芒果"。唯一优势是免费、可私有化部署，适合数据安全要求高但只处理普通话的场景。

2.5 Qwen ASR — 阿里百炼

调用方式：DashScope REST API，qwen3-asr-flash-filetrans，异步文件转写

功能矩阵：说话人分离 ✓ | 情感检测 ✓ | 语言检测 ✓ | 字级时间戳 ✓

Qwen ASR 是本次评测中综合表现最均衡的模型。它同时支持情感检测和语言自动识别，准确率在方言场景下也保持了较高水平：

原文	Qwen 识别	判定
蛋烘糕	蛋烘糕	✓
能不能买半个	能不能买半个	✓
半托半托（半坨半坨）	半坨半坨	✓
知青返乡	自己返乡	✗
五分钱	五块钱	✗
职工抓到要遭处分	只顾抓的要找菜的	✗

Qwen 在蛋烘糕场景的核心词汇上全部正确——这在 9 个模型中相当难得。歌曲片段的歌词识别也较为准确。

不足之处在于说话人分离只区分了对话（speaker_id=0）和歌唱（speaker_id=1）两大类，未能细分多个说话人。部分尾部句子出现了方言理解错误。

小结：Qwen ASR 是"性价比之选"——准确率优秀，功能齐全，适合不需要精确说话人区分的场景。

2.6 讯飞 — 科大讯飞

调用方式：讯飞开放平台转写 API，支持说话人分离参数（speaker_number）

功能矩阵：说话人分离 ✓（但本次失败） | 情感检测 ✗ | 字级时间戳 ✓ | 语速检测 ✗

讯飞的输出以 sentence 为单位，每个 sentence 包含 bg/ed（起止毫秒）、speaker、onebest（识别文本）以及 word 级时间戳（单位 0.01 秒）：

{
  "bg": 200,
  "ed": 9650,
  "onebest": "三年前的时候我知青返乡，我那个大学生有机会回城，那个时候我带起我女儿身上一分钱都没得，",
  "speaker": 0,
  "words": [
    {"word": "知青", "wp": "n", "wb": 220, "we": 263},
    {"word": "返乡", "wp": "n", "wb": 264, "we": 352}
  ]
}

准确率分析：

讯飞在方言核心词上的表现与豆包并列第一：

原文	讯飞识别	判定
知青返乡	知青返乡	✓
大学生有机会回城	大学生有机会回城	✓
好多钱一个呀	好多钱一个呀	✓
五分钱一个	5分钱一个	✓
蛋烘糕	蛋烘糕	✓
半坨半坨	半坨半坨	✓

九个模型中，只有讯飞和豆包能正确识别"知青返乡"这个高区分度方言词，说明讯飞的方言声学模型确实有深厚积累。蛋烘糕场景的核心词也全部命中。

关键缺陷：

分段极粗：129 秒音频仅分为 7 个 sentence，最长的一段 26 秒（9.99s→36.37s），包含了完整的蛋烘糕购买场景——对话、情绪变化、说话人切换全部压缩在一句里。这种粒度完全无法用于字幕或配音。
说话人分离完全失败：所有 7 个 segment 的 speaker 均为 0，未区分任何说话人。
后半段文本乱码：歌曲片段出现了"Cui美"、"yoyo不行"等明显的识别错误，说明模型在音乐场景下的鲁棒性不足。
无情感检测。

小结：讯飞是"方言之王但分段废了"——在方言词汇准确度上与豆包并列顶级，但 7 段的分割粒度和失败的说话人分离，让它在生产场景中无法独立使用。如果未来讯飞改善分段粒度，将是非常强力的方言 ASR 选项。

2.7 腾讯云 ASR

调用方式：腾讯云录音文件识别 API，16k_zh 引擎，异步任务模式

功能矩阵：说话人分离 ✓ | 情感检测 ✓ | 语速检测 ✓ | 字级时间戳 ✓

腾讯云的输出结构最为丰富——除了常规的说话人分离和情感检测，还额外提供了语速（SpeechSpeed） 指标：

req.SpeakerDiarization = 1   # 开启说话人分离
req.EmotionRecognition = 2    # 开启情感识别
req.ResTextFormat = 3         # 最详细的输出格式

识别了 4 个说话人，情感覆盖正常。方言关键词表现：

原文	腾讯云识别	判定
蛋烘糕	蛋烘糕	✓
半头半头（半托半托）	半头半头	✓
知青返乡	返校	✗
职工抓到要遭处分	自动炸弹要找	✗

后半段出现了明显的识别混乱："荡漾在你肩膀现我心头的有你了1"——歌唱片段中数字"1"的出现说明模型将歌词与其他信号混淆。0:54-1:14 区间有一个 20 秒的混段（对话和歌词混在一起），分段粒度在此处失控。

亮点发现：腾讯云有一个被低估的优势——时间戳精度与豆包完全一致，且覆盖了豆包丢失的蛋烘糕场景，同时自带 speaker 信息。此外，腾讯的分段粒度是所有模型中最细的（逗号级），这在字幕制作场景中非常有价值。

小结：腾讯云的文本准确度不算顶尖，但它真正的价值在于精准的时间轴 + speaker + 高覆盖率。在三模型融合方案中，腾讯云是空白区间的"时间轴骨架"提供者（详见第四章）。

三、横向对比

3.1 功能对比

能力	豆包	Fish	FunASR	Gemini	OpenAI	Paraformer	Qwen	讯飞	腾讯云
说话人分离	✓(6人)	✗	✓(4人)	✓(3人)	✗	✓(2人)	✓(2类)	✗(全0)	✓(4人)
情感检测	✓	✗	✗	✓	✗	✗	✓	✗	✓
性别识别	✓	✗	✗	✓	✗	✗	✗	✗	✗
字级时间戳	✓	✓	✓	✗	✗	✓	✓	✓	✓
语言检测	✓	✗	✗	✗	✗	✗	✓	✗	✗
语速检测	✗	✗	✗	✗	✗	✗	✗	✗	✓
离线部署	✗	✗	✓	✗	✗	✗	✗	✗	✗

3.2 方言关键词识别对比

以 5 个高区分度的方言词作为基准：

关键词	豆包	Fish	FunASR	Gemini	OpenAI	Paraformer	Qwen	讯飞	腾讯云
知青返乡	✓	✗	✗	✗	✗	✗	✗	✓	✗
蛋烘糕	—	✓	✗	✗	✗	✗	✓	✓	✓
半托半托	—	✓	✗	✗	✗	✗	✓	✓	✓
老汉儿	✓	✓	✗	✗	✗	✗	✗	✗	✗
职工…处分	✓	✗	✗	✗	✗	✗	✗	✗	✗
命中率	3/3	3/5	0/5	0/5	0/5	0/5	2/5	3/5	2/5

豆包和讯飞的"—"表示该段落未覆盖（不是识别错误），因此以覆盖区间内的准确率计算。讯飞虽然分段极粗，但覆盖了全部关键词区间。

3.3 时间戳精度对比

纸面上的功能列表不能说明一切。我们对 Doubao、Fish、Tencent、Qwen、讯飞五个表现较好的模型做了逐句时间窗口对比，结果出乎意料（讯飞因分段过粗仅参与部分对比）：

前段（0:00-0:17）— 四者一致

内容	Doubao	Tencent	Qwen	Fish
三年前…返乡	0:00-0:06	0:00-0:06	0:00-0:03	0:00-0:06
大学生…没得	0:06-0:09	0:06-0:09	0:04-0:09	0:06-0:09
老汉儿…饿瘪了	0:09-0:14	0:09-0:14	0:09-0:14	0:09-0:14
吃啥子+想吃啥子	0:15-0:17	0:15-0:17	0:15-0:17	0:15-0:17

蛋烘糕场景（0:33-0:54）— Doubao 全丢，其余三者一致

内容	Doubao	Tencent	Qwen	Fish
能不能买半个	—	0:33-0:35	0:33-0:34	0:33-0:34
蛋烘糕半坨半坨卖	—	0:38-0:40	0:38-0:40	0:38-0:40
走嘛	—	0:42-0:43	0:43-0:43	0:43-0:43
你不买嘛	—	0:47-0:50	(漏识)	0:47-0:50
弄都弄好了	—	0:51-0:52	(漏识)	0:51-0:54

蛋烘糕场景中，Tencent 和 Fish 时间戳高度一致；Qwen 漏掉了"你不买嘛你早点说嘛弄都弄好了"三句（0:47-0:52）。

后半段（1:08-1:23）— Fish 严重漂移

内容	Doubao	Tencent	Qwen	Fish
来小心来	1:08-1:08	—	1:08-1:08	1:01-1:08
谢谢你啊	1:16-1:17	1:16-1:17	1:09-1:16	1:08-1:10
警察来了…处分	1:20-1:23	1:20-1:22	1:20-1:25	1:12-1:22

后半段结论一目了然：Doubao ≈ Tencent >> Qwen > Fish。Fish 的时间戳在 1 分钟后偏差达到 7-10 秒，完全不可用。Qwen 的 "谢谢你" 首字从 1:09 跨到 1:16（7 秒），也存在异常。

时间戳精度总结

维度	Doubao	Tencent	Qwen	Fish
时间戳精度	全程准	全程准，与 Doubao 一致	基本准，个别字跨度异常	前 17 秒准，后半段漂移
覆盖率	31.7%	高，蛋烘糕场景全有	高，但漏 3 句(0:47-0:52)	最高
Speaker	6 人	4 人	无	无
分段粒度	句子级	最细，逗号级	句子级	字级

这组对比揭示了一个关键事实：没有任何单一模型能同时提供准确的文本和准确的时间轴。Fish 文本准但时间戳飘，腾讯时间戳准但文本差——这直接决定了融合策略不能只选一个搭档，而是要三模型各取所长。

3.4 歌曲/BGM 处理对比

这段音频中穿插了至少 4 段歌曲演唱（约 1:10-1:14, 1:17-1:19, 1:31-1:41, 1:58-2:07），对话与歌唱的交替是一个重要的区分难点：

模型	歌曲处理策略	效果
豆包	全局 `lid_lang: singing_mand` 标记 + 歌词正常输出	歌词准确（"给我一个吻，给我炙热的双唇"），但无法区分哪些段是歌曲
Gemini	直接跳过歌曲段（100.8s→108.3s 无输出）	对话不受歌曲干扰，但丢失了歌曲段的信息
Fish	无区分，歌词混入文本流	歌词准确，但与对话无法区分
腾讯云	歌词和对话混成乱码（0:54-1:14 一个 20s 混段）	歌曲段是腾讯最大的崩溃点
Qwen	歌词标为 sad 情绪输出	歌词基本准确，但情绪标签不对（歌曲不是 sad）
讯飞	歌词乱码（"Cui美"、"yoyo不行"）	歌曲段完全失控

结论：歌曲/对话混合是所有 ASR 模型的共同弱点。在融合方案中，需要先做歌曲段检测（利用豆包的 singing_mand 标记 + Gemini 跳过的时间段作为信号），将歌曲段与对话段分开处理。

3.5 成本与延迟

生产选型不能只看准确率，成本和延迟同样是决定性因素（以下价格基于 2026 年 3 月各平台官网公示，实际可能因量级折扣而不同）：

模型	类型	延迟（128s 音频）	估算成本	备注
豆包	云 API（流式）	~5s	~¥0.02	火山引擎按时长计费
Fish	云 API	~3s	~¥0.01
Qwen	云 API（异步）	~3s	~¥0.01	DashScope 文件转写
腾讯云	云 API（异步）	~5s	~¥0.02	录音文件识别
讯飞	云 API（异步）	~8s	~¥0.03	转写接口
Gemini	云 API	~8s	~$0.02	多模态 token 计费
OpenAI	云 API	~3s	~$0.01	audio token 计费
Paraformer	云 API（异步）	~5s	~¥0.01	DashScope
FunASR	本地	~10s(CPU)	免费	需自行部署

三模型融合（Doubao + Tencent + Fish）的总成本约 ¥0.05/段，对于每集 2-5 分钟的短剧来说，ASR 成本可忽略不计。

3.6 综合评级

模型	准确率	功能丰富度	方言适应	覆盖完整性	时间戳精度	综合评价
豆包	★★★★★	★★★★★	★★★★★	★★★	★★★★★	功能最全，覆盖有缺口
讯飞	★★★★★	★★	★★★★★	★★★★★	★★★★	方言最准，分段太粗
腾讯云	★★★	★★★★★	★★★	★★★★	★★★★★	时间轴精准，融合骨架提供者
Qwen	★★★★	★★★★	★★★★	★★★★	★★★★	综合最均衡
Fish	★★★★	★★	★★★★	★★★★★	★★	覆盖最全，时间戳后段飘
FunASR	★★	★★★	★	★★★	★★★	可离线，方言差
Paraformer	★★	★★★	★	★★★	★★	云端略优于本地
OpenAI	★★	★	★	★★★	—	中文方言明显短板
Gemini	★	★★★	★	★★	★	文本幻觉，但 speaker/emotion 最佳

说明：讯飞的准确率和方言适应性 ★★★★★ 是基于覆盖区间内的表现——它确实识对了几乎所有方言关键词。但由于分段过粗（7段/129秒）和说话人完全失败，整体可用性远低于星级所暗示的水平。Gemini 的准确率 ★ 仅指文本转写维度，其 speaker/emotion 标注质量实际领先所有模型。

四、融合策略的演进

4.1 V1：Doubao + Fish — 直觉方案

最初的融合思路很直接：豆包功能全但有覆盖空白，Fish 覆盖全但缺元信息，以豆包为骨架，用 Fish 填补空白。

算法分三步：

# Step 1 — 找出豆包的空白区间
def find_gaps(utterances, total_ms, min_gap_ms=500):
    gaps, prev_end = [], 0
    for u in utterances:
        if u["start_ms"] - prev_end > min_gap_ms:
            gaps.append((prev_end, u["start_ms"]))
        prev_end = max(prev_end, u["end_ms"])
    return gaps

# Step 2 — Fish 按标点分句，映射字级时间戳
sentences = re.split(r'(?<=[。！？!?])', full_text)

# Step 3 — Fish 句子填入空白区间，跳过重复
def fill_gaps_with_fish(doubao_utts, fish_sentences, total_ms):
    gaps = find_gaps(doubao_utts, total_ms)
    for gap_start, gap_end in gaps:
        for sent in fish_sentences:
            if sentence_in_gap(sent, gap_start, gap_end):
                if not is_duplicate(sent["text"], doubao_utts):
                    filled.append({...sent, "source": "fish"})
    return filled

融合后获得 26 段，其中豆包 18 段 + Fish 补充 8 段，时间线无重叠。

但时间戳对比暴露了致命问题：Fish 补充段的时间戳在后半段偏差达 7-10 秒，意味着这些段的时间定位完全不可靠。同时 Fish 段没有 speaker 和 emotion 信息，标记为 speaker=?。

4.2 V2：准确的文本 + 准确的时间轴

V1 的问题本质上是：Fish 文本准但时间戳飘，腾讯时间戳准但文本差。正确的做法不是二选一，而是各取所长——Fish 出文本，Tencent 出时间轴。

三个模型各自的强项：

模型	文本准确度	时间戳精度	Speaker/Emotion	覆盖率
Doubao	★★★★★	★★★★★	✓	31.7%
Tencent	★★★	★★★★★	✓	高
Fish	★★★★	★★	✗	最高

融合原则：每个维度取最准的那个模型。

Doubao 覆盖区间：文本 + 时间戳 + speaker + emotion 全保留，不动。

Doubao 空白区间（如蛋烘糕场景 0:22-1:08）：

时间轴骨架：取 Tencent 的时间戳和 speaker（精准，与 Doubao 吻合）
文本替换：用 Fish 的文本覆盖 Tencent 的文本（Fish 方言词更准确）
情感/语速：保留 Tencent 的（有总比没有好）

三者都丢失的段落：Fish 文本 + forced alignment 生成时间戳

蛋烘糕场景的三版对比：

=== V1: Doubao + Fish（文本准，时间戳飘，无 speaker）===
[F] 0:33-0:34  spk=?  -        能不能买半个？
[F] 0:35-0:38  spk=?  -        哎，你这跟出去耍两个样！
[F] 0:38-0:40  spk=?  -        我恁个便宜蛋烘糕，半托半托卖呀！

=== 纯 Tencent（时间戳准，有 speaker，文本差）===
[T] 0:33-0:35  spk=1  neutral  能不能买半个？              ← 文本碰巧对
[T] 0:35-0:36  spk=2  neutral  哎！
[T] 0:36-0:40  spk=2  neutral  你跟说去耍…蛋烘糕半头半头…  ← "半头半头"不准

=== V2: Tencent 时间轴 + Fish 文本（两者都准）===
[T+F] 0:33-0:35  spk=1  neutral  能不能买半个？
[T+F] 0:35-0:36  spk=2  neutral  哎！
[T+F] 0:36-0:40  spk=2  neutral  我恁个便宜蛋烘糕，半托半托卖呀！  ← 文本修正

V2 同时解决了 V1 的两个痛点：有了 speaker 信息，文本也是准确的。

4.3 实际方案：LLM 语义 Diff + 腾讯时间窗口

V2 的核心难点在于：如何知道豆包漏了哪些内容？直接比对文本行不通——两个模型的分句方式、用词都不同。

实际采用的方案是让 LLM 做语义级 diff：

拼接全文：将豆包（primary）和 Fish（secondary）各自的识别结果拼成完整文本
LLM 语义 diff：提交给 LLM，让它找出 secondary 中存在但 primary 中缺失的句子，同时标注类型（dialog / singing）
时间窗口回填：将 diff 出的缺失句子，按时间位置放入豆包空洞对应的腾讯时间窗口，获得精确的 start_ms / end_ms 和 speaker

实测 diff 结果示例（蛋烘糕场景）：

{
  "diff": [
    {"text": "能不能买半个？", "type": "dialog"},
    {"text": "哎，你这跟出去耍两个样！", "type": "dialog"},
    {"text": "我恁个便宜蛋烘糕，半托半托卖呀！", "type": "dialog"},
    {"text": "走嘛！", "type": "dialog"}
  ]
}

LLM 准确识别出了豆包 0:22-1:08 空洞中丢失的全部对话。这些句子再匹配到腾讯的时间窗口（腾讯在该区间有完整的逗号级分段和精确时间戳），就得到了准确的文本 + 准确的时间轴 + speaker 信息。

这个方案的优势在于：LLM 做语义理解远比字符串 diff 可靠，能正确处理用词差异（如 Fish 说"半托半托"、腾讯说"半头半头"，LLM 知道它们指同一句话）。

4.4 V3 展望：引入 Gemini Speaker + Forced Alignment

V2 仍有两个短板：

Speaker 映射不够干净：腾讯云的 4 人体系在歌曲段混乱，豆包的 6 人存在过度分裂
三者都丢失的段落没有可靠的时间戳

Gemini 虽然文本不可用，但它的 speaker diarization 是全场最佳——3 人体系（男主/女摊贩/路人）干净一致，分段边界语义完整。在 V3 中可以引入 Gemini 作为 speaker 映射的参考基准：将豆包的 6 speaker 和腾讯的 4 speaker 聚类映射到 Gemini 的 3 人体系上。

对于三者都丢失的段落，Forced Alignment（强制对齐） 可以补上最后一环。FA 不是 ASR 模型——它不做识别，而是接受已有文本 + 原始音频，用声学模型（如 torchaudio 的 MMS 或 wav2vec2）计算每个字的精确时间戳和置信度分数：

{
  "char": "蛋", "start_ms": 38422, "end_ms": 38602, "score": 0.89
}

FA 在本地运行（CPU 即可），不依赖云 API。融合后的文本经 FA 对齐，可以得到全覆盖、字级精度的时间轴——这在 Fish 时间戳漂移的后半段尤其关键。

4.5 融合的局限

腾讯云在 0:54-1:14 有一个 20 秒的混段（对话和歌词混成一句），这段的分句和文本替换需要额外处理
文本对齐依赖时间窗口重叠，当 Fish 时间戳漂移严重时（后半段），匹配可能失败，需退化为纯文本相似度匹配
Gemini 的 speaker 映射依赖时间段重叠匹配，Gemini 自身的时间戳精度不高（有超出音频总长的标注），映射时需要容错
当前 FA 的置信度分数在歌曲段普遍偏低（<0.1），说明声学模型在音乐背景下对齐质量下降

4.6 讯飞的潜在价值

讯飞在方言词汇上与豆包并列第一，是全场唯二能正确识别"知青返乡"的模型，且"蛋烘糕"、"半坨半坨"等核心词全部命中。

讯飞当前无法参与融合的原因很明确：7 段的分割粒度太粗，无法提供句级边界；说话人全部标为 0。但如果讯飞改善分段粒度（哪怕到 20+ 段水平），它完全可以替代 Fish 成为方言文本校准源——既有顶级的方言准确度，又省去了 Fish 时间戳后段漂移的麻烦。

小结：最优融合不是选一个"最好的模型"，而是每个维度取最准的来源——Doubao 出文本和 emotion，Tencent 出时间轴，Fish 补全文本，Gemini 提供 speaker 映射基准，FA 兜底时间戳。准确的文本 + 准确的时间轴 + 干净的 speaker，这才是融合的目标函数。

五、选型建议

场景 A：需要最全面的元信息（配音、字幕生产线）

推荐：豆包 + 腾讯云 + Fish + Gemini 四源融合

豆包出文本和 emotion，腾讯云出时间轴，Fish 补全文本，Gemini 提供 speaker 映射基准。四者各司其职，配合 Forced Alignment 兜底时间戳，实现"准确文本 + 准确时间轴 + 干净 speaker"的目标。

场景 B：单模型、追求性价比

推荐：豆包或 Qwen ASR

豆包：覆盖区间内文本准确率最高，且自带 speaker、emotion、gender 全套元信息。虽然存在覆盖空洞（本次测试丢失约 35% 的段落），但识别出的部分质量最可靠。适合对准确率要求高、可以接受部分漏段的场景。
Qwen：综合覆盖率好，支持情感和语言检测，异步文件转写模式适合批量处理。但不支持说话人分离，如果业务需要区分不同角色（如配音、字幕标注），Qwen 无法满足。适合不需要 speaker 信息的场景。

场景 C：数据安全要求高、需要私有化

推荐：FunASR

完全开源、可离线部署，模型支持 CPU 和 CUDA。但需要接受方言场景下明显低于云服务的准确率，建议仅用于普通话为主的音频。

场景 D：方言文本校准、热词需求

谨慎考虑：讯飞

讯飞在方言核心词识别上与豆包并列第一（"知青返乡"、"蛋烘糕"、"半坨半坨"全部命中），但存在明显短板：语义有时不通顺，部分段落幻觉严重（如将对话内容错误拼接），且 API 接入成本较高（需要自行实现 WebSocket 协议、签名鉴权等，SDK 封装程度不如其他平台）。当前分段过粗（仅 7 段）无法独立使用，作为融合方案中的方言词汇校准源有一定价值，但需权衡接入成本。

场景 E：无歌曲/BGM 的纯对话场景

推荐：腾讯云

如果音频中没有歌曲穿插，腾讯云是一个很不错的单模型选择。时间戳精度全场最高（与 Qwen 交叉验证偏差仅 ~100ms），支持说话人分离，分句粒度细（逗号级），价格也有竞争力。本次测试中腾讯的主要问题集中在歌曲段（20 秒混段），纯对话区间表现稳定。

场景 F：多语言或英文为主

不推荐 Gemini 和 OpenAI 用于中文方言场景。它们在英文和标准多语言场景下可能表现更好，但本次测试充分暴露了在中文方言上的短板。

六、评测局限

任何评测都有边界，本文的局限需要坦诚说明：

方言覆盖单一：仅测试了四川方言，结论不一定适用于粤语、闽南语、吴语等其他方言体系。不同方言的声调系统和词汇差异可能导致模型排名变化。
歌曲场景放大了差异：本段音频的歌曲穿插比例较高（约 30%），这对部分模型（尤其是腾讯云、讯飞）形成了额外干扰。纯对话音频的结果可能更好。
模型配置未穷举：豆包支持热词功能（hotwords），讯飞支持 speaker_number 指定，Gemini 的 prompt 可以优化——更精细的调参可能改善部分模型的表现。本文使用的是各模型的默认/推荐配置。
无标准 WER：没有逐字 ground truth，无法计算学术标准的 WER/CER 指标。本文的准确率判断基于人工听写确认的关键词命中，偏向定性而非定量。
LLM-as-ASR 结论有限：仅测试了 Gemini 一家 LLM，不能推广到所有 LLM。且 Gemini 的测试揭示了一个有趣现象——LLM 做"转写"不行，但做"语义理解"（speaker/emotion 标注）反而优于传统 ASR。这条路径值得更多探索。

七、结语

这次横评揭示了一个事实：ASR 的真正战场不在标准普通话，而在方言、多人、多场景的复杂音频。在这个战场上：

没有完美模型——豆包文本最准但会丢段，讯飞方言最准但分段太粗，腾讯时间轴精准但文本偶有差错，Fish 覆盖最全但时间戳后段失准，Gemini 文本幻觉严重但 speaker 映射最干净
LLM 和传统 ASR 各有所长——Gemini 的幻觉是警示，但它在语义标注上的优势也不应被忽视。未来"LLM 做理解 + ASR 做转写"的分工融合可能是更好的方向
融合的目标函数是"准确的文本 + 准确的时间轴 + 干净的 speaker"，而不是简单选一个"最好的模型"。每个维度取最准的来源，才是工程最优解
数据驱动的分析比直觉判断更可靠——时间戳逐句对比推翻了"Doubao + Fish"的初始方案，Gemini speaker 数据的重新审视推翻了"Gemini 完全不可用"的初始判断

选择 ASR 模型时，不要只看标准评测集上的 WER 数字，也不要只看功能列表。拿你真实业务场景的音频跑一遍，做逐句、逐时间戳的对比，结果可能和论文大相径庭。

引言