做了大半年RAG相关的东西，从最初只会照教程把流程跑通，到后来能针对不同业务场景自己定方案、调参数、解决线上问题，中间踩的坑确实不少。今天这篇就围绕“RAG构建”好好梳理一遍，覆盖原理、实操、调优和常见问题排查，适合刚接触大模型应用的小白，也适合已经在写提示词但想进一步落地的程序员。
先说明一点：RAG的全称是Retrieval-Augmented Generation，中文叫检索增强生成。它的核心作用是解决大模型落地时的几个典型痛点——幻觉、知识陈旧、无法使用私有数据。换句话说，RAG让大模型在回答问题时不再只靠“记忆”，而是先去外部知识库里检索相关资料，再结合这些资料进行回答。简单理解，就是给大模型配了一本可以随时翻阅的参考书，让它从“闭卷考试”变成“开卷考试”。
下面我会按照“先理解原理，再手动实操，最后进阶优化”的顺序来讲，内容比较多，建议收藏备用。
1. 先搞清楚：大模型到底有哪些痛点，RAG凭什么能解
1.1 三个说得最多的大模型痛点
痛点一，幻觉问题。这是使用大模型时最头疼的事情，它回答起来一本正经，但内容可能是凭空编造的。比如你问它一个公司内部的报销规则，它可能给出一个看起来逻辑完整、但实际不受任何政策支持的流程。幻觉的根源在于大模型生成文本时本质是在做概率预测，目标是生成“听起来合理”的内容，而不是“事实正确”的内容。
痛点二，知识陈旧。大模型的训练数据来源于一个固定时间点，之后发生的事情它并不知道。你去问半年前发布的新技术动态，它大概率会含糊其辞或胡乱拼凑。就算重新训练一次模型，成本高、周期长，对于大部分团队来说根本不现实。
痛点三，数据私有与合规。公司内部的财务制度、客服话术、产品手册、合同条款这些资料，既不能拿去训练公开的大模型，也不能随便上传到外部服务里。但业务上又确实需要基于这些资料为用户提供问答和搜索能力。这种私有知识的安全使用和检索，单靠通用大模型是做不到的。
这三点叠加在一起，就构成了大模型落地时最常见的“知识断层”。有人可能想到微调模型去解决，但微调适合的是改变模型回答风格、学会特定格式输出这类场景，用于注入新事实知识时性价比很低——因为知识更新容易导致灾难性遗忘，而且每次改数据都要重训一次。
1.2 RAG的核心思路：把“闭卷考试”变成“开卷考试”
RAG的基本思路非常直接：既然大模型的记忆不可靠、不实时、不包含私有内容，那就不让它凭记忆回答。每次收到用户问题后，先从外部知识库检索出与问题最相关的资料片段，把这些片段作为上下文和问题一起交给大模型，要求它只基于这些资料进行回答。整个过程由两个核心组件协同完成：检索器和生成器。检索器负责从知识库中召回候选内容，生成器负责根据召回的上下文字段来回答用户问题。
这个思路用生活化一点的话来解释，就像学生参加考试。闭卷考试时只能凭记忆作答，记不全就会编；但开卷考试时，你可以带资料进去，按题目索引找到相关章节，再根据资料组织答案，准确率自然高得多。RAG做的这件事，就是给每个大模型配一位专属的图书管理员和一套资料库，用户提问时，图书管理员帮忙查资料，大模型负责读资料并组织答案。
理解了这一点，你会发现RAG的好处不只是减少幻觉。它的知识更新成本变得很低，知识库内容改动只需要更新文档或索引，不需要重新训练模型。私有数据也能安全接入，因为大模型只接触当前检索出来的少量片段，不会把这些数据用于模型本身的更新，内部系统甚至可以把大模型部署在私有环境里完成全部调用。
2. RAG核心链路拆解：从一篇文档到一条带证据的答案
2.1 索引阶段：先把知识放进仓库
RAG的第一步是准备知识库，这一步通常叫“索引”或“离线处理”。整个链路是把一份份原始文档经过加载、清洗、分段、向量化、存储后，构造成一个可用的检索源。
文档加载和清洗常常被低估，但往往是最影响效果的一环。PDF里的页眉页脚、表格里的复杂结构、网页里的导航文字，如果不清理干净，后面分出来的块就会含有大量噪音。文档清洗的目标是提取正文核心内容，去掉与语义无关的重复内容、模板信息、定位符号。清洗这一步做得好，后面的分块、向量化才能真正有意义。
分块是索引阶段最关键的决策点。原始文档通常很长，一部技术手册可能有几万字，直接整篇做向量化，检索时很难精准命中局部细节。通常的做法是把文档切割成固定大小或按语义边界划分的块。固定大小最简单，例如按字符或词数每500个左右切一块，相邻块之间留50个字符的重叠，避免切割导致语义断层。按语义边界切，可以尝试利用标题、段落、章节结构进行划分，效果更好但复杂度也更高。
清洗和分块完成后，要把每个文本块输入嵌入模型，转换成向量。所谓“向量”，就是一段可以代表文本语义的浮点数数组。语义相近的文本，在向量空间里的距离也较近。嵌入模型的选型会直接影响检索效果，这是后面实操篇的重点。向量化完成后，把这些向量连同对应的原文和元数据一起存入向量数据库，索引阶段就算基本完成。
2.2 检索阶段：问答时怎么把相关内容捞出来
当用户发起一个问题时，检索阶段开始工作。首先要用同一个嵌入模型把用户问题也转换成向量，然后拿这个查询向量去向量数据库里做相似度搜索，找出距离最近的若干个文本块。常用的相似度计算方式是余弦相似度，取值越接近1，代表两个向量的语义越接近。
检索质量有一个经典评价指标叫召回率，也就是真正的答案出现在候选结果里的概率。召回率不高，后面大模型再厉害也无济于事，因为参考资料里根本就没把答案捞出来。这也是RAG项目中最常见的失败原因，很多人费劲优化提示词，结果发现瓶颈在检索环节。
纯向量检索并非银弹，它擅长理解语义，但对精确关键词匹配并不敏感。比如你检索产品编号“PLT-2024-031”，向量可能把它识别成一段无关描述。所以实际项目用得较多的是混合检索策略，把向量检索和传统的关键词检索结合起来，各自召回一部分，再做融合排序，这部分我会在后面的优化章节展开聊。
2.3 生成阶段：让大模型对着参考资料写答案
检索完成后，系统把召回得到的文本块拼接成上下文，连同用户问题一起送入大模型。这里的关键是要在提示词里明确指定模型必须基于给定的参考材料来回答，不得使用自身记忆之外的捏造事实。
提示词设计得好不好，直接影响答案质量。一个常见的说法是：
你是一位智能问答助手，请严格基于以下“参考材料”回答用户问题。如果参考材料中没有足够信息，请直接回答“资料库中未找到相关信息”，不要编造内容。所有回答请结合参考材料中的原话，保持准确和客观。
参考材料： {context}
用户问题：{question}
曾经有朋友问我，既然把参考资料拼进提示词就行了，那还需要做上面那么多索引工作吗？答案是当然需要。“把资料放进提示词”只是最后一步，真正决定资料质量的是前面检索阶段能不能把相关片段精准捞出来，能捞出100个候选块，但提示词空间有限，需要检索器先把最相关的几个块找出来，才有资格被放进提示词。
2.4 为什么这样设计？三个阶段的取舍与协同
索引、检索、生成三个阶段各有各的重心，它们之间是层层递进的关系。索引决定了信息是否被高效组织和表达；检索决定了在信息足够多时能否快速拿准相关片段；生成决定了最后是否用自然、可信的方式把答案表达出来。
这样的设计也给了RAG非常强的模块化特性。各环节可以独立替换，比如今天用开源嵌入模型，明天参数调优后换一个更强的嵌入模型；今天用向量数据库存储，明天换成带混合检索能力的存储引擎。各环节独立升级带来的收益非常直接，不用动其他模块，这也是RAG成为目前大模型落地主流方案的重要原因。
3. 从零搭一套RAG的实操记录
3.1 环境准备与工具选型
说再多原理，不如动手跑一遍。这里的实操我尽量用简洁的描述带你过一遍，让你能套用到自己熟悉的技术栈里。语言层面我建议直接用Python，生态成熟，嵌入模型、向量数据库、大模型调用都有现成的库支持。大模型调用建议使用OpenAI兼容的接口封装，这样迁移到不同大模型服务时，只需要改API地址和密钥。
向量存储方面，起步阶段不需要复杂的线上集群，常见的有两大阵营：一类是成熟的向量数据库服务，适合规模化场景；另一类是嵌入式向量索引，适合本地开发测试。选型时可以遵循一条很实用的原则：先把流程跑起来，用最简单的方式，后期数据量大了再迁移到更强的存储。
嵌入模型方面，选择的核心思路是，谁知道你的领域语言，谁就更适合。通用领域的嵌入模型对日常问答效果可以，但到了专业术语密集的领域，效果往往不够理想。业界有一种偏好是优先选择支持中文且需要对比评测后定，很多开源中文嵌入模型的效果已经非常能打，而且可以本地部署，不涉及数据外流。
3.2 清洗与分块：不要小看这一环
我见过太多人把原始文档喂进去就直接切分向量化，结果线上检索效果很差。这里以实际经验强调：一定要先清洗。
需要重点处理的内容包括：
- PDF的页眉页脚、页码、水印文字；
- 表格转成结构化的markdown格式，避免语义丢失；
- 网页抓取来的内容去掉标签、导航、版权声明；
- 统一换行符，处理全角半角符号。
清洗完成后进入分块。分块参数有两个数值经常被反复调：块大小和重叠大小。块大小需要权衡信息完整性与检索粒度。块太小，比如200字符以内，单个块可能表达不出完整语义，检索时会漏掉上下文信息；块太大，比如2000字符以上，单个块内部包含多个无关子主题，检索命中时噪音多，而且消耗大模型的提示词空间。拿中文场景举例，块大小设置在400到600字符之间是比较常见的起点，重叠设置在50到80字符，可以避免恰好在关键句子中间切开导致语义断裂。
分块方式也不止固定大小一种。结构感知分块利用文档现有结构，比如按Markdown不同层级标题分块，或者按项目符号列表分块。这类分块方式保留了文档本身的叙事边界，检索召回的相关块往往更完整。我在实操中会优先看源文档是否具备清晰结构，如果有，就采用结构感知分块，没有，才退回固定大小加重叠的方案。
3.3 向量化与入库
分块完成后，用选定的嵌入模型把每个块转成向量。这里有一个很容易被忽略的操作细节：查询阶段和入库阶段必须使用同一个嵌入模型，并且最好固定版本。如果中途切换了嵌入模型，旧向量和新的查询向量处在不同分布中，相似度计算就失去意义，这也是很多人在调试RAG时困惑“为什么效果突然变差”的原因。
一个简化的入库流程，核心是这样：
# 加载并清洗文档 raw_docs = load_documents("data/") cleaned_docs = [clean_doc(doc) for doc in raw_docs] # 分块 chunks = split_documents(cleaned_docs, chunk_size=500, overlap=50) # 向量化 vectors = [embed_model.encode(chunk) for chunk in chunks] # 写入向量存储，并保留原文与元数据 for vector, chunk in zip(vectors, chunks): vector_store.add(vector, {"text": chunk, "source": chunk.metadata})这里并不需要把代码细节手工抄下来，但你要注意的是向量化算力的消耗可能在数据量大时很明显，尤其是CPU环境下，百万级向量可能需要数小时。批量嵌入、并发请求、GPU加速，这些手段到了规模化阶段都得用上。
3.4 检索问答链路的落地代码
入库之后，线上问答链路的实现相对简单，主要就是三步。第一步接收用户问题并向量化；第二步查询向量存储，取回top-K个候选块；第三步把候选块拼成上下文，组装提示词，调用大模型，返回答案。清晰起见，我把核心逻辑表示如下：
def ask(question: str, top_k: int = 5): # 查询向量化 query_vector = embed_model.encode(question) # 相似度检索 hits = vector_store.search(query_vector, top_k=top_k) # 拼上下文 context = "\n\n".join(hit.text for hit in hits if hit.score > SIMILARITY_THRESHOLD) # 构造提示词 prompt = f"""请基于以下参考材料回答用户问题。 参考材料： {context} 用户问题：{question} 要求：优先使用参考材料中的信息作答，材料里没有的内容不要编造。""" # 大模型生成 answer = llm.chat(prompt) return answer这段代码最值得留意的有两个位置：一是相似度阈值SIMILARITY_THRESHOLD，二是“材料中没有就说没有”的约束条件。相似度阈值过低会让大量低相关片段进入上下文，分散大模型注意力；阈值过高则可能误杀真实答案，导致“查不到”。刚开始建议把阈值设得低一些，例如0.3到0.5之间，先保证召回率，后续再通过评测调整。约束条件的设置则是针对幻觉采取措施，模型确实擅长强行关联，如果上下文里没有相关内容，它也可能编一个看起来很合理的答案，明确的“不编造”指令至少能减少这种倾向。
top_k参数也有讲究。它代表最终送入大模型的片段数量。太小了，可能漏掉关键信息；太大了，很多噪音碎片会稀释大模型对核心问题的注意力，同时增加提示词长度和延迟成本。通用场景下top_k=5是一个不错的起点，知识密集型的场景可以调到8到10，但需要注意别把太多无关内容塞进去。
3.5 跑通之后先做一轮效果验证
很多人跑通之后直接上线，后面出问题再手忙脚乱地排查。更好的做法是先做一轮离线评测，把测试问题集准备好，再人工或自动判断每个问题是否能从知识库中找到对应答案。
我建议先准备三类测试问题：第一类是从知识库原文中改写出来的问题，保证存在标准答案；第二类是不在知识库范围内的问题，用来测试幻觉控制情况，期望答案应该是“未找到相关信息”；第三类是边界情况，模糊表述、同义替换、复杂复合问题。评测标准至少包含三项：答案能否正确检索到对应资料、最终答案是否正确、答案是否可追溯到参考材料。第三项特别重要，RAG和普通问答不同的地方在于它有据可查，回答结束后应能提供“来源材料”供用户核验。
4. 进阶优化：从“勉强能用”到“真正好用”
4.1 分块策略与参数调优心得
基础跑通是及格线，想让RAG在业务场景里真正被用户接受，还得花力气做优化。分块策略是最容易操作也最容易见效的切入点。
分块调优不能拍脑袋，最好基于测试问题集来评估。具体做法是：固定向量化模型、top_k和提示词不变，只改动分块方式或块大小，看测试集里的答案在正确率指标上的变化。这样能清晰量化分块参数的影响，避免凭感觉调参。
一个经常被忽视的小技巧是保留分块之间的“软关联”。例如，把父子分块方案应用在结构感知分块上：父块是较大粒度的章节块，用来提供足够上下文；子块是较小粒度的段落块，用来做精确匹配检索。检索时先用子块向量找到最相关的段落，再把该段落所属的父块一并填入上下文。这种设计兼顾了检索的精确度和生成时上下文的完整性，在复杂文档场景下提升非常明显。
4.2 混合检索：关键词与向量搭配着来
前面提到向量检索对精确词匹配不敏感，尤其在代码、型号、专有名词、日期等场景中表现不佳。混合检索就是针对这个问题设计的策略：使用传统的关键词检索方法（例如BM25算法）与向量检索并行，各自产生候选结果，再进行融合。
融合排序最常用的方法是线性加权和倒排融合，后者实现简单且效果稳定。核心思想是：把多路检索结果中的每一条记录，按它们在各自候选列表中的排名赋予一个得分，然后累加得到综合得分。例如某个片段在向量检索中排第2，在关键词检索中排第4，它的综合分为1/2加1/4，再加上一个用于平滑的小常数，防止某一路检索完全没有召回该片段的极端情况。最终按综合得分排序。
混合检索在真实业务里几乎已经是标配，因为用户提问的表达方式千奇百怪，有的习惯用自然语言大段描述，有的直接输入产品编号或报错信息。混合方案能让RAG在两种表达形态之间保持稳定表现，同时代码改动量并不大。
4.3 重排序和上下文压缩
即使做了混合检索，召回结果里可能仍有部分内容与问题仅有表面相关性。这些内容进入上下文后，会干扰大模型判断。这时候需要的是重排序阶段：用一个专用的排序模型，对候选集合重新打分，只保留排序靠前的3到5个片段进入提示词。
重排序模型和嵌入模型有本质区别。嵌入模型快速为海量数据生成向量向量库中粗暴但高效地筛出候选，缺少对“这到底和用户问题有多大关联”的精细判断。重排序模型则对“问题+片段”做深度语义交互，可以更精准地评估相关性。代价是速度较慢，所以重排序只适合运行在embedding粗筛后的少量候选上，比如top-50重排到top-5。这个组合方案在实践中能显著提升答案准确性。
上下文压缩是另一个容易被忽略但作用很大的优化点。召回片段往往包含大量与问题无关的句子，直接把整块塞进提示词里浪费token。上下文压缩的做法是去除与问题无关的句子或段落，只保留包含关键信息的子句。压缩后的上下文更干净，大模型生成答案时不必在大量噪音里“大海捞针”。这里可以用规则过滤，也可以用轻量语言模型来做提取。
4.4 知识库的更新与增量维护
知识库是活的，不是建好就不动。业务文档更新、制度变更，都会让旧向量过期，如果不及时清理，会出现新旧答案冲突的情况。
增量更新的关键原则有三个：追踪源文档版本、命中更新的文档时同步失效旧向量、定期做全量重索引兜底。具体来说，新增文档时直接为它的分块生成向量入库即可；修改或删除文档时，需要同步移除对应的旧向量，否则新旧版本会同时被检索到。
在工程实现上，建议为每个文本块记录源文档标识、章节路径、版本号和入库时间。这些元数据不仅在更新时有用，在答案溯源展示时也很重要，用户看到答案时能知道内容来自哪份文档的哪个小节。
另外还需要定期巡检知识库质量。可以周期性抽样运行一些典型问题，看看检索结果有没有偏离预期。还要注意数据隐私问题，权限控制要在检索阶段做，而不是等提示词拼完后再去清理，否则可能出现越权访问风险。
5. 常见问题速查与避坑指南
5.1 检索结果不准，相关片段根本没召回
这是RAG落地时最常见的问题，几乎80%的效果不佳都源于此。我遇到过的最典型一个情况是：测试集里问“怎么申请年假”，系统检索出来的却是考勤打卡规则。排查思路很简单，先单独看检索阶段的结果，不经过大模型，确认相关片段是否真的被召回。
相关片段没有被召回，通常有四个原因。一是分块粒度不合理，答案被封死在两个块之间，导致没有单独块包含完整答案，这时候需要调整块大小和重叠系数。二是嵌入模型和领域语言不匹配，专业术语表达不准确，这时候需要换领域嵌入模型或者增加关键词路。三是查询表达与文档写法差异过大，比如文档里写的是“年休假”，用户问的是“假期申请”，向量相似度不够高，解决思路是加同义词扩展查询或者引入混合检索。四是知识库中根本没有对应内容，这种反倒好处理，直接把问题标记为“无法回答”即可，不要硬答。
后台实践中我还发现一个容易被忽视的问题：检索和知识库的代码语言编码不一致。源文档的编码格式混用，比如一部分是UTF-8，一部分是GBK，在加载清洗阶段没有统一处理，导致文本内容出现乱码，向量自然也就失效。这类问题很难从检索结果里看出来，往往表现为大模型给出的答案里面带有一些奇怪的符号或不通顺的句子。清洗环节务必做统一的编码转换和规范校验。
5.2 回答读起来像拼凑，不像自然生成的
RAG生成的回答，有时候会显得生硬，感觉就是几个片段拼接在一起，缺乏连贯性和可读性。我早期经常被反馈“答案是能对上，但读起来完全不像一个正常人在说话”。
造成这类问题的原因，主要是上下文碎片化太严重。当提示词里塞了多个来自不同位置、不同文档的片段，模型要把这些碎片组织成流畅回答，难度很大。解决方式有几个方向：一是通过结构调整让上下文更有条理，比如按来源组织顺序，先放政策主文档，再放补充说明，模型生成时会更容易梳理主次关系；二是控制上下文总量，不要追求把所有候选都塞进提示词，精选五六个相关性最高的片段效果往往更好；三是可以在提示词里明确要求“综合参考材料的多个部分来回答，组织成通顺的一段话”。
5.3 检索太慢，用户等不了
延迟问题直接影响线上体验。RAG链路中耗时的大头通常有三个：查询向量化、向量检索、大模型生成。前两个还好控制，最容易爆发的瓶颈是大模型生成阶段。提示词越长，生成的token越多，延迟增长得就越明显。
常见的排查顺序是：先监控大模型生成耗时，看是不是提示词过长或者模型参数量过大导致生成慢；再检查向量检索耗时，看候选集规模和索引类型是否合理；最后检查嵌入模型推理耗时，尤其确认有没有在查询链路里重复计算向量。向量存储的索引类型对查询延迟影响很大，数据量到了百万级还用的是暴力扫描，那必然慢。
减少延迟还有几个很实用的技巧：为高频问题做检索结果缓存；在文档更新不频繁的前提下，把向量库整体预加载到内存；对大模型的输出长度做上限控制；或者使用流式输出，先把前面部分结果逐字返回给用户，提高感知上的响应速度。
5.4 感觉RAG没解决幻觉，核心原因排查
很多团队上线RAG之后发现幻觉并没有彻底消失，甚至原样复现。这其实并不意外，RAG减少幻觉的前提是检索到的资料覆盖了问题的答案。如果资料本身没覆盖，或者被错误的片段“误导”了，幻觉依然会发生。
排查顺序建议从以下三层着手。
第一层，看知识库覆盖度。如果用户经常提问的内容根本不在知识库里，RAG再努力也没有用。针对这个问题，一方面要扩充资料源，另一方面要在提示词里明确告诉模型“资料中没有的内容可以直接说不知道”。这一招非常有效，很多时候用户能接受“查不到”，但绝不接受“胡说八道”。
第二层，看检索效果。如果知识库有对应内容却没能召回，问题就在分块和检索策略上，参考前面5.1小节检查。
第三层，看提示词约束是否足够。如果检索命中但模型仍然生成越界内容，比如靠自身固有的常识进行了扩展描述，这时候需要强化提示词里的边界约束，比如“严格依据参考材料逐句作答”“不得补充材料之外的生活常识”。还可以引入答案溯源机制，在回答后方附上引用来源，一旦出错用户可以立刻点进去核对原文。
最后聊一个我个人的体会：做RAG项目最忌讳的是一上来就追求花哨的架构和复杂的参数调优。先把基础链路拆得足够细，数据清洗、分块、检索、生成，每部分都跑通并确认效果，再去叠加混合检索、重排序、上下文压缩这些进阶策略。很多时候，单纯把分块策略从固定大小换成结构感知、把提示词里的约束写得更明确，就能带来肉眼可见的效果提升。这个领域迭代速度很快，但核心的东西始终是那几件事：数据质量、检索准确率、可控生成本文。把这几件事做扎实了，什么框架和模型在变，你都稳得住。
