"类案同判"写进了文件,也压在了每位法官肩上,但落到办案现场,问题很具体:法官怎么知道有相似的案子已经判过?又哪来时间去一篇篇检索比对?这正是类案推送系统要解决的——不是再造一个检索框,而是在法官办理本案时,把高度相似的已决案件自动推到面前。本文不谈口号,只讲一套能用的类案推送系统该怎么搭:四层技术架构、为什么必须用语义检索、强制检索如何留痕合规、为什么要本地化部署,以及法院信息处选型时该照着问供应商哪些问题。
一、先厘清:类案"检索"与类案"推送"不是一回事
很多招标文件把两者混着写,但落地效果天差地别:
- 类案检索:法官主动输入关键词,系统返回结果列表。本质是一个搜索工具。问题在于——法官得先想到去搜、知道搜什么词,且愿意花时间翻结果。在案多人少的现实下,主动检索的使用率往往很低。
- 类案推送:系统在法官办理本案的流程中,基于本案的案由、争议焦点、关键事实,自动计算并推送最相似的已决案件,法官无需另起检索动作。它嵌在办案系统里,是"找上门"而非"等人来找"。
真正能支撑类案同判的是后者。因为同判的最大障碍从来不是法官不愿参照,而是不知道有相似案、或没有时间去找。一套合格的系统,要把"类案出现在法官眼前"这件事从可选项变成默认项。下面四层架构,正是围绕"推得到、推得准、推得合规"展开。
二、类案推送系统的四层技术架构
从数据到法官界面,一套类案推送系统由下而上分四层,缺一层都推不准:
| 层级 | 承担什么 | 关键能力 |
|---|---|---|
| ① 数据底座层 | 本院历史裁判 + 全国裁判文书 + 法律法规 | 全量、结构化、可溯源、离线可更新 |
| ② 检索召回层 | 把本案与海量已决案件做相似度匹配 | 语义向量召回 + 结构化条件过滤双轨 |
| ③ 相似度排序层 | 把召回的候选按"像不像"精排 | 争议焦点对齐、裁判要点匹配、可解释打分 |
| ④ 法官界面层 | 把类案嵌进办案系统、可一键参照与留痕 | 办案流程嵌入、强制检索留痕、对比视图 |
下面逐层说清每层的难点和该有的样子。
① 数据底座层:本院尺度 + 全国底座,两个都要
类案推送的准确度,先天受限于底座数据的完整度。一个常见误区是只用本院数据——结果是本院判得少的案由直接"无类可推"。正确做法是两部分融合:
- 本院 / 本辖区历史数据:体现本地裁判尺度,支撑"同院同判""同辖区同判"。这是法院最权威、最该优先参照的部分。
- 全国裁判文书 + 法规底座:补齐本院数据稀疏的案由,提供上级法院、兄弟法院的参照样本,避免"本院从没判过这类案就两手一摊"。
底座还要满足三个工程要求:结构化(案号、法院、审级、案由、当事人、裁判结果等字段齐全,才能做过滤)、可溯源(每条都能回到来源文书,法官敢引用)、离线可更新(以加密增量包导入内网,既保持时效又不在内网常开外网口子)。文书查提供的全国全量裁判文书与法规数据,正是按这三条交付,可与本院数据融合成统一检索底座。
② 检索召回层:语义向量,不是关键词匹配
这一层决定了系统是"能用"还是"摆设"。如果只做关键词匹配,问题立刻暴露:同一个法律问题,在不同文书里表述可能完全不同——"未及时支付货款"和"逾期履行付款义务"指向同一争议,但字面不重合,关键词检索会漏掉。而类案的本质是争议焦点和裁判要点相似,不是用词相同。
准确的召回要走双轨:
- 语义向量召回:把案件事实与争议焦点用模型编码成向量,按语义相似度排序,捕捉"说法不同、问题相同"的类案。
- 结构化条件过滤:在语义召回的基础上,用案由、审级、法院层级、裁判时间等硬条件过滤——比如优先推本省、近三年、同审级的案子,把"语义像但参照价值低"的剔除掉。
语义 + 结构化双轨,既保证不漏(召回率),又保证推上来的有参照价值(精准率)。单靠任何一轨都不够。
③ 相似度排序层:像不像,要能说清楚
召回回来的可能有几十上百条,法官没空逐条看。排序层负责精排,把最像的几条顶上来。关键不只是排得准,还要可解释:系统要能告诉法官"这条为什么和本案像"——是争议焦点一致、还是关键事实重合、还是法律适用相同。一个只给相似度分数、说不清理由的系统,法官不会信、也不敢用。可解释的相似度,是司法场景区别于普通推荐系统的硬要求。
④ 法官界面层:嵌进办案流程,顺手才会用
再好的模型,如果要法官切换到另一个系统、重新登录、手动检索,使用率就会归零。界面层的核心是无缝嵌入现有办案系统:法官在写文书、拟裁判时,类案就在侧边自动呈现,可一键展开对比、一键引用。同时,对于最高法院要求强制检索的案件类型,系统要自动记录检索与参照情况,生成类案检索报告,实现"检索过程可留痕、可监督"。这一层做不好,前三层全白费。
三、强制类案检索:推送系统也是合规工具
2020 年最高人民法院《关于统一法律适用加强类案检索的指导意见(试行)》明确了应当进行类案检索的情形(如拟提交专业法官会议、审委会讨论的,缺乏明确裁判规则的等)。这意味着类案检索在特定案件里是强制动作,而非可选。一套好的类案推送系统,顺势把合规这件事自动化了:
| 合规要求 | 系统如何承接 |
|---|---|
| 应检索情形不遗漏 | 按案件类型自动识别是否属强制检索情形,主动提示并推送 |
| 检索过程可留痕 | 自动记录检索条件、命中类案、法官参照情况,一键生成检索报告 |
| 类案参照可监督 | 审管办、院庭长可回溯检索与参照记录,纳入审判管理 |
换句话说,类案推送系统对法官是"减负"(不用自己想着去搜),对审判管理是"留痕"(过程可监督)。这两个价值叠加,才是法院愿意投入建设的真正理由。
四、为什么必须本地化部署
类案推送要在法官办本案的当下推送,就必须读到在办案件的事实与争议焦点——而这些是高度敏感的未公开信息,夹杂当事人个人信息,绝不能流向外网。因此系统必须与办案系统在同一内网环境本地化部署:
- 数据不出域:数据底座、向量索引、检索模型、推送服务全部部署在院内或政法内网,在办案件信息物理上不离开法院可控边界。
- 满足等保三级与信创:司法系统普遍要求等保三级、信创适配,本地化部署是天然合规形态,可写入建设方案与评审材料。
- 与办案系统打通:本地部署才能与现有审判系统做数据与界面级集成,实现"推送嵌入流程"。
这也是类案推送系统与一般商用法律检索 SaaS 的根本差别:后者数据在厂商云上,既进不了法院内网读在办案件,也过不了数据安全这一关。司法数据中台的建设逻辑同理——底层都是"数据不出域 + 内网智能"。
五、法院信息处选型采购清单
把类案推送系统纳入智慧法院建设或单独采购时,这 9 条可以直接照着问供应商,基本能筛掉只做关键词检索、过不了数据安全的方案:
- 召回是关键词还是语义向量?——要求演示"说法不同、问题相同"的类案能否推出来。
- 数据底座有多大、覆盖哪些案由、来源是否可溯源?——本院数据 + 全国底座如何融合。
- 能否与本院现有办案系统嵌入式集成?——而非另开一个独立检索系统。
- 相似度结果是否可解释?——能否说清"为什么像"。
- 是否支持强制检索情形自动识别 + 检索报告自动生成?
- 是否全程本地化部署、数据不出域?——明确无外网调用。
- 是否满足等保三级与信创适配?——能否提供合规材料。
- 底座如何离线更新?——增量包导入机制与更新频率。
- 审管办能否回溯监督检索与参照记录?——审判管理对接能力。
九条逐条要演示、要实测,别只看 PPT。尤其第 1、4、6 条,是区分"能用的系统"和"摆设"的分水岭。
六、常见问题
Q:类案推送系统和案件智能审判辅助、文书生成是一回事吗?
A:不是,但同属一个智慧法院技术栈。类案推送解决"参照什么";审判辅助、量刑参考解决"怎么判";文书辅助生成解决"怎么写"。它们共用同一套数据底座与院内 AI 能力,通常一并规划、分模块建设。
Q:本院判例太少的案由,推送还有用吗?
A:正是全国底座存在的意义。本院没判过或判得少的案由,系统从全国裁判文书底座里召回上级法院、兄弟法院的参照样本,避免"无类可推"。本院数据保证同院同判,全国底座保证类案不漏。
Q:建设周期和投入大概什么量级?
A:取决于底座规模、与现有办案系统的集成深度、等保信创要求。通常可分期:先打通数据底座与召回排序(核心能力),再做办案系统嵌入与强制检索留痕(合规闭环)。具体方案与预算可结合贵院现状评估,我们可提供参考架构与分期建议。
为贵院类案推送系统提供全国裁判文书底座与参考架构
提供法院层级与重点案由方向,我们反馈数据底座覆盖说明、四层参考架构与分期建设建议,并可安排离线部署演示。演示阶段不收费。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:地方法院信息中心 AI 系统采购清单 · 数字法治政府:司法数据中台建设方案 · 律所 AI 私有化部署完全指南 · 裁判文书 API / MCP 定价