9.3 从 Jev 迁移到开源的路径

9.3 从 Jev 迁移到开源的路径

本节摘要：9.1 与 9.2 解决「新系统怎么选」，本节解决「存量怎么办」——已经在 Jev 上的团队，怎么把一部分决策流量迁到 laya。地基是协议同线：laya-serve 与 Jev 说同一种话（POST /v1/systemone），Jev 客户端改一个 baseUrl 就能连上 laya（第 4.1 节）。在此基础上本节给三步路径：第一步直连对齐，用影子模式双发对比；第二步灰度切流，按流量比例与问题类型渐进接管；第三步回退开关，一键切回 Jev 并事先演练。验收不看点位一致率一个数字，而看四个指标：一致率、分歧样本分析、延迟分布、错误预算。最后把三个最常见的失败原因摆在前面：没微调就去对齐、高基数场景硬迁、成本只算 API 费不算微调与运维。

学习目标

• 说明「协议同线」为什么把迁移成本从改造工程降到配置变更。
• 设计影子模式：双发、采样、落盘、分歧四分类。
• 制定灰度切流的切分维度、监控项与熔断条件。
• 列出四个验收指标，并说出各自回答的问题。
• 识别三个典型迁移失败的前兆信号。

一、迁移的前提：协议同线，但能力不同线

协议同线是 laya 与 Jev 之间最值钱的一句话：请求路径、请求体、响应结构都一致。这意味着迁移不动客户端代码，只动端点配置——通常就是一个环境变量的事。

迁移前后的客户端视角（第 4.1 节的回顾）

  迁移前：  客户端 ──POST /v1/systemone──▶ Jev 云端
  迁移中：  客户端 ──▶ 分流器 ──┬──▶ Jev 云端（生产）
                              └──▶ laya-serve（影子）
  迁移后：  客户端 ──POST /v1/systemone──▶ laya-serve（自托管）
​

但协议兼容不等于能力等价。第 9.1 节的六轴表里 laya 有两轴是硬约束：zero-shot 近随机、必须微调。所以迁移前先过一遍这张自问清单：

二、三步路径：对齐、切流、回退

第一步：直连对齐（影子模式）

影子模式是迁移的地基：生产请求照常发给 Jev，同时复制一份给 laya，两边结果都落盘，但不采用 laya 的结果。这一步不承担任何生产风险，只产生证据。

# shadow_compare.py —— 影子模式：双发对比并落盘分歧
import json, time, random

def shadow_route(payload, jev_call, laya_call, sample_rate=0.1):
    # 生产路径：始终走 Jev，结果直接返回
    t0 = time.perf_counter()
    jev_result = jev_call(payload)
    jev_ms = (time.perf_counter() - t0) * 1000

    # 影子路径：按采样率复制给 laya，结果只落盘不采用
    laya_record = None
    if random.random() < sample_rate:
        t1 = time.perf_counter()
        try:
            laya_result = laya_call(payload)
            laya_record = {
                "latency_ms": round((time.perf_counter() - t1) * 1000, 1),
                "agreement": classify(jev_result, laya_result),
            }
        except Exception as exc:
            laya_record = {"error": repr(exc)}  # 影子失败不影响生产
    return jev_result, laya_record

def classify(jev_result, laya_result):
    # 分歧四分类：同对同信 / 同对异信 / 异对 / 单边弃权
    same_answer = jev_result["choice"] == laya_result["choice"]
    both_confident = jev_result["confidence"] > 0.8 and laya_result["confidence"] > 0.8
    if same_answer and both_confident:
        return "同对同信"
    if same_answer:
        return "同对异信"
    if laya_result.get("abstained"):
        return "单边弃权"
    return "异对"
​

采样与样本量用工程判断而非统计教条（以下为示意值）：低风险问题类型采 10%，高风险类型采 100%；每类至少积累几百个样本再下结论。分歧落盘后按四分类统计：

第二步：灰度切流

对齐数据达标后开始切流。切流维度从粗到细：先按问题类型（低风险类型先切），再按流量比例（从 1% 到 10% 到 50%，示意值），最后才考虑整类接管。每个梯度至少观察一个完整业务周期（例如一周，含工作日与周末的不同流量形态）。

第三步：回退开关

回退不是心理安慰，是一个真的按得下去的开关：客户端端点是环境变量，回退就是把 baseUrl 改回 Jev 并重启或热加载。三件事让它可信：切换操作写在值班手册里；上线前演练过一次；每次切流决策留下记录（谁、何时、依据什么指标）。回退之后不是终点——回退原因要回流到微调或校准环节，修完再走一遍对齐。

三、验收指标与常见失败

四个验收指标各回答一个问题，缺一不可：

三个最常见的失败，前兆都在第 10 章：其一，没微调就去对齐——底座 zero-shot 近随机，一致率必然难看，这不是 laya 不行，是流程跳步；其二，高基数场景硬迁——几十个选项的任务 laya 官方口径不如 Jev，先按 9.2 的决策树把它留在 Jev；其三，成本只算 API 费——微调人力、GPU 或 CPU 资源、运维值班都要进成本表，否则省下的 API 费会在别处加倍还回来。

本节要点回顾

• 协议同线让迁移从改造降级为配置：改 baseUrl 即可直连。
• 三步路径：影子对齐产生证据，灰度切流控制风险，回退开关兜底。
• 验收看四指标：一致率、分歧分析、延迟分布、错误预算。
• 三个失败前兆：没微调对齐、高基数硬迁、成本漏算微调与运维。

到这里，选型与迁移的路线图就完整了。但无论选哪条路线，长期跑下去都要面对下一章的问题：laya 的诚实边界——zero-shot 为什么近随机、位置偏差怎么测、高基数与校准自理为什么是绕不开的两笔运维账。