最近“AI engineering”这个词几乎到处都能看到。很多人以为它就是把几个大模型API串起来跑个聊天机器人就算入门了。我自己从纯后端转过来踩了不少坑之后才意识到AI工程的核心不是“用哪个模型”而是“怎么把一个模型能力打磨成稳定、可维护、能持续迭代的真实系统”。这篇内容我想聊聊真正“from scratch”的路径。不是抄一段代码就算会而是从知识地基、第一个项目、模型选型一直到生产环境里那些没人提醒你的坑完整走一遍。如果你是后端工程师、学生或者刚接触AI想系统入门的开发者这篇文章应该能帮你省下我当初浪费的那几个月。1. AI工程不是“调API”是“交付系统”先建立全局视角1.1 我理解的AI工程是什么先给一个我自己的定义AI工程是研究如何用现有模型和工具在真实业务场景里持续交付、运行、迭代AI能力的一整套方法。它不完全等于机器学习也不等于软件工程而是两者的交集还额外带上了一层“模型行为不可完全预测”的特殊性。传统的后端开发里函数输入和输出基本可控你写一个接口传参进去返回结果是可以预期的。AI工程不一样你调用的模型本身是一个概率系统同样的输入可能每次输出都不同同一个Prompt不同措辞结果可能天差地别。这就决定了它不能用传统的“写完就完事”的思路来交付。我做过一张对比表自己常用它来理解AI工程和几个相邻领域的差异维度传统后端机器学习/数据科学AI工程本文语境核心对象业务逻辑、数据流模型训练、指标优化模型在业务系统里的稳定运行主要输出接口、系统、功能模型文件、训练报告可运行、可评估、可迭代的产品能力风险来源逻辑bug、数据错误数据偏差、过拟合模型漂移、Prompt失效、成本失控关键技能架构、编码、运维数学、算法、实验设计工程化产品化模型理解说白一点研究模型的人目标是让模型在排行榜上更高做AI工程的人目标是让模型在公司业务里好用、便宜、稳定、出了问题能快速定位。这两个目标经常是冲突的比如榜单上最强的模型不见得在你业务里成本可控。1.2 从零到一要看懂的四层系统结构我第一次搭AI应用的时候脑子里只有“调用模型”这一个动作结果项目一上线就各种问题数据格式不对、回答乱编、一次请求几十块钱、用户反馈无法追溯。后来我把AI系统拆成四层看整个思路就清晰了。第一层是模型层包括基座模型的选择和调用方式是你能力的上限。第二层是数据层包括业务数据怎么采集、清洗、切分、存储、检索这层决定了模型能拿到什么信息。第三层是应用层包括Prompt设计、业务逻辑编排、用户交互、权限和校验。第四层是评测运维层包括离线评估、线上监控、日志分析、成本追踪、模型版本更新。这四层不是从上往下做完就结束而是一个循环先是数据准备然后选模型做应用上线之后用评测运维得到反馈反馈再改变数据和应用设计。1.3 适合谁、需要什么前置基础以我自己的带人经验来看AI工程的门槛没有想象中那么高但也没有低到“零基础也能当工程师”的程度。最适合开始的人是有基本编程能力、有服务端开发常识、愿意动手折腾的开发者。Python要会用命令行要能操作数据库和接口的基本概念要有。如果完全没有编程基础也不是不能学但建议先花2-3个月把Python基础、数据结构、面向对象这些补上。我见过最理想的状态是懂一点后端哪怕是写过学校项目、做过毕设然后带着具体业务问题来学AI工程。带着一个要解决的实际问题去学比照着教程敲代码效果好十倍。2. 地基速成指南用“够用就好”原则补足知识缺口2.1 编程和数学不需要成为算法高手做AI工程到底要学多深的数学我的答案是够用就好别被吓跑。你不是在推导Transformer的数学证明你是在用现成的模型解决实际问题。编程方面Python是比较重要的但也不是要你成为语言专家。需要熟练的是类与对象、装饰器、列表推导、异常处理、虚拟环境、requests库调用接口、用JSON处理数据。这些每天都会用到。再加一个可选加分项async/await因为AI接口调用比较慢异步并发在真实系统里几乎必用。数学方面优先级从高到低概率和统计基础知道什么是采样分布、置信区间、标准差因为你要理解“模型输出有随机性”这件事要理解评估指标为什么要对多个样本取均值。线性代数基础知道向量是什么、点积是什么、矩阵乘是什么因为向量检索和Embedding的概念都是从这来的。不需要会手算矩阵逆但最好能理解“向量相似度”这个几何直觉。微积分绕过除非你要做模型训练或者读论文否则日常AI工程里基本用不到梯度更新的手算推导。2.2 大模型最小原理用“图书馆管理员”类比来理解一个没有大模型背景的人做AI工程总想先把Transformer论文读透这是很大的误区。当年我也差点陷进去。读了三天论文只会画注意力机制的图但对自己要做的项目毫无帮助。真正需要在工程层理解的是这几个概念Token模型读写的基本单位。中文里一个token不严格等于一个字但对于预算和长度管理你要大致了解“多少token大约对应多少字”。实际经验1个中文汉字大约1.5-2个token1个英文单词大约1-1.3个token。这个估算能力在做成本控制的时候非常关键。Context Window上下文窗口模型一次输入能同时容纳的token上限。这不是“给它更多文字它答得更好”而是“超出的内容它根本看不见”。工程上你要负责控制送入上下文的量。Embedding向量嵌入把文字变成一串数字向量语义相近的内容向量距离更近。这套机制很像图书馆管理员的分类系统每本书被分到书架上的位置都依据书籍内容主题的相似程度。把书按内容语义摆放好后读者说“我想找讲编程入门的书”管理员就在附近架子上来回比较挑出最匹配的一批书推荐给读者。大模型本身也类似一个“很会说话的管理员”你有检索到的一堆参考段落加上用户问题模型负责组织成流畅且信息正确的回答。这里的关键点很反直觉——模型能记住的内容是被Context Window限制的不是“训练私藏”出来的。很多人误以为上传一次资料它就永久记住了实际不是。你不把资料放在请求里它就“忘记”了。2.3 必须懂的工程基础设施一次性把坑补齐AI工程里模型只是系统一部分你是靠下面这些工程设施来交付的Linux基础能登录服务器、装环境、看日志、用crontab做定时任务。容器化Docker把应用和依赖打包起来尤其在做本地模型部署的时候非常关键。数据库和缓存至少知道关系型数据库怎么存数据、Redis怎么当缓存和队列用。向量数据库虽然是新东西但它的底层思想和传统数据库索引是一脉相承的先把传统那块补明白。API设计基础的RESTful接口设计、鉴权、限流、超时。一个AI应用本质还是把你封装的模型能力通过HTTP暴露给前端。云服务基础对象存储S3协议、函数计算/Serverless、GPU服务器租用。这些是部署的兜底选项。我不建议一开始就背概念更好的方式是边做边补每遇到一个不认识的工程名词花半小时查一下亲手在云服务上开通一次服务。用一次比读十篇文章都记得牢。2.4 我推荐的学习顺序与时间盒分享一下我后来教新人的顺序大概4到6周可以完成基础段第1周Python补齐 Linux命令 Git。每天花两三小时做一个小爬虫或者数据处理脚本巩固。第2周用提示词调用一个大模型API写一个命令行版聊天脚本。顺便搞懂REST API调用、Key配置、环境变量、Token计数。第3周学习Embedding和向量检索本地装一个轻量向量数据库手动实现一个“给一批文档建索引然后按问题搜相关段落”的脚本。第4周把第2周和第3周的东西串起来用无框架的方式实现一个最简RAG系统。这个很关键后面细说。第5-6周学习部署和评估把系统扔到云服务器上跑自动评测集合记录延迟和成本。这个顺序的核心是先有一行能运行的代码再往上叠工程能力。不要先学三个月的理论再动手。3. 从零搭建一个能用的文档问答系统完整实战3.1 为什么我推荐“文档问答”作为第一个项目市面上有很多AI项目的练手Demo聊天机器人、摘要工具、代码助手我为什么强推文档问答因为它的链路非常完整覆盖了AI工程的所有核心环节数据解析、切块、嵌入、检索、生成、评估、迭代。而且它具备业务价值——公司内部文档多员工找资料难客服知识库散落各处学生看资料抓不住重点。你把它做好了是能真正用的。它还有天然的评估方法你可以准备一些“问题-答案”对来打分不像纯聊天那样很难评价回答好坏。我自己带的实习生给他三个项目选最后选了文档问答六周后他搭出的系统直接被他学校同学用起来了。这就是它的优势链路完整、需求真实、反馈直接。3.2 系统拆解与总体流程一个最小可用的文档问答系统按数据流向拆成五个环节文档加载读PDF、Markdown、TXT、Word等提取纯文本。文本切块把长文档按照一定长度切成分块并保留元数据来源、页码。这一步直接决定检索质量。向量化存储每个分块调用Embedding接口生成向量写入向量库。检索用户提问时把问题转成向量在库里找最相似的K个分块。生成回答把“问题 检索到的分块 系统提示词”拼给大模型生成最终答案。3.3 可运行的代码骨架无框架优先我建议你第一个版本不要用LangChain、LlamaIndex这类框架直接用最原始的代码把流程跑通。用框架的问题在于调试时你分不清是框架的封装问题还是你自己的理解问题。原生代码50行就能实现逻辑一目了然。这里我写一个极简版流程用伪代码和Python片段混写方便你理解整体结构import openai from openai import OpenAI client OpenAI() # 1. 读取文档 with open(company_handbook.md, r, encodingutf-8) as f: text f.read() # 2. 简单切块按固定长度约500个字符 def split_text(text, chunk_size500, overlap50): chunks [] for i in range(0, len(text), chunk_size - overlap): chunks.append(text[i : i chunk_size]) return chunks chunks split_text(text) # 3. 批量生成向量 def embed_texts(texts): resp client.embeddings.create( modeltext-embedding-3-small, inputtexts, ) return [item.embedding for item in resp.data] vectors embed_texts(chunks) # 此处省略把chunks和vectors写入向量库 # 4. 检索计算余弦相似度 import numpy as np def search(query, k4): q_vector embed_texts([query])[0] scores [] for v in vectors: # 归一化之后点积就是余弦相似度 score np.dot(q_vector, v) / ( np.linalg.norm(q_vector) * np.linalg.norm(v) ) scores.append(score) top_indices np.argsort(scores)[-k:][::-1] return [chunks[i] for i in top_indices] # 5. 生成回答 def answer_question(question): related search(question) context \n---\n.join(related) prompt f你是公司内部助理。只能依据下面的资料回答不要编造。 资料 {context} 问题{question} 回答 resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], ) return resp.choices[0].message.content这就是一个能跑起来的骨架几百行以内搞定。跑通它你对“数据链路”这件事的理解会直接超过那些只会调用ChatGPT网页的人。3.4 最小评估闭环别凭感觉判断好坏很多人的第一个RAG项目死在同一个地方没有评估系统全靠自己问几个问题感觉“还行”。上线后换个场景立刻翻车。最小可行的评估方案是准备30-50条真实问答对。从文档里提取也可以找真实同事帮你提问尽可能贴近实际使用。对每个问题跑系统记录三件事检索到的内容是否正确、最终回答是否正确、是否引用了原文。用三个指标打分检索命中率正确答案是否出现在召回的top4里、回答正确率人工判断回答是否准确、幻觉率回答是否含有资料中没有的内容。有了这三项你改Prompt、切块策略、Embedding模型时才有依据。否则每一次改动都是玄学。我会在后面章节详细展开评估闭环的搭建方法。3.5 跑通后立刻要做的三件实事第一个版本跑通后你大概率会觉得“就这”——对因为它还不算一个产品。要让它向真实应用靠拢马上做三件事第一把元数据加进检索结果展示。每块资料带上来源文件名和页码回答里出现“根据《入职手册》第3页”才有说服力用户才会信任你的系统。第二做好用户输入的边界。禁止用户输入超长内容限制单用户频率把敏感词过滤加上。AI应用是公开服务不做边界保护上线当天就有风险。第三加上请求日志和回答追踪。存下每个问题的检索链路、模型输出、耗时和费用预估。这里没有它后面所有优化和问题排查都寸步难行。4. 模型选型和提示词工程从“有输出”到“答得对”4.1 基座模型怎么选闭源API还是开源本地很多人上来就问“哪个最好”其实“最好”没有意义“在限制条件下最合适”才有意义。我的分类判断标准有这么几项维度闭源API如GPT、Claude、国内商用API开源本地部署如Qwen、Llama、DeepSeek开源版效果上限通常较高省心取决于硬件、量化、微调单次成本按token计费长期累积可观GPU和电费规模化后成本平滑延迟网络往返排队本地推理可控可以优化数据隐私数据出域需评估合规数据留在自己服务器合规性好调试难度低方便快速试错高部署、配置、内存管理自定义程度低只能改Prompt校准高可以微调和换采样策略我的经验项目第一版优先用效果好的闭源API先验证业务逻辑和用户体验。如果用户反馈好但成本高再考虑用开源模型替换推理层。工程上这叫“用钱买时间”——第一版最怕的不是贵是跑不起来。4.2 提示词工程的三个层次提示词工程不是靠“魔法咒语”它有规律。我把它分成三个层次第一层任务指令角色约束。告诉模型你是谁、要干什么、输出什么格式。这是最低要求。第二层加入检索上下文和示例Few-shot。给模型一到三个示例它能立刻学会你要的格式和深度。工程里最常用的稳定技巧是给一个“好答案”示例再给一个“错误答案”示例让模型模仿前者、避开后者。第三层结构化输出和工具调用。让模型输出JSON字符串或者使用函数调用Function Calling来严格约束它的动作边界。下面是一个结构化输出实例系统你是文档问答助手。只允许输出JSON {answer: 回答内容, source: [来源文件], confidence: 0到1} 用户根据现有资料我们公司的年假政策是什么 回答模型返回的是一个可被程序解析的JSON你就能把“回答”“来源”“自信度”直接写进数据库做展示和监控而不是在一个长段落里做字符串截取。实际工程里强烈推荐所有模型调用都输出结构化数据哪怕你用了强力的提示词也在程序里做好解析兜底。4.3 微调的正确位置先调提示词和RAG再谈微调这里要敲一个重点90%的应用场景不该一上来就微调模型。微调是最后的手段不是起步手段。微调解决的是“模型通用能力足够但不熟悉特定领域术语和输出风格”的问题。而大多数系统里的回答不准确根源根本不是模型不懂而是检索到的上下文不对或Prompt没把约束说清楚。你先对照评估闭环看错误类型如果是检索质量导致的错误去调数据切块、重排而不是微调如果是格式不符改提示词如果所有环节都做了仍然不对这时候再认真评估微调的投入产出比。微调本身也不是万灵丹它需要高质量标注数据、训练算力、更复杂的迭代管理。我见过一个团队花了两周微调一个开源模型效果比Prompt优化只提升了百分之几还引入了新问题。所以我的建议是越往上层找问题越节省成本调数据的成本远低于调模型的成本。5. 从Demo到生产级性能、成本、稳定性和可观测性5.1 性能与成本缓存、并发、流式一个都不能少一个AI应用的性能瓶颈通常不在服务器并发而在模型推理的耗时。一次大模型调用动辄几秒甚至几十秒所以优化方向非常明确。先加语义缓存。把用户的问句转成Embedding和过去的问句做相似度匹配如果命中高相似度的问题直接把上次的答案返回不再调用模型。这一步通常能省30%-50%的调用量。实际实现时可以设置一个相似度阈值比如0.95以上命中缓存。再加流式输出。把模型吐字过程像打字机一样实时发给前端用户的首字延迟从3秒降到200毫秒体感提升巨大。后端用SSEServer-Sent Events协议前端用EventSource实现成本很低。最后是并发控制。用Redis或MQ做令牌桶限流防止单个用户发动大量请求打爆账号配额。工程上有句话叫“没有限流的AI应用就像没有刹车的车”。成本估算给个实例假设你的应用每天处理5000个请求每请求平均送进模型2000 token输出500 token。用某商用API的粗略费率2000输入token约人民币几分钱整体算下来一天几十元。如果要降到一天十元就得靠缓存、更短的工具链、或者换更便宜的模型分级。5.2 稳定性和兜底策略假设模型一定会出错生产级系统有一个基本假设外部模型随时可能超时、拒绝服务、乱回答。所有代码都要围绕这个假设设计。设置超时时间每层API调用都给超时上限比如1分钟超时后自动走备份方案。做自动重试对限流错误和临时网络错误按指数退避重试最多3次。建降级方案主模型失败时切换到备用模型或提示用户“稍后再试”。一个核心功能不能绑死单一供应商。加模型输出校验如果要求模型输出JSON但解析失败回调一次重新格式化工序。程序里永远不要直接假设模型输出是合法JSON。5.3 上线前必做评估与回测避开几个致命陷阱上线前我强烈建议做一次“离回归测试”。把离线问答集在每一次系统改动后完整跑一遍记录指标变化。改动Prompt、调整切块参数、换Embedding模型都要重新跑看是否正确和是否引入退化。有两个特别容易被忽略的陷阱第一是信息泄漏。如果你准备测试问答对时是从和训练文档相同的内容里提取的那测出来的成绩会虚高。尤其当文档本身就在模型训练数据里出现过时哪怕检索环节没用上相关内容模型也可能“没有资料也答得出来”。这会掩盖检索链路的问题。第二是测试集太单一。只测“找得到答案”的正样本不测“文档里根本没有答案”的负样本。真实用户经常问库里没有的内容系统要学会说“不了解”而不是硬编。评估集里至少要加30%的负样本。5.4 可观测性从日志到trace到评估分数的闭环生产环境里AI应用比普通应用难排查。因为传统后端报错可以看堆栈而AI应用的“报错”通常是“答错话”词法上完全正常语义上严重偏离。我的做法是建立完整链路记录每次请求把“原始问题、判断后的意图、检索到的分块、送入模型的完整Prompt、模型返回结果、延迟、成本、版本号”记录到日志系统。一旦出现用户反馈或评估准确率下降就从这些问题日志出发重放链路看哪个环节出了问题。如果有能力还可以给每个请求分配一个trace_id贯穿客户端、应用、模型层配合现有的日志平台ELK等做统一检索。这一套体系不需要一开始就做很重先从“每次请求存一条JSON日志”开始就可以。评估闭环的终点是定时跑离线测试集并生成趋势图。准确率掉了一定第一时间知道而不是等用户投诉了才知道。这是AI工程和“随手写个脚本调模型”最本质的区别之一。6. 从零自学AI工程的踩坑实录我亲历的几件事6.1 坑一沉迷刷模型论文忽略工程落地刚入行的时候我花了很多时间读模型论文和层架构甚至能画清楚多头注意力机制的计算流程。听起来很专业但用处不大。真正催熟能力的是把一个失败的Demo修到“能给别人用”把一个慢到卡死的检索系统调到“响应低于1秒”把一次事故排查到“日志里每一行都看得懂”。工程能力的增长来自一个又一个系统上的真实问题而不是看论文心得。6.2 坑二不看数据质量直接把“垃圾”灌进系统我做过一个文档问答系统上线后回答质量惨不忍睹。我一开始以为是模型问题或者Prompt问题改了一整天没效果。后来把文档内容打印出来仔细看——大量表格被抽取成混乱文本、PDF中编码错误导致的乱码、重复段落占据大片空间。系统检索到的所谓“相关段落”根本是不可读的脏数据。那次之后我养成了习惯项目开始前至少花20%时间做数据清洗和分析。先随机打印几十条切块后的文本看一遍确认干净再进Embedding。数据质量是整个系统质量的下限。6.3 坑三一上来就搭全家桶框架我第二版RAG系统用了某全家桶框架配置了一堆组件写的时候感觉很专业但出问题之后排查了半天找不出是哪个环节的锅。后来干脆把框架拆掉用原生代码重写核心链路瞬间清爽。我现在的态度是能用标准库和云服务解决的优先原生处理确实需要框架的场景也要分模块引入并且把每一层的日志和接口都记录清楚。框架是用来提高效率的不是用来掩盖理解空缺的。先理解流程再选框架永远别倒过来。6.4 坑四没有评估体系就反复改需求有一段时间合作伙伴给了一堆新需求今天说“回答要更像人话”明天说“要有正式感”我每次都临时调Prompt。结果每次调整只能让一部分问题变好另一部分变差全靠个人主观判断。后来把评估集建立起来每次改动跑一遍分数才能可视化地回答“这个改法让整体指标提升了三个百分点还是倒退了两个百分点”。评估体系是AI工程的“测试用例”。你没有它就无法证明自己在变好也无从定位问题。6.5 踩过几次坑之后我给新人的几条建议挑三条最核心的第一个项目一定要小文档问答这种规模就够了。不要一上来做多Agent复杂编排、全自动流水线、跨系统集成。小系统里把每个环节吃透后续做复杂项目才不会心虚。始终把“数据-评估-迭代”作为主线流程永远是先处理数据再定义评估再迭代系统。模型只是其中一个组件不是全部。建立自己的“AI工程工具箱”把常用的切块函数、评估脚本、缓存模块、request重试逻辑沉淀成自己的代码片段库。以后做新项目会发现从零开始的时间在指数级减少。我自己到现在还保留着最初那个几百行的原始RAG脚本随时回去看一下能提醒自己AI工程的核心不是热闹的新技术而是扎实地把数据送进去、把答案送出来、把系统守住。从零开始的确要花不少时间但每一步都是实打实地长在自己身上的能力。这套路走完之后你面对任何新模型、新框架都不会再焦虑——因为底层的工程思维是不变的。
