从语言模型开始理解#

最基础的语言模型任务可以写成：给定前面的文本，预测下一个 token。

例如输入：

1
大模型的核心能力来自

模型需要预测后面可能出现的 token，比如“数据”“训练”“参数”“注意力机制”等。看起来只是续写，但当训练数据足够大、模型容量足够大时，这个简单目标会迫使模型学习语言结构、常识关联、代码模式、数学符号、对话风格和任务指令。

这也是为什么现代大模型常被称为“通用模型”。它并不是被单独训练成翻译器、问答器或代码助手，而是在大量文本中学到一种可迁移的表示能力。

Token 是模型真正处理的单位#

模型并不是直接读“字”或“词”，而是先通过 tokenizer 把文本切成 token。中文里一个 token 可能是一个字，也可能是一个词的一部分；英文里一个单词也可能被切成多个 token。

token 设计会影响几个重要问题：

• 上下文窗口能放多少内容
• 中文、英文、代码的压缩效率
• 训练和推理时的计算量
• 长文本任务的成本

所以当我们说一个模型支持 128K 上下文时，本质上说的是支持 128K 个 token，而不是 128K 个汉字。

Embedding：把 token 变成向量#

token 本身只是编号，模型不能直接理解编号的语义。Embedding 层会把每个 token id 映射成一个高维向量。

可以把向量理解成模型内部的“语义坐标”。相似含义的 token 往往会在向量空间里更接近，但这个空间不是人手工设计的，而是在训练中自动学出来的。

Attention：决定该看哪里#

Self-Attention 是 Transformer 的核心。它让序列里的每个位置都能根据当前任务，动态关注其他位置的信息。

一个简化理解是：

• Query 表示“我现在想找什么信息”
• Key 表示“我这里有什么特征可以被别人匹配”
• Value 表示“如果别人关注我，我能提供什么内容”

注意力权重来自 Query 和 Key 的匹配程度，然后用这些权重汇总 Value。这样模型在生成某个 token 时，可以关注前文中最相关的部分。

Multi-Head Attention：从多个角度看文本#

单个注意力头只能学习一种关注模式，多头注意力则允许模型同时从多个角度理解文本。

有的头可能关注语法关系，有的头关注实体指代，有的头关注代码缩进，有的头关注段落主题。多头机制不是显式规定的，但训练后常常会形成类似分工。

Feed Forward：逐位置加工信息#

注意力层负责信息交互，前馈网络负责对每个位置的表示进行非线性变换。很多大模型的参数其实主要集中在前馈网络部分。

这部分可以理解为模型对已经汇总的信息做进一步抽象、压缩和重组。

Residual 和 LayerNorm：让深层网络稳定训练#

大模型往往有几十层甚至上百层 Transformer block。如果没有残差连接和归一化，梯度传播会很不稳定。

Residual connection 让每一层可以在原始表示上做增量修改，而不是完全重写表示。LayerNorm 则让每层输入分布更稳定。

数据规模很重要，但不是越多越好#

训练数据通常来自网页、书籍、论文、代码、问答社区和多语言文本。数据量越大，模型越有机会看到更多知识和表达方式，但低质量数据也会带来噪声。

高质量数据处理包括：

• 去重，减少模型记忆重复内容
• 过滤垃圾文本和乱码
• 清理隐私和敏感信息
• 平衡不同语言和领域
• 保留高质量代码、数学和专业文本

很多时候，数据质量对模型效果的影响不亚于参数规模。

预训练目标很简单#

自回归语言模型的目标是最大化下一个 token 的概率。训练时模型会看到一段文本的前半部分，然后预测后面的 token。

简化伪代码如下：

1
for batch in dataset:
2
    input_ids = batch[:, :-1]
3
    labels = batch[:, 1:]
4
    logits = model(input_ids)
5
    loss = cross_entropy(logits, labels)
6
    loss.backward()
7
    optimizer.step()

真实训练会复杂得多，包括分布式并行、混合精度、梯度累积、学习率调度、checkpoint 管理和容错恢复。但核心目标仍然是预测下一个 token。

参数规模带来容量#

参数越多，模型通常越能拟合复杂模式，也更容易在多任务上表现出泛化能力。但参数越多也意味着训练成本、推理成本和部署难度上升。

常见规模可以粗略理解为：

• 小模型：1B 到 7B，适合本地部署和低成本任务
• 中等模型：13B 到 70B，综合能力更强
• 超大模型：百 B 以上，能力更强但成本明显提高

选择模型时不应该只看参数量，还要看训练数据、上下文长度、推理速度、工具调用能力和中文能力。

SFT：让模型学会按指令回答#

SFT 是 supervised fine-tuning，也就是监督微调。训练数据通常是“指令 -> 高质量回答”的格式。

例如：

1
{
2
  "instruction": "用三句话解释什么是注意力机制",
3
  "response": "注意力机制是一种让模型在处理当前 token 时动态选择相关上下文的方法。它会计算不同位置之间的相关性，并根据权重汇总信息。这样模型可以更好地处理长距离依赖和复杂语义关系。"
4
}

SFT 之后，模型会更愿意遵循用户请求，也更适合聊天、写作、总结和代码解释。

偏好对齐：让回答更符合人类期待#

只靠 SFT 还不够。模型可能啰嗦、答非所问，或者在不确定时编造。偏好对齐会通过人类反馈或 AI 反馈，让模型学会区分更好的回答。

常见方法包括 RLHF、DPO、IPO 等。不同方法细节不同，但目标相似：让模型输出更有帮助、更安全、更符合指令。

对齐不是万能的#

对齐能改善行为风格，但不能凭空补齐模型没有学过的知识，也不能保证所有事实都正确。对于知识密集任务，仍然需要检索、工具调用、结构化数据和人工校验。

这也是 RAG 和 Agent 系统存在的原因。

为什么需要 RAG#

大模型参数里的知识有几个问题：

• 可能过时
• 难以追溯来源
• 对私有数据一无所知
• 容易在细节上幻觉

RAG 可以把知识从模型参数中解耦出来。模型负责理解和生成，知识库负责提供事实依据。

一个典型 RAG 流程#

RAG 系统通常包含以下步骤：

1. 文档切分：把长文档切成合适片段。
2. 向量化：用 embedding 模型把片段转成向量。
3. 建索引：把向量写入向量数据库。
4. 检索：用户提问后检索相似片段。
5. 重排：用 reranker 重新排序候选片段。
6. 生成：把最相关片段放进 prompt，让大模型回答。
7. 引用：返回答案时附带来源。

RAG 最容易踩的坑#

RAG 不是把文档扔进向量库就能做好。常见问题包括：

• 切分太粗，检索片段包含大量无关内容
• 切分太细，单个片段缺少上下文
• embedding 模型和业务语言不匹配
• 只做向量检索，忽略关键词检索
• prompt 没要求模型基于资料回答
• 没有引用来源，答案无法验证

一个可用的 RAG 系统，往往需要 hybrid search、rerank、元数据过滤和答案校验。

Agent 的基本循环#

一个常见 Agent 循环是：

1. 理解任务目标
2. 制定下一步计划
3. 选择工具
4. 执行工具调用
5. 观察结果
6. 更新计划
7. 输出最终答案

这个循环看起来简单，但工程上很容易失控。模型可能调用错误工具、陷入循环、忽略工具结果，或者把中间错误继续放大。

工具设计比模型更重要#

给 Agent 设计工具时，应该让工具职责清晰、参数明确、返回结果结构化。

不好的工具：

1
search(anything)

更好的工具：

1
{
2
  "name": "search_docs",
3
  "description": "Search internal product documentation",
4
  "parameters": {
5
    "query": "string",
6
    "limit": "number",
7
    "product": "string"
8
  }
9
}

工具越清晰，模型越容易做出稳定选择。

Agent 需要边界#

真实业务里不能让 Agent 无限行动。需要限制最大步骤数、工具权限、花费预算、超时时间和高风险操作确认。

对于写入数据库、发送邮件、执行交易、删除文件这类操作，应该要求人工确认或增加权限校验。

Prefill 和 Decode#

大模型推理通常分成两个阶段：

• Prefill：处理用户输入的 prompt，一次性计算上下文。
• Decode：逐 token 生成回答，每次生成一个新 token。

长 prompt 会让 prefill 变慢，长回答会让 decode 变慢。聊天应用里，用户最关心的是首 token 延迟和整体生成速度。

KV Cache#

自回归生成每一步都依赖前文。如果每生成一个 token 都重新计算全部上下文，成本会非常高。KV Cache 会缓存已经计算过的 Key 和 Value，避免重复计算。

KV Cache 能显著加速生成，但也占用显存。上下文越长、并发越高，KV Cache 压力越大。

量化#

量化是把模型权重从高精度转换成低精度，比如 FP16 转 INT8 或 INT4。这样可以减少显存占用并提升推理速度。

但量化可能损失精度，尤其是数学、代码和复杂推理任务。实际选择时要在效果和成本之间平衡。

批处理与并发#

服务端通常会把多个请求合并成 batch，提高 GPU 利用率。问题是用户请求长度不一、生成长度不一，如果调度不好，会导致延迟波动。

优秀的推理服务需要处理动态批处理、请求排队、超时取消、流式输出和资源隔离。

Prompt 是接口，不是魔法#

Prompt 本质上是人和模型之间的接口设计。好的 prompt 应该明确角色、任务、输入、输出格式和约束。

例如：

1
你是一个技术博客助手。
2
请根据给定资料回答问题。
3
如果资料不足，请明确说明不知道，不要编造。
4
输出结构：
5
1. 结论
6
2. 依据
7
3. 需要确认的问题

越是复杂任务，越应该把输出格式结构化，比如 JSON、表格或固定段落。

评估要提前设计#

很多团队先做 demo，后面才发现无法判断模型改动是否变好。评估应该从一开始就设计。

常见评估维度：

• 准确性：事实是否正确
• 完整性：是否覆盖关键点
• 可追溯性：是否有来源
• 格式稳定性：是否符合输出结构
• 安全性：是否拒绝危险请求
• 成本：token 和推理时间是否可接受

对于知识库问答，可以构建一批标准问题和参考答案，每次更换模型、prompt 或检索策略后跑一遍。

日志与观测#

线上系统必须记录关键链路：

• 用户问题
• 检索到的文档
• 最终 prompt
• 模型输出
• token 消耗
• 响应时间
• 错误类型

这些日志用于排查问题、优化召回、评估成本，也能帮助发现模型幻觉和用户真实需求。

第一阶段：使用和概念#

先熟悉模型 API、本地模型部署、prompt 基础、token、上下文窗口、temperature、top_p、流式输出等概念。

这个阶段的目标是能独立做一个小工具，比如文章摘要、问答助手或代码解释器。

第二阶段：Transformer 和训练#

开始学习 Transformer、attention、embedding、loss、优化器、预训练、SFT 和对齐。可以不急着训练大模型，但要理解训练过程在优化什么。

这个阶段建议结合小模型实验，比如用一个小型 GPT 结构在玩具数据上训练，观察 loss 变化和生成结果。

第三阶段：RAG 和工程应用#

学习文档切分、embedding、向量数据库、rerank、prompt 拼接、引用来源和评估集。这个阶段最贴近真实应用，也最容易产生可展示项目。

第四阶段：推理部署和优化#

学习 vLLM、TensorRT-LLM、llama.cpp、量化、KV Cache、批处理、并发控制和监控。这个阶段更偏工程，需要结合服务器资源实践。

第五阶段：Agent 和复杂系统#

最后再进入 Agent、工具调用、多轮规划、权限控制、记忆系统和工作流编排。Agent 看起来酷，但没有前面的基础，很容易做成不稳定的演示。

误区一：参数越大越适合所有任务#

大模型不是越大越好。简单分类、固定格式抽取、轻量客服等任务，小模型加好数据可能更便宜、更快、更稳定。

误区二：RAG 可以解决所有幻觉#

RAG 能降低幻觉，但不能彻底消除。检索结果错误、上下文不足、prompt 约束弱，都会导致模型继续胡说。

误区三：Prompt 写得长就一定更好#

长 prompt 会增加成本和延迟，也可能引入冲突指令。好的 prompt 是清晰而不是冗长。

误区四：上线后不需要评估#

模型应用上线后会遇到真实用户输入，分布和测试集完全不同。没有日志、评估和反馈，系统会很难持续优化。