说实话，身边很多人第一次听到“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工程体系里，最值得先刻在脑子里的框架是四条主线。我把它们整理成一张表，方便对照着理解：

这四条主线不是割裂的，它们相互咬合。数据质量决定模型上限，评估标准决定迭代方向，部署稳定性决定业务价值。我在带新人时，会让他们先照着四个象限把项目拆一遍，哪怕只是一个很小的功能，也要把每条线都标出来。这样做的好处是能快速暴露出项目的薄弱环节，而不是等到上线前才发现问题堆在某个角落里。

1.3 与传统软件工程相比，AI工程难在哪

如果已经做过传统软件开发，你会觉得AI工程最别扭的地方在于“不确定性”。传统代码只要符合逻辑，同样的输入基本会有稳定输出。但AI系统不一样，模型本身有概率性，数据分布会漂移，甚至同一个模型的多次输出都可能不同。这就导致“测试通过”变成一个模糊概念——你需要用统计的方式去验证系统行为。

另外，传统软件工程的“需求-设计-开发-测试-上线”线性流程，在AI工程里也经常走不通。因为效果好坏往往要等数据、模型、评测都跑起来才能判断，前期做的很多假设会在中途被推翻。我经历过好几个项目，原本以为某类特征很重要，结果消融实验一跑，发现去掉它效果反而更好；又或者是费了大力气清理的数据，模型根本不在意。这个“先假设、再验证、随时调整”的循环，就是AI工程和传统工程最不同的节奏感。

2. 从零搭建AI工程的地基：数据、模型与评测

既然要“from scratch”，我们就按真实项目从零开始的顺序，一步步把地基打牢。很多人容易忽略的是，地基顺序也有讲究：先想清楚评测指标，再去碰数据和模型。别急着训练，先定义“什么叫做好”。

2.1 数据先行：把数据当产品来治理

如果你去翻那些失败的AI项目案例，十有八九都能归结到数据根源上。但数据问题往往藏得很深，不是简单看一眼统计分布就能发现的。我在实际项目里吃过不少亏之后，总结出三个高频数据坑：

第一个坑是标注一致性。多人协作标注时，每个人对“正例”和“负例”的理解可能微妙地不同。比如内容审核里，一条“略带调侃的段子”该不该判违规？A标注员觉得没事，B标注员觉得擦边。这种不一致会直接干扰模型学习方向。我在项目里会在正式标注前先做一个“标注校准”：准备一批有争议的样本，让大家讨论对齐标准，然后再铺开标注。

第二个坑是数据泄漏。测试集里混进了训练集的数据，或者特征里包含了未来信息，都会让离线指标虚高得离谱。有一回我把用户ID直接作为特征喂给模型，结果线下准确率逼近100%，后来仔细排查才发现，模型根本就是在“记用户ID对应的标签”而已。这类问题需要拿到数据后先做一套泄漏检查流程，最简单的方式就是随机抽样做人工交叉验证。

第三个坑是样本分布不均。很多业务场景里正负样本比例可能是100：1，这个时候直接用准确率当指标毫无意义。要么做重采样，要么改用精确率、召回率、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架构：让模型学会“查资料”而非“背资料”

RAG（Retrieval-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相关片段，把片段内容按编号拼进提示词，要求模型只能依据这些片段回答，并且每个回答后面标注引用来源编号。

第五步，做功能评测和回归集。这是最容易跳过、但最不该跳过的部分。抽出20～30个有代表性的问题，覆盖“文档里直接有答案”“文档里没有答案”“需要多段落综合”三种情况，先人工写好期望答案，然后每次修改代码或prompt后都跑一遍这些问题，记录得分。这个回归集不需要特别大，但能拦住大部分回归风险。

4.2 参数选择与效果调优思路

在实操中你会发现几个关键参数对效果影响很大。第一个是检索Top K值。K太小，上下文信息不够；K太大，会混入无关片段，干扰模型回答。我一般先在3～5之间试，再根据测试集效果调整。第二个是切分的块大小。块太小语义不完整，块太大则检索精准度下降。实践中我常用256～512字（中文）作为一个段落块的参考范围。第三个是温度参数。问答类场景希望输出稳定，温度通常设0～0.3。一旦温度太高，模型容易在回答里自由发挥，出现幻觉。

调优的思路不要拍脑袋，而是每次改动只调一个变量，跑一遍回归集，看指标变化再判断。我记得有次为了提升召回率，把Top K从3调到8，结果最终回答得分的忠实度反而下降了。原因是塞进去的噪声片段干扰了模型判断。这个教训说明，RAG里“检索质量”和“生成质量”是一对需要平衡的组合，不能只看其中一项。

4.3 让流水线可持续迭代

做完上面的步骤，你已经拥有一个能跑的AI应用。但工程的意义在于可持续迭代。我建议把整个流程沉淀成一套自动化脚本或者一个简单的CI流水线，比如每次更新文档后自动重建索引，每次改动代码后自动跑回归评测；线上加日志、保存用户query和模型回答，作为后续数据分析和评测样本扩充的来源。

在真实业务场景中，用户会提出大量你没想到的问题。这些真实query是最宝贵的评测数据，别让它们流走。我每做一个Agent或问答项目，都会定期导出线上咨询记录，人工标注质量，再回流到回归集里。半年下来，评测集越来越贴近真实业务，系统的改进方向也就越来越清晰。

5. 一路踩过来的坑：AI工程质量与效率笔记

我之所以把这个放在最后，是因为这部分内容很难从文档里学到，只能靠时间和项目砸出来。踩坑不可怕，可怕的是同一个坑反复踩。我把自己高频踩过的几个坑整理成一张排查表，还在持续更新。

除了技术问题，我还想分享三个工程习惯。第一个是“先写评测再动代码”。这个我在文中反复提，因为它真的是我和团队效率提升的关键。第二个是“任何模型产出都要有可追溯性”。是哪版模型、哪版prompt、哪版数据跑出来的？把这些信息记录成“实验日志”，否则出问题你连定位都无法定位。第三个是“留出缓存与降级方案”。模型有概率性波动，外部API也可能超时，因此生产系统里一定要有超时重试、缓存命中率优化、模型不可用时的降级响应。我用过最简单也最有效的降级方案，就是提前准备好一批高频问题的固定回答，模型挂了直接走这套预案，至少服务不断。

工程做多了之后你会越来越认可一句话：AI的“智能”来自模型，但“可靠”来自工程。同样的模型，有人接出了幻觉满天飞的服务，有人做成全天候稳定的产品，差异基本都出在工程环节。这也是我一直主张“from scratch”是因为只有自己从零把每一环跑过一遍，才知道哪些环节是真正藏着魔鬼的。

如果你正准备开始，我给你一条很朴素的操作建议：不要一开始就想着做一个宏大的多功能系统，而是选定一个非常具体的、可评判效果的小场景，用本文这套思路端到端跑通它，再逐步加复杂度。一次真实跑通，胜过我在这篇文章里讲一百个大原则。过几个月你回头再看，会发现当初觉得繁琐的数据治理和评测流程，恰恰是整个系统最值钱的部分。