最近在折腾一个基于大模型的内部知识库问答系统检索效果一直不理想调来调去发现根子都出在 Embedding 上。这篇是大模型开发系列的第三篇专门把 Embedding 技术从原理到落地完整捋一遍。如果你正在做 RAG 检索增强、语义搜索、智能问答这类应用或者已经调过向量接口但感觉“知其然不知其所以然”这篇文章基本能帮你把这条链路彻底打通。文章里的代码都是最简可用版本直接复制到开发环境就能跑跟着走一遍比自己看十篇文档都管用。1. Embedding 解决的核心问题先弄清它到底扮演什么角色1.1 为什么大模型需要 Embedding而不是直接“认识”文字大语言模型本质上是一个文本生成模型它吃进去的是字符串吐出来的也是字符串。但模型的内部计算全部发生在数值空间中Transformer 结构只能处理浮点数矩阵不能处理字符本身。所以任何一个大模型在真正开始“思考”之前都要先把输入文本切成一串 token再通过一个嵌入矩阵Embedding Matrix把每个 token 映射成一个稠密向量。这就是 Embedding 最底层的角色。这里有一个特别容易混淆的点我见过不少同学栽在这里。大模型内部的 Embedding 是 token 粒度的每个词元一个向量而且要经过多层注意力网络之后每个 token 的向量会带上上下文信息不再是孤立的静态查表。而我们在做应用开发时调用的“文本向量接口”返回的通常是一整句或一整段的向量比如 1024 维。这个句向量往往是模型最后一层的隐状态做池化pooling得到的。一个是 token 粒度一个是句子粒度空间层级不一样用途也完全不同。前者服务于语言模型的词元预测后者服务于我们自己的语义检索和相似度计算。大家刚开始上手时一定别把这两层混为一谈。很多教程讲 Embedding 会从 Word2Vec 开始讲那是词嵌入时代的老黄历了。现在的关键认知是在应用层Embedding 就是把任意一段文本映射成一个固定长度的数值向量并且在语义相近的文本之间向量的几何距离也相近。1.2 RAG 的地基召回上限由向量质量决定我把 Embedding 叫作 RAG 的“眼睛”。因为 RAG检索增强生成那条链路里系统先根据用户问题去知识库里捞相关段落再把捞到的段落拼进 Prompt 交给大模型生成答案。整个链路里那个“捞”的动作绝大多数时候就是在做向量近邻检索。用户的问题被编码成 query 向量知识库里的每段文本被编码成候选向量系统通过计算向量之间的距离或相似度把最接近的几个段落挑出来。这个环节一旦出了问题后续所有环节都救不回来。重排模型再厉害也只是在给定候选集里调整顺序如果 Embedding 本身就召不回正确的段落重排模型连看到正确文档的机会都没有。大模型生成能力再强喂进去的是无关内容它也只会一本正经地编。所以从工程价值上讲Embedding 决定了整个 RAG 系统的召回上限这比我后面要讲的所有技巧都重要。可以用一个特别生活化的类比来理解想象你是一个图书管理员用户跑来问你“怎么防止家里的绿萝烂根”。你脑子里把每本书都抽象成一条索书号然后根据语义相关性快速锁定几本园艺书籍。这个“索书号”质量好不好决定了你能不能在几十万册藏书里把那本真正讲到浇水频率的书捞出来。Embedding 扮演的正是这个“索书号”的角色。1.3 适用范围和选型思路概述Embedding 的典型应用场景包括语义检索、知识库问答、文本去重、聚类分析、推荐召回、异常检测等。在实际开发中最常见的需求就两类一是给文本做向量化存储二是根据查询向量做相似度召回。不管是做哪一种核心动作是一样的把文本变成向量把相似度计算做到又快又准。文章后面的内容会分成四个部分推进先搞清楚 Embedding 的底层训练逻辑和模型选型再带你完整落地一个小型语义检索系统然后结合大模型做成一个最简单的 RAG 问答最后把我在实际项目中踩过的一些坑集中整理出来。整体路线就是从原理到工程一步一步打通。2. Embedding 的底层逻辑与模型选型训练原理、指标与维度2.1 语言模型内部的 Embedding 层从静态词向量到上下文表示上一节我提到了 token 粒度的 Embedding。更深一层说在大模型内部初始的 token embedding 只是一个高维查表模型记着一本“词表”每个 token 对应一列可学习的浮点数参数。经过训练之后语义相近的 token 在这个原始嵌入空间里会靠得更近。随着层数加深每个 token 的表示不再只依赖自己而是通过注意力机制融合了句子中其他 token 的信息。所以到最后一层每个 token 的向量其实已经是“上下文感知的表示”。具体到代码层面你用开源的深度学习框架加载一个预训练语言模型时输入一批文本模型会返回一个形状为(batch_size, seq_len, hidden_size)的三维张量。这个张量里包含了每个 token 在最后一层 Transformer 输出中的向量。如果我们只想要一个句子级的向量常见的做法有三种取[CLS]位置的向量这是很多预训练模型专门为句级分类任务设计的标记位对序列维度做平均池化mean pooling把每个 token 的向量取平均对序列维度做最大池化max pooling取每个维度上的最大值。不同模型对池化方式有自己的推荐这一点后面实操部分我会提到。现在只需要记住模型输出的原始张量不是句向量你需要按模型官方推荐的方式做池化才会得到适合做检索的句子向量。很多初学者在这个地方踩坑直接拿第一个 token 的向量去跟库里做对比结果效果飘忽不定。2.2 文本向量模型的训练思路对比学习和双塔结构明白了“怎么用”之后还得知道“怎么来”。市面上所有优秀的开源文本向量模型核心训练思路几乎都是对比学习跟教一个小孩子认东西有点像。你得先准备大量“语义相似对”作为训练数据两个句子意思相近就组成一个正样本对随机抽两个不相关的句子就组成负样本对。训练目标相当直观同一个 batch 里让语义相近的句子向量相互靠近让语义不相关的句子向量相互远离。这里面有个非常关键的工程细节叫“批次内负样本”in-batch negatives。具体做法是一个 batch 里有 N 个句子分别编码得到 N 个向量对于其中第 i 个句子把 batch 里其他 N-1 个句子的向量都当作负样本参与训练。这样做的数据效率特别高不需要额外采样大量负样本训练成本一下就降下来了。现在很多开源向量模型的训练脚本基本都有这个设计你可以把它理解成“用同一桌吃饭的其他人来当陪练”特意去外面找反例反而没这么高效。模型架构上普遍采用双塔结构一个 query 编码塔一个 document 编码塔两个塔共享参数或者各自独立分别把 query 和 document 编码成向量。双塔的好处是query 和 document 可以离线分别向量化在线检索时只需要对 query 做一次正向计算然后去向量索引里做近邻检索。这种解耦设计是支撑大规模语义检索在工程上落地的基础。不然每次查询都要把所有文档重新编码一遍那算力谁也扛不住。2.3 Embedding 模型选型的关键指标选 Embedding 模型时我通常关注这几个硬指标输出维度一般是 768、1024、1536 等。维度越高单条向量的表达能力通常越强但存储成本和计算成本也越高。做粗召回的话不需要盲目追高512 维或者 768 维在很多场景下足够。最大输入长度常见的是 512 token 或 1024 token。超出会被截断所以长文档要提前切分好不能把一整页文本直接丢进去。语言支持中文场景必须看中文效果很多英文效果好的模型中文表现并不理想需要看公开检索榜单上的中文成绩。检索任务指标有些模型专门在语义相似度STS任务上优化有些模型专门在检索任务上优化。如果你的目标是做 RAG就应该优先看检索类评测的结果而不是只看相似度分数。是否支持领域微调垂类场景比如医疗、法律、代码下通用向量模型往往表现一般。碰到这种情况优先找有没有领域适配版本或者自己准备一批领域语料做微调。我在实际选型时还喜欢做一个小实验准备 20 组人工标注好的“相似/不相似”句子对分别用候选模型编码计算相似度分数直接看两个分布的重叠程度。这个实验十分钟就能跑完比看任何榜单都直观。榜单是平均表现而你的业务场景永远有自己独特的表达习惯。2.4 维度选择与存储成本的经验法则很多人在项目初期会纠结“是不是维度越高越好”。我的经验是先看检索场景的规模再看业务对召回精度的敏感度。如果知识库只有几万条文档用 768 维完全够如果到了千万级规模就需要考虑 512 维配合量化、分片等手段。高维度带来的收益在规模变大之后会边际递减而存储和内存的开销却会线性上升。还有一点很重要不同模型产出的向量不能互相混用。比如你之前用 A 模型生成了一批向量存进数据库后来换了 B 模型如果直接拿 B 模型的 query 向量去跟 A 模型的历史向量做相似度计算得到的结果基本没有参考意义。因为不同模型的向量空间是不一样的维度相同不代表坐标系相同。这个坑我在后文第 4 章会详细讲这里先提醒一下上线前就要在向量库里登记模型编号和维度否则得全量重建向量。3. Embedding 落地实践一个小型语义检索系统的完整实现3.1 环境准备与基础工具链下面我带着你完整实现一个“文档库语义检索”的 Demo。先说明环境Python 3.9 以上机器上有 PyTorch 以及对应的预训练模型加载库就够了。没有 GPU 也能跑选一个小一些的开源模型即可。我建议直接用一个已有的开源中文向量模型放在本地目录“local_embedding_model”里方便后面统一加载。在开始之前先把依赖准备好pip install torch transformers numpy如果是 CPU 环境安装的是 CPU 版 PyTorch跑一个小规模 demo 没问题只是生成向量的速度会慢一些。这一步没有太多技巧但要注意 Python 版本不要太高个别库对 3.12 以上的兼容性还没有完全跟上建议先用 3.10。3.2 生成向量把一段文本变成坐标用加载库加载本地模型对一批文本生成句向量做法如下from transformers import AutoTokenizer, AutoModel import torch model_dir local_embedding_model tokenizer AutoTokenizer.from_pretrained(model_dir) model AutoModel.from_pretrained(model_dir) model.eval() texts [ 如何防止多肉植物烂根, 多肉植物的浇水频率需要根据季节调整。, 深度学习模型训练时学习率设置过高会怎样 ] encoded tokenizer( texts, paddingTrue, truncationTrue, max_length128, return_tensorspt ) with torch.no_grad(): outputs model(**encoded) last_hidden outputs.last_hidden_state # 这里按该模型推荐的 pooling 方式取 [CLS] 向量 sentence_embeddings last_hidden[:, 0, :] sentence_embeddings torch.nn.functional.normalize(sentence_embeddings, p2, dim1) print(sentence_embeddings.shape) # (3, hidden_size)这里有几个关键操作值得展开说明。第一max_length设成 128 是经验值大部分检索场景的单条文本比如一个知识库段落、一个用户问题都在这个范围内。如果超出truncation 会把多余部分截断所以长文必须先切片。第二normalize这一步很重要将向量归一化成单位向量之后后续计算余弦相似度就直接相当于做点积计算性能会好很多这个技巧在构建大索引时尤其关键。第三不同的模型对句向量的推荐池化方式不一样有的是取第一行有的是对所有 token 取平均务必查看你所用模型的说明文档。不要想当然认为所有模型都一样。3.3 构建索引与语义检索不依赖数据库的最小实现拿到向量之后下一步就是检索。为了让你看清原理这里先不引入任何向量数据库直接用 Python 列表加 numpy 实现一个最小可用检索流程。import numpy as np # 假设 doc_embeds 是一个 (N, hidden_size) 的矩阵每行是一条文档的向量 doc_embeds np.array(sentence_embeddings) # 模拟一个查询 query_text 多肉叶子发软怎么办 query_encoded tokenizer( query_text, truncationTrue, max_length128, return_tensorspt ) with torch.no_grad(): query_outputs model(**query_encoded) query_vec query_outputs.last_hidden_state[:, 0, :].numpy() query_vec query_vec / np.linalg.norm(query_vec, axis1, keepdimsTrue) # 归一化后点积就是余弦相似度 scores np.dot(doc_embeds, query_vec.T).flatten() # 获取 top-k k 2 top_k_idx scores.argsort()[-k:][::-1] for idx in top_k_idx: print(f相似度: {scores[idx]:.4f}, 文本: {texts[idx]})这段代码的核心在np.dot(doc_embeds, query_vec.T)因为所有向量都已经归一化所以点积结果等价于余弦相似度而且用矩阵运算一次算完所有文档的相似度比循环快得多。道理很简单余弦公式的分子是点积分母是模长乘积模长都归一化成 1 之后分母就消失了。但要注意这种暴力遍历在文档数量超过几十万之后就会变慢。生产环境的标准做法是引入基于 ANN近似最近邻的索引结构常见的有 HNSW、IVF-PQ 等。HNSW 的基本思路是给这些向量建立一张多层图索引检索时从顶层往下逐层逼近最近邻速度能提升好几个数量级而召回率损失可控。你可以把 ANN 理解成图书馆里的分类标签你不必一本一本地翻完全部书只需要顺着分类标签找到对应的书架就好。这些索引能力通常由专门的向量数据库提供但它们的核心数据结构并不神秘理解“归一化后点积即为相似度”这一点后面迁移到任何数据库都轻松。3.4 与大模型结合从语义检索到最小 RAG 问答上面我们已经能把用户 query 转换成向量并从库里召回最相关的文本段。这就已经具备了做一个最小 RAG 问答的全部前置条件。剩下要做的事只有一件把召回结果放进 Prompt 里让大模型基于这些参考文本来回答。我平时项目里的做法很简单构造一个带参考材料的 Promptprompt f 请根据以下参考资料回答用户问题。如果参考资料中没有相关信息 请明确回答“资料中未找到相关内容”不要编造。 参考资料 1. {relevant_docs[0]} 2. {relevant_docs[1]} 用户问题{query_text} 把这段 Prompt 发给大模型接口得到回答。这就是 RAG 最朴素的表达。你也能直观感受到 Embedding 在整条链路中的地位召回对了大模型回答就靠谱召回错了模型再会表达也只会基于错误信息编一个听起来合理的答案。建议你在这个 Demo 上先手动对比一下不同模型的召回结果真的能直观看出向量模型之间的差距。如果要做得更完善一点还可以在 Recall 之后加一层 Rerank精排模型把召回的候选段落重新打个分。Rerank 和 Embedding 双塔不同它通常是把 query 和 document 拼在一起做深度交互精度更高但计算代价更大所以适合放在召回之后做小范围精排。这也是我下一篇文章想展开的内容。4. 常见问题与避坑实测中踩过的五个根因4.1 向量维度不一致换模型后库就废了这应该是最常见、也是最疼的一个坑。我接过一个线上排查现象是检索服务突然报维度错误查了半天发现是底层嵌入模型版本在后台升级了新接口输出的向量从 768 维变成了 1024 维。旧库里存的还是 768 维的向量两边直接矩阵相乘维度对不上整个检索链路直接瘫痪。更隐蔽的问题是如果升级后的模型维度碰巧还是 768 维程序不报错但向量空间已经变了相似度结果完全失真。所以从一开始就要在向量库中给每个 collection 记录“用了哪个模型、什么版本、多少维度”。一旦换模型宁可全量重建向量库也不要新旧混用。我个人的习惯是每次构建索引时都把模型名作为 collection 名称的一部分比如kb_docs_v2_768从源头杜绝混淆。4.2 相似度数值范围不同阈值不是拍脑袋定的很多开发者在做语义检索时会给自己设定一个相似度阈值比如“相似度大于 0.75 才算命中”。这个数值看起来合理但它跟模型、向量维度、度量方式都有关不同模型产出的相似度分布差异非常大。有的模型在合理语义匹配上的余弦相似度可能普遍在 0.6 左右有的模型则普遍出现在 0.8 以上。直接用一个拍脑袋的阈值要么召回一堆噪声要么把该召回的文本全部挡在门外。我建议的做法是准备一批业务正样本和负样本把它们的相似度分数分别画出来看两个分布的重叠区间再决定阈值设在哪里。这不是多出来的工作量而是检索系统调优的基本功。4.3 短查询与长文档的粒度错配RAG 场景里最常见的失败模式是用户问题只有十几个字而知识库里存的是上百字的长段落。直接把长段落整体向量化再去跟短问题算相似度效果通常很一般。因为长段落里夹杂了大量无关信息向量会被这些信息稀释导致整体表示偏离核心主题。我最后采用了文档切片方案按章节把文档切成 200 到 500 字的片段相邻片段之间保留 50 字左右的重叠保证语义不断裂。做法是找标题层级先切找不到标题就按段落数和 token 数估算。切片之后每个片段的核心语义更集中检索命中率明显提升。如果你在调检索效果时发现“怎么都召回不到点上”第一个要怀疑的往往不是模型而是切片太粗。4.4 脏数据与预处理全角半角、格式符号和 Token 截断还有一次线上问题很有意思有个包含英文冒号的文档在系统中以全角冒号存储用户在搜索时输入的却是半角冒号。这个差异在人眼看来毫无区别但进入模型之后字符表示完全不同向量自然也不同。类似的问题还包括直接把 HTML 标签、Markdown 语法字符当成正文去向量化文本里夹杂了大量换行符和不可见字符长文被截断后语义断裂。这些问题单个看影响不大但累积起来会让检索效果一团糟。我的建议是在向量化之前定义一个标准清洗函数统一半角转换、去标签、去超长空白再按 token 数检查是否超过模型最大长度。清洗和切片放在向量化之前而不是之后这是很多人容易忽略的顺序问题。4.5 通用模型与领域场景不匹配最后一个典型问题是场景不匹配拿通用中文向量模型去处理代码注释检索、专业术语密集的法律文书或医疗文本效果往往远低于预期。这不是模型“差”而是它的预训练语料里这些领域的高质量数据占比有限。一个直观的实验方法挑一组你自己的领域相似句对和不同句对跑一下模型看区分度。如果区分度不够有几个升级路径优先看有没有现成的领域微调模型其次是自己采集领域语料做二次微调最稳妥的是同时引入 Rerank 模型做精排兜底。这里提醒一句训练自己的 embedding 模型不是入门者该碰的深水区需要足够的算力和高质量标注数据普通团队基本靠领域微调版本加精排就能搞定。4.6 实测问题速查表为了平时排查方便我把上面这些典型问题整理成一张速查表直接贴在项目文档里遇到对应现象可以快速定位。现象可能原因排查思路解决方法检索报维度错误模型升级或版本替换后维度变化检查入库向量维度与查询向量维度记录模型版本与维度全量重建索引阈值设置后召回质量差不同模型相似度分布差异大抽样统计正负样本分数分布根据业务样本分布重新计算阈值长文档总是难以命中文本粒度太粗语义被稀释检查索引单元是否过长做 200-500 字切片并保留重叠相似字符形式不同导致漏召回全角半角、编码格式不统一检查原始文本和数据清洗流程向量化前统一清洗文本格式领域专业词检索效果差通用模型与业务领域不匹配用领域样本对跑简单评测换领域模型或叠加 Rerank 精排向量库检索命中但答案质量差Embedding 召回上限不足检查召回的段落是否包含正确信息先优化切片和模型再考虑精排除了表格里的常规问题还有一个容易踩到的隐性坑是批次处理时内存波动。向量化接口如果一次传入上千条长文本峰值显存和内存都会明显上涨一不留神就 OOM。我的建议是分批处理每批控制在 32 到 64 条并且做好失败重试逻辑。批量处理看起来简单但批大小、文本长度分布都会影响最终吞吐值得提前压测一下。我在实际项目中反复验证过一个体会Embedding 这条链路是整个 RAG 系统里最值得花时间打磨的地方。很多团队一上来就想着用大模型做生成优化却忽略了前置的检索质量检索召不回正确内容生成再怎么调也只是在错误的地基上盖楼。如果你动手搭这个 Demo我建议你先不要急着接向量数据库、不要急着接大模型就用自己的业务数据跑一遍向量化和手工检索把每一步输出都打出来看看。只有亲手看过向量怎么生成、相似度怎么计算、召回结果为什么好或为什么坏后面再上复杂系统时你才有足够敏锐的判断力去定位问题。这篇文章的核心代码都是最小实现但每一步背后的原理都是通用的顺着这个路径把基础打扎实了后续不管换模型还是换索引方案都不会慌。
最近在折腾一个基于大模型的内部知识库问答系统检索效果一直不理想调来调去发现根子都出在 Embedding 上。这篇是大模型开发系列的第三篇专门把 Embedding 技术从原理到落地完整捋一遍。如果你正在做 RAG 检索增强、语义搜索、智能问答这类应用或者已经调过向量接口但感觉“知其然不知其所以然”这篇文章基本能帮你把这条链路彻底打通。文章里的代码都是最简可用版本直接复制到开发环境就能跑跟着走一遍比自己看十篇文档都管用。1. Embedding 解决的核心问题先弄清它到底扮演什么角色1.1 为什么大模型需要 Embedding而不是直接“认识”文字大语言模型本质上是一个文本生成模型它吃进去的是字符串吐出来的也是字符串。但模型的内部计算全部发生在数值空间中Transformer 结构只能处理浮点数矩阵不能处理字符本身。所以任何一个大模型在真正开始“思考”之前都要先把输入文本切成一串 token再通过一个嵌入矩阵Embedding Matrix把每个 token 映射成一个稠密向量。这就是 Embedding 最底层的角色。这里有一个特别容易混淆的点我见过不少同学栽在这里。大模型内部的 Embedding 是 token 粒度的每个词元一个向量而且要经过多层注意力网络之后每个 token 的向量会带上上下文信息不再是孤立的静态查表。而我们在做应用开发时调用的“文本向量接口”返回的通常是一整句或一整段的向量比如 1024 维。这个句向量往往是模型最后一层的隐状态做池化pooling得到的。一个是 token 粒度一个是句子粒度空间层级不一样用途也完全不同。前者服务于语言模型的词元预测后者服务于我们自己的语义检索和相似度计算。大家刚开始上手时一定别把这两层混为一谈。很多教程讲 Embedding 会从 Word2Vec 开始讲那是词嵌入时代的老黄历了。现在的关键认知是在应用层Embedding 就是把任意一段文本映射成一个固定长度的数值向量并且在语义相近的文本之间向量的几何距离也相近。1.2 RAG 的地基召回上限由向量质量决定我把 Embedding 叫作 RAG 的“眼睛”。因为 RAG检索增强生成那条链路里系统先根据用户问题去知识库里捞相关段落再把捞到的段落拼进 Prompt 交给大模型生成答案。整个链路里那个“捞”的动作绝大多数时候就是在做向量近邻检索。用户的问题被编码成 query 向量知识库里的每段文本被编码成候选向量系统通过计算向量之间的距离或相似度把最接近的几个段落挑出来。这个环节一旦出了问题后续所有环节都救不回来。重排模型再厉害也只是在给定候选集里调整顺序如果 Embedding 本身就召不回正确的段落重排模型连看到正确文档的机会都没有。大模型生成能力再强喂进去的是无关内容它也只会一本正经地编。所以从工程价值上讲Embedding 决定了整个 RAG 系统的召回上限这比我后面要讲的所有技巧都重要。可以用一个特别生活化的类比来理解想象你是一个图书管理员用户跑来问你“怎么防止家里的绿萝烂根”。你脑子里把每本书都抽象成一条索书号然后根据语义相关性快速锁定几本园艺书籍。这个“索书号”质量好不好决定了你能不能在几十万册藏书里把那本真正讲到浇水频率的书捞出来。Embedding 扮演的正是这个“索书号”的角色。1.3 适用范围和选型思路概述Embedding 的典型应用场景包括语义检索、知识库问答、文本去重、聚类分析、推荐召回、异常检测等。在实际开发中最常见的需求就两类一是给文本做向量化存储二是根据查询向量做相似度召回。不管是做哪一种核心动作是一样的把文本变成向量把相似度计算做到又快又准。文章后面的内容会分成四个部分推进先搞清楚 Embedding 的底层训练逻辑和模型选型再带你完整落地一个小型语义检索系统然后结合大模型做成一个最简单的 RAG 问答最后把我在实际项目中踩过的一些坑集中整理出来。整体路线就是从原理到工程一步一步打通。2. Embedding 的底层逻辑与模型选型训练原理、指标与维度2.1 语言模型内部的 Embedding 层从静态词向量到上下文表示上一节我提到了 token 粒度的 Embedding。更深一层说在大模型内部初始的 token embedding 只是一个高维查表模型记着一本“词表”每个 token 对应一列可学习的浮点数参数。经过训练之后语义相近的 token 在这个原始嵌入空间里会靠得更近。随着层数加深每个 token 的表示不再只依赖自己而是通过注意力机制融合了句子中其他 token 的信息。所以到最后一层每个 token 的向量其实已经是“上下文感知的表示”。具体到代码层面你用开源的深度学习框架加载一个预训练语言模型时输入一批文本模型会返回一个形状为(batch_size, seq_len, hidden_size)的三维张量。这个张量里包含了每个 token 在最后一层 Transformer 输出中的向量。如果我们只想要一个句子级的向量常见的做法有三种取[CLS]位置的向量这是很多预训练模型专门为句级分类任务设计的标记位对序列维度做平均池化mean pooling把每个 token 的向量取平均对序列维度做最大池化max pooling取每个维度上的最大值。不同模型对池化方式有自己的推荐这一点后面实操部分我会提到。现在只需要记住模型输出的原始张量不是句向量你需要按模型官方推荐的方式做池化才会得到适合做检索的句子向量。很多初学者在这个地方踩坑直接拿第一个 token 的向量去跟库里做对比结果效果飘忽不定。2.2 文本向量模型的训练思路对比学习和双塔结构明白了“怎么用”之后还得知道“怎么来”。市面上所有优秀的开源文本向量模型核心训练思路几乎都是对比学习跟教一个小孩子认东西有点像。你得先准备大量“语义相似对”作为训练数据两个句子意思相近就组成一个正样本对随机抽两个不相关的句子就组成负样本对。训练目标相当直观同一个 batch 里让语义相近的句子向量相互靠近让语义不相关的句子向量相互远离。这里面有个非常关键的工程细节叫“批次内负样本”in-batch negatives。具体做法是一个 batch 里有 N 个句子分别编码得到 N 个向量对于其中第 i 个句子把 batch 里其他 N-1 个句子的向量都当作负样本参与训练。这样做的数据效率特别高不需要额外采样大量负样本训练成本一下就降下来了。现在很多开源向量模型的训练脚本基本都有这个设计你可以把它理解成“用同一桌吃饭的其他人来当陪练”特意去外面找反例反而没这么高效。模型架构上普遍采用双塔结构一个 query 编码塔一个 document 编码塔两个塔共享参数或者各自独立分别把 query 和 document 编码成向量。双塔的好处是query 和 document 可以离线分别向量化在线检索时只需要对 query 做一次正向计算然后去向量索引里做近邻检索。这种解耦设计是支撑大规模语义检索在工程上落地的基础。不然每次查询都要把所有文档重新编码一遍那算力谁也扛不住。2.3 Embedding 模型选型的关键指标选 Embedding 模型时我通常关注这几个硬指标输出维度一般是 768、1024、1536 等。维度越高单条向量的表达能力通常越强但存储成本和计算成本也越高。做粗召回的话不需要盲目追高512 维或者 768 维在很多场景下足够。最大输入长度常见的是 512 token 或 1024 token。超出会被截断所以长文档要提前切分好不能把一整页文本直接丢进去。语言支持中文场景必须看中文效果很多英文效果好的模型中文表现并不理想需要看公开检索榜单上的中文成绩。检索任务指标有些模型专门在语义相似度STS任务上优化有些模型专门在检索任务上优化。如果你的目标是做 RAG就应该优先看检索类评测的结果而不是只看相似度分数。是否支持领域微调垂类场景比如医疗、法律、代码下通用向量模型往往表现一般。碰到这种情况优先找有没有领域适配版本或者自己准备一批领域语料做微调。我在实际选型时还喜欢做一个小实验准备 20 组人工标注好的“相似/不相似”句子对分别用候选模型编码计算相似度分数直接看两个分布的重叠程度。这个实验十分钟就能跑完比看任何榜单都直观。榜单是平均表现而你的业务场景永远有自己独特的表达习惯。2.4 维度选择与存储成本的经验法则很多人在项目初期会纠结“是不是维度越高越好”。我的经验是先看检索场景的规模再看业务对召回精度的敏感度。如果知识库只有几万条文档用 768 维完全够如果到了千万级规模就需要考虑 512 维配合量化、分片等手段。高维度带来的收益在规模变大之后会边际递减而存储和内存的开销却会线性上升。还有一点很重要不同模型产出的向量不能互相混用。比如你之前用 A 模型生成了一批向量存进数据库后来换了 B 模型如果直接拿 B 模型的 query 向量去跟 A 模型的历史向量做相似度计算得到的结果基本没有参考意义。因为不同模型的向量空间是不一样的维度相同不代表坐标系相同。这个坑我在后文第 4 章会详细讲这里先提醒一下上线前就要在向量库里登记模型编号和维度否则得全量重建向量。3. Embedding 落地实践一个小型语义检索系统的完整实现3.1 环境准备与基础工具链下面我带着你完整实现一个“文档库语义检索”的 Demo。先说明环境Python 3.9 以上机器上有 PyTorch 以及对应的预训练模型加载库就够了。没有 GPU 也能跑选一个小一些的开源模型即可。我建议直接用一个已有的开源中文向量模型放在本地目录“local_embedding_model”里方便后面统一加载。在开始之前先把依赖准备好pip install torch transformers numpy如果是 CPU 环境安装的是 CPU 版 PyTorch跑一个小规模 demo 没问题只是生成向量的速度会慢一些。这一步没有太多技巧但要注意 Python 版本不要太高个别库对 3.12 以上的兼容性还没有完全跟上建议先用 3.10。3.2 生成向量把一段文本变成坐标用加载库加载本地模型对一批文本生成句向量做法如下from transformers import AutoTokenizer, AutoModel import torch model_dir local_embedding_model tokenizer AutoTokenizer.from_pretrained(model_dir) model AutoModel.from_pretrained(model_dir) model.eval() texts [ 如何防止多肉植物烂根, 多肉植物的浇水频率需要根据季节调整。, 深度学习模型训练时学习率设置过高会怎样 ] encoded tokenizer( texts, paddingTrue, truncationTrue, max_length128, return_tensorspt ) with torch.no_grad(): outputs model(**encoded) last_hidden outputs.last_hidden_state # 这里按该模型推荐的 pooling 方式取 [CLS] 向量 sentence_embeddings last_hidden[:, 0, :] sentence_embeddings torch.nn.functional.normalize(sentence_embeddings, p2, dim1) print(sentence_embeddings.shape) # (3, hidden_size)这里有几个关键操作值得展开说明。第一max_length设成 128 是经验值大部分检索场景的单条文本比如一个知识库段落、一个用户问题都在这个范围内。如果超出truncation 会把多余部分截断所以长文必须先切片。第二normalize这一步很重要将向量归一化成单位向量之后后续计算余弦相似度就直接相当于做点积计算性能会好很多这个技巧在构建大索引时尤其关键。第三不同的模型对句向量的推荐池化方式不一样有的是取第一行有的是对所有 token 取平均务必查看你所用模型的说明文档。不要想当然认为所有模型都一样。3.3 构建索引与语义检索不依赖数据库的最小实现拿到向量之后下一步就是检索。为了让你看清原理这里先不引入任何向量数据库直接用 Python 列表加 numpy 实现一个最小可用检索流程。import numpy as np # 假设 doc_embeds 是一个 (N, hidden_size) 的矩阵每行是一条文档的向量 doc_embeds np.array(sentence_embeddings) # 模拟一个查询 query_text 多肉叶子发软怎么办 query_encoded tokenizer( query_text, truncationTrue, max_length128, return_tensorspt ) with torch.no_grad(): query_outputs model(**query_encoded) query_vec query_outputs.last_hidden_state[:, 0, :].numpy() query_vec query_vec / np.linalg.norm(query_vec, axis1, keepdimsTrue) # 归一化后点积就是余弦相似度 scores np.dot(doc_embeds, query_vec.T).flatten() # 获取 top-k k 2 top_k_idx scores.argsort()[-k:][::-1] for idx in top_k_idx: print(f相似度: {scores[idx]:.4f}, 文本: {texts[idx]})这段代码的核心在np.dot(doc_embeds, query_vec.T)因为所有向量都已经归一化所以点积结果等价于余弦相似度而且用矩阵运算一次算完所有文档的相似度比循环快得多。道理很简单余弦公式的分子是点积分母是模长乘积模长都归一化成 1 之后分母就消失了。但要注意这种暴力遍历在文档数量超过几十万之后就会变慢。生产环境的标准做法是引入基于 ANN近似最近邻的索引结构常见的有 HNSW、IVF-PQ 等。HNSW 的基本思路是给这些向量建立一张多层图索引检索时从顶层往下逐层逼近最近邻速度能提升好几个数量级而召回率损失可控。你可以把 ANN 理解成图书馆里的分类标签你不必一本一本地翻完全部书只需要顺着分类标签找到对应的书架就好。这些索引能力通常由专门的向量数据库提供但它们的核心数据结构并不神秘理解“归一化后点积即为相似度”这一点后面迁移到任何数据库都轻松。3.4 与大模型结合从语义检索到最小 RAG 问答上面我们已经能把用户 query 转换成向量并从库里召回最相关的文本段。这就已经具备了做一个最小 RAG 问答的全部前置条件。剩下要做的事只有一件把召回结果放进 Prompt 里让大模型基于这些参考文本来回答。我平时项目里的做法很简单构造一个带参考材料的 Promptprompt f 请根据以下参考资料回答用户问题。如果参考资料中没有相关信息 请明确回答“资料中未找到相关内容”不要编造。 参考资料 1. {relevant_docs[0]} 2. {relevant_docs[1]} 用户问题{query_text} 把这段 Prompt 发给大模型接口得到回答。这就是 RAG 最朴素的表达。你也能直观感受到 Embedding 在整条链路中的地位召回对了大模型回答就靠谱召回错了模型再会表达也只会基于错误信息编一个听起来合理的答案。建议你在这个 Demo 上先手动对比一下不同模型的召回结果真的能直观看出向量模型之间的差距。如果要做得更完善一点还可以在 Recall 之后加一层 Rerank精排模型把召回的候选段落重新打个分。Rerank 和 Embedding 双塔不同它通常是把 query 和 document 拼在一起做深度交互精度更高但计算代价更大所以适合放在召回之后做小范围精排。这也是我下一篇文章想展开的内容。4. 常见问题与避坑实测中踩过的五个根因4.1 向量维度不一致换模型后库就废了这应该是最常见、也是最疼的一个坑。我接过一个线上排查现象是检索服务突然报维度错误查了半天发现是底层嵌入模型版本在后台升级了新接口输出的向量从 768 维变成了 1024 维。旧库里存的还是 768 维的向量两边直接矩阵相乘维度对不上整个检索链路直接瘫痪。更隐蔽的问题是如果升级后的模型维度碰巧还是 768 维程序不报错但向量空间已经变了相似度结果完全失真。所以从一开始就要在向量库中给每个 collection 记录“用了哪个模型、什么版本、多少维度”。一旦换模型宁可全量重建向量库也不要新旧混用。我个人的习惯是每次构建索引时都把模型名作为 collection 名称的一部分比如kb_docs_v2_768从源头杜绝混淆。4.2 相似度数值范围不同阈值不是拍脑袋定的很多开发者在做语义检索时会给自己设定一个相似度阈值比如“相似度大于 0.75 才算命中”。这个数值看起来合理但它跟模型、向量维度、度量方式都有关不同模型产出的相似度分布差异非常大。有的模型在合理语义匹配上的余弦相似度可能普遍在 0.6 左右有的模型则普遍出现在 0.8 以上。直接用一个拍脑袋的阈值要么召回一堆噪声要么把该召回的文本全部挡在门外。我建议的做法是准备一批业务正样本和负样本把它们的相似度分数分别画出来看两个分布的重叠区间再决定阈值设在哪里。这不是多出来的工作量而是检索系统调优的基本功。4.3 短查询与长文档的粒度错配RAG 场景里最常见的失败模式是用户问题只有十几个字而知识库里存的是上百字的长段落。直接把长段落整体向量化再去跟短问题算相似度效果通常很一般。因为长段落里夹杂了大量无关信息向量会被这些信息稀释导致整体表示偏离核心主题。我最后采用了文档切片方案按章节把文档切成 200 到 500 字的片段相邻片段之间保留 50 字左右的重叠保证语义不断裂。做法是找标题层级先切找不到标题就按段落数和 token 数估算。切片之后每个片段的核心语义更集中检索命中率明显提升。如果你在调检索效果时发现“怎么都召回不到点上”第一个要怀疑的往往不是模型而是切片太粗。4.4 脏数据与预处理全角半角、格式符号和 Token 截断还有一次线上问题很有意思有个包含英文冒号的文档在系统中以全角冒号存储用户在搜索时输入的却是半角冒号。这个差异在人眼看来毫无区别但进入模型之后字符表示完全不同向量自然也不同。类似的问题还包括直接把 HTML 标签、Markdown 语法字符当成正文去向量化文本里夹杂了大量换行符和不可见字符长文被截断后语义断裂。这些问题单个看影响不大但累积起来会让检索效果一团糟。我的建议是在向量化之前定义一个标准清洗函数统一半角转换、去标签、去超长空白再按 token 数检查是否超过模型最大长度。清洗和切片放在向量化之前而不是之后这是很多人容易忽略的顺序问题。4.5 通用模型与领域场景不匹配最后一个典型问题是场景不匹配拿通用中文向量模型去处理代码注释检索、专业术语密集的法律文书或医疗文本效果往往远低于预期。这不是模型“差”而是它的预训练语料里这些领域的高质量数据占比有限。一个直观的实验方法挑一组你自己的领域相似句对和不同句对跑一下模型看区分度。如果区分度不够有几个升级路径优先看有没有现成的领域微调模型其次是自己采集领域语料做二次微调最稳妥的是同时引入 Rerank 模型做精排兜底。这里提醒一句训练自己的 embedding 模型不是入门者该碰的深水区需要足够的算力和高质量标注数据普通团队基本靠领域微调版本加精排就能搞定。4.6 实测问题速查表为了平时排查方便我把上面这些典型问题整理成一张速查表直接贴在项目文档里遇到对应现象可以快速定位。现象可能原因排查思路解决方法检索报维度错误模型升级或版本替换后维度变化检查入库向量维度与查询向量维度记录模型版本与维度全量重建索引阈值设置后召回质量差不同模型相似度分布差异大抽样统计正负样本分数分布根据业务样本分布重新计算阈值长文档总是难以命中文本粒度太粗语义被稀释检查索引单元是否过长做 200-500 字切片并保留重叠相似字符形式不同导致漏召回全角半角、编码格式不统一检查原始文本和数据清洗流程向量化前统一清洗文本格式领域专业词检索效果差通用模型与业务领域不匹配用领域样本对跑简单评测换领域模型或叠加 Rerank 精排向量库检索命中但答案质量差Embedding 召回上限不足检查召回的段落是否包含正确信息先优化切片和模型再考虑精排除了表格里的常规问题还有一个容易踩到的隐性坑是批次处理时内存波动。向量化接口如果一次传入上千条长文本峰值显存和内存都会明显上涨一不留神就 OOM。我的建议是分批处理每批控制在 32 到 64 条并且做好失败重试逻辑。批量处理看起来简单但批大小、文本长度分布都会影响最终吞吐值得提前压测一下。我在实际项目中反复验证过一个体会Embedding 这条链路是整个 RAG 系统里最值得花时间打磨的地方。很多团队一上来就想着用大模型做生成优化却忽略了前置的检索质量检索召不回正确内容生成再怎么调也只是在错误的地基上盖楼。如果你动手搭这个 Demo我建议你先不要急着接向量数据库、不要急着接大模型就用自己的业务数据跑一遍向量化和手工检索把每一步输出都打出来看看。只有亲手看过向量怎么生成、相似度怎么计算、召回结果为什么好或为什么坏后面再上复杂系统时你才有足够敏锐的判断力去定位问题。这篇文章的核心代码都是最小实现但每一步背后的原理都是通用的顺着这个路径把基础打扎实了后续不管换模型还是换索引方案都不会慌。
