相关参考

    指标+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查询还是指标表达式的查询，在解读中，都可以从企业自身的业务数据库中召回相关的内容，对回答进行一定的描述性分析。

结果展示

    为了形成数据闭环，在生成查询结果后，应支持用户对条件进行检查并提供反馈。例如:

来自thoughtspot

    可以看出其展示了指标分析的时间范围、过滤条件和维度，同时提供对、错的反馈。理想的情况下，在用户点“对”后，应记录为历史问答作为fewshot的来源；而用户点“错”后，应引导用户进一步修改上述的条件，或提供条件正确与否的反馈，这种反馈进一步可以作为语义的补充。

感想

    虽然NL2SQL已经是AI Agent中一个细分类型，且SQL又是数据查询的通用语言，但数据平台可以进一步拆分场景，例如指标平台、标签画像平台等，在各自的工作流中，可以结合平台能力和上下文拆分任务，缩小大模型输出内容的空间，这可能是平台产品结合AI能力的另一种方式，而非一定去卷模型能力。