导语｜本文实践了一种GPT融入数据工具类产品的可行思路，简单来讲就是将GPT作为最小生产主体，通过构建多个【生产主体】，组成生产团队，以提升GPT融入产品后完成复杂任务的能力。
本文作者：markkwang，腾讯PCG产品经理
一、关于数科的数据基础场景
数据科学的工作场景简单来讲有两个方向，一是基于数据分析去做一些产品运营判断：比如指标、二是使用一些科学的方法来优化这些分析：比如 实验 等；这些任务的保障基础是数据的采集、加工与存储。采集、加工质量基本上决定了能用于分析、实验的数据质量。
目前比较主流的公司，无论大公司小公司，对于数据的采集与加工都在跑，但也在不断的进化。
- 相对大一些的公司可以进行行为数据的预先定义与采集、通过数据工程师的加工在数据库中进行存储，后续可以通过数据可查询语言、敏捷分析工具、实验平台等方式进行分析提取使用
- 小一些的公司，甚至非互联网公司也有很多方式进行数据的采集与加工，方式也从Excel等线下工具逐步转为了在线表格等相对新一代的分析套件
无论什么类型的公司，我们在思考优化迭代产品的时候，基本上的思路都是通过对于数据工作流的分析，尽可能多的减少因为流程、交流等方面造成的数据质量问题与效率问题。
- 比如 BI类工具 减少数据使用人员对于开发人员的依赖，可以通过【拖拽】等交互方式快速的进行数据分析；
- 比如 敏捷分析类工具 通过固化分析模型，减少数据使用人员对于【分析模型】等模型层面的理解，通过交互设计将 事件、路径等“专业名词“融入产品流程，降低用户的使用门槛与产出效率
- 比如 采集设计类工具 通过优化可视化等方式，将二维的数据结构立体化，可以直观的进行一些采集方案的设计，从而减少因为数据结构问题造成了需求遗漏与冗余等…
二、工具类数据产品AI化的一些探索
以上方案，我这边统一定义为「工具类Tools」数据产品，这个角度上讲，这类数据产品和Figma、Notion等工具的设计思想也基本是一致的。
在AI的加持下，我们首先看到了这些产品的一些动作：
- Notion等产品较为直接的可以通过“space”调取AI能力，进行一些文字创作
- Figma、蓝湖等服务设计师的产品，可以通过 自然语言 to 设计稿的方式，一句话生成设计稿
推至数据产品，工具类的数据产品也可以进行类似的优化———即将AI能力加入进来，可以完成例如 ：自然语言to需求转化、自然语言toSQL、自然语言to代码生成等。
基于这些内容我做了一些DEMO出来，逻辑也并不复杂，通过 System Prompt的调整，让GPT完成用户的需求并返回一些特定结构的数据。整体的产品功能覆盖了从数据采集到分析的全流程。
数据需求to采集需求
结果来看是正向的，产品能够满足相当一部分数据分析需求，进一步将其转化为DSL（领域特定语言）后，可以与其他工具平台进行对接，从而实际的减少开发人员和分析人员的工作量。（细节还很不足，仅供演示用）
三、复杂任务下的数据产品如何进行GPT融合
但在产品的实现与测试过程中也发现了一些问题。
最典型的问题是：产品在面对复杂分析任务的时候，生成的采集需求质量很低。以下例子可以看到，在用户需要分析“完播率”这样的复合指标的时候，GPT的采集需求生成基本不能支撑完成分析。
例子
用户问题：我想要分析首页推荐位视频的完播率
GPT返回如下图
GPT并没能很好的完成这个需求。按照ChatGPT的产品形态，可以不断的在对话框中继续提问， 补充足够的背景信息，好让GPT的生成不断逼近想要的答案。
但是这个思路或者交互放在工具类产品里面，多少显得有些“不智能”。在这个过程中，也尝试了不断去优化prompt好让GPT能够很好的生成计算完播率所需要的前因后果等，但效果 不是很理想。
核心原因是GPT对于前因后果的输入有限，因此生成的内容偏离较远。这也带出了在实际将GPT融入数据产品的过程中的一些预期：
一是希望减少类似ChatGPT那样的通过【对话】进行交互的方式，其原因是不稳定性会增多，数据工具类产品的设计多会与流程工具或者其他平台工具交互相关，会有意减少【用户人工介入】；
二是不希望融入后又过于【死板】，不能使得AI的加入仅仅是替带了部分后端工作，简单的将原本稳定输出的数据结构变为AI生成。
即不希望产品【太活跃】，但也不希望产品【不活跃】。仔细拆分我们的产品工作流可以看到，一个数据工具类产品的流程中，既包含了不活跃的【流程工具】或【限定工具】如数据结构构建等，也包含了很多活跃的【自定义工具】，如用户分析拖拽等；通过结合，以完成复杂诉求。从这个角度出发，GPT融入数据产品的过程也可以是【点状】的，【模块化】的。
基于这个思考，产品提出了一种解决方法，即并不把与GPT的交互当成单一的会话场景，不去追求在一次会话场景中完成太过于复杂的需求。将GPT做个单元，按照能力模块的方式来组成一套完整的【思维流】或者 【流程链条】。
befor
这个设计思路参考了包括 LongChain、Perfect_Prompt、Auto_GPT 等技术或产品的思考，核心的思路有3点：
1、将GPT看作独立生产主体，进行合理的工作分工以完成复杂任务
2、给到GPT足够的Prompt
3、让GPT自己给自己优化Prompt
在上述的例子中，我们设计了简单的一个工作流程：
实际结果相比之前的单独模块，效果好了很多：可以看到，面对【完播率】这样的复合指标，GPT进行了如下操作：
1、设计了is_full_play这样的参数来进行标注是否完播，可以完整的支持分析
（需求实际不包含，但是GPT进行了一定程度的发挥，这也是加入GPT的意义）
2、设计了video_id参数来支持视频维度拆分
3、设计了video_duration，可以进行播放比例分析
基本实现了上面所要求的，即没有【太活跃】，也没【不活跃】。我们通过添加一个监看窗，也可以观测一下需求分析模块的间接产出：
需求是{分析“首页频道页”推荐的视频的完播率}，需要采集用户在“首页频道页”推荐视频中的播放事件，并记录视频的完播情况。完播率可以定义为，完全观看视频的用户占总观看视频的用户的比例。具体计算方法为，用完全观看视频的用户数除以观看视频的总用户数。
更多的，根据《Prompt提示工程》中的例子，我们也可以给产品加上反馈机制，在每一次与GPT的交互中给到GPT 用户评价更高的例子，以获得更好的效果。
四、总结
综上，总结而言，本文实践了一种GPT融入数据工具类产品的可行思路，简单来讲就是将GPT作为最小生产主体，通过构建多个【生产主体】，组成生产团队，以提升GPT完成复杂任务的能力。
AI作为产品领域的【新推动力】，我作为数据产品策划也在入门、研究与实践，希望和大家一起讨论进步。
# 腾讯技术直播 #腾讯工程师分享技术干货：扫码预约，get开播提醒
【技术人说】科普对谈，技术没有那么难～
快快预约，鹅厂技术大咖在直播间等你💪
往期文章：
点个关注，下期再见👋
