用一篇博文的体量把“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 从零搭建检索增强应用RAGRAG 是目前落地最快、见效最明显的 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, }, timeout30, ) 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 工程哪怕现在什么都没有就按照这篇文章里提到的链路顺序先搭一套跑通最小闭环一段代码、一条数据管道脚本、一个评测脚本、一个部署脚本、一张监控看板。把这条最细的线拉通后面所有事情就都有了着力点。