英文题目：Amchi - Low Resource Language ASR with Crowdsourced Post-Processing
会议身份：
conference:speechprosody:2026:conference-paper-id:kopikar26_speechprosody
✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。
标签：#迁移学习 #韵律 #跨语言 #低资源 #语音识别
评分：6.2/10 | 创新 1.2/2 | 技术严谨 0.9/1.5 | 实验充分 0.6/1.5 | 清晰度 0.6/1 | 影响力 0.8/1.5 | 开源 1.0/1.5 | 可复现 0.1/0.5 | 工程/实践 1.0/1.5
排名：前50% | 文档类型：系统技术报告
👥 作者与机构
- Moksh Kopikar：机构信息未能从会议 PDF 纯文本可靠映射
- Naman Mandloi：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
Amchi Konkani是以口语传承为主、无标准文字和商业自动语音识别（Automatic Speech Recognition, ASR）支持的印度西海岸方言，输入为社区采集的自然故事录音，输出为天城体（Devanagari）文字转写，难点在于数据极少且口语到书面形式边界模糊。系统先冻结AI4Bharat IndicConformer混合联结时序分类与循环神经网络换能器（Connectionist Temporal Classification-Recurrent Neural Network Transducer, CTC-RNNT）模型中的Conformer编码器以保留印度语系声学表征，再仅微调CTC解码线性层以映射方言正字法，解码输出随后进入约80条手工正则规则与约5000词众包词典构成的后处理引擎做纠错与标准化。与直接复用邻近大语种模型相比，该链条把声学泛化与正字法适配解耦，使小数据训练不易过拟合。在以Marathi为最优源语言的对比中，后处理将基线词错误率（Word Error Rate, WER）从35.1%降至21.3%，相对降幅约39%。该结论仅在同一1.5小时社区故事数据上验证，未做跨说话人划分、噪声鲁棒性与统计显著性检验，字符错误率（Character Error Rate, CER）与延迟仅在演示设想中提及而无实测值。原文未披露训练、推理或部署成本。
🔗 开源与复现资源
- 代码相关资源：https://github.com/mokshkopikar/amchi_asr — 链接可访问（HTTP 200）
- 模型相关资源：https://huggingface.co/ai4bharat/IndicConformer — 暂时无法访问
- 第三方资源：https://github.com/NVIDIA/NeMo → https://github.com/NVIDIA-NeMo/Speech — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么，目标是什么，这篇解读要交付什么？
这篇解读的输入是 Speech Prosody 2026 收录的 Amchi 演示论文，目标是让刚进入语音、音乐或音频方向的研究生能复述方法并核对关键条件。必须保留的信息包括任务定义、数据规模、冻结与微调的划分、后处理构成、基线选择过程、主结果数字、部署形态与开源状态，输出是一套按学习依赖展开的中文技术说明。
Amchi Konkani 被论文描述为主要沿印度西海岸社区使用的口语方言，缺乏正式书写规范和商业语音识别支持。用白话说，研究对象不是有标准教材的语言，而是一群人日常讲但怎么写都不统一的声音。英文术语是 low-resource language，指有标注语音和文本极少、难以直接训练大模型的语言；under-resourced 在这里含义相同。数字包容风险是起点：没有识别器，这类口语就很难被搜索、存档和做韵律研究。
论文要解决的不是通用多语识别，而是用极小监督数据做出第一个可用的 Amchi Konkani 识别器和词典。做法分 3 段：高质量社区采集、微调声学模型、词典加规则精修。理解时先记住这个顺序，后面所有组件都是为它服务的。举例来说，这好比先请村民讲故事并写下大意，再请懂邻近语言的听者学听口音，最后请识字的长者把听写稿改成大家认可的写法，这只是帮助理解分工的例子，不是论文报告的实验数值。
为避免误解，需要先划清边界。论文报告的是端到端自动语音识别，英文为 automatic speech recognition，缩写 ASR，指输入一段波形，直接输出文字序列。演示系统还包含展示界面和云端推理，但核心可复述方法是声学迁移加文本后处理。凡是涉及可用性判断，本解读只按正文开源声明和资源可达状态写，不做营销式推广。
同样做少资源识别，已有路线与本文选择有何不同？
在同输入、同目标、同监督的维度上，少资源识别常见路线有 3 类。第一类是从零收集大规模标注再训练，这在 Amchi 场景下不可行，因为社区只有约 1.5 小时故事录音，且没有统一正字法。第二类是直接调用邻近大语言模型做零样本识别，这能出声学相近的文字，但会把 Amchi 特有发音映射到邻居语言的词形，出现系统性的词边界和拼写偏差。第 3 类是纯文本后处理，例如只建词典做替换，这能改字形但改不了声学听错的部分。
本文属于第四种组合：先做跨语言迁移，再做社区驱动的后处理。迁移部分利用 AI4Bharat 的 IndicConformer，英文全称为 IndicConformer，指为印度多语言训练的 Conformer 结构识别模型，论文使用其混合 CTC-RNNT 中的 CTC 分支做微调。选择它的理由在正文是地理与文化相近语言的声学表示可复用，而不是模型参数规模最大。后处理部分用 PostgreSQL 支撑的众包词典加手工正则，英文为 crowdsourced post-processing，指由母语者提供和校对词形，再用程序修正识别输出。
与 Speech Prosody 的关联在于，同运行阶段的韵律研究需要先有可对齐的正字转写。没有转写，研究者无法标注停顿、语调短语和话语节奏。有了统一转写基线，后续才能测量节奏、语调和组块。因此论文把识别器定位为 substrate，即后续韵律与发音研究的地基，而不是 1 次性的演示玩具。这种定位决定了它重视故事体连续语料，而非孤立词表，因为前者保留了自然韵律组块和话语级节奏。
要把哪段声音变成哪种文字，难在哪里？
任务输入是一段社区录制的故事音频，采样为连续口语，包含自然停顿、重复、语气词和不同讲述人的音色变化。目标输出是用天城体书写的 Amchi Konkani 转写文本，英文为 transcript，指与音频内容对应的逐句文字。难点在于发音到字形没有标准答案：同一种口语音，不同人可能写出不同拆分，模型即使听对了音，也可能写错词边界。
第二个难点是监督极少。训练只有社区收集的 1.5 小时音频加转写，验证和测试划分在正文中没有给出明确时长与说话人是否独立，这是复现时必须补记的缺项。初学者容易误以为小时数少就一定过拟合，准确的说法是可训练参数必须与数据量匹配，这正是论文冻结编码器的直接动机。
第三个难点是评估口径。主指标是词错误率，英文为 word error rate，缩写 WER，指把识别结果与参考文本按词对齐后，替换加删除加插入的词数除以参考词总数，越低越好。论文同时在演示界面提到展示 WER、CER 与延迟，CER 是字符错误率，英文为 character error rate，按字符计，粒度更细。但正文定量结果只报告了 WER，没有给出 CER 与延迟的具体数值，因此不能从 WER 下降推定延迟也下降。
沿一个样本走一遍有助于建立直觉。假设输入是一句故事旁白的波形，先被切成按时间推进的声学帧序列，再被编码器变成每帧一个高维向量，接着 CTC 解码层给每帧打出天城体字符或空白符的概率，最后经合并重复与去空白得到词序列，词典与正则再把不符合社区规范的词形改写。这只是流程举例，不代表论文用过该例句。
三段流水线如何分工，为什么这样接？
系统按 3 段组织：高质量数据收集、微调识别器并解码、基于词典与正则的精修。第一段解决有没有可学材料的问题，第二段解决听不听得懂的问题，第 3 段解决写得规不规范的问题。顺序不能颠倒，因为后处理只能改字形，若声学模型完全听错，后处理没有可靠锚点。
工具层面用 NVIDIA NeMo 搭建，英文为 NeMo，指 NVIDIA 开源的语音工具包，论文用它实现模型调用与微调流程。词典通过网页界面开放给社区搜索与提议修改，模型部署为 RunPod 无服务器端点以保证推理性能。正文还提到冻结编码器后计算 footprint 小、延迟低并可能部署到手机等边缘设备，但这属于基于参数量的推断，没有报告在手机上的实测延迟与内存占用，复述时应标为待验证。
迁移学习 × 众包后处理： 迁移学习负责解决从零训练不可行的问题，它借用地理文化相近的 Marathi 模型的声学基础，众包后处理负责解决口语到书面形式边界不一致的问题，它用社区词典和正则把解码粗结果拉回规范词形，二者搭配是因为声学接近不能保证字形规范，组合后声学模型管听得懂，词典规则管写得对。
下图展示了从浏览器到云端再返回的完整推理链路，读图时先分清谁负责交互、谁负责计算、谁负责存词典。
看图路径： 1. 先看左侧浏览器界面的音频输入与最终转写两个图标确认交互边界；2. 再沿中间 HTTPS 请求与转写返回箭头确认前后端数据走向；3. 最后自左向右检查服务端内封装接口、识别模型与后处理三个方框的串联顺序
论文图 3。原论文 Figure 3：“Finetuning and Inference Workflow Architecture”。
这张部署架构图把 1 次转写拆成清晰的 4 步。左侧是基于 Gradio 的交互空间，负责接收 WAV 音频并展示最终转写，中间经 HTTPS 接口进出，右侧无服务器容器内依次经过封装接口、NeMo 版 IndicConformer 模型与后处理模块，后处理下方还连着存众包词典的数据库。它的教学价值在于说明训练与推理分离：训练用社区故事数据离线完成，推理只走冻结后的模型加词典查询，因此新增词汇可以通过更新数据库生效，而不必每次重训声学模型。但图上标注的显卡型号只说明演示时的计算环境，不能当作复现的最低配置要求。
冻住编码器只练解码层，计算上到底发生了什么？
先解释术语。编码器，英文为 encoder，这里指 Conformer 堆叠块，用多头自注意捕捉长时依赖，用卷积捕捉局部谱变化，输出每帧的高维声学表示。CTC 解码器，英文为 CTC decoder，这里指最后的线性层加 Softmax，把高维表示映射到天城体字表加空白符上的概率。CTC 是联结时序分类，英文为 connectionist temporal classification，它允许音频帧数多于文字数，通过对所有合法对齐路径求和来训练，不需要逐帧标注。
编码器 × CTC 解码器： 编码器负责把声学输入变成保留印度语系语音特征的高维表示，CTC 解码器负责把该表示映射到天城体字形空间，二者搭配的理由是数据只有 1.5 小时，冻住编码器可保留预训练声学能力，只训练约 250K 参数的解码层即可学习 Amchi 特有的发音到字形对应，组合意义是以极小可训练量完成跨语言适配。
具体计算可分 4 步复述。第一步输入声学序列，记为每帧特征组成的序列，长度为 T。第二步冻结的 Conformer 把它变成隐藏状态序列，记为每帧一个向量，训练时不更新这部分权重，梯度不回传进去。第三步可训练的线性矩阵与偏置把每个向量投影成字表上的 logits，再经 Softmax 得到每帧的字符概率。第 4 步 CTC 目标把所有能经合并重复与删空白得到目标转写的路径概率相加，最大化该总概率。原文给出了该求和形式与 logits 投影形式，但本次没有收到可绑定的原始公式像素，因此正文不单独展示公式编号，只保留上述可复述的计算顺序。
正则规则 × 众包词典： 正则规则负责处理高频且有规律的口语到书面转换，例如可重复出现的词边界拆分或后缀变形，众包词典负责提供约 5000 个经社区确认的标准词形作为替换依据，二者搭配是因为规则泛化强但容易误改，词典精确但覆盖有限，组合时先用规则提议再用词典约束，形成可维护的精修层。
后处理引擎由约 80 条手工正则与 PostgreSQL 词典组成。运行时先对解码粗文本做规则替换，修正高频口语到书面边界错误，再用词典约束词形是否合法。词典本身通过网页界面众包得到，社区可搜索、建议修正并逐步统一写法。需要强调的是，正文没有报告规则与词典各自的消融贡献，也没有给出误改率，因此不能说规则越多越好，只能说两者共同把基线 WER 拉低到最终值。
1.5 小时故事数据如何变成可训练的监督信号？
训练数据是社区录制的故事音频加对应转写，总量为 1.5 小时。论文强调故事体的价值在于保留自然韵律组块与话语级节奏，这是孤立词表做不到的。对初学者而言，可以这样理解：故事有长短句、停顿和情绪起伏，模型能看到真实语流中的协同发音，而单词表只有干巴巴的单字。
故事数据 × 韵律基线： 故事数据负责提供连续自然语流中的停顿、语调和话语节奏，这是孤立词录音给不了的上下文，韵律基线负责把转写文本作为后续研究节奏、语调和短语划分的统一参照，二者搭配的理由是只有先有可信的逐句转写，才能对齐音频做韵律分析，组合意义是识别结果成为保护有声遗产的第一步而非终点。
采集分两路并行，这是理解众包的关键。下图左侧是社区贡献者，中间是两部手机应用，右侧分别是词典库与训练数据库，箭头方向说明了文本与音频各自的去向。
看图路径： 1. 先从左侧社区贡献者出发，沿上方书面词箭头和下方录音箭头分别向右追踪；2. 再看中间两个手机图标如何分开承担文本收集与音频录制；3. 最后确认右侧词典与训练数据如何同时汇入标注为微调与解码的识别系统框
论文图 1。原论文 Figure 1：“Community Sourced Data Collection”。
这张采集图把人力组织翻译成了数据流。上方箭头是书面词经文本收集应用进入众包词典，用于后处理；下方箭头是录音经音频录制应用进入带转写的训练数据，用于微调与解码；两者最终都指向右侧识别系统。这说明社区同时承担了声学数据提供者和正字法制定者两种角色。复现时要注意，正文没有说明录音设备、采样率、信噪比、说话人数与故事主题分布，也没有说明转写质检流程，这些都是重做采集必须补记的实验条件。
训练操作本身是只更新解码层。论文报告可训练参数从 120M 降到约 250K，目的是防止在小数据上过拟合并降低计算开销。正文没有报告学习率、轮数、优化器、批量大小与早停策略，也没有说明是否划分验证集调参，因此复现时只能先按 NeMo 默认的 CTC 微调流程搭建，再用自己的验证集搜索超参数，并如实记录。监督来源是社区转写文本，梯度只经过最后线性层，不更新 Conformer 权重，重置时机与随机种子均未报告。
用什么数据、和谁比、按什么指标算公平？
实验要回答两个问题。第一，地理文化相近的哪个基座语言更适合迁到 Amchi；第二，后处理在选定的最优基座上还能带来多少增益。比较对象是经微调的不同基座语言模型，正文明确点名 Marathi 基线最优，图上还出现了 Goan Konkani 与 Hindi 等条件。公平条件要求同一套 Amchi 训练与测试音频、同一套转写规范、同一 WER 计算脚本，但正文没有给出划分细节与解码超参数是否一致，这是解读时必须指出的缺项。
词错误率 × 字符错误率： 词错误率负责衡量按词切分后整词错了多少，直接反映可读转写的可用性，字符错误率负责衡量按字符计的细粒度声学字形偏差，能区分是一个字母错还是整词错，二者搭配的理由是口语方言常有词边界粘连，单看词错误率会掩盖部分正确的声学建模，组合使用才能同时看到解码与后处理各自的作用。
指标方向是 WER 越低越好，相对降低幅度越大越好。论文在摘要报告后处理带来 39% 相对 WER 下降并达到 21.3%，在结果节报告 Marathi 基线为 35.1% 并经规则修正降到 21.3%。百分点差与相对百分比含义不同：从 35.1% 到 21.3% 是下降 13.8 个百分点，相对下降约 39%，复述时不要混用。
社区界面是保证转写一致性的操作层，下图显示了可回放、可多版本对照的网页布局。
看图路径： 1. 先看左面板上方红色与蓝色按钮区确认录音校验类操作入口；2. 再看右面板每行末尾的播放按钮确认音频可回放核对；3. 最后对比同一行中两列转写文本的差异以理解社区校对对象
论文图 2。原论文 Figure 2：“Community Sourcing and Transcription Interface”。
这张界面截图左侧像是单条样本的校验面板，右侧是带编号的多行转写列表，每行都配有播放按钮与两列文本。由于像素模糊，无法辨认具体按钮文字与转写内容，只能确认它支持听音核对与多版本并列。这对复现的启示是，众包不只是收集，还包括可回放、可追溯的校对闭环。若重做，应记录每条音频的提交者、校对者、修改历史与最终采纳版本，否则词典更新无法审计。
资源可达状态按本次核验写：项目代码仓库当前可用，第三方 NeMo 仓库当前可用，IndicConformer 权重链接本次未能确认可达。复现前应先确认权重可下载的具体版本与许可，再谈训练。
最优基线加后处理到底降了多少，谁没胜出？
先提出比较问题：在同一 Amchi 测试条件下，选哪个基座语言微调，再叠加后处理，能否得到可部署的 WER。公平条件是同一测试集与同一 WER 口径，指标方向是越低越好。下表整理了正文直接报告的核心数字，基线是实际可运行的 Marathi 微调模型，收益是实际可部署的词典加规则后处理，不含事后最优或人工改写。
| 条件 | 指标 | 基线 | 本方法 | 相对变化 |
|---|---|---|---|---|
| Marathi 微调后直接解码 | WER | 35.1% | 21.3% | 39% |
| Marathi 微调加词典与正则精修 | WER | 35.1% | 21.3% | 39% |
表后需要解释收益与代价。后处理把 35.1% 降到 21.3%，相对降幅 39%，说明大量错误集中在可用规则与词典纠正的词形与边界问题上，而不是完全听错。这支持了声学迁移加文本规范的组合判断。但代价是词典规模约 5000 词且需持续维护，规则约 80 条且只覆盖高频模式，对未登录词与新讲述人的泛化能力没有报告。
下图用柱状对比呈现了不同基座的选择结果，读图时注意纵轴是原始 WER 而非改善量。
看图路径： 1. 先确认横轴四个基座语言条件与纵轴词错误率的含义；2. 再自左向右比较四个柱子高度的下降趋势；3. 最后聚焦最右侧后处理柱与 Marathi 基线柱的高度差
论文图 4。原论文 Figure 4：“Results of Training Various Base Language Models”。
这张柱状图横轴为基座语言条件，纵轴为 WER，柱子自左向右依次降低，最右侧 Marathi 加后处理最低。像素可辨认的标注约为 72%、55%、35%、21%，其中 35% 对应正文的 35.1% 基线，21% 对应 21.3% 最终结果，中间 2 位数的微小差异来自图上四舍五入。未胜出项同样重要：Goan Konkani 与 Hindi 柱明显更高，说明名称相似或同属大语种并不等于声学迁移效果最好，真正胜出的是 Marathi。这提示复现时不要只试直觉上最像的语言，而应按同一流程多试几个地理文化相近的候选，再用 WER 选择。
需要明确，未报告 CER、延迟、统计显著性与说话人独立性，因此不能把 WER 最优推广为全面最优。
去掉哪一块会怎样，论文实际做了什么对照？
论文实际做的对照有两类。第一类是基座语言对照，即同一微调方法换不同源语言，Marathi 胜出。这可以看作对迁移源的消融：换掉源语言，WER 明显变化，支持了地理文化相近性需要实测选择，而不能靠语言名称推定。第二类是有无后处理的对照，即 Marathi 基线直接解码对比叠加正则与词典，WER 从 35.1% 到 21.3%。这可以看作对后处理层的消融，但它没有进一步拆开正则与词典各自的贡献。
没有做的对照也要如实指出。没有冻结与全量微调的对比，因此不能从参数量下降推定冻结一定比全量好，只能说在 1.5 小时条件下冻结是一种防过拟合且省算力的选择。没有词典规模、规则数量、故事体与孤立词体的对比，因此不能说 5000 词或 80 条是最佳点。没有去掉社区校对、只用原始转写的对比，因此不能量化界面与质检带来的增益。
为把资源规模与可训练量放在一起看，下表整理了正文报告的构造参数，它不是性能表，不能替代上面的 WER 表。
| 环节 | 对象 | 规模 | 用途 | 运行形态 |
|---|---|---|---|---|
| 声学适配 | 可训练参数 | 120M | 冻结前总量 | 预训练编码器 |
| 声学适配 | 可训练参数 | ~250K | 仅训练解码层 | 微调后增量 |
| 数据采集 | 故事音频 | 1.5 hours | 训练监督 | 社区录制 |
| 文本规范 | 众包词条 | ~5,000-word | 后处理约束 | 词典库 |
| 文本规范 | 手工模式 | ~80 hand-crafted regex rules | 高频改写 | 规则引擎 |
表后解释为何要同时看两张表。上一张 WER 表回答效果好不好，这一张规模表回答代价与复现门槛：听的部分只动约 250K 参数，写的部分靠约 5000 词与约 80 条规则。这意味着复现的主要工作量不在调大模型，而在组织社区、清洗故事转写与维护词典。若把两张表混读，例如把参数量下降当成 WER 下降的原因，就犯了把相关当因果的错误。
哪些结论站得住，哪些还只是待验证？
站得住的结论有两条。第一，在论文的测试条件下，Marathi 作为源语言优于其他所试的基座，这是 WER 数字直接显示的。第二，在该最优基线之上叠加词典与规则，后处理带来了从 35.1% 到 21.3% 的下降，这是同一基线上有无后处理的直接对比。用词上，这两条可用报告或显示来表述。
支持但需限定的结论是小参数微调省算力且防过拟合。它有参数量从 120M 到约 250K 的证据支持，但没有全量微调的失败对照，也没有训练时长与显存实测，因此只能说降低了过拟合风险与计算负担，不能承诺在所有小数据上都最优。同样，边缘部署与低延迟属于基于轻量结构的推断，没有手机端实测，不应写成已验证的延迟改善。
待验证的推测包括 3 类。一是泛化：新讲述人、新主题、新噪声下的 WER 是否仍在 21% 附近，正文没有跨说话人与跨场景评估。二是韵律：论文希望支撑节奏与语调研究，但没有报告韵律标注一致性或下游韵律任务的提升，因此只能说提供了统一转写基线，不能说已改善韵律建模。三是濒危语言推广：论文提到近 3000 种语言的模板意义，这是愿景而非已验证的跨语言结论，复述时应标为可能与待验证。
原文内部没有发现数字自相矛盾，但存在口径缺失：测试集划分、说话人独立性、WER 计算工具、CER 与延迟数值、超参数与随机种子均未报告。遇到缺项时正确做法是标注缺项，而不是用模型名称或常识脑补实现细节。
要复现这条路，第一步先做什么？
复现先做三件事。第一，固定数据与评估：按故事为单位划分训练、验证与测试，确保测试讲述人不出现在训练中，统一转写规范并固定 WER 计算脚本，先跑通 Marathi 基线直接解码的 35.1% 量级，再接入后处理。第二，锁定代码与权重：先拉取当前可用的项目代码与 NeMo 工具，再确认 IndicConformer 权重的可达版本与许可，若权重本次不可达，应记录实际下载地址与校验值，不用不可用的链接冒充已公开。第三，搭建词典闭环：部署 PostgreSQL 词典与网页校对界面，保证每条音频可回放、每版转写可追溯、每个词形有提交与采纳记录。
关键超参数与信息条件在正文中缺失较多，复现时要自己补齐并报告：学习率、轮数、批量、优化器、早停、解码束宽、正则执行顺序、词典匹配优先级。训练只更新解码线性层，编码器保持冻结，梯度不进入 Conformer，这是必须保留的冻结安排。若改动冻结范围，就不再是论文验证过的配置，应作为新对照单独报告。
部署按论文是 RunPod 无服务器端点加 Gradio 前端，音频经 HTTPS 进、转写 JSON 回。复现时先在服务器上测端到端 WER 与延迟，再谈手机移植。不要把服务器上的低延迟直接当成手机上的低延迟。社区工作要留预算：约 5000 词的收集与约 80 条规则的编写维护是人力成本，不是零成本的自动步骤。
常见误解有三。其一，以为 Goan Konkani 名字最像就一定最好，实际胜出的是 Marathi，选源语言必须实测。其二，以为后处理能纠正一切听错，实际上它主要修词形与边界，若声学完全听错，词典也无能为力。其三，以为参数少就等于输出确定，实际上解码仍有搜索与采样不确定性，冻结只减少可训练量，不保证每次输出逐字相同。
何时值得尝试这套方法，还差哪项验证？
当同时满足 3 个条件时值得尝试：目标是口语为主、无统一正字法的少资源语言；能找到地理文化与语音相近的大语言预训练模型；能组织母语者持续提供故事录音并维护词典。此时先冻结编码器做小参数 CTC 适配，再用词典与规则做文本规范，是一条人力与算力都可承受的路线。若没有社区参与或没有相近源语言，这条路的第一步就缺了监督或声学起点，不宜硬套。
从学习依赖看，整条链是采集决定上限，迁移决定起点，后处理决定可用性。故事数据提供自然韵律与话语节奏，使模型见到真实语流；Marathi 迁移提供可复用的印度语系声学表示，使 1.5 小时也能起步；约 5000 词词典与约 80 条规则提供社区认可的书写规范，使 35.1% 降到 21.3%。三者缺一不可，但各自的独立贡献只有基座对照与有无后处理被验证， finer 的拆分仍是空白。
还需补的验证很具体：公布测试集划分与说话人独立性，报告 CER、延迟与统计波动，公开正则列表与词典版本，补充冻结与全量微调、不同词典规模、故事体与孤立词体的对照。只有补齐这些，才能把世界首个 Amchi 识别器从 1 次成功的演示，变成可审计、可移植的少资源语言保护模板。
📐 原文公式与排版
以下展示论文原页中的数学表达区域，保留原始上下标、分式和符号排版。区域序号仅用于本文导航，不是论文公式编号。
区域 1 · 查看论文原页
区域 2 · 查看论文原页
区域 3 · 查看论文原页
另有 2 个候选区域因边界不明确或图片数量、尺寸限制未展开；请查看完整论文中的原始排版。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses