RAG-embedding

大家好我准备开启一个全新的系列来聊聊——RAGRetrieval-Augmented Generation系统的底层设计与工程实现。你可能已经用过各种“大模型加检索”的应用AI 助手能秒答公司文档问题、客服机器人能一口气分析十几页合同、技术问答系统好像“查阅过全网资料”……但你有没有想过这些模型到底是怎么“知道”你提的问题答案的模型为什么能记住一整本文档我们把知识库接入大模型到底做了什么这一切的背后离不开三个字母RAG。这个系列将拆解构建一个 RAG 系统的全流程深入剖析每个关键步骤的逻辑、技术选型与工程落地难点此外所有相关源码示例、流程图、模型配置与知识库构建技巧我也将持续更新在 GithubLLMHub欢迎关注收藏1.前言RAG飞速发展成为连接“生成能力”与“外部知识”的桥梁关于RAG的介绍可以参考什么是RAG一文搞懂检索增强生成技术。前面我们介绍了RAG系统中的文档解析RAG 的文档解析PDF 篇在解析文档得到数据后由于数据规模很可能非常庞大整体存储具有难度并且在查询的时候可能仅仅和其中的一个或几个段落有关系所以需要分块技术将解析后的文档内容切分为适当的片段一分钟读懂RAG的切分策略。切分完成后需要将内容存储到向量数据库以供后续检索下面我们就来看看怎么进行存储。2.什么是embeddingEmbedding嵌入向量是将文字、图片、语音等“人类语言”转换为“计算机语言”的关键一步。它的作用是把一句话或者一个词变成一串可以进行数学运算的数字向量让模型能“理解”我们在说什么。计算机不懂“情绪”“背景”“常识”它只能处理数字。所以如果我们问它“北京和上海哪个更大”它必须先把这句话变成数字向量再去和知识库里的内容做匹配——这就靠 embedding。如果没有 embeddingAI 就像一个英语六级都没过的“文盲”你说什么它都回你“对不起我不明白。”经典例子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 / MPNetHuggingFace SentenceTransformers 库的经典嵌入模型轻量快速、适合低资源场景。Instructor支持带任务说明的嵌入如 Represent the query for retrieval: xxx效果优秀。OpenAI AdaGPT 体系内置嵌入模型如 text-embedding-ada-002闭源但商用表现稳定强劲。Cohere Embed专注于“可控语义检索”的服务型模型API 提供简单商用接口友好。如果不知道选哪个建议小模型部署快适合原型验证如bge-small-zh大模型更准适合上线产品如bge-large-zh-v1.5想本地部署就用 BGE、E5、GTE要省心云服务那就试试 OpenAI Ada、Cohere5. 向量数据库与存储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 接入简单向量关键词结合场景✅ 开源QdrantRust 构建响应快、资源占用低支持过滤条件精细检索、需要元数据过滤✅ 开源Pinecone全托管免部署免费额度友好快速上线、无需运维场景❌ 闭源Redis-VectorRedis 插件轻量级向量搜索边缘计算、实时性强的小应用✅ 开源插件向量数据库并不只是“把向量扔进去”它还支持附加一些元数据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 设计、模型微调到工程部署的完整流程帮助开发者、研究者以及求职者高效掌握大模型领域的关键能力。GitHub - zhangting-hit/LLMHub: 本项目旨在系统整理与分享大语言模型LLM相关的核心知识、面试内容、实际应用场景及部署技巧。内容涵盖从基础概念、主流模型对比、Prompt 设计、模型微调到工程部署的完整流程帮助开发者、研究者以及求职者高效掌握大模型领域的关键能力。