从Embedding到向量检索：语义搜索与RAG工程实践

在任何一次语义检索功能上线之前我都会先问自己一个问题这套系统到底是靠字面匹配还是靠意思匹配。区别很大。几年前我在一个内部知识库项目里用关键词检索硬撑了两个月用户搜“怎么退钱”文档里明明写着“申请退款流程”却一条都没召回用户搜“发票抬头填错了”只有标题里带“发票”两个字的文档才能出来。换成向量检索之后同一批问题召回率从三成多直接拉到八成以上。那一刻我才算真正理解 Embedding嵌入在做什么——它把“意思”变成了一串可以计算距离的浮点数让机器第一次能用“像不像”来比较两段文字而不是只能数“有几个字一样”。这篇内容想把嵌入这件事从零讲清楚包括它在数学上的最小必要概念、向量是怎么算出来的、怎么选模型、怎么定阈值、怎么放进真实项目以及我在实际落地时踩过的那些坑。适合三类人看刚接触大模型想搞懂基础概念的、准备搭 RAG 或者语义搜索但不知道从哪下手的、以及已经能用起来但效果不稳定想找原因的。全程不玩玄学能上代码的地方给代码能算账的地方算给你看。1. 一句话变成一个向量嵌入到底解决了什么问题1.1 从词表编号到连续空间里的坐标要理解嵌入先得知道没有嵌入的世界长什么样。最朴素的做法是给词表里的每个词编个号“退款”是第 1024 号“退钱”是第 8865 号。这种编号叫离散表示问题非常直接1024 和 8865 之间没有任何数学关系计算机只知道它们不相等不知道它们意思一样。你没法做减法没法算距离更没法说“这两个词八成像”。另一种老办法叫独热编码词表多大向量就多长每个词对应一个位置是 1其余全是 0。五万词的词表就是五万维向量里面 49999 个零。这种向量有两个致命缺陷一是存储和计算都浪费得离谱二是任意两个不同词的向量夹角永远是 90 度距离永远相等——在独热编码的世界里“猫”和“狗”的距离跟“猫”和“量子力学”的距离一模一样。嵌入做的事情就是把这个稀疏的、正交的空间换成一个稠密的、低维的连续空间。每个词、每句话、每段文档都变成空间里的一个点坐标是一串小数比如 768 个或 1024 个浮点数。这个空间是“训练”出来的不是人手工设计的所以它的每一维不对应任何人类能说清楚的含义——你不要指望第 37 维代表“情感色彩”第 512 维代表“是否正式”。真正有意义的不是单维而是整体位置语义相近的文本坐标就靠得近。提醒一句很多入门材料会说“每一维代表一个特征”这在早期的可解释性研究里勉强成立在现在的句向量模型里基本不成立。别在这上面浪费时间把注意力放在“距离”上就好。1.2 嵌入在大模型里的三个位置“大模型入门”这个语境下嵌入其实出现在三个完全不同的地方很多人会把它们混为一谈。第一个位置在模型内部是输入层。任何一个大语言模型的第一层本质上都是一张巨大的查找表词表里每个 token 对应一个向量输入一句话就是把这几个 token 查出来拼成一个矩阵送进后面的注意力层。这一层的参数在大模型总参数里占比不高但它决定了模型对“词”的最初始理解。这部分嵌入是随模型一起训练出来的你通常不会单独去用。第二个位置是句向量也就是把一整句话、一整段话压成一个向量。这是绝大多数人说的“Embedding”时真正指的东西也是做检索、聚类、去重、分类时用的东西。它需要一个专门的编码器把变长的文本序列聚合成一个定长的向量。第三个位置是外部知识索引是 RAG 场景里的基础设施。你的文档被切成块每块算一个向量存进向量库用户提问时问题也算一个向量去库里找最近的几块塞进大模型的上下文。这条链路里嵌入模型的质量直接决定了召回质量而召回质量又是后面一切的天花板——召不回来的东西再强的生成模型也编不出来。搞清楚这三个位置很重要因为它们的选型标准完全不同。模型内部的嵌入你不用管句向量要看你自己的语料和任务索引层还要额外考虑维度成本、更新频率和检索延迟。1.3 必须先建立的直觉距离近不等于意思相等这一条是我见过最多人误解的地方。嵌入空间里的“近”度量的是用法和上下文的相似不是逻辑等价。“今天天气不错”和“今儿天气挺好”向量距离会非常小这符合预期。但“我喜欢猫”和“我不喜欢猫”在很多句向量模型里距离也相当近——因为它们共享了绝大部分词汇和句法结构只是否定词不同。早期的静态词向量更夸张“好”和“坏”在空间里经常挨得很近因为它们出现的上下文高度重叠“这个产品很___”。这带来两个实操结论。第一如果你做的是情感分类、意图识别这类对极性敏感的任务纯靠向量相似度是不够的需要在下游加分类器或者用专门为这类任务训练过的模型。第二做检索时不要指望向量能理解“排除”“除了”“不要”这类否定约束这些交给关键词过滤或者让生成模型去处理更靠谱。还有一个相关的坑多义词。 “苹果发布了新手机”和“苹果今天很甜”如果模型是上下文相关的现在的句向量模型基本都是这两句的向量会分得很开这是好事。但如果你用的是按词查表的老式词向量一个词只有一个向量多义词就会糊成一团。这也是为什么现在做句向量都用基于 Transformer 的编码器而不是查表。2. 向量是算出来的编码器、池化与训练信号2.1 从 token 向量到句向量池化这一步决定成败一句话进模型出来的是 N 个 token 向量N 是 token 数量但你要的是一个向量。中间这一步叫池化是把矩阵压成向量的过程常见的有三种做法。第一种是取第一个特殊 token 的输出很多编码器在句首会加一个占位 token训练时让它承载整句信息。这种做法在早期模型里很常见缺点是如果模型不是专门为句向量训练的这个位置的信息未必最全。第二种是均值池化把所有 token 向量按维度求平均。这是目前最常用的做法稳健、实现简单。但这里有个非常容易出错的细节必须排除 padding。因为一批文本长度不一框架会自动用 0 补齐到统一长度如果你直接对整批做平均那些补齐位置的向量会把结果往 0 拉偏。长度差异越大偏差越大。正确的做法是用 attention mask 加权只对真实 token 求平均。第三种是取最后几个 token 或者加权池化用得相对少一些某些模型会在文档里明确说明推荐哪种方式。选哪种不要自己猜看模型说明。我见过一个很典型的翻车案例一个团队把池化写成了简单平均没有处理 mask短文本10 个 token和长文本500 个 token如果放在同一批里短文本的向量会被大量 padding 稀释导致短 query 和长文档的相似度整体偏低阈值怎么调都不对。改成 mask 加权平均之后同一批数据的召回立刻正常了。这类问题不看代码根本发现不了因为结果不会报错只是“效果不太好”。import numpy as np def mean_pooling(token_vectors, attention_mask): # token_vectors: [batch, seq_len, dim] # attention_mask: [batch, seq_len]真实 token 为 1padding 为 0 mask attention_mask[..., None].astype(np.float32) # [batch, seq_len, 1] summed (token_vectors * mask).sum(axis1) # [batch, dim] counts np.clip(mask.sum(axis1), 1e-8, None) # 防除零 return summed / counts2.2 两种训练信号解释了为什么“生成模型的第一层”不好用嵌入向量是怎么“学”出来的这决定了你能不能拿现成的东西凑合用。第一种训练信号来自语言模型本身也就是“预测下一个词”。模型为了把下一个词预测准被迫学会把语义相近的词映射到相近的位置嵌入是这个过程的一个副产物。这种训练方式得到的向量对“词”的表示不错但对“整句”的表示往往不行——因为训练目标从来没要求过“整句的向量要能代表整句的意思”。第二种是对比学习这也是现在专门的句向量模型的主流做法。思路很朴素构造正样本对意思相同或相近的两段文本和负样本对不相关的两段文本训练目标是让正样本的向量靠近、负样本的向量推远。经典的实现是用同一个批次里的其他样本当负样本一批 64 条就是 63 个负例成本很低。这里面有个温度系数控制“推多远算远”的力度调得太小模型会对难负样本过度敏感太大则区分度不够。对比学习的训练数据来源决定了模型的偏好。有些模型主要用问答对训练那么它在“短问题匹配长答案”这个场景下表现特别好这叫非对称检索有些模型主要用同义句对训练那么它更适合判断两句话是不是一个意思这叫对称任务。这两类任务的向量分布是不一样的用错了模型效果可能还不如关键词。这也是下一节选型时要重点看的东西。顺带说一个常见误解有人觉得“大模型这么强我直接拿它的隐藏层输出当向量不就行了”。实测下来通常不行原因就是上面说的——生成模型的训练目标里没有“句向量要好”这一项它的隐藏状态更适合用来生成下一个 token不适合用来做距离比较。偶尔能用但不稳定而且维度往往很大成本不划算。2.3 维度的账要这么算存储、精度与效果的三方权衡维度是选型时最容易被拍脑袋决定、又最容易后悔的参数。先说结论主流句向量模型集中在 384、768、1024 这几个档位少数到 1536 甚至更高。不是越高越好。先算存储。假设你要索引 100 万条文本块每块一个向量维度float32 单向量100 万条总占用float16 总占用量化到 int8 总占用3841.5 KB约 1.43 GB约 0.72 GB约 0.36 GB7683.0 KB约 2.86 GB约 1.43 GB约 0.72 GB10244.0 KB约 3.81 GB约 1.91 GB约 0.95 GB15366.0 KB约 5.72 GB约 2.86 GB约 1.43 GB单条向量的算法是维度 × 4 字节1024 维就是 4096 字节100 万条乘起来约 3.81 GB。这只是原始向量向量库还要存索引结构HNSW 这类图索引通常会额外占用 30% 到 100% 不等。所以别看着“才 4 GB”就放心实际部署时内存要按两到三倍预留。再算效果。维度提升带来的收益是递减的。从 384 提到 768效果提升通常明显从 768 提到 1024提升就很有限了除非你的任务特别难比如跨语言、专业领域。而检索延迟和内存是线性增长的。我的经验是中文通用场景 768 维是甜点区专业领域或者多语言可以上 1024再往上就要有明确的评测数据支撑不然就是花钱买心理安慰。还有个常被忽略的点有些模型支持降维。训练时用了特殊的损失函数让前若干维就能承载主要信息你可以直接截断到 256 维用效果损失很小。如果你的场景对内存极度敏感这类模型值得优先考虑。但截断不是随便截的得模型本身支持才行自己手工截断的向量和原始向量不在一个空间里会出问题。3. 选型与跑通把一段中文稳定地变成向量3.1 选模型先回答三个问题语言、长度、对称性模型选型不是看排行榜第一名就完事。榜单上的分数是在特定数据集上算的换个领域可能完全反过来。我一般按三个问题筛。第一个问题语言。如果你的语料以中文为主别直接上纯英文模型哪怕它榜单分很高。中文的分词、句式、成语表达纯英文模型处理得很勉强。中英混合的场景要选多语言模型但要注意多语言模型在单语任务上往往不如同规模的单语模型这是容量被分摊的代价。第二个问题最大输入长度。这是最容易被忽略、又最容易造成“效果莫名其妙差”的因素。相当多的句向量模型最大只支持 512 个 token中文大概 300 到 500 字。超过就截断而且很多框架是静默截断不报错不警告你的后半段内容根本没进模型。如果你的文档块普遍在 800 字以上用 512 的模型等于只索引了一半内容。要么换支持长输入的模型要么把块切小。第三个问题对称还是非对称。判断方法很简单你要比较的两段文本长度和形态是否接近判断两句话是不是同义、给相似问题聚类这是对称任务。用一个短问题去匹配一段长文档这是非对称任务。有些模型对这两类任务分别提供了不同的编码方式比如给查询和文档加不同的前缀用的时候要按说明来混用会掉点。我一般会准备一个小评测集把候选的三到五个模型都跑一遍看 recall10而不是只信榜单。评测集的构造方法在第 4 节细说。3.2 一个最小可运行的闭环下面这段是最小闭环的逻辑示意。不同框架的函数名和参数名会有差异但流程是一样的四步加载编码器、批量编码、归一化、算相似度。import numpy as np # 第一步加载本地向量模型具体加载方式看你用的推理框架 encoder load_encoder(model_dir/path/to/embedding-model, devicecpu) texts [ 申请退款的具体流程是什么, 我想把钱退回来需要怎么操作, 如何修改发票抬头信息, 服务器宕机了怎么排查, ] # 第二步批量编码注意 batch_size、max_length、normalize 三个参数 vectors encoder.encode( texts, batch_size32, max_length512, normalizeTrue, # 输出即单位向量后续相似度直接用点积 ) vectors np.asarray(vectors, dtypenp.float32) print(vectors.shape) # (4, dim) # 第三步归一化后余弦相似度等价于点积 sim vectors vectors.T print(np.round(sim, 3)) # 第四步取指定文本的 top-k 邻居 def top_k(query_idx, vectors, k3): scores vectors vectors[query_idx] order np.argsort(-scores) return [(i, float(scores[i])) for i in order if i ! query_idx][:k] print(top_k(0, vectors))跑通之后你会发现第 0 句和第 1 句的相似度明显高于跟第 2、3 句的相似度尽管它们字面上重合的词并不多“退款”和“退回来”只有一个字相同。这就是嵌入和关键词检索最本质的区别。注意normalizeTrue一定要开。很多相似度算出来数值很奇怪、阈值怎么调都不对的问题源头就是没归一化向量的模长在干扰结果。归一化之后余弦相似度落在 -1 到 1 之间点积就等于余弦后面的计算全部简化。3.3 批量、缓存、归一化上线前必须补的三刀Demo 跑通和上线之间隔着三件必须做的事。第一件是批量大小。单条编码在 CPU 上大概几十毫秒到上百毫秒一百万条就是十几个小时。批量编码能把这个时间压下来一大截因为 GPU 和 CPU 的并行度被用起来了。但批量不是越大越好太大容易爆显存而且在长度差异很大的批次里padding 会浪费大量算力。我的做法是先按长度排序再按长度分组做批次同批次内长度接近padding 浪费最小。这个优化在长文本占比高的时候效果非常明显。第二件是缓存。同一个文本不要算两次。索引重建的时候绝大多数文本块是没变的只有少数新增和修改。用一个内容哈希做 key把向量存起来重建时只算增量。这个改动看起来朴素实际能把重建时间从几小时压到几分钟。哈希用文本内容的摘要就行注意要把模型版本也拼进 key 里不然换模型之后会拿到旧向量这是第 6 节要讲的坑。第三件是归一化。前面说了要开这里补充一个细节如果你的向量库或者检索库要求你自己做归一化记得在写入前做而不是查询时做。两边都归一化才对等只归一化一边相似度就是错的。而且归一化后的向量模长恒为 1可以用 float16 存而不损失精度存储直接减半。4. 相似度不是概率分数怎么算、阈值怎么定4.1 余弦、点积、欧氏距离什么时候用哪个三种度量在归一化之后是有等价关系的但没归一化的时候差别很大。度量方式计算方式对模长敏感取值范围适用场景余弦相似度点积除以模长乘积否-1 到 1文本语义比较的默认选择点积对应维相乘求和是无上界向量已归一化时等价余弦且更快欧氏距离差的平方和开根号是0 到正无穷向量已归一化时与余弦单调对应文本场景我默认用余弦原因是文本长度差异大长文本的向量模长往往更大用点积会让长文本天然占优短查询匹配长文档时容易被压制。归一化之后两者等价那就直接用点积省掉除法的开销向量库内部也都是这么做的。欧氏距离在归一化之后和余弦是单调对应的距离越小余弦越大所以选哪个不影响排序只影响你看到的数值。如果你的向量库只支持欧氏距离不用担心归一化之后结果一致。有一个例外情况要注意某些模型在训练时用的就是点积损失没有做归一化那么它的向量模长本身携带信息比如文本的“重要性”或者“置信度”这时候强行归一化反而会丢信息。这种情况很少但如果你的模型文档明确说了不要归一化就按文档来。4.2 为什么 0.8 分不能当成 80% 把握这是我最想强调的一点。余弦相似度是一个相对排序指标不是概率。0.8 不代表“八成相关”0.6 也不代表“六成相关”。原因有三个。第一不同模型的分数分布完全不同。有的模型把所有文本都映射到一个很窄的锥形区域里任意两句话的相似度都在 0.5 以上那 0.6 就是“很不相关”有的模型分布很散0.4 就已经是强相关了。第二同一个模型在不同语料上的分布也不同。你的语料如果全是同一个领域的文档彼此天然相似整体分数会偏高。第三查询和文档的长度差异会系统性影响分数短查询对长文档的分数普遍偏低。所以正确做法是排序用分数判定用阈值而阈值必须在自己的数据上校准。不要抄别人的 0.7、0.75那些数字放到你的数据上大概率是错的。工程上我一般用“双保险”先取 top-k比如 10 条再用一个绝对值阈值过滤掉明显不相关的。阈值不求精确只求把噪声挡在门外。而且这个阈值要定期复查因为语料在变、模型可能换分布会漂移。4.3 用三十条样本把阈值钉死校准阈值不需要大数据集三十到五十条查询就够了关键是每条都要人工标出“哪些文档是真正相关的”。具体做法准备 40 条真实用户查询对每条准备 20 到 30 个候选文档从你的库里随机抽加上人工挑几个难的人工标注相关性相关/不相关二分类就行。然后用你的模型算出所有查询-文档对的相似度按分数从高到低排序逐个分数点试如果以这个分数为阈值精确率和召回率分别是多少。import numpy as np def eval_threshold(scores, labels, thresholds): # scores: 相似度数组labels: 1 表示相关0 表示不相关 rows [] for t in thresholds: pred (scores t).astype(int) tp int(((pred 1) (labels 1)).sum()) fp int(((pred 1) (labels 0)).sum()) fn int(((pred 0) (labels 1)).sum()) precision tp / (tp fp) if tp fp else 0.0 recall tp / (tp fn) if tp fn else 0.0 rows.append((round(float(t), 2), round(precision, 3), round(recall, 3))) return rows thresholds np.arange(0.30, 0.95, 0.05) for row in eval_threshold(np.array(scores), np.array(labels), thresholds): print(f阈值{row[0]} 精确率{row[1]} 召回率{row[2]})输出会告诉你一个很实际的结论阈值调高精确率上去、召回率下来调低则相反。选哪个取决于你的业务容忍度。召回不够的代价是“用户找不到”精确不够的代价是“用户看到一堆无关内容”或者“生成模型被噪声带偏”。做 RAG 的时候我一般偏向多召回一些把 top-k 放大到 20 甚至 30然后靠后面的重排模型收敛而不是在召回阶段就把阈值卡死。校准还有一个副产品你会看到那些“模型认为很像但实际不相关”的难例这些样本是后续优化换模型、微调、加关键词召回最宝贵的输入。5. 四个真实用法检索、去重、聚类、分类5.1 语义检索与知识库召回切块策略比模型更影响效果做知识库问答的时候很多人把精力全放在选模型上实际上切块策略对最终效果的影响往往比模型选型更大。原因很直接向量是块级别的如果你的块切得不好一块里混了三四个不相关的主题这个块的向量就是一个“平均脸”跟谁都不像。反过来块切得太碎一句话一块上下文丢了向量也没意义。我的经验参数中文文档按 300 到 500 字切块块之间保留 50 到 100 字重叠。重叠的作用是防止关键信息正好卡在切割边界上被劈成两半。切的时候优先按语义边界切段落、标题、列表项实在不行再按固定长度硬切。有标题结构的文档把标题拼进块内容里再编码效果提升很明显——标题往往就是这个块的主题句。另一个实用技巧是父子块小块用于检索精度高命中之后返回它所属的大块给生成模型上下文足。这样既解决了“块小了检索准但上下文不够”又解决了“块大了检索糊”的矛盾。实现上就是给每个小块记一个父块 ID召回后按父块去重。再就是混合检索。纯向量检索对专有名词、型号、编号这类东西不敏感——“X2000”和“X3000”在向量空间里可能非常接近但对用户来说是两个完全不同的产品。这种场景加一路关键词检索BM25 之类两路结果融合能把这类漏召回补上。融合最简单的做法是倒数排序融合按名次而不是按分数加权避免两路分数不可比的问题。5.2 工单去重先归一化再谈阈值客服工单去重是我做过的最容易见效的嵌入应用。逻辑很简单新工单进来算向量去历史工单里找最相似的几条超过阈值就提示“可能与这些重复”。这里最关键的参数不是模型是阈值和“看几条”。我一般这样定先取 top-5然后看第一名和第二名的分数差。如果第一名明显高出一截比如高 0.1 以上那大概率是真重复如果前几名分数都差不多那往往是“同一类问题但不是同一个问题”交给人工判断更稳妥。这个“分数差”信号比单纯的绝对阈值可靠得多因为它利用了相对关系。还有一个细节工单里往往有一大段是模板化的客套话“您好这里是客服中心…”这些内容对所有工单都一样会把向量整体拉近。处理办法是去重前先做文本清洗把模板段落、签名档、自动回复去掉只留问题描述部分。这个清洗动作带来的效果提升比换一个更强的模型还大。阈值方面去重场景我倾向保守宁可漏判也别误判因为误判的体验很差用户会觉得系统在敷衍。所以阈值取高一些并且只在前几名分数差明显时才自动标记。5.3 小样本分类嵌入加一个线性层往往就够了如果你有几百条标注数据想做个文本分类意图识别、情感极性、工单分类不必上来就微调大模型。用现成的句向量模型把文本转成向量然后在向量上训一个逻辑回归或者浅层网络往往就能拿到不错的效果而且训练成本几乎为零几分钟就能迭代一轮。原因是嵌入模型已经把语义信息提取出来了你要做的只是在这个空间里画几条分界线。数据量小的时候这种方案比微调更稳——微调几百条数据很容易过拟合反而不如固定特征加简单分类器。什么时候该升级到微调两个信号一是分类边界在语义上很微妙比如“咨询”和“投诉”的区分往往取决于语气而不是内容向量层面区分度不够二是你有上万条标注简单分类器的天花板到了。这时候可以用对比学习的方式微调编码器把同类样本拉近、异类推远效果会有明显提升。但要注意微调之后的向量空间变了之前建好的索引全部要重建这个成本要提前算进去。顺便说一个省事的技巧分类任务里如果某一类样本特别少比如只有十几条可以用“类中心”的思路——把这一类的样本向量平均一下当作类的代表向量新样本跟类中心比距离。这比训练分类器更不容易过拟合冷启动阶段特别好用。6. 踩坑记录五个我真实踩过的坑6.1 长文档截断结论永远召不回来这个坑我印象最深。当时做一个产品手册的问答手册里每个章节三四千字我图省事直接整章编码存进去。上线之后发现用户问章节末尾才提到的参数永远召不回来。查了半天最后发现模型最大输入是 512 个 token整章内容只编码了前面的四分之一后面的全被静默截断了。更麻烦的是这个问题很难自查因为不报错、不警告向量照常生成只是内容不全。我后来的做法是在编码前先统计 token 长度分布把超过模型上限的文本单独拎出来看比例。如果超过 5%就必须处理。处理方式要么换长输入模型要么老老实实切块。切块虽然麻烦但在检索场景里通常比长输入模型效果更好因为块小了之后每个向量的语义更聚焦。一个自查方法随便抽十条长文本把它们的向量和“文本末尾那句关键句”的向量算相似度。如果相似度低得离谱基本就是被截断了。6.2 换了模型向量库必须重建有一回我们觉得检索效果不够好换了个更强的模型。维度一样都是 768代码里只改了一行模型路径索引也没重建直接跑——结果检索结果乱七八糟甚至出现了完全不相关的文档排第一。原因很简单不同模型训练出来的向量空间完全不同即使维度一样第 37 维在两个空间里代表的含义也毫无关系。旧向量和新查询向量做点积等于把两份不同语言的词典硬对着翻译结果毫无意义。正确的做法是模型版本必须和向量库绑定。我在向量库里加了一个元数据字段记录模型版本和模型指纹查询时校验不匹配就拒绝服务并提示重建。重建的成本可以通过缓存降低——如果只是换模型所有向量都要重算这部分省不掉所以换模型前一定要先在小评测集上验证清楚真的更好别频繁折腾。6.3 行业黑话不敏感别急着怪模型通用句向量模型在专业领域经常表现不佳因为训练数据里这些术语出现得少模型没学过它们之间的关系。我做过一个工业设备的问答设备型号、故障代码满天飞通用模型把这些代码全都映射到了空间里同一片模糊区域导致“E102 报警”和“E205 报警”的向量几乎一样。解决办法有三个层次成本从低到高。最便宜的是混合检索把型号、代码这类强标识符用关键词检索单独处理向量检索负责语义部分两路结果融合。这个方法立竿见影我一般先上这个。第二个层次是在编码前做术语展开把缩写、别名、口语说法统一成规范说法或者在文本里补一句解释让模型有更多语义线索。第三个层次才是微调编码器用领域内的相似文本对做对比学习。微调效果最好但需要构造训练数据周期以周计不要一上来就走这条路。6.4 索引参数与过滤条件的组合陷阱向量库不是把向量丢进去就能用。以图索引为例有几个参数直接影响召回率和速度控制每个节点连边数量的参数决定了索引的连通性建索引时的搜索深度参数影响索引质量查询时的搜索深度参数影响查询时的召回和延迟。这些参数的调法不复杂但有一个陷阱特别隐蔽带过滤条件的查询容易召回不足。比如你只想在某个分类下检索向量库会先按条件过滤出候选集再在候选集里做近邻搜索。如果候选集很小而索引的连通性又是在全量数据上建的过滤之后图可能被切断导致明明有相关文档却搜不到。表现为“去掉过滤条件就能搜到加上就搜不到”。应对办法要么把过滤条件做成“后过滤”先搜索更大的 top-k 再过滤牺牲一点精度换召回要么把分类信息也编码进向量让同类聚在一起要么干脆按分类分库。选哪种取决于你的过滤维度和数据分布但一定要专门测一下带过滤的场景别只测无过滤的。6.5 成本与延迟什么时候该离线算什么时候该实时算最后一个坑是性能和成本的账没算清楚。原则很简单能离线算的都离线算。文档库、商品库、历史工单这些都是相对静态的向量应该提前算好存起来查询时只算用户那一句。实时编码的只有查询侧一条文本几十毫秒完全可接受。如果连查询侧都要编好几次比如多路查询改写那就要考虑加缓存把高频查询的向量缓存起来。批量重建的时候有几个能显著提速的点按长度分桶减少 padding 浪费、用更大的批量吃满硬件、关掉不需要的梯度计算、用半精度推理。这几个加起来吞吐能翻好几倍。另外重建不要全量重来用内容哈希做增量只算变化的块这个前面说过效果非常明显。延迟方面如果你的检索链路里还有重排模型要注意重排往往是延迟大头不是向量检索。向量检索在百万级数据上通常是个位数毫秒真正慢的是后面的模型推理。所以优化顺序应该是先看重排再看编码最后才看向量索引。我个人在实际项目里的体会是嵌入这套东西的技术门槛不高难的是工程细节切块怎么切、阈值怎么定、缓存怎么做、版本怎么管。模型选型在整个效果里大概只占三成剩下七成都在这些不起眼的地方。所以如果你刚开始做别在选模型上纠结太久先用一个够用的模型把全链路跑通然后用真实查询去校准阈值和切块策略效果提升会比换模型快得多。