在这篇文章中，我们将探讨Meta如何演进数据仓库架构，以提升人类用户和AI智能体的生产力与安全性。我们将详细介绍如何开发智能体来协助用户提交数据访问请求、帮助数据所有者处理请求并维护安全。我们还将分享如何通过审计和反馈系统等防护机制，确保智能体在设定边界内运行，并评估整体流程。
作为离线数据系统的一部分，Meta运营着一个支持分析、机器学习和AI用例的数据仓库。鉴于数据量庞大、系统规模巨大以及构建在其上的多样化用例，数据仓库的安全性至关重要。Meta的各个团队既管理访问权限，也在日常工作中使用这些数据。随着规模持续增长和数据访问模式日益复杂，管理访问的复杂性和获取访问所需的时间不断增加。我们如何最小化安全风险并提升团队运营效率？随着生成式AI和智能体的兴起，我们需要重新思考如何利用智能体增强安全性和生产力，使其成为内部数据产品的核心组成部分，既能简化数据访问又能降低风险。
背景
过去，我们通过将数据仓库组织成层次结构来扩展数据访问和管理，如图1所示。该层次结构的叶子节点是表，由流水线生产并由仪表板消费。值班人员管理这些资产，其次是团队和组织层级。通过基于角色的访问控制，我们进一步将业务需求建模为角色，与该层次结构及其他维度（如数据语义）对齐。
然而，随着AI的发展，及时访问数据变得越来越重要。随着数据仓库规模持续增长和数据访问模式日益复杂，管理和获取访问所需的时间和复杂性持续增加。
图1：资源层次结构中的数据仓库
为了理解我们传统上如何处理这一问题以及为何这变得越来越具有挑战性，将Meta离线基础设施中的数据流可视化为图很有帮助，如图2所示。该图中的每个节点是一个资产（如表、列或仪表板），每条边代表一项活动。
传统上，当大部分数据分析由规则驱动时，该图是高度分区的，所有数据访问决策都是局部的。想要使用数据的工程师可以通过询问队友或查看他人代码来发现数据。在访问审批方面，访问权限可以授予紧密相关团队的成员。但随着AI系统处理数据图不同部分数据的能力增强，这种由人类驱动的决策变得具有挑战性。
图2：作为数据图的数据仓库
图3说明，随着人类和智能体更频繁地跨领域工作，系统复杂性在数据规模和访问动态性方面均增加，AI是这些复杂访问模式的主要驱动因素。但我们相信AI也能为这些挑战提供解决方案。随着AI的最新进展，特别是智能体的发展，我们需要将先前的方法演进为数据访问的智能体解决方案。此外，虽然系统最初是为人类操作并服务于人类和服务而设计，但我们需要使其适应智能体与人类协同工作。新的智能体工作流必须原生集成到数据产品中，并创造流畅的体验。我们还必须创建严格的防护机制，例如基于分析规则的风险评估，以保护智能体。
图3：扩展和简化数据访问的挑战
用户与所有者智能体
我们将解决方案建模为一个多智能体系统，如图4所示。数据用户智能体协助数据用户获取访问权限，而数据所有者智能体帮助数据所有者管理访问。当双方都参与时，这两个智能体也会协作以简化流程。我们有意分离这两个智能体以分解问题，使每个智能体都能有各自的专注点。
图4：如何为智能体解决问题建模
仔细查看图5中所示的数据用户智能体。它不是一个单一实体，而是由三个专注于特定独立任务的专用子智能体组成，并由一个分流智能体协调。
图5：数据用户智能体
第一个子智能体建议替代方案。例如，当用户遇到受限表时，通常有其他选择，包括不受限或限制较少的表。该智能体还协助用户重写查询以仅使用非受限列，或利用精选分析。这些见解通常是隐藏的或被视为部落知识。大型语言模型和智能体使我们能够综合这些信息并大规模指导用户。
第二个子智能体促进低风险数据探索。通常，用户通常只需要访问表的一小部分数据，尤其是在分析工作流的数据探索阶段。该子智能体为低风险探索提供上下文感知、任务特定的数据访问。我们将在下文深入探讨。
第三个子智能体通过 crafting 权限请求并与数据所有者智能体协商来帮助用户获取访问权限。目前，我们保留人工干预进行监督，但随着时间的推移，我们期望这些子智能体将更自主地运行。
数据所有者智能体也由几个子智能体组成，包括一个处理安全操作的和一个协助访问管理的，如图6所示。
图6：数据所有者智能体
第一个数据所有者子智能体专注于安全操作，就像一个协助团队处理安全任务的初级工程师。它遵循数据所有者提供的标准操作程序（通常源自文档化的规则或指南）来处理传入的权限请求。
第二个子智能体主动为团队配置访问规则。这代表了传统角色挖掘过程的演进，智能体使我们能够更好地利用语义和内容。
面向智能体的数据仓库
正如我们开头提到的，我们将数据仓库组织成层次结构以扩展访问。我们如何通过智能体系统来演进它？
LLM通过文本进行通信。数据仓库的层次结构提供了一种将仓库资源转换为文本的便捷方式，很像嵌套的文件夹结构，如图7所示。这里，组织单元表示为文件夹，而叶子节点（如表、仪表板、策略或其他实体）表示为资源。这为智能体提供了数据仓库的只读摘要视图。我们之前讨论的SOP（记录了来自规则、Wiki和过去交互的数据访问实践）成为一种可以用文本格式表示的资源。它作为数据用户智能体指导用户和数据所有者智能体管理访问的输入。
图7：作为资源的数据仓库
除了组织输入供智能体使用外，另一个关键方面是上下文管理。这里，我们区分了三种场景，如图8所示。第一种场景称为“自动上下文”。想象数据用户发现了他们想要访问的数据，却发现访问被控制措施阻止。系统知道谁在尝试访问什么，允许智能体获取确切的上下文。第二种场景是“静态上下文”。当用户选择明确关注特定范围或将资源从自动上下文扩展到更广泛的范围时，就会发生这种情况。最后一种场景是“动态上下文”。它允许智能体通过元数据（如数据语义）或通过相似性搜索进一步过滤资源。
图8：上下文管理
另一个关键领域是意图管理。在数据访问的上下文中，我们通常称之为“业务需求”。是什么驱动数据用户访问某些资源？如图9所示，我们通过两种方式对用户意图进行建模：显式和隐式。
图9：意图管理
在显式意图管理中，用户明确向系统传达他们的意图。例如，当使用某些数据工具访问数据时，他们可以通过承担一个关联角色来告知系统他们当前的任务，该角色带有业务需求的上下文。这种方法捕获标准意图。
第二种是隐式意图。并非所有意图都能通过角色建模。这就是动态意图的用武之地。系统从数据用户在短时间内的活动推断意图。例如，如果数据用户在午夜被叫醒处理流水线故障，任何后续的数据访问都可能与解决该问题相关。
深入探讨：部分数据预览
现在，让我们深入探讨所有这些元素如何结合在一起，实现一个完整的端到端用例，我们称之为部分数据预览。
快速回顾一下：在我们的数据访问智能体解决方案中，我们有协助数据用户获取访问权限的数据用户智能体，以及帮助数据所有者管理和操作数据访问的数据所有者智能体。通常，数据用户的工作流从数据发现开始，然后是数据探索，之后才进入全面的数据分析。在探索阶段，通常涉及少量数据暴露的交互。那么，我们如何在这个数据访问阶段实现更多任务特定、上下文感知的访问？
为了使系统端到端无缝工作，一个智能体工作流协调了四个关键能力（如图10所示）：
- 上下文：我们分析数据用户活动和其他信息，以理解驱动数据访问的业务需求，并将其与数据控制对齐。这使我们能够提供任务特定、上下文感知的控制。
- 细粒度查询级访问控制：我们分析查询的形状，例如是否涉及聚合或随机抽样。
- 数据访问预算：根据员工通常访问的数据量为其分配数据访问预算，这个每日刷新的预算是我们的第一道防线。
- 基于规则的风险管理：我们采用基于规则的风险控制。这防御了对AI智能体的攻击或故障。
图10：部分数据预览概述
图11说明了系统架构的工作原理：数据用户智能体利用用户活动工具收集用户跨各种平台的活动，包括差异、任务、帖子、SEV、仪表板和文档。它还使用用户配置文件工具获取配置文件信息。利用这些数据，数据用户智能体根据用户的活动、配置文件和查询形状制定用户意图，然后调用数据所有者智能体。数据所有者智能体介入分析查询，识别正在访问的资源。然后获取与这些资源相关的元数据，如表摘要、列描述、数据语义和SOP。数据所有者智能体利用LLM模型生成输出决策及其背后的推理。输出防护确保决策与基于规则的风险计算一致。
图11：部分数据预览架构
所有决策和日志都安全存储，以供将来参考和分析。虽然这些构建模块中的许多对某些人来说可能很熟悉——毕竟，我们使用查询分析器已有数十年——但这是我们首次利用LLM的语言和推理能力为数据用户和数据所有者构建多智能体系统。LLM在这一领域显示出潜力，因为业务需求通常是上下文和任务特定的，难以通过分析建模。LLM使我们能够深入探究这些细微差别，而智能体帮助我们构建动态的端到端工作流。同时，我们采用防护机制，例如基于分析规则的风险计算，以确保智能体在设定边界内运行。在整个决策过程中，我们还高度重视透明度和追踪。
下面的图12显示了评估过程。评估是开发智能体解决方案中最关键的步骤之一。为了评估系统的准确性、召回率和其他性能指标，我们使用真实请求策划了一个评估数据集。这涉及编译历史请求、收集用户活动和配置文件信息、将它们与查询运行关联，然后使用这些数据进行评估。我们每天运行评估过程以捕捉任何潜在的回归。
图12：部分数据预览评估
我们还为该过程开发了一个数据飞轮，如图13所示。这意味着数据用户的查询、智能体的处理轨迹、上下文和最终输出都安全存储，以供反馈和审计。此外，我们为数据所有者创建了一个数据工具，允许他们查看和审查决策并向我们提供反馈。这种反馈帮助我们更新评估并评估整体过程。
图13：部分数据预览反馈循环
未来展望
要实现智能体就绪，我们面前还有大量工作。以下仅是几个例子。
首先，智能体协作。我们越来越多地看到不是用户直接访问数据，而是智能体代表他们行事的场景。我们如何以最有效的方式支持这些用例？
其次，我们的数据仓库和工具最初是为员工或服务构建的，而不是为智能体。我们如何继续演进它们，以便其他智能体能够有效使用？
最后，评估和基准测试很重要，我们需要持续发展这些领域以确保我们保持在正确的轨道上。