Phil Nash - 使用 Web API 构建浏览器 AI 应用

IBM的开发者关系工程师Phil Nash向与会者致以问候。演讲内容聚焦于在Web上利用应用程序接口（API）构建人工智能（AI）应用。然而，鉴于当前许多前沿技术仍处于早期发展阶段，演讲者首先发出重要警告，指出所展示的许多功能具有实验性质，可能无法在常规浏览器中正常运行，因此演示均在Chrome Canary版本中进行。

AI革命正在发生，并且不仅限于服务器端。Web平台也正在集成AI能力。演讲者的核心目标是展示如何构建一个完全在浏览器内部运行，并且能够完全离线操作的AI应用，以实现传统上无法完成的功能。

我的幻灯片和演示都在Chrome Canary中运行，因为有些东西在常规浏览器中根本无法工作。

AI技术的发展速度令人难以置信，构建的应用潜力巨大。关键在于将这种能力带到Web端，让开发者能够利用浏览器自身的能力来集成AI，而不是仅仅依赖远程服务器进行计算。

演讲者分享了个人经历，提到最近在西班牙和法国旅行时，发现回忆和使用西班牙语进行交流变得有些困难。这激发了构建一个翻译应用的设想，该应用必须完全在浏览器内运行，不需要任何互联网连接，实现完全的离线能力。

要实现这一目标，需要三个核心功能：首先是语音输入转文本（Speech to Text），其次是实现语言间的转换逻辑，最后是将翻译后的文本重新转换成语音（Text to Speech）。

浏览器平台已经内置了实现语音输入和输出的API。Web Speech API长期以来一直支持语音识别和语音合成。虽然构建过程并不复杂，但要实现翻译功能，通常仍需要调用外部的翻译API服务。

语音识别功能要求创建SpeechRecognition对象的实例并启动，同时需要指定预期的输入语言。该API会持续回调接收到的语音流，并将其实时转录到屏幕上，即使在幻灯片中也能实现动态字幕效果。

文本转语音功能即将文本转换回声音，技术上依赖于操作系统（如Mac和Windows）提供的底层支持。尽管API的调用对象——SpeechSynthesisUtterance——名称冗长，但该功能在浏览器中是可用的，并提供了多种声音选择。

虽然语音识别和合成已在浏览器中实现，但翻译功能传统上需要依赖外部API，即将语音数据发送到服务器进行处理，再返回结果。演讲者强调，用户更关心的是功能本身，而不是底层是否使用了AI。

当前Web AI的一个主要问题是，如果每个网站都要求用户下载大型语言模型（LLM），例如Gemma 3的某个版本，用户可能需要进行高达数GB的下载。这会迅速消耗用户的设备存储空间，是不可持续的体验。

人们不关心功能是使用AI构建的，他们关心的是这个功能本身。

Chrome团队着手将AI能力集成到浏览器中，首先推出了Prompt API。该API允许开发者调用浏览器内置的LLM（如Gemini Nano）。关键在于，模型只在浏览器首次运行时下载一次，而不是每次访问不同网站时都下载，从而解决了重复下载的问题。

通过观察开发者如何使用通用的Prompt API，Chrome团队发现用户需求可以被归类到更小的、更专注的场景中。因此，团队开始构建更小、更聚焦的模型API，以解决Web上实际存在的问题，避免了通用模型带来的广度问题。

目前，Chrome 138版本中已经发布了语言检测器（Language Detector）、翻译器（Translator）和摘要器（Summarizer）这三个API。此外，写作（Writer）和重写（Rewriter）API正在进行源试验（Origin Trial），证明了浏览器正在向更实用的、体积更小的AI功能迁移。

翻译器API的调用方式与通用模型类似，需要指定源语言和目标语言。虽然其模型大小约为70到80兆字节，远小于2GB，但它仍然需要下载。一旦下载完成，翻译操作就能立即执行，速度非常快。

演讲者随后展示了最终的演示，该演示完全在离线状态下运行。通过结合媒体录制API、Web Audio API处理音频缓冲区，并将数据发送给多模态提示API进行转录，再依次通过语言检测API、翻译器API，最后使用语音合成API输出，构建了一个完整的端到端离线翻译流程。

所有这些在浏览器内处理的最大优势在于隐私保护。过去，Web Speech API的语音数据会被发送到云端服务器进行处理。现在，所有操作都在用户设备上完成，确保了用户数据的机密性和安全性，这是Web AI集成的最重要驱动力之一。

这些AI能力现已存在并可供开发者使用。鼓励开发者利用Chrome Canary中的Prompt API以及已发布的翻译和语言检测API进行实验和创新。通过在浏览器中构建AI驱动的特性，开发者能够创造出令人惊叹的新应用和用户体验。