如何用AI大模型重塑数据机器人

我19年在蚂蚁的时候独立起了个项目，当然这个项目整体是个业务归因分析的平台，但是在这里面我采用了一种新的数据分析的用户交互方式，就是通过钉钉以IM进行问答式的分析交互。简单说就是想看什么样的数据，以及分析和归因都可以通过自然语言的方式进行提问，然后会返回具体的结果。

给大家个示例：

与国内某大模型的NLQ对话截图

这个用户明细表如果变成指标模型的多维表的话，表结构如下：

日期 | 注册渠道 | 注册终端 | 注册用户数（度量）

即使是变成这样的指标模型表结构的话数据形式也是有多样的，比如：

第①种：
近1天 | 微信 | App | 1000
近7天 | 微信 | App | 26000

第②种：
20240910 | 微信 | App | 1000
…
20240904 | 微信 | App | 6000

像上面我列出的这两种数据格式对于指标查询的处理就会有区别：

–第①种
select 注册用户数 where 日期=‘近7天’
–第②种
select sum(注册用户数) where 日期 between ‘20240904’ and ‘20240910’

当然上面这两种数据结构的前置数据处理逻辑也有区别，所以会有不同。我这里给大家举这个简单的例子是想说明，不同公司对指标数据的处理逻辑是不同的，要根据实际逻辑去看应该用什么样的查询方式，然后在提示词中进行声明和约束，否则就会导致数据口径出错的问题。

二、两种方式的优、劣对比

对于后一种利用大模型的方式进行构建（我们称为v2，前者是v1），很明显的要简单很多，容易实现，甚至说不需要太多的技术含量。但是这里面总会暗含着不确定性，也就是大模型在NLQ的过程中会不会搞些幺蛾子，这个在我们使用大模型的时候就很有体会，猛不丁的给你造个出人意料的东西出来（比如在这里就是出人意料的SQL查询逻辑）。

毕竟用户看的是数据结果，中间是黑盒，有时候结果很难察觉是否除了问题。所以就像总有一个苍蝇在你嘴边飞，不知道哪天就被吃进去了…所以就只能尽可能多的约束，但是约束是约束不了生成诡异的SQL代码逻辑的。

但是对于前一种方式（v1）来说，出错会意味着查询失败，但不会有“惊喜”！因为这里面主要可能出错的是在NLP分词的环节，分词分不好最多是维度、指标的错误和缺失之类的，把这些分词结果加到SQL中进行查询最多就是没有数据结果，而不会“一本正经的胡说八道”。

所以说v1版本的：

优势是——可以确保查询出的数据的准确性。

缺点是——构建复杂，会有很大的技术壁垒，比如知识图谱。

所以研发用时会很久，对于一般效率的研发来讲至少要4-6个月的时间才能有产品的mvp。

v2版本的：

优势是——可以很快速的把产品研发上线，甚至mvp版本2周应该就差不多。

缺点是——你要容忍暂时无法解决的“惊喜”，问题是这种惊喜还不容易发现和监控，甚至不容易察觉。

有的时候如果你的数据产品数据准确性像中奖一样且无法解决，对于需要可靠性的场景就直接被pass。但是从另一个角度来说，有很多对数据准确性没有那么严格，但是对取数效率比较重视的场景就是一个很好的产品。并且其实可以通过多次的查询以及经验去做简单的验证和判断。

毕竟对于这么炫酷好用的东西，很多老板可以暂时容忍一些小缺点的是吧！

以下是一些补充信息

本文中涉及到的一些专业名词解释：

• NLP：自然语言处理，一般通过算法模型进行语句的分词、内容分析、情绪分析等。
• 增强分析：通过机器学习和AI的方式降低数据分析成本以及自动化的分析挖掘
• NLQ：自然语言查询，通过自然语言的方式转换为查询语言，比如SQL等。
• 提示词（Prompt）：通过提示词帮助大模型理解用户的意图，要做什么事情。
• 元数据（Meta）：描述数据的数据，比如像表的元数据信息就是指的表名称、路径、字段描述之类的相关信息，与表内存储的数据无关。

本文涉及到的一些核心专业知识点：

指标模型的构建——文中指的是两方面：

①一方面是指标抽象的构成方式「时间周期+修饰词（维度）+原子指标」；

②另一方面是指的基于这种构成方式，数据表模型的构建。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！