很多 OpenAI API 项目上线前，只做了几次演示：问几个问题，回答看起来不错，就准备接真实用户。这个做法很危险。AI 功能的问题通常不是“完全不能用”，而是边界问题、极端输入、格式不稳定、成本超预期和少量高风险错误。
上线前评估的目标，不是证明模型很聪明，而是回答一个更实际的问题：这个功能在真实场景里，能不能稳定、可控、可追踪地工作。本文按小团队可执行的方式，整理 OpenAI API 上线前的评估清单。你可以和 OpenAI专题、AI智能体与自动化专题 一起看。
先明确：评估对象不是模型，而是整个功能
很多人会问“哪个模型准确率更高”。这当然重要，但上线前更应该评估整个功能链路：
- 用户输入是否被正确清洗和分类；
- 系统提示词是否覆盖业务规则；
- 检索、工具调用、结构化输出是否稳定；
- 模型回答是否符合事实、格式、语气和安全边界；
- 失败时是否有兜底，而不是继续编答案；
- 日志是否能追踪问题来自哪里。
OpenAI 官方评估文档也强调，evals 的价值在于测试输出是否符合指定标准。需要注意的是，OpenAI Evals 平台已经进入弃用过渡期，官方文档显示现有内容会在 2026 年 10 月 31 日变为只读，并计划在 2026 年 11 月 30 日关闭。因此，今天做评估时，更应该把“测试集、评分规则、日志和人工复核”沉淀在自己的工程流程里，而不是只依赖某一个托管界面。
第一步：准备一份真实测试集
测试集不要只写理想问题。真正有价值的测试集，应该来自真实业务和历史问题。可以先准备 50 到 100 条，分成五类：
- 正常问题：用户最常问、最希望 AI 回答的问题。
- 边界问题：信息缺失、表达含糊、条件冲突的问题。
- 风险问题：涉及价格承诺、合同、退款、隐私、权限的问题。
- 格式问题：要求 JSON、表格、固定字段、短回复的问题。
- 拒答问题：不应该回答、需要转人工或需要补充信息的问题。
如果你正在做结构化输出，可以参考 OpenAI API 结构化输出教程。评估时不要只看答案“像不像”，还要检查字段是否齐全、类型是否正确、空值是否可处理。
第二步：给每条样本写清评分标准
评估最容易失败的地方，是没有标准。比如“回答得好不好”太主观，不适合做上线门槛。建议把评分拆成几个明确维度：
- 正确性：结论是否符合资料、规则和业务事实。
- 完整性：是否覆盖用户真正关心的关键信息。
- 格式稳定性：是否按约定输出 JSON、表格或字段。
- 安全边界：是否拒绝越权、隐私、危险或不确定请求。
- 可执行性：是否给出用户下一步能做的动作。
- 成本延迟：是否在可接受的 token、耗时和重试范围内。
每个维度可以先用 0、1、2 分，没必要一开始就做复杂模型评审。小团队最重要的是让同一批样本在多次提示词、模型或知识库变更后可以对比。
第三步：把日志字段先设计好
没有日志，评估很快会变成凭感觉。至少记录这些字段：
- trace_id、用户场景、样本类型；
- 模型、提示词版本、知识库版本；
- 输入长度、输出长度、token 消耗、耗时；
- 是否调用工具、工具返回是否成功；
- 是否命中兜底、是否转人工；
- 评分结果、失败原因、修复建议。
日志字段越早统一，后面越容易做版本对比。站内的 OpenAI API 成本控制 讲过限额、日志和降级策略；评估阶段也要把这些因素放进来，否则上线后才发现账单和延迟不可控。
第四步：人工抽检不要省
AI 评分可以提高效率，但上线前不能完全交给 AI 自己判断。尤其是客服、销售、内容发布、合同摘要、内部知识库问答这类场景，至少要做一轮人工抽检。
人工抽检重点看三件事：
- 有没有自信地说错：表述很流畅，但事实或规则错了。
- 有没有越过边界：承诺价格、替用户做决定、泄露不该输出的信息。
- 有没有可解释记录：出错后能不能追到输入、提示词、模型、检索结果和工具返回。
如果你的项目带工具调用或批量任务，也可以配合 OpenAI Batch API 实战清单 和 OpenAI Responses API 入门 一起设计评估入口。
第五步：设置发布门槛，而不是只看平均分
平均分很容易掩盖风险。一个客服机器人 95% 问题答得不错，但 5% 涉及退款、隐私或价格承诺的问题出错，仍然不适合直接上线。建议设置硬门槛：
- 风险样本不能出现越权回答；
- 结构化输出解析失败率必须低于预设阈值；
- 关键场景必须能触发转人工；
- 平均耗时和 P95 耗时不能超过用户可接受范围；
- 单次调用成本和失败重试成本要在预算内；
- 上线后必须有监控和回滚方案。
这类门槛不一定复杂，但必须写下来。否则每次模型、提示词或知识库变更，团队都会重新争论“这样算不算可以上线”。
一个最小可用评估表
如果暂时没有评估平台，可以先用表格做起来。每一行是一条测试样本，字段可以这样设计：
- sample_id：样本编号；
- scenario：业务场景；
- input：用户输入；
- expected_behavior：期望行为；
- risk_level：低、中、高；
- prompt_version：提示词版本；
- model：模型；
- output：模型输出；
- score_correctness：正确性评分；
- score_format：格式评分；
- fail_reason：失败原因；
- next_action：修复动作。
等样本和规则稳定后，再考虑接入自动化脚本、CI 或内部评估服务。评估不是为了做漂亮报表，而是为了让每次变更都有证据。
老达点评
OpenAI API 的上线评估，本质上是一套质量管理流程。模型能力越强，越不能只凭几次演示判断是否可靠。真正影响交付的，往往是边界样本、失败兜底、日志追踪、人工复核和成本延迟。
对小团队来说，不必一开始就搭复杂评估系统。先把真实样本、评分标准、日志字段和发布门槛固定下来，就已经比“看起来能用”靠谱很多。等业务跑起来，再逐步把评估自动化。
