微信扫码
与创始人交个朋友
相关参考
指标+LLM的结合的路径已有比较多的讨论,尤其围绕dbt的生态,认为通过dbt中metric的语义说明可以减少歧义,有一些相关的参考及项目比如:
1. https://www.getdbt.com/blog/semantic-layer-as-the-data-interface-for-llms
2. https://github.com/dbt-labs/dbot
此外,常见的提升生成查询准确性的方法就是通过RAG召回标注问答,给大模型提供fewshot“仿写”的补充。类似的项目比如:
1. https://vanna.ai/docs/
不过以上这些方案,都只将数据模型和指标语义部分当做知识输入,最终还是输出sql查询,跟接下去描述的运用指标层的方式有一点差异。
具体说明
整体来说我们自然语言分析的过程如下,接下去将对有差异的一些点展开说明
意图识别
对于用户输入的问题,第一步是让大模型进行意图区分是分析问题还是普通的对话。由于指标回答即使出错,也可以通过兜底SQL编写,因此分析类查询问题可以尽量优先进入指标分支。
指标匹配
区分于常规的NL2SQL的查询,在查询prompt之前,我们需要明确用户问题与哪个/哪些指标有关,这里有以下手段可以参考:1.通过问题内容从指标元数据中进行召回(包括指标名称、指标业务描述、维度采样;2.通过传统NLP手段利用关键词召回指标;3.基于1,2召回的部分指标,再由大模型进行最终判断该问题与哪个/哪些指标相关。
在企业级客户的指标量级之下,直接通过大模型在全量指标中进行识别会导致响应慢、占用过多token的问题,因此这里加了1,2两步前置操作。
查询prompt
比如最简单的NL2SQL的prompt可能是这样的
##示意
你是一个分析师blahblah
现有schema如下:
{table_name}
|column|type|sampling_data|
现有指标以及其sql表达式如下:
xxx
有如下例子可供参考:
#1
{history question}
{history answer sql}
#2
...
请通过编写sql回答用户的问题:
{user’s question}
其中元数据、字段采样数据和历史问答的召回部分是可以通用的,而采用指标查询的方式其模版如下:
#示意
你是一个分析师blahblah
系统中对指标有三种查询策略
(以下表达式仅做示意区分于sql编写)
1.多维分析
对指标进行多维分析,支持添加过滤条件等
metric.analyis('metric_name').filter_by('expressions').group_by('dimensions')
2.指标归因
对指标在指定时间段内的波动进行多维下钻归因
metric.rootcause('metric_name').duration('time1','time2').filter_by('expressions').drill_by('dimesnions')
3.指标预测
对指标未来时间段内的趋势进行预测
metric.predict('metric_name').duration('time1','time2').filter_by('expressions').drilldown('dimesnions')
现有指标如下:
{metric name}
{metric describe}
|dimension|type|sampling_data|
...
有如下例子可供参考:
1
{history question}
{history answer query}
2
...
清通过编写查询表达式回答用户的问题:
{user’s question}
对比常规2SQL的方案,通过指标编写的优势如下:
1. 指标作为一个对象,在代码执行时会根据其定义进行查询,不需要大模型翻译其过滤条件、表达式,这样可以减少出错的机会(尤其是指标定义或过滤条件很复杂,或者涉及复合指标的定义时)。
2. 对采样数据来说,具体到某个指标会更准确。在sql方案中,只能对表的字段进行采样;而在指标方案中,每个指标的每个维度上都有采样结果。例如:“化妆品销量”的skuid列表和“服装销量”的skuid列表肯定不同,当用户直接提问“sku12345的销售额是多少”时,该ID出现在“化妆品销量”的skuid采样中,而可能不在全表的skuid列表采样中(一般会对采样数量限制),因此这种直接指定维值/字段值的问题通过指标采样被召回的可能性会更高。
3. 可以将业务常用的指标归因、指标预测等分析模型标准化,这样可以直接调用,这是通过sql查询不大容易做到或特别不稳定的点。
4. 对比sql,在结果展示时,更容易翻译为用户可读、可操作的条件要素
但同样通过指标方案有一些劣势如下:
1. 依赖指标语义的表达能力,不如sql开放,比如一些嵌套查询、多指标交叉查询、非指标的灵活查询等不一定支持
2. 编写指标查询表达式语法,是大模型需要学习的新知识,容易写错。这里可以通过finetune或者提供足够多的fewshot提升其准确度
回答解读
不论上一步是sql查询还是指标表达式的查询,在解读中,都可以从企业自身的业务数据库中召回相关的内容,对回答进行一定的描述性分析。
结果展示
为了形成数据闭环,在生成查询结果后,应支持用户对条件进行检查并提供反馈。例如:
可以看出其展示了指标分析的时间范围、过滤条件和维度,同时提供对、错的反馈。理想的情况下,在用户点“对”后,应记录为历史问答作为fewshot的来源;而用户点“错”后,应引导用户进一步修改上述的条件,或提供条件正确与否的反馈,这种反馈进一步可以作为语义的补充。
感想
虽然NL2SQL已经是AI Agent中一个细分类型,且SQL又是数据查询的通用语言,但数据平台可以进一步拆分场景,例如指标平台、标签画像平台等,在各自的工作流中,可以结合平台能力和上下文拆分任务,缩小大模型输出内容的空间,这可能是平台产品结合AI能力的另一种方式,而非一定去卷模型能力。
53AI,大模型落地应用首选服务商
定位:开箱即用的大模型落地应用平台
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
如果你看见AI对商业世界的变革,欢迎来和我们一起探索~
2024-07-03
让企业为大模型买单,目前有四大难
2024-07-03
Laplace AI Lab打破了传统SaaS和RPA框架的局限,解决了功能繁杂、操作复杂
2024-07-03
演讲实录|如何以 AI+指标平台构建企业数智竞争力
2024-07-03
演讲实录丨智能一站式指标平台在头部企业的实践分享
2024-07-03
“指标平台”掀起数智风暴:AI 对话已达 95% 准确率、100% 可解释!
2024-07-03
不是“尝鲜”,餐饮巨头市场团队已用指标平台+AI 更高效理解业务和决策
2024-07-03
GenAI大模型成熟度模型 - Google
2024-07-02
从企业内部的聊天记录中构建一个知识库式的检索增强生成 (RAG) 应用
2024-03-11
2024-04-02
2024-03-11
2024-04-24
2024-04-01
2024-04-18
2024-04-06
2024-04-08
2024-05-15
2024-04-03
2024-07-01
2024-06-29
2024-06-28
2024-06-24
2024-06-21
2024-06-20
2024-06-20
2024-06-19