1. 从零搭建AI工程体系为什么我劝你别急着调包ai-engineering-from-scratch这个标题第一次看到的时候我愣了一下。市面上讲AI的教程铺天盖地但绝大多数都是教你pip install一个库然后调几个API跑通一个demo就完事了。真正从零开始、把AI工程当作一门系统工程来拆解的内容少得可怜。我自己在这个领域摸爬滚打了七八年带过团队也踩过无数的坑。最深的感受就是能跑通一个模型和能上线一个AI系统中间隔着一整个工程体系。前者可能只需要二十行代码后者需要你理解数据管道、特征存储、模型版本管理、推理服务、监控告警、成本控制这一整条链路。而这个项目标题指向的恰恰就是这条链路——从最底层开始把AI工程该有的东西一块一块搭起来。这篇文章适合谁看如果你是刚入行的算法工程师只会写训练脚本但不知道怎么把模型变成服务那这篇内容能帮你补齐工程侧的认知。如果你是有经验的后端工程师想转AI方向但被各种框架和术语搞晕了那这篇能帮你理清哪些是真正重要的、哪些只是工具层面的噪音。如果你是技术负责人正在规划团队的AI基础设施那这篇可以当作一个参考蓝图。我接下来会从整体设计思路、核心模块拆解、实操落地过程、以及常见问题排查四个维度把从零搭建AI工程体系这件事讲透。不堆砌术语不照搬文档全部是我自己做过、错过、改过之后沉淀下来的东西。2. 整体架构设计与技术选型思路2.1 为什么不能一上来就用现成平台很多人一提到AI工程第一反应就是去找一个MLOps平台或者直接上云服务商的一站式解决方案。这个思路不能说错但它有一个致命问题你不知道平台帮你做了什么也就不知道出了问题该从哪里查。我见过太多团队用了一个封装得很好的平台训练、部署、监控全在界面上点几下就完成了。结果某天推理延迟突然飙升所有人面面相觑因为没人知道底层到底发生了什么。是模型加载的问题是批处理策略的问题还是资源调度的问题完全抓瞎。从零搭建的意义不在于你要造一个比商业平台更好的轮子而在于你必须理解每一个环节的运作机制。理解了之后你再用平台就知道该关注哪些指标该在哪些地方做定制化该在什么时候果断换方案。所以这个项目的整体设计思路是先手工搭建最小可用链路再逐步引入工具替代手写部分。每一步替换都要有明确的理由而不是因为别人都在用。2.2 分层架构的划分逻辑我把整个AI工程体系分成五层从下往上依次是基础设施层计算资源、存储资源、网络配置。这一层决定了你的系统能跑多快、能存多少、能扛多少并发。数据层数据采集、清洗、标注、版本管理、特征工程。这一层是AI系统的地基地基不稳上面盖什么都是危楼。模型层实验管理、训练流水线、模型评估、模型注册。这一层是算法工程师的主战场但也是最容易和工程侧脱节的地方。服务层模型打包、推理优化、服务部署、流量管理。这一层直接面向线上业务对稳定性和延迟要求最高。可观测层日志、指标、追踪、告警。这一层贯穿所有层级是系统运行的眼睛。为什么要这样分因为每一层的关注点不同迭代频率也不同。数据层的迭代周期可能是天级别模型层可能是周级别服务层可能是小时级别。如果不分层所有东西耦合在一起改一个地方就要全量回归效率极低。2.3 技术选型的核心原则在具体工具的选择上我遵循三个原则第一优先选社区活跃、文档完善的开源方案。不是因为开源一定好而是因为出了问题你能找到人问、能找到答案。商业方案虽然省事但一旦遇到边界情况只能等厂商排期这个时间成本在快速迭代的业务里是承受不起的。第二接口标准化优先于功能丰富度。比如模型推理服务我宁愿选一个只支持标准HTTP接口但稳定性极好的方案也不选一个功能花哨但接口私有的方案。因为标准接口意味着你随时可以替换实现不会被锁定。第三可观测性作为硬性指标。任何引入的组件如果它不能输出结构化的日志和指标直接否决。一个黑盒组件在线上就是一颗定时炸弹。具体到工具层面数据版本管理我会用DVC或者LakeFS实验追踪用MLflow模型服务用TorchServe或者Triton监控用Prometheus加Grafana。这些选择不是绝对的但背后的逻辑是一致的每个工具只解决一个明确的问题工具之间通过标准接口通信。3. 核心模块拆解与实操要点3.1 数据管道从原始数据到训练样本数据管道是整个体系里最不起眼但最重要的部分。我见过太多项目模型效果不好大家第一反应是调模型结构、调超参数折腾了几周才发现是数据管道里有个字段的编码错了。搭建数据管道的核心步骤数据接入确定数据源的类型和接入方式。批量数据用定时任务拉取流式数据用消息队列消费。这里的关键是幂等性——同一条数据重复消费不能产生重复样本。数据校验对每批数据做schema校验和统计校验。schema校验检查字段类型和必填项统计校验检查分布是否偏移。这一步能拦截80%以上的数据问题。数据清洗处理缺失值、异常值、重复值。这里没有通用方案必须结合业务理解。比如用户年龄字段出现200岁是直接删除还是截断取决于这个字段在模型里的重要性。特征工程把原始字段转换成模型可用的特征。这一步要特别注意训练和推理的一致性——训练时用的特征计算逻辑推理时必须一模一样否则会出现训练服务偏差。数据版本管理每次训练用的数据集都要有唯一版本号记录数据来源、处理逻辑、生成时间。这是后续复现实验和排查问题的依据。注意数据管道的每一步都要有数据质量监控。我通常会在管道的关键节点埋点记录通过率、延迟、异常数量等指标。一旦某个指标偏离历史基线立即告警。3.2 实验管理与模型注册实验管理解决的是我上次那个效果很好的模型是怎么训出来的这个问题。没有实验管理你的模型迭代就是一笔糊涂账。MLflow是我用得最顺手的实验追踪工具核心概念就三个实验Experiment、运行Run、制品Artifact。每次训练启动一个Run记录超参数、指标曲线、输出文件。Run归属于某个Experiment方便按项目或按任务分组。模型注册是在实验管理之上的进一步封装。当一个Run的模型通过了评估门槛就把它注册到模型仓库赋予一个版本号并标记状态Staging、Production、Archived。这样服务层只需要指定模型名称和版本号就能加载对应的模型文件。实操中容易忽略的一点是模型注册时一定要记录训练数据的版本号。否则当线上模型出问题时你无法回溯是哪个数据版本训出来的也就无法复现和修复。3.3 推理服务从模型文件到线上接口推理服务是AI工程里对工程能力要求最高的环节。模型文件本身只是一个二进制文件要把它变成能扛住线上流量的服务需要解决一系列问题。模型加载策略大模型加载慢不能每次请求都加载。常见做法是服务启动时预加载配合健康检查确保加载完成后再接流量。对于多模型场景可以用懒加载加缓存淘汰的策略。批处理与延迟的权衡批处理能提高吞吐但会增加延迟。我的经验是设置一个最大等待时间窗口比如10毫秒在这个窗口内积累的请求一起推理窗口结束立即执行。这样在吞吐和延迟之间取得平衡。资源隔离不同模型对资源的需求不同有的吃GPU显存有的吃CPU。用容器化部署给每个模型实例设置资源配额避免互相影响。版本管理与灰度发布新模型上线不能直接全量替换要先切一小部分流量做灰度。观察一段时间确认指标正常后再逐步扩大比例。这个过程需要服务层支持按权重路由。# 一个简化的批处理推理服务示例 import time from collections import deque from threading import Lock class BatchInferenceService: def __init__(self, model, max_batch_size32, max_wait_ms10): self.model model self.max_batch_size max_batch_size self.max_wait_ms max_wait_ms self.queue deque() self.lock Lock() def predict(self, input_data): with self.lock: self.queue.append(input_data) if len(self.queue) self.max_batch_size: return self._flush() # 等待窗口结束 time.sleep(self.max_wait_ms / 1000.0) with self.lock: if self.queue: return self._flush() def _flush(self): batch list(self.queue) self.queue.clear() results self.model(batch) return results这段代码只是一个示意实际生产环境要考虑线程安全、超时控制、错误处理等更多细节。但核心思想就是用时间换吞吐用窗口控延迟。3.4 可观测性让系统自己说话可观测性不是可选项是必选项。一个没有监控的AI系统就像在高速上开车没有仪表盘你永远不知道下一秒会不会爆缸。三个核心支柱日志记录系统运行中的离散事件。关键是结构化用JSON格式输出方便后续检索和分析。日志级别要合理使用ERROR级别必须触发告警。指标记录系统的连续状态。AI系统特别要关注的是模型指标准确率、召回率、AUC等和系统指标QPS、延迟、错误率、资源利用率。模型指标下降往往比系统指标异常更隐蔽需要专门监控。追踪记录一个请求在系统中的完整流转路径。在微服务架构下一个推理请求可能经过网关、预处理、模型服务、后处理等多个环节追踪能帮你快速定位瓶颈。实操心得模型指标监控要设置动态基线而不是固定阈值。因为业务流量有周期性波动固定阈值要么误报太多要么漏报严重。我通常用过去7天同时段的数据计算均值和标准差超出3倍标准差才告警。4. 完整实操流程从零到一搭建最小可用系统4.1 环境准备与依赖安装假设你有一台带GPU的Linux服务器我们从最基础的环境开始。首先确认GPU驱动和CUDA版本nvidia-smi输出里能看到Driver Version和CUDA Version。记住CUDA版本后面装深度学习框架时要对应。然后创建Python虚拟环境。我强烈建议用conda而不是venv因为conda能管理非Python的依赖比如CUDA库conda create -n ai-eng python3.10 conda activate ai-eng安装核心依赖pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install mlflow dvc fastapi uvicorn prometheus-client这里PyTorch的版本要和CUDA版本匹配。cu118表示CUDA 11.8如果你的是12.1就换成cu121。装错了会报找不到CUDA设备的错误。4.2 数据管道搭建实操我们以一个图像分类任务为例搭建从原始图片到训练数据集的管道。第一步定义数据目录结构data/ ├── raw/ # 原始数据只读 ├── interim/ # 中间处理结果 ├── processed/ # 最终训练数据 └── metadata/ # 数据版本信息第二步用DVC初始化数据版本管理dvc init dvc add data/raw这会在data目录下生成.dvc文件记录数据的哈希值。把.dvc文件提交到git原始数据本身不需要进git。第三步写数据清洗脚本。核心逻辑是遍历原始数据做格式统一、尺寸调整、异常过滤import os from PIL import Image from tqdm import tqdm def clean_images(raw_dir, output_dir, target_size(224, 224)): os.makedirs(output_dir, exist_okTrue) valid_extensions {.jpg, .jpeg, .png} skipped 0 for root, _, files in os.walk(raw_dir): for fname in tqdm(files): ext os.path.splitext(fname)[1].lower() if ext not in valid_extensions: skipped 1 continue src_path os.path.join(root, fname) try: img Image.open(src_path).convert(RGB) img img.resize(target_size, Image.LANCZOS) # 用相对路径保持目录结构 rel_path os.path.relpath(src_path, raw_dir) dst_path os.path.join(output_dir, rel_path) os.makedirs(os.path.dirname(dst_path), exist_okTrue) img.save(dst_path, quality95) except Exception as e: print(f处理失败: {src_path}, 原因: {e}) skipped 1 print(f完成跳过 {skipped} 个文件)这个脚本看起来简单但有几个细节要注意。Image.LANCZOS是高质量的下采样算法比默认的NEAREST效果好很多。保存时用quality95而不是默认的75避免JPEG压缩引入额外噪声。用相对路径保持目录结构是为了后续能根据路径推断标签。第四步生成数据版本元信息import json import hashlib from datetime import datetime def generate_metadata(data_dir, output_path): file_count 0 total_size 0 hasher hashlib.md5() for root, _, files in os.walk(data_dir): for fname in sorted(files): fpath os.path.join(root, fname) file_count 1 total_size os.path.getsize(fpath) hasher.update(fname.encode()) metadata { version: hasher.hexdigest()[:12], created_at: datetime.now().isoformat(), file_count: file_count, total_size_mb: round(total_size / 1024 / 1024, 2) } with open(output_path, w) as f: json.dump(metadata, f, indent2) return metadata这个元信息文件会跟着数据集一起版本化后续训练时把它记录到MLflow里就能实现数据版本和模型版本的关联。4.3 模型训练与实验追踪数据准备好之后开始训练。这里的关键不是模型结构本身而是如何把训练过程标准化让每次实验都可追溯、可复现。import mlflow import mlflow.pytorch import torch import torch.nn as nn from torch.utils.data import DataLoader def train_model(config): mlflow.set_experiment(image-classification) with mlflow.start_run(): # 记录所有超参数 mlflow.log_params(config) # 记录数据版本 mlflow.log_artifact(data/metadata/version.json) # 构建模型、数据加载器、优化器 model build_model(config[model_name]) train_loader build_dataloader(config[train_dir], config[batch_size]) optimizer torch.optim.Adam(model.parameters(), lrconfig[lr]) criterion nn.CrossEntropyLoss() # 训练循环 for epoch in range(config[epochs]): model.train() total_loss 0 for batch_idx, (data, target) in enumerate(train_loader): data, target data.cuda(), target.cuda() optimizer.zero_grad() output model(data) loss criterion(output, target) loss.backward() optimizer.step() total_loss loss.item() avg_loss total_loss / len(train_loader) mlflow.log_metric(train_loss, avg_loss, stepepoch) # 每个epoch做一次验证 val_acc evaluate(model, config[val_dir]) mlflow.log_metric(val_accuracy, val_acc, stepepoch) # 保存模型 mlflow.pytorch.log_model(model, model) return model这段代码的核心价值在于所有影响结果的因素都被记录下来了。超参数、数据版本、代码版本MLflow自动记录git commit、环境信息全部关联到同一个Run上。三个月后你想复现这个实验直接找到对应的Run一键还原。4.4 模型服务化与接口开发训练好的模型要变成服务我用FastAPI做一层封装from fastapi import FastAPI, File, UploadFile from PIL import Image import io import torch import mlflow.pytorch app FastAPI() # 启动时加载模型 model None app.on_event(startup) def load_model(): global model model_uri models:/image-classifier/Production model mlflow.pytorch.load_model(model_uri) model.eval() model.cuda() app.post(/predict) async def predict(file: UploadFile File(...)): contents await file.read() img Image.open(io.BytesIO(contents)).convert(RGB) img img.resize((224, 224)) # 预处理 tensor torch.tensor(list(img.getdata())).float() / 255.0 tensor tensor.view(1, 224, 224, 3).permute(0, 3, 1, 2).cuda() with torch.no_grad(): output model(tensor) probs torch.softmax(output, dim1) pred_class torch.argmax(probs, dim1).item() confidence probs[0][pred_class].item() return { class: pred_class, confidence: round(confidence, 4) } app.get(/health) def health(): return {status: ok, model_loaded: model is not None}启动服务uvicorn main:app --host 0.0.0.0 --port 8000 --workers 2这里有几个工程上的考量。--workers 2表示启动两个工作进程能提高并发处理能力但每个进程都会加载一份模型显存占用翻倍。如果显存紧张就只用一个worker靠批处理提高吞吐。健康检查接口返回模型加载状态配合Kubernetes的liveness probe使用确保模型没加载完之前不接流量。4.5 监控指标埋点与告警配置服务跑起来之后要让它自己汇报状态。用prometheus-client埋点from prometheus_client import Counter, Histogram, Gauge, generate_latest from fastapi import Response import time REQUEST_COUNT Counter(inference_requests_total, Total inference requests, [status]) REQUEST_LATENCY Histogram(inference_latency_seconds, Inference latency) MODEL_CONFIDENCE Histogram(model_confidence, Model prediction confidence, buckets[0.1, 0.3, 0.5, 0.7, 0.9, 0.95, 0.99]) app.post(/predict) async def predict(file: UploadFile File(...)): start time.time() try: # ... 推理逻辑 ... REQUEST_COUNT.labels(statussuccess).inc() MODEL_CONFIDENCE.observe(confidence) return result except Exception as e: REQUEST_COUNT.labels(statuserror).inc() raise finally: REQUEST_LATENCY.observe(time.time() - start) app.get(/metrics) def metrics(): return Response(generate_latest(), media_typetext/plain)然后在Prometheus的配置文件里加上这个服务的抓取目标再在Grafana里配置面板。我通常至少配置这几个告警规则告警项条件严重程度服务不可用up 0 持续1分钟紧急错误率过高错误率 5% 持续5分钟紧急延迟过高P99延迟 500ms 持续5分钟警告置信度下降平均置信度 0.6 持续30分钟警告流量异常QPS偏离基线3倍标准差警告置信度下降这个告警特别重要。它往往意味着数据分布发生了变化模型开始遇到训练时没见过的样本。这时候需要触发模型重新训练的流程。5. 常见问题与排查技巧实录5.1 训练和推理结果不一致这是最经典也最让人头疼的问题。同一个输入训练时评估准确率95%上线后推理结果完全不对。排查思路按优先级排列检查预处理逻辑是否一致。训练时用的归一化参数、resize方式、通道顺序推理时必须完全相同。我遇到过训练时用RGB推理时OpenCV默认读成BGR的情况准确率直接掉到随机水平。检查模型是否处于eval模式。PyTorch的Dropout和BatchNorm在train和eval模式下行为不同。推理前必须调用model.eval()。检查数值精度。训练时用float32推理时如果用了float16可能会有微小差异。大部分情况没问题但某些对数值敏感的模型会出问题。检查版本对应关系。确认推理加载的模型版本和训练产出的版本一致。用MLflow的话检查模型URI里的版本号。我的经验是把预处理逻辑封装成一个独立的模块训练和推理都调用同一个函数。这样从根源上杜绝不一致。5.2 推理延迟突然飙升线上服务延迟飙升原因可能有很多。我总结了一个排查顺序第一步看是全局还是局部。如果所有请求都慢那是系统级问题如果只有部分请求慢那可能和输入数据有关。第二步看资源利用率。GPU利用率、CPU利用率、内存占用、网络IO哪个到了瓶颈。GPU利用率100%说明计算是瓶颈需要优化模型或加机器。GPU利用率低但延迟高说明瓶颈在数据预处理或后处理。第三步看请求特征。大请求和小请求的延迟分布是否不同。如果大请求特别慢可能是批处理策略不合理需要设置最大批大小。第四步看依赖服务。推理服务可能依赖特征存储、数据库等外部服务这些服务的延迟会传导过来。常见原因和解决方案对照表现象可能原因解决方案GPU利用率100%延迟高计算瓶颈模型量化、剪枝、加机器GPU利用率低延迟高数据预处理瓶颈预处理异步化、用GPU做预处理延迟周期性飙升批处理窗口设置过大减小最大等待时间特定请求延迟高输入尺寸异常输入校验、设置最大尺寸限制延迟逐渐升高内存泄漏检查是否有未释放的缓存5.3 模型效果随时间下降模型上线一段时间后效果变差这叫模型漂移。原因通常是数据分布发生了变化模型在新数据上表现不好。检测方法持续监控模型指标设置动态基线。当指标连续多天低于基线触发告警。应对策略分三个层次短期如果只是轻微下降可以通过调整推理阈值来缓解。比如分类模型可以调整置信度阈值把不确定的样本交给人工处理。中期收集新数据做增量训练。用新数据微调模型让它适应新的分布。长期建立定期重训练的机制。根据业务变化速度设置每周或每月的重训练周期。实操心得重训练不是简单地用新数据重新训一遍。要保留一部分旧数据防止模型在新数据上过拟合而丢失了旧知识。我通常用新旧数据7:3的比例混合训练。5.4 显存不足的排查与优化GPU显存不足是训练和推理都常遇到的问题。排查思路先确认是训练还是推理阶段出的问题。训练阶段显存占用主要包括模型参数、梯度、优化器状态、激活值。推理阶段主要是模型参数和激活值。优化手段按性价比排序减小批大小。最直接有效但会影响训练稳定性。可以用梯度累积来补偿。混合精度训练。用float16代替float32显存占用减半速度还能提升。PyTorch的torch.cuda.amp几行代码就能启用。梯度检查点。用计算换显存适合深层模型。模型并行。把模型切分到多张GPU上适合单卡放不下的大模型。ZeRO优化。DeepSpeed的ZeRO技术能把优化器状态、梯度、参数分片到多卡上显存占用大幅降低。推理阶段的显存优化还有额外手段动态批处理根据当前显存情况调整批大小模型量化用int8代替float16进一步压缩。6. 工程化落地的几个关键决策6.1 什么时候该引入新工具从零搭建的过程中你会不断面临要不要引入某个工具的决策。我的判断标准是当手写方案的维护成本超过学习新工具的成本时就该引入。举个例子一开始你用shell脚本做数据版本管理每次手动记录哈希值。当数据集数量超过10个、版本超过50个的时候手动管理开始频繁出错这时候引入DVC就是合理的。但如果你的项目只有两三个数据集用DVC反而是过度工程。6.2 单体和微服务的取舍AI系统初期建议用单体架构把所有功能放在一个服务里。理由是减少网络开销和调试复杂度。数据预处理、模型推理、后处理在一个进程里完成延迟最低出问题也容易定位。当出现以下信号时考虑拆分成微服务不同模块的扩缩容需求差异大。比如预处理是CPU密集型推理是GPU密集型混在一起浪费资源。不同模块的迭代频率差异大。预处理逻辑天天改推理服务很稳定混在一起每次改预处理都要重新部署推理服务。团队规模扩大需要按模块划分职责。拆分的时候注意一点先拆数据流再拆服务。确保每个服务有清晰的输入输出边界通过标准接口通信。6.3 成本控制的实操方法AI系统的成本主要在GPU资源上。控制成本的核心思路是提高资源利用率。具体手段弹性伸缩根据流量自动调整实例数量。流量低谷时缩容高峰时扩容。Kubernetes的HPA配合自定义指标可以实现。混部把推理服务和训练任务混部在同一批机器上。推理服务通常有资源空闲期训练任务可以利用这些空闲资源。关键是设置好资源配额和优先级。竞价实例训练任务对中断不敏感可以用竞价实例成本能降低60%到70%。配合checkpoint机制中断后从最近的检查点恢复。模型压缩量化、剪枝、蒸馏减小模型体积和计算量直接降低推理成本。我自己的经验是一个中等规模的AI系统通过上述手段能把GPU成本降低40%以上。关键是持续监控资源利用率找到浪费的环节。6.4 团队协作的规范建设AI工程不是一个人的事需要算法工程师、数据工程师、后端工程师、运维工程师协作。协作的基础是统一的规范和接口。我们团队执行的几条硬性规范所有模型必须通过模型注册中心上线不允许直接从训练脚本部署到生产。所有数据必须版本化训练脚本必须声明依赖的数据版本。所有服务必须暴露健康检查和指标接口否则不允许上线。所有实验必须记录到MLflow包括失败的实验。失败的实验同样有价值能避免后人重复踩坑。这些规范看起来繁琐但执行下来团队的协作效率会大幅提升。新成员入职照着规范走一遍就能理解整个系统的运作方式。7. 我踩过的几个印象深刻的坑第一个坑是关于数据泄露的。早期做推荐模型特征里包含了一个用户过去7天点击次数的字段。离线评估AUC 0.85上线后效果惨不忍睹。排查了很久才发现这个特征在计算时用了未来数据——训练样本的时间戳是T但特征计算时用了T1的数据。这种错误在离线评估时发现不了因为离线数据是静态的但线上是实时的特征值完全不同。第二个坑是关于模型序列化的。用pickle保存了一个自定义的PyTorch模型本地加载没问题。部署到服务器上报找不到自定义类的错误。原因是pickle序列化依赖类的定义路径本地和服务器的目录结构不同。后来改用torch.save(model.state_dict())只保存权重模型结构在代码里定义就再也没出过这个问题。第三个坑是关于批处理超时的。推理服务设置了批处理窗口但没有设置最大等待时间。结果流量低谷时一个请求进来服务一直等凑够批大小等了30秒才返回。用户直接投诉。后来加了最大等待时间不管批有没有满时间到了就执行。这些坑的共同特点是在开发环境都不会暴露只有上了生产才会触发。所以我的建议是AI系统上线前一定要做压力测试和异常场景测试模拟流量低谷、流量尖峰、依赖服务不可用等情况。8. 后续可以继续深入的方向这套从零搭建的体系跑通之后有几个方向可以继续深入。模型性能优化研究更高效的推理引擎比如TensorRT、ONNX Runtime把推理延迟再降一个数量级。研究模型量化技术在精度损失可控的前提下大幅降低计算成本。自动化机器学习引入AutoML做超参数搜索和模型结构搜索减少人工调参的工作量。但要注意AutoML不是银弹它搜索出来的模型往往可解释性差在需要解释性的业务场景要谨慎使用。联邦学习在数据不能出域的場景下用联邦学习让多个参与方协同训练模型。这个方向在隐私敏感的业务里越来越重要。边缘部署把模型部署到边缘设备上减少网络延迟提高响应速度。挑战在于边缘设备的计算资源有限需要极致的模型压缩和优化。我自己目前重点在探索推理优化和成本控制这两个方向。在实际业务里这两个方向的投入产出比最高。模型效果提升10%可能需要几周的实验但推理成本降低50%可能只需要几天的工程优化。最后分享一个我在实践中总结的原则AI工程的核心不是追求最先进的技术而是追求最稳定的系统。一个用成熟技术搭建的稳定系统价值远大于一个用前沿技术搭建的脆弱系统。从零搭建的意义就是让你有能力判断什么是成熟技术什么是前沿但还不稳定的技术以及什么时候该用什么。