ChatGPT 服务端开发&变现
Hi,我是 TyCoding.
引言
在往期的文章中,我有在个人服务器上部署过 ChatGPT-API 项目:http://chatgpt.tycoding.cn 。有朋友反映链接空了,这里说明一下:
我的服务器被举报了,阿里云让强制关闭服务。没错,就是这样!
本篇文章目录:
-
我的服务器被举报了(Web 端存在的合理性) -
如何让 ChatGPT 成为助手(调教指南) -
关于 ChatGPT 变现的思考 -
Node-ChatGPT 服务端开发(如何维护会话上下文、历史消息)
关于模型
当前 OpenAI 开放的接口模型是基于 GPT-3,而 ChatGPT 官网是基于 GPT-3.5 特殊针对 Chat 聊天适配的模型,因此你在使用上明显感觉官网的回答更像“人类”。
关于服务器被举报
其实不难想到,在 Web 端部署一套 ChatGPT 服务,一定是无法避免的直接暴露服务器信息和接口信息。再加上 AI 本身肆无忌惮的输出文本信息,我们又无法做到过滤文本信息,被封禁只是时间问题,更不用说接口的安全性问题了。
显然,像我这样直接把接口地址暴露给大家测试,能想到:


Web 端存在的合理性?
其实早在刚接触 ChatGPT 的时候就发现,类似的开源项目很少有基于 Web 端的,而更多的是客户端的项目,比如微信公众号、机器人、小程序、客户端产品、各种插件…
不是说客户端产品就无法抓包到接口信息,而是这种毫无功能特点的项目只能是作为 Demo,或许我们需要让他针对性对特定问题回答才能发挥它的功能特点。
因此,可以考虑功能性小程序、机器人、集成到客户端产品中。这其实只需要在每段会话中增加 特定前缀或后缀 ,让 AI 限定在某个场景下回答问题即可。
如何让 ChatGPT 成为助手
我们知道,AI 的回答是完全不受任何限制的,因此在国内的环境中,很多内容是不被允许的,这也是为什么我的服务器很容易被举报,那么如何让 ChatGPT 听话一点呢?
很简单:只需要让 ChatGPT 限定在特定场景回答消息,不要回答和此场景相关的任何问题。 举个例子:

从开发者的角度,我们只需要定一个场景的后缀会话信息,最终推送给 ChatGPT 的消息是:用户输入文本 + 场景后缀文本
如果你想了解更多关于如何调教 ChatGPT 的信息可以查看:https://github.com/PlexPt/awesome-chatgpt-prompts-zh
关于 ChatGPT 变现的思考
先说结论:对于个人开发者而言,目前这很可能只能做用爱发电的项目。
Why?
接口开发的局限:
-
目前 OpenAI 接口的 Key,每个账户只有 18$ 额度,用完之后就要付费或者重新注册账号 -
目前 OpenAI 接口开放的 GPT-3 模型不够智能,想要更智能需要付费订阅 ChatGPT-Plus
,售价 20+$/月
这里提供几个思路:
-
做微信生态下的产品(公众号、小程序)
a. 首先微信个人开发者是无法接入微信支付的,因此你不太可能通过限定用户使用次数进行收费的方式实现变现
b. 其次考虑通过“流量主”变现,这个门槛比较高;公众号需要 500 粉丝才可接入,小程序需要 1000 独立访客才可接入
-
考虑写软文、科普自媒体。这个变现更慢,且需要长期维持高热度流量才行。
-
考虑卖账号。 这应该是目前最赚钱的方式了,通过给小白用户注册账号或者提供 🪜 服务指引,目前这种渠道收益应该很高。
-
考虑定制化一些小工具,参考上面“调教指南”,可以利用 AI 的功能协助我们完成各种小工具的快速生产。
-
利用特殊话术,可以让他帮我们写小说、行业分析报告…;
-
通过 AI 语言学习能力,可以给他一段文本,让他做语言分析包括:人物的心理状态、情绪状态;或者让他帮我们组织文本,让废话写的更简练标准…
-
…….
Node-ChatGPT 服务端开发
为什么是 Node?
如果你尝试过调用 ChatGPT 的接口,就知道目前开放的接口中并没有提到 ConversationId,但又都知道 AI 本身是能识别上下文语境的。这其实需要服务端自己去维护上下文,模型本身没有任何会话支持,需要服务端本地使用缓存来存储会话并将它们作为上下文传递给模型。
因此到这里,你可能就明白,为什么不直接写一个 HTTP 调用接口?因为不使用这些开源库,你可能需要自己研究官方 API 看如何实现会话存储和传递,否则只能是一问一答的每次作为一个新的 Conversation 和 Chat GPT 通信。
直接在 GitHub 搜索chatgpt-api
排名最靠前的项目:

其实要关注的是这两个库,因为相对于 Python 我更擅长前端开发,因此选用了transitive-bullshit/chatgpt-api
这个库,两者都实现了对 Conversation 的支持。
如何使用 chatgpt-api 库
需要什么库?(注意这里需要 Node 版本>18)
-
chatgpt
:transitive-bullshit/chatgpt-api
的 npm 库 -
express
:Node 官方推荐的 Web 框架,用于开发服务端接口
安装:
-
首先创建一个文件夹,然后使用
npm init
指令初始化 node 项目,一路回车(这其实和 Java 中的 Maven 一个道理) -
初始化完成后,该文件夹根目录会出现
package.json
文件,然后安装上述两个库,依次执行指令:npm install chatgpt
npm install express -save -
第三方库安装成功后,目前文件夹结构如下:
image-20230227214603894 -
在根目录创建
bin/server.js
存放服务端代码,并修改package.json
增加启动指令:image-20230227215016312 可以看到,环境已经搭建成功了,下面在
server.js
中写服务端代码。
server.js
鉴于transitive-bullshit/chatgpt-api
的 readme 中已经写过 demo 了,这里直接粘贴代码,主要功能:
-
使用 Express 框架定义一个 /chat
的接口,监听端口:3000 -
在 /chat
接口函数中调用chatgpt-api
的函数并推送消息
console.log('server run....')
// 引入express库,注意这里使用require引入(默认支持这种模式引入包)
// 要注意Node对require和import的分包模式,两者不能共存
var express = require('express')
var app = express()
var bodyParser = require('body-parser')
// 开启对json传参的支持
app.use(bodyParser.json())
// 定义chat接口
app.post('/chat', async (req, res) => {
const { text } = req.body
fetchChat(text)
res.send('Hello')
})
// 推送消息
async function fetchChat(text) {
// 注意,因为node的分包模式不同,这是使用动态引入包的方式,不可在文件顶部直接import
const { ChatGPTAPI } = await import('chatgpt')
const api = new ChatGPTAPI({ apiKey: 'you openai-api-key' })
console.log('------------------------')
console.log('推送消息:[' + text + ']')
const res = await api.sendMessage(text)
console.log('收到消息:[' + JSON.stringify(res) + ']')
}
// 服务监听端口
app.listen(3000)
执行效果:


从接口中可以看到很多数据,一些我们会使用到的参数:
-
conversationId (当前会话的唯一 ID) -
parenMessageId (会话的父消息 ID) -
model (当前使用的模型) -
text (应答文本内容)
如何保证唯一会话?
在上面未指定 conversationId 的情况下,每次调用都认为是新的会话;如果需要维持会话需要在传递消息时主动传递一个 conversationId,如下:
const res = await api.sendMessage(text, {
conversationId: 'xxxxxxxxxxxxxx',
parentMessageId: 'xxxxxxxxxxxxxx',
})
注意 parentMessageId 应该是每次会话都更新,而 ConversationId 需要保证在同一会话中的唯一性。
大家可以使用这种方式使用一下,这里就不再粘贴案例了。
联系我
-
个人博客:http://tycoding.cn/ -
GitHub:https://github.com/tycoding -
微信公众号:程序员涂陌
原文始发于微信公众号(程序员涂陌):ChatGPT服务端开发&变现思路
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/145641.html