做法律知识助手项目那阵子我被大模型的“一本正经胡说八道”整得没脾气。用户问的是很日常的劳动争议问题模型却能面不改色地把已经失效的旧规定当成现行法条讲出来还附上一段语气笃定的分析。客户一句话点醒了我“我们要的不是一个会聊天的模型要的是能拿出依据、说得清出处的法律助手。”这句话基本决定了我后面所有技术方案的走向。想在法律领域把LLM真正用起来离不开检索增强生成RAG这套方法——把外部法律知识先检索出来再让模型基于材料作答而不是让它凭训练记忆自由发挥。这篇就把我在这套法律RAG系统上的实战过程、选型取舍和踩坑记录完整写下来适合正在做法律问答、企业合规助手或知识库应用的开发者和产品同学参考也欢迎想了解RAG落地细节的朋友一起讨论。1. 法律大模型落地为什么绕不开RAG1.1 法律场景的特殊性不是“聊天”是“引用”法律问答和通用闲聊在本质上是两种任务。闲聊里说错一个常识无伤大雅但法律问答里每一句话都可能被用户拿去作为判断依据错误代价完全不同。法律文本有几个天然的属性决定了它和普通知识问答不是一回事。第一是权威性。法条是精确措辞一个字都不能含糊“应当”和“可以”在语义上看着接近在法律上分别是强制性义务和授权性权利差一个词结论就完全不同。第二是时效性。法规会不断修订、废止、被新法取代用户需要的永远是现行有效版本而模型训练数据里的知识截止时间根本跟不上法律法规的更新频率。第三是强结构。法律体系有编、章、节、条、款、项的严格层级专业场景里的引用方式是“某法第几条第几款”这种坐标式表达不是模糊的自然语言描述。第四是长文本和跨法条依赖。一个法律问题往往要同时参照多部法规里的多个条款单靠模型内部记忆很难把这些信息完整、准确地串起来。我举个实际遇到的例子。用户问“试用期被辞退有没有经济补偿”这个问题的答案分散在劳动合同类法规的多个条款里涉及试用期约定、解除条件、补偿基数计算等不同环节还需要判断具体情境。如果让模型凭记忆回答它能讲出大概但很难保证每一条引用都精确到条号更危险的是它可能把已经废止的实施条例里的内容当成现行规定混进来。这种场景下用户要的不是“意思差不多”的总结而是一个能一路回溯到法条原文的证据链。1.2 RAG能解决的问题和它解决不了的问题RAG的思路其实很简单模型回答之前先从外部知识库里检索出与问题相关的若干段落把这些材料作为上下文交给模型让模型的回答被限定在材料范围之内。相当于给模型开卷考试而不是闭卷凭记忆硬写。放在法律场景里RAG带来的收益非常直接。幻觉大幅度下降因为模型不再需要凭空“回忆”法条而是对着检索出来的条文原文归纳表述引用可追溯用户可以顺着回答中的标注找到对应法规和具体条目新规可以即时生效法规库一更新检索结果立刻就能反映到回答里不需要重新训练模型。但必须说清楚RAG不是银弹。如果知识库本身没洗好检索环节召回不到正确材料后面生成再强也白搭材料召回了但被切片切得七零八落模型读到的是语义断裂的碎片照样得不出正确结论即便材料齐全模型在对材料的解读上仍然可能存在偏差只不过从“自由发挥”变成了“有限的发挥”。我后来跟团队总结过一句话RAG系统的工程质量八分在检索两分在生成而检索质量有一半又取决于知识库处理得干不干净。这句话听着朴素但项目推进过程中每一个坑都在反复验证它。2. 整体选型与系统链路先跑通再优化2.1 最小可用链路的设计做这类系统的第一原则是先把端到端链路跑通再逐步替换弱环节。第一版我们实现的链路是这样的用户提问进来之后先做一轮问题处理把口语化表达或带指代的多轮追问改写成一个完整独立的问题然后并行走两路召回一路是用稠密向量做语义相似度检索另一路用稀疏检索做关键词精确匹配两路结果通过倒数排名融合RRF合并成一份候选列表再交给重排序模型做精排最后保留得分最高的几个材料连同法规名称、条号、效力状态等元数据一起组装成提示词交给大模型生成带引用标注的回答。我简单画一下这个结构不做流程图文字足够说明。问题改写这一步很多人会忽略但在法律咨询里特别重要因为用户经常上来就说“那赔偿基数怎么算”如果不结合前文“被公司违法辞退怎么办”这个问法单看后半句根本没法检索。多轮压缩在后面的章节单独讲这里先把链路固定下来。为什么选择多路召回而不是纯向量检索其实就是因为法律文本里有两类特性各异的查询。一类是语义型提问比如“没签合同被开除怎么维权”需要理解近义词和意图另一类是坐标型提问比如“劳动合同法第三十九条说了什么”本质上是在查一个精确的法条编号必须字面命中。这两类需求用单一检索方式都无法同时覆盖。2.2 组件选型在数据隐私和效果之间找平衡选型时要先想清楚项目的约束条件。我们做的是企业内部法律助手用户问题涉及劳动关系、合同纠纷等敏感信息数据绝不能出域这一点直接决定了不能把所有请求都抛给外部推理接口。所以我们整体走的是私有化部署路线。几个关键组件的选型逻辑我用一张表说明组件我们的选择可替代方案选择理由向量库开源自托管向量库商用向量库、开源检索引擎自带向量能力百万级分块以内自托管足够稳定数据不出内网稀疏检索开源检索引擎内置BM25其他全文检索引擎目的是精确匹配编号和核心术语和向量路互补底座模型开源中文底座模型7B至13B量级更大尺寸底座或商用推理接口数据隐私优先配合检索上下文和提示词约束后效果达标重排序模型常用中文跨编码器重排序模型更大规模精排模型在延迟可接受的前提下显著提升前几位命中率这里我想强调一下“先跑通再优化”的意思。我们第一版连重排序都没有就是向量加关键词融合之后直接丢给模型跑起来之后发现召回了相关材料但排序不准重要的法条经常排到第五名开外而提示词里上下文窗口有限塞不下太多候选这才决定加精排环节。整条链路几乎是在实际问题的驱动下一步步补完的不是一开始就设计得面面俱到。还有一点给小型项目参考数据量到了百万级分块之前不必上分布式方案。我们第一版跑在几台CPU服务器上向量检索是主要瓶颈后来通过优化索引参数把单次查询压到百毫秒级完全能满足交互需求。不要过早引入复杂度那是给自己找麻烦。2.3 一个容易忽略的选型原则检索范围要能收窄法律知识库有一个显著特点法规之间位阶分明领域清晰。用户在问劳动问题时正确条文大概率分布在劳动相关法规里用户在问合同问题时答案又跑到民事法律相关章节里去了。这意味着我们可以利用元数据做检索前提过滤先判定问题属于哪个法律领域再把这个领域范围作为硬约束传给检索层缩小召回空间。这一步对精度的影响甚至超过重排序。后面知识库章节会详细展开元数据设计这里先记住一个结论——在RAG系统里让检索范围变窄往往比让检索模型变强更划算。3. 知识库搭建切片和元数据是决定检索质量的地基3.1 按法规结构切块而不是按固定字符数切块不少RAG教程会直接告诉你“每块切512个字符重叠128个字符”但在法律文本上这么干基本等于自杀。我第一版就是这么做的上线后收到大量反馈说回答读起来像断章取义排查下来发现一个很尴尬的现象大量文本块从一条规定的中间开始、在另一条规定的中间结束模型实际读到的是被拦腰截断的半截条文自然得不出完整结论。后来我们把切块策略改成“按法规结构切”。法律文本本身有清晰的层级——编、章、节、条、款、项天然就是为引用而设计的。基本切块单位定为“条”每条内容携带它所属的章名称和节名称作为定位信息一起入库。对于特别长的条内部再按款拆分但每个子块都要保留“第X条第X款”的完整标识保证即使只召回一个款模型也能知道它出自哪里、和其他款是什么关系。下面是我们实际使用的分块结构示例用JSON表示一个知识条目{ chunk_id: labour-2024-031-002, doc_id: labour-2024-031, doc_name: 某劳动合同司法解释, chapter_path: 第二章 劳动合同的订立, article_number: 第二十一条, article_content: 条文内容全文……按自然段拆分为多个paragraph元素, paragraphs: [ {seq: 1, text: 第一款内容}, {seq: 2, text: 第二款内容} ], metadata: { effective_date: 2024-01-01, status: current, level: judicial_interpretation } }这样设计的好处是无论向量召回命中整个条还是条下的一个款模型都能拿到完整的坐标信息引用格式很容易规范成“某法规第X条第X款”。而且分块与人类阅读习惯一致人工质检时也方便核对。3.2 元数据设计让检索发生在“正确的时空”法律知识库的元数据不是可有可无的辅助信息它是检索阶段最重要的约束条件。我建议至少包含这么几类法规名称、位阶法律、行政法规、司法解释、地方性法规等、发文字号、施行日期、效力状态现行有效、已修订、已废止、章节路径、具体条号、主题标签劳动、合同、婚姻、公司、知识产权等。这套元数据真正发挥作用的地方是检索前过滤。用户问“试用期工资怎么算”检索层可以先判断领域标签为“劳动”只在这个范围内做候选召回效力状态默认只保留“现行有效”旧版本直接不参与排序。这样既提升了准确率也顺带解决了时效性问题。特别提醒一点效力状态过滤一定要在召回阶段做不要放在生成阶段。我们曾经图省事让模型在阅读材料时自行判断“这个法规是否还有效”结果发现模型会把明显过时的条文说得振振有词因为模型天然倾向于顺着材料回答而不是质疑材料。把失效材料挡在检索门外才是可靠的做法。3.3 增量更新与版本管理法律库不是静态库法律知识库和普通文档库最大的区别在于它的内容会按法定节奏更新。每年都有新法施行、旧法修订、配套司法解释出台知识库必须跟上这个节奏。我们做了一套相对笨但稳妥的更新流程法规更新经人工校对后先进入“待生效”区域系统记录生效日期到了生效日期自动切换为“现行有效”同时把旧版本标记为“已修订”或“已废止”。历史版本不删除保留完整档案重点是在检索时默认被过滤掉。这就要求检索时不仅能看到文本还能看到状态字段。元数据里的status字段就是为此设计的。有一次排查线上问题时我们发现某个旧版劳动法规的条文还在被大量召回原因是导入时没有给旧条目打失效标签向量索引照样把它当成有效内容参与排序。打上失效标签并加了过滤逻辑之后这个现象立刻消失了。做过一轮之后我深刻意识到法律知识库的“更新”不是简单追加文档而是同一逻辑文档的版本演进没有版本意识检索质量迟早会出问题。4. 检索质量从哪里来混合召回与重排序的实战调参4.1 BM25在法条检索里的独特价值向量检索有个隐含假设语义相近的多为相关。但法律引用的常见形态恰恰是“不语义相近但必须字面命中”的。比如用户问“竞业限制期限是几年”相关条文里通常会出现“竞业限制”和“期限”这两个词用户如果是追问特定条款输入的内容干脆就是“某法第X条”。这类问题的答案高度依赖字面术语的共现恰好是BM25这类稀疏检索的长项。我在实际项目里反复验证过同一个现象很多被向量检索排到很后面的条文恰恰是用户真正需要的那一条因为模型把它编码成了“语义向量”之后与问题的向量余弦相似度并不高但它的字面关键词高度匹配。所以在法律RAG里我强烈建议保留一路关键词精确检索用它和向量检索做互补而不是迷信某一种“更先进”的召回方式。4.2 RRF融合和重排序的实现要点多路召回之后如何合并排序是个关键问题。我们用的是倒数排名融合Reciprocal Rank Fusion——不依赖分数绝对值只依赖排名位置天然规避了向量分数和BM25分数量纲不一致的问题。公式核心思路是某个文档在多路召回结果中排名越靠前融合得分越高。常用实现是给每路结果的每个召回项一个得分1/(krank)k是常数常见取60。把两路的得分相加按总分排序得到融合后的候选列表。伪代码供参考很简短def rrf_fusion(ranked_lists, k60): scores {} for ranked in ranked_lists: for rank, doc in enumerate(ranked, start1): if doc not in scores: scores[doc] 0.0 scores[doc] 1.0 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)融合之后取前30条进重排序模型。重排序这一步的原因很简单召回的目标是高召回率宁可多召回也不能漏精排的目标是高精度把最相关、最应该被模型看到的材料排到前面。重排序模型通常是一个跨编码器结构对“问题-候选文本”逐对打分效果显著但计算量也大所以只能拿召回的候选子集去精排。重排后取前5到8条进提示词上下文。为什么不是越多越好一是上下文窗口有限二是材料太多会让模型“挑花了眼”反而更难聚焦。按我们调出来的经验法律问答里给3到6条高相关条文通常最合适既能覆盖跨条款回答的需要又不会稀释注意力。4.3 改造前后的效果对比我们在内部评测集上对比过几种策略的检索命中率。评测集是约300道从真实咨询中脱敏整理出来的法律问题每道题人工标注了标准答案所涉及的法规条文。命中定义是回答中引用到的条数里至少包含一条标准答案条文的条数占比。策略相关条文命中率观察纯向量检索63%语义相近但经常命中过时或不相关条文纯BM25检索71%精确但同义改写场景漏检较多向量BM25融合78%覆盖范围明显互补融合后加重排序85%左右精排显著改善了最终生成质量这个数字只代表我们项目里的情况但趋势有参考价值。纯向量在语义型问题上有优势纯BM25在术语型问题上有优势融合把两者互补做起来了重排序则把真正的“珍珠”提到前排。有意思的是重排序对最终回答质量的影响在评测里甚至比召回率还高因为同样的正确条文排在第2位还是第7位直接决定了模型最终敢不敢引用它。5. 生成端防幻觉引用、拒答与多轮追问5.1 引用溯源式的提示词设计检索做得好只完成了上半场。下半场要把材料交给模型并且让模型“只敢照着材料说”。这完全靠提示词约束是不够的但好的提示词能极大降低幻觉概率。我们的提示词结构大致是三层角色定义、回答规则、检索材料。角色定义说明这是一套法律知识问答系统必须基于提供的材料回答规则里明确几条硬约束——只能使用材料中的条文作答不得补充材料外的法律知识引用格式必须写成“法规名称具体条号”的形式如果材料不足以支撑回答明确说“根据现有资料无法给出明确判断”不能编造最后加一句“本回答仅供法律信息参考不构成正式法律意见”。检索材料部分的组织也很讲究。我们会给每条材料加上编号和元数据头让模型一眼看到材料来源[材料1] 来源某劳动合同司法解释 第二十一条2024年施行现行有效 内容…… [材料2] 来源某劳动争议处理法规 第七条 内容……材料编号直接呼应引用格式。这样模型在回答“依据材料1可以认定……”的时候引用关系是清晰可控的。我们在评测里发现这种带编号和来源头的材料格式比把大段裸文本堆进去的引用准确率高出一大截。5.2 无依据时的拒答策略宁可不答不可胡说法律场景最怕的不是模型说“我不知道”而是模型明明不知道却编一个“听起来很专业”的答案。所以我们专门设计了三条防线。第一条防线在检索层重排序得分低于某个阈值的材料整体判定为“与问题相关度不足”这时候不再进入生成阶段而是直接输出兜底话术。第二条防线在生成层提示词里明确要求模型先自检“材料是否覆盖了问题核心”覆盖再作答不覆盖就明说。第三条防线是产品层回答末尾带上一句“信息仅供参考涉及具体纠纷建议咨询执业律师”这既是风险提示也是在用户心里建立合理预期。我曾经为了追求回答流畅度一度把拒答逻辑调松过结果评测集里“编造条文”类错误立刻增加。后来把阈值重新收紧才回到可控状态。在法务场景里宁可让用户觉得系统“有点保守”也不能让用户拿着一个编造的依据去处理现实事务。5.3 多轮追问的处理先压缩再检索真实法律咨询很少是单轮结束的。用户往往会先问“公司辞退我合法吗”得到回答后再追问“那经济补偿金怎么算”“需要提前三十天通知吗”。这时候如果每一轮都用原始历史文本去检索会带入大量噪音而且检索效果会随着对话历史变长而退化。我们的做法是先做一轮“对话压缩”用LLM把上一轮回答的要点和当前问题合并成一个独立的检索query。比如用户前文问过“试用期无故被辞退怎么办”当前问“能要赔偿吗”压缩后的query就是“试用期被无故辞退能否主张赔偿金”。然后用这个独立query走标准检索链路生成回答时再把压缩后的对话摘要一并给模型保证连贯性。这个环节有一个小坑压缩后的query不能太口语化否则检索层的BM25路几乎被浪费。我们试过在压缩指令里加一条“生成适合检索的书面表述”效果提升明显。6. 评测闭环与五条踩坑经验6.1 三个评测维度正确性、引用可靠性、完整性系统做出来之后比“上线”更重要的是建立一套可持续迭代的评测集。我们评测集的题目从真实咨询记录里脱敏提取覆盖劳动纠纷、合同违约、婚姻家事、公司治理等常见法律场景每道题由有法律背景的同事标注标准答案及其所用法条。评分分三个维度。第一是结论正确性判断模型给出的法律结论是否成立第二是引用可靠性判断引用的法规名称和条号是否真实存在、是否真正支持结论第三是完整性判断面对多法条问题时是否遗漏关键要点。每个维度用0到2分给两张表汇总后形成一次迭代的基线分数。除了人工评分我们还会持续跟踪三类客观指标拒答率答不上时不硬编的比例、检索命中率标准答案条文是否出现在检索候选里、平均响应延迟。这几个指标配合起来才能综合反映系统的健康度。每改一次检索参数或提示词都跑一遍同一套评测集用数字说话而不是凭感觉说“好像变好了”。6.2 踩过的五个高频坑以及解决思路第一个坑是固定长度切片破坏条款结构这个前面已经讲过了解决方案就是按“条-款-项”层级切分宁可块数变多也不能让一个完整法律命题被截断。第二个坑是效力状态过滤缺失。旧版本法规明明已经被废止还留在向量索引里参与召回。解决方案是把效力状态作为硬性过滤条件默认只检索现行有效版本旧版本只作档案保留。第三个坑是“应当”和“可以”这类法言法语的语义混淆。向量模型很多时候理解不了这两个词的强制程度差异语义上它们太接近了。我们通过混合检索里的关键词路做硬匹配再靠重排序把精确命中的条文顶到前面解决了一部分问题。彻底解决还得靠后期的人工校对和规则补充。第四个坑是重排序模型对超长文本的打分偏差。法律条文动辄几百上千字有些精排模型对长文本的排序并不稳定经常把真正相关的长条文打到后面。我们采用的解决方法是把“条”拆成长度更均衡的子块去参与精排精排排序完成后再按父级structure把同一条的不同款合并回一个引用单位。排序对象和展示对象分离这是分块系统里很关键的一个技巧。第五个坑是用户问题里的干扰信息。真实用户提问往往带着情绪和背景故事比如“我在某公司干了三年老板昨天突然说要辞退我也没提前通知这种情况能赔偿吗”。背景信息对理解有帮助但大量无关词会干扰检索。我们把问题改写阶段不仅做多轮压缩还会做一轮“去噪”——保留法律事实要素去掉情绪词和无关叙述再进入检索链路。三轮之后同类问题的检索命中率又有了一次明显回升。回过头看这套法律RAG系统我最大的体会是在专业领域里RAG的价值不是让大模型“变聪明”而是让大模型“不敢乱说”。它把模型的角色从“知识的拥有者”变成了“知识的转述者和组织者”而知识本身由知识库、检索规则和人工校验来负责。这个定位一旦清晰很多设计上的纠结就自然化解了。最后再分享一点个人经验如果你也想做类似的项目我建议把至少一半的时间花在知识处理、评测集搭建和检索调优上而不是一上来就纠结用哪个更大更强的模型。评测集要早建它是整个项目的仪表盘知识库要精洗它在很大程度上决定了所有后续优化能触达的质量上限。把这些“笨功夫”做扎实了模型的每一次迭代才有正确的导航方向。