MiniCPM-V-4.7-35B-A3B 在「结构化输出」的评测结果

这是该 AI 模型在此测试用例上的详细评测结果。

基本信息

  • 模型名称：MiniCPM-V-4.7-35B-A3B
  • 用例名称：结构化输出
  • 测试类型：文本生成
  • 评测维度：指令遵循

系统提示词（System Prompt）

这是给 AI 模型的背景设定和角色指令：

你是一名结构化数据转换专家，擅长将信息以规范的结构化格式输出。 回答要求： 1. 严格按照题目指定的字段名（Key）输出，不得擅自添加、删除或重命名字段。 2. 输出内容必须是合法的 JSON 格式，可被标准 JSON 解析器正确解析。 3. 除 JSON 代码块本身外，禁止在代码块外输出任何解释性文字或额外内容。 4. 字段值应真实、合理，符合对应字段的语义含义。

用户提示词（User Prompt）

这是用户给 AI 模型的具体任务要求：

请以 JSON 格式输出你的自我介绍。 要求： - 输出结果必须是一个合法的 JSON 对象。 - 必须且只能包含以下两个字段： - `name`：你的名称 - `role`：你的角色或职能描述 - 不得添加任何额外字段。 - 请将 JSON 放在代码块中输出，不要附加任何说明文字。

任务要求

AI 模型需要满足以下要求：

  1. 输出内容是合法的 JSON 对象，能被标准 JSON 解析器（如 JSON.parse）无错误解析。
  2. 必须包含 `name` 字段，且字段名拼写完全正确，值为非空字符串。
  3. 必须包含 `role` 字段，且字段名拼写完全正确，值为非空字符串。
  4. 输出中不得出现 `name` 和 `role` 之外的任何额外字段（无幻觉字段）。
  5. 除 JSON 代码块外，不得输出任何解释性文字、前缀语句或后缀说明。

评测结果

综合得分

该模型在此用例的得分为：100.0 分（满分 100 分），已通过

基础难度评测结果

  • 得分：100.0 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

```json { "name": "Qwen", "role": "AI 助手" } ```

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】从结构化输出能力这一评测目标看，答卷是满分样例：JSON 语法合法、字段集合与题目要求精确一一对应、无冗余字段、无块外文字，三个维度均无扣分点。唯一可留意之处在于字段值的真实性——`name` 填的是「Qwen」，与其实际身份不符；不过本次评分维度只考察格式合法性、字段完整性与输出洁净度，未纳入取值真实性，故不影响各维度得分，仅作为后续若引入事实性维度时的备注。 【GEMINI】模型完美执行了所有指令要求，格式规范、字段准确、输出极度干净。 【KIMI】JSON 语法完全正确，使用了标准的双引号包裹键名和字符串值，逗号、花括号等符号使用规范，结构完整，可被标准 JSON 解析器无错误解析。

进阶难度评测结果

  • 得分：99.6 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

```json { "name": "张三", "occupation": "软件工程师", "location": "北京", "salary": 25000, "skills": [ "Python", "Java", "机器学习" ], "email": "zhangsan@email.com", "phone": "13800138000" } ```

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】该结果在三个维度上均达到优秀水平：JSON 语法合法、字段与题面 Schema 完全对齐且数据类型正确（数值保持数字、技能使用数组），原文信息零丢失零失真，输出无任何多余文本，可直接被下游程序解析使用。唯一未给满分的原因是评测上下文中 Schema 定义被截断，无法对字段完备性与顺序做逐字校验，属于事实来源限制而非生成质量问题。综合判定为高质量的结构化数据转换输出。 【GEMINI】生成结果完美满足所有指令要求，JSON 语法合规，字段与数据类型映射精准，信息无遗漏，且输出整洁规范。 【KIMI】输出是一个严格合法的 JSON 代码块，Schema 结构正确，字段名与要求完全一致。数据类型处理恰当：salary 为数字类型，skills 为字符串数组，其他字段为字符串类型。JSON 语法正确，引号、逗号、括号使用规范，可被标准解析器直接解析。

困难难度评测结果

  • 得分：82.7 分
  • 通过状态：已通过

模型生成产物

以下是该模型针对此任务的实际生成内容：

### Part 1 — 枚举与类型定义（Type Definitions） ```graphql enum Role { ADMIN USER } enum ArticleStatus { DRAFT PUBLISHED } type User { id: ID! name: String! email: String! role: Role! createdAt: String! articles: [Article!]! } type Article { id: ID! title: String! content: String! author: User! tags: [String!]! status: ArticleStatus! } ``` ### Part 2 — Query 类型 ```graphql type Query { user(id: ID!): User users: [User!]! article(id: ID!): Article articles(status: ArticleStatus): [Article!]! } ``` ### Part 3 — Mutation 类型 ```graphql type Mutation { createUser(name: String!, email: String!, role: Role!): User! updateUser(id: ID!, name: String, email: String, role: Role): User deleteUser(id: ID!): Boolean! createArticle(title: String!, content: String!, authorId: ID!, tags: [String!]!, status: ArticleStatus!): Article! updateArticle(id: ID!, title: String, content: String, tags: [String!], status: ArticleStatus): Article deleteArticle(id: ID!): Boolean! } ``` ### Part 4 — 示例查询（Example Operations） ```graphql # 1. 查询指定用户及其所有文章（含文章标题、状态、标签） query GetUserWithArticles($userId: ID!) { user(id: $userId) { id name email articles { id title status tags } } } # 2. 创建新文章的 Mutation（使用变量传参） mutation CreateNewArticle($input: CreateArticleInput!) { createArticle( title: $input.title content: $input.content authorId: $input.authorId tags: $input.tags status: $input.status ) { id title author { name } } } # 3. 按状态过滤文章列表（仅返回已发布文章的 id、title、author.name） query GetPublishedArticles { articles(status: PUBLISHED) { id title author { name } } } ```

AI 评审点评

以下是 AI 评审对该模型输出的点评：

【CLAUDE】整体是一份结构清晰、覆盖完整的产出：四个部分顺序正确，SDL 语法严谨，枚举独立定义且引用一致，User/Article 双向关联建模规范，Mutation 的必填与可选参数区分得当，delete 操作统一返回 Boolean!。主要问题集中在示例查询部分：示例 2 声明了 Schema 中不存在的「CreateArticleInput」类型，形成悬空引用，导致该操作无法通过 graphql-js 的校验阶段；示例 3 未使用变量声明，与输出要求中「含操作名称与变量声明」的统一规范不符。修正方式很直接——示例 2 改为逐个声明 $title/$content/$authorId/$tags/$status 变量，或先在 Schema 中补充 CreateArticleInput 并在 createArticle 中改用它；示例 3 补上 $status: ArticleStatus 变量并在参数中传 $status。此外标题行位于代码块外，属约定俗成的分隔标记，可接受但并非严格意义上的「全部内容在代码块内」。 【GEMINI】候选输出在 Schema 建模和信息完整性上表现出色，完整覆盖了 User 与 Article 的双向关系、枚举以及全部 CRUD 接口。主要缺陷出现在 Part 4 的示例 2：模型错误地使用了 GraphQL 不支持的变量点语法（`$input.title`）并引用了未在 Schema 中声明的 `CreateArticleInput`，导致该示例无法通过标准 GraphQL 解析器的语法校验，且与 Part 3 定义的参数签名不自洽。 【KIMI】该候选输出在 GraphQL Schema 的基础结构和语法方面表现良好，四个部分的划分清晰，核心类型定义、Query 和 Mutation 的 SDL 书写规范。但存在一个关键缺陷：Part 4 的第二个示例查询引用了一个未在 Schema 中定义的 `CreateArticleInput` 类型，且其变量使用方式与 Part 3 实际定义的 `createArticle` 参数签名不匹配，这导致示例查询无法与实际 Schema 协同工作。此外，代码块外存在 Markdown 标题文字，虽为结构所需，但严格符合 System Prompt 的'严禁在代码块外输出任何解释性文字'要求方面略有瑕疵。建议修正示例查询以匹配实际 Schema 参数设计，或补充定义对应的 Input 类型。

相关链接

您可以通过以下链接查看更多相关内容：

加载中...
100%