RAG 本地最佳嵌入模型 (2026)

开放、可自托管的嵌入模型，让你在自己的硬件上处理文本——经过对比、排名，并与你的使用场景匹配。

Aquila 团队 更新于 2026年6月19日

大多数自托管 RAG 系统的最佳本地嵌入模型是 nomic-embed-text ——体积小、在 CPU 上速度快、采用宽松许可证，并且性能足够出色，让你很少需要升级。如果检索质量比速度更重要，可以升级到 mxbai-embed-large 或 bge 模型；当你需要处理长文档或多语言时，选择 bge-m3。本指南对比了值得运行的开源、可自托管模型，展示了如何根据使用场景进行选择，并解释了与 OpenAI 托管嵌入之间的质量与成本权衡。

嵌入模型将文本块转换为向量——一串捕捉语义的数字——从而使相似的段落落在向量空间中接近的位置。这是 RAG 和语义搜索背后的检索引擎。如果你想从头了解概念，请阅读什么是嵌入；要了解这些向量如何被搜索，请阅读什么是向量数据库。本页讨论的是当你把整个管道保留在自己的硬件上时，应该运行哪个模型。

为什么要在本地运行嵌入

如果你出于隐私原因自托管 RAG，在本地进行嵌入是不可避免的一步。将向量数据库私有化，却将每个文档的每个块发送给第三方进行向量化，这很奇怪——这恰恰是你原本试图保护的内容。本地嵌入模型弥补了这一差距：

  • 你的文本永远不会离开机器。 索引和查询都在你的硬件上运行。
  • 零按 token 费用。 没有按量计费的 API；模型在你已经付费的 CPU（或 GPU）上运行。
  • 没有供应商锁定或无声的模型更新。 你可以固定版本；检索质量不会一夜之间发生变化。
  • 能够离线 / 在隔离环境中使用。 该模型只是一个一次性下载的文件。

坏处是你需要选择模型，而不同的选择在大小、速度、维度数量和质量上各不相同。这就是本指南其余部分要解决的问题。

模型对比

这些是 2026 年值得你在 RAG 中关注的开源、可自托管模型。维度和许可是可靠的事实；将“质量”视为相对定位，而非排行榜得分——基准测试（MTEB）会发生变化，而你的语料库才是真正重要的。

模型维度数大致大小最大上下文许可协议适合场景
nomic-embed-text768~270 MB长（8K 级别）Apache-2.0默认选择。CPU 上速度快，长上下文，出色的全能选手。
mxbai-embed-large1024~670 MB512Apache-2.0当你有多余计算资源时，提供更高质量的英文检索。
bge-large-en-v1.51024~1.3 GB（335M 参数）512MIT英文质量强劲，久经考验，广泛支持。
bge-base-en-v1.5768~440 MB（109M 参数）512MITBGE 家族中质量与速度的折衷。
bge-m31024~2.3 GB8192MIT长文档 + 100 多种语言 + 稠密/稀疏/多向量。
e5-large-v21024~1.3 GB（335M 参数）512MIT稳健的多语言检索；成熟、文档齐全。
gte-large1024~670 MB512Apache-2.0竞争力强的英文质量，相对其维度数而言体积紧凑。

一些说明，以免数字误导你：

  • 大小是近似的，取决于量化（Ollama 提供量化的 GGUF 版本，因此磁盘占用通常比原始的 Hugging Face checkpoint 小）。请使用它们进行相对比较，而非容量规划。
  • 此处 nomic-embed-text 为 768 维，以匹配 Aquila 指南中使用的数值；它是最轻量、可信赖的默认选择。有些资料引用了 1024 维的变体——无论你部署哪个版本，都要固定下来，并在索引和查询之间保持一致。
  • 维度更多并不严格更好。 高维向量可以捕捉更多细微差别，但会消耗更多存储和内存，并导致搜索稍慢。对于大多数知识库来说，768 维就足够了。
  • 上下文长度对分块很重要。 512 token 的模型意味着你的块必须在 ~512 token 或更小；8K 级别的模型（nomic、bge-m3）允许你嵌入更大、更连贯的段落。

如何根据使用场景选择

没有单一的“最佳”模型——请将其与你的情况相匹配。

“我只想要一个可靠的默认选择” → nomic-embed-text

体积小，可在仅 CPU 的 VPS 上运行，支持长上下文，采用 Apache-2.0 许可，并且质量在许多任务上与 OpenAI 的旧版嵌入不相上下。对于绝大多数自托管 RAG 系统，从这里开始，只有当你的评估集告诉你需要时才更换。

“质量比速度更重要” → mxbai-embed-large 或 bge-large-en-v1.5

当检索精度成为瓶颈，并且你有 CPU 余量（或 GPU）时，1024 维的大模型通常能提高英文语料库的召回率。mxbai-embed-large 通过 Ollama 运行简洁；bge-large-en-v1.5 是久经验证的选择，拥有最广泛的生态系统支持。始终在你的问题上确认提升效果——差异往往比基准测试差距所暗示的要小。

“长文档或多语言” → bge-m3

bge-m3 支持 8192 token 输入和 100 多种语言，并且原生生成稠密、稀疏和多向量表示——如果你想要混合搜索而不必额外添加独立的关键词索引，这会很方便。它是这里最重的模型；请相应规划内存。

“尽可能小的体积” → bge-base-en-v1.5 或 nomic-embed-text

对于小型 VPS 或边缘设备，768 维的基础模型使模型和向量索引都保持较小。嵌入存储随维度增加：768 维的 float32 向量原始大小约为 3 KB，1024 维约为 4 KB，尚未计入索引开销——乘以你的块数即可估算。

“多语言是不可妥协的” → bge-m3 或 e5 家族

BGE-M3 和 E5 系列在训练时就考虑到了多语言检索。如果你的文档和查询跨越多种语言，应从那里开始，而不是英文优先的模型。

如何运行它们

两种方式，取决于你的技术栈。两者都使文本保留在你的硬件上。

通过 Ollama（最简单）

如果你已经在运行 Ollama 进行生成（参见在 VPS 上构建私有 RAG），嵌入只需一次 pull：

ollama pull nomic-embed-text
ollama pull mxbai-embed-large
ollama pull bge-m3

然后直接调用嵌入端点：

curl http://localhost:11434/api/embeddings -d '{
  "model": "nomic-embed-text",
  "prompt": "Own your search."
}'

或者通过 LlamaIndex / LangChain，两者都有单行的 Ollama 嵌入封装，可直接插入你的索引管道。

通过 sentence-transformers（Python，完全控制）

适用于 Hugging Face 上的模型（完整的 BGE / E5 / GTE 目录），并对批处理和池化进行直接控制：

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-large-en-v1.5")
vectors = model.encode(
    ["Own your search.", "Self-hosted RAG keeps your data yours."],
    normalize_embeddings=True,   # 余弦相似度随后等于点积
)
print(vectors.shape)   # (2, 1024)

一个覆盖所有模型选择的规则：在索引和查询时使用完全相同的模型和版本。 来自不同模型的向量位于不同的空间中，不可比较——混合它们会静默地返回垃圾结果。有些模型（E5、BGE）还期望指令前缀，如 "query: " / "passage: "；请遵循每个模型的说明卡，并在两侧一致地使用此前缀。

质量与成本对比 OpenAI

这是大多数定价页面不会做的诚实比较。

本地（例如 nomic-embed-text）OpenAI text-embedding-3-small
每 token 成本$0（在你的硬件上运行）~$0.02 / 1M token
隐私文本从不离开你的机器每个块和查询都发送给 OpenAI
质量良好到非常好（取决于模型）优秀，无需调优
运维负担你运行模型无
供应商锁定无；固定版本供应商依赖 + 无声更新

这是人们忽略的部分：嵌入无论如何都是便宜的项目。 以约 $0.02/百万 token 的价格（text-embedding-3-small；text-embedding-3-large 约为 $0.13），调用 OpenAI 进行嵌入在美元成本上几乎免费——在托管 RAG 账单中，生成 LLM 占据主导地位，而不是嵌入。因此，你自托管嵌入不是为了在嵌入 API 上省钱。你自托管嵌入是为了隐私和控制：使用本地模型，你的文档永远不会传输给任何人，到此为止。如果隐私是你自托管 RAG 的原因，那么本地嵌入并非可选——它们是全部意义所在。完整的美元比较请参见自托管 RAG 与 OpenAI + Pinecone。

在质量方面，对于日常知识库检索，差距已基本消失。像 nomic-embed-text 或 bge-large 这样好的本地模型不会成为你的 RAG 系统表现不佳的原因——分块和检索调优才是。请将精力投入后者。

不要仅凭基准测试选择

MTEB 得分是一个有用的起始过滤器，而非定论。在学术数据集上主导公共排行榜的模型，可能在你实际的工单、合同或代码上并不胜出。可靠的方法是：

  1. 从上面的表格中选择 2-3 个符合你大小/许可证/语言限制的候选模型。
  2. 构建一个小型评估集——20-50 个真实问题，每个问题标记出应回答该问题的文档。
  3. 使用每个候选模型对你的语料库进行索引，并测量正确来源出现在 top-k 结果中的频率。
  4. 根据你的数据选择胜者，然后继续——追求更好模型带来的边际收益通常小于改进分块带来的收益。

常见问题

RAG 应使用哪个本地嵌入模型？ 从 nomic-embed-text 开始——它体积小、在 CPU 上快、支持长上下文、采用 Apache-2.0 许可，并且对大多数知识库来说足够好。如果你的评估集显示检索质量是瓶颈，则升级到 mxbai-embed-large 或 bge-large-en-v1.5；对于长文档或多语言，则使用 bge-m3。

本地嵌入模型和 OpenAI 的一样好吗？ 对于典型的知识库检索，非常接近，以至于很少产生影响。OpenAI 的模型无需调优即可表现优秀，但一个好的本地模型不会成为拖累 RAG 系统的原因——分块和检索策略才是。而且本地模型能保持文本私密，这正是自托管的真正原因。

维度数越高，检索效果越好吗？ 不一定。更多维度可以捕捉更多细微差别，但会消耗更多存储、内存和搜索时间。像 nomic-embed-text 这样的 768 维模型对大多数使用场景来说已经足够；只有在测量到你的数据有实际提升时，才去使用 1024+ 维。

以后可以更换嵌入模型吗？ 可以，但你必须重新嵌入整个语料库——来自不同模型的向量不可比较，因此你不能混合新旧模型。将模型切换视为一次全面的重新索引，并且始终对索引和查询使用相同的模型。

运行嵌入需要 GPU 吗？ 不需要。对于中等规模的语料库，像 nomic-embed-text 和 BGE 基础模型在 CPU 上也能舒适地进行嵌入。GPU 可以加速超大型文档集的批量索引，但不是入门所必需的。

Aquila 是关于私有、自托管 AI 搜索的独立指南——建立在这样的信念上：你应该拥有自己的索引，而非租用它。准备好让这些模型之一投入使用了吗？请遵循在 VPS 上构建私有 RAG，或探索更多指南。掌控你自己的搜索。

继续学习

更多关于自托管 AI 搜索、RAG 和向量数据库的指南。

全部指南 通过 RSS 订阅