原创 孔某人 2025-04-18 16:05 北京
该benchmark主要考察:32k context能力,指令遵从能力,分析能力。
由于一些机缘,我把个人场景简化了一下做一个评测集。测了一下海外各家,感觉还是有点意思的,把结果放出来供参考。
本次测试又花了我2400CNY的API调用费。
测试场景
测试任务是:输入一个长播客的转录文稿,然后根据播客简介和转录内容,识别每个说话人各是谁、以及哪些ASR结果的说话人实际上是同一个。平均输出长度25.8k token(以gpt-4o的tokenizer计算),长度的标准差12.4k token。
数据集经过了难度筛选,剔除掉OpenAI、Anthropic、Google三家最强模型的成功率都很低的case。真值经过人工标定,有些真值可能无法从输入中推断,所以理论准确率上限低于100%。数据集是直接从我自用的场景捞了一批,可能有少量标注错误。
任务prompt距离实际应用进行了一些简化,整体为推理模型而设计,只提供参考思路,不硬性规定CoT步骤。
以下是一个对话录音的语音识别结果,其中包含多个说话人,不同的说话人由speaker id区分。
你需要根据整个对话的语音识别结果,识别对话中是否有提到每个说话人是谁,以及他的身份信息和个人介绍。
如果能够确认说话人的名字和个人信息,则进行输出,如果不能确认,则对应字段输出为空。
不要添加没有发言的嘉宾信息,即没有speaker_id的说话人。
有些时候一个说话人可能由于语音识别的问题被识别为多个不同的speaker id,
此时需要将这些speaker id合并为同一个speaker id,并输出为is_same_to字段。
以下是语音识别结果:
```text
{asr_result_text}
```
该录音中有 {speaker_num} 个说话人。
该视频的标题为:{video_title}
以下是这个对话的相关信息,其中可能包含有说话人的名字和身份信息。
```text
{video_info_text}
```
speaker的名字或ID的拼写应该以以上信息中的文字为准。
识别说话人的方式:
pattern 1:
* 对话中提到某个嘉宾的名字,此时直接使用嘉宾的名字作为speaker_name。
pattern 2:
* 如果对话内容和频道默认信息都不能识别出说话人,则从视频的标题中尝试分析主要的发言人。
pattern 3:
* 对于仍然无法识别出说话人的情况,分配以下默认的speaker_name:
* 对于不知道名字,主要发言是配合演示的助手或者AI助手,为他们分配 助手1 助手2 AI助手1 等speaker_name。
* 对于不知道名字,主要发言是向主要发言人提问的观众,为他们分配 观众1 观众2 等speaker_name。
* 对于不知道名字,只在开头部分介绍各个嘉宾的人,为他们分配 司仪 的speaker_name。
* 其他无法识别出名字的,则使用 嘉宾1 嘉宾2 等speaker_name。
整个识别过程可以参考以下过程
---
Step 1:
分析对话中哪些speaker id可能是同一个说话人。
对于同一个说话人被识别为多个speaker id的情况,一般在这些speaker id对话的切换过程中没有提问和问答、回应等。可以根据这些信息进行推断。
有些时候多个说话人之间会进行抢话,但只有有明确的其他证据表明这确实是不同的人时,才把某些不完整的句子的来回切换作为不同的说话人。
当总说话人数量较多,且经常出现一句完整的话被拆分为多个说话人时,要优先怀疑这些说话人可能是同一个人被识别成了多个的情况。
Step 2:
对于Step 1去重后的每个说话人,逐个尝试匹配上面的规则pattern,如果匹配成功,则采用对应pattern的分析结果确定其speaker_name,跳过后续pattern的匹配。
要对于每一个说话人都进行分析,不要遗漏。
real speaker [index]:
contain_speaker_id_list: speaker_xx, speaker_yy, ... # 哪些speaker id是该说话人
pattern 1: 分析是否符合该规则,如果符合则终止匹配后续pattern,否则继续匹配pattern
pattern 2: ...
...
最终以json输出每个说话人的身份信息
如果不确定一个speaker的名字或ID,则在speaker_name中填入他的描述,例如主持人、嘉宾1、某某人的XX 等等。
{{
"speaker_info_list": [
{{
"speaker_id": "speaker_1",
"speaker_name": "speaker name",
"speaker_info": "该说话人的身份,不要包括其他信息。"
}},
{{
"speaker_id": "speaker_2",
"speaker_name": "",
"speaker_info": ""
}},
{{
"speaker_id": "speaker_xx",
"is_same_to": "speaker_xx"
}}
]
}}
这个测试考察的是:32k context能力,指令遵从能力,分析能力。不过从测试结果来看,并不能发挥出推理模型的优势,需要的分析能力对于非推理模型也足够。
测试结果
测试结果如下表:
其中:
“结果个数错误”、“json解析错误”是最严重的错误,表示输出的json与输入的speaker数量不匹配或json有问题。
“同一说话人识别错误”严重程度次之,是指相同说话人的聚合出错。
“说话人名称错误”的严重程度最轻,一方面是播客简介中没有介绍时,拼写很容易错,另一方面,这一错误对应用场景的影响不如前两项严重。
简评:
整体结果与我对各家模型在workflow场景的能力认知基本一致。
claude-3.7-sonnet仍然是最强的应用层workflow模型,但claude-3.5-haiku该更新了。
grok-3系列的模型结果意外地不错。
o3-mini/o4-mini仍然不适合处理这种通用场景的文本和内容处理,模型规模太小还是不行。
各家模型在过去的半年中,能力都有明显进展,本代模型相较于上代模型有明显提升。
Llama 4确实不算好。
Deepseek R1在这方面表现也不错,不过官网的API请求实在太慢了。
截止发稿时,还没有精力搞测试集开源。考虑到之前开源的测试方案用的人也不多,这个也不一定会做。各家模型厂的人如果有需要请单独找我获取。
交流与合作
如果希望和我交流讨论,或参与相关的讨论群,或者建立合作,请加微信,联系方式请点击 -> 专栏简介 及 联系方式 2024。
本文于2025.4.18 首发于微信公众号和知乎,知乎链接:
https://zhuanlan.zhihu.com/p/1896592220351595651