一文讲透 LLM 的 8 个核心概念：从 Token 到 RAG，工程师版
调 API 谁都会，但被问到「上下文窗口到底怎么算的」「温度调高会发生什么」，很多人就答不上来了。这篇文章把 LLM 的 8 个核心概念一次讲透，每条都带工程视角的实战建议。理解了这些，Agent、RAG、微调不过是它们的组合应用（上一篇讲过的 60 行 Agent 就是「Function Calling + 循环」的组合）。
1. Token：LLM 眼里的世界
LLM 不认「字」，认 Token。Tokenizer 把文本切成 token——英文一个单词可能是一个 token，中文通常一个字 1~2 个 token：
import tiktoken
enc = tiktoken.get_encoding("o200k_base")
print(len(enc.encode("hello world"))) # 2 个 token
print(len(enc.encode("大语言模型"))) # 6 个 token（每个字 2 个）
print(enc.encode("大语言模型")) # [100350, 100164, 24903]
工程上你必须知道的三件事：
- 计费按 token 算：输入和输出分开计价，输出更贵
- 中文比英文费 token：同等内容中文成本约为英文的 1.5~2 倍，做产品前先算账
- 上下文窗口按 token 算：不是按「几句话」
2. 上下文窗口：LLM 的「工作记忆」
上下文窗口是模型一次能处理的 token 上限（128K、1M 之类）。关键认知：
窗口 ≠ 记忆。 窗口只是「这一次请求能塞多少」。跨请求的记忆要你自己维护——把历史对话塞回 messages 列表（这就是 Agent 的短期记忆），或者存向量库做长期记忆。
窗口塞满会发生什么：最早的内容被截断或注意力稀释（模型「忘了」开头说的约定）。所以长对话要做摘要压缩，而不是无限追加历史。
实战建议：先算清楚你的场景需要多大窗口，别无脑买最大的——窗口越大，单次请求越贵、越慢。
3. 温度与 top_p：随机性从哪来
LLM 每次生成是在概率分布里采样下一个 token。温度和 top_p 控制采样的随机性：
| temperature | 几乎总选概率最高的词，输出稳定 | 分布被拉平，冷门词也有机会，输出发散 |
| top_p（核采样） | 只从累积概率前几名的词里选 | 候选池扩大，更多可能性 |
经验法则：
- 抽取、分类、代码生成、工具调用 → temperature 0~0.3，要确定性
- 创意写作、头脑风暴 → 0.8~1.2，要多样性
- 调一个就行，别同时猛调两个——两个都调很难预测效果，这是最常见的踩坑点
4. System Prompt：给模型定人设和规矩
System Prompt 是优先级最高的指令，用来定角色、边界、输出格式：
messages = [
{"role": "system", "content": "你是客服助手。只回答与订单相关的问题；
遇到退款请求，先引导用户提供订单号；回答保持 3 句话以内。"},
{"role": "user", "content": "我的快递怎么还没到？"},
]
实战建议：
- 具体 > 抽象：「回答简洁」没用，「3 句话以内」有用
- 把禁忌和兜底写进去：模型不知道你的业务边界，你不写它就自由发挥
- 结构化输出在 System Prompt 里定义（比如「只返回 JSON，格式为 {…}」），下游代码解析才稳
5. Function Calling：让模型「会动手」
模型本体只会生成文本。Function Calling 是让模型返回一个结构化的 JSON表达「我想调用某工具、参数是这些」，执行永远是你的代码干的：
resp = client.chat.completions.create(
model=MODEL, messages=messages, tools=tools,
)
msg = resp.choices[0].message
if msg.tool_calls:
for tc in msg.tool_calls:
args = json.loads(tc.function.arguments) # 模型给的参数
result = TOOL_MAP[tc.function.name](**args) # 你的代码执行
这正是上一篇文章 60 行 Agent 的核心。记住：工具的 description 是写给模型看的提示词——写得含糊，模型就选错工具、传错参数。
6. 幻觉：为什么会一本正经胡说八道
幻觉的根源：LLM 的本质是按概率续写，不是查数据库。当训练数据里没有答案时，它不会说「不知道」，而是生成一个统计上最像答案的东西——流畅、自信、且可能是编的。
工程上的三层防御：
7. RAG vs 微调：知识注入的两条路
要让模型懂「你的私有知识」，两条路，选错会白花钱：
| 原理 | 检索相关文档塞进上下文 | 用你的数据继续训练模型 |
| 成本 | 低，改文档即生效 | 高，数据准备 + 训练 + 部署 |
| 更新 | 实时（改知识库就行） | 重新训练 |
| 擅长 | 事实问答、文档查询、知识频繁更新 | 固定的风格、格式、领域话术 |
| 不擅长 | 注入「风格」和「行为习惯」 | 注入新事实（学得慢忘得快） |
决策口诀：知识会变用 RAG，风格不变才微调。 90% 的场景 RAG 就够了，先 RAG，RAG 明显不够再考虑微调。
8. Token 计费：成本是设计出来的
LLM 应用烧钱的三个大头，对应三个省钱手段：
- 上下文膨胀：对话历史无限追加 → 每轮把全部历史重发一遍。对策：摘要压缩、只保留最近 N 轮
- 重复内容：每轮都塞同样的长文档 → 用 RAG 只检索相关片段，别全文塞
- 输出冗长：让模型「详细解释」 → 输出 token 单价更高，明确要求输出长度
一个真实数字感受一下：一个 128K 窗口塞满中文的请求，成本相当于普通请求的几十倍。做大模型产品，先做 token 预算表。
总结
| Token | 计费、窗口、成本的计量单位，中文更费钱 |
| 上下文窗口 | 是工作记忆不是记忆，跨请求记忆自己维护 |
| 温度/top_p | 确定性任务调低，创意任务调高，别两个猛调 |
| System Prompt | 定人设和规矩，具体 > 抽象 |
| Function Calling | 模型出 JSON，你的代码执行 |
| 幻觉 | 概率续写的天性，RAG + 关键数据外置防御 |
| RAG vs 微调 | 知识会变用 RAG，风格不变才微调 |
| Token 计费 | 成本靠上下文管理和 RAG 设计出来 |
这 8 个概念是所有 LLM 应用的地基——Agent 是 5 + 循环，RAG 是 6 + 7 的组合。把地基吃透，往上盖楼才不会歪。下一篇讲 RAG 的工程实现，感兴趣的点个关注。
