RAG参数调优：4个关键设置让性能从可用变好用

为什么同样的 RAG 代码，检索结果总是答非所问？

前两篇文章我们搭建了一个可运行的 RAG Pipeline。但很快会发现：代码虽然跑通了，回答质量却忽高忽低——有时准确得惊人，有时文档里明明有答案，检索却扑了个空；有时检索命中了，大模型却啰嗦半天仍偏题。

问题往往不在代码层，而在参数配置。

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 直接影响两个指标：

切得太小会有哪些问题？文档中写到：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。如果超过这个时间，数据会被自动清理。”若 Chunk Size=128，这句话可能被切成两块：“系统使用 Redis 做缓存，默认过期时间是 3600 秒。”和“如果超过这个时间，数据会被自动清理。”当你问“Redis 缓存过期后会发生什么？”时，Retriever 可能只召回第一块，LLM 看到“3600 秒”却不知道后面还有“自动清理”——答案自然不完整。

切得太大呢？假设 Chunk Size=2048，一个块里塞了5个不相关的主题。当你问某个具体问题，这个块被召回后，LLM 的注意力会被无关内容稀释——就像在嘈杂的菜市场里想听清一个人说话，非常困难。

如何选择？

没有银弹，但有一条经验法则可供参考：

Chunk Size ≈ 期望答案长度的 1.5 ~ 2 倍

参数二：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%：

参数三：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

参数四：Embedding Model —— 谁来担任「语义翻译」？

Embedding 是 RAG 的「翻译官」

Embedding 模型的任务很简单：将文本转化为一串数字（向量）。语义相似的文本，向量之间的距离就近；语义不相似的，距离就远。

Retriever 正是依赖这个原理——将用户问题转换为向量，然后在向量库中寻找距离最近的块。

不同模型的差异有多大？

非常大。同一个问题，不同模型召回的结果可能截然不同。

一个真实的对比实验

我们用同一份中文技术文档（《Automotive SPICE PAM v4.0》），同一个问题，对比 text-embedding-3-small 和 BAAI/bge-large-zh-v1.5 的召回效果：

问题：“什么是过程能力等级 1？”

原因很简单：OpenAI 的模型主要基于英文语料训练，对中文专业术语的理解远不如 BGE 这样在中文语料上专门微调过的模型。

如何选择 Embedding 模型？

决策树如下：

你的文档是什么语言？├─ 纯英文 → text-embedding-3-small（性价比最高）│ 或 text-embedding-3-large（精度最高）├─ 纯中文 → BAAI/bge-large-zh-v1.5（国内首选）│ 或 BAAI/bge-m3（如果有中英混合）└─ 中英混合 → BAAI/bge-m3（多语言支持最好）

实战：控制变量实验

我们来做一次实验：使用同一份文档、同一个问题，仅改变 Chunk Size，观察答案质量如何变化。

实验设计

"""RAG 参数控制变量实验固定：文档、问题、Embedding 模型、Top-K、LLM变量：Chunk Size"""import osfrom pathlib import Pathfrom langchain_text_splitters import RecursiveCharacterTextSplitterfrom langchain_chroma import Chromafrom langchain_community.document_loaders import PyPDFLoaderfrom langchain_core.prompts import ChatPromptTemplatefrom langchain_core.output_parsers import StrOutputParserfrom langchain_core.runnables import RunnablePassthroughfrom langchain_openai import ChatOpenAI, OpenAIEmbeddings# 加载文档doc = PyPDFLoader("./data/Automotive-SPICE-PAM-v40.pdf").load()# Embedding（固定）embeddings = OpenAIEmbeddings(model="BAAI/bge-large-zh-v1.5",api_key=os.getenv("EMBEDDING_API_KEY"),base_url="https://api.siliconflow.cn/v1",chunk_size=32,)# LLM（固定）llm = ChatOpenAI(model="glm-4-flash",api_key=os.getenv("LLM_API_KEY"),base_url="https://open.bigmodel.cn/api/paas/v4",temperature=0,)# 测试不同 Chunk Sizedef test_chunk_size(chunk_size, overlap):print(f"n{'='*50}")print(f"Chunk Size={chunk_size}, Overlap={overlap}")print(f"{'='*50}")# 切分splitter = RecursiveCharacterTextSplitter(chunk_size=chunk_size,chunk_overlap=overlap,length_function=len,)chunks = splitter.split_documents(doc)print(f"生成 {len(chunks)} 个块")# 建向量库persist_dir = f"./chroma_db_{chunk_size}"if os.path.exists(persist_dir):import shutilshutil.rmtree(persist_dir)vector_store = Chroma.from_documents(documents=chunks,embedding=embeddings,persist_directory=persist_dir,)# 构建 RAG Chain（LCEL 方式）retriever = vector_store.as_retriever(search_kwargs={"k": 4})prompt = ChatPromptTemplate.from_messages([("system", "根据参考内容回答。参考：n{context}"),("human", "{question}")])rag_chain = ({"context": retriever | (lambda docs: "nn".join(d.page_content for d in docs)), "question": RunnablePassthrough()}| prompt | llm | StrOutputParser())# 提问question = "什么是过程能力等级 1？"answer = rag_chain.invoke(question)print(f"n答案：{answer[:200]}...")# 打印召回的来源sources = retriever.invoke(question)print(f"n召回 {len(sources)} 个来源：")for i, s in enumerate(sources[:3], 1):print(f"[{i}] 第{s.metadata.get('page', '?')}页: {s.page_content[:80]}...")# 跑三组实验test_chunk_size(chunk_size=128, overlap=20)test_chunk_size(chunk_size=512, overlap=50)test_chunk_size(chunk_size=1024, overlap=100)

预期结果

最常踩的 5 个坑

坑 1：Chunk Size 按 Token 数设置，但 length_function 用的是字符数

# ❌ 错误：你以为 chunk_size=512 是 512 个 Tokensplitter = RecursiveCharacterTextSplitter(chunk_size=512)# 实际上默认 length_function=len 是按字符数！# 512 字符 ≈ 256 Token（中文），导致块比你想象的小一半

解法：如果要用 Token 数，需要显式指定 tokenizer：

import tiktokendef token_length(text):return len(tiktoken.encoding_for_model("gpt-4").encode(text))splitter = RecursiveCharacterTextSplitter(chunk_size=512,length_function=token_length,# ✅ 按 Token 数算)

坑 2：Overlap 太大，导致向量库里 30% 都是重复内容

Overlap 并非免费。每个重叠字符都需要做一次 Embedding 计算，并在向量库里占一份存储。Overlap=100、Chunk Size=200 意味着 50% 的存储是冗余的。

解法：Overlap 设为 Chunk Size 的 10%~15%，不要超过 20%。

坑 3：换了 Embedding 模型，但没清空旧向量库

# ❌ 错误：昨天用 BGE 建了索引，今天换成 OpenAI，直接复用同一个 chroma_db/vector_store = Chroma.from_documents(documents=chunks, embedding=new_embeddings)# 结果：查询时用的向量和索引时的向量来自不同模型，完全对不上

解法：换 Embedding 模型时，必须删除旧向量库重新索引：

if os.path.exists(persist_directory):shutil.rmtree(persist_directory)# ✅ 清空旧数据

坑 4：Top-K 固定写死，没有根据问题复杂度动态调整

所有问题都用 K=4，但“默认端口是多少？”（简单事实）和“总结第三章的所有要点”（综合概述）所需的信息量完全不同。

解法：简单问题用 K=34，复杂问题用 K=810。更进阶的做法是用 LLM 先判断问题复杂度，再动态决定 K 值（后续文章会展开）。

坑 5：没有监控“空召回”（Zero Retrieval）

有时候 Retriever 召回了 0 个相关块（比如用户问了一个文档里完全没有的话题），但你不知道，LLM 只能凭记忆瞎编。

解法：给检索结果加阈值过滤——如果最相似的块的相似度分数低于某个阈值（比如 0.6），直接告诉用户“文档里没有相关信息”，而不是把不相关的块塞给 LLM：

# 在检索后加一层过滤docs = retriever.invoke(question)if not docs or max_similarity < 0.6:return "抱歉，根据现有文档无法回答这个问题。"

参数选择速查表

把上面的内容浓缩成一张表，贴在显示器旁随时查阅：

小结

这篇文章我们逐个拆解了 RAG 最核心的 4 个参数：

1. Chunk Size：决定每个文本块的长度。默认 512，短答案场景用 256，长论述场景用 1024。
2. Chunk Overlap：控制相邻块的重叠范围。默认取 Chunk Size 的 10%，避免跨块信息被切断。
3. Top-K：指定召回块的数量。默认 4，复杂问题增大到 8，简单问题减小到 3。
4. Embedding Model：中文推荐 BGE，英文推荐 OpenAI；切换时必须清空向量库重建索引。

并通过控制变量实验证明：参数并非越大或越小越好，关键是根据文档类型和查询模式找到最佳平衡点。

参考资料

• LangChain Text Splitters 文档 —— 官方分块策略详解
• BGE Embedding 模型 GitHub —— 中文 Embedding 最佳实践
• MTEB Leaderboard —— Embedding 模型权威排行榜
• ChromaDB 距离度量说明 —— 余弦相似度 vs 欧氏距离

来源：互联网