AI赋能运营实战：指标扫描自动运营

在AI浪潮下，LLM（大语言模型） 凭借其SQL解释能力，能够打通自然语言到SQL的壁垒，给 "智能查数" 这个之前无法触碰的场景，提供了无限想象的可能。能够看出，各大企业会尝试布局AI数据赋能，快速提高企业决策效率。

通用化NLP2SQL（“自然语言转 SQL”）似乎可以解决所有问题，依托强大的LLM，业务人员即可轻松获得准确的信息，在没有SQL基础条件下，快速发现数据问题。

实际上呢？

“智能查数”面对的问题，不只是LLM理解语言且翻译SQL这么简单。用户语言包含复杂的指标意图，也包含特定的公司内部术语，其所需要的结果有时是指标结果查询，有时需要LLM给出分析报告，问题就会变复杂了。

这中间的挑战还是不小的。

这些问题的本质，是数据工程问题，而非单纯的AI问题。 员工在工作中遇到的数据“找不到”和“取不出”的问题，Agent 一样会遇到。

ChatBI（基于聊天界面的商业智能工具），主要支持用户通过自然语言与数据进行交互，从而轻松完成业务数据查询。

ChatBI行业已经有很多种方案，各路大神在如何做好AI查数，思考了很多办法。

1、NLP->x->SQL

自然语言生成SQL，行业内讨论最多的两种方案是“Text2SQL”和“Text2DSL”。

Text2SQL（Text-to-SQL）可以简单理解为，通过大模型将自然语言问题转换为结构化查询语言（ SQL ） ，使数据库能够理解并返回数据查询结果。

缺点比较明显：

• • 生成SQL的准确性与可执行性：生成准确且可执行的SQL查询是一项重大挑战，需要大模型深入理解SQL语法、数据库模式和特定方言，同时依赖于Prompt中对表名、表字段以及各个表之间关系的清晰描述。
• • 特定业务的复杂查询：例如跨表或跨数据集查询。对于特定业务场景的数据分析可能涉及多表关联（JOIN），这要求模型具备强大的语义理解和逻辑推理能力。
• • 性能问题：在企业级数据查询中，宽表可能包含上百个字段，输入Prompt和输出SQL语句的复杂度会影响大模型的响应时间。超过3秒的响应时间会严重影响用户体验，导致用户流失。

Text2DSL（Text-to-DSL）技术是将自然语言转换为领域特定语言（DSL）。“领域特定语言”听起来有点抽象，但可以理解为是一种更易于用户理解和使用的语言，例如在BI领域，它指的是从底层数据集中抽象出的指标、维度和过滤条件等报表配置化参数。

Text2DSL本质上是一个text to DSL to SQL的过程。简而言之，DSL是对于SQL的一层抽象，而SQL是对于数据输出的具体执行。

Text2DSL方案同样面临挑战：基于Text2DSL搭建的ChatBI需要依赖成熟的指标体系，而且查询的灵活性和扩展性受限于现有指标和维度，本质上是报表搭建参数智能检索召回后的自动化数据查询流程。

但相比于Text2SQL，Text2DSL更易于实现，并且在指标体系能够满足大多数用户需求的情况下，能提供更准确、时效性更强的结果。

NL2MQL2SQL（MQL：Metrics Query Language） 方案是近期出现的新概念。指标平台的NL2Semantic2SQL 路线通过语义层标准化沉淀指标逻辑，从根本上解决了口径冲突问题。指标平台通过预定义的“基础度量”作为核心，并结合可选的“业务限定”、“时间限定”以及“衍生方式”等要素来灵活组合定义指标，并在语义层中强制统一管理和发布。

数仓如何规范指标定义示意图如下：

2、知识库增强

NLP2SQL，是为了将自然语言，更好的转化为SQL，这离不开数据库 DDL 以及业务数据知识库的输入。通过向量数据库或者数据库表MCP server，可以很好的对NLP2SQL这一步进行信息补充。

具体流程如下：

3、统一数据服务

在ChatBI场景下，统一数据查询引擎是连接NLP2SQL与异构数据源的“中枢神经系统” ，其核心价值在于屏蔽底层技术差异，提供一致的数据访问能力，让生成的SQL能自动适配多种数据源并高效执行。以下是深度解析：

具体流程如下：

4、指标服务

指标体系可以规范公司指标口径及指标输出，统一公司指标数据，同时减少同一指标多次计算的重复场景，减少计算及存储资源的消耗，方便业务方自助分析及报表搭建，提升工作效率。

这种方案的核心思想是将复杂的、易变的、 业务 逻辑密集的指标计算从NLP生成SQL的环节中剥离出来，交由专门的、标准化的指标服务平台（MCP）处理。

在ChatBI领域，NLP2指标服务 + MCP 的方案选型，对于拥有相对成熟 指标体系 、追求高准确率、高性能、强一致性和良好可维护性的企业级应用，具有压倒性的优势。它通过解耦NLP与复杂业务逻辑，将核心挑战（指标计算）交给专业平台（MCP）解决，使NLP能更专注于其擅长的语言理解任务，从而整体提升ChatBI系统的可靠性、效率、安全性和用户体验。

5、代码查数

看完火山引擎的Data Agent，着实让人眼前一亮。获取数据指标结果后，很多场景需要二次加工结果数据，将以前需要人写的逻辑转化为具体python代码，依托目前代码执行器的编写代码能力和自我纠错能力，可以很好的对结果进行二次增强。

当然，这些思路都是基于workflow，我们的思维还是基于Agentic Workflow：Planning Pattern，整体流程是意图拆解->工具执行->结果的模式。

再往后演进的话，能够自我反思和修正结果，AI进行的数据思考会更加深入。

想实现满足所有业务场景的ChatBI，需要业产研团队协同挖掘真实业务，打磨好一系列小而美的AI工具，最终凝聚形成大而全的ChatBI能力。

我们团队深入到运营同事日常工作中，发现运营岗位存在大量策略扫描上线的工作场景，这类场景具有清晰的SOP，可概括为运营同事需要扫描一系列固定的指标数据（可能需要修改维度枚举），并结合量化的策略规则（可能会改变）分析数据，生成输出具有固定模板的运营策略结果，最后在各运营平台完成策略配置与上线。

优质的真实场景激发了我们推出运营自动化助手的灵感。我们希望通过问答和聊天的方式，使运营同事能够高效闭环策略扫描和上线的工作。例如：扫描所有城市xxx车型的A指标， 满足[a, b)范围的，执行1号策略；满足[b, c）范围的，执行2号策略，将符合以上规则的城市车型配置到xx平台。

我将流程拆解为如下的workflow:

实际dify workflow如下：

路由prompt

用户意图还是需要LLM进行识别，这一步主要是识别指标、维度、筛选条件

司机的汽车类型名称枚举值为：A、B、C、D等。
业务大区的枚举值为：A、B、C、D等。
请根据用户输入问题，精准匹配以上枚举，抽取出对应的司机汽车类型，业务大区参数。

##要求
如包含多个大区值，用,将值隔开。
如包含多个司机汽车类型，拆分成多个元素存入列表
未明确说明司机汽车类型时，默认为全部的枚举值

可以看出，意图识别主要分两块内容：第一部分是提供LLM运营预设知识；第二部分是告诉LLM输出数据格式和兜底逻辑。

问题拆分prompt

意图路由后，会分拆不同执行单元。为了保证执行成功率，确定性的流程下，采用固定的数据加工流程。

效果

数据该做什么？

数据侧首先考虑的是应该提供什么粒度的结果数据，针对不同的NLP->x->SQL方案提供的数据粒度是不一样的。目前主流提供的是明细层宽表或者细粒度的原子指标表，同时为避免过度复杂的SQL模板+大模型幻觉导致的准确率问题，通常最后生成的结果表只有一张表，并且相关指标打横方便生成衍生指标或派生指标。

在元数据方面，为方便大模型理解还需要提供字段对应数据含义，如字段对应的修饰词、维度和指标。若是提供多张结果表，还需要给出相应的表含义，甚至提供元数据以支持表路由方式。

由于大模型应用通常基于对话，数据工程同时要考虑查询性能不能太慢。常用的OLAP引擎都可以通过创建索引、物化视图、设置查询缓存等方式提高查询效率。

应用该做什么？

应用侧需维护运营知识库，根据不同运营场景，提供一套workflow，对用户语义进行意图识别且指定执行计划。在数仓只需提供明细层数据或原子指标数据的基础上，应用后端需要对数据进行二次加工。

业务能说什么？

对于业务来说，最少的语言达到预期的效果就是他们想要的，业务侧包含两类信息

• • 业务领域知识：运营内部语言，包含自定义指标和自定义行业术语，符合扫描标准的数据输出后，运营有一套自己的运营策略
• • 行业术语：比如特殊车型、关键车型等
• • 运营规则：比如满足a->b范围内，需要配置1策略
• • 真实问答： 帮我扫描近7天， 符合我预设策略的数据，给我一份策略方案，需要带上扫描过程。

第一类信息可以在对话前预设入系统，第二类信息就是真实问答提出的问题了。如下图，就比较清晰了，即使是一个用户意图，也需要区分预设知识和实际问答。

指标体系

在AI时代，指标体系的演进需从静态、人工定义转向动态、智能驱动，成为企业智能化决策的“神经中枢”。其核心目标是通过AI技术重构指标的定义、计算、应用和迭代全流程。AI时代可能对于传统数据指标体系流程，在以下方向可以进一步升级。

所以，AI时代下，指标体系可以进行进一步升级：

1. 1. 被动→主动：传统方案依赖人工规则，AI驱动自动化与智能化。
2. 2. 静态→动态：从固定指标和阈值升级为实时自适应调整。
3. 3. 解释弱→解释强：AI提供自然语言归因，降低理解成本。
4. 4. 历史→预测：从描述性分析扩展到预测性和决策支持。

这种演进使得指标体系从"业务镜子"进化为"业务大脑"，实现从监测到决策的质变。

通用化推广

目前整个运营场景落地，如果想横向扩展到其他场景，只需要做好以下几件事情

• • 拆解运营工作流程，沉淀到workflow
• • 结构化运营的预设知识，通过知识库或者代码执行等方式预设到prompt，更方便理解运营语言
• • 拆解出运营需要的指标，在指标服务还没有很健全的情况下，开发明细层数据，尽可能在单表检索到所需结果，减少查询复杂度

但这仅仅是开始，workflow只是过渡阶段，后续应该是Agentic模式，能够自主决策、选择工具并采取行动，无需人工干预。只是目前来看，relfection pattern还没有可见的解决方案，这个方案可以很稳定的并且通用解决具体的业务问题，保持期待吧。