扒一扒 OpenAI o1 系列模型 (二)：对开发者有何影响？ #132
Comments
|
您好，邮件已查收。Anmi、
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
o1 系列模型在多项测评中锋芒毕露，它是否就是开发者的万能之选呢？今天魔法哥将从 性能、局限、成本、接口协议、提示工程 等几个方面来探讨这个问题。
性能
适用场景
上篇文章 曾提到，o1 系列模型借助 训练阶段的强化学习 + 推理阶段的预思考 token 这两大奇招，显著提升了复杂推理能力——也就是说，它是一个 “逻辑高手”，业界的相关测评也验证了这一点。
不过，对于创意生成类场景来说，o1 的表现并不比上一代模型 GPT-4o 更出色。因此开发者有必要针对自己的应用场景进行性能评估，再决定是否要切换到 o1 模型。
模型版本
此外，o1 系列模型目前有
o1-preview和o1-mini两个版本可用，未来还会放出 “完全体”o1，它们之间也有能力差异。简单来说，
o1-preview和o1具备广泛的世界通用知识，着重于复杂推理；而o1-mini是一个更小规格的模型，其优势在于推理速度更快、成本更低，因此在编程、数学等不需要通用知识的场景下是更合适的选择。以上图为例，在某些领域，
o1-mini以较低的推理成本获得了与o1接近的推理能力。因此，开发者有必要考虑到o1-mini的这些优势，获取更好的性价比。推理速度
上篇文章也提到，o1 在正式输出之前，会在内部生成一定的 token 数量来进行 “预思考”。因此，它的 TTFT（生成首个 token 所用时间）肯定是比不上 GPT-4o 等上一代模型的；而且按照 TPS（每秒生成 token 数，即平均推理速度）来评估，o1 显然也具有先天的劣势。
魔法哥以某个简繁转换的文本生成任务为例，拿 OpenAI 自家 GPT-4o 模型与 o1 进行了推理速度的横向对比，数据如下：
gpt-4oo1-previewo1-mini由于 o1 目前 并不向 API 开发者公开预思考 token 的内容，因此上表没有把这部分 token 计入有效输出的 token 数。不出意外，o1 的表现与 4o 存在明显差距。
不过，如果我们把预思考 token 也算进去，o1 的成绩会变成如下情况，算是挽回了一些颜面：
o1-previewo1-mini魔法哥在测试中发现，o1 的数据波动较大，应该是预思考环节的不确定性所导致的。以上数据是多轮测试后的统计结果，仅供参考。
总之，o1 的推理速度决定了它不是一款 “万金油”。对于直接面向用户进行交互的场景，o1 并不是最佳选择。
局限
o1 模型还处在测试阶段，它与 ChatGPT 的整合还没有全部完成，比如目前还不能提供联网搜索、上传文件、识别图片等高级功能，也不能驱动 GPTs。
在 API 层面，o1 目前还有很多能力没有开放出来，下面魔法哥针对这些局限来逐一分析。
暂不支持流式输出
上面我们提到，o1 模型在生成实际输出之前有较长的 “预思考” 时间，而且这部分 token 并不会暴露给 API 调用者，这两点几乎堵死了它用于 C 端对话场景的可能性。从这个角度来看，目前 o1 不支持流式输出也就不足为奇了。
很显然，这个局限是眼下开发者在选择模型时需要关注的重点问题之一。
暂不支持系统提示词
魔法哥猜测，目前 o1 模型的 “预思考” 行为是通过大量的系统提示词来进行约束的，因此现阶段的 o1 模型为保证自身行为的稳定性，暂不向开发者开放系统提示词的能力。
对于开发者来说，如果要在自己的应用中换用 o1 模型，则只能 对原来的系统提示词进行适当调整，以用户提示词的方式来传递给模型。
暂不支持工具调用和持结构化输出
这两项能力通常在复杂的 AI 应用工作流中扮演重要角色，但 o1 模型目前还没有开放。如果你需要用到这两项能力，就只能等待 OpenAI 官方的进一步消息了。
暂未开放多模态能力
据说 o1 也是一个多模态模型，但目前还没有开放这方面的能力。如果你的应用场景需要处理图片、视频、语音等多模态数据，o1 暂时还无法胜任。
接口参数限制
像
logprobs,temperature,top_p,n等参数，要么不能用，要么已经固定为默认值。开发者如果打算尝试 o1，暂时就只能忽略这些参数了。话说回来，尽管 o1 API 目前还存在以上种种不便，但相信在不久的未来，随着 o1 结束测试阶段，这些局限也会逐渐解除。让我们拭目以待吧。
成本
这里魔法哥先列一下 o1 和兄弟模型的价格对比：（单位：美元 / 百万 token）
gpt-4ogpt-4o minio1-previewo1-mini可以看到，
o1-mini的定价确实比o1-preview要低不少；但是相比 GPT-4o 系列，o1 系列模型的整体价格还是偏高的。除此以外，还有一个好消息和一个坏消息：
好消息是，o1 系列模型也都支持提示词缓存，这在不少场景下可以显著节省成本。（这个 “提示词缓存” 是什么？魔法哥有机会也给大家单独讲讲。）
坏消息是，o1 的 “预思考” token 也是算在输出 token 中进行计费的！不让你看，还让你付钱，你说冤不冤？（开个玩笑，没有这些 “预思考” token，o1 的推理表现也不会这么好。）
总之，目前 o1 的 API 调用成本确实还比较高，开发者在选择模型时也需要掂量一下自己的钱袋子呀。
接口协议
OpenAI 经典的 Chat Completion 接口已经推出快两年了，从 GPT-3.5 到现在的 o1，接口协议基本没有破坏性的变化。能做到这一点确实不容易，也让开发者在接入新模型时省去了不少麻烦。
不过值得注意的是，这次 o1 模型在接口层面引入了一些小变化，这里需要提供一下各位开发者注意。
输入参数变化
首先需要留意 o1 模型 Chat Completion 接口的输入参数变化：
原先我们在限制模型输出长度时，会用到
max_tokens参数；但在调用 o1 API 时，需要把这个参数名改为max_completion_tokens。上面提到，o1 暂时不支持系统提示词。因此消息类型（message role）只能是
user或assistant，不能使用system类型。强行使用system类型会导致接口报错。可以看出，这两点需要开发者在切换到 o1 模型时特别注意，改代码或者加兼容层基本上是不可避免的了。好在魔法哥可以用 API2D 提供的 o1 API 服务，他们已经针对这两点做了兼容处理，开发者想要切换到 o1 模型就省事多了。
返回字段变化
Chat Completion 接口的输出结果也有一些扩展。我们会发现接口返回数据中多了一个
usage.completion_tokens_details.reasoning_tokens字段，这里的数值就是 o1 模型在 “预思考” 阶段使用的 token 数量。接口返回数据也进一步证实，“预思考” token 是计入补全 token 并收费的。
提示工程
最后我们来探讨一下，在为 o1 模型编写提示词时应该注意什么。
由于 o1 系列模型已经内置了思维链的推理能力，因此我们以前常用的一些提示工程技巧可能就不适用了，甚至可能会适得其反。以下是 OpenAI 官方给出的一些建议：
简单直接的提示词往往表现更佳。要相信 o1 的理解能力，复杂的指令可能反而会干扰模型的行动。
不要使用思维链类型的提示词。模型内部已经具备了这方面的能力，因此没有必要再要求模型 “一步一步思考” 或 “解释你的推理过程” 了。
使用分隔符来提升提示词的清晰度。使用代码块、XML 标签或小标题这样的分隔符，可以标记出提示词的不同部分，从而帮助模型更好地理解指令。
在 RAG 场景下不要塞入过多的上下文。很多 AI 应用都会通过外挂知识库来拓展模型的能力，但如果在上下文中塞入过多不相关的知识片断，则可能会干扰模型的推理过程或让模型迷失重点。
总的来说，针对 o1 模型的提示词应该是更加简洁和直接的，以免干扰到模型的自身的推理过程。这也值得开发者注意的一个要点。
小结
总的来说，o1 系列模型的推理能力确实出众，但它现阶段在速度、功能和成本等方面仍有劣势，开发者需要根据具体需求谨慎选择。相信随着功能的不断完善，o1 的应用前景值得期待。
魔法哥最近一年都在做 AI 领域的研发和探索，下期分享更精彩。各位新朋友请关注公众号，下次更新不迷路：
🔥 往期推荐
AI 应用开发指南：
ChatGPT 高级技巧：
AI 资讯与评述：
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏
The text was updated successfully, but these errors were encountered: