作者：Jain Arvind
原文：https://x.com/jainarvind/status/2019553277571190821
场景图谱正迅速成为企业人工智能领域最热门的话题之一，投资者们也对此非常关注。Foudantion Capital的Jaya Gupta和Ashugarg称其为“价值万亿美元的商机”。
这是因为，尽管人工智能模型现在可以使用工具，但它们仍然缺乏真正实现工作自动化所需的流程知识。记录系统可以捕捉决策，但真正起工作的发生在会议、聊天、电子邮件和文档中。如果缺乏对实际工作方式的结构化了解，人工智能就无法可靠地实现自动化。
在各种宣传攻势下，社交媒体上的帖子始终围绕着两个问题：什么是场景图谱？以及如何构建场景图谱？在这篇博客中，我们将详细阐述Glean公司构建场景图谱的方法，并解释我们为什么采取了我们所采取的方法。
什么是场景图谱？
场景图谱是一种模式，它将企业实体（人员、文档、工单、系统）与它们之间操作和事件的时间轨迹连接起来。然后，它从这些轨迹中挖掘出可操作的洞察，使人工智能能够理解工作的实际完成方式。
场景图谱可以帮助人工智能回答诸如以下的问题：
- “P1事件在这里通常是如何解决的？”
- “关于产品 X，最常见的升级问题有哪些？”
- “从‘试点项目启动’到‘交易完成’之间通常会发生什么？”
- “对于这个团队来说，‘入职培训完成’究竟意味着什么？”
- “典型的部署需要多长时间？为什么？”
目前的智能体难以处理端到端流程或长期任务（跨越数周或数月），这些任务需要综合来自多个不同系统的知识。
当将跨越不同事件的多个任务关联起来时，需要整合来自各种来源和众多人员的信息，而每个人执行工作的方式都略有不同，流程中还包含一些局部例外和特殊情况。但记录系统通常只显示当前状态，很少能捕捉到这种执行差异或完整的历史背景，因此依赖这种不完整的视图可能会导致盲点和次优结果。
相反，建立一个组织真实流程的内部模型——一个由实际行动轨迹构建的场景图谱——就成了了解要遵循的结构和工作背后意图的最佳途径。
从“是什么”到“如何做”
场景图谱描述了工作流程，它从描述“存在什么”转变为描述变化“如何发生”：
- “什么”：传统数据和知识系统对事物进行建模：客户、工单、文档、人员、系统。
- “如何”：场景图谱对行为进行建模：谁在哪些应用程序中做了什么，以什么顺序做，以及产生了什么效果。
“如何做”是通过将动作转化为图中的一等实体来描述的：
- 节点：（又称用户和代理操作，包含丰富的数据跟踪）“创建”、“查看”、“批准”、“升级”、“评论”、“解决”，每个节点都带有时间戳和关于更改的丰富元数据。
- 边：边代表因果关系和相关性。“消息 A”以概率 P 触发“更新 B”。
我们选择以这种方式构建 Glean 模型，是为了赋予一系列活动预测能力，从而在不硬编码流程的情况下，预测下一步可能发生的步骤。最终，我们得到一个可能路径的分布图，赋予智能体自主选择最有可能适用于当前场景的路径的能力。
现在，在这些流程路径之上叠加了衍生见解——“路径 A”与“路径 B”不同的原因。这使我们能够不仅编码“如何”，还能编码可能的“为什么”，这些都可以在运行时输入到代理中。
智能体运行完毕后，其行为会成为上下文图的新轨迹。基于这些轨迹的强化学习会评估所选路径是否最优，并识别智能体未来可以采取的其他路径。
我们如何构建上下文图？
投资于深度连接器和可观测性
场景图谱需要深层连接器和可观测性作为基础。如果我们无法了解工作流程，就无法对其进行建模。这意味着需要在文档层面与实际发生工作流程的应用程序，以及结构化数据进行集成，例如：客户关系管理系统、工单系统、聊天工具、文档、电子邮件、日历、代码、仪表盘和内部应用程序。
我们了解每个应用的实际使用方式——例如，Jira 评论很快就会失效，而 Jira 描述中的链接通常是权威链接（例如：文档、设计等）。我们将这些模式捕获到一个集中式数据模型中，然后将其添加到我们的搜索索引中。
接下来，最难的部分是如何长期保持这种模式的健康运行：追踪不一致的 API，协调不同工具之间的身份差异，并不断强制执行内容权限，以确保每个结果都既相关又安全。
几年前，我们开始着手捕获应用程序中的所有变更事件，而不仅仅是文档数据。然后，我们将这些变更事件规范化并作为跟踪信息公开，目的是构建场景图谱。
构建统一的知识图谱
在抓取和索引数据之后，我们运行机器学习流程来构建知识图谱，从而推断出项目、客户、产品、团队和人员等更高级别的实体。我们还会识别它们之间的关系——确定哪些文档、工单、通话和仪表盘属于特定的产品或帐户。
我们会持续输入活动信号（浏览、编辑、评论等），以了解信息的实际使用方式以及用户如何协作。Glean 正是通过这种方式识别 CRM 中的“ACME Inc”和支持工单中的“ACME”指的是同一客户。
这样一来，我们就可以将各项活动整合到同一个规范项目或客户中，从而对实际发生的事情有高度的信心。
这就是为什么知识图谱是上下文图谱的关键基础，因为活动信号本身是嘈杂的，你需要知识图谱作为底层支撑，才能使活动变得有意义。
创建个人图谱
与知识图谱并行，我们构建了一个个人图谱，该图谱能够理解每个人的任务和项目，从而提供主动的个性化帮助。为了构建个人图谱，我们收集并整合活动流和轨迹，将这些原始信号拼接成时间线，并用来自知识图谱的实体对其进行丰富：
- 对于每个人，都会按时间顺序记录其使用各种工具的操作，以及更丰富的元数据。
- 从那里开始，我们将低级事件分组为语义任务。
这就是棘手之处。实际工作往往错综复杂：人们不断切换工作内容，在不同项目中重复使用同一份文档，还会放弃某个任务，几天后再重新拾起。一次“编辑文档”操作可能同时涉及多个并行工作流。
为了理解这一点，我们结合以下几点：
- 简单的信号，例如共享标题、工单和文档之间的链接、会议邀请、频道名称和时间窗口。
- LLM 会观察事件序列并推断，“这个集群看起来像是在调查警报”，或者“这些操作一起看起来像是在起草和推广规范”。
目标是将流程划分成连贯的工作单元——任务和更高级别的项目——以便系统能够进行推理。
目前，我们只分析了一位员工的工作情况。而且，由于我们保护用户隐私，这些数据只有他们自己才能看到。但当我们开始进行汇总分析时，就能发现其中的规律。
创建场景图谱
当我们对流程进行总体分析时，我们会将每个个人图谱规范化为一系列带有粗略标签的匿名“步骤”：
- 操作类型（查看、编辑、评论、升级）
- 工具系列（文档、聊天、工单、代码）
- 涉及的知识图谱实体（事件类型、产品、服务、客户群体）
- 从 LLms 或启发式方法派生的流程标签（例如“investigate_alert”、“draft_spec”、“negotiate_contract”、“onboard_customer”）
- 轻量级时间功能和结果（例如“P1 已解决，MTTR < 30 分钟”或“交易已完成并赢得”）
我们不将原始文本（文档正文、消息文本）、用户标识符或客户特定密钥带入抽象跟踪中。然后，我们计算抽象跟踪之间的相似度，以确定哪些跟踪可能涉及相同的过程。
此外，我们只将至少在k 个不同的用户和n 个独立的轨迹中出现的模式视为可行的模式，任何过于罕见的模式都会被舍弃以保护匿名性。
这样做，我们就构建了一个关于“通常会发生什么”、“按什么顺序发生”以及“为什么这条路径与其他类似路径有所不同”的概率视图。然后，我们利用时间来确定流程的价值。如果类似的用户群体完成某个流程需要花费大量时间，那么它很可能是一个高价值流程。这就构成了系统的上下文图——代理在遇到类似情况时可以依赖的“剧本”。
在构建此图的过程中，我们权衡了多种存储事件数据以供遍历的方法。纯粹的图结构过于僵化；原始文本虽然灵活，但难以导航。因此，我们采用了一种混合模型：将自由格式的文本分割成更小的块，并在其中嵌入实体 ID。
例如，一个事件会被分解成若干个短片段，这些片段通过添加诸如incident_id=INC-123、channel_id= 之类的 ID 标签来标记状态转换——从“调查”到“缓解”。#p1-incidents ，或action_type=escalated 。这可以让代理在清晰的指导下逐步完成流程，但缺点是它不适用于一次性处理数千个事件。
从智能体轨迹中学习
最后一步是利用智能体执行来闭合闭环。如果代理在这个系统之外运行，图就永远无法从中学习。如果它们在系统之内运行，那么每次代理运行都会成为一条新的轨迹：
- 它调用了哪些工具，调用顺序如何，以及使用了哪些输入和输出。
- 运行是否成功完成、运行效率如何，以及用户对响应的投票结果（赞成或反对）。
所有这些学习都是按企业划分范围的，并且侧重于代理如何使用工具，而不是存储底层内容。
离线状态下，我们会重放并尝试其他路径。我们会根据正确性、完整性、指令遵循性和效率对这些备选方案进行评分。我们处理这些智能体轨迹的方式与处理人类轨迹的方式相同：
- 成功的运行会强化你希望系统偏好的模式，使其成为自然语言的行动指南。
- 需要干预的运行结果凸显了反模式，这些反模式需要更多上下文信息或更好的工具使用。
随着时间的推移，场景图谱会逐渐演变为人类和智能体行为的联合模型。它不仅描述了过去工作是如何进行的，还反映了随着人类和智能体越来越多地参与工作，如今工作是如何展开的。
因此，场景图谱必须由数据层和编排层共同维护。对于高价值流程（例如事件响应、销售交易和产品开发），两者都不可或缺：一个上下文层用于捕获企业结构化的、流程感知的模型，另一个执行层则负责规划、迭代和生成跟踪信息。如果将二者分离，就会造成偏差：上下文图朝着一个方向演化，代理执行朝着另一个方向演化，最终导致两种截然不同的现实版本。
将图表和编排放在一个系统中，可以确保智能体始终了解企业实际运作方式的实时、不断发展的模型。
在 Glean 构建场景图谱
构建场景图谱是一项巨大的投入，因此我们在实际构建之前先进行了内部测试。我们利用已有的技术——个人图谱——手动为 Glean 创建了一个场景图谱。
我们邀请 Glean 的员工选择分享他们的个人流程图数据，这些数据记录了他们参与的项目、执行的步骤顺序以及花费的时间。通过时间这一要素，我们能够区分低价值流程和高价值流程。然后，我们分析了哪些团队拥有相同且重复的高价值流程，例如“AE 中端市场交易周期”、“SE 概念验证”、“值班事件响应”、“PM 功能发布”等等。
我们梳理了这项工作的流程，并与领域专家验证了A路径和D路径在完成工作中的优劣，以及偏差出现的原因。我们还审视了自身存在的盲点，即由于数据抓取不足或缺乏支持特定步骤的操作而导致的遗漏步骤。随后，我们投入资源，将这些高价值流程（经过Glean和客户需求的双重验证）转化为可在Glean中实际运行的代理。
虽然这些代理最终会成为当前状态的静态表示，但这并非我们的最终目标。我们想要的是上下文图。因为最优路径会不断演变，所有权会变更，新的工具会不断涌现等等。我们构建上下文图的目标并非仅仅是生成一组静态的代理，而是要不断地从上下文图中为代理提供新的流程洞察，并将更多的逻辑推入到学习层中，而不是持续依赖手动指令。我们相信，这才是实现长期自主运行代理的关键。在 Glean，我们正朝着这个目标迈进。