Chrome 中嵌入 AI 的语音控制网站

介绍

早期预览 Chrome Prompt API。

我最近被邀请参加Chrome 内置 AI（Prompt API）的早期预览计划。内置 AI 是一项探索性工作，有望成为嵌入式 AI 的跨浏览器标准。它利用设备上的 Gemini Nano，这意味着它被捆绑到您的 Web 浏览器中，并且 LLM 生成发生在您的本地浏览器环境中。

好处

美好、简单、快速、免费。

我们希望在浏览器中嵌入 AI 主要有三个原因：速度、成本和可用性。作为原生浏览器 API，它易于使用。访问 Prompt API 就像这两行代码一样简单。

 const session = await window.ai.createTextSession(); const result = await session.prompt( "Tyingshoelaces.com are writing a really cool blog about you. What do you think about that then?" );

在浏览器中获取生成式 AI 结果再简单不过了。我运行了一些测试来检查执行时间。虽然我很失望我们被限制在一个会话中（没有并发性），但复杂的长文本生成性能很好。

请记住，也没有延迟，因此执行时间实际上是从我们在浏览器中发出请求到在代码中使用结果的毫秒数。

 VM975:32 Execution Time 1: 0h 0m 3s 47ms VM975:32 Execution Time 2: 0h 0m 3s 870ms VM975:32 Execution Time 3: 0h 0m 2s 355ms VM975:32 Execution Time 4: 0h 0m 3s 176ms VM975:32 Execution Time 5: 0h 0m 7s 103ms VM975:44 Average Session Execution Time: 0h 0m 3s 910.1999999999998ms );

对于长文本生成提示，对内置 AI 的 5 个链式请求的平均执行时间为 3-4 秒/完整请求。我运行了几次（脚本包含在 GitHub 存储库中），虽然这因设备而异，但我还希望在 API 优化后这种情况会有所改善。我注意到较短的 JSON 生成任务要快得多（200-400 毫秒）。

对于大多数用例来说，这都是可以接受的。我们还将 LLM 的规模问题众包出去。工业级 API 的使用成本非常高，而每个 LLM 请求都通过实验性的浏览器 API 处理。这感觉非常好，开辟了一个充满可能性的世界。

通过让 Chrome 用户将模型嵌入到浏览器中，我们拥有一种分发机制，可以在使用时预加载生成式 AI 模型，而无需使用大型服务器。这类似于WebLLM ，但有一个显著的优势，即模型已预加载并捆绑到我们的浏览器中。

这意味着我们可以下载单一模型以供“互联网”使用，而不必被迫下载特定于供应商的模型。

这个实验性的浏览器 API 的巨大优势为采用它提供了强有力的理由；它速度快、免费（或由消费者付费）、并且非常易于使用。

但有什么权衡呢？

成本

快捷又免费。但成本是多少呢？

该 API 只适合实验，不适用于生产用途。因此，很多输出不如我们期望的更成熟和托管的模型那么精致。规模限制以及模型的通用性意味着我们没有精致的输出。

这导致了一些挫败感，让我们回想起生成式人工智能 API 的早期阶段。我发现自己使用了大量快速工程和验证逻辑来获得可靠的 JSON 响应。每隔几个请求，API 似乎就没有响应，很容易混淆响应，在这种情况下模型就会崩溃。

还提到了这样一个事实：鉴于该模型嵌入在浏览器中，它作为“私有”模型具有一定的价值。我不确定这是否适用于大多数用例，因为面向公众的网站仍将与其服务器交互，而对于普通用户来说，很难确定数据永远不会离开本地环境。话虽如此，对于通过浏览器运行的内部使用和非面向公众的系统（例如企业环境），这可能是一个加分点。

由于模型较小，响应不够复杂，这意味着我们必须非常小心地使用它来完成任务。未来的架构将优化其生成式 AI 实现，以使用正确的权重（因此成本）来完成正确的任务。我设想有多个小型、高度优化且面向任务的 LLM，每个都用于特定的输出。

话虽如此，一切都是可以原谅的，特别是因为 API 明确设计用于实验而不是生产用途。

优点
-成本
-规模
-速度
-可用性
-私人的

缺点
-牺牲品质
-实施成本

例如，如果我们想深入分析时事，我们需要一个大的上下文窗口和复杂的 RAG 流来提供输出信息；嵌入式 AI 几乎肯定不是正确的方法。谷歌在其资源中提到了这一点。

但是我有一个想要验证的理论；一个疯狂、疯狂而又极其有趣的理论；而微型浏览器托管的 LLM 是进行验证的最佳场所。

新的思维方式

神经元，不是大脑

有一段时间我一直有个小问题想解决。如果我们完全错误地使用了 LLM 怎么办？事实上，如果我们的概念模型是错误的怎么办？

随着我们竞相扩大上下文窗口并扩大训练数据，我们正试图垂直扩展生成式人工智能。更大、更强、更快、更好。当我看到人们好心地要求上下文窗口足够大以接入整个互联网，然后要求中间的算法从这个巨大的湖泊中准确地挑选出我们想要的信息和输出时，我惊讶得合不拢嘴。而且速度更快。

我们将 LLM 的每一个输入都视为 API，输入文本，产生奇迹，输出文本。我们称这种中间的奇迹为智能。输入的文本越多，奇迹就越大，结果就越好。这是我们目前的发展方向。

我不禁想知道，我们是否关注了错误的尺度或缩放，对认知进行了错误的解读。

关于一般思维，尤其是创造性输出（文本生成就是这样的），它并不是一个简单的过程。它不是一个单一的线程。我们已经在较新的模型中看到了这一点；例如，在我对 Claude 3.5 Sonnet 系统提示的分析中，我们看到 LLM 输出的许多最新进展可能与算法本身无关，而是与在上下文中指导输出的基础设施、系统和调整有关。

我一直想尝试一种概念，即微小、快速的连接相互交织，以构建更大的东西。最终，100k 的上下文窗口与 1k - 100 倍相同。我怀疑，即使我们专注于宏伟的目标，关键在于将微小而精确的细节交织在一起，以形成更大的东西。这比有感知的机器“大脑”更符合我对智能的思维范式。

由于模型总体效率较低且成本过高，到目前为止，这还无法实现。想象一下 Bob 在账户中，我们告诉他，我们将把 ChatGPT 的请求数量增加 100 倍，因为我们推测网状架构中的微交易将提高我们 AI 系统的质量。我不认为 Bob 在 OpenAI 工作，但对于我们其他人来说，这是不可行的。

即使是浏览器中一个小型而高效的嵌入式模型也还不足以处理我的理论。它的速度不够快，并且不支持并发请求（并发的想法！），但这是朝着正确方向迈出的一步，而且我们已经远离了云托管 API 对每个请求收取巨额费用的时代。我看不到功能架构，但我可以看到实现它的道路。

为了验证这个理论，我掸掉编程手套上的灰尘，打开浏览器，开始了我通往具有 1000 个多线程请求的网格架构的史诗之旅。

结果是神奇的。

你的大脑，而不是他们的大脑

大脑是本地的，我们的 API 也应该如此。

我喜欢语音。我认为键盘和鼠标已经成为我们猴子大脑的延伸，但它们是人类的装置，因此作为界面的作用在整体上是有限的。随着技术的进步，界面也会进步，在某个时候，键盘、鼠标甚至屏幕对我们的祖先来说都会过时，就像油灯和信鸽对我们的过时一样。

所以，无论我想要构建什么，都必须是语音控制的。幸运的是，有一个浏览器 API 可以实现这一点。

1. 语音识别 API（带语音转文本）
2. 同步传输接口
3. 提示 API
4. 互联网（通过浏览器访问）

我想要构建一个浏览器控制的语音交互演示。一个智能网站，它可以根据浏览器上下文和输入进行导航、响应和更改，只需使用我的声音即可。没有键盘。没有鼠标。“我、我的声音、浏览器和提示 API。 ”听起来像是我听过的最糟糕的儿童故事。我可能写过更糟糕的故事。

从概念上讲，它与Rabbit设备或Humane AI 针非常相似。这两者都是雄心勃勃的项目，但它们共同的问题是，它们试图构建一个“AI OS”。一个由 AI 驱动的软件界面。我觉得这个目标太宏大了，本质上是试图在互联网上构建一个带有少量 AI 的新界面。

创新就是迭代，2024 年的互联网无处不在，从根本上与浏览器交织在一起。尝试发明人性化的 AI OS 界面与尝试重塑互联网类似。人们已经在问，“我能做什么，而我的手机已经做不到，但做得更好”……

创新需要将新事物和未经测试的事物融合在一起，但要有坚实和经过验证的基础。如果不稳定，结果就会像疯狂科学家的领域一样，但如果能恰到好处地平衡经过验证的事物和实验性事物，有时，只是有时，就会发生一些特别的事情。

在大多数 LLM 用例中，我们犯了一个错误的认知范式，即我们将参与视为握手。输入 ← LLM → 输出。输入进，输出出。然而，在真实的人类互动中，我们拥有可以分解为不同想法和行动的多维过程。

“
商店服务员迎接顾客 ->

[思考]

他们穿什么？他们的风格如何影响他们的购买模式

他们的人口结构如何，他们的年龄如何影响他们的购买模式

性别如何影响他们的购买模式

他们发出了什么样的情绪/社交信号

他们实际上说了什么会影响他们的选择

[行动]

早上好，先生，你好吗

“
顾客向服务员打招呼 ->

[思考]

快点，我很忙

希望他们有我想要的东西（通过读懂我的心思！）

他们会接受退货吗？

[行动]

早上好，我在找一双鞋。

我们对计算机科学的了解已经如此深入，以至于我们围绕该学科的思维过程已经变成了二元的。我们考虑输入和输出，真和假。事实是，人类的互动和思维是复杂而微妙的，我们无法将其简化为二元的。

但我们能做的是以新颖和创造性的方式融入这项美妙的技术，打破产出同质化和互联网变成泥浆的障碍。互联网变成泥浆

一多一，多中一

让我们让 Gen AI 交互变得多线程且细致入微

我的实验建议是使用内置人工智能来模拟社交和人类互动。让我们用一个我有肌肉记忆的例子来说明：为电子商务构建推荐算法。

 Thread 1: Social Cues, sentiment analysis – How long has it taken for user to interact? – Is their browsing behavior aggressive, slow, calm, controlled – Have they arrived from particular source, or looking for something specific? Thread 2: Behavior Cues, interpretation user input – How have they begun the conversation? A greeting? – What tone are they using? Thread 3: User context, data we have about similar demographics and their preferences – What age group do they belong to? How does this influence preferences? – How do they identify? How does this influence preferences? Thread 4: Site context, data we have how other users are using the site and trends – What are the trending products?

没有灵丹妙药可以解释如此多的数据点，也永远不会有。LLM 不是插件“情绪分析器、实体分类器、万事通”。LLM 是生成算法，可以创造性地、逻辑性地解释输入。请注意，线程中的每个提示都不是输出，而是问题。

为了为思维和生成式人工智能提供信息，我们需要提出的问题远多于提供答案。我们需要精通如何获取所有数据点，并以结构化的方式将这些数据点输入到我们的 LLM 中。因此，以行为和社交线索为例，我们需要执行以下操作：

1. 情绪分析
2. 浏览器行为与网站和全球平均值的数据分析
3. 从请求中提取引荐数据

所有这些数据都会在进入我们的法学硕士课程之前准备好并处理。但是，一旦准备好，我们可以通过以下提示来提供帮助：

用户 A 是回访者，但表现出了些许不满。在与他们打交道时请记住这一点，务必向他们保证我们有退货系统。[操作]：链接到我们的退货政策和热门产品。

另一种方法是：

“
用户 B 表现出不耐烦的迹象，直接来寻找产品 X。将他们带到产品页面并建议将其添加到购物车。[操作]：直接导航到页面 X 并将产品添加到购物车。

从这个意义上说，法学硕士是我们的代理人和翻译，但人们犯的错误是认为“算法”是高质量输出的解决方案。就像真正的代理人一样，我们的判断只有依靠数据和我们提供给他们的线索才可靠。多问问题，少回答问题。

这是无法否认的社会事实，也是为什么我们目前对法学硕士的期望如此不平衡，而中介正让许多人陷入幻灭的低谷。垃圾进，垃圾出。算法有多好并不重要。

仅仅为了获得两组用于推荐算法的线索，我们就需要依赖一系列专业工具和 AI 基础设施，而这些工具和基础设施超出了地球上除少数平台之外所有平台的能力。但我们可以通过在为我们的 LLM 提供数据的基础设施中构建细微差别、线程和复杂性来迭代实现这一目标。

现在，它们就在浏览器中；未来从未如此接近。

我只构建了一个简单的原型，模拟社交提示和输入。添加一些用户数据，然后要求 Prompt API 通过想法和动作的组合来响应我的声音。这只不过是一个“可能”起作用的愿景。但通过向我们的 Prompt API 提供精细、详细和受控的输入，我们得到了智能、周到和受控的反馈。这是一个网状基础设施的愿景，因为微线程可以动态地学习、加强和相互通知。

目前还无法实现。但也许有一天会实现，语音输入的快速工程让人感觉很神奇。这是一个值得努力实现的目标。

结论

未来比任何时候都更近。

我们仍处于 LLM 的早期阶段，我预测进展将比预期慢，AGI（按照任何合理的定义）在几代人内都不会到来。但每走一步，都会带来无限机遇。构建高效、经过深思熟虑和定义明确的基础设施可以大大提高我们 LLM 的输出质量，无论模型大小或算法质量如何。

将 LLM 移至浏览器也可以理解为将 LLM 移至互联网。它将成本低廉、易于操作、易于使用和实验。迫使人们以更小的视角思考、更高效地构建，并在解决方案中增加深度和细微差别是一件好事，所以我甚至不太担心“微型”模型。复杂性在于使用，而不仅仅是工具本身，所以这是一个巨大的飞跃。

我已附上我的演示；它是用于证明概念的一次性代码，建立在仅适用于演示目的的探索性人工智能之上。

而且它只是有时有效。

然而，这是对未来的美好愿景。

链接

更多资源。

Github 仓库

最初发布

提交时请保留此 CTA：