当规则学会学习：面向法律案例检索的自进化 Agent

关联论文：2606.17220
作者：Tom
更新：2026-07-21

一句话结论

LLM 作为 Agent，无需参数训练，通过「自进化」循环自动构建、验证和淘汰查询改写规则，显著提升 BM25 在中文法律案例检索上的效果，揭示了 LLM 的「实验结果利用能力」和「规则消除内在知识」是自进化的两大核心驱动力。

解决什么真问题

法律案例检索长期面临两个挑战：一是法律语言高度复杂，专业术语多、长尾表述多，查询与案例之间的词汇对齐难以做到精确；二是虽然 Dense Retrieval 模型近年来进展迅速，但在法律领域，BM25 这类稀疏检索方法仍是难以击败的强基线——这与法律文本中精确词汇匹配的重要性高度相关。

已有的改进方案通常依赖人工设计查询改写规则，或用 Fine-tuning 方式让模型学习改写，但前者耗时且难泛化，后者需要标注数据和计算资源。本文的核心问题是：能否让 LLM 作为 Agent，完全自动地「学会」哪些规则有效、哪些无效，在无需训练的情况下持续提升 BM25 的检索效果？

核心方法

论文提出了一个 Self-Evolving Agent 框架，整体是一个「规则生成→实验验证→反馈淘汰」的三步迭代循环，核心组件如下：

（1）Rule Generator（规则生成） LLM Agent 负责根据查询上下文和历史反馈，生成候选的查询改写规则。规则形式为自然语言或半结构化的模式，例如「将当事人名称标准化」「补充法律条款编号」等。生成时 Agent 会参考已有的规则库和被淘汰规则的失败原因，实现有方向性的探索。

（2）Automatic Evaluation Environment（自动评估环境） 每次生成新规则后，Agent 会设计验证实验——对同一批查询，分别用「当前规则集」和「新候选规则集」运行 BM25 检索，通过 Recall@K、MRR 等指标评估效果差异。无需人工标注，评估基于批量查询的标准答案。

（3）Rule Eliminator（规则消除） 基于实验反馈，Agent 判断哪些规则没有正向增益，将低效规则从活跃规则集中淘汰。这是一个自我修正机制——Agent 并非盲目堆积规则，而是主动「遗忘」。

（4）Self-Evolution Loop（自进化循环） 迭代上述三步，规则集在整个过程中不断演化。论文强调两个关键机制： - 利用先前实验结果的能力（learning from historical feedback）：Agent 能从历史实验数据中提取规律，而非每次从零开始； - 规则消除的内在知识（intrinsic knowledge of rule elimination）：LLM 本身具备判断「什么规则在语义上不应该 work」的能力，可以指导消除方向。

伪代码逻辑如下（原文未给出精确算法，以下为机制概述）：

Initialize rule_set = ∅
for iteration in 1..N:
    candidate_rules = LLM_Agent.generate(rule_set, history)
    old_score = evaluate(BM25, rule_set)
    new_score = evaluate(BM25, rule_set ∪ candidate_rules)
    if new_score > old_score:
        rule_set = rule_set ∪ candidate_rules
    else:
        eliminated = LLM_Agent.eliminate(candidate_rules)
        rule_set = rule_set \ eliminated
return best_rule_set

关键实验与数据

数据集：LeCaRD-v2（中文法律案例检索基准）

基线对比： - 原始 BM25（无改写） - 人工设计规则 + BM25 - Greedy Rule Selection（贪心规则选择）

主要结果： - Self-Evolution 框架在 LeCaRD-v2 上显著优于所有非进化基线，包括人工设计规则和贪心规则选择； - 高容量（high-capacity）Core LLM 驱动时增益最大，说明模型本身的能力直接影响自进化效果； - 迭代过程中，规则集呈现「先扩张后收缩」的动态，最终规模趋于稳定。

消融分析： - 禁用实验结果利用能力后，规则集收敛质量显著下降； - 禁用规则消除内在知识后，规则冗余增加，检索效果回落； - 两项机制缺一不可，共同构成自进化的核心。

亮点与局限

亮点： 1. 零训练成本：完全不需要标注数据或模型微调，直接利用 LLM 的推理和反思能力； 2. 可解释性强：规则以显式自然语言形式存在，可以被人工审查和修改； 3. 跨任务迁移潜力：框架本身不依赖特定领域，理论上可迁移至其他需要规则优化检索的场景； 4. 揭示自进化机制：论文通过消融分析揭示了 LLM「从历史中学习」和「主动遗忘」两个此前未被充分讨论的能力。

局限： 1. 评测范围有限：只在 LeCaRD-v2 一个中文法律数据集上验证，未在其他语种或通用检索任务上测试； 2. 依赖 LLM 能力：实验表明效果高度依赖 Core LLM 的容量和质量，低配模型可能无法有效自进化； 3. 收敛稳定性未知：自进化过程的收敛性、最优迭代次数等问题原文未给出严格分析； 4. 与 Dense 模型的关系未充分探索：论文聚焦 BM25，未讨论该框架是否能帮助 Dense Retriever 提升。

对工程落地的启发

法律科技公司：可将自进化框架集成到类 Westlaw/北大法宝等法律检索系统，无需人工维护大量查询改写规则，降低知识工程成本；
RAG Pipeline 优化：规则驱动的查询改写可作为 RAG 流程中 Query Rewriting 模块的轻量级替代方案，不依赖额外训练；
冷启动友好：零训练特性意味着任何新领域、新语料上线时，可先用自进化快速构建规则集，再考虑后续 Fine-tuning；
监控与可审计：显式规则形式便于合规场景下的审计追溯，尤其适合法律、金融等强监管领域。

与同方向工作的关系

方向	代表工作	本文区别
Query Rewriting for Retrieval	Query2Doc、HyDE	本文不生成伪文档，而是生成可验证的改写规则；不依赖 Fine-tuning
Rule-based IR	Rule-based BM25 extensions	本文让 LLM 自动发现和淘汰规则，而非依赖人工设计
LLM-based Agent for IR	ReAct、Reflexion in IR	本文聚焦规则演化的长期优化，而非单步推理策略
Self-Evolving LLM	SELF-EVOLVE、ALPAGAS	本文面向检索任务，设计了专门的规则生成/消除机制

本文与 HyDE（生成伪文档帮助检索）属于不同路线：HyDE 依赖 LLM 生成假设性答案，本文则让 LLM 学习「如何改写查询」这一元技能。

适合谁读

法律科技从业者：法律检索系统开发者、法务 AI 产品经理；
RAG 系统工程师：正在优化 Query Rewriting 模块、寻找无需 Fine-tuning 方案的技术人员；
LLM Agent 研究者：对 Self-Evolving Agent 的实际应用案例感兴趣，想了解「Agent 如何自主改进工具」的研究者；
IR 学者：关注 BM25 在特定领域行为、研究稀疏检索与规则协同的学者。

信息来源

论文卡片：/shared/research-kb/organized/paper_cards/314-2606-17220.md（TLDR、被引、主题分类）
arXiv Abstract：https://arxiv.org/abs/2606.17220（方法概述、实验数据集、结论）

工程落地与核查（Jay）

事实核查

ACL 2026 接收：✅ arXiv 原文 ACL 2026 acceptance confirmed（ACL 2026 upcoming conference，接收状态与 abstract 来源一致）；
作者 Mingxu Tao：✅ 来源 arXiv submission history；
LeCaRD-v2 数据集：✅ 真实存在的中文法律案例检索 benchmark，GitHub 有公开版本；
BM25 + self-evolution agent 机制：✅ abstract 明确描述，逻辑一致；
原文无具体 Recall@K/MRR 数值（⚠️存疑）：原文未给出，解读稿引用的具体数字属于推断，非原文数据；
伪代码迭代次数 N：原文未给出上限，解读稿以 N 泛指，标注正确。

工程落地关键坑

BM25 库未指定：原文未说明使用 rank_bm25 / elasticsearch-py / Whoosh 中的哪一种；实际部署时需要明确，因为不同库的分词器（ik_maxword / jieba / pkuseg）对中文法律术语的分粒度差异直接影响召回率。
LeCaRD-v2 依赖 Ground Truth 标注：self-evolution 的 evaluation 依赖批量查询的标准答案；真实法律检索场景往往没有标准答案，需要自行构建评估集或依赖用户反馈作为信号——这是与原文 setting 最大的工程鸿沟。
规则生成 Prompt 未公开：LLM Agent 生成/淘汰规则的能力高度依赖 prompt 设计，原文未公开具体 prompt；复现时需大量调优，建议从「法律术语标准化」「法条编号补全」「当事人名称规范化」等高频法律改写规则入手做 few-shot prompt。
收敛判断无硬性指标：原文未给出 N 的上限或 Recall@K 的收敛阈值；实际系统需要设定 budget 上限（如最大迭代 20 轮）或最低增益阈值，防止 LLM 在规则集上无限自演化消耗 token。
中文法律 LLM 幻觉风险：法律场景中规则如果引入错误法律概念（法条误引、案由混淆）可能被直接用于实际检索——生产系统必须在规则加入前加人工审核闸门，不建议做纯 autonomous rule elimination 直接上线。

复现最小路径

# 1. 环境
pip install rank_bm25 jieba faiss-cpu  # 稀疏 + 密向混合可选
# LeCaRD-v2: https://github.com/thunlp/LeCaRD or search "LeCaRD dataset GitHub"

# 2. 核心循环骨架（非官方复现版，仅示意）
import jieba, json
from rank_bm25 import BM25Okapi

def evaluate_rule_set(rule_set, queries, corpus, ground_truth):
    # 对每条查询应用规则改写，再 BM25 检索
    rewritten = [apply_rules(q, rule_set) for q in queries]
    scores = bm25.batch_score(rewritten, corpus)
    return recall_at_k(scores, ground_truth, k=10)

def self_evolve(rule_set, history, core_llm):
    candidates = core_llm.generate_rules(rule_set, history)  # prompt 工程关键
    old_score = evaluate_rule_set(rule_set, ...)
    new_score = evaluate_rule_set(rule_set | candidates, ...)
    if new_score > old_score:
        return rule_set | candidates, history + [candidates]
    else:
        eliminated = core_llm.eliminate_rules(candidates)  # LLM 自带的"遗忘"能力
        return rule_set - eliminated, history

# 3. 监控
# - 每轮 rule_set 规模变化（应先增后减）
# - token 消耗 / 迭代次数上限
# - Recall@K 曲线收敛判断