收藏 | 程序员小白必看：手把手教你把 RAG 从“能用“提到“好用“！

嘴巴吃糖了

368人浏览 · 2026-04-25 11:34:33

嘴巴吃糖了 · 2026-04-25 11:34:33 发布

01 为什么 RAG 效果差？先定位问题根源

很多人调了半天 prompt，结果大模型还是答错了。根源不在生成，在检索。

RAG 的效果链路是：

用户问题

    │

    ▼

[ 检索层 ]

    │

    ├── 分块质量差 → 上下文残缺 → 召回无关块

    ├── 只用向量检索 → 关键词命中率低

    ├── 没有 Rerank → 排名靠后的相关块被截断

    │

    ▼

[ 生成层 ]

    │

    └── 拿到残缺/无关上下文 → 答案偏差/幻觉

三个核心问题，三个解法，今天一次讲完。

02 分块策略：这是 RAG 效果的地基

分块（Chunking）就是把长文档切成小片段，再入库。块的大小和切法，直接决定检索召回的上限。

一个反直觉的事实： 块太大 ≠ 信息更全，块太小 ≠ 检索更准。

块太大（1000+ tokens）：

┌──────────────────────────────────────┐

│  无关噪声  │  相关内容  │  无关噪声  │

└──────────────────────────────────────┘

         ↓ 向量被稀释，相关度下降

块太小（50 tokens）：

┌────┐┌────┐┌────┐

│ A1 ││ A2 ││ A3 │  一个完整语义被切断

└────┘└────┘└────┘

         ↓ 上下文缺失，LLM 看不懂

合理块（200-500 tokens + overlap）：

┌──────────────┐

│  完整语义单元  │  带20%重叠确保边界不丢

└──────────────┘

         ↓ 召回精准，上下文完整

4种主流分块策略对比：

策略	适用场景	优点	缺点
固定长度（Fixed-size）	通用文本	简单快速	可能切断语义
递归字符（Recursive）	结构化文档	尊重自然边界	需要调参
语义分块（Semantic）	知识密集文档	语义完整	计算成本高
父子分块（Parent-Child）	长文档精检索	召回精准+上下文全	实现复杂

工程上用得最多的是「父子分块」，检索小块、返回大块，兼顾精准和完整。

importRecursiveCharacterTextSplitterfrom"@langchain/textsplitters"importMemoryVectorStorefrom"langchain/vectorstores/memory"importParentDocumentRetrieverfrom"langchain/retrievers/parent_document"importInMemoryStorefrom"@langchain/core/stores"// 父块：大块，保证上下文完整（2000 tokens）constnewRecursiveCharacterTextSplitterchunkSize2000chunkOverlap200// 子块：小块，用于精准检索（200 tokens）constnewRecursiveCharacterTextSplitterchunkSize200chunkOverlap20// 父块存到 docstore（内存或 Redis）constnewInMemoryStore// 子块向量化，入向量库constawaitMemoryVectorStorefromDocuments// 父子检索器：检索子块，返回父块constnewParentDocumentRetrievervectorstoredocstoreparentSplitterchildSplitter// 入库awaitaddDocuments// 检索：命中子块 → 自动返回对应父块constawaitinvoke"你的问题"consolelog0pageContent// 返回完整的父块内容

03 Overlap 设置：边界不丢才是关键

很多同学忽视了 overlap（重叠窗口）。这个参数不起眼，但是关键句跨块的救命稻草。

不设 overlap：

块1：[...Apple今年发布了新款MacBook Pro，搭载M3芯片]

块2：[性能相比上代提升40%，续航延长至22小时...]

     ↑ "性能提升40%"是接着M3芯片说的，切断了！

设置 overlap=100：

块1：[...Apple今年发布了新款MacBook Pro，搭载M3芯片]

块2：[搭载M3芯片，性能相比上代提升40%，续航延长至22小时...]

     ↑ 重叠部分把语境带过来了

工程经验：

中文文档：overlap = chunkSize × 10%~15%
技术文档（含代码）：overlap = chunkSize × 20%
纯代码块：按函数/类边界切，不要硬切

04 混合检索：向量 + BM25，召回率直接拉满

纯向量检索有个死穴——关键词精确匹配弱。

用户问「LangChain v0.3 的 breaking change 有哪些」，向量检索只能捕捉语义相似，但版本号「v0.3」这种精确词汇，BM25 才能稳稳命中。

纯向量检索：

查询: "LangChain v0.3 breaking change"

    │

    ▼

向量空间计算语义相似度

    │

    └── 召回了"LangChain 更新内容"（正确）

        但漏掉了明确标注 "v0.3" 的文档（漏召回）

纯 BM25 检索：

    │

    └── 精确命中 "v0.3" 关键词（正确）

        但漏掉了语义相近但表述不同的文档

混合检索（Hybrid Search）：

向量结果 ───┐

            ├── RRF 融合 ──→ 最终排序

BM25结果 ───┘

     ↑ 两者互补，召回率最大化

LangChain 的 EnsembleRetriever 实现很简洁：

importBM25Retrieverfrom"@langchain/community/retrievers/bm25"importEnsembleRetrieverfrom"langchain/retrievers/ensemble"// 向量检索器（接 Milvus / Chroma 等）constasRetrieverk10// 多取一些，后续 Rerank 会精选// BM25 关键词检索器constBM25RetrieverfromDocumentsk10// 混合检索：RRF 算法融合排名// weights: 向量占0.6，BM25占0.4（可根据场景调）constnewEnsembleRetrieverretrieversweights0.60.4constawaitinvoke"LangChain v0.3 breaking change"// 返回两路召回的融合结果，按 RRF 分数重排

RRF（倒数排名融合）算法原理：

文档 D 在向量检索中排名 r1，在 BM25 中排名 r2

RRF(D) = 1/(k + r1) + 1/(k + r2)    k=60（平滑参数）

例：

  向量排名第2，BM25排名第1：

  RRF = 1/62 + 1/61 ≈ 0.0323

  向量排名第8，BM25排名第3：

  RRF = 1/68 + 1/63 ≈ 0.0306

两路都靠前的文档，RRF 分数最高 → 排到最前面

05 Rerank：第二关筛选，把最相关的送进上下文

混合检索帮你扩大了召回，但 LLM 的 context window 有限，最终只能放进去 3-5 个块。

这时候 Rerank 模型上场——它不看向量距离，而是直接用交叉注意力机制，对「查询+文档」联合打分，精度远高于向量相似度。

没有 Rerank 的问题：

向量检索 Top-5：

  ✅ 文档A（最相关，排第3）

  ❌ 文档B（相似但无关，排第1）

  ❌ 文档C（语义相近但答不了，排第2）

  ✅ 文档D（相关，排第4）

  ❌ 文档E（无关，排第5）

LLM 拿到 Top-3 → B、C、A  → 前两个都是干扰！

加了 Rerank 之后：

Rerank 重新打分（交叉注意力）：

  文档A → 0.95 ← 最相关

  文档D → 0.88 ← 次相关

  文档B → 0.23 ← 重排后被踢出

  文档C → 0.18 ← 重排后被踢出

  文档E → 0.09 ← 重排后被踢出

LLM 拿到 Top-3 → A、D、... → 全是精华

importCohereRerankfrom"@langchain/cohere"importContextualCompressionRetrieverfrom"langchain/retrievers/contextual_compression"// Rerank 模型（Cohere 或开源 BGE-Reranker）constnewCohereRerankapiKeyenvCOHERE_API_KEYmodel"rerank-multilingual-v3.0"// 支持中文topN3// 最终保留3个// 两步检索：先召回20个，再 Rerank 精选3个constnewContextualCompressionRetrieverbaseCompressorbaseRetriever// 接上一步的混合检索constawaitinvoke"你的问题"// rerankedDocs 是经过 Rerank 精选的 Top-3，送进 LLM 生成

如果用开源 BGE-Reranker（不需要 API key）：

importHuggingFaceInferenceEmbeddingsfrom"@langchain/community/embeddings/hf"// 本地部署 BAAI/bge-reranker-v2-m3// 调用方式略有不同，用 HTTP 接口包装constasynccompressDocumentsdocs: Document[], query: stringconstawaitPromiseallmapasyncconstawaitfetch"http://localhost:8080/rerank"method"POST"headers"Content-Type""application/json"bodyJSONstringifytextpageContentconstawaitjsonreturnreturnsort(a, b) =>scorescoreslice03map(item) =>doc

06 完整 RAG Pipeline：把三件事串起来

把分块、混合检索、Rerank 穿成一条链：

原始文档

    │

    ▼

[父子分块]

    ├── 子块（200 tokens）→ 向量化入库

    └── 父块（2000 tokens）→ docstore 存储

    │

    ▼

用户提问

    │

    ├── 向量检索（Top-10）

    └── BM25检索（Top-10）

    │

    ▼

[EnsembleRetriever RRF 融合]

    │

    └── 融合结果（Top-20）

    │

    ▼

[Rerank 精选]

    │

    └── Top-3 最相关块

    │

    ▼

[LLM 生成]

    │

    └── 最终答案

importChatOpenAIfrom"@langchain/openai"importfrom"langchain/chains/combine_documents"importfrom"langchain/chains/retrieval"importChatPromptTemplatefrom"@langchain/core/prompts"constnewChatOpenAImodel"gpt-4o-mini"constChatPromptTemplatefromTemplate`你是专业的技术助手，根据以下上下文回答问题。如果上下文中没有答案，直接说"我不知道"，不要猜测。上下文:{context}问题: {input}`// 文档整合链constawaitcreateStuffDocumentsChain// 完整 RAG 链：混合检索 + Rerank + 生成constawaitcreateRetrievalChainretriever// 已含混合检索+Rerank// 执行constawaitinvokeinput"LangChain 的 LCEL 和传统 Chain 有什么区别？"consoleloganswer// 输出精准的答案，不再幻觉

07 效果调优：这几个参数决定最终表现

搭完之后别急着上线，这几个参数值得花时间调：

（1）chunk_size 怎么定？

文档类型              推荐 chunk_size   overlap

─────────────────────────────────────────────

FAQ / 问答对          200~300 tokens   50

技术文档（连续段落）   400~600 tokens   100

合同/法律文件          600~800 tokens   150

代码文件（按函数切）   300~500 tokens   50

（2）混合检索权重怎么调？

问答类（用户问精确问题）：向量0.4 + BM25 0.6（关键词更重要）
语义搜索类（模糊语义查询）：向量0.7 + BM25 0.3
通用场景：向量0.6 + BM25 0.4（默认起点）

（3）初检 k 值设多大？

Rerank 需要有足够的候选才能发挥作用，建议：

初检 k = Rerank topN × 5~10

例：最终需要 Top-3 → 初检至少召回 15~30 个

k 太小，相关文档没进候选，Rerank 巧妇难为无米之炊。

08 常见坑与自查清单

坑1：分块时没处理特殊字符

中文文档里的全角空格、「」书名号、……省略号，会干扰 BM25 分词，记得预处理清洗。

坑2：Rerank 拖慢响应

Rerank 是额外的模型调用，延迟真实存在。生产环境建议：

缓存高频查询的 Rerank 结果
或用更轻量的本地模型（BGE-Reranker-base）

坑3：父子检索的 docstore 没持久化

InMemoryStore 重启就清空。生产用 RedisStore 或 MongoDBStore 做持久化，否则父块找不回来。

坑4：混合检索中 BM25 索引没更新

向量库支持实时入库，但 BM25 索引通常是静态构建的。文档更新后记得重建 BM25 索引。

// 自查清单const"chunk_size 是否按文档类型调整"false"overlap 是否设置"false"父子分块 docstore 是否持久化"false"BM25 分词是否处理中文"false"RRF 权重是否按场景调整"false"初检 k 值是否 ≥ topN × 5"falseRerank"Rerank topN 是否 ≤ 5"false"高频查询是否加缓存"false"模型选型是否支持中文"false