为什么同样的代码，你的 RAG 却答不对？前两篇文章我们搭了一个能跑通的 RAG Pipeline。但很多人发现：代码虽然跑起来了，答案质量却时好时坏——有时候精准命中，有时候明明文档里有答案却检索不到，有时候检索到了但 LLM 却答偏了。问题通常不在代码，而在参数。RAG 有 4 个核心参数，它们像收音机的四个旋钮：Chunk Size（块大小）：决定一块文本有多长Chunk Overlap（重叠长度）：决定相邻两块有多少重叠Top-K（召回数量）：决定每次检索返回多少块Embedding Model（嵌入模型）：决定文本怎么转成向量这四个参数的组合，直接决定了"能不能找到相关信息"和"找到的信息够不够回答"。本文会用控制变量实验的方式，让你亲眼看到不同参数的效果差异。参数一：Chunk Size —— 一块文本切多长？什么是 Chunk Size？想象你在整理一本 500 页的技术手册。Chunk Size 就是你每次翻开看多少页——看 1 页、看 5 页、还是看 50 页？在 RAG 里，Chunk Size 是每个文本块的最大字符数（或 Token 数）。文档被切成很多块，每块不超过这个长度。为什么它很重要？Chunk Size 直接影响两个指标：Chunk Size检索精度上下文完整性通俗理解太小（128）高差像看词典词条——精准但孤立中等（512）中中像看一段话——有上下文又不太长太大（2048）低好像看一整章——信息全但噪音多太小了有什么问题？假设文档里写：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。如果超过这个时间，数据会被自动清理。” 如果 Chunk Size=128，这句话可能被切成两块：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。” 和 “如果超过这个时间，数据会被自动清理。” 当你问"Redis 缓存过期后会发生什么？“，Retriever 可能只召回第一块，LLM 看到"3600 秒"却不知道后面还有"自动清理”——答案就不完整。太大了有什么问题？假设 Chunk Size=2048，一个块里塞了 5 个不相关的主题。当你问某个具体问题，这个块被召回后，LLM 的注意力被无关内容分散了——就像让你在嘈杂的菜市场里听清一个人说话。怎么选？没有银弹，但有经验法则：Chunk Size ≈ 你期望的答案长度的 1.5 ~ 2 倍文档类型推荐 Chunk Size理由FAQ / 问答对256 ~ 384答案短，精准匹配更重要技术文档 / API 手册512 ~ 768答案中等长度，需要一定上下文论文 / 书籍章节1024 ~ 1536论述性强，需要大段上下文理解法律合同 / 医疗记录768 ~ 1024专业术语多，需要前后文推断经验公式：先用 512 跑一遍，然后观察检索结果。如果发现"答案被切断了"就增大，如果发现"检索到的块里有很多无关内容"就减小。参数二：Chunk Overlap —— 相邻块重叠多少？什么是 Chunk Overlap？还是那本技术手册。如果你每次看 5 页，Overlap 就是每次翻页时保留几页上一章的内容。比如 Overlap=1 表示：第一次看 1-5 页，第二次看 5-9 页（第 5 页重复出现）。为什么需要重叠？没有重叠，关键信息可能被"切在接缝处"：块 A："系统使用 Redis 做缓存，默认过期时间是 3600 秒。" 块 B："如果超过这个时间，数据会被自动清理。"如果用户问"Redis 缓存过期后会发生什么？“，Embedding 模型可能觉得块 B 和问题更相关（因为都提到了"过期后”），只召回块 B。但块 B 开头是"如果超过这个时间"——没有块 A，LLM 不知道"这个时间"指的是什么。有了 Overlap=50，块 B 开头会带上前 50 个字符：块 B（带重叠）："默认过期时间是 3600 秒。如果超过这个时间，数据会被自动清理。"现在即使只召回块 B，LLM 也能看懂"这个时间=3600 秒"。Overlap 该设多少？一般设为 Chunk Size 的10% ~ 20%：Chunk Size推荐 Overlap说明25625 ~ 50文本短，稍微重叠就能保住上下文51250 ~ 100通用场景的黄金比例1024100 ~ 200长文本需要更多重叠来保衔接注意：Overlap 不是越大越好。Overlap 太大会导致向量库里存储大量重复内容，增加存储成本和检索时的去重负担。参数三：Top-K —— 召回多少块？什么是 Top-K？Top-K 是 Retriever 每次返回的文本块数量。K=4 表示"给我最相关的 4 个块"，K=10 表示"给我最相关的 10 个块"。为什么它很重要？K 太小 = 漏信息。K 太大 = 引入噪声。场景 A：K=2，漏掉了关键信息用户问：“怎么配置数据库连接池和日志级别？” 这个问题涉及两个主题。如果 K=2，Retriever 可能只返回"数据库连接池"相关的两块，完全没提到"日志级别"——LLM 只能回答一半。场景 B：K=20，噪音淹没了答案用户问：“默认超时时间是多少？” 文档里有明确答案。但 K=20 召回了 20 个块，其中 19 个都在讲不相关的主题。LLM 的上下文窗口被无关内容占满，反而找不到那个简单的数字。怎么选？Top-K = 期望的答案涉及的主题数 × 2 ~ 3查询类型推荐 K理由单点事实查询（“默认端口是多少？”）3 ~ 5答案集中，少而精多条件查询（“怎么配 A 和 B？”）5 ~ 8可能涉及多个主题综合概述（“总结第三章的内容”）8 ~ 12需要覆盖整章的多个要点经验公式：从 K=4 开始。如果发现"答案缺了一部分"就增大，如果发现"答案里有不相关的内容"就减小。参数四：Embedding Model —— 谁来做「语义翻译」？Embedding 是 RAG 的「翻译官」Embedding 模型干的事很简单：把文本变成一串数字（向量）。语义相似的文本，向量距离就近；语义不相似的，向量距离就远。Retriever 靠的就是这个——把用户问题转成向量，然后在向量库里找距离最近的那些块。不同模型的差异有多大？非常大。同一个问题，不同模型召回的结果可能完全不同。模型擅长语言维度定位适合场景text-embedding-3-small RAG 系列（三）：调对这 4 个参数，让你的 RAG 从「能用」变「好用」
为什么同样的代码，你的 RAG 却答不对？前两篇文章我们搭了一个能跑通的 RAG Pipeline。但很多人发现：代码虽然跑起来了，答案质量却时好时坏——有时候精准命中，有时候明明文档里有答案却检索不到，有时候检索到了但 LLM 却答偏了。问题通常不在代码，而在参数。RAG 有 4 个核心参数，它们像收音机的四个旋钮：Chunk Size（块大小）：决定一块文本有多长Chunk Overlap（重叠长度）：决定相邻两块有多少重叠Top-K（召回数量）：决定每次检索返回多少块Embedding Model（嵌入模型）：决定文本怎么转成向量这四个参数的组合，直接决定了"能不能找到相关信息"和"找到的信息够不够回答"。本文会用控制变量实验的方式，让你亲眼看到不同参数的效果差异。参数一：Chunk Size —— 一块文本切多长？什么是 Chunk Size？想象你在整理一本 500 页的技术手册。Chunk Size 就是你每次翻开看多少页——看 1 页、看 5 页、还是看 50 页？在 RAG 里，Chunk Size 是每个文本块的最大字符数（或 Token 数）。文档被切成很多块，每块不超过这个长度。为什么它很重要？Chunk Size 直接影响两个指标：Chunk Size检索精度上下文完整性通俗理解太小（128）高差像看词典词条——精准但孤立中等（512）中中像看一段话——有上下文又不太长太大（2048）低好像看一整章——信息全但噪音多太小了有什么问题？假设文档里写：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。如果超过这个时间，数据会被自动清理。” 如果 Chunk Size=128，这句话可能被切成两块：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。” 和 “如果超过这个时间，数据会被自动清理。” 当你问"Redis 缓存过期后会发生什么？“，Retriever 可能只召回第一块，LLM 看到"3600 秒"却不知道后面还有"自动清理”——答案就不完整。太大了有什么问题？假设 Chunk Size=2048，一个块里塞了 5 个不相关的主题。当你问某个具体问题，这个块被召回后，LLM 的注意力被无关内容分散了——就像让你在嘈杂的菜市场里听清一个人说话。怎么选？没有银弹，但有经验法则：Chunk Size ≈ 你期望的答案长度的 1.5 ~ 2 倍文档类型推荐 Chunk Size理由FAQ / 问答对256 ~ 384答案短，精准匹配更重要技术文档 / API 手册512 ~ 768答案中等长度，需要一定上下文论文 / 书籍章节1024 ~ 1536论述性强，需要大段上下文理解法律合同 / 医疗记录768 ~ 1024专业术语多，需要前后文推断经验公式：先用 512 跑一遍，然后观察检索结果。如果发现"答案被切断了"就增大，如果发现"检索到的块里有很多无关内容"就减小。参数二：Chunk Overlap —— 相邻块重叠多少？什么是 Chunk Overlap？还是那本技术手册。如果你每次看 5 页，Overlap 就是每次翻页时保留几页上一章的内容。比如 Overlap=1 表示：第一次看 1-5 页，第二次看 5-9 页（第 5 页重复出现）。为什么需要重叠？没有重叠，关键信息可能被"切在接缝处"：块 A："系统使用 Redis 做缓存，默认过期时间是 3600 秒。" 块 B："如果超过这个时间，数据会被自动清理。"如果用户问"Redis 缓存过期后会发生什么？“，Embedding 模型可能觉得块 B 和问题更相关（因为都提到了"过期后”），只召回块 B。但块 B 开头是"如果超过这个时间"——没有块 A，LLM 不知道"这个时间"指的是什么。有了 Overlap=50，块 B 开头会带上前 50 个字符：块 B（带重叠）："默认过期时间是 3600 秒。如果超过这个时间，数据会被自动清理。"现在即使只召回块 B，LLM 也能看懂"这个时间=3600 秒"。Overlap 该设多少？一般设为 Chunk Size 的10% ~ 20%：Chunk Size推荐 Overlap说明25625 ~ 50文本短，稍微重叠就能保住上下文51250 ~ 100通用场景的黄金比例1024100 ~ 200长文本需要更多重叠来保衔接注意：Overlap 不是越大越好。Overlap 太大会导致向量库里存储大量重复内容，增加存储成本和检索时的去重负担。参数三：Top-K —— 召回多少块？什么是 Top-K？Top-K 是 Retriever 每次返回的文本块数量。K=4 表示"给我最相关的 4 个块"，K=10 表示"给我最相关的 10 个块"。为什么它很重要？K 太小 = 漏信息。K 太大 = 引入噪声。场景 A：K=2，漏掉了关键信息用户问：“怎么配置数据库连接池和日志级别？” 这个问题涉及两个主题。如果 K=2，Retriever 可能只返回"数据库连接池"相关的两块，完全没提到"日志级别"——LLM 只能回答一半。场景 B：K=20，噪音淹没了答案用户问：“默认超时时间是多少？” 文档里有明确答案。但 K=20 召回了 20 个块，其中 19 个都在讲不相关的主题。LLM 的上下文窗口被无关内容占满，反而找不到那个简单的数字。怎么选？Top-K = 期望的答案涉及的主题数 × 2 ~ 3查询类型推荐 K理由单点事实查询（“默认端口是多少？”）3 ~ 5答案集中，少而精多条件查询（“怎么配 A 和 B？”）5 ~ 8可能涉及多个主题综合概述（“总结第三章的内容”）8 ~ 12需要覆盖整章的多个要点经验公式：从 K=4 开始。如果发现"答案缺了一部分"就增大，如果发现"答案里有不相关的内容"就减小。参数四：Embedding Model —— 谁来做「语义翻译」？Embedding 是 RAG 的「翻译官」Embedding 模型干的事很简单：把文本变成一串数字（向量）。语义相似的文本，向量距离就近；语义不相似的，向量距离就远。Retriever 靠的就是这个——把用户问题转成向量，然后在向量库里找距离最近的那些块。不同模型的差异有多大？非常大。同一个问题，不同模型召回的结果可能完全不同。模型擅长语言维度定位适合场景text-embedding-3-small