直接说结论现在市面上的“AI入门教程”十篇有九篇是教你怎么调现成API、怎么拼装LangChain流程少数讲训练的也只到“跑通一个notebook”为止。但你真要把一个AI系统从零搭起来、让它稳定地在生产环境里服务真实用户中间隔着的不是几行代码而是一整套工程体系。这篇文章想讲的就是这个“from-scratch”到底意味着什么——我踩过的坑、验证过的事、每次项目启动前必须补齐的六个环节以及一条可复现的从零到一路线图。写给那些不满足于做demo、想真正把AI工程化能力握在自己手里的朋友。1. 先重新定义“从零开始”AI工程不是调包是搭系统很多人理解的“从零开始”是打开终端敲pip install。我理解的是另一回事当你面前只有一个业务问题、一堆原始数据甚至还没有数据没有任何现成的模型服务你要从客观条件出发把AI系统从地基到屋顶一层层盖起来。这个过程的起点不是模型而是问题本身。1.1 动手之前必须回答清楚的三个问题第一个问题问题边界到底在哪。你要解决的是“帮助客服快速找到历史工单里的答案”还是“让客服不用翻文档就能回答用户问题”这两件事看起来像架构却完全不同——前者可能只做一个检索系统就够了后者还要面对“文档里根本没有答案”时的拒答策略。我见过太多项目第一步就跑偏到“选一个多厉害的模型”上结果训练做完才发现业务侧根本不需要那么高的准确率只需要更快的召回。第二个问题数据在不在你手里。数据是AI工程的燃料这句话每个教程都会说但实操里大部分精力恰恰是耗在这里。字段缺失、格式混乱、标注口径不统一、敏感信息没脱敏这些问题不会因为你用了大模型就消失。反而模型越强垃圾数据喂进去产生的“一本正经胡说八道”就越难抓。第三个问题算力从哪来、能持续多久。很多人评估算力只看“训练一次要花多少钱”忽略了推理阶段的长期成本。自建GPU集群和按量付费云服务要计算的不只是单价还有运维人力、扩容响应速度、数据出网合规成本。我的判断标准是如果项目未来三个月内的调用量还不确定优先按量付费不要提前锁死在自建集群里。1.2 资深从业者眼里的“AI工程”和你想的不一样同样是做AI的人有偏算法的、偏研究的、偏业务的。我给自己定位是“AI工程师”工作重心是让系统稳定、可控、可持续演进。和算法研究者最大的区别是我关心的不只是模型精度而是从数据到上线再到线上反馈的整条链路。我把AI工程拆成三个层面去看系统层数据管道、训练平台、推理服务、监控告警。这一层的目标是让“跑模型”这件事变得可靠、可重复。模型层模型选型、微调策略、评估体系。这一层的目标是让“模型效果”可度量、可解释、可回归。产品层Prompt设计、用户反馈回收、数据飞轮。这一层的目标是让AI能力真正转化业务指标。三个层面缺一环项目就会变脆。调包侠的问题在于只盯着模型层中间那一小块——能调用开源模型、能跑通微调脚本但整个系统经不起一点意外算法研究者的问题在于容易忽略系统层和产品层的成本。真正从零开始你要建立的是整个三层系统而不是某个环节的熟练操作。1.3 从零构建的完整链路一张图看懂全貌不用工具我也能把这个链路说清楚因为做过的工程基本都逃不出这个框架业务问题定义 → 数据采集与治理 → 基线评估集搭建 → 模型选型与训练/微调 → 离线评估与回归 → 推理服务封装 → 系统集成与部署 → 线上监控与迭代这条链路里最容易出错的地方反而不是模型训练而是“业务问题定义”和“基线评估集搭建”。原因很简单模型训练有损失函数帮你纠偏但业务目标定义错了后面全错评估集没搭好你根本不知道模型是变好了还是变差了。我习惯的做法是项目启动第一周不碰模型只做两件事写清楚“这个系统在什么输入下必须回答、什么输入下必须拒绝”以及“收集至少200条真实分布的业务样本作为黄金评估集”。这两个动作做完整个项目的地基就稳了。后面所有模型迭代都在这200条样本上跑分分数涨了才允许上线。2. 六个核心环节拆解AI工程的知识版图到底长什么样如果你已经理解了“系统思维”接下来就是把这条链路具象成可执行的知识版图。一个合格的AI工程师需要在这个版图的每个环节都有基本盘不能只有模型训练这一把锤子。2.1 数据工程所有AI项目的命运起点我见过太多团队在数据环节急急忙忙推进结果后面付出几倍代价。数据工程的本质不是“把数据喂进模型”而是“让数据可以被信任”。核心任务包括采集、清洗、标注、版本管理四个部分采集明确数据来源、采集频次、更新机制。内部系统数据走接口抽取外部数据要确认版权和隐私边界。清洗去重、去缺失、格式统一、敏感信息脱敏。这里特别强调去重要在“语义层面”做不是字符串完全匹配。很多垃圾数据是把同一篇文章改几个字发出来的。标注制定标注规范、设计质量控制流程多人标注一致性检查、标注数据的抽样复核。版本管理数据集也要像代码一样有版本。用DVC这类工具管理保证“模型可复现”——你训练出来的模型一年后还能用同一版本数据跑出同样的结果。数据质量的优先级永远高于模型参数。一个参数10亿的模型喂脏数据效果一定不如参数3亿的模型喂高质量数据。这不是理论推断是我实际对比过的结论。2.2 模型选型与训练从快速赢家到最终方案模型选型有一条我比较推崇的原则从最快能跑通的效果开始而不是从理论最优开始。选型金字塔从底到顶规则/启发式方案比如基于关键信息抽取正则匹配。适合边界清晰、数据量小的场景。经典机器学习逻辑回归、XGBoost、LightGBM。适合结构化数据、特征明确的任务。中小规模预训练模型比如几亿参数的模型做微调。适合数据量几万、需要垂直领域理解的场景。大模型工程化直接用开源大模型做RAG、Agent编排必要时LoRA微调。很多任务的最终方案停在第三层就够了没必要一上来就上大模型。大模型引入的部署复杂度、延迟成本和不确定性在业务价值不够大时是纯粹的负担。训练与微调环节要特别关注两件事一是分词器是否和预训练权重匹配很多新人直接换了自己的分词器导致效果崩盘二是学习率设置微调阶段如果还按从头训练的节奏去设预训练学到的知识会被快速冲掉。2.3 评估与回归体系没有评估的AI项目都是自嗨评估大概是AI工程里最被低估的环节。很多人训练完模型看一眼几张sample输出“看起来不错”就准备上线这是把项目命运交给运气。我做项目的习惯是离线评估和在线评估分开建。离线评估关注模型本身能力——在固定评估集上的准确率、召回率、拒答率、延迟在线评估关注业务效果——用户点击率、问题解决率、工单处理时长。离线评估是安全网在线评估是价值证明。评估集的设计也有讲究。不能只收集“模型答得好的样本”还要收集“边界样本”和“易错样本”。我通常在评估集里放三类标准样本有标准答案、上下文充分的问题测基础能力。边界样本需要模型做出判断“该不该回答”的问题测拒答能力。干扰样本看似相关其实无关的问题测抗干扰能力。这三类样本的比例大概是6:2:2。一套评估集跑下来你再决定模型是否能上生产环境比拍脑袋靠谱得多。2.4 推理与服务化把模型变成可用的服务训练出来的模型只是一个权重文件要变成服务还需要跨过几道坎推理引擎选型vLLM、TensorRT-LLM这类专门优化的引擎比直接用transformers的generate快几倍吞吐差距在并发场景下是数量级的。延迟控制大模型推理的延迟主要集中在显存带宽和自回归解码。如果业务要求首token延迟小于200ms你可能要做KV Cache优化、模型量化甚至在架构上取舍比如小模型先粗筛。接口设计FastAPI这类框架做模型服务封装足够关键是请求格式、超时策略、错误码要标准化。弹性扩容容器化部署让推理节点可以按负载自动扩缩容。这一环是“AI工程师”和“notebook用户”的分水岭。会训练模型的人很多能把模型稳定跑成线上服务的人少。2.5 工程化与运维可复现、可观测、可回滚模型上线只是开始。线上模型要经得起迭代、故障、回滚的考验可复现数据版本、代码版本、模型版本、推理引擎版本四个版本号要能一一对应。出问题时才能准确回到某个历史状态。可观测不只是监控CPU和内存还要监控模型性能的“语义指标”——比如在线请求中敏感话题的占比、坏case率、平均生成长度。这些指标比起物理资源更能反映模型健康度。可回滚一次模型升级如果导致线上效果下降你要能在几分钟内切回旧版本。这就需要蓝绿部署或者金丝雀发布的机制。这块用的是MLflow记录实验PrometheusGrafana做监控告警GitHub Actions做CI/CD。工程化程度决定了你的AI项目是“作品”还是“产品”。2.6 产品迭代闭环把线上反馈变成下一轮训练的燃料模型上线不是终点而是数据飞轮启动的起点。用户怎么用、如何反馈、哪些case失败了这些都是下一轮迭代最宝贵的原料失败case回收在服务层记录所有失败样本用户不满意、超时、空回复定期人工抽查标注。在线A/B测试新旧模型并行服务一部分流量按业务指标决定是否全量。数据回流将线上被验证为“好答案”的样本回流到训练集或评估集形成持续改进的正循环。没有这个闭环你的系统只会原地踏步。有了它每一轮线上反馈都在给系统喂营养让模型越用越贴合业务。3. 从零起步的技术栈选型我为什么这么选有了知识版图接下来要解决工具问题。我从零搭建AI项目时每个环节都有明确的选择逻辑核心原则是三条好事能换、环节可观测、不过度设计。逐条说我的默认选型。3.1 实验与开发环境Python uv PyTorchPython在AI生态的统治地位仍然稳固深度学习框架我默认选PyTorch因为它的动态图机制、生态覆盖HuggingFace、LoRA、vLLM等和社区活跃度都优于其他选项。依赖管理上我强烈建议直接用uv而不是pipvirtualenv。uv解析依赖的速度是pip的好几倍而且锁文件机制能保证不同机器上环境一致。做过一次多机环境重建你就会理解等环境装包等到怀疑人生是AI工程师最不值当的时间消耗。3.2 数据与特征工程Polars DuckDB DVC传统Pandas的API大家熟但在数据量大了之后内存占用太离谱。我后来切换到了Polars处理速度普遍提升一个数量级而且惰性求值机制让代码更清晰。DuckDB则是数据分析的瑞士军刀直接对Parquet/CSV文件做SQL查询不需要先导入数据库。做数据探查、统计分布、随机抽样都是一行命令的事。对于“百GB以下”的AI项目数据集这套组合完全够用不用上Spark。版本管理用DVC用起来和Git类似dvc add data/raw然后dvc push到远程存储。这样训练集、测试集、评估集的版本变化都有迹可循。3.3 训练与微调transformers peft bitsandbytesHuggingFace的transformers生态是事实标准它把预训练模型加载、tokenizer管理、训练循环封装得足够干净。我在微调阶段的基本组合是peft用LoRA做参数高效微调。在大部分业务场景全参数微调的成本和过拟合风险并不划算LoRA能调到足够好的效果而且一次只训练很小一部分参数。bitsandbytes做4bit/8bit量化加载降低显存门槛。个人开发机上也能微调几十亿参数模型。LoRA的重要超参里rank决定了微调容量越大拟合能力越强但过拟合风险也越高。我通常的起点是r16然后看评估集表现再调整而不是一开始就追求高rank。3.4 推理与服务化vLLM FastAPI Docker推理引擎在在线场景下我会优先vLLM。它把PagedAttention、连续批处理这些优化做到开箱即用吞吐量比原生HuggingFace实现提升数倍。需要支持流式输出、多并发请求的线上服务vLLM基本是绕不开的选择。API层用FastAPI轻量、异步支持好、自带OpenAPI文档。把模型封装成一个标准的REST端点后上游业务系统对接就很干净了。容器化用Docker推理服务必须镜像化否则环境漂移问题会让你线上事故不断。3.5 存储与检索向量库选择要分场景做RAG这类应用向量检索是核心组件。我的选择逻辑是数据量十万级、单机部署FAISS够用轻量、快不用额外运维。数据量百万级、需要过滤和实时更新上Qdrant或Milvus。我倾向QdrantRust写的单机性能和资源占用控制得不错Docker一键起。云厂商托管向量库如果团队没有专门的运维人力用托管服务省心很多。从零起步阶段不需要一上来就追求分布式、高可用。先把单机跑通跑稳规模需要验证了再演进架构。3.6 监控与CI/CDPrometheus Grafana GitHub Actions模型服务的监控分两层资源层GPU利用率、显存、延迟、吞吐量和语义层badcase数量、拒答率、平均答案长度。资源层用Prometheus采集指标Grafana做可视化看板语义层需要业务代码里埋点把模型输出质量信号上报到监控系统。CI/CD用GitHub Actions足够。代码推上去自动跑lint、单测、模型评估集跑分跑分达标才允许合并。模型部署做成自动化的流水线打镜像、推镜像、触发容器平台滚动更新。这一套自动化下来你在电脑上敲一个git push从代码到线上服务全自动完成这种感觉才是工程化的回报。4. 从零到一的可执行里程碑以内部文档问答助手为例知识版图和技术栈讲完我准备用一个具体的项目把全链路串起来搭建一个“内部文档问答助手”。这个项目几乎涵盖了AI工程的所有核心环节而且可以真实落地。我更愿意把它叫做一条从零开始的“行军路线图”。4.1 里程碑1本地跑通最小推理闭环第一个里程碑不是训练而是“让模型先跑起来”。我在一台有单张24GB显存显卡的机器上用Qwen系列的中型模型比如Qwen2.5-7B-Instruct通过vLLM拉起一个OpenAI兼容的服务。# 安装依赖 pip install vllm # 启动模型服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name doc-qa \ --max-model-len 8192 # 验证服务可用 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: doc-qa, messages: [{role: user, content: 介绍一下你自己}] }达到这个里程碑的标志是你能通过API完成一次完整对话并且知道如何调整max-model-len和gpu-memory-utilization参数来适配自己的资。4.2 里程碑2构建高质量领域数据集问答系统的核心瓶颈是“文档内容进不了模型上下文”。所以第二步要做一个离线文档清洗和切片工具把内部文档统一转成纯文本或Markdown。按语义完整性切成512~1024字符的chunk标题、段落边界优先不机械按字数切。用Embedding模型比如BGE系列把chunk向量化存入Qdrant。from qdrant_client import QdrantClient from sentence_transformers import SentenceTransformer client QdrantClient(localhost, port6333) encoder SentenceTransformer(BAAI/bge-large-zh-v1.5) # 每个chunk转为向量并入库 records [ { id: chunk_id, vector: encoder.encode(chunk_text).tolist(), payload: {text: chunk_text, source: doc_name} } for chunk_id, chunk_text in enumerate(chunks) ] client.upsert(collection_nameinternal_docs, pointsrecords)这一步做完你实际上已经拥有了一个完整的检索模块单测可用输入问题能返回最相关的文档片段。这是RAG系统的基础底座。4.3 里程碑3设计基线评估集量化各环节效果在还没做任何微调之前就要把评估体系建好。我收集了300条覆盖业务场景的问答对其中包含标准问题、边界问题、需要拒答的问题用JSON维护。{ eval_set_version: v1, cases: [ { question: 休假申请的最长时限是多少, gold_contexts: [休假管理制度.docx], gold_answer_keywords: [30个工作日], type: standard }, { question: 显卡坏了找谁修, gold_contexts: [IT支持手册.pdf], gold_answer_keywords: [IT服务台], type: standard }, { question: 公司食堂今天的菜单是什么, gold_contexts: [], gold_answer_keywords: [], type: reject } ] }然后用一个离线评估脚本跑“检索生成”全链路统计三个指标检索召回率、答案命中率、拒答准确率。跑完会有两个结果一是你知道了自己系统当前的真实水平二是你找到了最弱的环节——是检索没召回对还是模型生成了错误答案。4.4 里程碑4LoRA微调让模型适配自己的领域如果评估下来模型在你领域知识上的回答质量不行——比如术语理解错误、结论给出过于笼统那就是微调的信号。我用LoRA做参数高效微调from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config) # 训练数据格式Instruction Context检索到的文档片段 Answer微调用的训练数据是里程碑2的检索结果人工修正答案一条一条整理出来的。训练过程中需要盯着训练loss和评估集分数不能只看loss下降——因为loss下降可能存在过拟合评估集分数才是最终检验标准。4.5 里程碑5服务化封装与端到端部署全链路验证通过后就用FastAPI封装成产品级服务。接口设计为接收用户问题 → 检索相关chunk → 组装Prompt → 调用vLLM生成 → 返回答案和引用来源。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QARequest(BaseModel): question: str app.post(/api/qa) def qa(req: QARequest): chunks search_docs(req.question, top_k3) prompt build_prompt(req.question, chunks) answer llm_client.generate(prompt) return {answer: answer, sources: [c[source] for c in chunks]}然后Docker化把模型推理服务vLLM、检索服务QdrantAPI编排好走GitHub Actions流水线实现自动构建。到这一步你的系统已经是一个完整可交付的AI工程服务了。外部评估、压测、上线、监控是随之而来的日常工作。5. 我在从零构建中踩过的五个真实坑理论上限之外的工程经验很多时候是在事故中学到的。把我的翻车现场复盘下来给还没上路的朋友省点医疗费。5.1 坑一本地环境正常上容器直接崩现象本地跑vLLM推理一切正常打包成Docker镜像后启动报CUDA error反复重启无效。排查链路一开始怀疑是代码问题翻了半天没有任何改动。然后怀疑模型文件损坏重新下载依然不行。最后把宿主机和容器里的nvidia-smi输出对比了一遍才发现容器里的CUDA版本和宿主机驱动不匹配vLLM编译的CUDA算子因为版本不兼容直接无法初始化。根因本地开发机CUDA版本是12.1但生产容器基础镜像用的是CUDA 11.8底层驱动不匹配。解决与预防基础镜像统一用固定的CUDA版本标签比如nvidia/cuda:12.1.0-runtime-ubuntu22.04Dockerfile里的所有环境依赖锁定版本。以后新项目起步时先定镜像再写代码不再让环境成为变量。5.2 坑二训练集和评估集数据泄漏指标虚高到离谱现象微调后的模型在评估集上准确率达到98%我差点直接宣布项目成功。结果人工抽查线上badcase时发现系统经常返回训练数据里的原文而不是用户问题的答案。排查链路先是怀疑微调过拟合加了更多正则和dropout情况没有改善。后来我检查训练脚本的清洗逻辑发现构造训练数据时把一部分评估集样本当成上下文片段写进了训练样本——样本对内容高度重叠。根因训练数据的文档切分和评估集来自同一个源文档切分时没有做文档级去重训练数据里的“金标准答案”被当成了检索chunk进入上下文。解决与预防训练集和评估集必须做文档级隔离——同一篇文档的所有内容只能出现在一侧。同时评估集建立后不允许随意见“扩充”每次增加样本都要记录变更理由和时间防止阴差阳错把训练样本混进去。5.3 坑三微调加了领域分词推理时tokenizer没对上现象LoRA微调效果不错但部署到推理服务后模型输出的内容开始出现诡异的重复片段像是“记忆力受损”。排查链路先查推理引擎配置没有异常。再查模型加载器还是没发现问题。最后把微调脚本和部署脚本的tokenizer逐字节对比发现微调时给tokenizer添加了十几个领域专属token而部署时用的是原始tokenizer文件。根因新增token后重新训练了embedding和lm_head矩阵但部署端缺少这些token的映射导致输出错位。解决与预防微调后的模型保存时必须单独保存tokenizer部署镜像里强制使用微调产出的tokenizer文件。现在我在CI流水线里加了一步模型完整性检查——计算微调前后tokenizer的vocab size差异超过阈值直接红警。5.4 坑四延迟和吞吐的估算比实际情况乐观了十倍现象压测时单请求延迟300ms我以为能做到每秒3个并发请求的平稳服务。结果线上流量稍微一上来延迟就飙升到3秒以上大量请求超时。排查链路先看监控指标GPU利用率并不高但请求排队严重。查了推理引擎日志才知道在线并发场景下vLLM做了连续批处理多个请求会被塞进同一个batch里解码——单请求延迟和单并发延迟并非线性关系batch变大后每个请求的等待时间都在增加。根因我在容量规划时只算了单请求延迟没有考虑并发对解码批处理的影响。显存和计算吞吐很快被batch内最慢的请求拖住。解决与预防容量评估不能只看单请求耗时要看“并发数×单请求生成长度”对延迟分布的影响。现在压测标准是在目标并发条件下p95延迟不超过业务容忍值p99不超过两倍否则就要扩容或裁剪上下文长度。5.5 坑五为了“大模型”而大模型把简单问题复杂化现象一个“短文本分类”任务团队决策要上一套大模型RAG微调的架构光是基础设施搭建就花了两周线上效果却不如一个简单的关键词规则系统。排查链路不是技术问题是技术决策问题。回头复盘时发现需求文档里写的是“区分有限类别的用户反馈”数据量几千条。这类任务用一个几百万参数的文本分类模型甚至简单TF-IDF逻辑回归就能达到同样效果大模型的成本和延迟纯粹是浪费。根因赶时髦的心态压过了工程判断。大模型不是万能银弹选型应该严格按任务复杂度、数据规模、延迟成本三个维度来决策。解决与预防现在我的项目启动第一步就是“选型压力测试”先用简单方法跑出baseline规则→经典ML→小模型。只有证明了简单方案确实到顶了再考虑大模型路线。这个顺序帮助我避免了好几次无谓的复杂度投入。最后再分享一点个人的体会做了这么多年AI工程最大的感受是会写训练代码的人很多能把一个AI系统稳定地跑上一年、持续迭代、线上出故障能快速定位根因的人很少。从零开始的每一步都没有捷径但每一步都可以用工程方法沉淀成可复用的资产。我自己的一个小习惯是每个项目启动时先写“验收标准”再写代码——把“什么情况下系统算成功”用可量化的指标写清楚。这个习惯帮我拦下了不少不该做的项目也让我在项目推进到一半时不至于迷失方向。如果你的第一个AI项目还停留在“找个模型跑一下”的阶段希望这篇分享能帮你把目光放远一点模型只是系统的一个零件真正值钱的是把整个系统搭起来的能力。
从零构建AI系统：六大核心环节与生产级落地路线图
直接说结论现在市面上的“AI入门教程”十篇有九篇是教你怎么调现成API、怎么拼装LangChain流程少数讲训练的也只到“跑通一个notebook”为止。但你真要把一个AI系统从零搭起来、让它稳定地在生产环境里服务真实用户中间隔着的不是几行代码而是一整套工程体系。这篇文章想讲的就是这个“from-scratch”到底意味着什么——我踩过的坑、验证过的事、每次项目启动前必须补齐的六个环节以及一条可复现的从零到一路线图。写给那些不满足于做demo、想真正把AI工程化能力握在自己手里的朋友。1. 先重新定义“从零开始”AI工程不是调包是搭系统很多人理解的“从零开始”是打开终端敲pip install。我理解的是另一回事当你面前只有一个业务问题、一堆原始数据甚至还没有数据没有任何现成的模型服务你要从客观条件出发把AI系统从地基到屋顶一层层盖起来。这个过程的起点不是模型而是问题本身。1.1 动手之前必须回答清楚的三个问题第一个问题问题边界到底在哪。你要解决的是“帮助客服快速找到历史工单里的答案”还是“让客服不用翻文档就能回答用户问题”这两件事看起来像架构却完全不同——前者可能只做一个检索系统就够了后者还要面对“文档里根本没有答案”时的拒答策略。我见过太多项目第一步就跑偏到“选一个多厉害的模型”上结果训练做完才发现业务侧根本不需要那么高的准确率只需要更快的召回。第二个问题数据在不在你手里。数据是AI工程的燃料这句话每个教程都会说但实操里大部分精力恰恰是耗在这里。字段缺失、格式混乱、标注口径不统一、敏感信息没脱敏这些问题不会因为你用了大模型就消失。反而模型越强垃圾数据喂进去产生的“一本正经胡说八道”就越难抓。第三个问题算力从哪来、能持续多久。很多人评估算力只看“训练一次要花多少钱”忽略了推理阶段的长期成本。自建GPU集群和按量付费云服务要计算的不只是单价还有运维人力、扩容响应速度、数据出网合规成本。我的判断标准是如果项目未来三个月内的调用量还不确定优先按量付费不要提前锁死在自建集群里。1.2 资深从业者眼里的“AI工程”和你想的不一样同样是做AI的人有偏算法的、偏研究的、偏业务的。我给自己定位是“AI工程师”工作重心是让系统稳定、可控、可持续演进。和算法研究者最大的区别是我关心的不只是模型精度而是从数据到上线再到线上反馈的整条链路。我把AI工程拆成三个层面去看系统层数据管道、训练平台、推理服务、监控告警。这一层的目标是让“跑模型”这件事变得可靠、可重复。模型层模型选型、微调策略、评估体系。这一层的目标是让“模型效果”可度量、可解释、可回归。产品层Prompt设计、用户反馈回收、数据飞轮。这一层的目标是让AI能力真正转化业务指标。三个层面缺一环项目就会变脆。调包侠的问题在于只盯着模型层中间那一小块——能调用开源模型、能跑通微调脚本但整个系统经不起一点意外算法研究者的问题在于容易忽略系统层和产品层的成本。真正从零开始你要建立的是整个三层系统而不是某个环节的熟练操作。1.3 从零构建的完整链路一张图看懂全貌不用工具我也能把这个链路说清楚因为做过的工程基本都逃不出这个框架业务问题定义 → 数据采集与治理 → 基线评估集搭建 → 模型选型与训练/微调 → 离线评估与回归 → 推理服务封装 → 系统集成与部署 → 线上监控与迭代这条链路里最容易出错的地方反而不是模型训练而是“业务问题定义”和“基线评估集搭建”。原因很简单模型训练有损失函数帮你纠偏但业务目标定义错了后面全错评估集没搭好你根本不知道模型是变好了还是变差了。我习惯的做法是项目启动第一周不碰模型只做两件事写清楚“这个系统在什么输入下必须回答、什么输入下必须拒绝”以及“收集至少200条真实分布的业务样本作为黄金评估集”。这两个动作做完整个项目的地基就稳了。后面所有模型迭代都在这200条样本上跑分分数涨了才允许上线。2. 六个核心环节拆解AI工程的知识版图到底长什么样如果你已经理解了“系统思维”接下来就是把这条链路具象成可执行的知识版图。一个合格的AI工程师需要在这个版图的每个环节都有基本盘不能只有模型训练这一把锤子。2.1 数据工程所有AI项目的命运起点我见过太多团队在数据环节急急忙忙推进结果后面付出几倍代价。数据工程的本质不是“把数据喂进模型”而是“让数据可以被信任”。核心任务包括采集、清洗、标注、版本管理四个部分采集明确数据来源、采集频次、更新机制。内部系统数据走接口抽取外部数据要确认版权和隐私边界。清洗去重、去缺失、格式统一、敏感信息脱敏。这里特别强调去重要在“语义层面”做不是字符串完全匹配。很多垃圾数据是把同一篇文章改几个字发出来的。标注制定标注规范、设计质量控制流程多人标注一致性检查、标注数据的抽样复核。版本管理数据集也要像代码一样有版本。用DVC这类工具管理保证“模型可复现”——你训练出来的模型一年后还能用同一版本数据跑出同样的结果。数据质量的优先级永远高于模型参数。一个参数10亿的模型喂脏数据效果一定不如参数3亿的模型喂高质量数据。这不是理论推断是我实际对比过的结论。2.2 模型选型与训练从快速赢家到最终方案模型选型有一条我比较推崇的原则从最快能跑通的效果开始而不是从理论最优开始。选型金字塔从底到顶规则/启发式方案比如基于关键信息抽取正则匹配。适合边界清晰、数据量小的场景。经典机器学习逻辑回归、XGBoost、LightGBM。适合结构化数据、特征明确的任务。中小规模预训练模型比如几亿参数的模型做微调。适合数据量几万、需要垂直领域理解的场景。大模型工程化直接用开源大模型做RAG、Agent编排必要时LoRA微调。很多任务的最终方案停在第三层就够了没必要一上来就上大模型。大模型引入的部署复杂度、延迟成本和不确定性在业务价值不够大时是纯粹的负担。训练与微调环节要特别关注两件事一是分词器是否和预训练权重匹配很多新人直接换了自己的分词器导致效果崩盘二是学习率设置微调阶段如果还按从头训练的节奏去设预训练学到的知识会被快速冲掉。2.3 评估与回归体系没有评估的AI项目都是自嗨评估大概是AI工程里最被低估的环节。很多人训练完模型看一眼几张sample输出“看起来不错”就准备上线这是把项目命运交给运气。我做项目的习惯是离线评估和在线评估分开建。离线评估关注模型本身能力——在固定评估集上的准确率、召回率、拒答率、延迟在线评估关注业务效果——用户点击率、问题解决率、工单处理时长。离线评估是安全网在线评估是价值证明。评估集的设计也有讲究。不能只收集“模型答得好的样本”还要收集“边界样本”和“易错样本”。我通常在评估集里放三类标准样本有标准答案、上下文充分的问题测基础能力。边界样本需要模型做出判断“该不该回答”的问题测拒答能力。干扰样本看似相关其实无关的问题测抗干扰能力。这三类样本的比例大概是6:2:2。一套评估集跑下来你再决定模型是否能上生产环境比拍脑袋靠谱得多。2.4 推理与服务化把模型变成可用的服务训练出来的模型只是一个权重文件要变成服务还需要跨过几道坎推理引擎选型vLLM、TensorRT-LLM这类专门优化的引擎比直接用transformers的generate快几倍吞吐差距在并发场景下是数量级的。延迟控制大模型推理的延迟主要集中在显存带宽和自回归解码。如果业务要求首token延迟小于200ms你可能要做KV Cache优化、模型量化甚至在架构上取舍比如小模型先粗筛。接口设计FastAPI这类框架做模型服务封装足够关键是请求格式、超时策略、错误码要标准化。弹性扩容容器化部署让推理节点可以按负载自动扩缩容。这一环是“AI工程师”和“notebook用户”的分水岭。会训练模型的人很多能把模型稳定跑成线上服务的人少。2.5 工程化与运维可复现、可观测、可回滚模型上线只是开始。线上模型要经得起迭代、故障、回滚的考验可复现数据版本、代码版本、模型版本、推理引擎版本四个版本号要能一一对应。出问题时才能准确回到某个历史状态。可观测不只是监控CPU和内存还要监控模型性能的“语义指标”——比如在线请求中敏感话题的占比、坏case率、平均生成长度。这些指标比起物理资源更能反映模型健康度。可回滚一次模型升级如果导致线上效果下降你要能在几分钟内切回旧版本。这就需要蓝绿部署或者金丝雀发布的机制。这块用的是MLflow记录实验PrometheusGrafana做监控告警GitHub Actions做CI/CD。工程化程度决定了你的AI项目是“作品”还是“产品”。2.6 产品迭代闭环把线上反馈变成下一轮训练的燃料模型上线不是终点而是数据飞轮启动的起点。用户怎么用、如何反馈、哪些case失败了这些都是下一轮迭代最宝贵的原料失败case回收在服务层记录所有失败样本用户不满意、超时、空回复定期人工抽查标注。在线A/B测试新旧模型并行服务一部分流量按业务指标决定是否全量。数据回流将线上被验证为“好答案”的样本回流到训练集或评估集形成持续改进的正循环。没有这个闭环你的系统只会原地踏步。有了它每一轮线上反馈都在给系统喂营养让模型越用越贴合业务。3. 从零起步的技术栈选型我为什么这么选有了知识版图接下来要解决工具问题。我从零搭建AI项目时每个环节都有明确的选择逻辑核心原则是三条好事能换、环节可观测、不过度设计。逐条说我的默认选型。3.1 实验与开发环境Python uv PyTorchPython在AI生态的统治地位仍然稳固深度学习框架我默认选PyTorch因为它的动态图机制、生态覆盖HuggingFace、LoRA、vLLM等和社区活跃度都优于其他选项。依赖管理上我强烈建议直接用uv而不是pipvirtualenv。uv解析依赖的速度是pip的好几倍而且锁文件机制能保证不同机器上环境一致。做过一次多机环境重建你就会理解等环境装包等到怀疑人生是AI工程师最不值当的时间消耗。3.2 数据与特征工程Polars DuckDB DVC传统Pandas的API大家熟但在数据量大了之后内存占用太离谱。我后来切换到了Polars处理速度普遍提升一个数量级而且惰性求值机制让代码更清晰。DuckDB则是数据分析的瑞士军刀直接对Parquet/CSV文件做SQL查询不需要先导入数据库。做数据探查、统计分布、随机抽样都是一行命令的事。对于“百GB以下”的AI项目数据集这套组合完全够用不用上Spark。版本管理用DVC用起来和Git类似dvc add data/raw然后dvc push到远程存储。这样训练集、测试集、评估集的版本变化都有迹可循。3.3 训练与微调transformers peft bitsandbytesHuggingFace的transformers生态是事实标准它把预训练模型加载、tokenizer管理、训练循环封装得足够干净。我在微调阶段的基本组合是peft用LoRA做参数高效微调。在大部分业务场景全参数微调的成本和过拟合风险并不划算LoRA能调到足够好的效果而且一次只训练很小一部分参数。bitsandbytes做4bit/8bit量化加载降低显存门槛。个人开发机上也能微调几十亿参数模型。LoRA的重要超参里rank决定了微调容量越大拟合能力越强但过拟合风险也越高。我通常的起点是r16然后看评估集表现再调整而不是一开始就追求高rank。3.4 推理与服务化vLLM FastAPI Docker推理引擎在在线场景下我会优先vLLM。它把PagedAttention、连续批处理这些优化做到开箱即用吞吐量比原生HuggingFace实现提升数倍。需要支持流式输出、多并发请求的线上服务vLLM基本是绕不开的选择。API层用FastAPI轻量、异步支持好、自带OpenAPI文档。把模型封装成一个标准的REST端点后上游业务系统对接就很干净了。容器化用Docker推理服务必须镜像化否则环境漂移问题会让你线上事故不断。3.5 存储与检索向量库选择要分场景做RAG这类应用向量检索是核心组件。我的选择逻辑是数据量十万级、单机部署FAISS够用轻量、快不用额外运维。数据量百万级、需要过滤和实时更新上Qdrant或Milvus。我倾向QdrantRust写的单机性能和资源占用控制得不错Docker一键起。云厂商托管向量库如果团队没有专门的运维人力用托管服务省心很多。从零起步阶段不需要一上来就追求分布式、高可用。先把单机跑通跑稳规模需要验证了再演进架构。3.6 监控与CI/CDPrometheus Grafana GitHub Actions模型服务的监控分两层资源层GPU利用率、显存、延迟、吞吐量和语义层badcase数量、拒答率、平均答案长度。资源层用Prometheus采集指标Grafana做可视化看板语义层需要业务代码里埋点把模型输出质量信号上报到监控系统。CI/CD用GitHub Actions足够。代码推上去自动跑lint、单测、模型评估集跑分跑分达标才允许合并。模型部署做成自动化的流水线打镜像、推镜像、触发容器平台滚动更新。这一套自动化下来你在电脑上敲一个git push从代码到线上服务全自动完成这种感觉才是工程化的回报。4. 从零到一的可执行里程碑以内部文档问答助手为例知识版图和技术栈讲完我准备用一个具体的项目把全链路串起来搭建一个“内部文档问答助手”。这个项目几乎涵盖了AI工程的所有核心环节而且可以真实落地。我更愿意把它叫做一条从零开始的“行军路线图”。4.1 里程碑1本地跑通最小推理闭环第一个里程碑不是训练而是“让模型先跑起来”。我在一台有单张24GB显存显卡的机器上用Qwen系列的中型模型比如Qwen2.5-7B-Instruct通过vLLM拉起一个OpenAI兼容的服务。# 安装依赖 pip install vllm # 启动模型服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name doc-qa \ --max-model-len 8192 # 验证服务可用 curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: doc-qa, messages: [{role: user, content: 介绍一下你自己}] }达到这个里程碑的标志是你能通过API完成一次完整对话并且知道如何调整max-model-len和gpu-memory-utilization参数来适配自己的资。4.2 里程碑2构建高质量领域数据集问答系统的核心瓶颈是“文档内容进不了模型上下文”。所以第二步要做一个离线文档清洗和切片工具把内部文档统一转成纯文本或Markdown。按语义完整性切成512~1024字符的chunk标题、段落边界优先不机械按字数切。用Embedding模型比如BGE系列把chunk向量化存入Qdrant。from qdrant_client import QdrantClient from sentence_transformers import SentenceTransformer client QdrantClient(localhost, port6333) encoder SentenceTransformer(BAAI/bge-large-zh-v1.5) # 每个chunk转为向量并入库 records [ { id: chunk_id, vector: encoder.encode(chunk_text).tolist(), payload: {text: chunk_text, source: doc_name} } for chunk_id, chunk_text in enumerate(chunks) ] client.upsert(collection_nameinternal_docs, pointsrecords)这一步做完你实际上已经拥有了一个完整的检索模块单测可用输入问题能返回最相关的文档片段。这是RAG系统的基础底座。4.3 里程碑3设计基线评估集量化各环节效果在还没做任何微调之前就要把评估体系建好。我收集了300条覆盖业务场景的问答对其中包含标准问题、边界问题、需要拒答的问题用JSON维护。{ eval_set_version: v1, cases: [ { question: 休假申请的最长时限是多少, gold_contexts: [休假管理制度.docx], gold_answer_keywords: [30个工作日], type: standard }, { question: 显卡坏了找谁修, gold_contexts: [IT支持手册.pdf], gold_answer_keywords: [IT服务台], type: standard }, { question: 公司食堂今天的菜单是什么, gold_contexts: [], gold_answer_keywords: [], type: reject } ] }然后用一个离线评估脚本跑“检索生成”全链路统计三个指标检索召回率、答案命中率、拒答准确率。跑完会有两个结果一是你知道了自己系统当前的真实水平二是你找到了最弱的环节——是检索没召回对还是模型生成了错误答案。4.4 里程碑4LoRA微调让模型适配自己的领域如果评估下来模型在你领域知识上的回答质量不行——比如术语理解错误、结论给出过于笼统那就是微调的信号。我用LoRA做参数高效微调from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config) # 训练数据格式Instruction Context检索到的文档片段 Answer微调用的训练数据是里程碑2的检索结果人工修正答案一条一条整理出来的。训练过程中需要盯着训练loss和评估集分数不能只看loss下降——因为loss下降可能存在过拟合评估集分数才是最终检验标准。4.5 里程碑5服务化封装与端到端部署全链路验证通过后就用FastAPI封装成产品级服务。接口设计为接收用户问题 → 检索相关chunk → 组装Prompt → 调用vLLM生成 → 返回答案和引用来源。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QARequest(BaseModel): question: str app.post(/api/qa) def qa(req: QARequest): chunks search_docs(req.question, top_k3) prompt build_prompt(req.question, chunks) answer llm_client.generate(prompt) return {answer: answer, sources: [c[source] for c in chunks]}然后Docker化把模型推理服务vLLM、检索服务QdrantAPI编排好走GitHub Actions流水线实现自动构建。到这一步你的系统已经是一个完整可交付的AI工程服务了。外部评估、压测、上线、监控是随之而来的日常工作。5. 我在从零构建中踩过的五个真实坑理论上限之外的工程经验很多时候是在事故中学到的。把我的翻车现场复盘下来给还没上路的朋友省点医疗费。5.1 坑一本地环境正常上容器直接崩现象本地跑vLLM推理一切正常打包成Docker镜像后启动报CUDA error反复重启无效。排查链路一开始怀疑是代码问题翻了半天没有任何改动。然后怀疑模型文件损坏重新下载依然不行。最后把宿主机和容器里的nvidia-smi输出对比了一遍才发现容器里的CUDA版本和宿主机驱动不匹配vLLM编译的CUDA算子因为版本不兼容直接无法初始化。根因本地开发机CUDA版本是12.1但生产容器基础镜像用的是CUDA 11.8底层驱动不匹配。解决与预防基础镜像统一用固定的CUDA版本标签比如nvidia/cuda:12.1.0-runtime-ubuntu22.04Dockerfile里的所有环境依赖锁定版本。以后新项目起步时先定镜像再写代码不再让环境成为变量。5.2 坑二训练集和评估集数据泄漏指标虚高到离谱现象微调后的模型在评估集上准确率达到98%我差点直接宣布项目成功。结果人工抽查线上badcase时发现系统经常返回训练数据里的原文而不是用户问题的答案。排查链路先是怀疑微调过拟合加了更多正则和dropout情况没有改善。后来我检查训练脚本的清洗逻辑发现构造训练数据时把一部分评估集样本当成上下文片段写进了训练样本——样本对内容高度重叠。根因训练数据的文档切分和评估集来自同一个源文档切分时没有做文档级去重训练数据里的“金标准答案”被当成了检索chunk进入上下文。解决与预防训练集和评估集必须做文档级隔离——同一篇文档的所有内容只能出现在一侧。同时评估集建立后不允许随意见“扩充”每次增加样本都要记录变更理由和时间防止阴差阳错把训练样本混进去。5.3 坑三微调加了领域分词推理时tokenizer没对上现象LoRA微调效果不错但部署到推理服务后模型输出的内容开始出现诡异的重复片段像是“记忆力受损”。排查链路先查推理引擎配置没有异常。再查模型加载器还是没发现问题。最后把微调脚本和部署脚本的tokenizer逐字节对比发现微调时给tokenizer添加了十几个领域专属token而部署时用的是原始tokenizer文件。根因新增token后重新训练了embedding和lm_head矩阵但部署端缺少这些token的映射导致输出错位。解决与预防微调后的模型保存时必须单独保存tokenizer部署镜像里强制使用微调产出的tokenizer文件。现在我在CI流水线里加了一步模型完整性检查——计算微调前后tokenizer的vocab size差异超过阈值直接红警。5.4 坑四延迟和吞吐的估算比实际情况乐观了十倍现象压测时单请求延迟300ms我以为能做到每秒3个并发请求的平稳服务。结果线上流量稍微一上来延迟就飙升到3秒以上大量请求超时。排查链路先看监控指标GPU利用率并不高但请求排队严重。查了推理引擎日志才知道在线并发场景下vLLM做了连续批处理多个请求会被塞进同一个batch里解码——单请求延迟和单并发延迟并非线性关系batch变大后每个请求的等待时间都在增加。根因我在容量规划时只算了单请求延迟没有考虑并发对解码批处理的影响。显存和计算吞吐很快被batch内最慢的请求拖住。解决与预防容量评估不能只看单请求耗时要看“并发数×单请求生成长度”对延迟分布的影响。现在压测标准是在目标并发条件下p95延迟不超过业务容忍值p99不超过两倍否则就要扩容或裁剪上下文长度。5.5 坑五为了“大模型”而大模型把简单问题复杂化现象一个“短文本分类”任务团队决策要上一套大模型RAG微调的架构光是基础设施搭建就花了两周线上效果却不如一个简单的关键词规则系统。排查链路不是技术问题是技术决策问题。回头复盘时发现需求文档里写的是“区分有限类别的用户反馈”数据量几千条。这类任务用一个几百万参数的文本分类模型甚至简单TF-IDF逻辑回归就能达到同样效果大模型的成本和延迟纯粹是浪费。根因赶时髦的心态压过了工程判断。大模型不是万能银弹选型应该严格按任务复杂度、数据规模、延迟成本三个维度来决策。解决与预防现在我的项目启动第一步就是“选型压力测试”先用简单方法跑出baseline规则→经典ML→小模型。只有证明了简单方案确实到顶了再考虑大模型路线。这个顺序帮助我避免了好几次无谓的复杂度投入。最后再分享一点个人的体会做了这么多年AI工程最大的感受是会写训练代码的人很多能把一个AI系统稳定地跑上一年、持续迭代、线上出故障能快速定位根因的人很少。从零开始的每一步都没有捷径但每一步都可以用工程方法沉淀成可复用的资产。我自己的一个小习惯是每个项目启动时先写“验收标准”再写代码——把“什么情况下系统算成功”用可量化的指标写清楚。这个习惯帮我拦下了不少不该做的项目也让我在项目推进到一半时不至于迷失方向。如果你的第一个AI项目还停留在“找个模型跑一下”的阶段希望这篇分享能帮你把目光放远一点模型只是系统的一个零件真正值钱的是把整个系统搭起来的能力。