kaldi002 -- kaldi是如何使用决策树的

亦凉 2022-06-15 12:51 221阅读 0赞

**Kaldi 是如何使用决策树的**

**介绍**  
  
本页概述了Kaldi中如何构建和使用语音决策树，以及如何与训练和构建图相互作用。有关内部构造的代码描述，请参见决策树内部结构;有关我们构建解码图的方法的更多细节，请参阅解释Kaldi中的解码图的构建。  
  
基本算法是自上而下的贪婪拆分来实现，我们可以通过询问左音素，右音素，中间音素，我们所在的状态等方式来分解数据，等等。我们实现的算法类似于标准算法，参见Young，Odell和Woodland的“基于树的状态绑定高精度声学建模”一文。在该算法中，我们通过询问本地最优问题，即给出似然度增加的问题，将数据分开，假设我们通过单个高斯模型分割的每一侧的数据。与标准实现的区别包括如何配置树根的增加的灵活性;提出关于HMM状态和中心音素的问题的能力;并且事实上，默认情况下，Kaldi脚本中的问题是由数据的自顶向下的二聚类自动生成的，这意味着不需要提供手工生成的问题。关于树根的配置：可以将单个共享组中的所有音素的所有统计信息（包括关于中心音素和HMM状态的问题）（或者具有单个音素）或HMM-音素状态，或者是单个分裂的树根，或者有一组音素是树根。有关如何使用标准脚本进行配置，请参阅数据准备。实际上，我们通常让每个树根对应一个“真正的音素”，这意味着我们将所有的单词位置相关，音调依赖或每个音素的压力相关版本组合成一个成为树根的组。

这个页面的其余部分主要提供了代码级别的细节。

**语音上下文窗口**  
  
这里我们解释我们如何在我们的代码中描述语音语境。  一个特定的树将有两个整数值来描述上下文窗口的宽度和“中心位置”。 下表总结了以下值：  
  
**代码中的名称 命令行参数中的名称 值（triphone） 值（单声母）  
Ñ -context-width=？ 3 1  
P –central-position==？ 1 0**

N是上下文窗口的宽度，P是指定的“中心音素”的标识。 通常P正好在窗口的中间（因此名称为“中心位置”）; 例如，N = 3，我们通常会有P = 1，但是你可以自由地选择从0到N-1的任何值; 例如，P = 2和N = 3表示两个左上下文的音素，没有右上下文。 在代码中，当我们谈论“中心音素”时，我们总是意味着第P个音素可能实际上也可能不是上下文窗口的中心音素。

表示典型三音素上下文窗口的整数向量可能是：

**vector <int32> ctx\_window = \{12，15，21\};**

假设N = 3并且P = 1，这将代表具有21的右上下文和12的左上下文的音素15.我们处理结束的方式是使用零（这不是有效的音素，因为它在OpenFst中保留用于 epsilon，意思是“无符号”），例如：

**vector <int32> ctx\_window = \{12，15，0\};**

意思是音素15，左上下文为12，没有右上下文，因为它是句子的结束。 特别是在话语结束时，以这种方式使用零可能有点意想不到，因为最后的“音素”实际上是后续符号“$”（参见制作上下文转换器），但是为了方便决策树代码我们不将后续符号放在这些上下文窗口中，我们置零。 注意，如果我们有N = 3和P = 2，上述上下文窗口将是无效的，因为它的第P个元素将为零，这不是真正的音素; 当然，如果我们有一个N = 1的树，上面的窗口都不会有效，因为它们是错误的大小。 在单音素的情况下，我们会有一个窗口：

**vector <int32> ctx\_window = \{15\};**

所以单音素系统只是被视为一个特定情况的上下文相关系统，窗口大小为N，而一棵树不做任何事情。

**建树过程**

在本节中，我们将概述Kaldi的建树过程。

即使是单音素系统也有一个决策树，但是一个微不足道的一个;  请参阅MonophoneContextDependency（）和MonophoneContextDependencyShared（）函数，返回这些简单的树。 这些由命令行程序gmm-init-mono调用; 它的主要输入是HmmTopology对象，它输出树，通常是作为ContextDependency类型的对象写入名为“tree”的文件，以及模型文件（模型文件包含一个TransitionModel对象和一个AmDiagGmm对象）。 如果程序gmm-init-mono接收到一个名为\-shared-phones的选项，它将在指定的音素组之间共享pdf; 否则会使所有音素分开。

从扁平的开始训练单音素系统后，我们采用单音素对齐，并使用函数AccumulateTreeStats（）（从acc-tree-stats调用）来累积训练树的统计信息。该程序不限于阅读单音素对齐;它从上下文相关的对齐也起作用，所以我们可以基于三音素对齐。树构建的统计信息作为类型BuildTreeStatsType写入磁盘（请参阅构建树的统计信息）。函数AccumulateTreeStats（）取值N和P，如上一节所述;命令行程序将默认将它们设置为3和1，但可以使用\-context-width和\-central-position选项覆盖它们。程序acc-tree-stats需要一个与上下文无关的音素列表（例如静音），但即使有上下文无关的音素，这也不是必需的。它只是减少统计数据的一种机制。对于与上下文无关的音调，程序将累积对应的统计信息，而不需要对应于定义的左和右音素的键（c.f.事件映射）。

统计数据累积后，我们使用程序build-tree构建树。 这将输出树。 程序构建树需要三件事：

统计（类型为BuildTreeStatsType）

问题配置（类型问题集）

根文件（见下文）

统计数据通常来自程序acc-tree-stats;问题集配置类将由compile-questions程序输出，其中包含语音问题集的拓扑列表（在我们的脚本中，这些是由程序集群音素从建树统计过程中自动获得的）根文件指定手机在决策树聚类过程中共享根源，并针对每个音素设置以下两件事情：

“共享”或“不共享”表示每个pdf-class（即经典情况下的HMM状态）是否应该有单独的根，或者是否应该共享根。如果它表示“共享”，则对于所有HMM状态（例如，在正常拓扑中的所有三种状态）将共享单个树根;如果“不共享”将有三个树根，每个pdf-class一个。

“分裂”或“不分裂”表示决定树分裂是否应该实际上针对有问题的根（默认，我们通常不分裂）。如果说“split”（正常情况），那么我们做决策树拆分。如果它说“不分裂”，那么没有分裂，根不被分开。

以下将澄清如何工作：

如果我们说“共享分裂”，即使所有三个HMM状态都有一个根节点，不同的HMM状态仍然可以得到不同的叶子，因为树可以提出有关pdf-class问题以及语音上下文。

我们总是分享出现在根文件单行上的所有音素的根源。  这是不可配置的这些字符串，因为如果你不想共享音素的根，你可以把它们放在根文件的单独行。

下面是一个根文件的例子。  假设音素1是静音，所有其他音素都有独立的根。

**not-shared not-split 1**

**shared split 2**

**shared split 3**

**...**

**shared split 28**

当我们有一些像位置和压力相关的音素的东西时，同一条线上的多个音素是最有用的;在这种情况下，每个“真实”音素将对应于一组整数音素索引。在这种情况下，我们为特定底层音素的所有版本共享根。下面是一个来自华尔街日报的根文件的示例，来自egs / wsj / s5脚本（这是文本，不是整数形式;在被Kalid读取之前必须转换为整数形式）：

**not-shared not-split SIL SIL\_B SIL\_E SIL\_I SIL\_S SPN SPN\_B SPN\_E SPN\_I SPN\_S NSN NSN\_B NSN\_E NSN\_I NSN\_S**

**shared split AA\_B AA\_E AA\_I AA\_S AA0\_B AA0\_E AA0\_I AA0\_S AA1\_B AA1\_E AA1\_I AA1\_S AA2\_B AA2\_E AA2\_I AA2\_S**

**shared split AE\_B AE\_E AE\_I AE\_S AE0\_B AE0\_E AE0\_I AE0\_S AE1\_B AE1\_E AE1\_I AE1\_S AE2\_B AE2\_E AE2\_I AE2\_S**

**shared split AH\_B AH\_E AH\_I AH\_S AH0\_B AH0\_E AH0\_I AH0\_S AH1\_B AH1\_E AH1\_I AH1\_S AH2\_B AH2\_E AH2\_I AH2\_S**

**shared split AO\_B AO\_E AO\_I AO\_S AO0\_B AO0\_E AO0\_I AO0\_S AO1\_B AO1\_E AO1\_I AO1\_S AO2\_B AO2\_E AO2\_I AO2\_S**

**shared split AW\_B AW\_E AW\_I AW\_S AW0\_B AW0\_E AW0\_I AW0\_S AW1\_B AW1\_E AW1\_I AW1\_S AW2\_B AW2\_E AW2\_I AW2\_S**

**shared split AY\_B AY\_E AY\_I AY\_S AY0\_B AY0\_E AY0\_I AY0\_S AY1\_B AY1\_E AY1\_I AY1\_S AY2\_B AY2\_E AY2\_I AY2\_S**

**shared split B\_B B\_E B\_I B\_S**

**shared split CH\_B CH\_E CH\_I CH\_S**

**shared split D\_B D\_E D\_I D\_S**

创建根文件时，应确保每行上至少有一个音素。  例如，在这种情况下，如果音素AY至少在音调和字位置的组合中可见，那就可以了。

在这个例子中，我们有各种基于字位置的静音变体等等。  在这个例子中，他们将共享他们的pdf，因为它们在同一行，并且是“不分裂” - 但是它们可能具有不同的转换参数。 事实上，绝大多数这些静音的变体永远不会被用作静音，不会出现在单词之内; 这是为了将来的设置，以防万一有人在未来发生做奇怪的事情。

我们从之前（例如单音素）构建的对齐来做高斯混合的初始化;  使用程序convert-ali将对齐从一棵树转换为另一棵树。

**PDF标识符**

PDF标识符（pdf-id）是从零开始的数字，用作概率分布函数（p.d.f.）的索引。 每个p.d.f. 在系统中有自己的pdf-id，这些都是连续的（通常在LVCSR系统中有几千个）。 当树首次建成时，它们最初被分配。 对于每个pdf-id，它可能知道也可能不知道，它对应于哪个音素，取决于树是怎么构建的。

上下文相关对象

ContextDependencyInterface对象是树的虚基类，用于指定如何与图构建代码进行交互。 该接口只包含四个功能：

ContextWidth（）返回树需要的N（上下文宽度）的值。

CentralPosition（）返回树需要的P（中心位置）的值。

NumPdfs（）返回由树定义的pdf数量; 这些编号从零到NumPdfs（） \- 1。

Compute（）是为特定上下文（和pdf-class）计算pdf-id的函数。

ContextDependencyInterface :: Compute（）Compute（）函数声明如下：

**class ContextDependencyInterface \{**

**...**

**virtual bool Compute(const std::vector<int32> &phoneseq, int32 pdf\_class, int32 \*pdf\_id) const;**

**\}**

如果能够为此上下文和pdf-class计算pdf-id，则返回true。 返回值为false将指示某种错误或不匹配。 使用此功能的示例是：

**ContextDependencyInterface \*ctx\_dep = ... ;**

**vector<int32> ctx\_window = \{ 12, 15, 21 \}; // not valid C++**

**int32 pdf\_class = 1; // probably central state of 3-state HMM.**

**int32 pdf\_id;**

**if(!ctx\_dep->Compute(ctx\_window, pdf\_class, &pdf\_id))**

**KALDI\_ERR << "Something went wrong!"**

**else**

**KALDI\_LOG << "Got pdf-id, it is " << pdf\_id;**

ContextDependencyInterface当前继承的唯一类是ContextDependency类，它具有更丰富的接口; 唯一重要的补充是由TransitionModel类使用的函数GetPdfInfo来计算出特定pdf可能对应的哪个音素（只有通过枚举所有上下文才能模拟ContextDependencyInterface的接口）。

ContextDependency对象实际上是EventMap对象的相当薄的包装器; 参见决策树内部结构。 我们希望尽可能地隐藏树的实际实现，以便在需要时稍后重构代码。

**决策树的一个例子**

决策树文件格式不是以人的可读性作为首要，而是由于大众的需求，我们将尝试解释如何解释该文件。看看下面的例子，这是华尔街日报语料中的一个三音素树。它以ContextDependency开头，它是对象的名称;那么N（上下文宽度），即3;那么P（上下文窗口的“中心位置”）为1，即音素上下文位置的中心，因为我们处于基于零的索引。该文件的其余部分包含一个EventMap对象。 EventMap是一种多态类型，可能包含指向其他EventMap对象的指针。有关详细信息，请参阅事件映射它是从一组键值对（例如左音素= 5，中心音素= 10，右音素= 11，pdf-class = 2）映射的决策树或决策树集合的表示，到一个pdf-id（例如158）。简而言之，它有三种类型：SplitEventMap（如决策树中的分割），ConstantEventMap（如决策树的叶，仅包含表示pdf-id的数字）和TableEventMap（如表查找包含其他EventMaps）。 SplitEventMap和TableEventMap都有一个“键”，它们在这种情况下是0，1或2对应于左，中央或右上下文，或\-1对应于“pdf-class”的标识。通常，pdf-class的值与HMM状态的索引相同，即0，1或2.尽量不要让它感到困惑：键为\-1，但值为0,1或2，并且这没有连接到上下文窗口中的音素的键的0,1或2。 SplitEventMap有一组值将触发树的“是”分支。下面是一种准BNF符号，它解释了树形文件格式。

**EventMap := ConstantEventMap | SplitEventMap | TableEventMap | "NULL"**

**ConstantEventMap := "CE" <numeric pdf-id>**

**SplitEventMap := "SE" <key-to-split-on> "\[" yes-value-list "\]" "\{" EventMap EventMap "\}"**

**TableEventMap := "TE" <key-to-split-on> <table-size> "(" EventMapList ")**

在下面的示例中，树的顶级EventMap是SplitEventMap（SE），它分割在键1上，这是中心音素。方括号是音素索引的连续范围。事实上，这些并不代表一个问题，而只是一种在音素上分裂的方法，所以我们可以得到每个音素的“真实”决策树。问题是这棵树是用“共享根”构建的，所以有不同的音素索引，对应于同一个音素的不同的字位置和音调标记的版本，共享根。我们不能在树的顶层使用TableEventMap（TE），或者我们不得不重复每个决策树多次（因为EventMap是一个纯树，而不是一般的图，它没有指针的“共享”机制）。 “SE”标签的另外几个例子也是这个“准树”的一部分，这个“准树”最初在中心音素上分裂（当我们进入这个文件时，我们将进一步深入树中;注意大括号“\{”正在开放，但还没有关闭）。然后我们有字符串“TE -1 5（CE 0 CE 1 CE 2 CE 3 CE 4）”，它表示在pdf-class“-1”（实际上是HMM位置）上用TableEventMap分割，并返回值0到4.这些值代表静音和噪声音素SIL，NSN和SPN的五个pdf-id;在我们的设置中，这些三种非语音音素之间共享了这些pdf（只有转换矩阵是每个非语音音素都具体的）。注意：对于这些音素，我们有5状态而不是3态HMM，因此有5种不同的pdf-ids。接下来是“SE -1 \[0\]”;这可以被认为是树中第一个“真实”的问题。我们可以从上面的SE问题中看出，当中心音素的值为4到19，它是音素AA的各种版本时，它适用。问题是询问pdf-class（键\-1）是否具有值0（即最左边的HMM状态）。假设答案是“是”，下一个问题是“SE 2 \[220 221 222 223\]”，这是询问音素是否是音素“M”的各种形式之一（一个相当不直观的问题，因为我们处于最左边的HMM状态）;如果是的话，我们问“SE 0 \[104 105 106 107 ... 286 287\]”这是一个关于右边音素的问题。如果是，则pdf-id为5（“CE 5”），否则为696（“CE 696”）。

**s3\# copy-tree --binary=false exp/tri1/tree - 2>/dev/null | head -100**

**ContextDependency 3 1 ToPdf SE 1 \[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 \\**

**26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59\\**

**60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 9\\**

**3 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 1\\**

**20 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 14\\**

**5 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170\\**

**171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 \\**

**196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 \]**

**\{ SE 1 \[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34\\**

**35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 6\\**

**8 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 10\\**

**1 102 103 104 105 106 107 108 109 110 111 \]**

**\{ SE 1 \[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34\\**

**35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 \]**

**\{ SE 1 \[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 \]**

**\{ SE 1 \[ 1 2 3 \]**

**\{ TE -1 5 ( CE 0 CE 1 CE 2 CE 3 CE 4 )**

**SE -1 \[ 0 \]**

**\{ SE 2 \[ 220 221 222 223 \]**

**\{ SE 0 \[ 104 105 106 107 112 113 114 115 172 173 174 175 208 209 210 211 212 213 214 215 264 265 266 \\**

**267 280 281 282 283 284 285 286 287 \]**

**\{ CE 5 CE 696 \}**

**SE 2 \[ 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 132 \\**

**133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 248 249 250 251 252 253 254 255 256 257 2\\**

**58 259 260 261 262 263 268 269 270 271 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 30\\**

**3 \]**

以下是一个更简单的例子：Resource Management  数据库中的单音素树。 顶级EventMap是一个TableEventMap（“TE 0 49 ...”）。 由于上下文宽度（N）为1，所以键“0”是表示中心（且仅））音素位置为零。表中的条目数为49（在这种情况下，音素数量加1）。 表中的第一个EventMap（索引为零）为NULL，因为没有索引为零的音素。 下一个是具有三个元素的TableEventMap，对应于第一个音素的三个HMM状态（技术上，pdf-class）：“TE -1 3（CE 0 CE 1 CE 2）”）。

**s3\# copy-tree --binary=false exp/mono/tree - 2>/dev/null| head -5**

**ContextDependency 1 0 ToPdf TE 0 49 ( NULL TE -1 3 ( CE 0 CE 1 CE 2 )**

**TE -1 3 ( CE 3 CE 4 CE 5 )**

**TE -1 3 ( CE 6 CE 7 CE 8 )**

**TE -1 3 ( CE 9 CE 10 CE 11 )**

**TE -1 3 ( CE 12 CE 13 CE 14 )**

**ilabel\_info对象**

CLG图（参见Kaldi中的解码图构造）在其输入端具有表示上下文相关音素（以及消歧符号和可能的epsilon符号）的符号。 在图中，一如以往，这些由整数标签表示。 我们使用一个对象，在代码和文件名中，通常称为ilabel\_info。 ilabel\_info对象4与ContextFst对象有很强的连接，请参阅ContextFst对象。 与许多其他Kaldi类型一样，ilabel\_info是一种通用（STL）类型，但是我们使用一致的变量名称来标识它。 它是以下类型：

**std::vector<std::vector<int32> > ilabel\_info;**

它是由FST输入标签索引的向量，为每个输入标签赋予相应的语音上下文窗口（见上文，语音上下文窗口）。 例如，假设符号1500是音素30，其右上下文为12，左上下文为4，我们将具有

**ilabel\_info\[1500\] == \{ 4, 30, 12 \};**

**ilabel\_info\[30\] == \{ 28 \};**

在单音素的情况下，我们会有以下形式：

**ilabel\_info \[30\] == \{28\};**

有特殊情况来处理消歧符号（参见消歧符号或上面引用的Springer Handbook paper 的解释）。 如果一个ilabel\_info条目对应一个消歧符号，我们把它放在消歧符号的符号表项的负数（注意，这与＃0， ＃1，＃2等中消歧符号的打印形式的数量不同，它是一个符号表文件中对应的数字，在我们当前的脚本中称为phones\_disambig.txt）。 例如，

**ilabel\_info\[5\] == \{ -42 \};**

将意味着HCLG上的符号5对应于整数id为42的消歧符号。我们否定这些脚本的方便性，因此解释ilabel\_info对象的程序不需要给出消歧符号列表，以便被 能够将它们与单音素情况下的真实音素区分开来。 还有两个额外的特殊情况：我们有

**ilabel\_info\[0\] == \{ \}; // epsilon**

**ilabel\_info\[1\] == \{ 0 \}; // disambig symbol \#-1;**

**// we use symbol 1, but don't consider this hardwired.**

其中第一个是正常的epsilon符号，我们给它一个空的向量作为其ilabel\_info条目。 这个符号通常不会出现在CLG的左边。 第二个是一个特殊的消歧符号，印刷形式叫做“＃\-1”。 我们在正常（Springer手册）配方中使用它在C转换器的输入上使用epsilons的方法; 在有空语音表示的单词存在的情况下，需要确保CLG的确定性。

程序fstmakecontextsyms能够创建一个符号表，它对应于ilabel\_info对象的打印形式; 这主要用于调试和诊断。

你可以看到，ilabel\_info对象并不是非常好用，因为它与消歧符号相关，但代码中没有很多部分与它进行紧密的交互：只有fst :: ContextFst类（和相关的东西;见“上下文扩展相关的类和函数“），程序fstmakecontextsyms.cc，以及在类和函数中列出的一些功能，用于从HMM创建FST）。 ContextDependency对象尤其仅仅看到代表音素上下文窗口的长度为N的有效序列。