大多数语音转文字的对比以一个准确率数字开头，也以它收尾。对泰语来说，从这里起步并不稳妥。这个数字依赖分词器，而泰语本身并不提供分词；决定转写结果能否使用的特性，大多也与准确率无关。一个引擎可以把泰语句子听得完全正确，交回的结果却仍然没有产品能直接用上。
这篇文章是一份测试计划。录下三十分钟您手头真实的音频，逐一送进每个候选引擎，然后检查七件事。每一项都能从一次响应中得到答案。文中不点名任何引擎，包括我们自己的，也不引用任何数字。
1. 时间区间覆盖完整的词#
请求词级时间戳，然后看看返回了什么。有些引擎逐个字符地给泰语计时，因为泰文的书写系统没有提供别的边界。字符级时间区间在技术上算是时间戳，实际上却用不了：按它切出的字幕会在词中间断开，跟读播放器会只高亮一个辅音，搜索结果会定位到一个残缺的片段。
ประชุมวันพฤหัส
per word ประชุม 0.42-0.86 วัน 0.86-1.02
พฤหัส 1.02-1.48
per character ป 0.42-0.47 ร 0.47-0.51 ะ 0.51-0.55
ช 0.55-0.61 ุ 0.61-0.64 ม 0.64-0.86返回第一种形式的引擎已经替您完成了分词。返回第二种形式的引擎则把这个问题交给了您。事后补救，就得在转写文本上再跑一遍分词器，再把分词结果映射回字符级的时间。
2. 可以指定的数字书写规范#
说话人把一个数字念了出来。转写文本可以照着念法写成文字，也可以按文件里的印刷方式写成数字，这是两个不同的字符串。搜索索引要其中一种，字幕文件要另一种，理赔系统则需要能解析的数字。检查引擎是否让您选择，还是替您选好，再把转换的工作留给您。
用一段在同一分钟里同时出现价格、日期、电话号码和百分比的录音来测试。这在呼叫中心不过是一句寻常的泰语，却能把每条规则同时考一遍。
3. 泰语里夹着英语#
说泰语的人常在句子中间直接用英语说出产品名、技术术语和品牌，中间不停顿。发送一段这样的录音，再读一遍返回的那一行。有三种失败值得留意：英语单词被音译成泰文，周围的泰语被丢掉，或者词级时间区间在语言切换处丢了秒数。
4. 如果需要区分说话人#
通话里有两个人，会议里可能有四个。检查每段话的编号是否前后一致，隔了一段时间再开口的说话人是否保留原来的编号，以及同时开启说话人和时间戳时，词级时间区间会变成什么样。也要检查时长上限。标注谁在何时说话需要一次读完整段录音，这项工作的时长上限通常比普通转写更短。
5. 您自己的专有名词#
每个产品都有通用模型从没听过的词：零件编号、地名、拼写方式特别的品牌。检查引擎是否接受词汇表，能接受多少个词，以及拼写在不同请求之间是否保持一致。50 个词的词汇表足以覆盖大多数实际使用的词汇。会悄悄截断的词汇表，覆盖哪一部分都无法预料。
6. 动手开发之前，先看上限#
单次请求的时长、单个文件的字节数，以及支持的容器格式。这些比准确率更能决定您的处理流程长什么样。一次调用能处理一小时的引擎，和只能处理十分钟的引擎，是两种不同的集成方式；等代码写完才发现这一点，代价很高。
还要检查格式是从文件字节中识别的，还是由您自行声明。如果需要声明，您产品里的每条上传路径都必须先正确探测并标注文件格式，才能发送。
7. 失败的代价#
分别发送一个损坏的文件、一个静音文件和一个超过时长上限的文件。您想要的行为是在扣费之前拒绝请求，并返回一个说明属于哪种情况的错误码。接着检查扣费之后发生的失败会怎样处理。对未能完成的请求照样收费的引擎，会让您产品里每一次失败的上传都变成一笔小损失。
然后再测准确率#
七项都有了答案，再给剩下的候选引擎打分。按字符计分，用您自己的参考文本，并把规范化规则写下来。关于准确率的那篇文章讲了具体做法，简单说，没有人能复现的数字就不能算作数字。
我们如何回答这七项#
Paxa STT Lite 对这七项的回答如下。词级时间区间覆盖完整的泰语词。可按请求选择口语体或书面体。泰语和英语写在同一行里。较短的录音可以区分说话人，也接受词汇表。录音最长 60 分钟，容器格式从文件字节中识别，失败的请求不扣费。准确率数字要等测量方法能一并公布时才会发布。
下一步#
- 阅读语音转文字指南，了解上面七项检查用到的请求字段。
- 打分之前，先读为什么词错误率会误导泰语转写评测。
- 阅读 ASR 对泰语意味着什么，了解这些检查背后的泰语特性。
- 打开转写工具，用您自己的三十分钟录音跑一遍。