在工作中接触/使用大模型已经超过1年了，大部分是做分析/BI相关的场景。过去半年做指标平台+大模型应用项目，最终也有客户实际落地，梳理下自己的一些总结。 首先要说明的是，项目的结果是以产品形式交付给企业客户，那么往往就会遇到诸如私有化/本地化/国产化的限制，就要求我们的方案需要足够的健壮，且在较小的模型下也有稳定的表现。 其次，我们需要明确这类产品的目标用户是谁，如果将其视为一个NL2SQL的项目，那么只能面向分析师交付，最终实际上是起到code copilot类似的效果，其在商业化上的空间也比较有限。结合指标平台本身的定位（统一口径+分析能力的输出），真正面向的应该是管理者/业务人员等终端的用数角色。因此这在查询/推理速度、结果可见性、交互表达上就比NL2SQL多了很多要求。 接下去，我们将通过具体流程的说明看下跟一般NL2SQL项目的差异。相关参考
指标+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
有如下例子可供参考：{history question}{history answer sql}...
请通过编写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能力的另一种方式，而非一定去卷模型能力。
粤ICP备14082021号
免费POC，
零成本试错
