chromem-go：用 Go 编写的可嵌入向量数据库

图1：项目作者 Philip Gille

一、痛点切入：当 LLM 应用遇上向量检索

想象你正在构建一个基于检索增强生成（RAG）的法律文书分析系统。用户输入一段法律咨询，系统需要在海量判例中找到语义最相似的段落，再将结果注入 LLM 上下文。这听起来是个标准 RAG 流程——但背后有一个关键抉择：

向量数据库要不要单独部署？
如果你选择 Qdrant、Milvus 或 Weaviate，就需要多维护一套服务：容器化、版本管理、网络互通、鉴权、备份……对于个人开发者或小型团队而言，运维负担可能远超业务本身。chromem-go 给出了另一个答案：直接把向量数据库嵌入到你的 Go 应用进程中，像使用 SQLite 而非 PostgreSQL 那样。

二、项目背景：Chroma 的 Go 表亲，不是替代品

chromem-go 由德国开发者 Philip Gille 创建，定位是一款零第三方依赖的 Go 向量数据库库。它与 Chroma（Python 生态的向量数据库）有着相似的 API 接口设计，但两者有本质区别：chromem-go 不是连接 Chroma 的客户端，也不是 Chroma 的 Go 重写——它是一个完全独立的数据库，在 Go 运行时内运行，不需要任何外部服务进程。

项目的核心理念是极简主义：不追求百万级文档规模，不追求功能最全，而是专注于最常见的 RAG 场景——几千到十几万量级的文档检索——在延迟和性能上做到极致。官方基准测试显示，在 2020 年中端 Intel 笔记本 CPU 上，查询 1,000 条文档仅需 0.3ms，查询 100,000 条文档仅需 40ms，且内存分配次数极少。

三、技术架构：纯 Go、无 CGO、零外部依赖

chromem-go 的代码结构极为干净，根目录即是完整数据库实现：

3.1 内存模型

chromem-go 采用内存优先设计，数据全部驻留在 Go 进程的内存中。Collection 是最顶层抽象，每个 Collection 包含多个 Document，Document 持有原始文本、元数据和一个 float32 向量。文档 ID 通过 SHA256 前缀（8个十六进制字符）生成，短小且避免文件名冲突。

Collection 支持可选持久化：通过 gzip 压缩 + AES-GCM 加密将内存数据落盘，数据以 gob 格式序列化，可选加密（AES-256-GCM，密钥用户自行保管）。这一设计使得 chromem-go 既能做临时内存数据库，也能在需要时变成持久化存储。

3.2 嵌入函数插件

向量生成不内置模型，而是通过 EmbeddingFunc 函数类型注入。官方内置了四种适配器：

• embed_openai.go：默认使用 OpenAI text-embedding-3-small，向量归一化
• embed_ollama.go：连接本地 Ollama 服务（Llama2、Mistral 等），适合离线场景
• embed_cohere.go：Cohere Embed v3，多语言支持优秀
• embed_vertex.go：Google Vertex AI，支持 PaLM 等模型

这种设计让数据库层与嵌入模型层完全解耦：你可以随时切换底层模型，而无需改动数据库逻辑。

3.3 WASM 支持：浏览器内运行

项目包含 wasm/ 子目录，编译目标为 WebAssembly。这意味着 chromem-go 可以直接在浏览器中运行，实现真正的零服务器向量检索。这对于构建本地优先的 AI 原型工具具有独特价值。

3.4 示例生态

项目提供了 4 个完整示例，覆盖从入门到生产级的不同场景：

• examples/minimal：最小化使用示例，10 行代码完成文档添加与查询
• examples/rag-wikipedia-ollama：基于 Wikipedia 的完整 RAG 流程（Ollama 本地模型）
• examples/semantic-search-arxiv-openai：arXiv 论文语义搜索（OpenAI 嵌入）
• examples/s3-export-import：S3 持久化导入导出，适合生产环境备份

四、使用门槛：两行代码入门

chromem-go 的上手体验极为友好。作为 Go 库，只需 go get 引入即可：

import "github.com/philippgille/chromem-go"

// 初始化数据库
db, _ := chromem.New()

// 创建 Collection（使用默认 OpenAI 嵌入）
coll, _ := db.CreateCollection("docs", nil)

// 添加文档
coll.Add(ctx, []chromem.Document{
    {ID: "1", Text: "chromem-go 是一个可嵌入向量数据库"},
})

// 语义查询
results, _ := coll.Query(ctx, "什么是 chromem-go", 3, nil)

无 Web UI，完全通过 Go 代码操作。对于习惯了 Chroma Python API 的开发者，chromem-go 的 Collection/Query 风格非常熟悉，迁移成本极低。

五、局限性与争议

不追求大规模：作者明确表示项目不针对百万级文档场景。如果你需要 PB 级向量检索，应选择 Qdrant 或 Milvus。chromem-go 的设计边界是「中小规模 + 高性能 + 零运维」。

仍在 Beta：项目在 v1.0.0 之前可能引入破坏性变更，CHANGELOG 记录了所有 breaking change。对于生产环境使用，需要锁定版本号。

单机构限制：所有数据在单进程内存中，不支持分布式向量检索、多副本容灾等企业级特性。

六、行业意义：嵌入式向量数据库的新范式

chromem-go 代表了一个趋势：嵌入式（embedded）数据库让开发者像使用 ORM 那样使用专业数据存储。从 SQLite 到 leveldb，再到 chromem-go，嵌入式数据库的边界在 AI 时代被重新定义。

在 LLM 应用快速落地的当下，能在不改变架构的前提下引入向量检索能力，对 Go 生态的 AI 开发者意义重大。2024 年 GitHub Stars 接近千星，对于一个专注 Go 生态、定位极清晰的小型项目而言，增长质量相当不错。

定位总结：chromem-go = Go 生态的 SQLite 哲学 × RAG 场景 × 零运维负担。