本文只讲一件事:私有化判决库上线之后,新的判决怎么进到那台不联网的机器里。不是首次搬数据——见割接与数据迁移;不是模型换版本——见模型版本管理与升级;不是上线后的整体运营——见持续运营与数据回流;也不是库本身怎么搭——见文书私有库架构。边界很窄:更新从哪条通道进来、一个包里该有什么、进来之后怎么验、验不过怎么退。
一、三个真实的翻车场景
第一种,库停在了交付日。系统上线时数据是新的,验收顺利通过。半年后律师在系统里查不到一个他明明知道存在的近期判决,IT 去追才发现:合同里写了「提供数据服务」,但没写更新频率、没写交付方式、没有人被指定负责这件事。一个不更新的判决库,是一份会自己过期的资产。
第二种,包进来了,没人知道对不对。移动硬盘拿到内网,导入脚本跑完提示成功,于是宣布更新完成。两个月后偶然发现某个月份的数据只进来了一半——传输中断过,而脚本对「文件少了几个」并不敏感。没有校验和对账的导入,等于把数据完整性交给运气。
第三种,更新把检索搞崩,回不去了。为了让新数据可检索,更新时顺手重建了索引,中途失败,旧索引已经被覆盖。业务停摆一整天,因为没有人预先定义过「退回上一版」是什么动作。在断网环境里,回滚能力必须在更新之前就存在。
三者的共同点是同一个认知错位:把语料更新当成一次文件拷贝,而不是一次有版本、有校验、有回滚的发布。
二、为什么离线更新是另一本账
在线系统的数据更新是一个后台任务:定时拉取、失败重试、异常告警,出了问题工程师随时能连上去看。私有化环境把这三件事全拿掉了,于是同一件事的性质变了:
| 维度 | 在线系统 | 私有化离线环境 |
|---|---|---|
| 触发方式 | 定时自动拉取 | 人工按窗口执行,次数有限 |
| 失败处理 | 自动重试,几乎无感 | 重试成本高,一次失败可能等下一个窗口 |
| 校验依据 | 可随时回源比对 | 只能靠包内自带的清单与哈希 |
| 问题定位 | 工程师远程接入 | 需驻场或由甲方 IT 代为操作 |
| 审计要求 | 系统日志即可 | 介质、经手人、时间均需留痕 |
结论很直接:离线更新的可靠性不能依赖执行时的人,只能依赖包本身的自洽性。包必须能自证「我是完整的、我从哪个版本来、我要去哪个版本、我失败了应该退回哪里」。这一点和司法数据平台的安全合规要求是同一个方向:所有动作可追溯、可复核。
三、四种更新通道,先选对再谈频率
通道决定了更新频率的上限,所以它必须在方案阶段就定下来,而不是上线后再商量:
| 通道 | 典型形式 | 可行节奏 | 要注意什么 |
|---|---|---|---|
| 加密移动介质 | 专用加密硬盘寄送或专人交接 | 月度 / 季度 | 介质登记、交接签字、用后销毁或归还 |
| 单向导入设备 | 光闸 / 摆渡区,只进不出 | 周度 / 月度 | 单次容量与格式限制,大包需分卷 |
| 白名单专线 | 受控网络到指定地址的定向通道 | 可到日度 | 需网络与安全部门审批,变更成本高 |
| 驻场导入 | 工程师到场执行 | 按次 | 成本最高,适合重大版本与重建 |
一个常见的误判是:采购时按最理想的通道谈频率,落地时才发现安全部门只批了移动介质,于是「每周更新」自动降级为「有空再说」。先确认通道的审批可行性,再写更新频率,这条顺序反过来的项目,后面的更新条款基本都是空的。参见招标技术需求书怎么写与供应商尽职调查。
四、一个合格的增量包长什么样
把「一堆数据文件」变成「一次可发布、可回滚的更新」,差别就在包结构。可复用的最小结构如下:
manifest.json # 基线版本 → 目标版本、生成时间、覆盖区间、三类条数
data/added/ # 新增文书
data/modified/ # 修订文书(含变更原因)
data/removed.list # 撤下清单(只给标识,不给正文)
schema-changes.md # 字段与口径变更说明,无变更也要显式写「无」
checksums.txt # 逐文件哈希
package.sig # 整包签名
ROLLBACK.md # 失败时退回哪个基线、怎么退
其中三处最容易被省掉,而它们恰恰是出事时唯一能救人的东西:
- manifest 里的版本对。写清「从 A 到 B」而不只是「这是第三季度的包」。有了版本对,包就不能被乱序导入——这是内网环境里非常现实的风险,因为包可能积压几个月才一起处理。
- 三类变更分开放。新增、修订、撤下混在一个目录里,导入逻辑就只能猜;分开之后,每一类对应一个明确动作,失败时也能按类重试。
- 字段变更说明必须显式存在。哪怕本次没有任何字段调整,也要写一行「无变更」。一旦允许缺省,某次真的改了口径时,没有人会发现——这类问题的表现是「统计数字突然变了但查不出原因」,排查成本极高。见数据分类分级。
五、三件最容易漏的事
1. 撤下与更正:更新不只是追加
裁判文书上网之后并非永久静止:可能因程序性事由被更正或补正,也可能因为符合不公开的情形而不再对外呈现。因此增量更新必须同时支持修订与撤下,而不能只做追加。只追加的系统会长期保留已经不该继续呈现的内容,对律所和政法单位来说这是合规问题,不只是数据陈旧问题。落地上需要三件事:撤下清单只传标识不传正文、本地保留变更痕迹以备审计、检索层与向量层同步移除。
2. 索引与向量的连带更新
语料入库只是第一步。新增文本要切分、向量化、写入索引;修订文本要先删旧向量再写新向量,否则同一份文书会以两个版本同时被召回,用户看到的是自相矛盾的检索结果;撤下文本要同时从全文索引和向量索引移除。更关键的一条:向量必须与 embedding 模型版本绑定——换了 embedding 模型,增量写入的向量与存量向量不在同一个空间里,此时能做的只有整体重建,而重建属于重大版本,应当走驻场通道并单独安排窗口。参见向量库与检索引擎选型与语义检索与关键词检索之别。
3. 容量与带宽的一次性峰值
更新窗口内的资源消耗和日常完全不是一个量级:解压、校验、写入、建索引会同时压满磁盘与内存,而这段时间业务还在跑。规划时要给更新窗口单独留资源余量,并明确它是否需要错峰。见算力容量规划与扩容与运维监控与告警。
六、更新窗口:预检、灰度、切换、观察
把一次更新拆成四段,任何一段失败都不必在业务时间里抢修:
| 阶段 | 做什么 | 失败时 |
|---|---|---|
| 预检 | 隔离环境校验签名、哈希、清单条数、版本对是否衔接 | 直接退回,不进生产 |
| 灰度 | 生产环境导入并建索引,但不切换对外版本 | 丢弃新版本,业务无感 |
| 切换 | 把检索指向新版本,秒级完成 | 指回旧版本 |
| 观察 | 约定观察期内保留上一版本可回退 | 按 ROLLBACK 执行回退 |
这套流程的核心不在技术,在于切换是一个独立且可逆的动作。凡是「导入即生效」的设计,都等于把回滚能力放弃掉了。观察期长度按更新规模定,重大版本应当更长,并与灾备与高可用的备份节奏对齐:更新前的那次备份,是最后一道防线。
七、怎么证明「更新真的到了」
导入脚本返回成功不等于更新成功。建议固定做四项对账,并把结果写进更新记录:
- 计数对账:新增、修订、撤下三类的实际处理条数,与 manifest 声明是否一致。
- 边界抽查:取本次数据区间最早与最晚的若干条,确认在系统里能检索到。
- 随机抽样:随机取若干条,比对正文与关键字段是否与源一致。
- 撤下验证:确认本次撤下的条目已检索不到,且向量层同步移除。
四项都过才算完成。这份记录同时是审计材料,也是下次出问题时的定位起点。把对账结果写成一页纸,由甲方 IT 与厂商双方签字,是成本最低、效果最好的一条实践——它让「更新有没有做」从口头承诺变成可查证的事实。见验收测评怎么做与数据安全审计与等保测评。
八、合同里必须写死的六条
更新条款决定了系统在第二年、第三年还是不是活的,重要性不亚于功能演示,却经常在采购阶段被整体略过:
| 条款 | 写死什么 |
|---|---|
| 更新频率与时限 | 常规节奏 + 每次交付的最迟时间 + 紧急更新通道 |
| 交付通道与介质 | 约定通道形式、分卷规则、交接与登记方式 |
| 包内容与校验 | manifest、三类变更、哈希与签名为强制项 |
| 失败回滚责任 | 谁判定失败、多久响应、回滚到哪个基线 |
| 口径变更告知 | 字段与统计口径调整的提前告知期 |
| 服务期后处置 | 已交付数据的继续使用边界与处置方式 |
最后一条尤其值得在签字前问清楚:私有化的价值之一就是数据在自己机房里,但服务期结束后已交付语料的使用边界必须白纸黑字,否则三年后会变成一个谁都不愿意先开口的问题。参见律所采购 AI 的五个坑与私有化与客户保密义务。
九、语料更新十项自查清单
- 更新频率写进合同了吗?是否与获批的通道相匹配?
- 通道的安全审批走完了吗,还是只停留在方案里?
- 增量包是否包含 manifest、哈希与签名?
- 新增、修订、撤下三类变更是否分开交付?
- 字段口径变更说明是否每次都有,哪怕写「无变更」?
- 导入前是否在隔离环境做过预检?
- 切换是否是独立可逆动作,而非「导入即生效」?
- 更新前的备份是否确认可用,而不只是存在?
- 四项对账是否形成书面记录并双方确认?
- embedding 换版时的整体重建方案是否提前约定?
十、常见问题
Q:内网机器完全断网,还能定期更新吗?
A:能,通道决定节奏。移动介质通常按月或按季,单向导入设备可到周度,白名单专线能到日度但审批成本最高。
Q:更新一次要停机多久?
A:按「灰度 + 切换」设计的话,对外中断只发生在切换那一刻;导入和建索引都在不影响现有版本的前提下完成。
Q:能不能只做追加,不处理撤下?
A:不建议。文书状态会变化,只追加会长期保留不该继续呈现的内容,这是合规风险,不只是数据陈旧。
Q:更新包很大,介质装不下怎么办?
A:分卷交付,并在 manifest 里写明总卷数与顺序;导入端必须校验卷齐全后再开始处理,避免半包入库。
Q:换了 embedding 模型,增量还能继续写吗?
A:不能混写。新旧向量不在同一空间,必须整体重建,并按重大版本单独安排窗口。见律所 RAG 知识库。
Q:甲方 IT 自己就能执行更新吗?
A:可以,前提是包自洽、流程写成 SOP、回滚步骤明确。真正需要驻场的是重建索引和跨大版本升级。
Q:怎么防止旧包被重复导入?
A:靠 manifest 的版本对做前置校验,基线不匹配就拒绝执行。内网里包积压是常态,这条校验必须有。
Q:更新记录要保存多久?
A:至少覆盖整个服务期,并包含经手人与介质编号,以满足审计要求。见司法数据平台建设与私有化部署方案。
把更新条款一起谈进方案里
提供部署环境与可用通道,1 个工作日内反馈一份可落地的语料更新交付方案。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:割接与数据迁移 · 模型版本管理 · 持续运营与数据回流 · 文书私有库架构 · 裁判文书智能检索系统 · API / MCP 定价