2023年底到2024年AI这个圈子几乎是一夜之间从会写模型卷到了会做工程。很多人找我聊的第一句话都是我现在能跑通别人的模型demo但真要自己从零搭一个能上线的AI应用感觉完全没头绪。这个ai-engineering-from-scratch项目就是我把过去这两年从零搭建AI应用的完整过程重新捋了一遍沉淀成一条可复制、可执行的路线。这条路线上既有环境搭建、数据工程这种地基活也有Prompt工程、AI Agent这类今年最热的方向还包括模型微调、部署上线和端到端实战案例。这篇文章适合三类人一是刚开始接触AI开发、想系统入门的新手二是想从算法方向转做AI工程化的同学三是已经在用现成AI平台但总感觉隔了一层、想搞明白底层原理的从业者。我会把每个环节为什么这么做讲透同时附上我自己踩过的坑和正在用的方案争取你看完就能照着搭。1. 从零开始做AI工程先想清楚再动手1.1 AI工程的完整链路到底是什么一个真正能落地的AI项目从需求到上线走的是这样一条链路业务需求分析、数据采集与清洗、数据标注与增强、模型选型与训练或微调、模型评估与调优、服务化部署、线上监控与持续迭代。我见过太多同学把AI工程等同于训练模型结果一上来就扎进代码里调参最后项目还是挂掉。根据我自己带项目的经验训练环节通常只占总工作量的三到四成剩下六成以上都在数据、部署和迭代。举个最典型的例子你花两周训出一个准确率还不错的意图识别模型高高兴兴部署上线结果真实业务里用户输入五花八门之前没见过的写法、错别字、口语化表达全来了准确率直接掉十几个点。这时候你才发现之前测试集好看不代表生产环境好用评估体系没搭好迭代机制没建起来后面的每一步都是被动的。所以从零做AI工程第一步不是碰代码而是把整条链路在脑子里过一遍搞清楚每个环节的输入输出和依赖关系。我自己习惯画一张简单的数据流图原始数据从哪来、清洗成什么样、怎么进模型、模型输出怎么被业务消费、效果怎么回流。这张图一旦清楚后面所有工作都有了主线。1.2 为什么建议从零走一遍而不是直接套平台现在各种AI开发平台、拖拽式工作流很多确实方便。但我依然强烈建议至少完整走一遍从零搭建的过程原因是平台帮你屏蔽了细节同时也屏蔽了你的判断力。举个例子在平台上你拖入一个文本分类组件数据进去、结果出来一切看起来很顺。但你知道它底层用的什么预训练模型吗数据预处理做了什么操作学习率、batch size这些默认参数适合你的数据分布吗一旦效果不好你是完全无从下手调优的只能干瞪眼。而从零走一遍你会切身理解分词、padding、归一化、优化器选择、损失函数设计这些细节各自影响什么出了问题也能准确判断应该去哪个环节排查。当然从零开始不意味着所有轮子都自己造。模型结构直接用开源的训练框架用成熟的但每个环节的原理和接口你必须搞清楚。这也是本文贯穿始终的思路用开源技术栈解决问题但每一步的为什么都必须讲明白。2. 环境搭建与工具链准备把地基夯实2.1 硬件与软件选型做AI工程第一步就是环境这一步看着不难实际坑最多。先说硬件如果只是做Prompt工程、Agent开发或者小规模微调一张消费级显卡24GB显存左右基本够用。如果是大规模预训练那得靠多卡甚至集群但这对绝大多数人来说用不上也不建议一上来就折腾。我个人的经验是优先租云GPU按需使用比一次性买卡灵活得多。像AutoDL、恒源云这类国内算力平台按小时计费用多久付多久特别适合学习和中小型项目。软件层面操作系统方面Windows、Linux都可以做AI开发但生产环境绝大多数是Linux建议尽早习惯Ubuntu Server或Debian。深度学习框架选型上PyTorch目前是生态最好的选择社区活跃、预训练模型支持最全面TensorFlow也还在维护但如果你不是有特殊历史包袱选PyTorch更省心。Python版本建议3.10以上版本管理用conda或uv都行我自己现在更倾向于uv速度比conda快很多解析依赖也稳。CUDA和驱动这块很多人容易卡住。我的建议是不要手动去装CUDA直接用PyTorch官方提供的CUDA版本配套安装。比如你执行pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121PyTorch会自带对应版本的CUDA runtime你只需要装好NVIDIA显卡驱动就行。这个方式帮我省掉了大量环境排障时间。2.2 环境管理的三个关键习惯第一个习惯每个项目都建独立的虚拟环境和requirements.lock文件。独立环境保证项目之间互不干扰lock文件保证团队协作或者隔几个月回来看项目时能一键复现。第二个习惯项目代码和模型文件分离。模型动辄几个GB不适合进git仓库应该用专门的模型管理工具比如Hugging Face Hub、ModelScope或者自建MinIO做私有存储。代码仓库里只保留模型地址和版本号。第三个习惯从第一天就用Docker打包运行环境尤其是部署阶段。自己本地跑通demo不算完换成一台干净服务器跑通才算数。Dockerfile里把系统依赖、Python依赖、启动命令都写清楚这套环境描述文件本身就是项目最宝贵的文档之一。注意环境问题最大的坑是我本机可以跑。这句话几乎等于没说因为你本机的Python版本、CUDA环境、依赖历史都是不可复现的。凡是能被环境差异打败的项目本质上是工程化没做到位。3. 数据工程AI工程的隐形地基3.1 数据清洗与格式统一花最长时间的地方如果让我用一句话概括数据工程的重要性模型决定效果上限数据决定能否逼近这个上限。我参与过的项目里数据准备时间普遍占整个项目周期的40%到50%这个比例一点都不夸张。数据清洗第一步是去重。很多公开数据集里重复样本比例高得吓人如果你不去重模型会在重复样本上过拟合导致评估指标虚高。去重最简单的方式是计算文本的hash值或者用MinHash对长文本做近似去重效果都很不错。第二步是格式统一。中文里全角半角混用、繁简体混用、换行符不一致这些看着是小问题但会直接影响分词质量和模型输入的一致性。建议用标准化的清洗管线统一处理比如把全角转半角、统一日期格式、去掉无意义HTML标签等。还有一条容易被忽略的数据泄露。在做训练集/测试集划分的时候如果同一用户的帖子、同一份文档的多个片段被同时分到训练集和测试集模型实际是在开卷考试你以为的准确率水分很大。正确做法是按用户ID、文档ID等粒度做划分保证同一个来源的数据不会横跨训练和测试。这一点在NLP任务里尤其重要。3.2 标注、增强与数据版本管理标注是另一个绕不开的环节。业务方不懂AI、标注人员不读文档这几乎是常态。我的做法是把标注规范写成一份带正反例的详细文档并且先让两位标注员各自标50条拉齐一致率一般要求Kappa系数或简单一致率在0.85以上达成一致了再批量推进。批量标注过程中至少抽查10%的数据不合格的环节宁可返工也不要带病进入训练。数据增强方面文本领域有几个实用方法同义词替换用同义词词典替换不改变语义的关键词、回译中文翻译成英文再翻译回中文、EDA随机插入、交换、删除部分词等。需要注意增强数据要适度数据量翻倍左右是比较理想的范围翻太多倍可能引入噪声反而拖低效果。数据版本管理是AI工程里最容易被忽视的一环。训练数据变了模型效果变了但如果你没有记录这一版模型是拿哪一版数据训的后面排查问题将无比痛苦。工具上用DVCData Version Control或者最简单的方案每次实验记录一个数据目录的hash值随手记到实验笔记里。再配合MLflow或WandB记录训练参数和指标整个项目的可追溯性会强很多。4. Prompt Engineering与Agent开发让模型干活的关键4.1 提示词工程的核心不写咒语写说明书Prompt Engineering是这两年讨论热度最高的方向之一但很多人把它误解为找神奇咒语。我的体会恰恰相反提示词的本质是一份结构化的说明书它的目标是降低模型理解任务的歧义。一份高质量的Prompt通常包含五个要素角色设定你是谁、任务描述要做什么、输入输出格式怎么做、质量约束不能做什么、示例给出少量样例。举个例子如果你要做个中文摘要工具一个简单的提示词是你是一名资深编辑请将以下文章压缩成100字以内的摘要要求保留核心事实和结论不要发表任何评价直接输出摘要内容。这比只写一句帮我总结一下效果好得多原因就是它把判断标准前置了。少样本示例Few-shot是另一个提升效果的重要手段。你在Prompt里给出两三个输入输出对模型就能很快学会你的格式偏好。思维链Chain-of-ThoughtCoT适合数学题、逻辑推理等复杂任务在Prompt中要求模型先分步推理再给出结论准确率往往比直接回答高不少。而结构化输出则需要利用JSON Schema、function calling等能力让模型的输出以严格的格式返回这一步对工程化落地尤其重要——你后续业务代码总不希望写一堆正则去解析自由文本吧。4.2 Agent架构设计与多AI协作Prompt Engineering再往前走一步就是AI Agent。Agent这个词今年火得不行天天有人问。其实我的理解很简单Agent就是能自主规划、调用工具、循环决策直到完成目标的大模型应用。它把一次问答变成了一段工作流。一个典型的Agent框架包含四层模型层负责推理和决策、工具层搜索、计算器、数据库、API等、记忆层短期上下文和长期向量记忆、规划层把一个复杂任务分解成多个子任务并逐步执行。最有名的模式之一是ReActReasoning Acting模型一边思考我现在需要什么信息一边调用工具获取信息然后基于新信息继续推理形成一个循环。LangChain虽然是很多人的入门选择但它的抽象层次太多调试困难我个人的建议是小项目自己写Agent循环用大模型的function calling能力直接搭反而更可控。多AI协作是另一个热门方向今年DeepSeek公开的智能体训练新方法也让我重新思考了这条路的可行性。多Agent协作通常有两种模式一种是中心化调度由一个主Agent把任务拆给若干个子Agent收集结果后汇总输出另一种是沙盒商议多个Agent从不同角度讨论同一个问题最后投票或综合出结论。前者适合任务分解明确的场景比如写一篇包含调研、写作、排版三个环节的行业报告后者适合开放性问题比如产品需求评审。用多Agent的关键在于把每个子Agent的职责边界定清楚否则它们会在互相推诿中浪费大量token。5. 模型训练与微调从迁移学习到指令微调5.1 选基座模型决定上限的起点做AI工程很少从零预训练大模型那是成本极高的重型工程。绝大多数场景下的正确做法是选用开源基座模型然后做迁移学习或微调。基座模型的选择决定了你项目的效果天花板所以第一步就要花心思。我们可以通过一个六级评价清单来评估模型能力边界在目标任务上的基准表现、生态成熟度是否支持Hugging Face、vLLM等主流工具链、开源性权重是否可自由商用或商用需申请注意License、硬件需求参数量、显存要求是否匹配现有环境、社区活跃度issues响应速度、非官方教程数量、定制性是否有公开的微调方法和脚本。国内目前可用的开源模型很多Qwen系列、Baichuan系列、DeepSeek系列等各有特色。选型时不要只看排行榜一定要用自己的业务数据实测。这里有一个容易犯的错误盲目迷信参数量大的模型。7B模型在好的工程优化下推理速度和部署成本都远优于13B或70B如果你的任务并不复杂7B经微调后效果完全可能够用。成本是AI工程的生命线选型时务必做性价比评估。5.2 微调策略LoRA与全参微调的选择确定基座模型后就面临关键问题微调用什么策略。目前主流的选择是LoRA/QLoRA低秩适配微调和全参微调。全参微调的效果上限最高但对显存、数据量要求都很高而且大模型全参微调很容易破坏预训练学到的通用能力出现灾难性遗忘。LoRA的核心思路是冻结原模型参数只训练一小部分低秩矩阵作为增量参数训练成本大幅下降一张24GB显卡也能跑7B模型微调。QLoRA更进一步把基座模型量化到4bit显存需求又降一个量级。怎么选我的经验是如果你有几千万级的高质量领域数据可以考虑全参微调如果数据量在几十万级别以下LoRA基本够用且安全。LoRA有个常被忽略的参数rank低秩矩阵的秩。rank设大了表达能力强但容易过拟合设小了效果不明显。我一般从16开始试看验证集指标变化再调。还有个细节训练数据里指令格式要统一无论用Alpaca格式还是ShareGPT格式都要确保整体一致混用格式是很多微调效果变差的元凶。5.3 训练监控与评估训练不是启动脚本就完事了。我训练时至少盯三个指标损失曲线loss是否平稳下降、学习率调整是否生效、显存占用和训练吞吐是否正常。训练过程中的坑大多来自学习率设置不当——微调的初始学习率建议设置在1e-5到5e-5之间比预训练的学习率小一两个数量级。如果loss出现剧烈震荡就把学习率调低如果loss下降太慢可以适当提高。评估环节分两部分客观指标和人工评估。客观指标方面生成类任务看ROUGE、BLEU、BERTScore理解类任务看准确率、F1检索任务看RecallK等。但客观指标不能完全反映业务效果尤其生成任务所以我们每次微调完都会做人工抽评把模型的输出和真实业务预期放在一起看。实践下来混合评估的结果才更接近真实上线效果。这里我推荐一个工作流每次实验用MLflow统一记录训练参数、数据版本、评估指标和模型产物地址。没有这套记录体系你调三个版本之后就根本分不清哪个模型对应哪份数据、哪组超参了。6. 模型部署与工程化落地6.1 推理服务化的三种路线模型训练完了真正考验工程能力的是部署。目前推理服务化有三条主流路线对应不同规模的项目。第一条FastAPI/Flask封装加PyTorch推理。这是最简单的方案适合原型验证和内部工具。把模型加载到内存定义输入输出接口用Uvicorn起服务即可。缺点是一次只能处理一个请求或少量并发吞吐量上不去。第二条使用专用推理框架比如vLLM、TGIText Generation Inference、TensorRT-LLM。vLLM是目前社区使用最广泛的方案它通过PagedAttention技术大幅提升推理吞吐支持连续批处理对并发请求的利用率很高。我实测下来同样的GPUvLLM的吞吐比朴素PyTorch推理高3到5倍以上这在生产场景中是决定性的。第三条如果是少量调用且对延迟要求不高直接用模型平台的API服务也是一个选项虽然少了自己部署的灵活性和成本控制空间但胜在省心。选路线的核心判断依据是QPS每秒查询数和延迟要求。日均千次以内的小流量应用FastAPI就够了对外提供稳定的高并发服务直接上vLLM。另有一个中间方案值得提一下先用API快速上线业务等手段成熟了再替换成自部署这个策略对我来说是性价比最高的演进路径。6.2 性能优化与成本控制模型部署后的性能优化首先看三个指标单次请求延迟TTFT首Token延迟、生成速度Tokens/s和成本每千Token成本。vLLM的推理参数里有几个值得细调max-model-len控制最大上下文长度它和显存占用直接相关设太大会浪费显存gpu-memory-utilization建议设到0.85到0.95之间如果并发量特别大还应该启用分布式推理把负载拆到多张卡上。另一层优化是模型瘦身FP16半精度推理是基操INT8/INT4量化可以进一步把显存需求砍半但可能带来1%到3%的效果损失。对业务方来说如果影响很小量化带来的成本收益是非常划算的。部署形态方面先用Docker把服务打包再用Kubernetes管理自动扩缩容流量上来时自动加副本流量回落时缩容这是生产环境的标准操作。很多小团队一听K8s就头疼我的建议是单机直接用Docker Compose就能跑得很舒服等确实有多机需求再上K8s不迟。网络层面也要注意AI服务通常要配合Nginx做反向代理和负载均衡同时把API网关的限流、鉴权、日志审计这些通用能力放在同一层这样业务代码可以更专注。7. 端到端实战从零搭建一个知识库问答助手7.1 需求分析与架构选型前面讲了很多原理和组件我用一个完整案例把整条链路串一遍搭建一个企业内部知识库问答助手。假设你所在公司有几百份产品文档、FAQ和售后工单员工想快速找到某个功能如何配置某个报错怎么处理的答案这就是典型的RAG检索增强生成场景。为什么不直接微调模型因为知识库文档更新频率高每次更新都要重新微调模型成本太高也不现实。RAG的方案是文档先切片并向量化存入向量数据库用户提问时先在库里检索最相关的片段再把片段和问题一起交给大模型生成答案。这个架构的优雅之处在于知识更新只需要增量更新向量库模型本身不用变。技术选型上向量数据库用FAISS内网小规模场景或Milvus大规模生产场景Embedding模型用开源的bge系列或text-embedding模型生成模型用Qwen或同类开源模型自部署裸框架则直接基于FastAPI自研RAG流程这样可以方便控制链路细节。7.2 RAG流程的完整实现整个流程分成两个阶段离线的索引构建和在线问答。离线索引构建的核心是文档切分。切分质量直接影响检索效果切得太粗片段里混入大量无关信息切得太细单个片段缺乏上下文语义。我的默认策略是按段落切分再根据token上限合并相邻段每段控制在300到500个token左右段间保留适度重叠。切完后用Embedding模型批量向量化存入向量库。在线问答链路用如下代码完成检索和生成# 简化版RAG在线链路 from fastapi import FastAPI from sentence_transformers import SentenceTransformer import faiss import numpy as np from openai import OpenAI app FastAPI() embedder SentenceTransformer(BAAI/bge-large-zh-v1.5) index faiss.read_index(knowledge_base.index) chunks load_chunks(chunks.json) def search(query, top_k5): vec embedder.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.array(vec), top_k) return [chunks[i] for i in ids[0]] def generate_answer(question, contexts): context_text \n\n.join(f[{i1}] {c} for i, c in enumerate(contexts)) client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) messages [ {role: system, content: 你是一个严谨的知识库助手请基于提供的资料回答用户问题如果资料中没有相关信息请明确回答不知道。}, {role: user, content: f参考资料\n{context_text}\n\n问题{question}} ] resp client.chat.completions.create( modelqwen2.5-7b-instruct, messagesmessages, temperature0.3, max_tokens512 ) return resp.choices[0].message.content app.post(/ask) def ask(question: str): contexts search(question) answer generate_answer(question, contexts) return {answer: answer, contexts: contexts}这段代码有几个细节值得注意检索时对查询向量做了归一化并使用内积距离这能让相似度分数更稳定生成时system提示词里强调了资料中没有相关信息就回答不知道这一步能显著降低幻觉问题的发生频率。温度参数设置为0.3保证答案确定性优先而不是创造性优先。7.3 上线与迭代系统上线后还要搭建评测集合和回流机制。我会从真实用户问题里随机采样200条作为评测集每周跑一次完整评测计算检索命中率、答案准确率、答案忠实度是否忠实于参考资料三个指标。忠实度的检查方法是把模型生成的句子逐句和资料原文匹配如果出现资料里完全没有的信息就要标记为候选幻觉样本。迭代的路径通常是用户反馈差的问题进到评测集评测掉点后定位是检索问题还是生成问题。检索问题的常规解法是调整切分粒度、增加重叠、换更强的Embedding模型生成问题则是优化Prompt、调整生成参数或做轻量微调。这套闭环跑起来以后系统会越用越准真正成为业务依赖的工具。8. 常见问题排查与实战心得8.1 高频问题速查表我把实操中最常遇到的故障和排查优先级整理成一张速查表对应到上面每个环节的踩坑经验随时可查。症状可能原因排查优先级训练loss下降慢或震荡学习率过高/过低、数据噪声大先调学习率再查数据训练指标好但线上效果差数据泄露、训练集与真实分布不一致检查数据划分粒度模型输出格式不符Prompt约束不明确、温度过高结构化输出约束降温度检索结果不相关切分粒度不合适、Embedding模型不匹配先调切分再换向量模型首Token延迟高上下文过长、批处理没开开连续批处理精简上下文显存不足上下文长度设太大、量化未启用调整max-model-len量化微调后通用能力下降全参微调过拟合改用LoRA减少训练步数API报错频率高接口没有限流和重试机制网关层统一处理8.2 我的实战心得与建议写到这里我想分享几条最有体感的心得。第一AI工程的核心是流程管理不是算法魔法。很多项目失败不是没人会调模型而是数据、版本、评估、部署这套基础设施没搭好。与其追求某个模型刷高分不如先把实验记录和数据血缘管清楚。第二能简单就简单能开源就开源。每引入一个新框架、一个新平台都要反问一句它的抽象让我省了多少事又让我损失了多少可控性我的经验是初始阶段尽量少用黑盒平台核心链路尽量自己掌控等你对每个环节都熟悉了再用平台提升效率也不迟。第三评测才是AI工程的北极星。没有一套贴近业务的评测集你所有的调优都是盲人摸象。我建议从项目第1天就着手建设评测集哪怕初期只有几十条也比没有强。后续所有优化决策都建立在评测数据的对比上这样项目才能稳步正向演进。最后分享一个小技巧每次训练和部署实验把关键信息整理成一个实验卡包括数据版本、模型版本、参数配置、评测指标、线上观察备注。坚持一段时间后你会发现自己对项目的掌控能力明显提升排查问题从直觉驱动变成了数据驱动。AI工程这条路没有捷径但把每一个环节的为什么都搞清楚之后你会发现那些曾经让人抓狂的问题其实都源于基本功不够扎实。把这些基本功补上从零到一是完全可以走通的一条路。