用一篇博文的体量，把“ai-engineering-from-scratch”这个命题拆开揉碎。这不仅仅是一个项目名称，更是一条从零开始建立 AI 工程能力的完整路径。我结合自己做过的大大小小的项目，从环境搭建、数据准备、模型训练一直聊到部署监控和团队协作，把我踩过的坑、验证过的方法、沉淀下来的工具选型都放在里面，希望能给正在这条路上摸索的朋友一些实打实的参照。
1. 从零开始搞 AI 工程，到底在解决什么问题
先说个现象。很多人一听到“AI 工程”，第一反应是“不就是训练模型吗”。但真到了生产环境，你会发现模型训练只是冰山一角。数据怎么来、怎么清洗、特征怎么对齐、训练完怎么部署、上线之后怎么监控、模型漂移了怎么办、每次迭代怎么保证效果不回退，这些才是真正消耗精力的地方。我见过太多团队，模型在笔记本上跑得好好的，一上生产环境就崩，或者效果明明在离线测试里很好，上线一周后用户反馈就是不对。归根结底，就是没把 AI 当成一个工程问题来对待，而是一直停留在“搞个模型出来”的阶段。
“ai-engineering-from-scratch”这个标题的核心，其实就是要把这些工程细节系统地捋一遍，从零开始构建一套能落地、能维护、能迭代的 AI 系统。它不是什么高深的理论，而是一套方法论加实践组合拳。
这里适合三类人参考：
- 刚入行的算法工程师，天天调模型但没搞过完整项目，急需补上工程化这一课。
- 后端工程师转 AI，模型原理半懂不懂，但最头疼的是“模型怎么变成接口服务”以及“怎么保证服务稳定”。
- 技术团队负责人，想评估自己的团队搞 AI 项目还缺哪些能力，需要一份完整的蓝图来对照。
我自己在这条路上走了不少弯路，最深的体会是：AI 项目失败的概率之所以高，往往不是因为模型效果不够好，而是工程链路中存在没人愿意负责的“灰色地带”。数据归数据工程师管，模型归算法管，上线归运维管，监控归 SRE 管，结果出了问题，大家互相甩锅。而工程化做得好不好，就看能不能把这个链条上所有人拉到同一张图里协作。
2. AI 工程化的全景图：应用框架、数据链路和两个关键思维
2.1 先搞清楚你属于哪种 AI 工程模式
“AI 工程”这个词其实覆盖了两种差异很大的模式。第一种是“从零训练模型”，典型的是语言模型、多模态模型，从数据采集、清洗、预训练、微调再到部署，全链路都自己掌控。第二种是“基于底座模型的应用工程”，借助已有的基础模型能力，做检索增强、提示词优化、流程编排和外部工具调用，来实现业务功能。
这两种模式对人、对算力、对数据的要求完全不是一个量级。但绝大多数业务场景，其实用不到第一种。2023 年到 2025 年这一波技术演化之后，甚至很多中小团队已经不需要自己训模型了，选用开放平台或者开源底座，把精力聚焦在上层应用，反而更快更稳。
我的建议是，动手之前先把这个问题想透：你的项目里，模型本身的价值大，还是业务逻辑和数据的价值大？如果是后者，就别纠结训练自己的模型，把工程重心放在数据链路的打通和评测体系的搭建上，这个投入产出比是最高的。
2.2 数据链路是 AI 工程的“血液循环系统”
如果说模型是心脏，数据就是血液。所有 AI 项目里最脏最累、最不显眼但最要命的工作，基本都出现在数据环节。
一个标准的数据链路通常长这样：
- 数据源接入：文件、数据库、API、日志埋点、第三方接口、手工录入，各种各样。
- 数据质检与清洗：去重、去噪、格式标准化、敏感信息识别和过滤、异常值处理。
- 数据转换与特征工程：把原始数据变成模型容易消化的形态，文本切块、向量化、时间序列对齐、多模态数据关联。
- 数据版本管理：每次训练用的数据集是哪一批？谁生成的？参数是什么？结果能不能复现？没有版本管理，一切都是扯淡。
- 数据标注与反馈回流：尤其是监督式场景，没有高质量的标注数据，模型效果就是空中楼阁。
很多团队最直观的误区是“数据量越大越好”，实际上对 AI 工程来说，数据的“可用率”比总量重要得多。我见过一个项目，号称有 500 万条对话数据，拉下来一分析，去重之后真正干净可用的不到 80 万条，其中还有大量重复表达方式，多样性极差。这种数据训练出来的模型，表面指标还行，一到真实对话场景就露馅。
所以数据链路里最关键的一步，不是什么高级算法，而是建立一个“数据体检”的例行机制——周期性跑一遍数据分布、覆盖度、异常率，任何明显偏移都要第一时间发现。
2.3 两个贯穿始终的思维：评测驱动和迭代闭环
AI 工程和传统软件工程最大的区别，在于它不是确定性的。你改了一行代码，结果是能预测的；但改了模型参数或者换了训练数据，结果是需要重新评测的。所以 AI 工程必须有两条腿：
第一条腿是评测驱动。没有评测体系之前，不要动手训练。评测体系分三层：核心指标层（准确率、召回率、F1 等任务指标），系统效果层（端到端的业务漏斗、用户满意度、成本消耗），以及风险控制层（安全合规、敏感内容、越权操作）。有了这三层，你才能回答“这次改好还是改坏了”这个最基本的问题。
第二条腿是迭代闭环。上线一个模型只是开始，最重要的是把用户、业务系统产生的数据继续收回来，变成下一轮训练和优化素材。这个循环跑得越快，系统进化就越快。很多团队把模型一上线就当完成式了，结果三个月后模型效果越来越差，因为没有新的数据回来做微调和适配。
3. 从零搭建一个 AI 项目：核心链路实操拆解
基础环境与工具链选型，这是很多初学者的第一个卡点。我直接给一套我实测下来非常顺手的组合，纯开源，几乎零成本启动。
3.1 环境搭建的推荐配置
先说规模。搞 AI 工程不一定需要抢 A100。模型时代，就算微调一个 7B 量的开源模型，单张 RTX 4090 或者 A10 其实就能跑推理和微调，真正吃卡的是预训练和大规模全量微调。
我自己的标准测试环境长这样：
- 操作系统：Ubuntu 22.04 LTS，原因很简单：生态兼容性最好，几乎所有开源 AI 组件都优先支持它。
- GPU 驱动与 CUDA：用 NVIDIA 官方驱动的 535 或 550 分支，CUDA 版本 12.x，这个组合目前最稳定。
- Python 环境：3.10 以上，管理工具用 Miniconda，不要直接在系统环境里装包，不然版本冲突能让你怀疑人生。
- 向量数据库：Milvus 或者 Chroma 二选一。前期小规模验证用 Chroma 最省事，项目上了量再切 Milvus。
- 模型推理框架：vLLM 是主推，吞吐高、显存管理做得好，比原生 HuggingFace 的 generate 接口快不止一个档次。
- 应用框架：LangChain 或者 LlamaIndex，根据自己的偏好来。我建议早期不要过度依赖框架，先把原生 API 调用练熟，理解每个环节在干什么，再上框架提升效率。
3.2 数据处理与管道的必做步骤
数据阶段一定要建立自动化流程，不能靠手工跑脚本。我当时做数据管道踩过的坑，排在最前面的就是“手工跑完一批数据，忘了记录参数”。
现在我的做法是：
- 原始数据落地后，第一时间计算基础统计量，包括记录数、字段缺失率、重复率、长度分布和语言分布。
- 清洗流程全部脚本化，每一步的输入输出、参数配置都用配置文件记录，和代码一起提交到 Git。
- 对文本数据做切块，长度根据 embedding 模型的最长输入限制来定，常见选择是 512 到 1024 个 token。切块时要保留上下文重叠，一般重叠 10% 到 20%，不然语义会断。
- 清洗完的数据必须做抽样人工检查，哪怕只检查二三十条，也能避免很多“脚本看着没问题实际上逻辑错了”的意外。
- 数据版本标记，格式建议是“数据类型_时间戳_操作摘要”，比如
chat_v0526_dedup_v1。
3.3 从零搭建检索增强应用（RAG）
RAG 是目前落地最快、见效最明显的 AI 应用模式，很多业务问答、知识库助手、企业内部 Copilot，本质上都是这套架构。我拆一下核心步骤。
第一步，文档解析与切块。
PDF、Word、Markdown 混合输入，解析时最头疼的是表格和图片。表格用 unstructured 库处理效果还行，图片需要单独走 OCR。切块策略上，优先按语义逻辑切，比如按 Markdown 标题层级切，其次按固定长度切兜底。
第二步，向量化与入库。
选一个靠谱的 embedding 模型，中文场景我常用 BGE 系列，效果比 OpenAI 的 text-embedding-ada-002 在中文上还要扎实。入库时一定要把原文和 chunk 的对应关系存起来，方便溯源。向量库里的索引参数按默认走就行，数据量没到百万级别，不值得花太多时间折腾。
第三步，召回与重排。
召回数量先设 Top-20，然后用一个轻量级的 rerank 模型（比如 bge-reranker-base）重新排序，再把 Top-3 到 Top-5 拿给大模型做最后生成。这一步能显著提升检索质量，尤其当知识库里相似内容多、容易混淆的时候。
第四步，提示词与答案生成。
提示词里一定要注入“根据给定资料回答，资料无法覆盖时明确说明不知道”，不然模型会一本正经地胡说八道。同时要加上答案溯源和引用格式要求，方便用户核对。
3.4 训练与微调的工程化注意点
如果你确实需要微调，三步走比较舒服：
- 数据准备：至少准备一千条高质量指令样本，质量优先。微调不是说数据越多越好，几千条精心筛选的好数据，效果超过几万条注水数据。
- 配置训练：单卡小规模微调，优先用 LoRA 方式。原因很简单，显存占用小、训练速度快、效果与全量微调差距不大。训练过程中要盯住 loss 曲线，正常情况应该平滑下降，如果有剧烈抖动，大概率是学习率大了或者数据里有脏样本。
- 评估与迭代：微调完不能只看 loss，必须回到评测集上跑核心指标，用同一套评测集对比微调前后的效果。没有回退机制的微调，本质上就是在赌博。
4. 部署上线：让模型变成稳定服务的关键一步
4.1 核心平台选择：为什么 Ollama 适合起步，vLLM 适合生产
部署方案要根据团队的技术栈来选。2024 年之后的形势已经很清楚：Ollama 在本地开发体验上几乎做到了极致，把模型下载、启动、暴露 API 都封装成了傻瓜操作。但它不太适合高并发生产环境，性能和调度能力有瓶颈。
生产环境我强烈建议用 vLLM。它支持 PagedAttention 显存管理、Continuous Batching 连续批处理，吞吐量比原生推理高出数倍，还有 OpenAI 兼容的 API 格式，迁移成本几乎为零。部署时可以直接用 Docker 启动服务，模型路径挂载进去就行。
4.2 API 设计标准：直接兼容 OpenAI 格式
现在做 AI 服务接口，最稳妥的做法就是兼容 OpenAI API 格式。原因很朴素：生态巨大，所有主流框架、插件都天然支持，省去大量适配工作。
我自己部署的一个最小化例子的启动命令大概是这样的：
python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2-7B-Instruct \ --served-model-name my-assistant \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动后直接可以用 requests 做了：
import requests resp = requests.post( "http://localhost:8000/v1/chat/completions", json={ "model": "my-assistant", "messages": [{"role": "user", "content": "什么是模型蒸馏？"}], "temperature": 0.3, }, timeout=30, ) print(resp.json()["choices"][0]["message"]["content"])注意了，max-model-len别贪大，大输入长度意味着高显存占用。推理能效的核心是吞吐量，不是单次请求的长度上限。
4.3 部署时的关键参数与资源规划细节
部署时很多人不关心gpu-memory-utilization，默认策略下 vLLM 会把显存全部吃满，容易引发 OOM。建议设成 0.85 到 0.9，预留一部分给 tokenizer 和运行时开销。
并发评估时要记住，模型推理的延迟和吞吐是两种体验。RAG 场景下，真正的 E2E 延迟大头往往在向量检索和文档解析，而不是生成。所以瓶颈优化要盯着实际链路测，不要只看模型能跑多快。
还要关注一个小坑：模型预热。服务刚起来时显存缓存是空的，前几次请求会比较慢，生产上要加一个预热机制，启动后先用一两条静默请求把缓存打热。
5. 可观测性建设：模型效果、在线监控与自动评估体系
AI 应用上线之后，最怕的不是 bug，是“效果变差了但是说不出来什么时候开始变差的”。所以可观测性必须有两层：
5.1 传统监控层
CPU、内存、GPU 利用率、请求延迟、错误率、吞吐量，这些用 Prometheus 加 Grafana 就能覆盖。注意加一个 Key Metric：每请求 token 数（输入加输出），这个指标能帮你发现异常输入。
5.2 AI 专属的监控层
这是 AI 工程和传统开发最不一样的地方。你要监控模型的行为特征：
- 空回复率、超长回复率等基础质量指标
- 用户的负面反馈率
- 输入文本的分布漂移指标，用于判断用户提问类型是否发生了偏移
- 输出内容的安全标准命中率
这些监控数据要回流到评测集里，周期性跑评估。我现在手上所有项目都遵循一个铁律：每次模型升级、提示词调整、知识库更新，都必须先跑一遍固定的自动评测，打分通过才能上线。评测集就是 AI 工程的回归测试集。
6. 工具选型、算力成本与团队分工的经验参考
6.1 模型和向量数据库到底怎么挑
中文场景下，7B 量级开源模型我是推荐 Qwen 系列，中文能力强，生态成熟。英文为主的任务也可以考虑 Llama 系列。通用任务不用纠结谁强谁弱，纠结的是推理成本和维护难度。
向量数据库的选择看量级。百万条向量以下，Chroma 或者轻量化方案最省心。再往上，Milvus 是主流选择，因为它支持分布式、索引类型丰富、运维文档齐全。Qdrant 也是个不错的替代，性能很稳。
6.2 算力成本怎么控制
算力是这个领域最敏感的成本项。我的经验是：
- 开发测试环境用按小时的 GPU 实例或 GPU 池子，不要包月长期挂着，大多数时间其实用不满。
- 推理服务选按量付费的弹性方案，有业务波动时自动扩容，闲时缩容省成本。
- 批量任务走离线低价队列，对时效性要求不高的任务全部错峰跑。
- 优先级永远是把便宜的模型方案先试一遍，7B 能解决的绝不硬上 70B 模型。
6.3 团队需要哪种角色组合
传统小团队想搞 AI，我见过最顺利的配置是：
- 一个人的算法/机器学习工程师，负责模型选择、微调、评测
- 一人偏后端的工程师，负责服务化、数据管道、监控
- 半个运维支持，负责 GPU 资源和云成本
- 一个业务产品经理，负责定义问题、卡效果、管反馈闭环
记住，AI 工程里业务角色不是配角。没有懂业务的人定义评测口径、审核样例质量，技术再强也只能自嗨。
7. 常见问题排查现场：我踩过的那些坑
7.1 RAG 答案质量差
现象：检索到的资料明明是对的，但回答答案文不对题。排查方向先看提示词上下文拼接，看看模型是不是没有用检索到的资料。RAG 里最常见的翻车原因是把大量低相关度内容也塞进了上下文。相关性不够的就直接过滤掉，别什么都喂给大模型。
7.2 模型服务部署后延迟飙升
现象：刚上线还好，过了一会儿越来越慢，最后请求超时。典型的 vLLM 显存缓存碎片化或者 max-model-len 设置过大引发内存压力。解决方案是限制并发，设好 timeout，再用增加副本数分摊流量。
7.3 微调后效果反而变差
这是很多人最崩溃的瞬间。我遇到过好多次，排查下来基本是三种情况：
- 新增数据和原有数据格式不一致，造成领域偏移
- 数据质量差，样本里带有错误标签或者噪声内容
- 微调时学习率太高，破坏了底座模型的先验知识
我的习惯做法是，微调数据集里保留一部分通用能力的 seed data，比如 5% 到 10%，保证模型不会丢掉原有能力。训完必测通用能力加领域能力的双评测集。
7.4 评测集和真实场景脱节
离线指标很好，线上效果一塌糊涂，十有八九是评测集构建得有问题。评测集太简单、和真实分布不一致、或者只有正向场景而缺少边界情况。评测集要持续从线上反馈数据里挑选样本补充，每两周更新一次，保证评测集本身是在“呼吸”的。
8. 实操中沉淀下来的一些个人体会
最后说点实在的经验。
第一，AI 工程里“快”不一定意味着“好”。我看过太多团队急着把 demo 上线，上线之后发现问题一堆，再花十倍的时间修补。与其这样，不如在第一个版本就把数据链路、评测体系、监控这三件套搭好，后面每一次迭代都会越来越轻松。
第二，别过度依赖框架，也别排斥框架。我的原则是：理解原理之前不用框架，理解了之后大胆用。当你遇到框架解决不了的问题时，你会感激自己当初花过时间读底层实现。
第三，技术选型不要跟风，要跟着自己的场景走。每一个热门组件背后都有它适合的特定空间，脱离了场景谈优劣就是耍流氓。
第四，AI 项目的成功，很大程度上取决于数据反馈闭环跑得顺不顺。每一次用户可能都已经用行为给你的系统打了分，比如点击、复制、点赞、跳过、投诉。把这些行为信号变成可学习的数据，系统和用户就会越走越近。
如果你正准备启动自己的 AI 工程，哪怕现在什么都没有，就按照这篇文章里提到的链路顺序，先搭一套跑通最小闭环：一段代码、一条数据管道脚本、一个评测脚本、一个部署脚本、一张监控看板。把这条最细的线拉通，后面所有事情就都有了着力点。
