精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
语音识别训练很多细节，要会分析日志里的内容，本文就是关于日志里内容的解析线索。
亲爱的卡尔迪斯，
我遇到了一个使用“fmllr”进行无监督适应的问题。
由于 Dan 的“fmllr”能够处理这种基于话语的适应（只需要几秒钟的适应时间），因此我运行了通常的 Kaldi 脚本“基本 fmllr”用法以进行基于话语的适应。
与没有'fmllr'（合理）的情况相比，实现了显着的改进。
现在，我想使用所有测试数据（约 100 个话语，假设我得到了它们）来调整模型，以获得进一步改进的结果，作为与基于话语的模式相比的全批次模式。我想结果会随着更多的适应数据而得到改善，而不是仅仅用一个话语，如果有错误，请纠正我。
然后 'fmllr' 仍然用于完成这项任务，但是 'utt2spk' 'spk2utt' 只包含一个说话者 ID 而不是每个话语的不同 ID，因为我将所有测试话语分配给一个说话者，让 'fmllr' 知道他们一起使用以适应模型。
我认为 HTK 使用回归树 'MLLR' 和 'CMLLR' 来实现这种无监督的适应，并有足够数量的可用测试数据。
然而，结果与没有适应的原始结果几乎相同，并且比每个话语仅使用'fmllr'的情况差得多。换句话说，带有一个说话者 ID 的“fmllr”并没有增强那里的任何东西，或者没有充分利用整个数据。
一些猜测：
1：基础'fmllr'不适合使用整个测试数据来更新模型的任务，或者没有必要这样做，因为一个简短的适应数据就足够了
2：或者除了'basis fmllr'之外还有其他一些脚本来实现这样的像 HTK 和回归树一样，采用全批次模式进行无监督适应。
提前致谢 ！！！
费
随着数据量的增加，基础 fMLLR 应该与常规 fMLLR 等效，因为它使用越来越多的基础组件并最终与常规 fMLLR 相同。但这是有一个类的fMLLR ，它不是回归树 fMLLR。查看志中每帧的目标函数改进。可能是
当您将所有话语混为一谈时，您获得的改进要少得多，因为录音条件不同，或者因为您在测试时使用同一个扬声器进行训练（在这种情况下，显然没有什么可学习的）。
我们已经在代码级别实现了regression-tree MLLR和fMLLR，并且有二进制文件（搜索“regtree”），但是s5脚本中似乎没有相应的脚本。如果您可以
实现这一点，并且有帮助，我们可以添加脚本。
谢谢回复。
我检查了目标函数的改进，它们非常小，0.007……
但是，使用的适应/测试数据记录在相同的环境中，这可能会为模型提供一些适应增益。
您提到的“regtree”是一些二进制文件，例如“gmm-est-regtree-fmllr”、“gmm-est-regtree-mllr”，对吗？
具有大量适应数据，此回归树 fmllr 的性能是否会比具有一类或 ??? 的基础 fmllr 更好？
感谢您的进一步评论！！！
谢谢回复。
我检查了目标函数的改进，它们非常小，
0.007 ...
这听起来太小了，如果你能从日志中粘贴一些行，这样我就可以确切地明白你的意思了。可能是它对某事进行了多次迭代，而您只报告了最后一次迭代 - 或者可能是出现了问题。还请向我展示
您改编的单个话语中的可比日志行。
然而，使用的适应/测试数据记录在相同的环境中，这可能会为模型提供一些适应增益。
是的，如果它与训练数据的环境不同。
您提到的“regtree”是一些二进制文件，例如
“gmm-est-regtree-fmllr”、“gmm-est-regtree-mllr”，对吗？
具有大量自适应数据，此回归树 fmllr 的性能是否会优于
具有一类或 ??? 的基础 fmllr
是的，应该。
嗨，丹，
也许我只是告诉上次迭代目标改进。
一些日志信息在这里：
LOG (gmm-est-basis-fmllr-gpost:main():gmm-est-basis-fmllr-gpost.cc:165) For speaker t10c0203, auxf-impr from Basis fMLLR is 3.08658, over 599.283 frames, the top 119 basis elements have been used
LOG (gmm-est-basis-fmllr:main():gmm-est-basis-fmllr.cc:165) For speaker t10c0203, auxf-impr from Basis fMLLR is 0.17044, over 598.36 frames, the top 119 basis elements have been used
LOG (gmm-est-fmllr-gpost:main():gmm-est-fmllr-gpost.cc:140) For speaker dev1, auxf-impr from fMLLR is 1.29472, over 47325 frames.
LOG (gmm-est-fmllr:main():gmm-est-fmllr.cc:140) For speaker dev1, auxf-impr from fMLLR is 0.0447316, over 47836.8 frames.
LOG (gmm-est-fmllr:main():gmm-est-fmllr.cc:140) For speaker dev1, auxf-impr from fMLLR is 0.00752795, over 48207.8 frames.
'dev1' 包含所有无监督的测试数据，我修改为 fmllr 迭代 3 次（原始为 2 次）。然而，结果仍然没有显示出改进......
好的。大多数改进是在第一次迭代中，这是正常的。
因此，每个扬声器的展示次数约为 3.1，或将所有扬声器组合时的展示次数为 1.3 。这在我期望的范围内。
可能您的测试数据太少，无法看到统计上非常显着的改进。在组合所有扬声器时，我希望从适应中得到小的改进。
您当然可以尝试多类 fMLLR，但就像我说的那样，您必须编写方案。你也可以试试MAP适配；见steps/map.sh
周末我尝试了脚本'steps/map.sh'，但是，结果没有显示任何有希望的。我做了：
1：通过使用来自正常 HMM-GMM 模型的解码输出 .tra 文件获得
测试数据的对齐方式 2：使用整个测试数据及其对齐方式进行 MAP 适配
3：使用适配模型来识别再次测试数据
每帧大约有 1.25 个目标函数改进，WER 减少的绝对改进仅为 ~0.4% ......
或者我做错了一些步骤~
好的，我想我们正在谈论脚本步骤/decode_with_map.sh...
我的原始电子邮件中有一些星号，但一些电子邮件阅读器将它们删除了。
预计你不会得到那么大的改进，map 不是一个非常强大的适应技术。可能您的数据与训练足够相似，或者数量太少，因此适应自然不会带来太大的改进。
是的，我认为 'steps/decode_with_map.sh' 更适合我的任务，与我之前尝试过的结果相比，我得到了相似的结果。换句话说，改进仍然很小。我不确定在正常的“MAP”或一类 fmllr 之前，“回归树”方法有多少增益。也许我用 HTK 做了一个实验来检查相同数量的测试数据，以确保使用多类 fMLLR 编写脚本是值得的。