企业官网建设流程全解析

1. AI工程和算法研究的分水岭：起点不同，终点完全不同

最近后台总有人问我同一个问题：想做 ai-engineering 方向，是不是把深度学习课程刷完、能训练出个模型就够了？我每次都要解释很久——因为答案恰恰相反。训练模型只是这条路上最窄的那一段，真正让人头疼的是模型前后那一大圈工程问题：数据从哪来、怎么保证稳定、上线后崩了怎么排查、迭代的时候怎么不把线上搞挂。这套东西做熟练了，你才算入行 AI 工程，而不是只会调参。

算法研究和AI工程最大的区别，可以浓缩成一句话：研究者追求的是“模型在基准集上再涨两个点”，工程师追求的是“系统在真实环境里稳定跑三个月”。方向不一样，投入的重点就完全不同。研究岗可以把80%的时间砸在模型结构和新loss上，工程岗恰恰相反，80%的精力都花在模型外围——数据管道、服务封装、监控告警、灰度上线、成本控制。

我见过太多转行的人踩同一个坑：花三个月把Transformer、扩散模型啃得滚瓜烂熟，结果到了公司发现压根没人让你从零训练一个大模型，你面对的是几十个业务方提的需求、一堆脏乱差的历史数据、还有一台随时可能爆显存的开发机。真正的AI工程落地，是从“我懂模型原理”到“我能把一个模型变成线上可用系统”的跨越，这个跨越的每一步都是工程决策。

这篇文章我就把自己做AI工程项目的完整思路拆开来讲，从问题定义、数据闭环、模型训练、部署上线到线上监控，最后再说说现在最热的LLM、RAG、Agent落地时到底要关注哪些工程细节。内容不绕弯子，全是能直接拿走用的经验。

2. 第一块基石：先把问题和数据闭环锁死，再谈模型

2.1 需求拆解：你要做的到底是哪一类AI任务

很多人拿到需求就想找模型，这是本末倒置。接到任何一个项目，第一件事是判断任务的真实类型。一样叫AI，分类、检索、生成、决策的工程链路差别是巨大的。

分类任务最成熟，重点是样本均衡和阈值调优；检索任务的核心是 embedding 质量和召回排序；生成任务要定义输出规范、处理幻觉；决策任务更麻烦，要跟业务动作联动，涉及在线学习的闭环。我见过最典型的翻车案例：业务方说要做一个“智能问答”，团队接需求后直接上手大模型API，做完了才发现真正的场景是让用户从一万条历史工单里快速找到相似案例，这本质是检索问题，用向量数据库就能解决，根本不需要大模型生成，成本和响应速度完全两码事。

这个阶段我会强制自己写一页需求确认单：输入是什么、输出是什么、谁来用、错了会怎样、延迟要求多少、数据量多大。不用写得多学术，但这些问题必须落地。很多工程灾难都是因为第一页没写清楚，后来返工成本翻十倍都算轻的。

2.2 数据采集和清洗：AI工程里最脏最累但最值钱的环节

模型不会比数据更聪明，这个道理人人都背过，但实际做起来很少有人真当回事。我接手过几个项目，模型效果差的第一刀永远不是换模型，而是数据问题：标签错乱、重复样本、时间穿越、分布偏移，每个问题都能让你的精确率原地跳水。

数据清洗有几条铁律：

• 一定要区分原始数据和特征数据，原始数据永久留存，特征数据随版本迭代，中间链路必须有记录。
• 标签与特征要分开存储，严禁在特征工程里偷偷改标签。
• 时间类特征特别容易翻车，用未来数据预测过去属于典型的数据泄漏。
• 脏数据检测要写自动化脚本，比如检查特征取值越界、标签分布突变、ID重复率。

举个具体例子：有次做一个文本分类项目，线上表现和离线评测差了十几个点。排查到最后，发现训练数据里有大量重复文本，而且重复样本的标签是互相矛盾的——同一个用户投诉被两个渠道各标了一次，一个标“质量投诉”，一个标“物流投诉”。这种错误如果你不写脚本去查重复率和冲突率，光靠人力看永远找不出来。后来我在所有数据管道里都加了一组质量指标：唯一率、标签一致性、缺失率、时效性，跑完数据先看这四项，再决定要不要进模型。

2.3 数据版本和实验追踪：不然后面有你哭的时候

数据是活的，每天都在变。你今天训出来的模型，过两周复现可能完全不一样，这不是玄学，是因为数据变了。不做数据版本管理的人，迟早会碰到一个经典事故：模型线上出了问题，你想回滚到之前那个“效果好”的版本，结果发现既不知道当时用了哪份数据，也不知道当时调了哪些超参数。

所以数据版本管理不是可有可无，而是AI工程的保命符。实操上我常用DVC或者LakeFS这类工具管理数据快照，配合MLflow记录每次实验的参数、代码commit、数据版本和指标。成本不高，但能让你在事故排查时省下几个通宵。

有人觉得这是流程负担，但我想说，AI工程里“可复现性”根本就不是学术要求，而是基本的生产要求。你今天稀里糊涂跑出一个高分模型，明天你照样得稀里糊涂地看它崩。

2.4 数据闭环：让线上反馈回流到训练集

工程和实验最重要的区别，在于你有没有把线上数据变成下一轮训练的养料。模型上线不是终点，而是数据闭环的入口。线上用户反馈、日志日志、业务结果，这些才是真正反映模型真实表现的素材。

我的标准做法是：每个模型上线前必须设计反馈埋点，明确记录三个东西——用户的最终行为（点击/采纳/关闭）、模型当时的推荐结果、用户有没有主动修正。有了这三个字段，你就能持续构建硬样本集。所谓硬样本就是模型预测错而用户做了相反选择的数据，这些样本比任何人工标注都珍贵，因为它们直接反映了模型在真实场景里的失误模式。

数据闭环这件事，我见过太多团队做得很敷衍，日志存了，但没人去消费。结果模型上线半年，效果早就不行了团队还没察觉。工程思维的差别就在这里：有人把数据闭环当口号，有人把它嵌在系统设计里。

3. 从基线到微调：训练环节的工程化推进策略

3.1 先跑通再优化：别一上来就上大模型

很多新手做项目有个通病：上来就挑最复杂的模型，恨不得第一天就微调一个几十B的LLM。我的建议反着来，永远先做一个最简基线。分类问题先用逻辑回归或XGBoost，文本检索先用BM25，哪怕效果很糙也没关系，因为基线的作用不是拿冠军，而是给你建立参照系。

有了基线，后面所有复杂模型的收益才是可量化的。而且基线跑通还能帮你验证整个数据管道、评估代码、部署流程是否能闭环——这些环节如果等模型好了再搭，你会发现问题一个接一个冒出来，到时候根本分不清是模型问题还是工程问题。

我经常说一句话：先把整条链路用玩具模型跑通，再回来换真家伙。这条经验救过我很多次。因为工程链路里的问题往往是串行的，数据读不出来模型再强也是白搭，评估代码写错全局指标再漂亮也是假的。简单模型的意义就在于把这些问题提前暴露掉。

3.2 模型选型逻辑：开源私有化还是调API

这几年大模型成了AI工程绕不开的话题，选型决策也比以前复杂了。你手里现在有三条路：直接用商用API、部署开源模型、或者两者结合。我的选择逻辑很简单，看四个维度——数据敏感性、成本预算、延迟要求、定制深度。

数据敏感的行业，比如金融、医疗，基本走私有化路线，那开源模型加上微调就是主流。预算紧、场景通用，直接调API最划算，没必要自己养GPU。但如果你要做深度定制，比如要在模型里注入大量私有知识或特定风格，API的性价比反而会迅速下降。

要注意的是，很多人把“部署开源模型”想得太简单，以为拉个开源权重跑起来就完事了。实际上要处理的工程问题不少：推理框架选型、显存管理、并发优化、量化压缩、上下文长度限制。后面我会专门讲这部分，这里只提醒一句，开源模型不是免费的，它是用你的运维成本换授权成本。

3.3 微调实操：全参微调不是默认选项

前几年做微调还流行全参数更新，现在这个大模型时代，全参微调基本只属于资源充足的团队。普通团队微调LLM，LoRA和QLoRA才是更实际的选择。它们只训练一小部分低秩矩阵参数，显存占用大幅下降，效果在很多场景下已经可以和全参微调打得有来有回。

我在项目里用QLoRA做过一次7B模型微调，单卡24G显存就能跑，训练时间压到几小时内，效果提升也肉眼可见。这套方案很适合预算和数据都有限的场景。

# QLoRA微调的关键配置示例 from transformers import AutoModelForCausalLM, BitsAndBytesConfig from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype="bfloat16" ) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "v_proj", "k_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" )

这套配置里几个参数值得说清楚：r控制可训练矩阵的秩，越大表示适应能力越强但过拟合风险也越高；lora_alpha是缩放系数，经验值一般是r的两倍；target_modules选哪些层，对7B模型来说选注意力层的四个投影矩阵是常用做法。这些参数没有绝对最优，我通常的做法是小步快跑，先用小学习率试一轮，观察loss曲线再逐步调整。

3.4 训练中的显存、过拟合和实验记录

微调落地时最大的物理约束是显存。很多新人一上来就问“为什么我的显存爆了”，其实按经验估算，每10亿参数在fp16精度下大约占2GB显存，再加上梯度、优化器状态、激活值，实际需要量还要乘上几倍。现在用Adam优化器训练7B模型，全参微调没个80G根本跑不动，这也是LoRA能成为主流的原因——它把优化器状态的开销降到了忽略不计。

过拟合这个问题在微调里同样存在，而且更隐蔽。LoRA虽然参数少，但如果你用单一风格的数据反复训练，模型会产生严重的风格固化，回答任何问题都带着训练集的腔调，甚至把训练数据里的错误事实当成金科玉律。我的经验是保证训练数据的多样性，每类样本总量别超过总量的30%，同时留一部分数据做验证集，微调完先跑一遍通用能力测试，确认没有灾难性遗忘。

实验记录这里多说一句，就是训练日志一定要留全。很多工程事故复盘到最后，真正缺的往往不是技术方案，而是当时的参数和日志。MLflow、Weights & Biases都行，关键是养成记录习惯。每次跑实验，把数据版本、代码commit、超参数、最终指标这四个记录成一条不可变的条目，后续一切问题定位都有依据。

4. 部署上线：从GPU选型到推理优化的一条完整链路

4.1 训练和推理的硬件逻辑是两回事

模型训练好只是中点，部署上线才是真正考验工程的开始。很多人以为部署就是把模型文件放到服务器上跑个预测，实际差远了。先看硬件：训练阶段追求单卡算力和并行扩展性，推理阶段更看重吞吐、延迟和成本。同一个模型，训练用A100这种大算力卡没问题，但线上推理如果也用同款卡，可能连成本都背不住。

推理阶段的主流做法是选择推理优化的卡，或者干脆用普通服务器CPU加加速卡组合。做LLM推理的话，显存带宽往往比算力更关键，因为生成是逐token的，每一步都要重新读取全部模型权重，如果你的带宽不够，token生成速度就会严重拉胯。这也是为什么同一张卡，跑小模型可能延迟很低，一换大模型就慢得离谱。

GPU选型这件事我给不出一个放之四海皆准的答案，因为每个人的场景和数据敏感度不同，但有个思考框架是通用的：先测真实负载，再定配置。不要拿厂商的宣传参数当决策依据。拿你实际要跑的模型、实际的并发量、实际的输入输出长度去压测，压测数据才是唯一值得相信的。

4.2 模型压缩：量化、剪枝、蒸馏怎么选

模型太大上不了线怎么办？压缩是必经之路。这里三个常用手段各有适用场景：

• 量化：把权重从fp16降到int8甚至int4。推理显存直接降一半到四分之一，速度也明显提升，代价是精度略有损失。现在QLoRA、GPTQ、AWQ这些方法已经让4bit量化的大模型效果相当能打。
• 剪枝：把不重要的连接和通道去掉，模型更瘦。结构化剪枝对硬件友好，但效果损失需要靠微调恢复。
• 知识蒸馏：用大模型教小模型，让一个小模型逼近大模型的效果。工程上成本最高，但换来的是长期的低推理成本。

我推荐从量化入手，因为收益最直接、改动最小。部署的时候，量化后的模型和原模型一定要做同一批测试样本的对比，确定精度损失在业务可接受范围内，再上生产。不要只盯着平均指标，要看极端样本——比如领域内的困难样本、长尾样本，量化通常在这些样本上损失更严重。

4.3 推理服务化：并发、批处理、缓存缺一不可

部署模型本质上是要把它变成一个高可用的服务。这里有几个工程要点，照着做能避开很多雷。

第一，一定要做动态批处理。LLM生成是计算密集型的，单个请求来一个跑一个，GPU利用率会很难看。把多个请求攒起来一起推理，吞吐能提升好几倍。vLLM、TensorRT-LLM这些框架内置了连续批处理，强烈建议直接用。

第二，极致重视首token延迟。用户感知里，第一个字等多久决定了他觉得这个系统快不快。模型推理本身占一部分，但输入解析、token化、排队逻辑都可能成为瓶颈。我用过的最实用的优化手段是：对输入做缓存，命中缓存的请求完全不用走模型。

第三，并发和队列的容量规划。不要只测单路延迟，要测P95甚至P99延迟在并发下的表现。很多模型单看延迟不错，一旦并发上来，排队加上显存争抢，P99直接翻好几倍。压测必须做，而且要按你线上的峰值流量的两倍来压。

一个标准的模型服务配置文件，可以参考下面这个结构：

serving: engine: vllm model: /models/quantized-7b-awq tensor_parallel_size: 1 max_batch_size: 64 max_seq_len: 4096 gpu_memory_utilization: 0.85 enable_prefix_caching: true quantization: awq

gpu_memory_utilization这里值得单独说。很多人不敢拉高这个值，怕OOM，但设太低又会浪费显存导致并发上限变小。建议是在离线压测环境里从0.9往下降，找到一个稳定不下探的临界值。enable_prefix_caching对多轮对话尤其有用，因为长对话里有很多公共前缀可以被复用，这一项能显著降低延迟。

4.4 端云协同：不是所有场景都适合纯云端推理

最后聊一下部署形态。很多项目默认就要云端API部署，但实际场景里，纯云方案不一定最优。举个例子，做实时质检或者智能客服辅助，业务方要求响应在几百毫秒内，出差错的代价很高，这种场景如果还依赖公网往返，延迟和稳定性都很难保证。

端云协同的思路是：把轻量级模型部署在用户侧设备上做初筛，只把疑难样本或者需要大模型能力的数据送到云端做二次处理。这个模式下，离线、降级、缓存、本地计算都要设计好，等于把AI工程能力延伸到边缘侧。这块做得好，用户体验和成本控制会同时受益。

5. 线上稳不稳，评估和监控说了算

5.1 离线评估：选对指标比调参重要得多

上线前的离线评估是最后一道闸门，但很多人只盯accuracy这一个数字，这个习惯很危险。真实业务场景里，正负样本比例经常失衡，可能99%的样本都是负例，你模型全预测负例都能拿99%准确率，但这有什么意义？

我要强调几个工程上更常用的评估思路：

• 分类任务不能只看准确率，必须同时看精确率、召回率、F1，以及PR曲线下面积。不同业务对误报和漏报的容忍度不一样，医疗场景漏报不可接受，垃圾邮件场景误报不可接受。
• 排序/检索任务要看Recall@K、MRR、NDCG这类指标。它们更贴近真实用户行为。
• 生成任务要用多个维度评估：事实一致性、内容安全性、指令遵循率。这些往往要引入一套半自动化的评测pipeline，用人机结合的方式打标。
• 无论什么任务，都要做分维度评估，不能只看总体指标。不同用户群、不同时段、不同内容类型的表现都要拆开看，否则平均数的假象会掩盖很多严重问题。

5.2 线上监控：延迟、吞吐、漂移一个都不能少

模型上线后的监控，本质上分四大类，缺一个都是隐患：

数据漂移是最容易忽视的一环。模型是根据训练时的数据分布学习的，线上真实数据一旦发生偏移，模型效果就会悄悄下滑，而且不会报警。我的做法是每天跑一次数据分布对比，用PSI或KL散度量化训练集和线上数据分布的差异，一旦超过阈值就触发告警，然后需要相关人员介入分析。

5.3 反馈闭环：模型迭代的发动机

监控发现问题只是第一步，更关键的是要建立模型迭代的机制。我见过太多团队模型上线后就成了“石像”，半年不更新，效果差到业务方吐槽也没人管。原因通常是迭代流程没建立起来。

我推荐的迭代节奏是这样的：每周从线上抽取硬样本和用户反馈，形成增量数据集；每两周做一次小版本微调更新，只换权重不换服务；每季度做一次大版本升级，可以换模型结构或者调整训练策略。这条循环一旦转起来，模型才会越用越聪明。

需要特别强调的是：每一次更新都必须走完整的评估流程。很多人图省事直接上线，结果模型还不如上一版。我有一次深夜回滚的教训太深刻了，就是因为新模型有个badcase没测出来，上线两小时后业务吐槽如潮，紧急回滚才恢复。从那以后我再也不省评估流程。

5.4 事故复盘：AI系统出问题时先查什么

线上系统出事故是迟早的事，关键是能不能快速定位。根据我的经验，AI服务出问题通常按这个优先级排查：

1. 先确认是模型服务本身的故障，还是上游依赖出问题了。比如向量数据库挂了、feature store接口超时，都会让模型表现异常。
2. 再确认是请求数据异常，还是模型权重异常。输入数据格式不对、字段为null，这种问题排查顺畅的话应该能很快发现。
3. 最后追到模型本身，大概率是效果衰减，或者某个输入组合踩中了模型的盲区。

这个排查链路必须在事故前就准备好：日志要全链路追踪，从请求进来到特征计算、模型推理、结果返回，每一步都要有trace。没有链路追踪的AI服务，事故排查就像在黑暗里摸电闸，你可能永远找不到真正的原因。

6. 热点工程的落地真相：LLM、RAG和Agent不是调API就行

6.1 大模型接入：API调用和私有化部署的边界在哪里

现在一提AI工程，绕不开大语言模型。但“接入大模型”和“大模型工程化”之间差距非常大。API调用是最快的捷径，几行代码就能让产品拥有理解能力，但工程化的坑在后面：上下文怎么管理、接口超时重试怎么做、敏感内容怎么过滤、费用怎么控制。

私有化部署的意义在于数据可控和深度定制，但代价是算力成本和运维成本。我在前文也聊过，决策时四个维度：数据敏感度、成本、延迟、定制深度。这四个维度摆出来，边界其实很清楚，不需要跟风。

6.2 RAG系统的工程细节：切块、检索、重排、上下文

RAG是目前落地最高频的大模型应用模式，本质是用检索给大模型外挂知识库。听上去简单，但每个环节都有坑：

• 文档切块是第一步，也是最容易被低估的一步。切得太碎，语义被切断；切得太大，检索噪声变高。我的经验是根据文档结构先做段落级切块，再对长段落做滑动窗口重叠切分，重叠部分控制在15%~20%左右。这样既能保证语义完整，又能兼顾召回。
• 向量化模型的选择要跟语言和领域匹配。通用向量模型在垂直领域的效果一般，有条件应该用领域数据微调一个专用embedding模型，这一步能带来肉眼可见的检索提升。
• 检索不是只调向量库的topk就行。混合检索（关键词+向量）在长尾词和专有名词上表现更好，重排模型放在召回之后，能显著提升最终结果的质量。
• 还有个细节是上下文拼装。把检索结果一股脑塞给大模型，会稀释重点信息，也容易超上下文窗口。应该先筛选再排序，把最相关的结果放在最前面，并在prompt里明确定位、输出范围。

评估RAG系统也不能只看模型生成得好不好，得把检索层剥出来单独评估：召回率、命中率、重排后NDCG这些指标都要跑。RAG工程简单来说就是：检索决定了天花板，生成只是把结果说出来。

6.3 Agent工程化：状态管理比模型能力更考验工程水平

Agent是最近热度最高的方向，但也是“demo好做、生产难做”最典型的领域。很多人觉得Agent就是让大模型调用几个工具，但这个想法在真实场景里会被现实击穿。大模型的工具调用有概率失败，给错参数、选错工具、陷入死循环，这些问题在大模型能力不够的时候非常高发。

Agent工程的本质是一个状态机和一套可靠性机制。我的核心经验是：

• 每个Agent任务必须定义明确的状态流转：初始、工具调用、结果处理、终态。不能用散漫的对话去驱动，否则无法排查。
• 工具调用的每个参数都要做schema校验，模型输出不能直接当成可执行参数，否则一旦书格式稍有偏差，很可能会导致线上事故。
• 必须设置超时和最大迭代轮数，防止Agent陷入死循环烧钱。
• 对关键动作做人工确认机制，特别是涉及数据删除、发送消息这类不可逆操作，没有确认机制迟早出大事。

现在的Agent做产品demo很容易惊艳，但稳定商用需要工程细节堆积。谁先把这些可靠性机制补全，谁才能真的把Agent从Demo推进到生产环境。

6.4 多模态与垂直场景：工程链路更长，要求也更高

大模型之外，多模态工程化也在快速铺开。图像理解、语音交互、视频分析，它们的工程链路比纯文本长得多：图像要先做预处理和区域提取，语音要处理采样率和降噪，视频要做抽帧和时序对齐。每一步都需要单独的模型或算法模块协同，线上性能的瓶颈经常出现在视频解码和图像预处理上，而不是模型推理本身。

这条线我的建议是：别想着全流程自己造轮子。图像预处理用成熟的视觉库，语音对齐用稳定的音频框架，模型推理统一走同一个服务化平台。你在工程层面要负责的是串联、调度、监控和容错，这样整个系统的从零到一周期会大幅缩短。

7. 从零到一的最后一块拼图：踩坑之后我对AI工程的理解

一个人把完整的AI项目从零做到线上稳定运行之后，才会真正理解 ai-engineering 的含义。它不是一个新技术名词，而是一整套工程方法论：数据要闭环、实验要可复现、服务要可观测、迭代要可持续。算法模型只是其中一个环节，把这个环节放大的团队往往是最脆弱的。

我现在带项目，第一周不会让任何人碰模型，而是先做两件事：把数据管道跑通，把评估基线立起来。模型再烂都有救，但数据和评估的根基不稳，一切提速都是空中楼阁。这也是我最想分享给准备入行的人的经验——不要被“训练模型”四个字困住，多去看看模型前后那些枯燥的工程环节，那里才是AI工程真正的门槛和壁垒。

最后分享一个我自己坚持了很多年的习惯：每个项目收尾时，写一份“如果重来一次”的复盘文档，不用长，十条以内，记录哪里浪费了时间、哪个决策事后看是错的、哪个工具其实可以更早引入。这份文档比任何课程都有价值，因为它完整记录的是你在真实项目里积累的工程直觉。AI工程的成长路径没有捷径，但每一段踩坑的路都可以成为下一段路的捷径。