总有朋友跑来问我我想转行做AI工程从零开始应该怎么学是去啃深度学习教材还是先把线性代数捡起来每次听到这种问题我都想先拦一下。因为很多人对 ai-engineering-from-scratch 这件事的理解从第一步就是偏的。AI工程不是一门按目录顺序学习的课程它更像一门手艺。你不能像念大学那样先学一年理论再碰代码而是要先做出一个能跑的东西再回头补原理、补规范、补那些让系统真正抗揍的细节。这篇文章我想把从零到能独立交付一个AI应用的完整路径拆给你看包括学习路线、实战案例、翻车现场还有一些我真实花了预算才买到的教训。不管你是刚毕业、传统后端转方向还是产品经理想动手做点东西只要会一点Python这条路是通着的。1. 先拆掉误解AI工程师到底在做什么1.1 训练模型和用模型是两件完全不同的事很多新手看到AI工程四个字脑子里浮现的是写神经网络、调参训练、复现论文。这其实是算法研究员干的事。产业里绝大多数AI工程师日常工作不是从零训练一个模型而是把现成的、别人已经训练好的模型接进业务系统让它们稳定、可控、可维护地输出价值。我见过一个科班出身的朋友花两个月啃完了矩阵求导和反向传播推导结果让他做个能回答公司制度问题的机器人还是不知道从哪下手。反过来另一个只会基础Python的同事用一周时间就搭出了一个带知识库的问答Demo第二个月已经上线给内部几十个人用了。差距不在理论深度而在于是否理解AI工程用模型解决现实问题这件事。标题里的 from scratch指的是你从零基础开始掌握这门手艺而不是说你要把所有底层都从零造一遍。这个认知如果不纠正你会在错误的方向上消耗大量时间。1.2 真实的知识树比想象中窄也比想象中深我把一个能独立交付AI应用的人需要掌握的东西列出来你会发现它跟大学AI课程表的重合度其实不高必须掌握可以后期再补Python基本功函数、类、异常、装饰器线性代数、概率论的系统复习HTTP API调用、JSON处理、鉴权方式深度学习网络结构细节提示词设计指令、格式约束、少样本示例模型训练、微调底层原理数据处理清洗、切分、去重、格式转换分布式训练、GPU集群维护检索基础向量化、相似度、召回与重排模型架构论文精读评估方法构建测试集、指标计算特征工程等传统ML内容工程基础容器、队列、日志、监控自研向量数据库、推理引擎注意表格两列的差异点在哪里。左边所有内容都能在真实项目里直接转化为产出右边的东西是你做到一定程度后按需补的而不是起步阶段的门槛。这里我要特别强调一点AI工程的知识树是以任务为中心长出来的。你今天要做知识库问答就只需要学检索、切分、提示词、评测这几样明天要做流程自动化再去补函数调用、工具编排、状态管理。知识树跟着任务走而不是反过来先背完一整棵树再去找任务。1.3 为什么市面上大多数教程会把你带偏现在的AI学习资源有个共同问题它们把知识体系完整放在第一位把做出东西放在第二位。于是你看到的学习路径往往是先花三周学Python基础再花一个月学机器学习原理再学深度学习最后才轮到如何调用大模型接口。等走到最后一步热情已经磨没了。更糟糕的是很多教程教你的是造轮子而不是用轮子。比如让你从零实现一个Transformer却没人告诉你生产环境里根本不需要这么干。教程需要体系化所以它按知识本身的逻辑组织内容但工程是反过来的工程按解决问题的最小路径组织知识。正确的姿势是按需学习遇到一个问题解决它顺便把相关的知识补上。第一周你可能只需要知道什么是token、什么是上下文窗口、temperature有什么效果这些足够你做出第一个Demo。等要做到知识库问答时再学为什么切分长度会影响召回质量。这才是符合成年人学习规律的方式。2. 分阶段学习路线让每个阶段都有看得见的产出2.1 阶段一一周内做出一个能对话的Demo第一个目标不是学完什么而是我手里有一个能跑的东西。这个Demo的要求很简单调用一个大模型接口能进行多轮对话最好有一个简单的界面。我的建议是直接用一个现成的Web UI框架比如Gradio或者Streamlit别在这一步纠结前端。你需要体验的是完整闭环用户输入→请求模型→展示回答。这个闭环会让你直观感受到三件事模型返回速度有多慢、输出有多不稳定、token成本是怎么随上下文增长的。实操时注意几个细节。第一把API Key放在环境变量里不要硬编码到代码里这个习惯从第一天就要养好。第二给对话加一个系统提示词比如你是一个耐心的AI助手然后观察它对回答风格的影响。第三故意问几个超出上下文能力的问题看看模型怎么编造答案。这一周的核心收获是你对大模型能做什么、不能做什么产生真实体感而不是纸面上的理解。2.2 阶段二把会说话变成可靠回答大多数人卡在阶段一到阶段二之间。为什么因为Demo只需要能回答而可靠系统需要答得对。这个阶段的主题是可控性具体要做三件事第一建立评估基准。挑一个你熟悉的领域比如公司规章制度准备20到50个标准问题写清每个问题的标准回答要点。这组数据就是你后面每次改动的尺子。第二引入检索增强。让系统从文档里找依据再回答而不是直接凭记忆生成。这一步是RAG检索增强生成的核心思想也是目前业界落地AI应用最主流的技术路线。第三设计兜底策略。模型在找不到依据时应该直接说我不确定而不是硬编一个答案。这个约束在提示词里就要写清楚。这个阶段会逼着你处理真实数据PDF怎么解析、表格怎么处理、文档怎么切分不破坏语义。这些动手经验远比背概念值钱。完成这个阶段你已经超过绝大多数会调接口但做不出可靠应用的人了。2.3 阶段三把它做成能扛住真实用户的东西Demo和产品的差距在于它能不能同时应对多个人、长期运行、出了问题能追溯。这个阶段要补工程能力加上缓存降低重复请求的成本用队列处理耗时的后台任务把每次请求的耗时和消耗记录到日志里给系统加上简单的健康检查。注意这里不需要一开始就上微服务、K8s。对于刚起步的人一台服务器加一个进程管理工具足够。你要理解的是这些概念为什么存在为什么需要缓存省钱、省延迟、为什么需要日志出了问题能定位、为什么需要限流防止被刷爆。技术选型可以简单但工程思维必须建立起来。2.4 这条路线里可以安心砍掉的内容我见过太多人把时间浪费在以下事情上这里直接帮你排除掉不要一开始就学模型微调。对于大多数业务场景提示词和RAG已经能解决八成问题微调是最后的精细化手段不是入场券。不要自建向量数据库。起步阶段用开源或托管方案足够等数据量到百万级再考虑自建。不要试图掌握一个大框架的全部功能。很多框架的抽象层既能帮你提效也能让你看不清底层在发生什么。先会用最核心的几条链路其他按需查文档。不要每天追新模型。模型更新很快但工程方法论是稳定的。你花一周追一个新发布不如花一周把现有系统的评估集完善。一句话砍掉一切不直接服务于做出可靠系统的学习内容。3. 实战拆解用RAG做一个企业文档问答系统光讲路线没有抓手我拿一个最经典的入门项目——企业文档问答系统——完整拆一遍。它覆盖了数据、检索、生成、评估、上线全部环节是练手性价比最高的项目。3.1 先定义需求和评估标准再写代码很多人一上来就写代码这是项目管理上的错误。你需要先回答三个问题数据是什么形态PDF、Word、网页还是数据库导出量级是几十篇还是几万篇用户问什么是事实型问题年假有几天、流程型问题报销怎么走还是开放型问题公司对远程办公怎么看什么样的回答算好是答案正确就行还是必须带出处、按固定格式输出这三个问题的答案直接决定你的技术选型。同时动手之前先写20个代表性的测试问题并给每个问题标注期望答案的要点。这个测试集会成为你后面所有优化的度量尺。没有尺子的优化都是自我感觉良好。3.2 数据准备加载、清洗、切分数据准备通常占整个项目七成的工作量却最容易被忽略。一份200页的PDF里面可能有页眉页脚、目录、表格、图片说明直接全部切分向量化检索质量一定会崩。加载解析之后第一件事是清洗去掉无关的页眉页脚处理乱码字符把表格转成结构化的文本描述。然后做切分。切分是RAG里最考验经验的一步切太大会让上下文塞满无关内容切太小会切断语义。from langchain_text_splitters import RecursiveCharacterTextSplitter def build_chunks(documents, chunk_size500, chunk_overlap80): splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , , ], length_functionlen, ) return [chunk for doc in documents for chunk in splitter.split_text(doc)]这里的核心参数是 chunk_size 和 chunk_overlap。切分粒度要跟你的问题类型匹配如果用户问的是政策条款这种点状信息500字符左右比较合适如果问的是操作流程这种上下文强相关的信息可以适当调大。chunk_overlap则用来避免把一句话从中间切开。每次调整切分参数后都要用测试集评估检索效果而不是凭感觉决定。3.3 向量化与检索召回、重排、再给模型数据切好后要选一个向量化模型把每个片段的文本变成向量存入数据库。选embedding模型时关注两个指标检索效果和成本。中文场景下可以选择开源的中文embedding模型也可以使用商业API各有取舍。向量数据库同理数据量小的时候直接用轻量级方案就行不需要上重型集群。检索环节最常见的错误是只做向量Top-K召回。实际生产里我建议至少叠加两层先用向量检索召回候选再用重排序模型对候选重新打分。原因很简单向量的相似度不等于语义相关度就像这个苹果好吃和苹果公司股价向量可能很近但实际不是一回事。重排能有效提升最终送入生成模块的内容质量。def retrieve(query, top_k8): query_vector embed(query) hits vector_db.search(query_vector, top_ktop_k) candidates [h.payload[text] for h in hits] reranked reranker.rerank(query, candidates, top_n3) return reranked # 只把最相关的3段送给模型这里的 top_k 和送入模型的片段数量也要配合调节。送的片段太多既增加token成本又可能引入噪声干扰模型判断太少则可能漏掉关键信息。我刚做RAG时习惯一次送8段后来发现送到3到4段质量最好成本还降了一半。3.4 生成提示词决定输出下限检索做得再好最后输出质量还是由提示词和模型协作决定。一个可靠的RAG提示词至少要包含三部分角色与任务定义、检索到的参考资料、输出约束。PROMPT 你是一名企业知识库助手。请严格依据以下参考资料回答用户问题。 参考资料 {context} 要求 1. 只依据提供的内容回答禁止使用自身知识补充。 2. 如果资料中找不到答案直接说资料中未找到相关信息。 3. 回答中标注信息来源格式为[来源1][来源2]。 4. 回答要简洁控制在200字以内。 用户问题{question} 注意几个细节。第一不要只写请基于资料回答要写禁止使用自身知识补充。少了一个禁止模型就更倾向于自由发挥幻觉率会明显上升。第二要求标注来源这既是给用户的可信度也是给你自己的可追溯性。第三输出长度约束要根据真实使用场景来设不是越短越好。3.5 评估闭环你怎么知道系统变好了整个系统搭起来后就要进入一个持续循环定义指标→跑测试集→分析错误→修改系统→再跑测试集。既然你在动手前已经准备好了20到50个测试问题现在就可以拿它做回归。def evaluate(questions_with_answers): results [] for q, expected_points in questions_with_answers: answer rag_pipeline(q) hit any(point in answer for point in expected_points) has_source [来源 in answer refused 未找到相关信息 in answer results.append({ question: q, answer: answer, expected: expected_points, fact_correct: hit, has_source: has_source, refused_appropriately: refused, }) return results这里我用期望要点是否出现在回答里作为粗糙的自动判定。更精细的做法是用另一个模型当裁判把回答和参考答案一起送过去打分也就是LLM-as-judge。但要注意模型裁判也会有偏差所以关键样本要定期人工抽检。评估的终极目的是让你每次改完代码后能明确说出这版比上版好还是差好在哪里差在哪里。做不到这一点你的优化就是在玄学里打转。4. 预算、幻觉、评测、性能新手最容易翻车的四个环节4.1 成本API账单比想象中涨得快很多新手做项目时完全不看成本等收到账单才傻眼。我帮你算一笔账假设你的知识库有1万份文档每份平均2000 token全部向量化一次单次embedding费用虽然很低但1万份文档乘以2万token每份平均向量化消耗切分重叠累计消耗大约2000万token这只是一个基础量级。更花钱的是问答环节每次用户提问系统要送进模型的上下文可能有1500到2500 token如果一天被调用1万次光生成消耗就是几千万token。控制成本的现实手段有几个。第一缓存重复问题。用户问年假多少天和年假有几天在向量语义上几乎一样命中缓存后直接返回零成本。第二控制送入模型的片段数量。上面对比过从8段降到4段质量和成本双赢。第三给每日消费设置硬上限云平台都支持预算告警这个一定要开。我吃过一次亏一个Demo忘记关后台任务一晚上跑掉了一个月预算之后再也不敢不设告警。4.2 幻觉能缓解但不能根除幻觉是大模型天生的缺陷不是配置问题所以别指望彻底解决。RAG的思路是用检索到的内容约束生成这能把幻觉从凭空编造压到基于错误资料推理但依然会犯错。比如资料里写了年假5天模型可能自动推理出工作满一年后年假10天而这话在资料里根本不存在。在提示词里反复强调只依据资料能降低幻觉频率但挡不住推理型幻觉。所以在高风险场景医疗、法律、金融建议里我的建议是加一层人工确认环节把AI的回答定性为草稿而不是结论。另外让模型给出引用来源用户能点开原文核对这本身就是一种有效的信任机制。你要把系统偶尔会错这个事实在产品设计层面就消化掉。4.3 评测失灵没有指标优化全是心理安慰评测最容易踩的坑是用一条Demo上的漂亮回答来证明系统有效。我见过有人拿着精心设计的5个问题把系统答得完美无缺的截图发到群里过两天换了一批真实问题就漏洞百出。正确的评测动作是固定测试集→逐次改动→对比指标→保留改进。这里要特别提醒LLM-as-judge的使用边界。用大模型当裁判来评估大模型系统优点是速度快、能理解语义缺点是有系统性偏好。有的模型裁判天然偏爱更长的回答有的偏爱特定措辞。所以凡是用模型裁判的场景都要定期用人工标注的样本校准发现裁判跑偏就调整打分提示词或者换策略。4.4 性能与并发从Demo到能用的距离单个用户测试时系统响应3秒可能觉得能接受。但一旦有50个人同时用没有并发处理能力的系统基本就卡死了。你需要提前想清楚几个问题如果模型接口超时怎么办重试机制怎么设计是不是该给回答加流式输出让用户看到文字逐步生成而不是干等转圈流式输出不仅是体验优化更是心理上的性能优化——用户感知到的等待时间会大幅缩短。对于耗时的文档解析、批量向量化这类任务要用异步队列处理让用户先得到任务已提交的反馈。上线前用压测工具模拟几十个并发请求看看系统在什么量级开始变慢心里有数才不会上线当天手忙脚乱。5. 工程化必知让AI系统可维护、可观测、可回滚5.1 提示词也要做版本管理提示词是代码。它会变、会出bug、会需要回滚所以不能只存在Jupyter Notebook里。我从一开始就强烈建议把提示词模板抽成独立文件或配置项和代码一起进版本仓库。每次修改提示词对应你的测试集跑一遍记录前后指标差异。进阶做法是给提示词加版本号和变更日志。比如prompt_v3 增加了禁止猜测约束测试集准确率从71%提升到83%。这些记录不仅帮你复盘未来系统出问题时也能快速定位是代码问题还是提示词问题。很多团队上线半年后回答质量下降最后发现是某个同事偷偷改了提示词没有留痕这类事故完全可以靠版本管理避免。5.2 日志里要能看到什么传统应用的日志你关心异常AI应用的日志你还要关心模型的每一次输出质量。我给每个请求记录五类信息请求内容、输出内容、消耗的token数、耗时、检索命中的文档片段ID。有了这些用户投诉答得不对时你能回放当时的完整状态模型收到了什么、检索给了什么、最后生成了什么。更进阶的观测是记录拒绝率和引用率系统有多少比例的请求直接说找不到资料有多少回答带出了来源这两个指标异常上升往往意味着知识库更新出了问题比如新文档格式没解析好或者切分参数被意外改动。成本追踪同样重要按天、按用户维度统计token消耗能帮你及时洞察异常调用。5.3 测试与灰度LLM输出不确定的应对之道LLM输出天然不稳定同样的输入可能每次回答措辞都不同这让传统单元测试很难直接套用。我的做法是分层测试第一层对纯代码逻辑做单元测试比如数据清洗函数、切分器行为、检索结果的数量是否符合预期第二层对提示词结果做断言测试检查输出格式是否包含必需字段、是否包含引用标记、是否在应该拒绝的场景拒绝了第三层用评估集做全量回归这一层接受小的措辞波动但语义正确率必须稳定。上线策略上我建议先小范围灰度。老系统继续服务大部分用户新版本先放给10%的用户观察日志指标和用户反馈确认没有问题再逐步放量。如果新版本回答质量明显下降可以直接切回旧版本。这种可回滚的能力比任何预防措施都重要。5.4 框架与平台选型先直连再抽象工具选型是每个AI工程师都要过的关。常见的做法对比方案优点缺点适合场景直连模型API 自写胶水代码逻辑透明、依赖少、易排查功能重复、迭代较慢学习阶段、逻辑简单的项目LangChain等编排框架组件齐全、上手快抽象层级多、黑盒难排查快速原型、标准RAG场景LlamaIndex数据处理链完善偏检索场景、泛化一般文档知识库类项目低代码平台无代码门槛灵活度低、绑定平台非技术团队快速验证我的建议是学习阶段以直连API为主手写一遍检索和生成的主链路这样才能理解每一层在做什么。等项目复杂度上来再引入框架解决重复劳动。用框架前先问自己这个抽象帮我省了多少时间它出了问题我能Debug吗如果两个答案都是否定的就别用。很多AI项目最后重构地狱不是因为代码写得差而是因为框架抽象选错了。6. 三个月行动清单从零到能写进简历的完整项目6.1 第一个月打基础与第一个Demo前两周按第二条路线完成阶段一的任务Python基础复习、调用模型API、搭出带界面的对话Demo。后两周进入阶段二选一个你熟悉的领域积累数据完成数据清洗和切分搭出第一个RAG链路。月底目标你的Demo能基于一个具体资料集回答问题并且带来源标注。这里选领域有个小技巧选你自己工作或熟悉的领域不要选通用百科。你对领域有判断力才能写出高质量的测试集和判断回答好坏。做公司制度问答的价值远大于做一个什么都能聊但什么都不精的通用助手。6.2 第二个月完整项目加评估报告这个月的任务是把Demo升级成能说服别人的项目。完成三件事一是建一个不少于50条的测试集条条有标准答案要点二是跑通完整的评估流程输出一份指标报告包括准确率、拒绝率、平均耗时、单次成本三是写一份项目的README和技术文档清晰地说明系统架构、使用方式、评测结果和改进过程。很多人忽略文档但文档才是面试官看的东西。一个能讲清楚为什么用RAG、为什么这么切分、评估指标提升过程的工程师和一个只会说我搭了一个问答机器人的人专业度差距是肉眼可见的。6.3 第三个月上线、开源、复盘用一台云服务器把项目部署上线接一个简单的访问入口邀请几个真实用户试用收集反馈。同时把代码开源接受社区的意见和提问。真实用户反馈的杀伤力在于它会击碎你在测试集上的幻想有人会问你没准备过的问题有人会投诉回答格式有人会对引用来源提出质疑。这些反馈才是最珍贵的训练素材。项目做完后做一次完整的复盘哪些环节花了最多时间哪些问题是在上线后暴露的如果重做一遍会有什么不同的决策这份复盘写进简历的项目难点栏比任何证书都有说服力。6.4 我踩过的几个坑免费送给你最后分享几条我自己的经验都是付过学费换来的。第一别把切分参数当玄学。所有参数调整都必须有评估依据记录每次调整前后的指标。我早期调切分长度今天改明天改最后回头看完全是在原地打转因为没有用测试集约束每一次改动。第二别迷信新模型。新模型发布时总有人喊全面超越但等你实际迁移完就知道提示词要重写、行为要重新评估、成本要重新测算迁移成本远比想象高。没有明确收益就不要动。第三警告在所有细节上做简化。第一个项目用最简单的技术栈用最朴素的方式实现别一上来就堆一堆组件。真正的问题永远在你的数据和提示词里不在框架里。把基础链路吃透比掌握十个框架更值钱。第四学会记录失败样本。每次系统答错都把问题、预期、实际输出、当时上下文存下来。这些失败样本是改进系统的珍贵资源定期拿它们做回归你会发现系统在持续变好。从零开始学AI工程真正难的从来不是某个技术点而是你能不能坚持做完一个完整项目。只要完成了上面三个月清单里哪怕百分之八十你已经比市面上大多数自称做过AI项目的人走得更远。希望这份拆解能帮你少绕几个弯也期待看到你的第一个项目上线。