企业官网建设流程全解析

1. 先拆一层：大模型训练到底在“学”什么

1.1 大模型不是数据库，它是在学“下一个词的概率”

很多第一次接触大模型的人，会把它理解成一个巨大的知识库：你问一个问题，它去“查”答案然后返回。这个类比在应用层偶尔成立，但放在训练视角看，偏差很大。大模型的核心训练目标是预测下一个 token，也就是根据前文所有内容，给出下个词的概率分布。它没有显式的“知识表”，也没有多少人能解释清楚某个答案具体存在哪一个参数里。参数只是把训练数据里的统计规律压缩到了一张巨大的网络中。

这种压缩依赖自注意力架构。每一步计算，模型都会把上下文里所有 token 的信息按相关性加权融合，再逐层抽象出更高层的语义。预训练阶段做的事情，就是反复执行“看前文、预测下一词、计算误差、更新参数”这四个动作。优化器会用梯度信息微调参数，让模型越来越擅长这种概率预测。只要你意识到这件事，就能解释很多现象：为什么模型会在常识问题上犯低级错误？因为它预测的是“语料里最常出现的搭配”，而不是“逻辑上必然正确的答案”；为什么模型会产生幻觉？因为低概率但也可能出现在语料里的错误组合，同样会被赋予概率，生成时一旦采样到，就出现了瞎编文本。

理解了这一点，再看训练和应用的差别，就会少很多不切实际的预期。

1.2 Token、上下文窗口和参数数量：这些数字到底代表什么

训练和推理底层处理的最小单位不是字，也不是词，而是 token。一段中文先要被切分成若干 token，然后映射成词表中的一个 ID。分词的好坏直接影响模型对语义的捕捉：同一个字在不同上下文里含义不同，如果词表切得太碎，模型需要更多层才能拼出语义；切得太粗，又会牺牲泛化能力。常见的算法会综合考虑词频和子词拆分，找到压缩率与表现力的平衡。

上下文窗口指模型最多能同时“看到”多少 token。窗口越大，一次性处理的内容越多，但计算成本也越高。参数量则是可学习权重的总数，7B 就是 70 亿个参数。参数量决定了模型容量的上限，但决定上限能否发挥的关键，往往还是数据。一个只靠英文语料预训练的大模型，即使参数很多，中文专有名词的 token 切分也可能很别扭，输出难免有一种“翻译腔”。反过来，同样规模的模型如果中文语料配比合理，中文任务效果可能明显更好。所以选基座模型时，除了看参数量，也要关注词表构成和数据来源，最好用自己的行业术语做一组小测试。

1.3 幻觉不是 bug，是统计学习的代价

幻觉问题现在几乎成了大模型落地的头号痛点。本质上，模型并不知道“事实”和“编造”的边界，它只是按照条件概率生成最合理的文字。如果某个冷门知识点在训练语料里出现次数很少，模型可能只记住了大致的模式，一旦被问到底层细节，就会用语料中常见的模板填坑，填出来的内容自然不对。

应用层应对幻觉，不能只靠模型自身的“自觉”，要引入外部证据链。比如 RAG 检索，回答时附上检索到的原文；再如提示模型“如果没有把握，直接说不知道”。这些软约束能把很多幻觉风险挡在门外，但不能完全消除。训练阶段如果数据噪声大、重复多，也会加剧幻觉，因为它把错误的共现关系当成了规律。所以从训练到应用，数据质量是一条贯穿始终的生命线。

2. 训练工程三大核心：数据、算力、稳定性

2.1 数据清洗：决定模型气质的第一道关卡

预训练数据不是把互联网网页下载下来直接喂进去就行。真实语料里的问题，比外人想象的更脏：大量重复广告、机器生成的垃圾页、残缺的代码片段、含隐私信息和低俗内容的文本。如果不做清洗，模型训练效率会变慢，生成质量也会被拖垮。一个最简单的例子：同一条新闻被几十个站点转载，去重不彻底的语料里可能有几百份近似重复文本，模型就很容易在相关上下文中“背”出大段原文，而不是学会抽象表达。

实操中，可计算文本片段相似度的指纹算法做去重（比如基于最小哈希的方法），然后用规则加分类器做质量过滤，再按语言、主题、领域做统计和配比。更关键的是，不同来源的数据不能简单拼接，最好按业务目标调节语料配比：对话场景多一些口语化文本，专业场景多一些教材、论文、规范文档。预训练的数据配比某种意义上决定了模型擅长什么，我们曾有模型在代码任务上表现不佳，原因不是架构不行，而是语料里代码占得太少。后面把代码语料比例提上来，同样参数规模的模型，代码补全能力就明显改善。

2.2 Scaling Law：参数量、数据量和算力预算的三角平衡

大模型不是“参数量越大越好”，因为效果提升还受数据量和计算量的制约。相关实证研究给出过一个规律：模型最终的 loss 大致与参数量、数据量、计算量的幂次相关。如果只堆参数但不增加数据，模型会进入欠拟合与过拟合之间的灰色地带；如果只堆数据但参数太小，模型又没足够容量吸收规律。有个常被引用的近似结论：训练 token 数量最好是参数量的几十倍。一个 70B 参数的模型，建议至少用上 T 级别的 token。这个比例不是绝对标准，但能帮你在预算有限时做出取舍。

对绝大多数团队来说，从头预训练成本太高。理解这个三角关系更多是为了避免“拍脑袋”：比如你计划训练一个小模型，就得先算算手里的数据量和算力能不能配平；如果你只是想快速验证业务，不如直接拿现成的开源底座做微调，省下大量预训练成本。我自己见过不少团队，雄心勃勃要训练千亿模型，结果数据只有几百 G，训练到一半发现 loss 下不去，最后只能推倒重来。这不是执行力问题，是资源约束下目标定错了。

2.3 训练稳定：沉默的工程硬骨头

模型训练跑起来容易，稳定地跑到最后很难。7B 以上的模型训练周期往往要数周到数月，中途最怕两件事：一是 loss 突然飙升，二是训练中断后无法续上。loss spike 通常源于学习率设置不合理、batch 内异常数据或混合精度下的梯度溢出。工程上会给训练过程加监控，一旦发现 loss 异常，就回退到最近的检查点，调低学习率重启。这里光保存模型权重还不够，优化器状态和随机数种子也要定期保存，否则无法精确恢复到中断前的训练状态。

另一个容易被忽略的问题是算力利用效率。很多人以为 GPU 数量翻倍，训练速度就翻倍，事实并非如此。数据加载吞吐、网络通信、显存带宽都会成为瓶颈。我们曾经因为数据管道没做缓存，训练时 GPU 经常空转，算力利用率不到 40%。后来把数据预处理成高效的内存映射格式，并多进程预取，利用率才回到 80% 以上。训练工程与其说是炫酷的算法，不如说是琐碎的检查和调优，谁能把这些问题控制住，谁才能真正跑完一个大模型。

3. 从基座模型到业务可用：微调与对齐

3.1 指令微调：让模型从“续写”变成“听话”

预训练模型默认能力是续写，而不是执行指令。你让它“写一封请假邮件”，它可能继续输出一段不相关的文字。为此要做指令微调（SFT），用一批“指令-回答”样本继续训练模型。指令微调不需要几百万条数据，关键是质量。我们实测下来，两三万条设计合理的指令，往往比几十万条网上扒来的问答更有效。数据的多样性、难度分布、回答风格，都会影响最终效果。

指令数据要覆盖多个维度：不同任务类型（问答、摘要、改写、分类）、不同输入格式（短问题、长篇章、多轮对话）、不同回答风格（简洁、详细、正式、口语）。还要刻意加入“不知道”类样本，让模型学会在知识不足时承认不知道，而不是硬答。训练时的模板一致性也很重要，推理阶段的输入格式必须和训练时对齐，否则模型会“水土不服”，输出质量大打折扣。

3.2 偏好对齐：从 RLHF 到 DPO，哪种更值得做

SFT 之后，模型能听懂指令，但未必符合人的偏好。比如输出太长太啰嗦、语气冷冰冰、面对不合理请求时不懂拒绝。偏好对齐的目的，就是把模型拉向“人类喜欢”的方向。最经典的做法是先训练奖励模型，用强化学习来优化策略，工程链路长且不稳定；后来很多团队改用 DPO，直接利用偏好数据做隐式对齐，不需要单独的奖励模型和复杂的强化学习循环，对小团队非常友好。

偏好数据的构造是重点。一条偏好对包含同一个问题下的两个回答：一个更好、一个较差。这些数据可以从线上日志里抽取，也可以由模型生成后人工排序。数量上，一两万条高质量偏好对已经能让模型风格发生明显变化。实际操作中，不要只对齐“语气”，还要对齐“行为”：面对敏感内容要拒绝、面对不确定要澄清、面对多轮对话要承接上文。一个容易犯的错是偏好数据风格单一，最后模型所有回答都变成一种腔调，反而影响业务场景的自然度。

3.3 LoRA 与 QLoRA：没有超大算力也能微调

全参数微调对算力要求很高，大部分团队可以用参数高效微调来降低门槛。LoRA 的思路是在冻结原模型权重的前提下，插入少量低秩矩阵作为可训练参数。这样只需要更新极小一部分参数，显存和算力占用都小很多。实操中一般要调整秩和缩放系数两个超参：秩越大，模型的可表达能力越强，但过拟合风险也更高；对小规模数据，秩不必过大。QLoRA 更进一步，先把基座模型量化到低精度再用 LoRA 训练，让消费级显卡也能微调数十亿参数的模型。

微调完成之后，LoRA 权重通常要合并回原模型再用于推理部署。合并后不能只盯着训练 loss，要在验证集上重新跑一遍，因为低精度基座和合并运算都可能引入细微差异。一个常见坑是训练时上下文长度比线上短，线上问题一长就崩。所以微调阶段就要设定一个符合业务分布的上下文长度，并预留余地。低资源微调不是“万能解药”，但它确实让更多团队有了初步自研能力。

4. 部署推理：算清显存、量化和吞吐这笔账

4.1 一张显卡到底能不能装下模型：把显存算明白

很多人部署时只看模型权重的大小，结果一上线就 OOM。推理显存不只是权重，还要算上中间激活值和 KV Cache。特别是长上下文下，KV Cache 增长很快。以某 7B 模型为例，假设模型 32 层、32 个头、每个头维度 128，用 FP16 存储 Key/Value，每个 token 大约占 0.5MB 显存；支持 2048 个 token 的上下文时，单条请求的缓存就要约 1GB，如果 32 条并发，光 KV Cache 就接近 32GB。再加上权重本身约 14GB，一张 48GB 的卡就会被占掉大半。

所以部署规划要把模型权重、KV Cache、激活值、推理框架额外开销一起估算。一个比较稳妥的经验是：先用公式估出理论值，再预留至少 20% 余量，最后用真实压测确认。不要想当然地认为“权重能装下就没事”，上下文长度和并发数才是隐藏的显存杀手。反过来，如果业务上下文普遍很短，KV Cache 压力会小很多，这也是为什么不要盲目放开长上下文的原因。

4.2 INT8 和 INT4 量化：省钱都要付出一点代价

量化是把高精度权重压缩到低精度，换来更少显存和更快计算。INT8 量化后，7B 模型权重可以压到约 7GB，精度损失通常不大，多数对话场景可接受。INT4 更激进，权重能压到约 4GB，但量化误差会变大，尤其在数学、逻辑和长文本任务上。量化不只是一个文件转换操作，还要用代表性数据做校准，敏感层可能需要混合精度保留。

实操建议是先做一个 100 条左右的任务评估集，分别跑原始模型和量化模型，逐条对比输出。不要只比困惑度这类笼统指标，有些模型困惑度变化不大，但具体任务的答案已经错得离谱。我遇到过量化后在常规对话里完全正常，一遇到多步计算就开始乱报数字的情况，最后只能把部分敏感的算子留在高精度，问题才消失。量化的收益很直接，但一定要和业务任务绑定评估。

4.3 吞吐优先还是延迟优先：推理服务的现实取舍

如果只是自己调试，单进程加载模型足够；一旦接线上流量，必须做推理服务化。最明显的优化是动态批处理，也就是让新请求插入已结束的空位，而不是等待整个 batch 全部结束，这样能把 GPU 利用率提高不少。除此之外，小请求和大请求要分层，让响应时长更稳定。实际部署中，我习惯按模型规模做服务隔离：小模型负责意图识别、提炼、简单回答，大模型只在需要深度生成时才被调用，中间加一层路由判断。

延迟和吞吐常常不可兼得。流式输出能降低首字延迟，但吞吐可能下降；加大 batch 能提高吞吐，但单请求尾延迟会变大。因此要在产品体验和成本之间找平衡。一个更朴素的建议是先统计真实流量分布，再决定上下文长度、并发上限和卡数，而不是直接把某个开源示例的配置拿过来用。

5. 应用层落地：Prompt、RAG、Agent与评估

5.1 写出能稳定复现结果的 Prompt：最小成本的最大杠杆

Prompt 是应用层最便宜但最容易被低估的杠杆。许多输出不稳定，不是模型不行，而是提示词写得含糊。一个合格的系统 Prompt 应该包含：角色和边界、任务目标、输出格式、限制条件、少量示例。少写“你是一个助手”这种空话，多写“如果信息不足，只返回不知道”这样的明确规则。复杂推理时可要求模型先列出关键步骤再给结论，但简单任务就别加，否则只会增加延迟和 token 费用。

调试 Prompt 要有回归测试意识。我维护了一套几十条业务用例，每次改动 Prompt 后批量运行，人工对比输出差异。为什么必须这么做？因为 Prompt 优化往往是“拆东墙补西墙”，今天为了一个 bad case 加一句约束，可能让另一个场景的输出格式都变了。没有回归集，你根本发现不了这类退化。另外，Prompt 版本要纳入管理，别靠文件名“final_v2”来区分。

5.2 RAG：给模型装上可溯源的知识库

大模型的知识有截止日期，也没有业务私域数据，RAG 是最现实的解决方案。流程简单说：把文档切块、向量化、存入向量库；用户提问后，检索最相关片段，再把片段和问题放进 Prompt。切块大小直接影响检索质量：块太小容易切断语义，块太大又容易混入无关信息。比较稳妥的做法是先按标题、段落结构做粗切，再用固定长度和重叠做细切，反复在业务样本上测试召回率。

召回不要只依赖向量相似度。业务文档里有很多专业编号、人名、产品型号，向量索引很容易漏掉精确匹配，因此要加关键词检索，做混合召回，再用重排模型统一排序。最后送给模型的上下文要保留出处信息，比如文档标题、章节路径，这样模型在回答时可以引用来源，遇到无关内容也能判断该不该跳过。上线前最好人工检查 Top 20 条检索结果，因为很多问题是“根本没召回”而不是“模型答错”。

5.3 Agent：让模型学会用工具，但要设硬边界

Agent 让模型不再只是一个文本生成器，而是一个任务控制器：它可以决定调用搜索、读数据库、执行代码、观察结果再继续。听起来强大，工程上却很容易翻车。最常见的问题是循环调用和错误执行：模型反复调用同一个工具，或者工具报错了还继续往下编。原因是模型本质上只是在做概率预测，它没有内置的“终止”意识，需要外部机制强制约束。

落地方案一般包含三层保护。第一，每个工具要有清晰的定义和错误返回结构，模型拿到错误信息后才能做出合理的下一步判断。第二，设定最大迭代次数和超时时间，达到上限就强制生成最终答案。第三，答案输出前加规则校验，比如格式检查、关键字段是否存在、是否引用了工具结果。不要指望一个“聪明的模型”就能处理所有边界，好的 Agent 系统是把规则和模型能力拼在一起，而不是全交给模型自由发挥。

5.4 评估体系：没有验证就别谈上线

没有评估，模型优化就是无源之水。很多团队只跑公开榜单，分数高就以为没问题，但公开榜单和真实业务差距很大。我建议至少搭三层评估：自动化指标用于回归，场景化评测集用于对齐业务，人工抽检用于发现异常。场景化评测集不用太大，200 到 500 条真实输入就比 10000 条合成数据更有价值。每条数据最好带期望行为，不只带标准答案，因为开放式任务的评判不是非对即错。

每次迭代后都要跑一遍回归集，把 bad case 记录下来。bad case 分析要定位到环节：是检索没召回，是 Prompt 约束不够，还是模型本身能力不足？很多时候调整 Prompt 或 RAG 就能解决，并不需要重新训练。评估体系是应用层最容易偷懒也是最有复利的一块，早一天建立，后续迭代就快一步。

6. 避坑和成本控制：花钱之前先想清楚

6.1 用 API 还是自己微调：这笔账不能只看单价

很多团队一提到大模型就想着自己训练，但大多数情况这不是最优解。如果业务是通用问答、文案生成、代码辅助，接成熟 API 的成本和效率远高于自建。自己做微调和部署的价值，主要体现在三类场景：私有数据不能外发、需要离线部署、需要对模型行为做深度定制。在这些场景里，开源底座加 LoRA 微调也比从头训练现实得多。

成本核算不能只看训练一次的费用。后续的 GPU 运维、模型更新、推理调优、安全加固都是持续成本。一个比较实际的方式是把一次性投入平摊到预计使用周期，再看看 API 按调用量累计的费用，同时把数据外发风险折算进去。如果月调用量不高，API 大概率更划算；如果调用量很大且有合规约束，自部署的边际成本才可能降下来。

6.2 常见失败模式和安全护栏

模型落地的失败模式，翻来覆去就那么几类：幻觉、超长上下文、输出不稳定、安全违规。幻觉要靠 RAG 证据链和“拒绝回答”机制；超长上下文要靠裁剪、摘要和路由；输出不稳定要靠提示词模板和低采样温度；安全违规要靠输入输出双层过滤和敏感词策略。单独依赖模型自身做这些事，效果都很有限，护栏必须放在链路里，规则和模型互补。

值得注意的是，很多“模型问题”最后查出来是周边系统问题。比如知识库里混入旧文档，或 Prompt 里拼接了未转义的格式符号。遇到 bad case 时，先查数据链路和输入输出，再怀疑模型，这个顺序能省很多时间。系统上线后也要定期用攻击性输入做测试，模型会随版本迭代改变行为，不能测一次就高枕无忧。

6.3 日志、监控和迭代：把大模型当基础设施运营

大模型一旦接入业务，就应该按基础设施来运营。所有请求的输入输出、token 消耗、响应时长、错误类型，都要有日志和监控。日志需要脱敏，避免把隐私数据落盘。监控指标至少包括：调用量、平均延迟、P90/P99 延迟、失败率、token 消耗、bad case 占比。把这些数据聚合到看板上，才能及时发现劣化趋势。

每周做一次 bad case 复盘是值得投入的固定动作。把线上 bad case 按原因分类，比如知识缺失、检索不准、生成格式错误、拒绝逻辑过强等。每个类别对应不同的优化动作：知识缺失补数据，检索不准调切块和召回，格式错误改 Prompt，拒绝过强放宽规则。这样迭代才有方向。真正做久了会发现，AI 应用不是“训练一次就完事”，而是持续运营的数据产品。

7. 我的实操体会：模型只是系统的一部分

7.1 先跑通最小业务链路，再考虑升级

如果让我给新手一个最直接建议，那就是不要一开始就研究千亿参数训练，也不要同时上微调、RAG、Agent 全套架构。先用一个现成模型把最小闭环跑通：输入、处理、输出、反馈。哪怕这个版本很糙，至少能验证业务假设。之后再按实际瓶颈优化，发现格式不稳定就改 Prompt，发现知识不足就加 RAG，发现风格不合适再微调。很多问题会在链路跑通过程中暴露，而不是在规划会上暴露。

我曾经参与过一个知识问答项目，团队一开始就规划了完整的 Agent 工作流，做了两个月后发现大部分结果还不如一个简单的检索加 Prompt。后来砍掉那些花哨的调度，只保留核心的召回和生成，系统可用性反而大幅提升。这个教训我一直记得：先解决主要矛盾，再逐步扩展。

7.2 把 AI 当基础设施，而不是下一波炒作

现在各大社区都在追逐新模型、新框架，但真正让业务受益的，从来不是某一次模型升级，而是围绕模型构建的数据、评估、反馈和运营机制。模型会迭代，框架会变化，但稳定可复用的工程链路才是长期资产。我们团队现在每次换模型底座，都会先跑同一套回归集，验证行为变化，而不是拍脑袋切换。这个习惯帮我们避开了非常多次“模型变强了但业务变差了”的隐性风险。

大模型是我见过被高估和被低估同时存在的东西。被高估之处在于，很多人以为它有自主意识和事实判断能力；被低估之处在于，它确实能大幅降低自然语言交互、知识整理和复杂任务的实现成本。只要你把它当一个需要训练、需要调试、需要监控的工程系统，走完从数据到部署的完整周期，你就能从中拿到实实在在的收益。这条路没有捷径，但每一步都值得走。