我19年在蚂蚁的时候独立起了个项目，当然这个项目整体是个业务归因剖析的平台，但是在这里面我采取了一种新的数据剖析的用户交互办法，便是通过钉钉以IM进行问答式的剖析交互。大略说便是想看什么样的数据，以及剖析和归因都可以通过自然措辞的办法进行提问，然后会返回详细的结果。
给大家个示例：
数据机器人示例-就像这样支持用户进行自然措辞交互
在本日看起来是不是非常像AI大模型？如果那时候有大模型的加持肯定过会事半功倍，当时采取的方法是非常繁芜的，不过也有其优点便是能担保数据的准确性。
本日就来教大家如何构建问答式的数据机器人，以及两种办法各自的利害。
我之前的办法是采取：NLP分词+知识图谱的办法（在增强剖析领域，可以称为NLQ-Natural Language Query）。这个过程是通过NLP解析用户自然措辞的问题转换为SQL，然后通过SQL在对应的指标图谱中通过多维指标的数据关系进行指标汇总，末了返回给用户数据结果。
查询过程：用户自然措辞查询→NLP→SQL→查询指标图谱→数据聚合→图表和数据返回
这里面NLP实在核心是在做分词，把韶光、维度和指标名解析出来，由于在查询时是基于指标模型（韶光周期+润色词+原子指标）进行的，以是只要有查询的指标构培养可以做到。NLP解析出来后天生的SQL更多的是在做大略查询，假设用户要查询「今日杭州新注册用户数」的话，对付SQL来讲便是直接查询这个指标（select ‘杭州新注册用户数’ where day=‘本日日期’），但实在这个指标是通过知识图谱（指标图谱）的图关系把「今日」、「杭州」和「新注册用户数」这几个实体和关系的数据进行聚合。
以是繁芜关系的指标数据聚合实在是在知识图谱完成的，由于如果让NLP解析后直接天生繁芜SQL的话在那个时候技能并不成熟，当然对付本日的大模型来说天生繁芜的SQL措辞是小菜一碟。
去年也便是23年初大模型火热的时候我就在思考这个问题，如果通过大模型来实现是否可行，这取决于大模型的NLQ能力——对指标与剖析干系的自然措辞的理解以及转化为SQL的准确性。由于如果通过大模型的办法来实现的话，取代的是“NLP→SQL→查询指标图谱”这个流程环节，同时也就不须要构建繁芜的知识图谱了，只须要像数仓中间层正常构建多维的指标数据宽表就够了，由于派生指标的聚合实在是在大模型中天生的繁芜查询SQL。令人愉快的是，大模型的编程措辞能力比想象的更强。
一、利用大模型的办法
首先在大模型中设置提示词（Prompt）：声明数据表构造（表元数据信息）→声明查询办法→天生SQL
完全机器人交互查询过程：用户IM自然措辞查询→大模型NLQ→查询指标模型表→图表和数据返回
（这个过程和前面的比拟你会创造大模型取代了「NLP分词」、「SQL天生」和「知识图谱构建」这几个很繁芜的环节。）
由于我们全体数据指标核心还是依托指标模型（韶光周期+润色词+原子指标），以是在提示词声明表的元数据信息以及查询办法时可以把表相应的字段约束一下，比如——“韶光”是哪个字段，基于韶光聚合的话办法是若何的（韶光已经按照韶光周期标签化了，比如：近1天、近7天。还是字段存储的这天期，须要根据日期进行筛选后聚合），以及度量（原子指标）是哪个字段。
当然这些事情也可以不做，就相称于把准确性这个东西转嫁给了大模型，我测试过ChatGPT以及海内的大模型，我们只要把表的元数据信息——字段、字段类型、字段中文描述、分区以及分区存储类型（增量 or 存量），这些通过提示词声明好，我们在通过自然措辞查询的时候天生的SQL准确性很高（由于大模型会根据你的字段描述以及元数据信息去进行自动判断）。但是对付成熟产品交付来讲，我们通过这个约束的目的是减少缺点率。
不做提示词约束时大模型NLQ的实例：
比如这个便是我之前测试大模型NLQ时的一个实例，这个实例中我没有进行过多的提示就只是声明了一下表构造，大模型就能比较好的理解以及帮我天生SQL。
与海内某大模型的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）：描述数据的数据，比如像表的元数据信息便是指的表名称、路径、字段描述之类的干系信息，与表内存储的数据无关。本文涉及到的一些核心专业知识点：
指标模型的构建——文中指的是两方面：
①一方面是指标抽象的构成办法「韶光周期+润色词（维度）+原子指标」；
②另一方面是指的基于这种构成办法，数据表模型的构建。
专栏作家
戏说猫狗，"大众年夜众号：树荫下的猫猫狗狗，大家都是产品经理专栏作家。前BAT数据产品经理，专注于数字营销Martech与智能风控领域，从事企业数据中台、数据智能化转型与产品办理方案。
本文原创发布于大家都是产品经理，未经容许，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。