别再手调 RAG 了，让 Loop 自己找配置

手动调 RAG 是一件让人很头疼的事。

无论你是改 chunk size，还是换 embedding，或者是加个 reranker，都要重新跑结果。几十轮下来，单靠人工在 Excel 或是凭印象去记参数组合和评估结果，调到后面可能自己都记混配置——哪一组才是有效的组合？

其实，像是这种重复性任务刚好可以交给 Loop。尤其是这种任务往往步骤重复、结果可测量、需要不断尝试同一组旋钮，并通过一个明确指标判断结果好坏。

在本文我们会用一个例子，来实践一下如何把 RAG 调参包进一个工程 Loop。

假设我们现在有一个 RAG 系统和一组评估集，目标是把 recall@5 提到 0.9。我们会写好 Loop，让它自己去遍历搜索配置、运行评估，一旦达成既定目标就自动停下来，如果超过了最大运行限制也会及时熔断。

请记住，本文不是“让 Agent 神奇地调好 RAG”，是把一个重复性工程任务，变成一个有目标、有检查、有记录的自动循环。

Loop Engineering 有一个非常重要的前提：这个任务必须有一个自动检查机制。代码每次尝试新配置，系统得能自行判断这次跑出来的结果是好是坏。如果没有这个检查，Loop 就只能盲目运行，很难稳定改进。

而 RAG 调参刚好完美符合这个条件。

本文的检查指标是评估集的 recall@k。它是一个数字：有没有超过阈值，一目了然。就像跑单测，代码自己就能对齐结果，行就是行，不行就是不行，不用任何人为主观介入，也不用 Loop 去猜。

同时，RAG 调参本质上是在配置空间里搜索。chunk size、overlap、embedding、k 值、reranker、混合检索，这些组合起来会形成很大的搜索空间。人工试几轮之后就容易乱，但 Loop 不会累，也不会忘记自己试过什么组合。

这个 Loop 不是从零搭一个 RAG 系统，它调的是一个在工作的 RAG pipeline。

所以，在启动 Loop 之前，你的工程里需要先准备好这 3 样东西：

1. 一个跑通了且“暴露了关键参数接口”的 RAG pipeline。比如能随时传参修改 chunk_size、overlap、embedding_model、k 值、reranker 等。

2. 一组标注好的评估集。不用特别庞大，大概 30～50 个典型问题就行，但每个问题都要明确配上它对应的正确源 chunk ID。没有这个评估集，自动检查就不能进行，更别提 Loop 了。

3. 一个能返回指标的评估函数。这个函数负责接收一组 config 字典，重构完 pipeline 后在评估集上跑一遍检索，最后输出量化的召回率 recall@k。

下面这段代码就是整个 Loop 的“裁判”。Loop 每切到一组新参数，都会调用它去重新组装 pipeline，再在评估集上把所有的检索流程跑一遍，最后交出命中比例。

这段代码的重点不在具体的实现细节，而在它在架构里扮演的角色。

它是整个 Loop 的自动判断机制。Loop 每次尝试一组参数，都靠它判断这组参数是否更好。没有这个函数作基准，后面的自动搜索就没有依据。

Loop 要想干活，首先得知道它到底能动哪些旋钮。

不要一上来就给它开一个无限大的画布，要先定义一组真正会明显影响召回率的核心关键参数：chunk size、chunk overlap、embedding model、k 值、reranker，以及是否启用混合检索。

这个搜索空间看起来不大，但组合起来有 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 在调参过程中不能看到，最后只用它来检查最终配置是否可靠。

这段代码的作用就是把评估集拆成 train 和 holdout。

第二个问题是测量噪声。如果评估集只有 30 个问题，那么 recall 从 0.87 到 0.90 的变化，可能并不代表真实提升，它只是样本太小带来的波动。

如果最小提升阈值设得太低，Loop 就容易把随机波动当成真实提升，围绕噪声反复调整。比较建议的做法是先设一个最小提升幅度。当 recall 的提升超过这个阈值时，再更新当前的最佳配置。比如这里可以把阈值设成 0.02；如果提升小于这个幅度，就先把它当作测量噪声，不急着改配置。

上面说过把 648 种组合全部扫一遍是又贵又慢。

这里可以换一个更简单的策略：coordinate descent。一次只调一个参数，其他参数先保持不变；这个参数找到当前最合适的取值之后，再调下一个参数。

这种方法不一定能找到全局最优解，但可以用较少的运行次数，找到一组足够好的配置。对于很多工程调参任务来说，这比人工一轮轮试参数更稳定，也更容易复现。

这段代码的重点是给 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 会先在 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 不能只会“继续尝试”。它还必须知道什么算真的变好，什么情况应该停止，以及最终结果能不能被信任。