说实话身边很多人第一次听到“ai-engineering-from-scratch”这个标题都会反问一句AI工程还要从零开始难道不是把模型跑通就够了我干AI工程这些年早期也有过同样的幻觉。模型训练脚本能跑、loss能降、测试集上准确率还挺好看就觉得“嗯行了”。直到把模型真正塞进业务系统被线上数据的分布偏移、推理延迟、回滚机制、标注质量甚至是prompt换了个标点符号就结果大变这些事反复教育之后我才意识到所谓AI工程从来不是“训练出一个模型”那么简单。它是一整套把算法、数据、评测、部署、迭代组织成一个可靠系统的方法论。而“from scratch”这个前缀恰恰是我想在这篇文章里好好聊聊的起点。这篇文章是我基于自己实战经验的一次系统梳理。它不仅适合刚入门、想从零搭起AI工程体系的工程师也适合那些已经在调模型但总觉得“差点什么”的从业者。我会尽量用做项目的口吻把背后的设计逻辑、实践细节和踩坑过程都讲清楚保证你能直接参考着落地。1. AI工程到底在做什么先打破“模型中心主义”如果你去搜“AI工程”很容易看到一堆抽象定义。但放到真实项目里AI工程的范围其实特别具体业务方提了个需求比如“我们要做一个自动审核内容分类的系统”AI工程师要做的事情远不止“选个模型训练一下”。你得先想清楚数据从哪来、脏数据怎么处理、标注标准怎么定、模型效果用什么指标衡量、线上性能能不能扛住、模型出错之后怎么发现和回滚。我曾经接过一个需求业务方觉得很简单“你们不是有现成的开源模型吗套上就行了。”结果真正排下去才发现光是“数据到底怎么定义正负样本”就开了三轮会。有经验的人一听就明白这不是模型问题这是AI工程里的“数据语义对齐”问题。模型只是整个系统里的一个执行组件围绕它有数据管道、评测体系、部署策略、监控告警这一圈才是工程的重心。1.1 从“做一个模型”到“做一个系统”很多人在入门时习惯把重心放在模型结构、损失函数、调参技巧上这没有错但视角不够完整。模型只是“AI系统”的一个子系统。可以这么理解你要盖一栋楼模型是其中一台电梯。电梯当然重要但整栋楼的电路、消防、供水、承重结构任何一个出问题楼都住不了人。也就是说“从零开始做AI工程”的真正含义是学会围绕模型搭建完整的系统支撑。数据侧要解决“喂什么”模型侧要解决“怎么算”评测侧要解决“怎么算好”部署侧要解决“怎么稳定跑”。任何一侧缺失AI系统都会在某个环节悄悄崩掉。在我早期的项目里吃过最亏的一次就是因为只关注了模型侧。模型离线指标刷到95%结果上线后用户反馈一片“乱分类”最后排查发现线上输入的数据格式跟训练数据不一样——用户上传的字段里多了几个特殊字符预处理没统一。模型本身大概率没错但工程链条断了。这件事之后我再也没敢只看模型的训练指标而是把全链路当成一个整体来设计。1.2 四条关键主线数据、模型、评估、部署AI工程体系里最值得先刻在脑子里的框架是四条主线。我把它们整理成一张表方便对照着理解主线核心任务常见工具典型产出数据采集、清洗、标注、版本管理、质量监控SQL、pandas、Label Studio、DVC高质量数据集、数据版本模型基线选择、训练、微调、Prompt工程PyTorch、transformers、LlamaIndex可复现的模型/模型调用方案评估指标设计、离线评测、在线监控、回归测试sklearn、Weights Biases、Evidently评测报告、模型卡部署服务化、弹性伸缩、灰度发布、监控告警FastAPI、Docker、Kubernetes、Prometheus稳定运行的推理服务这四条主线不是割裂的它们相互咬合。数据质量决定模型上限评估标准决定迭代方向部署稳定性决定业务价值。我在带新人时会让他们先照着四个象限把项目拆一遍哪怕只是一个很小的功能也要把每条线都标出来。这样做的好处是能快速暴露出项目的薄弱环节而不是等到上线前才发现问题堆在某个角落里。1.3 与传统软件工程相比AI工程难在哪如果已经做过传统软件开发你会觉得AI工程最别扭的地方在于“不确定性”。传统代码只要符合逻辑同样的输入基本会有稳定输出。但AI系统不一样模型本身有概率性数据分布会漂移甚至同一个模型的多次输出都可能不同。这就导致“测试通过”变成一个模糊概念——你需要用统计的方式去验证系统行为。另外传统软件工程的“需求-设计-开发-测试-上线”线性流程在AI工程里也经常走不通。因为效果好坏往往要等数据、模型、评测都跑起来才能判断前期做的很多假设会在中途被推翻。我经历过好几个项目原本以为某类特征很重要结果消融实验一跑发现去掉它效果反而更好又或者是费了大力气清理的数据模型根本不在意。这个“先假设、再验证、随时调整”的循环就是AI工程和传统工程最不同的节奏感。2. 从零搭建AI工程的地基数据、模型与评测既然要“from scratch”我们就按真实项目从零开始的顺序一步步把地基打牢。很多人容易忽略的是地基顺序也有讲究先想清楚评测指标再去碰数据和模型。别急着训练先定义“什么叫做好”。2.1 数据先行把数据当产品来治理如果你去翻那些失败的AI项目案例十有八九都能归结到数据根源上。但数据问题往往藏得很深不是简单看一眼统计分布就能发现的。我在实际项目里吃过不少亏之后总结出三个高频数据坑第一个坑是标注一致性。多人协作标注时每个人对“正例”和“负例”的理解可能微妙地不同。比如内容审核里一条“略带调侃的段子”该不该判违规A标注员觉得没事B标注员觉得擦边。这种不一致会直接干扰模型学习方向。我在项目里会在正式标注前先做一个“标注校准”准备一批有争议的样本让大家讨论对齐标准然后再铺开标注。第二个坑是数据泄漏。测试集里混进了训练集的数据或者特征里包含了未来信息都会让离线指标虚高得离谱。有一回我把用户ID直接作为特征喂给模型结果线下准确率逼近100%后来仔细排查才发现模型根本就是在“记用户ID对应的标签”而已。这类问题需要拿到数据后先做一套泄漏检查流程最简单的方式就是随机抽样做人工交叉验证。第三个坑是样本分布不均。很多业务场景里正负样本比例可能是1001这个时候直接用准确率当指标毫无意义。要么做重采样要么改用精确率、召回率、AUC这类对分布不敏感的指标。我见过不少团队因为没处理好这个问题模型一路训练到上线才发现它对少数类样本根本毫无识别力。数据端的治理原则说白了就是“把数据当成产品来维护”。要有清晰的字段定义、质量检查规则、版本管理机制。我现在每接一个项目都会先花一定比例的时间建立数据体检表包含缺失率、唯一值数量、分布稳定性等指标并且每周出一次报告。数据质量是可观测的才能支撑起后面模型的稳定迭代。2.2 模型训练别一上来就追求SOTA模型侧的技术方案其实已经有大量成熟经验可借鉴尤其是现在开源社区非常活跃很多任务的基线模型都能直接找到。但我想特别强调一个理念不要一上来就追求SOTA。先把一个简单可靠的baseline跑通再逐步迭代。我之前带过一个项目团队里几个同学热血沸腾上来就要用大模型微调搞复杂架构。我按住他们让他们先用简单的统计规则加一个轻量分类器跑一遍花不到一天时间居然就达到业务方说“勉强能接受”的60%效果。随后我们花了两周迭代优化才慢慢逼近80%。如果一开始直接上重模型光是数据清洗和训练调试就可能耗掉三四周期间业务方早就失去耐心了。拿LLM应用来说同样遵循这个原则。很多人一上来就微调模型但实际上大部分需求靠优秀的提示工程就能解决。只有当prompt怎么调都无效、需要对特定领域的知识进行深度注入时才考虑微调。选模型也要考虑成本、延迟、可控性不能只看榜单分数。生产环境里“够用且稳定”的价值往往高于“最强但偶尔抽风”。2.3 评测体系AI工程的杠杆点我说过很多次评测体系是整个AI工程里杠杆率最高的环节。因为后续所有迭代都得有个客观的“尺子”来告诉你这次改动到底是变好了还是变差了。没有尺子优化就是盲人摸象。评测体系建设分三个层次。第一层是离线指标。分类任务看准确率、精确率、召回率、F1排序任务看NDCG、MRR生成类任务看ROUGE、BERTScore或者用LLM-as-a-Judge来做定性的打分。第二层是切片分析。光看整体指标远远不够要按不同类型样本、不同业务场景拆开看。我经常遇到整体效果很好但某个特定用户群体效果极差的情况这种fail case如果不做切片分析根本发现不了。第三层是线上监控。上线后要用真实流量来验证效果包括AB测试、效果报表、异常告警。这个环节往往最容易被忽视但恰恰是决定系统能否长期可靠运行的关键。评测不是一次性工作而是要融入迭代流程每一轮模型或prompt改动都跑一遍标准化评测出一份对比报告。我建议项目一开始就搭建好评测脚本和数据集让它成为“流水线节点”。之前我用过开源工具Weights Biases做实验记录也用Evidently做数据漂移检测效果都还行。工具可以灵活换但机制必须固定下来。3. 现代AI工程的关键拼图提示工程、RAG与Agent近两年大模型爆发之后AI工程的内涵又往外扩了一圈。以前聊AI工程主要是传统机器学习生命周期现在更多的情况是围绕大语言模型做应用开发。这也是热搜里那一堆关键词比如“prompt engineering”“ai agent”“ai native”背后真正的实践需求。在这个阶段提示工程、检索增强生成和智能体已经成为AI工程绕不开的三块关键拼图。它们本质上不是互相排斥的路线而是难度递进、能力逐级放大的方案组合。3.1 提示工程把和模型对话当成系统设计很多人把提示工程理解成“写几句漂亮的prompt”这是低估它了。我做了大量实践之后感觉它更类似于面向模型的一种需求工程。你需要把任务描述、上下文信息、输出约束、示例参考都结构化地组织起来让模型稳定地按预期输出。我在实战中常用的提示结构是“角色 任务 输入数据 输出格式 质量标准”。角色用来设定模型视角任务明确目标输入给上下文格式约束输出质量标准兜底。举个例子如果我要让模型做新闻分类一个相对稳的提示模板长这样你是一名资深新闻编辑擅长将新闻按“科技、财经、体育、娱乐、时政”分类。 以下是待分类新闻{{news_text}} 请只输出一个最匹配的类别标签不要输出解释。 如果你不确定输出“其他”。注意后缀的“如果你不确定输出‘其他’”这种护栏设计很关键。它把模型的不确定性显式暴露出来而不是让模型强行编造一个类别。在系统层面这就方便我们做兜底策略或者人工复核。提示工程还需要做好版本管理。我遇到过很坑的情况某天线上效果突然变差查了半天发现是有人可能是自己手动改了生产环境的prompt而且没记录。从那以后我要求所有prompt都放进代码仓库或配置中心变更要走评审流程。记住prompt在生产环境里就是代码必须有版本、有测试、有回滚方案。3.2 RAG架构让模型学会“查资料”而非“背资料”RAGRetrieval-Augmented Generation应该算是目前企业落地LLM应用最主流的架构了。它解决的核心问题是模型训练数据里的知识覆盖不全、时效性差企业私有知识更是无法通过训练直接注入。RAG的基本链路是把知识文档切分、向量化、存入向量数据库用户提问后先检索出最相关的知识片段再把这些片段作为上下文交给LLM组织回答。大家看着不复杂但工程化落地的时候坑很多。我梳理一个常见的处理流程文档清洗去掉页眉页脚、乱码、无关广告等噪声不然检索出来的片段可能重点全在广告上。切分策略按语义段落切分比固定长度切分更合理。固定切分容易把一句话从中间截断影响检索相关性。我常用的是按标题层级、段落边界做递归切分同时控制块大小在几百token左右。索引设计除了向量索引很多场景还要叠加关键词索引用混合检索方式提高召回精度。比如“产品型号”这类精确字符串向量检索经常匹配不准但关键词能精准命中。排序优化第一轮检索出来Top 50再用交叉编码器cross-encoder重排出Top 5能显著提升上下文质量。回答生成把检索片段、原始问题、系统指令一起拼给模型并明确要求“只能依据给定材料回答如果材料中没有就说不知道”。这套链路里每个环节都有专门的评测点切分后片段是否语义完整、检索召回率是否够高、重排后Top K质量、最终回答的忠实度。我之所以反复强调评测就是因为RAG如果不做分环节评测整体效果会非常“玄学”。你可能优化了半天最终回答结果发现瓶颈其实在文档切分上。3.3 Agent从单轮问答走向任务闭环Agent智能体是最近热度最高的方向。从工程角度看它的本质是让模型具备“规划和行动”能力通过调用工具解决多步骤任务。最简的结构可以理解为“模型 工具集 记忆 执行循环”。模型负责决策下一步做什么工具集提供执行能力记忆保存任务历史执行循环负责多轮迭代直至任务完成。但Agent的工程复杂度比单一RAG调用又上了一个台阶。最典型的问题就是状态控制和错误恢复。模型在某一步输出了错误的工具调用参数整个任务链条就可能断掉如果任务执行了十几步中途某一步失败到底是从头开始还是从失败点重试这些都需要严谨的工程机制支撑不能期待模型永远不犯错。我在落地Agent时有个很深的体会不要试图让Agent一次性完成复杂的端到端任务而是要把流程拆成多个有明确边界的子任务每个子任务用Agent能力辅助但关键节点上仍然用规则来校验。比如“从文档中提取订单信息并自动录入系统”这类操作Agent负责提取和结构化数据但录入前的关键字段校验必须走规则逻辑。这种“Agent做决策、规则做兜底”的混合模式生产环境里的可靠性要高得多。另外选择Agent框架也需要务实。LangGraph这类工具能帮你管理复杂的图状态但如果任务只是简单几步用纯代码编排可能更直白、更好维护。不要为了炫技用重型框架。我之前就吃过这个亏用了框架自带的状态节点结果排查一个bug都要绕半天后面直接改成代码硬编排反而清爽了。4. 实操用最小成本跑通一条AI工程流水线原则说得再多不如上手做一遍。我在这里分享一个“极简AI工程流水线”的搭建过程从零开始、不依赖太重的基础设施适合个人或小团队快速验证。我建议的目标场景是做一个“基于内部知识文档的智能问答助手”。这也是目前绝大多数企业拥抱大模型时的第一步。需求一句话就能说清用户提问系统基于上传的文档给出有依据的回答。接下来我们按工程主线一步步落地。4.1 端到端搭建步骤第一步环境准备。用Python语言创建虚拟环境安装核心依赖用于向量化的sentence-transformers、用于编排的LangChain或LlamaIndex、用于API调用的openai库或者其他模型厂商的SDK、用于向量存储的Chroma或FAISS。这些工具都是社区里验证过的个人项目足够用了。第二步数据准备。找一些真实的内部文档比如产品说明、FAQ、操作手册放进一个文件夹。先写一个简单的解析脚本把文本抽出来做基本清洗。这里不用追求自动化处理所有格式先在“能用”的层面跑通。第三步搭建索引。把清洗后的文档按语义段落做切分用embedding模型向量化写入向量库。代码示意如下伪代码可按实际框架调整from sentence_transformers import SentenceTransformer import chromadb model SentenceTransformer(BAAI/bge-small-zh-v1.5) client chromadb.PersistentClient(path./kb_store) collection client.get_or_create_collection(docs) # 切分段落并写入向量库 for chunk_id, chunk_text in chunks.items(): vec model.encode(chunk_text).tolist() collection.add(ids[chunk_id], documents[chunk_text], embeddings[vec])注意选择embedding模型时要和待处理语言匹配。中文场景下BGE系列、m3e这类中文效果通常比英文原版模型好不少。做向量库示例时我用Chroma是因为它足够轻量、本地就能跑等数据量上去了再迁移到Milvus或pgvector这类更专业的方案。第四步设计检索与生成逻辑。写一个“先检索、再拼装prompt、然后调用LLM”的查询函数。用户提问后先从向量库检索Top K相关片段把片段内容按编号拼进提示词要求模型只能依据这些片段回答并且每个回答后面标注引用来源编号。第五步做功能评测和回归集。这是最容易跳过、但最不该跳过的部分。抽出2030个有代表性的问题覆盖“文档里直接有答案”“文档里没有答案”“需要多段落综合”三种情况先人工写好期望答案然后每次修改代码或prompt后都跑一遍这些问题记录得分。这个回归集不需要特别大但能拦住大部分回归风险。4.2 参数选择与效果调优思路在实操中你会发现几个关键参数对效果影响很大。第一个是检索Top K值。K太小上下文信息不够K太大会混入无关片段干扰模型回答。我一般先在35之间试再根据测试集效果调整。第二个是切分的块大小。块太小语义不完整块太大则检索精准度下降。实践中我常用256512字中文作为一个段落块的参考范围。第三个是温度参数。问答类场景希望输出稳定温度通常设00.3。一旦温度太高模型容易在回答里自由发挥出现幻觉。调优的思路不要拍脑袋而是每次改动只调一个变量跑一遍回归集看指标变化再判断。我记得有次为了提升召回率把Top K从3调到8结果最终回答得分的忠实度反而下降了。原因是塞进去的噪声片段干扰了模型判断。这个教训说明RAG里“检索质量”和“生成质量”是一对需要平衡的组合不能只看其中一项。4.3 让流水线可持续迭代做完上面的步骤你已经拥有一个能跑的AI应用。但工程的意义在于可持续迭代。我建议把整个流程沉淀成一套自动化脚本或者一个简单的CI流水线比如每次更新文档后自动重建索引每次改动代码后自动跑回归评测线上加日志、保存用户query和模型回答作为后续数据分析和评测样本扩充的来源。在真实业务场景中用户会提出大量你没想到的问题。这些真实query是最宝贵的评测数据别让它们流走。我每做一个Agent或问答项目都会定期导出线上咨询记录人工标注质量再回流到回归集里。半年下来评测集越来越贴近真实业务系统的改进方向也就越来越清晰。5. 一路踩过来的坑AI工程质量与效率笔记我之所以把这个放在最后是因为这部分内容很难从文档里学到只能靠时间和项目砸出来。踩坑不可怕可怕的是同一个坑反复踩。我把自己高频踩过的几个坑整理成一张排查表还在持续更新。症状根因排查思路与建议离线效果好、线上崩训练与线上数据分布不一致严格复现线上预处理逻辑做数据稳定性监控同一个prompt效果忽好忽坏模型温度太高或提示语变动降低温度提示版本纳入代码管理RAG回答“答非所问”检索到了噪声片段或切分断句查看检索片段ID优化切分和重排模型评测得分上涨但业务方不满意评测指标与业务目标脱节重建评测集引入业务方参与标准制定Agent中途反复卡死工具调用参数错误且无恢复机制加校验和重试逻辑拆分子任务规则兜底除了技术问题我还想分享三个工程习惯。第一个是“先写评测再动代码”。这个我在文中反复提因为它真的是我和团队效率提升的关键。第二个是“任何模型产出都要有可追溯性”。是哪版模型、哪版prompt、哪版数据跑出来的把这些信息记录成“实验日志”否则出问题你连定位都无法定位。第三个是“留出缓存与降级方案”。模型有概率性波动外部API也可能超时因此生产系统里一定要有超时重试、缓存命中率优化、模型不可用时的降级响应。我用过最简单也最有效的降级方案就是提前准备好一批高频问题的固定回答模型挂了直接走这套预案至少服务不断。工程做多了之后你会越来越认可一句话AI的“智能”来自模型但“可靠”来自工程。同样的模型有人接出了幻觉满天飞的服务有人做成全天候稳定的产品差异基本都出在工程环节。这也是我一直主张“from scratch”是因为只有自己从零把每一环跑过一遍才知道哪些环节是真正藏着魔鬼的。如果你正准备开始我给你一条很朴素的操作建议不要一开始就想着做一个宏大的多功能系统而是选定一个非常具体的、可评判效果的小场景用本文这套思路端到端跑通它再逐步加复杂度。一次真实跑通胜过我在这篇文章里讲一百个大原则。过几个月你回头再看会发现当初觉得繁琐的数据治理和评测流程恰恰是整个系统最值钱的部分。