从听感打分到逐条核查：音乐生成评测如何拆解用户意图

在音乐生成App里输入“来一首深夜东京街头感的City Pop，带点Yorushika那种忧郁”，这样的操作不少人试过。

AI会照单生成一首歌：吉他清脆，鼓点工整，乍听也像回事。可总感觉哪儿别扭，又讲不出到底缺了什么。节奏出问题？编曲塞太满？还是所谓“深夜感”根本没做出来？

听众说不明白，AI系统本身更讲不清。眼下几乎全部音乐生成评测给出的都是笼统分数，例如“与描述匹配度85分”。听上去挺权威，却完全没说清哪一部分没对上——乐器选错、情绪偏了，还是提到的“Yorushika风格”压根没被理解。

山东大学、中国科学技术大学、中央音乐学院、昆仑万维和上海交大的研究团队想解决的正是这件事，他们给问题起了个名字：音乐意图对齐。

一个笼统的分数，漏掉了哪些信息

先说现有评测体系为何不够用。

业界常用的评测手段主要有两类。

一是**FAD（Frechet音频距离）**，衡量生成音频与真实音频在统计分布上的接近程度，跟某一首歌的具体内容对不对得上没有关系；二是**CLAP分数**，把文字和音频都映射到同一个数学空间里转成向量，再计算两者的接近程度，以此判断语义是否搭调。

要么是

两种方法给出的都是全局、笼统的相似度数值。好比在餐厅点了一份“少盐少油的宫保鸡丁”，端上桌尝一口说“嗯，像宫保鸡丁”，可服务员没告诉你盐到底少没少、油是不是真减了。要的是每条要求逐项是否被满足，而不是一个模糊的“像不像”。

继续沿用这种笼统打分，会有什么后果？一首歌可能总分很高——旋律好听、制作精良，却偏偏漏掉你明确点名的乐器，或者没抓住参考作品里最关键的味道。这类漏洞，笼统分数发现不了。

近年也有研究尝试把评测做细，比如把音频指令拆成一个个可验证的问题，用问答方式逐条核对。不过这些方法多数面向通用音频，关注声音语义和指令执行，并未真正对准音乐领域里专家在意的细节，比如和声走向、结构发展、情绪推进。

研究团队的思路，是把“对不对味”彻底拆开来评分。

把一首歌的要求拆成一张清单

他们的核心做法是：把每个用户请求转化成一份专属、可逐条核查的音乐需求清单，称为**音乐评分准则（Musical Rubric）**——针对某个具体请求量身定制的一组需求条目，每条都能独立地从生成音频里判断满足与否。

清单分两部分。

一部分叫

**显性需求（Base）**：请求文本里直接写明的要求，比如“要有钢琴”“节奏要快”。

另一部分叫

**隐性意图（Completion）**：请求里没直接写、但通过引用的艺术家、使用场景和上下文暗示出来的音乐特质。比如“要有Yorushika那种感觉”，背后隐含着特定的编曲风格、情绪基调和人声处理方式，得把这些显性挖掘出来。

这就像去裁缝店做衣服，说“我要件秋天穿的外套，有点复古学院风”。显性需求是明说的“外套”“秋天穿”，隐性需求则是“复古学院风”背后的东西——粗花呢面料、格纹图案、窄版剪裁。裁缝若只照字面做“外套”，不琢磨“复古学院风”具体指什么，成品肯定不是你想要的。隐性部分不挖出来讲清楚，双方永远鸡同鸭讲。

基于这一思路，团队构建了一个公开评测基准。

它叫**MuRA-Bench**：包含100条真实世界音乐生成请求，来自Mureka音乐平台上匿名收集的用户意图，并经三位音乐专家人工审核和修订。

100条请求中，68条为纯器乐，32条带人声，共含1566条评分条目，平均每条请求15.66个需求点。条目归入七个音乐维度：风格、乐器与人声、情绪、节奏、和声与旋律、结构与能量、制作与音色。

基准的构建过程颇费工夫。先由一个大语言模型根据用户请求草拟需求清单，区分哪些是显性、哪些属隐性补全。再由音乐专家逐条审核，删掉站不住脚的猜测，补上遗漏的约束，并把具体艺术家名字转化成可被听觉验证的通用音乐特征，而非直接当作模仿目标。有个细节：专家特意强调，“要像周杰伦的歌”这类引用不能直接变成“模仿周杰伦”，而要拆解成周杰伦音乐里可验证的具体特质，比如某种和弦进行方式、某种人声处理手法。这既为了评测可操作，也顺带避开了一些版权上的敏感地带。

清单列出来了，接下来要回答的问题是：生成的音乐究竟有没有逐条达标？团队用了一种音频问答的办法，让一个专门为音乐训练的大型音频语言模型上场。

这个模型叫MusicFlamingo，训练方向就是音乐理解，和声、结构、音色这类专业属性它比较拿手。让它去听每一首生成的歌，对着清单上的条目逐条回答"是"或者"否"。

这里有个精巧的处理：团队没有简单粗暴地取"是/否"的二元判断，而是把模型给出"是"和"否"背后的置信度数值提取出来，算成一个0到1之间的连续概率值。这个数值既保留了模型判断的把握程度，也避免了简单设一个阈值造成的信息损失。

打个比方，这就像一个考官批改开放性的问答题，与其简单打个对错，不如记下考官"有多确信这个答案是对的"。只取对错二分的话，那些模棱两可、答得半对半错的情况就会被粗暴地归到某一边，很多有用的信息就丢了。

研究团队拿这套打分办法跟另外七种评测方案逐一做了比对，其中有让模型直接按五分制打分的，有先写出文字描述再交由文本裁判判定的，还有传统的CLAP分数等。比对下来，靠音频问答加置信概率来打分的方式，跟人类专家的判断最对得上，各项指标都压过其他做法。

评测只是第一步，发现问题之后呢？总不能让用户自己去改提示词，改了还不知道对不对。光评测还不够，AI得学会改。

这就是团队提出的第二个核心贡献：MIRA（音乐意图优化智能体）。它是一个在生成模型外部运行的智能体系统，不改动模型本身的参数，而是通过反复生成、验证、修改提示词的方式，逐步逼近用户真正想要的音乐。

它背后立着三条设计原则。头一条，是把用户没明说的意图，整理成能一条条核对、不掺主观判断的清单。这跟前面说的评分准则搭法是一个路子，差别在于MIRA处理的是实时到来的用户请求，不是事先备好的测试集。

遇到含糊的引用或者场景描述时，MIRA会调用外部工具去查找相关信息。比如用户提到一个具体的使用场景"适合深夜独自开车听的歌"，MIRA会调用场景到音乐映射工具，把具体的使用场景或功能性描述，转化为可执行的音乐属性建议——也就是把这个场景翻译成具体的音乐特征建议。

中间还卡着一道证据门禁（Evidence Gate）：外部信息要想被拿来补全用户意图，得来源可追溯、有证据撑着，置信度还得过得了阈值，缺一样都不行。工具给的建议要是出处含糊、证据单薄，这条信息当场作废，不会带进后面的生成环节。说白了，就是不让AI自己脑补出用户压根没提过的东西，再照着这些臆想煞有介事地生成音乐。

第二个原则是用树状搜索的方式，在探索和利用之间找平衡。

那为什么非得用搜索，而不是生成一次、修一次就完事？音乐生成本身带随机性，同一个出问题的点，往往存在好几种都说得通的改法。要是只认准一条路死磕，很可能修好了这个毛病，反倒把原先做对的地方弄坏了。

MIRA把整个优化流程搭成一棵搜索树（Search Tree）：树上有多个节点，一个节点就是一次具体的生成尝试，提示词、生成的音频、验证结果、攒下的反馈记忆都记在里面。

每一轮，系统先从已有分支里挑出潜力最大的节点，再朝几个不同方向各生成一份修改候选，分别去生成音乐、分别去验证，等这一层跑完，再放到一起比，定下留谁、淘汰谁。留下的节点有两类：一类是综合得分最高的，另一类是在那些得分垫底的需求条目上表现格外突出的，这么一来，整体表现好的方向不会丢，个别老大难的薄弱环节也不至于一直没人管。

这套打法像登山队规划路线。山上有好几条可能通向峰顶的小路，老练的向导不会把宝全押在一队人一条路上，而是兵分几路往上探，走一段就互相通个气，走不通的路线砍掉，有戏的路线留着继续加人往里走。只派一队走一条路，万一半道撞上悬崖，整个计划就得推倒重来，先前攒的经验也白费了。

搜索的预算就那么多，团队定了两档：紧凑模式总共生成3次；宽松模式总共生成9次，这数字把最初那一次也算进去了。两档用的是同一套搜索机制，差别只在能跑多少轮。

第三个原则，是让搜索树上的每条分支都拥有自己的记忆，而不是只把最终那个最高分的结局记下来。

这一步妙在哪？它既会记下一次修改比上一版是好了还是坏了，也会把同一层里彼此竞争的几个候选摆在一起比，看这个方向相对别的方向是强是弱。团队给这套机制起的名字是

**树状结构反馈记忆（Tree-Structured Feedback Memory）**：顺着搜索树的分支路径，记下每次修改带来的具体变化，既包括跟上一版比是进步还是退步，也包括跟同层其他候选比谁优谁劣

评测里难免有细小的随机波动，团队怕它被当成真实变化，就设了一个容忍区间：幅度在正负0.03以内的，一律视为“没有实质变化”；只有超出这个范围，才会被记成明确的进步或退步。

有了这套记忆，AI下一轮提修改建议时就不用凭空乱猜了，它手里有具体经验，比如“这个方向之前试过，效果不行”，或者“这个方向上次让某个需求点明显变差了”。打个比方，这就像一个学生整理错题集，不是只写一句“这题做错了”，而是写清楚“上次我是这么想的，错在哪，下回碰到类似的要绕开这个思路”。少了这种细致的错题分析，学生多半还会在同一个坑里再摔一次。

不同分支之间的记忆是隔开的。一个分支看不到另一个分支完整的提示词，也看不到它私有的尝试记录，这样搜索过程中各个方向才能保持足够的多样性，不至于所有分支都抄同一个答案、最后趋同。每来一个新的用户请求，所有记忆都会清空重来。

实测效果：开源模型追上了商业大厂

设计讲了这么多，到底管不管用？

团队选了三个开源音乐生成后端做测试：ACE-Step v1.5 Turbo、SongGeneration2 Large和YuE2-3B；对照组是十个商业系统，包括MiniMax的音乐模型、Mureka的V9和V9.5、StepAudio 3 Music，以及Suno从v4到v6的多个版本。

结果显示，在生成预算为9的宽松模式下，MIRA让ACE-Step的整体对齐得分提升了12.9%，让SongGeneration2提升了19.0%，让YuE2-3B提升了7.3%。这种提升并非昙花一现，显性需求和隐性意图两个维度的得分都在往上走。

商业系统之间的版本对比也很有意思。Suno从v4到v5.5，整体对齐分数从73.6一路涨到81.9，v6稳定在81.8。看得出来，整个行业确实在往“更懂用户意图”这个方向使劲，不只是把音质做得更逼真。

最出人意料的结果是，开源模型YuE2-3B配上MIRA之后，整体对齐得分达到82.1，比当前最强的商业基准Suno v5.5的81.9还高一点点。ACE-Step配上MIRA则从67.6涨到76.3，超过了MiniMax音乐2.6的75.9分。

这个结果分量不轻。一个开源模型，没改动自身一个参数，光靠外部的搜索和反馈机制，就追上甚至超过了商业巨头砸大量资源训练出来的系统。说到底，“意图对齐”这件事，只把生成模型本身做得更强还不够，怎么用好反馈、怎么设计搜索策略，同样留出了巨大的提升空间。

团队还组织了人工盲听评测，专家在不知道哪首歌出自哪个系统的情况下打分。结果是，ACE-Step加上MIRA后的评分，无论整体意图、显性意图还是隐性意图，都明显高于原始的ACE-Step，也超过了MiniMax music-3.0，只是还没追上Suno v5.5。

团队另外做了一个公平对比实验：同样9次生成预算，让MIRA和简单粗暴的“生成9次挑最好的一个”（Best-of-9）策略正面比。MIRA在ACE-Step上领先3.6分，在YuE2-3B上领先2.35分左右。可见MIRA不是靠“多试几次”取胜，它的搜索策略本身就比盲目多次采样更聪明。

把各个部件拆开看贡献，团队发现，给Best-of-9加上工具补全意图这一步，隐性意图得分就能从0.719提到0.748；再加上自适应搜索，隐性意图继续涨到0.781；最后加上树状记忆，整体得分和分维度得分都达到最高。这就像搭积木，每加一块都踩实了，没有哪一块是摆设。

写在后面

读完论文，有个细节让人反复琢磨：团队特意强调了版本迭代的趋势，Suno从v4的73.6分涨到v5.5的81.9分。这条曲线摆在那里，其实在悄悄说一件事：“听起来好听”和“听懂了你要什么”，是两件正在分道扬镳、又需要同时追赶的事情。过去大家默认音质越做越好，模型就越来越强，但这篇论文提醒我们，哪怕音质已经相当逼真，意图对齐依然是个独立的维度，需要专门下功夫。这两条曲线不一定同步往上走。

另一个意外之处是，研究者没有重新训练一个更懂用户的生成模型，而是站在生成模型外面，搭了一套搜索和反馈的脚手架。思路挺朴素，有点像是承认了“现在的生成模型已经足够强，问题不在于它生成不出好音乐，而在于我们没有有效的方式告诉它哪里需要改”。这种对现有能力的信任，反而撑出了一个很大的改进空间。

团队的做法是把“引用某个艺术家”拆成一项项可核实的音乐特质，而非把它直接当成模仿的对象。这么处理有很实际的考虑：用户真实的审美需求要照顾，同时还得避开照搬他人作品惹来的版权麻烦。这种拆法，往后说不定会成为AI音乐生成领域谁都躲不开的常规操作。

用过AI写歌的人，大概都碰见过那种“听着凑合，可味道就是不对”的时刻。那个讲不清的“不对味”，其实能拆开、能量化，也能一条一条改过来。

Q&A

Q1：MuRA-Bench是什么？

A：MuRA-Bench这个评测基准收录了100条真实世界的音乐生成请求，均来自Mureka平台的用户意图，并由三位音乐专家修订，可以逐条核查生成的音乐有没有满足显性要求和隐性意图。

MIRA是怎么帮AI写出更贴合用户心意的音乐的？

它是个外部智能体，生成模型的参数一点没动。做法是靠工具把意图补全，用树状搜索一次生成多个候选，再借助分支记忆的反馈反复打磨提示词，一步步逼近用户真正想要的那个效果。

开源音乐生成模型接上MIRA之后，表现怎么样？

实验数据是：YuE2-3B配上MIRA，整体对齐得分82.1分，高过商业系统Suno v5.5的81.9分。这说明开源模型只要搜索优化策略用得对，也能跟商业大厂的产品打平甚至胜出。