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

背景

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

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

实际上呢？

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

从技术侧视角，用户问一句话，需要经过意图识别，然后对涉及的表进行相关信息召回 ，通过LLM生成SQL后，转换到统一的 数据服务 进行结果获取，最后区分用户意图，判断原始结果返回或者结合其他领域背景进行二次报告加工。

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

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

ChatBI行业思路

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这一步进行信息补充。

知识库类型	内容示例	增强目标
结构化元数据知识库	数据库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与复杂业务逻辑，将核心挑战（指标计算）交给专业平台（MCP）解决，使NLP能更专注于其擅长的语言理解任务，从而整体提升ChatBI系统的可靠性、效率、安全性和用户体验。

5、代码查数

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

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

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

参考文章： weaviate.io/blog/what-a...

运营背景

想实现满足所有 业务 场景的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的技术方案
动态指标生成	固定指标，需人工定义和调整，响应滞后	通过AI自动识别数据模式，动态生成业务指标（如异常检测指标、趋势预测指标）
智能指标推荐	依赖专家经验或固定报表，新指标发现效率低	基于用户行为和历史分析，推荐高价值指标（如关联指标、衍生指标）
实时指标计算	批处理T+1计算，或简单流式处理（固定窗口）	利用AI优化实时计算路径（如流数据处理中的弹性资源分配）
指标异常检测	基于静态阈值或规则（如"超过3σ即告警"）	替代传统阈值告警，通过AI识别指标异常模式（如时序波动、多指标联动异常）
自动化根因分析	人工排查日志和数据链路，耗时且依赖经验	基于指标异常，自动定位根本原因（如业务、基础设施、数据链路问题）
指标可解释性增强	简单图表+文字描述，归因分析需手动验证	通过AI生成指标变化的自然语言解释（如"销售额下降因天气影响"）
预测性指标	仅历史统计（如同比、环比），无预测能力	将传统滞后指标升级为预测性指标（如未来7天流失率、库存需求预测）
个性化指标服务	统一报表，用户需自行筛选和解读	为不同角色（运营、高管）提供定制化指标视图与洞察
指标数据质量治理	人工规则校验（如非空、唯一性），覆盖有限	AI自动检测数据漂移、缺失、一致性等问题，并修复指标计算逻辑
指标知识沉淀	文档管理，搜索依赖关键词匹配	构建企业级指标知识库，支持语义搜索（如"找与用户留存相关的指标"）

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

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

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

通用化推广

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

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

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

产研团队：李鸣、陆欢典、杨舒林、包恒彬

笔者介绍：李鸣｜大数据专家。曾任职于腾讯，从事地图渲染SDK研发、智能网联云平台后端开发，现就职于货拉拉，搭建了基于供需关系的调价平台、异动监测系统、GPT基础能力建设等项目，目前专注于大数据应用赋能。