2026-06-07 周报
自然周：2026-06-01 至 2026-06-07
本周主线
这一周的学习主线不是单一项目推进，而是把几个容易混用的技术概念拆清：检索链路里的召回、排序、重排，模型后训练里的 RLHF、DPO、LoRA，以及系统基础设施里的信任模型、虚拟化分层和容器生命周期状态机。
第一条线是“术语背后对应的工程位置”。Embedding、RAG rerank、搜推广精排/重排这些词看起来像翻译问题，实际都要落回它们在链路里的输入、输出和延迟约束。只看字面容易混淆，只看模型名也不够，关键是看这一层解决的是候选规模、排序质量还是业务策略。
第二条线是“抽象边界”。无论是 baoyu 配图 skill 的文件系统交接、Provider 的 duck typing，还是 KVM、Docker 里的状态机，核心都不是把所有层揉在一起，而是让每一层只承担自己能稳定负责的契约。
第三条线是“机制解释要带前置条件”。DPO 相对 RLHF 更简单稳定，但不等于强化学习在所有后训练场景消失；SSH 常见实践依赖 TOFU，但协议本身也支持 host cert；virtio 是半虚拟化 I/O，但通常嵌在 KVM 全虚拟化体系里。很多结论只有带上适用范围才不会误导。
主题一：检索排序链路的术语边界
核心脉络
- 问题起点：最初是在区分 embedding 的中文译名，以及搜推广、RAG 里 ranking、re-ranking、rerank 等相近术语。
- 推进关系：术语混淆的根源不是翻译，而是不同系统的候选规模和延迟预算不同。搜推广面对亿级候选和约 300ms 预算，所以拆出召回、粗排、精排、重排；RAG 候选量通常小得多，常见链路里的 rerank 更接近搜推广精排，而不是策略重排。
- 最终判断：判断一个排序术语时，先看它在漏斗里的位置和主要约束。召回解决“先找一批可能相关的”，粗排解决“替精排减负”，精排解决“模型细算相关性或转化概率”，重排解决“在模型分之后做业务策略干预”。
沉淀认知
- 过程结果分开：embedding 作为结果更适合译作“嵌入向量”或“embedding 向量”，作为过程更适合说“向量化”，因为前者是数据表示，后者是转换动作。
- 漏斗来自预算：搜推广拆成召回、粗排、精排、重排，是候选规模和延迟预算共同逼出来的结构；候选量每降一个数量级，下一层模型才有空间变复杂。
- 粗排保护精排：精排单条候选成本高，不能直接吃召回产出的千级候选；粗排用轻模型先筛到百级或几十级，保证总体延迟可控。
- 重排不是精排：Ranking/精排主要靠模型分排序，Re-ranking/重排主要靠策略干预，例如打散、去重、多样性、广告强插或业务规则兜底。
- RAG rerank 更像精排：RAG 里的 rerank 通常用 Cross-Encoder 对召回候选重新打分，角色更接近搜推广 Fine Ranking；它一般不是搜推广语境里带业务规则的重排。
适用边界
这套映射适合解释搜索、推荐、广告和 RAG 检索增强链路里的层次关系。不要把所有叫 rerank 的步骤都等同于业务重排，也不要把搜推广的四级漏斗机械套到小规模知识库检索上；候选规模、延迟预算和业务策略复杂度不同时，链路层数会不同。
来源
- 2026-06-01：Embedding 术语辨析
- 2026-06-04：搜推广四级漏斗架构
- 2026-06-04：Ranking与Re-ranking的本质区别
- 2026-06-04：搜推广与RAG术语映射
主题二：后训练、DPO 与 LoRA 的不同层次
核心脉络
- 问题起点：本周连续记录了 DPO/RLHF、SFT/RL 学习信号、LoRA 低秩适配，这些都容易被笼统归为“模型训练优化”。
- 推进关系：DPO/RLHF 讨论的是偏好对齐阶段如何使用人类反馈；LoRA 讨论的是微调时如何高效更新参数。前者改变训练目标和信号使用方式，后者改变参数更新的工程实现方式。
- 最终判断：后训练要区分“学什么”和“怎么高效学”。SFT 给标准答案，RLHF 用奖励模型和强化学习试错，DPO 直接从成对偏好中优化；LoRA 则是在底座权重旁训练低秩增量，合并后可以不改变推理结构。
沉淀认知
- SFT给答案：SFT 的学习信号是“应该输出什么”，适合用高质量示例把模型拉到目标风格或任务格式上。
- RLHF给奖励：RLHF 的第二阶段确实使用 PPO 等强化学习算法，模型通过生成、评分、更新的循环强化高奖励行为。
- DPO省掉中间层：DPO 的关键是成对偏好数据本身隐含奖励信号，因此可以跳过奖励模型训练和显式 RL 优化，直接提高偏好回答概率、降低被拒回答概率。
- DPO有适用范围：在通用对话偏好对齐里，DPO 因简单稳定、成本较低，常替代传统 RLHF；但推理模型训练仍可能需要额外强化学习阶段来优化长链路思考行为。
- LoRA改更新不改结构：LoRA 冻结底座权重，只训练低秩矩阵 A/B；合并部署时把增量矩阵加回原权重，推理时结构、速度和内存占用可与普通模型一致。
- 适配器两种交付：单任务、磁盘充足时常合并后部署；多任务共用底座时可以运行时动态加载适配器，用同一个底座切换不同任务能力。
适用边界
DPO/RLHF 的比较适合讨论偏好对齐和后训练策略，不适合替代所有训练范式解释；LoRA 适合解释参数高效微调和部署形态，不等于模型能力来源本身。说 LoRA “推理零额外开销”时，前提是已经 merge；运行时加载多个 adapter 时仍有管理和切换成本。
来源
- 2026-06-04：DPO与RLHF的本质区别
- 2026-06-04：LoRA低秩适配原理
- 2026-06-05：RLHF与DPO的后训练机制
主题三：图片生成 skill 的文件契约与 Provider 边界
核心脉络
- 问题起点：baoyu 配图流程需要让文章分析 skill 和图片生成 skill 协作，但不希望两个 skill 在代码层互相绑定。
- 推进关系：解决方式不是直接互调，而是通过文件系统形成稳定交接：
outline.md负责轻量索引，prompts/*.md负责详细 prompt，batch.json负责执行任务清单。执行层内部再用 ProviderModule 的结构化类型约束各 provider。 - 最终判断：这套架构的核心是“文件契约 + duck typing”。上游只产出可读、可审查、可复用的中间文件；下游只要求 provider 导出签名匹配的函数，并统一把不同 API 响应收敛为
Uint8Array。
沉淀认知
- 文件交接解耦：article-illustrator 和 image-gen 通过文件而不是函数互调协作，使分析层和执行层可以独立演进。
- 索引不塞正文：
outline.md只记录图片索引和文件名，prompt 详情放在独立文件里，能让批处理构建逻辑保持简单。 - 转换器归执行层：
build-batch.ts本质是把文件约定转换成批量执行任务，属于 image-gen 执行层配套，而不是文章分析层职责。 - Provider零仪式扩展：Provider 不需要显式
implements interface，只要导出getDefaultModel()和generateImage()这类签名匹配的函数即可接入。 - 返回值统一收敛：provider 自己处理 base64、URL 下载或 API 差异，最终统一交给调度层
Uint8Array，避免 main.ts 被上游响应格式污染。
适用边界
这种设计适合多工具协作、产物需要人工审查、provider 可能频繁变化的流水线。若上下游必须同步事务执行，或者中间产物没有复用和审查价值，文件系统解耦可能会增加额外复杂度。
来源
- 2026-06-04：baoyu 配图 Skill 协作架构
- 2026-06-04：Provider 鸭子类型契约
主题四：SSH 信任模型与密钥工程权衡
核心脉络
- 问题起点：学习 SSH known_hosts 时，需要解释它为什么不像 HTTPS 那样默认依赖 CA 证书链。
- 推进关系：SSH 常见工程实践使用 TOFU：首次连接记录主机公钥，后续连接比对是否变化。它牺牲了首次连接时的强验证，换来简单、无需第三方 CA 的部署模型。若担心首次连接被中间人攻击，可以借助 HTTPS 官方指纹做交叉验证。
- 最终判断：SSH 的默认信任路径是“首次看到即信任，之后检测变化”；HTTPS 的默认信任路径是“CA 链先证明身份”。两者不是谁更高级，而是信任锚和部署复杂度不同。
沉淀认知
- TOFU信首次：SSH 常见 known_hosts 模型完全信任首次收到的主机公钥，之后一旦变化就报警，因此首次连接是主要风险窗口。
- HTTPS可交叉验证：可以通过 HTTPS 访问官方 SSH 指纹，再用
ssh-keygen -lf计算本地指纹对比，把 HTTPS CA 信任链转化为 SSH 公钥校验依据。 - 协议实践分开：SSH 协议本身支持 CA 签发 host cert，但普通开发环境里更常见的是 known_hosts 的 TOFU 模型。
- 短密钥不等于弱安全：Ed25519 公钥短，是算法编码和曲线设计带来的工程优势；它的安全强度不能用字符串长度直接和 RSA 公钥比较。
适用边界
TOFU 解释适合普通 SSH 客户端首次连接、known_hosts 校验和 GitHub host key 验证。大型组织内部如果启用了 SSH host certificate 或集中主机密钥管理，就不能只按普通 TOFU 流程理解。
来源
- 2026-06-05：SSH TOFU 信任模型与 CA 证书体系的差异
- 2026-06-05：Ed25519 密钥长度的工程原因
主题五：虚拟化与容器生命周期的分层状态机
核心脉络
- 问题起点：本周系统侧问题集中在“谁在控制谁”：CPU 如何进入 Guest、KVM 什么时候能介入、Linux scheduler 是否理解 VM、Docker 为什么能区分手动停止和异常退出。
- 推进关系：这些问题的共同答案是分层状态机。CPU 每个核心有自己的执行上下文和 current VMCS；KVM 只在 vCPU 线程运行时加载 VMCS，并在 VM Exit 后重新获得控制；Linux scheduler 只调度 vCPU 线程，不理解 Guest OS；Docker/containerd 用 DesiredState 和生命周期路径区分人工 stop 与异常退出。
- 最终判断：系统机制不能只看最终现象。要问控制权当前在哪一层、状态标记什么时候写入、下一层能看到什么。很多“为什么不会重启”“为什么 KVM 不能随时切 VM”的答案都藏在状态转换顺序里。
沉淀认知
- VMCS预加载执行：
VMLAUNCH/VMRESUME不通过指令参数传 VMCS，而是隐式使用当前 CPU 已VMPTRLD加载的 VMCS，便于 CPU 缓存和优化 VM Entry。 - VMExit是控制权边界：Guest 运行时 KVM 不在执行路径上，只有 VM Exit 后 CPU 才把控制权交回 KVM；因此减少 VM Exit 是虚拟化性能优化重点。
- 调度器只看线程：Linux scheduler 调度的是 vCPU 对应的
task_struct，不感知 VM、VMCS 或 Guest OS；VM 切换最终表现为 vCPU 线程切换。 - virtio只改IO层：virtio 是半虚拟化 I/O，用 virtqueue 共享内存减少设备模拟开销；KVM 体系通常是 VT-x/AMD-V 全虚拟化 CPU + virtio/SR-IOV 等 I/O 加速的混合方案。
- 云厂商走混合分层：AWS Nitro、Azure Hyper-V、阿里云 KVM+神龙这类实践，趋势是 CPU 虚拟化硬件支持、控制层变轻、I/O 尽量 offload。
- 退出码不是状态机：Docker 重启策略不只看退出码，因为正常退出、外部 SIGTERM 和手动 stop 可能产生相似退出码；关键是 DesiredState 和是否经过 Stopping 路径。
- 先标记再发信号：
docker stop先把 DesiredState 改为 Stopped，再发 SIGTERM；容器退出后重启判断看到的是“期望停止”，因此不会触发重启策略。
适用边界
这些结论适合解释 KVM/VT-x、virtio、云主机虚拟化和 Docker 重启策略的常见机制。具体实现细节会随内核版本、hypervisor、container runtime 或桌面兼容层变化；讨论性能瓶颈时也要区分 CPU 虚拟化、内存虚拟化和 I/O 虚拟化。
来源
- 2026-06-05：VT-x 硬件虚拟化核心机制
- 2026-06-05：KVM 与 Linux 调度器的分层协作
- 2026-06-05：虚拟化技术分类与云厂商实践
- 2026-06-05：Docker 重启策略机制
其他杂项
- 无。本周日报 topic 都已并入上述主题，没有需要单独保留但无法归类的素材。
修正报告
- TOFU拼写修正：2026-06-05 日报中有一处写成
TTFU，正文统一修正为TOFU。原意是 Trust On First Use，修正理由是避免把信任模型术语写错。 - DPO替代范围收口：日报中“DPO 取代 RLHF 成为后训练主流”的说法容易被理解为所有后训练都不再需要 RL。周报正文收口为：在通用对话偏好对齐中，DPO 常替代传统 RLHF；但推理模型训练仍可能需要额外 RL 阶段。来源涉及 2026-06-04 与 2026-06-05 的 DPO/RLHF 记录。