带数据团队落地过几个快消渠道项目后，我对"AI 智能报告"这件事的判断越来越务实：它能不能用，不取决于模型多新，而取决于底座、权限和治理这老三样。下面聊聊我在一线的真实体会。

Text-to-SQL 的原理，没那么玄

说白了，Text-to-SQL 是把自然语言问题翻译成 SQL 查询。工程上通常分几步：

先是语义解析，模型把用户的中文问题切成语义单元，识别意图、实体、筛选条件和聚合维度。比如"上月华东区铺货率低于 60% 的门店"，要能拆出时间（上月）、区域（华东）、指标（铺货率）、阈值（<160%）、对象（门店）。

然后是 schema linking，把问题里的业务词映射到数据库的表、字段和指标定义。这一步高度依赖一张干净的语义层——铺货率、单店产出这些指标得先有统一口径，否则模型连"该查哪张表"都猜错。

最后才是 SQL 生成与执行，跑完再渲染成图表。我们给区域总演示时，最买账的不是图，而是"schema linking"之后展示的查询逻辑——AI 把"我是怎么算的"摊开，业务和 DBA 都能复核。只给结论不给依据，落地一定卡壳。

权限这道关，绕不过去

很多文章不讲，但生产环境里权限才是生死线。对话式取数意味着"业务自己写查询"，那就要解决两件事：

一是行级权限。区域经理问"哪些门店动销掉了"，结果集必须只包含他管辖的门店，不能越权看到别的省区。这要在查询生成后自动拼接权限谓词，或者从语义层就按角色裁剪可见维度。

二是数据脱敏与审计。对话日志、生成的 SQL、返回结果都要留痕，谁能问什么、问出了什么，可追溯。我们当初在方案里加了一层查询网关，所有 AI 生成的 SQL 先过权限校验再执行，宁可多一步，也不敢裸跑。

我反对那种"让业务随便问"的激进说法。权限不做实，AI 报告再好也是合规雷区。

初次接入时，客户 IT 常说"数据都通了"。结果一问"单店产出"，拜访系统和订货系统里"店"的主键对不上，指标各算各的。模型再聪明，喂进去的是脏数据，出来的也是脏结论。

所以我的建议很朴素：先把口径统一、主数据治理、语义层沉淀做扎实，再上对话式取数。没有这些，再多模型也是空中楼阁。治理到位后，AI 承担重复取数和初筛，人把精力留给判断，这才是合理的能力分配——技术团队从"取数外包"回归"数据基建"。

传统 BI 是"预先建模、固定看板"，适合口径稳定的监管报表；对话式取数擅长探索性、临时问题。两者互补而非替代。我们一般建议：固定报表保留看板，临时分析走自然语言入口。

这里提一句，eBest 的 AI Chat Report 把渠道全链路数据（拜访、进销存、费用、订货）做成对话式入口，并在结果里保留查询逻辑可追溯，业务在手机端就能用自然语言查数，对强一线的渠道团队比较贴合。至于要不要上，决策者还是先看自家语义层和权限网关是否就绪——地基不稳，先别急着盖楼。