1. 第七周的分水岭从“复习笔记”到“可上线的应用”第七周之前我的状态非常典型一个写了好几年 Java 后端的开发者决定转向 AI 工程化于是在前六周里拼命补知识。特征工程看了一些损失函数推导过一遍Transformer 的注意力机制也能讲个大概Prompt 调优更是收藏了十几篇文档。可当我把这些散落知识点放到一起试着做一个“能上线的应用”时才发现自己根本交不出东西。Week 7 没有学新算法也没有继续刷模型榜单我只做了一件事把之前记在笔记里、散在代码片段里的知识串成一个真正能被别人调用的服务。这一周值得单独写一篇是因为它暴露了转型路上最常见的问题“学过”和“能用”之间差着一整条工程链路。模型准确率再高装不进 Java 服务、跑不稳、没法监控、出了问题排查不了就只是 notebook 里的漂亮数字。我给自己定的 Week 7 目标是做一个可上线的文本意图识别小应用用户发一段文本服务返回分类结果和置信度。验收标准不是某个指标多好看而是能不能在干净环境里一键启动、连续请求不崩、日志能追踪、模型可回滚。我把这一周的完整过程、踩坑链路和最终沉淀下来的工作流放在下面给同样从 Java 后端转 AI 工程化的朋友一条可以复用的路线。1.1 前六周学的是零件不是系统前六周我学了很多孤立单元线性回归、逻辑回归、Embedding、RNN/CNN、Transformer、Precision/Recall、A/B 测试、模型量化。这些知识点单独拎出来每一个都能写一篇笔记但一旦要组成应用它们各自属于哪个层级、由谁负责、接口怎么定义我之前完全没有概念。最直接的感受是我可以在 Jupyter 里跑通模型训练却不知道模型文件应该放哪里、Java 服务如何加载、请求进来之后特征应该由谁算、预测出错时日志应该记哪些字段。这些内容不会出现在大多数教程里恰恰是工程化考验人的地方。第七周让我意识到散落知识点不是问题问题是没有一个“总装图”把它们固定到系统里。1.2 我给第七周定义的验收标准第七周开始时我写下了四条必须满足的验收标准而不是“我要做个模型”这种模糊目标标准一项目可以通过 Maven 打包在空机器上只装 JDK 和 Docker 就能启动标准二服务提供 HTTP 接口支持单条和批量预测返回结果包含分类、置信度和请求 ID标准三模型文件不放在代码仓库里而是放在独立模型存储路径版本号显式传递标准四关键指标有日志和内存态统计服务重启后能自动加载最新模型并完成预热。这条标准直接把我的学习方式从“继续吸收”切换到“组装交付”。后面所有的决策都围绕这四条展开。2. 先把系统边界画清楚模型、服务、数据各就各位写 Java 后端的时候我习惯先画模块边界再写代码。到了 AI 工程化这个习惯救了我。Week 7 第一天我没有写任何训练脚本而是花了大半天画了一张系统边界图模型从哪来、服务怎么拿到模型、请求如何变成特征、预测结果如何返回、日志如何回流。2.1 模型是资源不是业务逻辑很多 Java 开发者第一次接触 AI 项目会试图把模型推理代码直接写进业务代码里比如在 Controller 里加载模型文件、在 Service 里写预处理逻辑。这么做在 Demo 阶段没问题但只要模型更新版本或者需要灰度上线就会变成灾难。我更建议把模型看成独立的版本化资源与业务代码完全分离。模型文件由离线训练流程产出通过固定 Schema 导出Java 服务只负责加载指定版本的模型处理请求并返回结果。业务代码和模型之间通过一个薄薄的 Predictor 接口隔离这样演化空间会大很多。2.2 训练环境、预热脚本、在线服务各自独立训练脚本使用 Python 生态确实高效但我不打算把 Python 进程嵌进 Java 服务里。Week 7 我采用的方式是Python 负责训练和导出模型Java 负责加载和推理。两者通过模型文件和特征 Schema 通信。这样做的直接好处是线上服务不需要装 Python 环境、不需要管理 Python 依赖部署复杂度低很多。预热脚本也独立存在。服务启动后先加载一个固定数量的测试请求调用若干次推理确认模型输出符合预期后再接收线上流量。这个预热动作在本地很难发现价值真正部署时能拦住大量低级错误。2.3 数据闭环从第一天就要设计“模型上线不是终点而是数据循环的起点。”这句话我在前几周听过很多遍但 Week 7 才真正理解。线上日志不能只记录业务结果还要记录输入文本、模型版本、预测结果、置信度、是否人工复核以及最终的正确标签。我把日志字段设计成一张固定的表而不是临时拼几个字段。这样后续做离线评估、Bad Case 分析、模型迭代时都能直接回放线上数据不需要重新造数据。边界项训练期线上期模型存放本地文件独立模型目录模型版本训练时间戳显式版本号数据来源标注样本线上日志 人工复核特征计算Python 脚本Java 内部逻辑评估方式离线验证集灰度对比 人工抽检2.4 资源预算先算再写Java 后端转 AI 工程化很多人会忽略一个问题模型推理不仅吃 CPU还吃内存有时候还吃 GPU。Week 7 我的原型是个文本模型参数量不大单次推理大概几十毫秒但模型加载后占的内存是固定的。我先估算了一下一个模型文件约 200MBJVM 堆配置 1GB再加缓存和线程池一个容器至少要 1.5GB 内存才稳。如果不提前算资源预算部署很容易出现 OOM。更麻烦的是服务在流量高峰才崩溃排查起来会特别痛苦。所以我把容器内存、JVM 堆内存、模型加载内存写进了部署文档避免后续接手的人靠猜。3. 端到端落地一个文本意图识别服务是怎么从零变可用的边界画完后我开始做端到端原型。为了不引入过多业务干扰我选了一个非常经典的场景客服工单自动分类。输入一段用户描述输出“退换货、物流咨询、价格问题、产品故障”等八个类别之一。这个场景足够小又包含完整的训练、推理、评估、迭代闭环。3.1 数据准备与标签设计数据是训练的起点。我没有直接拿公开数据集而是用模拟项目 X 自己的业务形态造了一套小样本先写规则生成一批模板文本再人工修正明显不合理的地方。数据量不大大约 800 条训练样本、200 条验证样本、200 条测试样本。标签设计比想象中重要。一开始我设计了十五个细分类别结果训练后混淆矩阵里一堆相邻类别互相打架。后来我把相近类别合并成八个边界清晰了许多。这个动作让我切身体会到类别粒度是标注成本、模型难度和业务可用性的三方博弈。3.2 模型选型先从小模型开始很多教程会推荐直接上大规模预训练模型但工程化要综合考虑。我的场景是中短文本、类别固定、延迟敏感。经过对比我选择了一个轻量级的预训练编码器作为底座后面接一个简单的分类头。这个组合参数量不大单次 CPU 推理在 30 毫秒到 50 毫秒之间满足我的验收目标。选型逻辑是先跑通最小可行性链路再在链路稳定的基础上换更强模型。如果一上来就用最大的模型不仅训练慢Java 侧加载和推理也有更多不确定性排错时会非常痛苦。3.3 训练、评估、导出把笔记里的知识点串成流水线前六周学的知识点终于在这里汇合特征处理、损失函数、评估指标、模型保存。我的训练脚本非常简单但它是完整的# 示意脚本重点看流程不是具体参数 train_df load_labeled_data(data/intents.json) valid_df load_labeled_data(data/valid.json) tokenizer load_tokenizer(model/encoder) model build_intent_model(num_labels8) train(model, train_df, valid_df, epochs6, batch_size16) eval_out evaluate(model, valid_df) print(eval_out.confusion_matrix()) save_model(model, tokenizer, export/model_v1)导出模型时我额外保存了一份特征 Schema 文件里面定义清楚输入字段名、截断长度、标签列表、向量维度、预处理顺序。这份 Schema 是后面 Java 侧不会写歪的保险。3.4 Java 侧服务封装模型只加载一次Java 侧我使用最常用的 Web 框架搭建 REST 接口。第一版 Controller 特别简单RestController RequestMapping(/v1/intents) public class IntentController { private final IntentPredictor predictor; public IntentController(IntentPredictor predictor) { this.predictor predictor; } PostMapping public PredictResponse predict(RequestBody PredictRequest request) { return predictor.predict(request.getText()); } }关键在于IntentPredictor的实现。模型初始化必须在应用启动阶段完成而不是在第一个请求进来时才开始加载。初始化完成后所有请求共用同一个模型副本避免每次创建加载。特征预处理的顺序也必须和训练时完全一致。我在 Java 侧复刻了分词、截断、ID 映射和 Padding 的逻辑并用训练阶段的几十条样本做了回归测试。这一步是散落知识点变成工程细节的地方。3.5 同步还是异步先同步再加异步“在线推理要不要做异步”这个问题我在 Week 7 里反复权衡过。对于交单式分类接口同步响应最简单调用方拿到结果就能继续流程。Batch 场景可以单独做异步任务。我最终选择默认同步接口超时控制在 200 毫秒内同时预留了一个批量接口用于离线数据处理。异步虽然能提升吞吐但会引入消息队列、回调、结果存储等复杂度在原型阶段没必要。4. 一次错误率飙升的线上排查从现象到根因的完整链路Week 7 后半段我自认为部署已经稳定结果一次灰度直接把我的自信打碎了。这个问题不常见却非常值得完整复盘。4.1 现象灰度流量进来后准确率只剩一半我在生产环境复制了一小部分流量只放了一个模型版本。刚开始日志显示响应正常延迟也稳定。但人工抽检发现明显属于“物流咨询”的文本被分到了“产品故障”之前离线测试时准确率超过 90%线上看起来只有 50% 左右。第一反应是模型过拟合或者是线上文本分布和训练分布不一致。但仔细看 Bad Case发现错误并不是随机的而是有规律几乎所有文本都被分到相邻或靠后类别的概率变高。这个规律提示我问题可能出在特征侧而不是模型本身。4.2 缩小范围请求参数、模型版本、特征拼接我用请求 ID 找出了具体请求开始在本地重现。我用相同的模型文件、相同的输入文本在本地测试脚本里跑了一次结果分类完全正确。问题不在模型。然后我检查了 Java 服务的打印日志发现请求文本被正确接收但经过预处理之后Token ID 序列和本地 Python 脚本里的输出完全对不上。这时我意识到问题很可能出在特征构造顺序。训练时我的预处理流程是“先分词、再截断、后 Padding”而在 Java 侧我写成了“先截断、再分词、后 Padding”。大部分文本长度没有超过截断阈值所以差异不明显但一遇到特定长度的文本截断位置不同Token 序列就不同模型输出自然就偏了。4.3 定位根因离线与在线特征处理不一致这个根因让我非常惭愧因为它属于最基础的特征工程问题。离线和在线的特征处理流程没有对齐模型再强也白搭。我复盘后发现这不只是代码顺序问题更是协作流程问题。Python 训练脚本和 Java 推理服务是不同时间写的在没有统一 Schema 的情况下两边很容易各按各的理解实现。改了几次之后只有不经意触发到长度边界时才会暴露。4.4 修复方案固化特征 Schema建立回归用例修复动作有三层。第一层把特征 Schema 提升为唯一事实来源里面明确写下预处理每一个步骤的顺序、参数和输出维度第二层在 Python 侧和 Java 侧分别写一个输出对齐测试用同样的输入跑若干条逐字段对比第三层把这类对比测试加进 Maven 的集成测试流程每次构建自动执行。这之后我再也没有遇到过由特征顺序不一致导致的线上事故。这个坑让我明白AI 工程化里最隐蔽的风险往往不是模型而是训练与推理之间的流程漂移。5. 效果评估的工程化准确率之外还要看稳定性和可迭代性模型能用之后我开始认真思考效果评估。前六周学的指标在这个阶段显得特别有用但也特别容易被误用。5.1 准确率会骗人必须看混淆矩阵和 Bad Case准确率 90% 看起来不错但客服工单分类场景里类别分布天生不均衡。如果“产品故障”类样本特别多模型只要偏向这一类准确率就会虚高。我每次评估都看混淆矩阵重点关注容易混淆的类别对。比如“退换货”和“价格问题”为什么会互相串。接着我会抽样看 Bad Case仔细读那些被分错的文本判断是标注问题、特征问题还是模型能力问题。这个方法比盯着一个整体指标有用得多。5.2 在线灰度先把流量切到新模型上观察模型有新旧版本时不能直接全量切。我用了一个最简单的灰度方式在 Java 配置里加一个分流参数新模型先承接 5% 的请求观察延迟、异常率、置信度分布再逐步扩大到 20%、50%、100%。灰度期间我会同时记录新模型和旧模型的预测结果形成对比日志。即使新模型离线指标更好线上也要先跑一段时间再决定是否转正因为离线分布永远不等于线上分布。5.3 人工复核闭环把线上误判送回训练集线上日志里置信度低或者人工标记为“需要复核”的请求我会定期捞出来。随机抽一部分让业务方人工标注然后把标注好的数据合并进下一轮训练集。这个闭环虽然简单但能让模型持续吃到真实分布的数据。这一步也是 Java 后端能力最容易发挥的地方写定时任务、导出数据、生成标注队列都是后端开发的日常能力。AI 工程化并不是只写 Python更多时候是在构建数据和模型之间的自动化管道。5.4 迭代节奏小步、频繁、可回滚确定迭代节奏时我给自己定的原则是小步、频繁、可回滚。每轮迭代尽量只改一个变量比如换了更多训练数据、调了正则化参数或者升级了编码器。不要同时改三个东西否则出了问题根本不知道是哪一步引起的。回滚方案要在上线前就准备好。我的模型目录里保留最近三个版本Java 侧配置支持随时切换版本号并重启加载。这个动作成本很低但能显著降低试错心理压力。6. 第七周之后沉淀成一套可以复用的 Java AI 工作流Week 7 结束时我的收获不是某一个模型而是一套可复制的工作流。它把散落知识点变成了清晰的分工Python 负责训练和实验Java 负责服务和工程化两边通过 Schema、版本号和日志对齐。6.1 一页纸交付清单每次做新的 AI 功能我现在都会先过一遍清单数据是否有稳定来源标签口径是否清晰训练流程是否可重复是否依赖人工手动步骤模型导出格式是否固定是否带版本号和 SchemaJava 服务是否在启动时加载模型是否做过预热特征处理是否有离线和在线对齐测试日志是否记录了请求、版本、置信度和最终标签是否有灰度开关、回滚方案是否有 Bad Case 回流和人工复核入口。这份清单让项目从“好像能做出来”变成“确定能交付”。6.2 Java 背景在 AI 工程化里的优势转型容易陷入“一定要写很多 Python”的焦虑但 Week 7 让我看到本职经验的巨大价值。Java 后端对并发、稳定性、可观测性、依赖管理的理解都是 AI 工程化必需的。模型再强最终也要变成稳定运行在生产环境里的服务。我更建议 Java 开发者把切入点放在模型服务化、数据管道、离线在线一致性、评估闭环这些位置而不是只盯着模型训练。这样反而能更快拿到结果。6.3 下一个阶段的方向第七周之后我给自己排了三个练习方向把当前原型接入真实业务数据源做成一个完整的自动标注工具尝试换一个更大的预训练模型对比延迟和效果再研究一下请求级限流和排队策略避免流量尖峰打垮推理服务。我不再追求一次学完全部内容而是每做一个项目就补上这个项目暴露出的盲区。这个节奏比当初漫无目的地刷知识点踏实得多。如果你也正在从 Java 后端往 AI 工程化转型Week 7 最值得做的事就是停止“继续学”找一个哪怕是玩具级的场景把它完整接进 Java 服务里部署、监控、灰度、回滚都走一遍。走完这一遍那些散落知识点自然会长成一个系统。