MermaidSeqBench 如何评估大语言模型生成 Mermaid 时序图的能力？

MermaidSeqBench 是 IBM Research 提出的自然语言到 Mermaid 时序图评测基准。它不只检查代码能否渲染，还从语法、输出纯净度、逻辑、完整性、激活区间以及错误与状态跟踪六个维度评估模型。基准包含 132 组自然语言描述与参考图，并用两个不同的大模型评审器验证模型之间的相对差异。

为什么需要专门评测 Mermaid 时序图

时序图描述参与者随时间发生的消息交互。大语言模型很容易生成一段看起来像 Mermaid 的文本，但“可以解析”与“正确表达业务流程”不是一回事。模型可能遗漏参与者、颠倒消息顺序、丢失异常分支，或在激活与停用语句上出错。

通用代码评测通常依赖单元测试，而时序图没有天然的可执行断言。只做字符串匹配也不合理，因为同一交互可以有多种等价写法。MermaidSeqBench 因此把参考答案、细粒度评分标准和大模型评审结合起来，用于比较不同模型的结构化图表生成能力。

基准包含哪些数据

数据集共有 132 个样本，每个样本包含结构化自然语言说明和一份可接受的 Mermaid 时序图。自然语言说明统一覆盖三个部分：

• Purpose：流程的目标和使用场景。
• Main Components：参与者及各自职责。
• Interactions：消息顺序、条件分支和状态变化。

这种输入格式减少模糊性，让评测更聚焦于模型能否把明确需求转换成正确图表，而不是猜测缺失的业务信息。

132 个样本是怎样构造出来的

1. 领域专家手工编写并验证 10 个种子时序图。
2. 使用 Mistral-Large-Instruct 基于示例生成更多流程。
3. 从生成池中选出 30 个样本，并通过 Mermaid Live Editor 和专家人工检查。
4. 用确定性规则改变条件分支顺序和参与者命名，扩展到 132 对数据。
5. 为每个图配套编写目的、组件和交互说明。

这是一种“人工核心加合成扩展”的方法。人工种子保证基础质量，模型生成增加场景多样性，规则变换则在保持语义的同时扩大表面形式覆盖。

规则增强改变了什么

第一类规则识别 alt、else 和 end 条件块，并在不改变分支逻辑的前提下调整顺序，包括嵌套条件。第二类规则把参与者标识规范化，并同步替换声明与所有消息引用。

规则增强的价值在于可追踪：如果变换是确定性的，研究者能判断新增样本是否保持原语义。但它不会自动创造全新的业务逻辑，因此不能把 132 个样本简单理解成 132 个完全独立的真实项目。

数据覆盖了哪些 Mermaid 特性

• 118 个样本包含条件分支，占 89.4%。
• 116 个样本包含多分支 else，占 87.9%。
• 44 个样本包含嵌套控制流，占 33.3%。
• 全部 132 个样本都包含激活与停用。
• 全部样本都使用实线消息箭头，126 个样本包含响应箭头。
• 每个图有 4 至 7 个参与者，平均为 5 个。

这些数据有意强调条件分支、激活区间和请求响应，但尚未覆盖并行流、循环和可选块。若项目大量使用 par、loop 或 opt，需要补充自己的测试集。

一次评测如何运行

1. 从数据集读取任务指令、规则、示例和自然语言流程。
2. 候选模型生成 Mermaid 代码。
3. 将候选输出、参考答案和可选的原始提示交给评审模型。
4. 评审模型按六个维度分别给出 0 到 1 的分数和简短理由。
5. 聚合全部样本，比较模型、尺寸和评审器之间的趋势。

论文实验使用贪心解码，温度为 0，每个提示最多生成 1024 个新 token。这些参数应随结果一同保存，否则同一模型的复现实验可能不可比较。

六项指标分别检查什么

Syntax

检查输出是否符合 Mermaid 时序图语法，包括声明、箭头、控制块和激活语句能否正确配对。生产评测中最好再增加真实解析器验证，避免完全依赖评审模型判断语法。

Mermaid Only

检查回答是否只包含要求的 Mermaid 内容。模型若在代码前后添加解释、Markdown 围栏或无关文字，可能导致自动渲染管线失败。

Logic

检查消息方向、先后顺序、条件分支和参与者行为是否符合输入描述。代码可以成功渲染，但逻辑仍可能错误。

Completeness

检查需求中的参与者、交互和分支是否都被表达。遗漏错误响应、确认消息或某个后端组件都会降低完整性。

Activation Handling

检查 activate 与 deactivate 是否落在合理位置、是否成对出现，以及生命线的活跃区间是否符合调用过程。

Error & Status Tracking

检查失败路径、状态返回、确认信息和异常处理是否保留。这类细节对工程文档很重要，也是实验中相对困难的维度。

为什么不能只比较参考答案字符串

Mermaid 图存在多种语义近似的表达方式。参与者可以使用别名，响应箭头和注释可以有不同文本，某些激活写法也能等价表达调用范围。精确字符串匹配会把合理变体判错。

另一方面，单纯检查能否渲染又太宽松。LLM-as-a-Judge 位于两者之间：它能结合需求和参考图判断语义，但也会引入评审器自身的偏差。

论文比较了哪些模型

跨家族实验比较了 Llama、Qwen 和 Granite 的较大与较小指令模型。较大组包括 Llama-3.1-8B-Instruct、Qwen-2.5-7B-Instruct 和 Granite-3.3-8B-Instruct；较小组包括 Llama-3.2-1B-Instruct、Qwen-2.5-1.5B-Instruct 和 Granite-3.3-2B-Instruct。

同家族消融实验进一步测试 Qwen-2.5 的 0.5B、1.5B、3B、7B、14B、32B 和 72B 版本，以减少模型架构差异的干扰。

模型规模带来了什么变化

三个模型家族中，较大模型总体都优于较小模型。Qwen 家族的明显跃升出现在 3B 到 7B 之间，尤其体现在语法、逻辑和完整性上。32B 与 72B 在语法和纯 Mermaid 输出方面接近饱和，但在错误与状态跟踪等语义维度仍有改进空间。

趋势并非每个尺寸都严格单调。例如 DeepSeek-V3 评审下，Qwen-2.5-14B 在若干指标上略低于 7B，随后在 32B 和 72B 恢复。这说明结果同时受候选模型能力、提示和评审校准影响。

两个评审模型为什么分数不同

实验使用 DeepSeek-V3 671B 和 GPT-OSS 120B 作为评审器。DeepSeek-V3 给出的绝对分数通常更高，个别指标与 GPT-OSS 相差可达 24 个百分点。

尽管绝对分数差异明显，两个评审器对高层趋势的判断一致：大模型普遍强于同家族小模型；语法和纯 Mermaid 输出相对容易；激活处理、错误与状态跟踪更难。

应该怎样解读排行榜

MermaidSeqBench 适合回答“哪些模型在这组任务上相对更强”和“差距集中在哪些能力”，不适合宣称某个分数就是图表的客观正确率。

• 优先看同一设置下的相对排名。
• 确认趋势能否跨多个评审器复现。
• 不要比较使用不同提示模板和解码参数的裸分数。
• 对接近的模型进行人工抽查。
• 把真实 Mermaid 解析结果作为独立硬指标。

如何在项目中复现评测

1. 固定 MermaidSeqBench 数据集版本和样本 ID。
2. 记录候选模型名称、精确版本、推理服务和量化方式。
3. 使用统一提示、温度、最大输出长度和停止条件。
4. 保存原始输出，不要在评审前静默修复。
5. 先运行 Mermaid 解析器并记录语法错误。
6. 使用至少两个评审模型分别运行六项评分。
7. 抽样人工复核低分、高分和评审分歧样本。
8. 报告均值之外的分布、失败类型和置信区间。

怎样增加确定性校验

LLM 评审适合判断语义，但能用程序验证的部分应交给程序。可以增加以下检查：

• 用 Mermaid 解析器验证语法并尝试渲染。
• 解析参与者集合，检查需求中的组件是否出现。
• 检查 alt、else、end 块是否闭合。
• 检查激活与停用是否成对且引用有效参与者。
• 提取消息边，比较必需的源、目标和顺序约束。
• 拒绝代码之外的多余说明或围栏。

确定性校验给出清晰失败原因，模型评审补充难以形式化的逻辑和完整性判断，两者组合更适合持续集成。

如何设计团队自己的扩展集

公开基准不能覆盖每个组织的架构约定。团队可保留 MermaidSeqBench 作为通用回归集，再添加领域样本：

• 支付系统的超时、重试、幂等与补偿。
• 身份认证中的令牌刷新和权限失败。
• 消息系统的异步确认和死信处理。
• 微服务调用中的熔断、降级和追踪上下文。
• 包含并行、循环、可选块的复杂流程。

扩展样本应由熟悉业务的专家审核，并保存需求、参考图、允许变体和关键约束。只提供一份参考字符串，会让后续评分过度依赖表面形式。

一个实用的输入模板

目的：用户上传文档并安全保存。
主要组件：用户、移动应用、BFF、身份服务、数据库、对象存储。
交互：
1. 用户通过移动应用上传文档。
2. BFF 校验会话令牌和权限。
3. 令牌无效、权限不足或文件过大时返回错误。
4. 成功时保存元数据，再写入对象存储并返回确认。
要求：仅输出 Mermaid sequenceDiagram 代码，正确使用激活区间。

这个模板把目的、参与者和有序交互分开，也明确限定输出格式。实际评测应避免在提示中泄露参考 Mermaid 代码。

常见失败怎样定位

能够渲染但业务顺序错误

查看 Logic 分数，并把需求拆成必需消息的偏序约束。重点检查认证、写库和返回确认的先后关系。

回答包含解释文字

加强“仅输出 Mermaid”的指令，并在管线中对首行和尾部内容做确定性检查。

激活条不闭合

解析每个参与者的激活栈，发现多余停用或缺失停用时直接报告具体行，而不是只给总分。

两个评审器意见差异很大

保留双方理由，交由人工检查，并把该样本加入分歧集。不要简单平均后掩盖评审不一致。

模型换版本后分数变化

确认模型快照、推理参数、提示、评审器和数据版本是否全部固定。任何一项变化都可能导致结果漂移。

基准有哪些限制

• 数据只有 132 个样本，且来自 10 个专家种子的扩展。
• 专家选择场景可能带来归纳偏好。
• 只评估 Mermaid 时序图，不能直接外推到流程图、类图或 PlantUML。
• 未覆盖并行流、循环和可选块。
• 六项指标不一定囊括所有工程质量要求。
• 缺少大规模人工金标准来校准评审模型。

论文的主张是基准能够区分模型并揭示相对能力趋势，而不是给出绝对图表质量认证。

发布模型前的验收清单

1. 候选模型、提示和解码参数已固定。
2. 全部原始输出可追溯。
3. Mermaid 真实解析和渲染已通过。
4. 六项指标分别报告，没有只给总分。
5. 至少两个评审器的趋势已比较。
6. 高分、低分和分歧样本经过人工抽查。
7. 团队领域样本覆盖关键异常流程。
8. 报告说明数据覆盖和评审偏差。

总结

MermaidSeqBench 把自然语言到 Mermaid 时序图生成拆成六项可诊断能力，并用 132 个样本比较不同模型家族与规模。实验表明，模型变大通常能改善结果，语法和输出格式比激活管理、错误与状态跟踪更容易；不同评审模型的绝对分数可能明显不同，但高层趋势较稳定。实际落地时，应把相对排名、多个评审器、真实 Mermaid 解析、人工抽查和团队领域测试结合起来，而不能把单个 LLM 评审分数当作最终质量证明。