Manus团队测模型一点微小的经验

「今天很好学」

两天前刷即刻看到@胡迪Hoodie写的一条如何衡量 Agent 产出的调研报告是否易读的帖子，他选用的衡量指标是隐喻率，即通过模型使用比喻的频率来衡量。

比如 Claude Fable-5 智商极高，但写的东西我要读两遍，很大的原因是它打比方跟机关枪一样，完全不说人话。

我找@胡迪Hoodie聊了后才知道，哥们在Manus 团队做评测相关的工作。其中一个很重要的部分是 Research Bench，即在Manus里评测模型产出的 Reseach 质量，隐喻率这个指标就是在做 Research Bench过程中产生的。

众所周知，大部分工作场景要比Coding场景更难构建可验证的标准。

而胡迪Hoodie的思路就是从很难验证的复杂工作中，找到某个反映用户关键体验的信号，来客观评价模型生成的结果。

我认为@胡迪Hoodie的思路很有启发，于是邀请他在原即刻帖子的基础上做了一些补充，整理分享如下：

LLM 在 Coding 能力渐入佳境的同时，文本能力好像在退步，写的文字越来越狂野、难读。

在 Manus 中，深度研究撰写报告是非常基础的用户场景。如何构建有效的指标来衡量报告质量，并对 Harness 迭代带来有效反馈就成了当务之急。

从源头看，一份研究报告的好坏只涉及两个维度：

第一，报告包含哪些信息？这决定了用户是否能读到想读的且高质量的信息。

第二，这些信息是如何组织在一起的？这决定了用户能否低成本地理解读到的信息。

从这两个维度出发可以构造出非常多的指标，今天介绍 Manus 实践的 2 个指标：「信息量」与「隐喻率」。

这 2 个指标在构建思路上有两个相同的原则：

首先是有效，让 Signal 能简洁直接地反映一个具体的模型特点，通过分数高低，帮助我们顺藤摸瓜地从产品上把问题解决掉。

其次是可靠，让所有指标都尽量可以量化，让大规模自动化的评测也能得到稳定的结果。

01

信息量

2025年，不少 AI research 产品都「优化」得像 OpenAI 的 DeepResearch 一样写得足够长，给用户提供足量的价值感。

「写得长」这个优化目标极具迷惑性。用户使用 agent 做调研、写报告，最本质的需求是高效获得足量相关信息。

而一份充满有效信息的报告不一定比充满废话的报告写得长，后者将极大伤害用户体验。

因此，我们构建了「信息量」指标，用 LLM 抽取一份报告的事实点/数据点的数目。

比如，同一主题下，模型 A 的报告写道：

「2001 年，苹果发布了 iPod，采用东芝 1.8 英寸微型硬盘提供 5GB 容量，配合 Click Wheel 点按轮和 FireWire 高速接口，以「1000 首歌装进口袋」重新定义了便携音乐播放器。2003 年，iTunes Store 上线，以每首 0.99 美元的单曲模式解决了盗版泛滥的行业痛点。」

LLM 抽出 7 个事实点：「iPod 于 2001 年发布」「东芝 1.8 英寸微型硬盘」「容量 5GB」「Click Wheel 点按轮」「FireWire 高速接口」「iTunes Store 于 2003 年上线」「单曲定价 0.99 美元」。

模型 B 写同一段则是：

「iPod 的问世无疑是数字音乐史上的里程碑事件，它彻底改变了人们获取和消费音乐的方式。苹果以极具前瞻性的产品理念，将 5GB 存储空间装进了一台掌上设备，开创了便携音乐播放器的全新时代。随后推出的 iTunes Store 更是以颠覆性的商业模式重塑了整个音乐产业的格局。」

同样的主题，LLM 只能抽出 2 个事实点：「5GB 存储空间」「推出了 iTunes Store」。

其余全部是评价和修饰——「里程碑事件」「彻底改变」「极具前瞻性」「全新时代」「颠覆性的商业模式」「重塑了格局」。模型 B 的字数和模型 A 接近，但信息量不到模型 A 的三分之一。

Research Bench 覆盖了 9 个主流厂商模型，36 个 Research 题目。题目涉及技术调研、行业分析、公司调研等多种深度研究场景。

「信息量」的评测方法采用 Agent as a Judge，由 LLM 逐篇阅读、逐条抽取事实点，并计算同一篇报告下不同模型的信息点数目，横向归一化后将最终分数映射到 10 分制。

在我们的 eval 结果里，GPT 的旗舰模型在「信息量」这个指标上落后于 Claude 系列模型。

与此同时，GPT 在我们另一个指标「文章详实度」上得分却更高，即文章写得非常充实，这意味着 在我们的测试里，GPT 模型比 Claude 模型的信息密度更低。

为了搞清楚 GPT 模型在该测试下信息量这一指标更低的问题，我们统计了信息搜集环节的工具调用分布，发现 GPT 的 Search 工具调用平均次数甚至高于 Claude 模型。

如果信息量低不是因为信息接触得少，那也许就是发生了某种信息的丢失。

顺着这个思路，我发现 GPT 和 Claude 在写中间过程研究笔记的行为上显著不同。

Claude 会对每个信息源直接把关键事实、数据全部以 bullet points 记录下来；

GPT 则倾向于对每个信息源做一两百字的完整总结。在这个环节，GPT 就产生了更大的信息损失，从而影响了最终报告的信息量。

定位到这一问题后，我们通过 Prompt 规范了 GPT 写笔记的方式，有效提升了 GPT 最终撰写报告的信息量。

02

隐喻率

一篇Research的评判，大家最关心的部分可能是这个文字写得到底好不好读？

这也是让我们长期头疼的问题，即我们能不能量化文风？

我们可以粗暴地让 LLM 直接为若干个报告的易读性排序或打分。但这不是我们喜欢的指标，它不够可靠和稳定，得到的分数也没有足够的解释性，没办法帮助我们解决实际的产品问题。

直到 Fable 出现了。我们发现它总会用「胖」、「瘦」来描述文件大小，用臂、腿来描述「组别」的概念，用「一等公民」来描述一组元素里最脱颖而出的那个。

这些启发了我们构建一个从侧面衡量模型文风的指标——「隐喻率」。隐喻是常见的语言学现象，简单理解就是在句子中「悄悄」使用比喻。

来感受一个隐喻率很高的句子：

「全栈 AI 帝国率领评估军团与标注大军，向全球 Tier 1 俱乐部发起冲锋，踏上下一阶段的马拉松。」

句子里的「率领」「发起冲锋」「踏上」都是明显的动作隐喻；「AI 帝国」「评估军团」「标注大军」「全球 Tier 1 俱乐部」共同构成了竞争与征战的意象。

但这句话完全可以写成：「全栈 AI 体系由评估团队和大规模标注团队组成，目标是冲击第一梯队，并参与下一阶段的长期竞争。」

隐喻让这句话变得更加抽象和复杂，你的大脑需要处理一下才能让句子返璞归真，这就降低了报告的易读性。

隐喻的存在本身是希望通过把陌生、抽象的概念类比成更熟悉的概念，从而帮助理解。但 LLM 高密度、不适宜的隐喻使用，很可能把抽象的概念表达得……更抽象。

而且，从数学上讲，隐喻更本质的影响是：它作为一个把 x 词映射成 y 词的「语言函数」（y=f(x)），势必会带来信息的损失，因为 y 的信息量一定小于等于 x。

综上，我们构建了隐喻率指标：每一百句话中出现多少次隐喻表达。通过隐喻率，我们可以从一个视角反映模型的写作特征——更高的隐喻率往往意味着报告更难读，且会带来信息的损失。

实操上，同样采用 Agent as a Judge，测试来自 9 个主流模型、各自 36 篇不同主题的中英文研究报告。在一个 session 内同时处理同一主题下多个模型的报告，保证彼此相对可比。

Prompt 的核心约束是：排除已经完全融入日常使用的无感隐喻（如「字段」「运行」「面对挑战」这类已完全融入日常用语的词）和术语性比喻（如「神经网络」），并要求每个标注同时输出字面替换。

如果一个「隐喻」找不到更直白的说法，它大概率不是隐喻，以此反向校验标注质量。

句子切分上，中文按句号、问号、感叹号切分，英文使用标准 sentence tokenizer，Markdown 标题行、表格行、纯链接行不计入句子总数。

我们举一道题目为例：回顾索尼和任天堂过去二十年间的游戏主机技术进步，分析硬件性能如何影响游戏开发和消费者体验？

在这道题的测试结果中，Fable 5的隐喻率为 9.63，在187 句中有 18 处有隐喻，比如：玩家如考古学家般拼凑真相、开放结构是难度调节器、哥特与宇宙恐怖无缝缝合等等

GPT 5.6 luna的隐喻率只有1.44，139 句中只有 2 处隐喻，比如：将前作的区域式结构推进为彼此咬合、捷径回环的巨大连续世界。

再来看最终结果：

结论发现，在本轮题集和测评配置下， GPT 5.6 系列模型在隐喻使用上更克制。

Claude Fable-5的隐喻率最高。Fable 偏好身体和有机体相关的表达——「橡胶的血统」「侵蚀社区灵魂」「金字塔整体抬升」「搅动价值体系」。

Opus-5 的隐喻率明显低于 Fable，且用法更学术风一些，比如「把安全外包给材料」「气候的函数」「以数据为语言」。

Gemini-3.7-flash 的样本更偏向使用宏大词汇——「黄金十年」「双引擎驱动」「血液」「版图」「浪潮」「基因」，集中出现在章节的开头和结尾，这些表达在财经媒体中也很常见。

Grok-4.6 则会有不少商业和竞争分析的常用隐喻：「军备竞赛」「皇冠上的明珠」「护城河」「棋局」「催化剂」。

当然，隐喻率只是衡量报告可读性众多视角中的一个，而且隐喻率低也并不绝对意味着文章更易读。

但如果能围绕一篇报告构建出许多像隐喻率这样简洁、可操作的 Signal，这将有助于我们理解模型特征。

回到衡量一份报告的两个维度：1）报告包含哪些信息？ 2）这些信息是如何组织在一起的？

这两个维度依然有着众多可挖掘的 Signal，比如参考文献质量、信息的准确度、文章的详实程度、观点的嵌套程度、长短句的节奏等等。

即使是信息量这一个指标，仍有不少的未竟的话题，比如怎么防止一个模型提升信息量的同时也提升了废话的数量等等。

如何把主观感受通过一个简洁优雅的切口量化出来，是最需花心思的部分，指标的有效性也需要长期的线上数据跟踪来验证，最终筛选出经得住考验的 Signal，并真正能指导产品的迭代。

Evalution 是个复杂的工程，除了 Signal 建立之外，如何建设你的产品独属的评测集、如何设计好线上实验、如何搭建有效而稳健的自动化评测系统，都是非常有意思的话题。

今天的分享可能不涉及关于 Evaluation 的宏观 Insights，而是通过我们在践行的、可能有些枯燥的 Action，来分享一些我们的经验。如果能推动更多相关的 Action，我就非常开心了。

（本文封面由ChatGPT 生成，纯人工写作）