以下为阅读chatgpt的API文档笔记，可以帮助快速了解调用API相关细节。

一.快速开始

简单示例：

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
    model: "gpt-5-nano",
    input: "Write a one-sentence bedtime story about a unicorn."
});

console.log(response.output_text);

二.文本生成

2.1 提示工程

提示工程是为模型编写有效指令的过程，目的是让模型持续生成符合您要求的内容。

有些提示工程技术适用于所有模型，例如使用消息角色。但不同的模型可能需要不同的提示方式才能产生最佳结果。即使是同一系列模型中的不同快照（snapshot），也可能产生不同的结果。因此，随着您构建更复杂的应用程序，我们强烈建议：

• 将您的生产应用程序固定到特定的 模型快照（例如 gpt-5-2025-08-07），以确保行为的一致性。
• 构建评估来衡量提示词的行为，以便您在迭代过程中，或在更改和升级模型版本时监控提示词的性能。

2.2 Message roles and instruction following（消息角色与指令遵循）

您可以使用 instructions API 参数配合消息角色，以不同级别的权威性向模型提供指令。

instructions 参数为模型提供了关于生成响应时应如何表现的高级指令，包括语气、目标和正确响应的示例。通过这种方式提供的任何指令，其优先级都将高于 input 参数中的提示词。

示例：

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
    model: "gpt-5",
    reasoning: { effort: "low" }, //推理配置：{ 力度：‘低’ }
    instructions: "Talk like a pirate.",
    input: "Are semicolons optional in JavaScript?",
});

console.log(response.output_text);

上述示例大致相当于在输入数组中使用以下输入信息：

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
    model: "gpt-5",
    reasoning: { effort: "low" },
    input: [
        {
            role: "developer",
            content: "Talk like a pirate."
        },
        {
            role: "user",
            content: "Are semicolons optional in JavaScript?",
        },
    ],
});

console.log(response.output_text);

角色设置：

• developer 消息提供系统的规则和业务逻辑，就像函数定义。
• user 消息提供输入和配置，developer 消息的指令将应用于这些输入和配置，就像函数的参数。

developer (开发者)	user (用户)	assistant (助手)
developer 消息是由应用程序开发人员提供的指令，其优先级高于用户消息。	user 消息是由最终用户提供的指令，其优先级低于开发者消息。	由模型生成的消息具有 assistant 角色。

2.3 可复用提示词

在 OpenAI 仪表盘中，您可以开发可在 API 请求中使用的可复用提示词，而无需在代码中直接指定提示词的具体内容。通过这种方式，您可以更轻松地构建和评估提示词，并在不更改集成代码的情况下部署提示词的改进版本。

工作原理如下：

1. 在仪表盘 中创建可复用提示词，并使用像 {{customer_name}} 这样的占位符。
2. 在您的 API 请求中使用 prompt 参数来调用该提示词。prompt 参数对象有三个您可以配置的属性：
   • id — 您的提示词的唯一标识符，可在仪表盘中找到。
   • version — 提示词的特定版本（默认为仪表盘中指定的“当前”版本）。
   • variables — 用于替换提示词中变量的值映射。替换值可以是字符串，也可以是其他 Response 输入消息类型，如 input_image 或 input_file。

示例：

import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
    model: "gpt-5",
    prompt: {
        id: "pmpt_abc123",
        version: "2",
        variables: {
            customer_name: "Jane Doe",
            product: "40oz juice box"
        }
    }
});

console.log(response.output_text);

三.结构化模型输出

确保模型的文本响应严格遵循你定义的 JSON Schema。
JSON 是当前全球最广泛使用的数据交换格式之一。

结构化输出是一项功能，它确保模型生成的响应始终符合你提供的 JSON Schema。这样，你无需担心模型漏掉必需字段，或生成无效的枚举值等问题。

四.对话状态

4.1 手动管理对话状态

尽管每次文本生成请求都是独立且无状态的，但你仍然可以通过在请求中提供额外的消息参数，实现多轮对话。下面以一个敲门笑话为例：

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4o-mini",
    input=[
        {"role": "user", "content": "knock knock."},
        {"role": "assistant", "content": "Who's there?"},
        {"role": "user", "content": "Orange."},
    ],
)

print(response.output_text)

通过交替提供 user 和 assistant 消息，你可以在一次模型请求中捕获整个对话的历史状态。

要在多次生成响应之间手动共享上下文，你需要将模型上一次的输出作为输入的一部分，并将其附加到下一次请求中。

4.2 OpenAI 提供的对话状态管理方式

1）使用 Conversations API
[Conversations API] 可与 [Responses API] 配合使用，将对话状态持久化为一个拥有稳定 ID 的长生命周期对象。
创建对话对象后，你可以在多个会话、设备或任务中持续使用它。
对话对象会存储 Items，例如消息、工具调用、工具输出，以及其他数据。

conversation = openai.conversations.create()

在多轮交互中，你可以把 conversation 参数传入后续的 Responses 调用，以持久化状态并共享上下文，而无需将多个 Responses 的输出手动拼接在一起。

response = openai.responses.create(
  model="gpt-4.1",
  input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
  conversation="conv_689667905b048191b4740501625afd940c7533ace33a2dab"
)

2）使用 previous_response_id 传递上下文
另一种管理对话状态的方法是使用 previous_response_id，通过链式传递响应来形成“线程式对话”。

from openai import OpenAI
client = OpenAI()

response = client.responses.create(
    model="gpt-4o-mini",
    input="tell me a joke",
)
print(response.output_text)

second_response = client.responses.create(
    model="gpt-4o-mini",
    previous_response_id=response.id,
    input=[{"role": "user", "content": "explain why this is funny."}],
)
print(second_response.output_text)

五.后台模式

在后台异步运行耗时较长的任务。

像 Codex 和 Deep Research 这样的智能代理表明，推理模型在解决复杂问题时可能需要数分钟。后台模式让你可以在 o3 和 o1-pro 等模型上可靠地执行长耗时任务，而无需担心超时或连接中断问题。

后台模式会以异步方式启动任务，开发者可以轮询响应对象来持续检查状态。要在后台启动一个响应生成，只需在 API 请求中将 background 设置为 true：

由于后台模式会将响应数据保存约 10 分钟以支持轮询，因此它不兼容 Zero Data Retention (ZDR)。对于 ZDR 项目，虽然带 background=true 的请求仍会被接受（出于兼容性考量），但使用后台模式会破坏 ZDR 的数据不保留保证。Modified Abuse Monitoring (MAM) 项目则可以安全使用后台模式。

六. 流式API响应

学习如何使用 Server-Sent Events 从 OpenAI API 流式传输模型响应。

默认情况下，当你向 OpenAI API 发出请求时，服务器会等待模型生成整个输出后，再通过一次 HTTP 响应将其完整返回。当生成的内容很长时，这会导致等待时间较长。

使用流式响应可以让你在模型生成完整回答的过程中，就开始打印或处理它的部分输出。

七.网络钩子

使用 Webhooks 从 OpenAI API 接收实时更新。

OpenAI 的 webhooks 允许你在 API 中发生特定事件时接收实时通知，例如：

• 批处理任务完成
• 后台响应生成完毕
• 微调（fine-tuning）任务结束

Webhook 会按照 Standard Webhooks 规范 向你控制的 HTTP 端点发送事件。
完整 webhook 事件列表见 API 文档。

八.文件输入

支持视觉能力的 OpenAI 模型可以接受 PDF 文件作为输入。你可以通过以下两种方式提供 PDF 文件：

• 将文件内容转换为 Base64 编码后直接传入；
• 或先通过 /v1/files 端点（使用 API 或控制台）上传 PDF，并在请求中引用其 file_id。

为了帮助模型理解 PDF 内容，系统会同时将 提取出的文本 和 每一页的图像 一并放入模型上下文中。模型可利用文本和页面图像共同生成回应。
这在图表中包含关键信息、但文本中未体现时尤其有用。

1. Token 使用量
为帮助模型理解 PDF 内容，我们会在上下文中同时加入：

• 提取出的文本
• 每一页的图像（无论页面是否含图）
  因此在规模化部署前，需要评估 token 使用量和对应费用。

2. 文件大小限制

• 单个上传文件大小必须 小于 50 MB
• 单次 API 请求中多个文件的 总大小不得超过 50 MB

九.提示词

9.1 概述

Prompting（提示） 是向模型提供输入的过程。输出质量往往取决于你编写提示词的水平。

1）API中的提示词
OpenAI 提供了一个长期存在的提示对象（prompt object），具有版本控制和模板化能力，并在同一项目的所有用户之间共享。这样的设计允许你在团队范围内统一管理、测试并复用提示词，并通过单一的定义在 API、SDK 和控制台中使用。

通用的提示词 ID 为你提供了灵活性，使你更容易测试和构建系统。变量和提示共享同一基础模板，因此创建新版本后，你可以用它进行评测，判断新的提示版本表现更好还是更差。

2）提升工具与技巧
提示缓存：将延迟降低至80%，成本降低至75%
提示工程：学习策略、技巧和工具以构建高质量提示词

9.2 创建提示词

登录并使用 OpenAI 的 控制台，以创建、保存、版本化和共享你的提示词。
1）开始创建提示
在 Playground 中填写字段，创建你想要的提示。

2）添加提示变量
变量允许你注入动态值，而无需修改提示本身。可在任意消息角色中使用 {{variable}}。例如，在创建本地天气查询提示时，你可以添加一个名为 city 的变量，其值为 San Francisco。

3）在 Responses API 中使用提示词
在 URL 中找到你的提示 ID 和版本号，并以 prompt_id 的形式传入：

curl -s -X POST "https://api.openai.com/v1/responses" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
    "prompt": {
    "prompt_id": "pmpt_123",
    "variables": {
        "city": "San Francisco"
    }
    }
}'

9.3 提示词缓存

一句话总结：OpenAI 的一项“降本增效”神器。它能让模型“记住”处理过的长文本（如系统指令、文档），下次再用时直接调用记忆，速度提升 80%，成本降低 90%。

🌟 核心优势：自动启用、无需改代码、不收额外费用。

1. 触发条件与原理

只有当提示词满足以下条件时，缓存才会生效：

• 门槛：提示词长度必须 ≥ 1024 tokens。
• 机制：基于前缀匹配。
  • 系统会将相同前缀（通常前 256 tokens）的请求路由到同一台服务器。
  • 缓存命中 (Hit)：服务器发现这个前缀“背过”了 → 跳过处理，直接生成（省钱快跑）。
  • 缓存未命中 (Miss)：服务器没见过 → 完整处理并存入记忆（正常计费）。

2. 两种记忆模式

根据你的需求，可以选择让模型记多久。

特性	内存缓存 (默认)	扩展缓存 (需配置)
英文名	In-memory retention	Extended retention
记忆时长	短时记忆 5-10分钟无访问即清除 (最长1小时)	长时记忆 可长达 24小时 (即使无访问)
适用模型	所有模型	仅限新模型 (如 GPT-5, GPT-4.1)
存储原理	仅存 GPU 内存 (易失)	内存满时存入本地存储 (持久)
适用场景	实时高频请求	间歇性任务、低频但重型的上下文

3. 最佳实践

要想最大化缓存效果，请遵循以下法则：
结构优化：静态在前，动态在后

• 正确写法：[系统指令 + 参考文档] (静态) + [用户提问] (动态)
• 错误写法：[用户提问] + [系统指令]
• 原因：一旦开头变了，整个缓存链就断了。

流量控制

• 请求速率：针对同一长前缀的请求，保持 < 15 次/分钟 的稳定流量最佳。
  • 原因：请求太猛可能会被强制分流到不同机器，导致缓存没法集中利用。

高级技巧

• 使用 prompt_cache_key：
  • 如果你有大量请求共享长前缀，显式提供这个参数可以帮助系统更精准地路由，提高命中率。

9.4 提示工程

1. 核心概念

提示工程是一门通过编写高效指令，引导模型（LLM）生成符合预期结果（如代码、JSON、散文等）的技术。由于模型输出具有非确定性，良好的提示设计能显著提升结果的稳定性。

2. 模型选择策略

根据任务类型选择合适的模型是成功的第一步：

• 推理模型 (Reasoning Models, 如 GPT-5, o3)
  • 特点：生成内部思维链，擅长复杂分析、多步规划。
  • 类比：“资深同事” —— 给个目标，它能自行规划并完成。
  • 代价：速度较慢，成本较高。
• 通用 GPT 模型 (如 GPT-4, GPT-4.1)
  • 特点：速度快，成本低。
  • 类比：“初级同事” —— 需要明确具体的指令才能干好活。
  • 推荐：gpt-4.1 通常是智能、速度与成本的平衡之选。
• 模型尺寸：
  • 大模型：理解力强，适合跨领域难题。
  • 小模型 (mini/nano)：极快、极便宜，适合简单任务。

3. 消息角色与指令体系

OpenAI 引入了层级化的指令结构：

• instructions 参数：设定高层指令（语气、目标），优先级最高。
• 角色体系 (Roles)：
  • Developer (开发者)：定义系统规则和业务逻辑（类似函数定义）。优先级高于 User。
  • User (用户)：提供输入数据或任务配置（类似函数参数）。
  • Assistant (助手)：模型生成的回复。

最佳实践结构：

Developer (你是一个海盗…) + User (JS里分号是必须的吗？)

4. 提示词编写技巧

为了让模型更好地理解逻辑边界和结构：

• 格式化：使用 Markdown 或 XML 标签清晰分块。
• 结构化提示的四个要素：
  1. 身份 (Identity)：你是谁？（如：资深前端工程师）
  2. 指令 (Instructions)：要做什么？有哪些限制？
  3. 示例 (Examples)：即 Few-shot Learning，提供输入/输出样例，让模型模仿模式。
  4. 上下文 (Context)：即 RAG，提供额外的背景资料或专有数据。

5. 工程化管理：可复用提示

为了解耦代码与提示词，便于非技术人员维护：

• 做法：在 OpenAI 控制台创建模板（使用 {{变量名}} 占位）。
• 调用：代码中仅需传入 id、version 和 variables（变量值可为文本或文件）。
• 优势：无需修改代码即可更新提示词版本。

十.推理模型

10.1 基本知识

1. 核心概念

推理模型（如 GPT-5 系列）是新一代经过强化学习训练的语言模型。

• 核心特征：在回答之前会先“思考”。
• 思维链：模型在内部生成一长串逻辑推演（推理 token），用于分解复杂问题、规划步骤、自我纠错，然后再输出最终答案。
• 擅长领域：复杂解题、编程（Codex CLI 最佳选择）、科学推理、多步骤工作流规划。

2. 开发实战：如何控制“思考”

在调用 API 时，通过 reasoning 参数控制模型的思考深度。
参数配置：

// JavaScript 示例片段
const response = await openai.responses.create({
    model: "gpt-5",
    reasoning: { effort: "medium" }, // 核心参数
    input: "..."
});

effort 选项详解：

• low：速度优先，省钱（生成的推理 token 少）。
• medium (默认)：平衡速度与精度。
• high：深度推理优先（生成的推理 token 多，更聪明但更贵/慢）。

3. 运行机制：推理 Token

理解推理 token 是使用该模型的关键。

• 流程：输入 (Input) → 推理 (Reasoning, 不可见) → 输出 (Output, 可见)。
• 可见性：API 返回的最终文本中不包含推理 token（它们被丢弃了），但在处理过程中它们真实存在。
• 计费与限额：
  • 虽然你看不到，但推理 token 需要付费。
  • 推理 token 占用上下文窗口。
  • 推理 token 计入 max_output_tokens 限制。

4. 关键风险与上下文管理

由于推理过程可能产生数万个 token，容易撑爆上下文窗口。

• 常见错误：status: incomplete (原因: max_output_tokens)。
  • 后果：可能钱付了（跑了推理），但没拿到结果（输出被截断）。
• 解决方案：
  • 预留空间：OpenAI 建议至少为推理和输出预留 25,000 token 的空间。
  • 调整参数：适当调大 max_output_tokens。

6. 高级功能

• 推理摘要 (Summary)：
  • 虽然拿不到原始推理内容，但可以要求模型生成摘要。
  • 设置：reasoning: { summary: "auto" }（支持 concise 或 detailed）。
  • 注：使用此功能可能需要组织验证。
• 上下文保持：
  • 在函数调用（Function Calling）等多轮对话中，建议通过 previous_response_id 传递上下文，以便模型“接上”之前的思路。
• 加密推理 (Stateless)：
  • 在零数据保留模式下，使用 include: ["reasoning.encrypted_content"] 在客户端暂存加密的推理信息，以便在下一轮对话中回传。

10.2 最佳实践

1. 选型指南：何时使用推理模型？

如果你的任务符合以下特征，请选择 推理模型 (o系列)：

• 准确性与可靠性 优于速度和成本。
• 任务模糊：信息有限，需要模型理解意图并自动补全逻辑缺口。
• 复杂关系推演：需要在数百页文档（合同、财报）中发现隐蔽的逻辑联系。
• 多步骤规划：需要作为 Agent 的大脑，协调多个工具或子模型。
• 视觉推理 (仅限 o1)：处理结构复杂的图表或低质量图片（GPT-4o 搞不定的图）。
• 代码深层审查：发现人工容易遗漏的微小 Bug。

2. 提示工程最佳实践

推荐做法：

1. 使用 developer 角色：取代传统的 system 角色（从 o1-2024-12-17 版本起）。
2. 简单直接：指令要清晰、简明。
3. 结构化输入：使用 Markdown、XML 标签或章节标题来分隔不同部分。
4. 提供具体约束：明确限制条件（如“预算 < $500”）。
5. 明确成功标准：告诉模型什么样的结果才是完美的。
6. Formatting re-enabled：如果是新版模型，默认可能不输出 Markdown，需在 developer 消息首行显式开启。

避免做法

1. 不要使用思维链提示 (CoT)：不要对模型说“逐步思考” 或“解释你的推理”。
2. 无需少样例 (Few-shot)：通常 Zero-shot (零样例) 效果就很好。除非输出格式极度特殊，否则不需要提供示例。

3. 成本与性能优化

针对 o3 和 o4-mini 等新模型，在 API 使用上有特殊优化技巧。
推荐 API：Responses API (而非 Chat Completions API)
优化策略：

1. 保持状态 (Statefulness)：
   • 设置 store: true。
   • 在多轮对话或函数调用中，通过 previous_response_id 传递上下文。
2. 推理信息的复用：
   • 新模型（o3/o4-mini）能智能利用紧邻函数调用前的推理信息。
   • 关键操作：务必将上一次的推理项（Reasoning items）传回给模型。这能让模型在执行函数后不需要“重新思考”，从而大幅降低 Token 消耗并提升性能。
3. Chat Completions API 的局限：
   • 它是无状态的，推理项会被丢弃。在复杂的多函数调用场景下，性能会下降且成本增加。

十一.评估

11.1 数据集入门

在使用 Evals 或提示优化器前，首先需要准备数据集。

1.数据集的作用

数据集用于：

• 提供输入和期望输出，用于测试模型性能
• 生成评估数据，用于量化模型质量
• 支持提示优化器自动改进提示

2.数据集准备步骤

1. 创建数据集
   • 包含你希望优化的提示（prompt）
   • 包含用于评估的输入/输出数据
   • 可参考 OpenAI 数据集指南
2. 添加至少三条记录
   • 每条记录应包含模型输出示例
   • 对输出进行至少一条人工标注或评分
3. 提供标注或评分信息
   数据集可包含：
   • Annotations（好/坏评价以及自定义标注列）
   • output_feedback（文本批注）
   • 评分器结果（Graders）

提示：效果最佳的数据集包含详细的好/坏评分和具体批注。评分器（Graders）应精确捕捉你希望提示达到的特性。

11.2 使用 Evals

Evals 是 OpenAI 提供的结构化测试工具，用于测量模型性能，适用于非确定性生成模型。

1.Evals 的功能

• 测试模型准确性、性能和可靠性
• 提供可量化的指标
• 可用于改进 LLM 应用性能（通过微调或提示优化）

2.基本工作流

1. 定义评估目标
   明确成功标准，例如准确回答、摘要完整性等
2. 收集评估数据集
   可包含：
   • 合成数据
   • 领域专家数据
   • 历史生产数据
   • 用户反馈
3. 定义评估指标
   可量化的指标，例如 ROUGE、BERTScore、上下文召回率、准确率等
4. 运行并比较评估
   • 使用 Evals API 创建评估
   • 在控制台运行评估，收集结果
5. 持续评估（CE）
   • 每次模型更新都运行评估
   • 监控非确定性输出，持续扩展评估集

11.3 提示优化器

提示优化器用于根据数据集自动改进提示（prompt），提升模型生成效果。

1.使用方法

1. 在控制台选择提示优化器
2. 输入初始提示
3. 系统根据当前最佳实践优化提示
4. 查看和测试优化后的提示
5. 可重复优化流程：生成输出 → 标注 → 评分 → 优化

2.数据要求

提示优化器可使用：

• 数据集中的标注（好/坏及自定义列）
• output_feedback 批注
• 评分器结果

建议：添加详细批注和评分，创建精准评分器以获得最佳优化效果。

11.4 评估最佳实践

1.设计评估

1. 定义目标
   明确成功标准，例如准确回答、摘要质量等
2. 收集数据集
   支持：合成、生产、历史、专家标注数据
3. 定义指标
   数值指标（ROUGE、BERTScore）、人工评估或 LLM 评分器
4. 运行并比较
   使用 Evals API 执行
5. 持续评估
   捕获非确定性情况，扩大评估集

2.常见架构与评估点

架构类型	特点	非确定性来源
单轮交互	用户输入 → 模型输出	输入多样性、指令理解
工作流	多步模型调用	每步模型输出累积偏差
单代理	灵活选择工具解决问题	工具调用顺序、参数提取
多代理	多个代理协作	交接逻辑、工具选择、非确定性累积

3.评估方法

• 指标评估：数值评分，便于自动化测试
• 人工评估：高质量但成本高
• LLM 评分器：使用 GPT-4.1 或 o3 自动评分，可匹配人工偏好

十二.模型优化

12.1 模型优化工作流程

优化模型输出通常需要 Evals + 提示工程 + 微调 的结合，形成一个反馈飞轮，从而改进提示并生成更好的微调训练数据。流程一般如下：

1. 编写 Evals
   • 测量模型输出，建立性能和准确性的基线
2. 提示模型输出
   • 提供相关上下文数据和指令
3. 针对特定任务微调模型（可选）
4. 使用代表性测试数据运行 Evals
   • 衡量提示和微调模型的性能
5. 根据 Evals 反馈调整提示或微调数据集
6. 循环迭代
   • 持续改进模型结果

12.2 微调模型

OpenAI 模型已经经过广泛训练。微调可以让你：

• 提供应用中常见的输入输出
• 获得在特定任务上表现卓越的模型
• 一致性地格式化响应或处理新颖输入

微调优势：

• 超出单次请求上下文窗口的更多示例输入输出
• 短提示即可得到高质量结果，降低 token 消耗和延迟
• 可使用专有或敏感数据训练，无需在每次请求中提供示例
• 可以微调小型模型以高效完成特定任务

微调方法

方法	说明	适用任务	支持模型
监督微调（SFT）	提供示例正确响应指导模型行为	分类、内容生成、特定格式生成、纠正指令执行错误	gpt-4.1 系列
视觉微调	提供图像输入进行监督微调	图像分类、复杂指令执行	gpt-4o
直接偏好优化（DPO）	给模型正反示例，指明正确答案	文本摘要、聊天风格调整	gpt-4.1 系列
强化微调（RFT）	对生成结果进行专家评分并强化高分思路链	高级推理、医学诊断、法律判例分析	o4-mini

微调操作流程

1. 收集训练示例数据集
2. 将数据集上传至 OpenAI（JSONL 格式）
3. 创建微调任务（选择方法）
4. RFT 情况下，需要定义评分器
5. 评估微调结果

12.3 监督微调

1. 核心定义

监督式微调 (SFT) 是一种通过提供“问题 + 标准答案（Ground Truth）”的示例数据，来训练模型掌握特定行为的技术。

• 目的：让模型在风格、语气、格式或特定指令遵循上表现更佳。
• 适用场景：分类任务、细致的翻译、严格的 JSON 格式生成、纠正模型指令遵循错误。
• 支持模型：gpt-4.1 系列（包括 mini 和 nano）。

2. 黄金法则：先评测，后微调

在开始微调之前，必须先建立一套评测系统（Evals）。

• 原因：如果你无法量化基础模型的表现，就无法判断微调是否真的带来了提升。
• 逻辑：微调的目标是让模型在特定指标上优于基础模型。

3. 数据集构建指南

数据质量是微调成败的关键。

• 数量策略：
  • 起步：建议从 50 条高质量示例 开始。
  • 验证：先用这 50 条进行微调并评估。
  • 决策：
    • ✅ 如果有提升：继续增加数据量以优化效果。
    • ❌ 如果无提升：不要盲目加数据，应重新检查任务定义或提示词（Prompt）。
• 质量要求：
  • 示例必须源自真实的业务场景。
  • 输入和输出必须清晰、无歧义。
• 格式：必须是 JSONL 格式（每行一个完整的 JSON 对话对象）。

4. 高级技巧：模型蒸馏

这是一种“降本增效”的高级玩法，用大模型教小模型。

1. Teacher (老师)：使用最强的模型（如 gpt-4.1）调试提示词，生成高质量的输出。
2. Dataset (教材)：将大模型的优质输出保存下来，构建成数据集。
3. Student (学生)：用这个数据集去微调更便宜的小模型（如 gpt-4.1-mini）。
4. 结果：小模型获得了接近大模型的效果，但运行成本大幅降低。

5. 操作流程

1. 准备数据：
   • 训练集：用于教模型。
   • 保留集 (Holdout Set)：不参与训练，专门用来测试模型是否真的学会了，还是只是“死记硬背”（过拟合）。
2. 上传与创建：
   • 上传 JSONL 文件。
   • 创建任务：选择基础模型 + 训练文件。
3. 使用检查点 (Checkpoints)：
   • 系统会在每个 Epoch（训练轮次）结束时保存一个版本。
   • 作用：如果最终模型“学傻了”（过拟合），你可以回滚到之前表现更好的检查点版本。
4. 安全扫描：
   • 微调完成后，系统会自动进行 13 类安全检测（如仇恨言论、非法建议等），确保模型安全合规。

十三.成本优化

提高效率并降低成本。

在使用 OpenAI 模型时，有多种方法可以降低成本。成本和延迟通常是相互关联的：减少 token 数量和请求次数通常会加快处理速度。OpenAI 的 Batch API 和 Flex Processing 是降低成本的额外方式。

成本与延迟
为了降低延迟和成本，可考虑以下策略：

• 减少请求次数：限制完成任务所需的请求数量
• 最小化 token 数量：减少输入 token 并优化模型输出长度
• 选择较小的模型：使用在降低成本和延迟的同时仍保持准确性的模型
  欲深入了解这些策略，请参考我们的 延迟优化指南。

Batch API
批量异步处理任务。Batch API 提供了一组简便的端点，可以：

• 将多个请求收集到单个文件中
• 启动批量处理任务执行这些请求
• 在请求执行过程中查询批处理状态
• 批处理完成后获取汇总结果
  开始使用 Batch API →

Flex Processing
针对 Chat Completions 或 Responses 请求，可通过牺牲响应速度和偶尔的资源不可用性，获得显著降低的成本。适用于非生产环境或低优先级任务，例如模型评估、数据增强或异步工作负载。
开始使用 Flex Processing →