先聊个很多人都会问的问题AI 工程AI Engineering到底是不是个“新瓶装旧酒”的概念我自己的判断是它不是。早几年我们讲机器学习、深度学习重心大多放在模型训练——调参、刷榜谁 AUC 高谁厉害。但到了今天一个模型能不能真正落地、能不能持续稳定地服务业务靠的远不只是训练。数据怎么管、特征怎么算、模型怎么部署、上线之后怎么监控、效果变差了怎么捞回来这些环节加在一起才是完整闭环。而这个整体能力就是 AI 工程。几年前没有人给你规划好这条路网上资料要么偏算法理论要么偏纯后端能把这整条链路串起来讲的极少。这个“ai-engineering-from-scratch”要解决的就是这个痛点从头梳理 AI 工程到底学什么、做什么、怎么一步步做成适合刚入门想走 AI 工程方向的同学也适合已经在做后端或算法、想补齐工程能力的人。下文就是我从零到一完整跑通这个体系的实战笔记纯干货不绕弯。1. AI 工程到底是什么为什么值得从头搭建1.1 先搞清楚 AI 工程和传统软件工程的区别很多人第一次听说 AI 工程下意识会把它理解成“会写 Python 调模型”。如果只是这样那和算法工程师有什么区别行业里现在普遍接受的一种定义是AI 工程是面向 AI 应用的软件工程实践它把模型当作系统的一个组件而不是全部。换句话说AI 工程师的职责是让 AI 能力以稳定、可维护、可扩展的方式嵌入业务。对比传统软件工程最核心的区别有两个。第一传统软件的逻辑是确定性优先——输入 A输出 B行为可预期。模型的逻辑是概率性的——同一个 prompt 或者同一批特征结果可能有波动。所以工程上必须增加一层兜底和校验比如阈值判断、降级方案、结果合理性检查。第二传统软件的生命周期里测试数据和真实数据分布通常一致模型应用则经常出现“离线效果好、线上效果崩”的窘境。数据分布漂移这个变量传统软件工程师几乎不需要考虑但对 AI 工程来说是家常便饭。所以 AI 工程不是算法工程师的“下位替代”也不是普通后端的“加个模型接口”。它是一个更综合的位置既要懂模型的基本工作原理又得具备软件工程的纪律性还得有数据敏感度。这也是为什么业界常说“AI 工程师是 transformer 时代的全栈工程师”——不是说你什么都会而是说你需要具备跨层协调能力。1.2 从零搭建的必要性不经历底层谈何上层这轮大模型浪潮带来了很多“低门槛”工具比如封装好的 SDK、托管服务、微调平台。我举双手赞成用工具提效但我强烈不建议一上来就直接怼高层服务。理由很简单你不亲手跑一遍训练、评估、部署、监控的完整流程你根本不知道哪个环节会出问题出了问题也不知道该看哪里。举个很典型的例子。有人用了托管的模型 API 做问答应用线上反馈偶尔出现胡说八道的情况。他第一反应是换个更强的模型结果换了还是有问题。后来排查才发现问题出在他处理用户输入时把一些关键上下文截断了模型根本没拿到足够信息。这个错如果他自己写过完整的 RAG 链路一眼就能定位但如果他只接触过 API 调用就很容易在“模型不行”的错误方向上反复内耗。这就是 from scratch 的核心价值不是为了复古是为了建立“故障直觉”。你亲手写过数据处理脚本才知道脏数据长什么样自己部署过推理服务才知道延迟瓶颈往往卡在序列化和网络传输上自己写过评估脚本才明白人工评测在真实场景里有多不可靠。这些认知是任何工具替代不了的。2. 核心能力地图先画清楚要学什么再动手2.1 技术栈全景从底到顶的六个层次真要系统学习 AI 工程我建议把它拆成六层来看每一层都有明确的交付物和验收标准。这样学起来不会迷失方向因为每一层都可以单独验证。第一层是编程基础与工程素养以 Python 为主必须熟悉面向对象、类型注解、虚拟环境、git 工作流。第二层是数学与机器学习基础重点不是推导公式而是要理解损失函数、梯度下降、过拟合、评估指标这些概念背后的直觉。第三层是深度学习框架PyTorch 为主要做到能自己写训练循环、自定义数据集、断点续训。第四层是模型应用与微调包括预训练模型的加载、prompt 工程、指令微调、参数高效微调。第五层是推理与部署包括模型量化、服务化、容器化、GPU 资源管理。第六层是数据与评估体系包括数据清洗、标注规范、离线评估、线上监控。很多人会问数学到底要学到什么程度我的建议是你不需要会推导 transformer 的全部公式但必须理解以下几个概念向量与矩阵乘法做 attention 时能跟上、概率分布理解困惑度和采样、损失函数与梯度理解训练和过拟合、以及统计显著性理解 A/B 实验。到这一步就够支撑任何工程决策。2.2 关键思维转变从“模型优先”到“系统优先”真正动手做项目之后我发现初学者最容易卡住的不是技术而是思维。算法背景的人容易困在“我要把模型效果调到最好”这个单点目标里后端背景的人容易困在“接口能用就行”的功能交付里。AI 工程要求的是一种系统思维你需要在效果、成本、延迟、可维护性之间做权衡。举个真实例子。在公司做智能客服的过程中我们评估过两个方案一个是直接调用商用大模型 APIanswer 质量高但每次调用成本高延迟波动大另一个是用小模型加本地知识库answer 质量略低但成本几乎为零延迟稳定在 100ms 内。单看模型效果方案一完胜但放到真实业务里客服系统日均调用量几十万次成本差是数量级的而且延迟一高用户立刻感知到页面卡顿。最终我们选了方案二再用 prompt 优化和意图识别兜底把质量差距压缩到可接受范围。这就是“系统优先”的典型决策过程。在你的第一个项目里就要有意识地去记录和权衡这类指标而不是只盯着 accuracy 或者 BLEU。这个习惯越早建立后面做真实项目时越不吃亏。3. 从零到一实操搭建一个完整的 AI 工程小项目3.1 项目选型为什么是“本地知识库问答”前面讲了一堆理念下面我们用一个小项目把这些串起来构建一个基于本地知识库的问答系统。这个项目非常适合入门原因有三个。第一它覆盖了完整链路——数据处理、向量化、检索、模型生成、服务封装、评估一个都不少。第二它不需要昂贵资源本地 CPU 也能跑。第三它非常贴近企业真实需求你做完之后能直接讲出这个故事的价值。整体架构分成五块知识库文档解析、文本切分、向量化与存储、检索、生成回答。对应的技术栈我分别选了python-docx 和 pypdf 做文档解析RecursiveCharacterTextSplitter 做文本切分text2vec-base-chinese 或 bge-small-zh 做向量化FAISS 做向量存储和检索最后用 ChatGLM 或 Qwen 等开源模型做生成。你可能会问为什么不上 RAG 框架比如 LangChain、LlamaIndex不是不能而是我先建议你手工过一遍。手写过一遍之后你才能深刻理解哪些步骤耗时、哪些参数影响大、哪些环节容易出问题。之后再上框架你才算是在用框架而不是被框架用。3.2 步骤一文档解析与文本切分第一步是准备几份产品说明文档比如把公司的某产品手册导出成 PDF 和 Word 两种格式。这时候你立刻会遇到第一个工程问题PDF 解析出来的文本经常带乱码、多余换行和页码信息。我的处理流程是这样先写一个解析函数从不同文件类型抽取纯文本再写一个清洗函数统一做去特殊符号、合并断行、去空白字符最后打印前 500 字符做目检。注意这一步千万不能省因为后续文本切分和向量化的质量完全取决于这一步。文本切分是个容易被忽略但极其关键的环节。切太短语义不完整检索时噪声很大切太长向量表示被稀释而且超出 embedding 模型的最大输入长度。实践经验是先用 200 到 500 字作为初始窗口大小重叠 50 到 100 字。这里的“重叠”是为了保证跨段落的语义不断裂。修改切分参数之后一定要抽样检查切分结果我在实际项目里发现过切出来的文本是一半表格一半正文的情况这种质量是没法检索的。3.3 步骤二向量化与检索实现接下来是向量化。小规模场景直接用 CPU 跑 text2vec 或者 bge 就够。关键点有三个第一模型要统一查询和文档必须用同一个 embedding 模型否则向量空间不一致第二文本要归一化超长文本截断、空文本过滤第三向量要归一化余弦相似度才能正确计算。存储我建议先用 FAISS本地文件存储即可。你只存两样东西原始文本和向量。入库前还要维护一个 id 映射方便后续检索返回原文本。检索逻辑看起来简单——对 query 做向量化然后查 top-k——但实际有几个坑。第一个坑是混合检索单靠向量检索遇到专业术语或缩写时容易召回不准确。实操解法是叠加 BM25 关键词检索用加权融合的方式综合排序。第二个坑是重排序rerank初筛 top 50再精排成 top 5效果提升非常明显。第三个坑是阈值过滤即使相关性分数不高系统也会硬返回结果导致答非所问。正确做法是设定一个最低相似度阈值低于阈值就返回“知识库中未找到相关信息”。3.4 步骤三生成回答与 Prompt 设计生成阶段的关键是写好系统提示词system prompt。这里的经验法则是先给角色定位再给任务约束再给知识上下文最后给回答格式。以一个实际模板为例我的提示词是“你是企业智能助理。请只依据提供的知识片段回答用户问题每句话都需要有依据如果知识片段中不含所需信息请直接说明不知道不要编造。回答控制在 5 条要点以内。知识片段如下xxx。用户问题xxx”。这个模板里有几个值得注意的细节。第一“每句话都需要有依据”这句话能显著减少幻觉因为模型被要求对自己生成的内容进行隐含的“溯源”检查。第二“不要编造”比“如实回答”更直接行为约束更明确。第三限制答案长度可以避免模型堆砌冗长文本。第四把知识片段放在用户问题之前让注意力机制在推理时更聚焦于知识内容。这些都是低成本高收益的优化建议直接抄。3.5 步骤四把服务封装成可调用接口一个可交付的系统最终要变成服务。我选择的是 FastAPI理由很简单自带 OpenAPI 文档、异步支持、Pydantic 校验、部署方便。你需要构建两个接口一个负责写入知识数据入库一个负责查询问答query 进来、answer 出去。接口设计有几个工程细节。第一个是统一响应结构比如 {“code”: 0, “data”: {...}}不要让前端同学猜你的字段。第二个是超时控制模型推理可能很慢必须设置合理的请求超时避免连接堆积。第三个是并发控制本地小模型在同一时间只能处理少量请求可以用 Semaphore 限制并发数收到超过负荷的请求时直接返回 503 提示稍后重试而不是拖死进程。我在这步踩过一个很深的坑第一次部署用的是同步阻塞方式结果两个人同时提问时第二个人硬生生等了 30 秒。理论上模型推理本来就慢但是用异步代理把模型推理放到一个线程池里之后至少能让其他请求先响应起来体感好了很多。这个优化很小但是系统稳定性的关键。4. 评估体系你做的系统好不好要用数据说话4.1 离线评估别只看准确率要看细粒度很多初学者做 RAG 系统评估的时候只会看“几道题答对了几道”然后报告一个准确率。这在真实项目里远远不够。我建议建立三套评估维度检索质量、生成质量、端到端质量。检索质量用 Recallk 和 MRR。简单理解就是正确答案是否出现在检索返回的前 k 条里排得靠不靠前这个指标能独立验证你的 embedding 选择和切分策略。生成质量用 faithfulness 和 answer relevance。Faithfulness 检查生成内容是否有知识库依据相关性检查回答是否契合问题。这两个指标在生成式模型上比准确率更有意义因为它们能抓住“答非所问”和“胡编乱造”这两类高频问题。最实用的做法是准备 50 条覆盖不同难度的测试问题逐条手动打分并记录错误类型。每次改动系统比如换了切割参数、换了 embedding 模型、改了 prompt都用同一套测试集重新评估用得分变化来指导决策。没有这套基线你后面做的“优化”全是拍脑袋。4.2 线上监控让问题在产品化之前暴露离线评估做得再好线上也会出现新问题比如用户问了知识库里没有的东西、用户输入里带错别字、知识库文档更新后没有同步向量库。我建议至少做三层的线上日志监控。第一层是请求日志记录 query、检索结果、最终回答、延迟和 token 消耗。第二层是效果评价定期抽检日志让业务人员给回答打标签统计“优质回答率”。第三层是数据漂移监控统计新 query 和知识库的相似度分布如果相似度持续降低说明用户的问法在变可能需要更新知识库。在 Python 中做好这两类监控套路已经相对成熟日志直接输出到 JSON Lines 文件再定时用脚本聚合统计指标按天归档做成最简单的小报表。早期项目不需要复杂监控平台先把数据和工具链搭好后面自然知道怎么扩展。5. 常见问题与排查方向速查做这个项目时我一边写代码一边记录了踩坑日志最终积累了下面这份排查速查表。如果你在做同类项目时遇到问题可以直接对照定位。症状大概率原因排查方向检索结果驴唇不对马嘴切分单位过大/过小或 embedding 模型与查询不匹配检查切分文本确认查询和文档使用同一向量模型回答总是“不知道”检索到的知识片段与问题无关降低 top-k 阈值检查重排序逻辑查看检索片段原文回答出现幻觉内容prompt 约束不足检索片段为空时仍硬答强化 prompt 行为约束加入相似度阈值逻辑知识片段为空时直接拒答服务延迟很高模型无并发控制序列化影响CPU 推理增加缓存批量加载模型并发信号量量化模型用户输入稍变就答不出来依赖单路检索增加同义词改写、拼写纠错或混合检索策略知识库更新后系统不生效增量更新未实现检查新增文档是否写入向量库幂等性校验显存/内存持续增长推理框架缓存未释放定期加载测试用对象复用替代频繁创建模型对象prompt 改了但效果没变化缓存命中旧答案检查缓存 key 是否包含 prompt 版本号上面这张表是我最常用的排查起点。现实中的问题往往不是单点故障而是链路多个环节叠加因此排查时要按“数据 → 检索 → prompt → 生成 → 部署”这条链路逐层过别一上来就怀疑模型。6. 下一步怎么往深处走6.1 从 MVP 到可用的系统还需要补什么手工搭建完基础知识库问答之后下一步我会按优先级补三块工程能力。第一块是自动化评测流水线把 4.1 节里那套离线评估脚本接入 CI/CD每次改代码自动跑一遍回归测试避免“改坏了一处过了两周才发现”。第二块是知识库管理后台支持批量上传文档、增量更新向量库、人工修正错误回答并反馈到知识库。第三块是多路召回的进一步升级比如引入意图识别、FAQ 精确匹配、甚至多跳检索来处理更复杂的问题。这里插一句个人经验很多项目死于“过度设计”。如果你只是做一个 Demo不必一上来就上 Cranium 和庞大的 RAG 框架先把核心链路跑通再按真实数据暴露出的问题逐步迭代。框架只是手段问题才是引领者。6.2 技能栈的纵向延伸三条可选路线走完这个项目你已经具备了 AI 工程的全链路基本盘。在此基础上可以按职业兴趣选择纵向深入。第一条是算法纵深路线继续深入模型训练学指令微调、强化学习、模型评估方法论、推理优化。适合想走向算法专家路线的同学。第二条是工程纵深路线学更多性能优化、分布式推理、GPU 调度、自动扩缩容和云原生部署走向平台工程方向。第三条是数据纵深路线深耕数据质量、标注体系、数据版本管理、合成数据技术。大模型时代数据能力越来越值钱走这条路的人相对少但缺口很大。这几条路线并不是互斥的。我的建议是先用主线打通全链路再用支线补强一两个方向。AI 工程最忌讳的就是“啥都接触啥都不精”。7. 一些实际的经验体会最后聊几句实在话。我见过很多人学 AI 工程时最大的阻碍不是资料少而是“怕”字——怕数学看不懂怕环境配不好怕模型跑不起来。我的体会是大部分 AI 工程问题你动手去碰它就已经解决一半了。环境变量报错就一行行看模型推理慢就做性能分析数据脏就写好清洗脚本这些东西没有捷径但都是确定性的只要人肯坐在那里逐步磨总能磨出来。另一个特别想说的点是要尽早养成把自己的过程沉淀成文档和脚本的习惯。做这个项目时我记了一本“踩坑手册”后来它直接变成了团队的新人培训材料。AI 工程里很多隐形知识是跑在空气里的只存在于某个人的工作经历里你写下来它才成为可复用的资产。现在你手里的这份资料本质上也是这么来的。我不建议你按部就班每一步都抄一遍而是带着“如果这里出问题了会怎样”的疑问去过代码。跑通一遍之后再试着换一个领域的小项目比如做一个简历匹配助手、做一个内部信息检索机器人。一个项目能让你学会流程两个不同领域的项目才能让你学会迁移而迁移能力才是 AI 工程真正值钱的地方。