企业官网建设流程全解析

这两年我面试过不少人，也带过不少刚入行的同事，发现一个特别普遍的现象：很多人啃完了机器学习理论和 Python 教程，模型也能跑起来，但一提到 AI engineering——也就是把一个模型变成真正能稳定服务用户、经得起流量和时间检验的系统——整个人就懵了。模型精度达标了，系统却没上线过；Jupyter 里跑得飞快的代码，搬到生产环境里到处报错。这不是个别人遇到的问题，而是整个行业从“算法时代”转向“工程时代”后最典型的断层。

我写这篇东西的初衷很朴素：把“从零开始做 AI 工程”这件事，拆成能看懂、能上手、能避坑的具体动作。市面上讲模型原理的课很多，讲框架用法的教程也不少，但真正站在一个工程师视角，告诉你从需求分析、数据准备、模型选型、推理部署到监控复盘这一整条链路怎么串起来的内容，反而稀缺。这篇内容适合谁？适合那些已经会写 Python、跑过几个开源模型、但还没独立交付过完整 AI 系统的工程师，也适合想转岗做 AI 应用开发的同学。我会尽量不讲废话，直接说我在实际项目里怎么设计、怎么实现、怎么踩坑。

1. 为什么“从零开始”这么难：AI 工程不是调参，是搭系统

1.1 模型只是起点，不是全部

很多人对 AI 工程的第一印象是“找个模型、调调参数、看精度”。这个印象害了不少人。真实项目里，模型本身可能只占整个系统工作量的百分之二三十，剩下的全是数据、管道、接口、评测、监控、成本和稳定性这些“脏活累活”。

我给你打个比方：训练好的模型就像一个发动机，但用户要的是一辆能上路的车。发动机再猛，没有底盘、变速箱、油箱、仪表盘，它就是一堆铁疙瘩。AI 工程干的事情，恰恰是把“发动机”装进“车子”里，还要保证它跑一万公里不出大毛病。所以当你决定从零开始学 AI 工程，第一件事不是去研究最新的模型架构，而是建立“系统思维”——你做的每一块工作，最终都要服务于一个稳定、可维护、成本可控的整体。

另一个让新手特别难受的地方是：AI 系统的不确定性是没法根除的。传统软件开发里，同一个输入几乎必然得到同一个输出，你可以靠单测把逻辑锁死；但模型是概率系统，同样的 prompt 今天答得好，明天可能答得差，甚至同一天内跑两次结果都不同。这个本质差异，决定了 AI 工程的很多手段——评测集、灰度、兜底逻辑、人工审核环——在传统工程里都不是标配，但在 AI 系统里全都必不可少。

1.2 工程化能力栈：从数据到上线的完整链条

说到“从零开始”，我建议你先在心里建一张完整的工程能力地图，把各个节点都摆出来。这是我带过多个项目后整理出来的标准参考框架：

你可以对照这张表自查一下，自己的短板在哪一层。我见过太多“模型很会调、服务完全不会写”的算法工程师，也见过“服务写得很溜、但数据一塌糊涂”的后端转岗同学。真正合格的 AI 工程师，不需要每一层都成为专家，但每一层都要有起码的认知和动手能力——因为生产环境里的问题永远不会乖乖局限在哪一层里。

很多教程会直接给你一个模型微调的 step-by-step，说穿了就是拿现成数据集跑一遍脚本。那个流程本身不难，难的是你心里清楚“为什么这个模型需要微调”“微调之后怎么证明它变好了”“上线之后怎么持续验证”。下面几个章节，我会把工程化链条上的关键细节逐一展开，每个地方都给到可以直接抄作业的方案和参数，也会告诉你哪些坑我替你先踩过了。

2. 核心能力拆解：AI 工程的关键拼图

2.1 数据工程：喂进模型的数据决定了天花板

说句得罪人的话：很多团队做的所谓 AI 项目最后效果不好，八成不是模型不行，而是数据压根没法用。模型的能力上限由数据决定，这是深度学习时代一条绕不开的铁律。所以我把数据工程放在所有能力的第一位。

数据质量把控有几个关键动作，逐个说：

第一步是数据体检。拿到一份数据，别急着清洗，先做探索性分析。我都会先跑一段统计脚本，看总量、字段缺失率、重复率、类别分布、文本长度分布、语言混杂比例。这些指标直接决定后续策略。比如你发现重复样本占三成，不去重就直接训，模型会把高频样本背下来，泛化能力大幅下降。我曾经处理过一份客服对话数据，表面看有 50 万条，去重之后只剩 21 万条，这种水分非常常见。

第二步是清洗规则。清洗不是简单删空行，要有明确的规则意识。我常用的清洗项包括：HTML 标签去除、URL 和邮箱脱敏、全角半角统一、乱码字符过滤、敏感信息发现与脱敏、噪声短文本过滤（比如少于 10 个字符的碎片文本）。每条规则都要写清楚“为什么存在”，后续维护时才不会误伤。

第三步是数据血统与版本管理。很多人会忽略这一步，但它是工程化最核心的护城河。训练数据、微调数据、评测数据必须分别管理，每一版数据都要有唯一的版本号、生成时间和变更记录。否则你某天发现效果回退，想排查数据变化都无从下手。我自己的做法是给每个数据集建一个 manifest 文件，记录 schema、样本数、来源、时间戳，用 DVC 或者纯 Git LFS 管理文件版本。别觉得麻烦，等你线上出问题回滚数据版本时，你会感谢当初的自己。

数据规模则要看业务场景。微调一个 7B 参数的模型，几百上千条高质量样本可能就能见效；而预训练动辄需要几 TB 文本。绝大多数人不会做预训练，所以我的建议是：优先追求“小而精”，不要盲目堆量。保证每个样本都有清晰的输入输出结构和标注质量，比收集 100 万条杂乱数据有用得多。

2.2 模型工程：选型、微调与评估

选模型是第一个劝退新手的环节。模型这么多，参数范围从 0.5B 到几百 B，到底用哪个？我的选择逻辑很简单：先定任务，再定资源，最后定模型。

如果任务就是一个简单的文本分类：先尝试 0.3B~3B 的小模型，又快又省成本，往往够用。如果任务涉及多轮对话、复杂推理或内容生成：大概率需要 7B 以上的模型，7B 是“性价比甜点位”，单张 24G 显卡可以做推理，微调也可以，国内外很多开源模型都在这个档位。追求更高质量的角色扮演或复杂指令遵循，可以上 13B 或更大模型，但硬件压力和推理成本会显著增加。

微调环节，我强烈推荐新手从 LoRA 开始，不要直接做全量微调。LoRA 的本质是冻结原模型参数，只训练新插入的低秩矩阵，显存占用和训练时间都大幅下降。以 7B 模型为例，全量微调可能要 60G+ 显存，而 LoRA 在 16G~24G 显存的消费级显卡上就能跑起来，效果在很多任务上逼近全量微调。量化微调可以进一步压低门槛，QLoRA 把基座模型量化到 4bit，显存需求能降到 10G 左右，我个人的主力方案就是这个。

微调的关键参数我直接给你一份经过实测的基准配置：LoRA rank 设为 32~64，alpha 设为 rank 的两倍，dropout 设 0.05~0.1，学习率建议 1e-4 到 2e-4，用 cosine 或 linear 调度器，warmup 步数占训练总步数的 5%~10%。批次大小受显存约束，尽量用梯度累积把有效批次对齐到 32~64 条样本，稳定性明显更好。

但微调做得好不好，不能靠“loss 降了”来判断。loss 下降只说明模型记住了训练集，不代表它在真实场景里有效。正确做法是先冻结一份评测集，评测集要和训练集严格分开，绝不能从同一批数据里切，否则就是自己骗自己。分类任务看准确率、F1；生成任务看 BLEU、ROUGE，但更推荐结合人工打分或 LLM 打分；RAG 类任务则要关注答案的忠实度、相关性、上下文利用率等指标，工具里 RAGAS 是目前比较省事的。

2.3 推理与部署：目标只有一个——稳定省钱地跑起来

模型训练好只是第一步，让模型对外提供服务才是工程核心。部署层的关键词有两个：延迟和吞吐。用户体验上，标准是首字返回时间不大于 1~2 秒，整体回答时间可接受；成本上，则要尽量提升单卡吞吐，让同样的硬件服务更多请求。这两者需要做取舍，没有标准答案。

开源生态里比较成熟的方案我推荐用 vLLM 或者 TGI。它们的共同思路是通过 PagedAttention 管理 KV Cache，配合 continuous batching，让单卡吞吐量成倍提升。我做过一个对照实验：同样一张 A10 显卡跑 7B 模型，原生 PyTorch 推理并发 4 路就到顶了，vLLM 可以轻松支撑 20 路以上并发，首字延迟还更低。只要你的模型支持这些推理框架，就尽量不要自己写推理服务。

部署要点整理成清单的话，我认为下面几条优先级最高：

• 预热（warmup）是必须做的。冷启动会走一遍模型加载和编译流程，实际延迟可能是正常情况的几倍。服务启动后先发几条请求热一下，再挂到负载均衡。
• 接口设计建议用流式输出（SSE），用户端能边收边显示，体验好很多。非流式接口会让用户盯着空白界面等好几秒，心理感受完全是两个量级。
• 限流与兜底一定要做。用令牌桶或者简单计数做并发上限，超出直接返回排队提示，避免服务被冲垮。在线服务挂了个 504，用户是不会管你模型多牛的。
• 多模型或者多任务建议在应用层做异步化和削峰填谷，把请求丢到消息队列里，消费端按队列做推理，这样流量波动再大，后端都能平稳。

量化是部署的另一个重要话题。模型参数动辄几十 GB，单卡放不下就得做量化。常见方案有 AWQ 和 GPTQ，4bit 量化通常可以把 7B 模型压到 5GB 左右，显存压力大幅减轻。量化会牺牲部分效果，但对绝大多数任务，4bit 的损失在日常体验中几乎无感。我的实践原则是：先把量化版本跑起来，用评测集打一遍分，对比完整精度版本的差异，如果指标下降在可接受范围内，直接上量化版本。

2.4 应用架构：RAG、Agent 与链路设计

模型服务化之后，真正的 AI 应用还需要更多组件。目前最主流的两类架构是 RAG（检索增强生成）和 Agent（智能体），两者往往还会结合使用。很多从零开始的同学，一上来就试图复刻一个复杂的 Agent，结果链路太长、错误率超高。我给的建议是：优先做 RAG，把知识问答类场景打透，再逐步迈向 Agent。

RAG 的核心思想是：不直接让模型背诵知识点，而是先从外部知识库里检索出相关内容，再把这些内容“喂”给模型做参考回答。这个设计从根上解决了模型幻觉和知识时效性问题，让系统可以基于内部文档、私有资料回答问题，也能在知识更新后不需要重新训练就能刷新答案。

RAG 工程里有几个直接影响效果的点位，逐一拆开说：

数据切分（chunking）。切太粗，检索时噪音大；切太细，上下文信息不连贯。我实测下来，通用段落控制在 256~512 个 token 之间比较合适，同时要让切分尽量贴合语义边界。最好的做法是按文档自然结构切，比如 Markdown 标题、段落首行，而不是硬按字符数切；硬切会把一句话从中间断开，检索命中后上下文不完整，生成效果差一大截。切片之间可以加 10%~20% 的叠加重叠，避免边界信息丢失。

向量化和检索策略。常见的做法是用嵌入模型把文本变成向量，存到向量数据库，查询时做相似度检索。这里有个常见误解：向量相似度高的片段不一定语义上真相关。所以不要只看向量，可以做“混合检索”——向量召回虽然必要，但关键词、BM25 这类传统检索手段也常常有效，甚至效果更好。我在实际项目里会把两种方式结合，向量召回的候选和关键词召回的候选合在一起，做重排（rerank）再截取 top-k。重排模型可以小一点，用 0.3B~1B 的交叉编码器就够了。

Prompt 组装和回答生成。把检索到的 top-3~top-5 个片段拼进上下文，然后让模型“只依据给定资料回答”。这句话看起来很基础，但非常关键，它直接约束了模型不要天马行空。对于知识库问答，如果检索结果与用户问题相关度太低，我会把“无答案”作为一个合法输出，宁可告诉用户“资料里没找到”，也别让模型硬编一段话来误导。

Agent 架构则是在 RAG 基础上再叠加规划能力。模型需要决定调用哪个工具、按什么顺序调用、是否终止。这一块的复杂度指数级上升，我建议你至少先跑通三步：定义工具清单 -> 用 ReAct 模式让模型推理下一步 -> 加人审兜底（重要操作人工确认）。没有可靠的人工确认机制之前，不要让 Agent 在无人监督的情况下执行有副作用的外部动作。

3. 实操记录：从零搭建一个可用的知识库问答系统

3.1 需求定义与方案选型：先把问题想清楚

这一节我拿一个最常见的需求举例：做一个公司内部知识库问答助手。假设场景是 HR 部门有大量员工手册、制度文件，员工随手一问，系统需要给出准确回答，并且注明依据来自哪一份文档。

拿到这个需求后先别急着选模型选向量库，先和业务方把这个想清楚：“可用”的验收标准是什么？我通常会逼问三个问题：准确率如何度量？允许的回答延迟是多少？没有答案时该怎么回复？很多项目最后扯皮，都是因为一开始没把验收标准写清楚。建议产出一个 20~30 条的评测集，每条包含“问题、标准答案、相关文档来源”，这是后续所有迭代的地基。

方案选型上，这个场景的知识相对固定、答案多来自规定条文，适合做 RAG。基座模型我选了 7B 档位的中文能力较好的开源模型，向量模型用中文嵌入模型，向量库用开源的 Milvus 或者纯本地模式跑起来。部署层面，先单机单卡出一个 MVP，再考虑扩展。MVP 的意义是快速打通全链路，不要一上来就追求高可用架构——那会让你陷在配置环境的泥潭里出不来。

3.2 数据准备与向量化：决定检索质量的三件事

知识库原始数据是几十份 PDF 和 Word 文档，这一步要先把它们全部转成干净的文本。我的具体流程如下：

1. 文本提取后先人工抽检 5% 的页面，确认没有乱码、缺字、表格结构丢失。PDF 解析最容易坏的就是表格，如果表格信息很关键，建议表格单独处理，按行转成 Markdown 或结构化文本。
2. 做文档去重：不同版本的文件可能存在，按文件内容哈希找出重复项，让业务方确认保留哪一版。
3. 按语义单元切分：文档如果有标题层级，先解析出标题树，再在每个二级标题下按段落切块，块大小控制在 300~500 字。我用词数而不是 token 数控制，中文场景下 300~500 字大概对应 300~500 token，体感更直观。
4. 每个块生成元数据：来源文件、标题路径、页码、更新日期。这些元数据有两个用途：检索结果可以溯源，后续做权限过滤也能用。

向量化的关键参数，我实测后推荐这套：嵌入维度选模型默认值，不要乱调；检索的 top_k 设为 5~10，先多召回再靠重排过滤；相似度阈值不要设死，因为这个值在不同向量模型上分布差异很大，正确做法是先跑一批真实问题观察分数分布，再定阈值。这一步做完，把向量库建好，整个知识库的“记忆体”就绪了。

3.3 检索与生成链路：把性能调到能用的程度

链路设计走的是“召回 -> 重排 -> 生成”三段式。

召回阶段，我用向量检索和 BM25 关键词检索并行，各取 top 20。向量负责“语义相关”，BM25 负责“字面精确匹配”，尤其是在制度条文中，员工可能问的是里头的专有名词，BM25 反而打得准。两路结果合并去重后进重排。

重排阶段，我加载一个 1B 以下的交叉编码器模型，把每条候选和用户问题拼在一起，直接打分排序，取 top 3~5 作为最终上下文。交叉编码器比向量相似度准确很多，因为它做了完整的注意力交互。虽然重排会增加几十毫秒延迟，但对最终回答质量的提升非常值得。

生成阶段，组装 prompt 时做三件事：第一，明确告诉模型只依据提供的资料回答；第二，把资料条目用编号标出；第三，要求回答后附上引用来源。这样用户不仅得到一个答案，还能看到出处，信任感直接拉满。

实际运行里我发现一个高频问题：检索到的片段之间可能存在矛盾。比如新旧版本制度不一样，top-5 里藏着两条冲突的内容，模型可能会挑一个，也可能含糊其辞。我的解决方案是在 prompt 里显式提醒模型“如果资料存在不一致，明确指出并建议以最新版为准”，同时在切分时保留发布时间字段，生成时可以优先选用新版本的内容。

3.4 上线部署与监控：能跑和好用之间还差一个观测面板

服务上线后才是工程的开始。很多从零起步的团队，把服务部署完跑通了就以为大功告成，这是最大的误区。上线后必须做三件套：日志、指标、链路追踪。

日志方面，每条请求都至少记下 user query、检索命中的文档 ID 和分值、生成的完整答案、prompt 版本、模型版本、延迟和 token 数。这些数据是后续分析效果回退、用户投诉的第一手材料。指标方面，最核心的几项是请求量、成功率、平均延迟、首字延迟、平均 token 数、用户负反馈率。链路追踪用 Langfuse 或者 LangSmith 这类工具，能把一次问答的完整链路可视化，排查问题效率翻倍。

我当时上线后第一个星期就通过监控发现了两个问题。一是夜间流量低峰期，推理服务的空闲实例造成了明显浪费，后来做了定时伸缩，省了大概三成成本。二是很多用户的提问特别口语化，比如直接说“年假咋休”，知识库里没有这么说，检索命中率低，答非所问。后来我在检索前加了一个 query 理解和改写环节，把口语自动转成更规范的检索式，整体效果明显回升。这类问题如果不上线、不接真实用户，永远发现不了。

监控告警也别设太高大上，先把“成功率下跌 X%”和“延迟超过 X 秒”这两个最基础的告警设好，比什么都管用。

4. 常见问题与排查技巧实录

4.1 经典翻车现场复盘

记录几个我在实际项目中反复见到的、也亲身踩过的坑，保证真实。

翻车一：向量检索结果看着相关，实际完全不对。有一次用户问“公积金怎么提取”，向量检索召回的却是“公积金缴存比例调整”。这两段表面都聊公积金，语义也接近，但根本不是同一个任务。单靠向量检索的场景，这种问题几乎无解，解决的办法就是我前面说的混合检索加重排，同时提高阈值，宁可少召回不可滥召回。

翻车二：微调之后模型“变笨”了。模型微调后，目标任务效果好了，但通用能力明显下降，甚至原来会做的题不会做了。这大概率是灾难性遗忘，解决办法有三类：微调数据里加入一部分通用语料、降低学习率、减少训练步数。我后来在微调数据里按 9:1 的比例混入通用指令数据，遗忘问题基本就没再出现过。

翻车三：prompt 写得越长效果越好——这是个幻象。有人喜欢把 prompt 写得特别长，把所有约束都堆上去，结果模型反而不稳定。我自己的实测体会是：prompt 里要的是清晰和结构化，不是无尽的信息。核心约束用三五句话讲明白，相关背景可以给，但别超过模型上下文窗口的合理范围；超出预期的长 prompt 还会增加每次请求的 token 消耗，成本翻倍看不见。

翻车四：上线第一天，接口就被打爆。原因很简单，没有做限流也没有预热。现在我的所有服务，上线前都要跑一遍压测，确认单实例的并发上限；挂到网关时配上限流策略，超出的部分直接排队或返回提示，不要让服务崩溃，整体体验反而更稳定。

4.2 成本与效率：让每一分钱都花得值

AI 工程的成本大头往往是推理，不是开发。很多团队账单出来吓一跳，才发现钱都烧在模型调用上。我总结了几个省钱且不影响效果的手段，优先级从高到低：

• 用小模型兜底。不是所有请求都需要大模型。简单分类、抽取、提问改写，用 0.5B~3B 的小模型完全可以搞定，只有最终答案生成这类复杂任务才上大模型。大模型调用量直接砍半，成本立刻下来。
• 语义缓存。用户问的问题往往高度重复，特别是企业内部场景。把“问题->答案”缓存起来，相似度足够高就直接返回缓存结果。我加了一个语义缓存层后，命中率做到了 25%~35%，成本和延迟双双下降，这个优化体验非常直观。
• 批处理与队列削峰。离线任务不要逐条实时请求，把任务攒起来做 batch 推理，吞吐能高好几倍，成本平摊下来低不少。
• 控制上下文长度。每次请求能少塞一点就少塞一点，检索出的 top-5 就够用，不要为了“周全”把 100 个片段全塞进去。token 是按量计费的，长度就是钱。
• 量化与服务合并。多个模型共用一张卡，或者用 vLLM 同时服务多个小模型，也是省显存和省电费的办法。

4.3 个人学习路径建议

最后聊点学习方法。很多人问“从零开始学 AI 工程，应该按什么顺序学”，我给一份可以照着执行的路径：

1. 先别碰大模型，把 Python、SQL、Linux 基础打牢，能自如处理 JSON、调用 HTTP API、写清晰的数据处理脚本。
2. 用开源模型在本地跑通一个推理服务，不要用别人封装好的在线 API，要从装依赖开始，自己写 FastAPI 接口，自己处理流式输出。
3. 做一个完整 RAG 项目。数据自己找、切分自己做、向量库自己搭、检索结果自己调，每个环节都亲手碰一遍，这个项目能让你理解 AI 应用的基础架构。
4. 学评测。挑一个公开评测集，学会跑评测、看指标、做对比实验。评测能力是你后续所有迭代的眼睛，没有它你就是在黑箱里瞎调。
5. 再进阶到模型微调，从 LoRA 开始，控制变量，记录每一个实验配置和结果。
6. 最后再学分布式推理、模型并行、服务治理这些偏底层的工程主题。

我自己带人的时候有个体会：很多人卡在第二步就不愿意往下了，因为“调用 OpenAPI 已经很爽了，为什么要自己部署模型？”我理解这个心态，但如果你想成为一个真正的 AI engineer，必须亲手把部署、监控、调优的脏活干一遍。这些功夫省不掉，也替不了。

回头看这一路，我最大的体会是：AI 工程没有那么多“银弹”，也不存在一条神奇的学习路径。它的本质还是工程——把复杂问题拆成小问题，把不确定的东西通过评测和监控变得确定，把每个环节的质量都看住。对一个从零开始的人来说，你不需要在第一周就跑通全栈，但从第一天起，你就要有“全链路工程”的意识：你做的每一个小实验，都是为了最终能支撑一个真实系统稳定地跑下去。先搭最简单的 MVP，跑起来，再一层层补厚度——数据和评测永远是地基，模型和算法是塔尖，地基够深，塔尖才有意义。