Embedding 模型

• 内在指标（MTEB、相似度分布）衡量向量空间质量
• 外在指标（Recall@K、命中率、答案正确率）衡量业务效果
• 联合解读避免"内在好但业务差"

内在指标关注向量空间本身：MTEB 子集（检索、分类、聚类等 benchmark）、相似度分布是否合理（正负样本分数可分离、分布不塌缩）。外在指标关注业务结果：Recall@K（正确的 K 条是否被召回）、命中率（答案是否在候选里）、答案正确率（RAG 端到端是否正确）。联合解读：内在指标反映"向量是否区分语义"，外在指标反映"是否服务业务"。若内在好但外在差，问题在检索流程（切块、topK、rerank、融合）而非 Embedding；若外在好但内在异常，可能是评测集偏差。以"外在指标为主、内在指标辅助定位"的方式联合评估。

单一指标会误导：内在分数高不代表业务检索好，外在得分低也不一定是 Embedding 问题；联合解读才能定位是"向量质量问题"还是"检索链路问题"。

• MRL/Matryoshka 支持截断子维度仍可用
• 按业务精度需求分级选维度
• 召回率与存储/延迟的权衡

MRL/Matryoshka Embedding 训练时让"前缀子维度"也保留语义，因此可用同一向量按需截断到不同维度（如 1024→512→256）而无需重训。业务分级：高精度场景（精确检索、低容错）用高维（如 1024）保证召回率；中低精度场景（粗筛、批量候选、成本敏感）用低维（如 256/512）降低存储与延迟。评估时对每个维度测 Recall@K 与正确答案率，找到"维度下降但召回率损失可接受"的拐点，再按业务阈值选维度。存储成本 = 维度 × 向量数 × 字节数，维度减半存储即减半，用 A/B 验证维度对业务指标的影响。

MRL 让"维度"成为可按业务调节的参数而非固定成本；关键是找到召回率可接受的拐点，用实测而非猜来平衡精度与成本。

• 多语种 Embedding 的跨语言对齐
• 语言检测与语种路由
• 跨语言检索失败的处理

处理三方面：一是检索对齐，选支持多语种且对齐良好的模型（如 BGE-M3、mE5、多语种 SBERT），这类模型把不同语言映射到相近空间，保证跨语言检索（中文查英文文档）基本可用；二是语言检测，对查询做语言识别，若业务需要"同语言检索"则按检测结果路由到对应语种索引或做语种过滤，避免跨语言鸿沟；三是兜底，对对齐不佳的语种对，用翻译扩展（query 翻译成目标语言）或混合检索（多语种向量+关键词）提升召回。评测时按语种对分别测 Recall@K，确认跨语言检索质量。

跨语言鸿沟表现为"中文查询召不回英文文档"；对齐模型解决主体，语言检测与翻译/混合检索做兜底，并按语种对评测验证。

• 评测指标（Recall@K、nDCG、答案正确率）
• 混合检索的预期收益
• 上线无提升的归因

评测：在自有带标注查询集上对比纯向量与混合检索，指标用 Recall@K（是否召回正确项）、nDCG（排序质量）、答案正确率（RAG 端到端）。上线后没提升的归因：一、分布问题，混合检索的优势在于"精确关键词/术语/ID"场景，若评测集与线上查询偏语义化，重叠收益不明显；二、融合权重问题，BM25 与向量融合权重不当，BM25 结果被稀释或向量噪声主导；三、交集问题，两者结果重叠度高，混合没带来新召回；四、排序漂移，混合后正确项被排到 K 之后，Recall@K 不升反降。按此逐项排查，必要时分别看 BM25 与向量各自的孤立召回，找到端到端瓶颈。

混合检索不是必然提升，收益取决于"精确匹配 vs 语义匹配"的分布与融合质量；上线无提升要回归到融合权重、重叠度与排序逐项定位。

• 影子评测（shadow）并行对比
• 无停机切换（灰度、feature flag）
• 质量回退与回滚

影子评测：线上用旧 reranker 出结果，同时把同一候选集喂给新 reranker，在影子层对比两者的排序指标（Recall@K、nDCG、答案正确率）与线上行为，不改变线上结果，安全收集数据。无停机切换：先小流量灰度（5%→50%→100%），用 feature flag 控制，配合监控指标（召回率、答案正确率、延迟、错误率）；若质量回退或异常，立即回滚到旧模型，避免全量切换造成突变。评测集要与生产分布一致，并观察一段时间确认无回归后再全量。

Rerank 升级的风险是排序突变导致线上质量波动；影子评测先离线验证、灰度切换保在线稳定、回滚兜底，三步保证无停机升级。

• cross-encoder 的成本/延迟/效果
• LLM-based rerank 的成本/延迟/效果
• 按场景取舍

cross-encoder（如 bge-reranker）对 query-doc 对计算相关性分数，质量高、延迟低（毫秒级）、成本低，适合作为在线精排首阶段；LLM-based rerank（listwise/rankGPT）让 LLM 理解整体列表排序，能处理复杂语义与上下文，效果更强但延迟高（秒级）、token 成本高，适合小候选集、离线或高价值场景。取舍：在线高并发用 cross-encoder 做主要精排；对候选集小或误判代价高的场景，用 LLM 做二次精排或人类可解释排序；成本敏感时避免对全部候选跑 LLM，只对 top-K 做 LLM 终排。

cross-encoder 是性能与成本的平衡点，LLM-based 是效果上限但贵；取舍本质是"候选集大小、延迟预算、误判代价"三者的权衡。

• 分数校准（归一化、分布对齐）
• 阈值治理（相关性下限）
• 防止不相关结果进生成

rerank 分数是相对分数，尺度因模型与查询而异，直接设阈值会误判。校准做法：用带标注数据集统计 rerank 分数的分布，观察"相关"与"不相关"样本的分数区间，进行归一化或分位数校准，把分数映射到可比尺度；同时训练一个阈值（如相关性分数低于某值即丢弃该候选）或按"topK 内相关性下限"过滤。治理上：对候选做相关性门控，低于阈值的候选不进生成，避免模型基于不相关上下文编造；配合"即使分数高但过 query 相关度校验"的二次过滤，并监控生成的引用来源。

rerank 分数是相对分，必须校准到可比尺度才能设阈值；阈值门控把"不相关高分"挡在生成之外，防止幻觉与跑题。

• 三种切块策略的差异
• 与 rerank 的联合评估
• 切块对检索-精排整体效果的影响

固定切块简单但可能切断语义；语义切块按语义边界切分，召回更贴切但实现复杂；父子块（父块大语义完整、子块小精确）兼顾召回粒度与上下文语义。评估时不能只看检索本身，要联合 rerank 与端到端看：切块+检索+rerank 的整体 Recall@K、答案正确率。因为切块影响召回候选，rerank 影响排序，两者耦合。实验方法：固定 rerank 与 topK，比较不同切块策略的端到端指标，选出最优组合；也要关注切块对 token 成本与延迟的影响（子块小、候选多、rerank 负担重）。

切块与 rerank 是耦合的，切块决定候选质量、rerank 决定排序质量；必须联合评估端到端指标而非孤立看切块召回。

• 容量规划（QPS、并发、吞吐）
• 超时降级策略
• 降级对质量的取舍

容量规划：根据峰值 QPS、每请求候选集大小、rerank 单次延迟与并发上限，估算需要的实例数与吞吐，预留 buffer 应对尖峰；用压测确定单实例吞吐与延迟 P95。降级策略：设置 rerank 超时（如 300ms），超时则跳过 rerank 直接使用检索排序结果返回，保证在线可用性；或用"部分 rerank"（只对 top 候选 rerank）、降级到更轻量模型、限流保护。降级时监控降级率与质量影响，降级频繁说明容量不足，需扩容或优化候选集大小。

rerank 是延迟敏感服务，容量规划按峰值+并发算，超时跳过是保可用性的关键兜底；降级率是容量与质量的信号。

• 参数版本化
• 与评估基线绑定
• 防止漂移无法归因

把融合权重（BM25/向量权重）、topK、rerank 阈值、切块参数等做成可配置的"检索配置版本"，每次改动通过代码/配置管理生成新版本号，并记录该版本对应的评测结果（Recall@K、nDCG、答案正确率）作为基线。线上流量按配置版本标记，评估与线上实验都绑定版本号，这样效果漂移时可回溯"是哪个参数/哪个版本导致的"，能精确归因。同时参数变更走评测门禁，未通过基线校验的版本不允许上线，防止无记录调参埋雷。

检索参数繁多且互相影响，不版本化就难以归因；版本号+基线绑定让"调参"可追溯、可回滚、可对比，是防漂移的基础。

• RRF 原理与加权融合
• 用自有查询集做网格/自动调优
• 避免照搬经验值

RRF（Reciprocal Rank Fusion）不用绝对分数，用倒排排名融合，规避 BM25 与向量分数尺度不一致的问题；加权融合则给两路分配权重。调优方法：标注自有查询集（带正确检索结果），划分训练/验证集，用网格搜索或贝叶斯优化在验证集上调整权重（或 RRF 的 k 常数），以 Recall@K、nDCG 为优化目标，选最优权重；再用留出测试集验证泛化。不能照搬经验值（如 0.5/0.5），因为不同语料、不同领域 BM25 与向量的相对优势不同，权重必须按自有数据实测。

融合权重是领域相关的，经验值在不同语料上不适用；用自有标注查询集做有监督调优并验证泛化，才能得到可靠权重。

• 各模型维度
• 语言支持
• 适用场景

BGE（bge-large-zh 等）中英文支持好、维度 1024 左右，检索任务表现强；BGE-M3 是基于多语言（100+ 语言）的稠密+稀疏+多向量（M3）模型，维度 1024，擅长多语种与混合检索；E5（如 multilingual-e5-large）支持多语言，维度 1024，检索与语义相似度高。选型时看：语言覆盖（是否含目标语种、跨语言对齐）、维度（存储成本与精度）、检索能力（MTEB/BEIR 分数）、运行成本（模型大小、推理延迟）。中英主场景可 BGE，多语种用 M3，通用多语言用 E5，结合自有评测集实测选取。

各模型维度与语言支持不同，选型要匹配业务语种与检索需求，并用自有评测集实测而非只看公开分数。

• 各模型延迟/计费/维度/语种/维度可调
• 应用层权衡
• 选型决策

OpenAI text-embedding-3 支持维度可调（如 1536/1024/小维度）、API 计费、中英文可用、延迟取决于网络；BGE-M3 开源可自部署、多语言、维度 1024、无 API 计费但需自付推理成本；E5 开源多语言、维度 1024 左右；Cohere Embed v3 商业 API、支持多语言与维度可调、计费按 token。应用层选择：数据敏感/高并发用自部署开源（BGE-M3、E5）控成本与隐私；图省事与云端用 OpenAI/Cohere 商业 API；需要维度可调按业务分级时优先 OpenAI text-embedding-3 或支持 MRL 的开源模型；多语种跨语言优先 BGE-M3 或 Cohere。综合比较延迟、计费、语种与维度可调后实测选型。

四类模型在开源/商业、维度可调、语种侧重上差异明显；选型是"成本、隐私、语种、维度灵活度"的综合权衡，需实测验证。

• 两阶段中的接入位置
• 延迟预算
• 候选集大小设定

接入位置：检索阶段（BM25/向量/混合）先粗召回一段候选（如 50-100 条），reranker 在此精排，把 topK（如 5-10 条）送入生成或后续 LLM 精排。位置确定原则：召回要"高召回宽覆盖"，rerank 要"精排降噪"，所以 rerank 一定在粗召回之后、生成之前。延迟预算：rerank 是 cross-encoder，随候选数线性增长，需按线上 P95 延迟预算倒推候选集大小（如预算 200ms，单条 5ms，则候选 ≤40 条）；候选集取"召回质量与 rerank 延迟"的平衡点，过大延迟高、过小漏真。用实测调候选集大小与 rerank 单条延迟。

rerank 在"粗召回后、生成前"，成本与候选数成正比；延迟预算决定候选集规模上限，需在召回率与延迟之间取平衡。

• MTEB/BEIR 评测内容
• 检索指标的解读
• 用自有数据补充

MTEB 是综合评测基准，覆盖检索、语义相似度、聚类、分类等任务；BEIR 专注零样本检索（out-of-domain），测跨领域泛化，用 nDCG@10 等指标。它们用于横向比较 Embedding 模型的检索能力。但要注意：公开基准的领域分布与自有业务可能不同，分数高不代表业务检索好。工程使用：把 MTEB/BEIR 作为初步筛选与横向对比，再在自有业务数据集上建立检索评测（Recall@K、nDCG、答案正确率）做最终选型与回归。

MTEB/BEIR 是标准化的横向标杆，但领域偏差使其不能直接代表业务效果；公开基准做筛选、自有评测做决策。

• 高维精度 vs 存储成本
• 检索延迟
• 降维（MRL）的适用条件

量化：存储成本 = 向量数 × 维度 × 字节数（如 float32 每维 4 字节），维度越高存储越大；检索延迟与维度相关（内积计算量、内存带宽），维度越高延迟越高；精度随维度上升但边际递减。权衡方法是：在同一数据集上对候选维度（如 256/512/1024）测 Recall@K 与答案正确率，找到"精度损失可接受"的维度拐点。降维（MRL）值得的条件：存储/延迟成本敏感的大规模向量库、或业务对精度不敏感（粗筛、候选生成），且 MRL 截断后仍能保持可接受召回；反之高精度低容错场景（精确检索、医疗）保留高维更值。

维度是"精度-成本-延迟"三方权衡，关键是用实测找拐点；MRL 在成本敏感或精度不敏感场景值得，否则高维更划算。

• 增量更新 vs 全量重嵌
• 版本与一致性
• 更新策略

数据变化（新增/修改/删除文档）时，增量更新只对变更文档重嵌并更新索引，删除时把向量从索引移除，适合高频增量场景；模型升级时需全量重嵌（新旧向量空间不同，混用会破坏检索），配合双索引过渡（新旧向量并行，验证后切换）与版本化。一致性设计：向量库与源数据同步（用消息/定时任务），保证文档与向量一致；模型版本号编入索引，旧版本向量与新版本不可混用，升级时先重建再切换。降级：重嵌失败时保留旧向量并告警，避免检索空洞。

增量更新保效率、全量重嵌保模型升级一致性；关键是把"文档变更"与"模型版本"分开处理，用双索引与版本化避免混用。