私有化法律 AI 的项目文档里,通常有很厚的选型、部署、调优章节,却几乎没人写割接那几周——买完、装完、调完之后,怎么把人和数据真正搬过去而不出事。这一段最容易翻车也最难补救:数据搬错了要重来,律师第一周被坑一次,后面半年都不愿再打开。本文只讲这几周,范围严格限定在数据搬迁、并行运行、灰度切流、回滚四件事。相邻题目各有专文:选型与部署方案见私有化部署完全指南,上线前怎么验收见验收测试与评测,切完之后长期怎么迭代见持续运营与迭代,怎么让律师真正用起来见用户推广与赋能,宕机与冗余见灾备与高可用,成本见三年 TCO 测算。
一、三个典型翻车
割接失败的样子高度雷同,基本逃不出这三种:
第一种,一次性全量切。周五晚上停旧系统,周一早上全所用新平台。这一刀同时改变了四件事:数据位置、检索索引、权限模型、律师习惯。周一出问题时没人说得清是哪一环,更糟的是没有对照系,你甚至无法证明「这个结果比以前差」。
第二种,旧库脏数据原样搬。旧系统跑了五到十年,里面是同一份起诉状的多个版本、重复归档的证据包、早年扫得糊掉的 PDF。这些在旧系统里只是「翻起来烦」,搬进法律 AI 就是另一回事:检索层把它们当成对等语料召回,模型基于错误版本生成内容,而系统不会报错。脏数据在旧系统里是噪音,在 AI 里是错误答案。
第三种,律师没准备好、也回不去。技术上切得干干净净,但没人提前告诉律师什么时候切、哪些会变、出问题找谁;旧系统入口当天就关了。第一个撞上问题的合伙人无路可退,当天中午项目口碑就定了。
三者的共同点是:把不可逆的动作放在了信息最少的时候。
二、要搬的其实是四类对象,难的是后两类
很多迁移计划只写了「历史卷宗导入」,那只是四分之一。实际要处理的是:
| 类别 | 内容 | 性质 | 主要风险 |
|---|---|---|---|
| 卷宗文档 | PDF / Word / 扫描件 / 邮件附件 | 搬运 | 体量大、版本混乱、OCR 质量不齐 |
| 结构化案件字段 | 案号、案由、当事人、承办人、状态、时间轴 | 搬运 + 字段映射 | 旧系统字段口径与新平台对不上,枚举值缺失 |
| 检索索引 | 全文索引 + 向量索引 | 重建 | 不能拷贝,必须重跑;切分与 embedding 变了,召回质量随之变 |
| 权限与组织架构 | 部门、案件组、角色、利益冲突墙 | 重建 + 映射 | 照搬旧账号表会造出越权通道,且界面上看不出来 |
前两类是工程量问题,给够时间就能做完;后两类是设计问题。
检索索引必须重建,不能迁移。新平台的切分策略、embedding 模型、混合检索配置都和旧系统不同,索引是这些配置的产物而非独立资产。迁移完成后召回质量要重新验证一遍——见向量库与检索引擎选型与律所 RAG 知识库建设。
权限是四类里最危险的一类。旧系统权限往往是多年层层打补丁攒出来的,里面有大量「临时开一下没关」的授权。原样映射等于把历史遗留一次性放大——AI 的检索能力会把线下靠物理和流程隔开的东西一键打通。正确做法是按当前组织架构重新定义权限,而不是导入旧账号表,详见多租户与权限隔离架构。
三、数据清洗与去重:迁移前必须做的四件事
清洗不是可选项,也不该在割接周现做。以 2026 年年中的常见实践,这四项须在正式迁移前完成并出报告:
- 版本收敛。同一份文书的多个版本,要定一条机器可执行的规则挑出主版本(如归档时间 + 文件名规范 + 是否带签章),其余降权或不入检索库。不定规则,等于让检索层随机决定律师看到哪一版。
- OCR 质量分级。扫描件按识别置信度分档,低于阈值的单独标记。低质量 OCR 的处理不是丢弃,而是入库但不参与生成引证——可检索、可点开看原件,但不作为模型作答依据。
- 重复归档去重。同一份材料在多个案件下重复存在很常见。按内容指纹去重,保留一份主体加多条关联关系,而不是留多份副本——副本会让同一事实在召回里反复出现,模型会误判它更重要。
- 涉密标记继承。最容易漏的一项。旧系统的密级标记可能挂在文件夹上,也可能只存在于线下台账。迁移时必须明确:标记缺失的默认按高密级处理,而非默认公开。见法律数据分类分级。
一条经验:清洗报告要给出「入库 / 降权 / 不入库」三类的数量与占比,并让业务方签字确认。没有这份确认,上线后有人说「我那份材料搜不到」就会变成无法收敛的扯皮。
四、并行运行期怎么设计
并行运行不是「多一个备份」,而是造一个可比较的对照系:同样的检索,两边各给什么、差异在哪。三个必须提前拍板的问题:
| 问题 | 建议做法 | 理由 |
|---|---|---|
| 跑多久 | 两到六周,至少跨过一个完整业务周期 | 要覆盖月末结案、报表、归档高峰,平时不出的问题都在高峰出 |
| 以谁为准 | 旧系统是唯一权威数据源 | 并行期不是「两个都算数」,必须有且只有一个真相源 |
| 双写还是只读 | 新平台只读,增量数据单向同步过去 | 双写会造成两边分叉且无法合并,是并行期最常见的事故 |
「只读怎么验证写入路径」是常见质疑。答案是写入放到灰度阶段按业务线验证,而不是在并行期用全所数据去赌。并行期要验的是检索与生成质量。
并行期还要跑抽样对照评测:选一组固定的真实检索问题(建议五十到一百条,覆盖主要业务线),每周在两个系统各跑一遍,记录召回是否缺漏、引证是否可溯源。这组题后面会作为长期回归集用,不是一次性投入。方法见幻觉与引证核验。
五、灰度切流:按业务线放,顺序不能反
切流顺序只有一条原则:按「答错了代价从小到大」放。
| 批次 | 场景 | 为什么放这个位置 |
|---|---|---|
| 第一批 | 内部知识检索(类案查找、法规查询、所内知识库) | 答错律师当场就能发现,不进案卷、不对外,试错成本最低 |
| 第二批 | 案件工作台(要素抽取、材料摘要、内部底稿辅助) | 有内部复核环节兜底,错误不会直接流出 |
| 第三批 | 对客户产出(意见书、检索报告等对外交付物) | 代价最高,必须等前两批稳定后再放 |
每批内部再按人群分层:先信息化团队用一周,再放一个愿意配合的业务部门(劳动争议、合同纠纷这类案件量大、争议点标准化的部门最合适),稳定后全所铺开。工作台的能力边界见律师工作台:案件胜算量化。
反过来做——先上对外产出,因为「那个最能体现价值」——是割接期最贵的决定:系统最不稳的时候,承担了最不能错的活。
六、回滚触发条件表:必须切流前定好
事中判断「要不要回滚」几乎一定拖延,现场压力下所有人都倾向于再等等看。提前定义的意义,是把判断从开会讨论变成对照阈值执行。这张表建议原样带进项目文档:
| 触发条件 | 参考阈值 | 判定人 | 动作 |
|---|---|---|---|
| 检索质量塌陷 | 回归集通过率低于并行期基线一定幅度 | 项目技术负责人 | 立即回滚该批次 |
| 权限越界 | 出现任意一例确认的越权访问 | 合规官 | 立即全量回滚,不分批 |
| 数据缺失 | 抽查发现整类材料未入库 | 数据负责人 | 回滚该批次,补迁后重切 |
| 性能不可用 | 高峰期响应超出约定上限并持续 | 运维负责人 | 降级或回滚,视批次 |
| 业务方明确反对 | 试点部门负责人书面提出 | 项目负责人 | 暂停后续批次 |
三条配套约定:回滚路径必须演练过,没演练的方案等于没有;旧系统入口在最后一批稳定运行满一个业务周期前不关闭;每次回滚都要出原因说明,否则同一个坑会在下一批重演。
七、割接周时间线
以一次典型的批次切换为例,时间线通常是这样的:
| 时间 | 动作 | 产出 |
|---|---|---|
| T-14 天 | 清洗完成,存量数据迁移与索引重建 | 清洗报告 + 入库量核对 |
| T-10 天 | 权限重新定义并映射,越权抽测 | 权限矩阵 + 抽测记录 |
| T-7 天 | 并行运行,回归集对照评测 | 差异清单 + 基线数据 |
| T-3 天 | 发切换通知,明确影响范围与当班响应人 | 用户通知 + 值班表 |
| T-1 天 | 增量数据最后一次同步,回滚演练 | 演练记录 |
| T 日 | 本批次切流,现场值守 | 切换记录 |
| T+1 至 T+5 | 每日核对指标,收集反馈 | 日报 |
| T+14 | 批次评审,决定是否放下一批 | 评审结论 |
注意 T-1 的增量同步:并行期越长,存量迁移与切换日之间的增量越多,漏掉这一步会让新平台缺最近几周的数据,而这恰恰是律师最常检索的部分。
八、上线后两周盯什么
切完不是结束,接下来两周的指标决定要不要往下放一批:
- 使用类:日活律师数、人均检索次数。首周高、第二周断崖下滑,说明第一次体验没达标,不是「大家在适应」。
- 质量类:空检索率、无引证输出比例、人工纠错数。空检索率是迁移遗漏最直接的信号——本该有结果却查不到,系统不报错,只有这个指标会动。
- 性能类:首 token 延迟、高峰期排队情况。
- 安全类:权限越界告警、异常导出。
采集与告警怎么搭,见运维监控与告警体系。割接期别另起炉灶做临时看板,直接用长期监控体系,省得上线后再搬一次。
九、割接十项自查清单
- 四类迁移对象(文档 / 结构化字段 / 索引 / 权限)是否都有明确负责人和验收标准?
- 清洗报告是否出了「入库 / 降权 / 不入库」的量与占比,并由业务方签字?
- 涉密标记缺失时的默认规则,是否明确为按高密级处理?
- 权限是按当前组织架构重新定义的,还是照搬了旧账号表?
- 并行期是否明确写死「旧系统为唯一权威源、新平台只读」?
- 回归评测集是否已建立并跑出并行期基线?
- 灰度顺序是否为「内部检索 → 案件工作台 → 对客户产出」?
- 回滚触发条件表是否已定,且回滚路径演练过?
- 旧系统入口保留到什么时候、谁有权关闭,是否白纸黑字?
- 割接周是否有当班响应人,律师问题有明确的报障入口?
十、常见问题
Q:并行期能不能压到一周?
A:可以压,但要清楚代价:一周大概率跨不过月末结案与归档高峰,而高峰恰恰是问题集中暴露的时候。前提是回归评测集足够扎实,且接受第一批灰度承担更多试错。
Q:历史卷宗必须全量迁吗?
A:不一定。常见做法是按时间和业务线分层:近三到五年的核心业务线全量入检索库,更早的先入库不建索引,按需再补。一次性全量建索引会显著拉长割接周期,收益却集中在近几年数据上。
Q:旧系统什么时候能下线?
A:建议最后一批稳定运行满一个业务周期后再走正式下线,期间保留只读访问。下线前确认归档与审计要求——有些材料的留存义务不随系统更换而终止。
Q:割接要不要停机?
A:按批次灰度做通常不需要整体停机,只在增量同步窗口内限制写入。需要停机窗口的是一次性全量切方案——这也是不建议它的原因之一。
把割接方案先过一遍再动手
提供当前旧系统情况与数据量级,1 个工作日内反馈迁移与割接方案建议。演示阶段不收费。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:验收测试与评测 · 持续运营与迭代 · 律师工作台 · 裁判文书 API / MCP 定价