WebShell中接入AI

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

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

https://static.1991421.cn/2023/2023-11-01-234604.jpeg

提示词调优

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

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

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

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

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

  1. 提示词中英文差异

    受限于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 精调,这里就先留坑吧。

相关资源

写在最后

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