스크립트
00:00:00大家下午好。希望大家在AIE度过美好的一天。今天天气很棒，
00:00:17不过紫外线指数高达9左右，希望大家都涂了防晒霜，
00:00:20做成熟稳重的大人。我今天要和大家探讨的是上下文
00:00:24工程。我很荣幸能接着领英（LinkedIn）AJ的发言继续讲，因为他
00:00:27详细介绍了我们实际设计并出售给其他解决方案的系统，
00:00:29而我会分享一系列开源工具。如果你听了我前面那场演讲，
00:00:33你就会拿到一套可以自己动手尝试的工具链，
00:00:36我今天也会教大家许多实用技巧。我们的目标当然是
00:00:39修复……你说得完全没错。我想他们现在已经把这句话从
00:00:44提示词里删掉了，所以现在只会显示“你说得对”或者其他内容，但我确信
00:00:47大家都有过这种体验。我是布兰登（Brandon），来自Unblocked。没错，我拿了一个椰子，我们一直
00:00:53把这些送出去，代表新鲜的上下文、新鲜的椰子。不过我想和大家
00:00:57探讨的是，对于这些模型，尤其是像Claude这样的模型——
00:01:01我想Claude 5今天就要回归了，所以他们说你可以看我的语音通话
00:01:05录音尝试预定这个，我们先不管它。但我希望大家思考的是，
00:01:11在使用这些工具时，AI生成的代码应该让人感觉像是
00:01:15一个在你们团队待了多年的老员工写的。为了进入这种思维状态，
00:01:23你必须考虑到，你曾经就是那个上下文引擎。你是怎么做到的？
00:01:27你通过去公司上班、提问、提交PR并被拒绝、
00:01:34开会等经历，一点一滴、日积月累地构建出了
00:01:39充当大脑的引擎。你理解这里的运作方式，你知道事情是如何发布的，
00:01:42也记得那天晚上生产环境崩溃时你在值班以及故障发生的原因。问题在于，
00:01:48这些代理（Agents）也面临着完全相同的问题：每次你为代理
00:01:53创建一个新的终端会话时，它虽然非常聪明，却对你公司的
00:01:57运营方式没有任何上下文，所以它必须想方设法获取这些信息。问题是，
00:02:02如果你在一开始就弄错了，随着这些代理的规模扩大，成本也会随之成倍增加。
00:02:07我们要利用好上下文和内容。我们先解决这个小问题，
00:02:13因为大家可能想拍些照片。太棒了。那个上下文问题将会
00:02:20不断累积。所以在最左边，大家都还记得两年前那个
00:02:25古老的时代，当时我们有非常酷的代码补全模型。
00:02:29发生的情况是，它弹出来说：“嘿，你想用Tab键补全这个吗？”然后你迅速在脑海中
00:02:32结合上下文心想：不，这写得太烂了。或者你觉得：太棒了，直接按Tab。很好。
00:02:37随着我们沿着代理化（Agentic）的采用曲线前进，情况会变成怎样呢？你会进入
00:02:41更多这样的场景：代理在没有人类参与的情况下运行，或者至少你希望
00:02:46自己不必参与其中。它们需要某种方式，
00:02:50在遇到瓶颈时能够提出所需的问题，以便编写代码、
00:02:54解决问题或基本上修复问题，并最终输出可以合并到
00:02:58代码库中的代码。这里有许多人其实都在维护历史遗留代码库（Brownfield），
00:03:02这些代码库已经存在很长时间了，支撑着真正的业务营收，
00:03:06而不仅仅是全新的趣味项目。因此，如果一开始就带有糟糕的上下文，其成本累积起来就会很高。
00:03:12如果你把这比作“左移”（Shift Left）概念——尽早发现缺陷或漏洞，
00:03:17你就会希望尽可能早地发现它。上下文也是同理，因为随着你不断推进，
00:03:22你会陷入死循环。通常你会让代理去做某事，它说：“嘿，我做完了。”
00:03:26而你会想：“不对老兄”，然后你不得不一遍又一遍地进行纠正。
00:03:29这不仅浪费了搜索Token，也浪费了返工时间，
00:03:34在即将到来的Token经济学下，这是让人无法接受的。随着你进入并行
00:03:39代理等阶段，你会开始遇到审查税（Review Tax）。我们曾试图使用这些AI代码审查工具，
00:03:43但同样的，关键的上下文在那里至关重要，这样这些代码审查才能
00:03:48基本理解业务的运营方式，从而懂得业务逻辑以及更多内容；
00:03:52最后，如果你希望彻底摆脱人类参与的循环，
00:03:57比如希望后台代理搞定一切且不出任何差错，你真的必须确保
00:04:02拥有一个上下文引擎，以便这些代理可以向它查询并获得
00:04:05所需的所有答案，从而能够以高效的方式持续运行。
00:04:08有一些行不通的常见方法，它们基本上类似于局部最大值。在我们面对的数百家企业客户和
00:04:16中型市场企业中，我们看到最多的其中两个陷阱就是精心策划的上下文陷阱。
00:04:21如果你曾经坐下来，使用虚拟文件系统或本地文件系统，
00:04:26并在其中放入一些Markdown文件，心想：“这就是这个项目的所有上下文，它是这样运作的”，
00:04:30然后允许你的代理去检索（grep）这些内容，它确实能获取到一堆好数据，从而表现得更好。
00:04:35但问题是，首先你现在必须分发这些内容——比如把它放到GitHub上让团队成员获取；其次，这个代码库会像你写的所有其他文档一样逐渐腐烂；再者，在你们组织里，谁又是那个无所不能、拥有极佳品味来为组织里的每一个人精心维护这个文件或代码库的人呢？
00:04:52所以你开始遇到这些问题。下一个是MCP高原期（MCP Plateau），这一点相当明显。我们有了MCP，它们很棒，你可以把它交给代理，现在它基本上可以从另一个源系统获取信息。但问题当然是，根据你编写服务器描述和工具描述的方式，你的代理可能永远不会调用它（尽管它本来应该调用），或者如果它真的调用了，会存在一个众所周知的偏差，叫做“搜索满足偏差”（Satisfaction of Search Bias）。这意味着代理当它找到
00:05:22它认为正确的第一个信息片段时，就会觉得“我有需要的东西了”并继续执行。而在大多数组织中，昨晚的Slack对话可能已经说了“你应该做A而不是做B”，但如果代理先找到了某个架构记录，它就永远不会发现这一点，因此它并没有真正考虑所有的上下文。
00:05:40这里的问题在于，拥有信息并不等于理解。因此，要向模型传达理解，你必须采用其他技术。我基本上想表达的是，你的代理看不到的是水面以下的一切。它百分之百能写出可以通过编译的代码，但通过编译的代码却可能让生产环境瘫痪，导致你在凌晨一点遭遇P0级故障，因为代理忽略了一个事实：你们有一个特定的上线流程，即必须关闭某个功能开关（Feature Flag），无论具体情况是什么。
00:06:10因此，你们的团队需要一个上下文引擎，因为它的作用应该是理解你是谁、你在组织里什么地方工作。所以如果我对它说“我想搭建身份验证（Auth）”，它知道我在哪里工作，知道我的Git提交记录在哪里，知道是谁在审查这些提交，并且它理解我的上下文，从而能够锁定我的重点，并以此为触发点去寻找其余的信息。
00:06:33它能够解决冲突。正如前面提到的，一份旧的架构图和昨晚与CTO的Slack对话内容冲突时，究竟哪一个才是正确的？你需要使用一系列技术来判断这一点。
00:06:44当然，它还要尊重权限和治理。MCP允许我们使用OAuth以及其他作用域（scopes）和SSO，但如果这里有人提出了一个不应该了解“机密项目A”的问题，你需要确保这些信息不会泄露到回答中。
00:06:58最后，以Token优化的方式在正确的时机将正确的上下文交付给模型。
00:07:03我们有多个交互界面，因为人类工程师仍然经常与Unblocked交流，以在Slack或其他地方获取所需的信息。
00:07:09但如果是进行机器对机器的通信，为了避免在Token开销上浪费大量费用，你就需要Token优化后的响应。
00:07:17这就是引擎的工作原理。我会简明扼要地说明这一点，基本上在左侧你可以看到所有输入的数据源。
00:07:26对我们而言，我们专注于工程团队，这也是使用我们产品的群体，同时还包括周围技术要求较低的团队，如支持、销售等。
00:07:34你摄取所有这些数据，从诸如事件管理工具链等工具中获取实时数据。
00:07:39数据进入引擎，该引擎在底层进行思考，我稍后会展开讲讲这一页。
00:07:45但基本上，它利用这六大核心特征，然后在右侧以所需的方式将上下文输出到精准的工作流中。
00:07:53正如前面提到的这六个要点，统一的系统上下文，你必须贯穿整个系统。
00:08:01在大型组织中，像LinkedIn规模的公司、Workday、通用汽车等，都需要这类数据。
00:08:08他们需要了解正在发生的一切。
00:08:10今天上午Tharik在谈到Fable可能会在今天晚些时候发布时，
00:08:15他提到你需要先提供一张地图，然后让Fable去探索这片领土。
00:08:21帮助限定范围的方法是确保这些模型能够访问所有的上下文，因为它们会帮你找出那些“你不知道的未知数”（unknown unknowns）。
00:08:29公司里绝对有很多你并不知道、但对你正在尝试的任务极其有帮助的事情正在发生。
00:08:35这会让进展更快。
00:08:37但针对定向检索，如果你提供了一个链接，它应该能快速展开、取回该文档并继续前进。
00:08:43所以对于深度研究这类任务，可以耗时较长，这没问题。
00:08:46但在需要速度的时候，你也必须具备速度。
00:08:49冲突解决，我们刚才已经讨论过了。
00:08:51如果一处说做A，另一处说做B，究竟谁才是对的。
00:08:55个性化相关性：我是谁，我在哪里工作，我正在做什么。
00:08:59Token优化：确保回应优质高效，且不会撑爆上下文窗口。
00:09:04还有权限强制执行，当然包括OAuth——你无权查看的，就绝对不能看到。
00:09:10我们做了一些测试：将完全相同的提示词发送给同一个模型，一个带有上下文，另一个则没有。
00:09:17这是墙钟时间（Wall clock time）的节省，节约了两个小时，这非常棒。
00:09:21接着是Token的节省。
00:09:23这是一个相当大的任务。
00:09:25没有上下文时大约消耗了2100万个Token，而有了上下文之后则是1800万——抱歉，是1080万个Token。
00:09:31这就是你在使用上下文引擎时通常会看到的体验，因为当注入了上下文后，绝大多数在每次会话开始时为了理解和发现事物而不得不进行grep的浪费搜索Token就不复存在了。
00:09:45也就是处于“充分注入上下文”的状态。
00:09:47随着你继续推进，你就会获得这些成果。
00:09:50Token消耗减少50%，分诊速度更快，而且回答质量实际上也更高，因为它清楚业务内部正在发生什么。
00:09:57接下来这部分，你们可能想拍个照。
00:10:01如果你不知道的话，其实你可以拍下二维码的照片，之后在相册里点击它就能加载链接，这样你就不用一直站在这里等了，因为我要给出三个二维码。
00:10:09这第一个是给社交评论网络的。
00:10:12我把它放出来，这样你们就可以拍照了。
00:10:14但这是一个我们拥有的开源工具，它完全通过确定性编程来扫描你的GitHub，并了解谁在你的团队中工作。
00:10:22这是我的真实团队。
00:10:23我们管拉辛（Rasheen）叫“机器”，因为他发版的速度简直疯狂。
00:10:26但在右边，你可以看到他的代码提交记录、提交地点以及谁在审阅他的工作。
00:10:30然后在这些标签页中，你可以找到一个提炼后的专家图谱。
00:10:33从而全面了解业务中正在发生的事情。
00:10:35如果你选择性地添加 OpenAI 或 Anthropic 的 API 密钥，它就会为你进行一些标签分类，从而确定你的团队构成。
00:10:44这是一个非常酷的工具，能帮你了解团队的工作地点，并引入社交网络，以便在你亲自构建这些工具时专注于上下文引擎。
00:10:52下一个工具叫做仓库规则代理（repo rules agent）。
00:10:55这是我们真实代码库的一个示例。
00:10:57我无论如何都会把它展示出来，所以你们不需要对着这个设备讲。
00:11:00简而言之，它的功能是发现团队编写规则文件的所有位置，对它们进行全面检查，然后告诉你设置了哪些严重级别以及其他内容。
00:11:11我是不是该直接切换到这个？
00:11:13它会告诉你——哦，嘿。
00:11:15很高兴见到大家。
00:11:17基本上，它会找出代码库中的所有规则，然后告诉你是否存在重复的问题或其他隐患。
00:11:24然后你可以将其作为索引进行 grep 搜索。
00:11:26这样就可以调用该索引进行去重，从而帮助提高上下文的检索效果。
00:11:32最后，我们在周一举办了这场超越 RAG 的工作坊，并传授了如何从零开始构建关系型上下文引擎。
00:11:40所以只要扫描那个二维码，就能获取完整的练习手册。
00:11:43里面包含六个堆叠的 PR，教你如何一步步完成这项工作。
00:11:46简而言之，RAG 是一项极其强大的技术，你确实需要它。
00:11:49但问题的另一半在于，人们真正会问的是：
00:11:53在过去一周里，我参与处理的涉及身份验证的未合并 PR 都有哪些？
00:11:57仅靠 RAG 是无法回答这个问题的。
00:12:00你需要查询功能。
00:12:01所以这展示了如何进行基本上无架构（schema-less）的查找，允许代理发现架构，
00:12:08然后针对它编写确定性查询，以便提取出这类关系型数据。
00:12:13非常实用的技术。
00:12:15当然，上下文引擎的使用场景远不止于代码生成。
00:12:21这是我们经常生活的地方。
00:12:22也是我们许多客户花费时间的地方。
00:12:24但令人惊叹的是，当企业里其他部门的人开始使用这些工具时，会发生奇妙的变化。
00:12:30客户成功团队能够在客户工单刚提交的那一刻就将其解决。
00:12:35我们的销售人员在季度初期就能谈成交易，因为他们在外地时就能随时查询 Unblocked 上下文引擎。
00:12:44还有更多场景。
00:12:45你还可以这样做：如果你还记得之前我讲过各阶段的曲线图，
00:12:51我们构建了一个有趣的小工具，大意是通过大语言模型向你提问，询问当前的情况，
00:12:55然后将你准确映射到对应的水平，并向你传授一些如何晋升的技术，
00:13:01如果你希望大幅提升个人能力并在规模化运营中使用 AI 工具的话。
00:13:07网址是 readiness.getunblocked.com。
00:13:11差距不再是智能。
00:13:13而是上下文。
00:13:14我们将继续获得像 Anthropic 开发的 Mythos 那样不可思议的模型，
00:13:19而且我相信 Sol 模型只要我一获得权限就能用上。
00:13:22顺便祝大家加拿大日快乐。
00:13:24但实际情况是，关键在于你为这些模型周围提供的上下文，以此确保它们在你的组织内部发挥效用
00:13:30并提高 Token 的使用效率。
00:13:35所以我有准备问答幻灯片，但我不确定自己是否被允许展示。
00:13:40好吧，不行。
00:13:41所以大家可以来 P16 展位找我。
00:13:44你们可以认准椰子标志。
00:13:46很高兴能与各位交流，如果需要的话我们可以探讨具体细节。
00:13:49谢谢大家的聆听。
00:14:00谢谢。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기