1. 从“调包”到“理解”为什么我们需要再看一遍Embedding与Transformer如果你和我一样最开始接触LangChain和RAG检索增强生成时大概率是跟着官方文档或者某个热门教程一路“调包”过来的。流程很清晰选一个Embedding模型比如text-embedding-ada-002或者BGE选一个向量数据库比如Chroma、Pinecone然后调用from_documents、as_retriever这些方法一个基础的RAG系统就跑起来了。看起来Embedding和Transformer就像是封装好的黑盒我们只需要知道“输入文本输出向量”和“输入上下文输出答案”就够了。但当你真的想优化这个系统或者想解决一些实际生产中的棘手问题时比如为什么有时候检索回来的文档明明相关但大模型LLM给出的答案却答非所问为什么换了另一个同量级的Embedding模型效果就天差地别如何根据我的业务文档特点比如长文档、专业术语多、中英文混杂来定制或微调Embedding“重排序”到底在重排什么它和Embedding有什么关系你会发现如果不回到这两个最基础的组件——Embedding模型本质是经过特定训练的Transformer编码器和作为其核心的Transformer架构——去理解它们的工作原理和局限所有的优化都像是在隔靴搔痒只能凭感觉调参无法从根本上解决问题。所以这篇笔记不是入门教程而是一次“回头看”。我会结合自己踩过的坑和做过的实验抛开LangChain的封装深入到Embedding与Transformer的层面重新审视RAG的各个环节。目标是让你不仅能“用”RAG更能“懂”RAG从而有能力去设计和优化一个更健壮、更高效的RAG系统。我们关注的不再是LangChain的API调用而是其背后支撑整个流程的、最本质的技术逻辑。2. 拆解Embedding它远不止是“文本转向量”在RAG的语境里Embedding模型通常被简化为一个“文本编码器”。但正是这个编码过程的质量直接决定了后续检索的精度。我们需要理解它的几个关键特性。2.1 Embedding模型的“训练目标”决定了它的能力边界不同的Embedding模型即使在相同的Transformer架构如BERT、RoBERTa上训练也会因为训练目标Task的不同而具备截然不同的特性。这直接影响了它在RAG中的表现。对称 vs. 非对称搜索这是最核心的差异之一。对称搜索查询Query和待检索文档Document在语义上是同质的。例如用一段话去检索语义相似的另一段话。像text-embedding-ada-002和许多Sentence-BERT模型其训练数据大量包含“句子对”相似度任务因此它们在对称搜索上表现优异。如果你的RAG场景是“用问题找相似问题”或者“用摘要找原文”这类模型很合适。非对称搜索查询和文档在语义上不同质最常见的就是问答QA场景。用户的问题是简短的、口语化的如“如何报税”而文档是长篇的、正式的说明文。一个在对称任务上训练的模型可能无法很好地将简短问题映射到长文档的核心语义空间。为此社区出现了像BGEBAAI General Embedding这类模型它们专门使用了指令微调Instruction Tuning在训练时让模型学会根据类似“为这个句子生成表示”的指令来编码使其更适应“查询-文档”这种非对称检索。在实际项目中如果你发现用对称模型检索效果不佳首要排查点就是这里。实操心得不要盲目追求榜单上的高分数。先明确你的业务场景是“对称”还是“非对称”。对于中文RAGBGE系列模型如BAAI/bge-large-zh因其对非对称搜索的优化往往是更稳妥的起点。你可以用少量业务数据分别测试对称和非对称模型的Top-K召回率来做出选择。2.2 上下文长度被忽视的“隐形杀手”Transformer模型包括其衍生的Embedding模型有一个硬性限制最大序列长度Max Sequence Length。对于早期的BERT模型通常是512个token。这意味着当你输入一篇超过这个长度的文档时模型要么截断要么需要特殊处理。简单截断的代价如果你直接将一篇5000字的文档扔给一个最大长度为512的Embedding模型模型只会编码前512个token文档后半部分的信息完全丢失。这可能导致检索时只因为文档开头提到了某个关键词就被召回而真正包含答案的核心段落因为位于文档后半部而被忽略。滑动窗口与池化策略为了解决长文档问题常见的策略是“滑动窗口”“池化”。即将长文档按重叠窗口切分成多个片段Chunks分别编码得到多个向量然后通过池化如均值池化得到一个代表整个文档的向量。但这里有个关键点池化操作是一种信息压缩必然会损失细节。对于结构复杂、信息分散的长文档这种损失可能是致命的。长文本模型的兴起如今像text-embedding-3-large支持8191 tokens和专门的长文本Embedding模型如voyage-lite-02-instruct支持16000 tokens已经出现。如果你的业务文档普遍较长直接使用这类模型可能是比复杂分块策略更优的解。一个真实的踩坑案例我曾处理一批技术手册平均长度在3000字左右。最初使用BERT-base512长度并采用滑动窗口均值池化。检索效果时好时坏。后来分析发现很多问题的答案恰好位于两个chunk的交接处被切分和池化后语义变得模糊。切换到bge-large-zh-v1.5支持1024长度并优化分块策略按章节分而非固定长度滑动后召回率显著提升。2.3 向量空间与距离度量语义相似度的“尺子”Embedding模型将文本映射到一个高维向量空间如768维、1024维。我们通常用余弦相似度Cosine Similarity来衡量两个向量的“距离”认为距离越近语义越相似。各向异性问题早期研究发现未经特定训练的Transformer模型产生的向量分布并非均匀地充满整个空间而是聚集在一个狭窄的锥形区域内这被称为“各向异性”。这会导致所有句子的相似度都偏高区分度下降。现代Embedding模型通过对比学习Contrastive Learning等技术缓解了这一问题但理解这个概念有助于明白为什么需要专门的Embedding模型而不是直接用预训练语言模型的最后一层输出。距离度量的选择除了最常用的余弦相似度还有欧氏距离L2、内积等。大部分向量数据库默认使用余弦相似度因为它对向量的模长不敏感更关注方向即语义。但有些模型如OpenAI的某些版本可能更适合内积。关键是要确保你使用的相似度计算方式与Embedding模型训练时优化的目标一致。在Chroma或FAISS中创建集合时指定正确的distance_function至关重要。3. Transformer架构在RAG中的双重角色编码与生成在RAG中Transformer架构扮演了两个核心角色一是作为Embedding模型的骨干网络编码器负责理解并压缩文本信息为向量二是作为大语言模型LLM的核心负责根据检索到的上下文生成答案。理解这两者的联系与区别是优化RAG的关键。3.1 编码器从词序列到语义向量的“理解”过程Embedding模型通常是Transformer的编码器部分如BERT。它的工作流程可以简化为分词与嵌入将输入文本转换为词元Token序列每个词元被映射为一个初始向量Token Embedding。位置编码为每个词元添加位置信息让模型知道词的顺序。多层自注意力与前馈网络这是Transformer的核心。通过自注意力机制每个词元都可以“关注”序列中的所有其他词元动态地计算它们之间的关联权重。经过多层这样的变换模型能够捕获复杂的上下文依赖关系。池化输出对最后一层所有词元的输出向量进行池化如[CLS]标记的输出、均值池化得到一个固定维度的句子/文档级向量表示。为什么自注意力机制对检索如此重要因为它允许模型建立远距离依赖。在文档中答案可能分散在不同的句子里。例如问题“LangChain和LangGraph有什么区别”答案可能分布在介绍LangChain的段落和介绍LangGraph的段落中。一个好的编码器需要能通过自注意力机制在编码“区别”这个词时关联到前后文中关于这两个工具的描述从而生成一个能综合反映“对比”关系的文档向量。如果编码器能力不足生成的向量可能只捕获了表面词汇的共现而丢失了深层的逻辑关联。3.2 生成器从上下文到答案的“创作”过程LLM如GPT、LLaMA通常是Transformer的解码器或编码器-解码器架构。在RAG中它的输入是“检索到的上下文”“用户问题”的拼接。其生成过程同样依赖于自注意力机制但它是“因果的”或“交叉的”注意力。交叉注意力在编码器-解码器架构中解码器在生成每一个新词元时会通过交叉注意力机制去“查阅”编码器提供的上下文信息即我们检索到的文档。这就像学生在答题时不断回头参考参考资料。因果自注意力在纯解码器架构中生成时只能关注已生成的部分和输入的上下文确保生成是单向的。这里存在一个关键瓶颈上下文窗口限制与信息过载。即使我们检索回了5篇最相关的文档把它们全部拼接到LLM的输入中可能会占用大量token。一方面可能触及模型上下文窗口上限另一方面过多的信息可能让LLM难以聚焦出现“Lost in the Middle”现象即模型更容易关注输入开头和结尾的信息而忽略中间部分。这就引出了RAG中另一个重要环节重排序与上下文压缩。4. RAG流程的再审视基于底层原理的优化点当我们带着对Embedding和Transformer的理解重新走一遍RAG流程会发现每一个环节都有可以深度优化的地方。4.1 文档预处理与分块为优质Embedding打下基础分块Chunking策略直接决定了Embedding模型“看到”的是什么。不合理的分块是后续一切问题的根源。分块策略优点缺点适用场景固定长度重叠分块实现简单通用性强。可能切断完整的句子或段落破坏语义完整性。重叠部分处理不当会造成信息冗余或混淆。格式统一、结构简单的文档如新闻稿、社交媒体帖子。基于分隔符分块能保持自然段落或章节的完整性。依赖文档本身具有清晰的分隔符如换行、标题。对于格式混乱的文档效果差。技术文档、书籍、Markdown/HTML格式文档。语义分块尽可能保证每个块的语义独立性和完整性。计算开销大需要调用模型进行句子边界检测或语义分割实现复杂。对检索精度要求极高且文档语义结构复杂的场景。递归分块结合多种策略先按大分隔符分再对过大块按小分隔符或固定长度分。策略组合需要调优可能更复杂。处理混合格式、结构层次不一的文档集合。优化建议不要盲目使用默认的RecursiveCharacterTextSplitter。先分析你的文档结构。如果是API文档按函数/类分块如果是论文按摘要、章节分块。分块大小需要与Embedding模型上下文长度匹配。如果你的模型支持1024 token那么分块大小可以设为800-1000 token留出余量而不是机械地用256或512。谨慎设置重叠窗口。重叠是为了防止答案被切分在边界。通常50-100个token的重叠是合理的。但重叠部分在检索时可能被重复计算需要评估。4.2 检索与重排序从“相关”到“有用”检索器Retriever基于向量相似度返回Top-K个文档块。但“最相似”不一定等于“最有用”。Embedding模型的局限性正如前文所述如果模型不擅长非对称搜索或者长文档处理不佳那么召回的基础文档集合质量就可能不高。重排序器的价值重排序Re-ranker是一个轻量级但强大的二次筛选工具。它通常是一个专门训练过的、计算query和单个document相关性的交叉编码器模型如BGE-reranker。与Embedding模型的双塔结构编码后计算相似度不同交叉编码器将query和document同时输入通过充分的注意力交互计算一个相关分数。它的计算更慢但精度更高。两阶段检索模式这是生产级RAG的常见模式。第一阶段用快速的Embedding模型向量数据库召回较多的候选文档如Top-20。第二阶段用精确但较慢的重排序模型对这20个文档进行精排选出最相关的3-5个送入LLM。这样在精度和速度间取得了平衡。实操配置示例伪代码思路# 第一阶段向量检索粗筛 from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vectorstore Chroma.from_documents(docs, embedding_model) retriever vectorstore.as_retriever(search_kwargs{k: 20}) # 召回较多 # 第二阶段重排序精筛 from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CrossEncoderReranker from sentence_transformers import CrossEncoder reranker_model CrossEncoder(BAAI/bge-reranker-large) compressor CrossEncoderReranker(modelreranker_model, top_n5) compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverretriever) # 最终使用的 retriever 是 compression_retriever4.3 上下文构造与提示工程给LLM“喂好料”即使我们检索到了最相关的文档如何组织并呈现给LLM也极大影响最终答案的质量。信息过载与聚焦直接将多个长文档块拼接可能让LLM迷失。可以考虑摘要压缩对每个检索到的文档块先用一个轻量模型或LLM本身生成一个更简短的摘要再将摘要喂给主LLM。提取关键信息根据问题从文档中提取出直接相关的句子或数据而不是整段送入。LangChain的ContextualCompressionRetriever就集成了这类功能可以与重排序结合使用。提示词设计清晰的指令能引导LLM更好地利用上下文。明确来源要求在Prompt中要求LLM基于提供的上下文回答并注明“如果上下文未包含相关信息请明确说明不知道”。结构化上下文在拼接上下文时加入清晰的分隔符和来源标识例如[文档1]...\n[文档2]...方便LLM区分和引用。指定格式如果需要特定格式的答案在Prompt中说明。5. 进阶思考超越基础RAG的架构模式理解了基础组件我们可以看看更前沿或更复杂的RAG架构它们本质上都是对这些底层原理的灵活组合与应用。Self-RAG / Adaptive-RAG这类架构让模型在生成过程中自主判断是否需要检索、何时检索、检索什么。它打破了“一次检索终身使用”的模式实现了动态的、多轮次的检索-生成循环。这要求模型具备判断自身知识边界的能力通常需要对LLM进行特定微调。Hybrid Search混合搜索结合稠密向量检索Dense Vector Search即Embedding和稀疏向量检索Sparse Vector Search如BM25。BM25基于关键词匹配擅长处理精确术语、命名实体检索Embedding擅长语义匹配。两者结合可以互相弥补不足。例如查询“Python中如何连接MySQL数据库”BM25能确保召回包含“Python”、“MySQL”、“连接”这些关键词的文档而Embedding能召回关于“数据库操作”、“PyMySQL/connector使用”等语义相关的文档。Multi-Hop RAG多跳RAG对于复杂问题答案可能需要串联多个文档的信息。例如“LangChain的作者是谁他还在哪个知名AI项目工作”。第一个检索可能找到介绍LangChain的页面得知作者第二个检索则用作者名字去查找他的其他贡献。这需要系统能分解问题并进行链式或递归式检索。Agentic RAG将RAG系统嵌入到一个智能体Agent框架中。智能体可以规划、调用工具检索器只是其中一个工具、执行多步操作来解决复杂问题。LangChain的Agent和LangGraph正是为此类场景设计。它们提供了编排复杂工作流的能力而RAG作为知识获取的核心工具被集成在其中。回到我们最初的标题再看一遍Embedding与Transformer再看一遍RAG其意义在于建立从微观模型原理到宏观系统性能的认知桥梁。当你再遇到RAG效果不佳时你的排查思路会清晰很多是分块破坏了语义还是Embedding模型不匹配任务是检索到的文档本身质量差还是LLM没有用好上下文只有深入到这些基础层面你才能做出精准的诊断和有效的优化从而构建出真正可靠、高效的智能问答系统。这比单纯记忆LangChain的又一个新API要有价值得多。
1. 从“调包”到“理解”为什么我们需要再看一遍Embedding与Transformer如果你和我一样最开始接触LangChain和RAG检索增强生成时大概率是跟着官方文档或者某个热门教程一路“调包”过来的。流程很清晰选一个Embedding模型比如text-embedding-ada-002或者BGE选一个向量数据库比如Chroma、Pinecone然后调用from_documents、as_retriever这些方法一个基础的RAG系统就跑起来了。看起来Embedding和Transformer就像是封装好的黑盒我们只需要知道“输入文本输出向量”和“输入上下文输出答案”就够了。但当你真的想优化这个系统或者想解决一些实际生产中的棘手问题时比如为什么有时候检索回来的文档明明相关但大模型LLM给出的答案却答非所问为什么换了另一个同量级的Embedding模型效果就天差地别如何根据我的业务文档特点比如长文档、专业术语多、中英文混杂来定制或微调Embedding“重排序”到底在重排什么它和Embedding有什么关系你会发现如果不回到这两个最基础的组件——Embedding模型本质是经过特定训练的Transformer编码器和作为其核心的Transformer架构——去理解它们的工作原理和局限所有的优化都像是在隔靴搔痒只能凭感觉调参无法从根本上解决问题。所以这篇笔记不是入门教程而是一次“回头看”。我会结合自己踩过的坑和做过的实验抛开LangChain的封装深入到Embedding与Transformer的层面重新审视RAG的各个环节。目标是让你不仅能“用”RAG更能“懂”RAG从而有能力去设计和优化一个更健壮、更高效的RAG系统。我们关注的不再是LangChain的API调用而是其背后支撑整个流程的、最本质的技术逻辑。2. 拆解Embedding它远不止是“文本转向量”在RAG的语境里Embedding模型通常被简化为一个“文本编码器”。但正是这个编码过程的质量直接决定了后续检索的精度。我们需要理解它的几个关键特性。2.1 Embedding模型的“训练目标”决定了它的能力边界不同的Embedding模型即使在相同的Transformer架构如BERT、RoBERTa上训练也会因为训练目标Task的不同而具备截然不同的特性。这直接影响了它在RAG中的表现。对称 vs. 非对称搜索这是最核心的差异之一。对称搜索查询Query和待检索文档Document在语义上是同质的。例如用一段话去检索语义相似的另一段话。像text-embedding-ada-002和许多Sentence-BERT模型其训练数据大量包含“句子对”相似度任务因此它们在对称搜索上表现优异。如果你的RAG场景是“用问题找相似问题”或者“用摘要找原文”这类模型很合适。非对称搜索查询和文档在语义上不同质最常见的就是问答QA场景。用户的问题是简短的、口语化的如“如何报税”而文档是长篇的、正式的说明文。一个在对称任务上训练的模型可能无法很好地将简短问题映射到长文档的核心语义空间。为此社区出现了像BGEBAAI General Embedding这类模型它们专门使用了指令微调Instruction Tuning在训练时让模型学会根据类似“为这个句子生成表示”的指令来编码使其更适应“查询-文档”这种非对称检索。在实际项目中如果你发现用对称模型检索效果不佳首要排查点就是这里。实操心得不要盲目追求榜单上的高分数。先明确你的业务场景是“对称”还是“非对称”。对于中文RAGBGE系列模型如BAAI/bge-large-zh因其对非对称搜索的优化往往是更稳妥的起点。你可以用少量业务数据分别测试对称和非对称模型的Top-K召回率来做出选择。2.2 上下文长度被忽视的“隐形杀手”Transformer模型包括其衍生的Embedding模型有一个硬性限制最大序列长度Max Sequence Length。对于早期的BERT模型通常是512个token。这意味着当你输入一篇超过这个长度的文档时模型要么截断要么需要特殊处理。简单截断的代价如果你直接将一篇5000字的文档扔给一个最大长度为512的Embedding模型模型只会编码前512个token文档后半部分的信息完全丢失。这可能导致检索时只因为文档开头提到了某个关键词就被召回而真正包含答案的核心段落因为位于文档后半部而被忽略。滑动窗口与池化策略为了解决长文档问题常见的策略是“滑动窗口”“池化”。即将长文档按重叠窗口切分成多个片段Chunks分别编码得到多个向量然后通过池化如均值池化得到一个代表整个文档的向量。但这里有个关键点池化操作是一种信息压缩必然会损失细节。对于结构复杂、信息分散的长文档这种损失可能是致命的。长文本模型的兴起如今像text-embedding-3-large支持8191 tokens和专门的长文本Embedding模型如voyage-lite-02-instruct支持16000 tokens已经出现。如果你的业务文档普遍较长直接使用这类模型可能是比复杂分块策略更优的解。一个真实的踩坑案例我曾处理一批技术手册平均长度在3000字左右。最初使用BERT-base512长度并采用滑动窗口均值池化。检索效果时好时坏。后来分析发现很多问题的答案恰好位于两个chunk的交接处被切分和池化后语义变得模糊。切换到bge-large-zh-v1.5支持1024长度并优化分块策略按章节分而非固定长度滑动后召回率显著提升。2.3 向量空间与距离度量语义相似度的“尺子”Embedding模型将文本映射到一个高维向量空间如768维、1024维。我们通常用余弦相似度Cosine Similarity来衡量两个向量的“距离”认为距离越近语义越相似。各向异性问题早期研究发现未经特定训练的Transformer模型产生的向量分布并非均匀地充满整个空间而是聚集在一个狭窄的锥形区域内这被称为“各向异性”。这会导致所有句子的相似度都偏高区分度下降。现代Embedding模型通过对比学习Contrastive Learning等技术缓解了这一问题但理解这个概念有助于明白为什么需要专门的Embedding模型而不是直接用预训练语言模型的最后一层输出。距离度量的选择除了最常用的余弦相似度还有欧氏距离L2、内积等。大部分向量数据库默认使用余弦相似度因为它对向量的模长不敏感更关注方向即语义。但有些模型如OpenAI的某些版本可能更适合内积。关键是要确保你使用的相似度计算方式与Embedding模型训练时优化的目标一致。在Chroma或FAISS中创建集合时指定正确的distance_function至关重要。3. Transformer架构在RAG中的双重角色编码与生成在RAG中Transformer架构扮演了两个核心角色一是作为Embedding模型的骨干网络编码器负责理解并压缩文本信息为向量二是作为大语言模型LLM的核心负责根据检索到的上下文生成答案。理解这两者的联系与区别是优化RAG的关键。3.1 编码器从词序列到语义向量的“理解”过程Embedding模型通常是Transformer的编码器部分如BERT。它的工作流程可以简化为分词与嵌入将输入文本转换为词元Token序列每个词元被映射为一个初始向量Token Embedding。位置编码为每个词元添加位置信息让模型知道词的顺序。多层自注意力与前馈网络这是Transformer的核心。通过自注意力机制每个词元都可以“关注”序列中的所有其他词元动态地计算它们之间的关联权重。经过多层这样的变换模型能够捕获复杂的上下文依赖关系。池化输出对最后一层所有词元的输出向量进行池化如[CLS]标记的输出、均值池化得到一个固定维度的句子/文档级向量表示。为什么自注意力机制对检索如此重要因为它允许模型建立远距离依赖。在文档中答案可能分散在不同的句子里。例如问题“LangChain和LangGraph有什么区别”答案可能分布在介绍LangChain的段落和介绍LangGraph的段落中。一个好的编码器需要能通过自注意力机制在编码“区别”这个词时关联到前后文中关于这两个工具的描述从而生成一个能综合反映“对比”关系的文档向量。如果编码器能力不足生成的向量可能只捕获了表面词汇的共现而丢失了深层的逻辑关联。3.2 生成器从上下文到答案的“创作”过程LLM如GPT、LLaMA通常是Transformer的解码器或编码器-解码器架构。在RAG中它的输入是“检索到的上下文”“用户问题”的拼接。其生成过程同样依赖于自注意力机制但它是“因果的”或“交叉的”注意力。交叉注意力在编码器-解码器架构中解码器在生成每一个新词元时会通过交叉注意力机制去“查阅”编码器提供的上下文信息即我们检索到的文档。这就像学生在答题时不断回头参考参考资料。因果自注意力在纯解码器架构中生成时只能关注已生成的部分和输入的上下文确保生成是单向的。这里存在一个关键瓶颈上下文窗口限制与信息过载。即使我们检索回了5篇最相关的文档把它们全部拼接到LLM的输入中可能会占用大量token。一方面可能触及模型上下文窗口上限另一方面过多的信息可能让LLM难以聚焦出现“Lost in the Middle”现象即模型更容易关注输入开头和结尾的信息而忽略中间部分。这就引出了RAG中另一个重要环节重排序与上下文压缩。4. RAG流程的再审视基于底层原理的优化点当我们带着对Embedding和Transformer的理解重新走一遍RAG流程会发现每一个环节都有可以深度优化的地方。4.1 文档预处理与分块为优质Embedding打下基础分块Chunking策略直接决定了Embedding模型“看到”的是什么。不合理的分块是后续一切问题的根源。分块策略优点缺点适用场景固定长度重叠分块实现简单通用性强。可能切断完整的句子或段落破坏语义完整性。重叠部分处理不当会造成信息冗余或混淆。格式统一、结构简单的文档如新闻稿、社交媒体帖子。基于分隔符分块能保持自然段落或章节的完整性。依赖文档本身具有清晰的分隔符如换行、标题。对于格式混乱的文档效果差。技术文档、书籍、Markdown/HTML格式文档。语义分块尽可能保证每个块的语义独立性和完整性。计算开销大需要调用模型进行句子边界检测或语义分割实现复杂。对检索精度要求极高且文档语义结构复杂的场景。递归分块结合多种策略先按大分隔符分再对过大块按小分隔符或固定长度分。策略组合需要调优可能更复杂。处理混合格式、结构层次不一的文档集合。优化建议不要盲目使用默认的RecursiveCharacterTextSplitter。先分析你的文档结构。如果是API文档按函数/类分块如果是论文按摘要、章节分块。分块大小需要与Embedding模型上下文长度匹配。如果你的模型支持1024 token那么分块大小可以设为800-1000 token留出余量而不是机械地用256或512。谨慎设置重叠窗口。重叠是为了防止答案被切分在边界。通常50-100个token的重叠是合理的。但重叠部分在检索时可能被重复计算需要评估。4.2 检索与重排序从“相关”到“有用”检索器Retriever基于向量相似度返回Top-K个文档块。但“最相似”不一定等于“最有用”。Embedding模型的局限性正如前文所述如果模型不擅长非对称搜索或者长文档处理不佳那么召回的基础文档集合质量就可能不高。重排序器的价值重排序Re-ranker是一个轻量级但强大的二次筛选工具。它通常是一个专门训练过的、计算query和单个document相关性的交叉编码器模型如BGE-reranker。与Embedding模型的双塔结构编码后计算相似度不同交叉编码器将query和document同时输入通过充分的注意力交互计算一个相关分数。它的计算更慢但精度更高。两阶段检索模式这是生产级RAG的常见模式。第一阶段用快速的Embedding模型向量数据库召回较多的候选文档如Top-20。第二阶段用精确但较慢的重排序模型对这20个文档进行精排选出最相关的3-5个送入LLM。这样在精度和速度间取得了平衡。实操配置示例伪代码思路# 第一阶段向量检索粗筛 from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vectorstore Chroma.from_documents(docs, embedding_model) retriever vectorstore.as_retriever(search_kwargs{k: 20}) # 召回较多 # 第二阶段重排序精筛 from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import CrossEncoderReranker from sentence_transformers import CrossEncoder reranker_model CrossEncoder(BAAI/bge-reranker-large) compressor CrossEncoderReranker(modelreranker_model, top_n5) compression_retriever ContextualCompressionRetriever(base_compressorcompressor, base_retrieverretriever) # 最终使用的 retriever 是 compression_retriever4.3 上下文构造与提示工程给LLM“喂好料”即使我们检索到了最相关的文档如何组织并呈现给LLM也极大影响最终答案的质量。信息过载与聚焦直接将多个长文档块拼接可能让LLM迷失。可以考虑摘要压缩对每个检索到的文档块先用一个轻量模型或LLM本身生成一个更简短的摘要再将摘要喂给主LLM。提取关键信息根据问题从文档中提取出直接相关的句子或数据而不是整段送入。LangChain的ContextualCompressionRetriever就集成了这类功能可以与重排序结合使用。提示词设计清晰的指令能引导LLM更好地利用上下文。明确来源要求在Prompt中要求LLM基于提供的上下文回答并注明“如果上下文未包含相关信息请明确说明不知道”。结构化上下文在拼接上下文时加入清晰的分隔符和来源标识例如[文档1]...\n[文档2]...方便LLM区分和引用。指定格式如果需要特定格式的答案在Prompt中说明。5. 进阶思考超越基础RAG的架构模式理解了基础组件我们可以看看更前沿或更复杂的RAG架构它们本质上都是对这些底层原理的灵活组合与应用。Self-RAG / Adaptive-RAG这类架构让模型在生成过程中自主判断是否需要检索、何时检索、检索什么。它打破了“一次检索终身使用”的模式实现了动态的、多轮次的检索-生成循环。这要求模型具备判断自身知识边界的能力通常需要对LLM进行特定微调。Hybrid Search混合搜索结合稠密向量检索Dense Vector Search即Embedding和稀疏向量检索Sparse Vector Search如BM25。BM25基于关键词匹配擅长处理精确术语、命名实体检索Embedding擅长语义匹配。两者结合可以互相弥补不足。例如查询“Python中如何连接MySQL数据库”BM25能确保召回包含“Python”、“MySQL”、“连接”这些关键词的文档而Embedding能召回关于“数据库操作”、“PyMySQL/connector使用”等语义相关的文档。Multi-Hop RAG多跳RAG对于复杂问题答案可能需要串联多个文档的信息。例如“LangChain的作者是谁他还在哪个知名AI项目工作”。第一个检索可能找到介绍LangChain的页面得知作者第二个检索则用作者名字去查找他的其他贡献。这需要系统能分解问题并进行链式或递归式检索。Agentic RAG将RAG系统嵌入到一个智能体Agent框架中。智能体可以规划、调用工具检索器只是其中一个工具、执行多步操作来解决复杂问题。LangChain的Agent和LangGraph正是为此类场景设计。它们提供了编排复杂工作流的能力而RAG作为知识获取的核心工具被集成在其中。回到我们最初的标题再看一遍Embedding与Transformer再看一遍RAG其意义在于建立从微观模型原理到宏观系统性能的认知桥梁。当你再遇到RAG效果不佳时你的排查思路会清晰很多是分块破坏了语义还是Embedding模型不匹配任务是检索到的文档本身质量差还是LLM没有用好上下文只有深入到这些基础层面你才能做出精准的诊断和有效的优化从而构建出真正可靠、高效的智能问答系统。这比单纯记忆LangChain的又一个新API要有价值得多。
