Vector Storage：让浏览器成为你的专属向量数据库

想象一下这样的场景：你是一名 AI 应用开发者，正在构建一个本地优先的个人知识助手，不希望把数据上传到任何第三方服务器，却仍然希望能够"听懂"用户的语义查询——不只是关键词匹配，而是真正理解句子的含义。这时候，Vector Storage 登场了：它让浏览器本身成为一个轻量级的向量数据库，配合 OpenAI 的 embeddings API，在本地完成语义搜索的全流程。

一个以色列开发者的"边缘优先"实验

Vector Storage 的作者是来自以色列的独立开发者 Nitai Aharoni，项目于 2023 年 5 月在 GitHub 开源。作者在 LinkedIn 发文时写道：他希望让向量搜索的能力"下沉"到每一个普通用户的浏览器里，而不是只有拥有专业服务器团队的企业才能玩得起这项技术。

这一理念与当前 AI 领域"边缘计算"的大趋势不谋而合——当 Mistral、Llama 等开源模型不断压缩尺寸推向本地部署，向量数据库也在朝着"轻量化、浏览器化"的方向演进。Vector Storage 正处于这个交叉点上。

核心原理：把文字翻译成数字，再用数字找相似

Vector Storage 的工作原理分为三个阶段：编码 → 存储 → 搜索。

第一阶段：向量化（Embedding）。当用户调用 addText() 或 addTexts() 添加文档时，Vector Storage 会将文本通过 OpenAI 的 Embeddings API（默认使用 text-embedding-ada-002）转换为高维向量。每个文本对应一个固定维度的浮点数数组（1536 维），语义相似的文本在向量空间中距离更近。

第二阶段：本地持久化（IndexedDB）。转换后的向量并不发送到服务器，而是通过 Dexie.js（IndexedDB 的 Promise 封装库）直接写入浏览器的本地数据库。IndexedDB 的容量远大于 localStorage（通常从 50MB 到无限制，取决于浏览器和设备），Vector Storage 默认上限为 50MB，超出后自动触发 LRU（最近最少使用）淘汰机制，按照命中次数和写入时间双重排序，优先删除最不常用、最老的文档。整个过程对用户完全透明。

第三阶段：余弦相似度搜索（Cosine Similarity）。当用户发起查询时，输入的文本同样被编码为向量，然后与本地存储的所有向量逐一计算余弦相似度。计算公式为：

余弦相似度 = dot(a, b) / (|a| × |b|)

结果经过归一化处理（映射到 0-1 区间），得分越接近 1 表示语义越相似。Top-K 结果（默认 K=4）会被返回，同时更新这些文档的命中计数，为下一次的 LRU 淘汰提供依据。

技术架构：TypeScript + 模块化设计

Vector Storage 的代码结构非常清晰，总共只有 11 个文件，分为三层：

• VectorStorage.ts（核心类，约 220 行）：封装所有业务逻辑，包括数据库初始化、向量编码、相似度计算、LRU 管理
• types/（类型定义）：IVSDocument（文档结构）、IVSOptions（配置项）、IVSSimilaritySearchParams（搜索参数）等 5 个接口，类型覆盖完整
• common/（工具函数）：constants.ts（默认常量）和 helpers.ts（文档过滤、内存计算）

整个项目使用 TypeScript 严格模式编译为 ES6 模块，发布为 npm 包（dist/index.js + dist/index.d.ts）。开发依赖中包含完整的 ESLint 配置（5 个插件 + Prettier + TypeScript 规则集），代码风格一致性有保障。值得关注的是，Dexie.js 和 idb 两个 IndexedDB 封装库同时出现在依赖中，这表明作者在探索最优的 IndexedDB 操作方式。

灵活的嵌入策略：不仅限于 OpenAI

一个容易被忽略的细节是：Vector Storage 并不强制绑定 OpenAI。IVSOptions 中提供了 embedTextsFn 配置项，开发者可以传入自定义的嵌入函数，对接任何向量生成服务——比如 Cohere、Vertex AI、本地运行的 Sentence Transformers，甚至是专门训练的垂直领域嵌入模型。这意味着 Vector Storage 本质上是一个向量存储的抽象接口，嵌入层的选择完全由开发者决定。

局限与争议

尽管思路新颖，Vector Storage 的局限性也很明显：

1. 向量维度受限于 OpenAI 模型：OpenAI 的 text-embedding-ada-002 输出 1536 维向量，存储每个文档需要约 6KB 空间。50MB 上限大约能存储 8000-10000 个短文档，对于小型知识库够用，但无法支撑生产级 RAG 场景。

2. 纯浏览器环境限制：IndexedDB 的存储容量与设备强相关，iOS Safari 早期版本曾有 500MB 上限，移动端用户可能遭遇存储不足。此外，每次搜索都需要在浏览器主线程做数千次点积运算，大文档量时 UI 可能有卡顿。

3. 无法做复杂的向量索引：没有 HNSW、IVF 等近似最近邻（ANN）算法，所有搜索都是暴力遍历。当文档数量达到数千规模时，每次查询都要做 1536 维的点积运算，性能会明显下降。

4. API Key 安全问题：当前架构要求前端持有 OpenAI API Key，这在生产环境中存在密钥泄露风险。作者在 README 中有提示建议，但未提供服务端代理的参考实现。

行业意义：从"云端大脑"到"本地直觉"

Vector Storage 代表了一个正在壮大的技术方向：在用户设备上运行的本地向量引擎。2023 年下半年，Chrome 宣布内置 SQLite Wasm 版本、Edge 推出本地 AI 搜索功能，都指向同一个趋势——AI 能力正在从云端向边缘下沉。

对于隐私敏感的应用场景（医疗记录、法律文档、内部知识库），Vector Storage 提供了一种无需任何后端基础设施就能实现语义搜索的方案。虽然它无法替代 Pinecone、Weaviate 这类专业向量数据库，但对于原型验证、教育学习、轻量级个人工具来说，Vector Storage 是一个门槛极低的起点。

项目目前 245 Stars、39 Forks、8 个 open issues，由作者独立维护。最新一次提交为 2024 年 12 月，仍在活跃维护中。如果你正在探索 RAG 架构或想在浏览器中实验向量搜索，不妨从 npm i vector-storage 开始，在本地跑通全流程。