手动调 RAG 是一件让人很头疼的事。
无论你是改 chunk size，还是换 embedding，或者是加个 reranker，都要重新跑结果。几十轮下来，单靠人工在 Excel 或是凭印象去记参数组合和评估结果，调到后面可能自己都记混配置——哪一组才是有效的组合？
其实，像是这种重复性任务刚好可以交给 Loop。尤其是这种任务往往步骤重复、结果可测量、需要不断尝试同一组旋钮，并通过一个明确指标判断结果好坏。
在本文我们会用一个例子，来实践一下如何把 RAG 调参包进一个工程 Loop。
假设我们现在有一个 RAG 系统和一组评估集，目标是把 recall@5 提到 0.9。我们会写好 Loop，让它自己去遍历搜索配置、运行评估，一旦达成既定目标就自动停下来，如果超过了最大运行限制也会及时熔断。
请记住，本文不是“让 Agent 神奇地调好 RAG”，是把一个重复性工程任务，变成一个有目标、有检查、有记录的自动循环。
RAG 调参和 Loop
Loop Engineering 有一个非常重要的前提：这个任务必须有一个自动检查机制。代码每次尝试新配置，系统得能自行判断这次跑出来的结果是好是坏。如果没有这个检查，Loop 就只能盲目运行，很难稳定改进。
而 RAG 调参刚好完美符合这个条件。
本文的检查指标是评估集的 recall@k。它是一个数字：有没有超过阈值，一目了然。就像跑单测，代码自己就能对齐结果，行就是行，不行就是不行，不用任何人为主观介入，也不用 Loop 去猜。
同时，RAG 调参本质上是在配置空间里搜索。chunk size、overlap、embedding、k 值、reranker、混合检索，这些组合起来会形成很大的搜索空间。人工试几轮之后就容易乱，但 Loop 不会累，也不会忘记自己试过什么组合。
准备工作
这个 Loop 不是从零搭一个 RAG 系统，它调的是一个在工作的 RAG pipeline。
所以，在启动 Loop 之前，你的工程里需要先准备好这 3 样东西：
一个跑通了且“暴露了关键参数接口”的 RAG pipeline。比如能随时传参修改 chunk_size、overlap、embedding_model、k 值、reranker 等。
一组标注好的评估集。不用特别庞大，大概 30～50 个典型问题就行，但每个问题都要明确配上它对应的正确源 chunk ID。没有这个评估集，自动检查就不能进行，更别提 Loop 了。
一个能返回指标的评估函数。这个函数负责接收一组 config 字典，重构完 pipeline 后在评估集上跑一遍检索，最后输出量化的召回率
recall@k。
下面这段代码就是整个 Loop 的“裁判”。Loop 每切到一组新参数，都会调用它去重新组装 pipeline，再在评估集上把所有的检索流程跑一遍，最后交出命中比例。
# eval.py — the loop's oracle, returns recall@k for a config
def evaluate(config, eval_set):
pipeline = build_rag(config) # build RAG with these parameters
hits = 0
for case in eval_set:
retrieved = pipeline.retrieve(case["question"], k=config["k"])
retrieved_ids = {c["id"] for c in retrieved}
if case["gold_chunk_id"] in retrieved_ids:
hits += 1
return hits / len(eval_set)
这段代码的重点不在具体的实现细节，而在它在架构里扮演的角色。
它是整个 Loop 的自动判断机制。Loop 每次尝试一组参数，都靠它判断这组参数是否更好。没有这个函数作基准，后面的自动搜索就没有依据。
定义搜索空间
Loop 要想干活，首先得知道它到底能动哪些旋钮。
不要一上来就给它开一个无限大的画布，要先定义一组真正会明显影响召回率的核心关键参数：chunk size、chunk overlap、embedding model、k 值、reranker，以及是否启用混合检索。
# search_space.py — what the loop searches
SEARCH_SPACE = {
"chunk_size": [400, 600, 800, 1200],
"chunk_overlap":[0, 100, 200],
"embedding": ["text-embedding-3-small", "bge-large", "e5-large"],
"k": [5, 10, 20],
"reranker": [None, "bge-reranker", "cohere-rerank"],
"hybrid": [False, True], # vectors only or vectors + BM25
}
这个搜索空间看起来不大，但组合起来有 4 × 3 × 3 × 3 × 3 × 2 = 648 种配置。
如果我们用粗暴的网格搜索全部盲扫一遍，不管是在时间成本上，还是 Token 账单上都会非常感人，而且这完全没有必要。所以，后面不能搞暴力破解，得让 Loop 用更聪明的方式逐步找更好的配置。
做一个可评估的检查
Loop 的重点是检查。在这个例子里，recall@k 是一个很好的检查指标，但它有两个常见问题。
第一个是过度适配评估集，Loop 会把评估集刷高了，但真实效果没有变好。如果 Loop 一直在同一组问题上优化，它可能会找到一组“刚好适合这几十个问题”的配置。最后 eval 分数变高了，但真实场景里的 RAG 效果不一定变好。
这和代码里的 reward hacking 很相似，只不过这里的 reward 变成了一个数字指标。
这个问题的解法是把评估集拆成两部分：一部分给 Loop 优化用，叫 train set；另一部分作为 held-out set，Loop 在调参过程中不能看到，最后只用它来检查最终配置是否可靠。
import random
def split_eval(eval_set, holdout_frac=0.3, seed=42):
random.Random(seed).shuffle(eval_set)
n = int(len(eval_set) * (1 - holdout_frac))
return eval_set[:n], eval_set[n:] # train for the loop, holdout for you
train_set, holdout_set = split_eval(eval_set)
这段代码的作用就是把评估集拆成 train 和 holdout。
第二个问题是测量噪声。如果评估集只有 30 个问题，那么 recall 从 0.87 到 0.90 的变化，可能并不代表真实提升，它只是样本太小带来的波动。
如果最小提升阈值设得太低，Loop 就容易把随机波动当成真实提升，围绕噪声反复调整。比较建议的做法是先设一个最小提升幅度。当 recall 的提升超过这个阈值时，再更新当前的最佳配置。比如这里可以把阈值设成 0.02；如果提升小于这个幅度，就先把它当作测量噪声，不急着改配置。
Loop 的聪明搜索
上面说过把 648 种组合全部扫一遍是又贵又慢。
这里可以换一个更简单的策略：coordinate descent。一次只调一个参数，其他参数先保持不变；这个参数找到当前最合适的取值之后，再调下一个参数。
这种方法不一定能找到全局最优解，但可以用较少的运行次数，找到一组足够好的配置。对于很多工程调参任务来说，这比人工一轮轮试参数更稳定，也更容易复现。
import json
def tune_rag(search_space, train_set, target_recall=0.9, max_evals=40):
# start from a sensible default
config = {
"chunk_size": 600, "chunk_overlap": 100,
"embedding": "text-embedding-3-small", "k": 10,
"reranker": None, "hybrid": False,
}
best_recall = evaluate(config, train_set)
evals_used = 1
log = []
# coordinate descent: one knob at a time
for param, values in search_space.items():
if evals_used >= max_evals:
break
best_value = config[param]
for value in values:
if value == config[param]:
continue
if evals_used >= max_evals:
break
trial = dict(config, **{param: value})
recall = evaluate(trial, train_set)
evals_used += 1
log.append({"config": trial, "recall": recall, "eval": evals_used})
# improvement significant only if above the noise threshold
if recall > best_recall + 0.02:
best_recall = recall
best_value = value
# GOAL check: hit it, exit without spending more runs
if best_recall >= target_recall:
config[param] = best_value
save_log(log)
return config, best_recall, evals_used
config[param] = best_value # lock in the best for this knob
save_log(log)
return config, best_recall, evals_used
def save_log(log):
with open("tune_log.jsonl", "w") as f:
for row in log:
f.write(json.dumps(row) + "\n")
这段代码的重点是给 Loop 设定了一套清晰的运行规则。
它先从一组合理的默认配置出发，再一次只调整一个参数：比如先尝试不同的 chunk_size，找到当前最好的取值后先锁定，再继续尝试 overlap、embedding、k 和 reranker。每次尝试新配置后，Loop 都会重新跑一遍评估，并检查是否已经达到 target_recall。一旦达到目标，Loop 就会立刻停止，不再消耗后面的运行次数。
同时，max_evals 相当于保险丝。如果目标在当前搜索空间里达不到，Loop 也不会无限跑下去。0.02 则是前面提到的最小提升阈值，只有当 recall 的提升超过这个幅度时，才会更新当前的 best_recall，避免被很小的随机波动带着走。
最后，Loop 的每一次尝试都会写入 jsonl 日志。这样调参结束后，我们不只知道最终配置是什么，也能回看每组参数对应的 recall，判断到底是哪个组合真正带来了提升。
运行成本控制
RAG eval 有成本。每跑一轮 eval，都要让几十个问题完整走一遍检索流程：生成 query embedding、执行向量检索、必要时跑 reranker，在有些链路中系统甚至还会调用 LLM。
如果 Loop 没有停止机制，这些成本就会在后台持续累积。尤其是某些配置原本就贵，把 k 值设大，再叠加外部 reranker，每个问题的评估成本都会明显上升。
所以，一个真正可用的工程 Loop，不能只限制运行次数，还需要有预算上限。
def tune_rag_safe(search_space, train_set, target_recall=0.9,
max_evals=40, max_budget_usd=15):
config = default_config()
best_recall = evaluate(config, train_set)
spent = estimate_cost(config, len(train_set))
evals_used = 1
log = []
for param, values in search_space.items():
best_value = config[param]
for value in values:
if value == config[param]:
continue
# BUDGET brake: the next run would exceed the limit, stop
trial = dict(config, **{param: value})
trial_cost = estimate_cost(trial, len(train_set))
if spent + trial_cost > max_budget_usd:
print(f"Budget ${max_budget_usd} spent. Stop at {evals_used} runs.")
save_log(log)
return config, best_recall, evals_used
# RUN-COUNT brake
if evals_used >= max_evals:
save_log(log)
return config, best_recall, evals_used
recall = evaluate(trial, train_set)
spent += trial_cost
evals_used += 1
log.append({"config": trial, "recall": recall,
"spent": round(spent, 2), "eval": evals_used})
if recall > best_recall + 0.02:
best_recall = recall
best_value = value
if best_recall >= target_recall:
config[param] = best_value
save_log(log)
return config, best_recall, evals_used
config[param] = best_value
save_log(log)
return config, best_recall, evals_used
def estimate_cost(config, n_questions):
# rough estimate: query embedding + optional reranker per question
cost = n_questions * 0.00002 # query embedding
if config["reranker"] == "cohere-rerank":
cost += n_questions * config["k"] * 0.000001
return cost
上面代码有两个停止机制。一个是 max_evals，限制最多跑多少轮；另一个是 max_budget_usd，限制最多花多少钱。
此外，让预算检查发生在运行之前也很重要。Loop 要先估算下一轮成本，如果它会超过预算，就直接停止，不会先花完钱再提醒你。
这就是工程 Loop 和随手写脚本的区别：它不只负责往前跑，也得在该停的时候停下来。
运行 Loop
最后一步，是正式运行这个 Loop。
Loop 会先在 train set 上搜索配置，找到一组当前表现最好的参数。但这还不够。因为这组参数是在 train set 上调出来的，它可能确实更好，但也可能只是更适合这批训练集。
所以，最终配置还必须放到 holdout set 上单独跑一次。holdout set 是 Loop 在调参过程中没有见过的数据，它的作用是帮我们判断，这组参数是否真的具备泛化能力，还是只是在 train set 上把分数刷高了。
if __name__ == "__main__":
train_set, holdout_set = split_eval(eval_set)
# the loop tunes on train
config, train_recall, n = tune_rag_safe(
SEARCH_SPACE, train_set, target_recall=0.9, max_evals=40
)
print(f"Found in {n} runs. Recall on train: {train_recall:.2f}")
print(f"Config: {config}")
# CRITICAL: check on held-out, which the loop did not optimize
holdout_recall = evaluate(config, holdout_set)
print(f"Recall on held-out: {holdout_recall:.2f}")
gap = train_recall - holdout_recall
if gap > 0.1:
print("WARNING: large train/holdout gap. "
"The loop overfit the eval, the config cannot be trusted.")
else:
print("Gap is small, the config generalizes. Ship it.")
这段代码里，重要的是最后的 gap。如果 train recall 是 0.92，但 holdout recall 只有 0.79，那就说明 Loop 找到的不是一个可靠的 RAG 配置，是一组刚好讨好了训练问题的配置。
这时候我们不应该直接上线，应该扩大评估集、调整搜索空间，或是重新检查指标设计。
如果 train 和 holdout 的 gap 很小，说明这组配置更具泛化能力，可以进入下一步验证或上线。
小结
上面这些设计都在防止 Loop 跑偏。
最小提升阈值是为了避免 Loop 追着噪声调整。train / holdout 拆分是为了避免 Loop 对 eval 过拟合。max_budget_usd 是为了防止预算失控，max_evals 则是为了避免目标达不到时一直跑下去。
所以，一个可用的 Loop 不能只会“继续尝试”。它还必须知道什么算真的变好，什么情况应该停止，以及最终结果能不能被信任。
