周一早上9点，有人从财务团队离职。你的同步任务在凌晨2点照常运行。接下来的17个小时里，这个人依然能从检索索引中拉出财务文档，系统里没有任何机制知道这不对劲。

这个例子借自Truto，但几乎每个我聊过的团队都能对号入座。这是带时钟的版本。安全评审里被问到的版本听起来不太一样：检索试点跑通了，演示成功了，高管赞助人很满意，然后有人问——你怎么保证这东西永远不会把CEO的薪酬评审报告，总结给一个随口问薪资区间的新实习生？

打开网易新闻 查看精彩图片

大多数团队没有答案。他们有的只是一个过滤器。我认为答案必须是结构性的。

权限不是过滤器

权限不是你在组装完上下文之后套上去的过滤器。它是上下文如何为特定身份组装出来的一个属性——因为组装是最后一个时刻，拒绝包含某样东西，仍然意味着模型从未看到它。

这个赛道上的主要平台厂商都在构建某种相同步骤，但没人真正给它定下名字。我经营的公司Modus就在这个领域做产品，所以请带着这个背景来权衡我的论点。在我们的产品里，我们称之为上下文组合（context composition）。在这篇文章里，我称之为上下文组装（context assembly）。

这是系统决定把哪些企业知识交给模型的地方——为特定的人、在特定的时刻、针对特定的问题。上游一切都是存储，下游一切都是推理。组装就是身份要么存在、要么不存在的那个节点。

宣布不等于上线

为什么要在9月而不是6月争论这件事？因为平台厂商已经不再争论这个步骤该放在哪里，而大多数公司运行的软件还没跟上他们。

AWS在6月做了最明确的表态，在纽约峰会上发布了AWS Context。底层的设计决策才是真正有趣的部分。图谱由与数据湖相同的权限治理——通过Glue Data Catalog、SageMaker Unified Studio和Lake Formation——当有人发起请求时，身份会被再次检查。

负责治理它的人，就是已经在治理其他一切的人，用的是S3对象权限单独无法提供的列级、行级和单元格级策略。

这里值得精确一下时态，因为转述已经模糊了它。每次提到都是“设计为继承调用用户的IAM和Lake Formation权限，因此代理只能看到和遍历其身份被授权访问的关系”。

“设计为”。这是路线图语言。将近三个月过去了，AWS Context仍然显示为“即将推出”，没有GA日期，没有区域列表，没有定价。