法律 AI 私有化系统一旦上了生产,就不再是「试试看」的工具,而是律师庭前检索、文书生成、法官类案推送的日常依赖。这时候有个问题会突然变得很硬:它宕机了怎么办?私有化部署在内网,没有公有云那种自动故障转移和多可用区兜底,一切冗余都得自己建。更麻烦的是,法律 AI 的高可用比普通系统难——推理要靠昂贵且稀缺的 GPU,检索要靠向量库和全量文书,数据本身还不能丢,这三件事得同时活着,少一件都不算真可用。很多单位把它当普通 Web 系统做高可用,多开几个副本就以为万事大吉,结果 GPU 一挂全线瘫痪,或者检索库坏了 AI 还在一本正经地编。本文讲清楚:RTO/RPO 对法律 AI 到底意味什么、按推理层 / 检索层 / 数据层分层怎么做冗余、灾备等级怎么选、常见的单点和坑,以及一份可以直接照用的高可用与灾备自查清单。
一、先想清楚:法律 AI 的高可用,要保的不是一件事
普通信息系统做高可用,大体就是「应用别挂」——多副本、负载均衡、数据库主从,一台出问题流量切到另一台。法律 AI 不一样,它要同时保三件相互独立、又缺一不可的东西都活着,任何一层塌了,系统对用户就是不可用甚至更糟:
| 层 | 靠什么活着 | 它挂了会怎样 |
|---|---|---|
| 推理层 | GPU 集群跑大模型 | 整个 AI 停摆;GPU 又贵又稀缺,往往是最难堆冗余、最容易成单点的一环 |
| 检索层 | 向量库 + 全文索引 + 文书数据 | 最危险的一种故障:AI 不报错、还在答,只是从有据可查退化成凭记忆瞎编 |
| 数据层 | 结构化文书全量库 + 本所卷宗 + 模型权重 | 损坏或丢失不是重启能解决的,严重时要重新灌库甚至无法追溯 |
这张表就是法律 AI 高可用和普通高可用的根本差别。第二层的「静默降级」尤其反直觉:一般系统挂了会 502,用户立刻知道;而检索层坏掉时,大模型照样输出流畅的答案,只是不再基于真实文书——一个还在给答案、但答案不可靠的系统,比一个干脆宕机的系统更危险,因为没人会警觉。所以下面的架构,核心就是把这三层拆开、各自做冗余,而不是笼统地「多开几份应用」。
一句话原则:普通系统的高可用,证明的是「应用还能访问」;法律 AI 的高可用,还要额外证明「就算某一层出了问题,它要么优雅降级、要么明确停下,而绝不会一边坏着、一边继续给出看起来正常其实没有依据的答案」。
二、RTO 与 RPO:法律 AI 该怎么定这两个数
灾备的一切都从两个指标出发:RTO(恢复时间目标,出故障后多久必须恢复)和 RPO(恢复点目标,最多能容忍丢多少数据)。做法律 AI,这两个数不能对整套系统拍一个统一值,而要分开看:
RTO 看「业务离不开它到什么程度」
如果法律 AI 已经嵌进律师庭前准备、法官类案推送这些每天都在跑的关键流程,RTO 可能要压到分钟级;如果它还只是个辅助工具,小时级也能接受。定 RTO 之前,先跟业务方确认「这套系统停多久,业务真的受不了」,别由 IT 单方面拍脑袋定一个既做不到、又没必要的激进数字。
RPO 按「数据变化快慢」分层定
法律 AI 的数据变化速度差别很大,RPO 要跟着分层,而不是一刀切:
| 数据类型 | 变化速度 | RPO 策略 |
|---|---|---|
| 大模型权重 | 基本静态(除非重新微调) | 一次备份长期有效,微调后再备一版即可 |
| 全量文书库 + 向量索引 | 慢(定期增量) | 定期全量备份 + 增量记录,丢了可重灌 |
| 本所新增卷宗 / 增量新文书 | 快(每天写入) | 小 RPO,准实时或高频备份,丢了难补 |
| 用户对话 + 审计日志 | 持续写入 | 小 RPO 且不可丢——审计留痕本身是安全合规要求 |
换句话说:模型和全量库是「相对静态、丢了能重建」,做好定期备份就行;真正要小 RPO、要盯紧的是持续写入的那几类——本所卷宗、增量文书、对话与审计日志,这些丢了要么无法追溯、要么要重新灌一遍库。把 RPO 按数据分层,既省成本又不留死角。
三、分层做冗余:一层一层拆开看
把「保三件事都活着」落到架构上,就是按层各自设计冗余。下面从用户最近的一层往数据层走。
推理层(GPU):最贵的单点,重点在「降级」而非「热备」
GPU 是法律 AI 高可用里最现实的成本约束——给每个节点都热备一张闲置的高端卡,多数单位既买不起也不划算。务实的做法不是追求「一比一热备」,而是让 GPU 冗余变成共享的、能降级的:
- 多副本 + 负载均衡:平时多张卡分担流量,挂一张时其余顶上,表现是并发下降而非服务中断——冗余是「共享」的,不是「闲置」的。
- 优雅降级:单卡还活着时,自动降并发、排队、或切到更小的模型保住基本可用,总比直接 502 强。
- 大小模型并存兜底:最贵的全量高精度模型旁边,常驻一个轻量兜底模型,极端情况下用小模型维持检索问答不断线。
- 备件与一键拉起:GPU 坏了能在 RTO 内换上,推理服务镜像能一键重新部署,而不是现攒环境。
核心是回答一个问题:一张卡挂掉时,业务是彻底停、还是降速运行?好的设计让它是后者。
检索层:别让它「静默失败」
检索层(向量库 + 全文索引)最怕的不是宕机,而是检索悄悄失效却没人发现。三个动作:一是向量库和索引做副本与定期快照,单节点故障能切换;二是把检索健康做成硬性前置检查——检索层不可用或召回明显异常时,宁可让 AI 明确提示「检索暂不可用」,也不能让它跳过检索直接凭模型记忆作答;三是索引可从原始文书一键重建,这样即使向量库整个损坏,数据层的文书还在,重建即可恢复,不至于伤筋动骨。
数据层:高可用的最后一道底线
数据层塌了,前面两层做得再好也白搭。这一层的重点是「不丢 + 可恢复」:全量文书库和本所卷宗做多副本存储与异地备份;备份要覆盖三样东西——文书数据、向量索引、模型权重,缺一样恢复时都会卡住;最关键的一点是定期做恢复演练——备份没演练过,等于没有备份,很多单位是真出事那天才发现备份根本恢复不出来。数据层的稳固,直接决定了整套灾备是「纸面方案」还是「真能用」。
四、灾备等级怎么选:不是越高越好
灾备是分等级的,按业务重要性和预算选。硬套「双活」既烧钱又未必需要,选错等级比不选还糟。四档从低到高:
| 等级 | 做法 | 大致 RTO | 适合谁 |
|---|---|---|---|
| 备份可恢复(底线) | 数据 + 系统镜像定期备份、异地存一份、并真做过恢复演练 | 天级 | 再省也不能省,所有单位的下限 |
| 冷备 | 另有一套可拉起环境,平时不跑,灾难时手动切换 | 小时~天级 | 预算有限、可容忍较长恢复的大所 |
| 热备 / 温备 | 备用环境常态运行、数据准实时同步,故障快速切换 | 分钟级 | 政法生产系统、业务连续性要求高的场景 |
| 双活 | 两套同时对外服务、互为备份 | 分钟内 / 近乎无感 | 核心政法系统 + 预算充足,成本最高 |
给多数大所的实话:做到扎实的「备份可恢复 + 关键数据异地 + 演练过」,就已经甩开绝大多数只有一堆没验证过的备份的单位。对政法生产系统、尤其定了较高等保和业务连续性要求的,才有必要往热备甚至双活走。选型时务必把 RTO/RPO、预算、和这张表摆在一起谈,别一上来就默认最高档。
五、常见的单点与坑
下面这些是私有化法律 AI 灾备最容易踩的坑,提前避开能少走很多弯路:
| 常见坑 | 为什么危险 / 怎么避 |
|---|---|
| 只堆了推理冗余,检索是单点 | GPU 做了多副本,向量库却只有一份,检索一挂 AI 就开始编;检索层要同等做冗余 + 健康前置检查 |
| 备份只备了数据,没备索引和模型 | 恢复时发现文书在、索引和权重没了,还是跑不起来;三样都要备 |
| 备份从没演练过恢复 | 真出事才发现备份损坏 / 恢复流程走不通;把恢复演练做成定期动作,写进运维日历 |
| RTO/RPO 由 IT 单方拍定 | 要么定太松业务受不了、要么定太严做不到还烧钱;必须和业务方一起定 |
| 检索静默降级没有告警 | AI 还在答但已无依据,没人发现;把检索健康、召回质量接进监控告警 |
| 灾备只在纸上,切换没预案 | 方案漂亮但真故障时手忙脚乱;要有成文的切换手册 + 明确责任人 + 定期演练 |
六、给运维负责人的一页纸高可用与灾备自查清单
系统上生产、或做灾备评审前,把这份清单逐条过一遍:
- 分层:推理层、检索层、数据层是否各自都有冗余方案?还是只做了应用多副本?
- GPU:一张卡挂掉时,业务是彻底停还是降速运行?有没有优雅降级和兜底小模型?
- 检索:检索层不可用或召回异常时,AI 会明确提示、还是静默凭记忆作答?有没有健康前置检查?
- 备份:文书数据、向量索引、模型权重三样是否都备了?有没有异地一份?
- 演练:最近一次真做过恢复演练是什么时候?恢复出来能正常跑吗?
- RTO/RPO:是否和业务方一起定的?对持续写入的数据(卷宗 / 日志)是否单独定了小 RPO?
- 等级:灾备等级和业务重要性、预算是否匹配?有没有硬套过高或过低的档?
- 预案:故障切换有没有成文手册、明确责任人?告警是否覆盖检索静默降级?
- 供应商:高可用架构设计、备份恢复方案、灾备演练支持,合同里写了没、供应商拿得出吗?
把这九项做成上生产前的固定动作,法律 AI 就从「跑起来就行、出事再说」变成「三层都有冗余、备份演练过、故障有预案」。高可用不是买一堆硬件堆出来的,而是想清楚每一层塌了会发生什么、并为每一种塌法准备好答案。
七、常见问题
Q:法律 AI 的高可用,和普通信息系统到底差在哪?
A:普通系统高可用主要保「应用能访问」;法律 AI 要同时保推理(GPU)、检索(向量库 + 文书)、数据(全量库 + 卷宗 + 模型权重)三层都活着。尤其检索层挂掉时 AI 不报错还在答、只是没了依据,这种静默降级比整机宕机更危险,是普通架构里不常遇到的问题。所以要分层各自做冗余,而不是简单地多开副本。
Q:RTO 和 RPO 该定多少?
A:别对整套系统拍一个统一值。RTO 看业务离不开它到什么程度——嵌进关键流程就压到分钟级,辅助工具小时级可接受;RPO 按数据变化速度分层——模型和全量库相对静态、定期备份即可,本所新增卷宗、增量文书、对话与审计日志变化快且难补,要单独定小 RPO。定之前先和业务方确认「停多久、丢多少真的受不了」。
Q:一定要建双活、两个机房吗?
A:不一定。灾备分四档:备份可恢复(底线,再省不能省)、冷备、热备/温备、双活。多数大所做到「备份可恢复 + 关键数据异地 + 演练过」就够;政法生产系统、定了较高等保和业务连续性要求的,才需要往热备甚至双活走。把 RTO/RPO、预算和业务重要性放一起选,别默认最高档。
私有化部署,高可用与灾备一起交付
文书查提供 1.5 亿+ 结构化裁判文书私有化部署,交付时一并给到分层高可用架构设计、推理/检索/数据三层冗余方案、备份与恢复演练支持,以及故障切换预案。数据不出内网,系统不轻易宕机。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情 · API/MCP 定价
相关阅读:私有化法律 AI 运维监控告警 · 数据安全审计与等保测评 · 私有化三年 TCO 测算 · 上线后持续运营与数据回流 · 法律 AI 供应商尽职调查 · 律所 AI 私有化部署指南