从GitHub上刷到这个ai-engineering-from-scratch仓库名的时候我第一反应是终于有人把AI工程里那些散落的知识点串成了一条可执行的学习路线了。市面上聊AI的教程要么在讲数学公式推导要么就直接甩给你一个包装好的WebUI真正能让人从零开始、一步步把大语言模型应用做出来并部署上线的资料反而稀缺。这个项目的核心价值就是给像我这样“有点编程底子、但没系统做过AI工程”的人提供一条动手驱动的成长路径不靠看视频看懂而是靠写代码跑通。它解决的是实际团队里最常见的尴尬——模型调通了提示词也能输出像样内容但一旦要接入业务系统、处理真实数据、应对各种边角Case整个方案就开始崩。ai-engineering-from-scratch最大的不同在于它把“会调API”和“能做工程”中间的鸿沟一点点填平了。今天这篇就把我在实践这类从零项目时的完整拆解、代码骨架、踩坑记录和排查经验一次性整理给你。1. 项目本质拆解所谓“从零开始”到底要重建什么1.1 这个标题背后隐藏的完整能力地图很多人在真正动手之前以为AI工程就是学会调用开放平台的接口传一段Prompt接收一段JSON返回然后完事。这种理解不能说错但只停留在“消费者”层面。ai-engineering-from-scratch这个词组真正想表达的是你需要亲手重建一遍从数据准备、模型调用、上下文工程、Agent编排到质量评估的整条链路才能真正承担AI工程师这个头衔。我把它拆成五个必备能力域提示词工程与模型行为控制、检索增强生成RAG、Agent工具调用与规划、系统化评估与回归、生产成本与性能调优。每个域之间不是割裂的而是层层递进。比如RAG做不好很大程度上不是向量库的问题而是分块策略的问题Agent跑飞也不是模型不聪明而是你给它的工具描述和终止条件没设计好。这些交叉点正是这个项目精妙的地方。从零开始还有一个容易被忽略的好处你会被迫理解每个环节的“为什么”而不是拿到一个现成框架后知其然不知其所以然。比如用现成的RAG框架你只需要填API Key就能跑但你自己写一遍分块、向量化、检索、重排的流程才会知道为什么有的文档必须按Markdown标题切分而不是无脑按字符数切成512块。1.2 为什么“重建轮子”反而是最快的成长路径我接触过不少转行做AI的开发者最大的通病就是太依赖框架和现成中间件。碰到问题就搜Stack Overflow升级版本就换API签名完全没建立自己的技术判断力。这类项目采用“从头写”的方式强迫你摆脱对封装的过度依赖这个选择是刻意的。自己实现一遍还有一个巨大红利你以后用任何商用框架或者内部平台时能直接看懂它们抽象了什么、隐藏了什么、牺牲了什么。比如自己写过Embedding检索后再看Pinecone或Milvus你就明白它们解决的只是向量搜索效率问题而召回质量还得靠你的分块和查询改写逻辑。这种底层认知一旦建立就不会被各种新名词带着跑。当然“从零开始”不是让你从反向传播开始推公式。项目的最佳路径是用成熟的模型API作为推理底座然后用基础Python代码搭建周边的工程链路。这好比做菜食材你买现成的大模型API但配菜切分、火候控制、调味、摆盘这一整套流程你得自己练。这样既不会被底层训练细节劝退又能真正掌握应用层的核心工程能力。1.3 谁适合走这条路线谁其实不适合老实说不是每个人都适合从零式学习。如果你目前只希望在业务里快速验证“AI能不能解决这个问题”直接去调现成应用、用低代码平台搭个原型就够了没必要重复造轮子。但如果你是后端工程师想转型AI应用开发、算法工程师想补齐工程化短板、或者独立开发者要交付生产级AI产品那这条路线就是性价比极高的投资。判断标准其实很简单当你的AI系统报错时你是只能把错误信息CtrlC、CtrlV发给搜索引擎还是能够按链路一步步排查出问题究竟出在分块、召回、排序、上下文压缩还是输出解析环节前者适合用现成工具后者才需要从零学习。项目里的每个练习都在刻意培养这种“链路级定位”的能力。2. 关键技术环节深度拆解四个绕不开的核心模块2.1 提示词工程不是玄学是可量化调优的工程模块提示词工程在这条路线里的定位很特殊——它看起来最简单实际最考验抽象能力。我见过太多人拿“精心设计的提示词”当作解决方案本身但遇到一次输出格式错误就全盘崩溃。所以这个项目里提示词工程只教三件事任务描述的结构化、输出可控化、少量样本引导。先说结构化。一个稳定的提示词应该是“角色背景任务约束输出格式”五个部分的组合。我常用的模板长这样system: 你是一个严谨的数据清洗助手。我们正在处理电商平台的商品描述数据。 任务从输入的原始文本中提取商品名称、品牌、规格、价格四类信息。 约束 1. 只输出JSON不要输出任何解释性文字。 2. 如果某字段缺失使用null填充。 3. 价格统一转换为数字类型去掉货币符号。 输出格式{name: string, brand: string, spec: string, price: number|null}这个模板的精髓在于约束部分。很多人写提示词只顾着描述任务忘了定义失败边界。我加了一条“缺失字段用null填充”之后解析侧代码就再也不用面对一大堆缺字段导致的KeyError异常了。这就是把提示词当工程做而不是当作文写。温度参数的选择往往被忽略。做信息抽取、分类这类确定性强任务temperature设为0或接近0做创意写作、头脑风暴可以调到0.7以上。这个参数不是锦上添花而是直接影响你后续所有逻辑能否稳定解析的根本变量。我在项目里特意安排了一个练习同一段Prompt温度从0调到1.2观察JSON输出失败率的变化——不用解释太多跑一次你就懂了。2.2 RAG给大模型装外部记忆时的那些暗坑RAG模块是整个项目里内容密度最高的部分因为它横跨了文本处理、向量化、检索策略、上下文组装四个子领域。初学者最容易犯的错是以为把PDF丢进向量库就完事了。项目用三次递进练习把这个问题打穿。第一版实现是最朴素的“固定分块余弦相似度检索”通常效果很差。用户问一个跨段落的问题召回的内容就是不连贯。我在实操时把分块策略改成了按文档结构动态切分读取Markdown或HTML的标题层级以##和###作为切分边界每个分块保留其祖先标题作为上下文前缀。原理其实很朴素——作者的章节结构本身就反映了语义边界你强行按字符数切等于把逻辑完整的段落拦腰斩断。第二版加上了元数据过滤。我给每个分块打上来源文件名、章节路径、最后修改时间。检索时先按业务条件过滤再做相似度搜索。比如一个包含2023年和2024年两份年报的知识库用户在Query里问到“最新的营收数据”如果你不做时间元数据过滤模型很可能抽中年份不对的旧数据。第三版加入了混合检索和重排序。纯向量召回在专业名词、代码标识符、人名地名面前表现不佳所以我在管线里并联了一个BM25文本检索把两路结果合并后交给一个重排序模型统一打分。这里我必须提醒很多项目加了rerank之后效果反而变差原因是没有做“查询改写”。用户问题通常很口语化和文档里的书面表达隔着语义鸿沟。我在重排序前先让LLM把用户Query改写成适合检索的多个子查询再分别去检索召回质量立刻上了一个台阶。2.3 Agent让模型学会规划、调用工具与收手Agent在ai-engineering-from-scratch里的定义很克制一个能够调用外部工具、并根据执行结果决定下一步动作的循环。项目刻意没有用LangChain那种高层抽象而是手写了一个最小的ReAct循环。这个取舍我认为非常正确因为只有亲手写过这个循环你才能理解Agent真正的风险点在哪里。核心循环其实就是四步观察输入 → 生成推理和工具调用请求 → 执行工具并返回结果 → 判断是否该输出最终答案。我写了一个简化版骨架def run_agent(query: str, max_steps: int 5) - str: messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: query}) for step in range(max_steps): response llm.chat(messages, toolsTOOL_SCHEMAS) if response.tool_calls: messages.append(response) for call in response.tool_calls: result execute_tool(call.function.name, call.function.arguments) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result) }) continue return response.content return 达到最大步数强制终止。这个骨架里的max_steps就是我要强调的保命参数。真实业务中Agent最莫测的问题不是“不会调用”而是“不断调用停不下来”。哪怕是简单的知识库问答模型也可能反复调用同一个工具好几遍才肯收手。每轮调用都是真金白银的Token和时间延迟。我在项目里把max_steps默认设为5同时监控每一轮的工具返回结果大小防止某个工具返回了超大的数据撑爆上下文。工具描述对Agent行为的影响超出大多数人的预估。我给同一个计算器工具写了两种描述“计算两个数字之和”和“执行任意数学表达式计算并返回数值结果适合加减乘除、取余、幂运算”。第二种描述明显更精准Agent在遇到复杂计算时使用该工具的频率翻倍。工具描述本质是模型决策时的先验信息写不好再聪明的模型也会傻掉。2.4 评估与回归确保AI系统不越改越烂的底线评估是AI工程里最不被重视、却最致命的一环。没有评估你根本不知道一次提示词调整是让系统变好了还是变坏了。很多团队做AI应用感觉像在开盲盒本质上就是缺少一个可重复的评估流程。最朴素也是我推荐起步的方式是LLM-as-judge用一个大模型当裁判给生成结果按相关性、忠实性、完整性等维度打分。听起来有点循环论证但实测下来只要设计好评分标准裁判模型的判断和人工评估的一致性可达八成以上。我在项目里用这个方式搭了一个最小回归测试集每次改动提示词或检索逻辑后跑一遍看平均分和单项分的变化。除此之外还有一个被很多人忽略的评估维度是结构化输出解析成功率。模型虽然按照格式约定输出了JSON但实际返回里可能带Markdown代码块标记、多余的逗号、甚至是截断的半截JSON。这类问题只有在生产环境下才会暴露。我在管线里专门加了一个统计项原始输出成功解析JSON的比例。这个指标对体验的影响有时候比RAG召回率还要直接。3. 实操路径按这个顺序走少走三个月弯路3.1 第一阶段先跑通最小闭环建立核心手感这个阶段不用搞任何花哨的东西目标只有一个用代码完成一次完整的“请求-解析-展示”过程。我会选一个不带流式输出的简单模型接口用Python的requests库直接调不借助任何SDK。为什么不用官方SDK因为我想让你亲眼看到HTTP请求体长什么样理解Authorization头、model字段、messages数组这些底层概念。建议做一个小练习写一个命令行的FAQ问答机器人问题写死在JSON文件里答案由模型生成。跑通之后慢慢给它加功能支持多轮对话把历史消息拼进messages数组、支持错误重试遇到限流自动退避、支持简单的日志输出。这套小系统虽然简陋但它是一个完整的工程闭环你会第一次体会到“AI应用”和“调用一次接口”的边界在哪。这个阶段最容易踩的坑是忽视Token用量。调试时随手打一大段提示词没感觉但数据量上来之后成本会变得非常可观。我建议从一开始就在每次响应里记录usage字段并把它打印到日志里养成量化成本的习惯。等到后面做RAG和Agent你会感谢这个习惯。3.2 第二阶段用结构化输出把模型“锁进规矩里”第二阶段的主题是输出控制。你需要在提示词中明确要求模型以JSON格式返回设置严格的字段约束然后写对应的解析逻辑。这个阶段我强烈建议使用函数调用能力而不是靠提示词约束因为函数调用天然限制了参数结构模型“乱说”的概率低得多。实操时可以选一个现实场景把用户对商品的自由文本评价解析成情感倾向、评价维度、关键词列表三个字段。先用函数调用规范输出再写一段代码自动解析出这三个字段最后统计一百条真实数据里的解析成功率。你会发现即便定义了严格的Schema模型仍可能在长文本里遗漏字段或输出不存在的枚举值。遇到这种问题回到提示词里把约束写得更明确同时在解析侧加入容错逻辑解析失败时记录原始输出和错误信息统一做重试或走兜底分支。这个阶段结束后你应当建立起一个底层认知任何未经Schema约束的模型输出都不应该直接进入业务逻辑。这是从“玩模型”到“做工程”的分水岭。3.3 第三阶段从零搭建一个RAG知识库问答系统这是整个项目中最有成就感的阶段。选一批你熟悉的文档比如项目里的README、产品说明书、工作笔记搭建一个完整的知识库问答流程。我推荐用纯Python来实现不要引入企业内部知识库平台。分块用递归字符文本分割器给每个片段加title和section元数据向量化用一个开源的Embedding模型存储直接用chromadb这类轻量级向量库。搭建完基础链路之后别急着收工。把注意力放在两个优化上一是查询改写写一段提示词让LLM把用户的问题改写为更适合检索的形式比如“今年的营收是多少”改写成“2024年度营收数据”二是上下文窗口组装召回的文档片段不能全部塞进提示词要按相关度截取前3-5个片段并在每个片段前标注来源方便模型区分不同文档的权重。我用实测数据给个参考同一组问题单纯向量检索的命中率大概在65%加上BM25混合召回后到78%再加查询改写和重排后能到88%以上。这三个优化措施的投入产出比极高几乎是成本最低的提效手段。3.4 第四阶段手写Agent循环过一把“编排者”的瘾当你具备了提示词和RAG的基础就可以开始写Agent了。我给这个阶段的练习任务很简单做一个能查询天气、计算日期差、搜索知识库的助手。工具就三个但你需要把它们注册成模型能识别的函数描述结构。这个阶段的核心目标是理解Function Calling协议。我把工具定义为一份JSON Schema列表模型返回的tool_calls里包含函数名和参数。执行完工具后把结果以tool角色消息追加回对话里。这里有个小细节很多人不知道tool_call_id必须原样传回去否则模型会分不清这个工具响应到底对应哪次调用。这个细节在并发场景下尤其重要我曾在生产环境里因为漏传ID导致对话上下文错乱排查了一整天才定位到。循环之外我还会专门演示“防跑飞三板斧”最大步数限制、单轮工具响应体量限制、超时熔断。初创团队做Agent最容易在演示时翻车就是因为没设限制。加好这三板斧Agent系统才算达到了“可以放到演示环境给人看”的基本水准。3.5 第五阶段评估、回归和成本治理的落地实操最后一个阶段回到工程本质。你需要整理一批代表真实使用场景的测试问题最少五十条多则上百条把答案录成Golden Set。之后每次调整提示词、改分块参数、换Embedding模型都跑一遍回归。没有这个过程你后续所有的优化都是蒙眼开车。成本治理也要从这一阶段开始。我给自己的项目定了几条规则所有外部API调用尽量缓存命中结果长文档处理优先用便宜模型做预处理复杂推理才动用强模型Agent的循环步数压到最低可接受值流式输出能省就省不需要实时展示就别开。这些不是小聪明而是规模化之后必须养成的工程纪律。我见过太多项目死在“指标很好但成本撑不住”上提前养成成本意识后期能救你于水火。4. 高频问题与真实改善手记4.1 模型输出“一本正经地胡说八道”怎么防这是被问得最多的问题。如果模型在回答中编造了知识库里没有的内容九成问题出在检索上下文里没有明确边界标记。我在提示词里加入一段固定话术后情况立刻好转回答以下问题只能使用给出的参考资料。 如果参考资料中没有相关信息必须回答“资料中未找到相关信息”严禁自行补充。 参考资料 document index1 source2024年报.pdf ... /document同时把温度调到0.1。这两步做完无中生有的情况基本被按住了。如果在生产系统里还担心就加一道兜底校验从回答文本中反向提取关键实体和检索回来的文档实体做交集比对交集为空的回答直接判定为疑似幻觉走人工复核或拒绝回复。4.2 RAG检索效果差多半不是向量库的锅“我换了一个更强的Embedding模型为什么检索效果还是没变化”这种问题我见过太多次。真相是大多数检索质量问题出在分块和查询两端而不在向量化模型本身。如果文档切得太碎长段落的信息被切断模型看不到完整上下文如果切得太粗分块里掺入大量无关段落向量被稀释召回精准度下降。我的建议是先检查两个地方一是分块大小是否和文档本身的语义粒度匹配二是用户查询是否经过改写。我遇到过最夸张的一个案例用户问题只有八个字而知识库文档全是两三页的长报告向量化后的分块语义本身就是散的匹配效果当然差。后来把查询改写为多个覆盖不同子主题的子查询每个子查询分开检索后再合并排序效果立刻提升了两成。4.3 Agent陷入死循环或反复调用同一个工具Agent系统上线后最常见的故障就是“同一个工具被反复调用七八次每次参数都差不多就是不输出最终答案”。这通常意味着模型对工具结果的解读不够充分。解决办法有三个方向在系统提示词里明确告知“当工具返回的结果满足需求时立即结束调用并生成最终答案”把温度调到0在循环里记录上一次相同的工具调用参数如果完全一致就强制打断并兜底输出。另外一个很隐蔽的原因工具返回结果格式太复杂模型看不懂。我给知识库检索工具返回的JSON加了精简字段top_results里只保留标题、来源和摘要不再塞完整内容。工具返回变简洁后模型做决策的难度明显下降循环步数也随之减少。4.4 评估分数挺高但用户反馈还是很差这类问题通常在“评估集和真实场景的分布不一致”上。我一开始建的评估集全是晴朗天气的常见问题模型表现很好一放到生产环境用户各种口语化、模糊的追问立刻把系统打回原形。解决办法是持续从真实对话日志里采样失败Case扩充到评估集里。另一个常见原因是评估指标只看“相关性”没看“忠实性”。相关还得看模型有没有真的依据检索来的资料作答还是光凭自己的世界知识在发挥。我在裁判提示词里增加了一条强制要求参考内容中找不到对应信息时忠实性直接打零分并且要求裁判给出打分理由。这样一来评估系统开始能准确反映真实体验。5. 从学习项目走向生产系统前再补三刀如果你已经走完了上面五个阶段手里应该有了一整套可运行、可评估、可控成本的最小系统。这时候再往生产环境推请先过一遍这三项检查每一个都是我用实际代价换来的教训。第一可观测性必须前置。不要等线上出问题才开始加日志。每次模型调用、检索召回、Agent步骤、解析失败都需要有结构化日志。我习惯在每个关键节点输出一个包含request_id的JSON日志排查问题时顺着ID就能串起整条链路。第二兜底逻辑一定要写在业务代码里而不是写在提示词里。模型随时可能返回空值、超长文本、非法JSON或完全无关的内容。凡是拿模型输出直接做业务判断的代码都是定时炸弹。正确做法是在代码里做一层防御——解析失败重试两次再失败走规则兜底或人工介入。第三性能优化从第一天就盯住延迟。大模型推理的平均首字延迟通常在几百毫秒到数秒之间这意味着你的业务架构必须允许非阻塞调用。异步请求、缓存、流式返回、任务队列这些后端基本功在AI应用里的重要性被严重低估。我见过太多团队界面UI已经画好了接口却因为同步等待模型返回而频频超时。把这三件事做扎实你的项目才算真正从“演示能用”跨越到了“生产能扛”。ai-engineering-from-scratch这类命名听起来像是在教你做一个练习项目但走到最后你会发现它教的其实是一种工程化思维把不确定性当输入把确定性当目标把每一次模型输出都当作需要被管理和校验的数据。顺着这条路径走下去AI对你就不再是黑盒子而是一个你熟悉脾气、知道怎么哄、也清楚它何时会撒谎的协作对象。