duangxinBlog

记录 LLM、Agent、文章阅读与项目实践

个人技术博客源码分析 | Hexo + NexT + Cloudflare Pages

一句话概括
duangxinBlog 是一个用于沉淀学习记录、论文阅读笔记、项目实践和阶段复盘的中文静态博客项目。项目用 Hexo 负责生成静态站点,用 NexT 提供博客主题和阅读体验,再通过 Cloudflare Pages 完成自动化构建与发布。

1. 项目定位

项目 说明
项目名称 duangxinBlog
项目类型 个人技术博客 / 静态站点源码
核心目标 把学习过程、阶段复盘和技术实践沉淀为可持续维护的博客内容。
维护方式 在本地仓库编辑 Markdown 文章,构建为静态文件,再通过托管平台发布。
当前状态 项目结构、主题配置、分类页面、标签页面、关于页面、学习计划页面和静态构建流程均已建立。

2. 使用的技术

层面 技术 / 配置 作用
运行环境 Node.js >= 20.19.0;.nvmrc 指向 Node 22 确保本地开发环境与部署环境的 Node 版本保持一致。
静态生成 Hexo 8.1.2 / hexo ^8.0.0 将 Markdown 文章、页面、模板和资源生成静态站点文件。
主题系统 hexo-theme-next ^8.27.0,NexT Pisces 方案 提供博客布局、菜单、归档、侧栏、文章目录、深色模式等界面能力。
内容格式 Markdown + YAML Front Matter 通过文本文件维护文章正文,并用 front matter 管理标题、日期、分类和标签。
渲染依赖 hexo-renderer-marked、EJS、Stylus、highlight.js 分别处理 Markdown、模板、样式和代码高亮。
生成插件 archive、category、index、tag、feed generators 生成首页分页、归档页、分类页、标签页和订阅源。
部署平台 Cloudflare Pages 监听主分支变更,执行构建命令,并把 public/ 目录发布为静态网站。
依赖维护 package-lock.json + Dependabot npm daily 锁定依赖版本,同时跟踪 npm 依赖更新。

3. 已实现功能

3.1 内容发布能力

  • 支持用 Markdown 编写文章,正式文章统一放在 source/_posts/。

  • 支持文章标题、发布时间、分类、标签等元信息管理。

  • 支持首页分页、文章详情页、归档页、分类页和标签页自动生成。

  • 支持 Atom 订阅源生成,方便读者订阅后续更新。

  • 构建输出统一进入 public/,便于静态托管平台发布。

3.2 站点阅读体验

  • 使用 NexT 的 Pisces 布局,整体结构适合个人技术博客和长文阅读。

  • 顶部菜单包含首页、归档、分类、标签、关于和学习计划。

  • 侧栏保持显示,并开启文章目录,方便阅读长文时快速跳转。

  • 开启深色模式、返回顶部、文章创建/更新时间、分类元信息和代码高亮行号。

  • 外部链接默认在新标签页打开,降低读者跳出当前文章的打断感。

3.3 分类与内容组织

分类 用途 维护建议
文章阅读 用于论文阅读、技术文章阅读和可复用的阅读笔记。 适合放结构化阅读记录,文章标题和标签要尽量清楚。
笔记 用于课程学习、工具使用、概念理解、项目过程记录。 适合沉淀学习过程中的阶段性理解和实践经验。
杂记 用于个人经历、阶段复盘,以及暂时不适合归入前两类的内容。 保持数量可控,后续如果某类内容变多,再拆分为更明确的分类。

当前文章仍统一放在 source/_posts/。项目更推荐用分类、标签和文件名前缀管理内容,而不是频繁移动已发布文章路径;如果未来确实要按目录拆分文章,应先固定 permalink,避免已发布链接发生变化。

3.4 附件管理

  • 图片、PDF、压缩包等附件统一放在 source/uploads/。

  • 文章中使用 /uploads/文件名 的方式引用附件。

  • post_asset_folder 已关闭,新建文章时不会再自动生成每篇文章同名的附件文件夹。

  • 构建后上传资源会输出到 public/uploads/,与文章中的引用路径对应。

4. 搭建过程说明

4.1 初始化与依赖准备

  1. 准备 Node.js 环境,并用 .nvmrc 约定 Node 22,避免本地和部署平台版本不一致。

  2. 安装 Hexo 及相关依赖,包括 Hexo 本体、NexT 主题、Markdown 渲染器、样式渲染器、代码高亮和各类页面生成插件。

  3. 在 package.json 中定义常用脚本:npm run server 用于本地预览,npm run build 用于生成静态文件,npm run clean 用于清理生成结果,npm run deploy 保留给 Hexo 部署命令。

  4. 通过 package-lock.json 锁定依赖版本,降低不同机器安装依赖时出现版本漂移的概率。

4.2 Hexo 站点配置

  • 在 _config.yml 中配置站点名称、副标题、描述、关键词、作者、语言和时区。

  • 设置 source_dir 为 source、public_dir 为 public,使源码内容和构建输出边界清晰。

  • 设置文章固定链接格式,保证文章路径可读、可追踪。

  • 配置首页分页、默认分类、日期格式、代码高亮、订阅源和主题名称。

  • 关闭 post_asset_folder,配合 source/uploads/ 形成统一附件管理规则。

4.3 NexT 主题配置

  • 在 _config.next.yml 中使用 Alternate Theme Config 管理主题,避免直接改动主题包造成升级冲突。

  • 选择 Pisces 布局,并开启深色模式,让页面适合长时间阅读。

  • 配置菜单项、侧栏、文章目录、文章元信息、返回顶部、动效和代码块样式。

  • 保留评论、搜索、统计、图片放大、懒加载等扩展项为关闭状态,当前阶段优先保证博客结构和内容发布稳定。

  • 配置社交入口和版权许可,但文档中不展示任何具体站点 URL。

4.4 内容目录与页面建立

  • source/_posts/ 用于正式文章,source/about/ 用于关于页,source/study-plan/ 用于学习计划页。

  • source/categories/ 和 source/tags/ 用于分类、标签入口页面。

  • scaffolds/ 保留 Hexo 新建页面和文章时使用的模板。

  • themes/ 目录只保留占位文件,实际主题通过 npm 依赖维护,便于依赖管理和升级。

5. 后续更新文章与部署流程

5.1 写文章

  1. 在 source/_posts/ 新建 Markdown 文件,文件名建议使用清晰的英文或拼音前缀,便于后续检索和排序。

  2. 在文件顶部写 front matter,至少包含 title、date、categories、tags。分类优先从“文章阅读”“笔记”“杂记”中选择。

  3. 正文按标题层级组织,长文建议使用二级、三级标题,让 NexT 的文章目录自动生成可用导航。

  4. 如果需要插入图片或附件,先把文件放入 source/uploads/,再在正文中用 /uploads/文件名 引用。

5.2 本地检查

  1. 运行 npm run server,在本地预览文章页面、分类页和标签页。

  2. 重点检查标题、日期、分类、标签、图片路径、代码块和目录跳转是否正常。

  3. 运行 npm run build,确认 Hexo 可以成功生成 public/。

  4. 如修改了附件,检查 public/uploads/ 是否出现对应文件。

  5. 运行 git status,确认改动范围只包含本次要发布的文章、附件或配置。

5.3 提交与发布

  1. 将本次修改加入 Git 暂存区,通常包括 source/_posts/、source/uploads/、必要的配置文件或 README。

  2. 提交时使用能说明内容的 commit message,例如“add new reading note”或“update blog writing guide”。

  3. 推送到 main 分支后,Cloudflare Pages 会按配置自动执行 npm run build。

  4. Cloudflare Pages 的构建目录应保持为 public,Node 版本使用 22 或至少 20.19.0+。

  5. 构建成功后,静态站点会自动发布;如果构建失败,优先检查 Node 版本、依赖安装、front matter 格式和资源路径。

5.4 发布后的维护规则

  • 已经发布过的文章不要随意移动路径;需要调整目录结构时,先固定 permalink。

  • 附件继续统一放入 source/uploads/,不要恢复每篇文章单独附件文件夹的旧流程。

  • 文章变多后,优先通过分类、标签、文件名前缀和学习计划页来增强导航。

  • 每次发布前至少跑一次 npm run build,这是最小但很关键的质量检查。

  • 当文章数量明显增加后,可以再启用本地搜索、图片懒加载、图片放大或阅读进度条等增强功能。

6. 项目结构说明

项目 说明
package.json 定义依赖、Node 版本要求和 build/clean/deploy/server 脚本。
_config.yml Hexo 站点级配置,负责站点信息、目录、文章生成、固定链接、订阅源和主题入口。
_config.next.yml NexT 主题配置,负责布局、菜单、侧栏、文章元信息和扩展功能开关。
source/_posts/ 文章 Markdown 源文件目录。
source/uploads/ 统一附件目录。
source/about/、source/study-plan/ 独立页面内容。
scaffolds/ Hexo 新建文章和页面时使用的模板。
public/ Hexo 构建输出目录,用于静态托管发布,不作为主要源码维护。

7. 后续优化建议

  • 启用本地搜索:文章数量增加后,可以安装并配置本地搜索数据库插件,再在 NexT 中打开 local_search。

  • 完善写作模板:为“文章阅读”“笔记”“杂记”分别准备 front matter 和正文结构模板。

  • 建立发布清单:把本地预览、构建、附件检查、git status、推送后的构建检查写成固定 checklist。

  • 增强阅读体验:根据需要逐步开启图片懒加载、图片放大、阅读进度条等功能。

  • 维护分类克制:短期内保持三类内容体系,等内容量足够后再拆分新分类。

资料依据:当前仓库文件 package.json、README.md、_config.yml、_config.next.yml、source/_posts/、source/uploads/、.nvmrc、.github/dependabot.yml,以及 2026-06-02 本地 npm run build 验证结果。

文档日期: 2026-06-02

项目类型: 前端单页应用;面向淋浴房方案的参数化绘图工具

构建验证: 已执行 npm run build,Vite 生产构建成功

一句话概括
本项目实现了一个在浏览器中运行的淋浴房方案绘图工具:用户可以基于预设或空白方案调整尺寸、添加构件和边框,实时生成等轴透视线稿,并导出 SVG/PNG 供沟通和交付使用。

一、项目概况

项目名称为 shower-plan-drawing-app,页面标题为“淋浴房方案绘图”。项目采用纯前端实现,不依赖后端服务,主要用于快速生成淋浴房方案示意图、调整尺寸参数、对构件进行可视化编辑,并输出可保存或进一步编辑的图纸文件。

从业务定位看,它更像一个轻量级方案草图与沟通工具:不是完整 CAD 系统,但已经具备参数驱动、构件编辑、等轴投影、材料估算和图片导出的核心闭环。

二、技术栈与工具

层次 技术或工具 在项目中的作用
前端框架 React 19.1、React DOM 使用组件和 Hooks 管理页面、方案状态、选中对象、缩放和拖拽交互。
构建工具 Vite 7、@vitejs/plugin-react 提供本地开发、生产构建和 React 编译能力;配置 base: ./ 便于静态部署。
语言与模块 JavaScript / JSX / ES Modules 核心业务逻辑写在 src/main.jsx;依赖中包含 TypeScript,但当前业务源码不是 TS/TSX。
图形渲染 SVG 使用 viewBox、path、line、polygon、rect 等 SVG 元素绘制等轴透视图和可交互对象。
导出能力 XMLSerializer、Blob、URL、Canvas API 将 SVG 序列化为文件;PNG 导出时先把 SVG 绘制到 Canvas,再生成图片下载。
界面样式 CSS Grid、Flexbox、媒体查询 实现顶部工具栏、画布区域、右侧检查器面板和移动端适配。
图标库 lucide-react 用于工具栏、面板标题、导出和缩放等 UI 图标。
静态封装 Node.js fs/path 脚本 scripts/build-static.cjs 会把构建后的 CSS/JS 内联到单个 HTML 文件。

三、已实现的主要功能

功能模块 说明
方案管理 内置“基础方案”“备用方案”等预设;支持新建空白方案、复制当前方案、切换方案和重命名导航标签。
尺寸参数编辑 可调整方案名称、正面宽、侧面深、高度、墙边距等核心参数;输入组件带最小值、最大值和提交校验。
等轴透视绘图 通过 makeGeometry 中的 p(x, y, z) 投影函数,将毫米单位的三维坐标映射为二维 SVG 坐标。
自定义构件 支持玻璃、墙体、拉手、合页四类构件;可编辑类型、平面、坐标、尺寸、角度和显示状态。
自定义边框 支持直线边框和弧形边框;可配置所在平面、长度、角度、半径、位置,并选择是否显示长度标注。
拖拽交互 用户可直接在 SVG 图上选中并拖动构件或边框;拖拽位移会根据对象所在平面转换回三维坐标。
缩放和纸张背景 工具栏提供放大/缩小;画布支持白底和浅灰底两种纸张效果。
导出能力 支持导出 SVG 和 PNG;SVG 导出会嵌入当前页面样式,PNG 使用 2 倍画布尺寸生成。
材料估算 右侧面板显示正面玻璃、侧面玻璃、轨道估长、自定义边框长度和玻璃面积估算。
响应式界面 桌面端采用画布 + 右侧检查器布局;窄屏下检查器自动移动到下方,画布可横向滚动。

四、核心实现结构

1. 数据模型

应用以 schemes 数组作为最外层状态,每个方案包含 id、name、presetKey 和 drawing。drawing 内部保存项目名称、尺寸参数、玻璃厚度、边框颜色,以及 customFrames 和 customParts 两组可编辑对象。

  • customParts 表示玻璃、墙体、拉手、合页等构件,字段包括 type、plane、x/y/z、w/d/h、angle、show。

  • customFrames 表示线性或弧形边框,字段包括 type、plane、x/y/z、length、angle、radius、showLabel。

  • 预设方案通过 buildCustomFrames 和 buildCustomParts 自动生成默认框架、玻璃、墙垛、拉手和合页。

2. 渲染与交互分层

模块 职责
App 页面状态、方案管理、表单面板、导出逻辑和拖拽入口。
IsoScheme 创建等轴投影上下文,并组合构件层与边框层。
CustomPartLayer / CustomPart 按构件类型分发渲染玻璃面、立体墙体、拉手和合页。
CustomFrameLayer / CustomFrame 渲染直线/弧线边框、选中态、命中区域和长度标注。
NumberField / Toggle / Panel 复用表单控件,负责数值输入、开关和右侧面板结构。

3. 几何与投影逻辑

makeGeometry 会先对输入尺寸进行范围限制,再计算 x、y、z 三个方向的缩放比例。核心投影函数 p(x, y, z) 将三维坐标转换为 SVG 平面坐标,从而实现类似工程示意图的等轴透视效果。

拖拽时,dragDeltaFor 会根据对象所在平面分别处理 front、side、floor、box、angled 等场景,把屏幕上的 dx/dy 位移转换为对应的 x/y/z 坐标变化。这样构件在不同平面中拖动时仍能保持合理的空间关系。

五、运行与交付方式

用途 命令 说明
安装依赖 npm install 根据 package-lock.json 安装 Vite、React、lucide-react 等依赖。
本地开发 npm run dev 启动 Vite 开发服务器,默认绑定 127.0.0.1。
生产构建 npm run build 输出 dist/index.html、CSS 和 JS 资源。已验证构建成功。
本地预览 npm run preview 使用 Vite preview 预览生产构建结果。
单文件输出 npm run build:static 先构建,再生成 dist-static/淋浴房方案绘图.html,便于单文件分发。

本次检查已执行 npm run build,构建结果显示 1578 个模块转换完成,CSS 约 9.00 kB,JS 约 225.91 kB(gzip 约 70.72 kB)。

六、项目亮点

  • 业务场景明确:围绕淋浴房方案沟通,把尺寸、玻璃、墙体、拉手、合页和边框编辑集中到一个页面中。

  • 纯前端闭环完整:无需后端即可完成方案编辑、实时绘图、材料估算和图片导出。

  • 图形实现较轻量:没有引入大型 CAD 或 3D 引擎,而是用 SVG 和自定义投影函数完成工程线稿表达。

  • 交互成本低:右侧表单适合精确输入,画布拖拽适合快速调整,二者能同步更新同一份状态。

  • 具备交付意识:支持 SVG 可编辑导出,也支持 PNG 图片交付;另有单 HTML 打包脚本。

七、当前不足与后续优化建议

  • 项目目前没有持久化存储,刷新页面后方案会丢失;可增加 localStorage、JSON 导入/导出或云端保存。

  • 导出的 SVG/PNG 是图形成果,但项目参数本身没有独立文件格式;可设计 .json 项目文件,方便二次编辑。

  • 材料估算偏轻量,当前主要统计玻璃面积和边框长度;可加入五金、轨道、损耗、单价和报价清单。

  • 代码集中在单个 main.jsx 中,后续功能增加后可拆分为 geometry、drawing-model、components、export 等模块。

  • 当前 package.json 没有测试脚本;建议补充几何计算、投影转换、导出逻辑和关键组件的自动化测试。

  • 可增加撤销/重做、对象复制、吸附对齐、图层管理、尺寸标注系统等更接近绘图软件的能力。

八、关键文件说明

文件 作用
src/main.jsx 应用主体:状态管理、方案数据模型、等轴绘图、拖拽交互、导出逻辑和表单控件。
src/styles.css 全局样式、页面布局、画布视觉、面板样式、选中态和响应式适配。
package.json 项目名称、依赖和 npm 脚本定义。
vite.config.js Vite 配置;使用 React 插件,并设置相对路径 base。
scripts/build-static.cjs 读取 dist 中的 HTML/CSS/JS,并生成单个可分发 HTML 文件。
dist-static/淋浴房方案绘图.html build:static 脚本生成的静态交付文件。
assets/concept-shower-planner.png 项目中的概念设计图资产,当前源码未直接引用。

总结

整体来看,这个项目已经完成了一个可运行、可交互、可导出的淋浴房方案绘图原型。它的核心价值在于把尺寸参数、空间构件和方案图输出放在同一个浏览器应用中,适合用于方案初稿、客户沟通和内部确认。后续如果继续迭代,优先建议补齐方案持久化、项目文件导入/导出、报价清单和自动化测试,让它从“方案绘图工具”逐步增强为更完整的轻量设计交付工具。

这是这个博客的第一篇学习总结。

我搭建这个博客,不只是为了记录每天学了什么,更重要的是把学习过程变成可以回顾、可以展示、也可以继续迭代的材料。

为什么开始写

学习大语言模型和 Agent 很容易陷入“看了很多,但沉淀很少”的状态。博客可以帮我做三件事:

  • 记录:保留学习路径和关键资料。
  • 复盘:把理解不清楚的地方写出来,再逐步补齐。
  • 展示:把论文阅读、项目实践和阶段成果整理成作品集。

接下来怎么写

第一阶段先不追求复杂功能,只保证内容能够稳定发布。等文章数量增加后,再逐步优化主题、分类、搜索和阅读体验。

来源:duangxin/LLM-learing week4/week4_log.md

Flamingo: a Visual Language Model for Few-Shot Learning

Flamingo | Alayrac et al., 2022 | 【略读】

阅读重点

  • Flamingo 首次证明 few-shot 多模态 in-context learning 可行。
  • 核心思想是将冻结视觉编码器与冻结 LLM 通过跨注意力机制连接。
  • 由于工程细节和训练成本较高,重点把握它的历史定位,以及“如何把视觉信息高效注入 LLM”的思想。

笔记

  1. Flamingo 想让模型看懂图片或视频,并且只靠几个例子就学会回答新任务。它可以接收图片、视频和文字交错组成的提示,然后生成文字输出。
  2. 它的目标是把大语言模型的上下文学习能力搬到多模态任务里。这里的 few-shot 不只是文本 prompt 里的几个例子,而是图文交错上下文中的示例。
  3. Flamingo 同样冻结视觉编码器和语言模型,但和 BLIP-2 不同,它面向交错图文序列的自回归生成,并在语言模型层中插入跨模态注意力模块,让视觉信息能在多层被使用。
  4. 这篇文章和 BLIP-2 可以形成对照:BLIP-2 更强调用 Q-Former 低成本桥接冻结模型,Flamingo 更强调在 LLM 内部多层注入视觉信息和支持 few-shot 多模态上下文。
  5. Flamingo 使用网页级大规模图文数据,因此容易遇到噪声和不准确标签。它的数据清洗主要依赖基础网页过滤、图像质量过滤、显式内容过滤、部分 benchmark 去重,以及用高质量数据补充 noisy 数据。
  6. 我的质疑是:Flamingo 可以借鉴 BLIP 的 CapFilt 思路进一步清洗数据。用生成器生成更贴近图片内容的 caption,再用过滤器筛掉不匹配样本,可能有助于降低训练成本并提升泛化。

来源:duangxin/LLM-learing week4/week4_log.md

BLIP-2: Bootstrapping Language-Image Pre-training with Frozen Image Encoders and Large Language Models

BLIP-2 | Li et al., 2023 | 【精读】

阅读重点

  • BLIP-2 是连接传统视觉语言预训练与现代 MLLM 的重要桥梁。
  • 核心是 Q-Former:在冻结视觉编码器和冻结 LLM 的前提下,用轻量连接模块实现高效多模态对齐。
  • 重点理解:Q-Former 设计、两阶段训练、冻结大模型带来的成本与性能权衡。

笔记

  1. 传统视觉语言预训练通常需要端到端联合训练大型图像模型和语言模型,成本很高。BLIP-2 的关键思路是利用现成的冻结模型:图像编码器不训练,LLM 也不训练,只训练中间的 Q-Former。
  2. Q-Former 是视觉编码器和 LLM 之间的桥梁。它用一组可学习 query 从冻结视觉编码器输出中提取与语言任务相关的信息,再把这些视觉信息变成语言模型能接收的软提示。
  3. Q-Former 包含两个共享自注意力层的 Transformer 子模块:一个用于和冻结图像编码器交互的视觉 Transformer,一个可以作为文本编码器和解码器的文本 Transformer。
  4. 第一阶段连接 Q-Former 和冻结图像编码器,让 Q-Former 学会从视觉表示中提取有用信息。第二阶段把 Q-Former 接到冻结 LLM 上,通过生成任务训练 Q-Former,让输出成为语言模型可用的视觉提示。
  5. 这篇文章里的“多模态对齐”已经不只是把图像和文本拉到同一个向量空间,而是进一步考虑:视觉表示怎样变成 LLM 可以用于生成的上下文。
  6. 冻结大模型的好处是成本低、训练稳定、复用已有能力;缺点是中间连接模块压力很大,所有跨模态适配几乎都压在 Q-Former 上。
  7. 我的质疑是:Q-Former 第一阶段学习的是图像和文字之间的匹配关系,第二阶段却要求它支持开放生成。两个阶段的目标跨度较大,第一阶段学到的东西可能不完全适合第二阶段。可以考虑增加过渡阶段,让 Q-Former 学习更通用的视觉语义表示。

来源:duangxin/LLM-learing week4/week4_log.md

BLIP: Bootstrapping Language-Image Pre-training for Unified Vision-Language Understanding and Generation

BLIP | Li et al., 2022 | 【略读】

阅读重点

  • BLIP 是视觉语言统一建模的重要过渡工作,核心贡献是通过 bootstrapping 方式清洗和增强图文数据。
  • 它属于“纯视觉语言预训练”时代,和后续“接入 LLM”的 MLLM 范式之间还有一次跳跃。
  • 重点把握 CapFilt 数据清洗的思路与动机。

笔记

  1. 当时视觉语言预训练已经很强,但模型常常偏科:encoder 型模型适合理解和检索,encoder-decoder 型模型更适合生成,单个模型很难同时兼顾两类任务。
  2. 数据侧也有问题。网页 alt-text 和图片配对规模大,但噪声也大;很多网页文本并不是图片内容的准确描述。规模变大带来收益,噪声也被一起放大。
  3. BLIP 提出统一的视觉语言预训练框架,既能迁移到理解任务,也能迁移到生成任务。它要同时解决两个问题:模型架构不统一,以及网络图文对噪声太大。
  4. BLIP 采用 CapFilt 数据增强方法:Captioner 为网络图像生成合成标题,Filter 根据图像-文本匹配损失筛选与图像匹配的高质量标题,从而移除噪声标题。
  5. BLIP 提出 MED(Multimodal Mixture of Encoder-Decoder)。同一个模型可以切换三种功能:单模态编码器用于图文对比学习;图像引导文本编码器用于判断图文是否匹配;图像引导文本解码器用于看图后自回归生成文字。
  6. 从 ALBEF 到 BLIP,可以看到路线从“先对齐再融合”继续走向“理解和生成统一”。这一步很关键,因为后来的 MLLM 不只要判断图文是否匹配,还要能围绕图片生成开放回答。
  7. 我的质疑是:BLIP 的 ITM 是 matched / unmatched 二分类,但图文关系不是非黑即白。有些文本部分匹配,有些对象错了,有些属性错了。ITM 可以进一步升级为更细粒度标签,例如完全匹配、部分匹配、对象错、属性错、关系错。

来源:duangxin/LLM-learing week4/week4_log.md

Align Before Fuse: Vision and Language Representation Learning with Momentum Distillation

ALBEF | Li et al., 2021 | 【略读】

阅读重点

  • ALBEF 提出“先对齐再融合”:先让图像和文本在全局语义上对齐,再用跨模态模块做更深层的融合。
  • 它是图文对齐与深度融合之间的过渡性工作,适合作为理解 BLIP 系列演进逻辑的背景。
  • 重点理解:对比学习、跨模态融合、momentum distillation。

笔记

  1. ALBEF 的直觉是先让模型学会“图片和文字说的是同一件事”,再把两者融合起来做理解任务。多模态对齐就是把图像、文本等不同模态映射到共享空间,让模型能捕捉它们之间的语义关联。
  2. 当时一条主流路线依赖目标检测器提取图像区域特征,再和文本 token 一起送入跨模态 Transformer。这样做的问题是检测器成本高、类别有限,而且会提前压缩视觉信息;海报小字、细微表情、背景关系可能根本没被检测出来。
  3. 另一条路线是 CLIP 这种双塔对比学习。ALBEF 折中处理:先用对比学习做全局图文对齐,再通过轻量融合模块做深度交互。
  4. ALBEF 采用 12 层 ViT 作为视觉编码器,6 层 BERT 作为文本编码器,再加一个 6 层多模态编码器。图文特征在多模态编码器里通过交叉注意力融合,并配合 MLM 和 ITM 等预训练任务。
  5. 动量蒸馏(Momentum Distillation)用于稳定训练。蒸馏的直觉是让学生模型模仿教师模型输出,把较强或较稳定模型里的知识转移给当前模型。
  6. ALBEF 里的教师模型不是单独训练出来的专家,而是学生模型参数的指数移动平均。可以把学生模型理解成“每天变化很大的人”,教师模型是它过去一段时间表现的平滑版本:teacher = m * teacher + (1 - m) * student。
  7. 我的质疑是:ALBEF 认为 one-hot 标签太硬,因为一个 batch 里的其他文本不一定都是真负样本;但 soft label 也可能把本来应该区分开的样本拉近。比如两张图片都包含 “a dog”,一张是狗追球,一张是狗躺在沙发上,teacher 可能因为关键词相似而忽略动作和场景差异。

来源:duangxin/LLM-learing week3/week3_log.md

Learning Transferable Visual Models From Natural Language Supervision

CLIP | Radford et al., 2021 | 【精读】

阅读重点

  • CLIP 通过大规模图文对比学习,把图像和文本映射到统一表示空间。
  • 重点理解:双塔结构、对比学习目标、zero-shot 泛化能力。
  • 读完 CLIP 后可以略读 SigLIP,因为主流 MLLM 的视觉编码器已经逐渐从 CLIP 演进到 SigLIP 等路线。

笔记

  1. CLIP 的输入是图像和文本对,输出是它们在共享空间中的相似度。图像编码器和文本编码器分别得到向量表示,再计算相似度来判断是否匹配。
  2. 对比学习的目标是拉近正样本、推远负样本。对于一个 batch 里的 n 对图文对,正确图文对有 n 个,错误图文对有 $n^2-n$ 个。CLIP 用 softmax 和交叉熵让正确图文对的概率最大。
  3. 余弦相似度用于衡量两个向量方向是否相近,公式是 $\text{Cosine Similarity} = \frac{A \cdot B}{|A| |B|}$。结果越接近 1,表示两个向量越相似。
  4. CLIP 的预训练数据来自互联网收集的 4 亿对图文对,规模非常大。它在很多 benchmark 上表现出很强的 zero-shot 能力,但也需要警惕:预训练数据里可能包含测试集或相似图文对,这会让 zero-shot 的神奇程度打折。
  5. CLIP 和传统图像分类模型的区别是:传统模型通常只会把图片映射到训练集中已有类别,CLIP 学的是视觉概念和语言概念之间的关系。所以见到训练集中没有的新词时,它可以把词语拆解组合来推理。
  6. CLIP 使用 prompt engineering,例如在类别名前加 “a photo of a”,让文本输入更接近自然图文描述,从而提升 zero-shot 泛化。
  7. CLIP 的局限在于,它仍然很难理解深层概念,比如图片中的人是否安全、行为是否危险。继续扩大数据集未必总是现实,后续 SigLIP 通过改进损失函数等方式继续优化。
  8. SigLIP 把 CLIP 中的 softmax 损失改为 sigmoid 损失。CLIP 的 n×n 矩阵更像多分类,SigLIP 则把每个图文对判断为独立二分类,从而简化分布式训练中的损失计算。

来源:duangxin/LLM-learing week3/week3_log.md

An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale

ViT | Dosovitskiy et al., 2020 | 【精读】

阅读重点

  • 视觉 Transformer 的代表作,核心思想是将图像切分为固定大小的 patch,并视作序列输入 Transformer。
  • 重点理解:patch embedding、位置编码、大规模预训练对视觉模型性能的影响。
  • 这是很多后续 MLLM 视觉编码器的起点。

笔记

  1. ViT 主要采用有监督学习。因为 ViT 缺少 CNN 那种先天的视觉归纳偏置,比如局部性和平移等变性,它需要大量带标签数据来学出“哪些 patch 组合起来才是一个物体”。
  2. 这篇论文是 CV 和 NLP 架构统一的重要节点。ViT 证明:只要数据量够大,CV 不一定非要依赖卷积核,也可以直接用 Transformer 这套通用注意力机制。
  3. CNN 的卷积操作有权重、要训练,主要用于提取局部特征;池化操作通常无权重、不训练,主要用于压缩和筛选特征。这个流程天然带有图像局部结构假设,而 ViT 刻意把图像转成序列,让 Transformer 自己学习关系。
  4. Transformer 自注意力复杂度是 $O(n^2)$,直接作用在所有像素上序列太长。因此 ViT 把图片切成 16×16 patch,用牺牲部分细粒度像素关系的方式,让 Transformer 处理图像在算力上变得可行。
  5. 如果输入图片是 224×224,patch 是 16×16,那么图片会被切成 14×14=196 个 patch,再加上一个 [CLS] token,总长度就是 197。
  6. ViT 没有采用平均池化,而是使用 [CLS] token 聚合全局信息。它不代表任何具体 patch,只作为输出位置来代表整张图片做分类。
  7. 平移不变性指目标出现在图像不同位置时,最终分类结果仍然不变;更严格地说,CNN 前面层常体现的是平移等变性,即输入平移后特征图也相应平移。Transformer 如果没有位置编码,更像在处理一个集合,对空间位置并不敏感。
  8. ViT 使用一维位置编码,因为作者没有观察到二维位置编码带来明显提升。虽然图像是二维的,但 patch 被展平为一维序列输入 Transformer,一维位置编码也能学到二维空间结构。
  9. 微调时如果输入图片分辨率更高,patch 数量会增加,位置编码长度就不匹配。ViT 用插值(Interpolation)调整位置编码来适应新的输入尺寸,这种方法简单但实用。
  10. 位置嵌入可视化显示:一维位置编码也学习到了二维空间结构,说明模型训练过程中确实捕捉到了图像的空间关系。

位置嵌入可视化

来源:duangxin/LLM-learing week2/week2_log.md

LLaMA: Open and Efficient Foundation Language Models

LLaMA | Touvron et al., 2023 | 【略读】

阅读重点

  • LLaMA 更贴近开源大模型实践,重点不是提出全新架构,而是在较小参数规模下用更多高质量数据训练出强模型。
  • 理解它的意义:让高性能 LLM 从“只有少数公司能玩”变得更接近研究社区和工程实践。
  • 适合作为后续读 LLaMA 2、LLaMA 3、Qwen、Mistral 等技术报告的背景。

笔记

  1. LLaMA 系列要解决的问题更偏现实工程:在推理预算更低、参数规模相对更小的条件下,通过更多数据和更好的训练配方获得高性能。
  2. 它延续了 decoder-only 自回归范式,这说明 GPT-3 之后的主线并不是频繁换掉核心结构,而是在数据、训练稳定性、注意力实现和推理效率上持续优化。
  3. LLaMA 后续框架常见的优化包括分组查询注意力(Grouped Query Attention)。直觉上,它把 Query 分成多个组共享或复用 Key/Value,从而减少计算量和显存占用,同时尽量保持性能。
  4. pre-normalization 指把 LayerNorm 放在子层前面,而不是子层输出之后。这样做可以让非常深的 Transformer 更稳定,缓解深层训练中的梯度问题。
  5. LayerNorm 会减均值、除以标准差,并带有缩放和偏置:$\text{LN}(x)=\frac{x-\mu}{\sqrt{\sigma^2+\epsilon}},\gamma+\beta$。
  6. RMSNorm 则更简单:$\text{RMSNorm}(x)=\frac{x}{\sqrt{\mathbb{E}[x^2]+\epsilon}},\gamma$。它不减均值,也通常没有偏置,因此计算更轻,在 LLaMA 这类模型里很常见。
  7. 对我来说,LLaMA 这种技术报告的阅读价值在于看“工程取舍”:不是每次都发明新结构,而是在成本、数据、训练稳定性、开源可复现之间找到更好的平衡。
0%