1. 从零搭建AI工程的全景设计先想清楚这四件事我见过太多人拿到“AI工程”这个词就开始动手写代码结果写了两周发现不是在调参就是在补数据真正该设计的架构反而被忽略了。作为一个折腾过多个从零到一项目的从业者我想先说一个结论AI工程和AI建模是两件完全不同的事。建模解决的是“这个模型能不能跑通”工程解决的是“这个模型能不能稳定地跑在真实场景里”。如果你也想自己从零开始搭一套完整的AI工程体系这个项目标题里的from scratch才是真正的关键。它意味着你不用依赖某个厂商的炼丹平台不用被某个框架锁死而是从数据层、模型层、服务层、评估层一步步搭起自己的流水线。这样做最大的收益不是“什么都能自己造”的快感而是当线上出问题时你具备从底层开始定位问题的能力。动手之前我会先花大量时间思考四件事数据从哪里来、模型怎么迭代、服务怎么部署、效果怎么评估。这四件事构成了AI工程闭环的基本骨架。围绕它们的核心方法业界一般叫“AI工程化”本质就是把模型当作软件工程中的一个模块来管理而不是当作一个黑盒来供奉。1.1 AI工程的核心闭环数据、模型、服务、评估整个AI工程的运转逻辑可以拆成一条循环链路。数据环节负责采集、清洗、标注、版本管理模型环节负责训练、微调、量化、蒸馏服务环节负责把模型封装成API、处理并发、监控延迟评估环节负责回答“模型到底变好了没有”这个必须量化的问题。这四个环节不是线性的而是循环的。模型上线之后会产生新的用户反馈数据这些数据经过清洗和筛选又变成下一轮微调的原料。我在搭建第一个AI项目时犯过最大的错误就是把它做成了线性流程模型部署完就以为大功告成结果效果不好却没有任何数据支撑去定位原因。后来把评估环节前置在每次迭代前先定义好指标整个项目才进入良性循环。1.2 为什么选择从零搭建而不是直接用现成平台现在市面上的AI开发平台确实很多拖拽式工作流、一键微调、自动部署看起来很美好。但我坚持建议有一定技术基础的人走一遍from scratch的路线原因有三个。第一平台抽象程度高意味着你对底层细节的掌控力低。平台上的一个“数据集上传”操作背后可能是格式转换、去重去噪、分布校验一旦在平台里出了问题你能做的事情非常有限。第二平台的定价策略往往在你切换到自部署时才会暴露真实成本模型调用量上来之后按次计费的开销远超自己用开源模型部署的成本。第三AI工程能力本身是迁移的你在自建项目里积累的经验才是真正能带走的资产。当然我不是说完全不用平台。在实际工作中混合模式效果最好。比如评估部分的标注可以借助人工标注平台数据处理部分可以用现成的开源库。但核心链路尤其是模型服务和数据管线值得自己亲手搭一遍。2. 核心组件选型解析哪些工具值得一用哪些坑别踩从零搭建并不意味着所有组件都从零编写。真正高效的路线是理解每个环节的职责边界然后选择最合适的开源工具把它们嵌进自己的体系里。这一章节我会按照工程架构分层来讲透选型逻辑聊清楚每个组件为什么值得选以及背后容易踩的坑。2.1 代码与协作基础Python工程化栈AI工程的基础语言基本就是Python这一点没有太大争议。但“用Python”和“用Python做工程化”是两码事。我的建议是重视依赖管理和项目结构哪怕你只是一个人在做项目。具体落地时依赖管理我推荐用uv或poetry来替代裸pip加requirements.txt的组合。裸需求文件在环境复现时经常出现依赖地狱的问题今天能跑明天不能跑这个问题在AI项目里尤其严重因为涉及CUDA、torch等重量级依赖。用工具锁定精确版本之后整个项目的可复现性会有质的提升。项目结构上我会按数据、模型、服务、评估四条主目录组织代码。不要小看这个习惯当你项目做到第三个月回头去找一份清洗脚本时一个清晰的目录结构能帮你节省大量时间。这个阶段不用做什么高深的事把地基打实后面的每一步都轻松。2.2 数据流通基础设施从原始数据到高质量语料数据环节是整个AI工程里最耗时但最容易被低估的部分。我自己的经验是一个成熟项目里数据准备的工作量通常占60%以上而且这个比例随着模型能力增强还在上升。数据环节的核心工具可以分为采集、处理、存储三块。采集侧如果是做垂直领域应用通常需要自己写爬虫或对接第三方API获取原始数据。这里需要特别注意合规性问题优先使用公开数据集、已授权数据源或自己业务产生的数据。处理侧我强烈推荐认真使用Pandas配合Datasets库做统一的数据集格式管理。Datasets库里的Dataset.map和Dataset.filter方法在处理大规模语料时效率很高而且能直接和后面的训练框架对接。存储侧的选择有讲究。小规模项目用Parquet文件就能满足需求配合HuggingFace Datasets的缓存机制读写都很顺畅。数据量上到TB级别时再考虑引入文件型数据湖方案。不要一开始就上重型中间件AI项目的数据问题往往先出现在数据质量而非数据容量上。2.3 模型微调与预训练的路线选择模型环节首先要回答的问题是你真的需要从零预训练吗绝大多数场景都不需要。你需要做的是选择一个合适的基础模型然后在自己的领域数据上做微调。基础模型的选择我建议优先考虑开源生态最活跃的几家。模型的具体选择取决于你的业务场景比如中文场景优先考虑训练语料中文占比高的模型代码场景优先考虑代码语料占比高的模型。国内的智谱、阿里、DeepSeek等厂商也在持续贡献高质量开源模型选择时可以多对比。微调框架方面现在最主流的路线是低秩适配技术。这类方法只训练一小部分参数显存占用低而且效果在很多场景下接近全量微调是目前性价比最高的微调方式。框架层面我常用HuggingFace的PEFT配Transformers配合TRL库里的监督微调、DPO等训练流程数据集准备好之后只需几行配置就能跑起来。这里必须强调一个很多人忽略的细节微调前一定要先跑通推理验证流程。先把要用的基础模型加载起来写几个测试用例跑一遍确认它的输出风格和能力边界。这个步骤能帮你建立微调前后的效果基线否则你根本不知道微调到底带来了多少提升。2.4 推理服务化与性能优化工具模型训练完只算走了一半另一半是把它变成真正对外可用的服务。推理服务化要考虑三个核心指标吞吐量、延迟、显存占用。这三者是互相制约的实际调优时需要按业务场景取舍。小规模试点可以直接用Transformers的Pipeline加载模型再用FastAPI包一层接口。但这个方案只适合日请求量在几百次级别的场景。当并发上来之后必须引入专门的推理加速方案。目前开源生态里最主流的方案是vLLM它通过PagedAttention优化显存管理吞吐量相比原生推理提升显著。连续批处理机制让它在高并发场景下表现很稳定这几个方向上它基本是标配。如果你有更极致的性能需求可以进一步引入量化方案把模型压到4bit或8bit精度。量化会带来一定程度的精度损失但结合蒸馏等方法可以在损失可控的情况下大幅降低显存占用和推理延迟。我用2块消费级显卡跑70B级别模型做离线任务的经验就是靠量化实现的功能效果虽然没有满血版好但性价比极高。2.5 Agent与编排层从单模型到多智能体协作单模型能力再强也只是在回答“这个输入对应什么输出”的问题。真实业务需要多步决策、工具调用、任务拆解这就必须引入Agent的概念。Agent不是某个具体模型而是一种编排多个模型和工具来完成复杂任务的工作流架构。搭建Agent工作流时当前推荐的路线是基于图编排的框架。以LangGraph为例它允许你定义节点和边的状态图每个节点可以是一个模型调用、一个API请求或一段逻辑代码状态图本身是持久化的适合构建复杂的执行流。另一个常用选择是Dify它提供了完整的可视编排、数据集管理、插件体系适合快速搭建企业级应用。两者各有优势写代码为主的项目选LangGraph这类灵活性更高的方案重运营的应用原型验证选Dify这类效率优先的方案。Prompt Engineering是Agent工作流里绕不开的环节但这几年大家逐渐形成了一个共识与其花大量时间精心构造Prompt不如用结构化的Few-shot示例并借助更好的模型来提升效果。经验数据表明同等情况下经过系统化Prompt优化的开源模型产出的质量明显更好。Prompt工作中最核心的其实是意图识别和任务分解而不是华丽的提示词模板。2.6 评估体系没有度量就没有迭代最后一个核心组件是评估这也是最容易被新手忽略的部分。很多人做AI项目时只关注“模型能不能答对”却没有一个系统化的评估体系导致每次改动都凭感觉判断好坏。我搭建评估体系时的核心思路是三层嵌套。最底层是单元评估针对单条输入检查输出是否符合预期可以用规则匹配也可以用子模型打分。中间层是场景评估把多条相关用例组合成一个业务场景检查模型在场景内的整体表现。最顶层是用户反馈捕获在线上服务里埋点记录用户对模型输出的行为反馈比如点赞、点踩、复制、放弃等。大型语言模型类的应用还可以引入参考模型评估方法用更强的模型充当裁判对输出质量打分。研究表明这种方法在多个评估维度上与人工评估的相关性很高。实践中建议每次评估都保存详细的评测样本和打分日志方便后续回溯对比。有了这套体系你做任何模型迭代时心里都有底。3. 实操全流程记录从数据处理到Agent落地的一次完整走通理论讲再多都不如直接走一遍流程来得直观。这一章我会用一次真实项目经历作为样例记录从零到一搭建AI工程的完整操作过程。这整个流程跑下来大约花了两周时间每天平均投入两到三小时。3.1 数据准备构建领域指令数据集我当时的项目目标是做一个面向特定垂直领域的智能问答助手。第一步就是准备数据这一阶段的工作量占到了整个项目的四成。第一搜集原始语料。我从业务团队那儿拿到了过去一年累积的问答记录包含大约两万条真实问答对。这些数据的优点是真实反映用户需求缺点是噪音很大。问答里混着大量口语化表达、错别字、不完整问题和重复内容。第二设计数据清洗流程。我用Datasets库加载原始数据先做了精确去重和模糊去重。精确去重很简单模糊去重我用的是MinHash方法做文本相似度计算将相似度阈值设为0.85去掉了一批重复提问的问答对。然后写规则清洗掉含敏感信息、无实质内容的样本最后剩下大约一万八千条高质量问答对。第三构造指令格式。为了让模型学习到更丰富的指令理解能力我把所有问答对转换成统一的指令模板加入系统提示、用户指令、模型回答三个字段并通过指令模板生成策略将同一批问答对改写为不同语气和格式的指令样本把数据集扩充到两万五千条左右。这一步直接关系到微调后模型的泛化能力。3.2 模型微调从基座模型到领域模型数据备好后模型微调环节的实操空间相对标准但有几个关键细节很值得记录下来。选择基座模型时我对比了多个候选模型的参数规模和训练语料特点考虑到领域知识偏中文且需要较强的指令跟随能力最终选择了Qwen系列模型的中等规模版本参数量在7B级别。7B模型的优势是单张24GB显存即可完成微调推理时的显存占用也在可控范围内。微调框架采用了LLaMA-Factory它是目前开源生态里对新手最友好的微调工具之一。配置文件里设定了学习率2e-5、批次大小2、梯度累积步数8。这里有个经验值得说明学习率的选择很关键2e-5是一个经过大量实践验证的稳定起点过大会导致灾难性遗忘过小则模型学不到领域特征。训练轮数定在两轮配合余弦退火的学习率调度器处理整体训练时间大约三个多小时。训练完成后用PEFT库做了低秩适配权重和基座模型的合并这一步是为了后续推理时不需要额外加载适配器层简化服务部署的复杂度。合并后的模型大小大约14GB单张显卡可以直接加载。3.3 推理服务搭建从测试脚本到标准API模型微调完成后我把服务端版本先放在本地跑通推理验证流程测了一组训练时留出的验证集样本确认效果可接受之后才开始搭API服务。推理方案我选了vLLM它的部署方式很简洁一条命令就能启动OpenAI兼容接口。这种方式有个很大的好处下游业务系统可以直接用标准的API调用方式接入不用为每个模型适配一套专属接口。启动时设定了最大并发请求数和最大上下文长度启用连续批处理机制实测单卡吞吐量比原生Transformers推理提升了数倍。我用FastAPI写了一个薄薄的业务适配层放在vLLM接口和业务系统之间负责处理鉴权、请求转发、响应格式化、以及关键请求的日志记录。日志里记录每次请求的输入、输出、响应时间和token消耗量这些数据是后续评估和迭代优化的数据资产。整个服务用Docker容器化部署通过环境变量配置模型路径和端口参数。3.4 接入Agent工作流完成业务闭环服务搭建完成后我基于LangGraph设计了一个包含意图识别、知识检索、答案生成三个节点的Agent工作流。意图识别节点用一个小模型做分类判断用户问题是知识咨询类、操作指引类还是闲聊类。知识检索节点把用户问题向量化后在知识库中做相似度检索把检索到的相关内容块拼入上下文。答案生成节点走vLLM接口在用户原始问题和检索结果的基础上生成最终答案。检索部分我用了一个很轻量的方案把知识文档切块后用向量化模型做索引配合向量数据库做近似搜索。没有引入重排序模型在这个业务场景下Top-5的召回结果直接送进生成环节效果已经够用。整体走通后我又在服务层加了基础的可观测性能力。日志里记录每个节点的响应时间、token消耗和检索到的知识块标识方便定位延迟瓶颈和错误的检索结果。这套轻量级的可观测性体系让项目后续迭代时少走了很多弯路。4. 常见问题与排查技巧实录AI工程从零搭建的过程中遇到的坑往往比预想的多得多。这一章我把实际项目中踩过、填过、甚至还在踩的坑整理成一个问题速查表附带排查思路和解决实操方法希望帮你少走一些弯路。4.1 训练不收敛或效果奇差的排查路径微调后模型效果不升反降这种情况在初学者项目里非常常见。排查顺序很重要我会按成本从低到高逐个检查。先用一个最简单的方法判断问题方向加载基座模型与微调模型输入相同的若干条测试样本对比输出的差异性。如果两者输出几乎一样说明微调没有充分学到目标数据分布优先调大学习率或延长训练轮数如果输出完全跑偏说明模型灾难性遗忘优先调小学习率或增加通用语料比例。很多效果问题的根源其实在数据侧。常见的问题一是指令模板不一致训练时用了“请回答以下问题”推理时却用“帮我解决”导致模型懵了二是数据分布过于单一训练集全是一种语气格式模型只学会了对应模板泛化能力自然差。这方面没有捷径必须老老实实清洗和扩增数据。4.2 显存不足和推理延迟的实用解法显存溢出是每个做大模型工程的人都会撞上的墙。我遇到的情况是7B模型的全精度推理就已经接近24GB显存上限并发稍高就触发溢出。最直接的解决方法是加载量化版本把模型权重的精度从float16降到4bit显存占用直接砍半推理速度反而可能提升。这里推荐AWQ或GPTQ格式他们是目前量化格式里效果损失较小、兼容性较好的方案。如果还想进一步压低显存裁剪上下文长度或者改用更小的模型是可行的兜底方案。推理延迟的排查思路是先分清瓶颈在模型计算层还是服务架构层。快速验证方式是压测工具直接对模型服务发请求看吞吐量如果模型本身的每秒请求数偏低需要关注vLLM的批处理配置和显存预留空间。如果模型本身吞吐不错但业务侧延迟高重点看网络、接口转发和序列化开销。4.3 输出质量不稳定与幻觉问题模型输出时好时坏是评估体系建设不完善时最常见的症状。这类问题不能靠“再改一版Prompt”来解决一定要回到数据和评估两个体系里找原因。首先把同一条问题重复测试多次摸清输出的随机性。如果输入完全相同但输出差异很大检查推理参数里的温度系数设置偏高会带来更强的随机性偏低则输出更稳定但可能重复。业务场景里我通常把temperature控制在0.3以下。幻觉问题的排查核心是查看检索增强部分的前置产出质量。如果检索到的上下文本身就不相关那么模型在生成回答时更容易产生不可信的内容。我建立了一份“幻觉案例日志”定期收集用户反馈中疑似幻觉的记录并反推当时的输入上下文分析是检索失败还是生成过度发挥。持续迭代后幻觉发生频次能明显降低。4.4 微调失效为什么加了数据模型反而不听话这里面有个很典型的认知落差部分工程师以为喂的数据越多效果越好但实际上模型微调是质量远比数量重要的工作。我试验过一次把网上爬来的数万条弱相关语料直接灌进模型结果模型学会了在这些语料上反复绕圈子反而忽略了原本掌握的通用能力。那之后我做了一轮清理工作把数据集压缩到数千条高质量样本效果明显回升。这个经验说明一个问题数据准备决不能“多而滥”必须“精而准”这比任何模型参数的调整都更影响最终效果。关于数据清洗还想补充一个容易忽略的细节标注一致性。即便是人工标注的数据不同人的标注风格也会带来差异。AI Agent辅助预标注加人工审核修正比纯人工标注的稳定性要好很多而且效率提升明显。对需要持续迭代的项目最好提前拟定清晰的标注规范。5. 一些值得分享的实操心得与扩展建议在这个项目里踩过不少坑也积累了一些值得分享的心得体会。整理几条我觉得对后来者最有价值的经验作为收尾也算给这篇完整的工程记录做一个真实落地的注脚。5.1 流程规范比技术炫技更重要整个项目走下来我最深的一个体会是AI工程里真正稀缺的不是技术技巧而是流程规范。数据有版本、模型有标签、评估有记录、服务有日志这四件事做到位项目就已经成功了一大半。自动化是保证流程规范落地的重要手段。GitHub Actions或类似工具可以做训练流水线的定时触发模型产物记录每次训练的超参数和数据版本确保任何时刻可以复现线上的模型。这让我在多个项目的迭代过程中始终能快速定位线上表现异常的训练版本不用靠回忆猜测。测试先行也是同样的道理。我在项目后期强制自己在微调前先跑一组固定的验证用例包含业务核心场景、边界情况、敏感内容过滤只有验证用例通过才允许模型上线。这个习惯在多次模型迭代中被证明是防止线上退化的最佳防线。5.2 这个项目的后续扩展方向当前完成的是一套基础但完整的AI工程闭环后续的扩展方向还很明确。一是引入更完善的多智能体协作机制用多个专注单一任务的子Agent协作处理复杂业务配合图编排框架迭代成一套独立的智能体团队体系。二是在线学习管道把用户反馈数据回流到评估数据集定期触发增量微调。三是对接多模态能力在当前文本问答的基础上扩展图片输入和RAG场景中的多模态知识解析。这条扩展方向需要介入更底层的多模态模型架构对工程侧的能力挑战也更大。四是在评估层面引入更细粒度的自动化质量指标以降低对人工标注的依赖。这个项目的完整意义不在于提供了多么高深的技术方案而在于给所有想真正掌握AI工程能力的人提供了一条可行的从零到一的路径。跟着这套流程走下来后面做任何垂直领域的AI应用你都能走得更稳更快。