类案检索

1客户嘴上要的

「输入案情，AI 返回最相似的 20 个判决，省得律师自己在数据库里翻。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周找真问题（看律师怎么用案例）

   • 跟律所诉讼团队 3 个律师坐，看他们写代理词时怎么找和用案例。发现：律师按「争议焦点」找案例，不按事实找。他们要的是：同一个法律问题、对本案法官有说服力、近几年、裁判观点对我方有利；如果有不利案例，也要提前知道，准备区分理由。
   • 「说服力」有现成的排序依据：最高人民法院关于类案检索的指导意见规定了检索范围的优先顺序——指导性案例优先，其次是最高法发布的典型案例和裁判，再到本省高院、上一级法院和本院的案例。排序直接按这个顺序做。
   • 真问题是「按争点检索 + 按说服力排序 + 发现不利案例」。成功标准改成：「在 30 个历史案件的争点上，律师认可的有用案例出现在前 10 条的比例不低于 70%；每条结果标出裁判要旨所在段落。」
   • 踩坑别用「相似度分数」做验收。律师不关心分数，只关心能不能写进代理词。
2. 2

   第 2 周定范围 + 数据来源

   • 范围：只做律所业务量最大的两类纠纷（买卖合同、建设工程施工合同）。
   • 数据：公开裁判文书覆盖不全。人民法院案例库收录了经过筛选的参考案例，是律师常用来源；律所还采购了商业法律数据库。确认数据库的接口授权和使用条款，能否做二次检索和结构化处理。不能用的就只做查询辅助，不做本地存储。
   • 把律所历史代理案件的判决和代理词作为内部案例库，和公开数据一起检索。
   • 踩坑别默认能批量下载商业数据库。授权条款不允许时，项目架构要改。
3. 3–4

   第 3–4 周原型 + evals

   • 两步检索：先由模型把律师输入的案情拆成争点（例如「工程款优先受偿权的行使期限」），律师确认或修改争点；再按争点检索，按指导意见的优先顺序和年份排序，结果分「支持我方」「不利我方」两栏。
   • evals：选 30 个已结案件，由主办律师列出当时实际引用的案例和应该知道的不利案例。同时统计「不利案例发现率」。
   • 踩坑裁判观点的正反判断容易错。系统只标出裁判要旨原文，正反由律师确认，不自动下结论。
4. 5

   第 5 周Demo + 并肩改

   • 让律师用正在办的案件试用。反馈：「争点拆得比我想的细，有两个我没想到」——把争点拆解单独做成功能。另一条反馈：「希望看到这个法官以前怎么判」——涉及数据边界，记入待评估事项，不在本期做。
5. 6

   第 6 周交接交接

   • 交给律所知识管理团队：维护内部案例库，定期补充新结案的判决和代理词；每半年请诉讼律师更新一次测试集。
   • 没有内部案例库的持续补充，系统只剩公开数据的能力，律师会回到原来的数据库。

4这个案例教给你的可复用判断