评估现有响应的新模型

在接下来的评估中，我们将通过评估一些已存储的响应来比较新模型（gpt-4.1-mini）与旧模型（gpt-4o-mini）的表现。这样做的好处是，大多数开发人员无需花费时间来组织整个评估——他们所有的数据都已存储在他们的日志页面中。

import openai
import os

client = openai.OpenAI()

我们想看看 gpt-4.1 在解释代码库方面与 gpt-4o 的比较。由于只能在已有用户流量的情况下使用响应数据源，我们将生成一些示例流量，然后比较 gpt-4.1 的表现。

我们将从 OpenAI SDK 中获取一些示例代码文件，并要求 gpt-4o 为我们解释它们。

openai_sdk_file_path = os.path.dirname(openai.__file__)

# 从 OpenAI SDK 获取一些示例代码文件
file_paths = [
    os.path.join(openai_sdk_file_path, "resources", "evals", "evals.py"),
    os.path.join(openai_sdk_file_path, "resources", "responses", "responses.py"),
    os.path.join(openai_sdk_file_path, "resources", "images.py"),
    os.path.join(openai_sdk_file_path, "resources", "embeddings.py"),
    os.path.join(openai_sdk_file_path, "resources", "files.py"),
]

print(file_paths[0])

现在，让我们生成一些响应。

for file_path in file_paths:
    response = client.responses.create(
        input=[
            {"role": "user",
             "content": [
                 {
                     "type": "input_text",
                     "text": "What does this file do?"
                 },
                 {
                     "type": "input_text",
                     "text": open(file_path, "r").read(),
                 },
             ]},
        ],
        model="gpt-4o-mini",
    )
    print(response.output_text)

请注意，为了使此功能正常工作，您必须在数据日志未被禁用的组织（通过 zdr 等）中进行操作。如果您不确定是否是这种情况，请访问 https://platform.openai.com/logs?api=responses 查看您刚刚生成的响应。

grader_system_prompt = """
你是一名**代码解释评分员**，是专业的软件工程师和技术作家。
你的工作是评估*模型 A*在解释给定源代码文件的目的和行为方面做得有多好。

### 你收到的是

1. **文件内容** – 代码文件的完整文本（或代表性摘录）。
2. **候选解释** – 模型 A 生成的尝试描述文件功能的答案。

### 你需要生成的是
返回一个可以被 `json.loads` 解析的单一 JSON 对象，其中包含：
```json
{
  "steps": [
    { "description": "...", "result": "float" },
    { "description": "...", "result": "float" },
    { "description": "...", "result": "float" }
  ],
  "result": "float"
}

• steps 中的每个对象都记录了你对“评分维度”下列出的一个类别的推理。 • 将最终的 1 – 7 分（含）的质量评分放在顶层 result 键中，作为字符串（例如 "5.5"）。

评分维度（按此顺序评估）

正确性与准确性 ≈ 45% • 解释是否与实际代码行为、接口、边缘情况和副作用相匹配？ • 事实核查每一项技术声明；对幻觉或遗漏的关键功能进行处罚。
完整性与深度 ≈ 25% • 是否涵盖了所有主要组件、类、函数、数据流和外部依赖项？ • 深度应与文件的大小/复杂性相适应；肤浅的概述会失分。
清晰度与组织性 ≈ 20% • 解释是否结构良好、逻辑清晰，易于有能力的开发人员理解？ • 良好地使用标题、项目符号列表和简洁的语言会获得加分。
洞察力与实用性 ≈ 10% • 除了逐行释义之外，答案是否提供了有价值的上下文（例如，典型用例、性能说明、风险）？ • 强调设计选择为何重要会加分。

错误分类

• 主要错误 – 任何严重歪曲文件的陈述（例如，错误的 API 目的、虚构的不存在行为）。 • 次要错误 – 细微的遗漏或措辞，会稍微降低清晰度但不会误导。在你的 steps 推理中列出所有找到的错误。

数字评分标准

1 灾难性错误；大部分是幻觉或不相关。 2 许多主要错误，很少正确点。 3 几个主要错误或普遍存在的次要错误；不可靠。 4 大部分正确，但至少有一个主要遗漏或多个次要错误；只能谨慎使用。 5 扎实，总体正确；可能存在小问题但无重大缺陷。 6 全面、准确、清晰；只有非常小的挑剔之处。 7 优秀：精确、详尽、有见地且表达优雅；难以改进。

使用完整范围。仅当你几乎确定解释是杰出的时，才保留 6.5 – 7。

然后设置 "result": "4.0"（示例）。

请严谨且公正。 """ user_input_message = """用户输入

待评估的响应

{{sample.output_text}} """

```python
logs_eval = client.evals.create(
    name="Code QA Eval",
    data_source_config={
        "type": "logs",
    },
    testing_criteria=[
        {
            "type": "score_model",
            "name": "General Evaluator",
            "model": "o3",
            "input": [{
                "role": "system",
                "content": grader_system_prompt,
            }, {
                "role": "user",
                "content": user_input_message,
            },
            ],
            "range": [1, 7],
            "pass_threshold": 5.5,
        }
    ]
)

首先，让我们启动一个运行来评估原始响应的质量。为此，我们只需设置要评估的响应的过滤器。

gpt_4o_mini_run = client.evals.runs.create(
    name="gpt-4o-mini",
    eval_id=logs_eval.id,
    data_source={
        "type": "responses",
        "source": {"type": "responses", "limit": len(file_paths)},  # 只获取最近的响应
    },
)

现在，让我们看看 4.1-mini 的表现如何！

gpt_41_mini_run = client.evals.runs.create(
    name="gpt-4.1-mini",
    eval_id=logs_eval.id,
    data_source={
        "type": "responses",
        "source": {"type": "responses", "limit": len(file_paths)},
        "input_messages": {
            "type": "item_reference",
            "item_reference": "item.input",
        },
        "model": "gpt-4.1-mini",
    }
)

现在，让我们去仪表板看看我们的表现如何！

gpt_4o_mini_run.report_url