1. 为什么“个人词典就等于替换”这个思路一开始就错了1.1 个人词典到底解决了谁的什么问题先聊个场景。你用了很久的听写输入工具日常听写一些专业内容比如病历、法律文书、产品名、人名。听写引擎每次把你的口头内容转成文字时总会把一些词转错比如你说“胃镜”它给你出“味精”你说“汇票”它出“会票”你说自家产品的代号“云岚”它永远识别成“云蓝”。于是你打开个人词典把这些词一个一个添加进去指望下次听写时它能乖乖给出正确结果。这个需求非常真实。几乎所有主流输入法、听写软件、语音转写工具都提供了“自定义词”或“个人词典”的功能逻辑也几乎一样当你发音对应的识别结果与词典里的词条匹配时就把识别结果替换成词典词条。用户要的就是一个确定性我说“云岚”你就必须给我输出“云岚”。到这里一切都好。问题出在“必须”这两个字上。我在实际使用和开发听写功能的过程中逐渐意识到一个矛盾个人词典的表达能力其实非常弱它只记录了两件事——一个词条和它对应的读音或拼音串。用户以为自己在定义“规则”但系统实际做的是“无条件替换”。而语言是在语境里运行的脱离了上下文去替换几乎必然误伤。1.2 “一刀切”纠错的三类典型翻车现场我们用三个真实高发场景来说明为什么“无条件替换”很危险。第一类是同音异义词串的误伤。用户的个人词典里添加了一个高频词“图像生成”它对应的拼音串是“tu xiang sheng cheng”。但同样的发音在“图像生成模型”里没问题在“对象生成报告”这句口语里识别引擎本来正确输出了“对象生成”可因为个人词典的替换逻辑是按拼音整体匹配的“对象生成”和“图像生成”的拼音并不完全相同“对”是dui“图”是tu这个例子里的替换未必会发生。但换一个例子就明显了你添加了词条“传输”对应“chuan shu”有一天你说“船书”这个古籍术语拼音也是“chuan shu”引擎可能本来识别对了“船书”结果被个人词典强行替换成“传输”。这就是典型的替换误伤。第二类是跨场景干扰。某个做医疗信息化的人在个人词典里添加了几百个医学术语比如“冠状动脉”“心肌梗死”。这些词对他来说每天都要用但对同一个用户输入法的另一条语种通道、另一个输入场景比如给朋友发消息聊天来说一旦出现“关状动脉”这类口语发音用户本意是打字聊天却会被替换成医学术语聊天内容变得很生硬。第三类是品牌名与通用词的冲突。你在个人词典里加了“企查查”或者某个产品名如果你的产品名与高频率通用词发音相似比如“某某地图”和“某某地图”那用户平时说“某某地图”时系统可能会错误地替换成另一个产品名。对这种冲突传统的全局替换策略完全没法区分。这三类问题说明一件事只看“读音是否匹配”忽略了“这句话在说什么”。1.3 从“替换思维”切换到“决策思维”所以后来我们在设计听写引擎的个性化模块时刻意做了一次思路转换个人词典不再是“查到了就替换”的规则表而是“参与候选排序的一个先验信号”。这句话怎么理解正常的语音识别流程并不只是把读音转成唯一文字。它的核心是给定一段声音信号在巨大的词图和语言模型构成的搜索空间里找出概率最高的那一串文字。中间会产生大量候选结果。个人词典如果在识别前介入做硬替换等于直接把搜索空间砍掉一块把“可能的正确答案”也一起砍了。但如果把个人词典作为一个加权先验放进去让它在候选集里提高与用户词条相关的结果的分数那么用户在说“冠状动脉”时它会被选中用户在说“关状动脉”时如果上下文明显指向一个轻松场景候选里正确的通用词依然有概率胜出。这就是Entune这套方案的基本立场不让个人词典拥有“最终解释权”而是让它获得“影响力”。具体怎么做到接下来拆开讲。2. Entune 语境感知听写的整体架构思路2.1 语境信号从哪里来上下文窗口不是越长越好要避免“一刀切”前提是系统能感知“当前这句话在说什么”。那感知的输入是什么一般有三个来源。第一个来源是上文已经识别出的文字。语音识别是按句子实时推进的在判断当前这个候选词时前面几百毫秒到几秒里已经出了几个字或十几个字这些文字提供了最直接的语境线索。比如前文已经出现了“心脏”“血管”那后面出现“shu zhi”的时候把“舒张”排在“树汁”前面的把握就大得多。第二个来源是句子的整体结构信号。一些轻量的句法特征比如当前位置的词性可能性、前后词的搭配强度都能提供补充。这里要说明Entune没有做特别复杂的深度学习句法分析而是用传统的N-gram语言模型概率加一部分上下文特征因为听写场景对延迟非常敏感句法分析的耗时很难压到实时范围内。第三个来源是场景信号。这一点很容易被忽略。同样是“胃镜”这个词在一片默认的美式英语语音环境里你很可能根本不会说中文。但如果你手里有双拼和语音输入并存的中文场景说“胃镜”就非常自然。场景信号可以由用户输入法当前的模式、语言栏状态、甚至应用身份比如正在用一个笔记软件辅助判断。上下文窗口长度我在实践中的经验是向前看最多15~20个字就够用了。再往前的信息看似更多但占比很低还容易引入噪声。比如用户前半句在说工作后半句突然转去聊家常窗口太长反而把无关主题拉进来导致个人词典在整句话里的权重被稀释或错误放大。2.2 个人词典条目的“场景标签”与“通用度评分”那么个人词典里的词条怎么和语境信号对接这里需要给词条本身做一些元信息扩展。传统个人词典只有两列拼音串、词条文字。但要做语境感知至少要再加两样东西。第一样是通用度评分。这个词在所有用户日常用语里出现的自然程度有多高比如“输出”是通用词任何场景都自然“心肌梗死”则是领域词只在医学语境里自然。这个评分可以用一个基础语言模型来估计把一个词放到大量混合语料的上下文里看它的概率。通用度低代表这个词强烈依赖特定场景通用度高代表它几乎可以在任何地方出现。第二样是场景标签。这个词默认偏向哪些场景医学、法律、技术、游戏、影视娱乐、日常闲聊……用户添加词条的时候系统可以帮助自动识别一个候选标签比如“心肌梗死”默认标给“医学”用户也可以手动改。没有这个标签系统只知道“这个词要优先”不知道“什么时候优先”。有了这两个元信息决策逻辑就活了。当我听到一段声音识别出一组候选词其中包含一个个人词典词条“心肌梗死”同时当前句子的上文里出现过“心电图”“胸闷”场景信号也指向医学那么这个词条会被赋予一个比较大的加分。如果上文是“今天中午吃什么”那这个词条不但不加分反而会因为通用度低被压一压。刻意压一压这件事是“避免一刀切”的关键。很多听写系统只会在识别结果里找和词典读音相同的词找到了就替换根本没想过“当前语境适不适合”。一个语境感知的词条应该既能推动正确结果上位也能在错误语境中主动退让。2.3 一个具体案例从“烟酰胺”到“烟酰胺”我举一个很有代表性的例子。假设某个用户是做护肤成分研究的她的个人词典里有一个词“烟酰胺”对应拼音“yan xian an”。问题在于“烟酰胺”和“烟酸安”“盐酸胺”都有相似的发音片段。用户在语音输入时说了这样一句话“这个配方里要加百分之三的烟酰胺。”在识别引擎的候选序列里原本“烟酰胺”和“烟酸安”的分数接近传统个人词典逻辑会直接把“烟酸安”硬改成“烟酰胺”因为读音匹配。效果似乎很好。但同一天用户给朋友发消息说“上次说的那个药膏你查了吗那家店卖的盐酸胺。”这句里的“盐酸胺”拼音也是“yan suan an”和“烟酰胺”读音差异很大这个例子不严谨。我换一个更准确的用户说“要把烟酰胺浓度调低”但前文在讲药膏成分实际想说的是“含水杨酸”这两个词的发音差异较大替换不会发生。真正容易出事的是这种用户说“这个实验要控制烟酰胺的用量”结果上文在讲“农业土壤烟酰胺转化”对一个农业背景的用户来说“烟酰胺”这个词在他的词典里其实是“土壤中的烟酰胺态氮”他根本不想把这句话替换成护肤成分。于是我们需要用上下文的语义来判定。这就是语境感知的胜负手同一个词条在不同上文里要得到完全相反的待遇。这个例子说明与其追求“词条级准确”不如追求“句子级准确”。让个人词典的词条在整句话的概率计算里参与角逐而不是在每一处局部读音上“一票定生死”。3. 实操过程在听写引擎里实现语境感知的四个关键环节3.1 词典结构升级从字典表到带特征向量的词条库这一节直接写可以落地的做法。假设我们手里已经有一个基本的听写引擎后端是常见的WFST解码器或者基于Transformer的端到端模型。要实现语境感知第一步改动的是词典存储结构。传统的个人词典可能长这样字段示例拼音串yan xian an词条文字烟酰胺创建时间2024-05-12现在至少扩展成这样字段示例说明拼音串yan xian an用于初始候选匹配词条文字烟酰胺最终输出候选通用度评分0.320~1之间越低表示越依赖场景场景标签护肤, 化学用逗号分隔支持多标签出现次数156用户实际触发次数动态增量最后使用时间2024-08-01判断词条冷热程度出现次数和最后使用时间虽然在传统设计里也有但在语境感知方案里它们的用途变了——不再只用于“排序”而是用于动态调整通用度评分。一个词条如果用户半年没触发过它的通用度评分会缓慢上调因为它已经越来越像“一个过去的高频词”而不是“一个必须马上生效的强规则”。数据量上个人词条库通常不会超过几万条用SQLite或者一个JSON文件都能存不需要引入重型数据库。但要注意听写引擎的候选生成发生在内存里词典检索必须在解码前完成。所以这些词条每次启动时要被加载进内存构建成一个以拼音串为Key的哈希表。可以按词条的“通用度评分”分桶比如通用度低于0.5的词条单独存到一个活跃库里高于0.5的词条只在需要时做慢速检索减少内存占用。这一步不做的话几万条词条驻留内存对移动端非常不友好。3.2 决策打分函数让词典词条参与排序而不是做硬替换现在核心来了。假设解码器已经给出了一个候选句子“要控制yan xian an的用量”候选词列表里有“烟酰胺”和“烟酰胺态氮”。我们需要决定这一句里“烟酰胺”这个词条该不该被激活我用的方案是设计一个轻量打分函数给每个候选词汇计算一个增量分加到原来的语言模型分数上。逻辑如下原始候选分数S 声学模型分数 语言模型分数。引入词典词条后如果当前候选词与某个词典条目match则S_final S_orig W_scene * scenic_match W_prior * familiarity_score - W_penalty * contextual_conflict这里几个权重系数是在离线验证集上调出来的我的经验值大概是这样W_scene1.2场景标签匹配时的高增益场景不匹配时直接给0不参与W_prior0.6词条本身高频出现的增益用来对抗通用词的自然概率优势W_penalty0.8当词条的通用度极低但当前上下文完全不属于它绑定的场景时给惩罚计算方式就简单了。先看当前句子的场景标签集合。比如上文是“心电图、胸闷、胸痛”这些词经过一个轻量场景分类器输出“医学”标签的概率是0.87。如果当前候选词“烟酰胺”的词典场景标签包含“医学”那scenic_match 0.87 * 1.2。接下来判断上下文冲突。冲突的定义是当前句子主语、谓语、宾语中的名词性成分与词条场景完全不搭。这不需要复杂词法分析我用一个最简单的做法把当前候选词前后的top 5个高频实词拿出来和词条的场景词库做内积。词条“烟酰胺”的场景词库里有“皮肤”“美白”“浓度”“护肤”而当前上文是“心电图”“胸闷”“胸痛”交集是0那么contextual_conflict 0.8。如果交集不为0冲突值按比例降低。实际操作中这种打分函数不需要做成一个复杂的机器学习模型只用一个几十行的规则模块就能覆盖80%的问题。重点在于每个词的权重系数要不断通过badcase迭代来调而不是一次设好就不动。3.3 决策后的兜底什么时候宁可不出词也不能乱出词这个打分的决策框架有一个非常关键的补充逻辑如果候选结果因为词典介入后的分数变化幅度没有超过某个安全阈值那么保持原始解码结果不变。这一点特别重要。你会发现很多听写引擎实现个人词典时一旦词典词条和某个候选词匹配成功就无条件替换语境感知方案如果搞砸了容易变成另一个极端——评分加来加去替换了本不该替换的词。所以要设一个安全阈值。我习惯把这个阈值设为“候选词得分变化绝对值超过0.3才允许替换”。低于0.3意味着系统对当前语境判断的置信度不够高那就别动让解码器原始结果保持。用户如果在接下来的几秒钟里发现这个词还是不对会手动点击修正这个修正行为本身就是最好的训练信号系统可以把这次手动修正记下来调高这个词在特定场景下的触发权重。这个兜底逻辑虽然简单但在用户侧的感受差异很明显一个听写系统如果偶尔不出个人词典里的词用户顶多觉得“这次没识别出来”但如果总是把不该替换的词硬换错用户就会觉得“这东西自作聪明”。两害相权宁可保守。3.4 场景分类器做人人都能用的小模块最后一个实操环节是场景分类器。这里不需要调用大模型服务更不需要GPU推理。我用的是一个经典的轻量文本分类器——朴素贝叶斯加TF-IDF特征训练语料是几万条标注过的日常短句。场景类别一共就七八个医学、法律、科技、教育、金融、日常闲聊、娱乐、编程。有人会问编程也算场景吗算。因为程序员用户经常在个人词典里加变量名、框架名、函数名例如“numpy”“matplotlib”而这些词在通用语料里的出现概率极低如果不做场景区分替换基本就是随机命中。分类器的输入是当前已经转写出的上文文本比如前20个字符输出是每个场景的概率分布。因为只是做文本分类一个普通的轻量模型在手机CPU上的推理时间可以控制在2毫秒以内放在实时听写管线里完全感知不到延迟。分类器的训练数据不用多但场景分布要均匀。这里有一个我在实际迭代中踩过的坑如果语料里医学占比过高分类器会偏向把一切模棱两可的句子都分到医学去导致医学词典词条被滥用。后来做了重采样和类别权重平衡问题才缓解。4. 常见问题与排查技巧实录4.1 用户添加的词条在特定场景下一直不生效听写引擎升级到语境感知方案后最常见的用户反馈是“我明明加了词怎么还是识别错”。排查时先要区分两种原因。第一种原因是词条压根没进入候选。这时候和语境感知没关系是老问题拼音串匹配不上。排查方法是打开引擎的调试日志看用户说那段话时候选词列表里有没有词条的拼音前缀命中。常见原因是用户添加词条时写的是全拼但语音输入用的声母简写或模糊音设置不一致。第二种原因才是语境感知的锅。如果候选词里已经出现了这个词条但最终没有被选中那检查一下打分日志里的scenic_match和contextual_conflict值。我遇到过一个典型case用户在医院场景下说“收缩压”个人词典里有“收缩压”但当时上文是“这个屋顶的面积”场景分类器输出了“工程”标签和词条的“医学”标签不匹配导致scenic_match为0词条完全没有加分。这确实是语境感知的正确行为——用户在聊屋顶的时候说“收缩压”的概率极低。但如果用户在医学场景下也遇到不生效就要检查分类器的置信度是不是太低下文再展开。4.2 场景分类器置信度低导致的“时灵时不灵”场景分类器置信度低是实践中很普遍的现象。比如用户输入的内容混合了技术和日常表达“我今天在改那个接口等一下聊。”前半句有编程场景信号后半句立刻转向日常闲聊分类器可能会给两个场景各50%的概率。这时scenic_match的增益就被平均化词典词条的激活概率跟着下降。我的建议是在工程实现上做一套“场景平滑”机制不要每时每刻都用当前窗口的结果作为唯一判断而是维护一个滑动窗口的场景概率累计值。比如最近5秒内如果编程场景累计占比超过60%那就认为当前处于编程场景即使最近一两秒聊了闲话也不立即切换。这么做的依据是用户通常在同一个输入会话里保持相对稳定的主题切换场景不会瞬间发生。实现上这个累计值可以简单用一个环形数组存最近若干个场景分类结果更新时用指数衰减scene_score scene_prev * 0.7 scene_current * 0.3指数衰减比窗口平滑更省内存而且能快速响应真正的场景切换。这个值我建议放在0.7和0.3衰减过快会导致场景频繁抖动衰减过慢则切换迟钝。4.3 词典词条与基础语言模型的高频词打架另一个常见问题是个人词典里添加了一个词但这个词和引擎内置的词表里的某个高频词拼音完全相同。比如用户添加“小鹿”对应“xiao lu”但基础语言模型里“小路”的概率远高于“小鹿”。在传统方案里个人词典会用替换机制强行让“小鹿”胜出。在语境感知方案里我们只会给它一个先验加分如果语境完全不支持“小鹿”比如上文是“走弯”那么即使加分“小路”仍然会赢。很多用户不理解这个现象会认为自己的词条“失效了”。我的经验是针对这类“同音常用词冲突”主动弹出一个引导提示让用户决定是否要对该词条设置“强制模式”即无论什么语境都替换。这在产品设计上是必要的补充毕竟有些词就是用户的刚需专名比如他自己的名字。强制模式和语境感知模式可以共存按词条维度区分。这种折中方案既避免了全局一刀切又照顾了重语义用户的确定性需求。4.4 实时性问题打分计算不能拖慢听写速度最后分享一个性能排查的真实经验。有一次在集成Entune方案时数据集多了一个新的场景分类器Android端的语音转写延迟从200毫秒涨到了600毫秒。排查后发现不是分类器本身慢而是词典词条的特征向量预计算被塞进了识别主线程里每个词条都要动态计算场景相关度几十万维特征在每次候选生成时重复计算。解决方式是把所有词典词条的特征向量在解码前一次性预计算并缓存。运行时仅做向量的点积与查表开会话内缓存避免重复计算。延迟直接打回200毫秒内存增长不到5MB。如果你在做类似的听写引擎记住一个铁律任何与语境感知相关的计算都应该发生在候选集生成之前或者与候选评分并行绝不能进入实时解码的热路径。如果把特征抽取、场景分类、打分函数全部串在解码过程中延迟一定失控。5. 延伸思考Entune 方案能扩展到哪些场景这套语境感知的思路并不只是给“个人词典”一个更聪明的替换策略它其实可以延展到几个相邻的场景。第一个是专业领域的缩写扩展。技术用户经常输入“RGM”“LTV”这类缩写但纯靠全局替换在很多日常句子里会出现莫名其妙的“RGM”。如果给缩写条目加上场景标签再配合声学上下文判断能做到“在技术文档里自动展开全称在聊天里保持原样”。第二个是多音字的动态读音选择。很多人名地名是多音字例如“乐”可以读“le”也可以读“yue”。个人词典记录“乐乐”为“le le”但对话人说“音乐老师”时读“yue”。语境感知可以发现当前上下文的语义指向哪个读音从而在解码前调整声学模型的发音候选概率这和传统的多音字消歧问题其实是同一个底层难题。第三个是个性化的热词周期管理。流行语、热点事件里的专名往往只在几周内有很高的输入需求。语境感知可以让这类词条在相关话题活跃时权重很高话题冷淡后自然降低不用用户手动去删词条。这直接解决了一个长期痛点用户的个人词库里堆满了过期的梗和旧产品名时不时跳出来干扰正常输入。最后再说几句我的实际体会把个人词典从“替换规则”升级为“语境感知”这个思路技术难度并不算高难点其实在于取舍。你要接受一个事实有些时候系统的确不如用户自己懂他自己强行加规则反而是伤害。很多做输入法的人执着于“用户加了词就必须给”但这个词条本身在错误语境里带来的困惑远比“这回没识别出来”更严重。我在实际迭代中和很多真实用户聊过他们的使用习惯。他们最终最喜欢的状态是系统“大多数时间主动给对偶尔给错也能很快被纠正而且越是新场景越不容易乱来”。这比“时刻都按词典硬来”要有价值得多。如果你也在做类似的东西从“替换”到“决策”的那一步值得你花一个迭代周期去尝试。