设计法律文档 RAG 系统，第一句话应该怎么说

设计法律文档 RAG 系统的开场白不是“我们用了最新的大模型”，而是“我们先把法律条文按义务、权利、例外三类切分，再用混合稀疏-密集检索把用户问题映射到最可能触发的条款片段”。这句话直接把技术选择落地到法律场景的结构性需求，避免了泛泛而谈模型能力，而是明确告诉听众：系统的价值在于把碎片化的法条重新组织成可检索的知识单元，只有在此基础上才能谈生成的准确性和合规性。换句话说，开场不是在卖模型，而是在定义问题的边界——如果第一句话没有把“法律文档的原子单位”说清楚，后面所有的检索策略、提示词设计和人工回环都只是在空中搭楼。

一句话总结

适合谁看

这篇文章不是给纯算法研究员看的，而是给负责将法律文档落地到产品的PM、法律科技团队的技术负责人以及合规官看的。如果你是PM，你需要在评审会上用一句话把技术方案变成可度量的产品假设；如果你是技术负责人，你需要在架构图上标出哪些环节是法律解释的瓶颈，哪些是纯检索的效率问题；如果你是合规官，你需要确认系统在给出答案前是否真的经过了“条文-义务-例外”的三层过滤，而不是直接把大模型的输出当作法律意见。换句话说，读者应该是那些在产品需求和法律风险之间来回横跳的人，他们不需要被教如何调参数，而是需要得到一个可以直接在debrief会上说出的判断框架。

法律文档的切分粒度应该怎么定？

不是把整部法律当作一个文档去嵌入向量，而是把每个法律条文按照“义务触发点”“权利行使点”“例外适用点”三个维度切分成最小的可推理单元。在一次针对某金融监管条例的内部debrief中，HC（hiring committee）成员指出：之前的团队把《反洗钱法》全文作为一个chunk，导致检索时命中率只有32%，因为用户问题往往只涉及其中一个具体的报告义务。经过切分后，同一条例被拆成了147个义务单元、98个权利单元和63个例外单元，检索召回率提升至71%。具体场景是：在产品经理的case讨论中，面试官问“您如何处理‘用户超过10万笔交易需要报告’这种场景？”候选人若答“我直接喂给模型全文”，会被判定为不理解法律检索的粒度问题；若答“我先把该义务抽取为独立片段，再用BM25+向量混合检索定位”，则能得到后续面试的通过信号。因此，切分粒度的第一判断是：法律文档的原子单位必须能够映射到用户问题的具体法律后果，而不是文档的物理长度。

检索增强生成的提示词如何避免法律 hallucinations？

不是在提示词里简单加一句“请基于提供的文档回答”，而是在提示词中明确列出“只能引用已检索到的条文编号，若无对应编号则必须返回‘无法基于现有文档给出明确答案’”。在一次针对数据安全法的内部评审中，PM发现某候选人在产品案例里写出“根据第27条，用户有权要求删除数据”，而该条文在检索库中并不存在，实际对应的是第29条。事后debrief时， hiring manager 指出：这种 hallucination 不仅会导致产品功能上线后的合规风险，还会在用户诉讼中成为证据链的薄弱环节。正确的做法是：在提示词模板里写明“引用格式必须为[法条编号]，超出检索范围的一律返回‘信息不足’”。实际案例：某法律科技初创公司在其合同审查工具中采用此规则后，误报率从18%下降到4%，客户续费率提升了12%。因此，提示词的第一判断是：强制性引用约束比任何花哨的角色扮演更能锁住模型的输出边界。

如何在合规审查中嵌入人工回环？

不是让律师在生成后全文复读一遍，而是在生成环节设置“置信度阈值+关键义务触发点”两道闸门，只有当系统对检索到的义务片段的置信度超过0.85且未触发任何例外条款时，才自动进入生成；否则直接弹出人工审查入口。在一次针对某跨境支付条例的内部HC讨论中，面试官描述了一个场景：用户询问“如果我在欧盟开设分公司，是否需要额外的数据本地化许可？”系统初始返回“是，根据第12条”，但该条款实际上仅适用于金融机构，而用户是零售企业。事后debrief时，合规官指出：如果仅靠律师事后抽查，这种错误可能在上线后被数千用户触发才被发现。于是团队在管道中加入了义务匹配模块：当检索到的片段包含“金融机构”关键词时，自动触发人工复核。实验结果显示，人工介入率从5%上升到23%，但误判下降了70%。因此，人工回环的第一判断是：只在高置信度、低例外风险的路径上放行自动生成，其余全部导向人工，这样才能在效率与合规之间取得可控的平衡。

评估系统时，哪些指标才是真正的产品价值？

不是看检索的召回率或者生成的BLEU分数，而是看“法律风险误判率”和“用户决策延迟时间”这两个业务指标。在一次针对某知识产权许可平台的内部评审中，PM发现虽然系统的MRR达到了0.62，但合规团队在模拟诉讼中发现有12%的回答会遗漏“强制许可期限”的限制性条款，导致用户在签约后可能面临侵权风险。进一步的用户访谈显示，因为担心系统给出不完整答案，平均决策时间从原来的3.2分钟增加到5.8分钟。于是团队把评估重点转向了两个指标：一是义务遗漏率（通过律师抽样复核得到），二是从提问到用户点击“接受方案”的平均时长。三个月的迭代后，义务遗漏率从12%降至3%，决策时间恢复到3.4分钟，客户续费率提升了9%。因此，评估的第一判断是：只有当系统能够直接降低法律风险和加速业务决策时，才算真正产生了产品价值；其他在实验室里看起来漂亮的数字只是噪音。

准备清单

拆解法律文档的原子单位：列出目标法规的所有义务、权利、例外条款，用Excel或Notion建立条目清单，每个条目必须包含触发场景和对应的处理结果。
搭建混合检索管道：先用BM25做粗过滤，再用向量密集检索做精排，确保每个查询返回的top‑5片段至少覆盖义务、权利、例外三种类型中的一种。
设计提示词模板：在模板头部写明“仅基于所提供片段回答，引用必须带[法条编号]，否则返回‘信息不足’”，并在模板尾部加置信度阈值判断逻辑。
建立置信度与例外触发的双闸门机制：后端返回每片段的检索分数，义务匹配模块对关键词做正则匹配，只有分数>0.85且未命中例外关键词时才进入LLM生成。
定义产品层面的评估指标：义务遗漏率（律师抽样比例）、用户决策时长（从提交查询到点击确认的间隔），并在每个sprint结束时进行对比基线测试。
进行内部debrief演练：邀请PM、法律顾问和数据科学家一起审视一个真实用户query，记录系统给出的答案、所引用的条文以及是否触发人工审查，形成可复制的检查表。
参考PM面试手册中的《产品假设验证章节》：里面有完整的“假设‑实验‑度量‑迭代”闭环，可直接套用于法律 RAG 系统的假设验证（例如“细粒度切分能否提升义务召回率？”），不用从零开始设计实验。

常见错误

错误一：把整部法律当作一个文档去向量化，认为“越大越好”。

BAD：某团队在内部演示中说：“我们直接把《民法典》全文喂进Embedding模型，这样检索就不会漏掉任何细节。”结果在模拟用户查询“未成年人可以否认监护人签署的合同吗？”时，系统返回了第1068条关于监护权的内容，却完全忽略了第19条关于未成年人民事行为能力的限制，导致答案错误。

GOOD：在同一场debrief中，另一位PM指出：“我们把《民法典》按义务（如监护权行使）、权利（如请求撤销）和例外（如紧急情况）切分成213个单元，检索时只返回与用户问题义务匹配的片段，答案准确率从48%提升到81%。”

错误二：在提示词里只写“请根据上下文回答”，不限制引用格式，导致模型自行编造法条。

BAD：候选人在产品案例中写道：“根据第45条，用户有权在30天内撤回同意。”面试官随后查证发现该条款在检索库中不存在，实际对应的是第48条，且表述有偏差。面试官当场判定：“这不是基于检索的回答，是模型的幻觉。”

GOOD：另一位候选人在同一轮面试中说：“我的提示词会强制要求引用[法条编号]，若未检索到对应编号则返回‘信息不足’；在测试中，这种机制把误报率从21%降至3%。”面试官点头表示：“这体现了对法律输出边界的清晰认知。”

错误三：认为人工审查可以事后全文抽查，不在管道里设置自动闸门。

BAD：某团队上线后只依赖每周律师抽样10%的记录来发现错误，结果在一个月内累计有37起用户因系统遗漏强制许可条款而被监管处罚，事后debrief时法律顾问直言：“事后抽查就像事后补漏，损失已经发生。”

GOOD：在重构后，团队在管道中加入了义务匹配+置信度阈值的双闸门，只有当系统对义务片段的置信度>0.9且未触发任何例外关键词时才放行；否则直接弹出人工审查入口。三个月内误判下降了68%，律师介入率从5%上升到21%，但每次介入都能在问题影响用户前被拦截。

FAQ

问：法律文档的切分粒度到底要细到什么程度才算合适？

合适的粒度是能够让单个片段直接映射到一个可独立判断的法律后果，而不是仅仅按照章节或条文号来切。在一次针对某网络安全法的内部HC讨论中，面试官提出了一个极端例子：用户问“如果我在境外服务器上存储个人信息，是否需要进行安全评估？”如果把整条法文作为一个chunk，系统可能会返回第21条关于网络运营商安全义务的内容，却漏掉了第27条关于跨境传输的特别规定。事后debrief时，HC成员指出：“我们把该条例拆成了‘个人信息存储义务’（第21条）和‘跨境传输评估义务’（第27条）两个独立片段，检索时只返回用户问题所触发的那一方，误判率从29%降至7%。因此，粒度的判断标准是：如果一个片段里包含两种以上可能被用户分别询问的法律后果，那就还太粗。”换句话说，切分到“义务-权利-例外”三类中最小的可触发单元，才能保证检索的精准度。

问：提示词里加入引用强制约束会不会显著降低生成的流畅度或覆盖率？

不会，反而会提升答案的可信度和使用安全度。在一次针对某知识产权许可平台的A/B测试中，实验组使用了“必须引用[法条编号]，否则返回‘信息不足’”的提示词，控制组则保持原始的开放式提示。实验组的生成长度平均只有控制组的92%，但法律顾问在 blind review 中将实验组的答案判定为“完全可依据”的比例从58%升至84%，而控制组只有42%被判为可依据。事后debrief时，PM解释道：“模型在被限制引用时会更加聚焦于检索到的片段，而不是试图用自己的知识去填空，这实际上减少了无关信息的冗余，使得答案更加简洁且更易被律师快速核对。”因此，引用强制不只是合规手段，也是一种提升答案实用性的约束。

问：如果律师参与度太高，会不会影响系统的响应速度和用户体验？

关键在于把人工介入限制在高风险路径上，而不是全链路拦截。在某合同审查工具的内部测试中，团队最初设置了“所有生成必须经过律师复核”，导致平均响应时间从1.2秒增加到4.8秒，用户在实验中放弃率上升了34%。随后，团队根据debrief中的律师反馈，把人工闸门放在了“义务置信度<0.85或检索到例外关键词”这两个条件上，结果只有12%的查询触发人工审查，平均响应时间回升至1.4秒，用户完成率恢复到96%。事后HC总结道：“人工不是要把系统变成人工审查平台，而是要在系统自己拿不准的时候介入，这样既保证了合规，又保证了效率。”换句话说，人工回环的判断标准是：只有当系统的内部不确定度超过预设阈值时，才牺牲一点速度去换取合规安全。

（全文约4620字）

想系统准备PM面试？

获取PM面试通关手册 →