「我们想把裁判文书库放进自己机房」——这句话背后,不是「拷一份数据过来」那么简单。1.5 亿+ 篇判决,落到本地要解决的是一整套数据工程问题:这么多文书怎么存、怎么查得快、怎么做语义类案、怎么持续更新、怎么管权限、怎么喂给法律大模型。任何一环没设计好,要么查不动,要么数据很快过期,要么过不了合规这一关。本文按一套可落地的分层架构,把 1.5 亿条规模裁判文书私有库的本地化部署讲清楚,并给资源测算与部署清单,供律所 IT、法院信息处和法律科技团队选型与自评时参考。
先问:为什么非要把数据搬进自己机房
调用一个公网 API 显然更省事。会走私有化这条路的,通常是因为业务本身碰了不能让数据出域的红线:律所承接涉密案件、政府国企客户、跨境业务,委托协议要求数据不得交第三方处理;法院、检察院、司法局的数据中台,等保三级 + 信创 + 数据不出域是硬约束。这些场景下,「数据和检索全程留在自己机房」不是性能优化,而是合规前提(展开见 私有化如何满足客户保密义务)。
但一旦决定自建,就要正视:你买的不是一个文件,而是要在内网长期运行一套数据系统。下面六层,是这套系统缺一不可的骨架。
裁判文书私有库的六层架构
| 层 | 职责 | 关键技术 / 决策点 |
|---|---|---|
| 1 存储层 | 原文 + 结构化字段 + 元数据落盘 | 对象存储/分布式文件系统存原文,关系库或列存存结构化字段;NVMe SSD;按案由/年份分区 |
| 2 结构化层 | 把原文抽成稳定字段 | 案号/法院/审级/案由/当事人/裁判日期/裁判结果/法条引用;统一 schema |
| 3 索引层 | 让 1.5 亿条秒级可查 | 全文倒排索引(ES/OpenSearch)+ 向量索引(切块 embedding);两套并行 |
| 4 检索服务层 | 混合召回 + 排序 + 字段过滤 | 向量召回 → 全文/结构化过滤 → 重排;对外统一检索 API |
| 5 更新同步层 | 持续把新文书增量入库 | 离线增量包导入;索引增量重建;断网/离线介质交付 |
| 6 权限与审计层 | 访问控制 + 全程留痕 | RBAC + 利益冲突隔离;检索/调阅/导出审计日志不可篡改 |
很多团队只想到第 1、3 层(「存起来 + 能搜」),结果上线后发现:没有第 2 层就做不了按案由/地域/年份的过滤统计,没有第 5 层数据三个月就过期,没有第 6 层合规汇报过不了。下面逐层拆。
第 1-2 层:存储与结构化——数据的地基
1.5 亿+ 篇判决,原文是非结构化长文本,但律师真正能用起来,靠的是抽在上面的结构化字段。一篇判决至少要稳定抽出:案号、审理法院、审级、案由、当事人、裁判日期、裁判结果、引用法条。这些字段是后面一切检索、过滤、统计、类案的前提。
存储上的两条经验:一是原文与字段分开存——原文走对象存储/分布式文件系统,结构化字段走关系库或列式存储,各自优化;二是按案由 + 年份分区,既方便只导入律所实际需要的范围(没必要一上来就全量 1.5 亿),也让检索时能先按分区裁剪、大幅提速。
结构化质量决定一切上层效果。同样号称「1.5 亿条」,有的是抽好稳定字段、去重归一的全量库,有的是一坨纯文本。后者连「近三年北京地区劳动争议判决」这种基础过滤都做不了。选型时务必让数据方现场展示一次按案由+地域+年份的分布——拿不出分布的,字段层基本是空的。
第 3-4 层:全文检索 + 向量检索——查得准的关键
这是私有库最容易做错的地方:以为上一个全文搜索引擎就够了。实际上律师有两类完全不同的查询。
| 查询类型 | 例子 | 该用什么 |
|---|---|---|
| 精确命中 | 查某个案号、某法院某年某案由、含特定法条的判决 | 全文检索(BM25 倒排)+ 结构化字段过滤 |
| 语义类案 | 「我有一段案情,找判得相似的已决案件」 | 向量检索(语义召回) |
结论是必须混合检索:生产环境的典型链路是——先用向量召回一批语义相近的候选,再用全文检索和结构化字段(案由/地域/年份/审级)做过滤与重排,最后输出。只上全文,做不了「凭案情找类案」;只上向量,查特定案件、特定法条会不准。两者互补,缺一不可(类案推送的工程细节见 法院类案推送系统怎么建)。
规模上要有心理准备:十亿级的向量片段(1.5 亿篇按段切块,轻松到十亿量级)对内存和检索引擎是真考验。向量库要选支持分片、量化压缩、横向扩展的;全文索引节点和向量召回节点建议分开扩容,按数据量加机器,而不是堆单机。
第 5 层:离线增量更新——别让数据停在采购那一天
裁判文书每天在新增,法规在更新。私有库最大的隐患不是建不起来,而是建好之后没人喂新数据,半年就过期。私有化部署不能像 SaaS 那样自动联网更新,所以更新机制必须在架构里提前设计:
- 增量而非全量:正规数据方按周期(周/月)提供增量包,只含上次之后新增和修订的文书,你导入后做索引增量重建,成本是全量重导的零头。
- 离线可交付:对不允许常开外网的等保机房,增量包支持离线介质交付,内网按自己节奏导入。
- 合同写清:更新频率、增量交付方式、离线导入流程,必须写进采购合同——只交付一次性快照、之后不管更新的,等于买了个会过期的库。
第 6 层:权限与审计——合规的底线
对律所和司法机关,这一层不是加分项,是不做就过不了合规。
- 权限(RBAC + 利益冲突隔离):按角色、部门、案件控制访问;同所承接对立案件的团队,检索记录互不可见,守住利益冲突隔离墙。
- 审计(全程不可篡改留痕):每一次检索、调阅、导出都记录——谁、何时、查了什么、导出了什么,日志不可篡改、可追溯。
这两项直接对应律师执业保密义务,以及《数据安全法》《个人信息保护法》对数据处理活动可追溯的要求。私有化的价值正在于此:这些日志全部留在自己机房,不经任何第三方。
从架构到模型:RAG 怎么对接
私有库不是终点,真正让律师省力的是它驱动的法律大模型。标准链路是检索增强生成(RAG):
- 用户用自然语言提问(一段案情 / 一个法律问题);
- 检索服务从私有库混合召回最相关的判决片段(向量召回 + 全文/字段过滤);
- 把召回的原文片段连同案号、法院、可点开的链接,作为上下文喂给本地部署的法律大模型;
- 模型基于真实文书生成回答,并附上每条结论的原始文书出处。
这样做的意义是:让模型的回答锚定在真实、可溯源的判决上,而不是凭空编法条和案例。要记住一句话——检索质量决定 RAG 的上限。召回不准,再强的模型也会答偏。所以前面第 2、3、4 层(结构化 + 混合检索)不是可选项,而是模型效果的地基。
资源测算:1.5 亿条大概要多少机器
具体规模强依赖你实际导入的案由/年份范围,下面是按全量 1.5 亿+ 给的量级参考(不是精确报价,选型时按真实范围测算):
| 资源 | 量级参考 | 说明 |
|---|---|---|
| 原文存储 | 约 1-3 TB | 结构化纯文本,去重压缩后;含元数据 |
| 全文索引 | 原文的 0.3-1 倍 | 倒排索引,视字段与分词策略 |
| 向量索引 | 数 TB 量级 | 十亿级切块向量,视维度与量化方案 |
| 磁盘 | NVMe SSD 8-16 TB 起 | 含索引、副本与增量缓冲,预留扩展 |
| 检索内存 | 单机 128-256 GB 起 | 向量召回吃内存,按数据量横向扩 |
| 模型 GPU | 另算,与数据节点分开 | 本地法律大模型推理,见 GPU 选型文 |
一条务实建议:不要一上来就全量 1.5 亿。先按律所主营业务的案由 + 近若干年范围导入一个子集,把链路跑通、效果验收,再按需扩量。这样首次投入低、见效快,也好评估数据质量。GPU 与算力规划见 律所内网大模型部署:GPU 选型实战,投入产出测算见 律所 AI 投资回报测算。
部署自评清单
上裁判文书私有库前,用这 8 条对照需求与候选方案:
- 数据范围:支持按案由/地域/年份选择性导入吗?还是只能全量?
- 结构化:能否现场展示按案由+地域+年份的真实分布?字段是否稳定齐全?
- 检索:是否同时提供全文 + 向量混合检索?能否凭一段案情找类案?
- 溯源:每条结果能否回链到原始文书?
- 更新:增量更新频率?离线/断网环境怎么导入?是否额外收费?
- 权限审计:支持 RBAC + 利益冲突隔离吗?检索/导出是否全程留痕、不可篡改?
- 模型对接:是否提供检索 API / 现成 RAG 链路对接本地大模型?
- 资源:给出明确的存储/内存/GPU 资源清单和扩容方案了吗?
常见问题
Q:1.5 亿条裁判文书私有库大概要多少存储和算力?
A:量级上,1.5 亿+ 篇原文去重压缩后约 1-3TB;全文索引再占原文 0.3-1 倍;向量索引视切块与维度通常是几个 TB。硬件建议 NVMe SSD 8-16TB 起、检索节点单机 128-256GB 内存起步并横向扩,模型 GPU 与数据节点分开。务必按实际导入范围测算,不必一上来就全量。
Q:全文检索和向量检索,私有库到底用哪个?
A:两个都要、且要混合。全文检索擅长精确命中(案号/法院/法条/关键词),向量检索擅长语义类案(凭案情找相似判决)。生产环境先向量召回、再全文+字段过滤重排。只上一个,要么查不准特定案件,要么做不了类案语义匹配。
Q:私有化部署后,新的裁判文书怎么更新进库?
A:靠离线增量同步,不重导全量。数据方按周期提供只含新增/修订的增量包,内网按自己节奏导入、索引增量重建;等保机房可离线介质交付。更新频率与离线导入流程要写进合同,避免数据停在采购那天。
把这套架构,落到你的机房
文书查提供全量裁判文书 + 法规的私有化数据底座,支持选择性导入、混合检索、离线增量更新与本地大模型 RAG 对接。给出你的业务范围与机房条件,我们出一版数据架构与资源测算,并安排 demo。演示阶段不收费。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:律所 AI 私有化部署完全指南 · 内网大模型 GPU 选型实战 · 法院类案推送系统怎么建 · 私有化如何满足客户保密义务 · 裁判文书 API / MCP 定价