把力度、角色与延迟一起改写：jam_bot 如何实现可接话的音乐对话

英文题目：Enhancing Expressive Musical Conversation in the jam_bot.

会议身份：conference:nime:2026:conference-paper-id:nime2026_73

✅ 来源为官方会议 PDF；表格与 Figure 按原文证据绑定。PDF 公式以原页区域图片展示，未冒称作者原始 TeX。

会议来源：官方记录 · 官方 PDF

标签：#Transformer #高效推理 #实时处理 #音乐 #符号音乐生成

评分：6.4/10 | 创新 1.2/2 | 技术严谨 1.2/1.5 | 实验充分 0.8/1.5 | 清晰度 0.8/1 | 影响力 0.9/1.5 | 开源 0.2/1.5 | 可复现 0.1/0.5 | 工程/实践 1.2/1.5

排名：前50% | 文档类型：系统技术报告

👥 作者与机构

• Lancelot Blanchard：机构信息未能从会议 PDF 纯文本可靠映射
• Perry Naseck：机构信息未能从会议 PDF 纯文本可靠映射
• Katherine Liang：机构信息未能从会议 PDF 纯文本可靠映射
• Joel Tan：机构信息未能从会议 PDF 纯文本可靠映射
• Heidi Lei：机构信息未能从会议 PDF 纯文本可靠映射
• Cheng-Zhi Anna Huang：机构信息未能从会议 PDF 纯文本可靠映射
• Joseph Paradiso：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

该工作处理现场钢琴输入到富有表现力符号音乐响应的实时生成，难点在于原系统缺失力度维度、交互受限于固定速度与固定轮换、外部输出设备延迟破坏节奏连贯性。方法链分四步：先将每音符从起音时长音高三元组扩展为增加力度词元的四元组并微调预训练AMT以获得力度表达，其输出进入基于ggml的手写计算图推理后端以承载更长序列的实时生成。再由脚踏开关连续控制器信号标注的双乐器呼叫响应微调限定演奏者提示与系统回答的角色分工，最后由延迟补偿调度器利用超实时生成换取的提前量将生成音符提前发送以对齐物理发音。相比延续式生成的原系统，新机制在训练时用显式控制信号划分双声部角色，并在输出时区分全局偏移与逐音高逐力度查找表延迟，从而支持无固定速度的自由呼叫响应与可切换设备的节奏对齐。在吞吐评测设置下，416M参数模型在ggml CUDA后端的Tokens/second指标为247.65，高于ONNX CUDA后端的Tokens/second指标124.84。该结论适用边界受限于与Jordan Rudess合作录制的约3.5小时无固定速度独奏语料与特定自动钢琴链路验证，尚未验证跨风格与跨设备泛化。推理开销方面原文以吞吐与延迟形式披露成本，还报告了170M模型与Metal及CPU后端的多档延迟与吞吐实测。

🔗 开源与复现资源

• 演示资源：https://jambot.media.mit.edu/nime2026 — 暂时无法访问
• 第三方资源：https://ggml.ai/ — 链接可访问（HTTP 200）
• 第三方资源：https://onnxruntime.ai/ — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么：现场钢琴对话需要系统做什么？

这篇论文的输入是演奏者在舞台上实时弹出的符号音乐信号，具体就是通过键盘与踏板产生的音符开关、时值与力度信息，目标是让机器在同一首即兴里接得上话。读者可以这样想象学习任务：人弹一段没有固定速度与小节数的乐句，机器要在几秒内生成一段风格连贯、强弱合理、节奏卡得准的后续，并在自动钢琴上播放出来。

原文开场交代的目标很明确：此前 jam_bot 已经能在公开演出中实时生成与输入连贯的符号序列，但它在速度、曲式或音乐角色上限制了表达，例如固定交换四小节，或者不建模力度，或者输出存在机械延迟。本文必须保留的关键信息是 4 个并列改进：力度建模、提高吞吐、新呼应训练模态、补偿输出延迟，以及两个可定量核对的评价：吞吐提升与延迟补偿效果。输出形式是可直接播放的带力度 MIDI 序列，评价时用每秒词元数与节拍对齐分数来衡量，听感样本放在伴随网站上。

本文写作只讲论文实际做的钢琴呼应任务，举例会标明是教学例子，不虚构未报告的分数。

对于刚进入音频领域的研究生，先要建立白话理解：符号音乐不是波形，而是像乐谱一样的离散事件，告诉系统何时按下哪个键、按多久、用多大力。力度就是 MIDI 协议里 0 到 127 的整数，数值越大通常越响，也影响音色与乐句起伏。语言模型在这里被当作音乐语言模型使用，把一串音符符号当作一句话来续写。实时因子大于 1 的意思是模型造谱速度比实际演奏速度快，这样才有时间提前算好后面的音符。

此前路线如何处理即兴：从规则到大模型缺了什么？

论文把相关工作分成 3 条路线对照。第一条是早期交互系统，例如用遗传算法进化爵士独奏的 GenJam，以及用马尔可夫模型在线学习演奏者风格的 Continuator，它们的输入与本文相同都是现场演奏，目标也是风格连贯的回应，但监督与运行阶段不同，多为小规模统计学习而非大规模预训练。第二条是近年的神经与隐空间即兴方法，强调潜变量操控与伴奏生成，输入可能是节奏或管风琴等特定场景，目标更偏向质感变化。

第 3 条是音乐语言模型路线，例如性能循环网络与音乐 Transformer 曾建模过力度与表现力，而预知音乐 Transformer 为了在大规模数据上预训练基座模型牺牲了表情建模。本文的差异在于运行阶段：它要求在演出中实时调用数亿参数的大模型，并用脚踏开关控制轮次。与同输入同目标的工作相比，本文不是提出全新基座模型，而是把已在大规模数据上预训练的模型拿来做表达性改造。

教学例子：这好比不重新写字典，而是给已有字典增加表示语气的标点，并教会它在对话中何时使用。论文明确说此前 jam_bot 的 3 种交互策略是按固定时间、按乐句手势与按需触发，后续工作加入脚踏开关控制手势起止，但输出仍随机不可控，这正是本文要解决的对话可控性问题。

限制在哪里：为什么原来的接话不够自然？

论文把不自然归纳为 4 个可操作的问题。第一，词表缺力度，模型只能决定弹什么音与弹多久，不能决定用多大力触键，共享词汇少了 1 维。第二，序列变长后吞吐不够，加入力度会让每个音符从 3 个词元变成 4 个词元，固定上下文能装的音符变少，生成压力变大。第三，训练任务与演出期待错位，原模型在 PiJAMA 等多样化数据上做续写训练，演出时演奏者却期待像人与人一样的呼应，角色没有在训练时讲清楚。

第四，输出链路有延迟，自动钢琴等机械乐器需要提前量才能发声，不同力度延迟还不一样，若不补偿，机器的节奏与声部顺序会被乐器本身扭曲。理解这 4 个问题后，后文每个方法都能对号入座：力度表示解决词汇问题，加速框架解决吞吐问题，呼应数据解决角色问题，延迟表解决节奏问题。

四步全景：一个乐句如何变成带力度的回应？

先沿一个样本走完全程。演奏者在自动钢琴上弹出一句任意长度与速度的呼叫，同时踩下脚踏开关，系统把这段 MIDI 记录为呼叫段；松开开关后，呼叫被送入已微调的预知音乐 Transformer，模型以呼叫为条件自回归生成回应段的四元组序列；生成结果经过延迟补偿模块查表提前调度，再送到自动钢琴播放。整个链路依赖实时因子大于 1 留出的提前量。下面这张现场图展示了这种演奏形态，值得先看人和机器如何共用一台琴。

看图路径： 1. 先看演奏者右手在自动钢琴键盘上的位置与琴盖反射；2. 再找地面上的黑色脚踏开关与演奏者左手的关系；3. 最后确认琴键有自动下沉痕迹，区分人弹与机器弹

论文图 1。原论文 Figure 1：“Musician playing with the jam_bot on a player piano. The MIDI foot switch is used to trigger the system generation.”。

上图显示 1 位演奏者坐在三角自动钢琴前，右手正在中音区触键，左手离开键盘，地面上可见黑色脚踏开关，图注说明该开关用于触发系统生成。像素细节支持方法理解：人与机器不需要两台琴，机器的回应直接由同一台琴的机械结构发出，因此机械延迟必须计入；脚踏开关是轮次的物理边界，踩下表示人在说，松开表示轮到机器说。这种设计把何时提示、何时刷新、何时回应的控制权交还给演奏者，为后文呼应训练提供了可标注的边界信号。

力度如何写进词表：为什么是加一个词元而非合并？

白话先行：词表就是模型认识的所有符号清单，词元是清单里的最小单位。预知音乐 Transformer 原来把每个音符写成 3 个词元：起始时间、在 0 到 9999 之间取值，时值、在 0 到 999 之间取值，以及音符编号、把音高与乐器折叠成一个整数。论文要加入力度、在 0 到 127 之间取值。作者比较了两种写法。一种是把力度与时值合并成一个混合词元，类似原来把音高与乐器合并的做法，但这会让词表膨胀到约 128 乘 1000 量级，新增大量随机初始化的嵌入需要从头学习，训练更慢更不稳定。

另一种是每个音符写成 4 个词元的元组，词表只增加 128 个力度符号与 128 个用于预知机制的预期力度符号，代价是同样长度上下文能装的音符变少。论文选择第二种，并相应扩大输入嵌入与输出投影层，新参数随机初始化后训练。

力度 × 预知音乐 Transformer： 力度负责表达每个音符的强弱与触键意图，预知音乐 Transformer 负责在长上下文里预测下一个符号序列，二者搭配的理由是把力度写成与起始时间、时值、音高乐器共生的第 4 个符号，让大模型在保持预训练乐句能力的同时学会何时轻何时重，组合后模型输出的每个音符都自带可执行的强弱信息。

为增加数据多样性，训练时还对单个音符力度做随机缩放，缩放因子在 0.5 到 2.0 之间按一定比例施加。除这些改动外，训练方式与原文前作相同，并延续允许模型过拟合训练数据的策略，以在演出时保证风格与结构的可预期性。作者也坦承风险：改词表与表示可能削弱在大规模数据上预训练的好处，但引用符号音乐迁移学习的结果说明在稍有不同的表示上继续微调仍能保留预训练收益，因此在新数据集上用新表示微调中等规模模型。教学例子：这像是给习惯简谱的人增加强弱记号，谱面变长了，但读谱能力还在，只需少量带强弱的练习就能适应。

吞吐如何提高：ggml 相对 ONNX 做了什么取舍？

白话先行：吞吐在这里指每秒能生成多少词元，延迟指生成一个词元平均需要多少毫秒，二者互为倒数乘 1000。原来系统用微软的 ONNX Runtime 在 C++ 里跑模型，它能自动追踪计算图、跨平台支持英伟达与 Linux，落地快，但体积大、开销大，在某些平台上编译耗时很长，且对苹果 Metal 加速支持不好，实际只能用 CUDA 后端。新方案改用 ggml 框架，需要手写计算图，实现工作量更大，但优化更彻底、开销更小，可编译成按后端与指令集区分的动态库，启动时自动选择最优的中央处理器后端，并支持英伟达、苹果 Metal、Vulkan 与超威等后端。

ONNX Runtime × ggml： ONNX Runtime 负责用通用计算图快速落地模型，ggml 负责用手写计算图与精简运行时降低开销并适配多种加速后端，二者搭配的理由是力度建模把序列变长后必须用更高吞吐抵消计算量，组合后同一模型在消费级苹果电脑与英伟达显卡上都能保持超过实时播放速度的生成。

实际效果是论文报告在 CUDA 上两档模型吞吐都提升约 2 倍，在中央处理器上也有较小提升，且最小的 170M 参数模型能在特定中央处理器上跑短生成，苹果笔记本也能演出，这打开了更广泛的复现可能。需要区分的是训练资源与推理开销：这里的加速只改善推理阶段每秒词元数，不改变训练所需的计算量；总体趋势成立不代表每一步都更快，因为随着上下文填满，每秒词元数会下降并趋于平稳，论文因此采用运行 15 秒后再读数的方法。

延迟如何补偿：全局提前与逐音符查表有何不同？

白话先行：延迟补偿就是把音符比目标时刻稍早发出，让乐器机械动作与网络传输恰好在目标时刻完成。论文设计两种方式。全局偏移在界面文本框配置一个毫秒数，实践中用数字音频工作站报告的延迟已够用，更精确可用外部录音测量。逐音符与按力度偏移则从逗号分隔文件加载查找表，下拉菜单可切换不同输出设备的画像。建表方法是可复现的操作：准备一个 MIDI 文件，覆盖乐器每个音符并按力度递增排列，音符间隔足够让余音基本衰减。

在工作站播放的同时录制输出设备的实际发声；用脚本以音频分析库检测录音中每个音符的起始时刻，与原始 MIDI 目标时刻比较，并扣除音频接口报告的采样延迟；对每个音高位置不同的物理乐器用多麦克风录音，按麦克风与音符距离校正，取最早检测值；最终把音符、力度与毫秒偏移写入表格。该方法不计工作站与接口自身延迟，但实践中这部分不可感知。

实时因子 × 延迟补偿： 实时因子负责保证模型生成速度快于实际播放速度，延迟补偿负责利用抢出的时间余量把音符提前调度，搭配的理由是只有生成够快才有提前量可用于抵消机械与传输延迟，组合后自动钢琴在不同力度下仍能按原定节奏与声部顺序发声。

为什么力度让补偿更重要，论文给了机制解释：若输出设备对不同力度引入不同延迟，机器想好的节奏与音符顺序会被乐器改写，评价小节会用实例展示这种扭曲。教学例子：这像指挥知道大鼓手举槌慢半拍，就提前半拍给手势，且重击与轻击提前量还不一样。

呼应数据如何构造：脚踏开关怎样变成监督信号？

这一节承担训练与数据构造的讲解。论文认为此前不可控有两个原因：一是 PiJAMA 数据风格太杂，独立生成容易跑偏；二是训练任务是续写，与演出时期望的呼应不一致。为此作者与演奏家合作录制约 3.5 小时的独奏钢琴数据，全程不限定速度，录制时踩下映射到连续控制器 1 的脚踏开关表示呼叫，松开后表示回应。形式化目标是学习在给定呼叫音符序列条件下生成回应音符序列的分布。

实现上沿用此前的词元化，但用两个 MIDI 乐器编号区分角色，0 代表呼叫，1 代表回应，各自占用 128 个音高符号区间，而时间、时值与力度词元在两种乐器间共享。这种做法把音乐角色在训练时强制执行，而不是期待在演出时自然涌现，类似指令微调中先由专家示范期望行为再微调。推理时演奏家踩开关录制提示并暂停回放，松开后提示送入模型并恢复播放。下图把标注过程可视化，是理解监督来源的关键。

看图路径： 1. 先看上半部分原始文件中的灰色音符条与下方连续控制器曲线；2. 再看控制器从 0 跳到 127 又回到 0 的方波边界如何切分乐句；3. 最后看下半部分橙色与蓝色如何对应两种乐器编号

论文图 2。原论文 Figure 2：“The annotation process of the call and response model.”。

上图上半为原始 MIDI 文件示意，深浅灰色条为录制的音符，下方折线为脚踏开关记录的连续控制器信号，从 0 跳到 127 再回到 0，中间箭头标示乐器映射，下半为切分后文件，橙色为乐器 0，蓝色为乐器 1。可见动作是：凡是开关为高电平阶段的音符整体映射为一种颜色，低电平阶段为另一种颜色，时间位置不变，只有身份标签改变。这说明监督来源不是人工事后听写，而是演奏同时踩出的物理信号，因此角色边界与演奏意图一致。

呼叫 × 回应： 呼叫负责承载演奏者即兴提出的动机，回应负责承载系统要学习的接话方式，二者搭配的理由是用不同乐器编号把两段音乐在词表层面分开，使模型在训练时就明确谁在提问谁在回答，组合后推理时踩放脚踏开关就能稳定触发 1 次可预期的轮次交接。

论文未报告该微调的具体学习率、轮数与冻结策略等超参数细节，这是复现时需要补看代码或追问的缺项，不能从模型名称推定实现。已知的是基座为中等规模预知音乐 Transformer，训练数据为上述专家数据加力度增强，目标是呼应分布而非通用续写。

实验测什么：在什么条件下才可比？

评价聚焦两个可定量的问题：吞吐与延迟补偿，力度与呼应质量留给读者到伴随网站听样本。吞吐测量方法是保持运行平均，每秒统计生成词元数，等待 15 秒后再报告，此时上下文已填满并趋于平稳；同时报告单词元延迟毫秒数。最大上下文设为 120 个词元，对应无力度时 40 个音符、有力度时 30 个音符。比较对象是同一模型在 ONNX 与 ggml 下的表现，硬件覆盖超威锐龙中央处理器、英伟达 4090 与苹果 M3 Max，模型覆盖 170M 小模型与 416M 中等模型。

延迟补偿实验用贝多芬《致爱丽丝》首分钟 MIDI 转录，把每个音符力度按正弦波改写，周期 4 秒，在 20 到 70 之间振荡，以考验不同力度下的稳定性；在自动钢琴上用 4 种策略回放：无补偿、固定上界延迟、平均延迟、逐音符按力度补偿，录音后与合成参考音频比较。用节拍估计模型估计节拍，再用音频信号处理库报告对齐分数，取 5 个不重叠窗口。指标方向是分数越高对齐越好。资源状态方面，演示链接本次未能确认可达，应写本次未能确认可达，而第三方框架链接当前可用。

论文未报告人类听感打分与误判率，因此不能把对齐分数当作审美评价。

主结果是什么：多快才算够快，多准才算对齐？

先看吞吐。论文报告使用 ggml 后在 CUDA 上两档模型吞吐都提升约 2 倍，中央处理器上提升较小，且 ggml 使苹果加速硬件可运行，这是可部署收益。注意比较必须保留原文实际可运行的策略：ONNX 的 CUDA 与中央处理器、ggml 的 CUDA、中央处理器与 Metal 都是实际可运行项，不能只挑最优一项代替整体。由于原表选择不可用，这里用连续原句可覆盖的上下文容量来说明力度带来的固定代价，避免把表格数字与正文数字混为一谈。以下整理表提出的问题是：在固定词元预算下，加入力度会吃掉多少音符容量，公平条件是同一最大上下文，指标方向是能装音符数越多越好。

上表后解释：加入力度后容量下降是预期代价，因为每个音符从三词元变为四词元，但词表只多 128 加 128 个预期力度符号，远小于合并方案的膨胀；未胜出项是合并方案，它在容量上可能更省词元，但因嵌入从头学习多而不被采用；边界是长乐句仍会被截断，实时生成需配合 120 词元小窗口滚动。再看延迟补偿，下图是关键证据，导读后给出。

4 种补偿条件下节拍对齐分数的分布是本节核心，先看箱体高低再看离散程度。

看图路径： 1. 先看横轴四种补偿条件从左到右的排列顺序；2. 再看纵轴节拍对齐分数越高表示节奏越准；3. 最后比较红色无补偿箱体与最右侧逐音符补偿箱体的高度差异

论文图 3。原论文 Figure 3：“Beat alignment with and without latency compensation, as measured by the madmom F1 score”。

上图像素显示 4 个箱体从左到右依次为无补偿、固定上界、平均、逐音符按力度补偿，纵轴为节拍对齐分数，越高越好。红色无补偿箱体贴近零线，固定上界箱体升至中低位，平均与逐音符箱体明显更高且更紧凑，最右侧绿色箱体中线最高且上须线接近 1。原文报告无补偿时在 5 个样本上分数为 0.0678，几乎无对齐，逐音符补偿中值为 0.7834，平均补偿中值为 0.7638，固定上界中值为 0.3386。机制解释是延迟随音符与力度大幅变化，固定上界过于保守，平均已接近真实，而逐音符表最精细。限制是该结论仅在该琴与该曲目首分钟、正弦力度条件下测得，不能推广到所有乐器与曲风。

四种补偿之间差多少：能否用平均代替查表？

把延迟补偿当作消融来读：测什么，是 4 种调度策略在同一录音与同一对齐流程下的节拍分数；与谁比，是无补偿基线与 3 种补偿变体；条件是否一致，是同一 MIDI 文件、同一自动钢琴、同一 5 窗口聚合；指标方向是分数越高越好。以下整理表用原文连续原句可逐字覆盖的数字，避免引入表格矩阵中无法绑定的精度。

上表后解释：主要收益是任何补偿都好于无补偿，但固定上界明显弱于平均与逐音符，说明用单一最大值提前会打乱内部时值比例；具体代价是逐音符表需要为每台设备录制建表，耗时且需多麦克风校正，而平均延迟几乎达到相近中值，在不想建表时是务实折中；未胜出项固定上界在此琴上失败，但不代表在延迟方差小的设备上无用；未评测边界包括网络传输抖动、不同曲目密度与踏板等控制信息，原文未测量这些条件下的对齐变化。总体趋势不等于每窗口都成立，箱体仍有离散，最高窗口接近 1 而最低仅 0.6 以上，复现时应报告分布而非单点。

还有哪些做不到：表达与通用性边界在哪？

论文在未来工作与结论中明确了 3 类限制。第一，表达维度只做到力度，延音踏板、弯音与其他连续控制尚未建模，难点在于密度差异大：弯音消息很密会拖慢实时生成，踏板很稀会超出上下文依赖，词元化需要重新设计。第二，吞吐仍有提升空间，作者提到蒸馏与更先进量化等方法可能继续加速，但本文未验证这些方法的效果，不能承诺它们一定改善延迟或质量。

第三，风格通用性受限，用单人专家数据过拟合能保证演出时风格稳定，但换演奏者与风格就需要采集更多样数据并研究新的微调策略，否则会丢失精确的风格依从。此外评价也有缺项：力度与呼应质量只有线上样本可听，没有人类评分；延迟补偿只在一台自动钢琴与一首曲目上验证；训练超参数、数据增强比例与重置时机未完整报告。区分直接报告与推测：吞吐翻倍与对齐分数是报告，保留预训练收益是有限解释，而更广泛乐器与曲风上的表现是待验证。

复现先做什么：按什么顺序搭起可演出的系统？

若要在实验室复现，建议按学习依赖顺序操作。先准备基座：获取中等规模预知音乐 Transformer，按四元组扩展词表并随机初始化新增嵌入，注意不要从模型名称推定优化器与冻结方式，以代码为准。数据方面复刻脚踏标注流程：把开关映射到连续控制器 1，踩下录呼叫、松开录回应，全程不限速，录够数小时后按开关电平切分为两种乐器编号，时间时值力度词元共享。训练时加入力度随机缩放，并延续过拟合以保风格的策略，但要记录验证集以防跑偏。

推理侧把 ggml 编译为按后端区分的动态库，启动时自动选优，最大上下文先用 120 词元对应 30 个带力度音符，运行 15 秒后再测每秒词元数。输出侧先用全局延迟试听，再按论文 5 步建逐音符表：制表、播放录音、检测起始、扣除接口延迟、多麦克风校正。何时值得尝试：当演出允许演奏者用脚控制轮次、且输出为机械乐器或网络链路时，这套方案收益最大；若只是工作站内合成，可先只用全局补偿。

代码开源、权重下载与系统可运行是三件不同的事，论文只说明方法与部分实现框架，需以实际仓库与伴随网站可达性为准，本次演示链接未能确认可达，不应写已公开可用。

收束：这四步如何共同回答音乐对话？

回到最初问题：机器如何与人进行有表情、可预期、节奏准的音乐对话。力度建模回答表情，用最小词表代价换来强弱词汇，但吃掉约 1/4 上下文容量；ggml 回答速度，用手写计算图换来约 2 倍吞吐与苹果设备可演出，但实现成本更高；呼应微调回答角色，用脚踏信号在训练时讲清谁问谁答，换来直觉的轮次，但牺牲风格多样性；延迟补偿回答节奏，用逐音符查表换来从 0.0678 到 0.7834 的对齐跃升，但需要为每台设备建表。

论文特有的误解需要澄清：过拟合在这里不是失误，而是有意为演出稳定性做的选择；平均延迟接近最优不代表查表无用，在力度相关延迟大的琴上查表仍是最准；吞吐提升不等于音质提升，它只是为表达腾出时间余量。下一步验证应补上双盲听感、跨乐器延迟表与踏板等控制的建模，再谈更通用的音乐对话系统。

📐 原文公式与排版

以下展示论文原页中的数学表达区域，保留原始上下标、分式和符号排版。区域序号仅用于本文导航，不是论文公式编号。

另有 2 个候选区域因边界不明确或图片数量、尺寸限制未展开；请查看完整论文中的原始排版。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1
• 评分模型：muse-spark-1.3-contributor
• 评分请求协议：openai_responses

← 返回 nime-2026 论文汇总