[音乐]

大家好，听得见吗？很好。由于只有20分钟时间，我们将进行一场快速演示。我是来自Unblocked的Peter。在Unblocked，我们构建上下文引擎（Context Engine）。接下来我将展示几项内容：首先介绍什么是上下文引擎及其为组织带来的价值，然后我们将实际构建一个组件，并推荐一些开源项目供会后体验。议程包括：什么是上下文引擎、如何创造价值以及动手构建环节。

让我们回顾几年前的AI代理时代之前，那时你是组织的“上下文层”。想象你是一名新员工，试图了解组织现状。通常你需要浏览大量代码、搜索文档系统以获取工作所需信息，还要处理通过历史事件积累的组织记忆和“战斗伤痕”。上下文引擎的作用是将这些机构知识整合，将分散的输入转化为接地气的、相互关联且特定于意图的个人化上下文。

假设我在Claude中演示，未连接上下文引擎时，我要求制定优化“Source Mark Engine”组件的计划。Claude像新员工一样，起初不了解代码库或组织背景，它会先探索代码库并自信地给出建议。但当后端连接Unblocked上下文引擎后，它调用引擎获取全面且任务特定的上下文包。这不仅包含源代码，还涉及Notion架构文档、拉取请求（PR）以及关于优化该组件的Slack对话，形成紧密关联的上下文链接。

有趣的是成本差异：使用上下文引擎耗时约1分30秒，花费29美分；而不用则需3分钟，花费高达2.60美元。这实现了惊人的50%成本降低。接下来展示同事Richie与Unblocked的有趣互动：我们的代码审查产品发现报错数量下降，他询问引擎后迅速定位原因为模型从Opus 4.6切换至Opus 4.8导致行为变化。Richie要求修复，引擎在后台生成PR并自动解决。

更令人惊叹的是，引擎理解了最初导致回归的PR，找到相关Slack讨论并提取数据以指导修复。抱歉，我好像切错了演示文稿……让我们回到正题。代理同样面临成本问题。我们将直接进入构建环节，因为时间紧迫。总结来说：上下文分散在PR、评论、Issue、文档和对话中，虽可语义查询但缺乏结构。RAG擅长内容检索（如找代码、PR或Slack线程），若结合代理循环和文件搜索工具，功能强大。

然而RAG无法处理结构性查询（如“上周合并了哪些PR”、“谁审查的支付代码最多”）。这些不是语义搜索，而是基于时间或统计结构的查询。以Richie为例，他询问“自1月1日以来的周比率图表”。向量存储无法编码此类信息，必须通过查询引擎处理。检索分为语义和结构化两部分：前者处理基于含义的问题，后者将自然语言转化为结构查询。生成查询本身不难，难点在于其周围的脚手架工作。

你需要理解Schema以便传递给LLM以生成紧密绑定的查询，还需要能够映射……

身份识别问题：如果我问“由 Rashene 提交的 PR”，模型可能不知道 Rashene 是谁，因为他在 GitHub 上的身份标识可能完全不同。因此我们需要某种映射机制。从 LLM 输出的查询是不可信的，它可能包含危险的操作或跨越租户边界，所以必须验证其正确性和安全性。此外，即使经过验证仍可能出错，我们可以让 LLM 在遇到错误时尝试自我修正。我们的目标是实现这一流程：输入“由机器提交的 PR”，后端生成相应的查询语句。

接下来展示开源仓库 Document Query Engine 的启动过程。首次运行时系统未连接，无法产生结果，我们将逐步构建功能。首先讨论自动模式发现（Automatic Schema Discovery），这是一种完全动态的技术。虽然并非所有数据库都支持，但原理相同：在运行时通过采样文档存储中的大量数据来推导模式。

该技术的一个难点在于推断枚举类型（Enums）。虽然可以用 LLM 作为“重锤”来处理，但传统过程化方法往往就能做得很好。这类工作实际上是确定性的，不必总是依赖 LLM 处理看似非确定的任务。发现模式后，我们演示了从 GitHub 集合中提取 PR 的模式及索引信息，这有助于提升查询性能。

下一步是身份解析（Identity Resolution），即将用户名映射到真实身份，这同样可以通过简单的过程化技巧解决。Unblocked 在底层对不同系统的用户名进行模糊匹配，必要时可将候选名单交给 LLM 作为最终裁决者。

在展示核心功能前，最后一步是合成（Synthesis）。这是相对简单的部分：结合动态解析的模式、当前时间以及提问者信息，让 LLM 合成查询语句。例如，系统能区分“我的 PR”和特定用户的 PR。LLM 生成的查询结果随后被送入引擎执行，拉取文档并生成最终数据。

最关键的一步是验证（Validation）。查询可能包含危险操作符，如在数据库服务器执行原始 JavaScript 的函数操作符。此外，可能需要隐藏特定字段（如包含租户 ID 的元数据），以确保查询隔离并防止 LLM 访问或推导这些字段。通过在后台注入约束，可以安全地限制交互范围。

我们演示验证步骤的效果：当询问“标题包含认证的 PR”时，系统可能尝试使用正则表达式。验证引擎会拦截并拒绝此类操作，因为不被允许。面对错误，我们将错误信息回传给 LLM 进行自我修正。这在技术上只是一个带有最大重试次数的循环过程。

再次尝试后，虽然经历了几次迭代才成功，但 LLM 最终调整了策略。然而，它受限于使用精确匹配（match），导致未找到结果。因此需要引入全文搜索功能。加入全文搜索后，引擎能够更准确地处理此类查询，最终成功返回了预期的结果。

整个过程从开始到结束演示完毕，代码完全开源，可供查看和体验。我们构建了一个能有效处理 RAG 中结构性数据另一半问题的系统：支持过滤、聚合、时间范围限定及自我修正。更酷的是，它还能驱动聊天代理：例如询问“上周我们在认证方面做了哪些工作”，系统即可回答。

现在，你会看到整个流程的展示，它清楚地显示了正在执行的操作以及生成的所有查询。目前系统已经获取了数据，并在后台进行推理分析。看，就是这样。非常酷！现在你拥有了可供智能体和人类使用的结构化可查询上下文。

接下来还有最后一件事。在描述中你可能看到了，我们承诺提供一个上下文引擎模拟器。如果你因为环境限制而不想立即接入 Unblocked，我们可以使用一个开源项目来完全在本地自行实现这一功能。

其思路是：针对每个任务创建上下文包，然后利用该上下文包对同一任务进行 A/B 测试，展示让智能体随时获取所有上下文的益处。如果你需要相关代码，这是对应的 PR 链接。

好了，最后一件事：想要椰子吗？欢迎来展位看看。谢谢。