PART 3｜优缺点：全部来自真实实测
以下每一条都有实测证据支撑，不是官方宣传口径。背景：诗歌领域知识图谱，5 个决策任务（作者归属 5 选 1、下一跳 5 选 1、朝代 5 选 1、体裁 5 选 1、作者判定二元），0.6B 底座 LoRA 微调。
优点
| # | 优点 | 实测证据 |
|---|---|---|
| P1 | 可微调，且微调真有效：领域监督信号能把它从随机救到可用 | 朝代任务 0.185→0.925（AUROC 0.89）；下一跳任务问法对齐后 1.000，rank 对照 20/20 |
| P2 | API 兼容 Jev：TypeSafe SDK 原样可用，未来换官方 Jev 或更大 Kev 零改造 | /v1/systemone 契约一致，评测与服务都走该协议 |
| P3 | 笔记本级训练成本 | 0.6B LoRA 在 6GB 卡上峰值 1.71GB，1 epoch 378 步约 31 分钟 |
| P4 | 一次前向答多问题：state 编码一次，choice/noul/score 同请求并答，隔离精确 | 官方 parity 测试：合并/分开提问差异 4e-6 |
| P5 | 概率有校准：checkpoint 自带温度拟合 | 朝代任务 ECE=0.018（0.907 置信 vs 0.925 准确，近乎完美） |
| P6 | 服务化成熟：kev.serve 开箱即 HTTP 服务 | GPU 上全链路约 98ms/问，200+ 次调用零降级 |
| P7 | 工程透明：model card 冻结评测协议、三种子、带 checksum 的测试集；PLAN.md 记录全部试错 | 官方仓库，数字在 CI 里对 committed report 复验 |
缺点与边界
| # | 缺点/边界 | 实测证据与口径 |
|---|---|---|
| C1 | 0.6B 容量有限，作者级判别学不动：二元作者判定重设计数据后仍 0.500（=随机）、AUROC 0.475、输出恒定 | 想做需要实体知识的判定，直接上 4B 或先注入知识，别在小模型上硬磨 |
| C2 | 对问法极其敏感：训练与运行的问题措辞必须逐字同源，漂移即偏置 | 旧问法「哪首同作者」被模型做成「选名气大的」，名气倍数 20.9x；改问法「接下来想读《X》：这五首里是哪一首？」后 1.000 且 1.0x |
| C3 | confidence 在低准确率任务上系统性偏低（conf 0.13–0.15 vs acc 0.34–0.40） | 拿置信度做路径打分/排序时，需按任务重标定，不能直接跨任务比较 |
| C4 | LoRA 模式无原生 resume（--resume 仅限 full_ft） |
中断续跑必须靠 --init_from 分段热启动——建议一开始就把训练切成段 |
| C5 | Windows 适配缺失：train.py/serve.py 顶层 import resource（POSIX-only）、测试引 fcntl |
需 runpy 预注入 no-op stub，不改上游仓库；纯 Linux/Mac 无此问题 |
| C6 | 自由文本意图是分布外调用：没有对应训练语料的问法，能力未经证实 | 新问法先量化评测再上线，不预设能过 |
| C7 | 训练上下文 384 token 内，长文档精度下降 | 官方：1k–6k 干扰文本里 Kev-27B 0.833，Kev-9B 只有 0.556；长 state 是 27B 的场景 |
| C8 | 模型时间与全链路延迟有差距 | 模型侧 18–41ms/H100，HTTP 全链路约 98ms/问；高频热路径考虑进程内接入 |
| C9 | 选项顺序会改变答案：问题隔离不等于选项隔离 | 官方提供 /v1/systemone/permute 端点做顺序扰动测试；对排序敏感的场景要自己测 |
一句话总结：Kev 是一把「领域内精排」的好刀，不是「什么都会」的通用模型。域内任务微调后能到 0.9+ 甚至 1.0，域外任务和需要实体知识的任务上，小模型直接判不动。
