企业官网建设流程全解析

三个月前，我们团队做了一个看起来有点疯的决定：不融资、不扩招，用三个月时间，从零训练一个能打的模型，在核心指标上逼近Deepseek。陈大年是团队里负责拍板的那个人，他说“别搞大而全，就照着我们的业务场景做，跑赢Deepseek的一个子集就赢了。”结果是，第三个月末的评测里，我们在自建测试集上把与Deepseek的差距压缩到了不到3个百分点，有几个细分任务甚至打了平手。这篇文章就是这三个月完整的技术复盘，包括目标设定、数据怎么凑、训练怎么调、评测怎么设计，以及中间踩过的所有坑。如果你也在做模型落地、微调或者本地部署，这里面的思路和教训应该能帮你少走不少弯路。

1. 目标设定：为什么三个月敢去追成熟模型

1.1 一句话说清楚我们要做的事

先说结论：我们不是想复刻一个通用大模型，而是想针对特定的行业场景，交出一个“够用且能落地”的模型。

Deepseek这类模型强在哪，用过的人都有数：通用知识扎实、指令理解能力强、中文表达自然。但把它真正放到某个垂直业务里，问题也很明显——回答偏“泛”，没有内部术语体系，不敢直接拿来做关键决策。我们要做的，就是在保留基础能力的前提下，让模型在特定场景里比它更懂行、更精准。

所以陈大年定的目标很克制：不追求全面超越，只要求在三个自建业务场景里，把准确率追到Deepseek的95%以上。这个目标看起来保守，实际上三个月时间非常紧张。因为“追到95%”不是拍脑袋估的，而是要把评测集拆成几百道题，一题一题过、一个错误一个错误地消，非常磨人。

1.2 为什么选“领域追赶”而不是“全面超越”

很多人问，既然要用三个月追Deepseek，为什么不直接全面复刻？原因很现实：算力、数据、人才，三样都打不过，硬拼只会浪费时间。

通用大模型的竞争，本质上是“算力+数据规模”的竞争。一个几十人、几张卡的小团队，去追千卡集群训练出来的模型，基本没有胜算。但我们能赢的地方是“场景深度”：Deepseek再强，它不会给你的内部数据库单独做适配；它懂通用的客服话术，但不懂你业务里那些缩写、黑话和异常流程。

这就引出第一个关键经验：选对标方向时，不要拿自己的短处去碰别人的长处，而是找一个对方“虽然能做但没专门优化”的领域，打差异化。陈大年原话是“我们不做第二个Deepseek，我们只做Deepseek在某个角落里暂时不care的那块地。”这句话后来成了整个项目的定调。

2. 数据和训练策略：把劲用在对的地方

2.1 数据清洗与配比：宁可少而精，不要多而杂

模型效果七分靠数据，这是老生常谈，但真正执行起来，大部分人还是会被“多多益善”带偏。我们这次严格做了减法。

一开始团队成员从开源数据集、爬虫日志、公开文档里收集了大约60万条指令数据，第一轮直接洗掉一半。清洗规则并不复杂，但很实用：

• 去掉重复度超过80%的样本，防止模型反复背同样的答案。
• 过滤掉OCR乱码、HTML标签残留、语言混杂严重的脏数据。
• 对问题和答案做长度统计，去掉过短无信息量的样本。
• 人工抽检5000条，把与业务无关的通用闲聊数据单独拎出来，不混进训练集。

最终用于指令微调的高质量数据剩下约12万条。这个数字在行业里不算大，但覆盖率足够：业务问答占40%，复杂推理链占20%，格式生成类任务占20%，剩下的20%是通用对话与安全兜底数据。

配比非常重要。我们第一版训练时，业务问答占比超过70%，结果模型的通用能力崩得厉害，问一句“今天天气怎么样”都能回答得前言不搭后语。后来把配比调成上面的比例，通用能力才恢复过来。记住一个原则：垂直能力靠的是“高质量、高密度”，不是“高数量”。

2.2 基座选择与训练方式：LoRA起步，最后全参微调

基座模型我们对比了好几款开源权重，包括7B、14B和32B级别。陈大年的意见很明确：优先保证本地能部署，所以第一版锁定了7B量级。

训练方式上，我们没有一上来就全参微调。第一周先用LoRA跑通全流程，用小批量数据验证数据质量和评测流程是否合理。LoRA的优点在于显存占用低、训练速度快，适合快速试错；但它也有天花板，容量有限，学习复杂领域知识时容易“学不到位”。

所以第二个月，我们做了一个关键决定：在LoRA验证完思路后，切到全参数微调。这一步让模型效果有了质的飞跃，但同时带来了显存和稳定性问题。我们用的是DeepSpeed ZeRO-3加8卡A100，7B模型全参微调勉强能跑。如果你手里的卡更少，我建议用LoRA或QLoRA多跑几轮不同随机种子，也能达到类似效果，只是需要更长调参时间。

2.3 训练参数与算力安排：几组可以直接抄的配置

直接贴我们最终使用的关键超参数，方便参考：

特别注意学习率。LoRA阶段用2e-4没问题，但全参微调必须降到5e-5以下，否则模型会很快出现灾难性遗忘，表现为通用能力断崖式下跌。我们第一轮全参微调就吃过这个亏，训练到一半发现模型连“1+1等于几”都开始胡说，只能回滚重来。

算力安排上，建议不要一周七天全跑满。训练过程需要留出足够时间做评测和数据分析，最好是“训练两天、评测半天、数据分析半天、再接着训”。这样看起来慢，实际比闷头跑一个月再返工高效得多。

3. 评测对比：怎样才算“差点超过”

3.1 基准与测试集设计：不能只看跑分，要盯业务效果

评测是这次项目里最容易骗自己的环节。如果只用公开榜单的分数，你根本看不出模型差在哪。所以我们搭了三层评测体系：

• 第一层：公开基准，包括C-Eval、MMLU、GSM8K，用来监测模型通用能力的漂移。
• 第二层：自建业务测试集，从真实业务日志里挑出2000条问题，覆盖高频、中频、低频场景。
• 第三层：对抗性测试，人为构造难度更高的变体问题，比如改换问法、加入干扰信息、连续多轮追问。

第一层决定了模型“还是不是人话”，第二层决定了业务能不能用，第三层决定了模型是不是“死记硬背”。三层结果要一起看，不能只看某一层。

3.2 对比结果：强在领域，弱在泛化

下面是第三个月末的评测结果，对比对象是Deepseek的公开接口版本和本地部署的蒸馏版本。

数据说得很清楚：通用能力还差5到6个点，但业务场景里差距缩到了2.5个百分点。有几个难度中等的任务模板，我们的准确率甚至超过了Deepseek，因为那些术语和答法就是从真实业务里学来的，属于“主场优势”。

“差点超过”这个说法，准确来讲是在特定子集上接近，离全面超越还有一段距离。这个结果也验证了最初的定位：小模型走深度定制路线，确实能咬住大模型的尾巴。

3.3 部署与本地加载：不能只跑分，还要能落地

跑分好看只是第一步，最终客户要看到的是“本地部署能不能跑、响应快不快”。

这里提一下模型导出与推理压测。全参微调完成后，我们用vLLM部署了FP16版本，同时用llama.cpp导出GGUF格式做CPU推理测试。7B模型的FP16版本在单张A100上可以跑到每秒40个token左右，4-bit量化后放在32G内存的服务器上，每秒也能有15到20个token，足够支撑内部工具和客服助手类场景。

如果你的生产环境只允许离线CPU推理，建议直接用GGUF量化，优先用Q4_K_M档位，兼顾体积和效果。别用Q2，那是给实在没内存的机器准备的，效果损失太明显。实际压测时，我们还发现并发请求超过16路后，vLLM的排队延迟会急剧上升，所以生产环境一定要配负载均衡，不要单点裸奔。

4. 踩坑实录：训练损耗、过拟合和一切意外

4.1 损失在降，评测不升：最典型的伪健康信号

训练过程里最容易遇到的问题，就是loss一直在降，但评测分数纹丝不动，甚至倒退。我们第二周就撞上了。

排查思路分三步。第一步，检查训练集和评测集是否同分布。我们发现有大量训练数据来自旧版业务文档，而评测集用的是新版本话术，术语变了，模型自然答不对。第二步，检查评测集是否有歧义或错误答案。人工抽检时发现大概有3%的标注错误，这些错题会严重干扰小模型的分数。第三步，确认模型没有过拟合到训练数据的表面形式，比如只记住“幸福都是奋斗出来的”这类金句，却在语义理解上偷懒。

最后解决方法是：清洗训练数据中的旧文档，重新标注评测集，并加入更多“改写题”让模型学会语义不变换表达。修正之后，评测分在两天内就涨了4个点。

4.2 回答截断与输出token上限：生成不完整是隐形杀手

很多小团队只盯训练，不盯推理，结果模型上线后被人吐槽“话只说一半”。我们一开始也踩了。

Deepseek等模型默认输出长度可能比较保守，但我们自己的模型因为训练数据里有一些超长答案，导致模型倾向于生成很长的回复。在vLLM部署时，如果max_token设置得太小，比如128，就会频繁截断。更麻烦的是，用户问一个简单问题，模型还非要用“首先、其次、最后”三板斧，把简单问题说复杂。

解决方法是：在训练数据里强制加入大量“简洁回答”模板，同时在推理参数里设好max_token上限，配合温度0.3和top_p 0.9，基本能压住废话问题。如果你发现模型仍然“意犹未尽”，可以在系统提示词里直接写“请用不超过50个字回答”，效果立竿见影。

4.3 常见问题速查：训练与本地部署避坑清单

除了表里的问题，还有两个容易被忽略的细节。

第一个是随机种子。同样配置，换个随机种子，业务集分数可能差2到3个百分点。小模型尤其明显，所以正式训练前一定要多跑几个种子，选最稳定的结果，不要只看一次训练。

第二个是数据泄漏。我们在自建测试集里发现有一部分数据直接来自训练语料的公开渠道，导致分数虚高。后来用n-gram重叠检测把训练集和测试集高度重合的样本全部剔除，分数才变得可信。

5. 从三个月复盘里得到的最终体会

项目收尾那天，陈大年看着评测曲线说了句实话：“我们追的不是Deepseek，我们追的是用户对‘可用’的定义。”这句话我到现在印象都很深。

这三个月让我最受用的经验至少有两点。

第一，小团队做模型，不要被“榜单焦虑”绑架。拿一个7B模型去跟几百B的模型比综合排名，没有意义；对比基准应该来自你自己的业务场景，而不是别人的排行榜。我们的自建测试集虽然采样规模不大，但每一题都来自真实需求，这样的评测才真正指导了训练方向。

第二，训练之外的大半工作量，都花在了数据清洗和评测设计上。实际算下来，真正跑训练的时间只占30%，剩下70%都在处理数据、分析badcase、调整评测集。很多团队觉得“模型不行就换配置多跑几轮”，其实数据和评测没做扎实，再跑多少轮也是原地打转。

最后再分享一个小技巧：每次训练完，一定把badcase截图存档，按错误类型分类。后面每次调完参，先不看总分，只看这些badcase有没有被修复、有没有新的badcase冒出来。这种方法比盯总分数更灵敏，能让你提前判断这次调整是变好还是变坏。三个月下来，我们积累了四百多条badcase记录，最后两周的每次迭代都靠它们做决策。

项目结束后，我们没有急着去追更大的开源模型，而是先把这套数据清洗和评测流程固化了下来。下一阶段打算把业务数据从12万条扩到50万条，再试一次全参微调。三个月的时间确实短，但证明了一件事：方向对、数据精、评测准，小团队也能在某个角落里和大模型掰一掰手腕。