选错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, devicecuda)这里有一个我踩过的坑模型名称不要拍脑袋填先去模型库确认完整路径。名字填错了加载时可能不会立刻报错但推理得到的向量会非常异常。我之前有一次就是填错了一个版本号结果整个评估流程跑完了数据一分析才发现向量特征完全不对白白浪费了大半天时间。另外device参数一定要显式指定。默认情况下它会自动选择但有时候机器上同时存在多张GPU卡自动选择不一定是性能最好的那张。手动指定避免不确定性。3.2 构建领域测试集这里的关键是测试集必须包含“查询”和“相关文档”两个部分。伪代码如下import json # 建议格式: JSON文件每条记录包含query和positive_docs两个字段 # positive_docs是跟该查询相关的文档文本列表 with open(domain_eval_set.json, r, encodingutf-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_size32): 批量编码文本返回归一化后的向量矩阵 embeddings model.encode( texts, batch_sizebatch_size, show_progress_barFalse, normalize_embeddingsTrue # 归一化后点积与余弦相似度等价 ) return embeddings这里有一个性能优化技巧normalize_embeddingsTrue会把向量归一化为单位向量。归一化之后计算相似度时直接用点积就行不需要再除以模长计算效率会高很多。在候选文档数量达到几十万上百万的量级时这个优化对检索速度的影响非常明显。batch_size的选择也有讲究不是越大越好。批量太大容易导致显存溢出太小又浪费GPU并行能力。一般根据模型的参数量和GPU显存来定我从32开始尝试如果显存不足就降到16要是还有问题再降到8。3.4 计算MRR与召回率MRR和召回率RecallK是评估检索质量时最常用的两个指标。直接上代码def evaluate_retrieval(model, eval_data, corpus_docs, top_k10): 计算MRR与RecallK # 先对全部候选文档编码 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 # 计算RecallK 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, fRecall{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_typetypo): 模拟用户输入噪声 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[pos1:] 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_k10): 对比原始查询与噪声查询的召回率差异 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_runs100): 测量批量编码的平均延迟与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_size64, max_gpu_memory_gb8): 分批编码文本控制显存占用 all_embeddings [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] embeddings model.encode(batch, normalize_embeddingsTrue) 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 常见问题速查表附带一张我总结的问题排查表按高频程度排序问题现象可能原因排查方向检索结果明显不相关模型语种不匹配确认模型是否覆盖目标语种结果时好时坏不稳定相似度阈值不合理分析相似度分布重新设定阈值同义表达检索不到模型语义能力不足换成参数量更大的模型向量库搜索很慢维度太高/数据量大评估降维或用向量索引加速显存不够用批量过大/多模型并存降低batch_size或逐模型释放模型加载特别慢网络下载/未启用缓存提前下载模型到本地目录线上效果远不如测试集训练集代表性不足重做领域测试集增加真实语料这张表不是万能的但它覆盖了我在项目中遇到的大多数问题。如果你的对角线问题不在表里建议先从“测试集是否真实”这个源头排查因为很多问题表面上是模型问题实际是评估数据不够真实。6. 实操心得一次完整的选型复盘最后分享一个我在模拟项目X里的完整复盘过程。这个项目的业务背景是某企业内部文档检索系统语言为中文数据总量约200万篇文档日常查询高峰集中在工作日上午查询类型以长尾为主。6.1 候选模型池的选择初筛阶段我从模型库中选了4个候选分别代表了不同的技术路线一个通用中文模型一个领域微调的专用模型一个参数量较小的轻量模型还有一个以英文为主的多语言模型。排除最后一个是因为它虽然声称支持中文但我测试下来中文语义理解能力明显不足5分钟就出局了。最终进入深度对比的是三个中文模型。6.2 测试结果对比用真实的业务查询构建了80组测试数据混合了高频查询、长尾查询和歧义查询。评测结果为评估指标模型A模型B模型CMRR0.7610.8230.712Recall100.8420.8950.803鲁棒性分数0.860.920.78平均延迟毫秒/条2.83.62.1P99延迟毫秒/条10.212.58.4向量维度7681024512存储成本200万条6.1GB8.2GB4.1GB模型B在检索质量和鲁棒性上全面领先但延迟高了30%存储成本高了35%。如果是在一个资源紧迫的项目里模型B未必是最终选择。但在当前项目里检索质量是第一优先级所以最终选了模型B。6.3 上线前踩的最后一个坑模型B部署上线的过程中我们遇到了一个没人预料到的问题首令牌延迟比预期高很多。排查后发现是模型在首次推理时会加载额外的分词器资源导致第一批查询延迟异常。用一次“预热推理”就能解决在服务启动后主动跑一次编码任务把相关资源全部加载到位。这个问题让我意识到评估阶段的延迟测试不能只看稳定状态还要包含冷启动场景。我把这个经验整理进了团队的技术手册后续所有模型上线前都强制加一轮预热验证。这个项目做完后我最大的感受是选Embedding模型不是一个技术决策而是一个综合权衡——质量、成本、延迟、可维护性缺一不可。没有全局最优的模型只有最适合你业务场景的选择。希望这套框架和代码能帮你在自己的项目里少走一些弯路。
