Open cssmagic opened 1 month ago
o1 系列模型在多项测评中锋芒毕露,它是否就是开发者的万能之选呢?今天魔法哥将从 性能、局限、成本、接口协议、提示工程 等几个方面来探讨这个问题。
上篇文章 曾提到,o1 系列模型借助 训练阶段的强化学习 + 推理阶段的预思考 token 这两大奇招,显著提升了复杂推理能力——也就是说,它是一个 “逻辑高手”,业界的相关测评也验证了这一点。
不过,对于创意生成类场景来说,o1 的表现并不比上一代模型 GPT-4o 更出色。因此开发者有必要针对自己的应用场景进行性能评估,再决定是否要切换到 o1 模型。
此外,o1 系列模型目前有 o1-preview 和 o1-mini 两个版本可用,未来还会放出 “完全体” 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-4o
由于 o1 目前 并不向 API 开发者公开预思考 token 的内容,因此上表没有把这部分 token 计入有效输出的 token 数。不出意外,o1 的表现与 4o 存在明显差距。
不过,如果我们把预思考 token 也算进去,o1 的成绩会变成如下情况,算是挽回了一些颜面:
魔法哥在测试中发现,o1 的数据波动较大,应该是预思考环节的不确定性所导致的。以上数据是多轮测试后的统计结果,仅供参考。
其实 “推理速度” 这个指标在云端有很大的调度空间,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,暂时就只能忽略这些参数了。
logprobs
temperature
top_p
n
话说回来,尽管 o1 API 目前还存在以上种种不便,但相信在不久的未来,随着 o1 结束测试阶段,这些局限也会逐渐解除。让我们拭目以待吧。
这里魔法哥先列一下 o1 和兄弟模型的价格对比:(单位:美元 / 百万 token)
gpt-4o 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。
max_tokens
max_completion_tokens
上面提到,o1 暂时不支持系统提示词。因此消息类型(message role)只能是 user 或 assistant,不能使用 system 类型。强行使用 system 类型会导致接口报错。
user
assistant
system
可以看出,这两点需要开发者在切换到 o1 模型时特别注意,改代码或者加兼容层基本上是不可避免的了。好在魔法哥可以用 API2D 提供的 o1 API 服务,他们已经针对这两点做了兼容处理,开发者想要切换到 o1 模型就省事多了。
往期文章也介绍过,API2D( https://cmcm.link/p/api2d )是一个大模型 API 聚合平台,按量计费,随充随用,相当适合个人开发者和小型团队。
Chat Completion 接口的输出结果也有一些扩展。我们会发现接口返回数据中多了一个 usage.completion_tokens_details.reasoning_tokens 字段,这里的数值就是 o1 模型在 “预思考” 阶段使用的 token 数量。
usage.completion_tokens_details.reasoning_tokens
接口返回数据也进一步证实,“预思考” token 是计入补全 token 并收费的。
最后我们来探讨一下,在为 o1 模型编写提示词时应该注意什么。
由于 o1 系列模型已经内置了思维链的推理能力,因此我们以前常用的一些提示工程技巧可能就不适用了,甚至可能会适得其反。以下是 OpenAI 官方给出的一些建议:
简单直接的提示词往往表现更佳。要相信 o1 的理解能力,复杂的指令可能反而会干扰模型的行动。
不要使用思维链类型的提示词。模型内部已经具备了这方面的能力,因此没有必要再要求模型 “一步一步思考” 或 “解释你的推理过程” 了。
使用分隔符来提升提示词的清晰度。使用代码块、XML 标签或小标题这样的分隔符,可以标记出提示词的不同部分,从而帮助模型更好地理解指令。
在 RAG 场景下不要塞入过多的上下文。很多 AI 应用都会通过外挂知识库来拓展模型的能力,但如果在上下文中塞入过多不相关的知识片断,则可能会干扰模型的推理过程或让模型迷失重点。
总的来说,针对 o1 模型的提示词应该是更加简洁和直接的,以免干扰到模型的自身的推理过程。这也值得开发者注意的一个要点。
总的来说,o1 系列模型的推理能力确实出众,但它现阶段在速度、功能和成本等方面仍有劣势,开发者需要根据具体需求谨慎选择。相信随着功能的不断完善,o1 的应用前景值得期待。
魔法哥最近一年都在做 AI 领域的研发和探索,下期分享更精彩。各位新朋友请关注公众号,下次更新不迷路:
📣 AI 魔法群开放啦! 扫码加群,领取魔法哥整理的常用 AI 工具包:
扫码加群,领取魔法哥整理的常用 AI 工具包:
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏
您好,邮件已查收。Anmi、
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-4o
o1-preview
o1-mini
由于 o1 目前 并不向 API 开发者公开预思考 token 的内容,因此上表没有把这部分 token 计入有效输出的 token 数。不出意外,o1 的表现与 4o 存在明显差距。
不过,如果我们把预思考 token 也算进去,o1 的成绩会变成如下情况,算是挽回了一些颜面:
o1-preview
o1-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-4o
gpt-4o mini
o1-preview
o1-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 | 我要订阅 | 我要打赏