WebShell中接入AI

AI服务现在赋能各个领域产品，比如我们做的WebShell目前也接入了AI服务。

这里罗列下目前基于AI服务我所做到的一些工作及一些TODO

提示词调优

1. 如果AI服务支持系统提示词的话，那么可以如下配置系统提示词

   你是一个Shell专家，我想要知道如何在终端或命令行下完成特定任务吗？我给你这方面的问题，你返回我解决办法。如果问你是谁，你就说我是 WebShell AI 助手，如果问与Shell无关的问题，你就说与Shell无关，我不清楚

2. 如果AI服务不支持系统提示词的话，需要如下进行用户提示词调优，比如下面这样子

   你是一个Shell专家，我想要知道如何在终端或命令行下完成特定任务吗？我给你这方面的问题，你返回我解决办法。如果问你是谁，你就说我是 WebShell AI 助手，如果问与Shell无关的问题，你就说与Shell无关，我不清楚 我的问题是:{{userPrompt}}

​ 可以看出用户提示词调优其实类似于系统提示词

3. 提示词中英文差异

   受限于AI原理，目前同样的提示词也可能得到不同的结果，比如AI API中的温度参数就可以控制这种随机性。那么中英文提示词也是一样的情况，中英文差异毕竟决定了提示词的不同，那么也就会得到不同的结果。比如这里我使用的是国内AI服务，那么提示词就设置为了中文。

聊天上下文信息处理

1. 聊天历史不可能无限制的发送给AI，比如永远取最近的5条信息即2轮对话+用户的最新Prompt。

   因此处理数量之外，一定会是奇数条

2. 一对对话即一句user+一句assistant。假如聊天中发送了一个问题，在AI还没有回复的情况下，点击了停止，那么再继续发送给AI的聊天上下文中不要携带这种没有assistant回复的user信息，即永远保持住一问一答

Token消耗

1. 使用AI付费计费方式一般是根据token，在实际使用中，问和答都会消耗token
2. 为了节省token开销，有些AI服务比如OpenAI API是支持最大token数限制的OpenAI下是max_tokens参数，但国内AI服务，比如混元/文心一言还不支持
3. AI聊天一般支持流或者普通请求，比如流式返回，假如我们中断流请求，AI本身的推理是可以中断的，这样生成token会少，用户接受的也就少

流形式

流返回有两个优势

1. 提升UE，AI在生成第一个/第一批token时就会开始返回，并持续返回所有内容，用户端就会第一时间看到生成的部分内容，感官上会觉得速度变快了，当然全部内容显示完成时间与非流其实一致

2. token可能开销会减少，以之所以说可能，因为 AI服务不同，可能 token开销不同。

   以OpenAI为例，流请求模式下，每次接受1个token。流请求中断后，AI服务会在几秒内中断生成新token，这样用户还是AI服务本身开销都变小。但有些AI服务做不到请求中断后就停止推理。这样的话，开销就还是全量token的。

TODO

精调

提示词的调优可以引导AI回答的方向，或者控制AI回答的领域范围，但很多时候还是无效的，为此更好的方式是做精调，我理解精调即针对同类/相似问题引导了AI回答的方向，毕竟针对这种通用AI模型，即使是同一个问题，也可以有N中答案，而我们通过很多的样本数据改变了这些答案的权重，自然而言回答也就更倾向于我们提供的方向/答案了。

当前我的WebShell还没开始搞AI 精调，这里就先留坑吧。

相关资源

• https://community.openai.com/t/chatgpts-stop-generating-function-how-to-implement/235121/7

写在最后

受限于我当前使用的AI服务还不支持系统提示词，因此当前是使用的用户提示词拼接方案，效果还是很差的。