OpenAI GPT-6.1 Terra 发布后怎样评估视觉推理场景

GPT-6.1 Terra 发布后，评估视觉推理不能只看发布页上的单项分数。更稳妥的做法是拿一组已经知道答案的业务图片，固定提示词、输入格式和 reasoning.effort，让旧模型与 Terra 做同条件回放，再按准确率、延迟、token 成本和人工复核量决定是否灰度。

官方地址：https://developers.openai.com/api/docs/models/gpt-6.1-terra

先把发布信息转换成可验证假设

OpenAI 对 GPT-6.1 Terra 的定位很明确：匹配商品照片与目录、解释技术图纸、操作应用界面，以及起草和修改文本。模型页还列出 none 到 max 的 reasoning effort，工具调用需要使用 Responses API。这个信息适合形成测试假设，却不能直接替代业务验收。

例如，商品图匹配可以验收“类别和规格字段是否同时正确”；技术图纸可以验收“关键尺寸、标注关系和缺失信息是否被完整指出”；屏幕任务则要增加“是否只改了目标字段、是否保留了其他数据”的检查。把任务拆成这些可判定结果，后面才有可比性。

建立同输入同 effort 的视觉评测集

先从真实流程抽取少量但有代表性的样本，覆盖清晰图、遮挡图、低光图、相似物料和需要拒答的边界图。每张图片保存脱敏后的输入、期望字段、允许的等价表达和不可接受的错误。测试集不宜只挑容易展示的样本，否则结果会偏乐观。

比较 GPT-5.6 Terra 与 GPT-6.1 Terra 时，保持图片、提示词、输出 schema 和 reasoning effort 不变。可以先从 medium 开始，只有质量提升值得额外时间和 token 时才提高 effort。下面的示例用 Python 记录一个最小的评测行；其中的 API 调用位置应替换成团队现有的 Responses API 封装。

def record_eval(case_id, model, effort, result, expected, latency_ms, cost_usd):
    # 同一 case_id 只更换模型，便于做配对比较。
    exact = result.get("label") == expected.get("label")
    return {
        "case_id": case_id,
        "model": model,
        "reasoning_effort": effort,
        "exact_match": exact,
        "needs_review": result.get("needs_review", True),
        "latency_ms": latency_ms,
        "cost_usd": cost_usd,
    }

# 生产环境还要把原图哈希、提示词版本和人工复核结论写入评测表。
row = record_eval("drawing-017", "gpt-6.1-terra", "medium", output, answer, 820, 0.004)

用准确率、拒答和成本三条线判定结果

建议至少记录下面四组字段。准确率回答“看懂了吗”，拒答和接管回答“遇到不确定时是否暴露风险”，延迟与成本回答“能否承受规模化运行”。不要把平均分掩盖长尾错误：一张关键尺寸读错的图，可能比十张普通图片识别正确更重要。

发布页给出的基准只能说明模型在特定评测环境中的相对表现。安全卡也提醒，研究环境或 API 评测与生产 ChatGPT 可能因系统提示、工具和 effort 不同而产生差异。因此，最终门槛应写成团队自己的规则，例如“关键字段全对且低置信度样本必须进入人工队列”，而不是照搬一个公开百分比。

把复杂场景与屏幕操作分开做灰度

离线回放通过后，再做小流量灰度。商品匹配和图纸解释通常可以先以只读结果进入人工复核；应用屏幕操作则要额外记录保存前后的页面状态、模型声称完成的动作和实际变更。验证结果时，重新打开受影响记录，确认无关字段没有被修改。

当错误来自图片质量、提示词或字段 schema，先修输入并回放；当错误来自模型能力边界，保留人工接管或升级到 GPT-6.1 Sol、GPT-6 Astra。Terra 的优势是速度、视觉推理和成本平衡，复杂且开放的项目不应只因为名称更新就整体迁移。

延伸问答

只测 MMMU-Pro 之类公开基准够吗？

不够。公开基准适合了解方向，业务上线仍要用自己的图片、字段和错误代价做配对回放。

reasoning effort 越高越好吗？

不一定。把质量提升与额外延迟、token 成本放在同一张表里，选择刚好超过业务门槛的档位。

什么时候不适合直接切换 Terra？

当任务开放性很高、错误代价大，或需要长链路协调时，应先保留更强模型作为兜底，并用灰度结果决定分工。