盘古大模型落地指南：从 L0/L1/L2 分层到 ModelArts Studio 实践

大模型落地最常见的误区，是把它当成"换个更聪明的 API 而已"。实际上，企业真正需要的不是一个通用聊天窗口，而是在具体业务场景里稳定、可控、算得起账的模型能力。

华为盘古大模型的思路很有代表性：不做"一个模型打天下"，而是分层设计，再配合华为云 ModelArts Studio 的大模型托管与推理服务，把能力送到业务手里。本文从架构讲到实践，最后给出一张落地检查清单。

一、盘古的分层设计：L0 / L1 / L2

盘古大模型采用"基础大模型 + 行业大模型 + 场景模型"的三层结构：

这个分层解决了一个现实矛盾：L0 通用能力虽强，但对行业术语、业务流程、数据口径一无所知；而直接从头训练行业模型，成本和数据量又不现实。 在 L0 之上用行业数据继续训练得到 L1，再针对具体场景做微调与工程封装得到 L2，是性价比最高的路径。

以盘古 5.0 系列为例，公开信息显示其在多模态、强思维、Agent 等方向持续演进，参数规模覆盖十亿到万亿级。对绝大多数企业来说，真正用得上的其实是 L1/L2 这一层。

二、ModelArts Studio：大模型即服务平台

如果说盘古是"模型"，ModelArts Studio 就是"把模型变成服务"的地方。它的核心模块包括：

• 模型广场：除盘古系列外，还托管了 DeepSeek、Qwen、Llama 等主流开源模型，可以直接体验、对比；
• 我的模型：支持对托管模型做微调（LoRA、全参），产出自己的模型版本；
• 推理服务：在线推理与批量推理，可选择公共资源或专属资源池；
• 应用编排：RAG 知识库、工作流、Agent 等能力，把模型接进业务流程；
• 模型评测：对比不同模型/版本在自有评测集上的表现。

一个常见的误解是"上了平台就能自动落地"。平台解决的是工程效率问题，场景选择、数据质量、评测标准仍然要靠业务团队自己。

三、企业落地四步法

3.1 第一步：场景选型

不是所有场景都值得上大模型。可以用三个问题快速筛选：

1. 价值密度：该环节的人力成本、错误成本是否足够高？
2. 容错空间：错了能不能被人工兜底？高频、低风险场景优先；
3. 数据可得性：有没有足够的领域文档、问答对、操作记录？

典型的高价值起点：合同/工单/报告的辅助生成、知识库问答、代码补全、质检报告理解。反过来，强合规、零容错、实时性要求极高的场景要非常谨慎。

3.2 第二步：数据准备

大模型项目的成败，八成在数据。三个关键动作：

• 知识资产盘点：把散落在 OA、Wiki、工单系统里的文档统一收集，标注时效性与权威性；
• 清洗与脱敏：去重、去噪、去掉过期版本；个人信息与商业机密必须处理；
• 切片策略：RAG 场景下，切片太大导致检索不准，太小导致语义残缺。实践起点可以取 512～1024 token，重叠 10%～20%，再根据召回效果调整。

3.3 第三步：微调还是 RAG？

这是被问得最多的问题。一句话判断：

很多团队一上来就做微调，最后发现模型"背"下了知识但不会用。知识归 RAG，能力归微调，这条界线划清楚能省很多钱。

3.4 第四步：评测与上线

没有评测集的微调等于盲调。建议至少准备 100～300 条覆盖典型场景的评测样本，关注四个维度：

• 准确性：答案是否正确、是否引用了正确资料；
• 幻觉率：无依据编造的比例；
• 时延：首 token 时间与完整响应时间；
• 成本：单次请求 token 消耗与单位调用成本。

上线节奏上，先内部灰度，再小流量对外，最后全量。保留回滚开关，是比任何优化都重要的工程习惯。

四、动手：调用托管模型的推理服务

在 ModelArts Studio 中部署模型后，控制台会提供"调用指南"，包含服务地址、鉴权方式和请求示例。大多数服务使用标准的对话补全协议，下面是一个通用示例（地址与模型名请替换为控制台实际值）：

import os

import requests

API_KEY = os.environ["MAAS_API_KEY"]          # 建议从环境变量读取
BASE_URL = "https://{your-endpoint}/v1/chat/completions"
MODEL = "{your-model-name}"

payload = {
    "model": MODEL,
    "messages": [
        {"role": "system", "content": "你是一名严谨的行业知识助手，不确定时请说明。"},
        {"role": "user", "content": "请总结这份设备检修记录中的异常项。"},
    ],
    "temperature": 0.3,
    "max_tokens": 1024,
}

resp = requests.post(
    BASE_URL,
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json=payload,
    timeout=60,
)
resp.raise_for_status()
print(resp.json()["choices"][0]["message"]["content"])

如果你使用的服务支持 OpenAI 兼容协议，也可以直接用 openai SDK，把 base_url 指向平台提供的地址即可。具体协议以控制台调用指南为准，不同模型、不同部署方式的鉴权方式可能不同（如 IAM Token 与 API Key 的区别）。

五、RAG 最小闭环

企业知识问答是最容易见效的落地场景，最小闭环如下：

graph TB
    A[业务文档] --> B[解析与切片]
    B --> C[向量化 Embedding]
    C --> D[向量数据库]
    E[用户提问] --> F[检索 Top-K 片段]
    D --> F
    F --> G[拼装 Prompt]
    G --> H[盘古/托管大模型]
    H --> I[带引用的回答]

每个环节都有容易踩的坑：

• 解析：PDF 表格、扫描件是重灾区，解析质量差会直接污染知识库；
• 检索：纯向量检索对专有名词不友好，建议"向量 + 关键词"混合检索；
• 重排：加一层 Rerank 模型，通常能明显提升 Top-K 的准确率；
• 引用：让模型输出引用片段编号，既方便溯源，也降低幻觉的采信率。

六、安全与合规

企业大模型的合规成本常常被低估。几个必须提前设计好的点：

1. 数据不出域：敏感行业优先选择专属资源池、VPC 内访问，避免数据经过公网；
2. 权限隔离：模型、知识库、应用按项目隔离，IAM 细粒度授权；
3. 内容安全：输入输出都要过内容审核，尤其是面向 C 端或对外服务的应用；
4. 审计留痕：记录调用日志、模型版本、知识库版本，出问题能追溯到具体链路；
5. 模型版本管理：生产环境禁止直接使用"最新版本"，必须锁定版本号。

七、常见的五个坑

结合社区案例，总结几个高频问题：

1. 为了用大模型而用大模型：规则引擎能解决的问题，不要交给模型；
2. 只微调不评测：效果好坏全凭感觉，上线后问题集中爆发；
3. 知识库大而全：把所有文档一股脑塞进去，检索噪音反而增大。知识库要"小而准"，按业务域拆分；
4. 忽视 Token 成本：长 Prompt + 大上下文会迅速放大成本，压缩上下文、做缓存是必修课；
5. 忽视并发设计：演示时单人可用，一上量就超时。压测与限流要在上线前完成。