企业官网建设流程全解析

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应用，你都能走得更稳更快。