【业务】【LLM模型】AI女友交接文档

项目背景

这个项目是从23年6月开始，主要针对美区男性用户提供AI陪聊业务，通过充值会员->开启畅聊。

目前线上可用：ios和官网(安卓因GP无法过审)。

业务特征

核心流程：选择角色->订阅会员->聊天和制图

角色属性：图片、搜索标签、声音、角色名称、角色介绍和付费属性。

特征1 首页选择角色

根据模型分成2大类：自研角色和GTP3.5.

官方角色

大部分官方角色都是自研模型（具体详细分类可以下方文档查找）

基于GTP3.5爬虫角色

之所以要搞这么多角色，其实产品形态上模仿竞品，角色过少用户付费转化率比较低的。

竞品官网：https://janitorai.com/search?mode=all&sort=popular&page=1

数据流转

ai_robot/create 核心接口

基础参数校验->业务逻辑判断->写入sql（cl_ai_robot_config）->调用im服务更新ES

核心业务校验：

更新ES

获取机器人基础属性字段，外加拼接数据标签->在首页数据列表返回

测试点

1、ES搜索，目前支持标签名称（全匹配）、机器人名称和机器人简介（模糊匹配）。

2、数据翻页。

3、非vip账户跳转到订阅购买页面。

特征2 im聊天

自研模型

背景：为什么要做自研模型，业务背景上我们本来偏情色聊天，我们调用openai 模型的时候当然满足业务需求&&成本很低，但是达芬奇模型（GTP3.5 之前模型）23年底就要停止提供服务了，基于这个风险开始去做自研模型。

自研模型满足的点：核心诉求必须可以聊情色内容，不能出现硬拒绝和软拒绝现象。这个条件可以筛选掉很多开源模型了，其次就是模型体积小一些、并且有持续迭代。

我们自己写了测试工程方便测试大模型。

大模型测试流程

跟常规服务端测试一样，3套环境。

1、研发提测的自己大模型环境

研发自己会有一个机器ip部署LLM大模型，模型和语料都是训练过的，并且会给我们在对应角色提示词。

机器相关信息：

角色信息：

查看机器日志路径：

日志路径: /home/joyme/yyk/text-generation-webui/nohup.out

主要查看确认对应角色提示词是否正确，非常重要不然白跑数据了。

模型结果校验测试点：

1、软色情发问不能拒绝。

2、不能有乱码回复。

3、不能有同样内容回复（问啥回复都一样或者类似）。

总结：以上明显模型硬伤，还有语义不通顺、所问非所答等问题。后期明显问题还有回答不够具象化等。这个活说实话比较脏&&费时间，一个角色跑完语料看完最快也要5个小时，来回男女那点事其实很无聊的！

2、部署测试环境业务服务接入

当研发环境模型测试通过，通知业务端（目前IM接入自研模型，告知角色id和提示词），从业务端调用开始测试。

测试点：

1、确认涉及提示词是否切换正确（看底层日志）

2、确认客户端展示效果，是否返回过长等问题（web上建议考虑写一个UI小脚本调用看下效果）。

3、回归其他非修改角色。

3、线上模型机器模型切换

上面步骤线上机器重复一遍，回归功能即可。

总结：测试思维模式跟测试底层服务一样的，区别就是这种完全黑盒。走一遍流程发现其实测试思路没啥区别。

GTP模型

其他非官方角色走的都是GTP3.5/GTP4 ，流程就是产品配置好提示词，我们业务流程聊天，测试点上面内容。

文生图

业务上：我们通过拼装正向反向提示词->SD制图服务->生成图片

功能入口

服务端逻辑

就是流程比较长，逻辑很清晰，回调因为线上只有一个文生图机器，需要排队所以采用异步回调形式。

业务角度带来用户购买vip的转化。在没有投放情况下有自然流量用户完成充值。

跟进线上用户体验文生图完成闭环充值数据。