如 Mozilla Connect 上所述，Firefox 130 将引入一项实验性的新功能，使用完全私有的设备端 AI 模型自动为图像生成 alt 文本。此功能将作为 Firefox 内置 PDF 编辑器的一部分提供，我们的最终目标是将其提供给使用屏幕阅读器的用户，并在一般浏览中使用。

为什么需要 alt 文本？

网页具有基本简单的结构，其语义允许浏览器根据用户自身的需求和偏好以不同的方式解释相同的内容。我们认为这正是 使 Web 特别之处 的一大原因，也是浏览器能够充当用户代理，负责让 Web 为人们服务的原因。

这对辅助技术（例如屏幕阅读器）特别有用，它们能够与浏览器功能一起使用，以减少人们访问和交换信息的障碍。对于静态网页，这通常可以通过很少的网站交互来实现，而且这种访问方式对许多人来说都非常有益。

但即使对于一个简单的静态页面，也有一些类型的信息（例如 图像的替代文本）需要由作者提供，才能为使用辅助技术的人提供可理解的体验（如 规范要求）。不幸的是，许多作者都没有这样做：Web Almanac 报告 2022 年近一半的图像缺少 alt 文本。

直到最近，浏览器还无法推断出图像的质量较高的 alt 文本，而无需将潜在的敏感数据发送到远程服务器。然而，人工智能的最新发展使这种图像分析能够高效地进行，即使是在 CPU 上。

我们在 Firefox Nightly 的 PDF 编辑器中添加了一项功能来验证这种方法。随着我们进一步开发并从部署中学习，我们的目标是为希望在浏览时使用此功能的用户提供它，帮助他们更好地理解原本不可访问的图像。

使用小型开源模型生成 alt 文本

我们使用基于 Transformer 的机器学习模型来描述图像。这些模型在描述图像内容方面越来越出色，同时又足够紧凑，可以在资源有限的设备上运行。虽然它们无法胜过像 GPT-4 Turbo with Vision 或 LLaVA 这样的大型语言模型，但它们足够准确，可以在各种硬件上提供宝贵的设备端见解。

像 BLIP 甚至 VIT 这样的模型架构，是在 COCO（上下文中的常见物体）或 Flickr30k 等数据集上训练的，它们擅长识别图像中的物体。当与 OpenAI 的 GPT-2 等文本解码器结合使用时，它们可以使用 2 亿个或更少的参数生成替代文本。一旦量化，这些模型在磁盘上可以小于 200MB，并且可以在笔记本电脑上运行几秒钟 - 与 LLM 所需的千兆字节和资源相比，这是一个巨大的进步。

示例输出

下面的图像（来自 COCO 数据集）由以下内容描述：

• FIREFOX - 我们的 1.82 亿参数模型，使用 GPT-2 的精简版本以及 Vision Transformer (ViT) 图像编码器。
• 基线模型 - 一个略微更大的 ViT+GPT-2 模型。
• 人工文本 - 数据集标注者提供的描述。

这两个小型模型的准确性都比一个人提供的描述差，基线模型对手的姿势感到困惑。Firefox 模型在这方面做得略好，并且抓住了重要的信息。

无论如何，重要的是可以是暗示性的。请注意，这个人没有写办公室环境或蛋糕上的樱桃，而是明确说明了蜡烛很长。

如果我们在像 GPT-4o 这样的模型上运行相同的图像，结果会非常详细

图像描绘了一群人围着一个点燃了蜡烛的蛋糕。重点是蛋糕，蛋糕上有红色的果冻浇头和几个樱桃。前景中有多支点燃的蜡烛。背景中，一位女士面带微笑，穿着灰色高领毛衣，还可以看到几个人，很可能是在办公室或室内环境中。图像传达了一种庆祝的氛围，可能是生日或特殊场合。

但这种详细的 alt 文本太过冗长，并没有优先考虑最重要的信息。简洁不是唯一的目标，但它是一个有用的起点，简洁准确的初稿可以让内容创作者专注于缺失的上下文和细节。

所以，如果我们要求 LLM 提供一个句子描述，我们会得到

一群人在办公室里庆祝，前景中是一个点燃的生日蛋糕，背景中是一位微笑的女士。

这比我们的小型模型更详细，但无法在本地运行，除非将图像发送到服务器。

小而美

使用小型模型在本地运行推理具有许多优势

1. 隐私：所有操作都在设备内进行，确保数据隐私。我们无法访问您的图像、PDF 内容、生成的字幕或最终字幕。您的数据不会用于训练模型。
2. 资源效率：小型模型消除了对云端高性能 GPU 的需求，从而减少了资源消耗，使其更加环保。
3. 提高透明度：对模型的内部管理允许直接监督训练数据集，与某些大型语言模型 (LLM) 相比，提供了更高的透明度。
4. 碳足迹监测：在内部训练模型可以利用 CodeCarbon 等工具对 CO2 排放进行精确跟踪。
5. 易于改进：由于重新训练可以在一台硬件上完成，所需时间不到一天，因此可以频繁地更新和改进模型。

将本地推理集成到 Firefox 中

扩展翻译推理架构

Firefox 翻译使用由 Marian C++ 推理运行时驱动的 Bergamot 项目。运行时被编译成 WASM，并且每个翻译任务都有一个模型文件。

例如，如果您在法语环境下运行 Firefox 并访问一个英文页面，Firefox 会询问您是否要将其翻译成法语，并下载英文到法语模型（约 20MiB）以及推理运行时。这是一次性下载：一旦这些文件在磁盘上，翻译将完全离线进行。

WASM 运行时和模型都存储在 Firefox 远程设置 服务中，该服务允许我们大规模分发它们并管理版本。

推理任务在单独的进程中运行，这可以防止浏览器或其某个选项卡在推理运行时崩溃时崩溃。

ONNX 和 Transformers.js

我们决定将 ONNX 运行时 嵌入 Firefox Nightly 以及 Transformers.js 库，以扩展翻译架构以执行不同的推理工作。

与 Bergamot 一样，ONNX 运行时也有 WASM 分发版，可以直接在浏览器中运行。ONNX 项目最近引入了 WebGPU 支持，该支持最终将在 Firefox Nightly 中为此功能启用。

Transformers.js 在 ONNX 推理运行时之上提供了一个 Javascript 层，使为大量的模型架构添加推理变得容易。API 借鉴了非常流行的 Python 库。它完成了所有繁琐的工作，例如准备传递给运行时的数据和将输出转换回可用的结果。它还处理从 Hugging Face 下载模型并缓存它们。

根据项目的文档，以下是如何在文本上运行情感分析模型

import { pipeline } from '@xenova/transformers';

// Allocate a pipeline for sentiment-analysis
let pipe = await pipeline('sentiment-analysis');
let out = await pipe('I love transformers!');

// [{'label': 'POSITIVE', 'score': 0.999817686}]

使用 Transformers.js 使我们对使用 ONNX 尝试新模型充满信心。如果其架构在 Transformers.js 文档中列出，那它很可能对我们有效。

为了将其引入 Firefox Nightly，我们略微更改了它的发布方式，将 ONNX 与 Transformers.js 分开分发，删除了与 Node.js 相关的部分，并修复了 ONNX 库附带的那些令人讨厌的 eval() 调用。您可以在 此处 找到用于填充该供应商目录的构建脚本。

从那里，我们重复使用翻译架构，在自己的进程中运行 ONNX 运行时，并让 Transformers.js 使用自定义模型缓存系统运行。

模型缓存

Transformers.js 项目可以使用本地和远程模型，并具有使用浏览器缓存的缓存机制。由于我们在隔离的 Web 工作线程中运行推理，我们不想提供对文件系统的访问权限，也不想将模型存储在浏览器缓存中。我们也不想在 Firefox 中使用 Hugging Face 作为模型中心，而是希望从我们自己的服务器上提供模型文件。

由于 Transformers.js 为自定义缓存提供了回调，我们已经实现了 特定模型缓存层，该层从我们自己的服务器下载文件并将其缓存到 IndexedDB 中。

随着项目的发展，我们预计浏览器将存储更多模型，这会占用磁盘上的大量空间。我们计划在 Firefox 中添加一个界面来管理下载的模型，以便用户可以列出它们并在需要时删除一些模型。

微调 ViT + GPT-2 模型

Ankur Kumar 在 Hugging Face 上发布了一个 流行模型，用于为图像生成替代文本，并 发布了相关的博客文章。该模型还由 Joshua Lochner 作为 ONNX 权重发布，因此可以在 Transformers.js 中使用，请参阅 https://hugging-face.cn/Xenova/vit-gpt2-image-captioning

该模型的效果很好——即使在某些情况下，我们使用 https://hugging-face.cn/microsoft/git-base-coco 获得了更好的结果——但 GIT 架构尚未在 ONNX 转换器中得到支持，并且参数少于 2 亿个，大部分准确性是通过关注良好的训练数据获得的。因此，我们选择了 ViT 作为我们的第一个模型。

Ankur 使用了 google/vit-base-patch16-224-in21k 图像编码器和 GPT-2 文本解码器，并使用 COCO 数据集对它们进行了微调，COCO 数据集包含 12 万多张带标签的图像。

为了减小模型的大小并使其速度更快一些，我们决定用 DistilGPT-2 替换 GPT-2——根据其文档，DistilGPT-2 的速度快 2 倍，体积小 33%。

在 Transformers.js 中使用该模型取得了不错的效果（请参阅 GitHub – mozilla/distilvit: 用于 PDF.js 的图像到文本模型 中的训练代码）。

我们使用 更新的训练数据集 和一些 监督学习 进一步改进了模型，以简化输出并减轻图像到文本模型中常见的某些偏差。

PDF.js 中的替代文本生成

Firefox 能够使用我们的 流行的开源 pdf.js 库 在 PDF 中添加图像。

从 Firefox 130 开始，我们将自动生成替代文本并允许用户对其进行验证。因此，每次添加图像时，我们都会获得一个像素数组，我们将它传递给 ML 引擎，并在几秒钟后，我们得到一个与该图像描述相对应的字符串（请参阅 代码）。

用户第一次添加图像时，需要等待一段时间才能下载模型（根据您的网络连接，这可能需要几分钟），但后续使用会快得多，因为模型将存储在本地。

将来，我们希望能够为 PDF 中的任何现有图像提供替代文本，但包含文本的图像除外（对于包含扫描书籍的 PDF 通常如此）。

下一步

我们的替代文本生成器远非完美，但我们希望采用迭代方法并在公开环境中对其进行改进。推理引擎已作为新的 ml 组件 以及 初始文档页面 落地到 Firefox Nightly 中。

我们目前正在使用本文中介绍的方法改进图像到文本数据集和模型，这些内容将不断更新到我们 Hugging Face 页面。

生成模型的代码位于 Github https://github.com/mozilla/distilvit，我们为团队构建的用于改进模型的 Web 应用程序位于 https://github.com/mozilla/checkvite。我们希望确保我们构建的模型和数据集以及所有使用的代码都能够提供给社区。

一旦 PDF.js 中的替代文本功能成熟并证明有效，我们希望将该功能提供给使用屏幕阅读器的普通浏览用户。