大家对场景的理解都是错的

作者：Gil Feig

原文：https://x.com/GilFeig/status/2009683673558462584

最近很多关于“场景图谱”的文章都在绕圈子，多聚焦于结构化布局与功能实现。这些文章固然有用，但却忽略了在实际生产环境中实现场景的难点所在。

场景信息并非存在于整齐的文档堆中，而是存在于其他系统中，通常是别人的系统。例如，你的客户关系管理系统（CRM）、你的工单系统、你的数据仓库、你的计费系统、日历、Slack 工作区等等。十种不同的 SaaS 工具，每种都有自己的身份验证模型、流量限制和各种奇特的数据特性。

因此，在生产环境中真正重要的场景图谱并不是你绘制的一次性图表，而是一个运行时系统（Runtime System），需要对一个请求一个请求地做出实时决策：

• 要咨询哪些系统
• 是调用 API 还是使用缓存数据
• 来电者是否有权查看结果
• 如何将结果拼接成模型可以使用的东西

如果要给场景图谱下一个可操作的定义，那应该是这样的：

协调层是真正需要进行复杂工程的地方。同时，大多数关于“场景图谱”的文章也往往对它语焉不详，因为各类集成过程迫使你在公开场合做出权衡取舍。

为什么不只是一个知识图谱

有些场景图谱的编写方式类似于知识图谱2.0（Knowledge Graph2.0），只是在上面添加了一些额外的元数据，两者之间存在重叠，但目的不同。

传统的企业知识图谱往往以正确性和持久性为优化目标，它们以稳定的方式对实体和关系进行建模，通常基于三元组式表示（主语、谓语、宾语）。

场景图谱（至少是与LLM产品相关的版本）在约束条件下优化了可用性：

• 时效性（Timeless）：
  指本周的情况，而非普遍情况。
• 受众（Audienc
  e）：用户看到的内容，而不是所有存在的内容。
• 成本（Cost）：
  值得获取的东西，而不是能够获取的东西。
• 可追溯性：
  事后可以用作为证据的内容，而不是“听起来正确”的内容。

有一种研究思路将“场景图谱”定义为知识图谱加上时间有效性和来源等额外场景信息，这种思路方向正确，但更大的转变在于操作层面：一旦你承认时间、来源和权限是首要因素，你就不再是在构建静态图谱，而是在运行一个场景组装系统。

集成是导致这种转变不可避免的关键因素。内部文档索引可以让人误以为所有内容都易于访问且成本低廉，但 Salesforce的API 却无法做到这一点，工单系统会限制你的访问速度，用户的 OAuth 令牌会过期，工作区管理员会撤销权限。

真正的核心：智能数据选择

一个必须认识的行业事实是：场景图谱最重要的职责，是决定剔除哪些冗余信息。即使你没有把它们写下来，每个用户请求都附带一定的预算：

• 延迟预算： 响应阈值是 300 毫秒还是 3 秒？
• 成本预算： API 调用与 Token 消耗并非零成本。
• 速率预算： 跨用户共享的每分钟调用频率上限。
• 信任预算： 有些来源是噪音来源，有些是权威源。
• 注意力预算： 模型在感知模糊前能承载的上下文带宽。

总是抓取“所有相关信息”的场景图谱并不是先进的表现，成本高昂、速度慢，而且通常会因为塞入大量平庸的上下文信息而使答案变得更糟。

选择既是一个排序问题，也是一个协调问题，一个完善的系统会提出诸如此类的问题：

• 我是否需要访问客户关系管理系统（CRM），还是可以从上次已知的快照中获取答案？
• 这个问题是询问某个时间点的状态（需要实时状态）还是策略状态（缓存状态即可）？
• 我是否应该先获取排名第一的资源，然后再决定是否需要更多资源？
• 如果某个集成出现故障，优雅的回退方案是什么？

这就是“图”变成“控制平面”的地方，图是你对已知信息的内部表征，选择引擎则是你现在选择了解的信息。

如果你想要一个具体的思维模型，可以把场景想象成一个有严格消费限额的购物车，你添加的每件商品都有一个价格：毫秒、token、配额和风险，一个好的场景图谱会非常注重细节。

场景的三个层级：实时、缓存、派生

一旦开始集成第三方系统，最终会遇到三个实际层面的场景。你可以假装没遇到，但最终还是会遇到。

1）实时 API 调用

最适合：当前状态、快速变化的数据、任何高风险的情况。

例如：“Acme的续约状态如何？”“那张发票付款了吗？”“该事件是否仍未解决？”

优点：最新鲜、最可靠。

缺点：速度慢、价格昂贵、需要大量身份验证、脆弱。

实时调用是权限检查的难点所在，因为访问权限通常取决于用户的令牌，而不是应用程序的服务帐户。实时调用也意味着你需要付出协调成本：重试、超时、退避、部分响应、模式漂移等等。

2）本地缓存或快照

最适合：数据会变化，但不是每分钟都在变化，并且需要快速获得答案的情况。

例如：账户摘要、开放机会列表、“最近 20 个工单”、组织结构图。

优点：速度快、成本低、结果可预测。

缺点：可能过时，需要失效应对策略。

缓存不仅仅是一种优化手段，更是一种设计选择，它迫使你定义“新鲜度”。“足够新鲜”需要明确定义，而不是隐含的约定。这通常意味着需要采用基于时间的 TTL（生存时间）机制，并在条件允许的情况下加上基于事件的失效机制（例如 Webhook、变更流）。

3）衍生场景（摘要、嵌入、先前结论）

最适合：浓缩和检索，尤其适用于大量文本。

例如：工单线程摘要，“与上周相比发生了哪些变化”，提取的实体和关系，文档的语义索引。

优点：查询时成本低，可扩展性好。

缺点：有损数据，数据老化后性能可能较差，容易误用。

很多团队都会在衍生场景上栽跟头。他们存储一个摘要信息，并将其视为真理。然后，底层对象发生了变化，权限发生了变化，或者用户提出了一个需要精确的细节，而这些细节信息已经被摘要舍弃，这是问题就会暴露出来。

成熟的场景图谱会将这些层级视为阶梯，从低成本的信号开始，只有在必要时才会使用成本更高的信号源。它也知道何时应该放弃，因为“更多”并不总是更好。

一个简单有效的选择模式

对于许多生产流程而言，简单直接的策略胜过花哨的启发式方法：

1. 首先使用缓存的、域化的上下文（速度快，权限安全）。
2. 如果把握不大或注重新鲜感，则对收益最高的整合方案进行一次实时通话。
3. 当有足够的信息来回答问题时，就应该提前结束。
4. 只有当请求需要时，才拉取更复杂的上下文（完整的线程、大型文档）。

重要的不是顺序，而是场景图谱对成本和新鲜度有明确的策略，而不是让每个查询都分散到十几个集成中。

溯源和可追溯性：被忽略的部分

一旦第三方数据被纳入参考，溯源就不再是“锦上添花”的功能了，它决定着系统是可以在生产运行的，还是你还不敢发布的。

至少，传递给模型的每个场景节点都应该能够回答以下问题：

• 这是从哪里来的？（系统、对象 ID、端点）
• 我们是什么时候获取的？（时间戳）
• 依据何种身份和权限？（用户令牌还是服务令牌，权限范围）
• 它是否经过转换？（总结、提取、合并）
• 什么情况会导致它失效？（生存时间、Webhook事件、权限变更）

这不仅仅是为了审计，虽然审计肯定会发生，它也是为了调试。

当模型给出错误答案时，第一个问题几乎从来不是“为什么模型会这样做？”，而是“我们给它展示了什么？”

如果没有可追溯性，你就无法回答这个问题，你无法重现运行过程，因为你不知道使用了哪些数据源。你无法修复错误，因为你不知道哪个节点的数据过时了。你无法解释这种行为，因为你无法追溯到系统当时的判断。

此外，还存在信任问题。人们越来越善于识别千篇一律、过度修饰的文本，并对其抱有怀疑态度。研究人员甚至发现，一些特定的“人工智能偏好”的措辞正逐渐渗透到人类语言中。在这种环境下，建立信任的方式并非依靠自信的文笔，而是提供有理有据的答案，而有理有据的答案需要可追溯的信息来源。

还有一个原因：权限漂移（Permission Drift）。

集成是权限的表层，用户可能会失去对某个文件夹的访问权限、离开 Slack 频道、CRM 角色被更改，或者撤销 OAuth 授权。如果没有为存储或派生的数据附加权限场景，则很容易通过缓存或汇总节点意外泄露数据。

出处可以防止“我以前被允许看到这个”变成“助手仍然记得它”。

实际情况是什么样的

假设用户提出以下问题：

请用一段话简要汇报 Acme 的最新情况，包括续约风险和最近一次的客户支持互动情况。

围绕集成构建的场景图谱可能会执行以下操作：

• 检查 Acme 的缓存“帐户摘要”节点（新鲜度窗口：15 分钟）。
• 如果信息缺失或过期，调用CRM 获取商机阶段和续订日期（实时）。
• 查询工单系统以获取上次交互记录（实时或缓存，取决于服务级别协议）。
• 只调取最近 5 张工单，不调取全部历史记录。
• 生成包含以下标签的工单摘要：
• 源工单 ID
• 获取时间戳
• 用于访问的用户身份
• 将最终上下文包与来源元数据组装在一起。
• 生成更新，并在内部保留可链接的跟踪，以便可以回答“你为什么这么说？”

价值不在于你拥有了一张图表，而在于你做出了严谨的选择：小规模的拉取、权限感知的获取、每一步都记录了溯源信息。

这就是演示系统和可实际操作的系统之间的区别。