当提到领先的人工智能研究机构，OpenAI 人工智能公司绝对是其中之一。作为全球最知名的 AI 研究机构之一，OpenAI 的成果和贡献不可谓不深远。它在自然语言处理和生成领域的 GPT 系列模型（GPT-1、GPT-2、GPT-3）尤为出色，引领了该领域的发展。
最近 ChatGPT 对各个领域都造成了不小的冲击，大家或多或少都已经和 ChatGPT 对话过，并且也得到了不少答案和结果，相信对它的能力也有了较为清晰的认知。
当然这篇文章的重点并不是怎么注册使用 ChatGPT 或是怎么搭建一个自己的 ChatGPT 服务，在很多同学的印象里，ChatGPT 是一个人工智能的模型，可以通过聊天的方式得到一些答案。这个并不是一个全面的认知，它能做到的事情也远不及此。
通过 GPT 模型 , 可以批量智能并且自动化地完成各行各业的工作。在这篇文章中，我们就将来学习 GPT 的高阶玩法 — 基于GPT模型开发自动化应用, 通过这篇文章的学习，大家将对 GPT 模型产生一个初步的认知，并且具备使用 GPT 模型应用到自己需要的方向的基本开发能力，形成整个 AI 应用维度的架构思维。本文将从以下几个大方向展开这部分的学习：

  • GPT 模型篇：通过这部分的学习，大家将对 GPT 模型具备一个相对清晰的认知，并且了解怎么根据自己的应用场景灵活选用模型。实际上，我们使用的 ChatGPT 只是其中的一种模型，即 GPT-3.5-turbo 模型。
  • GPT 接入篇：这部分我们将结合实际的例子来介绍 GPT 模型的接入，涵盖流获取、流式接入等高阶玩法。
  • GPT 应用篇：这部分我会基于我最近开发 GPT 模型的 vscode 自动化测试插件 GPT Unit Test，来具体剖析整个方案是如何设计的，并延伸到其他方向应该如何展开具体的 AI 应用。

全文干货很多，建议收藏深读！ 本文虽会以技术视角展开，但是并没有较深的技术门槛，非技术同学也可以关注，其中的 AI 应用思路相信会对优秀的你有不一样的启发，在这个领域，想法💡远比技术要更有价值。

GPT 模型篇

初识 - 什么是 GPT 模型？

GPT (Generative Pre-trained Transformer) 模型是一种基于 Transformer 结构的预训练语言模型，由 OpenAI 人工智能公司开发。它表现出色的原因是它能够在大规模文本数据上进行预训练，并根据任务进行微调，从而在多种自然语言处理任务上取得优异的结果。
GPT 模型是在大规模语料库上进行训练的。在预训练阶段，它会学习构建句子的基本结构、单词之间的关系、句子的文法和语法等等。在对其进行微调后，它可以实现诸如对话生成、文本摘要、机器翻译、命名实体识别等任务。
简单来说，GPT 是一种预训练算法模型，在它的基础上，存在一些变体，具备更大的预训练规模和数据集，使得它的自然语言能力更强，我们一直使用 ChatGPT 就是其中的一种变体。
因为这个性质，GPT 也可以被理解为是一系列预训练模型的统称，这些变体其实我们也可以称它们为 GPT 模型。经过这样的描述，相信大家也可以理解，GPT 模型的能力来自于大量数据集的反复预训练，不同的变体之间的差异也与训练的次数、规模和数据集息息相关。

差异 - GPT-3 , GPT-3.5, GPT-4 模型之间有什么区别？

InstructGPT（2022 年 1 月）是一系列 GPT-3 模型（包括 text-davinci-001、text-davinci-002 和 text-davinci-003）统称，于GPT-3相比，它的最大不同是针对人类指令（reinforcement learning with human feedback, RLHF）进行了微调 ； InstructGPT 产生的幻觉更少，更真实，但它在生成的多样性或者说创意上相对更差，因为它们试图在“对齐”的前提下，将人类偏好/价值观硬塞进原始数据模型中。
ChatGPT（2022 年 11 月）更进一步。 为了训练 ChatGPT，OpenAI 对 InstructGPT 对话模型进行了微调（马斯克在Twitter上指出openai 使用了Twitter 数据）, 这种微调在一定程度上也是可以的, 区别在于使用的policy and reward model
在了解了什么是 GPT 模型后，我们来看一下它的变体。当然除了 GPT-3, GPT-3.5, GPT-4 以外还有 GPT-2，GPT-2的能力在各方面都比较差，也不适合微调，这里就不展示描述了。

首先大家需要了解 GPT-3, GPT-3.5, GPT-4 都是具备对人类指令做出基本有效反馈的模型：

  • GPT-3 模型也称 davinci 模型，它虽然具备基础的响应能力，但是创造性比较差，在逻辑构造方面也比较难形成有规律或者说逻辑紧密的回答，所以通常来说，项目的应用（即 GPT 模型 的接入）我们并不会直接选用 GPT-3 模型，更多是用于模型微调，来产生适合业务的变体。
  • GPT-3.5 模型是在 GPT-3 模型的基础上微调的产物，相比之下，它具备更强的语言逻辑组织能力和创造力，也是目前使用范围比较广的 GPT 模型。
  • GPT-4 模型在 GPT-3.5 模型上提供了更具有实效性的数据集来进行微调，在时效性、创造力上都有一定的提升，缺陷是还没有完全公开，需要体验名额，或者接入微软提供的 azure gpt 模型使用。

    清晰认知 — 最近大火的 ChatGPT 使用的是哪种模型？

    那么我们平时常用 web ChatGPT 使用的是哪种模型呢？通常来说，使用的都是 GPT-3.5 模型，即 gpt-3.5-turbo 和 gpt-3.5-turbo-0301 这两种模型。
    上文我们也提到 GPT-3 模型通常是不会直接用来应用的，而 GPT-3.5 模型是在 GPT-3 模型基础上做出的更具创造力的模型，也是最基本适合应用直接使用的模型。至于 GPT-4 模型目前还没有直接推广，需要和企业签订协议，或者拿到体验名额后才能尝试。（不过目前我实验下来的效果，个人感觉，GPT-4 和 GPT-3.5 并没有太大差异）
    大家在看完 GPT 接入篇后也可以尝试接入一下 GPT-3 模型试试效果，相比目前的答案实体，GPT-3 的答案更像是信息的堆砌，所以这也是 GPT-3 模型通常是作为其他模型母体的原因。

    思路确定 — 应用阶段，我们应该选择哪种模型？

    如果你的应用比较轻量，没有过多的业务背景或是技术壁垒（即没办法在外网查阅到），那么可以直接接入 GPT-3.5 及以上模型。
    反之，如果你的应用需要了解业务背景，或者存在一些自研的能力，形成了技术壁垒，又或者是在时效性上有更高的要求，那么则需要以 GPT-3 模型为母体，进行微调。
    微调的文档可以参考platform.openai.com/docs/api-re… ，这里不再赘述，需要注意的是，请提前准备好和你业务背景、技术能力相关的训练数据，微调的效果与数据集的完整度和逻辑可靠性强相关。

    GPT 接入篇

    迈出第一步 — GPT 模型的接入 ?

    相信大家在上面的学习中，应该已经对 GPT 模型有了一个较为清晰的认知，事实上，GPT 模型提供可以为应用接入的能力，我们可以按照自己想法为自己的业务接入 GPT，并基于它批量完成一些工程化的事情。
    当然这里提到的自动化能力，绝不仅仅是 ChatGPT 这种 web 聊天这么简单, 通过对实际业务场景的通用性问题总结以及规律性结果处理，我们完全可以做到自动化完成一些工程化的事情，比如测试，代码优化等等，这个就是后话了，我们会在应用篇详细介绍。
    GPT 模型提供了 fetch 和 npm 包两种方式接入，当然这两种接入方式底层都是相同的，npm 包可以理解为是基于 fetch 逻辑的 nodejs 包装。接下来，我会结合实际的例子来给大家详细讲解 GPT 模型的接入以及实际业务接入使用中必须解决的一系列问题。

    GPT 模型接入 — fetch

    GPT 模型可以通过接口的方式来完成接入，上面我们提到 GPT-3 模型有很多变体，分别用于不同行业方向，比如 图片、聊天等，具体的文档大家可以参考 platform.openai.com/docs/api-re…
    下面我们将以聊天模型的接入展开介绍，这个是我们应用中最常用的模型（即使不是用来做聊天室），它的结果更具备逻辑性，容易总结出通用性问题并集中处理, 我们来看下面的例子 ```javascript const messages = “Once upon a time”; const apiKey = ““; // OpenAI API 授权密钥 const apiUrl = “https://api.openai.com/v1/chat/completions“;

const headers = { “Content-Type”: “application/json”, Authorization: Bearer ${apiKey}, };

const data = { messages, max_tokens: 5, };

const options = { method: “POST”, headers, body: JSON.stringify(data), };

fetch(apiUrl, options) .then((res) => res.json()) .then((json) => console.log(json)) .catch((err) => console.error(err)); 复制代码 ``` 在上面的例子中，我们实现了一个简单的 fetch 方式的接入，其中 apiurl 即是 chatgpt 模型的接入地址，我们需要获取到 openAPI KEY 并作为鉴权传入 headers 中，其中 openAPI Key 可以从 openAI 账号中生成，是一个用户信息鉴权 key，使用过程将会消耗 openAI 的额度，大家可以到 platform.openai.com/account/api… 生成。

data 的部分是 openAI 提供给我们的参数，可以进行一些自定义的配置，大家需要关注的有下面这些参数：

  • model：文本生成器使用的模型，即 GPT-3.5及以上 模型
  • messages：文本生成器的输入，表示您要向 API 提出的问题或问题描述。
  • temperature：控制生成的文本的随机性。值越高，生成的文本越具有创造性和想象力。当然并不是越高越好，值越高，答案存在错误的可能性也越高，需要根据业务场景灵活调整，默认为 0.7。
  • max_tokens：生成文本的最大长度，以 token 数量为单位。默认为 150，最大为 2048。
  • top_p：控制模型多个单词的权重。取值范围从 0 到 1，默认为 1.0。
  • n：请求 API 生成的新文本的数量。默认为 1。
  • stop：如果生成的文本包含以下任意一个字符串，即停止文本生成过程。默认为一个空数组 []。
  • presence_penalty：生成文本时减少出现重复子串。若设置，则模型尝试消除两个已经重复出现的词语间的文本。默认为 0.0。
  • frequency_penalty：在生成文本时惩罚使用过于频繁的单词。较高的值有助于提高生成文本的多样性，但可能会导致生成文本的不连贯性等问题。默认为 0.0。

需要额外注意的是，该模型输入（即 messages）最大为 4096 token，这里 token 的单位指的是自然语言处理领域中的最小语言单位，可以理解成小于等于1个单词，而输出（即max_tokens)最大为 2048 token。
也就是说如果问题过大，或者说回答过大，都将会造成内容的截断，常规的调用并不能无限制地问答，当然这个也是有解法的，我们会在下文中流相关部分详细介绍。

GPT 模型接入 — npm 包

除 fetch 调用外，我们还可以通过 npm 包的方式完成接入，当然底层都是用 fetch 链接，我们需要安装一下 npm 包的依赖。
我们来结合例子看看具体应该怎么通过 npm 接入 GPT 模型
不过需要注意的一点是，fetch 中我们举例调用的 chatgpt 模型，即 gpt-3.5-turbo 及以上模型，而 npm 包不需要填 fetch 链接，如果想调用了 davinci 模型（即 gpt-3），参数需要有一些调整，需要将 messages 换成 promt，因为 davinci 底层调用的链接其实是 api.openai.com/v1/completi…
如果用的是 gpt-3.5-turbo 及以上模型, 那么 parameters 中的问题描述参数请用 messages。

流获取 — 如何解决 max_tokens 答案截断的问题？

在上文中，我们有提到 gpt 输出的结果长度由一个参数 max_tokens 限制，最大为 2048。但是在实际的业务场景中，我们不可能保证我们需要的答案一定只在 2048 内，一个可能截断的答案我们是没办法进行有效规律地提取我们需要的内容然后做一些事情的。
这个问题很头疼，但是是有解法的，我们来看下面这段示例
在上面的例子中，我们在请求中补充了一个响应类型，即 responseType：stream，这将使得 openai 的响应将由一个固定的结果，调整为文件流。在后面的逻辑中，我们创建了一个可写流，接收这个可读流，并将内容完整写入到文件中。
流是一种处理读写文件、网络通信或任何端到端信息交换的有效方式。流的独特之处在于，它不像传统的程序那样一次将一个文件读入内存，而是逐块读取数据、处理其内容，而不是将其全部保存在内存中。这也是为什么通过这种方式可以突破 max_tokens 长度限制的原因，因为我们并不是一次性拿到全部的答案，而是逐步写入。

流式接入 — 怎么突破输入的限制（ChatGPT 实现原理）？

上文中我们有提到，除了输出有 2048 token 的限制外，不仅如此输入也是有的，我们的输入不能超过 4096 token，否则就会被 openAI 拒绝。事实上，在真实的业务场景，如果涉及代码，这个限制是很容易被超过的，那么这个问题我们可以怎么解呢？
我们可以采用相同的思路，建立流，并通过 webSocket 保持一个持久化连接，我们知道 gpt 的问题在长连接的状态下是可以保有上下文的，通过拆解我们的问题，将一个大问题分解为多个小字符串输入给 gpt，从而达到突破输入限制的目的，我们来看下面这段示例代码。
在上面的示例中，我们用 websocket 建立了一个持久化连接，需要注意的是，参数中我们为它开启 stream: true，这个参数将响应数据流式返回，这样可以在使用 WebSocket 或其他无状态通信协议时，实时处理生成的响应文本，这样就可以在需要长时间持续对话时节省请求时间和开销，并使对话过程更加自然连贯。
看完这部分相信大家会有一个额外的收获， web chatgpt 是怎么实现的？是的，也是采用这种方式，用 websocket 建立持久化连接，持续输入获得答案。

GPT应用篇

抛砖引玉 — 基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)

在完成上面的学习后，相信大家对 GPT 模型和它的接入都有了初步的认知，可能已经对做一个自己的应用跃跃欲试了，在这里想提醒一下大家：
因为 GPT 模型本质上是一个训练集模型，这意味着你问它的所有问题，都会上传到外部，注意隐私和数据安全是很重要的事情，一些内部或者公司内的代码或者敏感信息不要拿来问 GPT 哦～
我们言归正传，在应用篇我会以我最近写的一个 demo — “基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)” 为大家讲解应该如何应用 GPT 模型到你感兴趣的方向中，希望对大家有一定启发。
这个插件已经发布到了 vscode extensions，大家可以直接安装使用

插件的使用很简单，在安装完成插件后，文件夹和文件的右键目录中会多出一个选项 generate unit test，点击后如果没填写有效 openApi key 会要求填写，鉴权完成后即可自动为需要的文件目录或是文件生成单元测试，当然也支持 ignore 文件和测试库等配置，具体的大家可以阅读 readme，其中有更详细的解答。

因为是个 demo,所以可能仍然有bug，但是主流程上经过测试是没有问题的，如果你出现不能使用的情况，可能是以下情况：

  • 中国区ip被锁，需要替换虚拟 ip, 因为底层它用的还是 openAI 的能力
  • vscode 的 engines 版本低于 1.77.0，这个需要升级 vscode 版本
  • 输入的 token 限制，测试文件过大，这个 demo 版还没支持，目前测试下来 300 行上下的文件测试质量还是很在线的
  • 其他的一些问题，这个你可以在评论区或是按照 readme 中贡献 & issue 的方式联系我，我会尽快答复你

当然这个插件也许不一定会继续迭代，这只是我技术建设抽离出来的一个 demo 版本，在隐私性没办法做得更好，所以只适合 C 端项目（GPT 是公开的），后续的迭代可能都会以我内部对应的技术建设项目为主（大家用不了0x0），所以这也是我不开放贡献的核心原因。
如果是插件主流程阻塞的问题我也许还是会修的，目前看来没有，主要还是会根据我的个人时间来决定（几乎没什么个人时间）。
虽然但是～我想这个插件作为一个 AI 应用方向，用来抛砖引玉我相信会是很好的借鉴，也期待得到更多大家的反馈。下面我们就来具体谈谈这个插件是如何设计的。

场景还原 — GPT Unit Test 是如何设计 & 与 GPT 模型结合的？

我们先来看看这个插件的流程图

其实可以看到整个流程是并不复杂的，除了 openAI 的流式接入外，主要的逻辑都只是一些 i/o 操作，而且这边我们并没有与 GPT 建立持久化连接。
因为在这个 case 中，单元测试有一个重要的特点，就是单一原则上体现比较强，在对于一个组件的测试中，我会拆分为 n 个文件，每个文件独立测试，依赖的部分 gpt 则采用 mock 的方式完成，即 A 引用 B, 那么 A 的单测中只保证 B 和 使用 B 调用的内容存在，而 B 的功能则在 B 的用例中跑。
经过上面的拆分，一个组件的测试我们将不再需要关注整体，GPT Unit Test 的最小粒度就被拆分为了文件，而不是组件或是其他代码集合。接下来只需要按照常规的遍历文件系统，逐步以流的方式写入就行，具体接入的代码在 GPT 接入篇有讲解，还不清楚的同学可以回过头看看。

方向调研 — 如何判断 GPT 模型在某个方向的可行性？

回顾上面的过程，我们可以发现 AI 的应用技术门槛并不高，相反更高的反而是方案的设计以及你如何去应用，就像是一个“万能”（偶尔会胡说八道）的接口，只要可以找到对应方向的使用规律，就很容易拿到预期的结果，并做一些事情。
这里帮大家提取了这个过程真正需要关注的、消耗时间的三点：

  • 可靠性验证：保证 AI 帮你完成的事情是可靠的，这个过程需要经过大量 case 对比，将 AI 完成的用例和我写的进行对比，看看谁优谁劣，这里怎么对比的我就不赘述了，单元测试的部分不是这篇指南关注的重点。当然最后我得出了结论，AI 写的用例覆盖率、mock 和单一原则都很在线，不亚于我写的。
  • 通用性问题的总结：你使用 AI 不仅是解决单个问题，那么在每次解决之后，这些问法之间是否有共通的地方，能否总结出在一定微调后就可以使用的通用性问题，这个过程需要经过反复测试，并补充边缘情况的限制。比如 GPT Unit Test 使用的通用性问法就是这个

使用 jest 和 xxx （插件暴露出来给用户配置，暂时提供三个，mocha， enzyme 和 react-testing-library ） 为下面文件覆盖单元测试，要求所有的用例代码写在一起，且覆盖率达到 100%。需要测试的文件路径为 zzz (文件系统里取出来） ，且在单元测试的文件上一级目录，需要使用相对路径完成引用，请注意引用路径。请根据上述要求给出完整可用，具备有效依赖引用的代码。需要覆盖单元测试的文件代码如下 yyy

  • 结果是否规律可提取：每次拿到的结果是否存在一定规律，能否按照一定的格式或者套路提取出你需要的内容，这也是为什么我要求 gpt 把所有的用例代码写在一起的原因，通过这种方式我就能使用正则提取出代码块，再进行文件写入，这个同样也是需要通过 case 测试并对通用性问题进行补充的。

如果说，你感兴趣一个方向，并且希望这个方向可以使用 AI 提高效率，或者创造收益价值，那不妨回顾一下这三点，如果这三点都想清楚了，那 GPT 模型在这个方向一定是大有可为的。

你也可以做到！— 将 GPT 模型应用到某个方向的可复刻实践方案

经过上面的学习，相信很多同学心里都已经有了自己的答案，将 GPT 模型应用到某个方向的可复刻实践方案无非就是三点：

  • 可靠性验证
  • 通用性问题的总结
  • 规律性结果提取

当我们处理一个大问题的时候，我们有一个常见的算法思路，就是分治法，通过把大问题拆解为小问题，再逐步将小问题解决，从而达到解决大问题的目的。在将 OpenAI 应用到某个方向的时候，也是相同的道理。
以自动化测试为例，如果我需要使得 OpenAI 能够批量去处理某些场景，那么首先 OpenAI首先要能解决某个例子的自动化测试用例生成，因为一个都不能解决，那就不用去考虑批量或者说更多场景的事情了。
如果每个小问题都逐一解决后，我们需要考虑的就只剩下对比这些问法中间的共同点与不同点了，通过这个过程，提取出通用性问法就是能够应用到这个方向的关键了。 就和动态规划的动态表达式一样，难的并不是动态规划，而是表达式的提取，当完成这一步 OpenAI 在这个方向的应用就已经完成大半了。
在拿到通用性问法后，至少可以说明这个方向是可行的了，在绝大多数场景下，一个合适的问法都可以拿到一个比较有规律的答案，我们通过正则等字符串处理的方式就能拿到最终的结果。如果结果比较多样性，那大概率是因为通用性问题缺乏一些限制。
就比如“为下面文件生成用例，要求覆盖率100%，且当前文件路径为xxx，请使用合理的相对路径引入”远远比“为下面文件生成用例”得到的答案更具备规律性，如果因为结果不够规律，不知道该怎么提取结果，在放弃前不妨试试多加一些限制（即使这些限制在你看来像是废话）
当前这些更像是纸上谈兵，具体怎么问也要结合实际场景，和大量 case 测试后才能提取出来，不妨大胆试试，宁愿犯错，也不要什么都不做。不仅是测试，类似代码优化、性能优化、代码迁移重构其实 AI 都可以做到，而且我相信大有可为，至少在这个领域，想法💡远比技术要更有价值。

小结

这篇指南我们分别就 GPT模型、GPT模型接入、GPT模型应用三个方向结合例子详细学习了 GPT 的高阶玩法 — GPT模型自动化应用，不管是搭建一个私服 chatgpt，还是利用 gpt 的能力完成一些工程化，或者是代码优化的内容，都可以参考上面的部分，相信大有可为～
还是那句话，在这个领域，想法💡也许远比技术要更有价值，GPT 的应用还远不及此，最近推出的 GPT 克隆人、AutoGPT 都让人眼前一亮。
也许有一天流浪地球 2 中的数字生命也不再是幻想，如果用 websocket 搭建两个 gpt-3,并且通过一定的数据微调让他们扮演两个人，互相对话训练又会发生什么呢？
这个方向有太多可以探索的东西，希望大家可以不设边界，多去尝试，也许真的你就是改变世界的那个人～如果对这方向有疑惑或者需要探讨的内容，也欢迎大家在评论区与我交流！