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

在AI浪潮下，大语言模型凭借SQL解释能力，打破了自然语言到SQL的壁垒，给“智能查数”这个曾经难以落地的场景带来了无限想象空间。各大企业纷纷布局AI数据赋能，希望快速提升决策效率。然而，通用化的NLP2SQL（自然语言转SQL）看似能解决所有问题——业务人员只需说句话，强大的LLM就能给出准确信息，无需任何SQL基础就能发现数据问题。

“智能查数”要面对的，远不止LLM理解语言并翻译成SQL这么简单。用户的自然语言里藏着复杂的指标意图、公司内部术语，结果有时是简单查询，有时却需要LLM生成一份完整的分析报告。从技术视角看，用户一句话背后需要经历意图识别、相关表信息召回、LLM生成SQL、统一数据服务获取结果，最后还得根据用户意图判断是原样返回还是结合背景做二次加工。这中间的挑战可不小。

说到底，这些问题的本质是

，而非单纯的AI问题。员工平时遇到的“找不到数据”、“取不出数据”，Agent一样会遇到。

背景

LLM能理解自然语言并生成SQL，看似打通了天堑，但现实远比想象复杂。用户的语言中既有明确的指标诉求，也有模糊的行业黑话，系统需要先判断“是想查个数，还是想让我分析一下”，然后才能决定走哪条技术路径。这不是LLM一个人能扛的事，背后是完整的数据工程链路。

ChatBI行业思路

ChatBI（基于聊天的商业智能工具），核心就是让用户用自然语言跟数据对话，轻松完成查询。行业内已经涌现出不少方案，各路专家都在琢磨怎么把AI查数做好。

1、NLP→x→SQL：两个主流方向

自然语言生成SQL，目前讨论最多的是

和。

：大模型直接把自然语言问题转成SQL语句，数据库执行后返回结果。但缺点也很明显：

• 生成准确可执行的SQL很难，大模型必须深入理解SQL语法、数据库模式和各表关系，还要依赖Prompt里对表名、字段、关系的清晰描述。
• 复杂业务查询（比如多表JOIN）需要模型有强大的语义理解和逻辑推理能力。
• 企业级宽表可能有上百个字段，输入输出复杂度直接影响响应时间——超过3秒用户就跑了。

：先把自然语言转成领域特定语言（DSL），比如BI领域里的指标、维度、过滤条件这类报表配置参数，然后再转成SQL执行。本质上是一个“text → DSL → SQL”的过程。DSL是对SQL的一层抽象，SQL是对数据输出的具体执行。

Text2DSL方案同样有挑战：它需要依赖成熟的指标体系，查询的灵活性和扩展性受限于已有指标和维度，本质上更像“报表参数智能检索+自动化数据查询”。但优点是比Text2SQL更容易实现，在指标体系能满足大多数需求的情况下，准确率和时效性都更好。

最近还出现了一个新概念：

（MQL：Metrics Query Language）。通过指标平台做语义层标准化，把指标逻辑预定义好，从根本上解决口径冲突问题。指标平台用“基础度量”为核心，结合“业务限定”“时间限定”“衍生方式”灵活组合定义指标，在语义层统一管理发布。

数仓如何规范指标定义，可以参考下图：

2、知识库增强

NLP2SQL要转得好，离不开

的输入。通过向量数据库或MCP server，可以给NLP2SQL这一步做很好的信息补充。

知识库类型	内容示例	增强目标
结构化元数据知识库	数据库DDL（表结构、字段类型、主外键关系）、数据血缘、字段注释	解决“技术歧义”（如字段同名异义、计算逻辑）
业务语义知识库	指标定义（如“GMV=成交金额-退款”）、业务术语词典（如“活跃用户”定义）、维度层级（如“省-市-区”）	解决“业务歧义”（如用户口语化表达与术语差异）
上下文知识库	历史对话记录、用户权限范围、常用查询模式	解决“个性化需求”（如用户偏好、数据权限）

具体流程如下：

3、统一数据服务

在ChatBI场景下，统一数据查询引擎是连接NLP2SQL与异构数据源的“中枢神经系统”。它的核心价值是屏蔽底层技术差异，让生成的SQL能自动适配多种数据源并高效执行。

异构数据源类型	传统方案痛点	统一引擎解决方案
关系型数据库	需手动适配不同SQL方言（MySQL vs PostgreSQL）	自动重写SQL方言（如将LIMIT转为FETCH FIRST）
OLAP引擎	需手动优化聚合语法（ClickHouse vs Doris）	智能转换聚合函数（如GROUP_CONCAT → array_agg）
NoSQL数据库	需自定义查询逻辑（MongoDB的Aggregation Pipeline）	将SQL翻译为原生查询语言（如SQL → MongoDB Pipeline）
API/REST数据源	需手工编写HTTP请求+解析JSON	自动生成REST API调用，解析返回结构
数据湖	需切换Spark/Presto等引擎	—

具体流程如下：

4、指标服务

指标体系可以规范公司指标口径及输出，统一数据，减少重复计算，节省资源，方便业务自助分析。核心思路是把

从NLP生成SQL的环节中剥离出来，交给专门的指标服务平台（MCP）处理。

特性	传统NLP2SQL方案	NLP2指标服务 + MCP方案	优势说明
NLP核心任务	生成完整、复杂的SQL语句	识别指标、维度、筛选条件，映射到标准接口	大幅降低NLP生成难度，提升准确率
业务逻辑处理	嵌入在生成的SQL中，分散且易变	集中在MCP中统一管理、版本控制	保障指标一致性，简化变更管理
扩展性	新指标/逻辑需重新训练NLP模型	新指标只需在MCP定义，NLP只需识别新名称	更快响应业务需求，提升敏捷性
安全性	主要依赖数据库权限控制，粒度较粗	指标级、维度级细粒度权限控制，支持脱敏	更精细、更安全的数据访问控制
开发维护	NLP需懂业务逻辑，维护成本高	NLP与指标开发解耦，职责清晰，维护成本低	提升开发效率，降低长期维护负担
一致性	易因不同SQL写法导致结果不一致	MCP是单一事实来源，确保全企业指标一致	提升数据可信度和决策质量
可复用性	生成的SQL通常仅用于当前查询	指标服务可被多种应用（BI, API, 报表）复用	最大化数据资产价值，避免重复建设
适用场景	简单查询、探索性分析、指标体系不成熟	成熟指标体系、核心业务指标、高频查询	更适合企业级、生产环境ChatBI应用

在ChatBI领域，NLP2指标服务 + MCP的方案，对于那些拥有

的企业级应用来说，优势明显。它把NLP与复杂业务逻辑解耦，让NLP专注语言理解，整体提升了系统的可靠性、效率、安全性和用户体验。

5、代码查数

火山引擎的Data Agent让人眼前一亮。获取指标结果后，很多场景需要

。以前这些逻辑得人写代码，现在可以交给LLM，借助代码执行器的编写能力和自我纠错能力，对结果进行二次增强。

当然，这些思路目前都基于workflow，本质上是Agentic Workflow里的Planning Pattern：意图拆解→工具执行→结果输出。再往后演进，如果能自我反思和修正结果，AI的数据思考会深入很多。

运营背景

想实现

的ChatBI，需要业产研团队协同挖掘真实业务，打磨一系列小而美的AI工具，最终凝聚成大而全的能力。

我们团队深入运营同事的日常工作，发现运营岗位有大量策略扫描上线的场景。这些场景都有清晰的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引擎可以通过创建索引、物化视图、设置查询缓存等方式提高效率。

应用该做什么？

应用侧需维护

，根据不同的运营场景，提供，对用户语义做。在数仓只提供明细层或原子指标数据的基础上，应用后端需要对。

业务能说什么？

对业务来说，用最少的语言达到预期效果就是目标。业务侧包含两类信息：

• 业务领域知识
  ：运营内部语言，包括自定义指标和行业术语，以及运营策略规则（比如满足a→b范围配置1策略）。

• 真实问答
  ：比如“帮我扫描近7天，符合我预设策略的数据，给我一份策略方案，需要带上扫描过程。”

第一类信息可以在对话前预设进系统，第二类信息就是用户直接提出的问题。即使是一个用户意图，也需要区分

。

延伸扩展性

指标体系

在AI时代，指标体系需要从

，成为企业智能化决策的“神经中枢”。核心目标是用AI技术重构指标的定义、计算、应用和迭代全流程。传统指标体系的很多环节都可以升级。

演进方向	传统方案	AI方案
动态指标生成	固定指标，人工定义调整，响应滞后	AI自动识别数据模式，动态生成异常检测、趋势预测等指标
智能指标推荐	依赖专家经验或固定报表，效率低	基于行为和历史分析，推荐高价值关联指标
实时指标计算	批处理T+1或简单流式处理	AI优化实时计算路径，如弹性资源分配
指标异常检测	静态阈值或规则（如3σ）	AI识别时序波动、多指标联动异常
自动化根因分析	人工排查，耗时依赖经验	基于异常自动定位根本原因
指标可解释性增强	简单图表+文字描述	AI生成自然语言解释（如“下降因天气影响”）
预测性指标	仅历史统计，无预测	升级为预测性指标（如未来7天流失率）
个性化指标服务	统一报表，用户自行筛选	为不同角色提供定制化视图与洞察
指标数据质量治理	人工规则校验，覆盖有限	AI自动检测数据漂移、缺失、一致性问题并修复
指标知识沉淀	文档管理，关键词匹配	构建语义搜索的知识库

所以，AI时代下指标体系可以完成几个关键转变：

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

通用化推广

目前这个运营场景如果要想横向扩展到其他场景，只需要做好三件事：

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

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