Google Cloud 扩展对话式分析，但企业信任才是真正考验

尽管企业仍普遍质疑是否应将关键业务数据交给生成式 AI，Google Cloud 仍已将两款对话式分析产品推向正式发布。BigQuery Conversational Analytics 和 Conversational Analytics API 现已具备面向生产环境的状态，可用于 BigQuery 和 Looker；数据库支持仍处于预览阶段。

7 月 28 日的公告不只是又一次聊天机器人发布。Google 正在构建一层受治理的分析能力，横跨数据仓库、运营数据库、商业智能工具、自定义应用和工作场所助手。其目标是让自然语言分析能够随员工流转于这一环境中，同时不丢失访问控制和已达成一致的业务定义。

这一策略将对 Snowflake、Microsoft、Databricks 及专业分析厂商形成压力。然而，更深层的竞争并非 Google 与某一家对手之间的较量，而是受治理的数据代理与通用语言模型封装工具之间的竞争：后者能够生成看似合理的答案，却并不理解企业如何定义自身的指标。

Google Cloud 将对话式分析推向生产环境

眼下最直接的变化是，对话式分析已从一系列实验跨入受支持的 Google Cloud 产品架构。

该公司宣布 BigQuery Conversational Analytics 及其 Conversational Analytics API 正式发布。该 API 为开发者提供了编程入口，可将同样的能力带入 Google 原生界面以外的应用。

Looker 中的 Conversational Analytics 此前已正式发布。Google 现在又为 AlloyDB、Cloud SQL 和 Spanner 增加了预览支持，将自然语言分析从分析型数据仓库延伸至运营数据库。

这一区别很重要，因为数据仓库通常包含为报表准备的精选数据。运营数据库则保存着应用、交易、库存系统和客户体验背后的实时记录。涉及这些系统的问题需要更严格的控制和更谨慎的解读。

官方产品公告还扩大了可访问的数据资产范围。代理可分析 Lakehouse Managed Service 表、Apache Iceberg REST catalogs 以及联邦 AWS S3 Unity Catalogs。

因此，Google 并未将该产品局限于完全存储在其云端的数据。它正将对话式分析定位为一个可跨越混合存储和多云部署的接口。

员工可在 BigQuery Studio、BigQuery Data Canvas、Database Studio、Looker、Data Studio 和 Gemini Enterprise 中使用这些代理。数据团队可从多个 Google 数据产品中发布代理至 Gemini Enterprise，供更广泛的组织访问。

开发者还有另一条分发路径。正式发布的 API 提供 Node.js、Java、Go、Python、PHP、Ruby 和 .NET 的 SDK。Google 还支持通过其 Agent Development Kit 和 Model Context Protocol（MCP）构建的集成。

MCP 是一种用于将 AI 系统与外部工具和上下文连接起来的标准。在这里，它可以让另一个代理调用受治理的分析代理，而不是自行生成数据库逻辑。

例如，供应链助手可以请求财务数据代理计算延迟发货对利润率的影响。该计算将持续连接到受治理的财务定义，以及提出请求员工所拥有的权限。

Google 还将 Slack 机器人和自定义应用描述为可能的部署目的地。这改变了部署模式：分析不再局限于访问某个分析产品，而是可在决策发生的任何地方被调用。

API 发行说明显示，该 API 于 2026 年 6 月 23 日正式发布。说明还记录了第一版 REST 端点、数据驻留功能和企业安全控制。

之后的博客公告将这些技术里程碑整合进了更广泛的产品叙事。Google Cloud 希望在数据系统、用户界面和代理工作流之间提供统一的对话层。

这种广度带来了核心张力。分发可以提升采用率，但每增加一个触点，也就多了一个错误答案可能影响决策的地方。

Google Cloud 押注于治理能力胜过通用聊天机器人

Google Cloud 将业务含义视为基础设施，而非部署后附加的提示文本。

通用聊天机器人可以把问题翻译成 SQL，但这并不意味着它了解组织如何界定已确认收入、活跃客户或符合条件的交易。

这些定义往往依赖获批准的筛选条件、连接、排除项、会计规则和报告周期。两条语法正确的查询可能产生不同答案，但在非技术员工眼中却同样显得自信。

Google 的解决方案是将语言模型与元数据、语义模型、经验证查询以及现有数据权限结合。语义模型为业务概念提供一致定义，供应用重复使用。

在 Looker 中，这种基础来自 LookML——其用于集中管理维度、度量、连接和访问规则的建模语言。代理可以检索这些定义，而不是根据表名和列名臆造业务逻辑。

Google 还使用其所谓的 Golden Queries。这些经过验证的示例，捕捉了重复性问题所接受的业务逻辑。它们为代理构建新查询时提供可信模式。

Knowledge Catalog 提供描述、词汇表和关系上下文。BigQuery Graph 和 Spanner Graph 能够表示跨多个实体的连接，帮助代理推理多步骤关系。

这一设计十分重要，因为数据库模式很少能自我解释。名为 status 的列，可能表示付款状态、发货状态、账户状态，或内部处理状态。

模型必须先获得业务上下文，才能做出正确选择。通过目录和语义层补充这些上下文，比期待员工在每个问题中解释所有定义更可靠。

治理层同样限制了结果的可见范围。Google 表示，代理会执行现有的基于角色的访问控制，包括行级和列级权限。

区域经理与全球高管提出同一个问题时，可能会获得范围更窄的结果。代理应继承底层平台的授权，而不是另建一套访问系统。

Google 已加入客户管理的加密密钥、私有网络控制和数据驻留选项。该公司称，机器学习处理可保留在美国或欧盟境内受支持的多区域端点。

该公司还将 HIPAA 合规性列为可用控制项之一。这些功能能满足采购要求，但无法独立证明答案的准确性。

准确性要求在代理面向员工投入使用后持续评估。Google 允许管理员通过 OpenTelemetry——一项行业系统可观测性标准——导出延迟、令牌消耗、健康状态和工具使用指标。

团队还可检查追踪记录和用户反馈。BigQuery 查询标签和 Looker 活动日志提供了另一种理解使用情况、调查异常昂贵或可疑请求的方式。

原生限制可约束单次查询处理的最大字节数。当一个随意提出的自然语言问题可能触发对大型数据集的广泛扫描时，这一控制尤为重要。

这些要素使对话式分析成为一项可运营的服务，而非演示样例。与此同时，它们也将大量责任置于数据团队肩上。

薄弱的目录、不一致的指标定义或不完整的访问策略，仍会导致薄弱的结果。代理无法修复其底层早已存在的所有治理问题。

考虑大范围部署的组织，应将语义准备视为维护共享知识层的一部分。其价值在于连接相关上下文，同时保留其来源、范围和含义。

真正的竞争是受治理的数据代理与看似合理的答案之争

市场正趋于认同一个结论：对话式分析更依赖准备完善的语义，而非模型的对话流畅度。

Google Cloud 并非唯一得出这一结论的厂商。Snowflake 和 Microsoft 都围绕语义上下文、经验证示例、权限和可检查查询构建了各自的方法。

Snowflake 的 Cortex Analyst 使用语义模型和 Verified Query Repository。该存储库将自然语言问题与经人工检查的 SQL 配对。

其已验证查询系统可在新问题与获批准的问题相似时检索相关示例。Snowflake 警告称，无效的已验证查询可能降低答案质量。

这一警告揭示了一个重要现实：当 AI 界面到来后，人工验证并不会消失。它只是被前移到团队定义指标和批准代表性查询的环节。

Snowflake 还开发了一个反馈循环，用于研究查询历史并提出缺失的筛选条件、指标或已验证示例。其模型建议在成为语义层的一部分前，需要经过人工审核。

Microsoft Fabric 遵循类似模式。其数据代理可查询数据仓库、湖仓、Power BI 语义模型、KQL 数据库、本体以及通过 Microsoft Graph 暴露的组织数据。

Microsoft 表示，数据访问将在员工身份和现有权限下运行。其代理会生成只读查询，并公开中间步骤以供检查。

该公司的数据代理指南还指出了一项重要限制。该代理不执行高级分析、机器学习或因果推断。

这一限制很有价值，因为流畅的答案可能让普通聚合看起来像更深入的分析。一个在历史数据中识别出相关性的系统，并未解释这种关系为何存在。

Google 正通过内置分析工具拓宽边界。其代理可调用用于预测、异常检测、嵌入、分类、评分和贡献分析的函数。

Google 的时间序列预测基础模型 TimesFM 支持部分预测和异常检测任务。ai.key_drivers 函数旨在识别与意外指标变化相关的因素。

Agentic Workflows 则将系统进一步推进。在预览阶段，它们可安排报告、监控指标并调查异常，而无需等待某个人先提出问题。

Google 表示，多维度调查可检查指标变化背后的 10 至 20 个影响因素。当某项度量跨过设定阈值时，流式异常检测也可启动调查。

这比聊天更具深远影响。聊天机器人等待用户发起提问，而监控型智能体会自行判断何时某件事值得关注，并组织出相应的解释。

这种模式正与 Microsoft 从数据智能体转向运营智能体的趋势竞争。它也挑战了围绕仪表板、告警和分析师创建报告构建的传统商业智能工作流程。

不过，每家厂商都面临同一个瓶颈：生成的查询可能在语法上有效，却回答了错误的业务问题。

设想一位销售主管询问营收为何下降。正确的分析可能需要进行汇率标准化、排除已取消订单、调整地区日历差异，并应用收入确认规则。

语言模型可以编写出令人印象深刻的 SQL，却未必会应用这些规则。受治理的智能体更有可能做到这一点，因为规则可以存在于其语义层和经验证示例中。

Google 的优势在于，其数据产品连接了广泛的使用界面。Snowflake 的优势则在于，让对话紧贴其平台内部受治理的数据。

Microsoft 可以将分析能力与 Microsoft 365、Teams、Power BI 和 Copilot Studio 连接起来。Databricks 也将自身的数据智能和 lakehouse 上下文带入同一场竞争。

胜负不会仅由针对预设问题的基准准确率决定。企业还会考察在数千个真实请求中，维护成本、可追溯性、访问控制执行、延迟和故障处理等表现。

这也是为什么主要对手是通用封装方案。它承诺可以快速演示，而受治理的智能体则要求在大规模部署前完成语义建模并具备运营纪律。

封装方案更容易上线。受治理的系统则更有可能经受住财务、合规、安全和高管决策场景的考验。

更多数据访问也意味着更多出错方式

Google Cloud 扩展智能体能力范围的速度，快于行业建立衡量分析可信度通用标准的速度。

正式发布意味着产品成熟度和支持承诺，并不表示每一个生成的答案都能针对每一种架构、问题或组织定义保持准确。

Google 对其 grounding 功能使用了谨慎的表述。语义模型和 Golden Queries 有助于减少猜测式连接，但无法保证每个新问题都会映射到获批准的解释。

经验证示例可能涵盖月度营收，却未涵盖报告期结束后入账的退款。一个陌生的变体可能让系统进入看似合理、但违反政策的逻辑。

企业之间的元数据质量也各不相同。许多组织存在重复指标、未记录的表、被遗弃的仪表板以及不一致的命名规范。

对话式访问可能会将这些不一致暴露给更广泛的受众。智能体可能让已有的治理问题变得更明显，却无法解决它。

运营数据库还带来了另一项挑战。它们的架构往往优先考虑应用性能和事务完整性，而不是易于理解的分析概念。

跨 BigQuery、Cloud SQL、Spanner、AlloyDB 和外部目录连接数据，可能引入数据新鲜度、区域可用性、身份映射和指标定义方面的差异。

当数据源相互矛盾时，系统也需要给出明确响应。悄无声息地选择一个答案会制造虚假的确定性，而列出每一项冲突又会削弱助手的实用性。

安全性也继承了类似的复杂性。行级权限可以约束查询结果，但智能体的解释仍可能通过摘要或比较暴露敏感模式。

组织需要针对推断风险、提示注入、恶意元数据和未经授权的工具调用进行测试。他们必须同时审查生成的查询，以及用于描述其结果的语言。

将分析智能体发布到通用工作场所助手中，会使受众扩展到训练有素的分析师之外。这种扩展提升了易用性，却降低了每位用户都会检查生成逻辑的可能性。

分析师可能会通过阅读 SQL 并核对源表来质疑可疑结果。销售经理在聊天中收到答案时，则可能因为措辞听起来很有信心而接受相同的结果。

主动式工作流程再次提高了风险。一份定时摘要可能会在任何人提出疑问之前传播错误的解读。

触发式调查也可能选择无关的影响因素。贡献分析识别的是统计关联，并不一定是因果驱动因素。

该产品的可观测性控制为监控这些故障提供了途径。管理员可以检查智能体追踪记录、反馈、延迟、token 使用量和底层工具调用。

然而，收集遥测数据只是第一步。企业仍需要评估集、升级处理路径、业务定义负责人，以及纠正错误答案的流程。

他们还需要区分采用率和信任度的指标。提问次数高可能反映热情使用、反复重试，或员工在核查不一致的答案。

同样，积极反馈也可能具有误导性。即使无法验证底层计算，用户往往仍会奖励清晰的呈现方式。

最有价值的评估，应将智能体答案与经过分析师审查的结果进行对比，覆盖重复出现和陌生的问题。测试应包括模糊语言、受限制记录、不完整数据和相互冲突的定义。

团队应记录：当不确定性具有实质影响时，智能体是否会要求澄清。拒绝猜测，可能比立即生成图表更好。

成本控制也需要同样严格的审视。最大查询规模限制可以防止过度扫描，但如果用户不了解这一限制，也可能导致不完整的分析。

token 测量只能涵盖部分成本。语义模型维护、评估、事故审查和人工验证，也将影响部署的总体运营负担。

Google Cloud 的架构比通用聊天机器人封装方案更直接地应对了其中许多问题。不过，该公司尚未发布独立证据，证明完整系统能够消除分析幻觉。

更站得住脚的结论应当更为有限：grounding、权限、经验证逻辑和可观测性，能够为可信分析创造更好的条件。

这些条件能否产生可靠答案，取决于每个组织的数据质量、语义规范、评估流程，以及是否愿意让人类继续对重大决策负责。

Google Cloud 发布后值得关注的事项

下一阶段将由生产环境证据、数据库就绪度和竞争对手的回应决定，而不是另一场精致的聊天演示。

第一个信号是正式发布的 BigQuery 和 Looker 产品能否获得可衡量的采用。Google 描述了从实验走向企业部署的转变，但买家需要更清晰的运营证据。

有用的指标包括活跃用户数、重复使用率、问题成功率、查询量，以及需要分析师纠正的答案比例。Google 的监控工具可以捕捉其中部分情况。

客户案例研究也应说明部署范围。一小群数据专家与数万名业务员工，面临的是不同的信任挑战。

广泛采用且纠正率低的证据，将强化 Google 关于对话式分析能够成为标准数据界面的主张。大量人工审查则会削弱广泛自治的论据。

第二个信号是预览功能能否达到稳定的生产状态。面向 AlloyDB、Cloud SQL 和 Spanner 的 Conversational Analytics，代表着从以数据仓库为中心的分析向外的重大扩展。

Agentic Workflows 也仍处于预览阶段。其进展将表明 Google 能以多快速度从回答问题转向监控指标和发起调查。

这些功能的正式发布，将表明 Google 已解决了足够多的可靠性、安全和支持问题，能够作出生产环境承诺。漫长的预览期则意味着复杂性尚未解决。

细节比标签更重要。买家应考察每个数据库支持的区域、权限行为、审计覆盖范围、延迟和功能差异。

他们还应关注主动式工作流程是否获得更强的审批关卡。自动化调查很有用，但高影响行动仍需要明确的人类控制。

第三个信号是 Snowflake、Microsoft 和 Databricks 如何回应。每家厂商都已经拥有一条从自然语言通向受治理企业数据的路径。

值得关注的方向包括更广泛的数据源覆盖、更深入的工作场所集成、更强的语义自动化，以及公开的评估方法。经验证查询系统很可能会在整个类别中变得更加核心。

Microsoft 的进展尤其值得关注，因为 Fabric 结合了语义模型、组织身份、协作工具和工作流程自动化。Snowflake 则可以凭借紧密受治理、贴近其数据平台的分析能力进行反击。

竞争压力可能改善互操作性。无论平台战略如何，企业很少会将所有运营和分析数据都保留在单一厂商的边界内。

对开放目录、MCP 连接和联邦数据源的支持可以降低锁定风险。不过，跨平台访问也会使安全审查和语义一致性更加复杂。

决定性的客户问题不是智能体能否回答一个令人印象深刻的提示，而是员工能否依赖日常答案，而不会形成一条隐蔽的验证工作队列。

Google Cloud 已经针对这一问题构建了严肃的回应。它在同一架构中结合了数据访问、语义 grounding、权限、可观测性、API 和工作场所分发。

这一结果改变了企业对话。围绕数据库封装的定制聊天机器人，如今看起来不再像成品，而更像早期原型。

不过，治理功能不会自动制造信任。组织必须定义指标、修复元数据、测试模糊问题，并为故障指定负责人。

在扩展对话式分析之前，应选择一个影响重大的工作流程，并衡量其完整路径。跟踪其中的问题、生成逻辑、纠正、权限、延迟以及后续的业务决策。

如果 Google Cloud 能将这些受控部署转化为可重复的证据，对话式分析将超越聊天。它将成为企业调查自身运营状况的受治理界面。