从毕业到能独立交付一个AI项目中间其实隔着一整片海。很多人以为学会了调几个Python库、能跑通transformers的demo就算入了门结果一到真实业务场景被Prompt不稳定、模型幻觉、上下文截断、token成本爆炸这些问题轮番教育。我自己也是从这个阶段爬过来的所以看到ai-engineering-from-scratch这种标题第一反应是终于有人把“从零到能干活”这条路给认真捋了一遍。这篇文章不聊那种三天速成的鸡汤也不堆一堆“AI时代你必须掌握的核心竞争力”之类的空话。我想把AI工程化这条路上真正绕不开的东西——技能栈怎么搭、第一个项目怎么做、坑都长在哪、怎么持续进阶——从头到尾拆开讲一遍。如果你正准备进入这个方向或者已经在门口转悠了这篇应该能帮你省下不少试错的学费。1. 先把战场看清楚AI工程化究竟在解决什么问题1.1 AI工程不是“调个API”那么简单两年前我一度也觉得既然大模型能力这么强拿过来用不就行了直到第一次做实际交付才发现模型能力只占整个系统的一小块甚至经常是最不稳定的那一块。什么叫AI工程化一句话把大模型、数据、业务逻辑、系统架构揉成一个稳定、可控、可维护、成本可接受的产品级系统。它不只是“调用一次模型接口”的事还涉及几个关键点怎么把用户的问题转换成模型最容易发挥的形式Prompt工程、检索增强怎么让模型输出变成能被业务系统直接消费的结构化数据函数调用、结构输出怎么控制幻觉怎么兜底失败怎么在模型答错的时候把损失降到最低怎么评估每一次改动到底是变好了还是变坏了怎么控制延迟和成本怎么应对流量波动怎么持续迭代而不是上线之后就只能祈祷模型别抽风。这些东西没有哪个是“调用一个API”能解决的。你可以把大模型想象成一个能力很强但脾气很不稳定的新员工——你知道他能干活但你不确定他哪天会给你整出什么幺蛾子。AI工程化就是围绕这个“新员工”搭一套管理机制让他在你的业务流程里稳定输出。1.2 为什么“from scratch”的学习方式反而更快接触过很多想入行的朋友他们最常见的误区是一上来就奔着“微调大模型”去或者直接扎进最新的论文堆里。我问他们为什么这么做回答多半是“因为看起来高级”。在这个领域高级感最害人。从零开始不是要从线性代数开始啃而是要从最小可用的系统开始一层层往上加复杂度。这个“从零”指的是不依赖现成的AI应用模板亲自动手把每一个环节搭出来理解每一层为什么存在。这样做的价值在于出了问题你知道去哪查。用现成框架的人遇到bug往往只能瞎试因为你不知道框架替你做了哪些决策你对“技术选型”有真实的感受。Vector DB为什么选这个不选那个、Chunk大小为什么影响检索效果——这些只有踩过坑才记得牢面试和实际工作里最看重的恰恰是你对系统每个环节的掌握深度而不是你用过几个云计算平台。我自己带过一个零基础转行的朋友他花三个月从Python语法开始一路做到一个完整的RAG问答系统上线靠的就是“每一步都自己搭一遍”的方式。回头看那些急着上教程、到处抄代码的人反倒在半年后还在原地打转。2. 从零起步的能力地图学什么、按什么顺序学2.1 第一层Python和工程基本功别在这里省时间不管AI怎么发展工程落地目前还是Python的主场。你不需要成为Python语言专家但下面这些基本功必须过关数据结构与基本算法尤其是字典、列表、集合的常用操作和复杂度概念面向对象的基本思想能用类来组织代码就行文件操作、JSON/YAML数据的读写与处理异常处理这个特别重要——调模型接口的时候异常是常态不是意外能用virtualenv或uv管理虚拟环境能读懂依赖冲突报错会用pip install和requirements.txtGit的基本操作包括分支、提交、合并、回滚。很多人觉得这些东西“太基础了浪费时间”但实际工作中一个词嵌入维度过大导致的内存问题、一个JSON解析失败导致的线上事故往往就卡在这种“低级”环节上。工程能力的本质是你对基础设施的掌控力不是你会多少个高级库。2.2 第二层机器学习地基——不需要当研究员但要知道原理AI工程不需要你手推反向传播公式但你必须知道模型在干什么。我推荐的底线是搞清楚分类、回归、过拟合、欠拟合这些基本概念理解训练集、验证集、测试集的划分逻辑了解评估指标准确率、召回率、F1、困惑度等的含义了解神经网络的基本结构嵌入层、注意力、Transformer的粗粒度原理了解Tokenization是怎么回事知道为什么“字数为啥对不上Token数”不用会训练大模型但最好把huggingface transformers的加载、推理跑通一遍哪怕只是加载一个小的开源模型试试。有一个特别反直觉的体会想分享真正让你区别于“调包侠”的往往不是你懂多少模型结构而是你对“数据”和“评估”的理解有多深。模型是别人的数据是你的评估标准是大家定的——这三个里面有两个在你手里。2.3 第三层LLM时代的工程新技能——这才是“AI工程”的本体到了这一层才开始进入真正的AI工程领域。核心技能包括Prompt工程与结构化输出。你得会设计系统提示词、少样本示例会使用JSON Mode、函数调用Function Calling让模型稳定输出结构化内容。这块的经验很密集踩坑也最多。检索增强生成RAG。你会学到文档加载、文本分块Chunking、向量化、相似度检索、上下文重排Re-ranking这些环节。目前大多数落地场景本质都是RAG的各种变体。评估Evaluation。你不仅要知道怎么构建系统还要知道怎么量化“系统好不好”。从人工评估到自动化指标再到基于大模型做裁判LLM-as-Judge这一套是工程落地的灵魂。AI应用架构。包括如何用FastAPI/Flask把AI能力封装成接口、如何管理会话状态、如何做缓存、如何做重试与降级、如何做流式输出、如何接入前端。向量数据库与数据工程。掌握至少一种向量库Chroma、FAISS、Milvus、pgvector中的一种会做基础的ETL能处理非结构化数据的清洗。模型微调可选但重要。当RAG和Prompt都解决不了问题时微调是一张底牌。至少要了解LoRA、Q-LoRA这些参数高效微调方法的原理和适用场景。2.4 一个可以参考的学习顺序和时间规划拿我自己来讲如果现在从零重新走一遍我会按下面的顺序排大概四到五个月可以到“能独立交付小项目”的水平阶段时长核心内容输出物第一阶段3-4周Python语法、Git、API基础、JSON处理能写脚本调用任意HTTP API第二阶段4-6周ML基础、Transformers原理、跑通开源模型推理在自己的电脑/服务器上跑通一个小模型第三阶段6-8周Prompt工程、RAG全流程、向量库、FastAPI一个“上传文档→提问→得到答案”的RAG系统第四阶段4-6周评估体系、微调初步、部署上线、成本优化一个有评估报告、可上线演示的完整项目这个节奏的前提是每天保证三小时左右的投入。如果你是全职转行可以压缩到三四个月如果是业余时间节奏拉长到半年也很正常。关键是每个阶段结束必须有看得见的成果物否则你根本不知道自己是“会了”还是“觉得会了”。3. 第一个完整项目实战从零搭一个RAG问答系统3.1 项目拆解先画系统架构再动手写代码我最建议新手做的第一个完整项目是“基于企业知识库的问答助手”。这个项目覆盖了AI工程的大部分核心环节难度适中而且拿得出手。整个系统需要拆成六个模块文档处理模块负责接收PDF/Word/Markdown/网页内容做格式解析和清洗分块与向量化模块把长文档切成小块生成向量索引向量存储模块存向量提供相似度检索检索与重排模块根据用户问题检索相关片段必要时做重排生成模块把检索结果和用户问题组装成Prompt调用大模型回答服务与交互模块用FastAPI封装接口做一个可交互的Web对话界面。这张图在心里一定要非常清楚。很多新手写代码是“边写边想”结果越写越乱。我建议第一步先在纸上画出完整的数据流用户提问→问题向量化→向量库检索→拼Prompt→调模型→返回答案→展示引用来源。数据流想清楚了代码只是一个翻译过程。3.2 核心代码实现分块、向量化、检索、生成我拿一套最经典的实现来说。先看文档分块和向量化from langchain_text_splitters import RecursiveCharacterTextSplitter from openai import OpenAI import chromadb # 1. 文档分块这里用递归字符分块器按段落句子边界切 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , ., !, ?, , ] ) chunks text_splitter.split_text(raw_text)这里有个很多新手忽略的重点chunk_size和chunk_overlap不是拍脑袋定的它们直接影响检索质量。chunk太小语义不完整检索到的片段往往答非所问chunk太大一个块里包含太多主题向量会被平均掉检索精度下降。500到800字是中文场景下比较通用的起点但具体要看你文档的类型。我的经验是先手动抽查20个检索结果再决定要不要调整别一开始就追求完美参数。接着是向量化和存储。我用Chroma举例因为它零配置、够轻量client chromadb.PersistentClient(path./chroma_db) collection client.get_or_create_collection( nameknowledge_base, metadata{hnsw:space: cosine} ) # 用Embedding模型把每个chunk转成向量 from sentence_transformers import SentenceTransformer embedder SentenceTransformer(BAAI/bge-m3) for i, chunk in enumerate(chunks): embedding embedder.encode(chunk).tolist() collection.add( ids[fchunk_{i}], embeddings[embedding], documents[chunk], metadatas[{source: file_name, chunk_index: i}] )这里的选型考量是为什么用bge-m3而不是OpenAI的Embedding接口因为本地部署的Embedding模型没有API调用成本也不存在数据外传问题对新手练手更友好。等以后业务规模上来了再考虑换成效果更优的专用Embedding服务也不迟。检索和生成的配合是整个系统最关键的地方from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keylocal) # 本地部署的模型 def answer_question(question: str): # 1. 问题向量化并检索 q_embedding embedder.encode(question).tolist() results collection.query( query_embeddings[q_embedding], n_results5, include[documents, distances, metadatas] ) # 2. 拼接上下文构造Prompt context \n\n.join(results[documents][0]) prompt f请基于以下资料回答用户问题。 如果资料中没有相关信息请直接说明“根据提供资料无法回答”不要编造。 回答时请附上引用编号。 【资料】 {context} 【用户问题】 {question} 【回答】 # 3. 调用大模型要求结构化输出 response client.chat.completions.create( modelqwen2.5-14b-instruct, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content这里有几个新手容易踩的坑我当年全踩过temperature一定不能调太高。问答类场景建议0到0.3之间。我见过有人用默认值1.0结果同一个问题每次都给出不一样的答案用户直接投诉。检索结果里必须带引用来源。不只是为了“看起来专业”更是为了用户能追溯验证。没有引用的AI回答在企业场景里根本不敢直接用。Prompt里必须明确“不知道就说不知道”。模型天生就有补全倾向你不禁止它编造它就编给你看。3.3 封装接口与部署上线让系统真正“能用”后台逻辑做完了还得让它跑起来。我推荐用FastAPI封装from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QuestionRequest(BaseModel): question: str app.post(/ask) def ask(req: QuestionRequest): answer answer_question(req.question) return {answer: answer}然后再用一个简单的HTML页面接上这个接口一个能用的问答服务就出来了。部署方面新手不用上来就上K8s一台带GPU的小服务器或者直接用云服务器配Docker跑一个docker compose up就够了。说到Docker给一个最小可用的配置参考FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]要注意Embedding模型和向量库最好用volume挂载持久化不然每次重启容器都要重新向量化那种等半小时的痛苦我不想你体验第二次。4. 评估与调优从“能跑”到“好用”的关键一跃4.1 没有评估体系你的优化全是盲人摸象我见过太多人做完RAG系统之后就开始凭感觉改参数。今天把top_k从5改成10明天换一个Embedding模型问他“效果到底好了没有”他说“感觉回答好像更完整了”。这种感觉派做法在真正交付的时候会吃大亏。正确做法是先建立一套评估基准再谈优化。最实用的入门评估方案是准备50到100条高质量的问答对可以从你的知识库里人工构造每条包括问题、标准答案、来源文档。然后用这套基准去跑你的系统统计几个指标检索命中率正确文档有没有被检索到前5名里回答正确率人工判断回答是否基于检索到的资料且正确幻觉率回答中出现了多少资料里没有的编造内容拒答率该拒绝回答的时候有没有明确拒绝。自动化评估现在也成熟了。用大模型当裁判LLM-as-Judge让GPT-4o或Qwen-Max这类强模型给回答打分。但要注意提示让模型当裁判之前先人工标50条数据做一致性校验。如果裁判模型的判断和你自己的判断一致性不到80%说明你的评估Prompt有问题先调评估Prompt别急着调业务系统。4.2 调优三板斧检索、上下文、生成有了评估体系调优就有方向了。我总结出来的调优顺序按优先级排第一板斧优化检索质量。检索是一切的基础检索不到正确内容生成再强也白费。试这几件事换Embedding模型国产的bge-m3、gte-large-zh在中文场景都很能打调整分块策略语义完整性和长度平衡要反复测加入重排Re-ranking用bge-reranker-v2-m3这类模型对检索结果做二次排序top_k从20缩到5尝试混合检索向量检索关键词检索用BM25兜底向量检索的盲区。第二板斧优化上下文组装。检索出来的片段不是你一股脑全塞给模型就完事。经验是控制上下文总量不是塞得越多越好无关信息会淹没关键信息给每段资料加来源标签如[1][2][3]让模型引用编号相关信息之间可能分散在不同片段里考虑做“二次检索”先找段落再找句子。第三板斧优化生成策略。这一步是最容易出效果的温度调到0.2左右回答稳定性会肉眼可见地提升在Prompt里加入“如果信息不足请提出需要补充什么信息”让模型学会追问而不是瞎编对高风险场景增加一个独立的“安全回答模式”由另一条Prompt单独判断是否回答。4.3 成本与性能工程化绕不开的两座山这一块几乎是所有教程都不讲的但偏偏是实际交付时最要命的。先说Token成本。每次问答消耗的Token主要由三部分构成系统提示词检索到的上下文用户问题模型输出。我见过一个团队检索top_k取10每个chunk 500字一次问答就要消耗近5000个Token用户一个问题成本七八分钱日均一万个问题就是大几百块。优化手段包括压缩上下文只装最相关的片段无关片段直接丢弃Prompt缓存把系统提示词和稳定上下文缓存起来可以省掉不少重复计费用小模型做前缀过滤把明显无关的问题直接挡掉不用每次都调大模型用流式输出来改善用户体验让第一个字尽快出现而不是等全部生成完。再说延迟。回答在2秒内用户基本无感5秒以上用户就会开始焦虑。影响延迟的因素包括模型尺寸、上下文长度、并发量。实操建议是自建模型的话用vLLM部署推理服务吞吐量能翻好几倍尽量用小模型处理简单问题大模型处理复杂问题做两级路由Embedding计算提前做好不要让用户请求实时触发文档向量化。5. 实务中的坑与排查手记5.1 高频问题速查表我把自己这几年踩过的坑整理成了一张表遇到问题可以先对照排查现象最可能的原因快速排查方法解决方案回答总在编造资料外的内容上下文相关度不够打印检索到的片段人工判断是否与问题相关调分块/检索/重排Prompt强制加“资料中没有就说不存在”同一个问题每次答案不一样temperature太高检查生成参数降到0.1-0.3检索结果相关的排不上去chunk切割破坏了语义打开chunk列表看内容完整性增大chunk_size或改用按语义切分回答莫名中断/截断超出上下文窗口或输出长度限制查看报错与服务端日志压缩上下文、增大max_tokens、开启自动截断加载文档时内存飘红没做流式处理/大文件一次性读入观察内存曲线改流式读取限制文件大小PDF按页处理相同内容反复被检索出来重复文档/重复chunk检查向量库doc数量加去重按文档hash过滤线上延迟忽高忽低并发没控制好或模型推理队列阻塞看QPS与推理服务指标加并发限制、启用连续批处理、必要时扩容5.2 三个让我印象深刻的翻车现场翻车记录对工程人的价值往往比成功经验更大。分享三个具体的第一个翻车被“上下文长度”背后捅了一刀。当时做了一个文档问答用户上传了一份几百页的PDF我天真地以为把全文塞进Prompt就完事。模型收到几万Token的上下文之后直接开始忽略部分内容回答质量直线下降用户问第一章的问题它偏要引用第三章的内容。后来才明白长上下文不等于强理解模型对长上下文中段信息的注意力会明显衰减。从那以后凡是超过一定长度的内容一律先检索再生成绝不硬塞。第二个翻车Embedding模型换了检索效果反而变差。有次觉得开源的Embedding模型不够“高级”换了一个更大更贵的结果评估分数降了。仔细排查才发现新模型的向量维度不同直接把旧向量库里的数据一起用了维度对不上检索结果完全乱套。这个教训让我深刻记住了换Embedding模型必须重建向量库而且要在同一套评估基准上跑分数对比不能靠感觉。第三个翻车评估标准没先定白忙活了两周。这个最惨。当时调Prompt调到“自我感觉良好”上线之后用户反馈很不好。复盘时发现问题的根源是我没有任何量化指标所有的“优化”都是靠个人感觉。后来老老实实花了三天做了一批评估问答对又花了几天调整效果才真正稳下来。没有评估体系的优化本质上是在赌运气。5.3 排查问题的方法论先拆环节再打日志遇到AI系统的问题最忌讳的是凭感觉改代码。我给自己定了一个排查流程先看数据流到哪一环断了。用户问题进来向量化成功了吗检索返回结果了吗Prompt拼接完整吗模型调用成功了吗每一步都打日志、打印中间结果。再判断是“检索问题”还是“生成问题”。会快速打印检索结果如果检索结果里有正确答案但回答错了那是生成环节的问题如果检索结果根本没有正确答案那就是检索或分块的问题。大半的RAG问题都能用这一招定位。最后才怀疑模型本身。所有改动落空之后用最简单的例子直接测模型排除是模型抽风还是你系统的问题。这个流程帮我节省了无数排查时间。建议你把这个三步骤流程刻在脑子里。6. 持续进阶从一个项目到真正的AI工程师6.1 做完了第一个项目下一步怎么走第一个RAG系统跑通之后人会进入一个“蜜月期”觉得AI工程不过如此。这时候恰恰是最危险的。真实的业务场景比这复杂得多我建议往这几个方向延伸加一个多轮对话管理模块。你的RAG目前是无状态的用户追问“那第二个方案呢”时系统根本不知道“那”指什么。加一个会话摘要上下文管理的模块难度上一个台阶也实用得多。加一个接入外部工具的能力。让模型能够调用真实的API或数据库比如查订单、查库存。这就是目前最火的Agent智能体方向掌握的性价比很高。做一个真正的微调项目。用LoRA微调一个开源模型哪怕只是让它的回答风格变成某个领域的专家。微调不是万能的但理解它的原理能让你对整个大模型生态有更清醒的认识。把部署和运维打磨到“生产级”。做监控、告警、日志采集、灰度发布、多版本切换。不需要做到大厂的规模但至少要对“生产级的AI系统需要什么样”有直观的认知。6.2 我眼中的“合格AI工程师”底色聊了这么多技术细节最后想说点更重要的判断标准。在这个领域待得越久我越觉得AI工程师真正的核心竞争力不在于“背了多少模型结构”或“接触了多少新框架”而是这么几件事第一对不确定性有天然的警惕。大模型的概率输出决定了它天然不稳定一个合格的AI工程师不会百分之百信任任何一次输出而是会设计兜底、校验、监控、降级方案。不管哪个环节出了问题系统都能优雅地给出反馈。第二有很强的“翻译”能力。能把业务问题翻译成技术方案再把技术方案的边界翻译给业务方听。经常有业务方觉得AI什么都能干你要能清楚告诉他哪些能做、哪些不能做、哪些能做到什么程度边界在哪。第三会平衡理想和现实。RAG效果还能再提升但投入产出比已经很低了这个版本的交付要不要锁微调可能让效果提升10%但数据集标注要花两周值不值这种取舍每天都在发生“做得出来”和“做得好”是两码事“做得好”和“做得值”又是两码事。我在实际带人的时候发现能走到最后的人往往不是在技术竞赛里赢最多的那个而是遇到问题愿意沉下心把原理搞清楚、出了问题第一个冲到现场的那个人。AI工程这条路说长不长你会踩的坑其实就那几个类型提前把地图看清楚了走起来心里会稳很多。希望这篇分享能帮你在起步的时候少摔几跤把你从“能跑demo”往“能落地系统”那个方向实实在在推一把。