企业官网建设流程全解析

1. 大模型入门到底在学什么

1.1 先搞清楚大模型的能力边界

很多人一上来就问“大模型怎么学”，其实更该先问的是“大模型到底能干什么、不能干什么”。我见过太多人抱着“学会大模型就能做一切”的期待进来，结果卡在第一步——连自己要用它解决什么问题都没想清楚。

大模型（LLM，Large Language Model）本质上是一个基于海量文本训练出来的概率生成系统。它做的事情说穿了就一件：给定一段上下文，预测下一个最可能出现的词元（token）。这个机制听起来简单，但参数量堆到几十亿甚至上千亿之后，涌现出了推理、翻译、摘要、代码生成、角色扮演等能力。

你需要先建立三个基本认知：

• 大模型不是数据库。它不会“查询”事实，而是“生成”看起来合理的文本。这意味着它可能一本正经地胡说八道，也就是所谓的幻觉（Hallucination）。
• 大模型不是万能的。它在数学精确计算、实时信息获取、长链条逻辑推理上仍然有短板，需要外部工具或工程手段来补。
• 大模型的能力高度依赖输入。同一个模型，提示词写得好和写得烂，输出质量差距可能是天壤之别。

搞清楚这三点，你后面学提示词工程、微调、部署的时候，才知道每一步是在解决什么问题。

1.2 入门路线怎么排才不走弯路

我自己的经验是，大模型入门分四条线并行推进，但不同阶段侧重点不同：

这个路线不是死的，但核心逻辑是：先用起来，再拆开看，最后动手改。很多人反过来，先啃一个月Transformer论文，结果连API都没调过，学习效率极低。

1.3 不同背景的人该怎么切入

我接触过的学习者大概分三类，切入方式完全不同：

纯小白（非计算机背景）：先从提示词工程入手，学会用自然语言和大模型高效交互。推荐从提示词工程与上下文工程这个方向切入，理解什么是系统提示、少样本示例、思维链。这个阶段不需要写代码，但需要大量练习和总结。

有编程基础但没接触过AI：直接从API调用开始。选一个主流大模型平台，用Python写几十行代码跑通对话、摘要、分类三个任务。然后逐步深入理解token、温度参数、上下文窗口这些概念。

有AI基础想深入：直接看开源模型源码，从nano-vllm这类精简实现入手，理解推理引擎的关键功能——KV Cache、连续批处理、PagedAttention。同时可以开始尝试微调实战，用LoRA在单卡上跑通一个领域适配任务。

2. 核心概念拆解：从Token到Transformer

2.1 Token：大模型世界的原子单位

大模型不直接处理文字，它处理的是token。你可以把token理解成“子词”——一个英文单词可能是一个token，也可能被拆成两三个token；一个中文字通常对应一到两个token。

为什么这件事重要？因为计费按token算、上下文窗口按token算、生成速度也按token算。我见过有人写了一段超长提示词，结果发现光输入就吃了三千token，成本直接翻倍。

粗略估算规则：

• 英文：1个token约等于0.75个单词
• 中文：1个token约等于1到1.5个汉字
• 代码：通常比自然语言更密集，同样长度消耗更多token

实操建议：在调用API之前，先用平台的token计算工具估算一下，避免超限或成本失控。

2.2 Transformer架构：为什么它成了主流

Transformer的核心是自注意力机制（Self-Attention）。用生活化的话解释：读一句话的时候，每个词都会“看”其他所有词，判断谁跟自己关系最近，然后决定自己在这个语境下应该表达什么含义。

举个例子：“小明把书放在了桌子上，因为它太重了。”——这里的“它”指什么？自注意力机制会让“它”和“书”之间的权重更高，而不是“桌子”。这就是它理解上下文的方式。

Transformer相比之前的RNN有几个关键优势：

• 并行计算：RNN必须一个词一个词顺序处理，Transformer可以同时处理整句话，训练效率高几个数量级。
• 长距离依赖：不管两个词隔多远，自注意力都能直接建立联系。
• 可扩展性：加层数、加宽度、加数据，效果持续提升，这才有了“大”模型的可能性。

2.3 上下文窗口：大模型的“工作记忆”

上下文窗口（Context Window）是大模型一次能“看到”的token数量上限。早期模型只有2K、4K，现在主流模型动辄128K甚至1M。

这个参数直接决定了你能用它做什么：

• 4K窗口：适合短对话、简单问答
• 32K窗口：可以处理中等长度文档、多轮对话
• 128K以上：可以塞进整本书、大型代码库

但要注意，窗口大不等于效果好。实际使用中，模型对窗口中间部分的信息注意力会下降，这就是所谓的“迷失在中间”现象。我的经验是，关键信息尽量放在上下文的开头或结尾，中间部分放辅助材料。

2.4 温度与采样：控制输出的随机性

温度（Temperature）是控制模型输出随机性的参数。温度越低，输出越确定、越保守；温度越高，输出越多样、越有创意。

除了温度，还有Top-p（核采样）和Top-k两个参数，它们和温度配合使用。我的习惯是：做工程任务时温度设0.1，Top-p设0.9；做创意任务时温度设0.8，Top-p设0.95。

3. 提示词工程与上下文工程实战

3.1 提示词工程的核心原则

提示词工程不是“玄学”，它有明确的原则可循。我总结了四条最实用的：

第一条：角色设定要具体。不要只说“你是一个助手”，而是说“你是一个有十年经验的Python后端工程师，擅长性能优化和代码审查”。角色越具体，模型的输出风格越贴近你的需求。

第二条：任务描述要可验证。不要说“帮我写个好方案”，而是说“帮我写一个包含三个步骤的部署方案，每个步骤需要列出具体命令和预期输出”。可验证的任务描述能让模型输出更结构化的内容。

第三条：给例子比讲道理管用。这就是少样本提示（Few-shot Prompting）。你给两三个输入输出示例，模型就能模仿格式和风格。我试过同一个任务，不给例子准确率大概60%，给三个例子直接拉到90%以上。

第四条：让模型一步步想。这就是思维链（Chain of Thought）。在提示词里加一句“请一步步分析”，模型在数学题、逻辑题上的准确率会显著提升。原因是它把中间推理过程也生成了出来，相当于“打草稿”。

3.2 上下文工程：比提示词更上一层

提示词工程关注“怎么说”，上下文工程关注“给模型看什么”。在实际应用中，后者往往更重要。

一个典型的上下文工程问题：你要做一个企业知识库问答系统，用户问“我们公司的报销流程是什么”。模型本身不知道你公司的流程，你需要从知识库里检索相关文档片段，塞进上下文里，再让模型基于这些片段回答。

这里的关键决策包括：

• 检索多少片段：太少信息不够，太多稀释注意力。我的经验是3到5个片段，每个片段200到500字。
• 片段怎么排序：最相关的放最前面，次相关的放最后面，中间放补充材料。
• 怎么防止模型编造：在提示词里明确写“如果上下文中没有相关信息，请回答‘我不知道’”。

3.3 实操：搭建一个可复用的提示词模板

下面是我自己在用的一个提示词模板框架，你可以直接抄：

SYSTEM_PROMPT = """你是一个{role}，擅长{skill}。 你的任务是{task}。 请遵循以下规则： 1. {rule_1} 2. {rule_2} 3. {rule_3} 输出格式要求： {output_format} 如果信息不足，请明确说明缺少什么信息，不要编造。""" USER_PROMPT = """背景信息： {context} 用户问题： {question} 请基于以上背景信息回答。"""

这个模板的好处是：角色、任务、规则、格式四要素齐全，而且把“不要编造”写进了系统提示，实测能显著降低幻觉率。

3.4 常见提示词陷阱与避坑指南

我踩过的坑，你大概率也会遇到：

• 陷阱一：提示词太长太杂。有人把十几条规则塞进系统提示，结果模型顾此失彼。建议规则不超过5条，按优先级排列。
• 陷阱二：用否定句。“不要输出markdown格式”往往不如“请输出纯文本”。模型对否定指令的遵循度较低。
• 陷阱三：忽略输出格式约束。如果你要程序解析输出，一定要在提示词里明确JSON格式，并给出字段说明。
• 陷阱四：一次让模型做太多事。又要总结、又要翻译、又要分类，模型容易顾此失彼。拆成多个调用，每个调用只做一件事，效果更好。

4. 微调实战：让大模型适配你的领域

4.1 什么时候该微调，什么时候不该

这是我最常被问到的问题。我的判断标准很简单：

不该微调的情况：

• 只是想让模型输出特定格式 → 用提示词工程
• 只是想让模型知道一些事实 → 用RAG（检索增强生成）
• 只是想让模型扮演某个角色 → 用系统提示

该微调的情况：

• 需要模型掌握特定的输出风格，且提示词难以描述清楚
• 需要模型在特定任务上达到极高准确率，且已有标注数据
• 需要减少提示词长度，把领域知识“内化”到模型里
• 需要模型学会新的技能，比如特定的代码规范、特定的分类体系

一句话总结：提示词能解决的，不要微调；RAG能解决的，不要微调；只有前两者都搞不定，才考虑微调。

4.2 LoRA微调：单卡也能玩

LoRA（Low-Rank Adaptation）是目前最流行的微调方法，核心思想是：不改动原模型参数，而是在旁边加一个小矩阵，只训练这个小矩阵。

为什么这样做？因为全量微调一个70亿参数的模型，需要多张A100，成本极高。LoRA只需要训练原模型0.1%到1%的参数，单张消费级显卡就能跑。

实操步骤：

# 1. 安装依赖 pip install transformers peft datasets accelerate # 2. 准备数据（JSON格式，每条包含instruction和output） # 3. 加载基础模型和tokenizer # 4. 配置LoRA参数 lora_config = LoraConfig( r=8, # 秩，越大容量越强，常用8-64 lora_alpha=32, # 缩放系数，通常是r的2-4倍 target_modules=["q_proj", "v_proj"], # 作用在哪些层 lora_dropout=0.1, bias="none" ) # 5. 开始训练 # 6. 保存适配器权重（通常只有几十MB）

关键参数选择经验：

• r值：任务越复杂，r越大。简单分类任务r=4够用，复杂生成任务建议r=16到64。
• 学习率：LoRA的学习率通常比全量微调大10倍左右，常用1e-4到3e-4。
• 训练轮数：1到3轮通常足够，太多容易过拟合。

4.3 数据准备：微调成败的关键

我见过太多人微调效果不好，最后发现是数据问题。数据准备有三个原则：

原则一：质量大于数量。500条高质量数据，效果往往好过5000条噪声数据。每条数据都要人工检查，确保输入输出对应正确。

原则二：多样性要够。如果所有训练样本都是同一种问法，模型只会回答那一种问法。要覆盖不同的表达方式、不同的场景。

原则三：格式要统一。训练数据的格式必须和推理时的提示词格式一致。训练时用“### 指令：xxx ### 回答：xxx”，推理时也要用同样的格式。

4.4 微调后的评估与迭代

微调完了不是结束，而是开始。你需要一套评估方法来判断效果：

• 自动评估：用BLEU、ROUGE等指标对比生成结果和参考答案。适合快速筛选。
• 人工评估：随机抽100条，人工打分。适合最终判断。
• A/B测试：把微调前后的模型放在真实场景里对比。适合上线前验证。

如果效果不好，排查顺序是：数据质量 → 数据格式 → 超参数 → 基础模型选择。大部分问题出在前两步。

5. 本地部署：让大模型跑在自己的机器上

5.1 本地部署的硬件门槛

本地部署大模型，第一个问题是：我的机器跑得动吗？

如果显存不够，有几个方案：

• 量化：把模型参数从FP16降到INT8或INT4，显存占用减半甚至更多，效果损失通常在可接受范围内。
• CPU推理：用llama.cpp这类框架，纯CPU也能跑，但速度慢。
• 混合推理：部分层放GPU，部分层放CPU。

5.2 部署工具选型对比

目前主流的本地部署工具有：

我的建议：先用Ollama体验，确定要深入了再上vLLM。如果是个人电脑智能化场景，llama.cpp配合量化模型是最务实的选择。

5.3 实操：用vLLM部署一个API服务

vLLM是目前生产环境部署的主流选择，核心优势是PagedAttention和连续批处理，吞吐量比朴素实现高十几倍。

# 安装 pip install vllm # 启动API服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --port 8000

关键参数说明：

• tensor-parallel-size：张量并行数，多卡时设为GPU数量
• gpu-memory-utilization：GPU显存利用率，0.9表示用90%
• max-model-len：最大上下文长度，根据显存调整

启动后就可以用OpenAI兼容的API调用了：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy") response = client.chat.completions.create( model="your-model", messages=[{"role": "user", "content": "你好"}] ) print(response.choices[0].message.content)

5.4 部署后的性能调优

部署起来只是第一步，性能调优才是重头戏。几个关键指标：

• TTFT（Time To First Token）：首token延迟，影响用户感知的响应速度。优化方法是减少批处理大小、使用更快的GPU。
• TPOT（Time Per Output Token）：每个输出token的耗时，影响生成速度。优化方法是量化、使用投机解码。
• 吞吐量：每秒处理的请求数。优化方法是增大批处理、使用连续批处理。

我的经验是，先保证TTFT在1秒以内，再优化吞吐量。用户等首字超过2秒就会觉得卡。

6. 常见问题与排查技巧实录

6.1 模型输出质量类问题

问题：模型总是胡编乱造怎么办？

排查思路：

1. 检查提示词是否明确要求“不知道就说不知道”
2. 降低温度到0.1以下
3. 如果是RAG场景，检查检索到的上下文是否真的包含答案
4. 考虑用微调让模型学会“拒答”

问题：模型不遵循输出格式怎么办？

排查思路：

1. 在提示词里给出格式示例，而不只是描述
2. 用JSON Schema约束输出（部分平台支持）
3. 如果还是不行，用后处理脚本强制解析和修正

问题：模型回答太短/太长怎么办？

排查思路：

1. 在提示词里明确字数要求，比如“用200字左右回答”
2. 用max_tokens参数硬性限制
3. 给例子展示期望的长度

6.2 部署与性能类问题

问题：显存不够怎么办？

排查顺序：

1. 量化模型（INT8或INT4）
2. 减小max_model_len
3. 减小batch_size
4. 使用CPU offload
5. 换更小的模型

问题：推理速度太慢怎么办？

排查顺序：

1. 确认是否用了GPU，而不是CPU
2. 检查是否开启了连续批处理
3. 尝试量化
4. 尝试投机解码
5. 升级硬件

问题：多用户并发时服务崩溃怎么办？

排查思路：

1. 检查显存是否溢出，降低gpu_memory_utilization
2. 限制最大并发数
3. 使用请求队列
4. 考虑多实例负载均衡

6.3 微调类问题

问题：微调后模型效果反而变差了？

这是典型过拟合。解决方法：

1. 减少训练轮数
2. 增加数据多样性
3. 降低学习率
4. 增大LoRA的dropout
5. 检查数据格式是否和推理格式一致

问题：微调后模型忘记了通用能力？

这叫灾难性遗忘。解决方法：

1. 在训练数据里混入一部分通用数据
2. 降低LoRA的r值，减少对原模型的改动
3. 使用更小的学习率

6.4 我的独家避坑清单

最后分享几条我踩过坑才总结出来的经验：

• 不要一上来就微调。先把提示词工程和RAG玩明白，80%的需求这两样就够了。
• 不要迷信大模型排名。排行榜上的分数和你的实际任务表现可能完全不相关。一定要在自己的数据上测。
• 不要忽略数据清洗。微调数据的质量比数量重要十倍。花在数据上的时间应该占总时间的60%以上。
• 不要在生产环境用最新模型。新模型可能有未知的坑，等社区验证过再上。
• 不要忘记成本核算。API调用按token计费，本地部署按电费和硬件折旧算。做之前先算一笔账。
• 不要停止学习。这个领域三个月不跟进，就感觉落下一大截。保持读论文、看源码、动手实验的习惯。

我个人在实际操作中的体会是，大模型入门最难的不是某个具体技术点，而是建立一套“遇到问题知道往哪个方向排查”的直觉。这套直觉只能靠大量动手实践来积累，看再多教程也替代不了自己跑一遍。