很多律所和政法机关以为,私有化法律 AI 最难的是上线那一天——把模型和 1.5 亿裁判文书私有库灌进内网、跑通 RAG 检索、验收通过。可真正的考验从上线之后才开始:这是一套跑在你自己机房、离线、没有厂商云端替你 7×24 盯着的系统,接下来三年,它活得好不好,只能靠你自己的监控和告警看得见。更麻烦的是,法律 AI 有个别的系统没有的隐患——就算进程一直活着、接口一直返回 200,它的回答质量也可能在你毫不知情的情况下悄悄变差。本文给出一套可以直接照着搭的私有化法律 AI 运维监控体系:四层监控指标、告警怎么分级降噪、离线环境特有的坑,以及一份运维负责人可以贴在墙上的巡检清单。
一、为什么私有化上线后,监控比 SaaS 更重要
用 SaaS 法律工具时,系统在厂商的云上,厂商有一整支 SRE 团队 7×24 盯着可用性,出了问题厂商比你先知道、先修。私有化部署把这份便利换成了数据不出内网的安全,但也把运维责任完整地搬到了你这边:系统在你的机房、你的 GPU 上、通常还是离线的,没有外部兜底,没有厂商替你半夜爬起来。上线验收那天一切完美,不代表三个月后还完美——GPU 会老化、显存会泄漏、数据回流管道会断、模型对新出现的问题会答非所问。
这里有一个反直觉但极其关键的点:法律 AI 的『健康』有两层,而大多数运维只盯了第一层。第一层是『系统活着』——进程在、接口通、时延正常,这是传统运维的全部;第二层是『答得对』——检索召回够不够全、引证回不回得去、有没有开始编造。第二层在 CPU、内存、QPS 曲线上完全看不出来,一套只监控基础设施的运维体系,会在律师已经开始抱怨『AI 最近答得不靠谱』时,仪表盘上还是一片绿。私有化法律 AI 的运维,本质是要把这两层都看住。
一句话原则:普通系统的运维目标是『别宕机』;法律 AI 的运维目标是『别宕机,而且别在没人发现的情况下答错』。后半句,才是法律 AI 运维真正的难点。
二、四层监控指标:从『系统活着』到『答得对、用得安全』
建议把私有化法律 AI 的监控指标分成四层来搭,从下到上依次是基础设施、模型服务、检索质量、业务与安全。前两层保证系统活着,后两层保证它答得对、用得安全:
| 监控层 | 关键指标 | 盯它是为了发现什么 |
|---|---|---|
| ① 基础设施层 | GPU 利用率/显存占用、CPU/内存/磁盘、机房温度与电力、网络内联通 | 硬件本身的问题——私有化最容易忽略『机器和机房也要监控』 |
| ② 模型服务层 | 推理接口成功率/错误码、P95/P99 时延、并发排队与超时、显存 OOM 次数、许可证/证书有效期 | 推理服务的可用性与性能:慢、超时、崩、证书过期 |
| ③ 检索质量层 | 空检索比例、引证回链有效率、无答案时是否老实说没有、向量索引与数据版本是否同步 | 最容易漏的一层——系统正常但『答得越来越差』 |
| ④ 业务与安全层 | 各业务线调用量/活跃用户、按 matter/团队的权限越界尝试、审计日志完整性、异常导出行为 | 用得对不对、安不安全——政法与大所的合规红线 |
四层里,第①②层是所有系统运维的常规操作,不再展开;真正拉开差距、也最容易被跳过的,是第③层检索质量和第④层业务与安全。下面重点讲这两层,以及离线环境特有的坑。
三、检索质量监控:法律 AI 运维最大的盲区
这是私有化法律 AI 运维里最反常识、也最重要的一环。一套 检索增强的法律 AI,它的回答质量取决于『检索到的对不对』,而检索会因为很多原因悄悄退化:数据版本更新后向量索引没重建、新增文书没进库、切分或脱敏规则改动引入偏差、甚至只是查询分布变了。这些退化不会让系统报错,只会让答案越来越水,而离线环境又没有海量用户帮你自然暴露问题。抓手有三个:
- 建一套固定的回归评测集,定期自动跑。挑几十到上百条本单位高频真实问题,配上人工确认的标准答案,做成回归集,每天或每周自动跑一遍,监控回答准确率、检索命中率、引证有效率。任何一个指标掉出阈值就告警——这是把『答得对不对』从主观感受变成可量化、可告警的数字的唯一办法。(评测集怎么建,见 法律大模型验收测评方法,验收用的那套集子正好复用为上线后的回归集。)
- 盯两个『泄漏指标』:空检索比例、无引证回答比例。『查了但什么都没召回』和『答了但给不出引证来源』这两个数字一旦上升,几乎总是意味着数据版本没跟上或索引出了问题。它们是检索退化最灵敏的先行指标,比等律师投诉早得多。
- 保留并汇总用户负反馈。在产品里放『点踩/这个答案不对』的入口,把负反馈按业务线、按问题类型汇总进周报。用户的纠错是最真实的质量信号,但不能只靠它——它是滞后的,评测集才是提前量。
核心一句话:不能等律师投诉才发现 AI 退化了。要用回归评测集和泄漏指标,在质量真正影响到办案之前,把退化提前量化、提前告警。这也正是幻觉与引证核验从『上线前测一次』升级成『上线后持续监控』的落地方式。
四、业务与安全层:政法与大所不能松的合规监控
法律 AI 处理的是当事人隐私、案件卷宗、客户机密,私有化的初衷本就是数据安全与保密,所以运维监控必须把安全和合规审计当成一等公民,而不是事后补的日志。重点盯四类信号:
| 监控项 | 为什么要盯 |
|---|---|
| 权限越界尝试 | 按 matter/团队/人做的检索层隔离(A 客户材料不能在办 B 客户时被召回)一旦出现越界访问,是利益冲突墙被击穿的信号 |
| 审计日志完整性 | 谁在什么时候查了什么、AI 答了什么,必须完整留痕且不可篡改;日志本身断了要立刻告警 |
| 异常导出/批量拉取 | 短时间大批量导出、非常规时段的高频调用,可能是数据外带的前兆 |
| 各业务线活跃度 | 调用量骤降往往说明某条业务线『买了没人用』,是 adoption 运营要介入的信号,不完全是故障 |
对政法机关,这一层还要对齐等保三级与数据中台的合规要求;对大所,它是客户保密义务在系统层面的落地。这层监控的价值,在平时看不出来,在出事或被审计那一刻决定你是否说得清楚。
五、离线环境特有的三个坑
私有化、离线,带来几个云端系统根本不会遇到的运维问题,提前知道能少踩很多:
- 数据回流管道断了,没人第一时间知道。私有库要靠定期把新增裁判文书、法规同步进内网来保持新鲜。这条数据回流管道一旦断(介质没更新、同步任务失败),系统不会报错,只会答得越来越『过时』。必须监控『最新数据版本日期』这个指标——超过 N 天没更新就告警。
- 模型/许可证/证书悄悄到期。离线环境里,授权文件、TLS 证书、软件许可证到期不会有云端自动续期,到点直接罢工。把所有有效期做成『剩余天数』指标,提前 30 天进日报、提前 7 天告警。
- GPU 显存泄漏与硬件老化。长期运行的推理服务可能缓慢泄漏显存,直到某天 OOM 崩溃;GPU 也会随高温高负载老化。显存占用的长期趋势、OOM 次数、GPU 温度,都要留趋势曲线,把『缓慢恶化』在崩之前抓出来。
这三个坑的共同点是:都是『静默恶化』,不会主动报错,只会在某天突然爆发或悄悄变差。对付静默恶化,唯一的办法是给它们各配一个趋势指标 + 提前量告警,而不是等它爆。
六、告警怎么设,才不会变成没人看的『狼来了』
指标建得再全,如果告警设计得差,结果就是告警刷屏、大家麻木、真出事反而被淹没。好的告警遵循三条原则:
| 原则 | 怎么做 |
|---|---|
| 分级 | P1 全所不可用(推理全挂/GPU 宕机)→ 立刻电话短信找到人;P2 局部降级(单业务线变慢/单卡故障)→ 工作时间响应;P3 趋势预警(显存缓慢泄漏/许可证 30 天到期)→ 进日报不打扰 |
| 降噪 | 同一故障持续期间只报一次不刷屏;能自愈的短暂抖动(一次重试成功)静默不报;给足阈值与持续时间窗口,避免瞬时毛刺误报 |
| 可执行 | 每条告警写清『哪台机、什么指标、超了什么阈值、先查什么』,而不是甩一句『系统异常』让人干瞪眼 |
一套设计良好的告警系统,应该是平时安静,一响就是真事,而且一看就知道去哪查。判断告警设计好不好,有个简单标准:如果运维同事已经开始习惯性忽略告警群,那你的告警不是太少,而是噪声太多、该降噪了。
七、给运维负责人的一页纸巡检清单
把这份清单固化成每日/每周巡检项,大部分故障能在影响办案之前被发现:
- 系统活着:推理接口成功率、P95 时延、GPU 显存与温度,是否都在阈值内?
- 答得对:回归评测集今天/本周跑分是否达标?空检索比例、无引证比例有没有异常上升?
- 数据新鲜:私有库最新数据版本日期距今几天?回流同步任务上一次成功是什么时候?
- 期限:许可证、证书、授权文件的剩余天数,有没有进入 30 天预警区?
- 安全:有没有权限越界尝试、异常批量导出?审计日志是否完整无缺口?
- 业务:各业务线调用量与活跃用户环比,有没有某条线骤降(可能是没人用而非故障)?
- 告警复盘:过去一周的告警,有没有反复误报的该调阈值、有没有被忽略的该降级?
- 容量:磁盘、显存、并发余量,按当前增长还能撑多久?
把这八项做成看板 + 日报,私有化法律 AI 的运维就从『出事了才救火』变成『趋势里提前拦截』。私有化系统没有厂商替你半夜爬起来,但一套好的监控告警,等于给你请了一个不休息的运维值班员。
八、常见问题
Q:我们信息化团队不大,搭这么一套监控是不是太重?
A:不必一步到位。优先级很清楚:先把第①②层(基础设施 + 模型服务可用性)用现成的开源监控搭起来,这部分和普通系统运维通用;再把第③层检索质量的『回归评测集 + 空检索/无引证比例』两个抓手加上,这一层投入最小、收益最大;第④层安全审计按合规要求逐步补齐。关键是别只做第①②层就以为够了——那正好漏掉了法律 AI 最独特的风险。
Q:回归评测集要多大、多久跑一次?
A:不追求规模,追求代表性。几十到一两百条覆盖本单位高频业务、且有人工确认标准答案的问题就够用,关键是稳定复用——每次数据更新、模型调整、索引重建后都跑一遍,对比历史跑分。频率上日跑最好,至少每周一次,数据版本一变必跑。它的价值不在大,在于把『质量退化』变成一条能报警的曲线。
Q:这套运维是供应商负责还是我方负责?
A:私有化的现实是运维责任在你方,但成熟供应商应当在交付时把监控看板、告警规则、回归评测集一并交付并培训,而不是丢个系统就走。签约时就把『运维监控与告警体系的交付、SLA 响应时效、远程/驻场支持方式』写进合同(参见供应商尽职调查),避免上线后运维无人接手。
私有化部署,连监控看板一起交付
文书查提供 1.5 亿+ 结构化裁判文书私有化部署,交付时一并给到四层监控看板、分级告警规则与回归评测集,并培训你的运维团队。数据不出内网,系统上线后答得对、盯得住。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情 · API/MCP 定价
相关阅读:法律 AI 上线只是开始:数据回流与持续运营 · 法律大模型验收测评方法 · 法律 AI 幻觉与引证核验 · 律所知识库 RAG 落地 · 司法数据中台等保三级 · 法律 AI 供应商尽职调查