企业官网建设流程全解析

我在后台经常看到一类私信，说自己在学Python、看了不少机器学习入门课，但一打开AI工程（AI Engineering）相关的岗位要求就懵了，什么RAG、向量数据库、模型微调、Prompt工程、模型评估，这些名词全都认识，但就是不知道从哪儿开始学、怎么把它们串成一个能跑起来的系统。这个项目名起得挺直白——ai-engineering-from-scratch，意思就是从零开始，把AI工程这条线完整地走一遍。

这篇内容我想结合自己的实操经验，把"从零学AI工程"这件事拆开揉碎讲清楚。先说清楚AI工程到底是什么、和AI研究有什么区别；然后把学习过程中真正需要掌握的核心知识栈列一遍，哪些必须啃、哪些可以缓一缓；接着用一个端到端的企业知识库问答项目做例子，带你把AI工程从数据准备到模型调用再到部署评估的完整流程走通；最后聊几句我在学习和落地过程中踩过的坑，尤其是那些资源规划和学习顺序上特别容易犯的错误。

无论你是刚看完Python基础课准备转行，还是已经做了几年后端开发想往AI方向靠，这篇文章应该都能给你一条明确的路径参考。它能帮你少走不少弯路——因为这些东西，我基本都是一个个坑踩过来才明白的。

1. 先说清楚：AI工程和AI研究不是一回事

1.1 你以为的AI工程师，和你实际要做的AI工程师

我刚开始接触这个领域的时候，以为AI工程就是把论文里的模型跑起来。后来发现自己完全想偏了。AI研究（AI Research）的核心任务是探索未知——比如设计一个新的网络结构、提出一种新的训练策略，目标是发论文、做实验，指标好就是胜利。但AI工程（AI Engineering）的核心任务完全不同，它是在各种现实约束下，把已经存在的模型和算法组合起来，变成一套能稳定运行、能被用户使用的系统。

这么说可能还是有点抽象，我换个类比。AI研究有点像实验室里的药剂研发，重点是把分子结构搞清楚，验证它对某种病有效。而AI工程更像是药厂里的生产线，你不只关心药效，还得关心生产成本、稳定性、包装运输、保存条件、能不能规模化生产。同一个药，在实验室里做出来和做成千万人能用的一盒药，中间隔的正是"工程"。

所以你在AI工程里遇到的核心问题往往是这些：

• 模型效果还行，但推理速度太慢，用户等不起。
• 召回质量不错，但整个链路偶发报错，偶尔还会把无关内容拼进上下文。
• 模型API调用的成本越来越高，怎么在效果和费用之间找平衡。
• 线上模型表现突然变差，是数据分布变了，还是上游某个环节出了问题。

这些问题没有一个能靠"调一个更好的模型"直接解决，它们需要的是系统工程能力。

1.2 判断你的学习策略对不对

因为很多人把AI研究和AI工程混为一谈，学习策略就容易跟着跑偏。最常见的情况是：花了好几个月啃深度学习理论，各种损失函数、反向传播推导都会了，结果一到真实的项目场景，连一个最简单的文本分类任务都部署不到生产环境里去。

反过来的问题也有，就是完全不做理论学习，直接拿工具拼装。今天调一个LangChain，明天跑一个Stable Diffusion，效果出来还挺高兴，但一旦遇到报错、性能瓶颈、或者需要定制逻辑的时候，就彻底抓瞎了，因为你不理解底层在发生什么。

给你的判断标准很简单：如果你学完一个知识点，能清晰地说出它在真实系统里解决什么问题；你做一个功能时，能说清楚每一步的原理和你为什么这么设计——那你的学习路径基本是对的。如果只是记住了概念、能跑通Demo，那大概率还停留在"会使用"而不是"会工程"的阶段。

2. 从零搭建AI工程的核心知识栈：到底要学什么

2.1 数学基础：不需要当数学家，但要有"能看懂公式"的能力

很多零基础的朋友一听到数学就头皮发麻，这里我可以负责任地告诉你：AI工程对数学的要求，远没有你想象中那么高。

你不需要去证明什么定理、不需要深究矩阵分解的全部细节，但你需要具备的能力是：看到一个公式，能理解每个符号代表什么、整体在做什么运算。微积分重点掌握导数和梯度下降的关系，线性代数重点掌握矩阵乘法、维度和向量空间的概念，概率论重点掌握条件概率、贝叶斯公式、期望和方差。

这些知识的作用是帮你理解模型内部的机制。比如embedding（向量化）为什么能把语义相近的句子映射到相近的向量空间，这背后就是高维空间中的几何关系；Transformer里的注意力机制为什么能学到"词与词之间的关联强度"，本质也是一个加权计算。你不需要重新发明这些，但你会更清楚调参时自己在调什么。

2.2 编程与工具链：Python是起点，但不止于Python

Python是AI工程的第一语言，这一点没什么争议。但如果你只会写Python、只会用Jupyter Notebook，离真正的AI工程还有距离。因为生产环境不是Notebook，它是模块化代码、版本管理、容器化部署、管道调度这些东西的组合。

我个人建议的基础工具链清单是这样的：

• Python编程：掌握面向对象、异常处理、装饰器、生成器这些高级用法，不用精通，但要能在实际项目里流畅使用。
• Linux基础：因为绝大多数训练和部署环境都是Linux服务器。常用的文件操作、进程管理、环境变量、磁盘空间这些命令要手熟。
• Git：这是协作和版本管理的命根子。模型代码、配置、Prompt模板，全都应该被版本管理。
• Docker：容器化是部署的基石。至少会写一个简单的Dockerfile，知道怎么构建镜像、怎么映射端口。
• SQL和数据处理：真实项目里九成时间花在数据上，会SQL能让你从数据源到特征的转化过程顺畅很多。

这些技能不需要一次全部学完，但它们是AI工程这座房子的地基。地基不稳，后面盖的每一层都会晃。

2.3 机器学习与深度学习的核心概念

机器学习这一块，重点不是让你把sklearn里每个算法都搞明白，而是建立几个贯穿AI工程的核心概念：

• 监督/无监督/强化学习的区别和适用场景。
• 过拟合与欠拟合：模型在训练集上表现很好、测试集上表现很差，这是工程里最常遇到的经典问题。
• 评估指标：准确率、召回率、精确率、F1得分、AUC，以及什么时候该用哪个。
• 特征工程：对结构化数据来说，特征的好坏比模型本身更影响效果。
• 训练集/验证集/测试集的划分逻辑：这是很多人容易忽略、但至关重要的一步。

深度学习部分，核心理解几条线就够了：神经网络的前向传播和反向传播，激活函数为什么要非线性，优化器（SGD、Adam这些）在干什么，过拟合的正则化手段（Dropout、权重衰减）。不用去扣繁琐的推导，但要能理解每个设计解决什么问题。

2.4 AI工程的系统知识：比模型更重要的半壁江山

模型训练只是AI工程中很小的一部分，甚至可以说，在今天的开源生态下，很多场景你根本不需要自己训练模型。AI工程真正的核心知识栈，应该覆盖一个系统的完整生命周期。

数据层要懂怎么采集、清洗、去重、标注、版本管理；特征与训练层要懂怎么构建训练集、怎么选模型、怎么做实验管理；部署与在线层要懂怎么把模型包装成服务、怎么做负载均衡和缓存、怎么监控线上效果；评估与迭代层要懂怎么建立一套自动化评估流程，让每次修改都能量化地判断效果是变好还是变坏。

我把常用领域和知识重点整理成了表格，方便你对号入座自查：

之所以单独强调评估体系，是因为这是AI工程和AI实验最大的区别之一。实验里你只要跑几十个epoch看loss就行，但工程上你要持续回答一个问题："这版改动到底是不是比上一版好？"没有一套可靠评估机制，后面所有的迭代都是在盲猜。

3. 打通第一条实战主线：用RAG案例走完AI工程全流程

3.1 为什么我推荐第一个完整项目做RAG

如果你刚入门AI工程，我强烈建议你的第一个完整项目做检索增强生成（Retrieval-Augmented Generation，RAG），而不是一上来就微调大模型或者训练自己的模型。

原因是RAG这个方向几乎覆盖了AI工程的每一个关键环节：文档处理、文本切分、向量化、向量检索、大模型调用、Prompt设计、效果评估、部署上线。它本身就是一套完整的小系统，但每个环节的技术门槛又相对适中，非常适合用来建立全局观。

更实际的理由是：RAG是目前企业中落地最多、需求最广的应用形态，企业内部知识库问答、客服助手、文档审阅、合规检查，大量真实场景都是RAG的变体。学会RAG，你基本就掌握了AI应用开发的主干技能。

3.2 需求定义与场景假设

我用来演示的项目场景你肯定遇到过：一个公司想把内部的产品手册、售后文档、FAQ做成人人可用的问答助手，让客服和用户可以快速找到答案。

第一步不是写代码，而是明确需求和数据情况。你需要列出这几个硬信息：数据文件有哪些格式（PDF、Word、Markdown？）、数据总量大概多大（几千字还是几百万字？）、更新频率多高（每周更新还是半年更新一次？）、回答的形态是什么（纯文本，还是带上出处引用？）、并发量大概多少（几个人查询，还是面向外部用户高并发？）。

这些信息直接决定后面的选项。比如数据量只有几千字，那可能不需要上重型向量数据库，一个轻量级的方案就够了；如果并发大，就要考虑服务部署和缓存策略。

3.3 数据准备：清洗与切分的细节问题

第二个环节是数据处理。很多人会直接拿原始文档一股脑丢给向量化模型，结果检索质量惨不忍睹。问题出在数据没有整理干净。

你需要做的第一件事是格式归一化。PDF要解析出文本，表格要尽量提取成结构化格式，扫描件要OCR，图片里的信息要单独考虑。这一步做不好，后面Embedding出来的是垃圾，检索出来的也是垃圾。

第二件事是文本切分。切分策略对检索效果影响极大。经验上，一个检索单元的文本块（chunk）保持在300到500字左右比较合适，如果你用的是中文语料，大概一到两个完整的知识条目。太小了信息不完整，太大了检索的精度差，TOP-K结果里容易混入大量无关内容。切分时要加overlap（重叠区），一般取10%到20%，这可以避免切分线恰好切断一个完整语义单元。

我自己常用的是递归字符切分器，先按段落切，再按句子切，这样能最大程度保留语义完整性。但记住，切片规则没有银弹，一定要结合你的文档结构来调整。如果文档本身有明显的小节标题，最好先按标题结构切成父子块，检索时用父块提供上下文、子块提供精确片段。

3.4 Embedding选型与向量库存取

文本切分完之后，进入向量化环节。Embedding模型的核心指标有两类：一是语义表达能力，通俗说就是相似的两句话能不能在向量空间里挨得近；二是维度，维度越高，单个向量占的存储和计算开销越大，但通常检索精度也会更好。

开源场景里，中文常用的是BGE系列和M3E系列；如果你的使用场景英语居多，OpenAI的Embedding接口或开源的Sentence-Transformer系列也都很成熟。我自己在中文企业文档场景实测下来，BGE-large-zh的检索效果明显好于通用多语言模型，但在资源受限的笔记本上，M3E-base是更务实的折中。

向量数据库的选型取决于你的数据规模和部署方式，我列出几种常见方案：

• 轻量场景（本地学习/小数据量）：SQLite加sqlite-vec扩展，或者用Chroma，几分钟就能跑通。
• 标准场景（万级到百万级向量）：Milvus或者Qdrant，检索速度和扩展性都不错。
• 已有PostgreSQL的场景：直接用pgvector扩展，减少一套新组件，运维更省心。
• 生产级高可用场景：云厂商的向量检索服务，免运维，自带监控和高可用。

这里要强调一个容易犯的错：不要一开始就纠结"哪个向量数据库最强"。在项目起步阶段，它们带来的差异远不如数据质量和Embedding模型选型带来的差异大。先跑通、再优化，这个顺序不要搞反。

3.5 检索与生成的组装：Prompt的设计逻辑

有了向量库，核心链路就是"问句向量化 -> 向量相似度检索 -> 组装上下文 -> 调用大模型 -> 返回答案"。这里面最容易出错、也最值得打磨的是检索结果的组装和Prompt设计。

检索出来的TOP-K结果，一般取3到6块就够用了。取了之后不是直接塞给大模型，你需要做几件事：一是过滤掉相似度明显不达标的文档块，宁可答不了也不要给用户编造答案；二是按原文顺序重新排列，不要让模型看到一个语义跳跃的文本碎片；三是在Prompt里明确交代角色、任务、资料范围、回答限制和输出格式。

我常用的Prompt骨架大致是这个样子：

你是一个企业知识问答助手。请根据提供的资料回答问题。 资料内容： <资料> {context} </资料> 要求： 1. 优先使用资料中的信息作答，不要编造。 2. 如果资料中没有答案，请直接说明"资料中未找到相关内容"。 3. 回答时标注引用编号，例如[1]、[2]。 4. 保持简洁，控制在200字以内。 用户问题： {question}

这个模板看起来简单，但每个要求都是血泪教训换来的。比如"不要编造"是在堵住幻觉的漏洞，标注引用是为了让用户能溯源，控制长度是为了兼顾Token成本和阅读体验。你不需要一开始就设计得很完美，但要养成"每个Prompt元素都有明确目的"的习惯。

3.6 评估与迭代：这套系统怎么持续变好

RAG系统上线之后最大的挑战是：你说不清楚它到底好不好。答案不是能跑就行，而是要有量化的评估。

第一个要建的东西是评测集。我从实际项目中总结出来的做法是这样的：挑选50到100个真实用户问题，给每个问题标注标准答案或至少标注它对应的正确资料段落。这些问题要覆盖正常提问、换一种说法提问、专业术语提问、资料里没有答案的问题这几种情况。构建集的时候和你实际场景的分布越接近，评估结果就越有参考价值。

第二个是做效果回归。每次改动（换了Embedding模型、改了切分策略、调了Prompt、换了模型）之后，把评测集整体跑一遍，记录三项指标：命中率（检索到的资料包含正确答案的比例）、准确率（最终回答的正确率）、拒答率（无准确把握时果断说不的能力）。任何改动都要用数据说话，而不是靠"我感觉好像变好了"。

这套评估体系就是整个AI工程的定盘星，也是你从新手转向成熟工程师的分水岭。我见过太多团队Demo很惊艳、一上生产就翻车，根源就是没有建立这套体系。生产环境和Demo最大的区别，是生产会一直变，你必须有能快速判断好坏的工具和流程。

4. 学习路径里的常见误区与实用避坑指南

4.1 误区一：无止境地刷课程，就是不碰项目

这是最典型、也最伤时间的坑。"我要把机器学习的基础系统学完再动手做项目"——这种思维在AI工程领域是行不通的。AI工程不是线性学科，它的知识结构更像是一张蜘蛛网，你先掌握一个节点，然后顺着边爬到其他节点，反复迭代，网才会密起来。如果非要先织完整张网再出发，你会永远停在第一根线上。

我的建议是：用70%的时间做项目，用30%的时间补理论。项目遇到瓶颈时，带着问题去查书、看文档、读博客，这种"以用带学"的方式比漫无目的地刷课高效得多，因为你理解每一个知识点的背景和动机，记忆也会深很多。

4.2 误区二：一上来就追求训练和微调大模型

如果你手里没有一块24GB显存以上的GPU，别轻易把第一个项目定为"微调一个大语言模型"。不是说这件事不重要，而是它的前置条件和投入产出比不适合零基础阶段。

举个实际的数字例子：一个70亿参数（7B）的模型，用FP16精度训练，仅模型参数就要占大约14GB显存，再加上梯度、优化器状态和中间激活值，保守估算也要50到60GB显存。普通消费级显卡根本装不下，即使强行用LoRA把显存需求降下来，你也会发现大量时间耗在环境配置和错误排查上，真正学到东西的时间反而很少。

相比之下，RAG项目用到的模型基本是Embedding模型（通常只有几亿参数）和现成的大模型API，CPU也能跑，成本低还能学到完整的工程链路。微调这件事，等你把应用层摸透了、明确知道现有模型在哪类问题上不够用的时候再学，效率会高很多。

4.3 误区三：把最新论文当成万能钥匙

AI领域的节奏非常快，每周都有新模型发布，技术社区里永远有人在讨论"XXX又刷新了SOTA"。但这里有个反直觉的事实：在工程落地中，最新最强的模型往往不是你该优先选的。

原因有几个。模型越新，相关资料越少，踩坑了能搜到的解决方案也越少；模型越强，通常也越贵、越慢，你的场景可能根本用不到那么强的能力；模型更新太快，你如果每次都追最新，就没有任何积累，因为上一个还没学透就过时了。

我在生产环境里的选择逻辑是：优先选相对成熟、生态完善、社区资料丰富的稳定版本。效果够用是第一原则，能力过剩是浪费。创业公司尤其如此，你花两个星期把一个新模型接进来，结果它在一个月后被另一个新模型取代，这个时间的浪费是致命的。

4.4 误区四：只学工具，不透原理

这个坑发生在有一定基础、爱追热点的开发者身上。今天看到LangChain火，学了，明天看到LlamaIndex有意思，又去试，后天看到新的Prompt技巧，赶紧抄过来。工具用得很溜，但让你解释LangChain内部是怎么管理记忆和调用的，就说不出来了。

我在实际中遇到过一个场景：某个同事实现的Agent应用出了Bug，他左调右调都不行。我去看代码，发现他其实不理解LangChain里Agent的核心循环——模型要经历"思考-行动-观察-再思考"这个循环，每一步都对应一次模型调用和工具调用。他以为是一次魔法，出了错自然无从下手。

工具会演化，今天流行的框架明天可能就被更好的替代，但底层原理是相对稳定的。你理解了LLM的输入输出规律、理解了向量检索的基本机制、理解了上下文窗口的约束，换任何工具都只是适应API的问题。

4.5 避坑心得：我踩过最深刻的那个坑

聊到坑，我记忆最深的一次是自己的数据管线问题。当时我给一个客户做领域问答，评测集上效果一直不错，但上线后回答经常出现明显的时效性错误。排查了很久，找了很多模型原因，最后发现是数据更新流程本身有问题。我用的数据同步脚本写错了文件路径，导致数据源一直停留在两个星期前的版本，线上的向量库根本就没更新过。

这件事让我养成了一个习惯：在任何AI系统里，遇到问题先去排查数据和流程，再排查模型和代码。数据错了，模型再聪明也是巧妇难为无米之炊。这个教训也建议你提前记下——AI工程的排错顺序永远是从底层往上查，数据问题排在第一位。

5. 没有高端GPU能不能起步？资源规划与硬件选型经验

5.1 算力焦虑：没有4090，也能把AI工程学透

每次有初学的朋友问我"没有高端GPU能不能学AI工程"，我都会给出非常明确的回答：完全可以，前提是你在学习阶段不要选错任务方向。

基于我自己的经验，没有高端GPU时你可以做的任务是这样的：Embedding模型和文本向量化，在CPU上跑完全没问题，几百MB参数的模型CPU推理也就几百毫秒；常用的大模型推理，可以调用云端的API服务，按量付费，成本对学习阶段完全可控；微调实验，可以用Google Colab的免费TPU或Kaggle的免费GPU，也可以租云实例，按小时计费，实验做完就释放。

这些路径加起来，足够你把AI工程的应用层、数据层、评估体系全部练熟。等到你真正需要自己训模型、自己微调大模型的时候，在很大程度上也已经知道了自己该买什么配置，到时候再投入硬件，比盲目买一台跑不动的机器有价值得多。

5.2 显存的计算方法和选型逻辑

如果你还是想购置自己的GPU，那我给你一套简单的显存估算方法。推理场景下，一个7B参数模型用FP16精度，显存需求大约是参数量的两倍，也就是14GB；用INT8量化会降到大约7GB；用INT4量化可以压到4GB左右。也就是说，一块RTX 4060 Ti 16GB基本能跑7B模型的INT8推理，一块RTX 4090 24GB可以比较舒服地跑7B模型的FP16推理和部分微调实验。

训练场景的显存需求要翻好几倍。以LoRA微调7B模型为例，靠优化器状态和梯度裁剪，最低也需要24GB左右；全参微调的话，没有80GB以上的大卡基本不要考虑。所以我给的建议是：预算有限的话先上24GB显存的卡，它覆盖的学习和实验场景最广；如果只是单纯做应用开发和API调用，那根本不需要买卡，先把需求跑清楚再说。

5.3 常用工具生态速览：哪些值得你现在就上手

最后简单介绍一下我常用的工具生态，按使用频率排序。HuggingFace是模型和数据集的中枢，不管是找模型还是找数据集都从它开始；Ollama适合本地快速运行开源模型，几行命令就能跑起来对话模型；LangChain和LlamaIndex是应用开发框架，前者更偏Agent和工具调用，后者更偏检索和数据框架；向量数据库方面，Chroma适合本地摸实验，Qdrant和Milvus适合做正经项目；评估方面，Ragas这类开源框架可以帮你套用现成的指标，但更关键还是搭建自己的评测集。

学会这些工具不需要全部精通，跟着你的项目走，用到什么学什么。今天用到向量数据库，就花半天把它的API过一遍；明天用到模型部署，就看看vLLM的用法。工具是为人服务的，人和项目才是主角。

关于AI工程从零起步这件事，我最后的体会其实只有一句：不要试图走一条完全笔直的路。AI工程是一个实践学科，它的所有知识都沉淀在"动手做出来"的过程里。你先跑通一个最小的RAG系统，然后把数据换得更复杂、把评估做得更严格、把部署做得更稳定——在这个不断循环里，你会自然地把数学、代码、模型、系统这些知识一块一块地拼接起来。别怕慢，别怕错，做得多了，路自然就出来了。