RAG 的下一站:能自己改代码、跑实验的知识底座

2026-05-25 13 预计阅读时间:1 分钟
来源:my.oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:11 分钟

去年你刚把 RAG pipeline 搭起来,向量库选了 Milvus,chunk 策略调了几轮,topK 从 5 改到 10 又改回 3——上线后效果还行,但每次新增文档都要人工造问答对验证检索质量。今年再看,有人已经让知识库自己改检索算法、自己跑 A/B 测试、自己决定哪版参数留下来。这不是噱头,是商汤开源的那套智能知识底座正在做的事。

传统 RAG 的瓶颈在哪

大部分团队的 RAG 还停留在"检索 + 拼接 + 生成"的线性流程:

用户提问 → 向量检索 topK 段 → 拼接 prompt → LLM 生成回答

瓶颈不在 LLM,在检索侧。你手动调 topK、换 embedding 模型、改 chunk 大小,每次都是人在做决策。文档多了、领域变了,又得重来。更致命的是——你不知道当前参数是不是最优的,因为没有自动化的评估闭环。

商汤的方案本质上给 RAG 加了一层 Agent 循环:知识库不再只是被动检索,而是能观察自己的表现、提出改进方案、执行修改、验证效果。

自进化知识底座的核心机制

从公开信息看,这套系统的关键不是某个单一算法,而是三个能力的闭环:

1. 自评估——系统对每次检索结果打分,不只是看召回率,还看最终生成答案的质量(事实一致性、用户满意度信号)。

2. 自修改——Agent 能改自己的检索配置,甚至改 pipeline 代码。比如把 chunk 策略从固定 512 字符改成按语义边界切分,或者把 topK 从硬编码改成动态计算。

3. 自验证——改完之后自动跑 A/B 测试,用历史问答集做基准对比,只有指标确实提升才采纳新版本。

这三个能力串起来,知识库就从"人调参数"变成了"系统自己调自己"。

从零搭一个最简自评估 RAG

下面用一个可运行的 Python 示例演示自评估闭环的最小实现。核心思路:每次检索后自动评估,如果质量低于阈值,Agent 尝试调整 topK 并重新检索。

"""
最小自评估 RAG demo —— 检索后自动评分,低于阈值则调整 topK 重试
依赖: pip install openai chromadb sentence-transformers
运行前设置: export OPENAI_API_KEY=sk-xxx
"""

import os
import chromadb
from sentence_transformers import SentenceTransformer
from openai import OpenAI

# ── 1. 初始化向量库和 embedding ──
embed_model = SentenceTransformer("all-MiniLM-L6-v2")
client = chromadb.Client()
collection = client.get_or_create_collection("demo_kb")

# 写入示例文档
docs = [
    "Python 的 GIL 使得多线程无法真正并行执行 CPU 密集任务,应改用 multiprocessing。",
    "FastAPI 的依赖注入系统支持 async generator,可在请求结束时自动清理资源。",
    "ChromaDB 默认使用 cosine similarity,也可切换为 L2 或 IP 距离函数。",
    "RAG 的 chunk 大小建议 256-512 字符,过大会稀释语义,过小会丢失上下文。",
    "topK 参数不是越大越好,超过 10 段后噪声增加,生成质量反而下降。",
]
embeddings = embed_model.encode(docs).tolist()
collection.add(ids=[f"d{i}" for i in range(len(docs))],
               embeddings=embeddings, documents=docs)

# ── 2. 检索 + 评估函数 ──
def retrieve_and_score(query: str, top_k: int) -> dict:
    q_emb = embed_model.encode([query]).tolist()
    results = collection.query(query_embeddings=q_emb, n_results=top_k)
    passages = results["documents"][0]

    # 用 LLM 评估检索质量(1-5 分)
    eval_prompt = f"""你是一个检索质量评估专家。
用户问题: {query}
检索到的段落:
{chr(10).join(f'[{i+1}] {p}' for i, p in enumerate(passages)}

请评分(1-5): 段落是否包含回答问题所需的关键信息?
只输出一个数字。"""
    llm = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
    score_text = llm.chat.completions.create(
        model="gpt-4o-mini", messages=[{"role": "user", "content": eval_prompt}],
        max_tokens=5
    ).choices[0].message.content.strip()
    try:
        score = int(score_text)
    except ValueError:
        score = 3  # 解析失败给中间分

    return {"passages": passages, "score": score, "top_k": top_k}

# ── 3. 自调整循环 ──
def self_evolving_rag(query: str, initial_k: int = 3, max_retries: int = 3) -> dict:
    k = initial_k
    history = []
    for attempt in range(max_retries):
        result = retrieve_and_score(query, k)
        history.append(result)
        print(f"尝试 {attempt+1}: topK={k}, 评分={result['score']}")

        if result["score"] >= 4:
            print("✓ 评分达标,采用当前参数")
            return result

        # 评分不足,策略:逐步扩大 topK
        k = min(k + 2, len(docs))
        print(f"→ 评分不足,调整 topK 为 {k}")

    print("⚠ 达到最大重试次数,采用最佳历史结果")
    best = max(history, key=lambda r: r["score"])
    return best

# ── 4. 运行 ──
if __name__ == "__main__":
    answer = self_evolving_rag("RAG 里 topK 怎么选?")
    print(f"\n最终 topK={answer['top_k']}, 评分={answer['score']}")
    print("检索段落:")
    for p in answer["passages"]:
        print(f"  - {p}")

运行方式:

pip install openai chromadb sentence-transformers
export OPENAI_API_KEY=sk-your-key
python self_eval_rag.py

这个 demo 只演示了 topK 的自调整。商汤开源的完整系统更进一步——Agent 能改 chunk 逻辑的代码、换 embedding 模型、甚至重写评估脚本本身。上面的循环是单参数调整,完整版是多维度并行搜索 + 版本管理。

从 demo 到生产:需要补什么

上面的最小闭环离生产级自进化还有几道坎:

评估基准集——不能每次都用 LLM 评分,成本太高。应该维护一套 golden QA 集,定期自动跑批量评估,作为 A/B 对比的锚点。

# eval_benchmark.yaml —— 评估基准示例
benchmark:
  name: rag_v2_qa_set
  pairs:
    - question: "RAG  topK 怎么选?"
      expected_facts: ["topK 不是越大越好", "超过 10 段噪声增加"]
    - question: "Python 多线程为什么不能并行 CPU 任务?"
      expected_facts: ["GIL 限制", "应改用 multiprocessing"]
  metrics:
    - fact_coverage    # 期望事实被检索到的比例
    - answer_accuracy  # 最终答案与期望的一致性

版本管理——每次 Agent 改了配置或代码,必须存版本、可回滚。类似 Git 但针对 pipeline 配置:

# 假设商涛开源项目提供了 pipeline 版本管理 CLI
pit version commit --config current_config.yaml --message "topK 动态化: 从固定5改为 min(3+2*retry, 15)"
pit version list
# v3  | topK=dynamic(chunk_count)  | fact_coverage=0.87 | 2025-06-01
# v2  | topK=10                     | fact_coverage=0.72 | 2025-05-28
# v1  | topK=5                      | fact_coverage=0.65 | 2025-05-20
pit version rollback --to v2   # 如果 v3 在新文档集上表现变差

安全边界——让 Agent 改代码是高风险操作。必须设白名单:只允许改检索参数、chunk 策略、评估脚本;禁止改数据库连接、权限逻辑、对外 API。每次修改前做 diff review,超范围改动直接拒绝。

什么时候该上自进化 RAG

不是所有场景都需要。判断标准很简单:

场景 建议
文档量 < 1000 页,领域稳定 传统 RAG 够用,手动调一次就行
文档持续增长,每周新增 需要自动评估,但自修改可以先不上
多领域混合,检索策略需差异化 上自评估 + 自修改,让系统按领域调参数
十人团队维护上百项目 全闭环:自评估 + 自修改 + 自验证 + 版本管理

商汤的场景正是最后一行——少量人力维护大量项目,自进化是唯一可行路径。如果你的团队规模和项目数量还没到这个比例,先从自动评估闭环做起,不要一步跳到让 Agent 改代码。

上手路线

  1. 先建评估基准——收集 50-100 条真实用户问题 + 期望答案,做成 YAML 或 JSON。没有基准,所有"自进化"都是盲调。
  2. 跑上面的 demo——理解自评估循环的逻辑,然后把它接入你现有的 RAG pipeline。
  3. 逐步开放修改权限——先让系统只调 topK 和 chunk_size,观察一周;确认稳定后再开放更多参数。
  4. 关注商汤开源项目——他们的完整实现包含代码级自修改和 A/B 测试框架,值得参考架构设计,但直接引入生产前务必做安全审计。

RAG 没有过时,但停在"人调参数"阶段的 RAG 会越来越跟不上文档增长的速度。自评估闭环是最小投入、最大收益的第一步——今天就可以动手。


相关推荐