Chrome 扩展如何实现本地图像向量检索

把图片特征提取和向量检索放进 Chrome 扩展，难点不只是让模型跑起来。Manifest V3 的后台随时可能被终止，模型加载和索引还会争抢页面资源。作者以 OmniPic 为例，介绍了一套图片不出设备的本地检索流程。

值得读的是这套实现背后的约束和取舍：任务怎么恢复、索引怎么复用、首次加载怎么交代。不过，原文没有公开模型、性能数据或完整代码，更适合作为架构经验参考。

为什么先设计任务恢复，再考虑模型

Manifest V3（MV3）的 service worker 不是常驻后台。它可能随时被终止，因此长任务和保存在内存中的模型状态，都不能默认一直存在。

作者给出的方向是：把工作拆成短小、可恢复的单元，模型按需加载。对于图片索引，这要求开发者考虑中断后从哪里继续，以及哪些计算结果已经保存。原文没有展开检查点、任务队列或恢复机制，不能直接当成完整实现方案。

另一个约束是资源。模型文件和索引数据会与网页争抢内存，冷启动慢也会直接影响体验。把服务端程序搬进扩展，并不会自动得到一个好用的端侧产品。

权限同样要进入设计。跨域请求、下载和存储都要声明相应权限；作者认为，相比 MV2，审核也更严格。每多申请一项权限，都要承担额外的审核风险和用户信任成本。

端侧 AI 的架构，要围绕可中断的后台和有限的浏览器资源重新设计。

1024 维检索解决了什么，又没证明什么

OmniPic 的流程并不复杂：先把图片变成特征向量，再用同一套提取方式处理查询图片，通过余弦相似度找到接近的结果。

原文用下面两行描述建库和查询的关系：

Image -> on-device feature extraction -> 1024-d vector -> local index
Query image -> same extraction -> cosine similarity -> TopK -> results

第二行的关键是 same extraction：查询图片与图库图片必须采用同一套特征提取方式，才能在同一个向量空间里比较。TopK 则表示取相似度最高的 K 个结果，原文没有给出 K 的具体值。

作者选择 1024 维，理由是：维度更少时，相似图片不容易区分；维度更多时，消费级硬件上的索引和计算负担会明显增加。作者称这是自己测量后的平衡点，但没有披露使用的模型、设备、图片规模、耗时或检索质量指标。

所以，1024 是这套实现的选型结果，不能直接当成其他项目的默认答案。

索引方面，向量和元数据保存在浏览器存储中，只为新增图片提取特征，已有向量继续复用。这样可以避免每次启动都重建图库。至于采用哪种浏览器存储、如何处理图片变更，以及相似度计算是否使用专门的索引结构，原文都没说清楚。

隐私主张也来自数据路径：作者称图片不离开设备，查询不访问网络，因此「0 bytes uploaded」有架构依据。原文建议打开 DevTools 的 Network 面板，观察运行时是否存在携带图片内容的出站请求。这是有用的检查入口，但一次观察不能替代对完整数据流的核查。

真正磨人的部分，可能是找到原图

图片检索之外，作者还谈到批量下载原图。网页展示的图片往往是 CDN 缩放版本，拿到当前元素的地址，不等于拿到最高分辨率文件。

实现需要追踪 srcset、懒加载属性、CSS 背景图等线索；同一图片可能存在多个尺寸，还要去重并保留更好的副本。失败重试和可读的文件名，也属于交付的一部分。

这对前端开发者很有参考价值：模型完成的是特征提取，页面结构适配决定了输入质量和下载结果。后者通常需要逐站处理细节。

作者还列出三个实际遇到的问题：Chrome、Edge、Firefox 的扩展 API 实现进度不同；首次加载模型容易流失用户；权限申请过多会增加阻力。对应做法是跨浏览器验证、展示加载进度并按需加载，以及只申请功能必需的权限。

我的判断

我认可本地索引、增量计算和可恢复任务这几个方向。它们分别减少重复计算、缩短后续启动成本，并适应 MV3 的后台生命周期，理由比较扎实。

但原文的证据不足以证明性能优势。没有对照数据，就无法判断 1024 维比其他维度好多少，也不能判断端侧方案在多大图库下仍然流畅。这部分应当视作作者的工程经验。

与服务端检索相比，本地方案能减少图片上传环节，却把模型加载、计算和存储压力留给用户设备。选哪条路，需要结合数据敏感程度和实测结果，不能只看服务器成本。

作者还称这套本地优先思路用于 ResumeRadar、OmniPost、OmniSense 等工具。不过，「本地优先」不自动等于全部功能离线。比如 OmniPost 涉及向 8 个平台同步，原文没有交代同步时的数据边界，不能把 OmniPic 的图片隐私主张直接推广到整套产品。

能拿来做什么

• 做图片检索扩展时，先验证索引任务能否中断后继续，并复用已经保存的向量，再扩大图库规模。
• 选择向量维度前，用自己的模型、目标设备和图片集比较检索质量、耗时与存储占用，把 1024 当作一个候选值。
• 设计首次打开体验时，提供模型加载进度和可理解的状态提示，避免用户面对空白面板等待。
• 做原图下载或隐私检查时，分别核查 srcset 等图片来源线索，以及 Network 中的出站请求，让功能表现和隐私描述都有可检查的依据。