手动调 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 样东西：

1. 一个跑通了且“暴露了关键参数接口”的 RAG pipeline。比如能随时传参修改 chunk_size、overlap、embedding_model、k 值、reranker 等。
    
2. 一组标注好的评估集。不用特别庞大，大概 30～50 个典型问题就行，但每个问题都要明确配上它对应的正确源 chunk ID。没有这个评估集，自动检查就不能进行，更别提 Loop 了。
    
3. 一个能返回指标的评估函数。这个函数负责接收一组 config 字典，重构完 pipeline 后在评估集上跑一遍检索，最后输出量化的召回率 `recall@k`。
    

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

```Python
# 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，以及是否启用混合检索。

```Plain
# 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 在调参过程中不能看到，最后只用它来检查最终配置是否可靠。

```Plain
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。一次只调一个参数，其他参数先保持不变；这个参数找到当前最合适的取值之后，再调下一个参数。

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

```Plain
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，不能只限制运行次数，还需要有预算上限。

```Plain
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 上把分数刷高了。

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

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

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

本文介绍如何用工程化 Loop 自动调优 RAG 参数：通过定义搜索空间、构建自动评估函数（recall@k）、设置最小提升阈值与 train/holdout 拆分防过拟合，并集成运行次数与预算双熔断机制，实现目标驱动、可复现、可审计的智能调参闭环。

编程语言

本文介绍如何利用自动化Loop工程优化RAG系统参数配置，通过定义搜索空间、拆分评估集、设置预算限制等策略，实现高效调参。文章详细讲解如何建立自动检查机制，避免过拟合，最终获得泛化能力强的RAG配置方案，提升recall@k指标。

代码解释

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

别再手调 RAG 了，让 Loop 自己找配置-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐