OpenLess 中文文档 下载 App

同音字与形近字识别——光标上下文如何帮助润色模型消歧

中文同音字问题有多严重

中文的语音识别(ASR)面临一个英文不存在的挑战——同音字太多了。随便列几个:

正确写法同音错误语境
接口借口API 的接口设计
账号帐号用户账号注册
权利权力用户权利 / 公司权力
必须必需必须遵守 / 必需元素
截止截至截止日期 / 截至目前
度过渡过度过假期 / 渡过难关
制定制订制定法律 / 制订方案
反应反映用户反应 / 反映问题

ASR 听出来的声音完全一样。没有上下文的纯声学识别无法区分。

光标上下文怎么解决

开启光标上下文后,润色模型在处理转写文本时同时能看到光标前后的文本。它不是瞎猜,而是:

  1. 看转写文本里哪个词有歧义
  2. 看光标上下文里这个词应该属于什么语境
  3. 结合语境判断正确写法

具体示例

场景:你在 VS Code 里写代码注释,光标位置:

# 这个 API 的 ____ 设计需要考虑错误处理
def process_request(...):
    pass

你按住热键说:「这个 API 的接口设计需要考虑错误处理」

不开光标上下文

步骤结果
ASR 转写「这个 API 的借口设计需要考虑错误处理」
轻度润色「这个 API 的借口设计需要考虑错误处理」(模型瞎猜,保留了错误)
清晰结构「需求:关于 API 借口设计的错误处理考虑」——还是错的

开光标上下文

步骤结果
ASR 转写「这个 API 的借口设计需要考虑错误处理」
轻度润色「这个 API 的接口设计需要考虑错误处理」← 修正了!

润色模型看到光标上下文里有「API」「process_request」「def」这些编程关键词,结合转写文本判断——这里肯定是「接口」不是「借口」。

光标上下文还能帮助什么

除了同音字消歧,光标上下文还能:

帮助说明
保持前后术语一致你在正文里已经用过「OpenLess」,模型不会把转写里的「open less」再润色成其他写法
纠正专有名词词典里没加的专有名词,如果光标上下文里已经出现过正确写法,模型能自动匹配
理解技术缩写光标上下文里有 HTTP / JSON / API 等缩写时,模型能正确理解转写里的相关术语
保持文风一致如果光标上下文已经是正式书面语风格,模型润色时会保持同样的正式度

配合词典效果更好

光标上下文是语义层面的判断,词典热词是 ASR 识别层面的注入。两者配合:

  1. 词典里有的专有名词 → ASR 直接识别正确 → 根本不会出错
  2. 词典里没有的普通同音字 → ASR 可能错 → 光标上下文帮润色模型修正
  3. 既不在词典里又没有足够上下文的 → 润色模型可能还是会错 → 这时建议手动修正

局限

光标上下文能解决绝大多数同音字问题,但不是万能的:

对于这些情况,建议手动纠正,OpenLess 的自动学习功能(实验)会把你纠正的词加入词典——下次就不会再错了。