快速打造你的OpenAI/GPT应用的步骤
本文正在参加 ✍???? 技术视角深入 ChatGPT 征文活动
ChatGPT 与 OpenAI:两者的关系
ChatGPT
是 OpenAI 推出的应用,它使用的是最新的模型。OpenAI 作为一家人工智能领域的知名企业,一直在致力于推进人工智能技术的发展和应用。而 ChatGPT 作为 OpenAI 推出的一款应用,为用户提供了基于语言理解的自然语言交互服务,它的出现也标志着 OpenAI 在人工智能应用领域的又一次突破。
然而,需要注意的是,OpenAI
开放接口的模型是 gpt-3.5-turbo
,这个模型相对于 ChatGPT
使用的最新模型而言,存在一些不足之处。虽然 gpt-3.5-turbo
已经具有很高的语言理解能力,但相对于最新的模型而言还有一些提升的空间。因此,如果需要使用更为智能化、精准化的自然语言交互服务,建议选择使用 ChatGPT
应用。
需要说明的是,由于 ChatGPT
使用的最新模型没有开放接口,因此它只能通过无头浏览器等方式来使用,这也导致了它的使用相对不稳定。但是,随着技术的不断进步和完善,相信 ChatGPT
将会在未来得到更好的应用和发展。
除了 ChatGPT
应用之外,OpenAI
还在不断探索和推进人工智能技术的发展,也在持续地开发出更多的应用和产品,以满足不同用户的需求。相信在未来,我们将会看到更多更加智能化和便捷化的人工智能应用和服务。
OpenAI API 接口的应用范围
OpenAI API 接口提供了丰富的应用功能,包括自然语言处理、语音识别、图片生成等方面。具体的使用方法和说明可以查看官方文档
(platform.openai.com/docs)。需要注意的是,由于一些原因,目前该文档在中国网络中无法访问。
然而,需要明确的是,OpenAI API 接口中真正智能的模型是 gpt-3.5-turbo
。该模型具有非常高的自然语言处理能力,可以实现多种不同的应用,比如对话补全、文本自动摘要、文本翻译等。近年来,众多应用和产品已经开始将 gpt-3.5-turbo 应用到实际生产中,包括各类智能客服、智能问答、智能写作等应用场景。
需要说明的是,除了 gpt-3.5-turbo
之外,OpenAI API 还提供了其他的接口和模型,如语音识别和图片生成。这些接口和模型也可以应用到不同的场景中,满足用户的不同需求。但是相对于 gpt-3.5-turbo,这些模型的智能化程度可能要稍低一些,因此在选择接口和模型时需要根据具体需求进行选择。
总的来说,OpenAI API 接口提供了丰富的应用功能,可以帮助用户在不同场景下实现自然语言处理、语音识别、图片生成等多种应用需求。相信随着技术的不断进步和完善,OpenAI API 将会在未来得到更好的发展和应用。
chat completions 接口如何使用?
可以通过很多方式来使用,比如使用官方SDK,第三方项目,但其实只需要一个HTTP请求就可以。以下是官方文档给出的例子:
curl <https://api.openai.com/v1/chat/completions> \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_API_KEY' \
-d '{
"model": "gpt-3.5-turbo",
"messages": [{"role": "user", "content": "Hello!"}]
}'
除了基本的使用方法外,还有一些细节需要注意,以保证 GPT 的使用效果更佳。
1. model选择
在选择使用哪个 model 的时候,需要考虑两个因素:计费和效果。目前官方文档提供的 model 有 gpt
, gpt-2
, gpt-3
和 gpt-3.5-turbo
四种。其中,gpt
是最便宜的,但是效果最差;gpt-3.5-turbo
则是最贵的,但是效果最好。在选择时,需要根据实际需求进行权衡。
2. messages的构造
在构造 messages 的时候,需要注意以下几点:
- messages 的长度不能超过
2048
字节。 - 在一次请求中,可以传递多条 message,每条 message 的
role
不能相同,即不能有两个user
或两个system
。 - 对于 user 的 message,需要注意语言和表达方式,以便 GPT 能够更好地理解问题。
3. max_tokens的选择
max_tokens
是生成回答的最大长度。在实际使用中,需要根据具体需求选择合适的长度。如果长度过长,会导致生成的回答不够准确;如果长度过短,会导致回答内容不够完整。
4. 请求地址的选择
由于种种原因,OpenAI 的 API 目前在中国大部分地区已经无法访问。解决这个问题的方法可以是使用国内的 API 中转服务,或者使用 VPN 等工具进行访问。
Stream 参数
补充一下关于 SSE
的信息,SSE
是一种非常有用的网络传输协议,能够允许服务器主动向客户端推送数据。这种方式可以实现实时性很高的应用,例如实时聊天、股票行情推送等。
使用 SSE 时,客户端与服务器之间建立一个持久化的连接,服务器可以随时向客户端发送数据,客户端也可以随时向服务器发送请求。与传统的 HTTP 请求不同,SSE 中的请求不会被关闭,而是保持打开状态,直到客户端主动关闭连接或服务器关闭连接。
因此,当我们需要实现实时性较高的应用时,SSE
是一个非常好的选择。而对于 ChatGPT
这样的实时聊天应用,使用 SSE 是非常必要的。
其他参数
接口的其他参数可以看官方文档,访问不了的同学可以看我做的截图。
Chat completions 接口如何计费?
chat completions
接口按 token 计费,有一个专门的算法来计算 token。输入和输出全部都会计入到 token 里边,在 chat completions
接口的 usage
里边会有具体消耗的 token 数。
如果你要自己计算,可以用这个在线表单,程序计算可以看看这两个项目:
- github.com/dqbd/tiktok…
- github.com/openai/tikt…
除了 gpt-3.5-turbo
模型的 chat completions
接口,还有 text-davinci-003
模型的 text completions
接口可以用,但是价格更贵,效果更差 ????
你可以在 openai.com/pricing 查询到价格,以下是3月中旬的定价
Model | Usage |
---|---|
gpt-3.5-turbo (ChatGPT) | $0.002 / 1K tokens |
Davinci (InstructGPT) | $0.0200 / 1K tokens |
Ada (InstructGPT) | $0.0004 / 1K tokens |
Babbage (InstructGPT) | $0.0005 / 1K tokens |
Curie (InstructGPT) | $0.0020 / 1K tokens |
chat completions 接口能做什么
虽然 chat completions
看起来像是一个聊天接口,但接口设计上并没有为聊天优化,因为这个接口是记不住上下文的。
为了让对话具有连续性,我们每次请求需要带上上次的聊天记录。你可以使用这个第三方库,它可以自动帮你发送聊天记录(通过指定对话的parentMessageId
)实现:
- github.com/transitive-…
在加上对话记录后,chat completions
接口就可以制作一个看起来有智能的聊天应用了。
如果你要在国内运营聊天机器人之类的话,请记得将内容通过文本内容审核接口进行审核,否则很可能导致被封。
如何解决国内用户无法注册OpenAI账号、无法访问OpenAI接口的问题?
两个思路,一个是绕道海外去注册,通过代理使用服务;另一个是直接使用第三方代理API服务。前者可以暂时解决当前的问题;后者更方便省心。
注册OpenAI
- 准备一个海外的网络
- 准备一个海外手机号来接收验证短信,可以用海外虚拟号码
注册完成后,进入API页面 创建Key,然后就可以使用了。
这个方案目前可行,是因为OpenAI给每个新用户提供了18美金的免费额度。但是一旦不再提供,就会面临充值的问题。目前OpenAI不接受中国信用卡,因此还必须准备一个海外信用卡。也就是说,要长久稳定的使用,必须有海外信用卡。
以前有财付通的海外虚拟信用卡,后来服务下线了。最近看了下,很多500RMB起,还只支持电商网站,感觉不太靠谱 ????
访问OpenAI API
3月3日开始,国内大部分网络不再能直接访问 OpenAI 接口。
因此你需要架设代理来访问OpenAI 接口。你可以将整个服务器代理到海外网络,或者只是简单的通过 Cloudflare 或者 腾讯云函数来部署API代理。
相对来说,我觉得腾讯云香港可能稳定点。
需要注意的是,部分API代理不支持SSE,因此不能实时返回内容。当然,有同学说腾讯云的 ApiGateway 直接就能代理,但我测试了下没成功。
通过第三方接口访问
如果你搞不定海外手机号和信用卡,或者自己不想架设代理,那么可以考虑用像API2D这样的第三方代理API。
主要的优点:
- 基本兼容原有接口,只需要改下 API endpoint 和 Key
- 支持国内卡充值,开发者可以让用户自己自行购买点数并创建Forward Key
- 接口国内直接可以访问,无需架设代理
缺点:
- 不支持 stream 参数,因此只能一次性返回内容
- 不支持微信充值,价格比官方略高
推荐阅读
-
谈API网关和应用网关--从技术选型谈起:API网关的性能是第一指标,一般会选择Kong、Apisix等基于OpenResty+Lua的高性能网关(得益于Ngnix基于C++的高性能无阻塞网络IO模型),应用网关一般是结合自身业务的技术栈来选择,比如SpringCloud Gateway、Zuul等。当然,这也不是绝对的,如果你对 Kong 非常熟悉,用它来做应用网关也不是不可能。 一些开源网关项目的例子: Kong Apisix 特使 Traefik SpringCloud 网关 Zuul / Zuul2 接下来,我们将重点介绍应用网关。在网格中,应用网关侧重于以下功能(与 API 网关不同) 动态路由 服务发现 服务聚合/协调 可观察性 如果您使用的是 Sping 技术栈,使用 SpringCloud Gateway 和 Zuul 可以轻松重用现有类库,如集成您的注册表,使用 Hystrix、resilience4j 完成熔断和限流功能等,快速完成一个生产级可用应用网关,如果引入新的复杂技术栈 成本将直线上升。根据使用场景的不同,性能有时并不是第一指标,但通常我们很容易陷入性能误区。
-
你可能不知道的快速排序:3 向快速排序 - 步骤
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
快速掌握Next.js:搭建你的第一个Next.js应用指南
-
简单教程:快速上手,10分钟打造你的数字代币
-
快速指南:Flutter应用的Android与iOS打包与发布的步骤
-
全面了解GPT Open API,轻松打造你的个人ChatGPT
-
打造快速Verilog并行FIR滤波器的7.2步骤详解
-
打造你的首个iPhone应用:从零开始的教程
-
Google打造应用背后的架构设计步骤流程详解