夜雨聆风这周我做了一次真正意义上的架构改动。没有调参，也没有堆数据，只往模型里加了一个很小的模块。改动不大，却把过去几周零散的经验串成了一条线。
先说结论：语音模型微调，其实要面对两个上限。
一个是感知上限，决定模型能不能听清某个方言的口音和发音，能不能在噪声里把声音特征提取出来。这个能力主要来自接收语音信号的编码部分。另一个是决策上限，决定模型拿到声音之后能不能写出正确的字，尤其是关键短语该出现的时候能不能把它写出来。这个能力主要来自后面的语言模型和输出环节。
这两个上限，一个管听得见，一个管写得对。感知上限和决策上限，一个像表层功夫，一个像底层功底，都很重要。
一、听懂方言，只是表层目标
这周我继续在做某个方言场景的语音识别，目标是让模型在真实口音里，依然能抓住几个关键短语。
为了这个目标，最自然的做法是继续加数据。多造例句，多合成音频，让模型多听几遍，它总会更熟。但做了几轮之后我发现，这条路越走越像表面功夫。
模型确实更听得懂这个方言了，可真正要解决的核心问题并没有动：关键短语的召回率不够，准确率也不够。该出现的时候它可能漏掉，不该出现的时候它可能误报。这两个指标，一个管该说的说出来，一个管不该说的别乱说，缺一个都不行。
听懂方言，只是把模型往前推了一层。热词能不能被稳定地想起来，是另一层问题。
二、堆数据为什么是表面功夫
为什么堆数据不够？可以这样理解：模型见过的句子越多，对常见说法越熟，但遇到没见过的说法、近音词，或者关键短语藏在句子中间的位置，依然可能漏掉。
更麻烦的是，如果只训练这句话里有热词的正样本，模型容易学会偷懒：听到关键词提示就往热词上靠。加上这句话里没有热词的负样本之后，它才被迫回到音频证据本身，判断这个热词到底说没说。
所以真正要提升热词召回和精确率，不能只靠数据量，还要从模型内部结构入手。
三、第一次架构改动：加一个偏置型小模块
作为产品经理，第一次碰架构改动，我选了一个偏置型的小模块。思路很简单：在模型输出的时候，给热词对应的结果加一点偏向，让它更容易被写出来。
这个思路在语音模型里早有先例，很多模型都做过类似的事情。尤其是在注意力机制成为主流的时代，一个通用做法是让热词进入注意力机制，让模型在推理的每一步都能看见这份清单，再据此提高热词输出的概率。我的第一次尝试，也是照着这个方向走的。
但真正开始改之后，问题一个接一个：小模块应该加在模型的哪个位置？偏置应该作用在哪一次输出上？怎么设计开关，才能在有热词时打开、没有热词时关掉？热词表能不能只在推理时传入，而不写死在模型里？说话人的音色特征，能不能和说话内容分开，不让音色影响热词判断？
这些问题，没有一个可以拍脑袋决定。
四、别急着原创，先学会迁移
刚开始的时候，我也试过让 Coding Agent 直接帮我改。Agent 确实能把输入输出维度对接好，代码也能跑起来，但效果很一般。
原因其实不复杂：一个没有见过类似架构的 Agent，只能按接口把模块接上去，很难理解这个模块应该在什么位置、以什么方式起作用。
后来我换了一个做法：放下原创的念头，回去翻以前读过的论文，找和当前问题最像的架构，再定位对应的开源仓库。我这次参考的，是 FunASR 里已经验证过的热词机制。它和我要做的场景很像，都是让模型在推理时知道一份热词清单，并且不依赖把清单写死在模型里。我让 Agent 先学习它的设计，把结构迁移过来，再根据我们的模型做调整。
这一步很关键。它意味着，在算法工作里，**知道去哪里找答案，比记住一个答案重要得多。**产品经理平时积累的论文阅读和架构理解，在这里会真正变成生产力。
五、迁移和试错是算法工作的常态
迁移常常要试很多次才能成功。我第一次把结构搬过来时，模型对训练时见过的热词效果不错，可换一批新热词就退化。问题出在训练方式，结构本身没有问题。后来我参考原项目的训练思路，让模型在训练时接触大量随机文本片段，不再固定背一张热词表，效果才稳定下来。
这个过程中我意识到，**算法岗位的日常工作，很大程度上就是试错。**大公司里的算法工程师，每天面对的就是这条路走不通、换一条的循环。新入职的算法工程师，理应有一段适应期，至少一个月，用来排除错误的技术路线，找到正确的方向。即使方向是对的，也需要多次试错，才能形成一套合理的架构方案。
如果企业把新人当成上来就能出结果的机器，反而会逼着他们走最熟悉但最不合适的路线。
六、想象力来自基本功
在 Coding Agent 时代，算法问题的难度变了。逻辑能力依然重要，但更稀缺的是迁移能力、联想能力，甚至是想象力。
同样一个问题，有人只会等 Agent 报错再修，有人能想到这个机制在另一个模型里已经解决过。后面这种能力，来自平时认真读论文，来自对模型架构基本功的持续积累。
所以这周我最深的体会是：架构改动打开了一扇门，但门后面没有捷径。真正决定能走多远的，是脑子里有没有足够多的架构地图；会写多少代码，只是把想法变成现实的手段。
写在最后
回到开头说的两个上限。感知上限让模型听得清，决策上限让模型写得对，两个上限都要补。
堆数据解决不了所有问题，架构改动也常常要试很多次才能成功。对技术产品经理来说，真正的价值在于：知道问题出在哪一层，知道该去哪里找参考，也能在一次次试错里判断方向对不对。
AI 时代执行变得越来越快，判断和想象力反而成了最稀缺的东西。
参考资料
https://github.com/modelscope/FunASR https://github.com/stepfun-ai/Step-Audio2
