RAG-embedding篇

1.前言

RAG飞速发展，成为连接“生成能力”与“外部知识”的桥梁，关于RAG的介绍可以参考
什么是RAG？一文搞懂检索增强生成技术。

前面我们介绍了RAG系统中的文档解析，
RAG 的文档解析：PDF 篇，在解析文档得到数据后，由于数据规模很可能非常庞大，整体存储具有难度，并且在查询的时候可能仅仅和其中的一个或几个段落有关系，所以需要分块技术将解析后的文档内容切分为适当的片段
一分钟读懂RAG的切分策略。

切分完成后，需要将内容存储到向量数据库以供后续检索，下面我们就来看看怎么进行存储。

2.什么是embedding

Embedding（嵌入向量） 是将文字、图片、语音等“人类语言”转换为“计算机语言”的关键一步。它的作用，是把一句话或者一个词，变成一串可以进行数学运算的数字向量，让模型能“理解”我们在说什么。

计算机不懂“情绪”“背景”“常识”，它只能处理数字。所以如果我们问它：“北京和上海哪个更大？”它必须先把这句话变成数字（向量），再去和知识库里的内容做匹配——这就靠 embedding。

如果没有 embedding，AI 就像一个英语六级都没过的“文盲”，你说什么，它都回你：“对不起，我不明白。”

经典例子：

embedding(国王) - embedding(男人) + embedding(女人) ≈ embedding(女王)

这就像告诉 AI：“把男人换成女人，但身份还保留”，于是就得到了“女王”。

我们也可以来个幽默中文版：

embedding(程序员) - embedding(秃头) + embedding(头发浓密) ≈ 理想中的程序员

 在 RAG 系统中，Embedding 的任务：

·把文档每个段落、用户提问，都转成向量。

·用这些向量去做“语义检索”，找出最相关的内容。

·最后喂给大模型生成回答，回答才“有根有据”。

3.选择嵌入模型

在 RAG 系统中，嵌入模型（Embedding Model）就像是用户与知识库之间的翻译官——它决定了“你在说什么”和“它能不能听懂”。

选择一个合适的嵌入模型，能大幅提升检索质量与上下文匹配度。选得好，模型如虎添翼，问啥答啥；选不好，可能“查到不对题，答得更离谱”。

以下是选型时需要重点考虑的几个维度：

4.主流嵌入模型

以下是一些主流且表现优秀的嵌入模型，涵盖中英双语、轻量级部署、本地化支持等需求。

中文 & 多语言方向

英文或通用方向

如果不知道选哪个，建议：

·小模型部署快，适合原型验证（如 bge-small-zh）

·大模型更准，适合上线产品（如 bge-large-zh-v1.5）

·想本地部署？就用 BGE、E5、GTE

·要省心云服务？那就试试 OpenAI Ada、Cohere

5、向量数据库与存储（Vector Store）

在 RAG 系统中，文档被切分成多个片段，并转换为嵌入向量后，我们需要一个专业的仓库来高效存储和管理这些向量，这就需要向量数据库。

传统数据库（如 MySQL、MongoDB）虽然擅长处理结构化数据，但它们并不擅长处理“向量之间的相似度查找”。你可以在 SQL 里找“年龄大于30岁的人”，但你很难写出一句 SQL 语句找出“语义上跟‘年龄’相似的段落”。

向量数据库专门设计来处理高维向量的相似度搜索，支持高效的 Top-K 相似查找、ANN（近似最近邻）检索、向量聚类等操作，是构建 RAG 系统不可缺的部分。

目前的主流向量数据库如下：

向量数据库并不只是“把向量扔进去”，它还支持附加一些元数据（metadata），比如：

{            
  "id": "para_12",            
  "embedding": [0.12, 0.83, ..., -0.01],            
  "metadata": {            
    "source": "环境学教科书.pdf",            
    "page": 24,            
    "title": "温室效应原理"            
  }            
}            

这样做的好处是，在检索出相关段落后，可以提供出处、页码、标题等辅助信息，不仅增强模型输出的可信度，也方便用户回溯查证。

6.总结

构建一个靠谱的 RAG 系统，不只是喂一个大模型这么简单，而是要让文档处理、切分、嵌入、检索、生成，像一套精密齿轮那样默契协作。正所谓“你给模型什么嵌入，它就给你什么回答”。

未来也许我们会看到更加智能的嵌入策略，甚至由模型动态决定怎么切、怎么嵌。但无论技术如何进化，嵌入始终是RAG系统中最“低调却有分量”的一环。

文中内容部分参考