企业官网建设流程全解析

去年年初我接了一个内部工具项目，需求相当朴素：把公司合同里那几百页PDF变成一个能直接对话的知识库。我一开始想得很简单，觉得调个现成API就能交差，结果在实际落地时发现，托管服务在数据权限和定制能力上的瓶颈很明显。最后我决定把“ai-engineering-from-scratch”当成一个正式项目来做：不依赖任何云厂商的托管PaaS，自己从模型部署、推理服务、数据增强到微调，把整套AI工程链路从头搭一遍。这篇文章就是这次实践全过程的技术拆解，适合刚接触AI应用开发的工程师，也想给打算自建私有助手的同学一条可以照抄的路径。

真正跑通之后我才意识到，所谓“从零开始”并不是重复造轮子，而是把每个工程环节的选择权拿回自己手里。下面我把这个项目的整体设计、硬件评估、模型部署、数据微调、RAG与Agent集成，以及我踩过的坑，完整拆开讲一讲。

1. AI工程整体设计：先弄明白“从零搭链路”解决了什么

1.1 不依赖云端托管，换来的是数据边界和长期成本

刚开始我也问过自己：现在各家云平台都有现成的模型服务，为什么非要自己搭？做完这个项目，答案很清晰——数据边界是第一位的。合同、财务报表、内部知识库这些东西一旦发到第三方API，哪怕只是做推理，都会涉及数据出境和合规审计的问题。而把模型部署在自有服务器或内网环境里，数据流全程可控，这一点对于中小团队尤其重要。

第二个理由是长期成本。云上推理服务按Token计费，短期看单价不高，但如果业务量上来，或者需要反复尝试不同模型，账单会非常难看。自部署的核心成本是硬件折旧和电费，一旦模型跑起来，每次调用的边际成本几乎趋近于零。我做了一个简单测算：一个7B量级的量化模型，在消费级显卡上跑，每百万Token的电费成本大概只有云服务商报价的十分之一到二十分之一。这种差距在批量处理场景下会直接决定项目能否回本。

第三个理由是可定制性。云端托管通常只提供黑盒接口，你没法改采样策略、没法注入自定义的预处理逻辑、没法把模型和检索模块放进同一个进程做低时延调度。自己搭链路之后，所有环节都能按业务需求调，这种自由度在项目后期微调的时候价值最大。

1.2 项目拆成四个阶段，每个阶段都有明确交付物

整个从零搭建的过程，我按依赖关系拆成了四层，每一层都有独立的验收标准。

• 基础环境层：算力评估、驱动安装、Python环境、模型权重准备。验收标准是模型能加载、能跑通一次推理。
• 推理服务层：把模型包成OpenAI兼容的API服务，支持并发请求和流式输出。验收标准是下游程序能通过HTTP调用模型，并且性能满足业务要求。
• 能力增强层：在推理服务之上加入知识库检索（RAG）和工具调用（Agent）。验收标准是模型能结合外部文档回答问题，能调用预定函数完成操作。
• 进化微调层：用业务数据对模型做参数微调，改进特定场景的表现。验收标准是评测集上的关键指标明显优于未微调基线。

这四个阶段不是简单串行推进，实际开发中它们是迭代关系。先把第一版跑通，然后再根据业务反馈决定是增加检索还是做微调。我的建议是千万不要一上来就微调——很多问题用RAG、Prompt优化就解决了，微调是代价最高、周期最长的手段，应该放在确定真正需要的时候再用。

2. 硬件算力评估与本地运行环境准备

2.1 一张消费级显卡能跑什么模型：显存容量估算

很多人问“没有A100能不能玩本地模型”，答案是能，关键是算清楚显存账。模型加载需要的显存大致由三部分组成：权重参数、KV Cache、中间激活值。

权重部分有个快速估算公式：参数量（Billion）× 每个参数字节数。FP16精度下每个参数占2字节，所以一个7B模型权重就要约14GB；如果开4bit量化，占用量降到约4GB。这还没算KV Cache和激活值，所以一张16GB显存的显卡，跑7B的FP16模型会非常勉强，但跑4bit量化版本就游刃有余。

我实测下来，不同规模模型大致对应的显存需求如下：

这个表仅供参考，实际还要看上下文长度和并发数。如果你只有一张8GB显卡，建议锁定7B的4bit量化模型；有16GB到24GB，就可以在13B量级甚至7B的更高精度之间选择。我自己的主力机型是24GB显存，既能流畅跑7B的FP16，也能跑13B的量化版，覆盖面比较均衡。

2.2 环境搭建踩过的坑：CUDA版本和Python环境

环境问题看似基础，但八成以上的初学卡壳都发生在这里。首先别用系统的全局Python环境，一定要创建虚拟环境隔离。我习惯用conda，命令很简单：

conda create -n aieng python=3.10 conda activate aieng

然后安装PyTorch。这里有个细节：PyTorch的CUDA版本必须和显卡驱动、推理框架匹配。最稳妥的做法是先运行nvidia-smi查看驱动支持的CUDA版本，再去PyTorch官网选对应的安装命令。

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

装完之后务必做一次验证，确认GPU真的可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出False，大概率是CUDA版本不匹配或者驱动太旧。这个检查一定要做，否则后面所有步骤都会在看不见的地方出问题。

2.3 基座模型与量化方案怎么选

基座模型的选择直接影响后续所有效果。我在项目里优先考虑了中文场景，所以主力用了Qwen系列，Llama系列作为备选对比。选择原则有三个：社区活跃度、中文能力、生态兼容性。社区活跃意味着遇到问题能搜到解决方案，中文能力决定了业务场景下的可用性，生态兼容性则关系到推理框架和微调工具的适配程度。

量化方案的取舍也很关键。GGUF格式适合Ollama这类轻量工具，部署简单；AWQ和GPTQ适合在vLLM框架下做高性能推理，精度损失都很小。我的建议是优先考虑AWQ或GPTQ，因为vLLM对这两种格式的支持更成熟，吞吐表现也更好。4bit量化看起来损失精度，但实际测评中在常见任务上的效果下降通常不到5%，换来的是显存需求减半，非常划算。

3. 推理服务化：把模型变成稳定可用的OpenAI兼容API

3.1 用vLLM一步启动推理服务

模型部署的核心是让模型提供稳定的服务接口，而不是只在交互式脚本里跑通。我直接选用了vLLM，原因有三个：支持连续批处理（continuous batching）、兼容OpenAI API协议、吞吐性能明显优于原生Transformers方案。

安装和启动都很简单：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen2.5-7B-AWQ \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192

--max-model-len控制最大上下文长度，如果显存不宽裕，建议设成4096或2048。启动完成后，用一行curl验证服务是否正常：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/path/to/Qwen2.5-7B-AWQ", "messages": [{"role": "user", "content": "你好"}], "temperature": 0.7}'

如果返回了正常的JSON响应，说明推理服务已经就绪。整个流程比我预想的快很多，关键收益是下游程序可以用任何支持OpenAI协议的SDK直接对接，省掉了一堆自定义封装。

3.2 推理参数调优：温度、采样和上下文长度

模型服务跑通之后，别急着接业务，先把推理参数弄清楚。temperature控制随机性，值越大回答越发散，越小越保守。做知识库问答时我习惯设0.2甚至0.1；做创意写作再调大到0.8。top_p是另一种采样策略，和temperature配合使用，建议保持默认值0.8左右，不要同时把两个值都调得很高，否则回答会变得破碎。

max_tokens决定单次回复的最长Token数，很多人在这里踩坑：设太短会导致长文档总结被截断，设太长又占用显存中的KV Cache。我的经验是按业务最长预期加上20%余量来设置，比如合同问答场景最大回答可能到1500字，我设max_tokens=2048。另外还有个关键参数是repetition_penalty，回答循环重复时调高到1.1或1.2效果立竿见影。

vLLM的并发性能也不需要额外调整，--gpu-memory-utilization 0.9表示允许vLLM占用90%的显存做KV Cache，剩余留给模型权重和激活。这个数值过低会降低并发能力，过高则可能导致OOM，0.85到0.92是安全区间。

3.3 服务稳定性工程：重试、超时与健康检查

本地部署的服务一旦被业务方调用，就不能再用“手动重启”的思路了。我建议在客户端封装三层保障：连接超时、读取超时、重试策略。vLLM在长上下文场景下，单次请求可能耗时几十秒，如果客户端设置的超时时间比服务端还短，就会出现一堆无谓的超时报错。我推荐把客户端读取超时设为服务端预估响应时间的两倍以上。

我还在服务前置了一层简单的健康检查脚本，定时调用/v1/models接口，如果连续失败就发告警。服务挂掉之后的自动恢复可以借助systemd或容器编排工具，但初期最现实的方案是写一个看门狗进程，检测到进程退出自动拉起新实例。这些内容看起来和AI关系不大，但恰恰是把模型从“demo”变成“产品”的分水岭。

4. 数据工程与微调实战：让模型懂你的业务语言

4.1 先判断：这个问题该用RAG还是微调

很多人在模型表现不如预期时，第一反应就是“微调”。但实际上，模型不懂业务术语、不知道内部文档内容，这类问题优先考虑RAG就能解决；只有模型“会了知识但不会按你的格式回答”，或者需要稳定的输入输出行为时，才是微调的主场。

我做过一个对比：

判断清楚之后，再决定投不投微调的成本，否则很容易白忙活一场。

4.2 微调数据集构建：质量和格式比数量重要

微调数据是训练效果的基石。我最初向同事收集了一堆问答记录，结果格式五花八门，自己看得头大。后来统一成了ChatML格式，每一行都是一条完整的对话样本：

{"messages": [{"role": "user", "content": "合同中的违约金条款在哪里？"}, {"role": "assistant", "content": "违约金条款通常在合同第十条，具体约定为……"}]}

清洗数据时，最重要的是剔除三类噪声：答非所问的样本、信息过时的样本、含有个人隐私的样本。数据量方面，我的经验是一千条高质量样本就能看到明显行为变化，三千到五千条通常足够覆盖一个明确的垂直场景。盲目堆量效果未必好，质量不行反而会拉低模型原有能力。

4.3 LoRA微调：用可控成本完成训练

全参数微调7B模型需要至少80GB显存，个人和中小团队根本玩不起。所以我选了LoRA（Low-Rank Adaptation），它只训练注入的低秩矩阵，需要更新的参数量不到原模型的1%。这样一张24GB显卡就能稳定训练7B模型。

我用HuggingFace的PEFT库做LoRA训练，核心配置如下：

from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer model = AutoModelForCausalLM.from_pretrained("/path/to/model", torch_dtype="auto") lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config) training_args = TrainingArguments( output_dir="./lora_output", per_device_train_batch_size=2, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=3, logging_steps=20, save_steps=200, fp16=True, )

这里r=16、lora_alpha=32是实践经验中比较平衡的起步值，rank太大显存占用上升，太小则拟合能力不足。学习率用2e-4，比全参数微调的1e-5级别要高，这是LoRA这类参数高效微调的常见选择。

训练完成后把LoRA权重合并回原模型，生成一个独立的推理版本：

model = model.merge_and_unload() model.save_pretrained("./lora_merged")

之后生产环境部署的就换成这个合并后的权重。

4.4 评测与版本切换：别让微调毁了原有能力

微调最大的坑是“灾难性遗忘”——模型学会了新任务的格式，却忘了原本的通用能力。所以我在微调前专门预留了两组评测集：一组是目标业务的验收集，一组是通用能力抽查集。每次微调完，两边都跑一遍，如果通用项显著下降，就要调整数据配比或降低学习率。

更工程化的做法是保留多个版本权重，用简单的配置切换线上使用的模型。我习惯给每个版本打上标签：“base-7b-v1”“lora-contract-v1”“lora-contract-v2”，切换时只需改环境变量。这样即使某个版本上线后发现异常，也能瞬间回滚到之前的稳定版本。

5. RAG与Agent能力构建：知识库与工具调用的工程落地

5.1 最简RAG链路：切分、向量化与召回

RAG是目前让模型接触私有知识最成熟的手段。整体链路不复杂：文档先切块，再向量化存入向量数据库，查询时用同一套向量模型把问题编码，到库里做相似度检索，最后把命中的文本块塞进Prompt交给模型生成答案。

具体实现中我踩过最大的坑是文档切分。早期我按固定长度500字符硬切，结果大量语义完整的段落被拦腰截断，检索效果非常差。后来改成分层切分：先按标题或章节标记做结构切分，再做长度控制，并让相邻块之间保留50字左右的重叠。这样既减少了语义断裂，又保证了切块数量不会爆炸。

向量库我用了Qdrant，因为它部署简单、支持过滤条件，数据量小时甚至可以跑嵌入式模式。一开始想用Chroma，但并发检索性能不太令人满意。Embedding模型选了bge-large-zh-v1.5，中文效果比通用多语言模型明显更稳，而且维度和检索库兼容性都很好。

5.2 检索质量优化：混合检索是质的飞跃

纯向量检索有一个经典问题：用户输入的“违约金比例是多少”和文档原文里的“违约金的计算标准”语义相近但字面差异很大，简单向量召回会抓不到。这个问题靠向量模型本身很难完全解决，我用混合检索改善了明显——把BM25关键词检索和向量检索的结果做加权合并，再交给重排序模型筛选。

实际的优化步骤是：先用向量召回Top 50，再用BM25召回Top 50，合并去重后，通过一个cross-encoder重排模型给每个候选块精细打分，取Top 5送入Prompt。这套流程加上去之后，准确率提升非常可观。代价是多了一次重排的推理调用，但在内部系统中完全值得。

5.3 Agent工具调用：让模型真正“干活”

知识库问答只是第一层，下一步是让模型能调用工具完成动作，比如查数据库、发通知、算金额。我基于OpenAI的函数调用协议做了Agent流程：预先定义一组JSON Schema描述每个工具的入参和用途，模型在对话中决定是否输出工具调用请求，应用侧解析请求并执行真实函数，再把结果作为新消息返回给模型继续生成。

关键细节是工具描述必须极其明确。我一开始写“根据日期查询订单”，模型经常猜错参数格式。改成“查询指定日期范围内的订单总量，日期格式YYYY-MM-DD，范围不超过30天”之后，调用准确率直接从七成提升到九成以上。工具调用的循环控制也要注意，加上最大迭代次数限制，防止模型调工具上瘾陷入死循环。

6. 常见问题与排查技巧实录：这一路踩过的坑

6.1 显存溢出（OOM）的排查顺序

显存不够是最常见的故障，我遇到过三次典型的OOM。第一次是上下文设置太长，8GB卡上硬跑8192的上下文；第二次是并发请求太多，KV Cache挤爆了显存；第三次是微调阶段FP16全量权重加优化器状态超限。

排查顺序建议先看nvidia-smi确认显存占用，然后依次做三件事：降低max-model-len、限制并发数、用更低精度的量化格式。如果做微调，就把batch_size减半，同时调大gradient_accumulation_steps补偿训练效果。系统提示：OOM不是靠重启能解决的，必须往下调资源水位，直到显存峰值在90%以内才能长期稳定运行。

6.2 推理速度慢先分辨是哪个环节

“模型好慢”这句话其实有很多种原因。用户说慢，可能是首Token延迟高，也可能是整体生成速度慢，更可能是网络传输或者应用层逻辑慢。排查时要先分清瓶颈。vLLM的一个核心优化是连续批处理，它能让多个并发请求共用推理批次，所以有时候并发上去了，吞吐反而更高。如果单请求速度慢，优先检查是否因为显存不足导致KV Cache被频繁清理；如果多个请求都慢，那可能是模型量化格式选得不够高效，或者物理机算力确实不够。实测下来在24GB的4090上，7B模型的开源框架推理速度大约在每秒50到80个Token之间，低于这个水平就要找原因了。

6.3 模型“胡说八道”的解法不是无脑调低温度

幻觉是自带模型最让人头疼的问题。很多人第一反应是把温度调到0.1，但这只能缓解字面不稳定的问题，改不了事实性错误。我实践下来真正有用的手段是：给模型提供足够的参考材料（RAG命中内容）、在Prompt里明确“只能依据给到的资料回答”、缺失信息时直接说“不知道”。对于高风险场景还可以加一层事后校验逻辑，让另一个更便宜的模型做引用比对，检查生成内容是否和检索到的文档一致。这套组合拳下来，幻觉比例可以降到可接受范围。

6.4 训练loss不降与过拟合的处理

微调时如果loss不降，先看学习率和数据噪声。学习率太小时梯度更新幅度过小，模型学不进去，可以尝试从2e-4向3e-4逐步上调；数据里混入了大量答非所问的样本，则会让损失函数在矛盾方向上震荡，这时需要回数据清洗环节。过拟合通常表现为训练loss持续下降但验证集表现却变差，对策是增加数据多样性、增大dropout、减少训练轮数。我的经验是微调数据集只要质量过关，1到3个epoch就足够，不需要像预训练那样跑很多轮。

项目走到今天，我最深的体会是：AI工程的核心已经不是“模型有多强”，而是“工程链路有多稳”。从部署一个开源模型到真正把它变成业务系统的一部分，中间隔着的是一整套关于数据、接口、评测、回滚的工程细节。“ai-engineering-from-scratch”的价值不在于证明了没有昂贵硬件也能玩AI，而在于把每个环节的决策权都握在了自己手里——这个模型不行就换，这个参数不对就调，这些数据有问题就重新洗。踩过几次坑之后你就会发现，这种掌控感才是从零搭建最大的回报。