Amazon AWS 推出智能体目录，但人类策展人仍掌握关键决策权

Amazon AWS 推出了一项智能体目录体验，将 Amazon Quick 与两大企业级目录连接起来，尽管围绕 AI 生成数据模型的疑问仍然存在。

该预览版支持 AWS Glue Data Catalog 和 Databricks Unity Catalog。数据策展人可以用自然语言描述分析用例，审阅推荐资产，并通过一次引导式对话创建多个数据集。

这一工作流将商业智能中颇具难度的一部分前移至目录层。策展人不必在每个分析工具中重新构建描述和关系，而是可以复用上游已维护的语义。

不过，AWS 并未将策展人排除在流程之外。其文档明确要求作者在继续前审阅已发现的表、推断出的关系以及继承而来的描述。

这一提醒定义了真正的重点。Amazon Quick 正在自动组装分析上下文边界，但该边界的质量仍取决于人的判断。

这也让 Amazon AWS 进入了与 Databricks 和 Microsoft 更广泛的竞争。各家厂商都希望让受治理的元数据成为对话式分析和企业智能体的基础。

Amazon AWS 将目录元数据转化为 Quick 资产

这一预览版将数据发现、数据集创建和语义设置整合为单一的对话式工作流。

策展人首先将 Amazon Quick 连接至受支持的目录。随后，作者选择 Explore data，并用日常语言描述预期的用例。

AWS 在其 智能体工作流 中提供了一个供应链示例。策展人请求获取支持分析配送中心之间承运商表现和运输成本的数据。

智能体会在可用目录元数据中搜索相关资产。这些元数据可能包括表描述、列描述、数据质量评分和血缘信息。

这比搜索熟悉的表名更具针对性。智能体需要将业务目标与技术资产匹配起来，即使二者采用不同的命名规范。

策展人在创建任何内容之前先审阅推荐结果。获得批准后，Quick 会一并创建所选数据集，而不再要求为每张表单独进行设置。

这些数据集使用 DirectQuery，即向已连接的数据源发送查询，而不是将所有数据导入 Quick。上游目录仍被声明为唯一事实来源。

随后，工作流处理关系。Quick 可以在目录中已有关系时继承这些关系，也可以根据可用元数据建议其推断出的额外关系。

最后，智能体会创建一个多数据集 Topic。Topic 是帮助 Quick 理解业务语言，并在所选数据集之间生成查询的语义层。

描述也会自动向下游传递。目录中的表和列描述会成为新 Quick 数据集上的元数据。

这种继承之所以重要，是因为单靠列名很少能承载足够的业务含义。一个名为 revenue 的字段，可能指已预订收入、已确认收入，或预测收入。

经过维护的描述可以保留这种区分。没有它，AI 系统就必须根据名称、相邻字段和用户措辞进行猜测。

因此，智能体目录体验的作用不只是定位表。它将所选资产、关系和定义打包为 Quick 可用于分析的上下文。

AWS 将该能力描述为预览版，这意味着其行为和支持的功能仍可能发生变化。预览状态也意味着，在生产环境依赖它之前，必须进行审慎评估。

对于 Databricks 连接，AWS 明确表示，通常不建议将预览功能用于关键生产工作负载。这一限定降低了引导式工作流所承诺便利性的预期。

此次发布依然意义重大，因为它瞄准了一个反复出现的瓶颈。企业分析团队往往在上游维护有价值的元数据，随后又在报表平台中重复大量工作。

Amazon AWS 押注于智能体可以将更多这类上下文跨越边界传递。策展人的工作将从重复构建资产，转向选择和验证。

真正的瓶颈是选择正确的上下文

找到更多数据并不难；为业务问题界定最小且可信的数据集合，依然很困难。

大型组织可能拥有数千张表，分布在数据仓库、数据湖、运营系统和各部门项目中。广泛的目录有助于组织它们，但广度本身也带来了问题。

分析智能体不应接收每一张可用表。额外资产会引入含义模糊的字段、相互竞争的定义、无关的关系，以及更多生成错误查询的机会。

AWS 将这一选定集合称为聚焦的上下文边界。它建议只创建目标用例所需的数据集。

这一建议揭示了智能体目录体验如今出现的原因。与传统目录搜索通常提供的内容相比，对话式分析需要更窄、描述更充分的上下文。

人类分析师可以检查几张名称相近的表，并询问同事哪一张才是权威来源。AI 智能体则需要通过元数据、指令和受治理的关系来表达这些差异。

新工作流试图缩短从企业目录到可用上下文的路径。它检索元数据、提出相关子集，并将获批准的语义带入 Quick。

以供应链场景为例。交付表现可能涉及运输事件、承运商、配送中心、合同、发票和日历维度。

选择的资产过少会导致答案不完整。选择过多则会增加歧义，也可能暴露与管理者实际决策无关的字段。

因此，策展人仍须对范围负责。AI 提出一个分析包，但人必须决定该包是否反映了组织的运营语言。

这正是语义继承具有实际价值的地方。维护良好的目录已经包含数据管理员和领域专家创建的定义。

复用这些定义能够减少重复工作，并避免再形成一个孤立的语义层。它也能为 Quick 智能体提供比原始模式更丰富的业务上下文。

然而，继承无法改善不准确的源元数据。含糊的描述在被 Quick 复制后依然含糊，而过时的定义可能被自信地传播到新的界面中。

血缘和质量信号有助于发现过程，但无法解决每一项业务争议。两张受治理的表仍可能代表同一指标的不同、且都被接受的版本。

智能体还必须从简短的自然语言请求中推断用户意图。请求客户价值数据的策展人，可能指收入、利润率、留存率，或公司特有的综合评分。

自然语言让设置更易于使用，但也可能掩盖歧义。相比流畅的对话，带有明确建模选择的表单有时更早暴露分歧。

重要的转变并不是建模消失了。建模变成了智能体提出结构后进行的审阅任务。

这一转变与其他 AI 辅助知识工作流相似。工具可以收集和融合上下文，但可信的输出仍要求控制进入工作集的来源。

对于个人研究，同样的原则支撑着审慎的知识融合。有用的单位并非每一份可用文档，而是针对明确问题的相关证据。

Amazon Quick 将这一原则应用于受治理的企业数据。只有当策展人能够理解为何推荐每项资产和关系时，其预览版才能成功。

目录厂商如今通过语义层展开竞争

Amazon Quick 正进入一场竞争：哪一个平台能将受治理的元数据转化为可靠的 AI 答案。

Databricks 已将 Unity Catalog 定位为数据与 AI 的统一治理层。它实施访问控制、记录血缘，并通过多个界面提供受治理的资产。

Databricks 还支持对已注册表和列进行关键词和语义发现。其较新的发现工具让用户可以浏览共享资产并以自然语言提问。

Databricks discovery 体验与 Amazon 的主张存在部分重叠。两套系统都利用目录上下文帮助用户找到相关的受治理资产。

差异在于目标端。Amazon Quick 使用目录结果来创建 Quick 数据集和一个用于分析及对话式提问的多数据集 Topic。

因此，AWS 并非要取代 Unity Catalog。它是在将 Unity Catalog 元数据转化为由 Amazon 控制的分析体验的输入。

这种区别使该集成既有合作性，也有竞争性。Databricks 提供受治理的数据源，而 Amazon Quick 则成为业务用户使用由此产生的上下文的场所。

该预览版支持用于 Databricks 连接的 Personal Access Tokens 和三方 OAuth。Quick 查询上游系统时，OAuth 还可以保留个人用户身份。

AWS Glue Data Catalog 提供了更为垂直整合的路径。Quick 可以使用服务角色或 AWS IAM Identity Center 进行智能体发现和语义继承。

对于使用 Lake Formation 的客户，可信身份传播可为每位用户执行上游权限。源系统决定该用户可以查询哪些数据。

智能体工作流中的身份传播是可选的。不过，根据治理文档，它仅适用于 DirectQuery 数据集。

如果数据集转为 SPICE 或接受转换，则不会应用该传播的身份。届时，团队必须使用 Quick 自身的行级和列级安全控制。

这一限制很重要，因为治理是产品价值的核心。便捷的发现过程无法弥补团队误解的权限模型。

Microsoft 正通过 Fabric data agents 和 Power BI 语义模型推进相关战略。这些智能体将自然语言问题与受治理的数据源和业务定义连接起来。

Microsoft 的指导强调，答案质量取决于是否为 AI 准备好语义模型。描述、已验证答案和指令有助于智能体正确理解业务语言。

其语义模型指南强化了与 AWS 对策展人提醒相同的教训：当结构化业务上下文已存在时，对话式访问最为有效。

竞争并不只是关于哪个模型能写出更好的 SQL。它关乎谁拥有原始企业数据与提出问题的员工之间的那一层。

目录平台希望治理这一层。商业智能平台希望消费并丰富这一层。智能体平台希望在这一层之上进行推理并发起行动。

Amazon AWS 正在将这些角色连接到 Quick 中。其目录预览减少了治理元数据与最终分析界面之间的摩擦。

不过，Databricks 和 Microsoft 也在加速贴近业务用户。它们无意在另一平台掌握对话式体验时，继续充当被动的元数据提供者。

如果这种竞争能推动可移植的描述、明确的关系以及具备身份感知能力的查询，将有利于客户。但若每个平台都增加难以顺畅迁移的专有语义，则会带来风险。

该预览在架构上最突出的选择，是让上游目录继续作为唯一事实来源。这种做法限制了企业定义出现另一份失控副本的可能性。

其长期价值将取决于变更能否持续可靠地流转。若后续目录更新无法传递至依赖的 Quick 资产，即使一次性继承流程也可能造成漂移。

Amazon Quick 如何构建多数据集 Topic

这一机制之所以可行，是因为 Quick 会将目录对象转换为受约束的分析模型，而不是让代理不受限制地访问所有内容。

Quick 数据集代表选定的目录资产。管理员接受代理建议后，代理可以批量创建其中多个资产。

随后，工作流会通过继承或推断的关系连接这些数据集。这些关系会告诉查询引擎，来自不同表的字段应如何联接。

最终生成的 Topic 为自然语言分析提供了语义容器。它包含解读用户问题所需的数据集、关系、业务定义和指令。

Amazon 最近通过另一项公开预览扩展了多数据集 Topics。根据该公司的语义层概览，一个 Topic 最多可包含 12 个数据集。

查询引擎会解读问题、识别有用的列、沿着已定义的关系进行关联，并构建所需的 SQL，随后返回表格或可视化结果。

这一模型解决了早期 Quick Sight 架构中的一项限制。传统上，数据集会以单个扁平表的形式呈现，每个可视化只能使用一个数据集。

团队通常会在准备阶段将源表联接成大型非规范化数据集。这种设计简化了执行，但使复杂业务领域更难维护。

多数据集 Topics 允许规范化数据集保持独立。语义层描述它们之间的关系，Quick 则在问题需要多个资产字段时构建联接。

例如，一个零售 Topic 可能连接销售、退货、客户、产品、门店和日期。管理者可以询问不同客户细分和产品类别下的退货率。

未必有任何一张表单独包含这个答案。引擎必须选择正确的度量指标，遵循有效关系，并避免因错误联接而导致行数倍增。

目录继承可降低该模型的配置负担。当 Unity Catalog 已记录关系和描述时，Quick 可复用这些信息，而无需人工重复录入。

AWS Glue 提供表和列的描述，而 Unity Catalog 还可以提供关系。该预览的具体能力会因数据源和认证方式而异。

描述只是语义准确性的一部分。Quick 更广泛的增强模型还包括同义词、语义类型、计算字段、排除项和自定义指令。

同义词可以将“headcount”映射到具有技术名称的字段。语义类型可以告诉系统某一列包含货币、日期、城市或州。

自定义指令可以编码财务日历或内部定义。当上游目录元数据缺少特定受众所需的细节时，这些补充仍然很重要。

代理式目录体验加快了初始构建速度，但并未消除后续优化工作。管理员仍需测试真实问题，并检查生成结果。

DirectQuery 也带来了运营层面的权衡。它让数据和权限更接近源端，但查询速度取决于上游平台和生成的 SQL。

SPICE 是 Amazon 的内存分析引擎，可改善导入数据的交互性能。不过，切换离开 DirectQuery 会改变身份传播模式。

因此，团队必须在新鲜度、性能、治理和转换需求之间取得平衡。该预览并未将这些选择收敛为一种普遍正确的配置。

这一机制的价值在于自动化可重复的工作。它可以搜索元数据、创建表示、继承定义，并组装候选 Topic。

更困难的决策仍取决于具体场景。管理员必须选择哪些资产应归为一组、哪些关系是安全的，以及哪些业务定义还需要进一步澄清。

流畅的推荐仍需保持审慎审核

最大的风险并不是工作流明显失效，而是一项看似合理的推荐悄然编码了错误的业务含义。

AWS 明确要求作者审核每一项推荐，包括发现的表、推断的关系以及从源目录继承的描述。

对于推断关系而言，这一警告尤为重要。共享的列名并不能保证两个字段采用相同的粒度、业务范围或更新频率。

客户标识符在一张表中可能代表账户，而在另一张表中则代表计费实体。将它们联接后，可能产生看似可信但实际错误的汇总结果。

基数带来了另一项风险。代理可能识别出技术上有效的联接，却无法预判多对多关系造成的重复。

这类失误很难察觉，因为最终仪表盘可能看起来十分精致。自然语言解释也可能让不确定的答案显得比实际更权威。

管理员需要准备已知结果的测试问题。他们应将 Quick 的输出与可信仪表盘、已批准的查询以及领域负责人的预期进行比较。

审核也应覆盖负面情形。可靠的 Topic 必须知道何时所选上下文无法安全地回答一个问题。

元数据质量仍是另一处压力点。目录中往往存在不完整的描述、过时的所有权记录，以及各业务部门间不一致的命名。

语义继承会保留已有工作，但也会保留已有缺陷。自动化加快了优质和劣质上下文传播的速度。

数据质量评分可帮助对资产进行排序，但单一评分很少能涵盖所有语义问题。新鲜度、完整性和有效性并不能证明一张表能够回答预期问题。

血缘可以显示数据的来源及流转过程，但未必能解释财务和销售为何对同一标签使用不同定义。

预览阶段的成熟度增加了不确定性。在所审阅的材料中，AWS 尚未发布完整“目录到 Topic”工作流的独立准确性基准。

也没有公开证据显示，该功能在不同规模目录中究竟能节省多少管理员时间。因此，关于更快交付的说法仍应视为公司的主张。

跨平台行为同样值得谨慎对待。Unity Catalog 的元数据可以非常丰富，但不同组织的配置和维护方式并不相同。

治理良好的 Databricks 环境能提供比主要由技术模式构成的目录更有价值的输入。该集成无法凭空创造缺失的组织知识。

权限需要经过审慎测试。团队应在多个用户身份下验证结果，而不是假设目录连接就能确保正确执行控制。

DirectQuery 是实现身份传播的必要条件，但身份传播本身是可选的。管理员必须了解每个数据集由哪个控制平面保护。

代理建议的上下文也应在创建后保持可检查性。管理员需要清晰记录所选资产、继承定义、推断关系和手动修改。

若缺乏这种可见性，排查问题将变得更加困难。错误答案可能源自源数据、目录元数据、关系推断、Topic 配置或生成的 SQL。

这并不意味着该预览无法使用。它界定了企业买家应采用的评估标准。

一个有价值的试点应聚焦于具有既定参考答案的单一、范围明确的业务领域。随后，团队可衡量配置投入、修正率和答案一致性。

最理想的结果并不是完全不需要人工参与，而是在保留清晰责任归属和可审计审核路径的同时，实现更快的组装。

随着预览扩展，值得关注什么

三个信号将表明 Amazon Quick 正在成为可信的语义消费者，还是仅仅变成另一处修复元数据的地方。

第一个信号是来自 AWS Glue 和 Databricks 客户的生产反馈质量。团队应关注管理员在无需大幅修正的情况下接受推荐的频率。

在治理良好的目录中持续保持高接受率，将支持 AWS 的机制。频繁替换表或修复关系，则会削弱自动化主张。

仅看原始接受率还不够。客户还需要在多位用户以不同方式表达同一业务问题时，获得稳定的答案。

第二个信号是 AWS 如何处理初始创建后的目录变更。只有当团队能够避免无声漂移地管理更新时，语义继承才具有持久价值。

AWS 应说明修改后的描述、关系、质量信号和血缘是否会流入既有 Quick 资产，也应解释冲突如何被呈现。

可靠的同步将强化上游唯一事实来源模型。手动重新导入会带回该工作流原本承诺减少的大部分维护负担。

第三个信号是 Databricks 和 Microsoft 的竞争回应。两者都已将受治理的数据、语义上下文和自然语言交互结合起来。

Databricks 可以加深从 Unity Catalog 发现到业务分析的自身路径。Microsoft 可以加强 Fabric、Power BI 模型与数据代理之间的连接。

若这些平台改善跨系统可移植性，客户将对消费层拥有更多自主权。若语义仍保持专有，迁移成本将会上升。

在这些信号之外，正式发布将提供另一个实际检验点。买家应关注更广泛的目录支持、已记录的限制、管理控制和可衡量的可靠性。

Amazon AWS 已识别出正确的企业问题。AI 分析不能依赖模式名称和不受限制的目录访问。

该预览也采用了合理边界。代理提出资产和关系建议，而管理员批准哪些内容进入分析上下文。

现在，AWS 必须证明这种分工能够经受真实目录复杂性的考验。流畅的配置对话固然有帮助，但可信的分析需要可重复的验证。

评估 Amazon Quick 的团队应选择一个元数据成熟、答案已知的领域。他们应记录在创建数据集和 Topic 期间所做的每一项修正。

随后，他们应测试权限、关系行为、查询一致性和目录更新。这些证据将揭示该工作流是减少建模工作，还是仅仅将其转移到别处。

更广泛的问题并不局限于商业智能。每个企业代理都需要一座受控的桥梁，连接用户语言与组织的实际信息。

Amazon AWS 现已提供了这座桥梁的一种实现。未来几个月将检验，策展人员能否在不放弃保障企业数据可信度的判断力前提下，更快地跨越它。