很多人以为 AI 工程是从写模型代码开始的实际上不是。真正从零开始把一个 AI 想法变成可运行、可评估、可维护的系统中间隔着的不是几篇教程而是一整套工程方法论。这个项目我完整走了一遍从环境搭建、数据准备、模型训练到 RAG 应用开发、部署上线和持续迭代踩了不少坑也沉淀了一套可以复用的流程。这篇文章就围绕“ai-engineering-from-scratch”的完整实践展开把核心思路、技术选型、实操步骤和排错经验一次性讲透适合正在入门 AI 工程、想独立完成一个端到端项目的开发者参考。1. 项目定位AI工程到底是什么为什么不叫“学AI”1.1 从“算法”到“工程”的认知转变我见过太多人把“AI 工程”和“机器学习”混为一谈。学机器学习的时候你关注的是模型精度、损失函数、梯度下降但做 AI 工程的时候你关注的是数据流水线、服务稳定性、请求延迟、模型版本、成本控制、灰度发布。这是两个完全不同层面的问题。从零开始做 AI 工程第一个要扭转的认知就是模型只是整个系统里的一小部分。一个完整的 AI 工程项目模型代码可能只占 20% 不到剩下 80% 是数据清洗、特征处理、训练管道、评估体系、推理服务、监控告警和迭代机制。如果一开始就把精力全放在“调模型”上后面一定会被数据问题和工程问题折磨到崩溃。这个项目之所以叫“from scratch”核心意思就是不走捷径从最底层的能力开始构建。不依赖任何现成的 AI 平台一键部署也不直接用别人封装好的完整解决方案而是把每一个环节亲手走一遍。这样做的好处是你对整个系统的每一个环节都有掌控力出了问题知道去哪查、怎么修而不是对着黑盒束手无策。1.2 这个项目要解决的三个核心问题在动工之前我给自己定了三个必须解决的问题这也是整个项目的核心目标。第一个问题是数据从哪来、怎么变成模型能吃的东西。真实场景的数据永远不干净重复、缺失、格式混乱、标签错误都是常态。数据工程能力是 AI 工程的地基地基不稳模型再强也白搭。第二个问题是模型训练和评估怎么做到可重复、可追踪。训练跑了一次又一次每个版本的超参数、数据集、代码状态都必须能追溯不然你根本不知道哪个改动让效果变好了。这需要搭建一套实验管理机制不一定是重型平台哪怕是一个规范的目录结构和配置文件体系都行。第三个问题是模型怎么服务于真实业务。训练好的模型只是一个文件要变成线上可调用的服务需要处理请求封装、并发控制、推理优化、异常回退。这一步最能体现“工程”二字的分量。这三个问题对应着 AI 工程的三条主线数据管道、实验管理、服务化部署。整个项目围绕这三条线展开每一部分都有对应的实操内容。1.3 技术选型的底层逻辑技术选型上我遵循的是“生态成熟优先、自己可控优先、成本可承受优先”这三个原则。生态成熟优先意味着不选小众框架。Python 搭配 PyTorch 是当前 AI 工程的主流组合文档全、社区大、踩坑案例丰富遇到问题基本都能搜到解决方案。数据科学的 pandas、NumPy、scikit-learn 也是绕不开的工具集。自己可控优先意味着所有关键环节都要有替代方案。比如向量数据库生产环境可能用 Milvus 这类专业服务但本地开发我就直接用一个轻量的 FAISS 索引功能足够、原理透明出了问题能快速定位。成本可承受优先意味着先在小规模上验证可行性再逐步扩容。整个项目先用 CPU 跑通流程再用单张消费级 GPU 做训练和推理最后才考虑多卡分布式。这个思路帮我省下了大量不必要的成本也让每一步的学习更扎实。提示刚起步的人最容易犯的错就是一开始就上重型工具链。Kubernetes、分布式训练、微服务架构这些在项目规模很小的时候都是负担而不是助力。先跑通再优化是 AI 工程里最实用的原则。2. 技术栈拆解从零开始该先学什么、后学什么2.1 Python 与数据处理绕不开的基石AI 工程的一切都建立在 Python 之上但这个“Python”不是指语法而是指用 Python 高效处理数据的能力。我把它拆成三个等级能写脚本、能用数据结构解决实际问题、能写出可维护的数据处理管道。第一个等级的标志是熟练掌握列表推导式、字典操作、文件读写、异常处理。第二个等级是会用 pandas 做数据筛选、分组、聚合、透视会用 NumPy 做向量化运算。第三个等级是能把数据清洗逻辑封装成函数或类配合配置文件或数据库实现数据版本的追踪。数据处理的实操中我最深刻的体会是永远保留原始数据清洗后的数据单独存储。我一开始直接在原始 DataFrame 上做修改后面发现数据出问题时完全没有回退的余地。后来改成“原始数据只读、清洗数据另存”的模式加上每一道清洗步骤都做了记录排查问题的效率提升了不止一倍。数据处理还有一个容易忽略的点编码和格式的统一。UTF-8、时间格式、数值格式这些看似琐碎的细节在多数据源合并的时候会变成巨大的坑。我建议从项目一开始就建立一个数据规范文档哪怕很简单也能避免后期大量的返工。2.2 机器学习与深度学习理解原理而不是背公式机器学习和深度学习的知识体系我建议按照“先原理、后框架、再实战”的顺序推进。原理部分不需要推导每一个公式但必须理解核心概念过拟合与欠拟合、偏差与方差、交叉验证、梯度下降的基本思想、常见损失函数的适用场景。深度学习的核心是理解“表征学习”这个概念。卷积神经网络怎么提取空间特征Transformer 怎么通过自注意力机制建模序列关系这些不需要自己从零实现但要能在调试模型时看懂中间过程、理解输出维度变化。我自己的学习方法是用框架跑通官方示例然后自己动手改结构、改参数观察训练曲线的变化。这种方式比单纯看书效果好得多因为每个改动带来的结果变化都会加深理解。在算法覆盖面上我建议先掌握几类基础模型线性模型作为基线、树模型处理表格数据、CNN 处理图像、Transformer 处理序列。不要贪多重点是理解不同模型在什么场景下适用、有什么优缺点。后续遇到具体问题再针对性地深入某个方向。2.3 大模型应用开发提示工程与 RAG 的工程化当前阶段做 AI 工程绕不开大语言模型的应用开发。这里的核心技术不是训练大模型而是两件事提示工程和检索增强生成RAG。提示工程不是简单地“写好 prompt”而是系统地设计、测试、优化输入让模型稳定输出高质量结果。我在实践中总结了几个要点任务指令要明确无歧义、输入输出格式要有约束、复杂任务要拆分成多轮子任务、关键步骤要提供示例Few-shot。更重要的是提示也需要像代码一样进行版本管理每次修改都要记录效果变化。RAG 是当前把大模型落地到具体业务最实用的技术方案。核心思路很简单不直接让模型回答而是先从自己的知识库中检索相关资料把资料连同问题一起交给模型让模型基于资料生成答案。这样既缓解了模型幻觉问题又能让模型“知道”私有领域知识还不需要重新训练模型。RAG 工程化的难点在于每个环节的质量把控。文档切分为多少长度合适Embedding 模型选哪个检索结果的相关性怎么评估答案生成后怎么验证这些都需要建立评估指标和测试集用数据驱动的方式持续优化。这部分我后面在实操章节还会详细展开。2.4 部署与评估模型上线只是开始模型训练完成之后部署和评估是决定项目能否真正交付的关键。部署的方式有很多种从简单到复杂依次是脚本调用、Flask/FastAPI 封装成 HTTP 接口、容器化部署、Serverless 推理服务。我建议从 FastAPI 入手它是目前 Python 生态里最合适的 API 框架。自带参数校验、文档生成、异步支持搭配 Uvicorn 作为 ASGI 服务器性能足够应对中小规模流量。封装模型推理时要注意几个细节模型加载在启动时完成而非每次请求时加载推理逻辑与 API 层分离便于单元测试输入输出要做严格的格式校验和异常处理。评估环节常常被低估。很多项目“感觉效果还不错”就上线了这是大忌。我在项目中建立了一套三层评估体系离线评估在测试集上算准确率、召回率等指标、在线评估通过日志记录线上请求和反馈、业务评估看最终业务指标是否改善。只有三层评估都通过我才敢把模型正式发布。3. 实操路线三个月走通一个完整AI工程项目的详细步骤3.1 第一阶段环境搭建与基础能力验证2周第一阶段的目标是搭好开发环境跑通最小示例验证技术方案的可行性。我花了两周时间完成的工作包括Python 虚拟环境配置、依赖管理、GPU 驱动与 CUDA 安装验证、PyTorch 安装、数据加载与预处理脚本编写、基线模型的训练与评估。环境搭建的坑非常多。首先是版本匹配问题PyTorch、CUDA、cuDNN 三者版本必须兼容否则训练时会出现莫名的错误。我的建议是严格按照官方文档的对应关系表安装不要贪新。其次是依赖管理我强烈建议用poetry或uv这类工具管理依赖而不是裸用pip install然后靠requirements.txt碰运气。依赖版本锁定在 AI 工程里非常重要否则一次环境重建就能拖慢整个项目进度。基础能力验证环节我选择了一个小规模的开源数据集完成了一个简单的文本分类任务。这个过程不是为了做出多好的效果而是为了验证整条链路数据加载、预处理、模型定义、训练循环、评估脚本、结果保存。每一环都通了后面的开发才有信心。3.2 第二阶段数据集构建与模型微调3周第二阶段的核心工作是构建真实业务场景的数据集并在预训练模型的基础上做微调。我用的是一个大语言模型作为基础模型目标是让它学会一个特定领域的文本生成任务比如从产品描述中自动生成规范化的技术文档段落。数据集构建花了大部分时间。我从公开数据源和业务模拟数据中收集原始语料经过清洗、去重、格式转换最终形成了约 2 万条训练样本。这里有个非常重要的细节训练集、验证集、测试集的划分一定要按时间或来源分层而不是纯随机。因为真实场景中模型要处理的数据往往在分布上与训练数据不完全一致随机划分会高估模型性能导致上线后效果崩盘。模型微调的过程我使用了 Hugging Face 的 Transformers 库。基础模型选择了参数量适中的开源模型既保证效果又控制资源消耗。微调时重点调整了几个超参数学习率、批量大小、训练轮数、上下文长度。我采用了小学习率加早停策略在验证集损失不再下降时及时停止训练防止过拟合。整个过程下来最大的体会微调的质量主要取决于数据质量而不是模型结构。我把训练样本里标注不一致的数据重新修正之后效果的提升比调整任何超参数都明显。所以做 AI 工程与其花大量时间纠结模型结构不如把更多的精力放在数据质量的把控上。3.3 第三阶段RAG系统实现与优化3周第三阶段做的是把大模型和知识库结合实现一个 RAG 系统。场景设定为基于企业内部技术文档回答用户的提问。这个场景很典型也是当前 AI 应用落地最密集的方向之一。RAG 系统的实现链路包括四个核心环节文档加载与解析、文本切分、向量化与索引构建、检索与答案生成。文档加载与解析是第一个难点。企业文档往往是 PDF、Word、Markdown 混杂PDF 还有扫描版和文字版之分。我用了专门的文档解析库将各类文档统一转换为纯文本并保留基础的段落结构信息。表格内容单独处理因为直接转纯文本会丢失结构导致后续检索质量严重下降。文本切分直接影响检索效果。切得太短语义不完整切得太长包含太多无关信息检索精度下降。我测试了多种切分策略后最终选择的是“按标题层级分块 固定最大长度截断”的组合方式块与块之间保留了小幅重叠确保跨块的语义连贯性。向量化与索引构建环节我对比了几种 Embedding 模型的检索效果最终选用了一个效果稳定、维度适中的中文 Embedding 模型。向量索引先用 FAISS 构建本地索引后续数据规模增长后再迁移到专业向量数据库。检索与答案生成环节我设置了“先检索 top K 个片段再重排序取 top N 个片段最后拼入 Prompt 交给模型生成”的流程。重排序这一步很重要它能显著提升最终答案的质量。我用了 cross-encoder 类型的重排序模型虽然推理速度相对慢一些但在这个场景下对答案准确率的提升非常值得。优化阶段我建立了一个包含 50 个问题的评估集覆盖了简单事实查询、多文档综合查询、模糊问题、需要拒答的场景等。每次调整切分策略或检索参数都在这个评估集上跑一遍量化对比效果而不是靠感觉。3.4 第四阶段封装、部署与持续迭代4周第四阶段把整个系统封装成可对外提供的服务并建立持续迭代的机制。我用 FastAPI 封装了四个接口问答接口、文档上传接口、知识库刷新接口、健康检查接口。问答接口是核心。每个请求携带用户问题和会话上下文服务端先执行检索流程获取相关文档片段再调用语言模型生成答案。接口返回除了答案之外还附带了引用的文档来源和置信度信息这样用户在甄别答案准确性时有据可依。文档上传接口和知识库刷新接口用于持续更新知识内容。文档上传后将进入异步处理管道经过解析、切分、向量化之后写入向量索引。这里需要注意并发安全如果多个文档同时上传索引的更新要做锁处理避免读写冲突。部署环节我选择了 Docker 容器化。Dockerfile 里固定了 Python 版本、依赖版本和系统库确保在不同环境下行为一致。容器内部运行 FastAPI 服务对外映射端口。我还配置了基本的容器资源限制防止模型推理内存溢出拖垮宿主机。持续迭代的机制上我做了三件事日志记录每次请求的详细过程、定期回放用户反馈数据、每周更新评估集并重新评测系统。这些数据会成为下一轮优化方向的依据。整个系统从最初的“能跑通”到“稳定可用”靠的就是这种循环迭代的节奏。4. 避坑实录从零开始做AI工程最常见的几个问题4.1 数据质量比模型大小重要得多这个坑我踩得最深有必要放在最前面说。项目中期我遇到过一个现象换了更大的模型效果不升反降。排查了很久才发现是训练数据里引入了大量低质量样本——有些标签错误、有些文本格式混乱让模型学到了错误的模式。换了更大的模型之后模型的学习能力更强了错误模式反而学得更彻底。教训是数据质量永远是第一优先级的。在做任何模型改进之前先用数据可视化工具检查数据分布、标注一致性、噪声比例。在数据清洗上投入的时间会在模型效果上产生数倍的回报。我在项目后期把数据清洗和标注规范的流程固化下来效果稳定了不少。另外要提一点数据不足时不要盲目用拼接、复制之类的方式扩充数据。简单复制数据会加大过拟合风险。更合理的方式是收集更多真实场景数据或者通过同义词替换、句式改写等温和的数据增强手段。4.2 评估指标选错整个优化方向都会带偏做问答系统时我一开始只关注答案的“语义相似度”认为分数越高答案越好。后来发现这个指标很不靠谱有些答案语义上挺接近但实际上答非所问有些答案表述不同但信息完全正确。只盯一个相似度指标优化方向被明显带偏。后来我引入了多维度评估体系。准确性方面用“人工标注正确率”和“忠实度评分”完整性方面检查答案中的关键信息点是否覆盖帮助性方面邀请使用者在真实场景中打分。用这些指标综合评估才能看到系统真实的表现。建议所有从零做 AI 工程的人宁可多花时间设计评估集也绝不要在评估上偷懒。一个科学的评估体系是项目迭代的“导航仪”没有它你只是在盲目地调参。4.3 上下文窗口和成本控制的博弈大语言模型的应用有一个绕不开的矛盾上下文越长回答质量往往越好但 token 成本也随之上升。RAG 系统中尤其明显如果检索回来的文档片段太多拼出来的 Prompt 可能超出上下文窗口或者推理时间明显变长。我用的策略是分层控制。第一层检索环节只取相关性最高的片段第二层重排序环节进一步压缩到最关键的片段第三层在 Prompt 中明确限制模型基于已有资料回答不额外发挥。这样既控制了 token 消耗又保证了答案质量。成本控制还有一个量化手段为每个请求记录 token 消耗和耗时汇总成每日报表。有了数据之后你才能判断哪些环节值得优化。比如我发现某个请求类型总是检索很多低相关片段优化检索策略后成本明显下降用户体验也更流畅。4.4 测试策略和传统软件工程不一样传统软件的单元测试是确定性很强的输入固定输出可预期。但 AI 系统天然带有不确定性同样的输入模型输出可能每次略有不同。这让测试变得棘手也让很多人干脆不写测试直接把服务上线。我的做法是分层测试。确定性部分按传统方式测试数据清洗函数、切分逻辑、API 参数校验、提示模板的格式拼接这些都是纯函数可以严格断言。不确定性部分用“属性测试”的方式校验输出必须符合已定义的格式、模型不返回空内容、引用的文档片段必须真实存在等。回归测试在 AI 项目里尤其重要。每次修改提示词、切分策略或检索逻辑都可能影响其他功能的表现。我在项目里维护了一个回归测试集每次变更后自动跑一遍关键场景确保没有引入明显的倒退。这个机制帮我挡掉了好几次“改好一个地方、破坏另一个地方”的事故。4.5 模型版本管理和回滚策略不能忽视模型文件动辄几个 GB不像普通代码那样用 Git 管理就行。我把模型版本管理分成了两层模型文件用对象存储保存文件名中加入版本号、训练日期和关键指标版本对应关系用 JSON 配置文件记录标明哪个版本对应哪套代码、哪套数据和哪个评估结果。这套机制在一次事故中救了整个项目。某个新训练版本效果突然变差线上服务表现明显下滑。我依靠配置文件快速回滚到上一个稳定版本整个过程只花了几分钟。如果没有版本管理机制回滚几乎不可能问题排查也会花上大半天。另外一个容易被忽略的点提示词也需要版本管理。提示词是逻辑代码的一部分每次修改都要和模型版本、测试结果关联起来。我看到很多项目模型代码管理得井井有条提示词却直接改在线上配置里出了问题也没法追溯。这个习惯非常危险尽早纠正。做 AI 工程从零到一最大的收获其实不是某一个模型跑出了多好的指标而是建立起了一整套“发现问题、定位问题、解决问题、防止再犯”的工程思维。回看整个项目数据、模型、服务、评估、版本管理每个环节单独拆出来都不算特别难难的是把它们串联成一条稳定可靠的流水线。我自己在这条路上踩过的坑、试错的经验都沉淀成了本文里的这些细节。如果你也在从零开始做 AI 工程希望这套经过验证的流程和避坑清单能帮你少走一些弯路更快做出真正可用的系统。