嵌入模型教程：语义向量、中文Embedding、稠密/稀疏/混合检索
摘要
嵌入模型把文本、图像或其他对象映射到向量空间，但生产检索的关键不只是“向量相似”。中文语义、专有名词、短查询、长文档、术语匹配、表格片段和代码片段会共同改变召回表现。本文把 embedding 模型放在检索系统中讨论：模型训练目标、正负样本构造、稠密和稀疏信号、混合检索、查询改写、索引版本和业务评测必须一起设计。文章的目标不是推荐某个单一模型，而是帮助读者建立从语义表示到生产召回的判断框架。
关键词
嵌入模型；Embedding；中文语义检索；稠密检索；稀疏检索；混合检索；余弦相似度；MTEB；RAG
研究问题与方法
本文回答三个问题：嵌入模型如何把语义相似转化为几何邻近；中文场景为什么必须关注分词、实体、同义表达和行业术语；生产系统怎样决定只用稠密检索、保留 BM25，还是采用混合检索与重排。方法上，文章从表示学习和检索工程两侧展开：先解释向量空间和对比学习，再把模型选择放入 chunk、metadata、query rewrite、索引更新和评测集的完整链路。
下图显示本文采用的评价路径。embedding 模型不是孤立评分对象，它要通过真实查询、真实文档和真实错误类型接受检验。
语义向量最常用的相似度可写成余弦形式：
其中 是查询向量， 是文档片段向量。公式看似简单，却隐含一个前提：训练目标、语料分布和业务查询必须让“方向接近”真的对应“证据有用”。否则高相似度只会制造流畅但无根据的召回。
嵌入模型是现代 AI 检索系统的底层能力。用户输入一句自然语言问题，系统要在文档、网页、代码、表格、工单、商品、论文、聊天记录中找到真正相关的内容，不能只靠关键词是否完全相同。嵌入模型把文本转换成向量，让“合同违约责任怎么写”和“协议未履行时如何承担责任”这类表达不同但语义接近的内容落在相近位置，再用向量检索找到候选资料。
但嵌入模型不是把文本“变聪明”的万能按钮。中文语义、行业术语、数字编号、专有名词、表格字段、缩写、错别字、长文档结构、权限过滤、召回评测都会影响结果。很多知识库答错，并不是大模型不会写答案，而是前面的检索没有把正确片段送进上下文。检索系统一旦召回错误，后面再强的生成模型也只能在错误依据上发挥。
一套生产级检索系统通常不只用一种办法。稠密向量适合语义匹配，BM25 和 SPLADE 这类稀疏检索适合精确词项、编号、术语和可解释匹配，混合检索把两类结果合并，再交给重排模型或业务规则筛选。学习嵌入模型，不能只看某个排行榜分数，也不能只问“哪个模型最好”。更重要的是理解向量如何表达语义、中文场景如何评测、稠密和稀疏各自擅长什么，以及怎样把检索链路做成可观察、可回归、可上线的工程系统。
引言：嵌入模型解决的核心问题
传统全文检索把文本看成词项集合。用户搜“报销审批”，系统优先返回包含“报销”和“审批”的文档。这种方法简单、快速、可解释，对编号、姓名、产品型号、法律条款、错误码特别有效。但它不擅长处理表达差异。用户问“发票抬头填错了怎么办”，文档里写的是“开票信息有误如何更正”，关键词不完全重合，纯词项检索可能排不高。
嵌入模型把文本映射成高维向量。向量不是给人阅读的内容，而是模型学习到的语义坐标。两个文本如果在训练数据里经常表现为同义、相关、问答对应、标题正文对应、查询结果对应，它们的向量距离通常会更近。检索时，系统先把用户问题编码成查询向量，再把文档片段提前编码成文档向量，通过余弦相似度、点积或内积找到最近的候选。
这种能力让检索从“字面匹配”进入“语义匹配”。同一个概念可以有不同表达，同一个问题可以用口语或书面语提出，同一份资料可以用标题、摘要、正文、表格说明承载信息。嵌入模型的价值，就是在这些不同表达之间建立可计算的距离。
语义向量也有明显限制。向量相近不代表答案正确，只代表模型认为两段文本在某种训练目标下相关。模型可能把“如何注销账号”和“如何注册账号”看得很近，因为二者共享很多词和场景；可能把“不能退款”和“可以退款”拉得不够开，因为否定词在短句中权重不足；可能对长表格里的列名、单位、时间范围理解不稳；也可能把行业黑话和通用词混在一起。
因此，嵌入模型在检索系统里负责召回候选，不应该独自承担最终判断。真正可靠的系统通常会叠加元数据过滤、稀疏检索、重排模型、引用校验、答案生成约束和人工评测。向量检索越强，越需要清楚它的边界。
语义向量是怎么训练出来的
嵌入模型一般来自 Transformer 编码器或经过改造的语言模型。训练目标不是让模型续写文本，而是让它学会把相关文本拉近、无关文本推远。典型训练数据包括查询和文档、问题和答案、标题和正文、相似句、翻译句、点击日志、人工标注相关对、合成指令数据和困难负样本。
最常见的训练方式是对比学习。模型同时看到一批正样本和负样本，例如“如何办理社保转移”和相关政策片段是正样本，批次里的其他片段是负样本。训练目标要求正样本向量更接近，负样本向量更远。E5 系列早期工作就强调通过大规模弱监督文本对进行对比预训练，使模型能迁移到检索、分类、聚类等任务。
正样本越贴近真实查询，模型越懂场景。普通相似句训练能学到语义相近，但未必学到“用户问题和文档答案之间的相关性”。搜索日志、问答数据、人工标注检索数据可以让模型更像搜索模型，而不只是句子相似度模型。面向 RAG 的嵌入模型，重点不是判断两句话是否同义，而是判断一个片段是否能回答问题。
负样本同样重要。简单负样本与查询毫不相关，模型很快能分开；困难负样本看起来相似但不能回答问题，更能训练模型的辨别力。例如用户问“劳动合同到期不续签是否有补偿”，困难负样本可能是“劳动合同解除补偿标准”或“试用期辞退补偿”。它们都像劳动法资料，但答案条件不同。没有困难负样本，模型在真实检索中容易把主题相近但结论不同的片段排到前面。
现代嵌入模型还会加入指令感知能力。Qwen3 Embedding、multilingual-e5-large-instruct 这类模型允许在查询侧加入任务说明，例如“为中文企业知识库检索能够回答问题的段落”。指令不是魔法，但能告诉模型当前任务是问答检索、分类、聚类、代码搜索还是跨语言匹配。同一段文本在不同任务下需要不同表示，指令感知就是让向量表达更贴近任务。
另一个重要方向是 Matryoshka Representation Learning，也就是嵌套式表示。Jina embeddings v3、Qwen3 Embedding 等模型支持把同一个向量截断成不同维度使用。高维向量质量更强但存储和计算更贵，低维向量更省资源。生产系统可以用较低维度做第一阶段大规模召回，再用高维、重排或多向量方法做精排。
中文 Embedding 为什么要单独讨论
中文检索不是英文检索的翻译版。中文没有天然空格，词边界要由分词器或子词模型推断。“苹果发布会”和“苹果怎么保存”里的“苹果”含义不同；“小鹏 P7”“理想 L9”“问界 M9”既有中文品牌又有字母数字；“开票”“抬头”“销项”“进项”“数电票”有强行业属性；“不予退款”和“可退款”只差几个字但业务含义相反。
中文还经常混合英文、数字、符号和缩写。企业知识库里会出现 API、SKU、SOP、CRM、OA、SLA、QPS、GPU、A100、RTX 4090、合同编号、发票号码、错误码、地区简称和项目代号。稠密向量可以理解语义，但对这些精确标识不一定稳定。只靠向量检索，可能把“E1001”和“E1007”混淆，把“Q4_K_M”和“Q5_K_M”看成相近表达，把“杭州社保”和“上海社保”排得过近。
中文表达还容易省略主语和上下文。用户会问“这个能报销吗”“怎么改”“有没有风险”，真实语义依赖当前页面、上一轮对话、用户部门、文档集合和业务对象。嵌入模型只能编码输入文本本身，若查询改写没有补全上下文，向量再好也难召回正确资料。
因此，中文嵌入模型选型要关注三个层面。第一，模型本身是否在中文和多语言数据上训练充足，能否处理长文本、口语、术语和中英混写。第二，系统是否保留关键词检索和元数据过滤，防止编号、时间、地区、型号被语义向量抹平。第三，评测集是否来自自己的中文业务，而不是只看英文或通用榜单。
C-MTEB 对中文文本嵌入提供了更贴近中文场景的公开基准，覆盖检索、分类、聚类、文本相似度、重排等任务。它适合做模型初筛，但不能替代业务评测。公开基准里的任务分布、文本长度、领域词汇和真实系统差异很大。一个模型在 C-MTEB 上分数高，不代表它在企业制度、客服工单、医疗病历、招投标文件、中文代码注释里都最好。
中文场景常见的模型选择包括 BGE、Qwen Embedding、Jina、多语言 E5 等。BGE-M3 的特点是同一模型支持稠密、稀疏和多向量检索，适合希望统一检索表示的系统。Qwen3 Embedding 系列提供多个尺寸，模型卡显示其支持长序列、指令感知和可变维度，适合中文和多语言高质量检索。Jina embeddings v3 强调多语言、长上下文、任务适配和嵌套维度。multilingual E5 系列成熟、易部署，指令版本在查询侧需要明确任务说明。
稠密检索：语义召回的主力
稠密检索是当前 RAG 系统最常见的第一阶段召回方式。它把查询和文档都表示成固定长度向量，例如 768、1024、2048、4096 维。文档向量提前写入向量数据库或近似最近邻索引，查询到来时实时编码，再搜索最相近的若干片段。
稠密检索擅长处理同义改写。用户问“请假会不会影响全勤”，文档写“月度考勤奖励扣减规则”，稠密向量可能把它们关联起来。用户问“怎么把客户资料导出来”，文档写“联系人列表支持批量导出”，也能被召回。对教程、问答、政策解释、客服知识、产品帮助中心、开放域搜索，稠密检索通常比纯关键词更能覆盖真实用户表达。
稠密检索的工程流程包括资料解析、结构化切分、向量编码、索引构建、查询编码、相似度搜索、候选合并、重排和引用输出。每一步都会影响质量。若 PDF 解析把页眉页脚混入正文，向量会学习到噪声；若分块太长，向量会混合多个主题；若分块太短，答案条件被拆散；若标题路径没有拼入片段，模型看不到上下位关系；若更新索引不及时，检索会返回过期内容。
切分是稠密检索最容易被低估的环节。好的切分不是固定每 500 字切一刀，而是尽量保持语义单元完整。制度按条款切，教程按小节切，FAQ 按问答对切，表格按表头和行记录切，代码按函数和类切，合同按条款和附录切。片段可以带上标题、章节、来源、日期、版本、权限、业务对象等元数据，让模型在语义之外获得结构信息。
相似度指标也要统一。很多模型默认输出需要归一化，使用余弦相似度；有些模型在训练时使用点积或内积。向量库配置、模型输出、分数阈值必须一致。把未归一化向量拿去做余弦，或把余弦分数当成可跨模型比较的绝对概率，都会导致线上阈值混乱。
稠密检索的弱点主要有四类。第一，精确符号弱，容易混淆编号、型号、版本、地名和数值。第二，可解释性弱，用户难以理解为什么相似度高。第三，领域外泛化不稳定，模型没见过的术语和短语可能表达差。第四，长文档信息压缩严重，一个单向量很难代表复杂段落里的所有细节。
解决办法不是放弃稠密检索，而是给它配上稀疏检索、元数据过滤和重排。稠密向量负责找语义相近，稀疏检索负责守住字面和标识，重排模型负责在候选集中做更细判断。
稀疏检索：关键词、术语和可解释性的底座
稀疏检索把文本表示成大量词项维度，大多数维度为零。传统 BM25 根据词频、逆文档频率和文档长度计算相关性，适合全文搜索。用户搜“Q4_K_M”“E1007”“发票抬头”“劳动合同法第四十六条”，BM25 往往比稠密向量更稳，因为它不会把精确词项过度语义化。
BM25 的优点是速度快、成本低、可解释、易增量更新。用户看到结果包含自己输入的关键词，会更容易信任。对企业内部资料，BM25 还可以结合字段权重，例如标题、标签、产品线、地区、发布时间、文档状态。很多生产搜索系统即使用了向量，也不会移除 BM25。
BM25 的缺点是表达差异。它难以理解“离职补偿”和“经济补偿金”的关系，难以处理口语化查询和正式制度之间的距离，难以跨语言匹配，也难以理解用户真正想找的是答案段落而不是包含关键词最多的段落。
SPLADE 代表另一类学习型稀疏检索。它仍然输出稀疏词项表示，可以利用倒排索引，但词项权重由神经模型学习，并可能做词项扩展。比如查询里没有出现某个同义词，模型也可能在稀疏表示里给相关词项权重。这样既保留倒排索引的优势，又获得一定语义泛化能力。
学习型稀疏检索适合希望在关键词可控和语义泛化之间折中的系统。它比纯 BM25 更懂语义，比稠密向量更容易与倒排索引结合，也更适合需要解释词项贡献的场景。但它的训练、部署和索引维护成本高于 BM25。中文环境下还要注意分词、子词、繁简体、同义词和行业词表。
稀疏检索不是旧技术。它承担的是语义向量不擅长的部分：精确匹配、可解释排序、低成本更新、长尾术语、强过滤搜索。生产级中文检索系统如果完全移除稀疏通道，常会在编号、法规、产品型号、错误码、表格字段上付出代价。
混合检索：把语义和字面合成一条召回链
混合检索的基本思路是同时跑两条或多条召回通道，再把候选结果合并。常见组合是 BM25 加稠密向量，也可以是 BM25 加 SPLADE 加稠密向量，或 BGE-M3 这种模型同时输出稠密、稀疏、多向量表示。混合检索不是为了显得复杂，而是因为真实查询类型不同。
当用户输入“VPN 连不上提示 720”，关键词和错误码很关键，BM25 可能优先命中排障文档。当用户输入“远程办公网络总是断开”，稠密检索更容易命中同一类资料。当用户输入“报销系统里发票验真失败怎么处理”，既有口语语义，又有业务术语，混合检索更稳。
结果合并有几种方式。第一种是加权分数融合，把 BM25 分数和向量相似度归一化后加权。它直观，但分数尺度很难稳定，换模型、换索引、换文档集合后阈值可能失效。第二种是排名融合，例如 Reciprocal Rank Fusion。它不直接比较原始分数，而是根据各通道排名给候选加分，适合分数不可比的情况。Elasticsearch 等搜索系统已经把 RRF 作为混合检索的重要能力。
第三种是分层召回。先用多通道各取一批候选，去重后用重排模型精排。重排模型可以逐对读取查询和候选片段，比单向量相似度更能判断“这段能不能回答问题”。在 RAG 中，这种做法很常见：第一阶段追求召回率，第二阶段追求排序质量，第三阶段生成答案并给引用。
混合检索要注意候选池大小。若每条通道只取前 5 个，正确片段可能还没进入候选池；若每条通道取前 500 个，重排成本和延迟会升高。生产系统通常根据文档规模、查询复杂度和模型成本选择候选数量，例如稠密取 50、BM25 取 50、去重后重排前 80，再给生成模型前 5 到 12 个引用片段。
混合检索还要处理去重和分块关系。同一文档的相邻片段可能被多次召回，直接塞进上下文会浪费 token。系统可以按文档、章节、片段位置合并，保留最高分片段和邻近上下文。对制度和合同，邻近条款经常包含例外条件；对教程和代码，前后片段可能包含定义和使用方式。
最重要的是，不要把混合检索当作默认胜利。某些资料库结构简单、用户查询稳定，纯稠密加重排就够；某些场景术语强、编号多，BM25 权重应更高；某些长文档问答，多向量或 late interaction 会更好。混合检索需要用业务评测调参，而不是凭感觉固定比例。
中文嵌入模型评测怎么做
公开排行榜用于初筛，不用于最终上线判断。MTEB 覆盖多种文本嵌入任务，C-MTEB 面向中文提供更直接参考，BGE、Qwen、Jina、E5 等模型也会在模型卡或论文里给出公开评测。但检索系统真正关心的是自己的用户问题、自己的资料质量、自己的答案标准。
业务评测集应从真实问题开始。可以收集客服问题、员工搜索词、产品问答、历史工单、销售咨询、研发文档查询、运营知识库提问。每条查询至少标注一个正确片段，最好标注多个可接受片段、不可接受相似片段和必要过滤条件。对于没有答案的问题，也要标注“资料库无明确依据”，防止系统强行召回相似但无关内容。
检索评测常用指标包括 Recall@K、MRR、nDCG、Precision@K。Recall@K 看前 K 个候选里是否包含正确片段，适合第一阶段召回；MRR 关注第一个正确结果的位置；nDCG 适合多级相关性，例如完全可回答、部分相关、主题相关但不能回答。RAG 系统通常优先保证 Recall@20 或 Recall@50，再通过重排提升前几名质量。
中文评测要专门设计困难样本。包括否定表达、近义政策、地区差异、时间版本、产品型号、编号错误、繁简混排、口语缩写、错别字、同名实体、表格问答、长文档跨章节问题。例如“试用期被辞退有没有赔偿”和“合同到期不续签有没有补偿”同属劳动法，但结论条件不同；“Q4_K_M”和“Q5_K_M”都像量化格式，但资源占用和质量不同。
评测时要固定整条链路，而不是只测模型。模型、分块、标题拼接、元数据、向量维度、归一化、索引参数、BM25 分词、混合权重、重排模型、候选数量都会影响结果。更换任何一个环节，都应跑回归集。否则团队会把分块问题误判为模型问题，把权限过滤问题误判为向量库问题。
评测还要看成本和延迟。8B 级嵌入模型质量可能更高，但批量索引成本、查询延迟、显存占用也更高。小模型可能分数略低，但能支撑更大并发和更频繁增量更新。生产选型不是只看最高分，而是在质量、成本、延迟、可维护性之间取得可接受平衡。
上线后还要做线上反馈。用户是否点击了引用，是否改写问题，是否点踩，是否复制答案，是否继续追问，人工客服是否采用检索结果，这些行为可以帮助发现召回漏项和排序错误。线上反馈不能直接当训练标签，但可以进入抽样复核和评测集扩充。
从零搭建中文检索链路的实操路径
第一步是整理资料源。不要一开始就向量化所有文件。先确定哪些资料是权威来源，哪些是历史记录，哪些是草稿，哪些已经过期，哪些有权限边界。每份资料要有来源、版本、更新时间、责任人、可见范围和业务标签。嵌入模型无法替团队解决资料治理问题，只会把混乱资料更快地召回。
第二步是解析和切分。PDF、Word、网页、Markdown、表格、代码、图片 OCR 的结构不同，切分策略也不同。切分时尽量保留标题路径、列表层级、表头、页码、段落编号和上下文窗口。对于“定义加例外”“条件加流程”“表格字段加说明”这类结构，不要切散。片段文本可以组合成“标题路径 + 正文 + 关键元数据”的形式再编码。
第三步是选择模型。通用中文知识库可以从 BGE-M3、Qwen3 Embedding、Jina embeddings、multilingual E5 等开始。若系统需要统一稠密和稀疏表示，可重点测试 BGE-M3。若需要强中文、多语言和长文本能力，可测试 Qwen3 Embedding 系列。若需要多语言、任务适配和可截断维度，可测试 Jina。若团队追求成熟部署和指令式查询，可测试 multilingual E5 instruct。
第四步是建立索引。向量索引要记录模型名、版本、维度、归一化方式、片段 ID、文档 ID、权限标签和更新时间。BM25 或稀疏索引要使用适合中文的分词和字段权重。两类索引都要支持增量更新、删除失效和版本回滚。文档删除后，原始文件、解析文本、片段、向量、缓存和引用结果都应同步失效。
第五步是设计查询处理。用户问题可以直接编码，也可以先做轻量改写。多轮对话中，要把“这个”“刚才那个”“怎么处理”补成完整问题；但改写不能改变用户意图。查询侧可加入任务指令，例如要求检索可回答问题的中文段落。对含编号、日期、产品型号的查询，应保留原始关键词进入稀疏通道。
第六步是召回和合并。稠密通道取语义候选，稀疏通道取关键词候选，必要时按文档类型、权限、时间、业务线过滤。合并时可以用 RRF 或业务调过的加权策略。去重后进入重排，最后选取少量片段给生成模型。每个片段都要保留引用信息，让答案能回到原文。
第七步是建立评测和监控。离线评测看召回率、排序、延迟、成本；线上监控看空召回、低置信、无引用回答、用户追问、点击引用、人工纠正和异常查询。每次换模型、换维度、换分块策略、换混合权重，都要跑相同评测集。
多向量检索和 late interaction
单向量检索把一个片段压成一个向量，速度快、索引简单、成本可控，但表达能力有限。一个片段里可能同时包含定义、条件、例外、流程和示例，单个向量要把这些信息揉在一起。查询只关心其中一个细节时，整体向量未必能准确代表它。长片段、表格、代码、法律条款和多主题段落尤其容易出现这种问题。
多向量检索的思路是让一个文档或片段拥有多个向量。ColBERT 这类 late interaction 方法会保留 token 级或子片段级表示，查询和文档之间不是只算一次整体相似度，而是在更细粒度上匹配。这样可以让“某个查询词”和“文档中的某个关键表达”建立强联系，减少单向量压缩造成的信息丢失。
BGE-M3 提到的 multi-vector 能力也属于这个方向。它把稠密、稀疏和多向量能力放在同一模型框架里，目标是同时覆盖语义召回、词项匹配和细粒度匹配。对工程团队来说，这类模型有吸引力，因为它降低了多模型维护成本，也方便在同一套评测中比较不同检索表示。
多向量的代价是索引和计算更重。同一份资料如果从一个向量变成几十个向量，存储、检索和重排成本都会上升。late interaction 还需要专门索引和推理实现，不能像普通向量库那样简单替换。它适合对召回质量要求高、文档结构复杂、查询细粒度强的场景，不一定适合所有知识库。
实践中可以先用单向量加混合检索建立基线，再在失败样本上判断是否需要多向量。如果主要问题是术语、编号和精确匹配，优先增强 BM25、SPLADE 或字段过滤；如果主要问题是长片段内部细节被淹没，或同一段里多个语义互相干扰，多向量才更值得投入。
查询改写、扩展和路由
用户问题进入检索系统前，常需要轻量处理。多轮对话中，“这个怎么处理”必须还原成明确问题；企业系统里，“这份合同有没有风险”要结合当前文档对象；搜索入口里，“报错 500”要保留错误码，同时补充产品和页面上下文。查询处理的目标不是让模型自由发挥，而是把用户意图表达完整。
查询改写最容易犯的错，是把用户问题改得太漂亮。检索需要保留原始关键词、数字、专名、否定词和约束条件。如果用户问“杭州社保断缴一个月影响买房吗”，改写成“社保缴纳对购房资格的影响”会损失地区和时间粒度。一个稳妥做法是同时使用原始查询和改写查询：原始查询进入 BM25 和精确过滤，改写查询进入稠密检索。
查询扩展适合补同义词和行业词。例如“开票信息”可以扩展“发票抬头、税号、纳税人识别号”，“离职赔偿”可以扩展“经济补偿金、解除劳动合同补偿”。扩展词不应无限增加，否则会把召回范围拉得太宽。最好把扩展词作为辅助通道，而不是替换用户原始查询。
查询路由决定走哪条检索链。短编号、错误码、型号查询可以提高稀疏权重；口语问答提高稠密权重；法律、制度和合同查询增加版本过滤和重排；表格查询转向结构化索引；代码查询走代码索引和路径过滤。路由可以先用规则和轻量分类器实现，再用评测数据校准。路由的价值在于让不同查询得到合适检索方式，而不是所有问题都套同一套参数。
还有一种做法是多查询召回。系统把用户问题拆成几个子查询，例如“退款条件”“退款流程”“不支持退款的例外”，分别召回候选，再合并重排。这对复杂问题有用，但也会增加噪声。多查询适合资料充分、重排能力强的系统，不适合没有评测和去重能力的早期知识库。
索引更新和版本治理
检索系统上线后，资料会不断变化。产品文档更新，制度版本替换，客服话术调整，代码仓库提交，表格数据刷新。如果索引无法及时反映这些变化，嵌入模型再好也会召回旧内容。很多知识库事故不是模型理解错，而是索引里还躺着旧版本。
索引更新要记录版本。每个片段应该知道自己来自哪份文档、哪个版本、哪次解析、哪个模型、哪个索引批次。文档修改后，旧片段不能简单留在索引里继续参与召回。若需要保留历史版本，也必须通过文档状态和时间过滤控制可见范围。用户问当前制度时，只应召回当前有效版本；用户问历史记录时，才允许检索旧版本。
删除和权限变化比新增更难。新增文档只要解析、切分、编码、写索引；删除文档要删除原文、片段、向量、全文索引、摘要、缓存和派生引用。权限从公开改成私密时，召回结果必须立即变化。生产系统应把文档状态和权限作为检索过滤条件，而不是只在生成答案前检查。
模型升级也会引入版本问题。不同嵌入模型的向量空间不可直接混用。用 BGE 生成的向量不能和用 Qwen 生成的向量放在同一向量字段里比较。升级模型时要么新建索引全量重建，要么做双索引灰度：新请求同时查新旧索引，评测和线上观察稳定后再切换。混合索引会让分数和排序不可解释。
维度截断也要治理。支持 Matryoshka 的模型可以用不同维度，但维度变化会改变分数分布和召回效果。若从 1024 维切到 256 维，必须重建索引并重新校准阈值。不能只改查询侧维度，让查询向量和文档向量不一致。
索引治理的最终目标，是让每一次回答都可追溯。用户看到引用后，系统能说明它来自哪个文档、哪个版本、哪个片段、由哪个模型编码、何时进入索引、当前是否有效。没有这些信息，质量问题只能靠猜。
一个最小可行实验
学习嵌入模型时，可以做一个小实验。准备一批中文资料，例如公司制度、产品帮助文档或公开技术文章，数量不必大，几十篇即可。手工整理二三十个真实问题，每个问题标注应该命中的片段。这个小集合比网上随便找 benchmark 更能帮助理解检索链路。
先做 BM25 基线。观察哪些问题能被关键词直接命中，哪些因为表达不同漏掉。再做稠密向量基线，选择一个中文或多语言嵌入模型，把每个片段编码后检索。比较两者结果，会很直观地看到稠密向量擅长语义改写，BM25 擅长精确词项。
然后做混合检索。可以先用简单的排名融合，不急着调复杂权重。记录每个问题前 5、前 10、前 20 是否包含正确片段。若正确片段在前 20 但不在前 5，说明召回基本有了，排序需要重排；若前 20 都没有，说明分块、模型或检索通道存在根本问题。
接着加入困难样本。把“可以退款”改成“不能退款”，把“北京”改成“杭州”，把“版本 2.1”改成“版本 2.0”，把“离职补偿”改成“试用期辞退”，把“E1001”改成“E1007”。这些样本能快速暴露模型是否混淆相近概念。真实业务的检索质量，往往取决于这些边界样本，而不是简单问题。
最后记录失败原因。失败不要只写“没召回”，要归类为解析错误、分块错误、模型语义错误、关键词缺失、权限过滤、版本错误、重排错误、查询改写错误。分类之后，团队才能知道该换模型、改分块、加词表、调混合权重，还是修数据治理。
典型场景中的模型和检索策略
企业制度知识库适合混合检索。制度文档里有大量条款编号、适用范围、时间版本和例外条件。稠密检索能处理用户口语提问，BM25 能守住关键词和条款，重排模型能判断片段是否能直接回答。答案必须带引用，且只使用当前有效版本。
客服帮助中心适合稠密检索加重排。用户表达变化大，常用口语、错别字和模糊描述。系统可以先通过稠密向量找相关 FAQ，再用 BM25 捕捉产品型号、错误码和订单状态。若答案涉及退款、赔付、账号封禁等风险动作，应要求人工确认或跳转流程。
电商搜索适合多通道检索。商品标题、品牌、型号、属性、价格、库存、评价都影响排序。稠密向量能理解“适合露营的小炉子”“通勤用轻薄电脑包”，BM25 能匹配品牌和型号，结构化过滤处理价格、地区、库存和品类。最终排序还会叠加点击、转化、利润、时效等业务信号。
代码检索适合专门模型和结构切分。用户可能用自然语言搜索函数，也可能用错误信息搜索实现。代码片段应按文件、类、函数、注释和调用关系组织。稠密模型要能理解代码语义，BM25 要保留函数名、变量名、错误码和路径。跨仓库权限必须在检索前过滤。
学术和法律资料适合高召回加严格引用。用户经常需要事实、出处、版本和限定条件。稠密检索能找到主题相关文献，稀疏检索能定位术语和法条，重排模型能筛掉主题相近但结论不匹配的片段。生成阶段不能把相似资料混成确定结论。
模型选型的务实标准
选择嵌入模型时，第一看语言和领域。中文资料占主导，就优先测试中文和多语言表现强的模型；跨境业务需要中英日等多语言，就测试跨语言检索；代码资料多，就加入代码查询样本；表格和数字多，就评估结构化处理和稀疏配合。模型说明页的通用能力只能决定候选名单，不能决定最终上线。
第二看上下文长度。模型支持长输入，不代表长片段检索一定更好。长输入可以让片段保留更多上下文，但也可能让多个主题混在一起。短片段更精确，却容易丢失条件。选型时要同时测试不同分块长度，而不是只换模型。
第三看部署成本。大模型向量质量通常更强，但索引成本、查询延迟和显存占用更高。文档量很大、更新频繁、查询并发高的系统，可能需要小模型或降维。对高价值低并发的研究助手，可以接受更大模型和重排成本。模型好坏必须放在成本结构里看。
第四看生态和可维护性。模型是否有稳定模型卡，是否说明输入格式、维度、归一化、指令模板、最大长度、许可证和评测结果；推理框架是否支持批量编码；向量库是否能承载维度和数据规模；团队能否重建索引和回滚。生产选型不只选分数，也选维护确定性。
第五看与重排模型的组合。有些嵌入模型第一阶段召回已经很好，重排收益有限；有些模型前 50 召回不错但前 5 排序一般，配重排会明显提升。若系统必须给大模型少量引用片段，重排几乎是必要环节。嵌入模型和重排模型应一起评测，而不是分开看榜单。
常见误区
误区一是把嵌入模型当成答案模型。嵌入模型只负责表示和召回，不负责判断最终答案是否成立。它能把候选资料排到前面，但不能保证资料正确、最新、完整、有权限。
误区二是只看排行榜。公开基准能帮助排除明显落后的模型，却不能代表你的资料、查询和业务风险。中文系统尤其需要自己的金集，覆盖真实用户问题、术语、否定、编号和版本差异。
误区三是只用稠密向量。很多中文知识库一开始觉得语义检索很先进，移除了关键词搜索，后来在错误码、产品型号、政策条款上频繁漏召回。稠密和稀疏不是谁替代谁，而是分工。
误区四是忽视分块。模型再强，也很难从被切碎或混杂的片段中恢复原始结构。分块质量往往比换一个相近分数的模型更重要。
误区五是把相似度阈值当成通用规则。不同模型、不同维度、不同归一化方式、不同文档集合的分数分布都不同。阈值必须用业务评测校准，不能从别的项目照搬。
误区六是先召回再做权限过滤。无权限片段进入候选、重排或模型上下文，本身就已经越界。权限过滤应发生在检索前或检索过程中，并贯穿稠密、稀疏、缓存和引用。
误区七是没有回归测试。知识库上线后资料每天变化，模型和索引也可能升级。没有固定评测集，团队只能靠用户投诉发现检索退化。
上线检查清单
- 是否明确了资料来源、责任人、版本、权限和更新频率。
- 是否按文档结构切分，而不是只按固定长度切分。
- 是否记录模型名、版本、维度、归一化方式和索引构建时间。
- 是否同时测试稠密、稀疏和混合召回。
- 是否为中文术语、编号、型号、否定句、地区和时间版本建立困难样本。
- 是否使用 Recall@K、MRR、nDCG 等指标评估召回和排序。
- 是否在检索前执行租户、组织、项目、密级和文档状态过滤。
- 是否保留引用信息，让用户能回到原文。
- 是否对换模型、换分块、换索引参数建立回归流程。
- 是否监控空召回、低质量召回、用户追问、引用点击和人工纠正。
学习路线建议
初学者可以先理解三个概念：向量表示、相似度搜索、分块。只要能把一批中文文档切成片段，选择一个嵌入模型编码，使用向量库检索，再观察正确片段是否出现在前几名，就已经掌握了嵌入模型的基本用法。
进入工程实践后，要学习稠密检索、BM25、SPLADE、RRF、重排模型、元数据过滤和评测指标。不要急着追模型榜单，先把自己的评测集做出来。没有评测集，任何模型选型都是凭印象。
面向生产系统时，要把检索当成完整链路：资料治理、权限、解析、切分、索引、召回、合并、重排、引用、生成、反馈、回归。嵌入模型是关键部件，但不是全部。真正稳定的中文 RAG 系统，靠的是模型能力和工程治理一起工作。
写作日期：2026-05-22
参考资料
- BGE-M3 官方文档：https://bge-model.com/bge/bge_m3.html
- BGE-M3 论文：https://arxiv.org/abs/2402.03216
- Qwen3 Embedding 8B 模型卡：https://huggingface.co/Qwen/Qwen3-Embedding-8B
- Qwen3 Embedding 论文：https://arxiv.org/abs/2506.05176
- Jina embeddings v3 模型卡：https://huggingface.co/jinaai/jina-embeddings-v3
- Jina embeddings v3 论文：https://arxiv.org/abs/2409.10173
- multilingual-e5-large-instruct 模型卡：https://huggingface.co/intfloat/multilingual-e5-large-instruct
- E5 论文：https://arxiv.org/abs/2212.03533
- MTEB 官方组织与榜单入口：https://huggingface.co/mteb
- MTEB 论文：https://arxiv.org/abs/2210.07316
- C-MTEB / C-Pack 论文：https://arxiv.org/abs/2309.07597
- SPLADE 论文：https://arxiv.org/abs/2107.05720
- SPLADE 官方代码库：https://github.com/naver/splade
- Elasticsearch RRF 文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html