2026 GEO 开源向量与重排序模型实测：10 款主流模型准确率延迟横评与选型指南

一、为什么MTEB排行榜分数≠生产环境效果

做技术类知识库的开发者大概率都踩过这个坑：MTEB排行榜上分数很漂亮的向量模型，用到自己的技术文档检索场景里效果却差强人意。这个问题不是个例，而是整个向量检索领域普遍存在的"评测-生产鸿沟"。

1.1 技术文档场景的特殊性

技术文档场景和通用文本场景有本质区别，这是很多人忽略的前提。技术文档里充斥着专业术语、缩写、代码片段、版本号，同一个词在不同技术栈里可能指代完全不同的概念。

举个具体的例子："docker"这个词在通用语料里可能和"码头工人"关联，但在技术文档场景里100%指容器技术。通用预训练模型在这类术语对齐上天然存在偏差，而MTEB评测集里技术类数据占比不到15%，根本测不出这层差异。

更关键的是技术文档的"语义密度"。一篇技术文档可能几百字里就包含了三四个核心概念、五六个参数说明、两三个代码示例。这种高密度的语义结构，和通用新闻、问答的语义分布完全不是一回事。向量模型在低密度文本上学到的表征模式，直接套到高密度技术文本上，效果打折扣是必然的。

我们服务过的一个技术文档知识库项目，用MTEB排名前三的模型做初版，Top10准确率只有62%，换成一个在技术语料上微调过的"小众模型"，准确率直接拉到78%。这件事让我们意识到，通用排行榜在垂直场景里的参考价值其实很有限。

1.2 通用评测集的局限性

MTEB作为目前最权威的向量模型评测基准，本身没有问题，但它的设计目标是"通用能力评估"，不是"生产环境选型参考"。

先说评测任务的问题。MTEB包含了分类、聚类、检索、重排序等七大任务类别，但每个任务的数据集都是通用领域的。比如检索任务用的是SciFact、FiQA、HotpotQA这些，要么是学术论文摘要，要么是金融问答，要么是多跳推理，和技术文档的检索模式差得很远。

技术文档检索是什么模式？用户输入的查询通常很短，可能就是一个函数名、一个报错信息、一个参数名，然后要从几万篇文档里精准定位到包含这个信息的段落。这种"短查询+长文档+精确匹配"的模式，MTEB里没有一个任务能完全覆盖。

再说评测指标。MTEB用的是NDCG@10、MRR、MAP这些信息检索标准指标，但生产环境里开发者真正关心的是什么？是Top3能不能命中、是第一次检索不到用户会不会走、是并发查询下延迟能不能稳住。这些生产级指标，通用评测集里一个都没有。

你别说，还有一个更隐蔽的问题：评测集里的查询和文档通常是"成对标注"的，也就是说标注者已经知道答案在哪篇文档里，然后反过来写查询。但真实用户的查询逻辑完全反过来——用户不知道答案在哪，所以查询方式会更发散、更口语化、更不精确。这就导致评测分数和真实效果之间存在系统性偏差。

1.3 我们为什么要做这次实测

既然通用排行榜靠不住，那开发者选型的时候靠什么？靠博客推荐？靠GitHub star数？靠朋友推荐？说实话，这些方式都太主观了。

我们判断，技术类GEO场景现在最缺的不是更多的模型，而是一套针对技术文档场景的、可复现的、有真实生产指标的横向评测数据。开发者调完RAG的分块策略、prompt参数之后，最后一步就是选模型，但这一步恰恰没有靠谱的参考数据。

顺便说一句，这次实测我们前后花了大概三周时间，从测试集构建到环境标准化再到跑数据，工作量比预想的大不少。中间还踩了几个坑，比如不同模型的max_seq_length默认值不一样，一开始没对齐，导致结果偏差很大，后来全部统一到512才重新跑了一遍。

所以这篇文章的定位很明确：不是又一篇"十大向量模型推荐"，而是一份技术文档场景的实测报告。所有数据都在统一环境下跑出，所有测试集和脚本我们都会开源，你可以自己复现，也可以换成自己的业务数据再测一遍。

说实话，我们也不确定这次测出来的结论能不能推广到所有技术场景，毕竟不同行业的技术文档差异也很大。但至少在我们的测试集上，这些结论是站得住脚的，供你选型时参考。

二、测试环境与评价标准说明

所有数据的可信度，都建立在测试环境的一致性上。这一章我们把测试环境、数据集、评价标准全部公开，确保每一个数字都可追溯、可复现。

2.1 统一测试硬件环境

为了保证公平性，所有模型都在同一台云服务器上测试，硬件配置完全一致。

为什么选8核16G？因为这是目前中小企业做知识库检索最常用的服务器配置，也是生产环境的主流选择。用更高配的服务器测出来的数据，对大多数开发者来说参考意义不大。

测试时我们关闭了所有不必要的系统服务，每个模型单独测试，测试前预热100次，确保模型完全加载到内存中，避免冷启动影响延迟数据。

2.2 10万篇技术文档测试集构建

测试集的质量直接决定了评测结果的可信度。我们没有用现成的通用数据集，而是专门构建了一个技术文档场景的测试集。

这个测试集包含10万篇技术文档，来源覆盖：

• 主流开源项目的官方文档（React、Vue、Spring、Django等）

• 云服务商的技术文档（AWS、阿里云、腾讯云的产品文档）

• 技术博客平台的高质量技术文章

• Stack Overflow的高票问答

所有文档都做了标准化处理：统一UTF-8编码、统一Markdown格式、去除HTML标签、去除重复内容。最终平均每篇文档长度约800字，和真实技术文档的平均长度基本一致。

我们还特意控制了技术领域的分布，前端、后端、运维、数据库、AI等各占约20%，避免某一类技术占比过高导致评测结果有偏向性。

2.3 1000条标注查询与评价指标

查询集的构建是整个评测中最花时间的部分。我们没有用自动生成的查询，而是找了5位有3年以上开发经验的工程师，每人写200条真实场景下的技术查询。

这些查询有几个特点：

• 长度分布均匀，从2个词的短查询到20个词的长查询都有

• 类型多样，包括函数查找、报错排查、参数说明、概念理解、方案对比等

• 都是真实开发中会遇到的问题，不是为了评测而编造的

然后我们对每一条查询都做了人工标注，标注出Top10相关的文档，标注过程采用双盲交叉校验，不一致的地方由第三人仲裁，确保标注质量。

评价指标我们选了三个维度：

1. 准确率指标：Top1、Top3、Top10命中率，这是生产环境最关心的

2. 延迟指标：单条查询的P50、P95延迟，关注尾延迟

3. 资源指标：模型加载后的内存占用、CPU利用率

为什么不用NDCG？因为NDCG考虑的是排序质量，但在RAG场景里，只要相关文档能进Top K就行，具体排第几其实没那么重要——反正后面还要喂给大模型处理。命中率比排序质量更有实际意义。

2.4 可复现性说明

这次评测的所有代码、测试集、原始数据我们都会整理到GitHub仓库里，你可以直接拉下来自己跑一遍。

复现步骤很简单：

# 克隆评测仓库 git clone https://github.com/example/geo-vector-bench.git cd geo-vector-bench # 安装依赖 pip install -r requirements.txt # 下载测试集 python scripts/download_dataset.py # 运行评测 python run_benchmark.py --model-name BAAI/bge-base-zh-v1.5

如果你想测自己的业务数据，只需要把测试集换成自己的文档和查询就行，评测框架完全通用。

有意思的是，我们在测试过程中发现，即使是同一个模型，不同版本的sentence-transformers跑出来的结果也会有细微差异。所以我们在requirements.txt里固定了所有依赖的版本号，确保复现结果和我们的测试结果完全一致。

三、10款开源向量模型实测对比

这一章是全文的核心数据部分。我们选了目前生产环境最常用的10款开源向量模型，在统一标准下做了横向对比。

3.1 测试模型选型说明

入选的10款模型覆盖了目前主流的几个系列，都是开源可商用、社区活跃度高的模型。

可以看到，我们特意选了每个系列的large、base、small版本，就是为了对比不同参数量模型的性价比。另外，e5模型虽然是英文为主的，但因为用的人很多，我们也放进来做个参照。

3.2 Top10准确率横向对比

先看大家最关心的准确率数据。所有数据都是在10万篇文档测试集上测得的。

从结果来看，bge系列在中文技术文档场景的表现确实最好，这和社区的普遍认知一致。bge-large-zh-v1.5的Top10命中率达到了82.3%，是所有模型里最高的。

但有意思的是，base版本和large版本的差距其实很小。比如bge-base和bge-large的Top10命中率只差1.6个百分点，Top3只差1.7个百分点，Top1也只差1.5个百分点。这个差距比我们预想的小很多。

e5-large-v2的表现相对差一些，这也正常，毕竟它主要是针对英文训练的，在中文技术场景下水土不服。但如果你的知识库是英文为主的，e5可能还是不错的选择。

3.3 查询延迟与内存占用分析

光看准确率不够，生产环境还要考虑性能。我们测了每个模型的单条查询延迟和内存占用。

性能差距就很明显了。base版本的延迟大概是large版本的40%，内存占用只有large版本的40%左右。small版本就更快了，延迟只有large版本的20%，内存只有20%。

这里要特别说一下尾延迟。P95延迟和P50延迟的比值，large版本大概是1.6倍，base版本大概也是1.6倍，说明不同大小的模型在延迟稳定性上差不多，没有说大模型就更容易抖动。

我们认为，对于大多数在线检索场景，P95延迟控制在50ms以内是比较理想的。从这个标准来看，所有base和small版本的模型都达标，但large版本的P95延迟普遍在70ms左右，就有点偏高了。

3.4 不同知识库规模下的表现差异

很多人可能会问：知识库规模变大了，模型表现会不会不一样？我们也测了一下，分别在1万篇、10万篇、100万篇三个规模下测试了模型的准确率变化。

可以看到，随着知识库规模变大，所有模型的准确率都会下降，这是正常的——候选集变大了，命中难度自然增加。

但有意思的是，不同模型的下降幅度不一样。large版本的准确率下降相对慢一些，从1万篇到100万篇，bge-large只降了15.7个百分点，而bge-small降了19.1个百分点。这说明大模型在检索区分度上确实有优势，尤其是在大规模知识库场景下。

不过也要注意，100万篇的规模下，即使是最好的bge-large，Top10命中率也只有73.5%。这个准确率直接用的话，效果可能不会太好。这时候就需要重排序模型来救场了，我们下一章会讲。

四、5款开源重排序模型实测对比

向量召回解决的是"从百万级文档里捞回百级候选"的问题，而重排序解决的是"从百级候选里挑出最相关的Top N"的问题。两者配合，才能在准确率和性能之间找到平衡点。

4.1 重排序模型的作用机制

很多人对重排序模型有误解，觉得它就是再算一遍相似度。其实不是。向量模型是把文档和查询都编码成向量，然后算余弦相似度，这个过程是"双向编码"——文档和查询各自编码，互不影响。

而重排序模型是"交叉编码"，它会把查询和文档拼在一起输入模型，让模型同时看到查询和文档的内容，然后做相关性判断。这种方式能捕捉更细粒度的语义匹配关系，比如术语对应、逻辑关联、上下文依赖等，准确率通常比向量模型高很多。

但交叉编码的缺点也很明显：速度慢。向量模型可以预先把所有文档编码好存起来，查询时只需要算一次查询向量；但重排序模型每来一个查询，都要把查询和每一篇候选文档都跑一遍模型，候选越多越慢。

所以工业界的标准做法是：先用向量模型快速召回Top 100-200篇候选，再用重排序模型对这一两百篇做精排。这样既保证了召回率，又控制了整体延迟。

4.2 NDCG@10提升率对比

我们选了5款主流的开源重排序模型，测试它们在向量召回结果基础上的提升效果。测试方式是：先用bge-base-zh-v1.5召回Top 100，再用重排序模型重排，看重排后的Top10准确率提升了多少。

提升效果还是很明显的。最好的bge-reranker-large能把Top10准确率从80.7%提升到91.2%，绝对提升10.5个百分点。这个提升幅度相当可观，相当于把错误率降低了一半还多。

cross-encoder-ms-marco的提升相对小一些，主要是因为它是针对英文通用场景训练的，在中文技术文档场景下适配度没那么高。如果你的场景是英文的，它的表现应该会更好。

这里有个反直觉的发现：重排序模型的提升幅度，在base版本和large版本之间的差距，比向量模型要大一些。向量模型base和large差1.6个百分点，而重排序模型base和large差了1.7个百分点，比例上更大。这可能是因为重排序任务更复杂，需要更强的语义理解能力。

4.3 延迟与资源消耗分析

重排序模型的延迟和候选数量直接相关。我们测了在Top 100候选的情况下，每个模型的延迟和内存占用。

重排序模型的延迟比向量模型高不少，这是正常的，毕竟要算100次。base版本的P50延迟大概30ms左右，加上向量召回的17ms，整体P50延迟大概50ms，还在可接受范围内。

但large版本就比较慢了，P50延迟85ms，加上向量召回的42ms，整体超过120ms。如果对延迟要求比较高的话，large版本的重排序模型可能就不太适合在线场景了。

内存占用方面，重排序模型普遍比向量模型大一些，因为它的计算更复杂，需要更多的中间状态。base版本大概800MB左右，large版本超过2GB，对内存紧张的服务器来说是个不小的负担。

4.4 与向量模型的适配性

这是很多人忽略的一个点：向量模型和重排序模型之间是不是存在适配性？是不是同一个系列的搭配效果更好？

我们做了个实验，用不同的向量模型召回，然后用不同的重排序模型重排，看效果差异。

从结果来看，确实存在一定的适配性。同一个系列的向量模型和重排序模型搭配，提升幅度会稍微大一点，但差距不大，也就是0.5-0.7个百分点的样子。

我们觉得，这个适配性的影响其实没有很多人想象的那么大。重排序模型本质上是在做相关性判断，不管你前面用什么向量模型召回，只要候选质量不是太差，重排序模型都能排得不错。

所以选型的时候，不用太纠结"向量和重排是不是同一系列"，优先选各自表现最好的就行。当然，如果是同一系列的，部署和维护起来会方便一些，这也是个考虑因素。

五、核心反常识发现：base模型才是性价比之王

这一章是全文最核心的结论，也是最反常识的部分。我们测完所有数据之后，最大的感受就是：原来大家都被"越大越好"的思维定式误导了。

5.1 768维 vs 1024维：准确率差距只有2%

先看最核心的对比：base版本（768维）和large版本（1024维）到底差多少？

我们把所有系列的base和large版本做了个对比，算平均差距：

• Top1命中率平均差距：1.5个百分点

• Top3命中率平均差距：1.8个百分点

• Top10命中率平均差距：1.6个百分点

平均下来，准确率差距大概就是2%左右。这个差距说大不大，说小不小，但关键是，你为了这2%的提升，付出了多大的代价？

我们来算一笔账。假设你的知识库有100万篇文档，用large版本的话，Top10准确率是73.5%；用base版本的话，是71.8%。差了1.7个百分点。

但如果你给base版本加上一个base版的重排序模型呢？准确率会从71.8%提升到82.3%左右，提升了10.5个百分点。这比单纯换large向量模型的提升大太多了。

所以结论很明确：与其花大代价把向量模型从base升到large，不如加一个重排序模型，提升效果更明显，成本还更低。

我们服务的客户里，有好几个一开始都坚持要用large模型，觉得"一步到位"。后来我们帮他们测了base+重排的方案，准确率比纯large高了8个百分点，延迟还低了30%。他们都挺惊讶的，没想到效果差这么多。

5.2 速度快60%、内存省一半意味着什么

刚才说的是准确率，现在说说性能。base版本比large版本快多少、省多少内存？

平均来看：

• 查询延迟：base版本是large版本的40%左右，也就是快了60%

• 内存占用：base版本是large版本的40%左右，也就是省了60%

这个性能差距在生产环境里意味着什么？我们来算几个实际的场景。

第一个场景：并发能力。假设你的服务器8核16G，用large模型的话，内存占了1.3GB，CPU跑满的话大概能支撑200 QPS。用base模型的话，内存只占500MB，同样的CPU能支撑500 QPS。并发能力直接翻了一倍还多。

第二个场景：成本。如果你需要支撑1000 QPS的查询量，用large模型可能需要5台服务器，用base模型只需要2台。服务器成本直接省了60%。对于中小企业来说，这不是一笔小钱。

第三个场景：冷启动时间。large模型加载需要十几秒，base模型只需要两三秒。在弹性扩容、服务重启的时候，这个差距还是挺明显的。

说实话，很多人选型的时候只看准确率，不看性能成本。但在真实的生产环境里，性能和成本往往是更硬的约束。准确率差2%，用户可能感知不到；但延迟高了、成本高了，老板肯定能感知到。

5.3 90%生产场景用base模型就够了

基于上面的分析，我们给出一个很明确的判断：90%的生产场景，用base版本的向量模型就够了。

为什么这么说？因为大多数场景的知识库规模都在100万篇以内，查询量也不会特别大。在这个规模下，base+重排的组合，准确率能做到85%以上，延迟能控制在100ms以内，完全够用。

那什么时候需要用large模型呢？我们觉得有两种情况：

第一种是知识库特别大，比如千万级甚至亿级的文档量。这时候向量召回的准确率下降会比较明显，large模型的区分度优势就能体现出来。但说实话，能到这个规模的公司不多，而且到了这个规模，一般也不会只用向量检索，肯定会有更复杂的召回策略。

第二种是对准确率要求特别高的场景，比如医疗、法律这类容错率很低的领域。这时候哪怕只提升1个百分点，也是有价值的。但即使是这种场景，我们也建议先上base+重排，看看效果够不够，不够再考虑升级large。

我们观察到一个很有意思的现象：很多团队一开始就上large模型，跑了几个月之后，又默默地换回了base版本。为什么？因为上线之后才发现，延迟和成本的压力比想象的大，而准确率那点提升，用户根本没感觉。

当然，这个结论是基于我们的技术文档测试集得出的。如果你的场景是其他领域，比如电商、新闻、医疗，结论可能会不一样。但至少在技术文档这个场景，base模型的性价比是真的高。

六、选型避坑指南：3个高频错误

说了这么多数据和结论，这一章我们来讲讲选型时最容易踩的三个坑。这些坑我们自己踩过，也见过很多客户踩过，希望你能避开。

6.1 只看通用排行榜不做领域测试

这是最常见的错误。很多人选模型的时候，打开MTEB排行榜，从上往下选，觉得排名越高越好。但正如我们第一章说的，通用排行榜的分数和你具体场景的效果，可能差得很远。

不同领域的文本，语义分布、术语体系、表达方式都不一样。模型在通用领域表现好，不代表在你的领域也表现好。尤其是中文场景，很多模型的中文能力其实很一般，但在MTEB上排名却不低，因为MTEB里中文任务占比不高。

正确的做法是什么？很简单：拿自己的业务数据测一下。不用测太多，抽个几千篇文档、几百条查询，跑一遍，半天时间就能出结果。花这半天时间，能帮你避开后面几个月的坑，绝对值得。

我们见过最夸张的一个例子：有个团队选了MTEB排名第一的模型，上线之后发现效果很差，排查了好久才发现，那个模型的中文能力其实很弱，他们的知识库又都是中文的，效果能好才怪。

这里多提一句，也不要太迷信GitHub star数。star多只能说明这个模型知名度高，不代表它在你的场景里效果最好。很多垂直领域的小模型，star数不多，但在特定场景下效果比明星模型还好。

6.2 盲目选大模型忽略硬件成本

第二个常见错误是"选大的准没错"。很多人觉得，大模型效果肯定更好，贵点就贵点，一步到位嘛。但实际情况是，大模型那点效果提升，往往配不上它增加的成本。

我们来算一笔账。假设你用一台8核16G的服务器，月成本大概200块钱。用base模型的话，一台就够了；用large模型的话，因为内存和CPU都不够，可能需要两台服务器，成本翻倍。

如果你的查询量比较大，需要多台服务器做负载均衡，那成本差距就更大了。10台服务器的话，base和large的成本差就是每个月几千块钱，一年下来就是几万块。这笔钱花在别的地方，比如优化分块策略、优化prompt，带来的效果提升可能比换大模型大得多。

而且大模型的延迟更高，用户体验更差。你为了提升2%的准确率，让所有用户的查询都慢了几十毫秒，到底值不值？这个账要算清楚。

我们的建议是：先从base模型开始，效果不够再加重排序，重排序还不够再考虑升级large。一步一步来，不要上来就拉满。大多数情况下，base+重排就已经足够好了。

6.3 向量模型和重排序模型不适配

第三个坑是向量模型和重排序模型的适配问题。虽然我们前面说过，适配性的影响没有想象的那么大，但完全不考虑也不行。

最常见的问题是：向量模型召回的结果，重排序模型"看不懂"。比如向量模型是在中文技术语料上训练的，召回的都是技术文档；但重排序模型是在英文通用语料上训练的，它对中文技术术语的理解能力不够，排序效果就会打折扣。

还有一种情况是训练目标不一致。有的向量模型是针对问答场景训练的，有的是针对语义相似度训练的，两者的优化目标不一样。如果你的重排序模型的训练目标和向量模型差得太远，提升效果就会打折扣。

怎么避免这个问题？我们的建议是：

1. 尽量选同一个团队出的向量模型和重排序模型，它们的训练数据和目标通常比较一致

2. 如果不是同一系列，一定要在自己的数据集上测一下提升率，不要想当然

3. 重排序模型的提升率如果低于5%，就要考虑是不是适配有问题，或者换一个重排序模型试试

说实话，这个坑相对隐蔽，很多人根本想不到要测这个。他们觉得只要加了重排序，效果就一定会好。但实际上，如果两个模型不适配，提升可能微乎其微，白花了算力成本。

七、1分钟快速选型决策工具

说了这么多，可能有人还是觉得太复杂，想直接要答案。这一章我们就做一个简单的决策工具，你根据自己的情况，1分钟就能选出适合的模型。

7.1 按知识库规模选型

第一个维度是知识库规模，这是最核心的选型依据。

解释一下：

1万篇以内的小知识库，small模型就够了，准确率差不了多少，但速度快很多，成本也低。这种规模的知识库，哪怕用关键词检索效果都不会太差，向量模型只是锦上添花。

1万到10万篇，base模型是性价比之选。这个规模下，base模型的Top10命中率能到80%左右，大多数场景都够用了。如果对准确率要求不高，不加重排序也能跑。

10万到100万篇，base模型的准确率会降到70%多，这时候就建议加重排序了。加了重排序之后，准确率能回到85%以上，效果就很不错了。

100万篇以上，这时候base模型的召回率可能有点不够用了，可以考虑上large模型。但即使是large模型，也必须加重排序，否则准确率还是不够看。

7.2 按硬件配置选型

第二个维度是你的服务器配置。很多时候不是你想选什么模型，而是你的服务器能跑什么模型。

这里的并发能力是估算值，实际情况和你的查询长度、文档长度、CPU型号都有关系，仅供参考。

如果你的服务器内存比较紧张，比如只有4G，那就老老实实选small模型，别勉强上base，否则模型加载都费劲，更别说跑查询了。

如果有8G以上内存，就可以考虑上base模型。16G以上的话，base向量+base重排的组合应该能跑起来，这也是我们最推荐的配置，性价比最高。

如果想上large模型，建议至少32G内存，因为large向量+base重排加起来就要3G多内存，再加上系统和其他服务，16G其实挺紧张的。

7.3 按延迟要求选型

第三个维度是延迟要求。不同的业务场景，对延迟的容忍度不一样。

如果是实时性要求很高的场景，比如搜索框的实时联想建议，那可能连base模型都嫌慢，得用small模型，而且不能加重排序。

如果是普通的知识库问答场景，50ms到100ms的延迟用户基本感知不到，base+重排的组合就很合适。

如果是离线场景，或者对延迟要求不高的场景，比如批量处理、后台分析，那可以考虑上large模型，反正慢一点也没关系。

7.4 技术文档场景推荐组合

最后，针对技术文档这个特定场景，我们给出三个推荐组合，你可以直接抄作业。

入门版：bge-small-zh-v1.5

适合小团队、小知识库、预算有限的场景。部署简单，速度快，成本低，效果也够用。1万篇以内的知识库，用这个完全没问题。

标准版：bge-base-zh-v1.5 + bge-reranker-base

这是我们最推荐的配置，也是大多数生产环境的最优解。准确率够高，性能够好，成本也不高。10万到100万篇的知识库，用这个组合基本都能hold住。

旗舰版：bge-large-zh-v1.5 + bge-reranker-large

适合大规模知识库、对准确率要求极高的场景。效果最好，但成本也最高，延迟也最大。如果不是特别需要，不建议一上来就上旗舰版，标准版的性价比高太多了。

当然，这只是我们的推荐。最好的选型方式，还是拿自己的数据测一遍。毕竟每个团队的业务场景都不一样，适合别人的不一定适合你。

写在最后

这篇文章到这里就差不多结束了。最后再啰嗦几句。

我们做这次实测的初衷，就是想给技术类GEO场景的开发者提供一份靠谱的选型参考。网上的模型推荐文章很多，但大多是主观感受，很少有针对技术文档场景的、可复现的横向评测。我们希望这篇文章能填补这个空白。

当然，这次评测也有局限性。比如我们的测试集虽然覆盖了多个技术领域，但还是以通用技术文档为主，如果你是更细分的领域，比如医疗技术、金融技术，结论可能会有差异。再比如我们只测了CPU推理的情况，如果你用GPU推理，性能数据会不一样。

但我们觉得，大方向是对的。base模型的性价比远高于large模型，重排序带来的提升远大于模型升级，这些结论应该在大多数场景下都成立。

如果你生产环境在用什么模型，效果怎么样，欢迎在评论区交流。有选型问题的话，也可以把你的场景说出来，大家一起讨论。

如果你觉得这篇文章对你有帮助，也可以看看我们之前写的关于RAG分块策略、prompt调优、最佳实践的系列文章，都是技术干货。链接我放在下面了：

• 《RAG分块策略完全指南：从5种基础方法到语义分块的技术实现》

• 《大模型检索调参技术实操：Top K、温度、惩罚系数的最佳实践》

• 《GEO技术实现原理：生成式引擎优化的底层逻辑》

感谢阅读，我们下期再见。

参考文献

1. BGE: BAAI General Embedding. 智源研究院, 2023.

2. MTEB: Massive Text Embedding Benchmark. ACL 2023.

3. Text Embeddings by Weakly-Supervised Contrastive Pre-training. arXiv:2212.03533, 2022.

4. GTE: A General Text Embedding Model. 阿里巴巴达摩院, 2023.

5. M3E: Moka Massive Mixed Embedding. MokaAI, 2023.