Skip to content

離線轉錄的準確率不佳 #3419

Closed
#3712
Closed
離線轉錄的準確率不佳#3419
#3712
Labels
bugSomething isn't workingneeds feedbackWaiting for reporter feedback or retest results

Description

@aef5748
aef5748
opened on Jul 26, 2026

執行這個serve_vllm.py程式後，進行post的方式來將語音檔轉換成文字，速度是很快，但是準確率蠻差的
但看FunASR-nano的官方數據CER低於10%, 但實際我驗證出來的效果卻差很多，請問主要可能是什麼原因?

這是我的測試檔案和逐字稿內容，但我執行出來的準確率很低
Case: (CER 23.88%)
YT-02.mp3
YT-02.txt

Activity

  1. aef5748
    added
    questionFurther information is requested
    needs triageNeeds maintainer triage and routing
    on Jul 26, 2026

  2. LauraGPT commented on Jul 26, 2026

    @LauraGPT
    LauraGPT
    on Jul 26, 2026
    Collaborator

    感謝提供完整音訊與參考逐字稿。我用同一份 480 秒附件完成了復測，確認 serve_vllm.py 目前有一個會影響長音訊準確率的分段問題：獨立服務建立 FSMN-VAD 時沿用了 60 秒預設值，而 Fun-ASR-Nano 的其他範例採用 30 秒上限。原輸出中的 380.80-440.81s 長段確實漏掉了 Blackwell／產品更新與機器人討論的一大段內容。

    修正已提交到 #3420。參數必須在建立 VAD 模型時傳入；傳給 generate() 不會更新 FSMN-VAD 的 VADXOptions。

    同一音訊的實測結果：

    指標 修正前 修正後
    VAD 分段數 13 20
    最長分段 60.01 秒 30.01 秒
    對齊且統一簡繁後 CER 22.74% 19.63%
    RTF 0.0087 0.0169

    修正後，先前漏掉的段落已重新出現在輸出中；Blackwell 這類專有名詞仍可能辨識不準。

    另外有兩個評測口徑需要注意：附件音訊開頭 0-17.69s 是預告內容，但參考逐字稿沒有這一段；參考稿是繁體中文，模型輸出是簡體中文。因此直接逐字比較會額外計入未對齊內容與簡繁差異。上表先移除未對齊的預告段，再將參考與輸出統一為簡體、移除標點及空白後計算。

    官方低於 10% 的數字來自指定測試集，不能直接等同於任意 YouTube 錄音；口音、背景音、專有名詞與參考稿對齊都會影響 CER。不過這次確認的 60 秒長分段問題是服務實作本身的差異，PR 合併後會直接改善這條離線轉錄路徑。

  3. LauraGPT
    added
    bugSomething isn't working
    and removed
    questionFurther information is requested
    needs triageNeeds maintainer triage and routing
    on Jul 26, 2026
  4. LauraGPT
    added a commit that references this issue on Jul 26, 2026

    fix: limit vLLM VAD segments to 30 seconds (#3420)

    70c868c

  5. LauraGPT commented on Jul 26, 2026

    @LauraGPT
    LauraGPT
    on Jul 26, 2026
    Collaborator

    修正已合併到 main：#3420（merge commit 70c868c）。獨立 vLLM 服務現在會在建立 FSMN-VAD 時套用 30 秒分段上限；同一份 480 秒音訊的缺失段落已恢復，正規化 CER 由 22.74% 降至 19.63%。若更新到最新 main 後仍有可重現的漏字區段，歡迎附上時間範圍重新開啟此 issue。

  6. LauraGPT
    closed this as completedon Jul 26, 2026

  7. LauraGPT commented on Aug 30, 2026

    @LauraGPT
    LauraGPT
    on Aug 30, 2026
    Collaborator

    重新打开。此前在 #3420 合并后立即关闭不符合现在的维护标准：同一附件的标准化 CER 只从 22.74% 改善到 19.63%，报告者尚未确认原始准确率问题已经解决。这个 issue 将保持开放并标记 needs feedback；关闭条件是报告者用公开版本复测并确认，或维护侧给出同一音频、固定版本和明确评测口径的完整证据，并经过合理反馈窗口。

  8. LauraGPT
    reopened this on Aug 30, 2026
  9. LauraGPT
    added
    needs feedbackWaiting for reporter feedback or retest results
    on Aug 30, 2026

  10. aef5748 commented on Aug 31, 2026

    @aef5748
    aef5748
    on Aug 31, 2026
    Author

    我們後來改使用 qwen3ASR 的模型，並修改了 serve_vllm.py 這隻檔案進行驗證
    同樣的檔案準確率一樣沒有比較好, 大約就是改善過後的19%左右
    不過我們有嘗試參考這個專案 asr service
    在離線轉譯上效果好非常多，同樣的測試檔案可以達到10%內，這份專案中有採用Pipeline和vLLM的方式，兩個效果都有達到不錯的準確率
    Pipeline cer : ~= 8%
    vLLM cer : ~=9% (這有時候會出現不斷重複某個訊息)
    但都比直接修改 serve_vllm.py 得到的結果好

    另外請問你們有類似的 sample code 嗎? 因為我看qwen3_asr的範例檔內並沒有vLLM的架構樣子

  11. LauraGPT commented on Aug 31, 2026

    @LauraGPT
    LauraGPT
    on Aug 31, 2026
    Collaborator

    感谢补充 Qwen3-ASR 的复现信息。我们已经基于原生 qwen-asr vLLM 后端补了一套可独立运行的离线示例，PR 是 #3592。它会统一转成 mono/16 kHz，使用 Qwen3ASRModel.LLM 与官方 chunking，并在 JSON 中保留每段的精确时间边界。这个 issue 会继续保持打开，等你的实际复测，不会因为 PR 或 CI 通过就提前关闭。

    我也在 H100 80 GB 上用本 issue 的 480.24 秒附件做了实测，当前没有复现你提到的 8%-9% CER：

    • Qwen3-ASR-0.6B + 20 秒 VAD/vLLM：21.19%
    • Qwen3-ASR-1.7B + 20 秒 VAD/vLLM：20.04%
    • 5 秒 merge + 20 秒上限的 VAD/vLLM：19.96%
    • FSMN-VAD + 1.7B Transformers pipeline：20.11%
    • 原生 vLLM 180 秒 chunk：去除不在参考文本中的片头后，最佳 prefix-trim CER 为 18.74%

    上述结果使用相同的音频归一化和 CER 预处理；所以 #3592 只声明“部署样例已验证”，不声明准确率问题已经解决。为了和你得到的 8%-9% 做同口径复现，麻烦提供以下信息：

    1. 具体模型名称、大小与 revision；
    2. LanceLRQ/qwen3-asr-service 的 commit；
    3. 使用 pipeline 还是 vLLM serve，以及完整启动参数/配置；
    4. CER 计算脚本及文本预处理方式；
    5. 是否从参考文本和识别结果中都排除了开头约 17.69 秒的片头。

    拿到这些参数后我们会继续对齐验证。

  12. aef5748 commented on Aug 31, 2026

    @aef5748
    aef5748
    on Aug 31, 2026
    Author
    1. 模型名稱: Qwen3-ASR-1.7B
    2. LanceLRQ/qwen3-asr-service: 使用2.4.1版本
    3. pipeline和vllm都有使用, 且參數有設定: --enable-align --use-punc --enable-speaker --api-key=xxx --enable-speaker-db
    4. CER計算方式試將常見的語助詞或感嘆詞都過濾掉, 比如:
    • "啊", "嗯", "呃", "哦", "喔", "吧", "呢"....
    • 中文數字統一改成數字
    1. 逐字稿我有做修改, 增加17.69秒前段的內容:YT-02.txt

  13. LauraGPT commented on Aug 31, 2026

    @LauraGPT
    LauraGPT
    on Aug 31, 2026
    Collaborator

    感谢补齐信息。我已经把 qwen3-asr-service 的 v2.4.1 固定到 exact commit 9975a7a5ce236288e03d81262e7af920e46850fb，并下载了更新后的参考稿（SHA-256 7401f4bd742636229df5b2cc50599faac2f295a2dfa98c7846b5f665f72f24e2）。下一步会在同一份 480.24 秒音频上分别复测该版本的 pipeline 与 vLLM 路径，并与 #3592 的原生离线示例按同一文本归一化方式比较。

    这里需要先明确一个评测边界：过滤“啊、嗯、呃、哦、喔、吧、呢”等字符并把中文数字改成阿拉伯数字，会显著改变 CER 的分子和分母，因此目前的 8%-9% 不能直接与此前未过滤语助词的 18.74% 比较。为避免我们复现出另一个口径，请再附上实际 CER 计算脚本，或至少附上 pipeline/vLLM 各自归一化后的 hypothesis、reference、错误数与总字符数。

    这个 issue 会继续保持开放；不会因为部署 PR 合并或某一条 CI 通过而提前关闭。

  14. aef5748 commented on Aug 31, 2026

    @aef5748
    aef5748
    on Aug 31, 2026
    Author

    我的計算腳本

  15. LauraGPT commented on Aug 31, 2026

    @LauraGPT
    LauraGPT
    on Aug 31, 2026
    Collaborator

    已收到并按你提供的 cer_checker.py 原样复算。脚本 SHA-256 为 66ec56383c505418c78c5e7fe567d33564fcce7faccb0f508959a57f76d4ae50，新版参考稿 SHA-256 为 7401f4bd742636229df5b2cc50599faac2f295a2dfa98c7846b5f665f72f24e2。

    同一份 480.24 秒音频的结果如下：

    路径 你提供的 scorer CER
    #3592 最终原生 vLLM 示例，Qwen3-ASR-1.7B 6.45%
    原生 vLLM，180 秒 chunk 6.45%
    Transformers pipeline，20 秒 VAD 6.80%
    vLLM pipeline，20 秒 VAD 6.63%

    因此现在已经在相同口径下复现，而且 #3592 的原生 vLLM 示例不差于你报告的 8%-9%。此前 18.74% 使用旧参考稿和标准字符归一化；你的脚本会额外统一数字，并忽略选定的单字填充词、同义字替换，因此两组数字不能直接比较。我已同步修正 #3592 的 accuracy note，避免继续把不同口径放在一起。

    issue 仍保持开放，等待你在自己的 v2.4.1 / FunASR 环境复测 #3592；不会仅凭维护侧复现就替你确认问题已经解决。

  16. aef5748 commented on Sep 3, 2026

    @aef5748
    aef5748
    on Sep 3, 2026
    Author

    使用transcribe_vllm_offline.py 看起來效果差不多，是否可以增加speaker的呢?

  17. LauraGPT commented on Sep 3, 2026

    @LauraGPT
    LauraGPT
    on Sep 3, 2026
    Collaborator

    可以，但需要区分两条能力路径。

    你现在的 transcribe_vllm_offline.py / Qwen3-ASR 结果可继续作为纯转写基线；它不会因为加一个参数就变成可靠的说话人分离。对于“离线 ASR + 说话人归属”，FunASR 现已接入第三方 MOSS-Transcribe-Diarize：它一次生成转写、时间戳与录音内匿名说话人标签（如 S01/S02），不需要再拼外部 VAD、ASR 与 speaker 模型。

    若你已有 vLLM 服务，可按文档以 OpenAI 兼容接口部署 MOSS，并请求 response_format=diarized_json；FunASR 会将 segments 归一为 sentence_info。完整可复现命令、固定 revision 和返回校验见：
    https://github.com/modelscope/FunASR/blob/main/docs/moss_transcribe_diarize.md#vllm

    边界也需要明确：这些是单条录音内的匿名标签，不是已知人物身份识别、声纹验证，也不是实时 WebSocket 路径。你若在相同 480 秒音频上试验，欢迎贴出 exact model/server revision、segments 和你现有 CER 口径；我会据此比较纯 ASR 与带 diarization 的结果，而不会把不同模型的数字混为一谈。

  18. aef5748 commented on Sep 8, 2026

    @aef5748
    aef5748
    on Sep 8, 2026
    Author

    感謝回復, 關於準確率的狀況目前應該先告段落了
    另外也明白說話人分離的可靠度不會是很完整的
    不曉得能否將這個 transcribe_vllm_offline.py sample加上基礎的說話人分離代碼(MOSS-Transcribe-Diarize) 讓我參考下

  19. LauraGPT commented on Sep 8, 2026

    @LauraGPT
    LauraGPT
    on Sep 8, 2026
    Collaborator

    已把基础 MOSS 说话人示例直接加进你正在使用的 transcribe_vllm_offline.py，并在 #3678 合并。原来的 Qwen3 默认路径保留不变；新增 --engine moss 独立调用 MOSS 服务，不把 Qwen3 的文本与另一模型的标签混拼。

    请使用包含合并提交 01e822be1584ecb51e306c12f53b2dd47dcb96db 的源码；这次示例更新尚未包含在 PyPI 1.4.14 中。客户端安装及完整说明见中文示例说明。先按官网 MOSS 指南在独立环境启动 vLLM 0.27.1 服务，不要与 Qwen3 的 vLLM 0.14.0 环境混装，然后在仓库根目录运行：

    python examples/industrial_data_pretraining/qwen3_asr/transcribe_vllm_offline.py \
  YT-02.mp3 \
  --engine moss \
  --vllm-base-url http://127.0.0.1:8898/v1 \
  --served-model moss-transcribe-diarize \
  --request-timeout 600 \
  --max-completion-tokens 8192

    服务地址和注册名需与你的实际部署一致。结果写入 YT-02.moss-vllm.json，sentence_info 保留每段 start/end（毫秒）、text、spk；终端也打印时间与匿名标签。整条录音只上传一次，不走 Qwen3 的 180 秒切块，不额外拼 VAD 或 speaker 模型。HTTP 或段格式错误会报错，不覆盖已有结果。

    除 152 项本地测试、全新 CPU 客户端环境的真实 HTTP 测试外，我也在 H100 / vLLM 0.27.1、固定 MOSS revision e8681d68e7042738ffca8ac8212bc8fcb1131ab8 上跑了实际模型：短音频可返回结构化结果；你提供的 480.24 秒音频返回 284 段，本次全部标为 S01，最后一段结束于 469.2 秒。因此这里只确认示例可调用并保留返回字段，不把它当作多说话人准确率或全程转写完整性的证明；末尾语音及说话人归属仍需核对，8192 也不是长音频完整性的保证。

    S01/S02 是单条录音内的匿名标签，不是已知身份或跨文件身份识别。按你的意见，本次不继续展开 CER 比较。issue 先保持开放，等你使用这个具体示例后的反馈。

  20. aef5748 commented on Sep 9, 2026

    @aef5748
    aef5748
    on Sep 9, 2026
    Author

    感謝, 那我這個基本就先關閉了

  21. aef5748
    closed this as completedon Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingneeds feedbackWaiting for reporter feedback or retest results

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions