企业官网建设流程全解析

这几年AI行业最不缺的就是“炼丹师”——模型能跑通、指标能刷高的人一抓一大把，但真正能把一个AI应用从Notebook搬到生产环境、稳定服务成千上万用户、出了故障能快速定位修复的“AI工程师”，反而是稀缺资源。我自己带团队这几年，面试过不少简历上写着精通PyTorch、熟悉Transformer的候选人，一聊到线上推理延迟优化、数据漂移监控、RAG系统的召回质量评估，很多人就卡壳了。

所以我特别理解“ai-engineering-from-scratch”这种项目存在的价值。它本质上不是教你调参，而是帮你建立一套从零到一的AI工程化思维框架：怎么设计一个靠谱的AI系统架构，怎么选型技术栈，怎么把模型服务化，怎么监控和评估线上表现，怎么处理那些只在真实环境中才会冒出来的坑。这篇文章我想结合自己的实战经验，把这个项目背后涉及的核心知识点拆开揉碎，讲清楚AI工程到底涵盖哪些内容、学习路径该怎么规划、以及每个关键环节有哪些避坑经验。

1. AI工程的整体画像：先搞清楚它和算法岗、数据岗的区别

很多刚入行的人容易把AI工程和数据科学、算法研究混为一谈，上来就啃论文、刷LeetCode，结果真到了做项目的时候发现完全不是那么回事。我个人的理解是，AI工程的核心不是“发明”新算法，而是“驯服”现有算法，让它能在真实业务场景里稳定、高效、可维护地运行。

1.1 AI工程、数据科学、算法研究三者边界在哪里

打个比方，算法研究员是造发动机的，他们追求的是扭矩更大、油耗更低；数据科学家是试车的，他们分析不同路况下发动机的表现，决定哪款车适合跑赛道、哪款适合跑市区；而AI工程师是负责造整辆车、并且确保它能在各种天气下安全行驶的人——发动机只是他们工作的一部分，变速箱、底盘、刹车系统、仪表盘、甚至售后维修体系都得操心。

具体到日常工作上，AI工程涉及的内容包括但不限于：数据管道和特征平台的建设、模型训练和调优的基础设施、模型部署和服务化（尤其是推理延迟和吞吐量的优化）、模型监控和告警体系、RAG系统的检索与生成链路设计、Agent的工作流编排、以及AI应用的安全和合规。这些工作不追求算法指标上的极致提升，但追求的是系统的可用性和稳定性——比如你做一个推荐系统，离线AUC从0.75涨到0.76可能意义不大，但线上推理延迟从200毫秒降到80毫秒，用户转化率可能实打实提升1个百分点。

1.2 这个项目最核心的体系架构拆解

“ai-engineering-from-scratch”这类项目最值得借鉴的地方，是它会按照AI应用从开发到上线的生命周期，帮你梳理出一条完整的技术栈学习路径。拆开来看，大体上是这几个层次：

最底层是基础设施层，包括GPU计算资源的管理、容器化和编排（Docker、Kubernetes）、数据存储和特征存储。往上一层是模型开发层，涵盖数据处理、模型训练、实验跟踪、模型评估和版本管理（比如MLflow、Weights & Biases这些工具）。再往上是模型部署和服务化层，包括推理服务框架（TorchServe、Triton Inference Server）、模型优化加速（量化、蒸馏、剪枝）、在线推理和批处理推理的架构设计。最顶层是应用编排层，包括Prompt Engineering、RAG（检索增强生成）、Agent工作流、以及和业务系统集成的API设计。

这个分层逻辑非常重要，它决定了你的学习顺序和精力分配。很多人一上来就学LangChain、学Prompt技巧，但底层的服务化、监控都没搞明白，结果做出来的东西在demo环境跑得欢，一上生产就崩。我自己带项目的习惯是：先从纵向打通一条最小链路（比如一个简单的文本分类模型从训练到上线），再横向扩展各个层次的深度。

2. 从零开始的AI工程学习路径：基础、框架、实战三步走

如果你完全是个新人，又想把AI工程这条路走扎实，我建议不要急着碰大模型微调和Agent编排，先把地基打好。这个项目在学习路径上的设计，我认为是挺合理的，它遵循一个“基础理论—核心框架—工程实践”的递进逻辑。

2.1 第一层：理论基础和目标检测式的上手节奏

数学和机器学习基础是绕不开的。线性代数、概率论、微积分这三板斧不要求你达到数学系水平，但至少要理解梯度下降是怎么回事、矩阵运算是如何被GPU加速的、交叉熵损失函数的含义是什么。这些知识是后续理解模型架构和调试模型的底层语言。

编程基础方面，Python是绝对的主流，需要熟练使用NumPy、Pandas、Matplotlib这三件套，并且要习惯用Jupyter Notebook做探索性分析。但我特别想强调的是，工程化思维要从第一天就开始培养：不要只写能跑的代码，要写可维护、可测试、可复用的代码——模块化设计、类型注解、异常处理、单元测试，这些习惯比多会一个算法重要得多。

在这个阶段，最好的实操项目不是去啃ImageNet那种大规模竞赛，而是找一个中等规模的数据集（比如Kaggle上的Titanic或者House Prices），完整走一遍数据清洗、特征工程、基线模型训练、交叉验证、超参数调优的流程。你可以从逻辑回归、决策树这种简单模型开始，把Pipeline跑通，后面再接神经网络。这一步的核心目标是建立直觉：数据质量和特征工程对模型效果的影响，往往远大于模型本身的选择。

2.2 第二层：深度学习框架的工程化使用

PyTorch是目前学术界和工业界事实上的标准框架。学习PyTorch的时候，很多人会陷入一个误区：只盯着nn.Module和model.forward()，觉得会用预训练模型做推理就算学会了。实际上工程化使用框架的关键在于理解它背后的运行机制：张量的布局和内存管理、DataLoader的并行加载机制、混合精度训练（AMP）的原理、以及多卡训练的同步方式。

我建议搞一个完整的小项目来串联这些知识点：从头实现一个简单的Transformer或者ResNet变体，然后手动写训练循环，混入学习率调度、梯度裁剪、早停和模型检查点保存。当你手动写过一遍training loop而不是只会用Trainer.fit()之后，你排查训练问题的能力会完全不同。比如loss变成NaN，有经验的工程师会快速判断是学习率过大、数据里有脏值、还是数值稳定性问题，而这种能力完全来自于对底层机制的熟悉。

2.3 第三层：拥抱生成式AI时代的工具链

现在AI工程最大的增量市场在LLM应用，所以“ai-engineering-from-scratch”这类的学习项目也基本上都会重点覆盖大模型相关的工具链。这一层有四个重点方向：Prompt Engineering（提示词工程）、RAG（检索增强生成）、Agent开发与编排、以及模型微调（Fine-tuning）。

Prompt Engineering的核心是在不改变模型参数的情况下，通过输入设计来激发模型能力。这里面有思维链（Chain-of-Thought）、few-shot示例设计、角色设定、输出格式约束等等具体技术。RAG解决的是事实性知识和时效性问题，它的核心在于文档切分策略、Embedding模型选型、向量数据库的索引和检索参数调优。Agent开发则是让大模型具备调用工具和自主决策的能力，涉及ReAct模式、工具定义的Schema设计、多步推理的容错机制等。模型微调则是深度定制，用领域数据把模型本身的权重调整到更适配特定任务。

这四个方向不是互相替代的关系，而是一个能力递进的关系：先会用Prompt拿到基线效果，然后通过RAG注入外部知识，再通过Agent框架赋予行动能力，最后当积累的数据足够多时，用微调做进一步适配。我见过很多团队一上来就微调一个7B模型，结果效果不如直接用GPT-4加几段精心设计的Prompt——工具选型要按需来，不要为了技术而技术。

3. 从Demo到系统的工程化落地：核心环节逐一拆解

学习路径只是地图，真正的功夫体现在把东西做出来的过程里。我把AI工程里最重要、也是最容易出现问题的几个环节拎出来单独讲，这些都是我在实际项目里反复踩过坑、总结过经验的地方。

3.1 数据管线：AI系统的隐形地基

数据是AI系统的燃料，但数据工程这个环节往往被重视程度不够。我们常说“Garbage in, garbage out”，大模型时代这句话依然成立——只是“脏数据”的定义变了。在传统机器学习里，脏数据是缺失值、离群点、标签错误；在LLM应用里，脏数据是低质量文本、重复内容、错误信息、不安全的指令注入、或者格式混乱的文档。

我在搭建知识库型RAG系统的时候，光是在数据清洗环节就花掉了项目周期的三分之一。源文档是各种格式的PDF、Word、Excel，里面还夹杂着扫描件和表格嵌套；直接转成文本丢给Embedding模型，检索效果烂到无法直视。后来用了一套组合拳才解决问题：先布局识别和OCR还原结构，再按语义段落切分，然后做一遍质量过滤（去重、去噪、识别无效段落），最后才是向量化入库。这一整套流程如果你用现成的工具可能半天就搭完了，但真正的差别在于对每种异常情况的处理和规则设计。

数据版本管理也是一个容易被忽略的点。训练数据、测试数据、评测数据都应该像代码一样做版本管理，保证实验的可复现性。我之前踩过一次大坑：把数据文件直接放在共享目录里，结果有同事重新导出了一批数据覆盖了原文件，整个实验基线全部失效，模型的对比结果也就完全失去了可信度。从那以后我强制所有项目都使用DVC或者Delta Lake这类数据版本工具，这应该是AI工程的底线之一。

3.2 模型开发与训练：把实验管理当作工程问题

训练一个模型本身在现在这个时代已经不算难事了，难的是高效地管理大量的实验。当你每天都在调学习率、改网络结构、换数据集，如果没有一套实验管理体系，几天之后你连自己昨天跑出来的最优结果是在哪组配置下产生的都记不清。

实验管理需要解决的三个问题是：配置的可复现性、指标的可对比性、产物的可追溯性。配置可复现意味着你的超参数、数据版本、代码版本是一一对应的，任何人拿到这份配置都能重新跑出一样的结果。指标可对比意味着每次训练都要用一个统一的评估模块去算指标，不能今天用AUC，明天换Acc，后天又看Precision@10。产物可追溯意味着最终部署的模型权重、它的训练日志、它的评估报告，每一步都有一个清晰的记录。

MLflow是我目前用得最多的一套工具，它把实验跟踪、模型注册、模型服务三个环节串在一起，整个链路比较顺畅。如果你用的是Kubernetes环境，配合Seldon Core或者KServe做模型部署，那基本上就是一套标准的工业级架构了。不过工具是次要的，核心是团队要把实验管理当成一项纪律来执行，而不是可有可无的额外负担。

3.3 模型部署与服务化：性能优化是硬功夫

模型服务化是AI工程里最考验工程能力的环节，也是“从scratch”学习时最容易被跳过、但在真实工作中权重最高的部分。训练环境里模型跑得慢一点没关系，但线上服务直接面对用户的一个点击、一次查询，延迟和吞吐都是技术债。

部署一个基础的模型服务，最快的方式是用FastAPI包一个HTTP接口，里面调一下模型的predict方法。这在流量小的内部工具场景下完全够用。但一旦你要部署一个面向C端用户、日请求量百万级的服务，就要考虑批量推理（动态batching）、GPU内存管理、多模型复用、水平扩缩容这些进阶问题了。

以Transformer类模型为例，推理优化的手段主要有这几种：半精度推理（FP16/BF16）能够让显存占用减半、速度翻倍，但要注意LayerNorm层可能存在的精度问题；TensorRT或者ONNX Runtime做图优化，在GPU上一般能再挤出一倍的性能提升；蒸馏和量化则是更激进的手段，用一个小的模型去模仿大模型的行为，或者把权重从FP16压到INT8，换来更极端的效率收益。实际项目中我还会重点检查数据预处理是否成为瓶颈：很多模型推理本身只花20毫秒，但tokenization、padding、后处理这些环节加起来反而花了80毫秒，这在长文本场景里尤其明显。

3.4 监控体系：模型上线只是开始

模型监控是整个AI工程里最容易被低估的部分。传统软件工程里，服务上线后只需要监控CPU、内存、QPS这些基础设施指标就基本够了；AI系统则完全不同，你要同时监控三套东西：系统的健康度、数据分布的漂移、以及模型决策质量的退化。

数据漂移是个特别阴险的问题。线上真实数据的分布和训练数据分布慢慢偏离的时候，模型精度是一点一点下滑的，不会突然报错，但业务指标会在不知不觉中变差。我在金融风控场景遇到过这样一个问题：一个信用评分模型上线半年后KS值从0.35降到0.29，排查下来发现是客群结构变了，新增用户群体在年龄和收入分布上和训练样本有了明显差异。这里的关键是随机抽一部分线上请求，做人工标注，动态监控真实延迟反馈的准确率。还要给核心指标设置告警阈值，比如“低置信度样本占比”“高质量问题的占比”持续性恶化，才是更敏感的预警信号。

4. RAG系统与Agent应用：直接把可落地的架构给你

现在再进一步，拆解一下当前AI应用最主流的两个形态：RAG系统（检索增强生成）和Agent应用。这部分内容我觉得是“ai-engineering-from-scratch”这类项目里含金量最高的模块，因为它是知识密集型和经验密集型交叉的领域。

4.1 一个生产级RAG系统的完整链路设计

RAG已经不是新鲜概念了，但很多人对它的理解停留在“向量数据库加LangChain就完事”的水平，导致做出的RAG问答效果很差：答不对题、有幻觉、引用信息错乱。我搭过几个RAG项目之后总结了一套比较靠谱的链路设计原则，核心是：检索决定上限，生成只是把你检索到的东西讲清楚。

整个流程要点如下：

• 文档处理阶段：按照逻辑结构（章节、小节、段落）做切分，而不是机械按固定长度切分。切分粒度建议控制在300-800个token，边界要遵循语义完整性。另外要多保留一层冗余：同一份内容可以同时存原始长段落和摘要短段落，检索时用短段落召回，用长段落作为生成上下文。
• Embedding阶段：Embedding模型的选择要匹配你的领域知识。通用域使用OpenAI的text-embedding-3或者bge系列模型都行，但垂直专业领域（比如医疗、法律、代码库）就值得花时间对比专门的领域Embedding模型，效果差距很明显。
• 检索阶段：单一的向量相似度检索不够，至少要混合检索。BM25的关键词精确匹配和向量的语义匹配是互补的，通过RRF（Reciprocal Rank Fusion）把两路的结果合并，召回的准确率会有一个明显的提升。另外要给检索召回的结果做rerank，用cross-encoder的reranker模型精细排序，只取前3-5个片段进上下文。

生成阶段的核心经验是：提示词里要强制模型忠实于提供的上下文。我自己的Prompt模板里会明确写“如果上下文不足以回答问题，请直接说明信息不足，不要猜测”，并且要求回答中标注信息来源的文档编号。这一步能显著减少幻觉。不过要说明一点，Prompt的巧妙设计是工程约束，再高明的Prompt也无法100%消除幻觉——关键敏感场景从系统架构上就应该包含校验环节。

4.2 Agent的编排：从单步调用到自主工作流

Agent是当前AI工程里最有想象空间的方向，也是工程上最棘手的方向。一个Agent系统的核心不仅仅是让大模型能调用工具，而是要让它在不确定的环境中做决策、执行多步操作、从错误中恢复。

工程实现上，Agent一定要做状态管理，用状态机来驱动，而不是把全部逻辑都塞进一个大循环里。同时在循环内逐轮运行，但外层一定要有“最大步数限制”，避免模型陷入死循环或被用户恶意输入带偏方向。

工具调用的稳定性是Agent落地最大的坑。大模型非常擅长“想象”一个工具的行为，但真实世界里工具是有输入输出约束的。我通常在定义Agent工具时会给每个工具写非常严格的输入JSON校验逻辑，并在工具内部做完整的异常捕获，让错误信息更一步到位地回传到大模型，让它能基于错误信息调整策略。

一个典型案例是，我给内部运维团队做过一个故障排查Agent，它可以调用Kubernetes的API查询Pod状态、查询日志、查看告警信息，但是之前发现这个Agent偶尔会“编造”不存在的Pod名称，或者理解错命名空间。后来加了两个修复：一个是每次调用工具前，大模型必须先从最近缓存的命名空间列表中做选择；另一个是所有查询类工具都加了一层只读权限，避免Agent在误操作下修改集群配置。

包括设计一个大模型来解析用户意图，转成JSON格式的调度指令，再路由到不同的执行模块，在关键节点穿插规则引擎做硬校验，这类混合架构（规则+大模型+程序化执行）是我目前最推荐的Agent生产落地方案。

4.3 LLM应用的可观测性

大模型应用的排障难度比传统软件高一个数量级，因为它是概率性的——同一个输入可能每次输出都不一样。很多团队反映：“流程天天变着花样的出错，有一次是检索没召回，有一次是上下文截断，还有一次是模型突发幻觉”，如果没有一套好的可观测性体系，就全靠猜。

LLM应用的可观测性有三种思路。最粗暴的方案是在代码里加埋点，把输入输出以及中间结果打到日志里，但追踪复杂流程会很凌乱。更好的方案是借助LangSmith、Langfuse、Phoenix这类专门为LLM应用设计的可观测性平台，它们会把一次带Chain、RAG、Agent等结构的请求看作一个Trace，完整记录每一步的工具调用参数、检索得分、模型生成Token数、延迟等等。这样做RAG调试的时候，可以拿一批问题数据集做批量回放测试，对比不同切分策略和检索参数下整条链路的指标表现。

有一点我需要补充提醒：实际项目里LLM级别的可观测性平台虽然有用，但它解决的是“链路追踪”这个层面的问题。评估这一层（即我们这一轮问询回答的好坏）其实还要再往上走一层，构建一套“离线评测集+自动化评估”的体系。只有离线评测真正能自动化跑了，你才可能在上线新Prompt、新模型时，有信心去改，才不会搞出一次要全量人工回归这种原始状态。

5. 从零到一的工具选型与避坑实录

工具选型是AI工程里最让人纠结的事情之一，因为技术栈的更新速度太快，今天火一个框架，明天出个新平台，选错了就浪费时间，选对了能事半功倍。我讲讲目前工业界比较常用的一套组合。

5.1 核心工具链推荐与选型理由

• 模型开发和实验：PyTorch + Hugging Face Transformers + MLflow
• Feature Store可以考虑Feast，不过目前国内用Flink做实时特征工程比较多。搭建一套完整的特征平台，还能覆盖“训练/推理数据一致性”场景。
• 数据相关：如果需要做模型任务的数据处理，Apache Spark、Ray都可以考虑；DVC或LakeFS做数据版本。
• 向量存储：这块选项最多，要按场景区分：Milvus在百万级数据量和多租户场景下优势明显；Qdrant胜在轻量、Embedding索引效率高；Weaviate胜在集成友好；pgvector适合数据规模不大（几十万量级）、已有PostgreSQL体系的团队，能交割成本最低。这个选择后面我详细说。
• LLM编排框架：LangChain生态庞大但雷点多、兼容性是隐患；LlamaIndex在RAG场景的函数库里做得更好；我自己生产中会更偏好底层的裸代码配合LangChain的单模块，而不是用Chain对象做整套串联抽象。

关于LangChain，我多说一点。它帮你集成了很多现成的组件，刚上手时确实爽。但封装层级太多，出问题的时候你很难定位，而且内部函数的返回结构经常在各个版本之间变。很多工程团队到了生产环境之后都会逐渐用原生代码替代掉LangChain的链式调用，只保留它的一些集成工具类，这算是过来人的一条经验。

5.2 向量数据库选型的实战对比

最近很多人问，怎么合理选择向量库方案。这取决于几个关键变量：你的数据量级、查询QPS、和现有技术栈的耦合度。

从成本控制角度讲，如果你的Embedding条数少于50万，用pgvector是最省事的——你不需要额外维护一个分布式系统，直接在现有PostgreSQL里加一个向量字段，熟悉SQL的团队很快就能上手。

如果数据量到了千万级，或者你需要动态调整索引参数，Milvus则是更合适的选择。Milvus支持磁盘索引、标量过滤与向量检索混合查询，而且生态相对成熟，配合Kubernetes部署，扩缩容都比较方便。Qdrant的优势是Rust写的，性能很能打，部署简单，适合小团队快速起步。Chroma通常只适合demo级别的应用，生产环境我目前不会推荐它。

选型还有一个硬指标：要看它的“过滤式检索”能力。很多业务场景的检索不是全量找相似，而是限定在某个类别、某个业务域、某个时间段内找相似。比如电商场景里的“在某品牌、某品类下找相似商品”，如果向量库的标量过滤性能不行，检索延迟就会失控。

5.3 盘点几个典型的回避方案和技术选项

看到“从零开始”这四个字，很多人容易陷入一个误区：什么都想自己实现。我见过有人一个RAG项目里坚持不用向量库，自己手写余弦相似度搜索，结果几万条数据的时候检索延迟已经超过1秒——这是个非常典型的错误，效率也就是所谓“工程化场景的技术债”。另一个误区是，总是想一步到位地上大模型微调，结果以微小的效果提升换回了巨大的运维成本。实际上如果Prompt+RAG能解决80%问题，就坚决不要微调；只有当任务的数据分布相对稳定、需要学习特定风格或特定输出格式、而且持续调用量大到值得摊薄推理成本时，微调才是合理的选项。

关于AI工程里“热门”的AutoML技术，也要冷处理一下。这类工具有其价值，但它没有取代AI工程师的判断力。工程师的价值恰好在于定义问题、判断评估标准、设定约束条件、做最终技术决策，自动化框架在这些前提下帮你缩小搜索空间，但也仅此而已了。

6. 一个从0到1的快题路径：把零散信息串成一个完整项目

纸上得来终觉浅，下面我提供一个具体可落地的“从0到1”快题路径，方便你把刚才谈到的那些知识点串联成一条可执行的路线图。这个路径不需要你有一个真实的大规模业务场景，但它的产出物能代表你具备了AI工程的核心能力。

6.1 建议课程设计：一个带监控和评估的知识库问答系统

做一个“面向某个特定领域（比如某个开源项目的技术文档）的智能问答辅助系统”，要求系统不仅可以回答问题，还要能告诉我们它回答得好不好，这个设计我觉得特别值得推荐。

第一步，爬取该开源项目的官方文档和GitHub上的README，做数据清洗和结构化解构。第二步，搭建RAG链路：构建文档Embedding库（可以用OpenAI Embedding API或者跑一个开源的bge-m3），搭建混合检索（BM25+向量）、Rerank，最终用GPT等API生成回答。第三步，开发离在线评估模块：准备一批标准问题和参考答案组成评测集，离线跑一遍，统计RAG系统的召回指标和生成的准确率。第四步，上线一个带基本监控的API服务：用FastAPI部署，接入日志系统，把每次检索的命中情况、上下文长度、模型调用Token数都记录下来，再加上一个简单的数据漂移监控模块。

这套内容做完，你对AI工程的整个生命周期就有比较全面的体感了，而且拿出来放在简历上也能比较有说服力地证明你具备工程能力。

6.2 我踩过的主流的坑，先替你垫个底

在收尾前，我把自己在这条路上踩到的一些典型坑集中列一下，方便你实操时避让：第一个重复出现的坑是Embedding用默认参数，切分器根本没调过，5分钟之内跑通demo后定向做一个固定的“自动短信重发”项目，这样会导致召回指标一测就崩；第二个是忽略上下文长度的变化，总把整段文档拼在一起进上下文窗口，结果经常因为超出Token数而报错——实际上LLM的上下文窗口不是给你塞满用的，在调用长上下文模型时，越长的上下文往往意味着推理时间越长、费用越高，你应该尽量给最精简有效的上下文；第三个是混淆离线评估和线上效果的关系，缺少一套真实采集样本的反馈闭环。另外，用“本地模型”的时候尤其要注意模型量化后的效果退化问题，4比特量化在某些特定任务上可能会让准确率掉的比较大，务必用评测集把关之后再上生产。

讲在最后的话

做AI工程这几年，我越来越觉得这门手艺有点像Unix的哲学——不是追求某一个环节做到极致，而是让整个链条没有明显的短板。数据、模型、部署、监控、评估、迭代，每一环都差不多水平，系统整体才靠谱。如果你现在正准备从零开始学AI工程，可以按这个思路来规划：先扎扎实实把一条最小链路跑通，再横向补各个模块的深度，然后挑一个自己感兴趣的垂直场景做完整的端到端项目。最后记得保留一套随时能帮你做离线评测的数据集，它会是你在后续工程迭代里最有安全感的底牌。

我个人体会最深的一件事是：真正工程落地时几乎不存在“银弹”，多多了解实际项目的那个“多少有点脏”的面容，远比在精密的理念图里打转管用。希望这篇分享对你的AI工程之路有帮助。