AI-driven analytics 不能只靠 LLM + SQL：指标口径、权限和复核流程缺一不可

很多 AI 数据分析 demo 都会从一个很有吸引力的画面开始：

用户用自然语言提问，LLM 自动生成 SQL，数据库返回结果，系统再生成一段分析结论。

这个流程看起来简单，也确实适合展示“自然语言查数”的潜力。但如果把它直接搬进企业系统，问题会很快出现。

企业里的 analytics 不只是把数据查出来。它还涉及：

• 指标口径是否统一；
• 数据权限是否按用户和组织切片；
• 时间、币种、公司、业务状态是否按规则处理；
• 查询结果是否可复核；
• 结论是否能被用于业务决策；
• 错误、拒绝、截断和异常是否能被审计。

LLM + SQL 可以是其中一段链路，但不能成为完整的治理模型。

SQL 能算数，但不等于懂指标

SQL 很强。它能 join、filter、aggregate、window、CTE，也能处理复杂查询。但 SQL 本身不会自动知道一个企业如何定义指标。

比如“销售额”在不同团队里可能有不同口径：

问题	可能口径
是否包含税	tax included / tax excluded
是否包含取消订单	exclude cancelled / include for historical view
是否按订单确认时间	order date / confirmation date / invoice date
是否按发货完成	delivered amount / ordered amount
是否扣除退款	gross sales / net sales
多币种如何折算	transaction currency / company currency / report currency
多公司如何汇总	current company / allowed companies / group consolidation

如果这些口径没有被建模，LLM 生成的 SQL 可能语法正确、结果也能返回，但业务含义并不可信。

这类错误很难靠模型“多想一想”解决。因为问题不在 SQL 写得不够聪明，而在系统没有给它一个受治理的指标定义。

企业 analytics 需要 semantic metric

生产级 AI 分析应该尽量从 semantic metric 或 query model 出发，而不是从裸表结构出发。

一个 semantic metric 至少应该说明：

• 指标名称和业务含义；
• 计算公式；
• 默认时间字段；
• 默认过滤条件；
• 可用维度；
• 是否可 drill down；
• 是否支持跨公司或跨租户汇总；
• 金额、数量、比例等单位；
• 权限和字段可见性约束；
• 是否经过业务 owner 确认。

例如，“已确认销售额”不应该只是：

sum(sale_order.amount_total)

它可能需要表达：

• 只统计已确认或已完成订单；
• 默认排除取消订单；
• 金额按公司币种或报表币种处理；
• 当前用户只能看 allowed companies；
• 明细 drill down 时要执行 record rules；
• 返回结果需要带上 metric version 和查询过滤摘要。

这些信息不应该只存在于 prompt 里。它们应该进入可版本化、可校验、可审计的查询模型。

BI 指标治理和 AI 问数不是两套体系

很多团队已经有 BI、数仓或指标平台。接入 AI 后，容易出现一种危险倾向：让 AI 直接绕过已有指标层，去数据库里重新算。

这样短期 demo 很快，长期会制造口径分裂。

典型问题包括：

• BI 看板里的“销售额”和 AI 回答里的“销售额”不一致；
• 财务口径和销售运营口径混在一起；
• AI 为了回答问题临时选择字段，绕过指标 owner；
• 同一个问题每次生成不同 SQL，结果不可复核；
• 业务方不知道 AI 使用的是明细数据、汇总表还是缓存结果；
• 权限规则在 BI 里有，在 AI 查询里没有。

更稳的做法是：AI 分析能力应该复用或对齐已有指标治理体系。

如果企业已经有认证指标，AI 应该优先调用这些指标，而不是重新发明 SQL。如果没有成熟指标平台，也应该把 AI 常用指标沉淀到 query model 或 semantic layer 里，而不是每次临时生成。

权限切片会影响分析结论

权限不仅影响用户能不能看到明细，也会影响聚合结论。

比如同样问：

最近 30 天销售额下降了吗？

不同用户看到的答案可能不同：

• 集团负责人看到全部公司；
• 子公司负责人只看到当前公司；
• 销售经理只看到自己的团队；
• 销售人员只看到自己负责的客户；
• 财务人员可能能看金额字段，仓库人员只能看数量和状态；
• 外部伙伴可能只能看脱敏或汇总结果。

如果 AI 分析没有带上 effective user context，系统可能会给所有人返回同一个全局结论。这不是“更智能”，而是权限边界错了。

更重要的是，聚合结果也可能泄露信息。即使不返回明细，某些维度组合下的计数、金额或异常列表也可能暴露敏感业务状态。

因此，AI-driven analytics 需要在查询前处理：

• 当前用户可用的指标；
• 可用维度和 drill down 层级；
• 必须注入的 record-level 过滤；
• 最小聚合粒度；
• 小样本保护；
• 敏感字段和高风险维度；
• 导出和复制限制。

这些都不是 LLM 生成 SQL 时天然会做好的事情。

LLM 适合解释，不适合独占裁决

LLM 在 analytics 里很有价值：

• 把业务问题转换成候选查询意图；
• 帮用户澄清时间范围、指标口径和过滤条件；
• 根据查询结果生成自然语言解释；
• 总结异常模式；
• 提出后续分析问题；
• 帮助非技术用户理解图表和数据。

但 LLM 不应该独占几个关键裁决：

• 选择哪个指标口径；
• 判断用户是否有权查看某个结果；
• 决定是否可以跨公司汇总；
• 决定是否可以导出明细；
• 决定能否把结果作为业务审批依据；
• 在口径冲突时自行猜测。

这些应该由语义模型、权限系统、工具边界和业务流程共同决定。LLM 可以参与交互和解释，但不能替代治理层。

澄清比猜测更重要

AI 分析经常遇到模糊问题：

• “这个月业绩怎么样？”
• “哪些客户有风险？”
• “利润下降的原因是什么？”
• “库存是不是太高了？”
• “哪个销售团队表现最好？”

这些问题看起来自然，但技术上有很多隐含口径：

• “这个月”按自然月还是财务期间；
• “业绩”是销售额、毛利、回款还是订单数；
• “风险”是逾期、流失、信用、交付还是投诉；
• “库存太高”按金额、数量、周转天数还是库龄；
• “表现最好”按总额、增长率、利润率还是目标完成率。

如果系统直接猜一个 SQL 并给出结论，用户可能会把一个未经确认的口径当成事实。

更稳的处理方式是：

• 有默认认证指标时，明确使用哪个指标；
• 没有默认口径时，先澄清；
• 存在多个合法口径时，列出选项；
• 用户无权查看某些口径时，拒绝或给出可用替代；
• 输出结论时附带指标、时间、过滤和权限摘要。

这会让系统看起来“不那么神奇”，但更适合生产环境。

复核流程是 analytics 的一部分

企业分析结果经常会进入决策链路：

• 调整采购计划；
• 催收重点客户；
• 调整销售目标；
• 触发财务复核；
• 识别异常订单；
• 生成管理层报告。

这类场景不能只留下一个自然语言答案。

至少应该保留：

• 使用的 metric / query model；
• metric version；
• effective user context；
• 过滤条件；
• 权限过滤摘要；
• 结构化查询或查询 hash；
• 数据来源和时间戳；
• 是否使用缓存或预聚合；
• 结果行数和截断信息；
• LLM 生成解释的 prompt / model / trace id；
• 人工复核或确认记录。

复核流程不是额外负担。它是让 AI 分析从“看起来合理”变成“可以进入业务流程”的前提。

什么时候可以用 SQL

这篇不是反对 SQL。

SQL 仍然是底层查询和分析的重要表达方式。问题在于：SQL 应该处在受治理的边界内。

比较稳的分层是：

层次	适合做什么	边界
Query Model / Metric	定义业务可用字段、指标和权限	面向 AI 和业务用户的默认入口
JSON DSL / structured query	表达受限查询、过滤、排序、聚合	可校验、可审计、可转换
Semantic SQL	给高级用户或内部工具表达受限 SQL	需要白名单、解析、权限注入
Engine SQL	引擎内部生成的 SQL	不直接暴露给最终用户作为授权边界
Raw SQL	调试、运维、受控开发	不作为默认 AI 问数能力

这样既不否定 SQL，也不把 SQL 误用成业务治理模型。

一个生产级 AI analytics 检查清单

在把 AI-driven analytics 接入企业系统前，可以先检查：

• 是否有认证指标或 query model；
• 指标口径是否有 owner 和版本；
• 时间、币种、公司、状态等默认规则是否明确；
• 用户上下文是否进入查询执行前；
• 权限是否影响可用指标、维度和明细 drill down；
• 聚合结果是否有小样本和敏感维度保护；
• LLM 是否能伪造指标、用户或权限参数；
• 模糊问题是否会触发澄清；
• 越权、口径不支持、结果过大时是否会拒绝；
• 输出是否带有 metric、filter、scope 和 provenance；
• 关键结论是否支持人工复核；
• 写回、审批和业务动作是否与分析查询分开。

如果这些问题没有答案，就不要急着把“自然语言问数”升级成“AI 自动分析决策”。

结论

AI-driven analytics 的价值不在于让 LLM 随时写出一段看起来不错的 SQL，而在于让更多人以自然语言进入受治理的数据分析流程。

这个流程至少需要：

• 受版本管理的指标口径；
• 按用户和组织收敛的权限上下文；
• 可校验的结构化查询；
• 可解释的数据来源和执行证据；
• 澄清、拒绝、截断和脱敏策略；
• 能被业务复核的分析结论。

Foggy Data MCP / Foggy Odoo Bridge 更适合沿着这个方向表达：不是把企业数据交给任意 SQL 生成器，而是在语义模型、权限边界和审计证据之上，让 AI 成为数据分析流程里的交互层和解释层。