Grok模型匿名对比：同一文档字段提取完整性评测

先说说背景

说起来，从第三方API文档里提取字段信息，这事儿不少开发者都干过。通常需要把接口地址、参数名、返回字段和约束条件整理成表格，方便开发和联调时查阅。

事情本身不算复杂，但手工整理时，遗漏信息是常有的事。某个参数可能只在示例代码里露过一次脸，参数表里压根没它；某项说明可能藏在注意事项里，被直接跳过；还有一些约束，就散落在接口介绍的段落中，不逐句检查真的很难发现。

如果这些遗漏直到联调阶段才被发现，那就要重新查阅文档、修改代码，处理成本跟着就上去了。

只用一个模型提取时，很难直接判断它到底漏了什么，除非再人工核对一遍。另一种思路是：用同一模型系列的两个版本分别提取，然后把结果放一起比较。两边都提取到的内容可以相互印证，只有一边提到的内容则需要返回原文确认。

这个过程不预设哪个版本更可靠，只比较两份结果在哪些地方一致、哪些地方存在差异。

下面以Grok系列的两个版本为例，演示一次完整的匿名提取和对照过程。

输入材料：一份混合格式的支付接口文档

以下是一份模拟的支付接口文档片段，内容已经过脱敏处理：

## 创建支付订单接口

### 接口说明
向支付网关提交订单信息，获取支付链接。支持微信支付和支付宝。
接口采用HMAC-SHA256签名认证，签名计算方式见附录A。

### 请求方式
POST /v3/pay/order/create

### 请求头
| 参数名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| Authorization | string | 是 | HMAC-SHA256签名 |
| Content-Type | string | 是 | application/json |

### 请求参数
| 参数名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| order_no | string | 是 | 商户订单号，最大32字符 |
| amount | integer | 是 | 支付金额，单位：分 |
| channel | string | 是 | 支付渠道：wechat / alipay |
| notify_url | string | 是 | 回调地址，必须HTTPS |
| description | string | 否 | 商品描述，最大128字符 |

### 请求示例
{
  "order_no": "ORD20260723001",
  "amount": 9900,
  "channel": "wechat",
  "notify_url": "https://example.com/callback",
  "description": "VIP会员月卡"
}

### 注意事项
- 同一订单号不可重复提交，返回code:10001
- 签名时间戳与服务器时间差超过300秒时请求被拒绝
- 回调地址需在商户后台配置白名单

这份文档的信息分散在接口说明、参数表格、JSON 示例和注意事项中。结构化程度越低，提取时越容易遗漏。

例如，“回调地址需在商户后台配置白名单”只出现在注意事项里。请求参数表虽然列出了 notify_url，却没有提到白名单要求。如果模型只处理表格内容，就可能漏掉这项约束。

操作流程：独立提取，再匿名对照

这次选择Grok系列的两个较新版本进行独立提取。

Grok 4.5于2026年7月发布，采用1.5T参数MoE架构，推理速度为80 tokens/秒，是Grok系列当前性能领先的版本。

Grok 4.3于2026年5月发布，采用推理优先架构，拥有100万token的上下文窗口，在τ-Bench基准上的得分达到98%。

两个版本接收完全相同的文档和Prompt，并各自完成字段提取。首轮结果生成后，先将两份输出分别记为“版本A”和“版本B”，不立即公开对应的模型。

这样可以减少模型名称带来的预期偏差。如果一开始就知道哪份结果来自旗舰版本，评价时可能会不自觉地采用不同标准。匿名阶段只检查字段是否齐全、约束是否准确、信息组织是否清楚。

使用的提取Prompt如下：

请从以下API文档中提取所有字段信息，整理为结构化表格。

表格列：
字段名称 | 类型 | 必填 | 位置 | 约束与说明 | 信息来源

要求：
1. 逐字段提取，包括请求头、请求参数和注意事项中提到的所有字段与约束；
2. 保留原文中的数字、限制值和枚举值，不改动；
3. 不自行补充文档中未提及的默认值或规则；
4. 文档内容如下：

[此处粘贴API文档]

分别调用两个版本，并使用相同的文档和Prompt。提取完成后，先按照统一标准并排比较结果。

第一轮对照：核心字段是否齐全

从字段覆盖情况看，两份结果基本一致。

两个版本都提取了请求头中的Authorization和Content-Type，也完整覆盖了请求参数中的五个字段：

• order_no
• amount
• channel
• notify_url
• description

JSON示例中没有出现参数表以外的新字段，因此两份结果都没有额外补充字段。

注意事项中的三项约束也都被识别出来：

• 同一订单号不可重复提交，重复提交返回code:10001；
• 签名时间戳与服务器时间相差超过300秒时，请求会被拒绝；
• 回调地址需要在商户后台配置白名单。

如果只看“有没有提取到这些内容”，两个版本都完成了任务。真正的差异主要出现在约束与字段的关联方式上。

第二轮对照：约束是否关联到具体字段

第一个差异来自回调地址白名单。

版本A把“回调地址需在商户后台配置白名单”直接补充到了notify_url的“约束与说明”中。这样整理后，开发者查看notify_url这一行，就能同时看到两个要求：

• 必须使用HTTPS；
• 必须在商户后台配置白名单。

版本B也提取了白名单要求，但把它放在表格末尾的“其他约束”中，没有明确标注它与notify_url的关系。

两份结果都没有漏掉原始信息，但可读性不同。版本A已经完成了字段与约束的关联；版本B则保留了按文档位置分类的组织方式，需要读者自行判断这项约束对应哪个参数。

第二个差异出现在接口说明段落。

原文提到接口采用HMAC-SHA256签名认证，并说明“签名计算方式见附录A”。版本A将这项信息合并到了Authorization字段中，版本B则只保留了参数表中的“HMAC-SHA256签名”，没有加入附录引用。

这里同样不是字段缺失，而是两个版本对非结构化段落的处理方式不同。版本A会尝试把段落中的补充信息关联到具体字段，版本B更接近原文现有的结构。

对照结果与模型身份揭示

完成匿名对照后，再公开两个版本对应的模型：

• 版本A：Grok 4.5
• 版本B：Grok 4.3

综合两份输出，可以整理出下面这张字段对照表：

字段名称	类型	必填	位置	约束与说明	版本A（Grok 4.5）	版本B（Grok 4.3）
Authorization	string	是	请求头	HMAC-SHA256签名，计算方式见附录A	已提取，包含附录引用	已提取
Content-Type	string	是	请求头	application/json	已提取	已提取
order_no	string	是	请求参数	商户订单号，最大32字符	已提取	已提取
amount	integer	是	请求参数	支付金额，单位为分	已提取	已提取
channel	string	是	请求参数	wechat / alipay	已提取	已提取
notify_url	string	是	请求参数	必须使用HTTPS；需在商户后台配置白名单	已提取，包含白名单约束	已提取，白名单约束位于表格末尾
description	string	否	请求参数	商品描述，最大128字符	已提取	已提取
重复提交约束	—	—	注意事项	不可重复提交，返回code:10001	已提取	已提取
时间戳约束	—	—	注意事项	与服务器时间相差超过300秒时拒绝请求	已提取	已提取

揭示模型身份后可以看到，Grok 4.5在字段与约束的关联上处理得更细。它把“回调地址白名单”直接关联到notify_url，也把“计算方式见附录A”补充到了Authorization字段中。

Grok 4.3同样提取了文档中的主要字段和约束，但更倾向于按照原文的信息位置组织结果。请求参数仍归请求参数，注意事项则集中放在表格末尾。

从对比结果中可以看到什么

这次匿名对照并不是为了简单得出“哪个模型更好”的结论，而是观察同一系列的不同版本处理同一任务时，结果会在哪些地方出现差异。

从核心字段覆盖来看，两个版本的表现高度一致。请求头、请求参数、JSON示例，以及注意事项中的数字和枚举值，都得到了准确提取。

如果任务目标只是确认参数有没有漏掉，那么两个版本都能满足基本需求。

差异主要体现在信息组织方式上。Grok 4.5更倾向于把段落和注意事项中的补充说明关联到具体字段，Grok 4.3则更倾向于保留原始文档的分类方式。

哪种方式更合适，要看提取结果接下来如何使用。

如果字段表是直接交给开发人员查阅，把约束关联到具体字段会更直观。查看notify_url时，就能同时看到HTTPS和白名单要求，不需要再到其他位置寻找补充说明。

如果字段表主要用于文档审校，按信息来源分类可能更方便。维护者可以快速确认某条信息来自参数表、接口说明还是注意事项。

这次对比中，两个版本使用了完全相同的文档和Prompt。切换模型时不需要重新粘贴材料，两份输出也可以保留在同一个工作区中，便于逐项比较。

验收标准

字段提取完成后，可以用下面这个清单来验收结果：

验收项	通过标准
表格字段齐全	请求头和请求参数表中的所有字段均已提取
示例字段覆盖	JSON示例中的字段均能在提取结果中找到
注意事项纳入	注意事项中的约束条件均已进入提取结果
字段关系明确	与具体参数相关的约束已关联到对应字段
数字保持不变	32字符、300秒、128字符等限制值与原文一致
枚举值保持不变	wechat、alipay等枚举值未被翻译或改写
没有自创信息	不包含原文未提及的默认值、规则或状态

其中，“字段关系明确”值得单独检查。模型即使提取了全部句子，也不代表最终表格已经足够实用。对于开发人员来说，约束是否放在对应字段旁边，往往比单纯做到“不遗漏”更重要。

注意事项

本次使用的是模拟API文档，不包含真实的内部信息。

实际提取内部接口文档时，应在提交给任何第三方平台之前完成脱敏。需要处理的内容不仅包括密钥、Token和内部域名，还包括示例请求中的订单号、客户标识、回调地址，以及可能暴露内部系统结构的接口路径。

这次对比中，Grok 4.5和Grok 4.3的差异主要体现在信息组织方式上，不能据此直接判断两个版本在所有任务中的能力高低。面对其他类型的文档、语言或输出格式，结果可能会不同。

匿名对照也不能替代人工验收。两份结果如果同时漏掉同一项内容，相互比较时仍然无法发现。因此，对关键接口至少还需要按照验收清单回查一次原文。

后续可以尝试的方向

如果日常工作中经常需要从第三方文档提取字段，可以继续使用这种同系列对照方式。

先用一个版本完成首轮提取，再让另一个版本独立处理同一份材料。比较时重点查看“约束与说明”列，检查两份结果是否提取了相同的数字、限制条件和字段关系。

出现差异时，不要直接采用内容更多的那份结果，而应回到原文确认。额外内容可能是第一份结果遗漏的信息，也可能是第二份结果自行补充的推断。

经过几次对比后，就能逐渐判断哪个版本的组织方式更符合自己的使用习惯。后续还可以把常见要求写进固定Prompt，例如：

• 将注意事项中的限制关联到具体字段；
• 单独标记只在示例中间出现的字段；
• 保留附录和章节引用；
• 区分字段约束、接口级约束和业务规则；
• 对无法确定关联对象的约束单独标记，不自行归类。

这样可以把对比中发现的问题转化为下一次提取时的明确规则，让输出结果更接近实际开发需要。