RAG 调优别急着换模型：先检查这 7 处配置

2026 年，即使底座换成 Llama 4 或 Qwen 2.5，企业文档问答仍可能出现两种故障：片段搜到了，答案却拼错；回答看着正确，却给不出出处。

RAG 会把外部知识库中的相关内容与用户问题一起送入 LLM。检索、上下文组织和生成约束中的偏差，都会传到最终输出。关于这条链路的基本原理，可参见《检索增强生成（RAG）当前技术路线与前沿进展》和大语言模型的 RAG 方法介绍。

一组内部 A/B 测试提供了一个具体样本：知识库约 420 万 Token，内容为工业设备维护文档；Baseline 使用 LangChain 默认配置，Optimized 调整了七处配置。整体记录中，答案忠实度（Faithfulness）从 62% 升至 89%，检索命中率（Hit Rate）提高 15%。

数据说明：下文百分比均来自该内部测试记录，测试未附完整评测集和指标计算细节。忠实度、命中率、生成准确率等名称按原记录保留，不作跨指标换算，也不应当作其他项目的通用基准。

切块先保住一个完整动作

chunk_size 常被直接设为 512 或 1024，但企业文档并不整齐。一个完整操作步骤可能跨越 800 Token，一个定义也可能只有 50 Token。按固定长度硬切，很容易把条件、动作和结果拆到不同片段里。

这组技术手册测试将优化配置改成了语义分割（Semantic Chunking）。如果系统只能使用固定长度，512 可以作为起点，同时配合重叠窗口。

LlamaIndex 的 SentenceWindowNodeParser 也适合这类文档：检索时匹配较短的句子，送入 LLM 前再扩展周围的上下文。这样既能保留检索粒度，也能减少步骤被截断的情况。

Overlap 只负责补上断口

chunk_overlap=0 时，相邻片段没有任何衔接，关键信息可能正好从中间断开。原测试给出的扫描范围是 chunk_size 的 10%—20%。

当 chunk_size=512 时，测试把重叠度从 0 调到 80 Token，步骤类问答的答案连贯性提高了 11%。80 Token 是这组文档的测试值，其他知识库仍要根据段落长度和上下文预算重新验证。

Top-k 先扩大候选，再收紧输入

top_k 决定检索阶段拿回多少片段，不代表这些片段都要交给 LLM。候选过少可能漏掉答案，候选过多则会把噪声一起送进上下文，还可能触发“迷失在中间”（Lost in the Middle）。

没有重排序时，top_k 可以先在 3—5 之间测试。加入 Rerank 后，检索阶段可放宽到 20—50 个候选，最终送入 LLM 的 Rerank Top-k 收到 5—8 个。这组 A/B 测试采用的是 20 → Rerank → 5。

相似度阈值要靠扫描，不要照抄 0.72

向量数据库会按距离返回前 k 个结果。即使第 k 个片段与问题关系很弱，它仍然会出现在列表里。没有 Similarity Threshold 时，LLM 只能在这些片段中自行判断，幻觉风险随之增加。

原测试在 0.6—0.8 之间扫描阈值，最终采用 0.72，过滤掉 22% 的低质量片段。无效片段减少后，输入 Token 和 API 成本也会下降。相关成本排查可参见《LLM 推理账单怎么降：2026 年先查这 20 处浪费》。

0.72 只对应这组知识库和检索配置，更适合作为测试起点，直接复制到另一套系统风险很高。

Rerank 把“伪相关”片段挤出去

Dense Retrieval 擅长找到语义相近的内容，但对精确关系的判断不够稳定。可以先取回 20 个候选片段，再用 Cross-Encoder 模型二次打分。原测试使用的是 BGE-Reranker-v2。

测试记录如下：

• 仅使用向量检索：命中率 65%，生成准确率 62%；
• 向量检索加 BGE-Reranker：命中率 78%，生成准确率 89%。

按生成准确率计算，两组相差 27 个百分点。这个结果也解释了为什么继续放大 top_k 往往不够：候选数量增加后，还需要一个模型判断哪些片段真正值得留下。

Reranker 也是链路中计算较密集的一环。如果整条 Agent/RAG 链路迁往昇腾 910D 等国产硬件，需要单独压测它的推理延迟，不能只看生成模型的吞吐。

用户说得含糊，先改写查询

用户可能只问“那个报错怎么解？”，文档里写的却是“关于 Error 404 的异常处理流程”。直接拿口语问题做向量检索，召回往往不稳定。

可选方案包括 Multi-Query 和 HyDE（假设性文档嵌入）。原测试的做法是先让 LLM 将问题扩展为 3 个不同维度的同义问题，分别检索，再合并结果。在口语化较重的非结构化客服场景中，检索覆盖率提高约 20%。

查询改写会增加一次模型调用，因此仍要和延迟、Token 成本一起评估。

Prompt 要把回答边界写清楚

只写一句“请根据上下文回答”，约束通常不够。模型仍可能调用预训练知识补全缺失信息，答案看似通顺，却无法从知识库中验证。

可以把生成指令改得更明确：

你是一个严谨的知识库助手。请仅使用提供的【上下文】回答问题。如果【上下文】中没有相关信息，请直接回答“知识库中未记录此信息”，严禁调用预训练知识进行推测。每个答案必须在句末标注引用来源，格式为 [片段 ID]。

这道约束放在链路最后，主要解决两件事：减少脱离检索片段的补全，并让每句话能够追溯到具体来源。

案例配置放到一张表里

注：内部记录同时使用了“整体命中率提高 15%”和“重排序子项命中率 65%→78%”两组表述。由于评测口径未展开，这里不做换算。

上线前，先拿 500 条真实问题过一遍

无论链路由 LangChain 还是 LlamaIndex 搭建，上面的数值都只适合当作参数起点。上线前至少整理 500 条真实用户 Query，建立自己的评测集。

评测时同时记录检索命中率、答案忠实度、引用是否完整，以及延迟、Token 消耗和 API 成本。调参可以沿着链路往下走：先检查切块有没有拆坏答案，再测试 Top-k 与相似度阈值，随后加入 Rerank 和查询改写，最后收紧生成 Prompt。

420 万 Token 案例说明，RAG 的回答质量不只取决于底座模型。切块、候选数量、噪声过滤和引用约束，任何一处使用默认值，都可能把正确证据挡在最终答案之外。

参考资料

• 检索增强生成（RAG）当前技术路线与前沿进展
• 一文读懂：大模型 RAG（检索增强生成）含高级方法
• 【RAG 系统综述】一文读懂大模型 RAG
• 检索增强生成（RAG）和人类专业知识如何优化 AI 性能
• 大语言模型的检索增强生成（RAG）方法