企业官网建设流程全解析

我的第一反应是不可能。但当我真的在那张只花了 30 元租来的 GPU 卡上，用不到两个小时的时间训练出一个参数量只有 1200 万的小 transformer，并且把客服工单自动分类任务的 F1 值直接拉到了 0.93，而此前我用某个大模型 API 折腾了三天、烧掉了一百多块，指标也才 0.76 的时候，我知道这件事值得拿出来好好聊一聊。不是要否定大模型，而是要替小模型说几句公道话。在很多垂直、窄域、重复性极强的场景里，真正好用的不是那个全能选手，而是一个你了解它全部脾气的小模型，一个你亲手训练过、知道它会在哪里犯错的小模型。这篇博客就把我这一个半小时到底做了什么、为什么它能赢、边界在哪里，以及如何复现这个判断讲清楚。

1. 我为什么放着大模型不用，要转身去训练一个小模型？

先交代背景。我的任务是在公司内部的客户服务系统上做一个“工单自动分派”：当用户提交一条包含产品型号、故障代码和口语化描述的工单时，模型需要自动判断该转给硬件组、软件组、售后分析组还是财务退款组。表面上看这是典型文本分类，用大模型的 zero-shot 能力应该就像开卷考试一样简单。

然后真的开始开卷以后，问题暴露得比想象中更快。首先是价格，每条工单平均 800 个 token，用一次大模型 API 的成本在 0.002 美元左右，听起来不贵，但一天有 5 万条工单，那就是 100 美元，一个月下来可以买一张像样的消费级显卡。其次是延迟，那种边聊边等接口返回的体验，在自动化生产线上根本不可接受。最要命的是结果不稳定。同一个工单今天我把它分到软件组，明天模型就可能给你改判成硬件组，它不会告诉你原因，只是概率稍微变化了一点。有一次系统连续三天出现了 12% 的“幻觉改判”，直接导致积压了一百多个本该当天处理的上门维修请求。

这件事让我意识到一个关键点：大模型的最大能力是“泛化”，但泛化恰恰是它在生产环境里的短板。它要对全世界所有文本负责，就没有办法对一个公司内部特有故障代码库倾注足够的注意力。我需要的不是一个知识渊博的通才，而是一个只认识我们这一本“故障字典”的专科医生。大模型适合做需要世界知识的事，比如“帮我解读这个客户可能是什么心情”；但我现在需要的是把“E-204”这个故障码和“路由器固件回退”这个动作精准地对应起来，这种知识绝大多数不存在于公开互联网语料集里，它只存在于我们过去三年处理过的工单历史之中。

2. 另一个残酷的现实是：就算我有了数据，不代表大模型就能真正学会

在决定训练小模型之前，我其实还试了第二个套路：给大模型做微调。想的是把三千条已经标注好的工单整理成 JSON，用标准的 instruction tuning 做预处理，然后让大模型基于这些样例回答问题。听起来很完美，训练流程上可以用成熟的 LoRA 方案，成本也可控，但真正执行起来后我发现这个选择仍然带着几个很棘手的前提。

第一，大模型微调之后不会忘掉它原来的“脾气”，它还是要基于大规模预训练语料去“猜”你公司内部的域，如果你只有几千条样例，它往往会倾向保留通用说法而忽略你对故障代码的强关联定义。第二是部署问题，我本来只想要一个轻量接口，结果一个动辄几十 GB 的模型翻个倍变成上百 GB，就算用 vLLM 做量化推理，也需要一台像样的服务器。第三是可控性，指令微调本质上是让模型学会“服从格式”，而不是学会“真正理解规则”。在分类任务上，模型的输出会遵循输入的 prompt 模板，但它的逻辑证据依然藏在黑盒里，出了问题你根本没有办法去剖析。

这让我反思为什么过去大家总觉得大模型是唯一解。本质上是因为写 prompt 门槛低、不需要标注数据、可以极快地做概念验证。但它忘了自己在进入生产环境的那一刻，面对的约束已经从“知识丰富”变成了“稳定、便宜、可解释”。稳定意味着同样的输入必须产生同样的输出；便宜意味着单次推理成本要足够低；可解释则意味着当一个故障码被分错时，我能顺着 attention 权重的热度找出到底哪几个 token 把模型带偏了。大模型在这三项上天然不占优。

第三个隐藏问题来自数据分布。公司工单里有很多简写、错别字、输入法和行业黑话，比如“路由不断重启”会被写成“路由老掉线”，“摄像头扫码无反应”会被写成“扫不到”。大模型处理这类口语化数据时经常会去“脑补”一个更文雅的说法，结果把真正的故障逻辑忽略掉。而且我后来仔细统计发现，这条工单流里其实存在大量重复模式：光“升级固件后 Wi-Fi 信号变弱”这一个模式就占了硬件组的 18%。这些有规律、可枚举、特征清晰的文本结构，正是小模型最擅长学习的类别。

3. 一个半小时的训练里，我到底是怎么跑的？

敲定方案后，我用了比较常见的小模型路线：自己从零开始构建一个轻量级 Transformer Encoder，而不是直接加载一个 BERT 权重。因为我的素材主要是中文工单，而且它带强烈的行业属性和专有名词，通用预训练模型里的英文常识和百科知识根本帮不上忙。按通用实践思路，我先准备了一个 400MB 的历史工单脱敏语料，训练一个基于字的小型 BPE tokenizer，然后让 transformer 在纯文本上完成下一词预测，最终这个步骤不到 15 分钟。

接下来是真正让模型理解“该分到哪个部门”的部分。我的数据集来自历史工单，大概有 1.2 万条已标注记录，我按 8:1:1 划分出训练、验证和测试。模型架构上我采用了自定义的 5 层 Transformer Encoder，隐藏层大小 256，head 数为 8，中间用的是 GELU 激活函数。整个模型参数量算下来大概 12.1M，这个尺寸跟目前普通大模型的差距不用解释。训练环境是一张租来的 NVIDIA A10（24G 显存），我只跑了大约 1.5 个小时，一共 24 轮。

这里有个很容易踩坑的点：不要直接上一个全局学习率。我最后使用的是一套比较稳定的方案，做两层优化：顶层靠 5e-5，底层的 embedding 和 tokenizer 层用更慢的 1e-5。因为是冷启动，没有加载任何预训练参数，所以前几个 epoch 的 loss 下降像是在爬楼梯，需要耐心一点。真正发生质变的是大概在 8 轮之后，F1 从 0.63 突然跳到了 0.82。这说明在窄域文本分布里，模型不需要 40 层，不需要在公共语料上预训练过，它只需要拥有足够的容量去编码专有词汇之间的共现模式。

表格里的核心超参数是这么定的：

模型中有一个很关键的细节：我特意在 tokenizer 里把故障码（如 E-204、SW-L1）作为单个 token 来处理，而不是让它被拆成多个子词。这保证了模型能从同一维度去 “关注” 这个故障 ID 与后面的行为描述之间的关系，而不是被迫去拼凑几个毫无意义的字节。这种 tokenization 级别的设计，往往是决定效果的分水岭。

4. 单跑通只是第一步，真正难的是验证它“赢了”并且“为什么赢”

训练完成之后我的动作是先做一次全量验证，拿模型跑 300 条我从未放进训练集的真实工单，把它们和大模型 API 的结果放在同一套评估脚本里逐条对比。最后得到的统计数据非常有说服力：我的小 transformer 在测试集上的 macro-F1 是 0.93，准确率 0.95；大模型 API 在同样的 300 条数据上跑三轮，取最好的一次，F1 也只有 0.76。而且大模型的稳定性问题已经到了一种让我没法把它放在生产流水线上的程度——它同一批数据被重复调用三次，有两条的预测标签是完全不一样的，这还是同一个温度参数下产生的结果。

那“为什么”赢？我拆解下来有三个原因。第一是模型能力被用在了正确的方向：大模型需要分出一部分神经元去记忆历史人物、科学百科、文学常识等，但我的工单分类任务根本用不到这些知识；小型 transformer 的每一层都在学习“哪个词之后多半属于硬件组”这种直接的局部模式。第二是我给了模型正确的输入表示：把故障码整段落进 tokenizer，把历史语料中“无线网络”“USB 接口”这种高频复合词进行联合处理，这会显著降低模型需要探索的隐空间。第三是训练目标与评估目标一致，我用的是普通的交叉熵分类头，评估自然就用分类指标，这中间没有 prompt 模板差异、没有 temperature 波动，误差封闭在一个可重复推导的流程里。

更值得说是边界。我这里说的“赢”只针对这个分类任务，并不是什么通用推理测试。我拿一个小 transformer 去生成一段长文、去做多轮对话、去解答开放式问题，大概率还是会被大模型按在地面上摩擦。我不能因为这次实验成功就断言“所有小模型都能吊打大模型”，这既不准确也不公平。我的观点更保守：在任何一个有稳定分布、有标注数据、任务边界足够清晰的窄场景里，小模型能够用更低的时间和算力成本，取得更稳定的成绩，而且这种稳定在大生产的场景中可能比绝对的 F1 数值更值钱。

大模型在通用知识和少样本上有不可替代的优势。但如果你现在有一条几千条起标注的工作流，并且这些数据高度同质，那么先跑一遍训练成本测算，再愿意拿出来 1.5 个小时做实验，我个人是强烈推荐的。你可能不会得到和 LLM 一样的通用性，但你也不会因为一次模型升级让调用参数悄悄改变分派结果而半夜爬起来救火。

5. 把实验复现出来，你需要关注的核心步骤和坑

为了让你们也能在一个半小时内尝试出类似结果，我把一套完整的操作流程拆成相对清晰的六个步骤。这不是唯一方案，尤其在具体数据和硬件上可能都会有一种更适合的调整。但作为通用处理思路，它的顺序值得校验：

第一个步骤是数据清理和统计。不要直接拿原始工单丢给模型，先做预处理：把所有客户姓名、电话、地址等敏感信息去掉，将文本长度超过 200 字的长工单做一次切分，只保留包含故障码最多的一截作为主文本。之后再统计类别的分布，如果某个部门的工单数量极少，可以先做法类别合并，或者增加该类的重采样权重。

第二步骤是训练一个 domain-specific tokenizer。很多人一上手就喜欢加载开源的 BertTokenizer，但开源分词器不可能认识你内部的“MSL3-FW”这类符号组合。更实际的做法是用 400 到 800MB 的相关语料训练一个 30k vocab 的 BPE tokenizer，然后把模型里的unk率控制在 0.5% 以下，否则大量的业务词汇被切开后分类效果好不了。

第三步骤是选择合理的 Transformer Encoder 结构。不要从零开始写 multi-head attention，那太耗时了。直接用 HuggingFace 的BertConfig或者RobertaConfig把num_hidden_layers设为 5，hidden_size设为 256，然后通过BertForSequenceClassification去初始化一个不带预训练权重的模型。很多新手会以为必须加载权重才能训练，但实际上从零开始一个小层数的模型，在上万条数据场景下完全可以收敛，而且收敛速度比想象中要快。

第四步骤是训练策略。我做了两个让效果相差很大的决定：一是把句子最大长度限制成 128，后来测试从 512 降到 128，我不仅没有损失指标，反而由于去掉了长尾无用填充，训练速度大约提升了 1.6 倍。二是把学习率分成两组，一个是 embedding 层，一个是分类头。给 embedding 学习率设置的比分类头小一个数量级，本质上是让模型不要因为少量迭代就大幅重排词向量，避免泛化能力崩塌。

第五步骤是建立基线对比。我强烈建议在训练之前就把大模型 API 的预测结果保存下来，并且用完全相同的验证集分批跑一遍。这样对比才有意义。注意把大模型 API 的温度设为 0，但即使温度是 0，不少 provider 仍会给你非确定性的输出，所以一定要多跑几次取一个区间，而不是拿一次偶然结果来说事。

第六步骤是上线前的闭环检验。小模型训练出来后不能只看 F1，还要人工抽查至少 50 条预测错误，建立一个“错误模式清单”。比如我训练出的模型早期经常把“发票打印失败”分到软件组而漏掉售后服务，后来我在训练数据里补充了一些特殊规则之后才解决了。模型永远不可能学到它没见过的关键词，这种业务规则的历史积累实际上比调参更能提升效果。

注意：不要一上来就把 training steps 拉满。我遇到最多的问题其实是显存溢出，或者因为学习率太大导致 loss 不降，这类情况往往把 batch size 改小一点就立竿见影。完全不需要在一开始就追求 perfect 的超参数。

6. 决定用“小模型＋大模型”组合，才是这一轮最大的收获

做完这个实验之后，我并没有把原来的大模型接口整个关掉，而是调整成了双轨制。所有预测结果先由我的小 transformer 跑一遍，只有当预测置信度低于某个阈值（我用了 0.7，可以根据业务风险调整），或者遇到模型一开始就没有见过的全新故障码时，系统才会转发给大模型 API 做第二轮兜底。这样一来，90% 的流量都走在了小模型的高性价比路线上，真正碰到了少数陌生场景，再去调用更强模型去处理。

我也复盘思考了一下这套组合的边界。小 transformer 不能覆盖的情况主要包含三类。第一类是在文本里没有明显故障码或模式、完全需要常识推理的泛化问题，比如“客户情绪很激动，我如何处理”——这类需要上下文推理的让我宁愿让大模型处理。第二类是数据量严重不足的问题，遇到一个只出现三次的全新部门标签，小模型根本归纳不了任何模式，此时大模型带有强大的先验知识反而比小模型值得采用。第三类是开放式文本生成，比如要求生成一段工单回邮，小模型没有相关的能力场景，就不要拿着软尺寸硬撑着。

如果你问我这次 1.5 小时训练的意义到底是什么，我的答案其实很朴素。它不是让你把所有大模型换成小模型，而是提醒你，在任何生产系统里都有一个关键的判断：我到底需要一台什么都会的通用大脑，还是一个只认识我们家走廊的巡逻保安？使用预算不是越大越好，而是在约束条件下变得刚好用。这个判断决定了你的成本、你的上线速度，以及最后在深夜两点出现突发故障时你能不能睡得着觉。

最后给你一个我特别想强调的操作建议：如果你想复现这个路径，最快的方式不是从零复刻我的代码，而是先从一个你已经有了几万条真实标签数据的分类任务开始，用 1 小时去跑通小模型流程，再用 15 分钟去写一个大模型 API 的对比脚本。最后你一定会看到我问过自己的那个问题——真正的瓶颈并不是模型的大小，而是你有没有把“任务边界”这个最早的问题先搞清楚。