企业数据问答上线，先统一指标口径

把 LLM 接上公司数据库，演示时四秒就能画出上季度各地区收入，为什么一推广就出问题？作者的答案是：演示避开了企业数据里最难的部分，包括指标口径冲突、权限边界，以及错误答案造成的信任损失。

作者基于 Looker 和语义层建设企业对话式分析，最近又通过 MCP 接入 AI Agent。他主张把模型限制在理解问题和组织回答的位置，让已有的数据治理体系负责定义、授权和查询。这套分工值得参考，但原文没有给出准确率和对照实验，不能把架构主张直接当成效果证明。

同一个「收入」，模型凭什么知道你问的是哪一种？

演示数据里的 revenue 往往只对应一列。真实公司里，财务说的收入可能按权责发生制确认，还要扣除退款；销售说的收入却是签单金额。两者都可能正确，只是回答不同问题。

「活跃客户」也一样。客服可能把 90 天没有提交工单的人算作活跃客户，增长团队则看本周是否登录。模型直接面对原始表，并不会自动知道当前提问属于哪个部门、哪种口径。它可以生成语法正确的 SQL，同时给出业务上错误的答案。

作者的解决办法是语义层（semantic layer）：先把指标含义和计算规则写成受管理的定义，再让模型调用。

在 Looker 中，这部分由 LookML 描述，包括度量、维度和关联关系，交给数据团队维护，进入版本控制并接受评审。模型负责判断用户想问什么，语义层负责规定数据代表什么。

业务口径应该成为可复用、可审查的定义，而不是每次提问时重新生成的猜测。

这也是作者反对直接推广 text-to-SQL 的理由：如果每次都让模型从原始表重新推导业务逻辑，口径错误就会跟着查询覆盖范围一起扩大。

但「每个指标只定义一次」不能理解成全公司只准保留一种收入。更合理的落地方式，是把已确认收入、签单金额等定义分别命名，并明确适用范围。用户只问「收入」时，系统仍然可能需要追问。原文没有展开这一步。

权限写进提示词，为什么还不够？

传统 BI 通常在接近数据的位置实施权限控制，例如行级过滤、列访问限制和用户属性判断。快速接入 LLM 时，团队却容易给 Agent 配一个权限很大的服务账号，再通过聊天入口供所有人使用。

问题在于，数据库看到的是服务账号，未必是实际提问的人。如果查询没有携带用户身份，上层界面再友好，也可能把账号能访问的数据暴露给不该看到它的人。

自然语言还会掩盖查询的敏感程度。用户不必输入查询薪资的 SQL，只需问一句「团队里谁涨薪最多」，模型就可能尝试找到答案。

作者提出的边界很明确：Agent 继承请求者的权限，执行限制发生在数据层。对话查询携带用户属性，与仪表盘共用行级、列级规则。模型即使接受了「忽略限制」的指令，底层查询也应被拒绝。

这里真正起作用的是权限执行机制。语义层提供统一入口，但不会自动替团队补齐身份传递和授权配置。

作者也提到，Agent 缓存结果、彼此共享答案时，治理会更复杂，不过本文没有给出具体方案。因此，不能仅凭查询入口受控，就认定缓存和后续传播已经安全。

MCP 接通了工具，谁来保证数字可信？

作者认为，对话式分析里的「大致正确」很难过关。高管在董事会上发现一个错误数字，可能让项目失去信任。他用「推广停摆一年」描述这种代价，但没有提供统计依据，应当按经验性警示理解。

为了让答案可解释，作者把职责分成三部分：语义层提供确定的指标定义，数据层执行确定的权限，模型承担意图解析和结果表达。

这条路径还能保留审计线索。有人追问数字来源时，团队可以回到受管理的查询和具名指标，检查计算依据，而不是只面对一段无法复核的自然语言回答。

接入 Model Context Protocol（MCP）后，这种分工也没有改变。作者通过 Looker 的 MCP server，把语义层开放给公司内部的桌面 Agent 客户端。他强调，Agent 获得的是进入既有治理体系的入口，而不是一套额外放宽的权限。

MCP 负责接通入口，答案是否可靠仍取决于入口后面的定义、权限和验证。

作者建议从业务真正会问的 20 个问题开始，先定义指标，再连接模型；同时建立标准问题集和已确认的正确答案，像管理服务等级目标（SLO）一样管理准确率，并在内部公开结果。

原文没有公布实际准确率、评测样本规模或失败案例分布，也没说明如何判断文字解释和图表是否正确。它给出了评测方向，尚未提供完整的评测方法。

我的判断

我认同作者对职责边界的判断。企业分析里的很多错误，来自业务定义和访问上下文不明确。换更大的模型、继续补提示词，都无法替代业务负责人确认口径，也无法承担权限执行的责任。

但语义层只能固定已经写进去的规则，不能保证规则没有错误。模型也仍然可能选错指标、时间范围、过滤条件，或者在解释正确结果时说错话。因此，可审计与高准确率有关联，却不能画等号。

与直接对原始表生成 SQL 相比，作者的方案优先保证重复问题的一致性，适合已有 BI 治理基础的团队。代价是前置建模和持续维护；临时探索需求能覆盖多少，取决于已经建好的定义。

作者作为 Sr Database Engineer 参与相关实践，并在 Google Cloud Next '26 分享过工作，也共同署名了发表于 IEEE Access、2026 年的「Lineage-Aware Memory Governance」。这些经历说明观点有实践背景，但原文没有对照数据，「架构优于换模型」仍是有理由的经验判断。

能拿来做什么

• 给内部经营看板增加 AI 问答前，先整理 20 个高频问题，逐一确认指标口径、时间范围和标准答案，用它们限定首批上线范围。
• 在 Node 服务或 MCP 工具调用链中明确传递请求者身份，并验证同一个问题由不同权限用户发起时，底层查询是否正确限制结果。
• 在前端答案区域提供可追溯的指标名称、筛选条件和查询依据，方便用户发现口径偏差，也方便团队复核错误。
• 把标准问题集用于版本回归。更换模型、提示词或指标定义后，检查数字、所选口径和权限结果，并持续公开准确率。