英文题目：CodeVaani: A Multilingual, Voice-Based Code Learning Assistant
会议身份：
conference:interspeech:2026:conference-paper-id:havare26_interspeech
来源为官方会议 PDF；图片依据原页像素，表格数字依据原文引用。PDF 文字层不视为原始 TeX，未可靠恢复的结构不作推断。
标签：#教育 #偏好优化 #多语言 #语音 #语音交互
评分：5.9/10 | 创新 1.2/2 | 技术严谨 1.1/1.5 | 实验充分 0.7/1.5 | 清晰度 0.8/1 | 影响力 0.8/1.5 | 开源 0.2/1.5 | 可复现 0.1/0.5 | 工程/实践 1.0/1.5
排名：前50% | 文档类型：系统技术报告
👥 作者与机构
- Jayant Havare：机构信息未能从会议 PDF 纯文本可靠映射
- Srikanth Tamilselvam：机构信息未能从会议 PDF 纯文本可靠映射
- Ashish Mittal：机构信息未能从会议 PDF 纯文本可靠映射
- Shalaka Thorat：机构信息未能从会议 PDF 纯文本可靠映射
- Soham Jadia：机构信息未能从会议 PDF 纯文本可靠映射
- Varsha Apte：机构信息未能从会议 PDF 纯文本可靠映射
- Ganesh Ramakrishnan：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
CodeVaani面向印度初学者用母语语音提问代码概念的场景，输入为母语词夹杂英语技术词的代码混杂语音，输出为同语言文本回答与音频播放，难点在于口语化变量名、符号算子与编程关键词易被语音识别误转写并污染下游代码模型。系统先按语言路由调用Whisper处理英语、Indic-Conformer处理印度语言做初始转写，保留混合语义并输出文本给下一步。接着经直接偏好优化微调的指令调优Gemma-27B做代码感知转写修正，将误识同音技术词与符号表达恢复为代码形式。修正文本再送入Codestral-22B生成同语言解释、问答与排错回答，经Django、PostgreSQL、Redis与Celery异步轮询交付修正查询与回答文本及音频。与Saaras V3及通用多模态模型相比，该级联把声学识别与代码语义修复解耦，使后者专门纠正同音技术词失真，提升多语言代码密集语音的鲁棒性。在5种语言各100条共500条真人朗读查询的评测任务下，CodeVaani的WER为8.1%，低于Qwen3-Omni-Flash的WER 11.61%。28人实验室可用性评价中89%以上给出Fair及以上等级，26名回答采纳意愿者中25人表示可能或肯定在课程中使用。结论限于短句单轮查询与受控录音，未验证课堂噪声、多轮对话与长期学习收益，原文未披露训练与推理成本及延迟吞吐。
🔗 开源与复现资源
- 演示资源：https://tinyurl.com/icse2026-artifacts → https://drive.google.com/drive/folders/1V7gfxGeG1GmUNyZeC9iGNDQ_XOIUb-cs?usp=sharing — 暂时无法访问 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么，目标是什么，这篇解读要保留什么
这篇解读的输入是 CodeVaani 论文报告的一个已建成系统与 2 次小规模实测，目标是让刚进入语音或音频方向的研究生能复述它的方法链条与实验条件。需要保留的信息包括系统 3 段式划分、各段实际调用的模型名、部署在印度理工孟买学习管理系统中的异步链路、28 人可用性评价的分布、500 条真人语音上与印度代码混合语音识别基线和多模态大模型的词错率、音素错率与加权特征编辑距离对照，以及补充材料本次未能确认可达的状态。输出是一份可核对的技术复述，不做超出证据的效果承诺。
论文的任务不是通用语音转写，而是母语口语问编程。学生用浏览器录一段母语加英语代码词的提问，系统要听懂变量名、符号操作和编程关键词，再用同语言回一段能学的解释并同时给文本和音频。难点在三处，第一是同一句话里语言切换频繁且代码词发音不标准，第二是标准语音识别会把技术词听成同音常用词，第三是下游代码模型对这种转写错很敏感。作者的前期问卷也支撑这个任务设定，在 53 名印度程序员中只有 58.5% 自认英语熟练，54.7% 更愿意用语音而非文本问代码问题，这说明文本英语助手默认的交互假设在这里不成立。
代码混合语音 × 多语言回答： 代码混合语音指一句话里母语词裹着英语代码词，如印地语解释加 for loop，发音不规则且多界外词；多语言回答指系统用提问同语言回文本加音频，分工是前者决定输入有多难听准，后者决定输出是否可学，搭配理由是只解决听准不解决母语可懂，初学者的英语和打字门槛仍然存在。
理解这篇工作要先建立一个样本直觉。举例只是教学例子，不是论文原句，假设 1 名初学者用印地语混英语问循环为什么多跑 1 次，录音里 for 被读得含糊，初版转写可能出现同音常用词，修正阶段要把它拉回代码词，再由代码模型解释越界条件。整篇解读就沿着这个样本走完输入到表示到组件到目标再到输出，后面所有数字都回到原文条件去核对。
给新生的阅读顺序与核对清单
建议按学习依赖读，先看问题与 3 段划分，再看分语种识别与修正的搭配理由，再看部署链路，最后看实验条件与两张宽表。核对清单包括模型名是否对齐，语音识别是否为英语 Whisper 加印度语言 Indic-Conformer，修正是否为 Gemma-27B 加直接偏好优化，生成是否为 Codestral-22B。数据清单包括 28 人评价分布、26 人意愿、500 条真人语音的语言构成。指标清单包括 3 个错率的方向均为越低越好。
常见误解是把自动指标当成人评，把全局最优当作每种语言最优，把无训练报告当作确定性系统。纠正方法是回到原文条件，自动指标只到转写层，人评只到意愿层，语言间差异用分语言表核对，不确定性用生成采样与语音噪声解释。篇幅到此为止，所有数字都可在正文两张整理表与所附原文连续句中找到来源。
同输入同目标的路线有哪些，本文站在哪里
与 CodeVaani 同输入的路线是面向印度语音的识别系统，论文点名比较了支持 22 种印度语言并强调代码混合与噪声鲁棒的 Saaras V3。这条路线解决听准，但不负责把听到的东西讲成可学的代码解释。与 CodeVaani 同目标的路线是交互式代码理解助手，论文背景指出这类助手多假设英语熟练加文本交互，在印度从地区语言中学转入英语授课计算机课程的场景下会形成额外门槛。与 CodeVaani 同运行阶段的路线是可直接处理语音的多模态大模型，论文比较了 Phi-4 多模态指令版、Qwen3-Omni-Flash 和 Whisper，考察它们能否一步完成技术性代码混合语音的理解。
CodeVaani 的位置是把 3 段拆开，语音识别只管出初稿，代码感知修正专管修技术词，代码模型专管讲题。这种拆分不是为了堆模型，而是论文明确报告通用模型在混合输入上有残留错误，所以用分语种识别加后修正来兜底。相关工作的对照因此不能只看谁的词错率低，还要看是否支持印度语言、是否处理代码密集语音、是否能嵌入学习管理系统做异步教学服务。论文报告 Phi-4 不支持印度语言因而只限英语评测，这就是一条重要的适用边界，跨语言比较时必须注明条件不一致。
要解决的语音问题如何形式化
问题输入是一段浏览器录制的单轮口语查询，附带题目描述和代码上下文，输出是修正后的查询文本加同语言的代码回答文本与音频。系统不处理多轮追问，论文把多轮列为未来工作。评价分两层，一层是学习者主观可用性，问体验等级与是否愿意在课程中使用，另一层是语音层客观错率，用词错率、音素错率和加权特征编辑距离衡量转写与修正后的文本与参考的偏离，3 个指标都是越低越好。
关键约束是代码混合与发音变体。变量名、符号词如下划线、编程关键词如 ASCII 都可能被读成常用词，论文举例 ask key 被听成 ASCII 的反向过程，即技术词被同音非技术词替代。声学模型即便在印度语音数据上训练过，论文仍报告不能完全解决，因此问题形式化里必须包含一个显式的文本级修复步骤，而不是假设 1 次识别就足够干净。这种把残留误差显式建模的思路，是后文 3 段架构的直接来源。
三段流水线如何从录音走到回答
CodeVaani 的全景是一条异步流水线。学生端发送录音查询、题目与代码，后端写入数据库记录并创建任务，返回任务编号给前端轮询，真正重的语音识别、纠错与代码生成放在独立图形处理器服务器上执行，最后把转写查询、修正查询与回答一起送回。这种设计把交互层与计算层分开，学习管理系统只负责排队与状态，模型服务只负责算。论文报告的实现用了 React 前端、Django 后端、PostgreSQL 数据库、Redis 队列与 Celery 工作进程，人工智能模型跑在带 2 块 H100 的专用服务器上，一块跑语音识别加转写修正，另一块跑回答生成。
沿着前面的循环例子走一遍，录音先进入按语言分流的识别器得到初稿，初稿进入修正模型得到干净的代码混合查询，干净查询连同题目代码进入代码模型得到母语解释，前端同时展示修正后查询与回答并可播音频。修正后查询被显式展示这一点很重要，它让学生能核对系统到底听成了什么，也让实验能分别度量听准与讲对。
本段配的架构图用于把上述异步与 3 段串行 1 次看清，导读先看主路径再看分支汇合。
看图路径： 1. 先从左侧学生端沿发送录音查询箭头看到后端再到右侧 GPU 服务器；2. 再看后端内写库记录与创建 Celery 任务两条分支如何汇入 Redis 队列；3. 对比 GPU 服务器内语音识别模型到纠错再到代码模型的三段串行箭头；4. 最后核对返回括号中转写查询、修正查询与 AI 回答三件套
论文图 1。原论文 Figure 1：“CodeVaani Architecture: Processing student queries through ASR, error correction, and AI code generation.”。
从像素看，这张图分为左中右三栏，左是学生电脑图标，中是学习管理系统平台后端框，右是图形处理器服务器框。中框内画出写库记录、创建任务、Redis 队列与 Celery 工作进程的闭环，右框内自上而下画出语音识别模型、语音识别纠错与代码模型，箭头标注了去程的问题描述代码加录音查询与回程的转写查询修正查询加回答。左右两块图形处理器角标对应正文两块 H100 的分工，中间虚实箭头区分发送查询、按任务编号轮询与展示结果 3 个前端动作。读图时不要把中框的中央处理器角标误读为计算主力，真正的语音与语言模型都在右框。
Redis 任务队列 × Celery 工作进程： Redis 任务队列负责暂存浏览器录音请求并返回 TaskID 让前端轮询，避免语音加双大模型阻塞网页；Celery 工作进程负责异步取出任务并调度后端写库与 GPU 服务器转写修正生成，二者搭配的原因是语音推理耗时远大于普通网页请求，组合后形成学习管理系统可集成的非阻塞学习入口。
分语种识别与修正各管什么，为什么这样搭配
第一段是语音识别。论文报告先试过 Whisper，发现它在母语词加英语代码词的混合输入上有局限，于是改为英语用 Whisper、印度语言用 Indic-Conformer，后者在大规模印度语音数据上训练，更能保留混合语义。分工上这一段只负责声学到文字的初转写，不保证技术词全对。论文明确说这些模型没有完全解决问题，残留错误留给修正阶段，这是原文给出的保留两段的理由。
语音识别 × 代码感知转写修正： 语音识别负责把母语加英语代码词的音频先转成文字，它分英语用 Whisper、印度语言用 Indic-Conformer 以保留混合语义；代码感知转写修正负责接过这份带音近错词的初稿，用指令微调后的 Gemma-27B 把 ask key 这类发音还原为 ASCII、把 underscore 这类符号词还原为符号指向，二者搭配的原因是通用声学模型不认识变量名和符号，组合后才给代码模型一个可理解的查询。
第二段是代码感知转写修正。输入是带错的初稿，输出是更接近原意的代码混合文本，实现是用经过直接偏好优化微调的指令调优 Gemma-27B 做后处理。提示词的任务是纠正被误识、语音扭曲的技术词与符号结构，论文举例把 ask key 还原为 ASCII、把 underscore 还原为对应符号表达。这一段的计算是纯文本到文本的语言模型推理，不再听音频，只靠代码与语言先验把音近错误拉回技术词典。
第 3 段是查询回答生成。输入是修正后转写，模型是 Codestral-22B，任务覆盖代码解释、问答与调试，输出与提问同语言。论文称通过把修正与生成串起来，即使带发音错误与代码混合也能被正确理解，从而回答更可靠。这句话应读成论文的有限解释而非已证明的因果，因为论文的客观指标只度量到转写层，没有给出回答正确率的独立对照。
转写修正 × 查询回答生成： 转写修正的分工是清洗语言层错误，只输出更接近说话人原意的代码混合文本而不直接讲题；查询回答生成的分工是用 Codestral-22B 按修正后文本做代码解释、问答和调试并用同语言返回，二者搭配是因为若把带错转写直接丢给代码模型会连带误答，中间加一层修正等于把声学不确定性与编程知识解耦。
本研究训练了什么，没有训练什么
本节先明确训练边界。论文没有报告从零训练语音识别器或代码模型的完整训练流程，也没有给出优化器、学习率、轮数、数据划分与梯度路径。唯一明确提到带微调的组件是代码感知修正用的指令调优 Gemma-27B 加直接偏好优化微调，但原文未披露偏好数据构造、采样语言分布、冻结与更新哪些参数、监督来源是人工还是模型标注，也未说明何时重置或早停。这些缺项必须如实指出，不能从模型名字推定实现细节。
实际计算过程是调用与编排已有模型。语音识别是调用 Whisper 或 Indic-Conformer 做推理，修正是调用已微调的 Gemma-27B 做文本后处理，回答是调用 Codestral-22B 做生成。部署侧的真实计算是异步任务调度，浏览器录音经后端排队后在图形处理器服务器上依次执行 3 段推理，前端按任务编号轮询取回。这种无完整训练报告不等于系统输出确定，生成模型的采样与语音噪声都会带来不确定性，不能从参数冻结推定每次回答一致。复现时应把本工作当作系统集成与评测论文，而不是可重训的模型训练论文。
在什么数据与协议上测，指标方向是什么
可用性评价在结构化实验室中进行，对象是 28 名初学者，覆盖 Hindi、Marathi、Gujarati、Tamil、Telugu、Bengali、Malayalam、Kannada 和 Odia 等主要印度语言，方法是用学习日志加后续问卷。问题是体验等级与若顾虑解决是否愿在编程课中使用，指标是各等级占比与愿意使用的比例，比例越高越好。这部分是主观评价，不能当作转写准确率。
语音鲁棒性评价用真人录制的代码相关查询，共 500 条，来自 5 名参与者，每人按一种语言录 100 条，覆盖英语、印地语、马拉地语、古吉拉特语与孟加拉语。比较对象一是印度代码混合语音识别模型 Saaras V3，二是 Whisper、Qwen3-Omni-Flash 与 Phi-4 多模态指令版。指标是词错率、音素错率与加权特征编辑距离，都是越低越好。论文未报告统计显著性、说话人无关划分或多次采样方差，也未报告延迟与成本，读数时只能当作单次实测报告。
词错率 × 音素错率： 词错率统计词级别的替换删除插入，反映代码词是否被整个听错；音素错率统计发音单元级别的差异，反映母语口音和音近词造成的底层听辨偏差，二者搭配的原因是代码混合语音中一个词错可能只差几个音，加权特征编辑距离再补上发音特征距离，三者一起才能区分是完全听错还是音近可修复。
硬件与运行条件按原文交代，模型服务在 2 块 H100 上分卡部署，前端录音经任务编号轮询取回。补充材料方面，论文脚注给出演示与产物链接，但本次资源状态为暂时未能确认可达，因此只能写本次未能确认可达，不能写已公开可用。原视频链接同样按正文引用，不做可达承诺。
主结果在什么条件下支持什么判断
先看主观结果提出的问题，在实验室条件下初学者是否觉得可用。论文报告超 89% 评为公平及以上，具体分布需要与愿意使用率一起读。下表把原文连续句中的分布数字整理成可核对形态，表头单位与裸值保留原文写法，比较问题是各档占比如何构成超 89% 以及高意愿是否伴随保留意见。
| 评价口径 | Excellent | Good | Satisfactory | Fair | Needs Improvement |
|---|---|---|---|---|---|
| 体验等级占比 | 10.7% | 32.1% | 28.6% | 10.7% | 17.9% |
| 若顾虑解决是否愿用 | 25 out of 26 回答 Yes, definitely 或 Yes, probably | - | - | - | - |
表后解释要同时看到收益与代价。收益是公平及以上合计约 89% 且 26 人中有 25 人表示可能或肯定愿意用，支持语音母语问代码有较强 adoption 意愿的判断。代价与反例是仍有 17.9% 选需改进，且愿意使用是有条件的，若顾虑解决才用，论文未披露顾虑清单是转写错、延迟还是回答质量，因此不能把意愿直接读成课堂有效。未胜出项在这里就是需改进群体，复现时应追问他们的日志对应哪段链路。
再看客观语音结果。论文报告 CodeVaani 在多语言代码密集语音上全面低于基线，特别强调词错率降幅大。下表把与印度基线和多模态模型的对照放在同一宽表里，指标方向均为越低越好，条件是否一致需要分开注明。
| 语言或模型条件 | WER | PER | WFED | 对比对象与语言说明 |
|---|---|---|---|---|
| Gujarati 真人语音 | Saaras V3 45.3% 对 本框架 8.1% | Saaras V3 39.2% 对 本框架 3.4% | Saaras V3 14.1% 对 本框架 2% | 印度代码混合基线对本框架 |
| Bengali 真人语音 | Saaras V3 43.3% 对 本框架 23.5% | Saaras V3 22.4% 对 本框架 2.1% | Saaras V3 10.6% 对 本框架 1.2% | 同上 |
| Hindi 真人语音 | Saaras V3 24.6% 对 本框架 14.9% | Saaras V3 15.6% 对 本框架 11.4% | Saaras V3 8.1% 对 本框架 5.5% | 同上 |
| English 真人语音 | Saaras V3 70.5% 对 本框架 12.4% | Saaras V3 68.1% 对 本框架 7.9% | Saaras V3 26.2% 对 本框架 3.2% | 同上，基线英语失配明显 |
| 全局多模态对照 | Whisper 28.19% / Qwen3-Omni-Flash 11.61% / Phi-4 9.2% / 本框架 8.1% | Whisper 15.9% / Qwen3-Omni-Flash 3.52% / Phi-4 4.1% / 本框架 3.4% | Whisper 6.7% / Qwen3-Omni-Flash 2.05% / Phi-4 2.1% / 本框架 2% | Whisper 等对本框架，Phi-4 仅限英语 |
表后解释先给支持的判断，在所测 500 条真人语音上，本框架在所列语言与全局对照中均为最低，英语上相对 Saaras V3 的差距最大，说明分语种识别加修正对代码混合确有增益。但要指出两个限制，一是 Bengali 词错率仍有 23.5%，Marathi 按原文亦有 16.5%，不是所有语言都降到个位数，二是 Phi-4 只测英语，与多语言框架不是同条件胜负，论文已注明该边界。重提数字时新增的信息是语言间不均衡，这决定了复现时要分语言调修正提示而非只看平均。
哪一段在起作用，有无失败条件
论文没有给出标准的消融表，例如去掉修正后词错率回升多少、只用 Whisper 不用 Indic-Conformer 会差多少，因此不能编造拿掉后必然怎样的因果。能做的有源对照是把两组基线当作间接反证，一组是 Saaras V3 这类已为代码混合优化的印度识别器仍在所测集上显著高于本框架，说明单靠面向印度语音的声学优化不够，文本级代码先验有增量作用。另一组是 Qwen3-Omni-Flash 这类前沿多模态模型在全局词错率上为 11.61% 而本框架为 8.1%，支持拆分流水线在技术性代码混合语音上仍有优势的有限解释。
失败条件在原文中有两处可抓。一是作者承认语音识别模型没有完全解决混合语义，残留错误依赖修正，而修正只见文本不见音频，若初稿错得太离谱，文本先验也可能补错方向。二是 Bengali 与 Marathi 的剩余词错率仍明显高于 Gujarati，说明口音、语言与代码词密度的组合会影响上限。复现时应把这两处当作必测的压力条件，分别构造高噪声录音与符号密集查询，观察修正是否稳定，而不是只复现平均指标。
哪些量没有测，哪些结论不能推
未测量的量要逐项点名。延迟与成本没有报告，双 H100 分卡加异步轮询的实际等待时长未知，不能承诺低延迟部署。回答正确率没有独立度量，客观表只到转写层，不能把词错率低直接当作讲题对。误判率、跨说话人泛化、课堂长期学习增益、多轮追问的稳定性都没有数据，结论只能停留在单轮实验室可用性。
不能推的因果也要划界。相关性不是因果，愿意使用率高不等于学会编程，超 89% 公平以上不等于每种语言都好用，Bengali 的例子就是反例。总体趋势不等于每组都成立，全局最优不等于 Phi-4 在英语单项上无价值，原文限定 Phi-4 仅英语评测，跨语言推广需要待验证。缺失证据不是技术错误，论文如实报告了基线边界与未来工作，读者应把多轮对话、大规模代码混合语音数据训练、修正与生成统一以降低延迟这三项当作未验证方向。
要复现先做什么，需要哪些信息条件
复现先做最小可运行链路，而不是先复现数字。第一步按原文部署前后端骨架，用浏览器录音得到音频文件，确认能写入数据库、进入 Redis 队列、经 Celery 工作进程调度并按任务编号轮询取回。第二步接语音识别，先按语言分流，英语走 Whisper，印度语言走 Indic-Conformer，保存初稿。第三步接已做直接偏好优化的 Gemma-27B 做文本修正，提示词要覆盖音近技术词与符号结构两类，并把修正后查询显式存下。第四步接 Codestral-22B 生成同语言回答并同时存文本与音频。
信息条件方面，论文保留了关键模型名与硬件分卡，但未给出修正微调数据、提示词全文、解码参数与音频采样格式，这些是复现必须补的缺项。数据方面需要自采类似协议的真人语音，至少按语言分 100 条左右并标注参考文本，才能复算词错率、音素错率与加权特征编辑距离。代码开源、权重下载与系统可运行要区分，论文脚注的产物链接本次未能确认可达，因此复现不能依赖该链接，必须按模型名自行组织可运行版本并记录版本哈希。
何时值得尝试，还需补哪项验证
当学习者母语多样、英语打字吃力、问题集中在代码解释与调试单轮问答时，这套分语种识别加代码修正再生成的路线值得尝试，因为它把难听准与难讲懂分开处理，且修正后查询可展示可核对。当场景需要多轮追问、低延迟课堂互动或符号密集的白板推导时，应暂缓直接照搬，因为论文未验证这些条件。
还需补的验证有三项，一是分语言、分噪声、分代码词密度的细粒度转写对照，以解释 Bengali 与 Marathi 剩余误差的来源，二是回答层的独立正确率与人工评价，不能用自动转写指标代替人评，三是端到端延迟、并发与成本实测，以判断双 H100 异步方案在真实课程中是否可扩展。做完这三项，才能把当前报告的实验室 promise 推进为可部署的教学工具。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses