2026 嵌入模型选型指南：OpenAI、Gemini、Voyage 与开源方案怎么选

嵌入模型怎么选，关键看它能否稳定检索到回答问题所需的内容。可以先用 OpenAI text-embedding-3-small 建立低成本文本检索基线，再对比 Voyage 4 的检索效果；如果资料包含音频或视频，则考虑 Google Gemini Embedding 2。OpenAI small 的输入价格低至每百万 tokens $0.02，但真正需要提前考虑的是向量索引：换用嵌入空间不兼容的模型，就得重建索引。

嵌入模型会把内容转换成向量，也就是一组数字。这样，即使用词不同，搜索也能找到语义相关的内容。对客服机器人来说，它要能把“我登录不了账号”匹配到正确的登录故障排查文章。检索增强生成，也就是 RAG，再把检索到的资料交给负责生成答案的模型。

本文的规格、价格和许可证信息已于 2026 年 10 月 15 日对照厂商在线页面核实。 本文基于官方文档进行对比，没有实测准确率或延迟。下文的推荐适合作为自行评估的起点。开篇所列单价来自 OpenAI 价格页。

嵌入模型对比：先看适用场景和价格

先选能满足检索要求的最便宜模型，再根据语言、资料格式或部署限制调整候选名单。下面的七个模型系列涵盖托管 API、私有化部署和可下载权重。

除标注为自行部署的条目外，价格均为每百万文本输入 tokens 的标准付费价格，以美元计，不含向量数据库、答案生成和重排序费用。重排序是指用另一个模型对检索出的候选结果重新打分。不同供应商的文本分词方式不同，同一份文档可能产生不同的计费 token 数量。

“开放权重”意味着可以获取模型文件并自行运行，不代表计算、部署和维护免费。“多语言”也不代表每种语言的准确率都一样：要测试用户实际使用的查询语言与文档语言组合。

值得评估的模型系列

1. OpenAI text-embedding-3：实用的文本检索基线

OpenAI text-embedding-3-small 和 text-embedding-3-large 都是托管文本嵌入模型。如果创业团队要上线常规帮助中心搜索或客服机器人，我建议从 small 开始：成本低，也不用维护模型服务器。等 small 反复漏掉相关段落，再把 large 纳入对比。还没收集到这些失败案例就直接付费升级，会跳过选型中最有价值的一步。

向量维度： small 默认为 1,536，large 默认为 3,072。两者都支持通过 dimensions 参数缩短向量。
输入上限： 两款模型单条输入均为 8,192 tokens。
语言与模态： 多语言文本；均不接受图像、音频或视频。所引文档未列出完整的支持语言数量。
运行方式： OpenAI 托管嵌入 API。参见规格和模态支持。
适合谁： 希望快速建立可衡量基线的文本应用开发者。
主要特点： 在同一套 API 中对比 small 与 large，并配置输出维度。
价格： small 每百万输入 tokens $0.02；large 为 $0.13。标准价格核实于 2026 年 10 月 15 日。参见价格页。
免费试用： 不预设有新用户 API 赠送额度，按付费使用做预算。

它的主要限制是输入格式。故障排查 PDF 如果只保留提取出的文字，可能会丢掉那张说明“该按哪个按钮”的截图。两款 OpenAI 嵌入模型都无法还原这些视觉信息。如果提取文字后答案仍然完整，可以用文本嵌入；如果答案依赖页面呈现，就应对比多模态模型。

还要分清模型大小与向量维度。large 降低输出维度后，也许能满足现有存储限制，但这不意味着它可以直接替换 small。向量长度相同只说明数据结构匹配，不能证明两个模型以同样的方式组织语义。

建立基线时，先让检索问题暴露出来

初始流程要足够简单，能解释每条结果为什么被检索出来。

1. 1

   把资料切成能回答问题的片段

   按主题或章节切分帮助中心内容。每个片段都保留文档标题、来源 URL、客户访问权限和稳定的片段 ID。不要为了填满模型上下文窗口，把互不相关的操作说明拼在一起。

2. 2

   固定嵌入配置

   选择 text-embedding-3-small，记录输出维度。所有入库片段使用同一配置生成嵌入，再创建维度匹配的向量索引。原始文本另外保存。

3. 3

   先验证搜索，再接入答案生成

   使用相同配置为每个测试问题生成嵌入，检索最接近的片段并逐一查看。生成的答案即使看起来合理，也可能掩盖检索选错来源的问题。

4. 4

   用同一批问题对比候选模型

   为 large 或 Voyage 单独建立候选索引，保持资料切分和相关性标注不变。只有改善对应用确实有价值时，才采用新模型。

2. Voyage AI 4：值得与基线对比的检索 API

如果检索质量直接影响产品价值，Voyage AI 的 Voyage 4 系列值得加入托管文本嵌入候选名单。先对比 voyage-4，再根据延迟和成本评估 lite，或测试厂商定位为通用系列最高质量选项的 large。比起容易命中的关键词样例，技术文档搜索更能检验效果：用户经常会用不同说法描述同一个故障。

向量维度： 默认为 1,024；voyage-4-lite、voyage-4 和 voyage-4-large 均支持 256、512 和 2,048。
输入上限： 上述模型均为 32,000 tokens。
语言与模态： 多语言文本；模型表未给出完整的语言数量。这些模型与 Voyage 另行提供的多模态模型不同。
运行方式： Voyage AI 托管嵌入 API。参见模型规格。
适合谁： 愿意先对比检索效果，再决定使用哪家 API 的开发者。
主要特点： 通用 Voyage 4 系列内的嵌入兼容。
价格： 每百万输入 tokens，4-lite 为 $0.02，4 为 $0.06，4-large 为 $0.12，核实于 2026 年 10 月 15 日。参见价格页。
免费试用： 价格页为当前通用模型列出初始 2 亿免费 tokens；使用时需核对具体模型对应的额度。

系列内兼容对运维很有帮助。Voyage 文档说明，这些模型共享嵌入空间，因此评估另一款查询端模型时，不一定要重建全部文档向量。仍需保持输出维度一致，并实测具体的文档端与查询端组合。不能把这一承诺扩展到所有冠以 Voyage 名称的模型。

需要注意的是静默截断：API 的 truncation 默认值为 true。长文档即使丢掉了末尾内容，仍可能返回有效向量。开发入库流程时，把它设为 truncation=false，让超长输入明确报错，再修正切分方式。大上下文是为了容纳连贯的段落，不代表应该把整本手册做成一条搜索结果。参见 API 行为说明。

对于纯代码语料，厂商还提供 voyage-code-4；可以用代码仓库相关问题，对比专用模型与通用候选模型。不必仅仅因为部分客服文章里有代码片段，就引入专用模型。

3. Google Gemini Embedding 2：覆盖多种输入的多模态选择

如果搜索需要关联文本、图像、音频、视频或 PDF 页面，可以把 Google Gemini Embedding 2 纳入托管方案候选。对于同时包含文字指南和产品演示录像的客服系统，它能把这些资料放进同一个嵌入空间。选它的理由应是这些模态确实承载了有用信息，然后再用自己的资料检验检索效果。纯文本帮助中心不会因为支持的输入类型更多，就自动获得提升。

向量维度： 128 至 3,072；Google 推荐 768、1,536 或 3,072。
输入上限： 8,192 tokens。
语言与模态： 超过 100 种语言；支持文本、图像、音频、视频和 PDF。
运行方式： Gemini API，稳定版模型 ID 为 gemini-embedding-2。参见模型卡和能力说明。
适合谁： 需要托管搜索服务，且资料无法仅靠提取文字完整表达的团队。
主要特点： 音频、视频与文本、图像共享向量空间。
价格： 每百万输入 tokens 的标准价格为：文本 $0.20、图像 $0.45、音频 $6.50、视频 $12.00，核实于 2026 年 10 月 15 日。参见价格页。
免费试用： 提供免费 API 层级，受相应使用额度限制。

实际难点在于不同模态的入库处理。在满足总体输入限制的前提下，Google 每次请求最多允许 6 张图像、180 秒音频、120 秒视频，或一份最多 6 页的 PDF。视频最多处理 32 帧，并且不处理视频音轨。因此，带解说的演示视频需要分别规划画面和口述内容的处理方式。参见输入限制。

每个嵌入条目都应保留时间戳或页码。找到正确的视频，不如直接打开相关片段有用；找到正确的 PDF，也不如指出答案所在的那一页。切分方式和元数据决定了用户能否顺利定位原文。

现有 Google 用户还要注意迁移问题：gemini-embedding-001 与 gemini-embedding-2 的嵌入空间不兼容。即使维度相同，也无法保持兼容。Google 明确要求，在两者之间迁移时，需要重新为现有语料生成嵌入。参见迁移说明。

4. Cohere Embed 5：面向企业文档，部署方式灵活

如果检索对象主要是长文档、表格、图表和图文混排页面，可以考虑 Cohere Embed 5。当前系列包括 embed-v5.0-pro 和 embed-v5.0-fast。对于需要搜索复杂版式手册的内部客服助手，应把保留页面信息的检索方式与现有文字提取方案进行对比。关键是确认正确的操作说明经过入库处理后，是否仍然完整可用。

向量维度： 默认为 2,048；还支持 256、512、768、1,024 和 1,536。
输入上限： Pro 和 Fast 均为 128K tokens。
语言与模态： 超过 100 种语言；支持文本、图像及图文混合输入，包括文档页面表示。
运行方式： Cohere API、Model Vault、Microsoft Foundry 和 Amazon SageMaker；也支持在自有 VPC 或本地环境中进行商业私有化部署。参见规格及部署与语言覆盖。
适合谁： 部署需求超出共享公共 API 范围的企业文档搜索团队。
主要特点： Pro 与 Fast 共享嵌入空间，可以用 Fast 查询由 Pro 建立索引的语料。
价格： 每百万文本 tokens，Fast 为 $0.08，Pro 为 $0.12；两者的图像价格均为每百万图像 tokens $0.40，核实于 2026 年 10 月 15 日。参见文本价格和图像价格。
免费试用： 免费试用 API 密钥有速率限制，不得用于生产环境或商业用途。

当段落需要周边内容才能理解时，长上下文很有用，但它无法替代检索设计。如果返回的片段包含整本手册，答案模型仍然要从中寻找相关段落。不要只因模型装得下，就直接选更长的输入；应先对比长上下文表示与章节级切分的效果。

Cohere 还支持 float、int8 和二进制输出表示。这些格式决定向量中的数值如何存储，更紧凑的表示会影响内存占用，也可能改变检索表现。先确认数据库和检索实现支持什么，再实测压缩后的配置。完整浮点向量的测试结果，不能直接证明更小的二进制索引也有效。

厂商仍提供 embed-v4.0 文档，其上下文为 128K，默认维度为 1,536。这是需要单独评估的已有模型，不能把它的参数当成当前系列的规格。支持私有化部署也不意味着 Embed 5 是采用 Apache 许可证、可直接下载的模型；采购时仍需考虑商业部署条款。

5. Qwen3-Embedding：可灵活配置的开放文本模型系列

Qwen3-Embedding 提供多种规模的可下载文本嵌入模型。如果架构取决于数据存放位置或运行环境的控制权，它值得纳入自部署候选名单。企业搜索私有工程文档时，应从能达到相关性目标的最小版本开始。直接上最大的模型权重，可能还没弄清答案是否变好，就先把模型选型变成了基础设施项目。

向量维度： 0.6B、4B 和 8B 的最大输出维度分别为 1,024、2,560 和 4,096；该系列支持调整维度。
输入上限： 上述版本均为 32K tokens。
语言与模态： 超过 100 种语言，支持代码检索；输入为文本。这里比较的是 Qwen3-Embedding，与另一个 Qwen3-VL 系列不同。
运行方式： 在自有基础设施上运行，厂商提供 Sentence Transformers、Transformers、vLLM 和 Text Embeddings Inference 示例。参见模型卡。
许可证： Apache 2.0。参见许可证文件。
适合谁： 需要自行部署多语言文本检索，并控制模型规模和输出维度的开发者。
主要特点： 可通过任务指令明确指定检索任务。
价格： 开放权重，自行部署；基础设施成本没有统一的每百万 tokens 单价。
免费试用： 权重可下载，运行环境和算力由使用方提供。

实际限制在于推理服务成本和负载下的表现。索引构建吞吐量与交互查询延迟应分开测量。语料批量入库可以排队，等待客服答案的用户却能感受到每一次额外推理延迟。批量大小、输入长度、硬件和并发量共同决定大模型是否适合产品。

按模型卡的检索说明设置输入。查询格式也是受评配置的一部分，应与具体模型权重版本和输出维度一起记录。某种指令格式的基准结果，不能为另一种生产提示词背书。对比候选模型时，文档端和查询端的处理约定都应保持稳定。

当控制权本身有价值，或实测工作负载足以支撑运维投入时，自部署最有吸引力。它不一定是为小型帮助中心生成嵌入的更便宜方案。即使不计硬件，托管服务很低的 token 费用，也可能低于维护模型服务所花的时间成本。

6. BAAI BGE-M3：不止稠密向量的开放检索模型

如果希望由同一个模型提供稠密、稀疏和多向量检索，可以考虑开放模型 BAAI BGE-M3。稠密向量捕捉语义相似度，稀疏表示为词项特征赋予权重，多向量检索则保留多个向量以支持更丰富的匹配。包含产品标识符和错误代码的客服语料很适合比较这些方法，因为只靠语义接近，可能会返回标识符并不相同的结果。

向量维度： 稠密嵌入为 1,024；稀疏与多向量输出采用不同结构。
输入上限： 8,192 tokens。
语言与模态： 超过 100 种语言；支持文本。
运行方式： 使用厂商提供的 FlagEmbedding 实现自行部署。参见模型卡。
许可证： MIT，见官方模型卡元数据。
适合谁： 准备评估混合检索的开发者，即结合词项信号与语义信号进行检索。
主要特点： 同一模型系列提供多种检索表示。
价格： 开放权重，自行部署；计算和存储费用自行承担。
免费试用： 可下载权重，不代表包含托管服务额度。

需要认清的限制是：模型能生成多种表示，不等于数据库会自动使用它们。如果只存储稠密向量并执行稠密搜索，得到的仍是稠密检索系统。要使用稀疏或多向量输出，就需要兼容的索引与评分方式，还要决定如何合并结果。

先建立稠密检索，再在应当受益的问题上加入词项信号，例如精确的零件名称、报错字符串和标识符。同时检查这些改进是否损害了更广泛的同义表达匹配。先看清候选结果的问题，再决定是否加入重排序模型。

BGE-M3 入选的理由是这种灵活性，而不是较早发布时的基准足以证明它胜过所有当前 API。如果只需要简单的稠密嵌入，先把它与 Qwen 及托管基线对比，再决定是否值得增加检索复杂度。

7. Google EmbeddingGemma：本地搜索要分清两代模型

应用如果需要在用户设备上搜索文本和媒体，可以考虑 Google EmbeddingGemma 2。例如，桌面知识工具可以把笔记、截图和录音一起建索引，无需将每项内容发送给托管嵌入 API。当前模型与最初的 embeddinggemma-300m 在输入支持、上下文长度和许可证上都有区别，构建时要固定使用的具体仓库。

向量维度： EmbeddingGemma 2 输出 768 维，也可选择 512、256 和 128。
输入上限： 8,192 tokens。
语言与模态： 超过 100 种语言；支持文本（包括代码）、图像、视频和音频。
运行方式： 本地或自有基础设施，厂商提供 Sentence Transformers 示例。总计 740M 参数包含可选择加载的视觉与音频编码器。参见模型卡。
许可证： EmbeddingGemma 2 的模型卡注明采用 Apache 2.0。
适合谁： 需要多模态嵌入的本地或离线应用。
主要特点： 按应用需要加载对应模态的编码器。
价格： 开放权重，自行部署；设备资源及可能使用的托管基础设施仍需自行承担成本。
免费试用： 可下载权重。

最初的 EmbeddingGemma-300m 仍是独立的纯文本选项：300M 参数，输入上限 2,048 tokens，输出 768 维，也支持 512/256/128，训练覆盖超过 100 种人类语言。它可通过 Sentence Transformers 运行，但仓库要求接受 Google 的 Gemma Terms of Use。不能把 EmbeddingGemma 2 的 Apache 许可证套用到旧模型权重上。参见初代模型与条款。

实际限制是设备资源。比起“模型文件能否加载”，可用内存、发热表现以及应用同时运行的其他任务更重要。应在用户正常操作前台应用时，测试后台索引任务。如果入库任务独占设备资源，小模型也会带来糟糕的使用体验。

缩短向量时，遵循 Google 的归一化说明，并保证查询与文档维度一致。任务前缀也要保留。这些设置都是模型部署的一部分，不能等检索质量变化后才回头追溯。

搜索和客服机器人该如何选型？

先用明确需求排除不合适的候选，再比较质量。最关键的问题是：哪种失败会让应用无法使用？是找不到答案、丢失视觉信息、把数据发送到不可接受的位置，还是响应太慢？

文本嵌入模型怎么选？

托管文本应用可以从 OpenAI small 与 Voyage 4 开始。希望在现有 API 内做对比，就加入 OpenAI large；如果文档结构和私有化部署很重要，就加入 Cohere。只有新候选确实改善了用户遇到的问题，且延迟和总成本可以接受，才值得更换。

多语言客服应加入跨语言样例：用西班牙语提问、由英语文章回答，以及本地产品名称、多语言混写消息和音译词。“支持超过 100 种语言”并不能证明你最重要的语言组合效果可靠。

开源嵌入模型怎么选？

可配置文本检索可以比较 Qwen3-Embedding；同时需要词项与语义检索时考虑 BGE-M3；本地多模态输入则考虑 EmbeddingGemma 2。许可证对应的是具体模型权重版本。自行部署是一项可以核算运维成本的部署决策，不等于免费使用 API。

如果语料包含拍摄的说明书、示意图或演示录像，应有意识地在提取文字与保留原始模态之间做选择。提取文字可能已经够用，而且更容易调试。只有丢失的视觉或音频信息会影响答案时，才需要多模态检索。

本地嵌入模型怎么选？

本文中，本地多模态场景首先考虑 EmbeddingGemma 2；纯文本场景可对比 Qwen 的较小版本与 BGE-M3。要在实际服务用户的硬件上测量。开发工作站上的结果，很难说明需要同时承担索引和查询的笔记本或小服务器会表现如何。

决策原则： 保留能满足相关性、延迟、部署和语言要求的最简单方案。当评估证明另一方案修复了重要问题，而且收益足以抵消迁移成本时，再更换。

先参考 MTEB，再用自己的数据验证

用 MTEB 排行榜 筛选候选模型，不要据此认定一个适用于所有场景的冠军。MTEB 全称 Massive Text Embedding Benchmark，涵盖检索、分类、聚类、相似度等任务。排行榜也提供按语言、领域和模态查看的视图。不同任务集合的分数，并不一定能直接比较。

用于 RAG 时，应查看与你的语言和领域相关的检索结果；用于视觉资料时，应查看合适的多模态或文档检索基准。引用结果做决策前，记录基准版本及测试设置。本文没有引用排行榜的具体分数。

首次评估可以从 100 个真实问题开始，逐一标注应该回答它们的原文片段。这只是建议的起始样本量，并不意味着具有统计确定性。样本应包含无有效答案的问题、歧义表达、精确标识符，以及实际服务的语言组合。

比较模型时，保持资料切分、权限、召回条数和重排序模型不变，否则无法判断改进来自模型还是外围流程。以返回前十条结果为例，recall@10 衡量相关内容有多少进入这些结果，nDCG@10 则对把更相关结果排在前面给予更高评分。

之后人工检查失败案例：正确片段是缺失了、排名太低、被权限过滤了，还是提取时遭到破坏？从未进入索引的资料，无法靠升级模型补救。查询延迟和入库吞吐量要分别测量，修改维度或压缩方式后，应重新运行那些难例。

向量存在哪里，如何提供检索服务？

Pinecone 是托管向量数据库，既能存储在其他地方生成的向量，也通过推理 API 托管部分嵌入模型。其模型目录列出的嵌入推理选项包括 llama-text-embed-v2、multilingual-e5-large 和 pinecone-sparse-english-v0。这与自行调用 Gemini、OpenAI 或 Voyage 后上传向量，是两种不同的选择。

如果服务支持的模型通过了你的评估，而且希望由服务完成文本到向量的转换，可以使用集成嵌入功能。如果需要自行控制模型、媒体预处理或自部署编码器，就选择上传自有向量。Pinecone 的索引文档区分了这两种方式。

客服机器人的检索架构还应保留原文、稳定 ID、访问控制元数据和引用信息。嵌入相似度不能代替权限校验。无论选用哪个数据库，应用都必须把检索范围限制在用户有权查看的资料之内。

向量数据库选型对比讨论存储选择，Pinecone 价格分析介绍其独立计费。如果助手会自行决定何时搜索、改写问题或继续检索，可以参考 Agentic RAG 详解。嵌入模型负责提供内容表示，检索系统负责决定如何使用它。

向量维度如何影响存储成本？

选维度时，需要同时考虑数据库。float32 精度下，每个数值占四字节。因此，存储一百万条向量时，1,536 维的原始向量值需要 6.144 GB，3,072 维则需要 12.288 GB。这里按十进制 GB 计算，不含元数据、索引结构、副本和其他数据库开销。

这就是为什么即使嵌入 token 很便宜，缩小输出仍然可能很有价值。也因此，不能混淆模型参数量与向量维度：前者影响运行的编码器，后者影响每一条需要存储和检索的表示。

按照厂商支持的方法测试降维。如果文档没有说明支持，就不要随意截断向量。需要归一化时，应始终采用一致的处理方式。随后直接评估降维后的向量；只有仍能检索到所需证据，省下的存储才有意义。

更换模型，就要规划索引迁移

如果新模型的嵌入空间不兼容，就要为重建语料索引预留预算。仅替换查询端 API 中的模型名称，却继续使用旧文档向量，通常会破坏匹配关系，即便两个模型输出维度相同。Google 文档中的 embedding-001 到 embedding-2 迁移就是明确的例子。

也有适用范围明确的例外：Voyage 通用 4 系列，以及 Cohere Embed 5 Pro/Fast，文档均说明它们各自共享嵌入空间。这只允许特定的跨模型配对，不能跨供应商任意混用。仍需测试具体组合，并匹配维度和表示格式。

重新生成嵌入的成本，应按实际输入 token 数量估算。例如，一百万个片段、每个平均 500 tokens，总计为 5 亿 tokens。按 Gemini Embedding 2 公布的标准文本价格计算，这次嵌入处理费用为 $100，不含数据库写入、新旧数据并存期间的存储、预处理、查询、工程投入，也未计任何折扣。参见单价来源。

token 费用可能反而是容易处理的部分。你还需要原始文档、入库配置，以及足够的容量，让新系统构建期间的线上服务保持可用。每个索引版本都应保存模型 ID、维度、归一化方式、切分版本，以及查询与文档指令。

1. 1

   单独建立候选索引

   用新配置为保留的源片段重新生成嵌入，同时让现有索引继续处理请求。使用稳定的文档 ID，方便逐条对比对应记录。

2. 2

   重跑评估，检查效果退化

   使用同一批已标注查询比较候选方案。除相关性外，还要检查权限、引用目标、缺失文档和查询延迟，并处理全量回填期间发生变更的文档。

3. 3

   模型与索引一起切换

   通过一次配置变更，把查询同时切到相互匹配的新编码器和新索引。旧组合应保留足够长时间，以便线上表现与评估不符时回滚。

本文如何筛选模型？

这七个模型系列，在搜索、RAG 和客服机器人的选型中各有明确用途。筛选考虑了公开的输入限制、维度、模态、语言覆盖、部署方式、许可证和当前价格。厂商页面已在文中标注的核实日期检查；存储与费用示例则根据明示假设计算。

本文未对模型进行基准测试或负载测试。排序表示面向典型文本应用开发者的建议评估顺序，并非实测准确率排名。代码专用、领域专用及其他多模态系列没有单列排名卡片；如果应用成败取决于这些专长，应把对应模型加入自己的候选名单。

这些选型方式应当避开

不要直接用 OpenAI text-embedding-3 检索图像或音频。它是文本模型系列。提取文字是一种可行架构，但会丢失只存在于原始画面或声音中的信息。

不要在新项目中默认从旧版 Voyage 3 开始。Voyage 当前文档推荐更新的系列。已有部署如果经过评估且运行良好，可以继续保留，直到有理由承担迁移成本。

不要未经测量就把 Qwen3-Embedding-8B 设为笔记本默认模型。先确定设备的延迟和资源限制，再判断更大的模型权重是否值得相应运行成本。

如果只打算存储稠密输出，就不要把 BGE-M3 当成已经具备“混合搜索”的方案。只有检索设计实际使用额外的表示，才能获得相应能力。

不要把所有 EmbeddingGemma 权重版本都视为 Apache 2.0 许可。当前 EmbeddingGemma 2 模型卡注明 Apache 2.0，最初的 300M 仓库则使用 Gemma 条款。具体版本不仅影响检索，也影响部署。

常见问题

RAG 嵌入模型怎么选？

可以先用 OpenAI text-embedding-3-small 建立低成本托管文本基线，再用自己的问题对比 Voyage 4。如果资料模态会改变答案，应把 Gemini Embedding 2 或 Cohere Embed 5 纳入比较。本文的自部署候选是 Qwen3-Embedding、BGE-M3 和 EmbeddingGemma。能稳定检索到已标注证据的模型，才是对你有用的选择。

哪些嵌入模型可以免费试用？

托管方案评估方面，Gemini 提供免费 API 层级，Voyage 列有初始 token 额度，Cohere 提供有速率限制的试用密钥，但不允许用于生产环境或商业用途。面向客户的应用若准备依赖免费额度，应先核对具体模型的额度和生产使用条款。

RAG 有哪些可免费获取的嵌入模型？

自部署文本 RAG 可以对比 Qwen3-Embedding 与 BGE-M3；本地多模态 RAG 则可加入 EmbeddingGemma 2。它们提供可下载权重，允许自行运行编码器，但推理、存储和维护仍会消耗资源。记录每个具体模型权重版本对应的许可证，并在与托管 API 比价时计入运行成本。

下一步，收集现有搜索无法解决的客服问题，并标注应该回答它们的原文片段。在处理全量语料前，用 AI 业务流程审查清单明确工作流程和成功标准。