想写一手AI工程却又不知道从哪下手的人这几年我见了太多。项目名字叫 ai-engineering-from-scratch直译就是从零开始的AI工程但它绝不是一个简单的教程仓库名而是一整套进阶路线的浓缩。很多人以为AI工程就是调API、写提示词真上手做端到端项目才知道从数据到模型再到上线中间隔着一条巨大的工程鸿沟。这篇文章就围绕从零起步这条主线把我实际踩过的坑、摸索出的路径、以及能直接照抄的实操方案全部拆开讲。无论你是刚转行的开发者、在校学生还是想给团队搭AI能力的工程师只要目标是把AI真正用到产品里这篇文章应该能帮你省下至少三个月的试错时间。1. 先搞清楚AI 工程不等于调包1.1 这个项目到底在解决什么问题AI工程这个词这两年已经被用滥了。有人把写两行openai调用叫AI工程有人把微调一个小模型也叫AI工程。实际上真正的AI工程面对的是这样一个问题如何把一个模型从能跑出结果变成稳定、可控、可维护地跑在业务里。我见过太多团队死在半路上。模型在笔记本上跑得挺好一接真实数据就崩提示词在测试集上表现优秀换一批用户提问就答非所问本地延迟50毫秒上了生产环境变成5秒。这些问题都不是模型本身的问题而是工程问题。ai-engineering-from-scratch 这个项目的核心价值就是帮你搭建一条从零到一的完整链路数据处理、模型选型、提示词设计、检索增强、评估体系、部署监控。它不只是教你调一个模型而是教你怎么把一个AI能力做成一个产品。1.2 从零开始的完整学习框架我把整个学习路径压缩成了一张地图照着走基本不会迷路阶段核心任务产出物预估耗时基础层Python、数据处理、Git、Linux能写脚本处理真实数据2-4周模型层理解Transformer、微调、提示词能独立设计prompt并评估效果4-6周应用层RAG、Agent、多模型协作能搭建完整的AI应用6-8周工程层部署、监控、评估、成本控制能上线并持续维护8周以上这张表是我自己反复调整后的版本。最初我试图让新人先啃完深度学习理论再动手结果大部分人倒在数学推导上。后来改成先用起来再补理论的顺序效果好了很多。AI工程的本质是工程工程的第一原则是先跑通再优化。2. 从零开始需要攻克的四层技能2.1 第一层Python 编程与数据处理很多人以为AI工程对编程要求极高其实核心要求就三条能写干净的Python代码、能处理脏数据、能读懂别人的代码。你在实际项目里80%的时间都在跟数据打交道不是在跟模型打交道。数据清洗这一步被严重低估。我做过一个客服问答项目原始数据里有大量HTML标签、重复问题、错别字甚至还有把两个问题拼在一起的长文本。如果直接拿去建索引检索效果会一塌糊涂。我的习惯是先做一轮长度过滤再按标点和语义切分最后用正则把噪声去掉。import re def clean_text(text: str) - str: # 去掉HTML标签 text re.sub(r[^], , text) # 去掉多余空白 text re.sub(r\s, , text).strip() # 过滤过短或过长文本 if len(text) 20 or len(text) 2000: return return text这段代码看起来简单但很多新手会忽略长度过滤。太短的文本没有语义价值太长的文本会撑爆向量模型的输入上限切分时还要考虑上下文重叠。数据处理没有捷径唯一的技巧就是先看一批真实样本再写清洗逻辑千万别拿理想数据想当然。2.2 第二层模型原理与提示词工程这一层是很多人最感兴趣的也是误解最多的。提示词工程不是写几句好听的话让模型听话而是通过结构化的输入设计约束模型的输出空间。我的标准提示词模板通常包含五个部分角色定义、任务描述、输入格式、输出格式、约束条件。举个实际例子你是一名资深的技术客服。 请根据用户问题从提供的知识库片段中提取答案。 要求 1. 只能使用知识库内容回答禁止编造 2. 如果知识库中没有相关信息直接回复暂不支持该问题 3. 回答控制在100字以内 知识库片段 {context} 用户问题 {question}这个模板看着简单但每一行都有用意。角色定义让模型的语言风格稳定输出格式约束让后续解析不用写一堆兼容逻辑只能使用知识库内容是降低幻觉最有效的手段之一。要提醒的是提示词工程的边际效应很明显。把一段100字的提示词改成500字效果未必变好反而可能让模型过度关注不重要的细节。我一般在迭代三轮之后就不再改提示词了转而去看数据质量或检索逻辑——多数情况下问题根本不在提示词上。2.3 第三层RAG、Agent 与多模型协作如果说前面两层是基本功这一层才是AI工程真正拉开差距的地方。RAG检索增强生成解决的是模型不知道最新知识的问题Agent解决的是模型不能自主完成任务的问题多模型协作解决的是单一模型能力天花板的问题。以RAG为例我搭建过的标准链路包含四个环节文档切分按语义块切分保持上下文连续向量化用嵌入模型将文本转成向量检索排序用向量相似度召回候选片段重排与生成对候选片段重排后交给大模型生成答案这里最容易翻车的是切分策略。按固定字符数切分简单但会切断句子按段落切分语义完整但颗粒度不一。我自己的经验是先用递归切分器按标题和段落切再设置200-500字符的块大小和50字符的重叠这个组合在大多数场景下表现最稳。Agent这块很多新手一上来就搞复杂的工作流编排结果连基本的工具调用都频繁出错。我的建议是先做一个单工具Agent跑通全流程再逐步增加工具。比如先让Agent只会调用一个搜索API稳定后再加入计算器、数据库查询。工程上最忌讳的能力不是复杂度而是不可控。2.4 第四层工程化与部署交付模型跑通只是第一步真正决定项目生死的是工程化能力。这里包括三件事接口封装、性能优化、监控评估。接口封装的核心是把模型调用藏在服务层后面。我通常用FastAPI写一个浅封装对外暴露统一的HTTP接口对内管理模型加载、上下文组装和结果解析。这样业务方不需要关心你用的什么模型、怎么拼的提示词后续换模型也不影响上游。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str app.post(/ask) def ask(query: Query): # 内部调用LLM RAG链路 answer run_pipeline(query.question) return {answer: answer, sources: []}性能优化这块最常用三板斧模型量化、缓存、异步化。模型量化能把占用和延迟降低一半缓存可以把重复提问的响应时间从秒级降到毫秒级异步化则是为了应对并发场景。监控评估是最后一道防线每次上线前必须跑一遍测试集记录准确率、召回率和幻觉率否则你根本不知道一次改动是变好还是变坏。3. 实操7 天搭一个端到端 AI 问答助手3.1 第 1-2 天环境准备与数据清洗与其空谈理论不如直接跑一遍真实项目。我布置给新人的第一个完整任务是做一个基于内部文档的AI问答助手。这个项目麻雀虽小五脏俱全覆盖了AI工程的所有核心环节。第一天先把环境搭好。我的推荐组合是Python 3.11、Anaconda管理虚拟环境、向量数据库用Chroma或Qdrant、大模型接口先用现成的LLM API。不建议第一天就部署本地大模型显存不够会劝退很多人。先用API把链路跑通等有需要再换本地推理这是成本最低的学习路径。第二天花在数据上。找一个真实的文档集哪怕是自己读书笔记都行先做清洗和切分。我要求学生写一个数据预处理脚本输出每批切分后的文本块数量和长度分布。这一步能直观感受到脏数据对后续检索的破坏力。当时有个学生用了一份包含大量表格的PDF提取出来的文本完全是乱的过滤掉错乱行之后检索效果立竿见影。3.2 第 3-5 天RAG 链路搭建与参数调优环境就绪后第三天开始搭建RAG链路。核心代码不复杂关键在参数from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_text_splitters import RecursiveCharacterTextSplitter # 切分参数 splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) # 向量化与存储 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentssplitter.split_documents(docs), embeddingembeddings, persist_directory./chroma_db )第4天做检索调优。检索有两个关键参数一个是top_k召回数量一个是相似度阈值。top_k太小会漏掉相关内容太大又会让大模型淹没在无关信息里。我的经验是先从5开始根据测试结果逐个试3、7、10观察答案质量的变化。阈值则要看嵌入模型的相似度分布一般设在0.3到0.5之间。第5天把生成部分接上。这一步要把检索到的上下文、用户问题、提示词模板一起发给大模型同时要求输出引用的来源片段。不要小看输出来源这个要求它既能降低幻觉也为后续排查问题提供了线索。到了这一步一个能回答问题的demo就跑起来了。3.3 第 6-7 天接口封装、评估与上线第6天做评估。很多项目死在感觉效果还行上——没测试集、没指标、没基线改了一版都不知道是变好还是变差。我要求至少准备50条真实问题人工标注参考答案然后跑一遍RAG链路统计命中率。评估指标别贪多三个足够答案相关性、来源正确性、幻觉率。相关性可以人工打分来源正确性看RAG引用片段的准确率幻觉率统计模型编造内容的次数。每改一个参数都重跑一次把结果记在表格里。第7天封装上线。用FastAPI把RAG链路包成一个服务顺便加上两个监控指标响应时间和请求失败率。到这里一个完整的AI问答助手就真正工程化了后续不管是换模型、调参数还是接入新数据源都有清晰的抓手。3.4 关键参数速查表把这次实操里反复用到的参数整理成一张表方便你直接抄环节参数建议值备注文本切分chunk_size300-500字符按内容类型调整文本切分chunk_overlap50-80字符避免切断语义向量检索top_k5-10从5开始调向量检索相似度阈值0.3-0.5视嵌入模型分布定生成temperature0.1-0.3事实问答越低越好生成max_tokens300控制响应长度评估测试集规模≥50条覆盖典型场景这份速查表来自多次项目经验的平均值不是金科玉律。真正的调参过程一定是跑测试集-看结果-调参数-再跑测试集的循环直到各项指标稳定。偷懒跳过评估的后果就是上线后被用户问出各种五花八门的问题然后手忙脚乱地救火。4. 从 0 到 1 过程中的高频问题与排查实录4.1 环境与依赖问题AI项目开发里有一半时间都在跟环境斗争这不是夸张。我遇到最多的三个坑每个都可以让你卡上一整天。第一个坑是版本兼容。transformers、torch、CUDA三者之间的版本组合稍有不对就报错而且报错信息往往看不懂。我的解决思路是直接用官方提供的环境配置模板不要自己盲猜版本。比如确定要用某个模型就去找它的requirements.txt逐行对照安装宁可多装不能少装。第二个坑是嵌入模型和检索库不匹配。有一次我换了嵌入模型忘了重建向量库新旧向量混在一起检索结果完全不可用。这里养成一个习惯每次更换嵌入模型必须清空向量库重新索引不加例外。第三个坑是代理和网络问题下载大模型权重经常超时。我不展开细说只建议两个稳妥做法从国内镜像站下载权重下载后先校验文件哈希再加载能避免大量莫名其妙的加载失败。4.2 效果不理想时怎么排查回答质量差先别急着改提示词。我有一套固定的排查顺序从成本最低的开始第一先看数据。抽样检查文档切分后的文本块如果内容本来就是乱的后面的检索和生成无论怎么调都是白搭。这个环节占排查成功率的40%。第二再看检索。把用户问题拿去查询向量库看召回的结果是否合理。如果召回结果本身不对就要调整切分方式、嵌入模型或top_k参数。如果召回的片段是对的但答案还是错的那问题出在生成环节。第三才轮到提示词。仅当确认前两步没问题时再考虑优化提示词格式、补充约束条件或增加示例。有个经典案例用户问你们支持退款吗检索到的片段明明写了退款政策但模型回答暂不支持。排查后发现是提示词里给了过多约束把模型行为压制得过死。去掉冗余约束后答案立刻正常了。第四检查评估数据本身。有时候不是系统变差了而是测试集里的问题本身就模糊。把模糊问题删掉或改清晰让评估更聚焦在系统真实能力上。4.3 成本与性能的平衡AI项目的成本构成里大模型调用占了绝对大头。我见过一个demo项目测试阶段一个月烧掉几千块就是因为没有做缓存和限流。常见的省钱策略有三条。第一做语义缓存把用户问题和答案存下来同样的问法直接命中缓存省掉完整的LLM调用。第二用小模型做粗筛用大模型做精答简单的请求直接给模板答案。第三严格控制上下文长度很多团队上下文里塞了一堆历史对话导致每次请求都按最大token计费。性能优化则要分清瓶颈。推理时间主要耗在三个地方检索、模型生成、网络传输。先加日志统计每一段的耗时再针对性优化。我在一次排查中发现检索占了总耗时的一半原因是向量库数据量大了之后没有做索引优化。给向量库加上索引后检索耗时从300毫秒降到了30毫秒整体性能立刻提升一个量级。5. 后续进阶方向与个人经验补充5.1 从单点能力到AI Agent能把RAG问答助手跑通之后下一个自然的进阶方向是AI Agent。区别在于RAG还是问-答的被动模式Agent则是目标-执行的主动模式它可以根据目标自行决定调用哪些工具、按什么顺序执行。做Agent我有一条很深的体会工具设计决定Agent上限。Agent的能力不是模型给的而是工具给的。如果一个Agent只能做检索它就只会回答问题给它加上代码执行工具它就能做数据分析再加上写文件工具它就能自动生成报告。工具定义得越清晰、输入输出越规范Agent行为就越可控。多AI协作是另一个进阶方向。很多人幻想让多个模型各司其职、互相沟通做着做着就变成噩梦——模型之间互相甩锅来回对话好几轮都得不到结果。我的建议是引入一个调度的角色由它决定哪个子模型处理哪类任务而不是让模型自由对话。工程上结构化调度永远比自由协作可靠。5.2 关于学习和实践的一点体会写到这想分享一个我从多次带新人经历中总结出来的真实感受AI工程这个方向最大的瓶颈往往是心态不是技术。我见过太多人花几周时间研究理论却迟迟不写第一行代码。也有一些人反过来只追最新的模型和框架连基础的数据处理都写不利索。这两种倾向都走不远。最稳妥的路径始终是在项目中学习遇到什么问题解决什么问题把每个问题沉淀成经验。我个人比较推荐的做法是每一两周给自己一个小项目难度刚好超出当前能力边界一点。从做一个文档问答到做一个支持多轮对话的助手再到做一个能自动处理Excel的Agent每完成一个就把过程中的参数、踩坑、解法整理成笔记。这样积累三个月你会发现自己已经不自觉地跨过了从零到一的门槛。技术更新换代很快但工程方法论和解决问题的能力是你真正带走的东西。