直接跑通一个开源模型demo和真正把它变成稳定、可靠、能交付的业务系统中间隔着的正是这十多年里我踩过最深的坑。最近“ai-engineering”这个热词被讨论得很多说白了它就是要把算法工程师的“灵光一现”变成软件工程师的“长期可维护”。这篇博文不聊论文复现也不谈大模型原理就老老实实从零讲清楚一个没有AI工程经验的人怎么一步步搭出一套能跑在真实业务里的AI服务。不管你是后端想转AI还是算法工程师想补工程课又或者是创业团队里那个被安排“先做个AI原型”的倒霉蛋这篇都适合你。我列出的每个模块都有可复现的步骤、选型理由和踩坑记录照着做就行。1. 先搞清楚AI工程到底在解决什么问题1.1 从“跑通模型”到“稳定服务”的鸿沟我刚入行的时候觉得AI项目就是训练一个准确率高的模型。直到第一次把一个图像分类模型交给后端同事对方问了我三个问题这个模型接口的延迟是多少异常输入怎么返回模型版本更新了老调用方怎么办我当场愣住了。这三个问题就是AI工程和算法Demo的分水岭。算法Demo关心的是“能不能跑”AI工程关心的是“能不能持续跑、能不能被维护、能不能被上下游依赖”。一道API接口背后需要考虑延迟控制、错误码规范、版本兼容、数据幂等、资源调度这些都不是模型训练本身能解决的。说白了AI工程是用软件工程的纪律约束AI研发的混乱。混乱来自哪里来自模型是概率系统不是确定性函数。同样的输入模型版本一换输出可能就变了显存稍微吃紧推理速度可能就从50ms变成500ms训练数据稍有偏差线上效果就漂移。工程化要做的就是把这些“不确定性”隔离在可控范围内。1.2 AI工程的三个核心维度数据、模型、系统我习惯把AI工程拆成三层看拆完之后你会发现真正难的不是模型而是数据和系统。第一层是数据层包括数据采集、清洗、标注、版本管理、特征存储。很多团队死在不是模型不够好而是训练数据和评估数据混在一起模型效果根本无法客观衡量。数据层要解决的是“用什么学、怎么评”的问题。第二层是模型层包括模型选型、训练/微调、评估、打包、版本管理。这里的关键不是追求顶会模型而是建立一套“怎么选出合适模型”的流程。开源的、商业API、自研的各有各的适用场景。注意模型层最常见的坑是“用最新模型替代在线的成熟模型”我见过太多团队因为想追新模型把一个稳定运行两年、业务逻辑经过大量适配的模型随意替换结果线上效果没提升反而引发连锁故障。第三层是系统层包括模型服务化、推理优化、监控告警、CI/CD、灰度发布。这一层决定了AI能力能不能被业务稳定使用。新手最容易犯的错误是只盯着模型层以为训练出一个高精度模型就万事大吉。实际上系统层的工程债会在你上线后以最难看的方式还回来。2. 零基础起步搭建你的第一个AI工程骨架2.1 用Python虚拟环境与依赖管理打好基础AI工程起步第一个要过的坎是环境管理。我见过太多“在我电脑上是好的”这种甩锅现场根因就是依赖混乱。Python的虚拟环境工具不少venv、virtualenv、poetry、conda各有各的适用场景。我个人的选择是项目级依赖用poetry跨项目统一运行环境用conda。poetry的优点在于能把依赖锁定到具体版本避免“昨天还能跑今天就不行”的玄学问题。conda则擅长处理CUDA、cuDNN这些非Python原生依赖。# 创建conda环境指定Python版本 conda create -n ai-eng python3.10 -y conda activate ai-eng # 初始化项目用poetry管理依赖 poetry init poetry add torch --index-url https://download.pytorch.org/whl/cu118 poetry add fastapi uvicorn pydantic这里有个实操细节如果你的机器有NVIDIA显卡安装torch时务必匹配CUDA版本。用nvidia-smi查看驱动支持的CUDA版本再选择对应的torch安装源。装错了的结果就是“import torch报错”或者“在GPU上跑得比CPU还慢”。提示建议把requirements.txt和poetry.lock都提交到Git仓库。前者是给人看的后者是给机器看的。我曾经用一个老项目的lock文件在三天后重新部署秒级恢复环境同事还在痛苦地手动装包。2.2 一个最小但完整的AI服务长什么样环境就绪后第一件事不是去调模型而是搭一个最小可用的服务骨架。我建议用FastAPI它在AI工程领域已经事实上成了标准异步支持好、自动生成API文档、类型校验方便。以下代码是一个完整的“最小AI服务”包含模型加载、推理接口、健康检查和错误处理# app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field import torch import time import logging logger logging.getLogger(__name__) app FastAPI(titleAI Demo Service) # 全局加载模型避免每次请求都重复加载 device torch.device(cuda if torch.cuda.is_available() else cpu) model load_pretrained_model().to(device).eval() class InferenceRequest(BaseModel): text: str Field(..., min_length1, max_length512) class InferenceResponse(BaseModel): label: str confidence: float latency_ms: float app.get(/health) def health(): return {status: ok} app.post(/predict, response_modelInferenceResponse) def predict(req: InferenceRequest): start time.perf_counter() try: inputs preprocess(req.text) with torch.no_grad(): logits model(inputs) label, confidence postprocess(logits) latency_ms (time.perf_counter() - start) * 1000 return InferenceResponse(labellabel, confidenceconfidence, latency_msround(latency_ms, 2)) except Exception as e: logger.exception(inference failed) raise HTTPException(status_code500, detailinference failed)别看代码简单有几个细节值得说全局加载模型如果每次请求都重新加载一次模型延迟会从毫秒变成秒级。模型加载是重量级操作必须发生在服务启动阶段而不是请求阶段。异常处理务必catch所有异常返回统一错误码否则模型一个OOM能让整个服务崩溃——而前端只会收到一个名为“Internal Server Error”的迷之信息。健康检查/health接口是做K8s存活探针、负载均衡健康检查的基础没有它你在容器里挂没挂没人知道。3. 核心环节模型接入、评估与迭代的实操闭环3.1 模型选型与封装别把模型直接写死在业务代码里模型选型是AI工程最关键的决策之一。我看到太多团队一上来就用最大、最先进的模型不考虑成本、延迟和可维护性。真正务实的做法是根据业务容忍度和资源预算选模型不是用模型定义业务。选型的时候问自己三个问题延迟天花板是多少成本预算多大效果底线在哪如果是工业OCR识别一个轻量级的PaddleOCR模型可能比一个上百G的大模型更合适如果是开放域对话那么GPT类API可能比自研模型更便宜、更快落地。选完之后一定要做一层抽象封装不要让业务代码直接依赖某个模型# model_interface.py from abc import ABC, abstractmethod class BaseClassifier(ABC): abstractmethod def predict(self, text: str) - dict: 返回 {label: str, confidence: float} class LocalBertClassifier(BaseClassifier): def predict(self, text: str) - dict: # 本地模型推理 ... class ApiClassifier(BaseClassifier): def predict(self, text: str) - dict: # 调用远程API内部处理网络、重试 ...这么做的好处你换模型时只需新写一个类业务层一行不改这是“可维护性”最直接的体现。我踩过的坑是把模型调用逻辑写在视图函数里后来换模型改了两天还差点漏掉一个异常分支。3.2 评估先行建立自己的回归测试集eval setAI工程和普通软件开发最大的区别在于普通软件有明确的“对错”AI系统只有“好坏”。你没法断言某条预测是绝对正确的只能通过评估集数据来量化好坏。我强烈建议在开始任何模型开发之前先花时间构建回归测试集eval set。这个集合不是训练集它是人工标注、长期不变的“标准答案”。每次模型迭代都要在这个集合上重新评估确保新版本至少不比旧版本差。# evaluate.py import json from model_interface import LocalBertClassifier def load_eval_set(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: return json.load(f) def evaluate(model, eval_set): correct 0 total 0 for item in eval_set: pred model.predict(item[text]) total 1 if pred[label] item[label]: correct 1 return correct / total model_a LocalBertClassifier() print(accuracy:, evaluate(model_a, load_eval_set(eval_set.json)))这个脚本看起来简单但是它是AI迭代的基石。没有评估集你会陷入“这周觉得模型变好了下周又觉得变差了”的主观幻觉。有了评估集每次改动都有数字兜底。注意评估集一旦确定不要频繁改动。它应该是业务规则和核心诉求的静态切片而不是跟着你的心情走。最忌讳今天加一条、明天删一条那样你的评估曲线根本没有意义。3.3 数据标注与闭环迭代的落地做法数据标注是AI工程里最“脏”的活儿却也是最不能省的。很多团队试图用模型自动标注来加速但初期没有可靠模型时自动标注就是垃圾进垃圾出。我推荐的节奏是第一版用小批量人工标注比如500条快速上线一个baseline然后利用baseline做“主动学习”把置信度低、熵值高的样本挑出来人工复核再补充到训练集里。这样标注量最小、模型提升速度最快。用标注平台Label Studio等统一管理别用Excel传文件版本会乱。标注规范写清楚比如“观点极性”遇到模棱两可怎么处理避免标出来的数据口径不一。定期做标注一致性检验随机抽5%样本让不同人标看看一致率低于80%就说明规范本身有问题。闭环迭代的本质就一句话把线上错误样本回流到训练/评估流程形成一个飞轮。这一步做扎实了模型的效果会像滚雪球一样越滚越好做不好就是反复在同一个坑里摔。4. MLOps入门从手工部署到可靠的工程化发布4.1 五步建立可复现的训练/推理流程很多小团队做AI项目训练在本地部署靠“邮件发送模型文件”全靠人和人之间的信任。要走向工程化其实只需要五步第一步代码版本化。训练代码、推理代码、提示词配置全部进Git没有任何例外。特别是“提示词配置”它披着文本配置的外衣实际是业务逻辑的浓缩不版本化等于裸奔。第二步数据版本化。模型输出的差异往往来自数据差异。用DVC或者简单的哈希记录数据集版本。数据没变模型理论上就能复现。第三步模型版本化。这里指的不是商业化平台而是简单约定模型文件名带上版本号和训练日期比如bert_cls_v3_20240401.pt。第一时间能定位到哪个模型在线上跑。第四步依赖锁定。第2.1节提到的poetry.lock就是干这个的。加一行poetry export -f requirements.txt --output requirements.txt把锁文件导出部署环境就能彻底锁定。第五步脚本可重复执行。把训练和评估都写成可执行脚本参数通过配置文件传入而不是每次手动改代码。# 一条命令完成评估 python evaluate.py --model-name bert_cls_v3_20240401.pt --eval-set eval_set_v2.json这套五步流程做完你的AI项目至少对得起“工程”两个字了。很多人嫌麻烦但等到线上模型出了问题需要回滚你才知道这些“麻烦”在救命。4.2 监控线上系统真正需要看的指标AI服务和普通服务不同除了常规的QPS、延迟、错误率还要监控模型层面的指标。我选监控指标的原则是宁可少看也要看得精。我每次做AI服务第一个加的是输入分布漂移监控。模型效果变差从来不是一夜之间而是线上输入的数据分布逐渐偏离训练分布。比如训练数据里纯文本长度均值在100字以内线上现在平均300字那你等着瞧效果很快就会崩。第二个必加的是置信度分布。即使模型没有标错它开始给出大量“骑墙”的置信度比如都在0.5附近说明模型正在失去判别力。通过一个简单的直方图肉眼就能发现异常。第三个是推理延迟直方图。别只看P50要看P99。P50很稳定但P99经常飘到几秒这往往意味着偶发性的资源争抢或CPU/GPU分配不均会影响用户体验。工具方面轻量方案用PrometheusGrafana自建推送gateway成本低又灵活不想折腾就用云厂商的监控服务。但是前提是必须把指标反馈到一个所有人都能看得见的看板上而不是堆积在日志里无人问津。4.3 提示词工程与RAG的工程化落地要点进到大模型应用时代提示词工程和检索增强生成RAG成了AI工程的新核心。别被“提示词”这个名字迷惑它本质是代码只是用自然语言写的代码也要遵循工程规范。RAG的工程化最核心的是文档切分策略和召回质量。我见过太多团队把几千页的PDF直接丢进向量库结果检索出来的片段牛头不对马嘴。合理的做法是按语义段落切分而不是按固定字数硬切。固定字数切分很容易把一段话的因果关系切断检索出来是碎片。给每个切分块加元数据来源、章节、时间方便溯源和过滤。检索阈值。别只看top-k设定一个相似度下限低于下限直接告诉用户“未找到相关内容”避免模型硬编答案。# rag_example.py def retrieve_and_generate(question: str) - str: query_embedding embed(question) candidates vector_db.search(query_embedding, top_k5, threshold0.75) if not candidates: return 未找到相关内容 context build_context(candidates) prompt f基于以下资料回答问题\n{context}\n\n问题{question} return llm.generate(prompt)这段代码里threshold0.75就是安全阀。宁可少答不要瞎编——这是大模型应用里最值钱的一句话。让模型说“不知道”远好过让它编造成灾难性错误。5. 常见问题与排查技巧实录5.1 依赖冲突与环境复现问题这个问题能排在我踩坑榜第一名。典型场景昨天还能跑的代码今天因为某个依赖升级了突然报错。排查思路先看是不是依赖变了再看是不是数据变了最后才怀疑代码。很多时候代码一行没动纯粹是pip install的时候悄悄升级了间接依赖。解决办法很简单所有环境统一用lock文件重建别在新旧环境里来回横跳。CI里用pip install -r requirements.txt而lock文件要用poetry.lock或pip-tools维护保证每次构建的依赖完全一致。实操心得我在公司推进过一个约定——“任何环境不能直接pip install新增包”必须进pyproject.toml重新锁定。刚开始大家嫌麻烦后来环境出问题的次数直线下降。5.2 显存与内存泄漏模型服务跑两三天显存占用一路飙升到OOM是推理服务最常见的故障。排查的时候先怀疑是不是输入数据导致动态shape暴增再看推理代码里是否有累积计算图的操作。典型的错误写法是在推理时忘了with torch.no_grad()导致每次forward都构建计算图显存持续累积。更隐蔽的是通过timeout重试每次重试都创建一次新的GPU上下文旧的没被GC。# 推荐写法 with torch.no_grad(): for batch in dataloader: output model(batch) # 不要累积output变量用完即释放如果是OpenAI API等远程调用注意连接池的管理。每次请求新开一个连接不只是慢还可能把系统文件句柄耗尽应用“假死”。5.3 模型输出不稳定与返回空值这是大模型应用最常见的线上故障。同一个问题今天答得好好的明天开始输出空值或胡言乱语。排查顺序第一检查输入预处理的截断逻辑。很多模型对输入长度有硬限制超过限制的部分被静默丢弃输出自然变差。第二检查生成参数是否固定。温度、top_p哪怕变化0.1输出风格也可能剧烈变化。不固定的推理参数就是不确定的结果。第三检查远程API的“最大输出token”。很多人在接GPT类API时不设置max_tokens默认值可能只有16个token能返回什么有用的东西才怪。直接把max_tokens设置到256或更高效果立竿见影。5.4 数据隐私与安全底线做AI工程数据合规是红线我这里多说几句必须注意的。不可把用户隐私数据未经脱敏就发送到第三方大模型API。用户手机号、身份证号、地址等字段要么脱敏要么企业内部部署自研模型处理。日志里不要打印原始请求体和响应体要打印就打印截断版。我见过同事为了排查问题把用户全文对话打进了日志后来被安全团队约谈这些教训都真实存在。模型文件本身也要做版本和权限控制不能谁都能下载替换特别是企业内部的微调模型泄露出去相当于泄露业务策略。安全合规不是AI工程的全部但一票否决。别的方面可以慢慢补这里不能侥幸。6. 我的一些亲身体会回头看在AI工程这条路摸爬滚打的这几年最深的体会是AI工程不是算法工程师一个人的独角戏而是一套协作流水线。数据工程师要保证数据质量后端要保证服务稳定性算法要保证模型效果运维要保证资源调度所有人都在为同一个目标——让模型在真实业务里稳健输出——贡献力量。另一个体会是别把“工程化”理解成腾出一堆基础设施建设时间而无视业务优先级。工程化的目的是让业务迭代更快不是让你沉迷于搭建完美的流水线。我见过团队花三个月搭了华丽的MLOps平台业务的需求却一条都没跑通这就本末倒置了。如果你现在正准备从零开始做AI工程我的建议是从最小的闭环做起拿到数据标注500条训练一个小模型套一个FastAPI服务上线跑通监控起来。先让整条链路跑通再一步步优化每个环节千万别一上来就建平台、引框架那样大概率会死在“准备阶段”。最后分享一个实用小技巧在做任何AI服务的线上发布之前先跑一周的影子模式——把新模型的预测结果跟旧模型的结果同时记录只对比、不切流。这周的数据能告诉你新模型到底行不行比你在评估集上看到的数字真实得多。我靠这一招劝退了好几次冲动的模型升级计划也给团队省下了不少不必要的线上事故。