输入法装上了却永远不在列表里——自动回复打字链注册表里缺的条目

现象同一个字大图全对小字恒错系统里有一处标题文字识别的需求从界面截图里读出会话标题栏的名字拿去做身份匹配。测试集上识别准确率一直不错直到有用户反馈匹配不上人——把识别结果和真名一对“宇被认成了字”两个字形近人都差点看走眼。复盘数据时发现一个规律大图里的同一个字识别几乎不出错出错的全部集中在小字号场景。这不是随机噪声是系统性的误读。## 归因把错误拆成三层头一层墨芯尺寸。量了像素后发现这类标题的文字在原始截图里的墨芯笔画实际覆盖的像素范围只有 12 像素上下。通用 OCR 模型的训练数据以正常文档字号为主12 像素已经落在它的舒适区之外。笔画少一个像素“宇上面的宝盖头就缺了角模型的判别边界就滑向了形近字。第二层合成样本的不对称性。为了搞清模型到底怎么看这个字我们用标准字体合成了一批样本喂进去测。结果呈现出明显的不对称形近误读的例子里错误结果的置信度反而常常高过正确结果——模型很自信地认错了。这意味着靠置信度阈值过滤错误这条路走不通它筛不掉自己最自信的错误。合成测试还给出了一个反直觉的数据某些字在合成样本上错率固定、方向固定恒错向同一个形近字这说明问题在特征层不是采样抖动。第三层裁剪分辨率。翻识别引擎的源码发现一个隐蔽行为检测模型框出文字区域后识别模型做裁剪时取的是原始分辨率的图没有任何放大。也就是说检测和识别两段各自工作中间没有一个把小字放大再认的环节。检测框框得再准递给识别模型的还是那 12 像素的小图。## 修法窄带放大塞回原链路对症的修法是在检测与识别之间加一道放大对检测框所在的窄带区域做两倍最近邻放大再把放大后的图递给识别模型。选窄带而不是整图放大是为了控制耗时——只放大真正要认的那一条整帧处理时间几乎不变。实现时有两个细节。一是坐标系的换算窄带放大后识别结果返回的坐标处于放大坐标系里要除回去再交给下游这一步漏了就是成片的坐标错位。二是失败降级放大路径自身也可能失败极端比例、内存约束此时必须退回原始分辨率路径继续走完流程把错误向上抛而不是把回复吞掉——识别不出来只是体验降级吞掉回复就是事故。上线后用之前攒的误读样本集回归36 个历史错例全部转正整帧耗时无可感变化。## 泛化处理链路交接处的问题先看两段各自拿到什么这次排查里误读的锅既不完全在模型12 像素确实超出舒适区也不完全在用法链路交接处把小图原样递了过去而在两者叠加。分开看每一段都没坏”合起来就是系统性错误。由此沉淀一个排查习惯遇到识别/解析不准类问题别急着调参先把链路在交接点切开检查两段各自实际拿到什么——尺寸多少、坐标在哪、格式是否被隐式转换。链路问题九成藏在交接处而交接处恰恰是两边都以为自己不用负责的地方。## 为什么选择放大而不是换模型评估修复路径时换一个对小字更友好的识别模型是 obvious 的备选最后没走这条路原因说给同行听。成本结构不同。换模型意味着标注数据、训练算力、评测集重建以及新模型在其他识别场景的回归风险——通用识别在我们的链路里承担着多个场景为一个场景换心脏牵一发动全身。窄带放大是纯工程手段改动局限在链路的一个交接点行为可解释放大后墨芯从 12 像素到 24 像素回到模型舒适区出问题可回退退回原路径即恢复原状。效果也经过了对照同一批合成样本放大前后错率从三成降到接近全对真实误读样本三十六例全部转正。放大并非万能——它放大信号的同时也放大噪点对本身模糊的图帮助有限——但我们的场景是屏幕截图渲染的小字边缘干净放大的收益稳定。回归集的治理也值得一提。所有历史误读样本入了库命名带上场景与字体信息每次识别链路的任何改动模型升级、预处理调整、放大参数变化都要全量跑一遍。这个集子的价值随时间复利每一个线上新误读案例处理完都变成库里的一条链路的可靠度是被真实世界的多样性一口一口喂出来的。放大的插值方式也对比过。最近邻插值保边缘锐利适合渲染字这种边缘干净的小字双线性更平滑适合本身发虚的图。我们场景以屏幕截图为主选了最近邻同时给放大后仍识别失败的图留了重试机制——换插值方式再试一次仍失败就降级走原路径并上报样本。这段设计的核心思想是不要单点押注放大不是魔法它是把大概率事件变成更大概率剩下的小概率要有出路。还有一层经验关于「正确答案的观测」。形近字误读特别阴险的地方在于它产出的文本看起来完全合理下游无法怀疑。我们因此给身份匹配加了双重校验——识别结果与已知名单精确匹配之外的形近提醒机制识别出形近对时打标并走人工复核而不是默默放进匹配。这个机制的输入正是回归集里那批形近误读的字表。错误不可避免时尽早暴露错误比假装没有错误更能保住下限。## 参考文章-微信语音怎么转文字3 种场景方法 让 AI 自动听语音回客户- 微信 AI 自动回复机器人怎么用关键词与 AI 理解的差别