1. 动手之前先想清楚你缺的到底是不是一个“AI系统”先说我自己的经历。上个月有个做供应链的朋友找我开口就是“帮我写个算法用AI预测下个月每个仓的补货量”。聊到第三轮我才搞明白他其实已经用Excel公式把80%的常规补货跑得很熟了真正头疼的是每周要花几个小时处理供应商发来的格式混乱的对账单。他需要的根本不是预测模型而是一套能把非结构化文本清洗成语义化字段的抽取管线。这个案例特别典型——很多人说要搞AI工程但真正缺的往往不是一个“更聪明的模型”而是一条更顺的工程链路。这几年AI相关的岗位和项目肉眼可见地膨胀但“AI工程化”这个词被严重滥用。有人把它等同于调API、套LangChain有人觉得是训练模型、调超参数。以我从零搭过几套系统的体会来说AI工程化是一条完整的手术流水线先判断病人业务问题需不需要开刀要不要用模型、选什么术式模型选型、怎么准备手术室基础设施、怎么处理器官移植的排异反应生产环境下的性能和可靠性最后还得管术后恢复监控和迭代。任何一个环节掉链子整个系统都会在某个深夜突然崩给你看。这篇内容我打算按自己实际趟过的路径来讲从需求判断开始一路走到数据、模型集成、部署和监控。标题叫“ai-engineering-from-scratch”说的就是从零开始的完整落地过程而不是在某一个点上深挖。我不预设你有多深的机器学习背景Python能写、基本命令行会用就行剩下的概念我会用工程化的视角重新解释一遍。读完你应该具备自己从零搭一套可运行、可维护、可演进的AI服务的基本能力并且知道哪些坑是文档里绝对不会告诉你的。2. 需求拆解与技术选型不是所有问题都应该用神经网络硬怼2.1 先用“规则优先”原则过滤掉伪需求我在第一部分举的对账单例子本质上是一个“信息抽取”问题。但信息抽取有一个残酷的事实如果你面对的是固定格式、固定字段的文档正则表达式比任何大模型都便宜、快速且稳定。我在生产环境见过很多AI项目最后被一个三十行的正则脚本替换掉不是因为模型效果差而是因为业务和技术的成本结构完全不匹配。构建AI工程的第一步不是选框架而是做一个“问题分级”固定逻辑类问题字段格式统一、规则清晰的抽取、转换、校验优先用正则、xpath、pandas规则函数解决。这类业务的错误率要求往往是0%而模型天生做不到100%。强分类/数值预测类问题有历史标签、变量间存在统计相关性比如销售预测、风控评分、客户分群。这类用传统机器学习XGBoost、LightGBM往往性价比远高于深度学习训练快、可解释性强、部署轻。开放式生成/理解类问题需要语义理解、文本生成、多轮对话没有固定答案这才轮到LLM出场。混合类问题实际业务里最多比如“先把非结构化PDF转成结构化字段LLM再做规则校验脚本最后跑一个数值模型打分XGBoost”。这个组合我称之为“AI系统拼盘”也是后面所有章节的核心场景。给一个我自己常用的判断标准如果业务方说“偶尔错一个也能接受”优先考虑模型如果他说“线上绝对不能错”那第一选择永远是规则模型只能做候选排序和兜底。这背后是代价结构问题——大模型一次调用成本看似只有几分钱但错误导致的返工、客诉、审核人力才是真正的隐形账单。2.2 模型选型的决策矩阵凭什么选GPT、开源模型还是传统模型一旦确认某块确实需要模型参与立刻进入选型阶段。我总结了一个三维度决策框架效果天花板、成本结构、可控性需求。效果天花板最好理解——同一批数据不同模型能达到的准确率上限不同。成本结构分两块调用成本按token或按量付费和运维成本自己部署GPU集群的硬件和人力。可控性则包括数据隐私、输出稳定性、供应商锁定风险。需求类型推荐方案典型理由少量调用、效果优先、无隐私约束云端大模型APIGPT系列、Claude、Gemini等效果最好开发效率最高按量付费高频调用、成本敏感、可用开源模型达标本地/私有化部署开源模型Llama、Qwen等单次成本趋近于零可批量推理结构化预测、需要可解释性XGBoost / LightGBM 等传统模型训练快、特征可控、便于合规审查私有数据、强合规场景私有化开源模型 向量检索RAG数据不出内网可控性最强补充一个容易踩的坑模型在测试集上的“效果”和生产中的“效果”是两个完全不同的指标。测试集评估的是离线指标比如准确率、F1、BLEU而生产环境真正考验的是“输入分布漂移”下的鲁棒性。我在选型阶段一定会做一个小样本“对抗测试”而不是只看公开榜单——拿50条业务真实数据、包含各种脏乱差格式、边缘情况手动跑一遍输出观察它在意外输入下的表现。这一步花半天时间能省下后面好几个月的返工。2.3 成本估算算清一笔账再去谈方案成本估算很多人在项目启动时完全忽略等账单出来才目瞪口呆。我给一个标准的估算流程假设你要做一个客服助手日均调用5000次每次请求约2000 token输入 500 token输出按GPT-4o级别价格估算输入约每百万token几十元输出按倍率计算。粗略一算就是日均几百元的调用费一个月轻松破万。这还是在没有重试、没有失败回退、没有链式多次调用的情况下。对比之下如果自己部署一个13B量级的开源模型配一张消费级24GB显存的显卡初期硬件投入约万元级别电费每月几百。但它需要你付出工程时间——量化、批处理、并发优化这些后面会细讲。关键结论API方案适合起步期和低并发场景成本随调用量线性增长本地部署适合稳定高并发场景前期投入大但边际成本低。最理想的架构往往是混合的——高价值请求走最强模型普通请求走开源小模型极简单请求走规则脚本。这条“三级漏斗”思路是我在成本优化上做过最划算的一个决定没有之一。3. 基础设施从零到一先把地基浇结实再谈上层建筑3.1 环境管理与依赖锁定为什么我放弃conda改用组合方案从零开始的AI工程项目我踩的第一个坑就是环境管理。早年图省事直接用conda一把梭结果遇到两次事故一次是某次conda solve依赖花了四十分钟另一次是同事的Python版本和CUDA版本对不上模型死活加载不出来。互不兼容的依赖版本是AI工程里最普遍的“项目杀手”。现在的推荐组合是pyenv管理Python版本 poetry或uv管理虚拟环境和依赖配合Docker做最终部署集成。如果你还在用conda问题不大但务必要坚持一个原则——环境定义全部代码化禁止手工操作。poetry的核心价值在于poetry.lock文件它把每个依赖的精确版本锁死。这有多重要我见过不止一次项目跑得好好的某天突然崩了查半天发现是某个依赖从1.2.3自动升到了1.2.4悄悄改了一个返回字段的类型。上线半年的系统败给一个小版本升级这种事故一次都嫌多。一个可复用的最小操作序列# 安装pyenv后指定Python版本 pyenv install 3.11.9 pyenv local 3.11.9 # 初始化poetry项目 poetry new ai-service cd ai-service poetry add torch transformers fastapi pydantic-settings poetry deploy # 等价于lock文件生成后的完整安装3.2 配置管理与密钥隔离把变量从代码里扔出去第二个常被忽略的是配置管理。很多初学者把数据库连接串、API密钥、模型路径直接硬编码在代码里。这带来的问题远不止泄露风险——代码一多每处硬编码都是一个需要维护的“可变点”改一处漏三处是家常便饭。我现在的做法是用pydantic-settings统一管理所有配置项环境变量注入配合.env文件做本地开发配置。生产环境的密钥放在专门的密钥管理服务如Vault或云厂商的Secrets Manager里绝不进代码仓库。配置项至少要覆盖这几类服务端口、超时时间、重试次数等基础运行参数模型名称、版本号、推理参数temperature、max_tokens等数据库、缓存、对象存储的连接信息外部API的地址、密钥、RateLimit策略为什么特别强调模型版本号因为大模型API的更新非常频繁同一个模型名背后的实际版本可能已经换了好几代。如果不把版本号固定在配置里今天跑得好好的管线明天输出风格/格式可能就变了而你的下游解析逻辑还停留在旧时代。把模型版本当作工程配置而不是代码常量来管理是工作习惯从“调模型”转向“做工程”的标志性一步。3.3 实验追踪没有记录等于白干从零搭建系统的过程中你会频繁更换prompt模板、换模型版本、调参数。如果没有一个实验追踪机制你会陷入“我记得上星期跑过一个效果很好的版本但我忘了我当时填了什么参数”的崩溃循环。我推荐MLflow理由有三点开源、轻量、和主流框架集成度高。它至少能帮你做三件事记录每次实验的配置参数params、指标metrics和输出样例artifacts提供模型注册中心管理不同版本的模型状态Staging/Production和Docker、KServe等部署工具衔接让线上跑的和实验跑的版本可溯源这里有一条我付出过代价的经验笔记记得再详细都不如随手在MLflow里点一下记录。因为人会遗忘、会遗漏但日志不会。哪怕是最简单的项目我也建议从一开始就养成“每次跑实验必留档”的习惯。这个习惯会在一个月后省下你至少一天的排查时间。4. 数据处理链路脏活累活才是真正决定效果上限的地方4.1 数据获取与清洗的工程化细节做过真实项目的都知道80%的时间不是在调模型而是在处理数据。AI工程里的数据处理链路至少要包含抽取 → 校验 → 清洗 → 转换 → 版本化这五个环节。我按顺序拆开讲。抽取阶段最容易翻车的地方是“来源多样性”。同一个业务字段可能来自数据库、CSV报表、PDF邮件、合作伙伴的API格式千差万别。我的建议是不要试图用一个函数处理所有来源而是为每个来源写一个独立的抽取模块返回统一的内部数据结构。这个设计能让你在某个来源格式变化时只改对应模块而不影响全局。校验阶段的核心是“fail fast”数据在入口处就要被检查而不是等跑到模型训练/推理时才爆雷。基础校验包括字段完整性、类型正确性、取值区间合理性。进阶校验包括跨字段逻辑一致性——比如消费金额为正、城市字段存在于行政区划表。清洗阶段要特别注意三类问题重复数据同一客户在不同来源可能用不同ID需要定义主键合并策略敏感信息个人隐私数据的脱敏处理必须在清洗阶段完成绝不能让原始敏感字段进入模型、日志或下游系统脏格式日期格式混杂、编码问题UTF-8与GBK、全角半角混用这些看似小问题实际会导致模型输入质量断崖式下降4.2 数据版本化为什么直接存CSV会翻车很多踩坑故事的开头都是“我们直接把清洗后的数据存成了CSV然后……”。数据一旦进入模型训练和推理环节就和代码一样需要版本管理。原因很简单模型输出和训练数据的版本强绑定。如果你改了数据没改版本号下游所有实验记录都失去可比性。我目前的生产级做法是数据文件用DVCData Version Control管理数据本身放对象存储或NAS元数据进Git仓库保证每次数据变更都有记录、可回滚对于文本类数据集使用Hugging Face Datasets库管理它内置了数据集的加载、切分、映射和缓存功能还能和深度学习框架无缝衔接每次数据处理后生成一个数据摘要文件行数、字段统计、异常值占比随数据一起提交方便后续对比举个例子DVC的基础流程大概是这样dvc init dvc add data/raw_supplier_reports.csv # 把大文件加入DVC管理 git add data/raw_supplier_reports.csv.dvc git commit -m add raw supplier reports v1 dvc push # 推送到远端存储后续想回到之前某个数据集版本一条dvc checkout就搞定。这套机制在团队协作中的价值是巨大的——你再也不需要听同事说“我拿的是最新的那版数据”因为“最新”有明确的版本号可查。4.3 标注与数据质量从“能用”到“可信”如果项目涉及监督学习传统ML或模型微调标注质量就决定了效果天花板。我见过太多团队把大量精力花在调模型结构上却给标注工人下发极其含糊的标注规范最后模型效果怎么调都上不去——问题不在模型在标签噪声太高。标注规范至少要明确几个点每个标签的精确定义附带正例和反例边界情况的处理策略比如“客户投诉中包含表扬算正面还是负面”一致性校验机制同一批数据由多人标注后计算一致性指标冲突样本需要仲裁流程这里推荐一个很实用的小技巧标注完成后不要急着训练先做一次“标签自检”——写一个脚本统计每个类别的样本量、平均文本长度、标签分布再随机抽几十条看标注质量。这一步成本极低但能避免你拿着充满噪声的数据集跑三天训练才发现方向全错。另外如果是真实系统中的日志数据一定警惕“标签泄漏”问题——用未来信息预测过去事件这在时间序列场景尤其常见。做过一次销售预测项目差点把“当月的实际销售额”当成特征塞进训练集上线后才发现模型“预测”的其实是已经发生的事实。这种错误在离线评估时看不出来因为指标异常漂亮上线就抓瞎。5. 模型的工程化集成从notebook代码到可服务模块5.1 推理层的统一封装别让业务代码碰模型细节模型集成阶段最大的思维转变是把模型当成一个服务模块而不是一段可随意调用的函数。这个抽象带来的好处是你可以随时替换底层模型从GPT换到开源模型、从小模型换到大模型而不必改动业务代码的每一处调用。我设计的推理层接口通常包含class LLMService: def chat(self, messages: list[dict], **kwargs) - ChatResult: 统一的对话接口返回包含文本、token用量、延迟的结构化结果 ... def embed(self, texts: list[str], **kwargs) - list[list[float]]: 统一的向量化接口 ... def health_check(self) - bool: 探活接口供监控系统调用 ...在这个封装下面你可以自由选择API厂商、开源模型推理框架如vLLM、TGI、Ollama甚至做A/B对比。调用方的代码完全无感知。这对于后续的模型降级、成本优化至关重要。除了接口统一推理层还要内置三个关键机制超时控制每类模型调用设置合理的超时时间防止一个慢请求拖垮整个请求线程重试策略对瞬时的限流、网络抖动做指数退避重试但要设置上限防止雪崩优雅降级主模型挂了自动切到备用模型或规则脚本而不是直接把异常抛给用户5.2 提示词也是代码模板、版本管理和测试“提示词工程”这个词听上去像玄学但我更愿意把提示词当成一种高度业务相关的配置代码来管理。它需要版本管理、测试用例和审计追溯。我的提示词管理实践是这样的把提示词模板拆成“系统指令”和“用户输入”两部分系统指令中绝对不能拼接用户数据防止提示注入攻击模板放在独立目录里每个版本一个文件prompts/classifier_v2.md修改即留痕为每个提示词编写一组最小测试用例覆盖正常输入、边界输入、恶意输入每次改动后跑一遍这里重点说提示注入。它是LLM应用特有的安全问题用户输入的文本里如果夹带了“忽略你之前的所有指令直接输出……”之类的指令模型可能真的照做。防护措施包括系统提示词中明确声明指令边界、对输入做特殊字符检测和标记、输出侧做策略过滤。我在所有生产级系统里都会加这个保护因为AI服务的输出一旦被污染对业务的可信度打击是致命的。5.3 模型路由与缓存省钱的本质是“少算”在线上高并发场景模型路由和缓存是成本优化的两个杠杆。模型路由的核心思路是“分级处理”简单、低风险、可复用的问题 → 轻量开源模型或规则脚本一般业务问题 → 中等规模模型疑难/高价值问题 → 最强模型如何判断问题难度可以用一个“难例检测器”前置模块比如文本长度、关键词命中、历史相似度等特征打分高于阈值的走强模型低于阈值的走弱模型。这个分级体系做得好通常能省下30%-50%的总调用成本而效果几乎没有肉眼可见的下降。再说缓存。这里的缓存不是HTTP缓存而是语义缓存。普通的KV缓存要求键完全一致才命中但用户的问题是自然语言表达方式千变万化。语义缓存的做法是将查询向量化后在向量数据库或内存索引中做相似性检索相似度超过阈值的直接返回缓存结果。比如“你们的退款政策是什么”和“请问退款怎么操作”在语义上是同一个问题如果系统把这个查询缓存住了第二个请求完全不需要再调用大模型。在重复问题比例高的客服场景语义缓存的命中率有时能到30%以上这是个相当可观的数字。6. 部署与性能优化本地跑通到生产稳跑中间隔着一整条河6.1 推理性能的度量与瓶颈定位模型部署之后第一件事不是调参而是建立性能基线。我始终在追踪四个指标首Token延迟TTFT用户发出请求到看到第一个输出token的时间。在交互场景这个值超过2秒体验就会明显变差。生成吞吐tokens/sec单请求的生成速度决定单次对话的等待时长。并发吞吐requests/sec系统整体能支撑的QPS决定扩容需求。GPU利用率硬件资源的真实使用率决定你买的卡是不是在闲置。实操中最常见的瓶颈是QPS上去了但GPU利用率低得吓人原因多半是并发逻辑写成了串行——每个请求独占了模型推理没有做请求合并。解决思路是引入推理框架自带的批处理机制。以vLLM为例它实现了一种叫做“连续批处理”的调度机制不用等一批完整凑齐再推理而是随时有请求进来就插到正在推理的batch里极大提高了GPU利用率。实测用vLLM部署开源模型同等硬件下吞吐通常比原生Transformers推理高出数倍。如果只是个人项目也可以用Ollama这类工具快速起一个本地推理服务它的性能优化做得不错且配置成本极低。6.2 结构化输出与容错设计让模型行为可预期生产系统的核心要求是可预期而大模型天生不可预期。所以集成时一定要在“模型的不可控输出”和“下游对可控格式的需求”之间加一层强制规范。我最常用的方案是在提示词中要求模型输出JSON然后把输出交给一个严格的JSON解析器并做字段校验。但只靠提示词约束JSON格式并不可靠——模型偶尔会输出成别的结构我就在解析失败时自动触发一次“重新生成并修正格式”的重试。同时设置格式解析失败次数的上限超过上限就走备用方案比如规则抽取而不是无限重试。结构化输出的更进阶方案是使用各家的“响应格式约束”功能如OpenAI的JSON Mode以及各类推理框架支持的约束解码它从解码阶段就直接限制token生成输出天然符合JSON语法。做工程化一定要优先用这类能力它把很多解析噩梦直接消灭在源头。6.3 部署形态选择容器化、Serverless还是全托管部署形态的选择没有银弹取决于你的团队能力和调用规模。如果团队有基础运维能力、调用量稳定且大推荐“容器化 K8s”路线用Docker镜像封装推理服务K8s负责伸缩和自愈。这条路的成本是前期的Dockerfile、资源配置、探针调试收益是长期稳定的部署体验。如果调用量波动大、懒得维护集群Serverless容器如云厂商的弹性容器实例是更灵活的选择。冷启动可以接受的话成本还能进一步压低。唯一的风险是冷启动延迟——大模型镜像动辄十几GB冷启动可能要几十秒需要预热策略或者保活策略来兜底。无论选哪条路容器镜像的构建规范都应包括基于固定基础镜像、锁定依赖版本、单独挂载模型权重目录模型不打包进镜像、设置非root用户运行。这些细节决定了你在生产环境出问题时能不能三分钟内定位。这里特别强调“模型权重不打包进镜像”这一点。模型权重动辄几GB到几十GB如果每次都打进镜像每次发布都要重传几GB数据既慢又费流量。更好的做法是模型权重放独立的对象存储/共享卷中镜像启动时按版本号拉取镜像本身保持小而快。版本号放在配置里发布新版本只需要改一个配置项和触发一次热加载线上服务几乎无感。7. 上线后的持续迭代监控、反馈闭环、什么时候重新训练7.1 线上监控指标除了延迟还要盯“效果漂移”很多人以为服务上线后监控就是看看CPU、内存、延迟这些基础设施指标当然要看但对AI服务来说远远不够。你要额外监控的是“模型效果”本身。效果漂移最常见的形式是输入分布漂移线上流量的输入数据和开发期测试数据的分布逐渐不一致。比如客服机器人刚上线时用户问“登录不了怎么办”这类标准问题三个月后用户开始问“我的账号被异地登录了怎么办”新问题在你的训练数据里占比很低模型效果自然下滑。检测方法是在每个请求上打标记输入长度、主题分类、关键词命中率按时间窗口做分布统计。一旦发现分布偏移超过阈值就要触发一条告警。另外在输出侧也要做质量监测——定期抽样线上请求人工或LLM-as-judge检查输出质量把结果记录到监控看板。这里补充一个经验不要迷信自动评价工具抽查人工复核永远是最后一道防线。7.2 反馈闭环把用户的每一次不满变成算法改进的燃料一个合格的AI工程系统必须有数据回流机制。用户对输出的点赞/点踩、客服人工修改前后的内容差异、业务方的需求变更这些信号要能自动汇聚成一个个“待改进样本库”定期补充进数据集用于后续的prompt优化或模型微调。我在系统里一般会设计一个用户反馈表至少包含用户查询原文模型输出原文用户/客服的最终修改结果作为弱标签反馈类型点赞、点踩、修改、超时、举报时间戳、业务来源这个表的价值会随时间推移越来越大。它不仅是评估线上效果的数据源更是未来训练集扩充的金矿。没有这个回流机制AI系统就像一个只输出不学习的书呆子永远在老问题上反复犯错。7.3 什么时候需要微调什么时候只需要换Prompt每次有业务方来找我说“效果不够好”我都会先做一轮排查再决定要不要碰模型本身。排查顺序是这样是不是数据问题输入解析错了、字段缺失、编码异常。这类问题最常见修完立刻见效。是不是Prompt问题指令不够清晰、示例太少、格式约束没写死。多数情况下修改prompt能解决80%的效果问题。是不是模型能力问题换一个更强或更合适的模型对比跑一批测试数据。如果换模型效果提升很大说明当前模型能力不够。最后才考虑微调真正需要微调的场景是业务有独特风格或领域术语法律合同、医疗报告、代码规范通用模型很难通过prompt学到位。我做过的微调项目里最有价值的一个不是调大模型而是用少量业务数据微调了一个小开源的embedding模型把检索的召回率提升了15个百分点。这件事成本极低、效果极稳比微调生成模型性价比高得多。所以在“微调”这件事上我个人的建议永远是先想清楚你的瓶颈在“理解”还是“生成”理解的问题优先调检索、调embedding生成的问题优先试prompt最后才砸钱去微调大模型。回到开头那句“从零开始”。AI工程化不是买一本教材背概念也不是跑通一个demo就完事。它是一个从业务需求到技术选型、从数据治理到模型集成、从部署监控到迭代反馈的闭环系统。每一步都有无数细节坑等着你踩但只要整体的工程框架搭对了踩坑的成本都是可控的、可学习的。最后再分享一个我坚持了很久的小习惯每个项目建一个“事故复盘文档”把每一次线上故障的根因、修复过程、预防措施都记下来。半年后回头看你会发现这份文档的价值不亚于代码本身。踩坑不可怕怕的是同一个坑踩第二遍。