1 RAG检索

RAG检索：在大模型回答问题之前，先从一个知识库中“查找”相关信息的过程。为大模型找参考资料。

想象你是大模型，被问到：“苹果多少钱一斤？”

场景	你的做法	结果
没有RAG检索	凭自己记得的知识回答	“苹果大概5-10元一斤”（可能过时或错误）
有RAG检索	先查最新的价格表（RAG检索）	“根据今日批发市场数据，苹果5元一斤”（准确有依据）

RAG检索，就是那个“查价格表”的动作。

为什么需要RAG检索？

问题	没有检索	有RAG检索
知识过时	模型训练后知识就冻结了	可以实时查最新文档
私有知识	模型不知道你的内部数据	可以查公司内部文档库
幻觉问题	模型可能编造答案	基于参考资料回答，更可靠
大文件处理	上下文窗口有限	只取相关片段，不塞整本书

RAG检索 vs 关键词搜索

对比维度	传统关键词搜索	RAG检索（向量检索）
匹配方式	文字精确匹配	语义相似度匹配
“苹果多少钱”能匹配到	必须包含“苹果”、“多少钱”	能匹配“苹果价格5元”、“红富士批发价”
同义词处理	需要提前建同义词库	自动识别同义表达
检索依据	关键词命中数量	向量空间距离

它不是关键词搜索（匹配文字），而是语义搜索（匹配含义）。它的产出不是直接答案，而是给大模型的“参考资料”，让大模型能够看着资料回答，从而更准确、更及时、更可控。

2 嵌入模型

从技术架构上看，嵌入模型属于“大模型”的广义范畴，但在实际应用中，我们通常不把它叫做“大模型”。嵌入模型（Embedded Model），是为专门的任务（比如检索、推荐）生成“知识快照”的工具，它扮演的是“外挂知识库”的角色，可以灵活替换。

打个比方：一个公司里，内部通讯系统（对应模型自身的Tokenizer+嵌入层）必须使用统一编码，否则信息无法传递。但公司用的外部顾问或数据库（对应第三方嵌入模型），可以根据不同专业问题，选择不同领域的专家。

2.1 嵌入模型和生成式大模型

对比维度	嵌入模型	生成式大模型
架构类型	Encoder-only（编码器）	Decoder-only（解码器）
训练任务	对比学习 / 掩码语言模型	自回归语言建模（逐个预测下一个元素‌，即生成序列中的第n个元素时完全依赖于前n−1个已生成元素 。）
输入	任意文本	任意文本
输出	固定维度的向量（如1024个浮点数）	一段文本（逐词生成）
核心能力	语义理解 + 向量化（输出固定向量，用于比较）	语义理解 + 文本生成（ 接收 Token ID，输出下一个词）
能否对话	❌ 不能	✅ 能
参数规模	通常 1亿 ~ 10亿	通常 70亿 ~ 数千亿
例子	BGE, E5, M3E, text-embedding-3	GPT-4, LLaMA, Qwen, Claude

关联：

1. 底层架构相同：绝大多数嵌入模型和生成式模型，底层都是 Transformer。

2. 训练数据重叠：两者都在海量文本上预训练。

3. 同一个“家族”：很多嵌入模型甚至是从生成式模型派生出来的。例如：GPT → 取最后一层输出作为文本向量。LLaMA → 可以 finetune 微调成嵌入模型。

2.2 嵌入模型和嵌入层

对比维度	模型自带的嵌入层	独立/第三方嵌入模型
核心用途	词义理解。将输入的Token转化为模型能“思考”的向量，是模型内部计算的第一步。	语义检索。为海量外部知识（文档、数据库）创建索引和嵌入向量，用于外部的知识查找和比对。
依赖关系	强绑定。必须和模型的权重、Tokenizer使用同一套，否则模型会“读不懂”输入。其参数在模型训练时已固化。	松耦合。作为一个独立服务或模型存在，只要输入输出格式对齐，数据库或应用可以随时替换它。
应用场景	贯穿大模型每次生成回答的全过程。	主要用于检索增强生成（RAG）、语义搜索、推荐系统等需要理解“用户 query”与“外部知识”相似度的场景。

3 RAG检索和嵌入模型的应用

RAG（检索增强生成） 这类应用，架构是模块化的，它把用户问题和向量数据库连接起来，输出相关文本块。

3.1 检索增强生成流程

大模型本身像一个知识被封存在某个时间点（训练数据截止日期）的优等生。要让它使用你私有的、最新的外部文档库，不能重新训练它，而是要用一种“开卷考试”的思路。

在把问题扔给大模型之前，先去你的文档库里找到相关的资料，然后把“问题”和“资料”打包一起给模型，让它参考“资料”回答“问题”。

流程：用户问题 → 嵌入模型 → 向量 → 去数据库里找相似文档 → 把找到的原始文本拿出来 → 和问题合并 → 送给大模型 →生成答案

整个流程中，嵌入模型是作为一个独立的组件在工作。它只负责一件事：把文档或问题，都转换成能够进行数学比较的向量。问题和文档用同一个模型编码，相似度计算要求必须是“同一个模型”，RAG的核心操作是计算两个向量的余弦相似度或点积。因此，建库时用哪个嵌入模型，查询时必须用同一个。

嵌入模型作为可替换的独立组件，可实现如下优化目标：

• 追求性能与成本：比如，可以从收费的 OpenAI 模型，切换到本地免费开源的 nomic-embed-text 模型，虽然牺牲一点绝对精度，但换来了零成本和数据隐私。

• 追求特定语言的效果：比如在繁体中文场景下，实测替换为 multilingual-e5-large 后，检索准确度比许多通用模型更高。

• 应对不同的数据结构：比如，处理专业领域术语（如医疗、法律）时，使用在这些语料上继续训练过的领域模型，效果会远好于通用模型。

当然，切换时有几个必须注意的事项：

• 一致性：给文档建库时用的模型，和给用户问题编码用的模型，必须是同一个，否则两者会被映射到不同的数学空间，无法比较。

• 维度匹配：新模型产生的向量维度（比如768维或1024维），必须和你的向量数据库里已存储的维度一致，否则会报错。

嵌入向量仅用于检索，不会被直接送入大模型。大模型实际“看到”和处理的，始终是原始文本（Token序列），而不是嵌入向量。

3.2 流程说明

这个过程分为准备阶段（建库）和使用阶段（查询）。

准备阶段：外部文档 → 切块 → 嵌入模型 → 存向量数据库
使用阶段：用户问题 → 相同嵌入模型 → 问题向量 → 检索相似文档块 → 组装Prompt → 大模型生成回答

3.2.1 第一阶段：准备知识库

这个阶段的目的是把你的外部文档（PDF、Word、网页等）变成大模型能“快速查阅”的格式。它由上面提到的嵌入模型来主导。

1. 文档加载与切块：读取文档，但大模型的“注意力”有限，不能一次性看一整本书。所以要把文档切分成一个个小的“文本块”（Chunk），比如500个字一段。

2. 向量化（关键步骤）：用嵌入模型（如 BGE, E5）把每个“文本块”转换成一个代表其语义的向量（一串数字）。

3. 存入向量数据库：把这些“文本块”和它的“语义向量”作为键值对，存入一个专门的向量数据库（如 Chroma, Pinecone, Milvus）。这个数据库，就是大模型“开卷考试”时的“参考书架”。

3.2.2 第二阶段：使用知识库回答

当你向系统提问时，系统会执行以下“检索-生成”三步曲：

1. 问题向量化：系统会使用与建库时完全相同的那个嵌入模型，把你的问题也转换成一个向量。

2. 相似性检索：拿着问题的向量，去向量数据库里搜索，找出在语义上最相似的几个“文本块”。

3. 增强生成：这一步调用大模型。系统会构造一个提示词，把“检索到的相关文本块”和“你的原始问题”都放进去，然后让大模型根据提供的参考资料来生成答案。

3.3 代码实现流程：从嵌入到检索到生成

# 1. 用户问题
user_query = "苹果多少钱一斤？"

# 2. 用嵌入模型把问题变成向量（用于检索，不送给大模型）
query_vector = embedding_model.encode(user_query)  # shape: [768]

# 3. 用这个向量去数据库里找相似的文档块
similar_chunks = vector_db.search(query_vector, top_k=3)
# similar_chunks = [
#     "今日苹果批发价5元一斤",
#     "苹果价格稳定在4-6元区间",
#     "水果市场苹果供应充足"
# ]

# 4. 把找到的原始文本（！！！不是向量！！！）取出来
retrieved_text = "\n".join(similar_chunks)

# 5. 组装提示词：把问题和检索到的文本合并
prompt = f"""参考以下信息回答问题：
{retrieved_text}

问题：{user_query}
回答："""

# 6. 把提示词分词 → Token IDs → 送给大模型
token_ids = tokenizer.encode(prompt)  # 这才是大模型的输入
answer = llm.generate(token_ids)

关键观察：

• 嵌入向量 query_vector 在第2步产生，第3步用完就丢弃了

• 真正送给大模型的是第4步取出来的原始文本（经过 Tokenizer 变成 Token ID）

3.4 类比说明

把整个过程比作一个 “律师助理 + 资深律师” 的协作：

• 准备阶段：律师助理（你的系统）接手了你公司的文件柜（外部文档库）。他/她将所有文件拆解成一份份单页的摘要（文本切块），并为每份摘要贴上“内容标签”（向量化），然后把这些带标签的摘要按索引整齐地放入一个临时文件夹（向量数据库）中待用。

• 查询阶段：当老板（用户）问一个专业问题时：

  1. 助理检索：助理先把老板的问题转化成几个“关键词标签”（问题向量化），然后迅速在文件夹中找出标签最匹配的3份摘要（相似性检索），放在老板桌上。

  2. 律师回答：资深律师（大模型）看了看桌上这3份摘要（外部知识）和老板的问题，然后说：“根据您提供的这些资料，我的回答是……”，最终给出一个有理有据的答案。

这种模式解决了什么问题？

• 知识时效性：大模型训练数据截止于过去，而RAG可以实时引用最新文档。

• 减少“幻觉”：模型不再凭空生成，而是基于你提供的资料回答，大大降低胡编乱造的可能。

• 数据安全：你的私有文档库无需拿去训练模型，可以部署在本地，大模型只在你提问时“看一眼”相关内容。

当然，RAG模式也不是完美的，它仍然面临一些挑战，比如如何保证检索到的内容100%相关、如何让模型回答“资料里没有”的问题而非用资料强行拼凑等。不过，它依然是目前让大模型应用私有知识最主流、最高效的方法。