🥰个人主页：会编程的土豆（欢迎来访）
💎作者简介：后端学习者
❄️个人专栏：数据结构与算法，数据库，leetcode
✨那些你一个人走过的夜路，终将化作照亮未来的光

适合人群：会一点 Go / 后端，AI 基本零基础，想走「后端 + AI」方向的同学。
本文不讲训练公式，只建立能写进业务代码的正确直觉。

---

前言：为什么后端也要懂这些？

很多同学一上来就看 Agent、RAG、向量库，很快就会懵。其实大厂里大量「AI 工程」工作，并不是让你从零训练千亿模型，而是：

• 用 Go（或其它后端语言）调用大模型 API
• 控制 提示词（Prompt）、长度、成本、超时、降级
• 把模型嵌进真实业务：鉴权、落库、工具调用、检索

所以你需要先搞懂一层薄薄的基础概念。搞懂之后你会发现：
大模型对后端来说，首先是一个「特别重的远程 HTTP 服务」

---

一、从硬性规则，到模型自己「学习」

1.1 传统后端：硬性规则

你写后端，本质是：

如果 条件 A → 做事情 1
如果 条件 B → 做事情 2
否则 → 返回错误

例如登录：

• 用户名为空 → 400
• 密码错误 → 401
• 正确 → 发 token

对错完全由你写的 if/else 决定， 程序不会自己「想」；你没写到的情况，它就不会。

这叫 硬性规则（规则系统）

优点	缺点
可控、可测、好追责	遇到模糊的人话，规则写不完

比如用户说：

「帮我看看明天北京适不适合户外跑步」

要用规则覆盖天气、温度、空气、体质、「适合」的定义……规则会爆炸，也永远盖不全。

1.2 大模型换了一种办法

大模型这条路 不靠你写完所有 if，而是大致这样：

1. 拿海量文本（书、网页、代码、论坛、百科等）
2. 训练时反复做一件事：根据上文，猜下一个词更可能是什么
3. 猜错了就调整内部参数，再猜
4. 练到很久之后，它能根据你的问题，生成一段「像人会说的回答」

所以「学习」不是上课开窍，而是：

从大量例子里，统计出「怎样接下一句更像样」的能力。

1.3 一张对照表

	传统程序	大模型
知识从哪来	你写的代码 / 配置	训练数据 + 你这次给的提示
行为谁定	if/else、状态机	概率生成（下一段更可能说什么）
没见过的输入	容易挂或走默认	常能「硬生成」一段话（对错另说）
确定性	同输入基本同输出	同输入也可能略有不同

一句话：

• 规则：你规定「遇到 X 必须做 Y」
• 模型：它根据经验「觉得接下来该说什么」

1.4 一个常见入门例子（半对半要注意）

笔记里常写：训练之后，模型能明白「我不喜欢这件商品」在客服场景里常表示想退货——因为训练数据里见过很多类似说法。

这个例子想传达的是：

• 不一定要出现「退货」两个字
• 模型能处理更灵活的人话

但要校准两点，避免以后埋坑：

1. 不是 map["我不喜欢这件商品"] = "退货" 这种枚举映射
2. 更像是：在客服语境下，高概率往「不满 / 售后 / 退货」靠；换场景、换提示词，结果可能不同

模型负责「懂话」；真退货、真扣款，必须你用代码确认、鉴权、落库。

---

二、大模型「大」在哪里？

口语里的「大」，通常不是「回答很长」，而是下面几层。

2.1 参数多（最常说的「大」）

模型内部有海量可调数字，叫 参数（parameters）。
常说 70B ≈ 大约七百亿个参数。

粗糙理解：一个超大公式里有巨量「旋钮」；训练就是把旋钮拧到「续写比较像人话」。

后果：

• 模型文件很大，普通电脑不好本地跑满血版
• 公司一般买云 API，你的 Go 服务用 HTTP 去调

2.2 训练数据多

训练不是只读你们公司一本说明书，而是海量书、网页、代码、论坛等。
「好像懂退货、会写代码」，很大程度是因为这类说法在数据里反复出现过。

2.3 算力大（练得起、跑得动都贵）

训练和推理都很费 GPU，成本高。
所以对多数后端来说：

你更可能做的是 会调用、会控成本、会嵌进业务，而不是自己训练千亿模型。

2.4 对后端的衍生问题：一次塞不进无限内容

每次请求能放进模型的信息有上限（后面叫 上下文窗口）。
所以不能把整个数据库塞进一次 Prompt，才需要后续的 RAG（先检索再问）、Agent（分步、用工具）等工程手段。

大模型大在哪？
├── 参数多 → 模型很重，常靠云 API
├── 数据多 → 像见过很多书和对话
├── 算力贵 → 训练/推理都烧钱
└──（对后端）上下文有限 → 要省着用、会检索

---

三、参数是什么？（最容易误会的点）

3.1 不是 Go 函数参数，也不是枚举

这里的 参数 ≠ func Foo(a int) 的形参。
也 ≠ 把全世界句子都 switch / map 枚举一遍。

参数 = 模型内部那些已经被训练好的、大量的数字（也常叫权重 weights）。
模型靠这些数字，才能根据输入算出下一个词更可能是什么。

3.2 用 Go 建立直觉（伪代码）

// 伪代码，帮助直觉，不是真实现
type LLM struct {
    Weights []float64 // 这里可能有几百亿个数字 ← 就是「参数」
}

func (m *LLM) NextToken(上文 string) string {
    // 用 Weights 做大量计算
    // 得出：下一个词更可能是哪个
    return "…"
}

• 参数：Weights 里那些数（存在模型文件里）
• 训练：根据海量文本不断改这些数
• 你调 API：通常不改这些数，只把文字传进去，拿生成结果

3.3 枚举 vs 参数

	枚举 / 大 map	大模型参数
存的是什么	离散条目（句子、状态）	连续数字（旋钮）
没见过的说法	容易直接 miss	常能「凑」出合理续写
「大」的含义	条目多	旋钮多、表达能力强

一句话：

枚举 = 记条目；参数 = 记规律（用海量数字表示）。

3.4 别和「超参数」搞混

名字	是什么	例子
参数	训练出来的内部数字	那几百亿个权重
超参数	你/系统设置的选项	Temperature、最大生成长度

配置里的 temperature: 0.7 是超参数，不是「70B 参数」里的参数。

---

四、LLM 核心概念（后端必会四个 + 一个结构印象）

4.1 Token：大模型计量单位

模型不算「几个汉字」「几句话」来计长度，而算 Token。

• 英文：一个 Token 常常是一个单词或单词的一部分
• 中文：一个字有时是 1 个 Token，有时一个词被拆成多个
• 不要用 len(string) 或「字数」直接当 Token

可以想成：

你的 string  "你好，我想退货"
       ↓ 分词（tokenize）
Token 们   [示意小块…]
       ↓
按 Token 数：算长度、计费、是否超过上下文窗口

和参数的区别：

	参数	Token
是什么	模型肚子里的旋钮	每次请求里文字切出来的小块
何时变	训练时（你调 API 一般不变）	每次输入/输出都不同
你最关心	模型规模、能力档位	费用、长度、是否超限

长度、费用、是否超限，看的是 Token，不是字符串字节数。

4.2 上下文窗口 Context Window

上下文窗口 = 模型一次最多能「看见」多少 Token。

通常都算进窗口里的包括：

• system 提示（人设、规则）
• 历史对话
• 当前用户问题
• 有时还有检索片段、工具返回结果
• 以及模型正在生成的回答

像一个固定大小的缓冲区：

|←—————— 上下文窗口（例如 128K Token）——————→|
| system + 历史 + 当前问题 + … | 生成中… |
超出容量的旧内容 → 模型根本看不见

窗口满了会怎样？旧消息被截掉、报错、或需要你在业务里自己裁剪。
这就是为什么长对话要省着放，以及后面会出现 RAG：先检索，再只塞一小段进窗口。

4.3 Temperature：控制回答的「稳还是活」

Temperature（温度） 是调用大模型时的重要超参数，用来控制生成的随机性 / 创造力。

模型每次选下一个词时，前面其实有很多候选，每个带概率。Temperature 影响「多敢选不太稳的词」。

Temperature	行为	体感
≈ 0	几乎总选概率最高的词	最确定、最稳，但容易死板
≈ 0.7	在高概率词里有些随机	更自然、有变化（常见聊天设置）
≥ 1.0	更随机	更有创意，也更容易胡说八道

形象比喻：

• Temperature = 0：学霸，标准答案，稳，少惊喜
• Temperature = 1：创意学生，偶尔神来之笔，偶尔跑偏

注意：

温度高 ≠ 更聪明，只是更敢「赌」不常见的续写。

后端怎么选（实用）：

场景	建议
意图识别、抽 JSON、要稳定结构	偏低（接近 0）
普通聊天	中等（如 0.7）
头脑风暴、文案创意	可偏高（接受胡说风险）

4.4 MoE：混合专家架构（有印象即可）

MoE = Mixture of Experts（混合专家）。

直觉：

• 模型里有很多「专家」子网络
• 每个输入 只激活其中一部分 来计算
• 所以总参数可以很大，但单次计算不必「所有参数全算一遍」那么夸张

你听到「某模型总参数很大，但推理还比较能打」，有时就和 MoE 有关。
入门阶段记住一句即可：

不是每次推理都把全部参数用满。

4.5 四个概念怎么串起来（后端视角）

你的 Go 服务拼好一段文字（Prompt）
    → 变成很多 Token
    → 不能超过 Context Window
    → 带着 Temperature 等配置调 API
    →（若对方是 MoE 模型，内部只激活部分专家，你通常无感）
    → 返回的也是按 Token 生成出来的文本

---

五、基座模型 vs Chat 模型（别被名词吓到）

很多笔记会画出：预训练、对齐、SFT、RLHF……第一次看很容易眼花。
入门 只留一条线：

读很多书练出来  →  基座模型（Base）：主要会「续写」
        ↓
再按「听人话、好好答」练一遍  →  Chat / Instruct 模型：会按指令办事

5.1 一个例子就够

你说：「帮我写冒泡排序」

模型	可能表现
基座模型	像续写百科：介绍「冒泡排序是一种……」，不一定直接给可用代码
Chat 模型	听懂「帮我写」= 要代码，于是直接给你函数实现

再土一点：

• 基座 = 读了很多书、很会往下接一句的学生
• Chat = 同一个学生，又经过「怎么当助手、怎么按吩咐办事」的训练

你平时用的 ChatGPT、DeepSeek 对话、以及业务里调的聊天 API，基本都是 Chat 模型。

5.2 那些缩写现在怎么处理

名词	入门怎么记
预训练	读海量文本，练成基座
对齐 / SFT / RLHF	统称：再练成会听指令的 Chat（细节以后再说）
Instruct 模型	基本可当成 Chat 模型的另一种叫法

现在不要死背 SFT、RLHF。知道「还有第二步，才会好好听话」就行。

---

六、Prompt（提示词）：你和模型之间的「接口约定」

6.1 是什么

Prompt = 你发给大模型的那段说明 + 内容。
模型不读心，只根据这次请求里看到的文字生成回答。

Go 比喻：

大模型 API  ≈  一个函数
Prompt      ≈  你传入的参数（字符串 / 消息列表）
返回值      ≈  生成的文本

同一句用户原话，Prompt 不同，结果可以差很多。

6.2 一次 Chat 请求里通常有什么

角色	含义	例子
system	总规矩：你是谁、怎么答、别干什么	「你是客服，只判断是否退货，只输出是/否」
user	用户说的话	「我不喜欢这件商品」
assistant	模型以前的回复（多轮时带上）	上一轮回答

| system（人设/规则）|
| 历史对话           |   ← 都算进 Token，都占上下文窗口
| 当前 user 问题     |
        ↓
      模型生成

6.3 为什么 Prompt 重要

Chat 模型会「听指令」，但指令要写清楚。
可以把 Prompt 当成：写给模型看的需求文档。需求模糊，模型就像产品需求模糊时乱做。

6.4 写 Prompt 先记 5 条

1. 角色：你是什么（客服 / 信息抽取助手 / 代码助手）
2. 任务：要干什么（判断意图 / 总结 / 写代码）
3. 输入：用户原文或数据放哪里
4. 输出格式：只要 JSON、只要「是/否」、要分点……说清楚
5. 约束：不知道就说不知道；不要编造；别聊题外话

示例：

你是电商客服助手。
根据用户一句话，判断是否表达「想退货」。
只输出 JSON：{"refund": true/false, "reason": "简短原因"}
用户说：我不喜欢这件商品

这比只把用户原话扔给模型，要可控得多——尤其当你要用 Go 做 json.Unmarshal 时。

6.5 Prompt 和前面概念的关系

概念	和 Prompt 的关系
Chat vs 基座	Chat 才会认真「按 Prompt 办事」
Token	Prompt 越长越贵，也越占窗口
上下文窗口	Prompt + 历史太长会被截断，模型可能「忘了」前面的规矩
Temperature	Prompt 定「做什么」；Temperature 定「答得稳不稳」

6.6 对「后端 + AI」意味着什么

常见工作不是「会写漂亮作文」，而是：

• 把业务规则写成 稳定的 system Prompt
• 控制长度，避免超窗口、控制成本
• 要求 固定输出格式，方便解析
• 模型不靠谱时：校验、重试、降级、关键动作仍由代码执行

Prompt = 你和模型之间的接口约定