企业官网建设流程全解析

简介：面向具备一定IT基础的企业管理者、技术总监、数据科学家及IT工程师，方案以一份Docx设计文档完整呈现AI大模型数字底座项目的规划与实施路径，聚焦智能化决策支持、业务流程优化与客户体验提升。资源包共1个docx文件、约314KB，内容按项目概述、业务需求分析、技术架构设计等章节组织，沿基础设施层、数据层、模型层、应用层展开，便于不同角色按需查阅。方案细化了高性能计算与分布式存储资源配置、数据采集存储处理和管理机制，以及基于预训练大模型的微调与优化；同时给出智能客服、数据分析平台、自动化流程引擎等业务应用的落地设计。文档还将数据治理与安全、模型部署与监控、用户培训与技术支持纳入全流程，并做经济效益、效率提升、客户满意度与创新成果多维评估，同时展望技术演进方向和业务扩展可能。目前已有70人浏览学习，适合正在规划AI底座或开展数字化转型的团队作为方案参考和实施手册。

1. 企业数字化转型推进到深水区，AI大模型项目为什么需要一个数字底座

企业数字化转型推进到深水区，AI大模型项目不是死在POC，而是死在规模化落地那一步：业务部门各调各的API，算法团队各起各的推理服务，同一个模型在机房跑了几份实例，数据却还在库里躺着。缺的从来不是模型，而是数字底座。

数字底座把算力、模型、数据、工具链收拢成一个统一平台层，让业务线像用电用水一样按需申请模型能力。它不是某一个模型，而是一套工程体系：GPU调度、推理灰度、数据进RAG、业务编排Agent。

下面按底座项目从立项到上线的顺序展开：先定架构分层，再落vLLM服务、RAG管道、微调与Agent编排，最后是验证与成本。适合企业AI平台架构师和SRE参考。

2. AI大模型数字底座的四层架构与选型判断：先定骨架再谈其他

2.1 从算力到业务，底座通常切成四层

方案阶段最常见的失败，是直接画一张"大模型平台全景图"，几十个组件堆在一起，落到实施时谁都不知道先建什么。走得稳的做法，是把数字底座按职责切成四层，层与层之间只通过接口通信，业务侧只接触最上面那一层。

第一层是算力资源层，负责GPU集群调度和权重存储，通常由Kubernetes加GPU Operator组成，配一个共享文件系统放模型和数据集。这一层最常见的错误，是把GPU当CPU做静态分配，一个业务一个命名空间独占一批卡，底座从第一天就在制造显存浪费。

第二层是模型平台层，提供推理、微调、向量检索、模型仓库这些通用能力。推理引擎主流选vLLM或Triton，微调作业用LLaMA-Factory这类工具管理，向量检索用Milvus，模型文件用Harbor加模型仓库做版本管理。这一层是底座里投入最大、复用价值也最高的部分。

第三层是模型资产层，管理基座模型、领域微调模型、Embedding模型、Rerank模型和安全审核模型。很多方案的PPT把这一层画成一个小方块，实际业务效果恰恰由它决定：同样的底座，模型资产不同，业务侧体感差异巨大。

第四层是业务编排层，把RAG服务、Agent编排、统一API网关、权限审计和用量计量收拢在一起，对外暴露一个稳定的API入口。这样切分的价值在于骨架先立住：算力归平台部，模型归算法组，业务归应用组，各层独立演进，不需要为了一个AI项目重写整个技术栈。

2.2 选型先回答三个判断，再看开源还是闭源

立完四层骨架，选型通常围绕三个判断展开。第一，基座模型用开源私有化部署还是闭源API；第二，平台能力自建还是直接买公有云模型服务；第三，底座由集团统一建设还是各业务线自建。

判断原则比较固定：数据敏感度决定能不能走API，调用规模决定自建成本是否划算，组织现状决定统一底座能不能推得动。下面这组对比，是开源私有化和闭源API在实际项目里的常见取舍：

值得留意的是，现在不少数字底座最终走的是"双轨制"：核心敏感场景用开源模型私有化兜底，长尾场景和高阶能力用闭源API补充，网关层统一路由和切换。多模态大模型能力也是一样，底座里先留出接口，能力到位再平滑接入。

2.3 底座组件清单，按最小闭环去排

方案阶段不要急着上大而全的LLMOps平台，先把最小闭环的组件按层排出来。下面这份清单里的组件名称可以换成团队熟悉的替代品，但职责不要少：

layers: compute: - backend: kubernetes + gpu-operator # 容器调度与GPU分配 - storage: juicefs / nfs # 模型权重与数据集共享存储 platform: - inference: vllm # OpenAI兼容推理服务 - vector-db: milvus # RAG向量检索 - finetune: llamafactory # LoRA/QLoRA微调作业 - registry: harbor + modelscope # 模型文件版本管理 capability: - rag: question-answering-pipeline - agent: function-calling-orchestrator - gateway: unified-api / auth / throttle

这份清单的排布逻辑是：算力在最底层，平台层承载所有模型类任务，能力层对业务封装RAG和Agent能力。网关放在业务编排层而不是平台层，是因为它要把模型路由、鉴权、限流、计量集中在一个出口，业务方只认一个API地址。底座能不能立住，就看这一层是否真正收口。

3. 模型服务层落地：用vLLM把大模型部署成统一推理服务

3.1 推理引擎选vLLM的理由

模型服务层是最直接影响体验的一层。底座里所有上层能力最终都要落到模型推理上：RAG要调用模型，Agent编排要调用模型，业务侧接入也要调用模型。这一层的吞吐和延迟稳定性，决定了整个底座的口碑。

开源推理引擎里，vLLM几乎是本地部署大模型的首选，原因有三：PagedAttention管理KV Cache，配合continuous batching把GPU利用率拉高；提供OpenAI兼容API，业务侧改一下base_url就能接进来；社区迭代快，量化、多模态、多卡并行这些能力都能跟上。底座平台层的定位是"统一出口"，vLLM的兼容性正好踩在这个点上。

3.2 vLLM部署的最小命令与关键参数

在GPU集群上起一个OpenAI兼容的推理服务，最小命令是这个样子：

vllm serve Qwen/Qwen2.5-72B-Instruct \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --quantization awq \ --served-model-name qwen72b-chat \ --port 8001 \ --trust-remote-code

这段命令做了四件事：用张量并行把72B模型拆到4张卡上跑；把输入输出总长度上限设为32768；把显存留给KV Cache的比例调到90%；用AWQ量化降低每张卡的显存压力。--served-model-name qwen72b-chat是网关里要用的对外模型名，它和模型仓库里的名字可以不一致，灰度时不用动业务代码。--trust-remote-code只在模型仓库可信时加，第三方权重上传来源要先人工审查再启动。

实际调参时，下面几个参数是排障最常动的：

提示：想要在模型服务层加一道保护，可以把--max-num-seqs从256调低到64，延迟敏感的业务宁可排队，也不要让单实例超载拖垮所有请求。

3.3 用统一网关把模型路由和灰度收口

底座对外不能直接暴露vLLM实例，否则业务绕过网关直连，升级、审计、计量全部失控。常见做法是在网关维护一张模型路由表，每个逻辑模型名对应一个后端服务，并支持按权重灰度切换：

网关还要统一做三件事：API Key鉴权、按业务线配额限流、token用量计量与对账。验证链路连通的最小命令，是直接模拟一次业务调用，确认路由、鉴权和计量都正常：

curl -s http://gateway:8000/v1/chat/completions \ -H "Authorization: Bearer sk-xxx" \ -H "Content-Type: application/json" \ -d '{"model":"qwen72b-chat","messages":[{"role":"user","content":"测试网关连通性"}],"max_tokens":64}'

这里的sk-xxx是网关下发的测试密钥，真实环境要按业务线独立下发，便于审计和成本分摊。返回体里要核对model字段是不是命中了预期路由，而不是只看HTTP状态码。

3.4 并发上不去，先查这三个指标

本地部署大模型后，排障第一步不是改参数，而是看指标。vLLM自带Prometheus指标端点，最有用的两个是：

curl -s http://localhost:8001/metrics | grep -E "vllm:num_requests_running|vllm:gpu_cache_usage_perc"

num_requests_running表示正在处理的请求数，如果长期贴近max-num-seqs，说明实例已经满载，排队时间会快速上升；gpu_cache_usage_perc表示KV Cache利用率，接近1说明显存跑满，优先检查是不是输入长度异常偏长。三个指标的经验对应关系是：cache打满看max-model-len和量化方式，请求排队看max-num-seqs和副本数，TTFT变慢看tensor-parallel-size是否匹配卡间通信带宽。另外，压测一定要用业务侧真实prompt分布，固定长度的短文本压出来的结果没有参考价值。

4. 数据接入与RAG知识库：让数字底座接上企业存量数据

4.1 企业数据接入底座，先分清三种形态

大模型在企业落地的第一条路几乎都是RAG：不训练模型，把知识喂给底座，让模型带着企业数据回答。RAG落地快，但数据接入不能想当然，企业数据通常分三种形态。

结构化数据在库里，通过SQL查询或CDC同步，RAG检索的不是数据本身，而是描述库表和字段的元数据；非结构化数据是文档，先解析成文本再切分入库；实时数据走Kafka这类流管道，用于补充动态上下文。底座里常见是一个统一的数据接入层，把三种来源归一成"文档片段加向量"的格式，交给RAG服务统一消费。

4.2 文档入库的RAG最小管道

最简链路是"加载文档、切分、向量化、写向量库"四步，代码量不大：

from langchain_huggingface import HuggingFaceEmbeddings from langchain_milvus import Milvus from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.document_loaders import DirectoryLoader # 1. 加载指定目录下的文档 loader = DirectoryLoader("./docs", glob="*.md") docs = loader.load() # 2. 按语义边界切分，而不是按固定字符硬切 splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=64, separators=["\n\n", "\n", "。", "！", "？"] ) chunks = splitter.split_documents(docs) # 3. 中文检索用BGE系列Embedding，比通用英文模型稳 embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-large-zh-v1.5" ) # 4. 写入Milvus集合 vector_store = Milvus.from_documents( chunks, embeddings, connection_args={"host": "milvus", "port": "19530"}, collection_name="enterprise_kb" )

这段代码的关键点有三个。第一，切分器用RecursiveCharacterTextSplitter，separators按中文标点优先排序，避免一句话被拦腰切断；chunk_overlap的意义是保留跨切片的上下文线索。第二，Embedding模型用BGE系列，中文检索效果明显优于通用英文Embedding，中小规模场景bge-large-zh-v1.5就够，多语种或长文本场景再看bge-m3。第三，connection_args指向Milvus服务地址，collection_name按知识域分开建集合，便于权限控制和增量更新。

4.3 切分参数不能一套走天下

一份方案里最常见的坑，是所有文档统一用一套chunk_size。十类文档用一个512，合同问答上下文撕裂，技术手册又被截断。比较实用的做法是按文档类型分开配置：

调切分参数比反复换Embedding模型更见效。上线前花半天把存量文档按类型过一遍切分，RAG的命中率通常有肉眼可见的提升。切分后建议做一次抽样检查，确认没有把表格拆散、没有把条款编号和正文分开。

4.4 检索召回不理想，按顺序排查这四个位置

文档入完库，问答效果不行，按顺序查四件事。第一，查询和文档的术语体系是否一致，不一致做query改写或用同义词扩展。第二，Embedding模型是否匹配业务领域，用50条真实问题逐条验证Hit@3指标。第三，向量检索的top_k结果直接透传不够稳，加一层Rerank重排：

from sentence_transformers import CrossEncoder reranker = CrossEncoder("BAAI/bge-reranker-v2-m3") pairs = [(query, doc) for doc in candidates] scores = reranker.predict(pairs)

Rerank模型直接对"查询-文档"对打分，把向量检索召回的几十条候选重新排序，top5准确率通常提升明显。代价是额外时延，几十条候选大约多几十毫秒，对实时问答可接受，但底座里不要同时挂多个Rerank模型。第四，做增量更新：文档变更后重算切片并upsert到向量库，防止旧版本内容一直霸占召回。四件事做完还不行，才考虑动Embedding模型。

5. 模型微调与Agent编排：在底座上长出企业自己的业务能力

5.1 先判断该不该微调，再谈框架

RAG解决"模型不知道"，微调解决"模型不会按你的规矩做事"。企业里真正该微调的通常是三类场景：业务领域术语体系强、通用模型答不准；输出格式有硬约束，比如合同审查要按固定条目返回；行为规范需要对齐，比如客服不能乱承诺。反过来，数据量不足、知识要实时更新、需求变化快的场景，微调都不合适。

下沉到实操，我一般建议先用基座模型加RAG跑通业务，收集足够多的坏case之后，再决定是否微调。一上来就微调的，数据质量和数据量都是过不去的坎。

5.2 用LLaMA-Factory跑LoRA微调的命令与数据格式

底座里的微调平台，最常用的开源工具是LLaMA-Factory，它把SFT、DPO等流程封装成命令行和WebUI，配好数据集就能跑。微调数据用JSONL，一行一条，示例是这个样子：

{"instruction": "根据合同条款判断付款条件是否满足", "input": "合同编号HT-2024-001，项目已验收……", "output": "根据合同第5.2条，验收合格后30日内付款……"}

指令、输入、输出三段式是SFT最通用的格式，instruction写任务描述，input写业务输入，output写期望输出。数据量上，一类任务起步500到1000条，低于这个量级先别微调，优先优化RAG。

然后启动LoRA微调：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --peft lora \ --dataset contract_review \ --template qwen \ --output_dir ./checkpoints/qwen7b-contract-lora \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --lora_rank 16

这里的关键设计是：冻结原模型权重，只训练低秩适配器，7B模型在一张24G显存的卡上也能跑。per_device_train_batch_size是单卡批大小，gradient_accumulation_steps做梯度累积，两者相乘才是有效批大小。learning_rate常用区间是1e-4到2e-4，超出容易灾难遗忘。几个常见超参的经验值如下：

训练完不是直接部署，要先把LoRA适配器合并回基座模型，再注册到模型仓库：

llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path ./checkpoints/qwen7b-contract-lora \ --template qwen \ --export_dir ./merged/qwen7b-contract

提示：导出时基座模型必须和训练时完全一致，版本不一致会出现tokenizer错位，症状是回答开头乱码、中间莫名截断，这类问题最难排查。

合并后的权重上传模型仓库，在网关路由表注册新版本，按老版本100%、新版本5%起步、再逐步放量的节奏灰度。

5.3 Agent编排：让模型按业务规则调用工具，而不是全自治

微调解决单段式任务，企业真实流程往往是多步的：查合同、比对条款、再给出结论。Agent编排就是在这套流程上加一层可控的工具调用。底座里落地Agent，建议从function calling开始，先固定流程模板再谈自治：

from openai import OpenAI client = OpenAI(base_url="http://gateway:8000/v1", api_key="sk-xxx") tools = [{ "type": "function", "function": { "name": "query_contract", "description": "按合同编号查询合同文本中的指定条款", "parameters": { "type": "object", "properties": { "doc_id": {"type": "string", "description": "合同编号"}, "item": {"type": "string", "description": "条款关键词"} }, "required": ["doc_id"] } } }] resp = client.chat.completions.create( model="qwen72b-chat", messages=[{"role": "user", "content": "查一下HT-2024-001的付款条件"}], tools=tools, tool_choice="auto" )

这段代码里，模型不直接执行查询，而是返回tool_calls，由底座编排层去调用授权的业务接口，把结果回填给模型生成最终回答。编排层的设计重点有三个：工具定义要有JSON Schema校验和权限绑定，工具执行要设超时和重试，执行结果要截断长度再回填。企业Agent别一上来就追求完全自治，先固定任务模板、限定工具范围、保留人工确认节点，跑稳三个月再逐步放开。这一步的工程可靠性，决定底座从"能问答"走到"能干活"。

6. 数字底座上线后：三个验证手段和一个成本压法

6.1 评测集先行，模型升级必须过门槛

底座上线后的第一件正事，是建一份golden评测集。从真实业务流量里攒50到200条标注数据，每条含输入、期望输出和评分维度：答案准确率、格式规范率、拒答正确率。每次模型升级、prompt调整、RAG参数变更，都跑同一份评测集并记录结果。自动评测可以用LLM as judge打分，但每周抽样人工复核一次，防止评分模型被自己的话术带偏，也防止评测集被过拟合。

6.2 压测看三个数字：TTFT、TPOT、吞吐

第二件正事是压测。vLLM自带serving benchmark脚本，可以直接对网关做端到端压测：

python benchmarks/benchmark_serving.py \ --model qwen72b-chat \ --base-url http://gateway:8000/v1 \ --num-prompts 500 \ --request-rate 20 \ --max-concurrency 64

压测报告里固定看三个数字：TTFT首token时延，TPOT每token生成时延，整体吞吐。内部办公场景经验值是TTFT低于2秒，客服场景低于1.5秒，超过就要排查是上游排队、显存瓶颈还是网卡带宽。压测的prompt必须来自业务真实分布，同时包含长短文本、中英文混合、长上下文检索，否则测出的数据不能用于容量规划。

6.3 成本压不下来，优先动这三个开关

到最后，底座通常会发现：模型能力不是瓶颈，成本才是。三个开关按实施顺序排列：

这三个手段常被误解为"用质量换成本"，实际上对绝大多数业务场景，量化后的质量损耗很小；冷热分流靠网关规则实现，规则要能统计命中率和回滚；语义缓存只适用于RAG知识问答这类确定性场景，开放生成不能用。把评测集通过率、压测TTFT、每万token成本三个数字固定进每日巡检，后续任何模型替换、参数调整都有基线可对齐。这三个数字不达标之前，不要谈新场景扩容。

本文还有配套的精品资源，点击获取