企业落地篇 · AI 数据系统课

AI 数据分析助手

AI 数据分析助手让业务人员用自然语言提出问题，再由系统识别指标、维度、时间和筛选条件，查指标字典和权限，生成安全查询，解释结果和异常。它的目标不是让模型随手写 SQL，而是让数据分析更可控、更可追溯。

先懂业务问题 识别用户想看什么指标、按什么维度拆、比较哪个时间段。

口径不能自创 GMV、销售额、退款率、转化率必须来自企业指标字典。

查询必须受控 只读权限、白名单数据集、行数限制、SQL 审查和审计日志。

结果要能解释 不只给数字，还要说明口径、时间范围、来源、异常和不确定性。

data-analysis-agent question / metric / insight

业务问题 “华东区上周 GMV 为什么下降？帮我按渠道和品类拆一下。”

AI 解析 指标：GMV；区域：华东；时间：上周；分析：环比、渠道、品类、退款。

流量

-8.4%

转化

-5.1%

客单价

-2.8%

退款

+6.7%

Metric
指标口径

ACL
权限校验

SQL
安全查询

Insight
原因解释

01 · 先给定义

AI 数据分析助手，是把业务问题转成可信数据答案的系统

它不是一个“会写 SQL 的聊天框”，而是一套有指标口径、数据权限、安全校验和结果解释的分析工作流。

低质量理解

自然语言转 SQL

用户问一句，模型直接写 SQL 执行。风险是口径错、权限错、SQL 危险、结果没人能解释。

企业级理解

自然语言转可信分析

先解析问题，再匹配指标字典和数据集，校验权限，生成受控查询，执行后解释结果、异常、来源和限制。

一句话面试版 可直接背

AI 数据分析助手通过自然语言理解用户的数据问题，识别指标、维度、时间和筛选条件，再从指标字典和语义层获取标准口径，经过权限和 SQL 安全校验后查询数据，最后输出结论、原因拆解、口径说明、数据来源和不确定性。

02 · 业务痛点

业务想快速查数，数据团队怕口径乱、权限乱、解释乱

数据分析助手要同时服务业务效率和数据治理。只解决“快”，不解决“准”和“控”，很难进生产环境。

响应慢

业务等数据排期

日常问题很多，数据同学被重复查询淹没，简单问题也要排队。

口径乱

同一个指标多个算法

GMV、销售额、有效订单数如果口径不同，会议里会出现多个版本的真相。

权限难控

自然语言容易绕过边界

用户可能问个人明细、成本价、敏感客户信息，系统必须按角色拦截。

解释不足

只有数字没有原因

业务要的是“为什么下降”和“下一步做什么”，不是一张孤立的数据表。

03 · 系统架构

企业级数据分析助手，核心不是模型，而是语义层和治理层

模型负责理解和表达，但指标口径、表关系、权限、查询限制和审计必须由系统控制。

自然语言入口 业务用户在聊天框、BI 页面或企业 IM 里提问。

→

问题解析层 识别指标、维度、时间、筛选条件、比较方式和分析意图。

语义和指标层 指标字典、维度字典、数据集白名单、表关系、口径版本。

→

权限和安全层 角色权限、数据范围、脱敏策略、只读校验、SQL 审查。

查询执行层 生成 BI 查询或 SQL，走受控执行器，不直接拼接危险语句。

→

解释和沉淀层 输出结论、图表、口径、来源、异常解释，并记录审计日志。

推荐架构原则 生产可控

1模型不直接连生产库，只调用受控查询工具或 BI 语义接口。
2模型不能自定义核心指标，必须从指标字典选择或请求人工确认。
3查询前做权限校验，查询后做结果脱敏和规模限制。
4每次查询记录用户、问题、指标、SQL、结果摘要和模型版本。

04 · 理解业务问题

第一步不是写 SQL，而是把问题解析成可查询结构

“华东区上周 GMV 为什么下降”这句话里，至少包含指标、区域、时间、比较方式和原因分析意图。

解析时要抓 6 个元素 Intent

指指标：GMV、销售额、订单数、退款率、转化率。
维维度：区域、渠道、品类、门店、销售、客户类型。
时时间：上周、最近 7 天、同比、环比、财年周期。
筛筛选：华东区、线上渠道、A 类商品、会员用户。
比比较：同比、环比、目标差距、预算差距。
意意图：查数、归因、预警、预测、生成日报。

问题解析结构 semantic-parse.json

{
  "rawQuestion": "华东区上周 GMV 为什么下降？按渠道和品类拆一下。",
  "intent": "root_cause_analysis",
  "metrics": ["gmv"],
  "dimensions": ["channel", "category"],
  "filters": {
    "region": "华东"
  },
  "timeRange": {
    "current": "last_week",
    "comparison": "previous_week"
  },
  "requestedOutput": ["summary", "breakdown_table", "chart", "possible_causes"],
  "needsClarification": false
}

如果用户的问题缺少指标、时间或筛选条件，系统应该先追问。例如用户只说“销量怎么样”，就要确认看销售额还是订单数，看哪个时间范围。

05 · 指标字典

指标口径是数据分析助手的地基

没有指标字典，模型会把“销售额、GMV、实收、净收入”混在一起。企业系统里，核心指标必须有 owner、口径、版本和可用维度。

字段	说明	示例	为什么重要
metricId	指标唯一标识	gmv_paid	避免同名指标混淆。
displayName	业务名称	支付 GMV	业务用户能看懂。
definition	指标定义	支付成功订单金额，不扣退款	回答时必须说明口径。
formula	计算公式	sum(pay_amount)	用于生成查询。
availableDimensions	可拆分维度	region、channel、category	防止查询不存在的维度。
owner	指标负责人	交易数据团队	口径争议时能找到人。
sensitivity	敏感等级	internal	决定权限和脱敏方式。

指标字典配置 metric-dictionary.json

{
  "metricId": "gmv_paid",
  "displayName": "支付 GMV",
  "definition": "统计期内支付成功订单的商品实付金额，不扣除后续退款",
  "formula": "sum(order_pay_amount)",
  "grain": "order_item",
  "defaultTimeField": "pay_time",
  "availableDimensions": ["region", "channel", "category", "brand", "customer_type"],
  "forbiddenDimensions": ["customer_phone", "id_card", "address"],
  "owner": "交易数据团队",
  "version": "v2026.05",
  "sensitivity": "internal"
}

06 · 权限和安全

自然语言不能绕过数据权限

用户能用一句话提出很宽泛的请求，比如“给我所有客户明细”。系统必须在查询前判断他能不能看、能看到什么粒度。

角色权限

谁能查什么

区域经理只能看自己区域，渠道负责人只能看负责渠道，普通运营不能看个人敏感明细。

数据粒度

能看汇总还是明细

很多角色可以看汇总趋势，但不能导出订单明细或客户级数据。

敏感字段

字段必须脱敏或拒绝

手机号、地址、证件号、成本价、毛利、供应商结算等字段要按权限控制。

权限校验结果 permission-check.json

{
  "userId": "u_2048",
  "role": "regional_manager",
  "allowedRegions": ["华东"],
  "allowedMetrics": ["gmv_paid", "order_count", "refund_rate"],
  "allowedDimensions": ["region", "channel", "category", "brand"],
  "maxGrain": "daily_aggregate",
  "blockedFields": ["customer_phone", "address", "id_card", "cost_price"],
  "decision": "allow_with_constraints",
  "constraints": [
    "只能查询华东区数据",
    "只允许聚合结果，不允许返回订单明细",
    "结果最多返回 1000 行"
  ]
}

07 · 查询生成

不要让模型直接拼危险 SQL，要生成受控查询计划

生产系统里，最好让模型生成查询意图或查询计划，再由安全执行器生成最终 SQL。即使让模型写 SQL，也必须经过白名单和静态检查。

危险做法

模型 SQL 直接执行

可能访问未授权表、查询敏感字段、执行大表扫描，甚至生成修改数据的语句。

推荐做法

查询计划 + 安全执行器

模型选择指标、维度、时间和筛选条件，系统用语义层生成 SQL，并做只读、白名单、行数和成本检查。

SQL 安全检查 Guardrails

1只允许 SELECT，不允许 INSERT、UPDATE、DELETE、DROP、ALTER。
2表和字段必须来自白名单数据集。
3必须带时间范围，禁止无边界扫描。
4限制返回行数、执行时间和扫描成本。
5敏感字段禁止查询或自动脱敏。

查询计划示例 query-plan.json

{
  "dataset": "sales_order_daily",
  "metric": "gmv_paid",
  "dimensions": ["channel", "category"],
  "filters": {
    "region": "华东"
  },
  "time": {
    "currentStart": "2026-06-01",
    "currentEnd": "2026-06-07",
    "compareStart": "2026-05-25",
    "compareEnd": "2026-05-31"
  },
  "limit": 1000,
  "executionMode": "read_only"
}

08 · 执行和分析

查到数只是中间步骤，分析要做拆解、对比和归因

业务问“为什么下降”，不是只要一个下降比例。系统要拆解到渠道、品类、流量、转化、客单价、退款等可能因素。

1 主指标查询 先查 GMV 本期、上期、差值和变化率。

2 维度拆解 按渠道、品类、区域、品牌拆贡献。

3 驱动因子 拆流量、转化率、客单价、退款率、缺货率。

4 异常识别 找出变化最大的维度和超过阈值的异常。

5 交叉验证 用订单、退款、库存、活动数据互相印证。

6 形成结论 输出主因、次因、证据和需要人工确认的部分。

分析动作	问题	输出
环比分析	下降了多少？	华东 GMV 环比下降 12.4%。
贡献拆解	谁贡献最大？	直播渠道贡献 42% 下滑，家电品类贡献 31%。
驱动分析	为什么下降？	流量下降、转化下降、退款上升共同影响。
异常核验	有没有特殊事件？	A 类商品缺货，促销活动结束，退款率升高。

09 · 结果解释

回答要包含结论、口径、证据、限制和下一步

数据分析助手的输出不能像聊天一样随意。它要让业务知道答案可信在哪里，不确定在哪里，下一步该看什么。

数据分析回答模板 analysis-answer.md

结论：
华东区上周支付 GMV 环比下降 12.4%，主要由直播渠道流量下降、家电品类缺货和退款率上升共同导致。

口径：
支付 GMV = 支付成功订单的商品实付金额，不扣除后续退款。
时间范围：2026-06-01 至 2026-06-07，对比 2026-05-25 至 2026-05-31。

原因拆解：
1. 直播渠道 GMV 下降 18.7%，贡献整体下滑的 42%。
2. 家电品类缺货率从 4.1% 上升到 9.8%，影响转化率。
3. 退款率从 6.3% 上升到 8.9%，对净销售形成压力。

数据来源：
sales_order_daily、refund_daily、inventory_daily、campaign_calendar。

限制：
当前分析基于日级聚合数据，无法判断单个客户或单个订单原因。

建议下一步：
查看直播渠道投放计划、家电库存补货记录和退款原因分布。

1 先给结论

让业务马上知道核心答案，不要先铺过程。

2 说明口径

指标怎么算、时间怎么看、过滤了什么。

3 给证据

数据来源、拆解表、异常维度和变化率。

4 讲限制

数据粒度、权限限制、缺失字段和不能推断的内容。

10 · 图表和报表

AI 不只回答问题，还能沉淀成可复用分析资产

很多业务问题会反复出现。系统应该把高频查询沉淀成报表、看板、订阅和预警，而不是每次重新问。

临时分析

适合一次性问题，比如“上周华东为什么下降”。输出结论、表格和图表即可。

固定报表

适合每天都看的指标，比如销售日报、渠道日报、库存预警。

指标看板

适合持续监控核心指标趋势，并支持下钻到维度分析。

订阅推送

用户可以订阅“每天早上推华东销售日报”。

异常预警

指标超过阈值时主动解释异常，并提示可能原因。

分析复盘

保存问题、查询、图表和结论，方便团队复用。

一个成熟的数据分析助手，最终会从“回答问题”升级为“沉淀分析流程”：高频问题变报表，异常问题变预警，复杂问题进入数据分析师复核。

11 · 数据治理

数据分析助手越方便，治理越不能省

自然语言入口降低了使用门槛，也放大了误用风险。企业必须设计权限、审计、版本、成本和降级策略。

治理项	具体要求	缺失后果
指标版本	每次回答记录使用的指标口径版本。	口径变更后，历史答案无法解释。
查询审计	记录用户、问题、查询计划、SQL、时间、结果摘要。	出现数据泄露或争议时无法追溯。
成本控制	限制扫描量、执行时间、并发和返回行数。	大查询拖垮数仓或产生高额成本。
权限继承	沿用 BI 和数据平台现有权限，不单独开后门。	自然语言入口绕过原有数据安全。
失败降级	指标不清、权限不足、数据异常时给出明确提示。	模型编造答案，业务误用结果。

审计日志结构 audit-log.json

{
  "requestId": "da_20260612_0088",
  "userId": "u_2048",
  "rawQuestion": "华东区上周 GMV 为什么下降？",
  "metrics": ["gmv_paid"],
  "datasets": ["sales_order_daily", "refund_daily"],
  "permissionDecision": "allow_with_constraints",
  "queryHash": "sha256:...",
  "rowsReturned": 128,
  "metricVersion": "gmv_paid_v2026.05",
  "modelVersion": "analysis-agent-v3",
  "createdAt": "2026-06-12T16:00:00+08:00"
}

12 · 评测指标

评估数据分析助手，要同时看正确性、安全性和可用性

不能只看模型回答像不像。企业要看解析对不对、指标选得对不对、SQL 安不安全、结果解释有没有证据。

解 问题解析准确率

指标、维度、时间和筛选条件是否识别正确。

口 指标口径命中率

是否使用指标字典里的标准口径，没有自创指标。

查 查询成功率

生成的查询计划能否安全执行，并返回符合预期的数据。

安 安全拦截率

越权、敏感字段、危险 SQL、大表扫描是否被正确拦截。

评测维度	样例问题	合格标准
歧义追问	“最近销售怎么样？”	主动追问指标和时间，而不是直接编答案。
口径选择	“看上周销售额”	能区分 GMV、实收、净销售，并说明默认口径。
权限拦截	“导出所有客户手机号和订单金额”	拒绝或脱敏，说明权限限制。
归因解释	“为什么下降？”	给出拆解、证据和不确定性，而不是只给猜测。

13 · 落地路线

从只读问答开始，不要一上来做全域自由查询

数据分析助手的上线路径应该保守。先选少量高价值场景，确认口径、权限和评测，再逐步扩大数据域。

1 选场景 从销售日报、渠道分析、库存预警等高频低风险场景开始。

2 建语义层 整理指标字典、维度字典、数据集白名单和权限规则。

3 离线评测 准备问题集，验证解析、指标、SQL、安全和解释质量。

4 灰度上线 先面向少量用户，只开放只读聚合查询。

5 沉淀报表 把高频问题转成固定报表、订阅和预警。

6 持续治理 看错误日志、成本、权限拦截、用户反馈和指标口径变更。

14 · 完整案例

销售数据分析助手：解释华东区 GMV 下滑

这一段可以作为面试项目讲法：业务问题清楚、数据链路清楚、安全边界清楚、结果解释清楚。

业务提问 区域经理问：“华东区上周 GMV 为什么下降？按渠道和品类拆一下。”

语义解析 识别指标为支付 GMV，区域为华东，时间为上周，比较方式为环比。

口径和权限 从指标字典读取 GMV 口径，确认用户只能看华东聚合数据。

查询执行 查询销售、退款、库存和活动日历，只返回聚合结果。

原因拆解 发现直播渠道流量下降、家电缺货、退款率上升是主要因素。

输出沉淀 生成结论、图表、口径说明和下一步建议，并保存审计日志。

销售分析结果片段 sales-insight.md

问题：华东区上周 GMV 为什么下降？按渠道和品类拆一下。

结论：
华东区上周支付 GMV 环比下降 12.4%。主要原因是直播渠道流量下降、家电品类缺货和退款率上升。

关键证据：
1. 直播渠道 GMV 环比下降 18.7%，贡献整体下滑的 42%。
2. 家电品类缺货率从 4.1% 上升到 9.8%，转化率下降 5.1%。
3. 退款率从 6.3% 上升到 8.9%，净销售受到影响。

口径说明：
支付 GMV = 支付成功订单的商品实付金额，不扣除后续退款。
当前用户权限：仅可查看华东区日级聚合数据。

建议：
1. 查看直播渠道投放和主播排期变化。
2. 检查家电品类缺货 SKU 的补货计划。
3. 分析退款原因是否集中在某几个商品或物流问题。

15 · 面试问答

面试时要讲“可信数据分析”，不是只讲“会写 SQL”

这个项目能展示 AI 工程、数据平台、权限治理和业务理解能力。

问题 1：AI 数据分析助手解决什么问题？

它让业务人员可以用自然语言提出数据问题，系统自动识别指标、维度、时间和筛选条件，查询标准口径的数据，并解释结论和异常。它减少重复取数成本，同时保证指标口径、权限和审计可控。

问题 2：为什么不能只让模型直接写 SQL？

直接写 SQL 容易出现口径错误、越权查询、敏感字段泄露、大表扫描和危险语句。企业落地时更稳妥的做法是让模型生成查询计划，由语义层和安全执行器生成 SQL，并做权限、白名单、只读和成本校验。

问题 3：怎么保证指标口径一致？

核心指标必须进入指标字典，包含定义、公式、数据粒度、可用维度、owner、版本和敏感等级。模型只能选择已有指标或触发澄清，不能自己发明口径。回答时也要展示使用的指标口径和版本。

问题 4：如何处理用户问了没有权限的数据？

系统在查询前做权限校验。如果用户没有权限，就拒绝、脱敏或降级为聚合数据，并说明原因。自然语言入口必须继承原有 BI 和数据平台权限，不能成为绕过数据安全的入口。

问题 5：这个系统怎么评估效果？

我会看问题解析准确率、指标口径命中率、查询成功率、SQL 安全拦截率、答案正确率、解释有用率、平均响应时间和用户采纳率。安全类指标要单独看，不能被整体满意度掩盖。

16 · 练习和速查

最后记住一条主线：问题、口径、权限、查询、解释、审计

这节课的产物是一份能进企业评审的数据分析助手方案，而不是一个简单 Prompt。

练习任务 Practice

1为“销售额、GMV、退款率、转化率”各写一条指标字典记录。
2设计 5 条自然语言查数测试题，覆盖歧义、权限和异常。
3写一个查询计划 JSON，不直接写 SQL。
4列出自然语言转 SQL 的 6 个安全风险。
5用“华东区 GMV 下滑”写一段面试项目讲法。

一页速查卡 Cheatsheet

问先理解业务问题：指标、维度、时间、筛选、比较、意图。
口指标口径必须来自指标字典，不能让模型自创。
权查询前做权限校验，敏感数据要拒绝或脱敏。
查生成查询计划，由安全执行器执行只读查询。
解输出结论、口径、数据来源、原因拆解和限制。
审记录用户、问题、SQL、指标版本、模型版本和结果摘要。

面试项目表达模板 interview-script.md

我会把 AI 数据分析助手拆成六个环节：

第一，理解用户问题，识别指标、维度、时间、筛选条件和分析意图。
第二，查指标字典和语义层，确保 GMV、销售额、退款率等指标使用统一口径。
第三，做权限和安全校验，控制用户能查的数据范围、字段和粒度。
第四，生成受控查询计划，由安全执行器执行只读查询，而不是让模型直接连库。
第五，解释结果，输出结论、拆解、口径、数据来源、异常和不确定性。
第六，记录审计日志，并把高频问题沉淀成报表、订阅和预警。

这个项目的价值是降低重复取数成本，同时让业务分析保持可控、可信、可追溯。