XGBoost (eXtreme Gradient Boosting) 自诞生以来，凭借其在 Kaggle 竞赛中的统治级表现和工业界的广泛应用，成为了机器学习领域的“神兵利器”。

不同于传统的 GBDT，XGBoost 不仅在数学层面引入了二阶泰勒展开和正则化项，更在工程实现上通过稀疏感知、分块并行等技术将效率推向了极致。本文将深入剖析 XGBoost 的算法流程、核心推导及工程优化逻辑。

感知机（Perceptron）是神经网络和支持向量机（SVM）的鼻祖。虽然它只是一个简单的线性二分类模型，但其背后的思想——包括Novikoff收敛定理、对偶形式以及核技巧（Kernel Trick）的应用，构成了现代机器学习的重要基石。

本文将基于相关课程内容，系统梳理感知机的核心逻辑，并重点展开介绍其对偶形式与核感知机的原理。

详解操作系统的中断机制，包括外部中断与异常的区别、内核态被中断时的处理流程，以及进程用户栈、内核栈与中断栈的内存架构设计。

如果你曾遇到过“在我机器上跑得好好的，怎么在你那就不行了？”这种程序员终极悖论，那么 Docker 就是为你准备的救命稻草。

🐳 一、 什么是 Docker？（生动的比喻）

1. 搬家与集装箱

想象你要从上海搬家到新加坡。

• 传统方式：你把衣服塞进编织袋，电视机直接搬上车，电脑零散放着。到了新家，你发现插座型号不对，电视机磕坏了，电脑系统因为环境变化启动不了。
• Docker 方式：你租了一个集装箱（Container）。你把所有东西按原样布置在箱子里，连插线板都接好。到了新家，你只需要给集装箱通上电，一切立刻恢复原状。

Docker 就是那个集装箱。 它把你的代码、配置、库文件、甚至操作系统环境全部打包，确保“一次构建，到处运行”。

2. 核心概念三剑客

• 镜像 (Image) —— 建筑蓝图：它是只读的模板。比如“一个装好了 Python 3.9 和 Flask 的 Ubuntu 系统”。
• 容器 (Container) —— 真实的房子：镜像运行起来后的实例。你可以启动、停止、删除它。
• 仓库 (Registry) —— 蓝图展示馆：存放镜像的地方，最著名的是 Docker Hub。

🛠 二、 Docker 核心原理深度解析

Docker 为什么比虚拟机（VM）快？

底层技术简述：

1. Namespaces (命名空间)：给进程戴上“眼罩”，让容器以为自己拥有独立的网络、用户和进程空间。
2. Control Groups (控制组)：给容器套上“紧箍咒”，限制它能使用的 CPU 和内存上限。
3. UnionFS (联合文件系统)：分层存储。你修改了文件，它只记录“增量”，不破坏底层的原始镜像。

💻 三、 常用命令与实战场景

1. 镜像操作

2. 容器生命周期

3. 进阶调试与交互

📝 四、 快速上手实战：运行一个 Web 服务器

只需要一行命令，你就可以拥有一个 Nginx 服务器：

1
2
3
4

# 下载并启动 Nginx，映射到本地 80 端口
docker run -d -p 80:80 --name my-nginx nginx

根据我们之前的实操过程，以下是针对深度学习环境迁移、镜像瘦身及大文件处理的 Docker 经验总结。

五、 使用经验总结

• 空间管理：根目录不足时的生存法则
• docker save 极其吃空间，通常需要镜像体积 2-3 倍 的剩余空间作为临时缓存。
• 当磁盘空间告急（如剩余不足 30GB 处理 16GB 镜像）时，docker export 是唯一的救命稻草。它采用流式处理，几乎不产生临时文件。
• 瘦身先行：在打包前执行 conda clean --all 和 rm -rf ~/.cache/pip，通常能瞬间释放数 GB 空间。

• 镜像打包策略：Save vs Export
• docker save：适合完整备份。保留所有层（Layers）、环境变量、工作目录和入口脚本（Entrypoint）。
• docker export：适合环境交付。它将镜像“压扁”成一层，丢失所有历史元数据，但换来的是更小的体积和更高的导入兼容性。

• 协作交付：把“方便”留给对方
• 使用 export 导出的镜像在 import 时必须手动补回关键变量（如 PATH、LD_LIBRARY_PATH）。
• 最佳实践：不要给合作者一串长长的运行时命令（docker run --env ...），而应在 docker import 时通过 --change 选项将配置固化进镜像，实现“开箱即用”。

六、 常用命令速查表（增补版）

1. 基础服务管理

2. 核心概念辨析：镜像 vs 容器

• 镜像 (Image)：是静态的、只读的模板（类似于电脑操作系统的 .iso 安装光盘或类定义）。它存储了运行环境和代码，但不能直接运行代码。
• 容器 (Container)：是动态的、可运行的实例（类似于从光盘安装好并开机运行的电脑系统）。它是从镜像启动的，包含一个可写层，你可以在里面跑训练、改代码。

3. 运行与创建命令

• 从镜像启动新容器：

  1 2 3

  # 常用参数：-it (交互模式), --gpus all (调用显卡), -v (挂载目录) docker run -it --gpus all --name <自定义容器名> <镜像名> /bin/bash

• 进入正在运行的容器：

  1 2	docker exec -it <容器ID> /bin/bash

4. 状态保存与迁移（Commit/Export/Save）

当你修改了容器内的代码或环境，想把它存下来时：

• 本地保存修改 (Commit)：
  将当前容器的状态保存为一个新镜像。

  1 2 3

  docker commit <容器ID> <新镜像名>:<新标签> # 示例：docker commit e82722eaf5f8 dp_train:v3

• 三种导出方式对比：

5. 资源清理命令

• 查看镜像：docker images
• 查看运行中的容器：docker ps
• 查看所有容器（含已停止）：docker ps -a
• 删除容器：docker rm <容器ID>
• 删除镜像：docker rmi <镜像ID>
• 清理所有无用的数据：docker system prune（慎用，会删除所有停止的容器和孤儿镜像）。

镜像打包完成后，建议先执行一次 docker commit 将改动固化，然后再进行 export 或 save 操作，以防导出过程中意外丢失未保存的容器修改。

七、 Dockerfile 核心语法拆解（以项目为例）

一个标准的、高质量的 Dockerfile 通常遵循“从基础到应用”的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# 1. FROM: 指定基础镜像。就像选择地基，这里选的是带 CUDA 的 Ubuntu 20.04
FROM nvidia/cuda:12.1.0-devel-ubuntu20.04

# 2. ENV: 设置永久环境变量。容器运行时也会生效
ENV DEBIAN_FRONTEND=noninteractive
ENV PATH="/root/miniconda3/bin:${PATH}"

# 3. RUN: 执行 Shell 命令。这是构建镜像的核心
# 提示：将多个 apt 命令合并，并最后删除缓存，可以显著减小镜像体积
RUN apt-get update && apt-get install -y \
    libosmesa6-dev \
    libgl1-mesa-glx \
    git \
    wget \
    && rm -rf /var/lib/apt/lists/*

# 4. WORKDIR: 设置工作目录。相当于在容器里自动执行 "cd /app"
# 之后的 RUN, CMD, ENTRYPOINT 都会在这个目录下执行
WORKDIR /app

# 5. COPY: 从宿主机拷贝文件到镜像内
# 建议先拷贝配置文件安装环境，再拷贝代码，这样利用“镜像缓存”可以加快构建速度
COPY conda_environment.yaml /tmp/conda_environment.yaml

# 6. RUN (进阶): 这里利用管道符配置 Conda 和 Pip 源
RUN echo "channels: ..." > /root/.condarc && \
    pip config set global.index-url https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple

# 7. CMD: 指定容器启动时默认运行的命令
# 只有最后一行 CMD 生效，且可以被 docker run 后的参数覆盖
CMD ["/bin/bash"]

八、Dockerfile 编写与使用经验总结

1. 常用指令速查表

2. 如何使用 Dockerfile 构建镜像？

编写完 Dockerfile 后，在同级目录下执行：

1
2
3

# -t 指定镜像名和标签，后面的点 "." 代表当前目录（寻找 Dockerfile）
docker build -t dp_train:v3 .

3. 编写“高手”准则

• 顺序原则：将最不常变动的命令（如安装基础系统工具）放在前面，经常改动的（如拷贝代码）放在后面。这样在修改代码重新构建时，Docker 可以直接利用前面的缓存（Cache），秒速完成。
• 清理原则：在同一条 RUN 指令中完成安装和清理（如 rm -rf /var/lib/apt/lists/*），否则清理操作只会增加一个“删除层”，而不会真正减小镜像体积。
• 非交互模式：使用 ENV DEBIAN_FRONTEND=noninteractive 防止构建过程中弹出对话框导致失败。

九、 常用命令速查表（增补：构建与运行）

• 构建镜像：docker build -t <镜像名>:<标签> .
• 查看构建过程中的每一层：docker history <镜像名>
• 从 Dockerfile 启动并重命名：docker run -d --name my_container <镜像名>
• 强制不使用缓存构建：docker build --no-cache -t <镜像名> .

本文详细推导了支持向量机（SVM）的数学原理。从最基础的拉格朗日乘子法和KKT条件入手，逐步推导硬间隔SVM、软间隔SVM以及核技巧（Kernel Trick），旨在理清每一步推导的数学目的与几何意义。

本文总结了计算机存储层次结构、数据传输机制（DMA/PIO）、缓存写入策略（写回/写通）以及文件系统中的硬链接与软链接的本质区别。

🎓 深度解析反向传播：全连接层梯度的两种推导方法

在深度学习中，全连接层（Linear Layer）是最基础的模块。理解其反向传播中的梯度计算是掌握整个神经网络训练流程的关键。本文将以 $Y = WX + b$ 为例，演示两种核心梯度推导方法：维度检查法（Shape Check）和全微分法（Matrix Differential）。

场景设定与变量定义

假设我们在计算图中的某一层进行以下运算：

变量定义与维度（Shape）：

• $X$：输入向量，维度 $(n \times 1)$。
• $W$：权重矩阵，维度 $(m \times n)$。
• $b$：偏置向量，维度 $(m \times 1)$。
• $Y$：输出向量，维度 $(m \times 1)$。
• $L$：最终的损失函数（Scalar，标量）。

已知条件（上游传回来的梯度）：

我们已算出 Loss 对本层输出 $Y$ 的梯度：

• $G$ 的维度必须和 $Y$ 一致，也是 $(m \times 1)$。

我们的目标：
求出 $L$ 关于 $W$ 的梯度 $\frac{\partial L}{\partial W}$ 和 关于 $X$ 的梯度 $\frac{\partial L}{\partial X}$（用于继续往前传）。

方法一：维度检查法（Shape Check）

核心思想： 梯度的形状必须与其对应的变量形状一致。通过线性代数知识，用已知变量拼凑出正确的形状。

1. 求 $\frac{\partial L}{\partial W}$（权重 $W$ 的梯度）

• 目标形状： $\frac{\partial L}{\partial W}$ 的形状必须和 $W$ 一致，即 $(m \times n)$。
• 素材： $G$ (上游梯度，$(m \times 1)$) 和 $X$ (输入，$(n \times 1)$)。
• 拼凑： 想要得到 $(m \times n)$，只能将 $(m \times 1)$ 乘以 $(1 \times n)$。 $$(m \times 1) \times (1 \times n) = (m \times n)$$
• 结论： $$\frac{\partial L}{\partial W} = G X^T$$

2. 求 $\frac{\partial L}{\partial X}$（输入 $X$ 的梯度，传给上一层）

• 目标形状： $\frac{\partial L}{\partial X}$ 的形状必须和 $X$ 一致，即 $(n \times 1)$。
• 素材： $G$ (上游梯度，$(m \times 1)$) 和 $W$ (权重，$(m \times n)$)。
• 拼凑： 想要得到 $(n \times 1)$，需要将 $W$ 转置为 $(n \times m)$，再与 $G$ 相乘。 $$(n \times m) \times (m \times 1) = (n \times 1)$$
• 结论： $$\frac{\partial L}{\partial X} = W^T G$$

点评：维度检查法速度极快，是日常代码实现和面试推导的首选。

方法二：全微分法（Matrix Differential）

核心思想： 利用标量函数 $L$ 的微分 $dL$ 与梯度的关系，通过迹（Trace）的性质进行严谨推导。这是处理复杂矩阵运算的终极武器。

核心公式（迹与梯度）

对于标量函数 $L$，其微分 $dL$ 与梯度 $\nabla A$ 的关系是：

推导过程

第一步：对正向公式求微分

第二步：建立 $dL$ 方程

我们已知 $dL = \text{tr}(G^T dY)$。将 $dY$ 代入：

利用迹的线性性质：

第三步：逐项对比求梯度（利用迹的循环性质 $\text{tr}(ABC) = \text{tr}(BCA)$）

1. 求 $\frac{\partial L}{\partial W}$： 关注 $\text{Term}_W$
将 $dW$ 挪到最后面：

对比核心公式 $dL = \text{tr}((\frac{\partial L}{\partial W})^T dW)$ 可得：

两边转置：

2. 求 $\frac{\partial L}{\partial X}$： 关注 $\text{Term}_X$

对比核心公式 $dL = \text{tr}((\frac{\partial L}{\partial X})^T dX)$ 可得：

两边转置：

3. 求 $\frac{\partial L}{\partial b}$： 关注 $\text{Term}_b$

对比可得：

总结与建议：何时使用哪种方法

最佳实践：
在日常工作中，应熟练使用维度检查法快速推导和验证；在遇到非标准或复杂的矩阵运算时，则使用全微分法确保推导的准确性。

更多公式

二次型求导示例

以二次型函数 $f(\mathbf{x}) = \mathbf{x}^T \mathbf{Ax}$ 对向量 $\mathbf{x}$ 求导为例，这是机器学习（如最小二乘法、正态分布）中最经典的推导。

我们可以通过之前提到的“迹法则（Trace Trick）”和“微分法”三步走来实现：

第一步：写出函数的微分

由于二次型 $f(\mathbf{x})$ 的结果是一个标量，标量的迹等于其自身，即 $f = \text{tr}(\mathbf{x}^T \mathbf{Ax})$。
根据矩阵乘法的微分法则 $d(\mathbf{UV}) = (d\mathbf{U})\mathbf{V} + \mathbf{U}(d\mathbf{V})$，我们对 $\mathbf{x}$ 求微分：

第二步：利用迹的性质进行变换

我们的目标是将所有的 $d\mathbf{x}$ 统一移到表达式的右侧，并包裹在 $\text{tr}(\cdot)$ 中。

1. 第一项：$(d\mathbf{x}^T)\mathbf{Ax}$ 是一个标量，取迹并利用 $\text{tr}(\mathbf{M}^T) = \text{tr}(\mathbf{M})$：

1. 第二项：$\mathbf{x}^T \mathbf{A}(d\mathbf{x})$ 本身就是 $\text{tr}(\mathbf{x}^T \mathbf{A} d\mathbf{x})$ 的形式。

合并两项：

第三步：提取导数

根据定义 $df = \text{tr}((\frac{\partial f}{\partial \mathbf{x}})^T d\mathbf{x})$，对比上面的等式：

两边同时转置，得到最终导数公式：

📌 结论与应用

• 一般情况：$\nabla_{\mathbf{x}} (\mathbf{x}^T \mathbf{Ax}) = (\mathbf{A} + \mathbf{A}^T)\mathbf{x}$。
• 当 $\mathbf{A}$ 是对称矩阵时（即 $\mathbf{A}^T = \mathbf{A}$）：

这与标量求导 $\frac{d(ax^2)}{dx} = 2ax$ 在形式上非常相似，非常好记。

🚀 Hexo + GitHub Pages 搭建个人博客流程总结

本文根据 Hexo 与 GitHub Pages 的标准实践，简要总结了从环境配置到最终部署上线的四个主要阶段，帮助您快速建立自己的静态博客。

阶段一：环境准备与工具安装

这是本地工作的核心基础，确保 Hexo 和 Git 能够正常运行。

1. 安装 Node.js： Hexo 框架依赖于 Node.js 环境（版本要求 6.9+），用于安装 Hexo 本身和各种插件。
2. 安装 Git： 用于版本控制和将本地文件推送到 GitHub 远程仓库。
3. 安装 Hexo CLI： 通过 Node.js 的包管理器 npm 全局安装 Hexo 命令行工具。
   • 命令：npm install -g hexo-cli

阶段二：Hexo 本地框架初始化

在本地创建一个 Hexo 博客项目文件夹，并进行必要的测试。

1. 创建项目文件夹： 选择一个目录，并初始化 Hexo 框架。
   • 命令：hexo init <文件夹名称>
   • 命令：cd <文件夹名称>
2. 本地预览： 运行本地服务器，在浏览器中查看博客初始效果。
   • 命令：hexo s (访问 http://localhost:4000)

阶段三：GitHub 仓库与 Pages 配置

这一步将创建博客的托管空间，是实现公开访问的关键。

1. 创建 GitHub 仓库： 在 GitHub 上创建一个新的仓库，名称必须严格遵守 <YourUserName>.github.io 的格式（这是搭建个人主页网站的要求）。
2. 配置 Hexo 部署依赖： 确保安装了 Git 部署插件。
   • 命令：npm install hexo-deployer-git --save
3. 配置 Hexo 部署信息： 修改本地 Hexo 项目根目录下的 _config.yml 文件，配置 deploy 部分，指向您的 GitHub 仓库地址。
   • 推荐配置示例（使用 SSH 地址）：

     1 2 3 4

     deploy: type: git repo: git@github.com:<YourUserName>/<YourUserName>.github.io.git branch: main # 或 master，取决于您的 GitHub 默认分支

4. 配置 SSH Key (推荐)： 如果使用 SSH 地址，需在本地生成 SSH Key 并将其添加到 GitHub 账户中，以实现免密推送。

阶段四：编写、生成与部署

博客内容上线发布的核心操作。通常只需要这三个命令循环执行。

常用命令合集：

• 新建文章： hexo new "文章标题"
• 完整发布： hexo clean && hexo g && hexo d

💡 总结与核心原理

Hexo + GitHub Pages 的核心工作流是：

本地 Hexo 将 Markdown 编译成静态 HTML $\rightarrow$ Git 将 HTML 推送到 GitHub 仓库 $\rightarrow$ GitHub Pages 服务将该仓库内容作为网站发布。

部署成功后，您的博客即可通过地址 https://<YourUserName>.github.io 访问。

进阶优化 (可选)

• 更换主题： 通过下载主题包并在 _config.yml 中配置 theme: 字段。
• 自定义域名： 购买域名，配置 DNS 解析，并在 GitHub 仓库中配置 CNAME 文件。

📚 参考

• [GitHub Pages 官方文档]
• [Hexo 官方文档]
• https://www.cnblogs.com/xango/p/18909673

🚀 深入理解 C/C++ 条件变量：告别死锁与虚假唤醒

条件变量（Condition Variable）是多线程编程中实现线程间高效通信与同步的核心机制。无论是使用 C 语言的 POSIX 线程库 (pthread) 还是现代 C++ 标准库，理解其背后的语义和正确用法至关重要。

本文将深入解析 C++ std::condition_variable 与 POSIX pthread_cond_t 的异同，并强调条件变量使用中最关键的两个原则。

一、 条件变量的基本原理与作用

条件变量总是与互斥量（Mutex）和共享状态（Shared State/Predicate）一起工作。

它的核心作用是：

1. 原子性等待： 允许一个线程原子性地执行“释放锁并阻塞等待”的操作，确保不会丢失通知信号。
2. 线程通知： 允许另一个线程在修改共享状态后，通知等待的线程解除阻塞。

二、 语义核心：MESA vs. HOARE

条件变量规范主要有两种语义，它们定义了唤醒线程如何重新获得锁，以及是否需要重新检查条件。

1. MESA 语义 (多数操作系统/标准库的选择)

MESA 语义 是指 POSIX pthread_cond_t 和 C++ std::condition_variable 在绝大多数平台上的实现所采用的语义。

为什么采用 MESA 语义？

MESA 语义的实现成本较低，效率更高。它避免了复杂的内核操作来原子性地转移锁的所有权。它将“唤醒线程”和“线程重新获取锁”这两个步骤解耦，代价就是将安全检查的责任转移给了程序员（即 while 循环）。

BTW
posix的条件变量的工作方式有点像进程的管理方法，即有三种状态：等待->就绪->运行。pthread_cond_wait后会进入等待队列，被pthread_cond_signal后会进入就绪队列，但是不保证条件一定满足（MESA语义只是暗示有条件发生了改变）

2. HOARE 语义 (理论模型，实现较少)

HOARE 语义 源于条件变量的原始理论模型。

为什么 HOARE 语义不常用？

虽然 HOARE 语义在逻辑上更优雅，但其实现涉及内核必须原子性地完成“释放通知线程的 CPU -> 唤醒等待线程 -> 转移锁”这一复杂操作，开销较大，且难以在不同的操作系统内核中高效实现。

三、 MESA 语义与 C/C++ 条件变量的实际应用

基于 MESA 语义，无论是 C 还是 C++，其核心原则都保持一致：

1. POSIX pthread_cond_t (C 风格)

POSIX 库不提供异常安全和 RAII。开发者必须手动管理资源和同步逻辑，并显式实现条件检查的 while 循环。

1
2
3
4
5
6
7
8

// POSIX C 示例：必须使用 while 循环
pthread_mutex_lock(&mutex);
while (!condition_is_true) {
    // 释放锁并等待，唤醒后重新获取锁
    pthread_cond_wait(&cond, &mutex); 
}
// 此时条件满足，可以操作共享数据
pthread_mutex_unlock(&mutex);

2. C++ std::condition_variable (C++ 风格)

C++ 标准库将互斥锁和条件检查进行了完美封装，提供了异常安全和类型安全的 API。

方案 A: 经典 C++ 写法 (需手动 while)

这种写法与 POSIX 风格逻辑相同，需手动编写 while 循环来确保 MESA 语义的安全。

1
2
3
4
5
6

std::unique_lock<std::mutex> lock(m);
// 必须在 while 循环中检查条件
while (!condition_is_true) {
    cond.wait(lock); 
}
// ...

方案 B: 推荐的 C++ 写法 (带谓词)

这是对 MESA 语义的最佳应对方案。std::condition_variable::wait(lock, predicate) 的重载版本在函数内部为你实现了 while 循环和条件检查。

你不需要外部 while 循环，因为它已内置在 wait 函数中。

1
2
3
4
5
6
7
8
9
10

std::unique_lock<std::mutex> lock(m);

// **内置 while 循环**：
// 内部执行： while (!predicate()) { wait(lock); }
cond.wait(lock, []{ 
    return data_is_ready; // Lambda 表达式作为谓词
}); 

// 此时条件 guaranteed_data_is_ready 为真
// ...

四、 总结与最佳实践

强烈推荐： 在 C++ 项目中，始终优先使用 std::condition_variable 并采用带 谓词 (Predicate) 的 wait 重载，以最大限度地保证代码的健壮性和异常安全性。

五、参考

OSTEP ch30

第一部分：痛点驱动的 Policy Gradient (PG) 推导

1. 强化学习的起点

我们将强化学习建模为一个随机过程。
轨迹 (Trajectory) 定义为

• 策略 (Policy): $\pi_\theta(a|s)$
• 轨迹分布: $$p_\theta(\tau)=\rho(s_1)\prod_{t=1}^T \pi_\theta(a_t|s_t)P(s_{t+1}|s_t,a_t)$$

其中 $\rho(s1)$ 是初始状态分布，$P(s{t+1}|s_t,a_t)$ 是环境转移概率。

目标函数 (Optimization Objective)

最常见的写法是最大化折扣累计回报：

为避免符号干扰，下面有时会省略 $\gamma$，但不影响核心推导。

❗ 痛点 1：不能直接对奖励求导

奖励来自环境交互，环境通常是黑箱；而且期望又定义在依赖于 $\theta$ 的轨迹分布上，因此不能像监督学习那样直接把梯度穿过环境。

2. Log-Derivative Trick（REINFORCE）

从定义出发：

其中 $R(\tau)$ 表示整条轨迹的累计回报。

对参数求导：

利用恒等式

得到

再展开 $\log p_\theta(\tau)$：

由于环境转移概率 $P(s_{t+1}|s_t,a_t)$ 与策略参数 $\theta$ 无关，因此

代回得

这就是最基础的 REINFORCE 形式。

直观解释：
如果某条轨迹总回报高，就提高这条轨迹中所有动作的概率；如果回报低，就降低这些动作的概率。

❗ 痛点 2：高方差

每个时间步都乘上整条轨迹的总回报，这会把大量与当前动作无关的噪声也一起灌进梯度里。

3. 改进一：因果性（Causality）与 Reward-to-Go

REINFORCE 的一个关键问题在于：动作 $a_t$ 不应该为过去的奖励负责。

形式化地说，对于当前时间步 $t$，过去的奖励 $r1,\dots,r{t-1}$ 不会受到当前动作 $a_t$ 的影响。因此在期望意义下，过去奖励对应的项会消失，留下的只需要是从当前时刻开始的未来回报：

于是梯度可改写为

这一步常被称为 reward-to-go，它不改变期望梯度，但显著降低了方差。

直观解释：
在时间步 $t$ 采取的动作，只该根据它对未来回报的影响来被奖励或惩罚，而不该背锅过去已经发生的事。

4. 改进二：Baseline 与 Advantage

虽然 reward-to-go 已经降低了方差，但它仍然会遇到一个问题：
即使当前动作只是“平均水平”，只要该状态本身未来回报大，梯度也可能把这个动作无差别地推高。

这时我们引入一个只依赖状态、与动作无关的 baseline：$b(s_t)$。

关键性质是：

证明非常直接：

因此我们可以在不改变期望梯度的前提下，把 $G_t$ 替换为 $G_t-b(s_t)$。

最常用的选择是令 baseline 近似状态价值函数：

定义优势函数（Advantage）：

在采样估计里，常用

于是我们得到更实用的 PG 形式：

本质含义：
不是问“这个状态未来回报高不高”，而是问“这个动作是否比这个状态下的平均动作更好”。

5. 从 Trajectory 形式到 State-Action 形式（Policy Gradient Theorem）

从 REINFORCE 出发：

利用期望的线性性，将 trajectory 按时间步拆开：

对每一项使用条件期望（固定 (s_t, a_t)）：

注意到：

因此：

最后，将对时间步的求和吸收到状态访问分布中（定义 ($d^{\pi_\theta}(s)$) 为在策略下访问 state 的频率）：

得到：

第二部分：从 REINFORCE 到 Actor-Critic，再到基于旧策略样本的目标

到这里为止，主线还是标准的 on-policy policy gradient。接下来的核心问题是：

每次策略一更新，旧数据就和新策略不再完全匹配；如果每次都只用最新样本做一步更新，样本利用率会很低。

这里需要特别澄清一件事：

PPO 不是传统意义上的 fully off-policy 方法。

它的本质仍然是 on-policy / near-on-policy：

• 数据由旧策略 $\pi{\theta{\text{old}}}$ 采样；
• 然后固定这批数据，对当前策略做若干轮优化；
• 为了让“用旧策略采样的数据优化新策略”这件事在数学上成立，我们需要引入一个基于新旧策略比值的 surrogate objective。

因此，下面这部分不是在把 PPO 推成一个一般意义上的 off-policy 算法，而是在解释：

为什么 PPO 会自然出现 likelihood ratio，以及为什么需要限制新旧策略不要偏得太远。

1. Policy Gradient Theorem 的视角

上面从轨迹概率出发得到的是 REINFORCE 形式。更进一步，我们可以把梯度写成状态-动作分布上的形式：

其中 $d^{\pi\theta}(s)$ 表示策略 $\pi\theta$ 诱导的状态访问分布。

再减去任意只依赖状态的 baseline，可以写成

这就是从 REINFORCE 过渡到 actor-critic 的标准形式。

2. 用旧策略样本构造可优化目标

设旧策略为

我们用它采样得到一批数据 $(st,a_t,r_t)$。现在想优化一个新策略 $\pi\theta$。

对于任意固定的状态动作对 $(s_t,a_t)$，定义概率比值：

那么，对旧策略样本上的一个自然 surrogate objective 是：

其中

这个目标非常重要，因为它满足两个关键性质：

1. 当 $\theta=\theta_{\text{old}}$ 时，$\rho_t(\theta)=1$；
2. 在 $\theta=\theta_{\text{old}}$ 附近，它的梯度与真实目标 $J(\theta)$ 的梯度一致。

因此，它是一个一阶正确（first-order correct）的局部 surrogate objective。

这正是 TRPO / PPO 的起点。

3. 为什么这里会出现 likelihood ratio？

如果直接在旧策略样本上写

那它与当前策略 $\pi_\theta$ 无关，根本无法优化。

而如果我们想在旧数据上评估“当前策略对这些动作的偏好是否应该增大或减小”，就必须把当前策略和旧策略在同一样本上的概率联系起来。最自然的量正是

它的含义非常直观：

• 若 $\rho_t(\theta)>1$，说明新策略更倾向于这个动作；
• 若 $\rho_t(\theta)<1$，说明新策略更不倾向于这个动作。

再乘上优势 $\hat A_t$，就得到“应该把这个动作的概率往哪个方向调”的局部优化信号。

4. 关于 trajectory-level importance sampling 的正确位置

很多讲法会先写出全轨迹 importance sampling：

再把轨迹比值展开成

这个公式本身是正确的，因为环境转移概率会在比值中消掉。

但它更适合作为直觉背景，而不适合作为 PPO 的主推导。原因在于：

1. 全轨迹连乘的方差极大；
2. PPO 实际优化的并不是这个 trajectory-level 目标；
3. 更标准的路线是直接从 policy gradient theorem 与局部 surrogate objective 出发。

所以，在理解 PPO 时，trajectory-level importance sampling 可以作为“为什么 ratio 会出现”的背景说明，但不应把它当成 PPO clip 目标的正式来源。

第三部分：从 Surrogate Objective 到 TRPO / PPO 的核心思想

到这里，已经有了一个局部正确的目标：

它解决了“如何在旧策略样本上优化当前策略”的问题，但新的问题马上出现：

如果新策略和旧策略相差太大，这个局部近似就会失效。

这才是 TRPO 与 PPO 真正要解决的核心难点。

1. 为什么不能直接最大化这个目标？

看单个时间步上的项：

如果 $\hat A_t>0$，最大化它会推动 $\rho_t(\theta)$ 尽可能变大，也就是大幅提高该动作概率；
如果 $\hat A_t<0$，则会推动 $\rho_t(\theta)$ 尽可能变小，也就是大幅降低该动作概率。

问题在于：
这个目标本身并没有限制“改多大”。一旦 $\pi\theta$ 相对 $\pi{\text{old}}$ 偏移过大，

• 旧样本对新策略不再有代表性；
• surrogate objective 与真实目标之间的一阶近似关系会迅速变差；
• 训练会变得不稳定，甚至崩掉。

因此，真正的问题不在于有没有 surrogate，而在于：

如何让每次更新都保持“足够近端（proximal）”。

2. TRPO 的思路：显式限制 KL 距离

TRPO 的做法是：

在最大化 surrogate objective 的同时，显式约束新旧策略之间的 KL 距离不要太大：

它的思想非常清楚：

• surrogate objective 告诉我们“朝哪里改”；
• KL 约束告诉我们“每次别改太远”。

TRPO 具有很强的理论动机，但工程实现较复杂，因为它通常涉及二阶近似、共轭梯度等操作。

3. PPO 的思路：用更简单的方式近似“近端更新”

PPO 的目标不是推翻 TRPO，而是用更简单、更稳定、更适合深度学习训练的方式，近似实现“不要偏离太远”这一思想。

PPO 最常见的版本是 PPO-Clip。

它并不显式加一个硬 KL 约束，而是直接在每个样本的 ratio 上做截断：

定义裁剪函数：

然后构造目标：

这就是 PPO 的核心公式。

第四部分：为什么 PPO-Clip 这样设计是合理的？

1. 先看不裁剪时会发生什么

如果只有

那优化器会想办法把对目标有利的 $\rho_t$ 推得越来越极端：

• 对于 $\hat A_t>0$ 的样本，希望 $\rho_t$ 越大越好；
• 对于 $\hat A_t<0$ 的样本，希望 $\rho_t$ 越小越好。

这会使策略更新缺乏约束，导致 surrogate 失真。

2. 对正优势样本的解释

若 $\hat A_t>0$，则我们希望提高该动作概率，也就是希望 $\rho_t(\theta)$ 变大。

此时：

当 $\rho_t \le 1+\epsilon$ 时，裁剪不起作用；
当 $\rho_t > 1+\epsilon$ 时，第二项变成 $(1+\epsilon)\hat A_t$，而它比第一项更小，因此 min 会选择被裁剪后的那一项。

含义：
这个动作是好的，可以提高它的概率；但一旦提高幅度超过阈值，就不再继续鼓励。

3. 对负优势样本的解释

若 $\hat A_t<0$，则我们希望降低该动作概率，也就是希望 $\rho_t(\theta)$ 变小。

当 $\rho_t < 1-\epsilon$ 时，裁剪后的比值变成 $1-\epsilon$。因为此时乘的是一个负数，

所以 min 会选更小的那个，也就是裁剪后的项。

含义：
这个动作是坏的，可以降低它的概率；但一旦降得过猛，也不再继续鼓励。

4. min 的真正作用

min 并不是在构造一个对真实目标的严格数学下界，而是在构造一个更保守的 surrogate objective。

它的效果是：

• 当策略更新还在合理区间内时，目标基本等同于原始 surrogate；
• 当更新试图把 ratio 推得过大或过小时，目标会自动变“保守”，抑制继续朝极端方向走。

因此，PPO-Clip 的核心不是“精确逼近 TRPO 的 KL 约束”，而是用一种非常简单的样本级机制，达到“近端更新”的效果。

第五部分：Advantage 的实际估计 —— 为什么 PPO 通常配合 GAE

到目前为止，公式里一直写的是 $\hat A_t$。但在实际算法里，优势函数并不是直接已知的，需要估计。

最简单的估计是 Monte Carlo：

但它仍然可能方差较大，因此 PPO 中更常见的是 GAE (Generalized Advantage Estimation)。

先定义 TD residual：

然后定义 GAE：

它可以看作在 bias 与 variance 之间做折中：

• $\lambda$ 大，接近 Monte Carlo，偏差更小但方差更大；
• $\lambda$ 小，接近 TD，方差更小但偏差更大。

在工程实践中，PPO 几乎总会和 GAE 搭配使用。

第六部分：PPO 的完整训练目标

PPO 通常采用 actor-critic 架构，因此除了策略目标之外，还会同时训练价值函数，并加上熵正则以鼓励探索。

若将 actor 参数记为 $\theta$，critic 参数记为 $\phi$，则一个常见的总目标写作：

其中：

• $L^{\text{CLIP}}_t(\theta)$ 是前面定义的 clipped surrogate；
• $V_t^{\text{target}}$ 是 value regression 的监督信号，常由回报或 bootstrap target 构造；
• $\mathcal H(\pi_\theta(\cdot|s_t))$ 是策略熵，用来鼓励探索；
• $c_1,c_2$ 是权重系数。

如果 actor 与 critic 共享部分网络参数，上式也常被合并写成单个参数 $\theta$ 的形式；但从概念上区分 $\theta$ 与 $\phi$ 会更清晰。

第七部分：把公式串成算法流程

到这里，PPO 的推导已经闭环了。它的实际训练流程可以概括为：

1. 用当前策略 $\pi_{\text{old}}$ 与环境交互，采样一批轨迹；
2. 用 critic 计算每个状态的 $V(s_t)$；
3. 根据奖励和价值函数，计算 $\hat A_t$（通常用 GAE）以及 value target；
4. 固定这批由旧策略采样的数据，做若干个 epoch 的 mini-batch SGD；
5. 优化的 actor 目标是 clipped surrogate objective；
6. 同时优化 critic loss 与 entropy bonus；
7. 更新完成后，把当前策略记作新的 $\pi_{\text{old}}$，进入下一轮采样。

这也解释了为什么 PPO 通常被称为 on-policy / near-on-policy：
它虽然会对同一批旧数据重复优化多轮，但这些数据仍然只来自最近一轮旧策略，而不是像 DQN/SAC 那样在长期 replay buffer 中反复混用来自很多历史策略的数据。

总结

从 Policy Gradient 到 PPO 的演进，本质上是一条不断解决“高方差”和“更新不稳定”问题的路线：

1. REINFORCE：
   用 log-derivative trick 绕开环境不可导，但梯度方差很大。

2. Reward-to-Go + Baseline/Advantage：
   利用因果性去掉过去奖励的噪声，再通过 baseline 判断动作是否“优于平均”，进一步降低方差。

3. Policy Gradient Theorem + Actor-Critic：
   把轨迹级视角转成状态-动作级视角，得到更适合实际训练的优势函数形式。

4. Old-policy surrogate objective：
   为了在旧策略采样的数据上优化当前策略，引入 likelihood ratio

   $$\rho_t(\theta)=\frac{\pi_\theta(a_t|s_t)}{\pi_{\text{old}}(a_t|s_t)}$$

   构造局部正确的 surrogate objective

   $$\mathbb E_t[\rho_t(\theta)\hat A_t]$$

5. TRPO / PPO：
   当新旧策略偏得太远时，surrogate 会失效；TRPO 用 KL 约束显式限制步长，PPO 用 clipping 给出更简单、更稳定的近端更新机制。

所以，PPO 的本质并不是“把 off-policy importance sampling 做得更稳定”，而是：在基于旧策略样本的局部 surrogate objective 上，通过限制新旧策略偏离，稳定地进行策略优化。

这才是从 Policy Gradient 到 PPO 最核心的那条逻辑主线。