1. 项目拆解为什么要把AI工程化当作一门手艺做技术这行久了你会发现一个规律——真正的工作门槛从来不在某一个点而在于把散落的点串成线。AI领域尤其如此。今天你可以调通一个模型接口明天能跑通一个开源仓库但真要做一个能稳定产出、能落地给用户用的AI应用中间隔着一段相当长的“工程化”距离。这个项目叫 ai-engineering-from-scratch说白了就是把我自己从零搭建AI应用全流程的经验整理成一条可复制的路径让后来的人不必在十几套工具、几十个概念、上百个坑里反复打转。先把这个概念说透。“AI工程”和“AI算法”是两回事。算法工程师关注的是模型结构、训练技巧、指标提升AI工程关注的是怎么把模型或模型能力稳定地嵌进一个真实产品里。用生活类比来说算法是发动机的燃烧理论AI工程是把发动机装进车里、接好油路电路、调好悬挂刹车的那套活。没有工程化再好的模型也只是一堆躺在显存里的数字。这个项目解决的核心问题也明确缺一条从零到一的路径。市面上的教程要么偏理论给你一堆数学公式要么偏应用只教你调一个API。少有人告诉你完整的AI应用长什么样、中间要过哪些关卡、每道关卡用什么工具最省力。与此同时这阵子AI圈的热词也印证了方向——Prompt Engineering、AI Agent、AI工作流、AI编程工具它们本质上都是工程化链条上的具体环节。你学会提示词技巧只是学会了拧螺丝你做了一条工作流是给车接上了管路你会用AI编程工具是掌握了新的加工机床。但离“造出一台能上路的车”还差着整车设计和装配工艺。这个项目适合谁三类人。第一类想转行AI方向但被各种名词唬住的开发者。你懂一点Python用过几次ChatGPT想系统地知道AI应用到底怎么搭这文章能给你一张全景地图。第二类已经在做业务系统、想用AI能力给产品加buff的后端工程师。你不需要从头研究模型原理但需要知道怎么把AI能力像数据库、消息队列一样当成一个基础组件接进现有的架构里。第三类刚带团队做AI项目的Tech Lead。你需要从成本、稳定性、可评估性这些工程视角去规划落地路径这里面不少坑是我实实在在踩过的。一句话总结这个项目的价值它不教你训练一个大模型它教你成为能把AI用得像个老工程师的人。2. 从零起步的核心技能栈先别急着碰框架把地基打牢2.1 语言层Python够用但重点是工程习惯做AI工程Python依然是绝对主力这一点短期不会变。原因不只是生态丰富更关键的是从模型调用、数据处理到服务发布的完整链条Python的工具链最顺滑。但我要强调一个新手容易忽略的事实会用Python写脚本和会用Python做工程是两回事。在AI工程语境下Python的工程习惯体现在几个地方。一是虚拟环境管理我见过太多项目死在依赖地狱里torch和numpy版本互掐、transformers和tokenizers对不上最后只能删库重来。你在起步阶段就应该养成给每个项目建独立虚拟环境的习惯用conda或venv都行锁版本、留requirements.txt或者pyproject.toml。二是类型注解和代码组织AI代码有一半时间在试错实验代码和工程代码如果不分开三个月后你自己都看不懂自己写了什么。建议至少把数据读取、模型调用、业务逻辑、配置管理拆成不同模块。三是异常处理调用外部模型接口时网络超时、限流、返回格式变化都是家常便饭没有异常处理的服务上生产环境就是定时炸弹。说到底语言本身不是门槛工程习惯才是。你要是用Java或Go做后端多年转过来也顺手因为AI工程现在越来越像传统的服务端开发——定义接口、管理依赖、处理并发、做好监控。Python只是恰好站在了模型生态的中心位置。2.2 模型层不训模型也要懂模型的脾气很多做应用的人一听“模型”两个字就发怵觉得那是算法工程师的事。这么想会吃亏。AI工程化落地时你不需要会训练但你一定要摸清你手上模型的脾气。什么叫摸清脾气至少包括这些模型的输入输出格式、上下文窗口大小、token计费规则、响应延迟分布、对提示词的敏感度、能力边界在哪里。拿上下文窗口举例同样一个任务模型A的窗口是8k模型B是128k你的方案设计就得完全不同。短窗口模型你得做检索裁剪、分段处理、状态压缩长窗口模型你可以直接把全文丢进去但随之而来的是成本升高和注意力分散导致的“中间遗忘”问题。选型不是越强越好是越合适越好。再比如大模型的一个核心工程痛点输出不稳定。同一句提示词你调十次可能得到十种措辞温度调高一点它能给你发挥出花来但也可能跑题跑得没边儿。工程师要做的事情就是用工程手段把不稳定性约束住——结构化输出要求模型返回JSON格式再用schema校验温度参数控制创造性和确定性之间的比例few-shot示例把模型“掰”向你要的风格。这些都属于“不训练模型但管理模型”的典型工程手法。这一层还有一个重要的时代红利开源模型让私有化部署成为可选方案。像Qwen、Llama这些开源权重模型你可以自己部署到内网数据完全可控成本也有更明确的模型。但部署带来的问题也麻烦——你需要自己处理GPU资源、推理优化、高并发负载。这条路不是不能走而是要想清楚什么场景值得走什么场景调用API更省心。2.3 提示工程不是玄学是结构化沟通Prompt Engineering这个词这两年被聊烂了但大部分人学到的都是碎片技巧比如“你要让AI一步一步思考”、“你要给AI一个角色”。这些有用但远远不够系统化。我的理解里提示工程的本质是结构化的需求沟通。你把它当成给一个执行力超强、但理解力有局限的下属写任务书。一份好的任务书应该包含角色定位你是谁、以什么视角处理问题、任务目标最终交付什么、上下文材料相关数据、背景、约束条件不要做什么、必须做什么、格式要求是什么、输出规范JSONMarkdown固定字段。每一项都不是可有可无的装饰而是为了压缩模型的自由发挥空间让它把能力集中在你真正需要它做的事情上。举一个真实的例子。早期我做内容分类提示词只写了一句“请将以下文本分类为科技、财经或娱乐”效果惨不忍睹——模型经常把“人工智能公司发布财报”同时判断成科技和财经还给自己加戏解释。后来我把提示词改成结构化的角色资深内容编辑任务对文本做单标签分类三个候选标签规则当两个标签置信度接近时选择出现位置靠前的那一个最后只输出JSON格式为{category: 科技, confidence: 0.9}示例给出三个带标准答案的few-shot样本同样的模型准确率直接从82%提到96%。差别不在模型在于你把需求表述清楚的程度。提示词写得好模型的能力上限虽然没有变但它的能力利用率大幅提高了。但这里也要泼一盆冷水提示词不是银弹。模型的推理能力、知识储备、上下文处理能力是有物理上限的。你把提示词写得再好让模型做它力所不能及的复杂推理它照样翻车。提示工程解决的是“明明会做但没做对”的问题解决不了“根本做不到”的问题。识别这两者的区别是AI工程师的重要能力。3. 工程化工具链让AI能力变成稳定服务的关键选择3.1 框架选型LangChain、LlamaIndex与原生调用的取舍工具链选择是这个项目里最容易让人纠结的部分因为AI框架迭代速度实在太快今天刚学完LangChain的用法明天官方又重构了API。我自己的经验是框架是手段不是目的先想清楚项目复杂度再去选工具。先说最原始、也最不容易被时代淘汰的方案——直接调用模型API。如果你的应用逻辑比较简单比如只有单个模型的调用后面接一个格式化输出你用requests或openai SDK直接写就行。好处是零依赖、逻辑透明、排障简单、没有额外学习成本。坏处是当你要做多步骤任务、多个工具调用、上下文管理时裸写会变得很啰嗦你得自己维护状态、拼接历史、管理工具调用的输入输出。这时候就该考虑LangChain这类编排框架。它的核心价值在于把大模型应用中的通用模式抽象出来Chain链式调用、Message消息管理、Tool工具注册与调用、Memory对话记忆、Retriever检索器。我用它做过复杂的多Agent协作流程确实省了不少事——Agent调度、工具结果回填、上下文截断这些琐碎逻辑框架原生帮你兜着。但代价是学习曲线陡峭、抽象层次多、出问题时你要在一层层封装里去定位。LlamaIndex则是另一种定位它更偏“知识检索RAG”。如果你的核心需求是让模型基于你自己的文档库回答问题它对数据索引、分块策略、混合检索的实现比LangChain更顺手开箱即用的效果也好很多。我的建议分三档。逻辑简单的直接原生封装一层需要多步骤编排的上LangChain核心场景是文档问答的选LlamaIndex。另外还有一个趋势值得注意——直接用代码写流程不依赖重框架。把每一步封装成函数用基础流程控制代码串联起来中间加日志和校验。这种方式最灵活也最符合工程化的直觉适合团队技术能力强、需求变化快的场景。3.2 关键一环结构化输出与结果校验AI工程化落地的时候最让人头疼的事情之一是模型输出和代码预期的不一致。你让模型返回一个JSON它偶尔给你夹带一段解释文字你让它返回固定枚举值它可能给你来个同义改写。这在开发环境偶尔能容忍在自动化流程里就是直接报错、数据污染、用户体验崩塌。所以结构化输出和结果校验是AI工程里绝对省不掉的两个环节。结构化输出现在主流模型基本都支持。OpenAI的response_format可以强制输出JSON对象Anthropic的tool use机制能约束模型按预定义的schema输出。用这类机制的价值在于你在代码层面拿到的是一个干净的、可直接反序列化的结构而不是一个需要正则去抠内容的字符串。如果你用的模型不支持强制JSON退而求其次的办法是写非常严格的格式约束然后做容错解析——用json.loads先试失败了用正则找花括号片段再试再不行让模型自己修正。结果校验则是第二道保险。拿到结构化输出之后代码要验证几个东西字段存在性、字段类型正确性、枚举值合法性、逻辑约束一致性。比如你让模型抽取“日期”字段输出是一个字符串你最好再把它解析成datetime对象解析失败就标记这条数据异常。这一步的作用是防微杜渐——数据质量是AI应用的生命线脏数据进到下游又不好排查不如在入口就卡住。3.3 Agent与多步任务让模型学会使用工具Agent是这段时间最热的方向理解它不需要太玄学。本质是给模型一个“能动手”的能力——模型不再只是生成文本它可以根据任务需要调用外部工具然后基于工具返回的结果决定下一步动作。工具的范畴很宽搜索引擎、代码解释器、内部API、数据库查询、文件读写都可以。工程上要做好Agent关键不在模型本身而在三块能力边界界定、工具设计、循环控制与终止条件。能力边界界定是想清楚哪些步骤适合交给模型决策哪些步骤应该用确定性代码硬编码。工具设计是让每个工具的函数签名足够清晰工具描述写明白“什么情况下该用它、输入是什么格式”因为模型是靠描述来理解工具的描述写得烂模型就会乱调用。循环控制和终止条件是设置Agent最多跑几步、超时多久、什么条件下判定任务失败并退出不然一个失控的Agent能在你的系统里无限折腾下去既烧token又飙延迟。我见过不少团队做Agent失败的案例共同问题都是赋予Agent太多自由。真正的工程化Agent应该把自由限定在弹珠台里的几个轨道上——模型可以在有限范围内选择调用哪个工具、如何解释结果但整体流程的骨架、分支条件、异常兜底都应该由人来掌控。成熟的做法是“流程确定性节点智能性”主流程是明确的状态机每个状态节点里嵌入模型的决策能力。这样既保留了AI的灵活性又保证了系统行为的可预期性。4. 实操全流程从零搭一个AI文档问答系统4.1 需求定义与方案选型先想清楚到做到什么程度文字讲了这么多光说不练不行。接下来我完整走一遍这个项目里最有代表性的实操案例——从零搭建一个“私有文档问答系统”。业务场景很常见把公司的产品手册、技术文档、FAQ丢进去员工或者用户可以直接用自然语言提问系统返回有依据的答案。这个场景能覆盖AI工程里最典型的几个环节数据准备、索引构建、检索增强、模型调用、结果评估。第一步永远是需求定义。不要一上来就写代码先问几个问题文档量级是多少1万字的说明文档和1万份合同方案完全不同。答案的来源文档要不要显示给用户不显示你可以直接用RAG显示来源你要加引用匹配逻辑。对回答实时性的要求是几秒决定你要不要上流式输出。这些问题不落实后面每一步都会返工。方案选型上我这次采用“RAG开源模型流式输出”组合。选RAG而不是纯大模型生成是因为文档问答的场景高度依赖最新、最具体的私有知识纯靠模型内置知识肯定会瞎编或者答不全面。选开源模型而不是闭源API是考虑到文档内容可能涉及内部资料且高频调用下API成本会持续累积。组合方式在本地上用一套量化后的Qwen模型跑推理向量化用现成的embedding模型整体成本可控。4.2 数据准备与索引构建脏数据进坏系统出文档问答系统的性能天花板一半在数据准备的质量上。很多人的RAG效果差不是模型不行是文档切得不对、索引做得糙。数据准备这关要过三件事。一是格式清理把PDF、Word、Markdown统一抽成纯文本去掉页眉页脚、目录、重复的空白行、无意义的表格碎片。这一步听着简单实际最耗时。PDF抽取中文文本时经常出现断行错乱表格会变得完全不可读你得在不同抽样工具之间做测试对比甚至可能要针对特殊文档写规则做后处理。二是分块策略这是决定检索质量的胜负手。块太小检索到的片段缺乏上下文模型拿到碎片拼不出完整答案块太大噪音多且容易超出模型的上下文窗口上限。我自己常用的策略是“分层分块”先用标题层级把文档切成结构上相对完整的章节再对过长的章节按固定长度比如500~800字二次切分块与块之间保留少量重叠避免切断语义完整的段落。三是元数据标注每个块要记录它来自哪篇文档、哪个章节、页码是多少。这些元数据后面有两个用处——检索时可以做来源过滤和权重调整回答时可以用来引用溯源。索引构建相对直接把切好的块向量化后写入向量数据库。选型上轻量项目用Chromadb或FAISS就行数据量大、并发高再考虑Milvus或Qdrant。索引构建完成后建议做一个自检随机抽10个问题手动确认它们对应文档里的哪一段然后查索引看这些段落的检索召回排名。这一步能在问题还小的时候就暴露分块策略的缺陷。4.3 检索增强生成把上下文喂给模型之前先过三关RAG的核心就一句话先检索到相关内容再让模型基于这些内容回答。但细节都在“检索到相关内容”这六个字里。第一关是查询改写。用户来问“上周的版本发布文档里说批量导入上限是多少”这种口语化、带指代的问题直接拿去检索往往匹配不到好结果。所以我会在检索前加一步查询改写让模型把用户的问题转化成更适合匹配的检索表达式比如改写为“版本发布 批量导入 上限”。这一步是RAG里性价比最高的优化点之一花的token极少对结果的影响却很大。第二关是检索召回与重排。向量检索的召回基于语义相似度单纯靠它结果里经常混着不少“语义沾边但实际不相关”的内容。我的做法是双路召回再结合重排序一路是向量检索召回Top 50另一路是关键词匹配BM25召回Top 50两边结果合并去重后再用一个专门的rerank模型对候选片段做精细排序取前5条作为送入模型的上下文。这个流程比单路向量检索多耗一点算力但回答准确率的提升往往是肉眼可见的。第三关是上下文构造。把5个相关片段按顺序拼装成提示词时要控制总长度不要超过模型的窗口上限要给每个片段标注来源信息要让提示词明确告诉模型“只能基于以下内容回答如果内容中没有相关信息请直接说‘文档中未找到相关内容’不要编造。”这个边界约束非常重要——它直接决定了系统会不会一本正经地胡说八道。我在生产中还会加一个兜底策略当检索结果的整体相似度得分低于阈值时直接拒绝回答而不是把勉强匹配的内容硬塞给模型生成一堆烟雾弹。4.4 服务封装与流式输出用户体验从“转圈等待”到“逐字响应”模型能力验证通过后真正让它变成一个可用产品还要做服务化封装。这里有个朴素的道理用户不关心你用了什么模型、什么框架他关心的是输入问题之后多久能看到回答。服务封装要处理的事情包含这些把RAG完整流程查询改写、召回、重排、上下文构造、模型调用封装成一个可调用的服务接口接口的出入参用Pydantic做严格校验加入鉴权和限流防止服务被随意调用拖垮把检索过程的关键日志打出来方便线上排障。这些对于做过Web后端的人来说都不复杂但缺少任何一个上线后都会用事故提醒你。流式输出是一个容易被忽视、但对用户体验影响极大的环节。大模型生成回答通常需要几秒到几十秒如果让用户干等心理感知的时间会非常漫长。实现流式输出后用户可以看着回答一个字一个字地出现整体等待感大幅降低。工程实现上使用SSEServer-Sent Events把模型输出的token按批次推送给前端后端是异步接口前端拿EventSource或fetch流式读取。这块对前端体验差异巨大而且实现成本并不高值得做。最后一定要加评估闭环。不要靠感觉判断系统变好了还是变坏了要准备一组覆盖典型场景的评测集——易答问题、含指代的问题、文档里查不到的问题、对时效性敏感的问题——每次改动后跑一遍统计准确率、引用命中率、拒绝率这些指标。哪怕一开始只有几十条评测样本也远胜于拍脑袋。我在项目里吃过亏加了一段提示词感觉回答变详细了结果线上数据显示引用命中率反而掉了5个点。有了评测闭环这类问题就能在灰度阶段被拦下来。5. 生产环境避坑实录这些坑我替你先踩了5.1 成本失控token账单比服务器账单更吓人AI应用上了生产之后很多人第一次打开账单时会愣住原来模型调用的token成本可以这么高。一个面向用户开放的问答功能如果每个问题平均消耗3000个token加上检索到的上下文一个月下来轻轻松松烧掉几千块。控制成本要从两头下手。一头是减少不必要的token消耗缓存用户常见问题的回答相同或高度相似的问题直接命中缓存不再调用模型控制上下文长度检索结果不需要全塞进去相关分数低的片段果断丢弃压缩输出能用3句话回答的问题不要引导模型长篇大论。另一头是选对模型规格简单任务用便宜的小模型复杂任务才用贵的大模型。我常用的做法是做一个模型路由层根据任务的复杂程度动态选择不同规格的模型。这要求你对自家系统各环节的任务类型有清晰认知——分类、抽取这类结构化任务用轻量模型就行生成推荐理由、做复杂总结这类内容再生产才值得动用大模型。模型路由做得好成本能省一半以上效果几乎不掉线。5.2 延迟劣化为什么模型越来越“笨”了有一个现象挺有趣系统刚上线时效果很好用了一个月感觉明显变差大家第一反应是“模型是不是被供应商偷偷换了”。大部分情况还真不是。延迟劣化更多是因为你的文档库不断加入新内容新旧内容混杂检索的时候旧的低质量片段把人带偏了或者是评测集老化你的用户问题形态已经变了而评测集还是老问题指标没有跟随真实场景更新。应对办法有三个。一是数据质量管理新文档入库前要做和初始数据一样的清理和分块流程并且要评估它对索引的影响定期检测重复内容、过期内容对检索结果的干扰。二是评测集持续更新每隔一段时间从真实用户日志里捞一批高质量问题人工标注正确答案补充进评测集。这事情看着繁琐但它是你判断系统真实状态的唯一可靠依据。三是增加版本回溯机制每次更新索引或提示词后保留线上版本的快照一旦发现指标下滑可以快速回滚到之前表现稳定的版本。5.3 幻觉治理让AI知道什么该说“不知道”“幻觉”是生成式AI的老大难问题。工程上不可能完全根除但可以大幅压缩它出现的概率。我沿用的思路是从三个位置同时设防。输入端构建检索上下文时确保给模型的材料与问题高度相关不要让它在一个空背景下自由发挥如果你的业务场景允许加入“知识边界声明”例如“你只能基于提供的资料回答”。生成端用提示词约束模型——资料中没有的信息要么直接承认不知道要么给出基于资料的推断并明确标记为推断。这句话看着简单实际对降低幻觉有奇效因为模型在“被允许编造”和“被要求承认不知道”两种状态下的行为差异非常大。输出端做事实一致性校验主要针对结构化回答——如果回答中包含了可验证的事实项金额、日期、编号用后端代码从原始资料中做简单核验核不上就标记为低置信度不直接暴露给用户。三层设防下来幻觉率能压到用户几乎感知不到的水平。5.4 迭代与复用把AI能力沉淀成组织资产最后想多说一句关于“复用”的事。AI应用开发的项目经常长得很像今天做个文档问答明天换个场景做智能客服底层全是RAG模型调用流式输出的组合。如果你每个项目都从零开始搭不仅是浪费而且是把自己困在了重复劳动里。成熟的团队会把AI工程能力抽象成内部平台统一的模型网关管理多供应商、密钥、限流、成本统计、统一的RAG服务索引构建、检索、重排共用一套、统一的评测框架评测集管理、批量跑批、指标报表、统一的提示词管理版本化、灰度发布、回滚。这听起来是做平台的活但它带来的长期收益极大。一个AI应用跑成功之后把其中可复用的部分沉淀下来下一个项目可能只需要写业务逻辑基础设施全部复用。这也是我从这个项目里得到的最重要经验——用工程方法做AI越做越省力用“每次重新发明一遍”的方式做AI越做越累。我自己的体会AI工程化能力不是哪一次的灵光一闪而是持续把每个环节做扎实、把每个坑记录下来的复利积累。认准这个方向投入的时间都会变成你后续所有项目的地基。