几个月前，我们出了一篇文章，实测了Gemini 、jina、Qwen、BGE、OpenAI几家厂商的十大 embedding 模型。

那时候，我们会关心这些模型谁在单模态的表现更优，谁在多模态任务上普适性更强。

但一个有意思的变化是：最近几个月新出的 embedding 模型，开始把 RAG pipeline 里不少工程问题也带到了模型层，他们的使用前提，已经细化到图文能否同空间、PDF 是否要先 OCR、长文档如何切 Chunk、一个 Chunk 一个向量够不够、维度能否按成本裁剪的生产级粒度。

而过去那种基于单一 benchmark的测试结果，在面对企业的 PDF、扫描件、财务报表、产品截图、音视频及多语言混合库等真实业务场景，也随之彻底失效。

因此，本次 embedding模型对比，我们会按四种具体场景来具体聊一聊。

场景一：普通文本知识库

对于 Markdown、网页正文、代码注释、FAQ 等结构化文本，Single-vector Dense Embedding 依然是最稳妥、低成本且生态最成熟的起点。一个 chunk 对应一个向量的模式，不仅工程生态成熟，向量数据库支持好，成本可控，排查问题也相对容易。

最近值得关注的开源模型里，Qwen3 Embedding 可以作为首选。这个系列提供 0.6B、4B、8B 等不同尺寸，支持 100 多种语言，以及代码检索、多语言检索和跨语言检索。同时还配有同系列 Reranker，支持 MRL（Matryoshka Representation Learning，可自定义维度）。

Jina v5 text 的重点则是轻量部署。家族包括两个模型： jina-embeddings-v5-text-small以及 jina-embeddings-v5-text-nano 。Jina v5 text-small 是 0.6B 参数量，支持长文本和多语言； nano 版本有239M 参数，适合资源受限或延迟敏感的场景。

OpenAI text-embedding-3-large / small 依然是很多团队的默认选择：接入简单、服务稳定，适合先把 RAG 跑起来。

BGE-M3 更像一个开源多语言 baseline，中文和中英混合知识库都可以先拿它做参照。

mxbai-embed-large 偏英文场景，模型不大，MRL 维度压缩表现不错，适合成本敏感的英文知识库。

模型	适合谁	优势	注意点
Qwen3 Embedding	中文/多语言知识库，想用本地部署模型替代 API	多尺寸、100+ 语言、支持自定义维度，同系列有 reranker。	先用自己的 query 测不同尺寸和自定义维度后的召回。
Jina v5 text	资源受限、本地部署、长文本或多语言文本检索	sub-1B 路线，适合在质量、延迟、成本之间做取舍。	主要看文本场景；多模态数据要另测 Jina omni。
OpenAI text-embedding-3	想快速上线，不想维护本地 embedding 服务	官方 API 接入简单，支持 dimensions 参数控制向量维度。	API 服务，需考虑数据合规、调用成本和外部依赖。
BGE-M3	需要中文/多语言开源 baseline	稳定、可控，长期是中文开源 embedding 参照。	如果只做 dense retrieval，要先想清楚是否需要它的 sparse / multi-vector 能力。
mxbai-embed-large	英文知识库、成本敏感、希望通过维度压缩控制成本	模型不大，英文 MRL 表现突出，适合做轻量英文 embedding 候选。	中文和跨语言场景要单独测，不建议直接当默认模型。

场景二：PDF、图片和音视频

多模态 embedding 在最近半年多，是所有 embedding 模型中变化最大的一个。

过去处理 PDF、图片、截图、视频，传统做法是图片做 OCR，视频做 ASR，图表做 caption，PDF 页面抽正文，信息层层衰减，每做一次转化，就会丢失一部分信息。表格结构、页面版式、图片细节、截图里的 UI 层级，都可能在转文本的过程中被抹平。

Gemini Embedding 2、Jina v5 omni、Cohere Embed 4 为代表的新一代embedding模型，演进的趋势是直接将文本、图像、音视频直接映射到同一个语义向量空间。

拿Google 的 Gemini Embedding 2 来说。它支持把文本、图片、视频、音频和文档内容等不同模态映射到同一个 embedding space。这样一来，用户可以用文本 query 搜图片，也可以在多模态内容之间做比较和检索。

Jina v5 omni 也在强调一套 embedding 覆盖 text、image、audio、video。媒体素材库、课程视频库、电商图文商品库、内部培训资料、图文混合知识库。过去搞定这种复杂多模态，往往要拆成多个 pipeline：文本走文本 embedding，图片走 CLIP，视频先转写，音频先 ASR（Automatic Speech Recognition，是一种将人的语音转换为文本的技术。）。现在可以把表示层收得更统一一些，在一套架构中处理不同格式的信息。

Cohere Embed 4 则更强调面向企业检索场景的多模态检索，重点放在文本、图片，以及带有图片和文本的混合文档，并具备较长上下文能力，适合处理 PDF、报告、表格、图表等复杂企业文档。

当然，多模态 embedding 不会取代所有 OCR 或文档解析工具。它更像是一个当文本表达损失关键信息时，让原始视觉或多媒体内容直接参与检索的候补选项。

场景三：合同、论文和手册等带有完整上下文的长文档

相比普通多模态场景，长文档 RAG 的麻烦在于：文档太长，不能整篇拿去检索；切成 chunk 之后，每个 chunk 又可能失去原来的上下文。合同、论文、技术手册，这种很多句子的含义依赖前面的定义、章节标题、表格说明或附录的场景尤其明显。

比如合同里一句「乙方应在上述期限内完成交付」，如果「上述期限」被切到另一个 chunk 里，单独对该句进行向量化会产生严重的语义偏差。有时候会召回一个字面相似但语义不完整的片段，有时候召回正确但由于缺少标题、定义或前文，也可能影响最终回答的准确性。

Voyage context-4 代表的 contextualized chunk embeddings，可以很好的解决这个问题。它会让每个 chunk 的向量带上 full document context，减少对手工 metadata 或额外 context augmentation 的依赖。让长文档检索从 isolated chunk embedding，走向 document-aware chunk embedding。

场景四：表格、截图和复杂版面

多模态 embedding 让非文本内容能进检索流程。但复杂页面中，我们还需要考虑：一个向量够不够表示整页信息？

在普通文本 RAG 里，一个 chunk 一个 vector 通常够用。因为 chunk 本身就是一段连续文本，语义相对集中。但 PDF 页面里可能同时有标题、正文、表格、图注、流程图、脚注、页眉页脚。如果先 OCR 成一段文本，版式关系已经丢了一层；再压成一个 dense vector，很多细节还会继续被平均掉。

ColPali 这类方法就是在这个背景下出现的。它跳过完整文本还原，直接把页面图像送进视觉语言模型，生成 multi-vector embeddings，再通过 late interaction 做细粒度匹配。这样，标题、表格区域、图片、局部文字和页面布局，都有机会参与检索判断。

NVIDIA Nemotron ColEmbed V2 也延续了这条路线， 面向视觉文档检索提供 late-interaction embedding。

值得一提的是，Multi-vector 模式下，一个页面不再对应一个向量，可能对应几十或几百个局部向量，会带来成本的极大提升。大部分普通文本和简单页面其实根本用不上这种复杂表示。Multi-vector 更适合局部信息决定答案的资料，例如财报、发票、论文页面、复杂表格、扫描件、PPT 和技术图纸。

不同场景，需要不同的Benchmark

过去测评 embedding 模型，会默认先看MTEB 数据。迄今为止，它也是文本 embedding 方向最核心的Benchmark ，其拓展的retrieval、reranking、clustering、classification、STS、bitext mining 等任务，也可以让我们把pipeline 的不同环节，放在同一个评测框架中，方便做全面比对。

但是关于多模态和视觉文档检索的问题，MMEB、ViDoRe 这类 benchmark的结果，或许更值得一看。

MMEB 关注 multimodal embedding，把图像、视频、音频、视觉文档等任务纳入评测；ViDoRe 则专门评估 visual document retrieval，覆盖多领域、多语言和实际文档页面检索任务。

总而言之，公开 benchmark 适合用来缩小候选范围，但不能替代业务评估。

2026 下半年选型建议

以下是我们总结的生产级 embedding 模型选型流程。

首先，要按信息形态对数据做拆分。 不能只按文件扩展名分类。因为PDF内部可能包含完全不同的数据：可复制的纯文本 PDF；扫描 PDF；表格密集型财报；图文混排的产品手册；PPT 导出的页面；带复杂公式的论文……先抽样检查内容，再决定哪些资料可以走相同的表示 pipeline。

通常来说：

• 普通文本知识库：先从 dense embedding 开始。Qwen3 Embedding、Jina v5 text、BGE-M3、OpenAI text-embedding-3、Voyage、Cohere 都可以进入候选，重点测中文/跨语言、术语和真实 chunk 的召回；生产场景通常再评估 hybrid search 和 reranker。
• PDF、图片、截图、音视频：不要默认 OCR 后再进文本模型。图片、视频、音频可测 Gemini Embedding 2、Jina v5 omni、Qwen3-VL-Embedding、Voyage Multimodal；图文/PDF 场景再把 Cohere Embed 4 纳入。复杂版面则看 ColPali、ColQwen、Nemotron ColEmbed V2。
• 长文档：先检查 chunking 是否切断标题、定义、表格和前文，再考虑 Voyage context-4 或 late chunking，把整篇文档上下文带回 chunk 表示。