做AI工程快第七个年头了带过不少从零起步的新人也亲手把一个又一个 Demo 推到线上。我越来越确信一件事你看到这个 ai-engineering-from-scratch 标题时候心里想的从零开始和真正要在生产环境里落地一套 AI 系统的从零开始大概率不是一回事。多数人以为的起点是从数学原理推一遍 Transformer是自己从头实现一个模型而实际业务里的起点往往是给一堆乱七八糟的数据写清洗脚本、设计一个能被稳定调用的接口、把模型输出的垃圾结果拦在用户看到之前。这篇文章不聊高深的模型原理也不准备带你重造轮子而是想以我个人的真实项目体感讲清楚从零搭建 AI 工程体系的完整路径该选什么工具、先做什么后做什么、哪些环节会被反复返工、哪些坑是文档里永远不会写的。无论你是刚入行的开发者、想转 AI 工程方向的后端同学还是已经会用大模型 API 但总觉得差点工程味的人这篇文章应该都能给你一条能直接落地的路线参考。1. 先想清楚AI 工程解决的到底是不是模型问题1.1 你以为的从零开始和真正的从零开始刚转 AI 工程那会儿我也犯过同样的错误花了三周啃深度学习理论试图把反向传播、注意力机制从头推导一遍。结果第一次接到真实任务时发现卡住我的根本不是模型理解而是用户上传的 PDF 里表格解析出来全是乱的、向量库里检索出来的内容驴唇不对马嘴、同一个 Prompt 上午好用下午就抽风。后来带人我总会先问一个问题如果现在让你把一个已经训练好的开源模型部署成线上服务你能搞定吗这里的搞定指的是——能承受生产流量、能处理异常输入、能监控效果、能在模型输出变差时快速定位原因。大多数从零开始的人在这道题面前会卡住。这恰恰说明AI 工程的核心难点不在模型内部而在模型周围那一圈没人写进教程的工程基建数据管道、检索链路、评估体系、部署运维、成本控制。我见过太多人在这条岔路上浪费了好几个月。不是说算法原理不重要而是对于工程落地这个目标来说它既不是起点也不是捷径。真正的主线是把一个已经存在的模型能力稳定、可控、低成本地嵌入到业务系统里。想明白这一点你的学习路径会完全不同。1.2 最小可用的 AI 工程链路长什么样从零起步你不需要一开始就设计出什么宏大架构。我个人经验是任何 AI 应用只要能跑通下面这条最小链路就已经比 80% 的 Demo 强了输入数据 - 数据清洗/格式化 - 检索可选 - 模型调用 - 输出解析 - 结果评估 - 返回给用户别小看这条链每个环节都有各自的坑。数据清洗决定模型吃进去的东西干不干净检索决定模型有没有足够的信息来回答问题模型调用决定延迟和成本输出解析决定能不能把模型回复变成系统能用的结构化数据结果评估则决定你后续迭代有没有方向感。拿最常见的 RAG 知识问答来说最小链路就是文档切分 - 向量化 - 存储到向量库 - 用户提问 - 召回相关片段 - 拼进 Prompt - 调用大模型 - 返回答案。这一条链路里任何一环出问题最后用户体验都是答非所问或胡编乱造。而你能做的排查就是从链路末端往回逐个检查是没召回到是 Prompt 拼错了还是模型本身理解错了1.3 三条经典切入路径选一条先跑通从零开始的人最容易犯的第二个错是同时想做太多事。今天想搭问答机器人明天想做内容总结工具后天又想搞自动化 Agent。我的建议是先选一条最简单的路径把它从零到一完整打通再横向扩展。经验里最适合新手起步的三条路径RAG 知识问答适合想解决模型不知道企业内部资料这类问题的场景。技术栈相对固定链路清晰评估起来也直观答得对不对一眼就能看出来。这是我最推荐的第一条路。内容批量处理比如摘要生成、信息提取、分类打标。特点是单条调用独立不涉及复杂的状态管理最适合用来练数据清洗和输出解析这两项基本功。单 Agent 工具调用让模型学会调用外部工具查天气、查数据库、发邮件。这条路径开始涉及让模型做决策对 Prompt 设计和结果校验的要求更高建议放到第二条或第三条再做。这三条路径覆盖了 AI 工程最核心的几块拼图数据、检索、生成、评估。跑通任何一条你就不是从零而是有一了。2. 工具链选型不同从零起点对应不同的学习曲线2.1 三档起步方式横向对比工具选型这件事被太多人讲成了信仰之争。其实不存在绝对最好的方案只存在最适合你当前阶段的选择。我把常见起步方式分成了三档各有各的适用人群起步方式典型代表适合人群优点最大代价全托管拖拽平台Coze、Dify 等低代码平台非技术背景、想快速验证想法上手极快内置大量组件抽象层太厚出问题很难排查难以定制编排框架LangChain、LlamaIndex 等有一定编程基础想快速搭原型组件丰富社区活跃能省不少样板代码抽象层仍在版本变动大底层原理容易变黑盒原生代码组合Python 模型 SDK FastAPI 向量库工程师背景想真正掌握底层逻辑完全可控出问题能查到底学习收益最大开发量更大所有细节都要自己处理我个人的建议是如果你未来真想靠AI 工程吃饭至少要走一遍第三档。哪怕最终项目里用了编排框架也值得先用原生代码徒手搭一条链路亲身感受一下请求模型-解析结果-处理异常-封装接口每一步到底发生了什么。这就像学做饭用预制菜包能很快端出一桌菜但想真的会做菜总得自己切几回菜、炒糊几回锅。2.2 我推荐的起步组合以及理由如果让我给一个既不那么累、又能学到东西的起步组合我会选编程语言Python。生态最全没有之一AI 相关的库和示例几乎全是 Python 的。模型调用直接用官方 SDK 或原生 HTTP 请求先不套编排框架。你只需要把 API Key 配好发一个请求拿到回复就完成了模型调用这一步。接口服务FastAPI。写起来简单自带接口文档异步支持也好用来把链路暴露成 HTTP 服务再合适不过。向量库先别上分布式向量数据库本地用 Chroma 或 FAISS 就行。它们的 API 足够简单数据量在百万级以内完全够用。开发调试Jupyter Notebook 做探索PyCharm 或 VS Code 写正式代码。这套组合的理由不复杂每个组件都足够薄出现问题你都能直接看到底层实现。比如 Prompt 结果不对你随手打印一下实际发给模型的消息内容就能定位是模板问题还是模型问题根本不需要去翻框架源码。2.3 为什么先别急着上全家桶现在行业里有个不太好的风气一上来就是 LangChain 向量数据库全家桶 K8s 部署。对从零起步的人来说这是在给自己制造不必要的复杂度。我自己踩过一个大跟头。第一次做企业知识问答时上来就用了当时最流行的编排框架链式调用、记忆模块、各种回调加了一堆抽象。结果上线第一周用户反馈答案不对我愣是花了两天才排查清楚问题出在召回环节——因为我得先搞明白框架内部的检索流程到底是怎么拼装上下文。那个框架当时的一个小版本升级还顺手改了我依赖的接口签名吓得我从此对重量级抽象都有了心理阴影。不是说这些框架不好它们确实能提升交付效率。但从学习和稳定性的角度从零开始最忌讳的就是在一堆不确定之上再叠一堆抽象。先徒手跑通再用框架提效这个顺序一旦颠倒排查问题就会变成灾难。提示判断一个工具是否适合你现在用就看两件事——出了问题你能否在半小时内定位到根因以及它的版本变动是否会打断你的迭代节奏。如果两者都是否那你还没到用它的时候。3. 搭建第一条完整链路从数据准备到结果评估3.1 数据准备被吐槽但不做不行的脏活很多人以为 AI 工程的数据准备就是把文件丢给模型就行。真实情况是这一步能占到整个项目 40% 以上的工作量而且直接决定上限。我第一次做文档问答时喂进去的是一批几十页的 PDF。偷懒没做预处理直接把整页文本暴力切块。结果检索环节垃圾进垃圾出模型拿到的是跨段落拼接的碎块答案自然颠三倒四。后来老老实实写了清洗脚本做了这几件事格式统一把 PDF、Word、网页抓下来的文本全部转成统一的 Markdown 格式去页眉页脚、去重复空白。结构保留按标题层级切分而不是按固定字符数切分。表格单独提取图片里的文字做 OCR。这一步对后续检索质量影响巨大。去重去噪用文本哈希做相似去重把重复段落、导航文案、版权声明这类噪音清掉。分块策略固定字符数切分的块大小需要实测。我常用的配置是 500-800 个 token 一块块间重叠 50-100 token。重叠的目的是避免关键信息正好被切在两块交界处。这里有个工程细节值得单独说分块不是越大越好。块太大向量化后语义容易被稀释召回精度下降块太小单块包含的上下文不够模型回答容易缺前因后果。500-800 token 是我在多个项目里验证过的相对均衡的范围但最终还是要拿你自己的数据跑几组对比实验再定。3.2 检索层为什么召回比生成更像核心在 RAG 链路里召回质量对最终效果的影响经常比模型本身还大。原因很简单模型只能基于你给它的信息作答你连正确上下文都没找回来再强的模型也只能瞎编。一个典型的检索链路包括三块向量化 - 向量检索 - 重排序。向量化就是把文本变成向量。这一步的选型很关键早期我用的是开源 embedding 模型后来发现同样的检索逻辑换成更强的新版模型比如现在常用的 BGE 系列或各家的商用 embedding 接口召回准确率能提升好几个点。而且这个提升是白捡的你只需要改一行配置。向量检索阶段最常用的方式是 Top-K 召回。K 值的设置需要权衡太小容易漏该召回的内容没召回到太大容易吵无关内容混进来干扰模型。我的经验是初始设为 5-10再根据实际效果微调。另外可以加一个相似度阈值的硬过滤——低于阈值的片段直接不要这能在源头上减少垃圾进、垃圾出的情况。重排序是经常被忽视但性价比极高的环节。先用向量检索捞出 Top-50 候选再让一个专门的重排序模型精排取最相关的 Top-5。实测下来这个两步检索方案能让最终答案质量稳定很多尤其当你的知识库规模上去之后单靠向量相似度已经不够可靠了因为向量检索追求的语义相近有时候和事实相关并不是一回事。3.3 生成层Prompt 工程不是玄学是结构化设计Prompt 工程被很多人搞得很玄其实本质就是一件事把你希望模型做的事用模型最容易理解的方式结构化地表达清楚。一个生产级的 Prompt 模板至少包含这几个部分[角色设定] 你是一位精通企业制度的知识助手只能基于给定资料作答。 [任务说明] 请回答用户的问题。若资料中没有明确答案请直接说明不知道。 [上下文] 以下是检索到的相关资料 {context} [用户问题] {question} [输出规范] 回答中必须标注引用的资料编号如 [1]禁止编造细节。这套模板背后有几个设计逻辑角色设定限制模型的回答风格任务说明 不知道就直说能显著降低胡编概率上下文区域是留给检索结果的插槽输出规范则是为了后续解析和溯源。这些不是可选项生产环境里每一块都在发挥作用。另外我强烈建议在开发阶段就养成一个好习惯做 Prompt 版本管理。每一次改 Prompt都记录改动内容和对应测试结果。这个习惯能让你后期迭代时少走无数弯路否则你会陷入改了跟没改一样的迷宫。模型参数也不是随便设的。temperature采样温度建议初始设为 0.2 左右越低输出越稳定适合问答类任务越高越有创造性适合写作类任务。max tokens 要控制防止模型一口气输出冗长内容增加成本。这些参数都应该通过配置管理而不是写死在代码里。3.4 评估闭环没有评估的 AI 工程是沙上建房到了这个环节我要强调一个很多新手最容易忽略的事实AI 系统的输出是有概率性的改了 Prompt 或换了模型效果可能变好也可能变坏但没有评估体系你连变好变坏都判断不了。我见过的最常见翻车现场是开发了一个月的 RAG 系统上线用户反馈最近答案变差了团队一脸茫然因为没人记得上一次改动到底动了哪几句话。这种情况的唯一解药就是建立一套哪怕很简陋的评估流程。第一步准备一个小而精的测试集。不需要追求几百上千条一开始 20-30 条覆盖典型场景的问答就够。每条记录包含用户问题、预期答案要点、涉及的资料片段编号。第二步写一个自动化评估脚本。核心指标可以根据任务类型选问答类可以看答案是否包含预期要点和是否忠实于资料生成类可以看文本相似度指标更精细的做法是用一个评估模型来当裁判LLM-as-judge让它按照你制定的评分标准打分。# 一个最简化的评估骨架帮助你理解思路 def evaluate(question, expected, answer): # 检查预期要点是否出现在答案中 hit all(kw in answer for kw in expected[keywords]) # 检查答案是否引用了正确的资料编号 citation_ok expected[source_id] in answer return {hit: hit, citation_ok: citation_ok, pass: hit and citation_ok} # 跑完整个测试集统计通过率 results [evaluate(**case) for case in test_set] pass_rate sum(r[pass] for r in results) / len(results)别小看这 20 条测试集。它能防住绝大多数改了 A 结果 B 坏掉了的回归也是在业务方质疑这系统到底行不行时你能拿出的最硬气的证据。我对所有从零开始的项目都会强调评估集可以小但必须有不带着评估目标去做 AI 工程等于蒙眼开车。提示评估集不是一次性资产要跟着业务演进持续补充。每发现一类新错误就把这类的经典 case 加入测试集。一个月后这套评估集合就是你项目最值钱的部分之一。4. 部署上线才是真正工程的开始4.1 接口封装与鲁棒性设计模型跑通只是开始把链路变成可以被其他系统稳定调用的服务才是工程味道最浓的部分。这一步的重点不是跑通而是在极端情况下依然能给出可用响应。我的标准做法是用 FastAPI 把链路包成一个 HTTP 服务。接口设计上有几个约定俗成的原则输入校验请求体用 Pydantic 模型定义字段类型、必填项、长度限制都明确声明。不要相信任何外部调用方会乖乖按你的文档传参。超时控制大模型调用必须设置超时时间。线上我曾经遇到第三方模型服务变慢请求迟迟不返回把整个服务的线程池都拖垮了。加上合理超时比如 20 秒之后问题立刻缓解。失败重试对瞬时错误网络抖动、限流做一次重试但重试要有退避策略别在对方已经过载时雪上加霜。异常兜底任何环节出问题接口也要返回一个结构化的错误信息而不是 500 一堆堆栈。前端拿到错误后可以提示用户而不是页面直接白屏。流式输出如果面向终端用户强烈建议接口支持流式返回SSE用户在 1 秒内就能看到模型打字体验远好于等 10 秒然后一次性蹦出全部内容。# FastAPI 接口的骨架示例 from fastapi import FastAPI from pydantic import BaseModel, Field app FastAPI() class QueryRequest(BaseModel): question: str Field(..., min_length1, max_length2000) top_k: int Field(5, ge1, le20) app.post(/api/query) async def query(req: QueryRequest): # 这里接上你自己的检索 生成链路 answer run_pipeline(questionreq.question, top_kreq.top_k) return {answer: answer}这一步做好的意义在于你的项目从我本机跑得通升级成了别人也能稳定调用这是工程化和玩具之间的分水岭。4.2 性能与成本缓存、限流与模型分级模型 API 的按量计费让成本第一次如此直接影响架构设计。很多新手上线后不看成本曲线月底一算账直接傻眼。这里分享几个我实测有效的降本组合拳语义缓存把相同或相近的用户问题的答案缓存起来。常见做法是把问题的 embedding 向量存一份新请求来的时候先跟历史问题算相似度相似度超过阈值直接返回缓存答案。对于高频重复的咨询场景缓存命中率能到 50% 以上成本直接砍半。限流控制给接口配了限流策略每个用户每分钟最多 N 次请求。既防恶意外部消耗也防内部误调用。模型分级不同任务用不同规格的模型。比如意图识别、关键词提取这类简单任务用便宜的小模型只有最终答案生成才调用最强的大模型。一套流程下来平均单次调用成本能降一个量级而用户感知几乎没有变化。另外一个常被忽略的性能点是并发管理。对外提供服务的接口内部对模型 API 的调用要控制并发数不要无脑并发。我见过把模型 API 并发配额直接打满导致被限流的案例加个简单的信号量或队列稳定住调用速率反而整体吞吐更健康。4.3 可观测性你必须看得见系统在干什么上线前的最后一块拼图是可观测性。AI 系统的排查难度远高于普通后端服务因为输出不仅取决于代码逻辑还取决于你永远没法完全预知的模型行为。没有观测手段出问题时就只能靠猜。我的最小可观测性方案包含三层结构化日志每次请求在入口生成一个 request_id整条链路的所有日志都带这个 ID。日志里至少记录问题原文、检索到的片段ID和相似度、最终拼接的 Prompt或其摘要、模型返回的原始输出、耗时、token 消耗。这样任何一个用户反馈回答不对你都能通过 request_id 把整个链路重放一遍。性能指标用 Prometheus 之类工具统计接口 QPS、P95 延迟、token 消耗量、模型 API 的错误率。设好告警延迟或错误率一旦异常立刻触发。离线抽样分析定期抽样一部分历史请求做质量复检确认系统在真实流量下依然保持可用水平。这一步能弥补在线评估覆盖不到的长尾场景。做完这三层遇到线上问题你将不再是无头苍蝇而是可以像查普通后端 bug 一样一步步锁定是哪一环的锅。5. 让系统活过三个月版本、回归与迭代5.1 Prompt 和数据都是要进版本库的代码有 Git 管着但我在大量项目里发现Prompt 模板和数据集往往是活在 Excel 和聊天记录里的。这绝对是隐蔽的技术债而且一定会还。我现在的要求很简单Prompt 模板以文件形式放进 Git 仓库跟代码一起走 Code Review测试集用 JSON 或 YAML 文件存好同样入库到独立目录任何改动导致测试集评估指标变化的必须记录在提交信息里。这套做法的直接收益是当你发现上周那个版本的效果其实更好时只需要git checkout对应的版本就能一键复现而不是从聊天记录里翻一个也许已经失效的草稿。5.2 回归测试比模型精度更能保命大多数 AI 项目不会一次性上线完美系统而是持续迭代码、调 Prompt、换模型。每次改动都潜藏着回归风险你为了修 A 类问题改了 Prompt结果 B 类问题的表现突然变差了。解决回归风险的方式就是把评估脚本接入持续集成流程。代码仓库里加一个 task每次有改动就自动跑一遍评估集指标通过率跌过阈值就不允许合并。这相当于给 AI 系统装上了一条安全带。我第一次执行这个策略时恰好抓住了自己前几天的一处优化带来的回退改了一个 Prompt 措辞整体通过率从 82% 掉到了 70%但当时靠肉眼试用完全没察觉。有了回归测试后这类问题在第一时间就会被机器拦住而不是等用户来骂。注意回归测试的评估集要覆盖历史所有修过的问题类型而不只是当前最满意的样例。否则你只是在反复验证已经能答好的题真正的问题反而漏掉了。5.3 给未来留后路模块替换的抽象边界最后聊一点架构层面的经验。AI 领域的技术迭代快得离谱今天用得顺手的模型下个月可能就被新版本碾压今天用的向量库明天可能出现更合适的替代品。如果你的代码把这些组件全焊死了每次替换都是大工程。我的习惯是给关键组件画一条清晰的抽象边界数据加载、向量化、检索、生成、评估各自封装成独立模块模块之间用简单的接口协议通信。这样换模型时只需要改生成模块的内部实现其余全不用动换向量库时只需要保证检索模块对外的接口签名不变。举个例子我把调用模型封装成一个generate()函数内部可以用 A 厂商的 SDK也可以换成 B 厂商的请求但只要参数Prompt、模型名、temperature和返回文本、token 数保持一致外部完全无感。实测在没有预料到的情况下这个设计帮我省了大量替换成本。6. 零基础入门的学习路线与心态调整6.1 一条我验证过多次的三个月路线如果你完全从零开始我的建议是按周为单位推进。路线太松容易流失太紧容易劝退。以下是参考节奏第 1-2 周用 Python 调通一个大模型 API写几个简单的问答、摘要脚本熟悉输入一段文本 - 得到一段文本的基本流程学习数据清洗与文本处理基础。第 3-4 周搭一条最小 RAG 链路文档切分、向量化、向量检索、拼 Prompt、生成回答。不需要网络架构本地脚本跑通即可。第 5-6 周做一个 20 条 QA 的小测试集写一个自动化评估脚本开始量化你的系统表现尝试改进检索或 Prompt观察评估指标的变化。第 7-8 周把链路用 FastAPI 包成 HTTP 接口加上超时、重试、日志学会本地启动服务并在 Postman 里调通。第 9-10 周部署到一台服务器上接上正式数据源配置基础监控处理数据量变大之后的检索性能问题。第 11-12 周回归测试接入持续集成整理全部文档复盘整个过程中的失败 case形成自己的迭代检查清单。这个节奏不是绝对最优但胜在每个阶段都有看得见的产出不容易让人中途放弃。6.2 别踩这五个坑顺着前面的经验我再把新手最容易掉进去的五个坑集中说一遍沉迷原理不肯动手AI 工程是实践学科看十篇讲 RAG 原理的文章不如亲手跑通一次链路。原理可以在踩坑中学先动起来。没有评估就开始优化不量化效果地调 Prompt本质是在掷骰子。再忙也要先留出半天搭一个最小评估集。盲目追新框架技术更新换代很快但底层逻辑数据、检索、生成、评估很稳定。框架只是工具别让换工具变成你的主线任务。忽视成本和延迟Demo 阶段随便调用无所谓一旦要考虑上线就要在每个环节问一句这步值得花这么多 token 吗能缓存吗不写文档不记日志AI 系统的状态和信息流比传统后端复杂得多靠脑子记很快会崩溃。宁可代码写得糙一点也要把观测和记录做好。6.3 说点工程之外的大实话做了这么多年我越来越觉得 AI 工程的内核其实是传统软件工程和数据工程的老规矩——模块化、可测试、可观测、可维护——只不过披上了一层模型输出不可完全确定的新外衣。那些能在 AI 工程里走得远的人未必是算法最强的人但一定是工程习惯极好的人他们重视数据、拥抱评估、敬畏线上。从我自己带新人的经验来看从零到一跑通一条链路最多只需要两三个月真正拉开差距的是从一到十的那个阶段当你的系统开始承载真实用户的真实问题时工程这两个字的重量才会完全显现。希望这篇文章能帮你把那条最初的路子走直一些省下来的时间都值得用在打磨真正属于自己的那条链路上。