选错Embedding模型，你的RAG系统一开始就输了

做了几年向量检索相关的项目，我最大的感受是：很多人花了大把时间调优RAG流程、设计Prompt，却在最关键的Embedding模型选择上草率得离谱。

我见过太多这样的现场——项目遇到瓶颈，检索效果上不去，第一反应是换向量数据库、调分块策略、改重排序逻辑，折腾一圈下来发现收益微薄。最后有人随口问了一句：“你们用的Embedding模型是什么？”答案是某平台默认的那个。所有人都沉默了。

你可能会觉得“Embedding模型不就是把文本变成向量吗？能用就行”。如果你真这么想，那我建议你花十分钟看完这篇内容。我结合自己踩过的坑、对比过的模型、调过的参数，整理了一套6步评估框架，附上可直接运行的代码实践。这套流程我自己在模拟项目X里反复用过，不敢说让你一步到位，但至少能帮你避开90%的坑。

先说清楚，这篇文章适合哪类人：正在搭建RAG系统但检索效果不理想的开发者、准备做语义搜索但不知道选什么模型的新手、以及想系统理解Embedding选型逻辑的技术负责人。文章不绕弯子，直接讲方法和踩坑经验。

1. 先搞清楚：90%的人到底错在哪里

1.1 选模型等于选“翻译官”，不是选“字典”

很多人对Embedding模型的理解有个根本偏差——把它当成一个简单的映射工具，输入句子，输出向量，完事。但Embedding模型的本质是语义翻译官：它把人类语言翻译成机器能计算的坐标。这个翻译官的水平高低，直接决定了两个语义相近的句子在向量空间里是否真的挨得近。

这就像一个翻译官如果是个半吊子，客户说“我要辣一点”，他翻译成“增加温度”，老外厨师做出来的菜就是烫嘴但不辣。Embedding模型同理——如果它对中文语义理解不到位，“苹果发布了新手机”和“水果公司推出了新设备”这两句话的向量距离可能远得离谱。

我在实际项目中踩过的典型坑是：用只针对英文语料训练的模型来处理中文数据。结果就是检索结果经常“答非所问”，当时我还以为是分块策略的问题，调了两周参数，最后换了个中文模型，效果立竿见影。从那时起我就意识到，Embedding模型选型不是一个配置项，而是整个系统的地基。

1.2 只看榜单分数，脱离业务场景

另一个常见误区是过分迷信公开榜单。HuggingFace上的MTEB、C-MTEB、大规模中文Embedding评测榜单里的分数，确实能在宏观层面反映模型能力，但榜单上的高分段位，不代表在你的领域里就好用。

为什么？因为榜单评测的语料是通用领域的。我的项目里全是某个特定行业的技术文档，术语密集、表述严谨、行话极多。通用模型在这种语料上的表现，跟它在通用评测集上的表现完全是两回事。我自己做过测试，某个在C-MTEB上排名靠前的通用模型，在我这个行业的专用语料上，召回率反而不如一个参数量更小、但在该行业微调过的模型。

榜单分数可以参考，但只能作为初筛依据，不能作为最终决策依据。这就是为什么我需要一套系统化的评估框架，而不是依赖单一指标。

1.3 把维度、相似度算法、模型能力混为一谈

还有一类错误，是把向量维度当成了模型能力的象征。有人觉得“4096维肯定比768维好吧”，然后就选了高维模型，向量数据库存储成本翻了好几倍，检索速度也降下来，但效果提升并不明显——因为维度和语义理解能力没有直接关系。

维度只是语义特征的表示粒度，高维度给了模型更大的表达能力，但不代表模型更懂语言。一个768维的模型，如果训练充分、语料对路，完全可能比一个4096维但训练粗糙的模型更懂你的业务语言。

同理，很多人把余弦相似度和Embedding模型的能力混为一谈。余弦相似度只是个度量函数，不管用什么模型生成的向量，都可以用余弦相似度来计算距离。真正决定“语义相近是否等于向量相近”的，是模型本身，而不是相似度算法。这一点如果不搞清楚，后面所有评估都会失真。

1.4 忽略模型更新与维护成本

选Embedding模型不是一锤子买卖。模型要跟你的业务一起演进，你的数据在变、用户在变、业务的语义边界也在变。这就需要考虑模型是否可持续使用。

我在项目里遇到过这样的尴尬：选了一个闭源的API模型，用得挺顺，结果对方直接下架了对应版本，换成了新版。新版的向量维度变了，我存库里几十亿条向量全部得重新生成、重新索引。那种痛苦，经历过一次就不想再有第二次。

后来我偏向于选择那些有开源权重、社区活跃、迭代路径清晰的模型。开源意味着可控，活跃意味着可持续。你不能把自己的系统地基建在别人随时可能抽走的沙子上。

2. 六步评估框架：从需求到落地的完整路径

这一套框架的核心逻辑是：先搞清楚自己需要什么，再去测试模型能不能满足，最后用可量化的指标做决策。整个框架包含六个步骤，一步都别跳。

2.1 第一步：明确场景类型与任务边界

选模型之前，第一件事是给任务归类。不同任务对Embedding模型的要求完全不同。

检索任务（Retrieval）需要模型把查询语句和文档里的句子映射到同一语义空间，要求的是“区分度”——相关的内容距离近，不相关的距离远。聚类任务要求的是“紧凑性”——同一类内容的向量尽量聚拢。分类任务则更看重“线性可分性”——不同类别的向量在空间中是否有清晰的边界。同一个模型在这三类任务上的表现可能差异很大。

我在模拟项目X里先做了一个简单对照：用同一个模型，分别做语义检索和文本聚类，效果差异非常明显。检索阶段模型表现得很好，Top-10召回率很高；但聚类时同一类别的文档被散到多个簇里，边界模糊。后来我意识到这不是模型的问题，而是我压根没搞清楚自己的任务优先级。

所以第一步不是选模型，而是明确任务类型。检索为主，就重点测召回率；分类为主，就重点测分界线明显程度。一个模型不需要在所有任务上表现最优，适合你任务的就是好模型。

2.2 第二步：搭建领域语料测试集

这是整个框架里最耗时间、也最关键的步骤，但很多人在这一步偷懒了。

为什么不直接用公开评测集？因为公开评测集跟你的业务语料大概率是两个世界。你做一个电商领域的客服问答系统，用新闻摘要评测集来测Embedding模型，得出来的结论没有任何参考意义。就像你用体育生的体测成绩去选拔钢琴手，测出来的东西跟实际演奏水平毫无关系。

正确的做法是：从你的业务语料里抽出一批有代表性的样本，构建一个领域小测试集。不需要很大，50到100组“查询-相关文档”对就够了。重点在于“代表性”——必须覆盖你的业务中真正的查询场景，包括长尾查询、口语化表达、专业术语查询等。

我在这个环节的操作方式是：把过去半年内的真实用户查询日志拉出来，按照频率排序，取高频的60条和随机抽样40条，一共100条。针对每条查询，让业务同事标出3到5条相关文档。这个过程很痛苦，但做一次能用很久，而且选出来的模型是真正贴合业务的。

2.3 第三步：初筛候选模型池

确定测试集之后，就要圈定候选模型。这个阶段不需要精测，但要广撒网。一般我会从三个维度来圈定：

模型的语言能力是否覆盖我的核心语种。如果你主要处理中文，直接筛掉纯英文模型。社区活跃度也很重要，一个模型如果issues没人回、更新停滞、文档残缺，你后续落地的风险会很高。部署生态也不能忽略，是否支持常见的推理框架、是否有量化版本、是否能方便地导出为特定格式。

除了这些，我还会参考该模型在垂直领域的口碑。某些模型在法律、医疗、代码等垂直领域有专门优化，如果你的业务属于这些方向，优先关注这些模型。

初筛后的候选池建议控制在3到5个模型。太多了测试成本高，太少了选择空间不够。

2.4 第四步：设置量化评估指标

这一步是很多人最容易犯错的环节——用单一指标评估所有能力。我自己的实践是至少看四个维度的指标：

检索质量指标准确率、召回率、MRR（平均倒数排名）这些常规指标。其中MRR对检索场景尤其重要，它关注的是“正确答案排在第几位”，第一位给1分，第二位给0.5分，以此类推。对于问答系统来说，这个指标的参考意义比单纯的准确率更直观。

语义鲁棒性指标是同义改写、语序调整、错别字干扰下，检索结果的稳定性。这在真实业务里太重要了，用户不会按照你的标准格式来提问，口语化表达和错别字是常态。

效率指标包括单条文本的编码延迟、吞吐量。Embedding模型如果延迟太高，直接拖垮在线检索链路。

存储成本容易忽略，向量维度决定了存储开销和内存占用。高维模型意味着更高的存储成本和更大的内存消耗，但高维并不等于高质量。发布前先算清楚这笔账。

2.5 第五步：跑通模型对比实验

候选模型池和评估指标都确定了，就可以开始跑对比实验。这一步没有捷径可走，必须让所有候选模型接受完全相同的处理流程——相同的输入、相同的预处理、相同的评测脚本。

我在这一步的关键经验是：一定要在跟线上环境一致的条件下测试。有人说“我先在笔记本上快速验证一下”，结果数据集一换、硬件一换，性能数据翻天覆地。Embedding模型的推理速度跟硬件强相关，GPU、CPU、内存带宽都会影响。笔记本上的测试数据不能用于生产决策。

对比实验做完后，把所有指标汇总成一张表。不要只看“哪个总分高”，要结合自己场景的优先级来加权判断。比如我的场景里，召回率权重30%，MRR权重30%，鲁棒性权重20%，延迟权重10%，存储成本权重10%。各人权重不同，得出来的“最优模型”也不同。

2.6 第六步：上线前压力测试与灰度验证

很多人的对比实验做完就上线了，这是高风险操作。你的测试集规模再合理，也覆盖不了线上真实流量的多样性。上线前再做一轮压力测试和灰度验证，是对生产环境负责。

压力测试主要看模型在预期的峰值流量下，延迟和吞吐量能否满足要求。我做过一次测试，当时以为模型已经够快了，结果并发量一上来，P99延迟直接飙到了800毫秒，远远超出预期。后来加了批处理缓存才压下去。这问题如果不提前发现，上线当天就是事故。

灰度验证的做法是：新模型和旧模型同时跑，分别处理一部分流量，对比线上的真实检索效果。如果新模型的点击率、成交转化率或用户满意度显著优于旧模型，再逐步放量。灰度验证期建议至少一周，覆盖一个完整的业务周期。

3. 代码实战：手把手搭建评估流水线

框架讲清楚了，直接上实操。这一节我提供一套可复用的评估代码，核心流程包括：候选模型加载、领域测试集构建、指标计算、结果对比。所有代码基于Python环境，依赖库为sentence-transformers、numpy、sklearn。

3.1 环境准备与模型加载

先安装依赖：

pip install sentence-transformers numpy scikit-learn

加载模型的代码非常简单，但有几个细节需要注意：

from sentence_transformers import SentenceTransformer # 加载模型时，建议显式指定device，避免默认行为造成性能浪费 model = SentenceTransformer("your-model-name", device="cuda")

这里有一个我踩过的坑：模型名称不要拍脑袋填，先去模型库确认完整路径。名字填错了，加载时可能不会立刻报错，但推理得到的向量会非常异常。我之前有一次就是填错了一个版本号，结果整个评估流程跑完了，数据一分析才发现向量特征完全不对，白白浪费了大半天时间。

另外，device参数一定要显式指定。默认情况下它会自动选择，但有时候机器上同时存在多张GPU卡，自动选择不一定是性能最好的那张。手动指定，避免不确定性。

3.2 构建领域测试集

这里的关键是：测试集必须包含“查询”和“相关文档”两个部分。伪代码如下：

import json # 建议格式: JSON文件，每条记录包含query和positive_docs两个字段 # positive_docs是跟该查询相关的文档文本列表 with open("domain_eval_set.json", "r", encoding="utf-8") as f: eval_data = json.load(f) # eval_data结构示例 # [ # { # "query": "如何配置用户权限映射？", # "positive_docs": [ # "系统支持基于角色的权限控制，通过配置文件完成用户-角色映射...", # "权限模块默认开启白名单机制，管理员可在管理后台编辑角色绑定关系..." # ] # }, # ... # ]

我在实际项目里还会额外加一个hard_negative_docs字段，存放一些跟查询有点关联但实际不相关的文档。这种“看似相关实则不相关”的负样本，对评估模型的区分能力非常关键。如果一个模型总是把那些模糊的干扰项排在前面，说明它的语义边界不够清晰。

{ "query": "如何配置用户权限映射？", "positive_docs": ["系统支持基于角色的权限控制，通过配置文件完成..."], "hard_negative_docs": ["用户的登录日志存储在独立的审计模块中，支持按时间段检索..."] }

这个数据集不用追求数量庞大，但样例质量必须高。50到100组查询，对选型评估来说足够用了。

3.3 向量化与相似度计算

把查询和相关文档都编码成向量后，用余弦相似度来衡量距离：

import numpy as np from numpy.linalg import norm def cosine_similarity(vec_a, vec_b): return np.dot(vec_a, vec_b) / (norm(vec_a) * norm(vec_b)) def encode_texts(model, texts, batch_size=32): """批量编码文本，返回归一化后的向量矩阵""" embeddings = model.encode( texts, batch_size=batch_size, show_progress_bar=False, normalize_embeddings=True # 归一化后，点积与余弦相似度等价 ) return embeddings

这里有一个性能优化技巧：normalize_embeddings=True会把向量归一化为单位向量。归一化之后，计算相似度时直接用点积就行，不需要再除以模长，计算效率会高很多。在候选文档数量达到几十万上百万的量级时，这个优化对检索速度的影响非常明显。

batch_size的选择也有讲究，不是越大越好。批量太大容易导致显存溢出，太小又浪费GPU并行能力。一般根据模型的参数量和GPU显存来定，我从32开始尝试，如果显存不足就降到16，要是还有问题再降到8。

3.4 计算MRR与召回率

MRR和召回率（Recall@K）是评估检索质量时最常用的两个指标。直接上代码：

def evaluate_retrieval(model, eval_data, corpus_docs, top_k=10): """计算MRR与Recall@K""" # 先对全部候选文档编码 all_doc_embeddings = encode_texts(model, corpus_docs) total_mrr = 0.0 total_recall = 0.0 num_queries = len(eval_data) for item in eval_data: query = item["query"] positive_docs = set(item["positive_docs"]) # 编码查询 query_embedding = encode_texts(model, [query])[0] # 计算查询与所有文档的相似度 similarities = np.dot(all_doc_embeddings, query_embedding) # 获取相似度最高的前K个文档索引 top_indices = np.argsort(similarities)[::-1][:top_k] retrieved_docs = [corpus_docs[idx] for idx in top_indices] # 计算MRR for rank, doc in enumerate(retrieved_docs): if doc in positive_docs: total_mrr += 1.0 / (rank + 1) break # 计算Recall@K retrieved_set = set(retrieved_docs) hits = len(retrieved_set & positive_docs) total_recall += hits / len(positive_docs) mrr = total_mrr / num_queries recall_at_k = total_recall / num_queries return {"MRR": mrr, f"Recall@{top_k}": recall_at_k}

这段代码的核心逻辑是：对每个查询，找到它的真实相关文档在检索结果中的最靠前排名，计算MRR贡献；再统计相关文档被召回的占比，计算召回率。

代码本身不复杂，但有一个细节特别需要说明：确保corpus_docs里包含了测试集关联的全部候选文档。这个语料库可以是全量的业务文档，也可以是抽样的一部分。为了控制评估成本，我常用的是抽样语料——随机抽出一定数量的不相关内容混入，加上每条查询关联的positive和hard_negative文档。这个混合语料库规模控制在2000到5000条文本之间，已经足够评估模型的相对优劣。

3.5 鲁棒性测试：模拟真实噪声

真实用户的输入远没有测试集那么规范，所以我一直保留一条鲁棒性测试流程。做法很简单：对原始查询加入噪声，再测试模型的表现。

import random import re def add_noise_to_query(query, noise_type="typo"): """模拟用户输入噪声""" if noise_type == "typo": # 随机替换某个字符为相邻键盘字符 if len(query) > 4: pos = random.randint(1, len(query) - 2) char = query[pos] # 模拟一个常见错误：随机把中文替换成一个形近字 noise_table = {"的": "得", "用": "永", "权": "全", "配": "配"} if char in noise_table: query = query[:pos] + noise_table[char] + query[pos+1:] elif noise_type == "word_order": # 模拟语序颠簸 words = list(query) if len(words) > 4: idx1 = random.randint(0, len(words) - 2) idx2 = idx1 + 1 words[idx1], words[idx2] = words[idx2], words[idx1] query = "".join(words) return query def robustness_evaluation(model, eval_data, corpus_docs, top_k=10): """对比原始查询与噪声查询的召回率差异""" original_metrics = evaluate_retrieval(model, eval_data, corpus_docs, top_k) noisy_data_no = [] for item in eval_data: noisy_item = { "query": add_noise_to_query(item["query"], "typo"), "positive_docs": item["positive_docs"] } noisy_data_no.append(noisy_item) noisy_metrics = evaluate_retrieval(model, noisy_data_no, corpus_docs, top_k) robustness_score = 1.0 - abs(original_metrics["MRR"] - noisy_metrics["MRR"]) / original_metrics["MRR"] return { "original_mrr": original_metrics["MRR"], "noisy_mrr": noisy_metrics["MRR"], "robustness_score": robustness_score }

鲁棒性测试的产出是一个“抗噪分数”——原始查询和噪声查询的MRR差距越小，说明模型对输入变体越不敏感。我在真实业务中发现，某些模型在干净测试集上MRR很高，但用户一用口语化表达或带错别字的查询，效果立刻跳水。这类模型如果做C端产品，上线后必然被吐槽。

3.6 延迟测试与成本估算

最后是延迟测试和成本估算。延迟用代码测量：

import time def latency_test(model, texts, num_runs=100): """测量批量编码的平均延迟与P99延迟""" latencies = [] for _ in range(num_runs): start = time.perf_counter() encode_texts(model, texts) end = time.perf_counter() latencies.append(end - start) latencies.sort() avg_latency = sum(latencies) / len(latencies) p99_latency = latencies[int(len(latencies) * 0.99) - 1] return {"avg_latency_sec": avg_latency, "p99_latency_sec": p99_latency}

成本估算则相对简单：

• 存储成本 = 向量总数 × 维度 × 4字节（单精度浮点）
• 全量向量重新生成耗时 = 文本总数 ÷ 单条处理速度

这两个指标的意义在于让你对生产环境的资源需求有量化认知。举例来说，1000万条文档，每个文档用768维向量表示，需要的存储空间约为30GB。如果换用1024维模型，存储就变成了约38GB，增加接近28%。如果业务量还在快速增长，这个差距会被不断放大。

4. 工具选型：为什么我不建议直接“跑分选最优”

聊完评估流程和代码，再说说整个选型过程中的几个关键决策点。这些决策点看似小事，但选错了会让前面的评估工作全部白费。

4.1 开源本地部署 vs 托管API

这是最核心的一个决策。两种方案各有适用场景，不能一概而论。

开源本地部署的优势在于完全可控，模型更新、微调、定制都可以自主决定；没有API调用费用；数据不出内网，安全性更有保障。劣势也很明显：需要自己准备推理资源，GPU、内存、运维人力都是成本；模型版本维护要自己跟进。适合对数据安全要求高、有基础技术团队、调用量大的场景。

托管API的优势是开箱即用，不需要关心显存和推理优化；厂商会持续优化模型和基础设施。劣势是长期成本高，尤其调用量上来以后费用线性增长；且受制于厂商的版本变动，之前提到过的“模型版本被强制升级”风险就属于这类问题。适合快速验证原型、调用量小、对数据合规要求不高的场景。

我的个人建议是：如果业务已经进入稳定期，且调用量预估会持续增长，尽早布局本地部署方案。哪怕初期用一两张消费级显卡顶着，也比长期依赖API合同要稳妥。

4.2 通用模型 vs 领域微调模型

通用模型经过了大规模语料训练，覆盖面广，知识丰富。但它的语义空间是基于通用语料构建的，对特定领域的术语和上下文关系理解有限。

领域微调模型则是在通用模型的基础上，用领域语料进行二次训练。它的语义分布会向该领域倾斜。我之前测试过一个在医疗语料上微调过的模型，在通用领域的表现跟基础模型几乎一致，但到了医疗文档的检索任务上，MRR提升幅度明显。

不过领域微调模型有个潜在风险：微调语料的质量直接影响模型能力。如果微调语料质量参差不齐，模型反而可能学到错误的知识，使得通用能力大幅倒退。所以选择领域模型时，一定要确认它的训练语料来源和质量。

4.3 模型版本更新的兼容性考量

这一点很少被系统性地讨论，但实际做项目时极易踩坑。选模型时，提前确认它的版本演进策略——是每个版本独立，还是向后兼容？维度是否会变？向量语义是否稳定？

我之前经历过一次模型升级，新版模型的向量分布跟旧版差异很大，导致已经构建的索引全部失效，需要重新编码全量数据。那次之后，我在选型时增加了“升级成本”评估指标：模型升级时，重新编码全量数据的成本是多少？向量维度是否一致？是否需要重建索引？这些问题的答案直接关系到后续的维护成本。

5. 高频误区与问题排查：从失败中捞出来的经验

写这一节，是希望能帮你绕过那些我花了很多时间才爬出来的坑。这些问题如果早有人告诉我，我能省下至少一个月的调试时间。

5.1 “维度越高越好”的认知误区

这可能是最流行也最害人的误区。高维度确实能承载更多信息，但维度高意味着存储成本高、计算开销大，且容易引入无关噪声。如果模型的训练语料不足以支撑高维度的充分表达，高出来的维度反而成为负担。

我在一个未知文本类型的项目里做过一次对比：同一个语义任务，768维模型和1024维模型的检索效果几乎一致，但磁盘占用差了33%。为了那微不足道的提升付出一笔长期存储成本，说实话不划算。

5.2 “相似度阈值”不是拍脑袋定的

做检索系统时，很多人喜欢设定一个相似度阈值——大于0.75就算相关。但这个0.75是怎么来的？如果模型输出的向量分布整体偏高或偏低，0.75这个值就完全没有意义。

正确的做法是：先从测试集里把“相关文档对”和“不相关文档对”的相似度分布画出来，观察两个分布的重叠区间。阈值应该设在两个分布的重叠最小处，而不是拍脑袋定一个固定值。我在项目中实际做过一次分布分析，相关文档的相似度中位数是0.82，不相关文档的中位数是0.51，但两者尾部有较长的重叠。最终阈值定在0.68，才能最大化区分能力。

5.3 批量加载与显存管理

Embedding模型加载时，如果一次性把全部候选文档编码完，很容易显存溢出。我的做法是分批编码，每批处理后释放中间变量：

def encode_in_batches(model, texts, batch_size=64, max_gpu_memory_gb=8): """分批编码文本，控制显存占用""" all_embeddings = [] for i in range(0, len(texts), batch_size): batch = texts[i:i+batch_size] embeddings = model.encode(batch, normalize_embeddings=True) all_embeddings.extend(embeddings) # 释放中间变量 del embeddings import gc gc.collect() return all_embeddings

另外提醒一句：不要在同一进程中反复加载多个Embedding模型，每个模型都会占用大量显存，一次加载多个模型会导致互相挤兑。我遇到过在一个评估脚本里同时加载了4个候选模型的情况，结果后面的模型全部OOM报错。正确的做法是评估完一个模型，显式释放，再加载下一个：

import gc import torch # 评估完一个模型后，释放显存 del model gc.collect() torch.cuda.empty_cache()

5.4 常见问题速查表

附带一张我总结的问题排查表，按高频程度排序：

这张表不是万能的，但它覆盖了我在项目中遇到的大多数问题。如果你的对角线问题不在表里，建议先从“测试集是否真实”这个源头排查，因为很多问题表面上是模型问题，实际是评估数据不够真实。

6. 实操心得：一次完整的选型复盘

最后分享一个我在模拟项目X里的完整复盘过程。这个项目的业务背景是：某企业内部文档检索系统，语言为中文，数据总量约200万篇文档，日常查询高峰集中在工作日上午，查询类型以长尾为主。

6.1 候选模型池的选择

初筛阶段，我从模型库中选了4个候选，分别代表了不同的技术路线：一个通用中文模型，一个领域微调的专用模型，一个参数量较小的轻量模型，还有一个以英文为主的多语言模型。排除最后一个，是因为它虽然声称支持中文，但我测试下来中文语义理解能力明显不足，5分钟就出局了。

最终进入深度对比的是三个中文模型。

6.2 测试结果对比

用真实的业务查询构建了80组测试数据，混合了高频查询、长尾查询和歧义查询。评测结果为：

模型B在检索质量和鲁棒性上全面领先，但延迟高了30%，存储成本高了35%。如果是在一个资源紧迫的项目里，模型B未必是最终选择。但在当前项目里，检索质量是第一优先级，所以最终选了模型B。

6.3 上线前踩的最后一个坑

模型B部署上线的过程中，我们遇到了一个没人预料到的问题：首令牌延迟比预期高很多。排查后发现，是模型在首次推理时会加载额外的分词器资源，导致第一批查询延迟异常。用一次“预热推理”就能解决，在服务启动后主动跑一次编码任务，把相关资源全部加载到位。

这个问题让我意识到，评估阶段的延迟测试不能只看稳定状态，还要包含冷启动场景。我把这个经验整理进了团队的技术手册，后续所有模型上线前都强制加一轮预热验证。

这个项目做完后，我最大的感受是：选Embedding模型不是一个技术决策，而是一个综合权衡——质量、成本、延迟、可维护性，缺一不可。没有全局最优的模型，只有最适合你业务场景的选择。希望这套框架和代码，能帮你在自己的项目里少走一些弯路。