★ FEATURED ARTICLE 很多人在接触 AI 后都会有一个共同困惑模型会跑了、Demo 能出结果了但真要把它做成一个稳定服务、接进业务、扛住真实流量就到处卡壳。这个问题的本质其实是缺少一套 AI 工程的完整认知。如果把“ai-engineering-from-scratch”当作一条学习路径来看它囊括的正是从模型调用到系统落地之间的所有关键环节。这篇文章我会结合自己从零搭建 AI 服务的实际操作经验把 AI 工程涉及的核心领域、技能栈拆分、项目实践方式以及部署、评测、监控中的主流做法整体梳理一遍。不管你是刚入门想做 AI 应用还是已经有模型基础但想补齐工程能力这份内容都能给你一个可以照着落地的路线参考。1. AI 工程到底是什么它和“炼丹”有多大区别很多教程喜欢把 AI 工程等同于训练模型实际上这是两套侧重完全不同的事情。训练模型更多是算法工程师在做的事调参、选网络结构、处理数据分布、看 loss 曲线目标是让模型精度更高。AI 工程更关心的是模型从训练环境出来后怎么变成可用的产品能力。它要覆盖模型服务化、推理性能优化、接口设计、评测回归、可靠性保障、成本控制甚至还要考虑数据回流和迭代机制。简单说训练阶段解决的是“能不能”AI 工程解决的是“好不好用、稳不稳定、能不能持续迭代”。1.1 为什么不能只会调模型我见过不少团队模型在离线评测集上效果很好一上线就原形毕露。原因往往不是模型本身不行而是推理环境不稳定、接口超时、并发一高就 OOM或者输入数据格式稍微变化就崩了。这些问题的定位和解决跟模型结构没关系纯粹是工程问题。AI 工程要掌握的是在模型能力之上叠加稳定性、可用性、可观测性。例如服务端要对输入做校验避免脏数据直接进模型要用连接池管理外部依赖要做超时控制、降级策略、异常兜底日志和监控要能反映出线上真正的问题。这些技能不掌握模型再强也仅仅停留在“能跑”的阶段。1.2 AI 工程的实际范围从一次完整的项目交付看AI 工程至少包含这几个部分数据获取与清洗、模型选型与评估、特征工程或提示词构造、推理服务化、接口封装与测试、性能与压测、安全与限流、监控告警与自动重训、成本优化。任何一个环节没做扎实都可能成为上线的瓶颈。举个例子一个 RAG检索增强生成问答系统看起来核心是 LLM 的能力但真正决定效果上限的往往是谁把文档解析做干净了谁把切片和向量索引维护得好谁在召回阶段把相关性排序做得准。这些都属于 AI 工程的实践范畴。2. 从零开始的技能栈拆解按这个顺序学不迷路“from scratch”意味着不假设你有完整背景可以一步步建立知识体系。但 AI 工程的知识点太散如果东学一点西学一点很容易被困在细节里。我建议按五层结构去搭建自己的技能树每一层解决一个核心问题层与层之间是递进关系。2.1 第一层编程与基础设施意识AI 工程不等于写 Python 脚本但它确实以 Python 生态为主。你需要熟练 Python 基础语法、类型注解、虚拟环境管理、面向对象设计模式至少能写出结构清晰的代码。同时要懂一些 Linux 基础操作、进程管理、文件权限因为部署 AI 服务最常见的方式就是跑在 Linux 服务器上。此外容器化是绕不开的。Docker 能帮你把环境依赖、模型文件、启动命令打包成一致镜像避免“在我电脑上能跑”的魔咒。我建议从 Dockerfile 手写开始不要光用自动生成的模板。多写几次就知道什么依赖该装、什么该缓存、镜子怎么瘦身。这在后期部署 LLM 服务时尤其重要一个跑着 vLLM 或 TGI 的镜像动辄几个 GB不做分层缓存会非常痛苦。2.2 第二层数据与评测能力AI 应用对数据质量的依赖超过大多数人的预期。文本类项目至少要会数据清洗、去重、格式统一、切分训练/验证集。涉及 RAG 的还要掌握文本切片策略——按固定长度切按语义段落切还是按递归结构切这会直接影响召回效果。评测能力是 AI 工程里容易被低估的一块。没有评测体系的 AI 项目迭代就是拍脑袋。正规的做法是维护一个任务相关的评测集每次改动模型、提示词或检索逻辑都在同一套评测集上跑分对比。LLM 时代的评测不只看准确率还要看格式正确率、延迟、成本、安全拦截召回率等维度。把这些指标拉成一个表格谁好谁坏一目了然。2.3 第三层模型训练与微调基础如果方向是应用层这个阶段打基础即可。要熟悉 Hugging Face 生态的数据集加载、tokenizer、模型和 pipeline 的使用方法。理解 Transformer 的基本结构不算必须但至少明白输入输出的张量形态变化这样调试推理服务时不会两眼一抹黑。微调也建议实际跑通一次 LoRA哪怕是基于开源模型在一个小数据集上训练一两个 epoch。这个过程能让你体会什么叫做数据影响行为同一套微调代码换一个数据集模型输出风格可能完全不同。做全参微调或大模型预训练不是入门阶段该碰的事那是资源密集型的深水区。2.4 第四层推理服务与部署架构到了这一层才算真正进入 AI 工程的核心领域。模型要用什么框架服务化单机还是分布式GPU 显存够不够要不要做量化并发和延迟目标是什么LLM 场景下最常用的是 vLLM它内置 PagedAttention、Continuous Batching 等技术吞吐明显优于朴素方案。规模不大的也可以用 FastAPI 直接封装 Transformers pipeline简单直接但并发一高就吃不住。如果追求端到端性能还要关注 Token 流式输出的实现方式是 SSE 还是 WebSocket以及服务网关上的负载均衡、限流、超时配置。2.5 第五层系统与产品化思维AI 服务不是孤立的模型接口它要嵌进业务流程。这意味着你需要理解系统架构的基本概念比如微服务拆分的粒度、消息队列的用途、缓存策略、数据库选型。还要能够设计数据埋点记录每次请求的输入输出、反馈信号为后续评测和模型优化提供燃料。这一层决定了 AI 项目的上限。两个团队都用同一个模型一个做出来是能上线、能对用户反馈闭环的成熟产品另一个只是一个演示 API差别基本都出在系统与产品化思维上。3. 拿“从零搭建 RAG 知识库问答”当项目练手是最佳路径理论知识再多不动手都等于零。从零开始做 AI 工程我强烈建议把“本地知识库问答”作为第一个完整项目。它覆盖了数据接入、向量化、存储、检索、LLM 接入、接口服务化全链路而且可以无 GPU 运行Embedding 用 CPU 也能跑上手门槛低扩展空间极大。3.1 整体实现路径拆解这个项目的目标很明确给一个文档集合用户提问系统基于文档内容返回答案。完整路径是加载文档并做格式解析提取纯文本剔掉无意义内容按一定策略切片生成切块列表加载 Embedding 模型把每块文本转成向量向量写入索引库如 Chroma、Milvus、FAISS收到用户问题后Embedding 化并查询相似向量把命中的文本块拼接为上下文交给 LLM 生成答案用 FastAPI 把链路包装成 HTTP 接口我实践下来最影响最终效果的是文本切片这个步骤。切片过大向量检索容易抓到有噪声的长文本上下文浪费 token 且答案发散切片过小语义不完整召回的内容支离破碎。比较稳妥的方案是先按文档结构段落切再控制每片在 200500 字之间相邻切片可以加少量重叠防止语义边缘窗口丢失。等你做多了可以针对自己的文档类型专门调这个策略。3.2 各环节需要解决的问题文档解析里最坑的是 PDF。直接提取经常出现乱序、丢行、表格错乱建议先用工具把 PDF 转成结构化文本再人工抽检几份看效果。Embedding 选择上中文任务可以先从常见的开源中文向量模型入手等后续效果不满意再换大模型或商用 API对比维度主要是相似度准确率和维度对存储成本的影响。向量库的选型要结合数据量。小规模项目用 Chroma 和 FAISS 最轻便本地文件就能存。达到百万级向量以上就必须考虑 Milvus 或 Qdrant 这类服务化数据库它们附带索引构建、分片、过滤能力。刚开始做练手项目不建议一上来就上重型的分布式向量库先理解哈希索引和 HNSW 的区别比什么都强。3.3 检索与生成的调优细节RAG 的效果并非接入即完事要在检索质量和生成策略上反复调。检索侧先算召回率确保正确答案候选在前 10 条里再算排序看置信度高的向量是否真的相关。一个常见的坑是只按向量相似度截断不设相关性阈值结果无关内容也混进上下文把模型带偏。生成侧最重要的是提示词模板和上下文窗口管理。系统提示要写清楚“仅根据给定文档回答不要使用外部知识”并在上下文开头标注哪些是检索片段。如果文档片段太多超窗问题会频繁出现所以要做一个动态截断优先保留得分靠前的片段同时兼顾总 token 上限。这儿有一个排查技巧我反复用得很好如果回答引用了文档没有的内容把上下文打印出来逐条核对多半是切片切碎了关键句子或者是相似度太低的片段混了进来。4. 部署、评测和性能优化把 AI 服务推到生产级RAG 项目在本地能跑通之后下一步就是把服务推到生产级这个过程会让你碰到比写 Demo 多十倍的问题。这里我挑印象最深的几个方向展开讲。4.1 模型推理部署的核心选择如果你是基于开源 LLM 提供服务第一步就是确定推理引擎。我的实际体验是以 Transformers 原生代码直接部署代码简单但吞吐低并发上来后排队严重整个服务会被拖垮。换成 vLLM 后同样的模型和硬件吞吐可以提升数倍显存管理也更稳定。手头如果只有消费级显卡跑 7B 级别模型建议配合 AWQ 或 GPTQ 量化显存占用能控制在 68GB 左右推理速度也可以接受。选型上还要注意引擎的 API 兼容性。vLLM 默认提供 OpenAI 兼容接口这意味着你可以直接替换客户端 base_url不用改业务代码。这个设计非常务实新服务上线可以少写一层适配我建议项目起步就按这个标准来。4.2 接口层设计需要注意的坑模型服务内部搞定了接口层同样有很多细活。输入参数要做严格校验空字符串、超长文本、非法格式都要提前拦截不要等请求打到模型才报错。超时和并发限制必须配好防止某个慢请求占住连接池导致后续请求全部阻塞。流式输出是 LLM 产品的体验标配。用 FastAPI 的话可以基于 StreamingResponse 实现 SSE 流。但要注意流式场景下客户端断开连接服务端如果不做取消检测模型还继续生成浪费算力。前端每打一个终止符号后端要把生成任务显式取消。4.3 数据评测与回归机制评测不是上线前做一次就完了应该沉淀为每次迭代的固定动作。我会建议维护一组稳定评测问题集数量不用太多200 条左右精挑细选就够。每次改了提示词、换模型、调了切片策略都跑一遍这组问题把答案保存下来做对比。制作评测集时要覆盖正常提问、边界提问、对抗性提问三类。比如知识库中明确存在的内容、知识库没有的内容、诱导模型说错的内容。打分方式可以人工抽评也可以用 LLM 打分器做初筛最后人工确认。用表格记录每个版本的得分、平均延迟、token 消耗成本时间长了就是一份非常有价值的项目履历。4.4 成本与性能的平衡点LLM 服务的成本大头是 API 调用或 GPU 资源。控制成本的基本操作是加一层缓存把同语义的查询命中缓存直接返回避免重复调用模型。缓存键可以用输入文本的哈希值也可以先用低的模型做意图分类决定走缓存还是走全链路。另外要监控每次请求的 token 消耗。很多团队忽略这个数据等月底账单出来才傻眼。可以在接口层记录 prompt token 和 completion token按来源业务聚合这样能快速发现是哪个功能模块在烧钱。最难治的是提示词越写越长导致成本翻倍定期清理提示词范式和历史行为性价比非常可观。5. 实操中踩过的那些坑整理成速查表送你AI 工程入门阶段的报错和坑很多是重复性的完全没有必要每个人都重新踩一遍。我把自己实际项目中碰到的高频问题汇总成一张速查表你在排障时可以直接参考。问题现象根源原因排查方向与解决方法服务启动后显存直接爆掉模型最大上下文被设置过大加载时预分配显存调低 max_length、启用 vLLM 的 gpu_memory_utilization 限制比率并发一高接口延迟快速增长推理引擎没有批量调度或是锁竞争换 vLLM/TGI 引擎开启连续批处理检查是否有同步阻塞代码检索到的内容与问题不相关Embedding 模型能力弱或切片粒度不合理换更强的向量模型调整切片大小增加重排rerank环节回答“一本正经胡说八道”上下文包含无关内容或提示词没有约束增加相关性阈值过滤提示词写明“材料未提及则回答不知道”接口偶发超时根因难查没有全链路链路日志用请求 ID 贯穿网关、服务、向量库、模型调用全链路完善日志埋点GPU 利用率只有 30%钱花了力气没出模型服务空闲等待请求分布零散服务端做弹性伸缩或按并发峰值调整卡数和批处理参数除了表格里的还有两个经验我觉得特别值得提。一个是读文件路径的坑服务迁移到容器后路径变了、权限不够、工作目录不对代码本地能跑容器里就 404尽量用绝对路径并提前打印当前工作目录。另一个是模型下载的坑不设置模型缓存目录或者磁盘分区满了加载模型时静默失败看似报 CUDA OOM其实只是磁盘没有空间了。6. 后续可以继续扩展的方向从零到一搭好一个可运行的 AI 工程服务只是工程化的起点。后续还有几个很实用的扩展方向可以按实际需要选择。第一个方向是数据回流与自动评测机制。给产品加一个反馈按钮用户点“有用”或“没用”把这一条数据存进日志库每攒一批就跑到评测集上对比模型是否退化效果不佳就触发重新微调。这个闭环是 AI 产品持续改进的核心引擎。第二个方向是多 Agent 协同。整体架构会从单链路变成多个角色、多个模型的组合。你需要考虑怎么设计任务编排、怎么管理 Agent 的记忆、怎么处理不同 Agent 间的依赖失败。建议用可观测性很强的编排框架起步第一时间能看到每个节点耗时和产出。第三个方向是为特定领域深度定制。通用能力做出来后在垂直领域做高质量数据清洗、做符合领域习惯的切片策略、微调一个领域模型往往就能在竞品中建立优势。这个方向拼的不是模型大小而是对领域知识的工程化表达。最后一个值得投入的方向是成本引擎建设。当业务量上来后模型调用是大头开销可以研究路由规则简单问题走小模型复杂问题才调用大模型。我实际见过团队把整体成本压掉 40%而用户体感几乎没降关键就在于把问题难度分层和路由策略做细。我自己的体会是AI 工程这条路没有终点每解决一个问题就会自然冒出更深一层的需求。与其急着追新模型不如先把手头这套工程地基打扎实。当你的向量检索、评测闭环、成本监控都形成习惯后再上任何新模型都会有底气。最后分享一个小技巧做 AI 工程不要把所有东西都往一个大服务里塞按链路拆成数据层、检索层、推理层、业务层每层独立维护排查问题时直接定位某一层。这个习惯帮我节省了大量时间也是我从多次重构中得到的最大经验。
阅读完成 · 觉得有帮助？
)
