User

帮我搜索全网以及Github，确定没有专门对粤语正字字幕做过微调的OCR模型吗？

Assistant

我会按“OCR（读画面里的字幕）”和“粤语 ASR（听声音转字幕）”严格区分来查，并把“支持繁体中文/香港字形”和“专门用粤语正字字幕数据微调”也分开。这样才能避免把一堆其实不是目标模型的项目误算进去。

Assistant

目前已经找到一个非常关键的反证线索：2026 年刚发布的 CantoBench-Synth / Cantonese-OCR-Benchmark 项目，作者在盘点 Hugging Face 粤语资源后明确写道：当时甚至找不到粤语 OCR 图像数据集，现有二十多个粤语数据集都是文本或音频；这个项目本身也只是“评测集/数据生成管线”，不是微调后的 OCR 模型。

我还在继续排查两个容易漏掉的方向：香港繁体 OCR / HKSCS 字形模型，以及“视频字幕 OCR 项目里内置但未单独发布的自训练权重”。

Assistant

可以把结论说得比较明确：

截至 2026 年 9 月 5 日，我没有找到一个公开可获得、且有明确证据证明“专门使用粤语正字字幕图像进行过微调”的 OCR 模型。
更严格地说，我查到了一批非常接近的项目，但目前没有一个同时满足「OCR + 粤语正字 + 字幕场景 + 已微调并发布权重」这四个条件。

这不是“绝对证明世界上不存在”——私人模型、商业内部模型、未公开权重无法排除——但就 GitHub、Hugging Face、ModelScope、论文/学术检索以及中英文网页公开资料而言，我认为已经可以下一个高置信度结论：目前公开生态里基本没有现成的粤语正字字幕专用 OCR fine-tune。

最关键的证据：2026 年刚有人专门调查过这个空白

我找到的最重要项目是今年刚完成的 CantoBench-Synth / Cantonese-OCR-Benchmark。它本身就是专门研究「粤文 OCR」的项目，而且时间非常新：OCF 2026 AI Research Internship，项目期是 2026 年 7 月 1 日至 8 月 30 日。(GitHub)

作者明确写道，他们盘点已有资源时发现：

Hugging Face 上二十多个粤语数据集全部是文本或音频，没有找到粤语 OCR 图像数据集。

因此他们自己制作了一个 4,930 张图片的粤文 OCR 合成 benchmark，覆盖「嘅、咗、冇、喺、𨋢」等粤语字，但目前定位仍然是评测数据集和数据生成管线，不是一个微调后的 OCR 模型。更关键的是，他们把“训练集与微调验证”列在未来工作里——也就是说，截至 2026 年 8 月底，连这个目前最直接针对粤文 OCR 的项目都还没有完成/发布专门 fine-tune 的模型。(Trickster)

Cantonese-OCR-Benchmark GitHub
CantoBench-Synth Hugging Face 数据集

而且这个 benchmark 已经证明，通用视觉模型对粤语字的视觉辨识确实很差。他们测试 Qwen3-VL 4B 和 InternVL3.5 4B，整体 exact-match ACC 分别只有 17.5% 和 29.3%；所有 Unicode 扩展区字样本的 ACC 都是 0%。例如 冇，InternVL3.5 在单字样本是 0/7，在句子中也是 0/99；这正是你想专门 fine-tune 粤语 OCR 的实际理由。(GitHub)

我找到的几个“很像，但不是”的项目

其中 CantoCaptions 特别值得注意。它确实是我找到的最贴近你所谓“粤语正字字幕”的公开资源：项目目标就是制作准确的 Written Cantonese / 粵文字幕，仓库里面有大量字幕，而且还专门定义了粤语正字规范、句尾助词、异体字和字幕格式。README 甚至列出了 㗎、嘅、𠺢、𡁜、𠻹 等大量粤字。(GitHub)

但它的问题恰好是：

它是 SRT/文本字幕语料，不是 OCR 图像→文字训练数据。

所以它实际上非常适合拿来生成你的 OCR 合成训练集，却不是现成 OCR 模型。

CantoCaptions / 粵文字幕 GitHub

一个很容易被误认为“已经有粤语 OCR 模型”的例外：Apple Vision

这里有一个需要特别澄清的东西。

Apple 的 Vision OCR 确实支持语言代码：

• zh-Hant
• yue-Hant
• yue-Hans

公开的 macOS Vision OCR 工具也可以直接指定 yue-Hant。(GitHub)

Apple 官方文档说明，VNRecognizeTextRequest 会根据 recognitionLanguages 选择相应语言进行文本识别，并且可以执行 language correction；系统也会选择“appropriate model”。(Apple Developer)

所以严格来说：

“支持粤语的 OCR”是存在的。

但它依然不能算你问的“专门对粤语正字字幕做过微调的 OCR 模型”，原因有三个：

1. Apple 没有公开训练数据、模型架构或权重；
2. 没有证据表明 yue-Hant 是拿字幕截图 fine-tune 的；
3. 也没有公开说明训练集是否系统覆盖粤语正字/HKSCS/扩展区字。

甚至有一个字幕 OCR 软件 UVS_OCR 曾经专门调用这一接口，并写明 macOS 新版会增加 yue-Hant -> 粤语中文繁体；这证明这个接口确实有人用于字幕 OCR，但仍然只是调用 Apple 的通用粤语 OCR capability，不是公开的粤语字幕 fine-tune。(App Store)

字幕专用 OCR 已经很多，但没有找到粤语版

这一类项目我也重点查了，因为最容易藏着你要找的东西。

例如 voun7/Subtitle_OCR 明确写：

“The training data is optimized for subtitle text images.”

也就是说，它确实是针对字幕图像训练的 OCR，不是普通文档 OCR。仓库还发布模型下载。(GitHub)

但仓库里没有出现 Cantonese、Traditional、ch_tra 等相关说明，也没有粤语数据集或粤语正字 fine-tune 的证据。(GitHub)

另一个老项目 lars76/chinese-subtitle-ocr 也确实专门训练中文视频字幕 OCR，甚至有自己的训练流程和 checkpoint；但它推荐使用的是《通用规范汉字表》和普通中文字频表，没有粤语正字/HKSCS 的训练设计。(GitHub)

现在的 Video Subtitle Extractor / Subtitle-OCR 一类工具可以支持 Traditional Chinese，甚至多达 87 种语言，但公开资料仍只是“繁体中文识别”，没有“粤语正字 fine-tuning”的说明。(GitHub)

所以这里要区分：

「针对字幕微调」≠「针对粤语正字字幕微调」。

前者已经有很多；后者我目前没有找到。

PaddleOCR / EasyOCR 的“繁体中文”也不能算

PaddleOCR 有：

chinese_cht_PP-OCRv3_mobile_rec

官方定义就是“中文繁体识别”，对应一个约 8,421 字的 chinese_cht_dict.txt。(GitHub)

EasyOCR 同样有：

ch_tra / zh_tra_g1

也是普通 Traditional Chinese 模型。(GitHub)

这和粤语正字之间有一个非常大的区别：繁体中文字集 ≠ 粤语正字训练分布。

甚至 PaddleOCR 社区有人因为繁中字典没覆盖需要的字符而询问如何增加字符重新微调；讨论也明确指出，新增字符需要在训练数据里真正出现，否则模型不会学到。(GitHub)

这一点对：

嘅 / 㗎 / 冇 / 喺 / 咗 / 哋 / 嚟 / 啲 / 𠺢 / 𠿪 / 𡁜 / 𨋢

尤其关键。

GLM-OCR 今年刚好有人提交了“粤语 OCR 太差”的 issue

这个证据也很有意思。

2026 年 5 月，GLM-OCR 有一个公开 issue，标题直接是：

“Low OCR accuracy for Cantonese / Hong Kong Traditional Chinese characters”

里面测试了 㖭、㗎、㷫、𥹉 等粤语/HKSCS 字符，模型会识别成大量形近的错误字符。提交者明确指出这会影响：

Hong Kong Cantonese text、local publications、subtitles、menus、social media screenshots 等。

(GitHub)

这至少说明，截至今年，连新的专用 OCR/VLM 仍然没有把这个问题很好解决；否则实际用户不会遇到这么系统性的粤字错误。

所以我的最终判断

按照以下定义：

模型必须接受图像作为输入；训练/微调数据中明确包含 Written Cantonese/粤语正字；训练域明确包含视频硬字幕/字幕截图；并公开了模型权重或至少明确说明 fine-tuning 方法。

我目前找到：

公开模型数量：0 个。

如果把标准稍微放宽：

• 有粤语 OCR 支持但非字幕专用： Apple Vision yue-Hant
• 有字幕专用 OCR 但非粤语专用： Subtitle_OCR、Chinese Subtitle OCR、PaddleOCR/VSE 等
• 有粤语正字字幕数据但不是 OCR： CantoCaptions
• 有粤语 OCR 图像数据但还没 fine-tune 模型： CantoBench-Synth

这四块目前恰好是分开的。

而且最关键的是：CantoBench-Synth 直到 2026 年 8 月底才填上“粤语 OCR 图像 benchmark”这个空白，而且作者自己下一步才准备做“训练集与微调验证”。 (Trickster)

所以如果你的目的其实是：

“我要不要自己训一个粤语正字硬字幕 OCR？”

答案是：值得，而且从公开资料看，你很可能确实是在做一个目前没有成熟开源现成方案的 niche。

比较理想的数据路线其实已经很清楚了：CantoCaptions 的真实粤语正字 SRT 文本 + CantoBench 的字表/语料/字体生成方法 + 实际港片/YouTube/TV 字幕截图域随机化，拿一个成熟的繁中 recognition backbone 做 LoRA/full fine-tune。这样会比从零造粤语语料容易很多。

如果你愿意，我下一步可以直接继续帮你做一件更有价值的事：把目前最适合拿来做“粤语正字字幕 OCR 微调”的基础模型全部筛一遍（PaddleOCR、SVTR、PARSeq、TrOCR、Qwen3-VL、DeepSeek-OCR、GLM-OCR 等），按照训练成本、字典扩展、HKSCS 支持、字幕推理速度和可商用性给你选出 2–3 个最值得微调的底模。

User

我愿意。

Assistant

我会按你真正要落地训练的角度筛：粤字覆盖、字幕域适配、是否能扩字典/做定制训练、推理速度、显存成本、许可证/商用风险。重点不是“谁 OCR benchmark 最高”，而是“谁最适合拿来做粤语正字硬字幕专模”。

Assistant

一个比较重要的发现已经明确：PP-OCRv5 比我预期更适合作为第一底模。官方识别字典已经扩大到 18,383 行，并且确实包含 嘅、咗、嚟 等粤字；但像 㗎、喺、哋 仍不在字典里，所以它不是“开箱即用粤语”，但非常适合扩字典后继续训练。

Assistant

可以。我把目前值得考虑的路线重新按“粤语正字硬字幕 OCR”这个目标筛了一遍。结论比单纯看 OCR 排行榜清楚很多：

结论先给你

如果现在让我自己开这个项目，我会这样排：

如果只能训练一个：PP-OCRv5。

如果可以训练两个：PP-OCRv5 + GLM-OCR。

这两个不是互相替代，而是非常适合组成一个“快模型 + 疑难字模型”的两级系统。

1. 第一选择：PP-OCRv5_server_rec

这是我现在最推荐你先动手的。

PP-OCRv5_server_rec 本来就是文字行识别模型，官方定位同时覆盖简中、繁中、英文、日文，以及罕见字、手写、竖排等场景；官方当前模型只有约 85 MB，许可证 Apache-2.0。(Hugging Face)

更重要的是，Paddle 已经把“自定义字符集训练”这条路铺好了：

character_dict_path: ./ppocr/utils/dict/ppocrv5_dict.txt

训练配置明确允许换成自定义字典，而且训练集就是简单的：

图片路径<TAB>文本

形式。(GitHub)

对于你这个任务，这一点比“大模型 OCR benchmark 高几分”重要得多。

PP-OCRv5 已经有一些粤字，但远远不完整

我直接检查了当前 PaddleOCR 官方 ppocrv5_dict.txt 原始文件。它大约有 1.84 万个字符项。(GitHub)

里面已经有，例如：

• 嘅
• 咗
• 嚟
• 啲
• 嘢
• 佢
• 瞓
• 黐
• 攞
• 冚

例如 嘅 和 咗 都确实在当前官方字典中：(GitHub)

而 嚟、啲、嘢、佢 等也能在当前字典中直接看到。(GitHub)

但是我逐字检索：

• 㗎
• 喺
• 哋

当前官方字典均未检出。(GitHub)

这其实是个非常好的状态：

PP-OCRv5 不是一个粤语模型，但它已经学会了大量繁中、异体字和一部分粤字的视觉特征，我们只需要补齐粤语/HKSCS 字符和字幕域，而不是从零训练中文 OCR。

因此迁移学习的起点很好。

2. 为什么我选择 server，而不是一上来 mobile

PP-OCRv5_mobile 本身也很有意思，它当前配置的算法就是：

SVTR_LCNet + PPLCNetV3 + CTC/NRTR MultiHead

所以严格来说，你提到的“要不要搞 SVTR”，Paddle 这条现代路线本身已经吸收了 SVTR 的思路。(GitHub)

我的策略会是：

训练阶段：server → 先把准确率做到顶

部署阶段：mobile → 再把速度做到顶

而不是一开始就用 mobile 赌它容量够不够。

原因很简单：你现在首先需要回答的研究问题是：

“加入正确粤语字集 + 粤语字幕训练数据以后，OCR 上限到底能到多少？”

server 更适合当 accuracy baseline。

等你证明：

CER 0.x% / 行准确率 9x%

以后，再做 mobile 微调/蒸馏。

3. 第二选择：GLM-OCR

GLM-OCR 我反而认为特别值得拿粤语做 fine-tune。

不是因为它现在粤语很好。

恰恰因为它现在粤语明显不好，但模型本身很好改。

GLM-OCR 是一个 0.9B 的多模态 OCR 模型，官方模型 MIT License，仓库代码 Apache-2.0。(GitHub)

官方在 2026 年已经提供完整微调流程，而且给出了非常明确的硬件门槛：

• LoRA：≥ 8 GB 单卡显存
• Full SFT：≥ 24 GB 单卡显存

也明确支持用户自己的 OCR 图片数据。(GitHub)

所以训练门槛没有想象中高。

更关键的是：GLM-OCR 已经有一个专门的粤语 bug

今年 5 月有人专门提交：

Low OCR accuracy for Cantonese / Hong Kong Traditional Chinese characters

并且给出了大量错误实例。(GitHub)

包括：

• 㗎 → 各种形近字
• 喺 → 噝 / 㗎
• 嘅 → 嘁
• 嚟 → 嘟 / 噄 / 嘞
• 佢 → 仾
• 唔 → 晤
• 嗰 → 啯
• 𨋢 → 軲

甚至还出现：

• 醬 → 酱
• 帶 → 带
• 裝 → 装

也就是你最不想见到的：

OCR 自作聪明，把香港繁体/粤语原字“纠正”成普通书面中文或者简体。

而 issue 提交者明确点名影响场景包括：

Hong Kong Cantonese text、subtitles、menus、social media screenshots……

(GitHub)

换句话说，这几乎就是有人替我们做了一次粤语 OCR failure analysis。

4. 为什么 GLM-OCR 值得训练，但不应该做第一主力

因为 GLM 的优势和 Paddle 完全不同。

PP-OCRv5

本质上更接近：

看这个字长什么样 → 输出这个字。

它有固定字符表。

因此特别适合：

“不要替我改字，我画面写什么你就输出什么。”

这是字幕 OCR 的理想属性。

GLM-OCR

更像：

看图 + 语言模型 → 生成文本。

优点是：

Unicode/HKSCS/罕见字符的扩展不需要像 CTC 那样人为增加一个 output class。

但缺点也是语言模型：

它容易认为：

“这个句子写 嘅 好像怪怪的，我觉得应该是 的。”

而这正是 Cantonese OCR benchmark 故意测试的问题。

所以我的工程设计会是：

PP-OCRv5 = 第一识别器

↓

confidence 低 / 含疑难字

↓

GLM-OCR-Cantonese = 第二识别器

这样非常合理。

5. GLM-OCR 微调这里有一个隐藏坑

官方 full SFT 示例默认：

• freeze vision tower
• freeze multimodal projector
• 训练 language model

(GitHub)

对于普通“领域 OCR”可能没问题。

但是对于粤语罕见字，我不会完全照官方配置。

因为你的问题不仅仅是：

模型不知道 㗎 这个语言符号。

更重要的是：

模型视觉编码器没有真正学会 㗎 和 喺、啫、嘅 等复杂形近字的 glyph。

比如现在 GLM 会：

㗎 → 喍 / 喋 / 嘄

这明显包含视觉表征不足。(GitHub)

所以我会做两阶段实验：

阶段 A

先按照官方 LoRA，快速教它：

粤语正字必须原样输出，不准标准化，不准简化。

阶段 B

如果 rare-char test 仍然差，再让视觉侧参与适配，专门打：

glyph discrimination

而不是不停加语言数据。

这一点非常重要。

6. 第三名为什么给 PARSeq，而不是 Qwen

PARSeq 是个很“干净”的 OCR 研究底模。

它就是纯粹的 Scene Text Recognition，而且官方代码明确支持：

• 自定义 charset
• 自定义训练集
• pretrained weights 继续 fine-tune
• ONNX / TorchScript

(GitHub)

其公开训练权重的数据中也包含：

• RCTW17
• LSVT
• ReCTS
• MLT19

等场景文字数据。(GitHub)

而且大多数代码是 Apache-2.0。(GitHub)

它的优势

你可以自己定义：

“我的世界只有这 12,000 个中文字 + 粤字 + ASCII + 标点。”

完全不给语言模型“纠正粤文”的机会。

对于科研实验，这很有价值。

但 PARSeq 有个大问题

它官方演示的标准 pretrained 输出空间是：

94 个字符 + EOS

也就是非常典型的 Latin scene-text setting。(GitHub)

我们突然把输出类别扩成：

10,000～20,000 个汉字/HKSCS/粤字

这已经和它原本最舒服的任务分布很不一样了。

可以做。

但工程风险明显比：

已经原生拥有 ~1.84 万字符输出空间的 PP-OCRv5

大。

所以我的排序是：

PP-OCRv5 > PARSeq

不是 PARSeq 架构不好，而是Paddle 已经帮我们解决了中文 OCR 最麻烦的初始化问题。

7. Qwen3-VL 我为什么暂时不让你训练第一轮

Qwen3-VL 官方当然很强。

当前系列宣称 OCR 扩展到 32 种语言，并特别强化了低光、模糊、倾斜、罕见/古文字等能力；许可证也是 Apache-2.0。(GitHub)

但粤语 benchmark 已经给出了非常直接的数据。

CantoBench-Synth：

Qwen3-VL 4B：

• CER：0.7009
• 行 Exact ACC：17.5%
• 单字 ACC：16.7%
• 句子 ACC：5.7%
• Unicode 扩展区 ACC：0.0%

(Hugging Face)

这个结果非常说明问题。

不是说它 fine-tune 后一定不行，而是：

我们没必要先拿一个 4B VLM，去解决一个 85 MB OCR recognizer 很可能能解决的问题。

它最适合作为第三层语境模型。

例如：

PP：

我今日真係好攰㗎

GLM：

我今日真係好攰㗎

Qwen：

根据上下文判断两个 OCR candidate 哪个最可能对应画面。

而不是让 Qwen 每帧从头 OCR。

8. DeepSeek-OCR-2 也暂时不排第一轮

这里需要更新到最新版本：

DeepSeek 已经在 2026 年 1 月 27 日发布 DeepSeek-OCR-2。(GitHub)

官方 Hugging Face 权重约 6.78 GB，Apache-2.0。(Hugging Face)

它是非常有意思的通用 OCR/VLM，但目前官方仓库的公开重点还是：

• inference
• document OCR
• benchmark

而不像：

• PaddleOCR
• GLM-OCR

已经有一条这么明确的“拿你自己的 OCR 数据直接 fine-tune”路径。(GitHub)

对这个项目而言：

它太重，而且工程收益暂时不确定。

所以先不浪费 GPU 时间。

9. TrOCR 我会直接淘汰

原因不是它 OCR 能力差。

而是task prior 不对。

Microsoft 的经典 TrOCR printed checkpoint 主要是 encoder-decoder OCR 路线，体量已经远大于 PP-OCR，而其文本 decoder/tokenizer 并不是为了大型繁中+HKSCS 字符集设计。

你为了粤语重新搞：

• tokenizer
• decoder vocabulary
• 字符覆盖
• 中文预训练迁移

做到最后，相当于把它最好用的预训练优势拆掉一半。

投入产出比太低。

所以除非做论文 ablation，我不会训它。

我会怎么真正把这个系统做出来

而且这里有个很重要的优化：

不要把“字幕 OCR”当成普通 OCR。

普通 OCR pipeline 是：

整张图 → text detection → crop → recognition

你的视频字幕其实通常是：

固定区域 → 固定字体类型 → 固定大小范围 → 横向排列 → 连续多帧完全相同

所以实际上可以：

视频帧

↓

固定下方 ROI

↓

字幕变化检测 / temporal sampling

↓

直接 rec

↓

PP-OCRv5-Cantonese

↓

低置信度？

↙　　　↘

否　　　　是

输出　　GLM-OCR-Cantonese

↓

时间轴去重/合并

↓

SRT

也就是说，大多数时候甚至不需要运行文字 detection model。

这会让速度快非常多。

我建议的粤语字符集策略

这里不要犯一个常见错误：

“把 Unicode 所有 CJK 扩展区全部塞进去。”

我不建议。

字符类别越大，CTC 分类头越难训练，而且大量永远不会出现的字符只会浪费容量。

应该建立：

cantonese_subtitle_dict

基础：

PP-OCRv5 原字典

∪

粤语正字常用字

∪

香港增补字符集/HKSCS 中你的实际语料会出现的字

∪

CantoBench 的 154 粤语特有字集合

∪

字幕真实语料出现字

∪

ASCII / 数字 / 港式标点 / emoji（视素材决定）

这样最后可能仍然就在：

约 18k～20k 的量级

而不是几万个 Unicode 汉字全部塞进去。

数据才是真正决定成败的部分

我建议训练集分三层。

A. 大规模合成字幕

直接用粤语正字语料生成：

今晚你得唔得閒呀
你噉樣做唔係幾好喎
我真係頂你唔順㗎
佢頭先已經走咗喇
搭𨋢上去就得㗎喇

随机：

• 字幕字体
• 字号
• 白字黑边
• 黄字
• 阴影
• 描边宽度
• 透明度
• 视频背景
• JPEG/H.264 类压缩破坏
• blur
• resize
• chroma bleeding
• interlace
• motion blur
• 480p → upscale
• oversharpen

CantoBench 已经证明这种合成方法在粤语 OCR 上是可行的，而且他们的 benchmark 本身就用了旋转、透视、模糊、噪声、JPEG 压缩等 augmentation。(Hugging Face)

B. 真实字幕截图

这个最值钱。

我第一版会目标做：

3,000～5,000 条人工校对的真实字幕行

而不是一开始疯狂标 100 万张。

因为每一个字幕实际上会连续出现几十帧。

你只需要标其中：

最清楚的一帧

然后自动传播 label 到邻近帧，就能得到不同：

• compression state
• background
• motion
• frame phase

的同标签训练样本。

数据放大效率非常高。

C. Rare-character hard set

这块我要单独搞。

比如专门生成几十万次：

• 㗎
• 喺
• 嘅
• 啲
• 嚟
• 哋
• 嗰
• 唔
• 諗
• 攞
• 冇
• 𨋢
• 𠺢
• 𡁜
• 𥹉

而且不能只有单字。

要做形近 hard negative：

㗎 / 喺
嘅 / 嘁
唔 / 晤
嚟 / 嘞
嗰 / 啯
佢 / 仾
𨋢 / 軲

这恰好就是 GLM 当前真实错误里暴露出来的问题。(GitHub)

最关键的评价指标也不能只看 CER

我建议至少同时看四个。

1. CER

Character Error Rate。

整体识别能力。

2. Exact Line Accuracy

整行必须一个字都不错。

这个对字幕非常重要。

3. Cantonese Character Recall

只统计：

㗎、喺、嘅、咗、啲、哋、嚟……

这些目标字。

否则 99% 的普通汉字会把总体 CER 美化掉。

4. Cantonese Preservation Error

这个我甚至建议自己定义一个指标。

专门统计：

粤语 → 普通书面语
繁体 → 简体
香港字 → 常规 CJK 形近字

例如：

嘅 → 的

喺 → 在

唔 → 不

嚟 → 來

醬 → 酱

这里一律算严重错误。

因为对于“忠实提取正字字幕”，这种错误比普通 OCR typo 更糟。

我认为最有希望的最终架构

如果项目成熟，我不会追求一个巨型万能模型。

我会做：

Stage 1 — 超快

PP-OCRv5_mobile Cantonese

处理约 90%+ 的字幕。

Stage 2 — 高精度

低置信度转：

PP-OCRv5_server Cantonese

Stage 3 — 疑难字

仍然冲突：

GLM-OCR Cantonese

Stage 4 — 时序投票

同一句字幕在：

frame 100
frame 101
frame 102
frame 103

识别结果做 consensus。

这样视频字幕拥有一个普通静态 OCR 完全没有的巨大优势：

同一张字你可以看很多次。

利用好时序信息以后，最终字幕准确率可以远高于单帧 OCR accuracy。

所以我建议我们第一阶段就锁定这个实验

底模：PP-OCRv5_server_rec

任务：recognition only

字符集：PP-OCRv5 + 粤语/HKSCS 增量字符

训练数据第一版：

• 5 万～20 万合成字幕行
• 3,000～5,000 真实字幕行
• 单独的粤字 hard-negative oversampling
• CantoBench 只作为独立测试集之一，不要把 benchmark 混进训练集

最后这一点尤其重要：CantoBench 目前是 CC BY-SA 4.0，而且它自己明确定位为 benchmark；如果以后模型准备商用或公开权重，我建议训练数据许可另外整理，避免把 benchmark 污染和许可问题混进来。(Hugging Face)

第一轮甚至不用碰 Qwen、DeepSeek。

如果 PP-OCRv5 这一轮能把真实粤语字幕做到比如：

CER < 1% + 常见粤字 Recall > 99%

那我们就已经证明这个方向成立了。之后再针对 remaining errors 上 GLM-OCR。

我下一步会优先帮你把**“PP-OCRv5 粤语字幕微调方案”具体化到可以直接开工的程度**：包括粤语字符表怎么生成、训练/验证数据目录格式、合成字幕生成器应覆盖哪些字体与描边、如何处理新增字符导致的识别头维度变化，以及第一轮训练配置应该怎么改。

User

OpenOCR/SVTRv2 呢？

Assistant

这个值得单独拎出来。OpenOCR / SVTRv2 其实比 PARSeq 更应该进入你的第一梯队候选，尤其如果目标是“纯识别器、长中文行、尽量少语言模型纠错”。我查一下它当前代码、训练方式和中文预训练覆盖，再重新给你排位。

Assistant

这里还发现了一个我上一轮漏掉、而且很关键的现成起点：GitHub 上已经有人在 2026 年发布了 Cht-SVTRv2，直接用 OpenOCR 的 SVTRv2 从头训练繁体中文识别器，2300 万+图像、12,217 字符，并公开 best.pth。它不是粤语字幕专模，但对我们而言，比从官方简中 SVTRv2 权重起步更接近目标。

Assistant

对，OpenOCR / SVTRv2 应该进第一梯队，而且我上一轮把它放低了。

重新查完当前代码、官方权重以及一个我刚发现的 繁体中文 SVTRv2 权重以后，如果目标限定为“粤语正字硬字幕识别”，我的排序会改成：

我甚至建议我们第一轮直接做：

Cht-SVTRv2-Cantonese vs PP-OCRv5-Cantonese

而不是只训 Paddle。

为什么 SVTRv2 非常适合这个任务

SVTRv2 是 ICCV 2025 的工作，本质还是 CTC recognizer。它没有 VLM 那种自由生成的问题，但又通过视觉模型内部把一部分 linguistic context 加进去。它引入 MSR、FRM 和 SGM，尤其 SGM 只在训练时用于语义指导，推理时可以去掉，因此不会增加推理成本。(arXiv)

这点非常符合粤语正字 OCR：

既希望模型利用「我今日真係好攰㗎」的字间上下文，又不希望它像 LLM 一样把 嘅 自作聪明改成 的。

SVTRv2 正好位于这两端之间。

而且论文的纯 STR benchmark 很漂亮：

• SVTRv2-T：约 5.13M
• SVTRv2-S：约 11.25M
• SVTRv2-B：约 19.76M
• SVTRv2-B Union14M 平均约 86.14
• 1080Ti PyTorch latency 约 7 ms

并且专门测试了 25–36 字符的 Long Text Benchmark。(GitHub)

字幕恰好就是规整、横向、相对长的 text-line recognition。

所以从 task prior 来讲，SVTRv2 其实比很多 document OCR backbone 更对题。

更关键的是：已经有人训了繁中 SVTRv2

这个项目很值得你关注：

qpal147147/Cht-SVTRv2

它不是拿官方简中模型简单转换，而是按 OpenOCR/SVTRv2 路线从头训练繁体中文模型：

• 23,000,000+ 图片
• 12,217 字符
• Union14M-L-Filter
• TCSynth
• TC-STR
• 已公开 best.pth
• Apache-2.0
• 作者明确说用途之一就是作为后续预训练模型。(github.com)

这件事直接改变了我对 SVTRv2 的评价。

因为我们现在不需要：

英文/简中 SVTRv2 → 粤语

而可以：

2300 万图繁中 SVTRv2 → 粤语正字字幕

这个 domain gap 小很多。

更有意思的是它已经会不少粤字

我直接检查了它发布的 12,217 字符字典。

里面已经有：

咁

咗

哋

唔

啫

啱

啲

喎

嘢

嚟

例如字典里：

• 咁 在 1147
• 咗 在 1165
• 哋 在 1203
• 唔 在 1246 (GitHub)
• 啫 / 啱 / 啲 在 1298–1300
• 喎 在 1322 (GitHub)
• 嘢 在 1425
• 嚟 在 1501 (GitHub)

这是一个相当不错的基础。

但它仍然不是粤语模型。至少我查到这些关键字符没有出现在其 12,217 字符表里：

㗎

喺

嘅

𨋢

(GitHub)

所以它的状态非常典型：

繁中视觉能力很好 + 偶然覆盖了一批常见粤字，但没有系统覆盖 Written Cantonese/HKSCS。

这正是最适合 fine-tune 的位置。

SVTRv2 vs PP-OCRv5：我现在怎么看

两者体量其实非常接近。

官方 PaddleOCR 当前列出的：

PP-OCRv5_server_rec

• 81 MB
• GPU 高性能模式约 2.36 ms
• CPU 约 31 ms
• 官方繁中 benchmark 93.29%

ch_SVTRv2_rec

• 80.5 MB
• GPU 高性能模式约 8.31 ms
• CPU 高性能模式约 30.83 ms

不过这个表里的 accuracy 不能直接拿 93.29 和 68.81 比，因为它们的评测集/协议不是同一套。(GitHub)

所以目前不存在证据能说：

PP-OCRv5 一定比 SVTRv2 准。

尤其不能推导到粤语字幕上。

PP-OCRv5 的优势

它现在最大的优势是：

1. 字符覆盖更宽

PP-OCRv5 是一个多场景大字符表：

• 简体
• 繁体
• 日文
• 生僻字
• 手写
• 竖排

官方当前 ppocrv5_dict.txt 大约 1.8 万字符。

所以你需要增加的新粤字数量相对较少。

2. 工程成熟度非常高

训练、部署、TensorRT/Paddle inference、C++ 等都成熟。

3. 官方繁中已经专门强化

PP-OCRv5 官方明确把 Traditional Chinese 纳入训练目标。(GitHub)

SVTRv2 的优势则正中字幕场景

1. 它是真正为 Scene Text Recognition 设计的

字幕本质更像：

scene text line

而不是 document OCR。

2. CTC 特别适合“忠实抄写”

这是我很看重的一点。

最终 decoder 是：

CTCDecoder

而不是 autoregressive LLM decoder。官方中文配置也明确如此。(GitHub)

所以：

画面写 嘅 → 输出 嘅

是它天然应该学习的目标。

不容易产生：

嘅 → 的

这种“语义上更自然但 OCR 上完全错误”的 hallucination。

3. 长文字比传统 OCR 更舒服

SVTRv2 论文专门强调了 long text robustness，并设置了 25–36 字符 benchmark。(GitHub)

港剧/综艺字幕通常正好在这个范围附近。

4. 输入 resize 思路也适合字幕

官方中文 OpenOCR 的 SVTRv2 配置已经使用：

48 × 320

而不是经典 OCR 那种非常窄的 32×100。(GitHub)

对于 16～25 个中文字的一行字幕更合理。

但 Cht-SVTRv2 有两个地方不能直接照搬

这里很重要。

它目前配置是：

max_text_length: 25

并且其训练配置使用：

scales: [[128, 32]]

以及 RCTC decoder。(GitHub)

对于它原本的数据这样可以。

对于我们的粤语字幕，我不会直接保持这个配置。

第一处：长度

我会把粤语字幕任务设计成：

每一行单独 recognition

然后：

max_text_length = 40 或 48

原因很简单。

不要因为训练框架人为把：

26～35 字的真实字幕

全部扔掉。

SVTRv2 本身就有长文本能力，没必要自我限制。

第二处：输入宽度

对于中文，32×128 很容易把一长串中文字压得非常窄。

我们的字幕 ROI 非常规则，所以我反而会实验：

48×320

以及动态宽度，例如：

• 48×160
• 48×256
• 48×320
• 48×480

根据长宽比 bucket。

这个其实特别符合 SVTRv2 的 MSR 设计思想。

最大的技术问题：新增粤字的 CTC Head

比如当前 Cht-SVTRv2 没有：

嘅

如果我们把：

㗎、喺、嘅、𨋢……

加入 charset，那么：

CTC classifier 的输出维度改变。

所以不能傻乎乎：

改 dictionary → 直接完整 load best.pth

因为最后 classifier shape 对不上。

正确做法有两种。

简单版

保留：

SVTRv2 Encoder 全部预训练参数

重新初始化：

CTC classification head

然后用大量繁中 + 粤语数据继续训练。

能工作。

但会暂时损失原来 12k 字 classifier 学到的大量信息。

我更推荐的版本

做 vocabulary expansion weight transplant。

假设：

旧字典：

12217 chars

新字典：

12217 chars
+ 300~1000 Cantonese/HKSCS chars

那么新建 classifier 后：

对于共同字符：

把旧 classifier 中该字符对应的 weight/bias 行，复制到新 classifier 相同字符的位置。

对于新增字符：

随机初始化。

于是：

「餐、廳、學、嚟、咗……」原来的分类能力全部保留下来。

只有：

㗎、喺、嘅、𨋢……

从零学。

这个办法很适合我们。

而且我现在不建议只使用它的 12,217 字字典

这里 PP-OCRv5 和 Cht-SVTRv2 可以互补。

我会构造：

CantoneseOCR charset

大致：

Cht-SVTRv2 12,217

∪

PP-OCRv5 字典中的有价值繁中/生僻字

∪

CantoBench 154 粤语字

∪

CantoCaptions 全语料实际字符

∪

HKSCS 中实际可能进字幕的字符

然后频率清洗。

最终我猜大概：

15k～20k

已经足够。

没必要塞完整 Unicode CJK。

还有一个让我更偏爱 SVTRv2 的点

SVTRv2 的论文设计了 SGM — Semantic Guidance Module。

它在训练阶段给视觉特征提供语言上下文，但推理阶段可以删掉。(GitHub)

这实际上特别适合粤语。

我们可以大量喂：

我哋一陣去邊度食飯呀
你噉樣做唔係好得喎
我都唔知佢去咗邊
真係好鬼攰㗎
佢喺樓下等緊你
你噉都信得過嘅

于是网络会学到：

嘅 经常出现在什么视觉/语言环境
喺 经常跟什么字符共现
咗 常出现在哪里

但最终部署仍然只是：

visual encoder + CTC

不像 Qwen/GLM 带一个自由生成 decoder。

这是一个很漂亮的折中。

所以我现在会怎么设计第一轮

不再只训 PP-OCR。

而是同一份数据训两个模型：

A — SVTRv2-Canto

初始化：

Cht-SVTRv2 best.pth

字表：

Cantonese expanded charset

输入：

48px 高，动态宽度

decoder：

CTC / RCTC 做一次对照

B — PP-OCRv5-Canto

初始化：

官方 PP-OCRv5_server_rec

同样的数据。

同样的 train / validation / real-video test。

然后只看真正有意义的五个指标：

谁赢就用谁。

而不是事先根据通用 benchmark 猜。

我的预判

对于：

非常规整的港剧/电影/YouTube 横向字幕

我现在其实略微看好 SVTRv2。

对于：

各种字体、各种截图、文档、弹幕、艺术字、竖排混在一起

我更看好：

PP-OCRv5。

你的目标如果就是很纯粹的：

粤语正字硬字幕 OCR

那 domain 足够窄，SVTRv2 的专用 STR architecture 很可能能发挥得特别好。

所以我会修正前面的建议：

第一轮主线不要“PP-OCRv5 一家独大”；应该让 Cht-SVTRv2 → Cantonese subtitle fine-tune 和 PP-OCRv5 → Cantonese subtitle fine-tune 正面对打。

而且 Cht-SVTRv2 这个刚出现的繁中 checkpoint 是目前我看到最值得利用的资源之一。它已经替我们烧掉了“2300 万张繁中文字图从零学 glyph”的成本。(GitHub)

如果你要继续往下走，我建议下一步就具体研究 Cht-SVTRv2 的 best.pth 能否无损扩充粤语字符表，包括它 checkpoint 里的 classifier key、12,217→新字表的 weight transplant、SGM/RCTC 到底保留哪个，以及第一轮适合 24GB/48GB 显卡的训练配置。这一步做完就基本可以直接开训了。