--- area: "work-career" category: ai-ml date: '2025-12-19' draft: true guest: '' insight: '' layout: post.njk products_models: - Arc - GPT project: [] series: '' source: https://www.youtube.com/watch?v=o4scJaQgnFA speaker: AI Engineer status: evergreen summary: The Browser Company of New York 的 AI 工程主管 Samir Mody 分享了公司从构建 Arc 浏览器到 AI 原生浏览器 DIA 的转型历程。他深入探讨了在快速迭代、优化工具、将模型行为视为工艺以及应对 AI 安全挑战（如提示注入）方面学到的关键经验。演讲强调了拥抱技术变革、以用户为中心的设计以及跨职能协作在构建下一代 AI 产品中的重要性。 tags: - development - security title: 从 Arc 到 DIA：构建 AI 浏览器的经验教训 --- ### 公司愿景与使命 大家好，我是 Samir，在 **The Browser Company of New York** 担任 AI 工程主管。今天，我将与大家分享我们如何从构建 **Arc** 浏览器转型到 **DIA**，以及在构建 AI 浏览器过程中学到的经验。 首先，简单介绍一下我们公司。我们的使命是重新构想人们使用互联网的方式。我们坚信，浏览器是你生活中最重要的软件之一，但它并未获得应有的关注。简单来说，过去几十年来，我们使用浏览器的方式发生了变化，但浏览器本身却没有。我们公司成立于 2019 年，当时我们的 CEO **Josh** 分享了我们对互联网的初步构想，我们称之为“互联网计算机”。我们的使命一直是构建一个能够反映当今人们使用互联网方式，并预示未来浏览器应如何使用的产品。 ### 从 Arc 到 DIA 的演进 经过多年的探索、试错以及一些起伏，我们在 2022 年推出了首款浏览器 **Arc**。我们认为它比当时市面上的浏览器有所改进，让互联网更加个性化、更有条理，并且更加令人愉悦，充满了匠心。**Arc** 深受许多人喜爱，至今仍有数百万用户，其中可能很多人就在现场。 然而，如果我们退一步看，**Arc** 仍然只是对当时浏览器的一种渐进式改进，未能完全实现我们最初设定的愿景。因此，我们继续开发。到了 2022 年，我们获得了 **GPT** 等 **LLM**（大型语言模型: Large Language Models，一种能够理解和生成人类语言的 AI 模型）的访问权限。我们像往常一样开始进行原型设计，尝试新想法，并将其中一些想法集成到了 **Arc** 中。但最初的探索逐渐演变成了一个完整的理论。 2024 年初，我们发布了“Act 2”视频，阐述了我们的核心观点：**AI 将彻底改变人们使用互联网的方式，并进而从根本上改变浏览器本身**。基于此，我们重新开始构建，这一次，我们从头开始，以 AI 的速度和安全性为核心，打造了一款全新的浏览器。今年早些时候，我们推出了 **DIA**，一款 AI 原生浏览器。它允许你在浏览器中的所有工作中拥有一个助手，了解你，个性化你的体验，帮助你管理标签页，并通过你使用的应用程序更有效地完成工作。虽然 **DIA** 尚未完全实现我们的愿景，但我们坚信它正走在这条正确的道路上。 ### 经验一：优化工具与流程以加速迭代 构建产品并非易事，更何况是构建两个，尤其是第二个还是 AI 原生产品。我们经历了多年的迭代、试错，并从中学习良多。今天我想分享其中几点。 首先是**优化你的工具和流程以实现更快迭代**。从一开始，**The Browser Company** 就坚信，除非我们构建出能够比其他人更快地进行迭代、构建、发布和学习的工具、流程、平台和思维模式，否则我们将无法成功。这一点在今天依然适用，但随着 AI 和 AI 原生产品的出现，其形式发生了变化。 那么，作为一个小型公司，我们现在将资源投入到哪些工具的开发中呢？首先是为 AI 产品功能进行原型设计；其次是构建和运行评估（evals: evaluations，评估模型性能或产品质量的测试）；第三是收集用于训练和评估的数据；最后但同样重要的是，为“爬坡”（hill climbing: 指通过迭代优化来逐步改进产品或模型性能的过程）进行自动化。 让我们从工具开始。起初，我们像往常一样构建了一些工具，第一个是一个非常基础的提示词编辑器，仅限于开发版本。这对我们意味着什么？首先是访问受限，只有工程师才能使用；其次是迭代速度慢；第三是缺乏个人上下文。正如大家所知，对于 AI 产品而言，上下文至关重要，它决定了产品的优劣。 因此，我们不断进化。此后，我们将所有工具都集成到了我们的产品中——也就是我们公司内部每天都在使用的产品。这包括提示词、工具、上下文、模型以及所有参数。这不仅使我们在构思、迭代和优化产品方面的速度提升了 10 倍，还扩大了能够访问和迭代我们产品的人群范围。从我们的 CEO 到新入职的员工，都可以使用 **DIA** 构思和创建新产品，并结合他们的全部上下文来优化现有产品。 这一点也适用于我们所有的主要产品协议。我们有用于优化内存知识图谱的工具，我们公司每个人都在使用；我们还有用于创建和迭代计算机使用机制的工具。在将其集成到产品之前，我们实际尝试了数十种不同类型的计算机使用策略。我想以一句话结束这部分：这其实很有趣。人们对此谈论不多，但将这些工具集成到我们的产品中，确实激发了大量的创造力。它使我们的产品经理、设计师、客服、战略和运营团队能够尝试为他们的用例量身定制的新想法。而这最终就是我们想要做的。 ### 经验二：通过 Jepa 优化提示词 接下来，我想谈谈我们如何通过一个名为 **Jepa**（源自一篇论文，可能是对提示词优化机制的称呼）的机制来演进和优化我们的提示词。这对我们来说是一个相对较新的但非常重要的学习。 我们如何优化和改进我们的 AI 产品，与我们最初构思它们同样重要。因此，我们正在投资于相关的机制，以实现更快的优化过程，其中之一就是 **Jepa**。这基于今年早些时候一篇由几位聪明人撰写的论文。 这里的关键动机很简单：这是一种样本高效的方式，可以在不依赖强化学习（RL）或其他微调技术的情况下，改进复杂的 LLM 系统。对于我们这样的小公司来说，这一点至关重要。它的工作原理是：你用一组提示词“播种”系统，然后在多组任务上执行它们并进行评分。然后，利用一个称为 **PA selection**（可能是指 Pairwise selection，成对选择）的机制来选择最佳的提示词。接着，利用一个 LLM 对哪些方面做得好、哪些方面做得不好进行反思，然后生成新的提示词，并重复这个过程。这里的关键创新在于：围绕着反思性的提示词变异技术；允许你探索更广泛的提示词空间而非单一路径的选择过程；以及能够调整文本而非模型权重（weights: 模型中的参数，用于进行预测）的能力。 这里有一个我们实际应用的例子。你可以提供一个非常简单的提示词，通过 **Jepa** 运行它，它就能根据我们创建的用于优化该提示词的指标和评分机制进行优化。 因此，如果我退一步，谈谈我们如何为特定类型的功能进行构建，我会将其分为几个不同的阶段。第一个是原型设计和构思阶段，我们拓宽了漏斗顶部的想法数量，并降低了谁能以及如何构建它们的门槛。所以我们每天、每周都会尝试大量想法，来自各种各样的人，我们自己也会进行“试吃”（dogfooding: 指公司内部使用自己产品的行为）。如果我们觉得其中确实有实际的效用，它能为我们解决一个真实的问题，并且有路径可以达到我们认为需要的质量标准，那么我们就会进入下一个阶段。 在这个阶段，我们会收集和优化评估（evals），以明确产品需求，然后通过代码、提示词和像 **Jepa** 这样的自动化技术进行优化。之后，我们像往常一样在内部进行“试吃”，然后发布。我确实想强调这些阶段的重要性。构思阶段与优化阶段同等重要。我们的目标是实现更快的构思速度和更高效的发布路径。因为随着每周 AI 的进步，**DIA** 中都会解锁新的可能性。作为一款浏览器、一个产品，我们的责任是尽可能多地尝试这些新想法，探索它们。同时，也要认识到将这些想法转化为高质量的生产体验所需要付出的努力。 ### 经验三：将模型行为视为一门工艺与学科 接下来，我想谈谈如何将模型行为视为一门工艺与学科。 对我们而言，模型行为是什么？它是定义、评估和发布期望行为模型的职能。它是将原则转化为产品需求、提示词和评估，并最终塑造我们 LLM 产品（最终是我们的 **DIA** 助手）的行为和个性。 我们可以将其分为几个不同的领域。首先是行为设计，定义我们想要的产品体验、风格、语调，在某些情况下还包括响应的形态。然后是收集用于衡量和训练的数据，通过评估来明确产品需求。最后但同样重要的是，模型引导（model steering），即构建产品本身。这是提示词工程、模型选择，定义上下文窗口（context window: LLM 可以一次性处理的输入文本长度）中的内容、参数等，以及更多。 对我们来说，这个过程是迭代的，非常迭代。我们构建、优化，创建评估，然后发布，接着收集更多反馈，并将其反馈到我们的迭代构建过程中。这可以是内部反馈，也可以是外部反馈。 如果我举个类比，我们曾考虑过将模型行为类比为互联网的演进过程中的产品设计。起初，网站只是功能性的，能完成任务。但随着时间的推移，随着我们尝试在互联网上实现更多目标以及技术的发展，它也随之演进。互联网本身的产品设计和工艺也随之发展，复杂性也随之增加。 那么，模型行为会是怎样的呢？起初，它是功能性的。我们有提示词、评估，有输入和输出指令。现在，我们通过代理行为（agent behaviors）来构建它。它是目标导向的推理、自主任务的塑造、自我纠正和学习，甚至塑造 LLM 本身的个性。 那么未来会怎样呢？我很期待看到。但我们相信，我们正处于构建 AI 产品的早期阶段，模型行为将继续演进，成为一种专门的、普遍的功能，即使在产品公司中也是如此。 ### 经验四：AI 安全作为产品构建的涌现属性 最后我想和大家分享的是，**AI 安全作为产品构建的涌现属性**。今天我将重点关注提示词注入（prompt injection）。 什么是提示词注入？它是一种提示词攻击，攻击者可以覆盖 LLM 的指令以造成损害。这可能包括数据泄露、执行恶意命令或忽略安全规则。 这是一个例子：你将一个网站的上下文提供给 LLM，并指示它进行总结。但你不知道的是，该网站的 HTML 中隐藏了一个提示词注入。因此，LLM 没有真正总结网页内容，而是被指示打开一个新网站，提取你的个人信息，并将其作为 URL 的 GET 参数嵌入，从而有效地泄露了你的数据。 作为浏览器，防止提示词注入对我们来说至关重要。它们至关重要，因为浏览器处于我们称之为“致命三要素”的中间：它能访问你的私有数据；它会暴露于不受信任的内容；并且它有能力进行外部通信，对我们而言，这意味着打开网站、发送电子邮件、安排事件等。 那么，我们如何防止这种情况呢？有一些技术策略可以尝试。首先是将不受信任的上下文包装在标签（tags）中。你可以指示 LLM 遵循这些标签周围的指令，而不遵循标签周围的内容。但这很容易被绕过，而且相当容易实现。攻击者仍然可以利用提示词注入攻击你的浏览器。 另一个可以尝试的解决方案是分离数据和指令。我们可以将操作指令分配给一个系统角色（system role），将用户角色分配给第三方内容，甚至可以添加随机生成的标签来包裹用户内容，以确保 LLM 遵循指令而不是内容。虽然这可以提供帮助，但没有绝对的保证，提示词注入仍然会发生。 那么我们该怎么办？我们必须设计一个将这一点考虑在内的产品。我们必须将技术方法、用户体验和设计融合到一个连贯的故事中，从头开始构建它们并共同解决问题。 那么，**DIA** 中的一个功能会是什么样的呢？让我们以 **DIA** 中的自动填充（autofill）工具为例。自动填充工具允许你利用 LLM 的上下文、记忆和你的详细信息来填写互联网上的表单。这非常强大，但正如你所想象的，它也存在一些漏洞。这里的提示词注入可能会提取你的数据并将其填入表单，一旦数据填入表单，就超出了你的控制。因此，我们尝试在构建时就考虑到这一点。 在这种情况下，在写入表单之前，我们会让用户以纯文本形式阅读和确认这些数据。这并不能完全阻止提示词注入，但它赋予了用户控制权、意识和对正在发生的事情的信任。这是我们在整个产品中以及构建每一个功能时所遵循的框架。例如，在 **DIA** 中安排事件，我们有类似的确认步骤；在 **DIA** 中撰写电子邮件，我们也进行了类似的确认步骤。 ### 结论：拥抱技术变革 今天我分享了三点内容：第一，优化你的工具和流程以实现快速迭代；第二，将模型行为视为一门工艺与学科；第三，AI 安全作为产品构建的涌现属性。 但最后我想留给大家的是，当我们开始构建 **DIA** 的旅程时，我们认识到了技术变革，并试图改进我们的产品 **Arc**。我们最初的想法是：“嘿，我们如何利用 AI 来让 **Arc** 变得更好，让浏览器变得更好？”但我们很快就认识到并适应了，这不仅仅是产品演进，而是一次公司层面的变革。 今天，我分享了其中的一瞥：我们如何构建，它如何改变了我们围绕此建立的团队，以及我们如何思考 AI 产品的安全性。但实际上，这远不止于此。它关乎我们如何培训这里的每个人，如何招聘，如何沟通，如何协作，以及更多。 如果有一件事我想留给大家，如果我们过去几年学到的有一件事，那就是当你认识到技术变革时，你必须拥抱它。而且你必须带着信念去拥抱它。 谢谢大家。 [applause and music]