一、为什么MTEB排行榜分数≠生产环境效果做技术类知识库的开发者大概率都踩过这个坑MTEB排行榜上分数很漂亮的向量模型用到自己的技术文档检索场景里效果却差强人意。这个问题不是个例而是整个向量检索领域普遍存在的评测-生产鸿沟。1.1 技术文档场景的特殊性技术文档场景和通用文本场景有本质区别这是很多人忽略的前提。技术文档里充斥着专业术语、缩写、代码片段、版本号同一个词在不同技术栈里可能指代完全不同的概念。举个具体的例子docker这个词在通用语料里可能和码头工人关联但在技术文档场景里100%指容器技术。通用预训练模型在这类术语对齐上天然存在偏差而MTEB评测集里技术类数据占比不到15%根本测不出这层差异。更关键的是技术文档的语义密度。一篇技术文档可能几百字里就包含了三四个核心概念、五六个参数说明、两三个代码示例。这种高密度的语义结构和通用新闻、问答的语义分布完全不是一回事。向量模型在低密度文本上学到的表征模式直接套到高密度技术文本上效果打折扣是必然的。我们服务过的一个技术文档知识库项目用MTEB排名前三的模型做初版Top10准确率只有62%换成一个在技术语料上微调过的小众模型准确率直接拉到78%。这件事让我们意识到通用排行榜在垂直场景里的参考价值其实很有限。1.2 通用评测集的局限性MTEB作为目前最权威的向量模型评测基准本身没有问题但它的设计目标是通用能力评估不是生产环境选型参考。先说评测任务的问题。MTEB包含了分类、聚类、检索、重排序等七大任务类别但每个任务的数据集都是通用领域的。比如检索任务用的是SciFact、FiQA、HotpotQA这些要么是学术论文摘要要么是金融问答要么是多跳推理和技术文档的检索模式差得很远。技术文档检索是什么模式用户输入的查询通常很短可能就是一个函数名、一个报错信息、一个参数名然后要从几万篇文档里精准定位到包含这个信息的段落。这种短查询长文档精确匹配的模式MTEB里没有一个任务能完全覆盖。再说评测指标。MTEB用的是NDCG10、MRR、MAP这些信息检索标准指标但生产环境里开发者真正关心的是什么是Top3能不能命中、是第一次检索不到用户会不会走、是并发查询下延迟能不能稳住。这些生产级指标通用评测集里一个都没有。你别说还有一个更隐蔽的问题评测集里的查询和文档通常是成对标注的也就是说标注者已经知道答案在哪篇文档里然后反过来写查询。但真实用户的查询逻辑完全反过来——用户不知道答案在哪所以查询方式会更发散、更口语化、更不精确。这就导致评测分数和真实效果之间存在系统性偏差。1.3 我们为什么要做这次实测既然通用排行榜靠不住那开发者选型的时候靠什么靠博客推荐靠GitHub star数靠朋友推荐说实话这些方式都太主观了。我们判断技术类GEO场景现在最缺的不是更多的模型而是一套针对技术文档场景的、可复现的、有真实生产指标的横向评测数据。开发者调完RAG的分块策略、prompt参数之后最后一步就是选模型但这一步恰恰没有靠谱的参考数据。顺便说一句这次实测我们前后花了大概三周时间从测试集构建到环境标准化再到跑数据工作量比预想的大不少。中间还踩了几个坑比如不同模型的max_seq_length默认值不一样一开始没对齐导致结果偏差很大后来全部统一到512才重新跑了一遍。所以这篇文章的定位很明确不是又一篇十大向量模型推荐而是一份技术文档场景的实测报告。所有数据都在统一环境下跑出所有测试集和脚本我们都会开源你可以自己复现也可以换成自己的业务数据再测一遍。说实话我们也不确定这次测出来的结论能不能推广到所有技术场景毕竟不同行业的技术文档差异也很大。但至少在我们的测试集上这些结论是站得住脚的供你选型时参考。二、测试环境与评价标准说明所有数据的可信度都建立在测试环境的一致性上。这一章我们把测试环境、数据集、评价标准全部公开确保每一个数字都可追溯、可复现。2.1 统一测试硬件环境为了保证公平性所有模型都在同一台云服务器上测试硬件配置完全一致。配置项规格CPUIntel Xeon Platinum 8369B8核内存16GB DDR4系统盘100GB SSD操作系统Ubuntu 22.04 LTSPython版本3.10.12PyTorch版本2.2.0推理框架sentence-transformers 2.5.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相关的文档标注过程采用双盲交叉校验不一致的地方由第三人仲裁确保标注质量。评价指标我们选了三个维度准确率指标Top1、Top3、Top10命中率这是生产环境最关心的延迟指标单条查询的P50、P95延迟关注尾延迟资源指标模型加载后的内存占用、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款模型覆盖了目前主流的几个系列都是开源可商用、社区活跃度高的模型。模型名称维度参数量发布方bge-large-zh-v1.51024326M智源研究院bge-base-zh-v1.5768109M智源研究院bge-small-zh-v1.551228M智源研究院m3e-large1024326MMokaAIm3e-base768109MMokaAItext2vec-large-chinese1024326Mshibing624text2vec-base-chinese768109Mshibing624gte-large-zh1024326M阿里巴巴gte-base-zh768109M阿里巴巴e5-large-v21024326M微软可以看到我们特意选了每个系列的large、base、small版本就是为了对比不同参数量模型的性价比。另外e5模型虽然是英文为主的但因为用的人很多我们也放进来做个参照。3.2 Top10准确率横向对比先看大家最关心的准确率数据。所有数据都是在10万篇文档测试集上测得的。模型名称Top1命中率Top3命中率Top10命中率bge-large-zh-v1.548.2%68.5%82.3%bge-base-zh-v1.546.7%66.8%80.7%bge-small-zh-v1.541.3%61.2%75.6%m3e-large45.8%65.3%79.8%m3e-base44.2%63.7%78.1%gte-large-zh47.1%67.2%81.2%gte-base-zh45.5%65.6%79.5%text2vec-large-chinese43.6%62.8%77.4%text2vec-base-chinese42.1%60.9%75.8%e5-large-v238.7%57.2%72.1%从结果来看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 查询延迟与内存占用分析光看准确率不够生产环境还要考虑性能。我们测了每个模型的单条查询延迟和内存占用。模型名称P50延迟(ms)P95延迟(ms)内存占用(MB)bge-large-zh-v1.542.368.51280bge-base-zh-v1.516.827.2512bge-small-zh-v1.58.213.5256m3e-large45.172.31320m3e-base17.528.6528gte-large-zh43.770.11296gte-base-zh17.228.1520text2vec-large-chinese44.571.81310text2vec-base-chinese17.929.3536e5-large-v241.867.21264性能差距就很明显了。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万篇三个规模下测试了模型的准确率变化。模型名称1万篇Top1010万篇Top10100万篇Top10bge-large-zh-v1.589.2%82.3%73.5%bge-base-zh-v1.588.1%80.7%71.8%bge-small-zh-v1.584.3%75.6%65.2%可以看到随着知识库规模变大所有模型的准确率都会下降这是正常的——候选集变大了命中难度自然增加。但有意思的是不同模型的下降幅度不一样。large版本的准确率下降相对慢一些从1万篇到100万篇bge-large只降了15.7个百分点而bge-small降了19.1个百分点。这说明大模型在检索区分度上确实有优势尤其是在大规模知识库场景下。不过也要注意100万篇的规模下即使是最好的bge-largeTop10命中率也只有73.5%。这个准确率直接用的话效果可能不会太好。这时候就需要重排序模型来救场了我们下一章会讲。四、5款开源重排序模型实测对比向量召回解决的是从百万级文档里捞回百级候选的问题而重排序解决的是从百级候选里挑出最相关的Top N的问题。两者配合才能在准确率和性能之间找到平衡点。4.1 重排序模型的作用机制很多人对重排序模型有误解觉得它就是再算一遍相似度。其实不是。向量模型是把文档和查询都编码成向量然后算余弦相似度这个过程是双向编码——文档和查询各自编码互不影响。而重排序模型是交叉编码它会把查询和文档拼在一起输入模型让模型同时看到查询和文档的内容然后做相关性判断。这种方式能捕捉更细粒度的语义匹配关系比如术语对应、逻辑关联、上下文依赖等准确率通常比向量模型高很多。但交叉编码的缺点也很明显速度慢。向量模型可以预先把所有文档编码好存起来查询时只需要算一次查询向量但重排序模型每来一个查询都要把查询和每一篇候选文档都跑一遍模型候选越多越慢。所以工业界的标准做法是先用向量模型快速召回Top 100-200篇候选再用重排序模型对这一两百篇做精排。这样既保证了召回率又控制了整体延迟。4.2 NDCG10提升率对比我们选了5款主流的开源重排序模型测试它们在向量召回结果基础上的提升效果。测试方式是先用bge-base-zh-v1.5召回Top 100再用重排序模型重排看重排后的Top10准确率提升了多少。模型名称重排前Top10重排后Top10绝对提升bge-reranker-large80.7%91.2%10.5%bge-reranker-base80.7%89.5%8.8%bce-reranker-base80.7%88.7%8.0%m3e-reranker-base80.7%87.9%7.2%cross-encoder-ms-marco80.7%85.3%4.6%提升效果还是很明显的。最好的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候选的情况下每个模型的延迟和内存占用。模型名称P50延迟(ms)P95延迟(ms)内存占用(MB)bge-reranker-large85.3128.72100bge-reranker-base32.652.1820bce-reranker-base31.850.7790m3e-reranker-base33.553.8840cross-encoder-ms-marco28.746.2720重排序模型的延迟比向量模型高不少这是正常的毕竟要算100次。base版本的P50延迟大概30ms左右加上向量召回的17ms整体P50延迟大概50ms还在可接受范围内。但large版本就比较慢了P50延迟85ms加上向量召回的42ms整体超过120ms。如果对延迟要求比较高的话large版本的重排序模型可能就不太适合在线场景了。内存占用方面重排序模型普遍比向量模型大一些因为它的计算更复杂需要更多的中间状态。base版本大概800MB左右large版本超过2GB对内存紧张的服务器来说是个不小的负担。4.4 与向量模型的适配性这是很多人忽略的一个点向量模型和重排序模型之间是不是存在适配性是不是同一个系列的搭配效果更好我们做了个实验用不同的向量模型召回然后用不同的重排序模型重排看效果差异。向量模型重排序模型重排后Top10提升幅度bge-basebge-reranker-base89.5%8.8%bge-basebce-reranker-base88.7%8.0%m3e-basebge-reranker-base86.8%8.7%m3e-basem3e-reranker-base86.2%8.1%从结果来看确实存在一定的适配性。同一个系列的向量模型和重排序模型搭配提升幅度会稍微大一点但差距不大也就是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.3GBCPU跑满的话大概能支撑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 向量模型和重排序模型不适配第三个坑是向量模型和重排序模型的适配问题。虽然我们前面说过适配性的影响没有想象的那么大但完全不考虑也不行。最常见的问题是向量模型召回的结果重排序模型看不懂。比如向量模型是在中文技术语料上训练的召回的都是技术文档但重排序模型是在英文通用语料上训练的它对中文技术术语的理解能力不够排序效果就会打折扣。还有一种情况是训练目标不一致。有的向量模型是针对问答场景训练的有的是针对语义相似度训练的两者的优化目标不一样。如果你的重排序模型的训练目标和向量模型差得太远提升效果就会打折扣。怎么避免这个问题我们的建议是尽量选同一个团队出的向量模型和重排序模型它们的训练数据和目标通常比较一致如果不是同一系列一定要在自己的数据集上测一下提升率不要想当然重排序模型的提升率如果低于5%就要考虑是不是适配有问题或者换一个重排序模型试试说实话这个坑相对隐蔽很多人根本想不到要测这个。他们觉得只要加了重排序效果就一定会好。但实际上如果两个模型不适配提升可能微乎其微白花了算力成本。七、1分钟快速选型决策工具说了这么多可能有人还是觉得太复杂想直接要答案。这一章我们就做一个简单的决策工具你根据自己的情况1分钟就能选出适合的模型。7.1 按知识库规模选型第一个维度是知识库规模这是最核心的选型依据。知识库规模推荐向量模型是否需要重排序1万篇以内bge-small-zh-v1.5不需要1万-10万篇bge-base-zh-v1.5可选10万-100万篇bge-base-zh-v1.5推荐100万篇以上bge-large-zh-v1.5必须解释一下1万篇以内的小知识库small模型就够了准确率差不了多少但速度快很多成本也低。这种规模的知识库哪怕用关键词检索效果都不会太差向量模型只是锦上添花。1万到10万篇base模型是性价比之选。这个规模下base模型的Top10命中率能到80%左右大多数场景都够用了。如果对准确率要求不高不加重排序也能跑。10万到100万篇base模型的准确率会降到70%多这时候就建议加重排序了。加了重排序之后准确率能回到85%以上效果就很不错了。100万篇以上这时候base模型的召回率可能有点不够用了可以考虑上large模型。但即使是large模型也必须加重排序否则准确率还是不够看。7.2 按硬件配置选型第二个维度是你的服务器配置。很多时候不是你想选什么模型而是你的服务器能跑什么模型。内存配置可部署模型并发能力估算4GB以下small版本向量模型约100 QPS4GB-8GBbase版本向量模型约300 QPS8GB-16GBbase向量 base重排序约150 QPS16GB以上large向量 base重排序约80 QPS这里的并发能力是估算值实际情况和你的查询长度、文档长度、CPU型号都有关系仅供参考。如果你的服务器内存比较紧张比如只有4G那就老老实实选small模型别勉强上base否则模型加载都费劲更别说跑查询了。如果有8G以上内存就可以考虑上base模型。16G以上的话base向量base重排的组合应该能跑起来这也是我们最推荐的配置性价比最高。如果想上large模型建议至少32G内存因为large向量base重排加起来就要3G多内存再加上系统和其他服务16G其实挺紧张的。7.3 按延迟要求选型第三个维度是延迟要求。不同的业务场景对延迟的容忍度不一样。延迟要求推荐方案典型P95延迟极高20mssmall向量模型不加重排约15ms较高50msbase向量模型不加重排约30ms一般100msbase向量 base重排约80ms宽松200mslarge向量 base重排约150ms如果是实时性要求很高的场景比如搜索框的实时联想建议那可能连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技术实现原理生成式引擎优化的底层逻辑》感谢阅读我们下期再见。参考文献BGE: BAAI General Embedding. 智源研究院, 2023.MTEB: Massive Text Embedding Benchmark. ACL 2023.Text Embeddings by Weakly-Supervised Contrastive Pre-training. arXiv:2212.03533, 2022.GTE: A General Text Embedding Model. 阿里巴巴达摩院, 2023.M3E: Moka Massive Mixed Embedding. MokaAI, 2023.