聊到“ai-engineering-from-scratch”很多人的第一反应是“学Python、跑几个开源模型”但真正把一个AI想法变成一条稳定可用的服务背后其实是另一套能力数据管理、模型选型、训练评测、部署运维还要懂Prompt设计和Agent工作流。我在这条路上走了不少弯路从最早只会跑demo到后来能独立把一个AI功能从0搭到上线中间踩过的坑今天整理成一份可以直接上手的路线图。这篇文章适合几类人刚入门想系统学AI工程的新手做后端想转AI应用开发的工程师以及已经跑通过demo但不知道怎么上生产的团队。我会从整体认知讲起拆到具体环节再给一套可复现的实操流程最后聊一些常见问题的排查方法。内容偏工程实践不堆论文推导重点讲怎么做、为什么这么做。1. AI工程的整体认知与能力地图1.1 为什么说AI工程不是算法竞赛先给AI工程画个像它不是单一岗位而是把数据、算法、系统、产品串起来的综合工程。算法工程师关注模型效果但在实际项目里模型只占整个系统很小的一部分。一个完整的AI功能前面有数据采集和清洗中间有模型训练和评估后面还要有接口服务、监控日志、版本回滚、成本控制。这些环节加起来才是AI工程。我见过不少团队模型在notebook里跑得好好的一上线就崩。原因很简单notebook的代码和线上服务之间隔着一整套工程化鸿沟。训练时的数据分布和线上请求的数据分布不一致模型会过时没有日志监控效果变差时不知道是模型问题还是数据问题没有版本管理调了一个参数后想回退都难。这些都是工程问题不是算法能解决的。所以别只盯着最新的模型榜单先把工程基础打牢。工程能力决定了你的AI项目能走多远。1.2 从零开始的学习路径如果你想从零开始我建议按这条路径推进能少走很多弯路先掌握基础工具链Python、Linux、Docker、Git。Docker尤其重要AI项目的依赖冲突非常多用容器可以省掉一堆环境问题。跑通一个完整的小项目用公开数据集训练一个分类模型把数据加载、训练、测试、保存权重、加载推理的流程完整走一遍。学模型部署把训练好的模型包装成HTTP服务用FastAPI实现再用Docker部署到服务器能够从外部调用。理解工程化工具用MLflow或WB做实验管理用DVC管理数据集用Prometheus/Grafana做监控。再延伸到LLM应用掌握Prompt Engineering、RAG、Agent workflow并学会把AI能力接入现有系统。这条路径不追求快但每一步都为后面打基础。我自己当年急着做LLM应用跳过模型部署直接写业务代码结果线上出了问题连排查入口都找不到。后来补上服务化那一课很多问题都清晰了。1.3 harness思维给AI系统加上“模具”热词里经常出现“harness engineering”我理解这里的harness不是某个具体工具而是一种思维给系统加上夹具和护栏。模具本身不产生零件但决定了零件的质量。AI工程也需要这样的harness——训练时的数据校验、评测集、回归测试上线时的灰度发布、效果抽检、降级开关。具体来说我每次训练一个模型都会先做一个固定的评测harness一张标准输入测试集、一组评估指标、一条自动生成报告的命令。模型迭代时先用这个harness跑一遍效果不比旧模型差才允许继续测试。这套夹具看起来不起眼但能拦住大量回归问题。平时调Prompt也一样我会维护一份输入输出样例集每次改Prompt都用这套样例跑一遍避免修好一个例子却弄坏另外几个。这就是工程里的“回归测试”。1.4 团队里的角色分工和协作AI工程不是一个人能完成的。理想团队里需要数据工程师、算法工程师、后端工程师、SRE甚至还需要懂业务的人。小团队可以一人身兼多职但角色边界要清楚否则很容易出现“没人管数据质量”或“没人管线上稳定性”的情况。我的经验是项目启动时先明确一名“技术负责人”由TA统一决定模型选型、技术栈和部署方案。数据质量由数据工程师负责模型效果由算法工程师负责后端接口和稳定性由后端负责。每周至少对齐一次特别是数据分布变化和模型上线计划避免各搞各的。AI工程协作的关键不是工具多先进而是信息透明、责任清晰。2. 核心环节拆解数据、模型、训练与评测2.1 数据采集与清洗的完整动作AI工程里数据环节最容易被低估。很多人觉得数据就是下载公开数据集跑起来就完事。但真实项目里数据质量直接决定模型天花板。比如做文本分类标签打错5%模型效果就很难上去做知识库问答文档没清洗检索出来的都是乱码再强的模型也答不对。我把数据工程拆成四步采集、清洗、标注、版本管理。采集阶段明确数据来源、格式和权限不能随便爬数据就用于商业项目。清洗阶段做去重、去噪、格式统一文本数据要处理编码问题、空格、乱码和特殊字符。标注阶段制定详细的标注规范至少两个人打标并计算一致性样本不够时先小批量试标。版本管理阶段用DVC或简单的命名规则记录数据集变化比如dataset_v20250201。每一步都要留记录否则后面模型效果出了问题很难回溯是哪份数据导致的。2.2 模型选型API、开源、微调的取舍选型是工程里最纠结的一步。我的经验是先区分场景如果是通用能力比如聊天、翻译、摘要直接调成熟API往往更省心如果是垂直领域比如法律文本抽取、特定风格生成就需要考虑开源模型微调。API的优势是省运维、迭代快但要注意数据隐私和调用成本。开源模型的优势是可控性强可以私有化部署数据不出内网但你需要自己准备GPU、处理推理优化。选型时我会做一个对比表格对比项闭源API开源模型部署开源模型微调初始成本按量付费需要GPU需要GPU和训练时间数据隐私依赖服务商完全可控完全可控效果上限通用能力强取决于基座可适配垂直领域运维复杂度低中高高迭代速度快中慢选型时把模型体积、显存占用、推理速度、效果指标、成本都列出来用数据决策而不是凭感觉选“最强”模型。2.3 训练实验管理与资源规划训练模型不只是跑一次脚本而是一连串实验。每一轮实验的参数、数据集、代码版本、评价指标都要记录否则调参等于盲调。我现在用的是MLflow每次训练自动记录超参数、模型文件、指标曲线之后可以随时对比。资源规划也要提前想清楚。训练和推理不要抢同一批GPU否则训练时线上推理变慢用户直接投诉。我建议训练任务和推理服务分集群哪怕共享也要设置资源配额。另一个经验是先用小数据跑通流程再上全量数据既省时间又省经费。很多人一上来就买大机器结果代码bug导致训练中断钱白花了。2.4 评测体系离线指标、线上反馈与回归测试模型效果不能只靠肉眼看几个样例必须有系统评测。离线阶段分类任务看准确率、召回率、F1生成任务看ROUGE、BLEU、BERTScore但结合人工评估更可靠。我通常准备30到50条标准样例每次迭代先跑一遍记录好坏。线上阶段要设计反馈机制比如用户点踩、点赞、修改结果等信号定期回传做分析。我踩过最大的坑是只看离线指标结果线上效果很差。原因在于测试集和真实数据分布差异很大。后来我建了一个线上数据回流管道每天自动采集一批真实请求脱敏后加入评测集模型每迭代一版都拿这批数据回归。这套机制有效防止了“过拟合到测试集”。3. 从原型到生产模型部署与推理优化3.1 部署方案的几条路线模型跑通后核心问题是“放在哪里跑”。常见选项有CPU服务器、单卡GPU服务器、多卡GPU集群、边缘设备。选型关键看延迟、吞吐和成本。内部工具允许秒级响应用CPU部署小模型就够了面向用户的实时推荐服务则需要GPU加高效推理框架。我的建议是先压测用wrk、locust或简单的Python脚本模拟并发请求看当前配置下的QPS和延迟。如果QPS不够优先考虑换性能更好的推理引擎而不是直接加机器。比如开源模型用vLLM或Triton部署后吞吐往往能翻好几倍。别急着扩容先优化软件层。3.2 推理优化三板斧批处理、量化、缓存推理优化是整个AI工程的重头戏。我用过的组合拳有三板斧动态批处理把多个请求合并成一次前向计算能大幅提升吞吐。需要注意设置最大等待时间否则单条请求等待过久反而影响体验。模型量化把权重从FP16降到INT8显存和计算量都会下降。但量化要有校准集避免精度掉太多。小模型可以尝试验证。结果缓存对重复或相似请求直接返回缓存结果。文本可以算语义hash作为key命中后延迟从几百毫秒降到几毫秒。我在一个问答系统里做过试验加了语义缓存后重复问题的咨询直接命中后端压力小了一半以上。优化不是把每个指标调到极限而是用最少的成本解决最大瓶颈。3.3 可观测性日志、监控、告警部署上线只是开始稳定运行才是难点。我一般在服务里加三个东西健康检查接口、结构化日志、告警规则。健康检查接口返回模型版本、当前显存、最近请求的成功率和平均耗时。日志记录请求ID、输入长度、推理耗时、异常堆栈方便定位问题。告警规则覆盖延迟突增、错误率超阈值、队列堆积、显存占用过高等场景。有一次模型服务夜间挂掉因为接口被大量恶意请求刷量输入都是超长文本直接把显存打满了。如果没有监控和限制可能到第二天用户投诉才发现。后来我加了显存告警和单请求最大token限制问题再没出现过。可观测性不是锦上添花是生产系统的底线。3.4 上线前检查清单每次上线AI服务前我都会过一遍清单模型文件是否从固定版本目录加载而不是临时路径。环境依赖是否用Docker锁定确保和测试环境一致。有没有健康检查接口能否在负载均衡器里自动摘除异常节点。请求超时和重试机制是否配置好避免调用方无限等待。日志是否包含请求ID能否串联整个调用链路。有没有降级开关模型不可用时能否临时返回规则结果。这张清单救过我好几次。有一次发布新版模型时忘了固定版本号导致线上回滚后加载到了新权重幸好健康检查里记录了模型hash及时发现。生产事故大多数不是模型不行而是流程疏忽。4. Prompt Engineering与Agent应用落地4.1 Prompt的结构化设计方法LLM应用里Prompt就是产品逻辑的一部分。很多人把Prompt当成“写话术”其实它更像写接口文档明确指令、输入格式、输出格式、边界条件、示例。一个结构化Prompt通常包含角色设定让模型知道自己是谁。任务描述明确要做什么。输入数据用清晰的标记传递变量。输出要求指定JSON或Markdown格式。少样本示例给出两个典型例子。边界说明比如找不到答案时怎么处理。我常用的做法是先写粗糙版本跑几个例子针对失败case迭代。比如让模型从合同里抽取条款第一次输出格式不统一我加上“如果没有找到对应条款请返回not found”这种边界说明准确率立刻就上来了。Prompt工程没有定式但一定要有测试集思维。4.2 把大模型当调度器的Agent工程AI Agent现在很火核心是把大模型当作“调度器”让它决定调用哪些工具、按什么顺序执行。工程上要解决的问题包括工具定义怎么写、结果怎么解析、出错怎么重试、多步任务怎么跟踪状态。我的建议是工具定义用JSON Schema明确参数类型和必填字段模型返回结果后要做格式校验不能直接相信要设计循环上限避免模型陷入死循环。CodeBuddy这类工具能辅助开发Agent工作流但底层逻辑还是上面这几条。Agent不是黑魔法。把它当成一个状态机每一步有输入、输出、校验、重试再加上详细日志它就是一个可控的自动化任务系统。很多团队Agent效果不稳不是因为模型不够聪明而是缺了工作流管理。4.3 RAG与Agent结合的知识库问答RAG检索增强生成是目前最务实的落地方式。文档先切分、向量化存入向量数据库用户提问时先检索相关片段再交给大模型生成答案。这种方式能结合知识库的实时性和模型的生成能力。把RAG封装成Agent的其中一个工具就能组合出更复杂的能力用户提问Agent先判断需要查知识库还是调用计算器然后执行并返回结果。工程上要注意检索结果的质量不能只取top1要综合多个候选片段。另外要把引用来源返回给用户提升可信度。4.4 从一个Chat功能演变成Workflow很多团队做了AI聊天之后才发现真正的价值在Workflow。比如客服场景不只是问答还需要查订单、退款、转人工。这就要把AI能力嵌入到严谨的状态机里每个环节都要有确认和兜底。我在实际项目中做过一个工单助手用户描述问题后模型先做意图识别再匹配知识库生成回复草稿人工确认后发送。每一步都有日志模型出错时自动转人工。这种混合式Workflow比纯端到端生成可靠得多。工程化的本质不是让模型做所有事而是让模型在可控范围内发挥最大价值。5. 实战从0搭建一个文档问答系统5.1 需求界定、指标与方案设计假设我们要做一个“智能文档问答”系统输入是公司内部文档用户用自然语言提问系统返回答案并标出来源。这是一个很典型的需求可以走完整流程。先定义技术指标回答准确率、召回率、响应时间、并发量。再选技术方案我用的是RAG路线文档切分→向量化→向量检索→大模型生成。切分策略要按章节结构来不能硬按固定长度切否则语义被截断。向量模型要选择支持中文且维度适中的大模型先用API节省部署成本。方案里还要写明数据权限、脱敏方式、失败兜底。5.2 文档处理与检索体系的建立这个项目的数据准备包括把PDF、Word文档转成纯文本清洗格式按标题层级切分成块建立元信息标题、页数、路径。然后批量调用嵌入模型生成向量存入向量数据库。切分时要注意重叠。我一般设置每个块最多500字尾部重叠50字避免一句话被切断。向量数据库里要建索引字段后续检索按文档权限过滤。这里有个很容易踩的坑不做权限过滤用户可能检索到没权限看的内容不仅错误还有合规风险。5.3 模型微调与评测循环第一次跑通后我发现通用向量模型对领域词汇理解不好检索效果一般。于是我对嵌入模型做了微调用一批问答对构造训练数据训练一个领域适配模型。这个过程中评测集固化是关键。我准备了50个问题人工标注了每条答案应该包含哪些文档片段每次迭代都用这50条跑检索召回率。有了评测集调参就不再是玄学。否则用肉眼看几个case永远不知道是切分问题还是模型问题。5.4 部署、灰度上线与迭代整个系统包含三个服务文档处理服务、检索服务、问答服务。我用了Docker Compose编排检索服务连接向量数据库问答服务调用大模型API。部署后先做技术测试验证接口延迟和并发稳定性再做业务测试找几个真实用户提问收集反馈。上线第一周我发现用户经常问“某某文档的权限”模型答不上来。原因是权限信息没有写入检索结果大模型看不到就无法回答。于是我在检索阶段过滤无权限的片段再把权限上下文带给模型问题立刻解决。AI项目上线后才是真正迭代的开始必须有反馈闭环。6. 常见问题与排查技巧实录6.1 效果不好从数据到Prompt的排查顺序最常见的问题是“模型输出质量差”。别急着换模型先按顺序排查输入数据是否干净有没有截断、乱码、格式异常。Prompt是否明确任务描述、输出格式是否说清。有没有少样本示例模型需要模仿范例。评测集是否合理是不是有标注错误或分布偏差。模型能力是否够最后才考虑换更大模型。我遇到过一个文本分类模型准确率总在85%上不去后来发现是训练数据里几个类别样本严重不平衡重采样之后直接到93%。排查质量问题时先用数据说话别凭感觉调参。6.2 线上崩溃部署、性能与稳定性排查部署常见报错包括依赖冲突、显存不足、版本不一致。我推荐所有AI服务都用Docker依赖锁定在镜像里。显存不足时先看模型加载方式用半精度加载再看推理框架是否支持流式输出或分块处理避免长文本一次性塞进模型。性能问题也要用数据说话。压测时记录P50、P95延迟。如果P95很高大概率是有超长请求拖慢整个服务这时候要考虑按请求长度拆分处理或者加超时控制别让个别请求拖垮全局。6.3 版本混乱实验管理与协作规范AI项目的版本管理比普通代码项目复杂代码版本、数据版本、模型版本都要对应。我的做法是给每次实验生成一个实验ID记录代码commit、数据版本、模型路径、关键参数。模型文件名带版本号比如qa_model_v20250201.pt发布时在配置里锁定版本。团队协作时我建议用MLflow统一记录实验指标和产物。这样做的好处是任何一个人都能复现别人的实验。很多团队模型效果越做越乱就是因为实验记录太随意没人知道当前线上的模型是哪一版、基于什么数据训练的。6.4 快速自查速查表现象优先排查常用处理回答偏离主题Prompt意图不明确加角色和少样本示例回答格式乱输出约束不够强制JSON并校验检索不到内容文档切分/向量化问题检查切分重叠和模型延迟过高推理引擎or请求超长批处理/量化/限长显存OOM加载精度/批大小半精度加载/减批大小线上效果变差数据分布变化加线上数据回流评测这张表是我自己排查时用的不一定覆盖所有情况但至少能帮你优先定位大多数问题。AI工程里70%的问题出在数据、配置和流程上真正需要调模型的反而没那么多。7. 最后再聊几句实操体会做AI工程这几年我最大的感受是不要迷信模型要相信流程。模型再强如果没有数据管理、没有评测、没有监控线上一样会出问题。反过来只要工程流程合理哪怕用中小规模模型也能稳定服务业务。我自己现在的习惯是每做一个AI项目先把工程骨架搭好数据版本管理、评测集、可观测性、回滚开关。这四个东西补齐了再开始调模型。很多人觉得这样浪费时间但长期看这是最省时间的路。最后分享一个小技巧写代码和调Prompt一样都要留版本记录。我习惯把每次调Prompt的记录存在本地文件标注日期和效果变化改坏了可以直接回退。AI工程的本质就是管理不确定性而管理不确定性的第一步是让每件事都有迹可循。建议你找一个真正的小项目比如个人知识库问答按文中的流程完整走一遍。走通一遍之后你会发现后面的路顺很多。我从零开始做到现在最认可的一句话就是AI项目没有捷径但工程化就是那条最稳的路。