1. 先说清楚AI Engineering 到底在做什么很多人一听“AI 工程”第一反应是这玩意很高深动不动就要设计神经网络。实际干久了你就会发现AI Engineering 的重点根本不是“AI”而是“Engineering”。这个词拆开看AI 是技术手段工程是系统化地交付价值的方式。AI 工程师干的事情不是发明什么新算法而是把一个 AI 想法变成一条完整、可靠、能持续运转的流水线从原始数据进来到中间的数据清洗和特征处理再到模型训练与评估最后上线成用户能用的服务这中间的每一个环节都算工程问题。我自己是传统后端开发转过来的早期在这上面绕了非常多的弯。最开始我只会照着一个 Notebook 把经典模型调通数据集一换立刻抓瞎后来被业务逼着上线了一个推荐排序模型才有机会把训练、上线、监控这套链路真正走了一遍。走完以后最大的感受是市面上百分之八十的教程都在教“模型怎么跑”但真正让你在团队里值钱的偏偏是那些没人教的“模型怎么长期可靠地跑”。这里有一个特别容易混淆的点就是 AI 工程师、数据分析师、算法研究员这三种角色的分工。我用一张表说清楚角色核心交付物主要工作成功标准数据分析师报表、业务洞察统计、可视化、AB 分析结论能被业务采纳算法研究员新模型、新论文结构设计、损失函数创新公开指标刷新AI 工程师可运行的 AI 系统数据管线、训练调优、服务化、监控线上指标达标、服务可靠、成本可控很多团队的问题就在这把数据分析的活扔给算法研究员再把算法的东西丢给后端工程师两边都在猜对方想要什么。AI 工程恰恰是那个把两边焊在一起的角色——你要懂模型但不能只懂模型你要写代码但不能只会写接口。目标只有一个让模型像一个正经软件一样被交付、被维护。为什么我要强调“from scratch”现在的新手其实很幸福因为能学的东西太多。但同时也是不幸的因为知识极度碎片化。今天跟一个教程跑通了手写数字识别明天跟另一个教程调通了一个聊天机器人然后换一个真实的业务场景立刻就不会了。这是典型的“背答案式学习”本质上你只学会了流程没学会判断流程为什么这么走。from scratch 的意思不是让你从零发明轮子而是让你对整条链路有真正的掌控力。出了问题能定位到具体环节这才是“会”和“看过”的分界线。要用这个标准来检验自己我给你四个闭环数据闭环能理解数据分布、清洗数据、构造特征并且知道怎么避免数据泄漏建模闭环会调库也知道损失函数、指标和过拟合之间的联系服务闭环模型能被线上调用能更新、能回滚、能监控评估闭环知道什么指标代表做得好而不是只盯着训练损失一路往下掉。这四个闭环你可以理解成开车的四个基础操作你不会说“我只会踩油门”就算会开车AI 工程也一样。2. 从零起步一套够用的知识地图2.1 编程基础Python 只是起点学 AI 工程编程语言基本默认是 Python这个没什么好争的。但我要提醒你Python 语法只是起点你真正要具备的是程序员的思考方式错误信息能看懂、代码能调试、逻辑能拆成小块。我见过不少同学把 NumPy 的维度错误当成天书其实那行错误信息已经把每个数组的形状都标出来了只是你下意识不想读英文报错。具体来说你至少要掌握这些Python 的基础数据结构字典、列表、集合以及它们的适用场景函数怎么写、变量作用域怎么回事用 IDE 的断点调试或者至少会 pdbGit 的基本操作commit、branch、merge、rebase别让你的代码永远只是“本地文件”还有 shell 的基本命令find、grep、jq 这种处理文件和数据的时候能救命。我经常打一个比方编程能力就像一个房子的地基你不需要先把地基修得能扛核弹才开始装修但你至少要保证两层楼的承重没问题。对于 AI 工程来说能写 300 行以内结构清晰的模块化代码就算及格线了。不要等你觉得自己“编程完全练好了”再碰 AI那样你会永远等不到那个时刻。边做边补反而最有效率。2.2 数学到底要学到什么程度数学是劝退很多人的地方但它恰恰是区分“调参侠”和“工程师”的分水岭。我比较务实建议你按这三块来补每一块都只学跟 AI 最相关的部分。线性代数重点是向量、矩阵乘法、矩阵的形状变化规则。为什么形状这么重要因为神经网络的前向传播本质上就是一连串矩阵乘法和非线性变换你在代码里看到的(batch_size, seq_len, hidden_dim)这些维度背后全是线性代数。我自己的经验是把矩阵乘法的规则想清楚了PyTorch 里的view、permute、squeeze这堆操作你就会用得很顺不然就是在瞎试。微积分重点是偏导数和链式法则。神经网络的反向传播说白了就是链式法则的工程实现。你不需要能手推所有公式但最好能看懂求导符号。不然的话学习率为什么太大不行、梯度为什么会消失、梯度裁剪在做什么你只能靠猜。靠猜偶尔能蒙对但蒙不对的时候你会浪费大把时间。概率与统计这部分我认为对 AI 工程最重要。至少要知道正态分布和常见离散分布什么样期望和方差在说什么条件概率和贝叶斯公式怎么用以及抽样偏差这个概念。机器学习几乎所有的评估指标背后都是统计思想。你问“这批样本的准确率是 91%它可靠吗”本质上是一个统计学问题。一句话总结这块数学不是为了让你考试是为了让你听得懂模型在做什么、模型为什么错。遇到不会的公式先问自己三个问题——它在算什么、为什么需要它、不了解它会影响我判断哪个环节吗。很多数学细节其实是可以按需补的。2.3 经典机器学习绕不开的地基这里我给一个很多过来人都认可的建议先学经典机器学习再学深度学习这个顺序比反着来省时间。理由很简单经典机器学习把很多核心概念放在了一个更小、更透明的模型里你看得见每个参数在干嘛而深度学习模型动辄几百万个参数你对问题的判断经常被黑箱挡住。你需要掌握这几个核心概念监督学习和无监督学习的分法过拟合和欠拟合是什么怎么识别偏差与方差的权衡交叉验证是怎么回事以及一组最常用的评估指标准确率、精确率、召回率、F1、AUC。算法方面线性回归、逻辑回归、决策树和随机森林、GBDT、K 均值聚类这几种够你形成基本盘了。我知道现在流行说“经典机器学习没用直接学大模型”这种说法我不太认同。你在后面用神经网络苦苦排查的很多问题本质上还是过拟合、数据不平衡、特征泄漏这些经典问题只是换了一个更复杂的模型壳子。把经典环节吃透等于给你的排查能力装了底座底座不牢后面全飘。2.4 LLM 时代的新增知识大语言模型确实把很多事的门槛又降低了一截但它没有取消工程问题只是把工程问题转移了地方。作为 AI 工程师你需要对几个新概念有基本的直觉。Tokenization模型看的是 token 而不是“字”一个中文词可能被拆成一到多个 token计费成本和上下文长度都跟它有关。Context window也就是上下文窗口背后是注意力机制的计算复杂度问题这也是为什么模型“记不住”长文档的直接原因。Embedding它把一段文字变成一串向量用距离来衡量语义相似度这是检索和聚类的核心工具。Prompt engineering它不是什么玄学而是你跟模型之间的一套沟通协议同样的意思换一种说法输出质量会有明显差异。然后是两个经常被混在一起的操作Fine-tuning 和 RAG。很多人一上来就想微调模型但我自己的原则是百分之九十的场景不该一开始就微调。业务数据量不够、需求变化快、微调成本高这些问题都会在项目中期反咬你一口。RAG 先做起来效果可能已经能覆盖大部分需求。至于什么时候才该微调后面我会在实操章节展开。3. 工程环境怎么搭少踩一半坑3.1 Python 环境隔离第一堂生存课环境问题排在我遇到的坑里的第一名几乎每个新手都在这里死过一次。我最早的时候图省事所有项目都直接装进系统 Python结果某一天一个项目要 pandas 2.0另一个项目只兼容 pandas 1.5两个库在同一个环境里打架我花了一整天才把环境恢复原状。那之后我就老老实实用虚拟环境再也没受过这种罪。用 conda 或者 pyenv 都行我习惯用 conda简单直接conda create -n ai-engineering python3.11 conda activate ai-engineering pip install --upgrade pip pip install numpy pandas scikit-learn matplotlib jupyter这里有几个小经验第一一个项目一个环境不要怕麻烦第二每次装包不要只写包名尽量固定版本至少固定大版本第三项目里放好requirements.txt或者更好的依赖锁定文件这样换机器、换同事电脑都能在几分钟内复现。环境这件事前期多做一分钟事后面省几个小时。3.2 数据与实验版本管理代码可以用 Git 管理但数据和模型怎么办这个问题很多教程根本不提真做工程的时候却是命门。数据可能有几十 GB模型文件动不动几百兆Git 根本管不了。更麻烦的是数据和模型一旦变化之前所有离线实验的记录就失去了意义。我现在的做法是数据用 DVCData Version Control或者至少用带 hash 的文件目录来管理版本数据每次更新记下一个唯一的版本号实验记录用 MLflow 或者 Weights Biases把每次训练用的数据版本、代码 commit、超参数、模型输出全部记在一起。这样等到你要回头看“上个月的模型为什么比这个月好”的时候才不会两眼一抹黑。我为什么强调这件事因为大部分 AI 项目翻车不是模型不行而是“不知道为什么结果变了”。没有实验记录你连定位变因都做不到。这就像一个做饭的人从来不记菜谱今天好吃明天难吃你根本不知道哪一步出了问题。3.3 Notebook 和脚本的边界Jupyter Notebook 用来做探索性分析真的很好我到现在也经常用。但我要说一句得罪很多人的话不要把你整个训练流程写在一个大 Notebook 里。Notebook 天然适合“给人看”不适合“给系统跑”。一旦你的代码要有自动化、要有定时任务、要上生产环境Notebook 就会变成灾难单元格执行顺序乱了都不知道。我的建议非常明确Notebook 只做快速探索和可视化正式逻辑写进 Python 脚本和模块。项目结构可以长这样ai_engineering_project/ ├── data/ │ ├── raw/ │ └── processed/ ├── src/ │ ├── data.py │ ├── features.py │ ├── train.py │ ├── evaluate.py │ └── serve.py ├── models/ ├── notebooks/ │ └── exploration.ipynb └── tests/同时对features.py、evaluate.py这种核心函数写一点 pytest 单测逻辑越关键越值得测。代码格式化用 ruff 这类工具不用纠结格式问题。这套习惯看起来不起眼但它能让你的项目从“能跑的 demo”变成“能维护的系统”区别非常大。3.4 模型服务化的基础认知模型的最终归宿是线上服务。我见过太多模型在离线测试指标很好一上线就崩因为模型服务化和普通后端服务有很大的区别。最简单的入门方案是 FastAPI它把请求校验、并发、接口文档都帮你处理好了。一个最基本的预测接口长这样from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI() model joblib.load(models/best_model.joblib) class PredictRequest(BaseModel): features: list[float] app.post(/predict) def predict(req: PredictRequest): x [req.features] pred model.predict(x)[0] return {prediction: int(pred)}这只是一个骨架实际要考虑的更多批量推理还是实时推理、GPU 服务怎么管理显存、模型文件放在哪里、怎么在不停机的情况下切换模型版本。这些内容不用第一天全懂但你一定要知道它的存在。我的经验是第一次把模型接进 API 的体验会让你对“模型只是一个软件组件”这句话有完全不同的理解。4. 第一个能上线的端到端项目4.1 怎么选一个合适的项目理论学习到最后一定要落到项目上否则都是空谈。但项目选择有门道我强烈建议你选一个“全班人都做过”的标准题目。别觉得标准题目没意思正因为全世界都做过你才能找到海量的对照对象出了问题也有地方查。最忌讳的是一上来就选那种业务方自己都说不清要什么的需求你会被业务问题的模糊性淹没根本分不清是模型的问题还是需求的问题。我最推荐的入门级端到端项目是用户流失预测也叫 churn prediction。它是一个标准的二分类问题数据一般包含用户画像、使用行为、时间信息结果可以定义为“未来三十天是否活跃”。它有明确的时间顺序避不开特征泄漏的坑有类别不平衡的问题还可以部署成一个 API 供业务方查询。麻雀虽小五脏俱全能把 AI 工程的坑踩个大半。4.2 数据清洗与特征工程大部分时间花在这真实项目里模型训练本身可能只占百分之二十的时间剩下百分之八十全在数据上。数据清洗的第一步是看缺失值、看类型、看分布用 pandas 扫一遍把明显的错误值处理掉。第二步才是特征工程流失预测里经常要做的操作包括把用户行为聚合到周级或月级计算活跃天数、平均使用时长、最近一次使用距今天数等。这里特别要提一个魔鬼细节标签和特征窗口要严格分开。假设你定义“流失 未来三十天没有活跃动作”那么你构造特征的时候只能使用“当前时刻之前”的数据绝不能用未来数据来构造特征。否则就像考试的时候偷看了答案训练时模型表现很好上线后立刻原形毕露——因为线上预测的时候未来数据根本不存在。下面是我习惯性做法的简化版import pandas as pd def build_features(df_behavior, df_user): # 只使用观察点 dt 之前 30 天内的行为数据 recent df_behavior[df_behavior[dt] observation_date] features recent.groupby(user_id).agg({ active_days: sum, session_count: count, last_active_gap: min, }) features features.join(df_user.set_index(user_id), howleft) return features注意标签构造的时候要再往后看三十天。这两个窗口混淆是新手最容易犯且最难自查的错误因为模型指标看上去非常好但永远上不了线。4.3 训练与评估别让准确率骗了你流失预测这种问题类别天然不平衡。比如只有百分之十的用户最终流失了那么一个“永远预测不流失”的模型也能跑出百分之九十的准确率看起来很美实际上屁用没有。所以评估指标一定要结合问题来选这类二分类场景我一般同时关注精确率、召回率、F1 和 AUC。精确率回答“你说要流失的人里真流失的比例”召回率回答“真流失的人里你找到了多少比例”。你要根据业务取舍如果是给运营做定向挽回召回率太低的模型没有意义如果是做高风险预警精确率太低的模型会淹没真正的信号。训练时用分层抽样划分训练集、验证集和测试集再用交叉验证看误差的波动范围。from sklearn.model_selection import train_test_split, cross_val_score from sklearn.ensemble import GradientBoostingClassifier from sklearn.metrics import precision_recall_fscore_support X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) model GradientBoostingClassifier(n_estimators200, max_depth4) scores cross_val_score(model, X_train, y_train, cv5, scoringroc_auc) print(CV AUC:, scores.mean(), -, scores.std()) model.fit(X_train, y_train) y_pred model.predict(X_test) print(precision_recall_fscore_support(y_test, y_pred, averagebinary))还有一个我非常看重的步骤特征重要性分析。训练完模型把特征重要性排序打出来去跟业务方聊一遍。如果模型说最重要的特征和业务直觉完全对不上那多半是数据处理出了 bug而不是业务方错了。这一步能救你很多次。4.4 打包模型从训练到上线训练完了模型文件要落盘而且要带上版本信息。我用 joblib 或者 pickle 保存模型文件名里带上训练时间或者 commit hash比如churn_model_20241201_v3.joblib。然后把模型加载进前文那个 FastAPI 服务里写一个/predict接口接收特征数组返回预测概率而不只是类别因为业务方拿到概率可以做更多判断。上线之前还要想清楚一件事模型怎么更新、怎么回滚。传统软件可以快速发布新版本模型也要有同样的机制。如果你一开始没想清楚等线上模型效果开始衰减你就只能干着急。我一般把模型文件放在服务器某个固定目录服务启动时加载该目录下的模型更新时切换软链接指向新模型文件再重启进程。这套机制虽然简陋但能保证回滚只改一个链接操作风险很低。5. LLM 应用工程新一代的核心能力5.1 从“调 API”到“做产品”经典机器学习还没吃透LLM 时代又来了很多人的感受是追不上。但站在工程角度LLM 应用其实把很多环节简化了同时引入了一批新问题。现在做一个聊天机器人或者知识库问答已经不是写几百行 prompt 那么简单。用户真正关心的是答案质量稳不稳、多轮对话会不会乱、重复提问会不会花很多钱、上下文长了会不会崩溃。这些全是工程问题。我见过太多团队做了一个漂亮的 LLM demo给老板演示的时候惊艳全场一开放给真实用户就完蛋。原因几乎一致没有评估、没有兜底、没有成本控制、没有上下文管理。这跟传统软件上线前不做性能测试是一样的道理。所以下面我会重点讲 RAG 和评估这两块是当前 LLM 应用工程最核心的部分。5.2 RAG把外部知识装进应用RAGRetrieval-Augmented Generation的核心思路是不要让模型凭记忆回答而是先从你准备的知识库中检索相关片段再让模型基于这些片段生成答案。好处是知识可以随时更新不用每次换知识都重新训练模型也显著减少幻觉。一个最基本的 RAG 流程包含三块索引建立、检索、生成。索引阶段把文档切块每块用 embedding 模型转成向量存到向量数据库。检索阶段把用户问题也转成向量在向量数据库里做相似度搜索取最相关的若干块。生成阶段把这些块拼接成上下文连同用户问题一起交给大模型回答。伪代码大概是这样的# 伪代码主要展示流程具体接口以实际库为准 def build_index(docs, embed_model, vector_store): for doc in docs: vectors embed_model.encode(doc) vector_store.add(vectors, metadata{text: doc}) def answer(question, vector_store, llm): qv embed_model.encode(question) hits vector_store.query(qv, top_k5) context \n\n.join([h[metadata][text] for h in hits]) prompt f基于以下资料回答问题。\n资料{context}\n问题{question}\n回答 return llm.generate(prompt)实际工程里有一个细节特别容易被忽视文本切块。切得太碎语义不连贯检索质量差切得太大上下文容易塞爆答案也不聚焦。我的一般经验是优先按段落结构切每块 400 到 800 字左右相邻块之间留少量重叠避免把一个完整的意思硬生生切断。如果文档有标题、有结构把这些结构信息存进 metadata检索的时候可以做加权效果会好不少。另外向量数据库的选择也要看场景。入门用 Chroma 或者 FAISS 就行数据量大了再换需要部署的向量库。做 RAG 时有一个重要的心智转变检索质量决定回答质量的起点模型只是最后的润色者。检索不到正确答案再强的模型也只会一本正经地胡说。5.3 评估你的 LLM 应用LLM 应用最麻烦的是没有标准答案怎么验证“这次改得更好”我之前踩过大坑凭感觉调 prompt调了一整天自己觉得答案变好了结果让同事盲测对方说根本没区别甚至更差。后来我才认真搭了评估体系。一个通用的方案是建立 golden set也就是一批精选的问题和期望答案。不用太多一百道左右但要覆盖常见问法、边界情况、需要拒答的场景。然后每次修改 prompt 或者调整检索逻辑都拿金标集跑一遍。跑完以后可以用 LLM-as-judge 的方式让另一个模型打分按“答案相关性”“是否忠实于资料”“信息完整度”几个维度评判也可以让人快速抽检。没有这个飞轮你在 LLM 应用上做的每次优化都是盲人摸象。这里我建议要保存所有评估记录甚至把模型回答的案例存下来。因为 LLM 输出的随机性很高同一个 prompt 不同次跑结果可能不同多看几次才能判断一个改动是真的有效还是碰巧了。5.4 成本和延迟容易被忽略的工程指标大模型 API 是按 token 计费的一个长文档的 RAG 请求光是塞上下文可能就要消耗几千个 token。用户每问一次你都在花钱。另一个问题是延迟用户能接受 0.5 秒的等待但很难原谅 5 秒的白屏。所以在做 LLM 应用工程时成本与延迟优化跟效果同等重要。我常用的手段有几种第一精简 prompt把不必要的话删掉减少重复放资料第二加缓存相同或者高度相似的问题命中缓存就直接返回这是成本优化的最大杠杆第三用流式输出先吐字再补齐用户体感会好很多第四不要所有请求都用最大的模型简单问题走小模型复杂问题才走大模型成本能省一大截。这些策略没有多高深但它们是真正把 demo 变成产品时必需的一步。6. 常见问题与排查技巧实录6.1 数据泄漏最隐蔽的错误数据泄漏是我见过最阴险的 bug因为它不会让程序报错反而会让你的指标异常漂亮。最常见的几种泄漏场景我整理成了一张表泄漏类型典型表现纠正方法用未来数据构造特征训练 AUC 极高上线后暴跌特征构造严格限制在观察点之前先归一化再划分数据验证集被训练集的统计量污染先切分再只对训练集 fit重复样本同时出现在训练和测试指标虚高按用户或时间做去重切分标签参与特征筛选离线好到离谱特征筛选只在训练集上进行我在实际做数据时发现对样本里同一个用户可能会出现在多条记录里如果不按用户做整体切分训练集和测试集之间就有泄漏风险。不管业务规模多大请先把“时间边界”和“实体边界”这两条划清楚再谈特征工程。6.2 过拟合与欠拟合的诊断模型效果不好先别急着换模型加层数先判断它属于过拟合还是欠拟合。这两者的处理方向完全不同。我习惯用一张表来判断表现判断方向训练损失很低验证损失很高过拟合增大数据量、加正则、减模型复杂度训练损失高验证损失也高欠拟合增大模型容量、加特征、训练更久训练损失和验证损失都很高且接近数据或特征问题检查数据质量、特征表达诊断起来也很简单把训练和验证的损失曲线打出来看一眼就行。如果训练曲线还在降、验证曲线已经抬头那说明模型开始背题了。我个人最常用的应对是提前停止和交叉验证这两个机制能让你的超参调整有的放矢。6.3 依赖与版本不一致“在我机器上是好的”这句话在 AI 项目里出现频率极高而且往往是真的。模型训练依赖的库版本一变结果就可能对不上。比如某个库的小版本升级改了随机种子行为你复现出来的效果就跟记录的不一样。我的解决办法是两层第一项目容器化把训练环境固定到 Docker 镜像里第二锁定依赖版本至少把主要库的版本号记录在实验日志里。这样出了问题你能知道是环境变化引起的还是代码变化引起的。不要嫌麻烦模型该是什么样就是什么样可复现性比一次漂亮的指标值钱得多。6.4 LLM 应用的典型故障LLM 应用也有一些高频故障我从实践里挑了三个最常见的。上下文溢出文档太长塞进去之后 token 数量爆掉模型直接报错或者把开头忘了。处理方案是控制切块长度、做上下文压缩、必要时用摘要替换原文。Embedding 不一致你对知识库用的 embedding 模型和查询时用的不一样语义检索结果就会莫名其妙。很多人踩过这个坑还以为是向量库的问题其实只是模型没对上。检索返回不相关内容向量相似度高不代表语义对特别是有大量同主题片段时。解法是加混合检索加 rerank先召回候选再精排但注意别把系统搞得太重。还有一个就是幻觉。即使 RAG 答对了大部分问题模型仍可能在资料不足时强行编造。我的兜底策略很直接在 prompt 里要求“资料不足以回答时明确说不知道”同时在系统层面对低相似度的检索结果直接拦截。6.5 一套实用排查思路排查 AI 问题我特别推崇“最小复现”和“逐层二分”。就是说把问题尽可能缩小到一个最小数据集上然后从数据、特征、模型、服务四个环节逐一确认。比如线上模型预测不对先别急着怀疑模型找一条线上真实请求用 Python 复现同样的特征处理看特征值和你预想的一不一样。很多时候问题出在前端传参或者特征拼接上面跟模型毫无关系。另一个经验是日志要打在关键环节。数据清洗完有多少行、特征工程后维度对不对、模型输出概率的分布长什么样这些日志平时看着多余排查的时候全是指路明灯。我现在每做一个项目都会先把“每个环节的输入输出规模”打印出来这相当于给整条流水线装了一圈压力表哪里异常一眼就能看到。7. 最后分享一点我的个人体会这条路走下来我最深的一个体会是AI Engineering 的尽头不是某个厉害的模型而是你已经建立了一条能快速试错、快速定位问题的思维链路。模型在变框架会换但数据边界、评估体系、可复现性、成本意识这些工程原则几乎不会变。你如果能把一个小项目从头到尾做扎实做明白比追着十个大模型 demo 跑要值钱得多。还有一个小技巧我想送给正在从零起步的人做项目的时候专门留一个文档记下你自己踩过的坑和当时的排查过程。这个文档不需要给任何人看它是你给自己的“错题本”。我写这个错题本写了三年现在遇到大部分问题都能在十分钟内找到曾经记过的线索。别怕踩坑怕的是踩完不记那才是真的白踩。
