企业官网建设流程全解析

1. 先搞清楚：AI Engineering 到底是个什么方向

这几年“AI engineering”这个词被反复提起，但很多人其实没弄明白它跟机器学习工程师、算法工程师、数据科学家到底有什么区别。我自己带过几个从传统后端转过来的同事，也面试过不少自称“搞 AI”的候选人，最深的感触是：AI engineering 不是“会跑通一个模型”就完事的，它更接近一条完整的工程链路——从数据整理、模型选型、训练调优，到服务封装、性能压测、成本控制，再到线上监控和迭代更新，每一个环节都需要工程师自己扛下来。

换句话说，AI engineering from scratch 的意思是：你不依赖别人已经帮你封装好的全流程平台，而是从零开始，自己动手把一个 AI 应用从 idea 做成可用的产品。这条路适合谁？适合有软件开发基础、想切入 AI 领域的人，也适合已经在做数据分析或算法、但总觉得“模型一上线就各种翻车”的人。它解决的问题很具体：你知道模型怎么训练，但你知道模型上线后怎么稳定跑三个月吗？你知道数据集怎么构建，但你知道数据分布变化会让准确率一夜之间掉 20% 吗？

下面我会结合自己从零折腾到能独立交付 AI 项目的完整经历，把 AI engineering 的核心模块、实操路线和踩坑实录一次讲清楚。内容会比较长，但每一步都是能直接照着做的。

2. 从零开始的完整能力地图

2.1 先把基础语言和工具链打牢

不管目标多高，Python 这一关绕不开。AI 生态里绝大多数库、框架、工具都以 Python 为第一语言，虽然理论上可以用 C++、Java 或者 Go 来部署模型，但做实验、写训练脚本、处理数据、调接口，几乎全部是 Python 的活。我见过太多人一上来就啃 Transformer 论文，结果连DataLoader的collate_fn参数都搞不明白，这种学习路径效率极低。

基础阶段的重点不是刷语法题，而是围绕数据科学和 AI 常用的几个库建立手感：

• NumPy：张量和矩阵运算的基础，理解形状、广播、索引是底线。
• Pandas：表格数据处理，清洗、聚合、分组、透视表都要熟练。
• Matplotlib / Seaborn：画图分析数据的分布和趋势，不用多精美，但要能快速排查数据问题。
• Scikit-learn：经典机器学习算法、评估指标、交叉验证、特征工程的工具箱，是理解深度学习之前最好的“玩具”。

这个阶段最容易犯的错是陷入“教程地狱”——今天看 NumPy 教程，明天又去看 Pandas 教程，一周下来好像学了很多，实际一个完整流程都跑不通。我的建议是直接做一个端到端的小项目，比如用 Scikit-learn 对一份公开数据集做分类预测，从加载数据、清洗、画分布图、训练模型、评估效果，全部走一遍。跑通一个闭环，比看十遍教程都管用。

2.2 机器学习核心概念不能跳过

很多人觉得现在大模型时代了，经典机器学习可以不用学了，这是很大的误区。且不说很多实际业务场景里，XGBoost 或者逻辑回归依然是最稳定、成本最低的方案，更重要的是，机器学习的核心概念是理解深度学习和 AI 系统的基石。

必须吃透几个关键点：

• 过拟合与欠拟合：模型在训练集上表现好但验证集掉分，这就是过拟合。正则化、Dropout、早停、数据增强都是围绕这个问题来的。
• 训练集 / 验证集 / 测试集的划分逻辑：为什么不能拿测试集调参？因为信息泄漏会让评估结果虚高，上线后就露馅。
• 交叉验证的意义：小数据集上怎么稳定评估模型效果，K-Fold 是怎么工作的。
• 偏差与方差权衡：模型的误差来源到底是欠拟合还是过拟合，决定了你下一步应该加数据还是加复杂度。
• 损失函数与优化器：回归用 MSE 还是 MAE，分类用交叉熵，不同任务怎么选，梯度下降的变体为什么存在。

这些概念不是理论考试，而是工程判断的依据。举个最简单的例子：你训练一个模型，发现验证集损失先降后升，训练集损失还在降，如果你不懂早停和过拟合，你就不知道应该保存哪个时间点的权重，也就无法做出一个真正能用的模型。

2.3 深度学习框架怎么选

框架选型是很多人纠结的问题。我的结论很直接：新手首选 PyTorch，没有之一。原因有三点：

第一，PyTorch 的调试体验是动态计算图，print一个张量的形状、打断点、逐步执行都非常自然，这对初学者理解神经网络的运行过程极其重要。第二，目前学术界和工业界发布预训练模型几乎都首选 PyTorch 权重格式，Hugging Face 上的模型绝大多数都是 PyTorch 的，你用别的框架会平白多出很多格式转换的麻烦。第三，社区生态最活跃，遇到问题搜一下基本都能找到答案。

TensorFlow 和 PaddlePaddle 不是不好，但在通用 AI 工程领域，PyTorch 已经事实上成了默认选择。你如果是为了做业务应用而非特殊硬件适配，选 PyTorch 是最稳妥的。

这个阶段要动手实现的东西包括：手写一个简单的全连接网络跑 MNIST、用nn.Module搭建一个 CNN 做图像分类、用 LSTM 或者 Transformer 结构跑一个文本分类任务。不用追求 SOTA 效果，重点是理解forward和backward的过程、Dataset和DataLoader怎么写、模型权重怎么保存和加载。

2.4 LLM 时代的工程新范式

经典的深度学习路线走完后，要进入当前 AI engineering 的核心战场：大语言模型（LLM）的应用工程。这部分跟上面说的传统 ML 工程有重叠，但更多是新的模式和新的工具链。

需要掌握的内容包括：

• Prompt Engineering（提示词工程）：怎么写指令、怎么给示例（few-shot）、怎么设计角色和约束条件，让模型输出更可控。
• 上下文管理与 Token 计算：输入输出都按 token 计费，怎么截断、怎么分段、怎么控制长度上限。
• RAG（检索增强生成）：把私域知识库接进大模型，解决模型不知道最新信息或内部数据的问题。
• 模型微调（Fine-tuning）：什么时候该用 RAG，什么时候该微调，什么时候两者结合。
• 工具调用（Function Calling / Tool Use）：让模型调用外部 API、查询数据库、执行代码，这是 Agent 应用的基础。
• 向量数据库：Embedding 的存储和近似最近邻搜索，是 RAG 链路的核心依赖。
• 评估与监控：LLM 的输出没有固定答案，怎么评估质量，怎么捕捉模型退化。

从“训练模型”到“编排模型”，这是 AI Engineering 和传统 ML 工程最大的区别。传统 ML 是你训练一个模型，然后部署一个 API；LLM 工程更像是你手里有一个非常强但不太听话的“实习生”，你的工作是设计一套流程、工具和约束，让他稳定高效地完成具体任务。

3. 核心实践项目拆解

3.1 环境搭建的完整指南

环境问题是最劝退新手的第一道坎。我见过有人在 Windows 上装 PyTorch 折腾一整天，最后发现是 CUDA 版本和显卡驱动不匹配。这里先给一套稳妥的搭建方案。

建议直接用 Miniconda 管理 Python 环境，不要在自己系统全局环境里乱装包。创建一个独立的虚拟环境：

conda create -n ai-env python=3.10 conda activate ai-env

然后安装深度学习框架。如果你有 NVIDIA 显卡，先确认驱动支持的 CUDA 版本，然后用conda或pip安装对应版本的 PyTorch。官方安装命令生成页面会给你现成的命令，别再手动去下载 CUDA Toolkit 了，PyTorch 的 pip 包里自带 CUDA 运行时，你只需要驱动足够新就行。

# 以 CUDA 12.1 为例 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

没有独立显卡也没关系，CPU 版本照样可以学习和跑小型项目，只是训练速度慢一些。我早期就是拿笔记本 CPU 跑完了一个文本分类模型，分词、训练、评估全流程一点没耽误。

接着安装 AI 应用开发的核心依赖：

pip install transformers datasets accelerate sentencepiece pip install langchain chromadb pip install flask fastapi uvicorn

transformers是 Hugging Face 的核心库，负责加载预训练模型和 tokenizer；datasets是统一的数据集接口；accelerate用来做分布式训练的设备管理；langchain负责 LLM 应用编排；chromadb是本地的向量数据库，适合个人项目起步；fastapi用来把模型封装成 HTTP 服务。

提示：环境问题八成出在没有用虚拟环境，或者没有固定版本号。每次新建项目都建议先conda create，并在项目里写一个requirements.txt把关键包版本锁住，不然三个月后重跑大概率复现不了。

3.2 从一个真实的 RAG 问答系统开始

我强烈建议第一个完整项目不要做图像、不要做语音，做一个基于 RAG 的知识库问答系统。为什么选它？因为它几乎覆盖了 AI engineering 的全部核心环节：数据加载与清洗、文本切分、Embedding 模型选型、向量库构建、Prompt 设计、LLM 调用、服务封装、效果评估。而且它能直接解决真实问题——把自己的文档、笔记、合同、帮助中心变成问答机器人，做完就有实用价值。

系统架构很简单：离线阶段把文档拆成小块，每块文本用 Embedding 模型转成向量，存入向量数据库；在线阶段用户提问，把问题转成向量，在向量库里做相似度检索，取回最相关的文本块，连同问题一起拼进 Prompt，交给 LLM 生成回答。

我用一个具体例子来说明整条链路。假设你有一批 PDF 格式的公司制度文档，要做一个内部问答机器人。

第一步：加载和解析文档。langchain提供了PyPDFLoader可以直接读取 PDF，但要注意扫描版 PDF 没有文本层，需要 OCR，这是第一个容易踩的坑。我建议先用pypdf快速检测文本是否能提取，不行再上 OCR 方案。

from langchain_community.document_loaders import PyPDFLoader loader = PyPDFLoader("./company_policy.pdf") documents = loader.load() # 每页会返回一个 Document 对象，包含 page_content 和 metadata

第二步：文本切分是 RAG 效果好坏的关键。LLM 的上下文窗口有限，向量检索的粒度也影响召回质量。切太粗，一个块里混了多个主题，检索时噪音大；切太细，语义不完整，模型上下文不够。我常用的策略是先用RecursiveCharacterTextSplitter，以 500 到 800 个字符为一个块，重叠 50 到 100 个字符：

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=100, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) chunks = text_splitter.split_documents(documents)

separators这个参数很容易被忽略，它的含义是切分时的优先级顺序。按段落先切，不行按句号切，再不行按逗号。中文场景里，默认的英文分句符并不适用，必须把中英文标点都加进去，否则切出来的块经常断在半句话上。

第三步：Embedding 模型选型。中文场景下，我推荐用BAAI/bge-large-zh-v1.5或者shibing624/text2vec-base-chinese。直接用 OpenAI 的 embedding 接口也可以，但要考虑数据出境和成本，内网场景基本都是本地部署开源模型。加载 bge 模型的方式：

from langchain_community.embeddings import HuggingFaceBgeEmbeddings embeddings = HuggingFaceBgeEmbeddings( model_name="BAAI/bge-large-zh-v1.5", encode_kwargs={"normalize_embeddings": True} )

注意normalize_embeddings开启后，向量是归一化的，后续用内积和余弦相似度结果等价。很多教程不强调这一点，导致你比对相似度分数时总觉得不对劲。

第四步：构建向量库并写入。用 ChromaDB 起步最方便，它支持本地持久化，不需要单独跑服务：

from langchain.vectorstores import Chroma vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" )

每次跑完，向量数据会存在chroma_db目录下，下次直接加载不需要重新 embedding。

第五步：设计检索策略。最简单的是直接similarity_search取 top-k，但实际项目里我强烈建议做两件事：一是把k值调大一点（比如 6 到 8 个块），让 LLM 有更多素材可用；二是对召回的块加一个相关性过滤，设置相似度阈值，低于阈值的块直接丢弃，宁可少答也不要拿错误信息硬编。

docs = vectorstore.similarity_search_with_score(query, k=8) filtered_docs = [(doc, score) for doc, score in docs if score > 0.35]

这个 0.35 的阈值不是拍脑袋，是我在多个数据集上跑了交叉验证之后得到的经验值。不同 embedding 模型的分数分布不一样，你需要先拿几十条真实问题做测试，看正确答案的分数下限在哪，再设阈值。这一步是 RAG 效果优化的关键，很多人忽略，导致模型经常拿着不相关的文本一本正经胡说八道。

第六步：编排生成。用langchain的RetrievalQA链可以快速搭起来，但实际生产里我更建议自己写 Prompt 模板，这样可控性最强：

from langchain.prompts import PromptTemplate template = """基于以下已知信息，简洁准确地回答用户的问题。 如果已知信息中没有明确答案，请明确说"根据现有资料无法回答"，不要编造。 已知信息： {context} 用户问题：{question} 回答：""" prompt = PromptTemplate( template=template, input_variables=["context", "question"] )

然后组装完整的问答函数：

from langchain.llms import OpenAI from langchain.chains import RetrievalQA llm = OpenAI(model_name="gpt-3.5-turbo", temperature=0) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 6}), return_source_documents=True, chain_type_kwargs={"prompt": prompt} ) result = qa_chain({"query": "公司年假制度是什么？"}) print(result["result"]) print("参考文档：", [doc.metadata for doc in result["source_documents"]])

return_source_documents=True这一步很重要。它让你可以在回答下方展示“基于哪几份文档生成的”，既增加用户信任感，也方便你自己排查回答是来自可靠资料还是模型幻觉。

3.3 什么时候该微调，什么时候只做 RAG

这是 AI 工程里被问得最多的一个问题。我的判断标准很朴素：如果你的核心诉求是“让模型知道某个特定领域的知识”，首选 RAG；如果你的核心诉求是“让模型按某种固定风格、格式、行为模式输出”，微调更合适；更多时候两者是组合关系。

举个例子。如果你想做一个“懂你家公司所有产品手册”的客服机器人，知识是持续更新的，产品手册每个月都会变，你用 RAG 最合适——改文档、跑切分、更新向量库，就完事了，连模型都不用动。但如果你要做一个“把客户工单自动分类成 12 个优先级，并且输出固定 JSON 格式”的系统，这种任务的输入输出模式高度固定，few-shot 不一定稳定，那就值得做一次微调。

微调的门槛比 RAG 高不少。你需要准备几百到几千条高质量的训练样本，做数据格式转换、训练超参调优、效果评估，还要考虑算力成本。用 Hugging Face 的transformers和peft库做 LoRA 微调是当前的主流方案，因为 LoRA 只训练一小部分参数，显存和训练时间都大幅下降。

一个典型的 LoRA 微调脚本核心流程是：加载基座模型和 tokenizer → 用LoraConfig配置低秩矩阵参数 → 加载训练数据集 → 用Seq2SeqTrainer训练 → 保存并合并权重。这里不展开完整代码，但我想强调三个实操细节。

第一，基座模型的选择要考虑中文能力。Qwen、Yi、Baichuan这些中文语料占比较高的模型是更务实的选择。第二，训练数据格式必须统一，最常用的格式是"instruction"、"input"、"output"三段式，指令、输入、期望输出都要写清楚。第三，微调完成后一定要拿训练时没见过的测试集验证，我见过不少人微调完在训练集上效果惊艳，一上测试集就暴露过拟合，原因就是数据量太少或者学习率设置过高。

3.4 把模型封装成可用的 API 服务

模型跑通只是第一步，给业务方用才是工程真正的开始。现在最主流的方案是用 FastAPI 封装，配合uvicorn启动 HTTP 服务。

一个最简服务的结构：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI() class QueryRequest(BaseModel): question: str top_k: int = 6 @app.post("/qa") async def qa_endpoint(request: QueryRequest): try: result = qa_chain({ "query": request.question, "top_k": request.top_k }) return { "answer": result["result"], "sources": [doc.metadata for doc in result["source_documents"]] } except Exception as e: raise HTTPException(status_code=500, detail=str(e))

服务上线前必须考虑三个问题：并发量、超时时间、错误隔离。LLM 接口推理耗时通常是几秒到几十秒，如果用同步方式跑，并发一高 CPU 和显存直接被打满。实际工程里要用线程池或者异步任务队列，把推理放到后台执行，前端轮询结果。更重的场景要上消息队列加 Worker 的架构。

显存管理也是一个隐藏坑。Hugging Face 的pipeline默认会在显存里常驻模型，多个服务进程各加载一份权重，显存会成倍消耗。解决方案是用模型共享或者做成常驻单例，模型只在进程启动时加载一次，请求进来只做推理，不做重复加载。

4. 实操中的高频问题与排查技巧

4.1 环境与依赖问题速查

环境问题占了新手阶段 80% 的报错时间。我把最常见的几种情况和排查思路整理成一张表：

提示：遇到报错，先把完整报错信息贴到搜索引擎里，绝大多数问题都有人踩过。不要自己瞎改一通，我在调参上浪费的时间至少有一半是因为没耐心读报错信息。

4.2 数据质量与效果评估的隐形陷阱

AI 工程里有一句老话：垃圾进，垃圾出。模型效果不好，很多时候问题根本不在模型，而在数据。

最常见的坑是数据泄漏。比如你做时间序列预测，不小心把未来的数据放进了训练集，那验证集效果会好得离谱，上线后立刻失效。再比如做文本分类，同一篇文章的多个片段被切成了训练集和测试集，等于模型考试时偷看了答案。

第二个坑是类别不均衡。二分类任务里正样本占 95%，负样本占 5%，你全预测成正样本就有 95% 准确率，但业务上毫无价值。这时候要改用 F1 score、AUC 这些对不均衡更敏感的指标，或者做重采样。

LLM 应用的效果评估更麻烦。传统 ML 可以用准确率、F1 来量化，但 LLM 生成的文本没有标准答案。我的做法是建立一套多维度人工评估集：准备 20 到 50 条有代表性的测试问题，标注好“好的回答应该包含哪些要点”，每次改动 Prompt、换模型、调检索参数，都拿这套集子跑一遍，人工打分。虽然费时间，但这是唯一能持续追踪效果的办法。

后来我也用过 LLM-as-a-Judge 的方式，让 GPT-4 给自家模型的回答打分，把“参考回答”和“模型回答”一并投给裁判模型，用它的结论做初步筛选。这个方案能省不少人工，但要注意裁判模型本身也会有偏好和幻觉，最终还是要人来复核关键样本。

4.3 线上效果和线下效果对不上

这是最让人头疼的问题。你在评测集上 F1 刷到 0.9，上线后用户反馈一塌糊涂。原因通常集中在几个方面。

第一，线下数据分布和线上不一致。你是拿 2023 年的数据训的模型，线上来的全是 2024 年的新文本，术语、表达方式都有变化，效果自然会掉。解法是建立线上数据回流机制，定期采样线上真实请求补充到评测集里。

第二，线上输入的类型你没见过。比如你只训练了短文本分类，用户却传上来一篇几千字的文章，模型的输入截断策略不同，效果就变了。要在服务层对输入长度、格式、语言做防御性校验。

第三，延迟和并发导致超时，用户等不到结果就当系统坏了。这不是模型效果问题，却比模型问题更影响口碑。压测手段要提前做，我用locust或者wrk做并发压测，确认服务的 QPS 上限和响应时间分布。

4.4 成本控制的实用技巧

LLM 应用上线后，成本是必须算的账。我见过创业团队把 API 调用日志打出来，发现一个月花了几万块，大部分是无效请求和重复请求。

成本控制有几个立竿见影的做法：

• 加缓存。同样的用户问题，在 Redis 里按问题内容的哈希值做一层缓存，重复问题直接返回历史答案，能省掉很大比例的大模型调用。
• 减少 Prompt 长度。Context 越长 token 越多，费用越高。检索来的文本块不是越多越好，控制在能回答问题的范围内。
• 用小模型。简单任务用 7B 甚至更小的开源模型本地部署，每 token 成本几乎为零；只有复杂推理才调用大模型。
• 设置调用限流和告警。单个用户每秒请求数限制、每个请求的 token 上限、月度费用告警，都要配上。

我做过一个真实的成本对比：一个知识库问答系统，全部用 API 调用，日均 1 万次问答，按 2000 token 一次算，一个月费用大概在几千到上万元；换成本地部署 7B 模型 + RAG 架构，推理走 GPU 服务器，一次性的硬件成本平摊下来，跑同样量级的请求，月度成本可以降到原来的五分之一甚至更低。当然，本地部署要牺牲一部分效果和灵活性，这就是工程上的取舍。

5. 学习路线与资源规划建议

5.1 主线学习资源怎么选

网上 AI 学习资料多到爆炸，但真正值得看的没那么多。我按阶段整理一套主线资源，避免你在信息的海洋里淹死。

书不用多，关键是每本都要吃透。我个人最推荐的国产教材是李沐老师的《动手学深度学习》，它最大的优点是代码和理论完全对应，每一章都有可以直接运行的 Jupyter Notebook，非常适合工程向学习者的节奏。

5.2 项目驱动的学习节奏设计

学习 AI 工程最忌讳的就是只学不练。我的建议是把学习周期分成三个项目驱动的阶段，每个阶段都有可见的产出。

第一个项目是做经典机器学习全流程。用 Kaggle 的 Titanic 或者 House Prices 数据集，做特征工程、模型训练、交叉验证、提交结果。这个项目让你把数据科学的完整流程走通，也能让你体会到特征工程的重要性。

第二个项目是做计算机视觉或者 NLP 的深度学习。比如用 PyTorch 训练一个 CNN 做图像分类，或者微调一个 BERT 做中文情感分析。这个阶段要重点关注：数据加载的写法、训练的循环、模型的保存和加载、推理的封装。做完你就掌握了深度学习工程的基本套路。

第三个项目就是前面说的 RAG 问答系统。做成一个完整的产品：有数据上传、有向量检索、有流式输出、有历史记录、有服务日志。这一步做完，你已经具备了一个初级 AI 工程师解决真实问题的能力。

5.3 持续进阶的方向

AI 工程这个领域变化极快，三个月不看新东西就会被甩下。但我不建议每天刷几十条资讯制造焦虑，更有效的方式是跟踪几个关键信号：

• 主流大模型的测评榜和发布说明，了解当前能力边界在哪里。
• Hugging Face 的 Trending 页面，看社区在集中做什么方向。
• 自己维护一个“每周动手做一个小实验”的习惯，比如这周研究 Function Calling，下周研究多模态输入，再下周研究流式输出。每次实验产出一篇笔记，三个月后你会发现自己已经建立起一片属于自己的知识体系。
• 参与开源项目，从给文档补注释、修 bug、补测试用例开始。这不仅能提升代码能力，也能认识一批同路人。

我个人经验里，进步最快的阶段不是看书最多的阶段，而是被真实需求逼着解决问题的阶段。所以当你学完基础后，一定要尽快找一个真实场景——哪怕是帮朋友做一个会议纪要总结工具、帮社群做一个入门资料问答机器人——把技术放进真实约束里去打磨。

6. 最后说几句实在话

根据我个人的体会，AI Engineering from Scratch 这条路最难的不是某个技术点，而是耐心的分配。很多人容易在前期沉迷调参刷榜，却在“把模型变成服务”这种脏活累活上失去耐心。但恰恰是后者，决定了你在真实团队里值多少钱。

最后再分享一个小技巧：无论你做什么 AI 项目，从一开始就要养成写实验记录的习惯。模型版本、数据集版本、Prompt 版本、超参数、当时的效果指标，全部记下来。没有实验记录的项目，三个月后大概率是灾难——你会发现自己调过的参数全忘了，复现不了效果，也没有办法向别人说明“为什么这个方案可行”。养成这个习惯，比多看十篇教程都重要。