句子嵌入（Sentence Embeddings）检索增强生成（RAG）已成为构建生成式 AI 应用的主流架构

检索增强生成RAG已成为构建生成式 AI 应用的主流架构企业选择它主要原本是可以用自有数据约束模型输出使答案更准确、可更新且更贴合业务场景。RAG 的效果在很大程度上取决于检索到的上下文质量——提升效果的常用手段包括合理切分文本块chunking、选用合适的嵌入模型与采用稳健的检索策略。嵌入embeddings是这一流程的核心它将词、句与文档映射到向量空间在该空间中语义关系变为可度量的数学关系若嵌入选型不当会带来检索噪声导致模型的输出不准确。所以本文将说明嵌入的基本原理与重要性、列出选型时的关键考量并对典型模型与适用场景给出实用建议帮助你为 RAG 系统挑选既高效又稳健的嵌入方案。什么是嵌入嵌入是对语言中含义与模式的数值化表示。这些数字帮助系统找到与问题或主题高度相关的信息。这些嵌入由嵌入模型生成。嵌入模型可以将词、图像、文档甚至声音转换为一串称为向量的数字。你可能在大语言模型语境下了解过嵌入但嵌入的历史其实更悠久。目前大多数嵌入都由语言模型创建。与给每个 token 或词分配静态向量不同语言模型会创建上下文化的词向量让词/句子/片段在不同上下文下拥有不同表示。这些向量随后可被其他系统用于各类任务。生成文本嵌入向量的方法有多种。最简单的方法是对模型产生的所有token 嵌入取平均值而高质量文本嵌入模型往往针对嵌入任务专门训练。我们可以用来生成文本嵌入 from sentence_transformers import SentenceTransformer嵌入向量的数值个数即维度取决于底层嵌入模型。可通过方法查看嵌入向量的维度。嵌入在 RAG 中为何重要语义理解嵌入将词、句子或文档转成向量数字列表让相近语义彼此靠近。这帮助系统理解语境与含义而非仅做字面匹配。高效检索RAG 需要快速找到最相关的段落或文档。嵌入让检索更快更容易通常结合 k 近邻k-NN等算法。更高准确度借助嵌入模型能识别与你问题相关的信息即使没用相同措辞。这意味着更准确、更相关的答案。嵌入的类型根据系统需要处理的信息类型不同嵌入也有多种形式。按系统需理解的信息类型划分词嵌入Word Embeddings词嵌入把每个词表示为多维空间中的一个点。含义相近的词如 dog 与 cat会彼此靠近。这帮助计算机理解词与词之间的关系而非只看拼写。常见的词嵌入模型包括Word2Vec从海量文本中学习词关系GloVe关注词的共现频率FastText将词拆成子词片段更擅长处理罕见词或拼写错误句子嵌入Sentence Embeddings有些情况需要整句才能完整表达含义。句子嵌入将整句语义捕捉为一个向量。知名的句子嵌入模型有Universal Sentence Encoder (USE)对各种句式表现良好包括问句与陈述句SkipThoughts通过预测相邻句来学习更好理解上下文与意图文档嵌入Document Embeddings文档可以是一个段落也可以是整本书。文档嵌入把全文转成单个向量便于在海量文档中检索与查询相关的内容。主流的文档嵌入模型包括Doc2Vec基于 Word2Vec 扩展适用于更长文本Paragraph Vectors类似 Doc2Vec但聚焦段落等较短文本单元图像嵌入Image EmbeddingsRAG 系统不只处理文本还可处理图像。图像嵌入将图片转为一串数字描述颜色、形状与模式。常用的图像嵌入模型是卷积神经网络CNN它对图像模式识别尤为擅长。按嵌入的特性划分嵌入具有不同特性这会影响其工作方式与适用场景稠密嵌入Dense 稠密嵌入的向量几乎每个位置都有值每个数都携带一些信息。稠密向量紧凑高效在较小空间内承载丰富细节便于快速相似度比较。稀疏嵌入Sparse 稀疏嵌入的相当多位置为 0只有少数位置有值0 不携带信息。稀疏表示有助于突出最关键的特征便于识别与众不同之处。长上下文嵌入Long Context 有时需要理解整篇文档或长对话而非短句。长上下文嵌入可一次处理大量文本。旧模型只能看短文本如果给它们整篇文章就必须切分容易丢失关键信息或主线。新模型如 BGE-M3可一次接收上千词最高 8,192 token帮助系统保留完整语义脉络。多向量嵌入Multi-Vector 通常一个对象词/文档只有一个向量多向量嵌入为每个对象分配多个向量各自刻画不同侧面。多向量能捕捉更细的特征与关系带来更丰富、更准确的结果。文本嵌入模型的关键参数在选模型前先要明确看什么指标。关键因素包括上下文窗口Context Window上下文窗口是模型一次能处理的最大文本长度。例如窗口为 512 token 的模型一次只能读 512 个词或词片更长的文本必须切分。一些模型如 OpenAI 的 text-embedding-ada-0028192 token和 Cohere 的嵌入模型4096 token可以处理更长文本。更大的上下文窗口允许处理更长文档而不丢失信息对检索长文章、论文或报告很有帮助。分词单元Tokenization Unit分词是模型将文本拆分为 token 的方式。不同模型不同子词分词BPE把词拆成更小片段如 unhappiness → un happiness有助处理生僻或新词WordPiece与 BPE 类似常用于 BERT 系列词级分词按整词拆分对稀有词支持较差分词方式影响模型对不同词尤其是非常见词的理解能力。多数现代模型采用子词分词以获得更好灵活性。维度Dimensionality维度是模型为每段文本生成的向量长度。例如有的模型输出 768 维有的 1024 维甚至 3072 维。更高维可容纳更细节但需要更多计算与存储低维更快更省但可能损失细节。词表大小Vocabulary Size即模型已知的唯一 token 数。更大的词表可覆盖更多词与语言但占更多内存更小词表更快但可能不理解生僻或专业术语。例如多数现代模型的词表规模在 30,000–50,000 之间。训练数据Training Data训练数据是模型学习的来源。通用语料来自网页、书籍等多样文本适合通用任务领域语料来自医疗、法律等专业文本擅长特定垂直领域在特定数据上训练的模型在该领域表现更好但在通用任务上可能逊色。成本Cost最后就是成本考量了它包含使用模型的费用与算力开销。取决于接入方式API 模型按用量计费如 OpenAI、Cohere开源模型使用免费但需自备硬件如 GPU和运维能力API 模型易上手但数据量大时成本上升开源自部署省授权费但需要更多搭建与维护。选择嵌入时的关键考量设计 RAG 时我首先会问系统要处理什么数据若是通用知识或客服 FAQOpenAI 的 text-embedding-3-small 这类通用嵌入通常足够若是医疗、法律或金融等专业领域BioBERT、SciBERT、Legal-BERT 等领域模型更合适它们对该领域语言与语境更敏感。若还需处理产品图片或语音查询选择多模态嵌入。CLIP 非常适合同时处理文本与图像。除此以外还需要评估查询与文档是短是长、结构化还是非结构化。有些模型擅长短文本有些更擅长长文本。嵌入维度影响很大。高维如 1536 或 4096能捕捉更细微差别与上下文通常提升检索准确性但计算与存储成本高。低维如 384 或 768更快更轻适合扩展到百万级文档代价是可能牺牲部分精度。实践中建议从 384–768 维开始性能与资源之间更均衡。现代向量数据库Pinecone、Weaviate、FAISS 等可以用量化或降维压缩嵌入让你在不显著增加内存的情况下使用更大维度。然后就是要确定计算的效率比如对于实时应用速度关键。若响应时延要求严格选择推理延迟低的模型。DistilBERT、MiniLM 等轻量模型通常足够准确且更快。最后就是评估 RAG 需要回答的问题类型以及知识库内容的结构与长度。将内容切分为合适的块大小十分关键。上下文窗口大小是获得正确答案的关键因素之一。更大的上下文窗口在处理长且复杂的文档时会更有优势能够提供更准确的回答。选择合适嵌入的基准新嵌入模型层出不穷如何跟进MTEB 是社区运营的排行榜比较 100 文本与图像嵌入模型覆盖 1000 语言。它将评估指标、任务类型与广泛领域集中在一起是选型的良好起点。Massive Multilingual Text Embedding BenchmarkMMTEB传统基准常只覆盖少数语言或领域。MMTEB 进一步扩展包含 250 语言、500 评测任务并测试更具挑战的能力如指令遵循、长文档检索、甚至代码检索。它是当前最全面的多语言嵌入基准之一。如何使用 MTEBMTEB 有助于挑选嵌入模型。不同模型在不同任务上表现各异。排行榜展示了各模型在广泛任务上的表现帮助你按自身需求缩小范围。但别被 MTEB 分数迷惑。MTEB 提供分数头部模型之间的差距往往很小。分数来自多任务平均你看不到任务间的方差。有时榜首只略胜一筹但是其实多个头部模型效果可能是一样的。当模型非常接近时平均分并不总是有意义。建议关注与你用例相似任务上的表现这通常比总分更有参考价值。你不必深挖每个数据集但知道文本类型新闻、论文、社媒等会有帮助。你可在数据集说明或样本中快速了解。MTEB 很有用但并不完美别只盯最高分找到最适配你任务的模型才是最主要的。在选择时一定要考虑你的应用需求。不存在对所有任务都最好的单一模型这也是 MTEB 存在的意义帮助你找到更合适的那个。你需要的语言是什么模型是否支持是否涉及金融、法律等专业词汇模型体量多大能否在你的硬件如笔记本上运行你的机器内存有多大模型能装得下吗最大输入长度是多少你的文本偏长还是偏短明确对项目最重要的要素后你就可以按这些特性在 MTEB 榜单中过滤模型找到既表现优秀又满足实际约束的选择。总结选择嵌入模型这件事说复杂也复杂说简单也简单。复杂在于需要考虑的因素确实很多领域匹配、上下文长度、计算成本、部署难度...每一个都可能影响最终效果简单在于只要抓住核心需求很多选择其实是自然而然的。我见过不少团队在模型选择上踩坑。有的盲目追求 MTEB 高分结果发现在自己的数据上表现平平有的为了省成本选了最便宜的方案后来发现检索质量差到用户抱怨还有的一开始就选了最复杂的多向量模型结果系统跑得很慢维护成本高得离谱。所以在大多数情况下你不需要最新最炫的模型。OpenAI 的 text-embedding-3-small、NVIDIA 的 NV-Embed-v2、甚至开源的 BGE 系列对于大部分应用场景都够用。关键是要match你的具体需求。建议先从简单的开始。选一个在你领域表现还不错的通用模型快速搭建原型看看效果。如果检索质量达不到要求再考虑换更专业的模型如果成本控制不住再优化部署方案。别想着一步到位。RAG 系统的优化是个迭代过程嵌入模型只是其中一环。有了数据、有了用户反馈你自然知道该朝哪个方向调整。