Meta智能眼镜配套应用上线完整但休眠的人脸识别管线

标题：Meta 智能眼镜配套应用在官方正式版中内置了完整但处于休眠状态的人脸识别管线

URL 来源：https://www.buchodi.com/meta-glasses-facial-recognition/

发布时间：2026-06-04T17:09:58.000Z

Markdown 内容： 2026 年 6 月 4 日

Stella 是 Meta 智能眼镜的配套应用。在检查 Android 版本 273.0.0.21（包名 com.facebook.stella）时，我发现了一套完整的端侧人脸识别计算与存储技术栈：三个人脸模型、一个本地数据库 Schema、一个维度与模型相匹配的余弦相似度向量索引、一条将生物特征记录暂存至磁盘的写入路径、一套完全接好的通知系统，以及一个面向用户的“联系人”小组件。

我想准确说明这究竟意味着什么，以及不意味着什么，因为两者之间的区别至关重要。

我可以证实的是： 相关机制确实存在，且已相互连通。应用中包含多个人脸提取和人脸指纹识别模型，我成功使用测试图片端到端运行了该识别管线。它检测到了人脸，生成了一个 2048 维的生物特征嵌入向量，搜索了本地索引，并在匹配成功时触发了一条 Android 通知，向用户显示“已识别人物”。

为了让该管线运行起来，我直接使用一张测试照片调用了其现有的处理程序。

我无法证实的是： 这些功能是否对普通用户处于激活状态。在未注册的官方正式账号上，面向用户的 UI 并未出现，且识别通知深度链接所指向的页面在该版本中也缺失。此外，我也未观察到 Meta 服务器向我的测试账号相关数据库推送身份数据。

因此，这并非意味着“Meta 正在秘密识别你所看到的人”。实际情况是：用于实现这一功能的完整装置已经存在于设备中，组装完毕且功能正常，只是由 Meta 控制着启用开关。

以下所有发现均可在 com.facebook.stella v273.0.0.21 版本中复现。

• * *

设备端内置三个人脸识别模型（约 100 MB）

三个 ExecuTorch (.pte) 模型通过 Meta 的资源分发系统 NMLML 从 Meta 服务器下载并部署到设备上。

| 资源名称（Meta 命名） | 文件 | 大小 | 功能 | | --- | --- | --- | --- | | android_facerec_scrfd | SCRFD.pte | 3.4 MB | 检测图像中的人脸 | | android_facerec_kps_aligner | KPSAligner.pte | 117 KB | 裁剪并对齐每个检测到的人脸 | | android_facerec_sface | SFace.pte | 96 MB | 将人脸转换为 2048 维数值嵌入向量（即生物特征指纹） |

这些模型对应于开源架构，与其他应用和学术项目中使用的模型系列相同：

• SCRFD_Sample and Computation Redistribution for Efficient Face Detection_（InsightFace, ICLR 2022）。参考实现：github.com/deepinsight/insightface。
• SFace_Sigmoid-Constrained Hypersphere Loss for Face Recognition_（Zhong et al., 2021）。参考实现：github.com/zhongyy/SFace
• KPSAligner 基于关键点的对齐方法，自 2015 年以来的标准做法（MTCNN, dlib, InsightFace）。

Meta 的 SFace 变体似乎比公开参考实现的规模更大（96 MB 对比约 40 MB；输出为 2048 维，而参考实现为 128–512 维）。

需要明确说明的是：仅凭内置检测和嵌入模型本身，并不能作为具备识别功能的证据。许多应用都会在设备端运行人脸检测以实现构图或自动对焦。

• * *

余弦相似度人脸索引，维度与端侧指纹模型精确匹配

实际运行并读取该数据库的识别管线位于：

/data/user/0/com.facebook.stella/files/rldrive/person_profiles/objects.db

该数据库位于 RLDrive（Meta 的跨设备同步框架）下，属于一个设计为由远程填充数据的 person_profiles 命名空间。在我的测试账号上，我并未直接观察到 Meta 专门向 person_profiles 推送数据。我要强调的是，我描述的是该通道的存在，而非观察到的实际传输行为。

数据库 Schema 如下：

CREATE TABLE person (
  nodeid  INTEGER PRIMARY KEY,
  name    TEXT,     
  uri     TEXT,     
  blob    BLOB,
  deleted INTEGER,
  version BLOB
);

CREATE TABLE face (
  nodeid    INTEGER PRIMARY KEY,
  mediaPath TEXT,    -- the face_id used in the deep link
  personUri TEXT,    -- soft reference back to person.uri
  blob      BLOB,
  deleted   INTEGER,
  uri       TEXT,
  version   BLOB
);

CREATE VIRTUAL TABLE face_mediaPath_vec
  USING vec0(mediaPath float[2048] distance_metric=cosine);
  -- 2048-float biometric fingerprint per face, cosine-distance search
  -- (uses the sqlite-vec extension)

每个 face 行通过 personUri 关联到一个 person。每个 face.mediaPath 是 face_mediaPath_vec 的主键，后者存储 2048 维嵌入向量。识别过程是对该索引进行余弦相似度查询，然后与 person.name 进行连接以获取通知文本。

以下几点相互印证：

• vec0 是开源的 sqlite-vec 扩展，可将 SQLite 转变为向量相似度搜索引擎。
• 维度 float[2048] 与应用内置的 SFace 嵌入模型的输出形状完全一致。
• cosine 度量是比较人脸嵌入向量的标准选择。

该 Schema 允许每个 personUri 对应多个 face 行（无 UNIQUE 约束），但在未注册的设备上无法判断生产环境部署采用的是一对一还是一对多关系。

端到端测试确认了两个分支的行为，并明确了写入位置。 我对数据库进行了 SHA-256 快照并统计了行数，然后完整运行了两次识别管线：一次针对空索引（无匹配），一次针对预加载了单个嵌入向量的索引（匹配成功）：

• 无匹配（face_mediaPath_vec 为空）：一对 (uuid.jpg, uuid.emb) 被写入 NameTagsPending/ 目录。未触发通知。
• 匹配成功：通过生产环境的 nametags_recognition 通道触发了一条 Android 通知——标题为_“已识别人物”_，内容为_“识别出 Michel Foucault”_。NameTagsPending/ 目录下未新增任何内容。

• * *

当设备检测到本地索引无法匹配的人脸时，Stella 会将其写入：

/data/user/0/com.facebook.stella/files/NameTagsPending/

每张未识别的人脸都会生成一对以全新 UUID 命名的文件：

• 一个 .jpg 文件——经过裁剪和对齐的人脸图像，是 SCRFD + KPSAligner 的输出结果；以及
• 一个 .emb 文件——包含 2048 个数值的 SFace 特征指纹。

该目录权限为 0700，且在设备重启后依然保留。写入操作仅在匹配失败分支中触发；匹配成功的人脸只会触发通知，不会在磁盘上留下任何痕迹。

我直接验证了嵌入向量的结构：

File:    NameTagsPending/1566ab46-[...].emb
Size:    8,192 bytes (2048 × float32, big-endian)
L2 norm: 0.999999          ← canonical L2-normalized face embedding
Min/max: −0.092110 / +0.098950
Mean:    +0.000292

(uuid.jpg, uuid.emb) 组合在一起，构成了一条完整、可索引的单人脸生物特征记录——其数据形状和编码方式与 person_profiles/objects.db 中余弦索引的设计完全一致，用于后续匹配。

_NameTagsPending_ 这个名称最直白的解读就是“待命名的人脸”——已完成生物特征编码，只等贴上标签。我只需陈述这一结构性事实，其含义不言自明：一张人脸图像及其特征指纹以明文形式并排存储，权限为 0700，重启后依然存在——这恰恰是你若打算在获取标签后追溯识别人脸时所需构建的数据集。

**原始照片**：管线接收的输入图像（Jerry Bauer 于 1970 年拍摄的 Michel Foucault 肖像，318×418 像素 JPEG，28 KB）。公有领域，来源：Wikimedia Commons。

**Stella 管线生成的裁剪人脸**，已写入 NameTagsPending/ 目录。由 SCRFD（检测器）+ KPSAligner（对齐器）输出。83×118 像素 RGB JPEG，4,396 字节。

• * *

通知界面已完全接通

Stella 定义了一个专用的 Android 通知渠道：

NotificationChannel{
  id          = "nametags_recognition"
  name        = "NameTags recognition"
  description = "Notifications for recognized NameTags connections"
  importance  = IMPORTANCE_HIGH      (heads-up + sound + badge)
  sound       = system notification sound
}

通知模板在识别处理器中被硬编码。标题始终为 _"Person recognized"_；内容始终为 "Recognized " + name，其中 name 来自 person_profiles/objects.db 中的 person 表：

NotificationCompat.Builder(ctx, "nametags_recognition")
  .setContentTitle("Person recognized")
  .setContentText("Recognized " + matched_name)
  .setAutoCancel(true)
  .setContentIntent(
    PendingIntent.getActivity(
      ctx,
      matched_name.hashCode(),
      Intent.ACTION_VIEW with
        Uri "fb-viewapp://name_tags?face_id=" + face_id,
      FLAG_IMMUTABLE | FLAG_UPDATE_CURRENT))
  .build()

NotificationManagerCompat.notify(matched_name.hashCode(), notification)

该通知支持点击：其 contentIntent 是一个形如 fb-viewapp://name_tags?face_id=<face_id> 的深度链接，这是 Meta 自定义的 URL scheme，旨在打开 Stella 内部的人物资料页面。

需要如实说明一点：在 v273 版本中，我未能找到该目标页面。点击通知后，Stella 会跳转到默认标签页，因为导航图中缺少对应的 Compose 目标页面。通知可以正常触发，但其所指向的页面并未包含在此版本中。

• * *

APK 中存在面向用户的“Connections”入口

Stella v273 包含一个组件，会在标题为 "Connections" 的区域下渲染一张卡片，显示文本 _"See your connections"_ / _"Remember the people you met and make new connections."_。这两个字符串均为 APK 中的硬编码字面量，并非由服务器下发。

在未注册的普通账号上，该卡片在 Glasses 标签页中完全不显示。它仅在测试过程中才变得可见。在正常使用情况下，用户不会看到此内容。

• * *

综上所述

1. 完整的端侧人脸识别技术栈：包括检测、对齐、特征嵌入、向量索引、存储、写入路径及通知界面，均已存在于 Stella v273 中并完成集成。
2. 该系统具备功能性。端到端运行时，它能识别已知人脸并在通知中显示姓名，同时将未知人脸（裁剪图 + 特征指纹）暂存至磁盘。
3. 索引维度、嵌入向量形状与存储模式相互一致——这是一个连贯的系统，而非零散的废弃代码。
4. 用户实际可能接触到的部分：“Connections”卡片以及通知所打开的资料页面，要么未包含在当前构建中，要么被隐藏得更深。
5. 实时管线所使用的数据库位于 Meta 在服务端填充的同步命名空间中，与其他已由服务端填充的命名空间并列，但我未观察到我的账号收到过针对人脸命名空间的推送。

我并未声称：Meta 目前正在为用户识别陌生人、注册数据正在传输，或上述任何功能已在生产环境中启用。

但难以忽视的事实是：构建、交付并打通如此庞大的系统，直至实现 2048 维人脸特征提取和硬编码的“Person recognized”通知，是一项实质性的工程投入。这种能力绝非意外产物。至于是否以及何时投入生产，则需由 Meta 来回答。

_本研究与 WIRED 的报道同步发布。_