大家好，我准备开启一个全新的系列，来聊聊——RAG（Retrieval-Augmented Generation）系统的底层设计与工程实现。
你可能已经用过各种“大模型加检索”的应用：AI 助手能秒答公司文档问题、客服机器人能一口气分析十几页合同、技术问答系统好像“查阅过全网资料”……但你有没有想过：这些模型到底是怎么“知道”你提的问题答案的？模型为什么能记住一整本文档？我们把知识库接入大模型，到底做了什么？
这一切的背后，离不开三个字母：RAG。
这个系列将拆解构建一个 RAG 系统的全流程，深入剖析每个关键步骤的逻辑、技术选型与工程落地难点：
- RAG 实战指南（一）：什么是RAG？一文搞懂检索增强生成技术
- RAG 实战指南（二）：一文搞懂RAG 的文档解析
- RAG 实战指南（三）：一文搞懂RAG 的切分策略
- RAG 实战指南（四）：RAG-embedding篇
- RAG 实战指南（五）：RAG信息检索-如何让模型找到‘对的知识’
此外，所有相关源码示例、流程图、模型配置与知识库构建技巧，我也将持续更新在 Github：LLMHub，欢迎关注收藏！
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）就像是用户与知识库之间的翻译官——它决定了“你在说什么”和“它能不能听懂”。
选择一个合适的嵌入模型，能大幅提升检索质量与上下文匹配度。选得好，模型如虎添翼，问啥答啥；选不好，可能“查到不对题，答得更离谱”。
以下是选型时需要重点考虑的几个维度：
| 考量维度 | 说明 |
|---|---|
| 语义表现力 | 能否正确捕捉句子的含义？是否支持中文、多语言？ |
| 模型大小/效率 | 越大越准？不一定！推理速度、GPU/CPU占用也是关键 |
| 训练目标 | 是面向“检索”训练的（如BGE），还是面向“生成”或“通用”训练的？ |
| 向量归一化 | 是否适合 FAISS 等向量库索引（部分模型需显式归一化） |
| 开源/闭源 | 是否可部署本地？是否支持商用？ |
| 社区支持与文档 | 模型活跃度越高，调试与优化越方便 |
4.主流嵌入模型
以下是一些主流且表现优秀的嵌入模型，涵盖中英双语、轻量级部署、本地化支持等需求。
中文 & 多语言方向
| 模型名称 | 简介与特点 |
|---|---|
| BGE (BAAI) | 北京智源开源的检索导向模型，支持中文/英文，带bge-base-zh, bge-m3等版本，性能与速度兼顾。 |
| E5 系列 | 多语言嵌入模型（包括e5-base, e5-large），适用于检索任务，广泛支持中英文句子匹配。 |
| GTE 系列 | 百度提出的 GTE 模型（如 gte-base），表现稳定、部署友好，适合中文问答和文档检索。 |
| text2vec 系列 | 来自 HuggingFace 的中文句向量模型，如 shibing624/text2vec-base-multilingual，易用性高。 |
英文或通用方向
| 模型名称 | 简介与适用场景 |
|---|---|
| MiniLM / MPNet | HuggingFace SentenceTransformers 库的经典嵌入模型，轻量快速、适合低资源场景。 |
| Instructor | 支持带任务说明的嵌入（如 "Represent the query for retrieval: xxx"），效果优秀。 |
| OpenAI Ada | GPT 体系内置嵌入模型（如 text-embedding-ada-002），闭源但商用表现稳定强劲。 |
| Cohere Embed | 专注于“可控语义检索”的服务型模型，API 提供简单，商用接口友好。 |
如果不知道选哪个，建议：
- 小模型部署快，适合原型验证（如
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 系统不可缺的部分。
目前的主流向量数据库如下：
| 名称 | 特点 | 适用场景 | 是否开源 |
|---|---|---|---|
| FAISS (Meta) | 高性能、轻量、本地运行快；支持多种索引类型（Flat, HNSW, IVF） | 本地小型应用、实验原型 | ✅ 开源 |
| Milvus | 全功能向量数据库，支持 GPU 加速；和 Zilliz Cloud 集成好 | 企业级应用、大规模数据检索 | ✅ 开源 |
| Weaviate | 支持 hybrid search（关键词+向量）；RESTful API 接入简单 | 向量+关键词结合场景 | ✅ 开源 |
| Qdrant | Rust 构建，响应快、资源占用低，支持过滤条件 | 精细检索、需要元数据过滤 | ✅ 开源 |
| Pinecone | 全托管，免部署；免费额度友好 | 快速上线、无需运维场景 | ❌ 闭源 |
| Redis-Vector | Redis 插件，轻量级向量搜索 | 边缘计算、实时性强的小应用 | ✅ 开源插件 |
向量数据库并不只是“把向量扔进去”，它还支持附加一些元数据（metadata），比如：
{
"id": "para_12",
"embedding": [0.12, 0.83, ..., -0.01],
"metadata": {
"source": "环境学教科书.pdf",
"page": 24,
"title": "温室效应原理"
}
}
这样做的好处是，在检索出相关段落后，可以提供出处、页码、标题等辅助信息，不仅增强模型输出的可信度，也方便用户回溯查证。
6.总结
构建一个靠谱的 RAG 系统，不只是喂一个大模型这么简单，而是要让文档处理、切分、嵌入、检索、生成，像一套精密齿轮那样默契协作。
未来也许我们会看到更加智能的嵌入策略，甚至由模型动态决定怎么切、怎么嵌。但无论技术如何进化，嵌入始终是RAG系统中最“低调却有分量”的一环。
你给模型什么嵌入，它就给你什么回答。
文中内容部分参考
制定 RAG 解决方案 - 生成嵌入阶段 - Azure Architecture Center
非常感谢，如有侵权请联系删除！
更多相关资料在github中，系统整理与分享大语言模型（LLM）相关的核心知识、面试内容、实际应用场景及部署技巧。内容涵盖从基础概念、主流模型对比、Prompt 设计、模型微调到工程部署的完整流程，帮助开发者、研究者以及求职者高效掌握大模型领域的关键能力。
关于深度学习和大模型相关的知识和前沿技术更新，请关注公众号coting!
