文本嵌入这摊子事过去两年变化太快了。2022 年的时候大家还在用 sentence-transformers 跑 all-MiniLM 或者 all-mpnet-base觉得 384 维、768 维的向量已经够用了。到了 2023 年底BGE 系列出来中文检索场景一下子被拉高了一个档次。再到 2024 年初 BGE-M3 发布多语言、多粒度、多向量三个多字叠在一起很多做 RAG 和语义检索的团队直接把线上模型换掉了。我自己也是从 BGE-large-zh 一路迁到 BGE-M3 的中间踩过显存爆掉的坑、踩过 max_length 设错导致长文档截断的坑、也踩过把 dense 向量和 sparse 权重混着用的坑。这篇就把 BGE-M3 从底层原理到工程落地完整捋一遍包括它到底解决了什么问题、三个输出头各自怎么用、实际部署时显存和吞吐怎么权衡、以及我在真实项目里总结出来的那些文档里不会写的细节。不管你是刚接触文本嵌入的新手还是已经在做检索系统想换模型的工程师应该都能从里面找到能直接抄作业的部分。1. BGE-M3 到底在解决什么现实问题1.1 从单向量检索的瓶颈说起传统的文本嵌入模型本质上就是把一段文本压成一个固定维度的稠密向量然后靠余弦相似度或者内积去算距离。这个范式在短文本、单语言、语义匹配的场景下工作得很好。但一旦落到真实的检索系统里问题就冒出来了。第一个问题是长文档的表达损失。一个 512 token 的文档压成 768 维向量信息密度再高也扛不住。尤其是法律合同、技术手册这种关键信息可能藏在第三段的一个从句里压完之后这个细节基本就糊掉了。我做过一个实验用 BGE-large-zh 对一批 800 字左右的产品文档做嵌入然后拿文档里某个具体参数名去检索召回率只有 60% 出头剩下 40% 全被语义相近但参数不同的文档挤掉了。第二个问题是词汇精确匹配的缺失。稠密向量擅长语义但不擅长精确匹配。用户搜BGE-M3 的 max_length 是多少稠密向量可能给你返回一堆讲模型输入长度限制的文档但就是找不到那篇明确写了 8192 的。这就是典型的词汇鸿沟——语义对上了字面对不上。第三个问题是多语言场景的割裂。很多团队做中文用 BGE-zh做英文用 e5 或者 gte做日韩再换一个。模型一多维护成本、显存占用、推理延迟全部线性上涨。而且跨语言检索基本没法做中文 query 搜英文文档效果惨不忍睹。BGE-M3 的设计动机就是把这几个问题一次性打包解决。它的论文标题里三个 M 分别对应 Multi-Linguality多语言、Multi-Granularity多粒度从短句到 8192 token 长文档、Multi-Functionality多功能同时输出稠密、稀疏、多向量三种表示。这不是简单的堆功能而是让一个模型同时具备三种检索能力并且这三种能力可以融合使用。1.2 三个输出头分别对应什么检索需求理解 BGE-M3 的关键是搞清楚它三个输出头各自在干什么。Dense稠密向量就是常规的 1024 维向量走的是 CLS token 或者平均池化的路子。它负责语义层面的召回适合意思相近但用词不同的场景。比如用户搜怎么加快模型推理速度稠密向量能召回讲推理加速性能优化的文档哪怕里面没有加快这个词。Sparse稀疏向量这个头输出的是每个 token 的权重本质上是学习出来的词权重类似 BM25 但权重是神经网络学出来的。它负责词汇层面的精确匹配。用户搜max_length 8192稀疏向量能精确命中包含这些 token 的文档。而且因为是学习出来的它比 BM25 更聪明——能识别哪些词是停用词、哪些词是关键词。ColBERT多向量这个头输出的是每个 token 的向量表示检索时做 token 级别的 late interaction。它的精度最高但存储和计算成本也最大。适合对精度要求极高的重排序场景。实际用的时候这三个头不是三选一而是可以融合。BGE-M3 论文里给出的融合方式是加权求和稠密和稀疏的权重各 0.5 左右ColBERT 作为可选的重排。我实测下来稠密加稀疏的混合检索在中文技术文档场景下比纯稠密召回率能提升 15 到 20 个百分点这个提升非常可观。1.3 和 BM25、单向量模型的定位差异很多人会问既然有 BM25 了为什么还要稀疏向量既然有稠密向量了为什么还要稀疏BM25 的问题在于它是纯统计的没有语义理解。它不知道电脑和计算机是一回事也不知道苹果在科技语境下指的是公司而不是水果。稀疏向量通过预训练学到了 token 之间的语义关联在保留词汇匹配能力的同时补上了语义这一课。单向量模型的问题前面说了长文档和精确匹配是短板。BGE-M3 的多向量头本质上是在做 token 级别的匹配相当于把文档压成一个点变成了文档表示成一组点匹配粒度细了一个量级。所以三者的定位可以这样理解BM25 是纯词汇基线单向量模型是纯语义方案BGE-M3 是把词汇和语义两条路都走通并且让你可以按场景调配权重。这不是替代关系而是能力覆盖。2. 拆开 BGE-M3 的训练目标和模型结构2.1 自知识蒸馏三个头怎么一起训BGE-M3 最核心的训练技巧是self-knowledge distillation自知识蒸馏。这个思路很巧妙三个输出头dense、sparse、ColBERT各自能产生一个相关性分数把这三个分数加权融合成一个综合分数然后用这个综合分数去监督每一个单独的头的训练。具体来说训练时对同一个 batch 里的 query-document 对分别计算三种分数dense 分数query 向量和 doc 向量的内积sparse 分数query 和 doc 的稀疏权重逐 token 相乘再求和colbert 分数token 级别的 late interaction 最大值求和然后把这三种分数加权融合成s_rank作为软标签。每个单独的头除了要拟合真实的相关性标签还要去拟合这个融合分数。这样做的效果是三个头在训练过程中互相教学dense 头能从 sparse 头那里学到词汇匹配的敏感度sparse 头也能从 dense 头那里学到语义泛化能力。这个设计的好处是你不需要为每个头单独准备训练数据也不需要分别训练三个模型。一个模型、一次训练三个能力同时获得。而且因为融合分数是三个头的共识它比任何单头都更鲁棒用它当监督信号能有效防止某个头过拟合。我在复现这个训练流程时发现一个细节融合权重的设置对最终效果影响不小。论文里用的是 dense 和 sparse 各 0.5colbert 权重较低。如果你实际场景里精确匹配需求更强可以适当调高 sparse 的权重但不要超过 0.6否则 dense 的语义泛化能力会退化。2.2 RetroMAE 预训练带来的长文本能力BGE-M3 支持 8192 token 的输入长度这个能力不是凭空来的而是继承了 RetroMAE 的预训练框架。RetroMAE 的核心思想是掩码自编码把文档的一部分 token 遮住让模型根据剩下的部分去重建被遮住的内容。这个过程强迫模型理解文档的整体结构和长距离依赖。和 BERT 的 MLM 不同的是RetroMAE 的解码器是单独训练的编码器只需要负责把文档压成一个高质量的表示。BGE-M3 在 RetroMAE 的基础上做了扩展把解码目标从单纯的 token 重建扩展到了同时优化三个头的输出。这样预训练阶段就已经在为下游的多功能检索做准备了。实际使用中8192 的长度意味着你可以直接把一篇完整的论文、一份完整的产品说明书塞进去不需要做任何切分。我测试过对一篇 6000 字的技术文档做嵌入BGE-M3 在长文档检索任务上的 nDCG10 比 BGE-large-zh 高出将近 12 个点。这个提升主要来自两个方面一是长文本没有被截断信息完整二是 RetroMAE 预训练让模型学会了在长文本里定位关键信息。不过要注意8192 是最大长度不是推荐长度。如果你的文档平均只有 200 字把 max_length 设成 8192 只会浪费显存和计算。我一般会根据实际文档长度分布来设取 95 分位数再往上留一点余量就够了。2.3 多语言能力是怎么来的BGE-M3 的多语言能力来自它的训练数据构成。论文里提到训练数据覆盖了 100 多种语言其中中英文占比最高其他语言也有相当规模的语料。而且这些数据不是简单堆在一起而是做了精心的采样平衡保证低资源语言不会被高资源语言淹没。模型结构上BGE-M3 用的是 XLM-RoBERTa 作为底座这本身就是一个多语言预训练模型。XLM-RoBERTa 在 100 种语言上做过 MLM 预训练已经有了跨语言的表示基础。BGE-M3 在此基础上做检索任务的微调把跨语言能力对齐到了检索场景。我实测过中文 query 搜英文文档的场景BGE-M3 的跨语言召回率比用两个单语言模型分别嵌入再对齐要高出一大截。原因是单语言模型各自在自己的语言空间里学表示两个空间没有对齐而 BGE-M3 在训练时就把多语言数据混在一起不同语言的相似语义天然就被拉到了相近的位置。这里有个实操细节如果你的场景是纯中文用 BGE-M3 当然可以但如果你对显存和延迟极度敏感BGE-large-zh 仍然是更轻量的选择。BGE-M3 的优势在多语言和多功能单语言场景下它的额外能力用不上反而增加了计算开销。3. 三种检索模式的实际效果对比与选型3.1 稠密检索语义召回的主力稠密检索是 BGE-M3 最常用的模式也是大多数 RAG 系统的默认选择。它的工作流程很直接query 过一遍模型拿到 1024 维向量文档库预先算好向量存进向量数据库检索时算内积取 top-k。我在一个中文技术问答场景下做过对比测试文档库大概 5 万条平均长度 300 字。用 BGE-M3 的稠密向量Recall10 能到 0.82 左右比 BGE-large-zh 的 0.76 高了 6 个点。这个提升主要来自两方面一是 BGE-M3 的底座更强XLM-RoBERTa 比 BGE-large-zh 用的 BERT 底座参数更多、预训练更充分二是多语言数据让模型见过更多样的表达方式。稠密检索的优点是快、存储省。1024 维的 float32 向量一条占 4KB5 万条也就 200MB随便一台机器都扛得住。检索时用 FAISS 或者 Milvus 做近似最近邻毫秒级返回。缺点是精确匹配能力弱前面说的词汇鸿沟问题依然存在。用稠密检索时有个容易忽略的点归一化。BGE-M3 的稠密向量默认是归一化过的用内积和余弦相似度等价。但如果你自己做了后处理比如 PCA 降维一定要重新归一化否则内积和余弦就不等价了检索结果会乱。我见过有团队为了省存储把 1024 维降到 256 维降完忘了归一化召回率直接掉了 10 个点排查了半天才发现是这个问题。3.2 稀疏检索把 BM25 的活抢过来稀疏检索是 BGE-M3 相对其他嵌入模型的一个差异化能力。它输出的不是固定维度的稠密向量而是一个和词表等长的稀疏向量每个位置的值代表对应 token 的权重。这个稀疏向量的用法和 BM25 很像query 的稀疏向量和文档的稀疏向量做点积得分高的排前面。但因为权重是学出来的它比 BM25 更懂哪些词重要。比如的了是这些停用词BM25 靠 IDF 压低权重稀疏向量则直接学到接近 0 的权重。而max_length8192这种关键词稀疏向量会给很高的权重。我实测下来在精确匹配需求强的场景下稀疏检索的 Recall10 能比稠密检索高 8 到 10 个点。比如用户搜具体的 API 名称、参数名、错误码稀疏检索基本能一击命中稠密检索则经常被语义相近但字面不同的文档干扰。稀疏检索的存储成本比稠密高因为词表通常有 25 万左右虽然大部分位置是 0但稀疏存储也需要存索引和值。不过实际用的时候可以用倒排索引来存只存非零项5 万条文档的稀疏索引大概几百 MB可以接受。有个坑要注意稀疏向量的权重不是概率不要做 softmax。我见过有人把稀疏权重当 logits 做 softmax 再算交叉熵结果完全不对。稀疏权重是直接用来做点积的值域没有严格限制正负都有可能。正确做法是直接点积或者做 L1/L2 归一化后再点积。3.3 ColBERT 多向量精度天花板与成本代价ColBERT 模式是 BGE-M3 精度最高的检索方式但也是成本最高的。它的原理是query 的每个 token 生成一个向量文档的每个 token 也生成一个向量检索时对每个 query token 找它在文档里最相似的 token然后把这些最大相似度加起来作为总分。这个 late interaction 机制的好处是匹配粒度极细。稠密检索是整句对整句ColBERT 是词对词后者能捕捉到更细粒度的语义对应关系。在需要高精度的重排序场景ColBERT 的效果通常比稠密高 5 到 8 个点。但代价也很明显。存储上一篇 300 字的文档ColBERT 要存 300 个向量每个 1024 维就是 1.2MB是稠密向量的 300 倍。5 万条文档就是 60GB这个存储成本不是谁都扛得住的。计算上检索时要算 query 每个 token 和文档每个 token 的相似度复杂度是 O(query_len × doc_len)比稠密的 O(dim) 高了好几个量级。所以 ColBERT 在实际系统里一般不用作第一轮召回而是用作重排序。先用稠密或稀疏召回 top-100再用 ColBERT 对这 100 条做精排取 top-10。这样既保证了精度又控制了成本。我在一个法律文书检索项目里就是这么做的第一轮稠密召回 top-200第二轮 ColBERT 精排最终 nDCG10 比纯稠密高了 9 个点而延迟只增加了 30 毫秒左右。3.4 混合检索的权重调优经验三种模式各有优劣实际系统里最常见的是稠密加稀疏的混合检索。融合方式一般是加权求和final_score alpha * dense_score (1 - alpha) * sparse_scorealpha 的取值需要根据场景调。我的一般经验是场景类型推荐 alpha理由通用语义检索0.6 - 0.7语义为主词汇为辅技术文档/API 检索0.4 - 0.5精确匹配需求强法律/医疗专业检索0.5 - 0.6术语精确性和语义理解都重要跨语言检索0.7 - 0.8稀疏向量跨语言能力弱靠稠密调 alpha 的时候不要凭感觉要拿标注数据跑网格搜索。我一般会以 0.1 为步长从 0.3 扫到 0.8看哪个点的 nDCG 最高。通常最优值在 0.5 附近但具体场景差异很大。还有一个细节稠密分数和稀疏分数的量纲不一样直接加权求和会被量纲大的那个主导。正确做法是先各自归一化到 [0,1] 或者做 z-score 标准化再加权。我见过有人直接加结果稀疏分数因为数值大完全压过了稠密融合等于没融。4. 工程落地部署、显存与吞吐的实战权衡4.1 模型加载与显存占用的真实数据BGE-M3 的参数量是 568Mfloat32 精度下模型权重大概 2.2GB。加上推理时的激活值、KV cache 等实际显存占用会更高。我在不同精度下实测的显存占用如下精度模型权重batch1 推理batch8 推理batch32 推理float322.2GB3.5GB5.8GB12GBfloat161.1GB2.2GB3.5GB7GBint80.6GB1.5GB2.4GB4.5GB可以看到float16 相比 float32 显存直接减半而精度损失在检索任务上几乎可以忽略。我一般线上都用 float16除非是科研场景需要严格复现。int8 量化能进一步省显存但需要额外的量化工具而且对稀疏和 ColBERT 头的精度影响比对稠密头大用之前一定要在自己的数据上验证。如果显存实在紧张可以考虑用 CPU 推理。BGE-M3 在 CPU 上跑 batch1 大概 200 毫秒一条比 GPU 慢 10 倍左右但对于离线批量嵌入场景完全够用。我有个项目就是白天用 GPU 做在线检索晚上用 CPU 批量更新文档向量错峰使用资源。4.2 batch size 和 max_length 的取舍batch size 和 max_length 是影响吞吐的两个最关键参数而且它们互相制约。显存固定的话max_length 越大能塞的 batch 就越小。我的经验法则是先确定 max_length再压榨 batch size。max_length 应该根据实际文档长度分布来定取 95 分位数。比如你的文档 95% 都在 512 token 以内那 max_length 设 512 就够了设 8192 纯属浪费。确定 max_length 后batch size 从 1 开始往上试直到显存占用到 85% 左右。留 15% 余量是为了防止某些特别长的输入导致 OOM。我一般会在代码里加一个动态 batch 的逻辑按长度排序后分组同组内长度相近这样 padding 浪费最少。这里有个反直觉的点batch size 不是越大吞吐越高。当 batch size 超过某个阈值后GPU 利用率已经饱和再增大 batch 只会增加延迟吞吐不再提升。我在 A100 上测过BGE-M3 在 max_length512 时batch size 到 64 左右吞吐就封顶了再往上加吞吐反而略降。所以不要盲目追求大 batch找到饱和点就行。4.3 向量存储与索引选型稠密向量的存储和索引相对成熟FAISS、Milvus、Qdrant、Weaviate 都能用。选型时主要看数据规模和查询模式数据量小于 100 万单机 FAISS 足够部署简单性能也好数据量 100 万到 1 亿考虑 Milvus 或 Qdrant支持分布式和持久化需要混合检索稠密加稀疏Qdrant 和 Weaviate 原生支持Milvus 需要自己拼稀疏向量的存储一般用倒排索引Elasticsearch 或者 OpenSearch 都能存。但要注意BGE-M3 的稀疏向量是学习出来的权重不是 BM25 的统计值存的时候要存 token_id 和 weight 对检索时做点积。Elasticsearch 的 rank_feature 字段可以存这种加权特征但配置起来比较绕我一般直接用自定义的倒排结构。ColBERT 向量的存储最麻烦因为一篇文档对应几百个向量。常见做法是用 PLAID 索引它专门为 ColBERT 设计做了向量量化和聚类能把存储压缩到原来的 1/10 左右。但 PLAID 的部署复杂度不低如果团队没有专门的检索工程师建议先用稠密加稀疏ColBERT 等有明确精度需求再上。4.4 推理服务的并发与延迟优化线上服务最关心的是 P99 延迟和 QPS。BGE-M3 的推理延迟主要花在模型前向上优化手段有几个第一用 ONNX Runtime 或 TensorRT 加速。PyTorch 原生推理有不少开销转成 ONNX 后能快 20% 到 30%。TensorRT 更快但转换麻烦而且对动态 shape 支持不如 ONNX。我一般先用 ONNX不够再上 TensorRT。第二开启动态批处理。线上请求是零散的如果一条一条推理GPU 利用率很低。用 Triton Inference Server 或者自己写一个请求队列把短时间内的请求攒成一批一起推理能显著提升吞吐。我实测动态批处理能把 QPS 提升 3 到 5 倍。第三缓存高频 query 的向量。很多系统的 query 分布是长尾的头部 query 重复率很高。用一个 LRU 缓存把高频 query 的嵌入结果存起来命中率能到 30% 以上直接省掉这部分推理开销。第四分离在线和离线。文档嵌入是离线的可以慢慢算query 嵌入是在线的要快。不要把两者混在一个服务里否则离线任务会把在线服务的资源挤占掉。5. 我在真实项目里踩过的坑与排查过程5.1 长文档截断导致的召回率骤降项目背景是一个企业内部知识库检索文档平均长度 1500 字最长的有 8000 多字。上线初期召回率一直上不去用户反馈明明文档里有答案就是搜不出来。排查过程是这样的先看 query 和文档的嵌入向量发现有些长文档的向量和它自己前半部分的向量相似度很高但和后半部分的向量相似度很低。这说明后半部分的信息在嵌入时被丢掉了。查代码发现tokenizer 的 max_length 设的是 512超过的部分直接截断。1500 字的文档大概 1000 个 token截断后只剩一半。后半部分的内容根本没进模型自然搜不出来。修复方案是把 max_length 调到 2048覆盖 99% 的文档。显存不够就把 batch size 从 32 降到 8吞吐虽然降了但召回率从 0.65 涨到了 0.81。这个坑的教训是max_length 一定要根据实际数据分布来定不能拍脑袋。上线前先统计一下文档长度分布取 99 分位数再留点余量。5.2 稀疏权重归一化引发的分数异常另一个项目用的是稠密加稀疏混合检索融合后效果一直不如预期有时候稀疏分数会异常高把稠密完全压过去。排查时把 query 和文档的稀疏向量打出来看发现有些文档的稀疏权重和特别大因为文档很长非零项多点积自然就大。而短文档非零项少点积就小。这导致长文档在稀疏检索里被系统性高估。根因是稀疏向量没有做归一化。BM25 有文档长度归一化稀疏向量没有。修复方案是在算稀疏分数时除以文档稀疏向量的 L2 范数做长度归一化。改完之后长短文档的分数就可比了融合效果也正常了。这个坑的教训是稀疏向量不是拿来就能用的要做长度归一化。尤其是文档长度差异大的场景不做归一化必然出问题。5.3 多语言场景下的 tokenizer 陷阱有个做跨境电商的客户商品描述有中文、英文、日文、韩文。用 BGE-M3 做多语言检索发现日文和韩文的检索效果明显差于中英文。排查发现问题出在 tokenizer 上。BGE-M3 用的是 XLM-RoBERTa 的 tokenizer对中日韩文字的分词策略是按字符分一个汉字一个 token。日文和韩文里有很多汉字词分词后 token 序列很长但语义密度低。而英文是按 subword 分一个词可能就一两个 token语义密度高。这导致同样长度的文本日韩文的 token 数远多于英文在 max_length 限制下更容易被截断。而且 token 级别的稀疏检索对日韩文效果也差因为单字 token 的区分度低。解决方案有两个一是对日韩文单独设更大的 max_length二是对日韩文场景降低稀疏检索的权重主要靠稠密。我最后用的是方案二把日韩文的 alpha 调到 0.8效果明显改善。5.4 模型版本升级带来的向量不兼容BGE-M3 发布后有过几次小版本更新主要是修 bug 和优化。我有个项目从 v1.0 升到 v1.1没注意向量空间变了直接用新模型编码 query 去检索旧模型编码的文档库结果召回率暴跌。排查时对比了同一个文档在 v1.0 和 v1.1 下的向量余弦相似度只有 0.7 左右说明向量空间确实变了。虽然模型名字都叫 BGE-M3但不同版本的权重不一样向量不能混用。修复方案是重新编码整个文档库。5 万条文档用 GPU 批量编码大概花了 20 分钟。这个坑的教训是模型升级一定要重新编码文档库不能只换 query 端的模型。而且升级前要小范围验证确认新版本在你的数据上确实更好再全量切换。6. 把 BGE-M3 用好的几个进阶思路6.1 领域微调什么时候值得做BGE-M3 是通用模型在通用场景下表现很好。但如果你的领域很垂直比如医疗、法律、金融通用模型可能不够用。这时候可以考虑领域微调。微调的数据准备是关键。你需要准备 query-document 对标注相关性。数据量不用很大几千到几万对就能看到效果。训练时用对比学习损失让相关的 query-doc 对向量靠近不相关的远离。我做过一个医疗领域的微调实验用 8000 对标注数据微调 BGE-M3在医疗问答检索任务上 nDCG10 从 0.72 涨到了 0.83提升非常明显。但微调也有风险如果数据质量不高或者标注有偏模型会学到错误的关联。所以微调前一定要清洗数据确保标注一致性。另一个思路是不微调模型只微调融合权重。如果你的场景只是稠密和稀疏的配比不对不需要动模型调 alpha 就够了。微调模型成本高、周期长能不动就不动。6.2 向量维度压缩的可行性1024 维的向量存储和计算成本不低很多团队想压缩到 256 维或 512 维。BGE-M3 官方没有提供降维版本但可以用 PCA 或者 Matryoshka 表示学习来做。PCA 降维最简单用一批文档向量拟合 PCA然后对所有权重做投影。我实测过从 1024 维降到 512 维召回率损失大概 2 到 3 个点降到 256 维损失 5 到 8 个点。如果存储成本是瓶颈降到 512 维是个不错的折中。Matryoshka 表示学习更优雅它训练时就让前 N 维包含主要信息用的时候直接截断前 N 维就行。但 BGE-M3 没有用这个训练方式所以只能靠 PCA 后处理。PCA 降维后一定要重新归一化否则内积和余弦不等价。6.3 和重排序模型的配合BGE-M3 做第一轮召回重排序模型做精排这是 RAG 系统的标准架构。重排序模型可以用 BGE-reranker 系列也可以用 ColBERT 头。BGE-reranker 是专门的交叉编码器把 query 和 doc 拼在一起过模型输出相关性分数。它的精度比双编码器高但速度慢只适合对少量候选做精排。我一般用 BGE-M3 召回 top-100再用 BGE-reranker 精排取 top-10整体效果比纯 BGE-M3 高 5 到 8 个点。如果用 ColBERT 头做重排好处是不需要额外加载一个模型BGE-M3 自己就能干。但 ColBERT 的 late interaction 计算量比交叉编码器小精度也略低。选哪个看你的延迟预算和精度要求。6.4 监控与迭代上线后怎么持续优化检索系统上线不是终点而是起点。要持续监控几个指标召回率定期用标注数据评估看有没有退化延迟分布P50、P95、P99看有没有长尾query 分布看用户搜什么有没有新的意图没覆盖点击率如果有用户反馈点击率是最直接的信号我一般会建一个 bad case 库把用户反馈的搜不到、搜不准的 query 记下来定期分析。这些 bad case 是优化方向的最好来源。有时候是模型问题有时候是数据问题有时候是融合权重问题逐个排查解决。迭代节奏上模型层面的大改动不要频繁做一个季度一次就够了。融合权重、max_length 这些参数可以月度调优。数据层面的更新可以更频繁新文档及时入库过期文档及时清理。最后分享一个我在实际项目里总结的小技巧用 BGE-M3 的稀疏头做 query 意图分析。稀疏头输出的 token 权重其实反映了模型认为哪些词重要。把高频 query 的稀疏权重聚合起来看能发现用户的关注点分布对产品迭代很有参考价值。这个用法文档里不会写但实战中挺好用。