1. 当规则开始学习一个法律案例检索的自我进化智能体最近在跟一个做法律科技的朋友聊天他提到一个痛点他们团队用传统的BM25算法搭建了一个法律案例检索系统初期效果还行但用久了就发现律师们输入的查询词和他们系统里那些严谨的案卷标题、判决摘要经常“对不上频道”。比如律师可能输入“公司股东会决议程序瑕疵的效力”而数据库里对应的经典案例标题可能是“关于XX公司股东会召集程序违法所涉决议效力认定的再审审查裁定”。这中间的语义鸿沟靠简单的关键词匹配BM25或者固定的同义词库扩展很难弥合。更头疼的是法律语言本身也在微妙地演变新的司法解释、热点案件会催生新的表述方式。这让我开始思考我们能不能做一个不那么“死板”的检索系统一个能自己观察、学习、并优化检索规则的智能体这就是“When Rules Learn: A Self-Evolving Agent for Legal Case Retrieval”这个想法最初的来源。它不是一个静态的工具而是一个具备自我进化能力的智能代理核心目标是让法律案例检索变得更聪明、更贴合实务需求。简单来说这个智能体要做的事情是它不再依赖人工预先设定且一成不变的检索规则而是能够根据每一次的检索交互用户的查询、点击、反馈以及外部新的法律知识自动地调整和优化其内部的“查询理解”与“文档匹配”策略。它的核心驱动力是大语言模型LLM所提供的强大语义理解与生成能力而BM25这类经典检索算法则作为高效、可靠的“召回”基石。两者的结合再辅以一套持续学习的机制就构成了一个能够自我演化的闭环系统。对于法律从业者、法学研究者或者任何需要从海量判例中快速精准定位相关案例的人来说这样一个系统意味着检索效率的质变——你不需要再去猜测数据库的“偏好”用词系统会尝试理解你的意图并越用越懂你。2. 为什么传统法律检索需要“进化”在深入架构之前我们必须先理解现有方法的局限性。法律检索尤其是案例检索是一个对准确性要求极高、容错率极低的领域。一个漏检的关键判例可能会直接导致法律意见的错误或诉讼策略的失误。2.1 BM25的“死记硬背”与语义鸿沟BM25Best Matching 25及其变体是信息检索领域的常青树它基于词频TF和逆文档频率IDF来计算查询词与文档的相关性。它的优势在于速度快、可解释性强、对字面匹配exact match非常有效。然而在法律场景下BM25的局限性暴露无遗词汇不匹配问题这是最核心的问题。法律概念是抽象的但表达方式是多样的。例如“善意取得”在判例中可能被表述为“不知情的第三人以合理价格受让动产所有权”。“违约方解除合同”可能与“违约方诉请解除合同之权利限制”的案例相关。BM25无法理解这些表述在法学意义上的等价性。缺乏上下文理解查询“醉酒驾驶造成事故的保险赔付”BM25会平等地看待“醉酒”、“驾驶”、“事故”、“保险”、“赔付”这些词。但它无法理解“醉酒”是“驾驶”的修饰和条件“事故”是“醉酒驾驶”的结果而“保险赔付”是核心的法律争议点。这种词与词之间的逻辑关系BM25是看不见的。长尾查询与稀疏性律师的查询有时非常具体且冗长例如一份事实描述的片段导致查询向量稀疏与文档的匹配点很少BM25的评分会很低可能无法有效召回真正相关的案例。注意这并不意味着要抛弃BM25。恰恰相反在构建检索系统的第一级“召回”阶段BM25因其高效和稳定仍然是无可替代的“守门员”。它的角色是从百万甚至千万级的案例库中快速筛选出几百个可能相关的候选文档Candidate Documents。我们智能体进化的是在BM25之上的“理解”和“重排”层。2.2 静态规则库的维护噩梦为了缓解词汇不匹配传统的做法是构建一个法律同义词库、业务规则库或者查询模板。例如当用户搜索“劳动合同解除”系统自动扩展查询为“劳动合同解除 OR 辞退 OR 解雇 OR 开除”。这种方法初期有效但维护成本极高难以穷尽法律语言博大精深地域差异、审判层级差异、时代差异都会导致新的表述不断涌现人工维护的规则库永远滞后。容易冲突规则之间可能存在优先级冲突或意外叠加导致查询被过度扩展引入噪声降低检索精度。缺乏个性化不同领域的律师如知识产权、金融证券、劳动争议的查询习惯和关注点不同一套统一的规则无法满足所有需求。2.3 LLM带来的范式转变机会大语言模型LLM的出现为解决上述问题提供了新的可能。LLM如GPT系列、LLaMA等通过在超大规模文本理论上可以包含海量法律文书上的预训练内化了丰富的语言知识和世界知识其中包括对法律概念、逻辑关系的深层理解。LLM在法律检索中可以扮演两个关键角色查询理解与重写Query Understanding Rewriting将用户原始的、可能模糊或不规范的查询自动重写为多个对检索系统更友好、更可能匹配到相关文档的查询变体。例如将“股东会程序有问题怎么办”重写为“公司股东大会召集程序瑕疵的法律后果”、“股东会决议因程序违法被撤销的案例”、“《公司法》关于股东会召集程序的规定及违反效力”。语义匹配与重排Semantic Matching Re-ranking对于BM25召回的前K个候选文档利用LLM深度理解查询和每个文档的语义进行更精细的相关性打分和重排将语义相关但关键词匹配度不高的案例排到前面。然而直接、粗暴地使用LLM进行端到端的检索即用LLM直接为海量文档打分是不现实的因为其计算成本极高、延迟巨大。因此一个高效的架构必然是“传统检索召回 LLM精排”的混合模式。而我们提出的“自我进化智能体”则是要让这个混合模式中的“LLM精排规则”和“查询重写策略”能够持续学习和优化。3. 自我进化智能体的核心架构设计我们的智能体不是一个单一的模型而是一个由多个模块协同工作的系统。它的“自我进化”体现在一个基于反馈的闭环学习循环中。下图展示了其核心工作流程与进化机制graph TD A[用户输入原始查询] -- B[查询理解与重写模块]; B -- C[混合检索层: BM25 向量检索]; C -- D[召回Top-K候选案例]; D -- E[LLM语义精排与重排模块]; E -- F[返回最终排序结果]; F -- G[用户行为反馈点击/标记相关]; G -- H[反馈学习模块]; H -- 更新提示词/调整权重 -- B; H -- 生成正负样本对 -- I[持续训练数据池]; I -- J[定期微调LLM/Embedding模型]; J -- 模型能力提升 -- B; J -- 模型能力提升 -- E;下面我们来拆解每一个核心模块。3.1 模块一具备记忆与策略的查询重写器这是智能体与用户交互的第一道门也是进化的起点。它的输入是用户原始查询Q_original输出是一组优化后的查询列表[Q_rewrite_1, Q_rewrite_2, ...]。基础实现静态策略 我们可以设计一套固定的提示词Prompt给LLM你是一个专业的法律检索助手。请将用户的法律问题查询改写成3个更适合进行法律案例数据库检索的查询。要求 1. 使用更正式、更完整的法律术语。 2. 可以拆解查询中的复合法律问题。 3. 考虑同义词和常见表述变体。 4. 每个改写后的查询应独立且明确。 原始查询{Q_original}LLM会返回3个改写后的查询。然后系统并行地用这3个查询去调用BM25检索最后合并去重结果。进化点一基于会话历史的个性化重写智能体应该维护一个轻量级的用户会话记忆例如存储在向量数据库中的最近几次查询和点击的案例摘要。当新的查询到来时除了原始查询还可以将相关的历史上下文一同送给LLM。...上述提示词... 历史上下文用户最近搜索过“劳动合同中竞业限制条款的效力”并点击了关于“违约金过高调整”的案例。 当前查询“竞业限制补偿金标准”这样LLM可能会生成更贴切的改写如“竞业限制经济补偿法定标准”、“未约定竞业补偿金时条款效力”、“竞业限制补偿与违约金关系案例”其中最后一个改写明显受到了历史上下文的影响。进化点二基于反馈的提示词优化Prompt Tuning如果系统检测到对于某一类查询如“劳动争议”用户频繁点击由某个特定改写查询Q_rewrite_A召回的案例而很少点击其他改写查询的结果那么智能体可以学习到“对于劳动争议类查询Q_rewrite_A这种改写风格更有效”。系统可以将这个“规则”抽象化并用于动态调整后续同类查询的改写提示词例如在提示词中增加“此类问题请侧重从劳动者权益保障和合同履行角度进行改写”。3.2 模块二混合检索层与候选召回这一层负责高效地从海量案例库中初步筛选出候选集。我们采用混合检索策略以兼顾召回率与效率。稀疏检索BM25针对每一个改写后的查询使用BM25算法在案例的“标题”、“案由”、“当事人”、“裁判要旨”等关键字段上进行检索。这一步速度极快能保证高召回率尤其是对关键词的精确匹配。稠密检索Embedding同时使用一个法律领域微调过的文本嵌入模型Embedding Model将每一个改写后的查询转换为向量并在预先构建好的“案例内容向量库”中进行近似最近邻搜索。这一步旨在捕捉语义相似性弥补BM25的词汇不匹配缺陷。将两者的结果按一定权重初期可设为BM25权重更高以保证稳定性合并、去重得到最终的Top-K例如K200候选案例列表。这个K值是一个重要参数它需要在检索精度和后续LLM精排的成本之间取得平衡。3.3 模块三LLM驱动的精细化排序与理由生成这是提升检索精度的核心环节也是计算成本最高的部分。目标是对Top-K个候选案例进行精细化打分和重排。实现方案 我们采用LLM的“点对点”打分模式。对于每一个候选案例Doc_i我们构造如下提示词让LLM判断其与查询的相关性任务判断给定的法律案例文档与用户查询的相关性。 请仅输出一个0到10之间的整数分数代表相关程度10表示完全相关0表示完全不相关。 评分时请考虑1. 法律争点是否匹配2. 案件基本事实是否相似3. 裁判规则或法律适用是否具有参考价值。 用户查询{Q_original} 案例标题{Doc_i.title} 裁判要旨{Doc_i.summary} 可选关键段落{Doc_i.snippet} 相关性分数系统并行或批量地对K个候选案例进行评分。然后根据LLM给出的分数进行降序排列得到最终的检索结果列表。进化点从打分到生成排序理由构建学习样本单纯的打分对于进化来说信息量不够。我们可以让LLM在打分的同时生成简短的“相关理由”或“不相关理由”。例如分数8 理由该案例涉及“股东会召集程序瑕疵”与查询中的“程序有问题”直接相关且判决中论述了程序轻微瑕疵是否影响决议效力对用户问题有直接参考价值。这些“查询文档分数理由”四元组是极其宝贵的反馈数据。它们清晰地标注了哪些文档是正样本高分哪些是负样本低分并且包含了“为什么”的说明。这些数据将被存入一个持续训练数据池用于后续的模型微调。3.4 模块四反馈闭环与进化引擎这是智能体“自我进化”的动力来源。进化主要在两个层面发生层面一在线学习与策略调整隐式反馈记录用户的点击行为。用户点击了排名第3的案例而没有点击排名第1的这本身就是一个强烈的信号——可能LLM对第1个案例的评分过高或者查询改写没有准确捕捉用户意图。系统可以据此调整混合检索中BM25与向量检索的权重或者微调查询重写模块的策略。显式反馈提供“相关/不相关”按钮。这是更直接的监督信号。当用户标记某个返回案例“不相关”时这个“查询文档负样本”对会被立刻加入训练数据池并可能触发一次对当前查询重写策略的即时评估。层面二离线学习与模型微调这是进化更根本的形式。定期例如每天或每周执行以下流程数据收集从反馈数据池中抽取高质量的四元组数据。正样本高分且用户点击/标记相关和负样本低分或用户标记不相关都需要。数据构造将数据构造为多种训练任务检索精排微调将任务构造成对比学习或列表级排序学习。例如对于一个查询有一个正例文档和若干个负例文档训练模型使正例的相似度分数远高于负例。这里可以使用像RankLLM这样的专门针对排序微调的方法。查询重写模型微调输入原始查询和最终被用户认可点击的文档让模型学习如何生成能召回该文档的改写查询。这可以训练一个更专业的查询重写小模型。Embedding模型微调使用收集到的正负样本对继续在类似BERT的法律语料上做对比学习训练让Embedding模型更能区分法律语义上的相关与不相关。模型更新用新数据微调后的模型以A/B测试或渐进式发布的方式更新线上系统中的相应模块精排LLM、重写模型、Embedding模型。通过这个闭环智能体实现了“实践 - 反馈 - 学习 - 优化 - 再实践”的持续进化。它的“规则”体现在模型参数和策略中不再是工程师预设的而是从真实的用户交互中学习得来的。4. 关键技术细节与实操挑战构建这样一个系统在工程和算法上会遇到不少挑战。这里分享一些关键的细节和我们的应对思路。4.1 检索精度与延迟的权衡LLM的调用策略直接用大模型如GPT-4对数百个候选文档逐一评分延迟和成本都无法接受。我们的策略是分层处理第一层快速粗筛。使用轻量级模型如6B/7B参数的法律领域微调LLM或更小的交叉编码器对Top 200个文档进行快速评分筛选出Top 30。第二层精准精排。再将这Top 30个文档用更强大但更慢的模型如GPT-4或更强大的开源模型进行精细评分和理由生成得到最终Top 10结果。 这种“级联”结构能有效平衡效果和效率。此外对LLM的调用要做严格的超时控制和失败重试并考虑使用缓存对相同或相似的查询-文档对缓存其LLM评分结果。4.2 训练数据的质量与冷启动问题进化离不开数据但系统启动初期缺乏用户反馈数据。如何冷启动合成数据利用LLM自身根据已有的案例库批量生成“查询-相关文档”对。例如给定一个案例的裁判要旨让LLM生成可能提出这个问题的多种查询方式。虽然合成数据可能有偏差但足以完成初步的模型微调。利用历史日志如果存在旧的检索系统其查询日志和点击数据是宝贵的初始训练资源。主动学习在系统初期可以主动向专家用户如律师展示一些边界案例询问其相关性快速积累高质量种子数据。4.3 评估体系如何衡量“进化”的效果不能光说系统在“学习”必须有量化的指标来证明它变得“更好”了。离线评估保留一个带有标注相关/不相关的测试集。定期用这个测试集评估系统最新版本的检索效果核心指标包括MRR平均倒数排名衡量第一个相关结果出现的位置。NDCGK归一化折损累计增益衡量前K个结果的整体排序质量。RecallK前K个结果中相关案例的比例。在线A/B测试将新版本的智能体例如采用了新微调模型与旧版本进行线上对比关键业务指标包括点击率结果列表的整体点击率是否提升首位点击率排名第一的结果被点击的比例是否增加任务完成率用户在一次搜索会话后是否不再进行二次搜索暗示首次搜索已满足需求人工评估定期抽样检索结果由领域专家从相关性、有用性等维度进行评分这是最可靠的黄金标准。4.4 可控性与可解释性法律应用必须严谨可控。一个“黑箱”的、不断变化的系统可能会让用户不安。可解释性在返回检索结果时同时提供LLM生成的“相关理由”。这既是给用户的解释也方便用户快速判断该案例是否真的有用。版本控制与回滚每一次模型更新、策略调整都应有明确的版本记录。如果新版本在线指标显著下降应能快速回滚到稳定版本。偏见与公平性监控法律不应有偏见。需要监控系统是否对某些类型的案件如涉及特定群体、特定地区存在系统性检索偏差并在训练数据和学习过程中进行纠偏。5. 超越检索智能体的未来能力展望当这个以检索为核心的智能体具备了强大的语义理解和持续学习能力后它的潜力可以延伸到更广阔的法律服务场景。1. 关联推荐与知识发现用户检索到A案例后系统可以自动推荐“引用本案的后续案例B”、“本案法官审理的类似案件C”、“与本案适用同一法律条文的案件D”。这不再是简单的关键词匹配而是基于案例引用网络、法官画像、法律条文图谱的深度关联挖掘帮助用户构建完整的知识脉络。2. 案情分析与报告生成用户可以将一份复杂的案件材料上传智能体可以自动摘要生成案件事实与争议焦点摘要。类案检索基于上传的材料自动进行多轮、多角度的案例检索找出最相关的判例。观点对比分析检索到的案例总结出支持原告诉请和被告抗辩的主要裁判观点及其比例。生成检索报告自动整理以上分析形成一份初步的法律检索报告草稿极大提升律师工作效率。3. 法律问答与咨询导航系统可以作为一个法律问答的入口。用户输入一个自然语言问题如“公司拖欠工资我该怎么办”智能体可以理解问题背后的法律诉求劳动报酬争议。检索相关的法律法规、司法解释和典型案例。生成一个结构化的回答包含法律依据、维权步骤、风险提示并附上关键案例的链接。实现这些功能需要在现有架构上增加更复杂的任务规划、多轮对话管理以及多工具协调检索工具、计算工具、文本生成工具的能力这正是当前LLM Agent智能体研究的前沿方向。我们的自我进化法律检索智能体为其打下了坚实的数据和模型基础。构建一个“When Rules Learn”的系统其意义不在于创造一个完美无缺的AI律师而在于打造一个能够与法律从业者共同成长、不断适应复杂现实需求的智能伙伴。它从僵硬的规则执行者变为灵活的策略学习者最终的目标是让技术更好地服务于人对公平与正义的追求。这条路充满工程和算法上的挑战但每解决一个难题都让我们离这个目标更近一步。 基于大语言模型与BM25混合检索的法律案例智能检索系统设计与实现
1. 当规则开始学习一个法律案例检索的自我进化智能体最近在跟一个做法律科技的朋友聊天他提到一个痛点他们团队用传统的BM25算法搭建了一个法律案例检索系统初期效果还行但用久了就发现律师们输入的查询词和他们系统里那些严谨的案卷标题、判决摘要经常“对不上频道”。比如律师可能输入“公司股东会决议程序瑕疵的效力”而数据库里对应的经典案例标题可能是“关于XX公司股东会召集程序违法所涉决议效力认定的再审审查裁定”。这中间的语义鸿沟靠简单的关键词匹配BM25或者固定的同义词库扩展很难弥合。更头疼的是法律语言本身也在微妙地演变新的司法解释、热点案件会催生新的表述方式。这让我开始思考我们能不能做一个不那么“死板”的检索系统一个能自己观察、学习、并优化检索规则的智能体这就是“When Rules Learn: A Self-Evolving Agent for Legal Case Retrieval”这个想法最初的来源。它不是一个静态的工具而是一个具备自我进化能力的智能代理核心目标是让法律案例检索变得更聪明、更贴合实务需求。简单来说这个智能体要做的事情是它不再依赖人工预先设定且一成不变的检索规则而是能够根据每一次的检索交互用户的查询、点击、反馈以及外部新的法律知识自动地调整和优化其内部的“查询理解”与“文档匹配”策略。它的核心驱动力是大语言模型LLM所提供的强大语义理解与生成能力而BM25这类经典检索算法则作为高效、可靠的“召回”基石。两者的结合再辅以一套持续学习的机制就构成了一个能够自我演化的闭环系统。对于法律从业者、法学研究者或者任何需要从海量判例中快速精准定位相关案例的人来说这样一个系统意味着检索效率的质变——你不需要再去猜测数据库的“偏好”用词系统会尝试理解你的意图并越用越懂你。2. 为什么传统法律检索需要“进化”在深入架构之前我们必须先理解现有方法的局限性。法律检索尤其是案例检索是一个对准确性要求极高、容错率极低的领域。一个漏检的关键判例可能会直接导致法律意见的错误或诉讼策略的失误。2.1 BM25的“死记硬背”与语义鸿沟BM25Best Matching 25及其变体是信息检索领域的常青树它基于词频TF和逆文档频率IDF来计算查询词与文档的相关性。它的优势在于速度快、可解释性强、对字面匹配exact match非常有效。然而在法律场景下BM25的局限性暴露无遗词汇不匹配问题这是最核心的问题。法律概念是抽象的但表达方式是多样的。例如“善意取得”在判例中可能被表述为“不知情的第三人以合理价格受让动产所有权”。“违约方解除合同”可能与“违约方诉请解除合同之权利限制”的案例相关。BM25无法理解这些表述在法学意义上的等价性。缺乏上下文理解查询“醉酒驾驶造成事故的保险赔付”BM25会平等地看待“醉酒”、“驾驶”、“事故”、“保险”、“赔付”这些词。但它无法理解“醉酒”是“驾驶”的修饰和条件“事故”是“醉酒驾驶”的结果而“保险赔付”是核心的法律争议点。这种词与词之间的逻辑关系BM25是看不见的。长尾查询与稀疏性律师的查询有时非常具体且冗长例如一份事实描述的片段导致查询向量稀疏与文档的匹配点很少BM25的评分会很低可能无法有效召回真正相关的案例。注意这并不意味着要抛弃BM25。恰恰相反在构建检索系统的第一级“召回”阶段BM25因其高效和稳定仍然是无可替代的“守门员”。它的角色是从百万甚至千万级的案例库中快速筛选出几百个可能相关的候选文档Candidate Documents。我们智能体进化的是在BM25之上的“理解”和“重排”层。2.2 静态规则库的维护噩梦为了缓解词汇不匹配传统的做法是构建一个法律同义词库、业务规则库或者查询模板。例如当用户搜索“劳动合同解除”系统自动扩展查询为“劳动合同解除 OR 辞退 OR 解雇 OR 开除”。这种方法初期有效但维护成本极高难以穷尽法律语言博大精深地域差异、审判层级差异、时代差异都会导致新的表述不断涌现人工维护的规则库永远滞后。容易冲突规则之间可能存在优先级冲突或意外叠加导致查询被过度扩展引入噪声降低检索精度。缺乏个性化不同领域的律师如知识产权、金融证券、劳动争议的查询习惯和关注点不同一套统一的规则无法满足所有需求。2.3 LLM带来的范式转变机会大语言模型LLM的出现为解决上述问题提供了新的可能。LLM如GPT系列、LLaMA等通过在超大规模文本理论上可以包含海量法律文书上的预训练内化了丰富的语言知识和世界知识其中包括对法律概念、逻辑关系的深层理解。LLM在法律检索中可以扮演两个关键角色查询理解与重写Query Understanding Rewriting将用户原始的、可能模糊或不规范的查询自动重写为多个对检索系统更友好、更可能匹配到相关文档的查询变体。例如将“股东会程序有问题怎么办”重写为“公司股东大会召集程序瑕疵的法律后果”、“股东会决议因程序违法被撤销的案例”、“《公司法》关于股东会召集程序的规定及违反效力”。语义匹配与重排Semantic Matching Re-ranking对于BM25召回的前K个候选文档利用LLM深度理解查询和每个文档的语义进行更精细的相关性打分和重排将语义相关但关键词匹配度不高的案例排到前面。然而直接、粗暴地使用LLM进行端到端的检索即用LLM直接为海量文档打分是不现实的因为其计算成本极高、延迟巨大。因此一个高效的架构必然是“传统检索召回 LLM精排”的混合模式。而我们提出的“自我进化智能体”则是要让这个混合模式中的“LLM精排规则”和“查询重写策略”能够持续学习和优化。3. 自我进化智能体的核心架构设计我们的智能体不是一个单一的模型而是一个由多个模块协同工作的系统。它的“自我进化”体现在一个基于反馈的闭环学习循环中。下图展示了其核心工作流程与进化机制graph TD A[用户输入原始查询] -- B[查询理解与重写模块]; B -- C[混合检索层: BM25 向量检索]; C -- D[召回Top-K候选案例]; D -- E[LLM语义精排与重排模块]; E -- F[返回最终排序结果]; F -- G[用户行为反馈点击/标记相关]; G -- H[反馈学习模块]; H -- 更新提示词/调整权重 -- B; H -- 生成正负样本对 -- I[持续训练数据池]; I -- J[定期微调LLM/Embedding模型]; J -- 模型能力提升 -- B; J -- 模型能力提升 -- E;下面我们来拆解每一个核心模块。3.1 模块一具备记忆与策略的查询重写器这是智能体与用户交互的第一道门也是进化的起点。它的输入是用户原始查询Q_original输出是一组优化后的查询列表[Q_rewrite_1, Q_rewrite_2, ...]。基础实现静态策略 我们可以设计一套固定的提示词Prompt给LLM你是一个专业的法律检索助手。请将用户的法律问题查询改写成3个更适合进行法律案例数据库检索的查询。要求 1. 使用更正式、更完整的法律术语。 2. 可以拆解查询中的复合法律问题。 3. 考虑同义词和常见表述变体。 4. 每个改写后的查询应独立且明确。 原始查询{Q_original}LLM会返回3个改写后的查询。然后系统并行地用这3个查询去调用BM25检索最后合并去重结果。进化点一基于会话历史的个性化重写智能体应该维护一个轻量级的用户会话记忆例如存储在向量数据库中的最近几次查询和点击的案例摘要。当新的查询到来时除了原始查询还可以将相关的历史上下文一同送给LLM。...上述提示词... 历史上下文用户最近搜索过“劳动合同中竞业限制条款的效力”并点击了关于“违约金过高调整”的案例。 当前查询“竞业限制补偿金标准”这样LLM可能会生成更贴切的改写如“竞业限制经济补偿法定标准”、“未约定竞业补偿金时条款效力”、“竞业限制补偿与违约金关系案例”其中最后一个改写明显受到了历史上下文的影响。进化点二基于反馈的提示词优化Prompt Tuning如果系统检测到对于某一类查询如“劳动争议”用户频繁点击由某个特定改写查询Q_rewrite_A召回的案例而很少点击其他改写查询的结果那么智能体可以学习到“对于劳动争议类查询Q_rewrite_A这种改写风格更有效”。系统可以将这个“规则”抽象化并用于动态调整后续同类查询的改写提示词例如在提示词中增加“此类问题请侧重从劳动者权益保障和合同履行角度进行改写”。3.2 模块二混合检索层与候选召回这一层负责高效地从海量案例库中初步筛选出候选集。我们采用混合检索策略以兼顾召回率与效率。稀疏检索BM25针对每一个改写后的查询使用BM25算法在案例的“标题”、“案由”、“当事人”、“裁判要旨”等关键字段上进行检索。这一步速度极快能保证高召回率尤其是对关键词的精确匹配。稠密检索Embedding同时使用一个法律领域微调过的文本嵌入模型Embedding Model将每一个改写后的查询转换为向量并在预先构建好的“案例内容向量库”中进行近似最近邻搜索。这一步旨在捕捉语义相似性弥补BM25的词汇不匹配缺陷。将两者的结果按一定权重初期可设为BM25权重更高以保证稳定性合并、去重得到最终的Top-K例如K200候选案例列表。这个K值是一个重要参数它需要在检索精度和后续LLM精排的成本之间取得平衡。3.3 模块三LLM驱动的精细化排序与理由生成这是提升检索精度的核心环节也是计算成本最高的部分。目标是对Top-K个候选案例进行精细化打分和重排。实现方案 我们采用LLM的“点对点”打分模式。对于每一个候选案例Doc_i我们构造如下提示词让LLM判断其与查询的相关性任务判断给定的法律案例文档与用户查询的相关性。 请仅输出一个0到10之间的整数分数代表相关程度10表示完全相关0表示完全不相关。 评分时请考虑1. 法律争点是否匹配2. 案件基本事实是否相似3. 裁判规则或法律适用是否具有参考价值。 用户查询{Q_original} 案例标题{Doc_i.title} 裁判要旨{Doc_i.summary} 可选关键段落{Doc_i.snippet} 相关性分数系统并行或批量地对K个候选案例进行评分。然后根据LLM给出的分数进行降序排列得到最终的检索结果列表。进化点从打分到生成排序理由构建学习样本单纯的打分对于进化来说信息量不够。我们可以让LLM在打分的同时生成简短的“相关理由”或“不相关理由”。例如分数8 理由该案例涉及“股东会召集程序瑕疵”与查询中的“程序有问题”直接相关且判决中论述了程序轻微瑕疵是否影响决议效力对用户问题有直接参考价值。这些“查询文档分数理由”四元组是极其宝贵的反馈数据。它们清晰地标注了哪些文档是正样本高分哪些是负样本低分并且包含了“为什么”的说明。这些数据将被存入一个持续训练数据池用于后续的模型微调。3.4 模块四反馈闭环与进化引擎这是智能体“自我进化”的动力来源。进化主要在两个层面发生层面一在线学习与策略调整隐式反馈记录用户的点击行为。用户点击了排名第3的案例而没有点击排名第1的这本身就是一个强烈的信号——可能LLM对第1个案例的评分过高或者查询改写没有准确捕捉用户意图。系统可以据此调整混合检索中BM25与向量检索的权重或者微调查询重写模块的策略。显式反馈提供“相关/不相关”按钮。这是更直接的监督信号。当用户标记某个返回案例“不相关”时这个“查询文档负样本”对会被立刻加入训练数据池并可能触发一次对当前查询重写策略的即时评估。层面二离线学习与模型微调这是进化更根本的形式。定期例如每天或每周执行以下流程数据收集从反馈数据池中抽取高质量的四元组数据。正样本高分且用户点击/标记相关和负样本低分或用户标记不相关都需要。数据构造将数据构造为多种训练任务检索精排微调将任务构造成对比学习或列表级排序学习。例如对于一个查询有一个正例文档和若干个负例文档训练模型使正例的相似度分数远高于负例。这里可以使用像RankLLM这样的专门针对排序微调的方法。查询重写模型微调输入原始查询和最终被用户认可点击的文档让模型学习如何生成能召回该文档的改写查询。这可以训练一个更专业的查询重写小模型。Embedding模型微调使用收集到的正负样本对继续在类似BERT的法律语料上做对比学习训练让Embedding模型更能区分法律语义上的相关与不相关。模型更新用新数据微调后的模型以A/B测试或渐进式发布的方式更新线上系统中的相应模块精排LLM、重写模型、Embedding模型。通过这个闭环智能体实现了“实践 - 反馈 - 学习 - 优化 - 再实践”的持续进化。它的“规则”体现在模型参数和策略中不再是工程师预设的而是从真实的用户交互中学习得来的。4. 关键技术细节与实操挑战构建这样一个系统在工程和算法上会遇到不少挑战。这里分享一些关键的细节和我们的应对思路。4.1 检索精度与延迟的权衡LLM的调用策略直接用大模型如GPT-4对数百个候选文档逐一评分延迟和成本都无法接受。我们的策略是分层处理第一层快速粗筛。使用轻量级模型如6B/7B参数的法律领域微调LLM或更小的交叉编码器对Top 200个文档进行快速评分筛选出Top 30。第二层精准精排。再将这Top 30个文档用更强大但更慢的模型如GPT-4或更强大的开源模型进行精细评分和理由生成得到最终Top 10结果。 这种“级联”结构能有效平衡效果和效率。此外对LLM的调用要做严格的超时控制和失败重试并考虑使用缓存对相同或相似的查询-文档对缓存其LLM评分结果。4.2 训练数据的质量与冷启动问题进化离不开数据但系统启动初期缺乏用户反馈数据。如何冷启动合成数据利用LLM自身根据已有的案例库批量生成“查询-相关文档”对。例如给定一个案例的裁判要旨让LLM生成可能提出这个问题的多种查询方式。虽然合成数据可能有偏差但足以完成初步的模型微调。利用历史日志如果存在旧的检索系统其查询日志和点击数据是宝贵的初始训练资源。主动学习在系统初期可以主动向专家用户如律师展示一些边界案例询问其相关性快速积累高质量种子数据。4.3 评估体系如何衡量“进化”的效果不能光说系统在“学习”必须有量化的指标来证明它变得“更好”了。离线评估保留一个带有标注相关/不相关的测试集。定期用这个测试集评估系统最新版本的检索效果核心指标包括MRR平均倒数排名衡量第一个相关结果出现的位置。NDCGK归一化折损累计增益衡量前K个结果的整体排序质量。RecallK前K个结果中相关案例的比例。在线A/B测试将新版本的智能体例如采用了新微调模型与旧版本进行线上对比关键业务指标包括点击率结果列表的整体点击率是否提升首位点击率排名第一的结果被点击的比例是否增加任务完成率用户在一次搜索会话后是否不再进行二次搜索暗示首次搜索已满足需求人工评估定期抽样检索结果由领域专家从相关性、有用性等维度进行评分这是最可靠的黄金标准。4.4 可控性与可解释性法律应用必须严谨可控。一个“黑箱”的、不断变化的系统可能会让用户不安。可解释性在返回检索结果时同时提供LLM生成的“相关理由”。这既是给用户的解释也方便用户快速判断该案例是否真的有用。版本控制与回滚每一次模型更新、策略调整都应有明确的版本记录。如果新版本在线指标显著下降应能快速回滚到稳定版本。偏见与公平性监控法律不应有偏见。需要监控系统是否对某些类型的案件如涉及特定群体、特定地区存在系统性检索偏差并在训练数据和学习过程中进行纠偏。5. 超越检索智能体的未来能力展望当这个以检索为核心的智能体具备了强大的语义理解和持续学习能力后它的潜力可以延伸到更广阔的法律服务场景。1. 关联推荐与知识发现用户检索到A案例后系统可以自动推荐“引用本案的后续案例B”、“本案法官审理的类似案件C”、“与本案适用同一法律条文的案件D”。这不再是简单的关键词匹配而是基于案例引用网络、法官画像、法律条文图谱的深度关联挖掘帮助用户构建完整的知识脉络。2. 案情分析与报告生成用户可以将一份复杂的案件材料上传智能体可以自动摘要生成案件事实与争议焦点摘要。类案检索基于上传的材料自动进行多轮、多角度的案例检索找出最相关的判例。观点对比分析检索到的案例总结出支持原告诉请和被告抗辩的主要裁判观点及其比例。生成检索报告自动整理以上分析形成一份初步的法律检索报告草稿极大提升律师工作效率。3. 法律问答与咨询导航系统可以作为一个法律问答的入口。用户输入一个自然语言问题如“公司拖欠工资我该怎么办”智能体可以理解问题背后的法律诉求劳动报酬争议。检索相关的法律法规、司法解释和典型案例。生成一个结构化的回答包含法律依据、维权步骤、风险提示并附上关键案例的链接。实现这些功能需要在现有架构上增加更复杂的任务规划、多轮对话管理以及多工具协调检索工具、计算工具、文本生成工具的能力这正是当前LLM Agent智能体研究的前沿方向。我们的自我进化法律检索智能体为其打下了坚实的数据和模型基础。构建一个“When Rules Learn”的系统其意义不在于创造一个完美无缺的AI律师而在于打造一个能够与法律从业者共同成长、不断适应复杂现实需求的智能伙伴。它从僵硬的规则执行者变为灵活的策略学习者最终的目标是让技术更好地服务于人对公平与正义的追求。这条路充满工程和算法上的挑战但每解决一个难题都让我们离这个目标更近一步。