背景 在工作中接触/使用大模型已超过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
有如下例子可供参考：#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来源；点击“错”后，则应引导用户继续修改上述条件，或反馈条件是否正确，而这些反馈又可进一步补充语义。

来自thoughtspot 业务用户采用口语化方式提问时，常会出现近义词、同义词、缩写词和内部用语等情况。通过相似问题的修改与召回，可以提高这类问题的查询准确性；也可以收集相关词汇，将其纳入知识库。

感想

    虽然NL2SQL已成为AI Agent中的一个细分类型，SQL也是通用的数据查询语言，但数据平台仍可进一步细分指标平台、标签画像平台等场景。在各自工作流中，平台能够结合自身能力与上下文拆解任务，压缩大模型输出内容的空间。这或许是平台产品融合AI能力的另一条路径，而不一定要持续比拼模型能力。