20260706:新增一些文章
This commit is contained in:
89
articles/agents-want-filesystems-nokv-2026.md
Normal file
89
articles/agents-want-filesystems-nokv-2026.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
title: "Agents Want Filesystems：为什么文件系统形态的接口让 Agent 更高效"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: article
|
||||||
|
tags: [agent, filesystem, interface, token-efficiency, workspace, nokv]
|
||||||
|
source: "新智元"
|
||||||
|
url: "https://mp.weixin.qq.com/s/VdjhAzjmdAkL-aHRGiEUHw"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agents Want Filesystems：为什么文件系统形态的接口让 Agent 更高效
|
||||||
|
|
||||||
|
> 新智元 · 2026-07 · [原始存档](raw/articles/xinzhiyuan-agents-want-filesystems-2026.md) · [源博客](https://nokv.io/blog/agents-want-filesystems)
|
||||||
|
|
||||||
|
## 核心观点
|
||||||
|
|
||||||
|
NoKV 团队通过 100 次独立运行的 benchmark 证明：**给 Agent 提供文件系统形态的 namespace 接口（而非原生 SQL），可减少 45% token 消耗、39% 成本，且正确率略高。**
|
||||||
|
|
||||||
|
核心洞察：决定 Agent 效率的变量不只有模型和提示词，还包括 Agent 面对的操作界面（Interface/Surface）。
|
||||||
|
|
||||||
|
## 为什么文件系统语义对 LLM 友好
|
||||||
|
|
||||||
|
LLM 在训练中被反复暴露于 shell、Unix 工具、Git、日志排查等语料中，学到一套稳定模式：**进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用行号**。
|
||||||
|
|
||||||
|
文件系统提供 **progressive disclosure**（[[progressive-disclosure|渐进式披露]]）交互方式：
|
||||||
|
1. 先低成本发现：`ls` 看有什么，`stat` 看对象卡片，`catalog` 看可查询字段
|
||||||
|
2. 再按需读取：只有找到目标后才 `read` 打开内容
|
||||||
|
3. 搜索可限定范围：全局 `grep` 发现 + 目录内 `grep` 提取证据
|
||||||
|
4. 路径是稳定句柄：`/runs/abc/stdout.log` 既是名字也是地址
|
||||||
|
|
||||||
|
## 实验设计
|
||||||
|
|
||||||
|
- **数据**：875 个 Yanex 训练 run，80.6 万行指标，包含元数据、参数、artifact、git 状态、stdout/stderr
|
||||||
|
- **模型**：GPT-5.4-mini，100 次独立 stateless 运行
|
||||||
|
- **两种接口**：
|
||||||
|
- `sqlite_raw_v1`：原生 SQL + blob 读取 + `grep_blob`
|
||||||
|
- `nokv_native_v1`：NoKV namespace（`ls`/`stat`/`catalog`/`find`/`aggregate`/`read`/`grep`）
|
||||||
|
|
||||||
|
## 三类任务的结果
|
||||||
|
|
||||||
|
| 任务类型 | SQL Token | NoKV Token | 关键差异 |
|
||||||
|
|---------|-----------|------------|---------|
|
||||||
|
| 简单结构化查询 | **4.8k** | 9.3k | SQL 仍然更强 |
|
||||||
|
| 复合探索（扫参/溯源/分诊） | 127.4k | **53.3k** | NoKV 2.39× 更低 |
|
||||||
|
| 总体 | — | — | **-45% token, -39% cost** |
|
||||||
|
|
||||||
|
SQL 在简单结构化聚合上更强；NoKV 在需要「先定位 cohort → 再查日志 → 再引用证据」的复合探索任务上大幅领先。
|
||||||
|
|
||||||
|
## 减少的不只是 token，也是「心智负担」
|
||||||
|
|
||||||
|
更深层次：NoKV 减少了 Agent 的内部 reasoning token——模型不需要在每轮工具调用中重建「数据在哪」的临时地图。
|
||||||
|
|
||||||
|
- **[[attention-drifting|注意力偏移]]**：上下文塞进太多 schema 和无关日志时，模型容易被早期错误线索带偏
|
||||||
|
- **[[pushdown-in-agent-interface|下推]]**：过滤、排序、limit、投影放进一次调用，减少对话轮数和上下文回灌
|
||||||
|
|
||||||
|
## 架构定位
|
||||||
|
|
||||||
|
不是「文件系统替代数据库」，而是**两层架构**：
|
||||||
|
- **底层**：数据库、对象存储、API（可靠性、事务、持久化）
|
||||||
|
- **上层**：元数据控制层（路径、版本、权限、索引 → Agent-friendly namespace）
|
||||||
|
|
||||||
|
NoKV（[[nokv]]）就是这层上层。
|
||||||
|
|
||||||
|
## 应用场景：artifact-heavy agentic 系统
|
||||||
|
|
||||||
|
任何 Agent 系统高度依赖大量文件、日志、报告、模型、checkpoint 等外部产物时，都会遇到这个问题：
|
||||||
|
- 实验追踪与观测
|
||||||
|
- 法律咨询（合同、判例、尽调材料）
|
||||||
|
- 数据分析（notebook、CSV、图表交叉引用）
|
||||||
|
- 研发 Agent（issue、PR、日志、CI 结果）
|
||||||
|
- 多 Agent 协作（共享中间产物、锁定版本、监听更新）
|
||||||
|
|
||||||
|
## 外部佐证
|
||||||
|
|
||||||
|
- **Anthropic MCP code execution**：工具呈现为 TypeScript 文件树，代表性负载从 150k token → 2k token
|
||||||
|
- **OpenAI tool search**：建议把延迟加载工具组织到 namespace 或 MCP server
|
||||||
|
- **Letta memory benchmark**：对话历史保存为文件的 Agent 在 LoCoMo 上取得有竞争力结果
|
||||||
|
|
||||||
|
## 核心概念
|
||||||
|
|
||||||
|
- [[agent-workspace-filesystem|Agent 工作空间文件系统]]
|
||||||
|
- [[progressive-disclosure|渐进式披露]]
|
||||||
|
- [[attention-drifting|注意力偏移]]
|
||||||
|
- [[pushdown-in-agent-interface|Agent 接口下推]]
|
||||||
|
- [[artifact-heavy-agentic-systems|产物密集型 Agent 系统]]
|
||||||
|
- [[agent-interface-design|Agent 接口设计]]
|
||||||
|
- [[nokv|NoKV]]
|
||||||
|
- [[token-efficiency|Token 效率]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
83
articles/prompt-to-loop-engineering-2026.md
Normal file
83
articles/prompt-to-loop-engineering-2026.md
Normal file
@@ -0,0 +1,83 @@
|
|||||||
|
---
|
||||||
|
title: "AI 开发范式演进：从 Prompt Engineering 到 Loop Engineering"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: article
|
||||||
|
tags: [prompt-engineering, context-engineering, harness-engineering, loop-engineering, agent, paradigm-evolution]
|
||||||
|
sources: [https://mp.weixin.qq.com/s/hcgKahtQRE2QqI6xplv2Rg]
|
||||||
|
authors: ["邱汉宸（东南大学、阿里淘天）"]
|
||||||
|
platform: Datawhale
|
||||||
|
---
|
||||||
|
|
||||||
|
# AI 开发范式演进：从 Prompt Engineering 到 Loop Engineering
|
||||||
|
|
||||||
|
> 来源：[Datawhale 公众号](https://mp.weixin.qq.com/s/hcgKahtQRE2QqI6xplv2Rg)，作者：邱汉宸
|
||||||
|
|
||||||
|
## 一句话
|
||||||
|
|
||||||
|
系统性复盘 AI 开发范式的四次浪潮：**Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering**，揭示人类从 Agent 循环内部走向外部、从执行者变为设计者的范式迁移。
|
||||||
|
|
||||||
|
## 核心命题
|
||||||
|
|
||||||
|
2025–2026 年三句话引爆 AI 社区：
|
||||||
|
- "I really like the term 'context engineering' over prompt engineering." — Tobi Lütke, Shopify CEO
|
||||||
|
- "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." — Peter Steinberger, OpenClaw
|
||||||
|
- "I don't prompt Claude anymore. I have loops running. My job is to write loops." — Boris Cherny, Claude Code
|
||||||
|
|
||||||
|
## 四次浪潮
|
||||||
|
|
||||||
|
### 1. [[prompt-engineering|Prompt Engineering]]（2022–2024）
|
||||||
|
"如何跟 AI 沟通"。核心方法论：Zero-shot/Few-shot、Instruction Prompting、[[dspy|DSPy]] 声明式自动编译。瓶颈：上下文窗口限制、缺乏记忆/工具调用、[[blind-prompting|盲提示]] 带来的技术债务。
|
||||||
|
|
||||||
|
### 2. [[context-engineering|Context Engineering]]（2025）
|
||||||
|
"信息怎么喂给模型"。三大方法论：
|
||||||
|
- [[minimum-viable-context|轻量化装配 (MVC)]]
|
||||||
|
- [[graphrag|知识图谱增强检索 (GraphRAG)]]
|
||||||
|
- [[just-in-time-retrieval|即时检索 (JIT Retrieval)]]
|
||||||
|
|
||||||
|
三种故障模式：[[context-failure-modes|信息匮乏 / 信息过载 / 上下文腐烂]]。关键隐性维度：[[prefix-matching-invariant|前缀匹配不变性]] 与 [[prompt-caching|提示词缓存]] 的成本经济学。
|
||||||
|
|
||||||
|
### 3. [[harness-engineering|Harness Engineering]]（2026–）
|
||||||
|
"Agent = Model + Harness"。四大支柱：环境资产与工具集、控制与编排逻辑、规则中间件（Hooks）、运行时可观测性。八条[[model-proposes-harness-executes|非妥协原则]]。DataTalks.Club 事故案例：Claude Code 执行 `terraform destroy` 抹除生产数据库 — 问题不在模型，在 Harness 缺位。
|
||||||
|
|
||||||
|
### 4. [[loop-engineering|Loop Engineering]]（2026–）
|
||||||
|
"Loop = Cron + 决策器"。系统从人类单次触发的工具演进为具备独立运行周期的自主工程。[[loop-maturity-levels|三级成熟度]]：Open Loop → Closed Loop → Review Loop。核心组件 "五件套 + 一个记忆"：Automations / Worktrees / Skills / Connectors ([[mcp|MCP]]) / Sub-agents / State 文件。
|
||||||
|
|
||||||
|
## 核心框架
|
||||||
|
|
||||||
|
### Loop Contract（[[loop-contract|循环协议]]）
|
||||||
|
六维约束：TRIGGER / SCOPE / ACTION / BUDGET / STOP / REPORT。BUDGET 和 STOP 固化为 [[circuit-breaker-pattern|熔断器]] 和 [[watchdog-pattern|看门狗]] 两道硬约束。
|
||||||
|
|
||||||
|
### 嵌套关系
|
||||||
|
> Prompt ⊂ Context ⊂ Harness ⊂ Loop
|
||||||
|
|
||||||
|
### 架构哲学
|
||||||
|
[[mechanism-policy-separation|机制与策略分离]] — 底层平台提供机制（定时器、工作区隔离），控制策略由架构师独立配置。
|
||||||
|
|
||||||
|
## 工程实践
|
||||||
|
|
||||||
|
- **[[harness-as-a-service|HaaS（脚手架即服务）]]**：Worktree + Skills + Connector + Subagent + State 封装为标准底座
|
||||||
|
- **[[skill-issue-framework|Skill Issue 框架]]**（CodeRabbit）：当 Agent 表现不佳，排查 Harness 代码而非责怪模型
|
||||||
|
- **分层拦截流水线**：确定性规则层（Semgrep）→ 策略网关层（OPA）→ AI 审查层 → 人类终审（80%/15%/5%）
|
||||||
|
|
||||||
|
## 人类角色转变
|
||||||
|
|
||||||
|
开发者进化为 **[[loop-designer|Loop Designer（循环设计师）]]**，聚焦三件事：
|
||||||
|
1. 定义终止边界（Goal & Verifier）
|
||||||
|
2. 维护工具链与领域资产（Tooling & Skill）
|
||||||
|
3. 设计安全断路器（Human-in-the-Loop & Budget Guard）
|
||||||
|
|
||||||
|
## 关键引用
|
||||||
|
|
||||||
|
- Terminal Bench 2.0 实证：不改模型权重，仅改写 Harness 约束使排名从 30 → 前五
|
||||||
|
- 缓存经济学：同一前缀命中第 3 次即可净收益（首次 100% 计费，后续 20%）
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[prompt-to-harness-evolution|三阶段工程演进]] — 需扩展为四阶段
|
||||||
|
- [[agent-harness|Agent Harness (Claw)]]
|
||||||
|
- [[harness-engineering]]
|
||||||
|
- [[context-engineering]]
|
||||||
|
- [[prompt-caching]]
|
||||||
|
- [[human-in-the-loop]]
|
||||||
|
- [[mcp]]
|
||||||
61
articles/real-world-safe-exploration-see-2026.md
Normal file
61
articles/real-world-safe-exploration-see-2026.md
Normal file
@@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: "真机强化学习的安全探索均衡 — 机器之心报道"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: article
|
||||||
|
tags: [safe-reinforcement-learning, safe-exploration, real-world-rl, embodied-intelligence]
|
||||||
|
sources: [https://mp.weixin.qq.com/s/nE9gq1bStIg1qhWpIRvQHQ]
|
||||||
|
authors: ["机器之心 / 数据派THU"]
|
||||||
|
platform: 数据派THU
|
||||||
|
---
|
||||||
|
|
||||||
|
# 真机强化学习的安全探索均衡
|
||||||
|
|
||||||
|
> 来源：[机器之心 / 数据派THU](https://mp.weixin.qq.com/s/nE9gq1bStIg1qhWpIRvQHQ)，论文原文：[[safe-equilibrium-exploration|IEEE TPAMI 2026]]
|
||||||
|
|
||||||
|
## 一句话
|
||||||
|
|
||||||
|
对清华大学李升波教授团队 SEE 论文的中文科普解读：首次揭示 [[safe-exploration|安全探索]] 的理论收敛边界——可行域与不确定模型的[[equilibrium-safe-exploration|均衡]]，并给出单调收敛的严格证明。
|
||||||
|
|
||||||
|
## 核心故事
|
||||||
|
|
||||||
|
### 问题：真机 RL 没有"重来"按钮
|
||||||
|
|
||||||
|
[[real-world-rl|真机强化学习]] 与仿真训练的本质区别：物理世界不允许无限试错。无限制探索 → 机器损坏 / 人员伤亡。
|
||||||
|
|
||||||
|
### 主流思路：步步为营
|
||||||
|
|
||||||
|
将探索限制在 [[feasible-zone|可行区域]] 内 → 收集数据 → 降低[[uncertain-model|模型不确定性]] → 扩展可行区域 → 循环。
|
||||||
|
|
||||||
|
### 悬而未决的问题
|
||||||
|
|
||||||
|
这个"滚雪球"过程**会不会收敛？收敛到哪里？理论上能探索多大？**
|
||||||
|
|
||||||
|
- Andreas Krause (ETH): Lyapunov 函数 + 高斯过程
|
||||||
|
- Claire Tomlin (Berkeley): HJ 可达性分析
|
||||||
|
|
||||||
|
但收敛性始终未解决。
|
||||||
|
|
||||||
|
### 清华的答案：安全探索均衡
|
||||||
|
|
||||||
|
[[safe-equilibrium-exploration|SEE 算法]] 两步交替：
|
||||||
|
|
||||||
|
1. **求区域**：固定模型，求解 [[risky-bellman-equation|风险贝尔曼方程]]，得最大可行域
|
||||||
|
2. **求模型**：固定区域，将最小不确定模型问题转化为 [[clique-decision-problem|团判定问题]]
|
||||||
|
|
||||||
|
理论保证：模型误差**单调减小**，可行域**单调扩展**，必然收敛到均衡。
|
||||||
|
|
||||||
|
### 实验结果
|
||||||
|
|
||||||
|
- 双积分器、倒立摆、独轮车三类任务
|
||||||
|
- **零约束违反**
|
||||||
|
- 独轮车仅 10 次迭代即达 95.78% 区域召回率
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[safe-equilibrium-exploration|SEE 论文]]
|
||||||
|
- [[safe-exploration|安全探索]]
|
||||||
|
- [[feasible-zone|可行域]]
|
||||||
|
- [[equilibrium-safe-exploration|安全探索均衡]]
|
||||||
|
- [[real-world-rl|真机强化学习]]
|
||||||
|
- [[risky-bellman-equation|风险贝尔曼方程]]
|
||||||
66
articles/semantic-robustness-cert-vlm-report-2026.md
Normal file
66
articles/semantic-robustness-cert-vlm-report-2026.md
Normal file
@@ -0,0 +1,66 @@
|
|||||||
|
---
|
||||||
|
title: "面向视觉语言模型的语义鲁棒性认证：用文本提示刻画可证的语义变化区间"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: article
|
||||||
|
tags: [vlm, certification, semantics, robustness, icml-2026, chinese-report]
|
||||||
|
source: "数据派THU / 专知"
|
||||||
|
url: "https://mp.weixin.qq.com/s/HupoMpofsk5Ltx2RoCdAGQ"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 面向视觉语言模型的语义鲁棒性认证
|
||||||
|
|
||||||
|
> 数据派THU · 2026-07 · [原始存档](raw/articles/data-pie-vlm-semantic-cert-2026.md)
|
||||||
|
|
||||||
|
## 核心概述
|
||||||
|
|
||||||
|
ICML 2026 论文 [[semantic-robustness-certification-vlm-2026|Semantic Robustness Certification for Vision-Language Models]] 的中文科普报道。核心思想：利用 VLM 的开放词表能力，把文本提示作为语义代理，用一对 source/target prompt 在图文共享嵌入空间中定义语义变化方向；再利用 VLM 分类器决策边界的闭式几何结构，精确计算预测类别保持不变的 semantic extent interval。
|
||||||
|
|
||||||
|
## 方法直觉
|
||||||
|
|
||||||
|
- **问题**：图像发生语义变化（形状、风格、背景等）时，VLM 预测何时翻转？
|
||||||
|
- **传统方法局限**：像素扰动不能表达"更圆""更暗""像素描风"等语义变化
|
||||||
|
- **本文方案**：不采样图像，而是在 VLM **嵌入几何**中解析计算预测不变区间
|
||||||
|
|
||||||
|
## 三步框架
|
||||||
|
|
||||||
|
1. **语义平面**：一对文本 prompt 的嵌入 $u_a, u_{a'}$ 张成二维子空间 $P_{a,a'}$
|
||||||
|
2. **语义变换**：图像嵌入分解为 $z_\parallel$（语义相关）+ $z_\perp$（语义无关），只变 $\varphi$ 控制语义强度
|
||||||
|
3. **闭式认证**：VLM 的 Voronoi 决策边界给出闭式的类别翻转方程 → 排序 → 区间切分
|
||||||
|
|
||||||
|
## 应用场景
|
||||||
|
|
||||||
|
- 鲁棒性审计：指定语义方向，检查 VLM 稳定性
|
||||||
|
- Failure mode 诊断：证书区间短 → 模型对该语义敏感
|
||||||
|
- Prompt engineering：不同 prompt 产生不同稳定区间，证书长度可作为选择标准
|
||||||
|
- 下游任务复用：检索、检测、分割等共享同一 scoring mechanism
|
||||||
|
|
||||||
|
## 限制
|
||||||
|
|
||||||
|
- 证书依赖文本代理质量和跨模态对齐程度
|
||||||
|
- 真实世界语义变化难以完全隔离（非目标因素可能混杂）
|
||||||
|
|
||||||
|
## 核心概念
|
||||||
|
|
||||||
|
- [[semantic-robustness-certification|语义鲁棒性认证]]
|
||||||
|
- [[semantic-extent|语义 extent]]
|
||||||
|
- [[text-proxy-for-semantics|文本语义代理]]
|
||||||
|
- [[semantic-plane|语义平面]]
|
||||||
|
- [[prediction-invariant-intervals|预测不变区间]]
|
||||||
|
- [[voronoi-decision-regions|Voronoi 决策区域]]
|
||||||
|
- [[misalignment-budget|不对齐预算]]
|
||||||
|
- [[additive-semantics|加性语义]]
|
||||||
|
|
||||||
|
## 基底概念
|
||||||
|
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[robustness-certification|鲁棒性认证]]
|
||||||
|
- [[dual-encoder-vlm|双编码器 VLM]]
|
||||||
|
- [[clip|CLIP]]
|
||||||
|
- [[cosine-similarity-geometry|余弦相似度几何]]
|
||||||
|
- [[randomized-smoothing|随机平滑]]
|
||||||
|
- [[exactline|ExactLine]]
|
||||||
|
|
||||||
|
## 论文原文
|
||||||
|
|
||||||
|
- [[semantic-robustness-certification-vlm-2026|Semantic Robustness Certification for Vision-Language Models (ICML 2026)]]
|
||||||
83
articles/zleap-workspace-harness-2026.md
Normal file
83
articles/zleap-workspace-harness-2026.md
Normal file
@@ -0,0 +1,83 @@
|
|||||||
|
---
|
||||||
|
title: "Zleap-Agent：Workspace-first 的 Agent Harness 设计"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: article
|
||||||
|
tags: ["agent", "harness", "workspace", "memory", "context-management", "local-model"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Zleap-Agent：Workspace-first 的 Agent Harness 设计
|
||||||
|
|
||||||
|
> 作者：陈思州 (Datawhale) | 来源：[原始存档](raw/articles/zleap-workspace-harness-2026.md) | 代码仓库：[Zleap-AI/Zleap-Agent](https://github.com/Zleap-AI/Zleap-Agent)
|
||||||
|
|
||||||
|
## 核心命题
|
||||||
|
|
||||||
|
Agent 圈正经历从 **Prompt Engineering** → **Loop Engineering** → **Harness Engineering** 的范式演进。单轮提示词已不够用，接下来要处理的是「循环怎么跑、系统怎么撑住这些循环」。Zleap-Agent 提供了一套以 **[[workspace-first-architecture|Workspace-first]]** 为核心的 Harness 设计方案——专为本地小模型设计的 Agent 执行骨架。
|
||||||
|
|
||||||
|
## 核心思想：Workspace-first
|
||||||
|
|
||||||
|
```
|
||||||
|
不要先问 Agent 能接多少工具，而是先问当前任务应该发生在哪个工作区。
|
||||||
|
```
|
||||||
|
|
||||||
|
写代码、查资料、处理文件、做销售复盘——本来就不应该共享同一个上下文空间。Zleap 的解法是把 Agent 运行环境切成不同工作区，每个工作区有自己的 prompt、tools、memory、history、model 和 permission。Agent 进入哪个 Workspace，就只加载当前工作区需要的内容。
|
||||||
|
|
||||||
|
**Workspace vs 子 Agent vs 工具分组**：子 Agent 是临时找人帮忙（有独立角色和上下文），Workspace 是同一个人切换工作台（软件、资料、工具变了，但人没变），工具分组只是工具层面的归类。
|
||||||
|
|
||||||
|
## 五维度 Harness 设计
|
||||||
|
|
||||||
|
### 1. Context：上下文装配
|
||||||
|
|
||||||
|
Context = System Prompt + Workspace Prompt + Tools + Memory + History
|
||||||
|
|
||||||
|
Main Workspace 只做调度，不承载所有上下文。进入具体 Workspace 后，模型只看到当前工作区的 prompt、工具、记忆和历史。Harness 提前把信息范围收窄，而非靠模型在长上下文里自行筛选。
|
||||||
|
|
||||||
|
加载方式分两层：[[context-prefetch-vs-agentic|Prefetch（提前带入）vs Agentic（按需读取）]]。Prefetch 要短、准、可控（用户偏好、工作区最新事件、常用经验）；Agentic 是模型看到摘要后追问详情时再读取完整内容。
|
||||||
|
|
||||||
|
### 2. Tools：工具-工作区绑定
|
||||||
|
|
||||||
|
[[tool-workspace-binding|工具不再全局暴露]]——Main Workspace 只保留调度/记忆/交付工具，CLI Workspace 才能读写文件、执行命令，Web Search Workspace 才能搜索网页。模型在每个空间里只面对一组更小、更明确的动作集合，tool schema 成本、误调用概率和权限审计压力都下降。
|
||||||
|
|
||||||
|
### 3. Memory：记忆三分区
|
||||||
|
|
||||||
|
记忆被分成两条线：A 线 **people notes**（用户偏好、稳定画像）和 B 线 **core records**（工作事件 + 可复用经验）。本质上是一种 [[memory-tripartite-partition|人/事/经验三分区]]——用户偏好绑定人，项目事实绑定工作区和客户，可复用方法脱敏后共享。
|
||||||
|
|
||||||
|
- **[[memory-dream|Memory Dream]]**：离线记忆整理器，不在实时对话里抢上下文，而是在后台从会话材料中提取稳定画像和可复用经验
|
||||||
|
- **[[memory-recall-fast-slow|快慢召回]]**：prefetch 用 fast 模式（不走 LLM），主动 recall 走精细检索和 rerank
|
||||||
|
- 经验记忆准入规则：只记录可复用流程、失败模式、验证习惯和恢复策略；业务隐私和临时事实不入经验库
|
||||||
|
- **reconcile 机制**：新记忆入库时与旧记忆比对，判断跳过 / 并存 / 替换 / 保留旧记忆
|
||||||
|
|
||||||
|
引用了 [[channel-fracture|Hermes Agent Channel Fracture]] 案例——记忆写入需验证完整通道，不能只看"有没有存储"。
|
||||||
|
|
||||||
|
### 4. Runtime：运行轨迹持久化
|
||||||
|
|
||||||
|
[[agent-runtime-trace|每次循环都留下可复盘的轨迹]]——运行状态和记忆共用 PostgreSQL 持久化。出问题时可以倒回去看某一步读了什么、调了什么工具、拿到什么结果。对应的实验证据：WildClawBench 中同一模型切换 harness 表现差 18 个百分点，Agentic Harness Engineering 实验通过 harness 演化使 Terminal-Bench 2 pass@1 从 69.7% 提升到 77.0%。
|
||||||
|
|
||||||
|
### 5. Boundary：边界控制
|
||||||
|
|
||||||
|
[[agent-boundary-design|数据边界、工具边界、模型边界、记忆边界]]——企业场景中数据不能随便出内网，记忆不能在用户之间串。Zleap 的 Workspace 设计天然支持 [[multi-model-routing|多模型路由]]：不同工作区可绑定不同模型，敏感数据走本地模型，复杂分析走强模型，同时控制成本、延迟和数据边界。
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
> 「模型层做稀疏注意力，是为了让模型不要看所有 token；Harness 层做 Workspace，是为了让 Agent 不要加载所有上下文。」
|
||||||
|
|
||||||
|
Workspace-first 是一个可以脱离 Zleap-Agent 单独使用的设计范式：不管用什么模型、什么框架，先切工作区、再组装上下文，都是一个值得参考的起点。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[harness-engineering|Harness Engineering]] — 学科定位
|
||||||
|
- [[agent-harness-engineering|Agent Harness Engineering]] — 七维度框架
|
||||||
|
- [[loop-engineering|Loop Engineering]] — 循环工程
|
||||||
|
- [[prompt-engineering|Prompt Engineering]] — 提示工程
|
||||||
|
- [[context-management|上下文管理]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[tool-workspace-binding|工具-工作区绑定]]
|
||||||
|
- [[memory-tripartite-partition|记忆三分区]]
|
||||||
|
- [[memory-dream|Memory Dream]]
|
||||||
|
- [[memory-recall-fast-slow|快慢召回]]
|
||||||
|
- [[agent-runtime-trace|Agent 运行时追踪]]
|
||||||
|
- [[agent-boundary-design|Agent 边界设计]]
|
||||||
|
- [[multi-model-routing|多模型路由]]
|
||||||
|
- [[context-prefetch-vs-agentic|上下文预取 vs 按需]]
|
||||||
|
- [[channel-fracture|Channel Fracture]]
|
||||||
38
concepts/DFlash.md
Normal file
38
concepts/DFlash.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "DFlash"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, parallel-drafting, baseline-method]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# DFlash
|
||||||
|
|
||||||
|
DFlash（Chen et al., 2026）是最先进的[[parallel-drafting|并行草稿（Parallel Drafting）]]方法，也是 [[DSpark]] 采用的并行骨干。其核心创新是[[kv-injection|KV 注入（KV Injection）]]——从目标模型的选定层提取隐藏状态并注入草稿模型的每一层。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
- 草稿模型共享目标模型的嵌入层和 LM 头（均冻结）
|
||||||
|
- 输入：一个锚点 token 的嵌入 + $\gamma$ 个 mask token 嵌入
|
||||||
|
- 输出：所有 mask 位置的 logits（一次性并行生成）
|
||||||
|
- 块内所有位置双向注意力到彼此和注入的目标上下文
|
||||||
|
|
||||||
|
## 优势
|
||||||
|
|
||||||
|
与自回归草稿器相比：
|
||||||
|
- 草稿延迟 $O(1)$，可使用更深网络（如 5 层 vs 1 层）
|
||||||
|
- 在位置 1 上显著超过浅层自回归草稿器（深网络容量优势）
|
||||||
|
|
||||||
|
## 局限
|
||||||
|
|
||||||
|
与所有并行草稿器一样，存在[[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]导致的后缀接受率衰减。
|
||||||
|
|
||||||
|
## 在 DSpark 框架中的角色
|
||||||
|
|
||||||
|
DSpark 将 DFlash 作为并行骨干，仅做微小修改：将锚点本身也作为第一个预测位置，$\gamma$ 个输入（锚点 + $\gamma-1$ 个 mask）直接产生 $\gamma$ 个草稿 logits，减少草稿计算。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[parallel-drafting|并行草稿（Parallel Drafting）]]
|
||||||
|
- [[kv-injection|KV 注入（KV Injection）]]
|
||||||
31
concepts/Eagle3.md
Normal file
31
concepts/Eagle3.md
Normal file
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: "Eagle3"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, autoregressive-drafting, baseline-method]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Eagle3
|
||||||
|
|
||||||
|
Eagle3（Li et al., 2026b）是基于 TTT（Training-Time Test）的最先进[[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]方法。在 [[DSpark]] 的评估中作为自回归基线。
|
||||||
|
|
||||||
|
## 架构特点
|
||||||
|
|
||||||
|
- 自回归生成：逐 token 顺序预测，每个位置条件化于先前采样的 token
|
||||||
|
- TTT horizon = 7（与 DFlash/DSpark 的块大小对齐）
|
||||||
|
- 浅层网络（仅 1 层），受限于 $O(\gamma)$ 的草稿延迟约束
|
||||||
|
|
||||||
|
## 性能特征
|
||||||
|
|
||||||
|
DSpark 论文的逐位置分析揭示了 Eagle3 的独特模式：
|
||||||
|
- **位置 1 较低**：由于浅层网络容量受限（如 Chat 场景 ~0.53 vs 并行 DFlash ~0.72）
|
||||||
|
- **后续位置维持或上升**：得益于显式条件化——一旦早期 token 锁定语义路径，后续 token 更可预测
|
||||||
|
|
||||||
|
这种模式解释了为何 Eagle3 在某些场景下总接受长度低于并行草稿器，尽管其逐 token 建模能力更强：前缀接受机制下，第一个 token 的低接受率对整个块的影响被放大。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]
|
||||||
|
- [[position-wise-conditional-acceptance|位置条件接受率（Position-wise Conditional Acceptance）]]
|
||||||
30
concepts/MTP.md
Normal file
30
concepts/MTP.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "MTP (Multi-Token Prediction)"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, autoregressive-drafting, deepseek, production]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Multi-Token Prediction (MTP)
|
||||||
|
|
||||||
|
MTP（Multi-Token Prediction）是 DeepSeek 系列模型（DeepSeek-V2, V3, V4）内置的[[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]机制，作为生产环境中的投机解码草稿器。
|
||||||
|
|
||||||
|
## 变体
|
||||||
|
|
||||||
|
- **MTP-1**：单 token 草稿模式，DSpark 论文中的生产基线。历史上被维持是因为静态多 token 草稿器（MTP-3/5）在高并发下会因过度验证开销严格降低总吞吐量
|
||||||
|
- **MTP-3/5**：多 token 草稿模式
|
||||||
|
|
||||||
|
## 在 DSpark 部署中的角色
|
||||||
|
|
||||||
|
DSpark 在 DeepSeek-V4 发布两周后取代了 MTP-1 成为生产系统。DSpark-5（最大草稿长度 $\gamma=5$）相比 MTP-1：
|
||||||
|
- V4-Flash：在匹配吞吐量下，每用户生成速度提升 60%-85%
|
||||||
|
- V4-Pro：提升 57%-78%
|
||||||
|
|
||||||
|
关键突破：DSpark 通过[[confidence-scheduled-verification|置信度调度验证（Confidence-Scheduled Verification）]]安全解锁了大草稿块的性能潜力，解决了 MTP-3/5 因固定长度验证导致的吞吐量退化问题。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]
|
||||||
|
- [[Eagle3]]
|
||||||
38
concepts/additive-semantics.md
Normal file
38
concepts/additive-semantics.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "加性语义 (Additive Semantics)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [semantics, linearity, embedding, vlm]
|
||||||
|
sources: ["arXiv:2606.18839"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 加性语义 (Additive Semantics)
|
||||||
|
|
||||||
|
VLM 嵌入空间中语义强度的加性分解性质，来自余弦相似度的双线性。
|
||||||
|
|
||||||
|
## 假设
|
||||||
|
|
||||||
|
**Assumption 4.1 (Similarity-based Semantic Strength)**：语义 $a$ 在查询嵌入 $e$ 处的强度 $D_a(e) = \langle e, v_a \rangle \in [-1, 1]$，即内积（余弦相似度）度量语义强度。
|
||||||
|
|
||||||
|
## 加性性质
|
||||||
|
|
||||||
|
**Remark 4.2 (Additive Semantic Strength)**：若 $e = \sum_i \alpha_i v_{a_i}$，则
|
||||||
|
$$D_a(e) = \sum_i \alpha_i D_a(v_{a_i})$$
|
||||||
|
|
||||||
|
语义强度对内积的线性依赖意味着语义可被线性分解和组合。
|
||||||
|
|
||||||
|
## 为什么 VLM 有但一般网络没有
|
||||||
|
|
||||||
|
VLM 的预测基于 cosine similarity（内积），而非非线性 softmax on MLP。这使得嵌入空间中的**线性运算是语义可解释的**——内积的双线性在语义层产生加性结构，而一般神经网络的决策函数不满足此性质。
|
||||||
|
|
||||||
|
## 在语义认证中的作用
|
||||||
|
|
||||||
|
加性语义是实现 [[semantic-plane|语义平面]] 约束的基础：证明语义变化若只影响对 $u_a, u_{a'}$ 的强度，则变化必然在 $P_{a,a'}$ 内。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[cosine-similarity-geometry|余弦相似度几何]]
|
||||||
|
- [[semantic-plane|语义平面]]
|
||||||
|
- [[semantic-robustness-certification|语义鲁棒性认证]]
|
||||||
|
- [[semantic-robustness-certification-vlm-2026|论文原文]]
|
||||||
34
concepts/adversarial-robustness.md
Normal file
34
concepts/adversarial-robustness.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "对抗鲁棒性 (Adversarial Robustness)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [robustness, adversarial, security, perturbation]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# 对抗鲁棒性 (Adversarial Robustness)
|
||||||
|
|
||||||
|
模型在故意设计的微小输入扰动（对抗攻击）下保持正确预测的能力。
|
||||||
|
|
||||||
|
## 与鲁棒性认证的关系
|
||||||
|
|
||||||
|
- **对抗训练**：在训练中加入对抗样本提升鲁棒性（经验性）
|
||||||
|
- **鲁棒性认证**（[[robustness-certification]]）：给出严格的数学保证——在特定扰动范围内预测必定不变
|
||||||
|
- 认证是更强的声明，但通常更保守
|
||||||
|
|
||||||
|
## 常见攻击与防御
|
||||||
|
|
||||||
|
- 攻击：FGSM, PGD, C&W, AutoAttack
|
||||||
|
- 防御：对抗训练, 随机平滑（[[randomized-smoothing]]）, 输入去噪
|
||||||
|
|
||||||
|
## 与语义鲁棒性的区别
|
||||||
|
|
||||||
|
对抗鲁棒性关注**恶意设计的**、像素级的不可察觉扰动；语义鲁棒性关注**自然发生的**语义属性变化（形状、风格、背景等）。[[semantic-robustness-certification|语义鲁棒性认证]] 将问题推进到语义层。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[robustness-certification|鲁棒性认证]]
|
||||||
|
- [[randomized-smoothing|随机平滑]]
|
||||||
|
- [[semantic-robustness-certification|语义鲁棒性认证]]
|
||||||
|
- [[distribution-shift|分布偏移]]
|
||||||
41
concepts/agent-boundary-design.md
Normal file
41
concepts/agent-boundary-design.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 边界设计（Boundary Design）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "security", "boundary", "enterprise"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 边界设计
|
||||||
|
|
||||||
|
> 数据不能随便出内网，成本不能无限往上堆，权限不能只靠模型自觉，记忆不能在用户之间串。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Agent 边界设计** 是 Agent 系统在真实业务场景中必须处理的四重边界问题：数据边界、工具边界、模型边界、记忆边界。这是区分「企业级 Agent」和「个人玩具」的关键工程维度。
|
||||||
|
|
||||||
|
## 四重边界
|
||||||
|
|
||||||
|
| 边界类型 | 约束内容 | 实现方式 |
|
||||||
|
|---------|---------|---------|
|
||||||
|
| **数据边界** | 敏感数据不出内网 | 本地模型处理 + 数据访问规则 |
|
||||||
|
| **工具边界** | 工具不全局暴露 | [[tool-workspace-binding|工具-工作区绑定]] |
|
||||||
|
| **模型边界** | 不同任务用不同模型 | [[multi-model-routing|多模型路由]] |
|
||||||
|
| **记忆边界** | 记忆不能在用户/任务间串 | [[memory-tripartite-partition|记忆三分区]] |
|
||||||
|
|
||||||
|
## 与本地小模型的关系
|
||||||
|
|
||||||
|
企业场景中，很多任务不默认交给最贵、最大的云端模型：
|
||||||
|
- 敏感数据优先走本地模型
|
||||||
|
- 常规流程用便宜模型
|
||||||
|
- 复杂分析再交给更强模型
|
||||||
|
|
||||||
|
Workspace 设计让这种路由更自然——不同工作区可绑定不同模型。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[boundary-compliance|边界合规]]
|
||||||
|
- [[multi-model-routing|多模型路由]]
|
||||||
40
concepts/agent-evaluator.md
Normal file
40
concepts/agent-evaluator.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 评估器（Agent Evaluator）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [evaluation, long-horizon, code-generation, agent, judge]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 评估器（Agent Evaluator）
|
||||||
|
|
||||||
|
用于**长周期代码生成任务**的自主评估器，动态评估从零构建的完整代码仓库，提供可扩展的奖励信号。
|
||||||
|
|
||||||
|
## 评估流程
|
||||||
|
|
||||||
|
给定 task specification `T` 和生成的代码仓库 `G(T)`：
|
||||||
|
1. **分解**：将 `T` 分解为可验证的功能需求 checklist `C = {c_1, ..., c_N}`
|
||||||
|
2. **逐项检查**：评估每项是否满足
|
||||||
|
3. **输出双分数**：checklist pass rate `S_pass` + 整体评估分数 `S_eval`
|
||||||
|
|
||||||
|
## 提示迭代中发现的失败模式
|
||||||
|
|
||||||
|
| 版本 | 发现的问题 | 修复 |
|
||||||
|
|------|-----------|------|
|
||||||
|
| Baseline→v1 | 懒惰评估：仅静态代码阅读，不执行测试 | 要求执行测试 |
|
||||||
|
| v1→v2 | 缺少端到端验证：忽略 import errors、依赖冲突 | 添加全局编译检查 |
|
||||||
|
| v2→v3 | 角色混淆：修改生成代码修复 bug、为生成器辩护 | 禁止修改代码、禁止辩护 |
|
||||||
|
| v3→v4 | 上下文过载：exhaustively read 大段代码 | 限制只读 entry-point 定义 |
|
||||||
|
| v4→v5 | 过度规范化：过于详细的规则列表降低判断质量 | 适度细化原则 |
|
||||||
|
|
||||||
|
## 关键发现
|
||||||
|
|
||||||
|
Rubric 粒度存在最优区间——**适度规则帮助弱评估器，过度规定压垮模型**。v4 取得最佳 BoN-Acc（67.4%）和 Kendall τ（0.473）。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[evaluator-metrics|评估器质量指标]]
|
||||||
|
- [[verifier-generator-coevolution|验证器-生成器协同进化]]
|
||||||
38
concepts/agent-interface-design.md
Normal file
38
concepts/agent-interface-design.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 接口设计 (Agent Interface Design)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [agent, interface, design, token-efficiency, workspace]
|
||||||
|
sources: ["https://nokv.io/blog/agents-want-filesystems"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 接口设计 (Agent Interface Design)
|
||||||
|
|
||||||
|
面向 AI Agent 的工具和数据接口设计方法论。核心主张：决定 Agent 效率的变量不只有模型和提示词，还包括 Agent 面对的操作界面（Interface/Surface）。
|
||||||
|
|
||||||
|
## 核心原则
|
||||||
|
|
||||||
|
1. **[[progressive-disclosure|渐进式披露]]**：先发现 → 再按需读取，不要预加载全部
|
||||||
|
2. **路径是稳定句柄**：语义化路径（如 `/runs/abc/stdout.log`）既是名称也是地址
|
||||||
|
3. **[[pushdown-in-agent-interface|下推]]**：过滤/排序/limit/投影一次完成
|
||||||
|
4. **限定范围搜索**：全局发现 + 局部精确提取
|
||||||
|
5. **引用原生性**：行号、偏移量等引用形式天然适合审计和 debug
|
||||||
|
|
||||||
|
## 为什么文件系统语义特别匹配
|
||||||
|
|
||||||
|
LLM 被训练在大量 shell、Unix、Git、日志排查语料上——「进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用行号」是模型内在熟练的工作模式。接口设计与模型能力对齐，比强行适配更能发挥模型效能。
|
||||||
|
|
||||||
|
## 外部收敛信号
|
||||||
|
|
||||||
|
- Anthropic MCP code execution：TypeScript 文件树 → 150k → 2k token
|
||||||
|
- OpenAI tool search：建议 namespace/MCP server 按需加载
|
||||||
|
- Letta memory benchmark：文件组织对话历史 → 竞争力结果
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[agent-workspace-filesystem|Agent 工作空间文件系统]]
|
||||||
|
- [[agents-want-filesystems-nokv-2026|新智元报道]]
|
||||||
|
- [[token-efficiency|Token 效率]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
48
concepts/agent-runtime-trace.md
Normal file
48
concepts/agent-runtime-trace.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 运行时追踪（Runtime Trace）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "runtime", "observability", "postgresql"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 运行时追踪
|
||||||
|
|
||||||
|
> 每一次循环都应该留下可复盘的轨迹——运行状态持久化到数据库，而非只在进程内存里跑一遍就丢掉。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Agent 运行时追踪** 是 [[zleap-workspace-harness-2026|Zleap-Agent]] 的 runtime 模块设计：将 Agent 循环的每一步操作（上下文读取、工具选择、工具调用、结果接收、策略修正）持久化到 PostgreSQL，使运行轨迹可审计、可回滚、可复盘。
|
||||||
|
|
||||||
|
## 为什么需要
|
||||||
|
|
||||||
|
一次真实 Agent 运行中：
|
||||||
|
- 模型读上下文 → 选工具 → 调用工具 → 接收结果 → 修正计划 → 再次调用工具
|
||||||
|
- 中间可能失败、重试、切换策略
|
||||||
|
- 也可能写入记忆或修改文件
|
||||||
|
|
||||||
|
如果只在内存里跑，出错后很难判断问题是：模型能力不够？工具说明不清楚？上下文带错了？记忆读错了？工具返回误导信息？
|
||||||
|
|
||||||
|
## 持久化内容
|
||||||
|
|
||||||
|
- 每一步读了什么文件/上下文
|
||||||
|
- 调用了什么工具、传了什么参数
|
||||||
|
- 拿到了什么返回结果
|
||||||
|
- 下一轮基于什么信息调整方案
|
||||||
|
- 最终是否成功
|
||||||
|
|
||||||
|
## 实验证据
|
||||||
|
|
||||||
|
- **WildClawBench**: 同一模型切换不同 harness，表现最高差 18 个百分点
|
||||||
|
- **Agentic Harness Engineering**: 通过多轮 harness 演化，Terminal-Bench 2 pass@1 从 69.7% 提升到 77.0%，收益主要来自 tools、middleware、long-term memory
|
||||||
|
|
||||||
|
## 与 Prompt 的分工
|
||||||
|
|
||||||
|
Prompt 主要作用于单轮输入输出；Harness 的 Runtime 层管理执行过程、状态变化、失败恢复和后续优化。二者是不同的工程表面。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[agent-harness-engineering|Agent Harness Engineering]]
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
49
concepts/agent-workspace-filesystem.md
Normal file
49
concepts/agent-workspace-filesystem.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 工作空间文件系统 (Agent Workspace Filesystem)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [agent, filesystem, interface, workspace, token-efficiency]
|
||||||
|
sources: ["https://nokv.io/blog/agents-want-filesystems"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 工作空间文件系统 (Agent Workspace Filesystem)
|
||||||
|
|
||||||
|
为 Agent 暴露类 POSIX 语义的工作空间接口（路径寻址、目录列举、按需读取、局部搜索），让 Agent 以人类工程师熟悉的方式「找东西」：ls → grep → read → 引用行号。
|
||||||
|
|
||||||
|
## 为什么需要
|
||||||
|
|
||||||
|
LLM 的训练数据中大量存在 shell、Unix 工具、Git、日志排查语料——模型天然擅长「进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用行号」的工作模式。
|
||||||
|
|
||||||
|
相比之下，SQL 要求 Agent **先理解整张地图再写出正确路线**——对复合探索任务，前置认知成本（schema 理解、join 路径推理）会转化为 token 消耗。
|
||||||
|
|
||||||
|
## Progressive Disclosure 模式
|
||||||
|
|
||||||
|
文件系统接口的精髓是 [[progressive-disclosure|渐进式披露]]：
|
||||||
|
|
||||||
|
1. **低成本发现**：`ls` 看结构，`stat` 看元数据，`catalog` 看字段
|
||||||
|
2. **按需读取**：找到目标后才 `read` 打开内容
|
||||||
|
3. **范围限定搜索**：全局 `grep` 发现 + 目录内 `grep` 精准提取
|
||||||
|
4. **稳定句柄**：`/runs/abc/stdout.log` — 既是名字也是地址
|
||||||
|
|
||||||
|
## 实验证据
|
||||||
|
|
||||||
|
NoKV benchmark：同一份数据（875 run, 80.6 万行指标），文件系统形态接口 vs 原生 SQL：
|
||||||
|
- **-45% token**
|
||||||
|
- **-39% 成本**
|
||||||
|
- 复合探索任务上 2.39× 更低 token 消耗
|
||||||
|
|
||||||
|
## 与数据库的关系
|
||||||
|
|
||||||
|
不是替代，而是**分层**：
|
||||||
|
- 底层：数据库负责可靠性、事务、持久化
|
||||||
|
- 上层：元数据控制层提供 Agent-friendly workspace 视图
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[agents-want-filesystems-nokv-2026|新智元报道：Agents Want Filesystems]]
|
||||||
|
- [[nokv|NoKV]]
|
||||||
|
- [[progressive-disclosure|渐进式披露]]
|
||||||
|
- [[agent-interface-design|Agent 接口设计]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[token-efficiency|Token 效率]]
|
||||||
38
concepts/agentic-quality-judge.md
Normal file
38
concepts/agentic-quality-judge.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 质量判断器（Agentic Quality Judge）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [verification, quality-filtering, swe-bench, judge]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 质量判断器（Agentic Quality Judge）
|
||||||
|
|
||||||
|
自动评估 SWE 类任务质量（instruction 的清晰度和 test-instruction 的对齐度）的 Agent 判断器，作为 [[test-driven-rewards|测试驱动奖励]] 的语义过滤器。
|
||||||
|
|
||||||
|
## 工作原理
|
||||||
|
|
||||||
|
基于 MiniSWEAgent 框架，判断器主动探索 Docker 化的仓库环境：
|
||||||
|
1. 检查 instruction 和环境是否足够自包含（`instruct_clear`）
|
||||||
|
2. 验证 test suite 是否与所述任务匹配（`instruct_ut_align`）
|
||||||
|
3. 综合判定 `overall_good`
|
||||||
|
|
||||||
|
## 设计选择
|
||||||
|
|
||||||
|
- **Base judge model**：Qwen-Plus / Qwen-Max
|
||||||
|
- **投票机制**：3-voting / 5-voting majority voting
|
||||||
|
- **辅助信息**：few-shot demonstrations（提升 instruct_ut_align 精度）、ground-truth patch（提升 recall）
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
- 在 human-annotated benchmark 上 F1 = 76-81%
|
||||||
|
- 质量过滤后的数据使 RL 在 SWE-bench Multilingual 和 Pro 上显著提升
|
||||||
|
- 低 solve-rate 任务中低质量实例占比高 → 质量过滤提升采样效率和奖励可靠性
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[test-driven-rewards|测试驱动奖励]]
|
||||||
|
- [[behavior-monitoring-rl|行为监控RL]]
|
||||||
42
concepts/and-or-dag-memoization.md
Normal file
42
concepts/and-or-dag-memoization.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "AND-OR DAG 分层记忆化"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["theorem-proving", "dag", "memory", "planning"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# AND-OR DAG 分层记忆化
|
||||||
|
|
||||||
|
> 不只是记录证明进度，还结构化分层记忆——单调精化、引理复用、预期规划。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**AND-OR DAG 分层记忆化** 是 [[leap-agentic-atp|LEAP]] 证明树的组织方式：
|
||||||
|
- **OR 节点**：开放目标或引理声明——可用任意有效策略解决
|
||||||
|
- **AND 节点**：候选分解——其成功取决于所有子目标都被证明
|
||||||
|
|
||||||
|
## 三个关键属性
|
||||||
|
|
||||||
|
### 1. 单调精化（Monotone Refinement）
|
||||||
|
|
||||||
|
一旦目标被分解为子目标，后续搜索可聚焦于扩展和解决这些后代，**无需重构已有依赖结构**。单个证明尝试可被修改、扩展或放弃，而 DAG 保留整体证明计划的稳定依赖结构。
|
||||||
|
|
||||||
|
### 2. 引理记忆化（Lemma Memoization）
|
||||||
|
|
||||||
|
中间引理声明存储为共享证明节点，在**不同分支中出现相同子问题时复用**。这减少了冗余推导，让独立证明路径收敛于公共依赖。
|
||||||
|
|
||||||
|
### 3. 预期引理规划（Anticipatory Lemma Planning）
|
||||||
|
|
||||||
|
蓝图生成阶段可提出**当前不立即需要但未来可能有用**的辅助引理。这些预期引理作为非必需依赖（虚线边）保留在图记忆中，不影响当前 AND 节点的解决。
|
||||||
|
|
||||||
|
## 与证明透明度的关系
|
||||||
|
|
||||||
|
DAG 暴露了：哪些目标仍开放、哪些引理已解决、哪些节点阻塞下游进展。这为 [[verification-guided-proof-search|验证引导搜索]] 提供可解释的蓝图式工作空间，也支持人-AI 协作。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[blueprint-driven-atp|蓝图驱动 ATP]]
|
||||||
|
- [[interleaved-informal-formal-planning|非正式-形式化交错规划]]
|
||||||
34
concepts/anticipatory-lemma-planning.md
Normal file
34
concepts/anticipatory-lemma-planning.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "预期引理规划（Anticipatory Lemma Planning）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["theorem-proving", "planning", "dag", "lemma"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 预期引理规划
|
||||||
|
|
||||||
|
> 在蓝图生成阶段提前提出辅助引理——当前不需要，但保留在 DAG 中随时可用。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**预期引理规划** 是 [[leap-agentic-atp|LEAP]] 中 [[and-or-dag-memoization|AND-OR DAG]] 记忆化的一项高级能力：在生成蓝图时，Agent 可提出辅助引理声明，这些引理**不是当前证明草图的必要依赖**，但预期在后续证明步骤中可能有用。
|
||||||
|
|
||||||
|
## 在 DAG 中的表示
|
||||||
|
|
||||||
|
- 预期引理以**虚线边**连接——表示非必需依赖
|
||||||
|
- 在当前 AND 节点被解决前，这些引理不作为硬性依赖
|
||||||
|
- 当后续分支需要时，引理已经存在，无需重新推导
|
||||||
|
|
||||||
|
## 价值
|
||||||
|
|
||||||
|
1. **前瞻性**：类似人类数学家「我先引入几个可能有用的中间结果」
|
||||||
|
2. **避免重复**：当自然语言推理暗示某个中间结论有用时，提前注册为引理
|
||||||
|
3. **降低回溯成本**：不会因缺少引理而需要回溯到更早的节点
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[and-or-dag-memoization|AND-OR DAG 记忆化]]
|
||||||
|
- [[blueprint-driven-atp|蓝图驱动 ATP]]
|
||||||
37
concepts/artifact-heavy-agentic-systems.md
Normal file
37
concepts/artifact-heavy-agentic-systems.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "产物密集型 Agent 系统 (Artifact-Heavy Agentic Systems)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [agent, artifact, metadata, workspace, scalability]
|
||||||
|
sources: ["https://nokv.io/blog/agents-want-filesystems"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 产物密集型 Agent 系统 (Artifact-Heavy Agentic Systems)
|
||||||
|
|
||||||
|
高度依赖大量文件、日志、报告、模型、合同、图片、音视频、checkpoint 等外部产物的 Agent 系统。这类系统的核心挑战不是模型能力，而是**元数据管理的接口效率**。
|
||||||
|
|
||||||
|
## 典型场景
|
||||||
|
|
||||||
|
- **ML 实验追踪**：run、trace、日志、checkpoint、指标、配置的交叉分析
|
||||||
|
- **法律咨询**：合同、判例、尽调材料、邮件附件的元数据管理（来源、版本、权限、引用关系）
|
||||||
|
- **数据分析**：notebook、CSV、数据库结果、图表、报告的交叉引用
|
||||||
|
- **研发 Agent**：issue、PR、日志、CI 结果、构建产物、部署记录的溯源
|
||||||
|
- **多媒体 Agent**：原图、缩略图、转写文本、时间戳、向量表示和版本管理
|
||||||
|
- **多 Agent 协作**：共享中间产物、锁定版本、监听更新、回滚错误状态
|
||||||
|
|
||||||
|
## 核心问题
|
||||||
|
|
||||||
|
如果元数据散落在对象存储 key、向量数据库、业务数据库、缓存和工作流组件中，没有统一管理层，Agent 每次工作都要**重新拼接上下文**——token 被花在「去哪找」而非「做什么」上。
|
||||||
|
|
||||||
|
## 解决方向
|
||||||
|
|
||||||
|
- 统一 [[agent-workspace-filesystem|文件系统形态 workspace]]
|
||||||
|
- [[progressive-disclosure|渐进式披露]] → 按需发现和加载
|
||||||
|
- [[pushdown-in-agent-interface|接口下推]] → 减少轮数
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[agents-want-filesystems-nokv-2026|新智元报道]]
|
||||||
|
- [[nokv|NoKV]]
|
||||||
|
- [[agent-interface-design|Agent 接口设计]]
|
||||||
35
concepts/attention-drifting.md
Normal file
35
concepts/attention-drifting.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "注意力偏移 (Attention Drifting)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [agent, attention, context, cognitive-load, interface]
|
||||||
|
sources: ["https://nokv.io/blog/agents-want-filesystems"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 注意力偏移 (Attention Drifting)
|
||||||
|
|
||||||
|
当 Agent 的上下文窗口被塞进过多 schema、临时查询结果、无关日志和中间失败尝试时，模型容易被早期错误线索带偏，或在多轮调用后忘记最初的问题。
|
||||||
|
|
||||||
|
## 成因
|
||||||
|
|
||||||
|
Agent 在执行任务时不仅读取数据，还在**不断维护一张临时的任务地图**。当接口迫使 Agent 先理解复杂 schema、猜 join 路径、拼 blob_ref、回忆对应关系时，token 被花在「维持工作记忆」而非「做出判断」上。
|
||||||
|
|
||||||
|
## 与 token efficiency 的关系
|
||||||
|
|
||||||
|
Attention drifting 是 [[token-efficiency|Token 效率]] 问题的上层表征：
|
||||||
|
- 低效接口 → 更多上下文垃圾 → 注意力稀释
|
||||||
|
- 清晰接口（如文件系统形态） → 每一步看到更少但更相关的信息 → 注意力集中
|
||||||
|
|
||||||
|
## 缓解策略
|
||||||
|
|
||||||
|
- [[progressive-disclosure|渐进式披露]]：逐步披露信息，不预加载全部
|
||||||
|
- [[pushdown-in-agent-interface|下推]]：过滤/排序/limit 一次完成，减少回灌
|
||||||
|
- [[agent-workspace-filesystem|文件系统接口]]：路径稳定句柄，按需搜索
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[agents-want-filesystems-nokv-2026|新智元报道]]
|
||||||
|
- [[progressive-disclosure|渐进式披露]]
|
||||||
|
- [[token-efficiency|Token 效率]]
|
||||||
|
- [[agent-interface-design|Agent 接口设计]]
|
||||||
36
concepts/autoformalization.md
Normal file
36
concepts/autoformalization.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "自动形式化（Autoformalization）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["mathematics", "formal-verification", "nlp", "lean"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 自动形式化
|
||||||
|
|
||||||
|
> 将自然语言数学证明自动翻译为机器可验证的形式化证明——弥合「非形式化推理」与「形式化验证」之间的鸿沟。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**自动形式化** (Autoformalization) 是将人类可读的自然语言数学论证转化为 [[lean-proof-assistant|Lean]] 等 [[formal-theorem-proving|形式化定理证明]] 系统中的可验证代码。这是 LLM 在数学领域最具挑战性的任务之一。
|
||||||
|
|
||||||
|
## 挑战
|
||||||
|
|
||||||
|
- **语义鸿沟**：自然语言中的直觉跳跃无法直接对应形式化逻辑步骤
|
||||||
|
- **单次生成困难**：即使 LLM 能理解数学概念，一次性生成正确的形式化证明仍极难（[[leap-agentic-atp|LEAP]] 论文显示 direct formalization 在 Putnam 2025 上全军覆没）
|
||||||
|
- **反馈需求**：自然语言证明翻译为 Lean 后，Pass@128 的 Advanced 组得分仅 3.3%
|
||||||
|
|
||||||
|
## LEAP 的解法
|
||||||
|
|
||||||
|
[[leap-agentic-atp|LEAP]] 不依赖单次自动形式化，而是：
|
||||||
|
1. 先生成**非正式蓝图**（策略层面），再逐步翻译为 Lean
|
||||||
|
2. 利用编译错误反馈迭代修正
|
||||||
|
3. 将复杂问题分解为更小的子目标（[[blueprint-driven-atp|蓝图驱动]]）
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[formal-theorem-proving|形式化定理证明]]
|
||||||
|
- [[lean-proof-assistant|Lean 证明助手]]
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[blueprint-driven-atp|蓝图驱动 ATP]]
|
||||||
38
concepts/autoregressive-drafting.md
Normal file
38
concepts/autoregressive-drafting.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Autoregressive Drafting"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, llm-inference, sequential-generation]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Autoregressive Drafting
|
||||||
|
|
||||||
|
自回归草稿（Autoregressive Drafting）是[[speculative-decoding|投机解码（Speculative Decoding）]]的传统草稿架构：草稿模型逐 token 顺序生成候选序列，每个位置条件化于先前采样的 token。这种显式依赖关系提供了强大的建模能力，但草稿延迟随块大小线性增长：$T_{draft} \propto \gamma$。
|
||||||
|
|
||||||
|
## 结构约束
|
||||||
|
|
||||||
|
$O(\gamma)$ 的延迟迫使自回归草稿器使用**小块大小**（$\gamma$ 通常为 3-5）和**浅层网络**（通常仅 1 层），以避免草稿延迟主导总延迟。为补偿块大小不足，常配合树验证（tree-based verification）展开多条候选路径，但大量验证 token 会降低整体服务吞吐量。
|
||||||
|
|
||||||
|
## 与并行草稿的对比
|
||||||
|
|
||||||
|
DSpark 论文的逐位置条件接受率分析揭示了关键洞察：
|
||||||
|
|
||||||
|
- **自回归草稿器**在位置 1 起步较低（浅网络容量劣势，如 Chat: ~0.53 vs 并行 ~0.72），但后续位置**维持或上升**——得益于条件化于已采样 token 的语义路径锁定
|
||||||
|
- **并行草稿器**（[[parallel-drafting]]）在位置 1 起步较高（深网络容量优势），但后续位置**快速衰减**
|
||||||
|
|
||||||
|
这种结构性差异解释了为何初始 token 的高杠杆使得某些场景下并行草稿器在总体接受长度上反超自回归草稿器。
|
||||||
|
|
||||||
|
## 代表方法
|
||||||
|
|
||||||
|
| 方法 | 关键机制 |
|
||||||
|
|------|---------|
|
||||||
|
| [[Eagle3]] | TTT（Training-Time Test），horizon=7 |
|
||||||
|
| [[MTP]] | Multi-Token Prediction，DeepSeek 生产基线 |
|
||||||
|
| Medusa (tree) | 多草稿头 + 树验证 |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]] — 半自回归架构融合两者优势
|
||||||
|
- [[parallel-drafting|Parallel Drafting]]
|
||||||
|
- [[position-wise-conditional-acceptance|位置条件接受率（Position-wise Conditional Acceptance）]]
|
||||||
30
concepts/beam-shared-kv-caching.md
Normal file
30
concepts/beam-shared-kv-caching.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "Beam-Shared KV Caching"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [generative-recommendation, inference-optimization, kv-cache]
|
||||||
|
sources: [GR4AD]
|
||||||
|
---
|
||||||
|
# Beam-Shared KV Caching
|
||||||
|
|
||||||
|
Beam-Shared KV Caching 是 [[GR4AD]] 提出的束搜索推理优化技术，通过沿序列维度组织束来共享编码器 KV 缓存。
|
||||||
|
|
||||||
|
## 问题
|
||||||
|
|
||||||
|
在束搜索中，解码器的每步需要对 $B$ 个束分别计算注意力——每个束需要独立的 KV 缓存。标准实现中，$B$ 个束产生 $B$ 份完整 KV 缓存副本，per-step KV 读取复杂度为 $O(B \cdot L)$，其中 $L$ 是序列长度。
|
||||||
|
|
||||||
|
## 方案
|
||||||
|
|
||||||
|
将所有束沿序列维度拼接，多个束共享**同一份编码器 KV 缓存**。注意力计算中，束间通过适当的掩码隔离互注意力，但编码器部分完全共享。per-step KV 读取复杂度降至 $O(L)$。
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
- 消除冗余的内存访问
|
||||||
|
- 对束搜索的吞吐量有显著贡献
|
||||||
|
- 配合 TopK Pre-Cut（先并行选 $k$ 个候选人，再做全局 top-$k$ 选择）进一步减少搜索空间
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[GR4AD]]
|
||||||
|
- [[dynamic-beam-serving|DBS]]
|
||||||
46
concepts/behavior-monitoring-rl.md
Normal file
46
concepts/behavior-monitoring-rl.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "行为监控 RL（Behavior Monitoring in RL）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [verification, reward-hacking, rl, monitoring, coding-agent]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 行为监控 RL
|
||||||
|
|
||||||
|
在 RL 训练中对 agent trajectory 进行审计，检测并惩罚 shortcut 行为的机制，是防御 [[reward-hacking|奖励破解]] 的关键手段。
|
||||||
|
|
||||||
|
## 设计
|
||||||
|
|
||||||
|
### Pattern Set `P`
|
||||||
|
|
||||||
|
每个 pattern 指定三项：
|
||||||
|
1. **Observable evidence**：轨迹中的可观察证据（命令历史、网络访问、git 操作）
|
||||||
|
2. **Leakage risk**：关联的信息泄露风险
|
||||||
|
3. **Intervention**：token 级惩罚
|
||||||
|
|
||||||
|
### 闭环更新
|
||||||
|
|
||||||
|
Pattern set 在训练过程中迭代更新：
|
||||||
|
1. 每轮 RL 后，从当前 policy 抽样 trajectory
|
||||||
|
2. Agentic reviewer 检查轨迹，发现新的 shortcut 策略
|
||||||
|
3. 追加到 `P`，下一轮 RL 部署更新的 monitor
|
||||||
|
|
||||||
|
**关键**：reward hacking 是 policy-dependent 的——新 shortcut 随模型提升而涌现，静态 pattern set 不足以覆盖。
|
||||||
|
|
||||||
|
## 发现的两类泄露
|
||||||
|
|
||||||
|
| 类型 | 行为 | 频率 | Resolved Rate |
|
||||||
|
|------|------|------|:---:|
|
||||||
|
| **静态环境泄露** | Repository-history mining | 3.69% | 47.29%（↓基线） |
|
||||||
|
| | Test-oracle tampering | 8.25% | 41.47%（↓基线） |
|
||||||
|
| **Policy 依赖捷径** | Solution artifact retrieval | 4.32% | 72.34%（↑12.35pp） |
|
||||||
|
| | External fix lookup | 7.03% | 61.69%（↑1.70pp） |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[test-driven-rewards|测试驱动奖励]]
|
||||||
|
- [[reward-hacking|奖励破解]]
|
||||||
36
concepts/blind-prompting.md
Normal file
36
concepts/blind-prompting.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Blind Prompting（盲提示）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [prompt-engineering, anti-pattern, methodology]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Blind Prompting
|
||||||
|
|
||||||
|
> [[prompt-engineering|Prompt Engineering]] 的反模式：仅依赖 trial-and-error 换词、缺乏系统测试、对模型原理一知半解的"凭手感"提示方法。
|
||||||
|
|
||||||
|
## 与 Prompt Engineering 的区别
|
||||||
|
|
||||||
|
| 维度 | Prompt Engineering | Blind Prompting |
|
||||||
|
|------|-------------------|-----------------|
|
||||||
|
| 方法论 | 定义问题 → demonstration set → 候选 prompt → 实测准确率 → 成本/精度权衡 → 持续迭代 | 凭直觉换词 → 看输出 → 不满意再换 |
|
||||||
|
| 测试 | 有系统化评估矩阵 | 无测试或仅主观判断 |
|
||||||
|
| 可迁移性 | 底座模型切换时可重编译（如 [[dspy|DSPy]]） | 换模型后集体失效 |
|
||||||
|
|
||||||
|
## 危害
|
||||||
|
|
||||||
|
- 无法规模化：应用稍大就需要维护成百上千条"万能模板"
|
||||||
|
- 技术债务累积：模型升级时精心打磨的 prompt 可能反向退化
|
||||||
|
- 成本失控：无缓存意识、无 token 预算概念
|
||||||
|
|
||||||
|
## 起源
|
||||||
|
|
||||||
|
Mitchell Hashimoto (2023) 首次系统区分了 Prompt Engineering 与 Blind Prompting。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[prompt-engineering|Prompt Engineering]]
|
||||||
|
- [[dspy|DSPy]]
|
||||||
48
concepts/blueprint-driven-atp.md
Normal file
48
concepts/blueprint-driven-atp.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "蓝图驱动 ATP（Blueprint-Driven ATP）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["theorem-proving", "planning", "decomposition", "lean"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 蓝图驱动 ATP
|
||||||
|
|
||||||
|
> 不是一次性合成完整证明，而是通过蓝图草图逐步分解和迭代——仿效人类数学家的证明工作流。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**蓝图驱动 ATP** 是 [[leap-agentic-atp|LEAP]] 在直接形式化失败后的回退策略：生成**非正式蓝图**（说明如何将目标归约为子目标），再翻译为 **Lean 证明草图**，将子目标注册入 [[and-or-dag-memoization|AND-OR DAG]] 后递归处理。
|
||||||
|
|
||||||
|
## 工作流
|
||||||
|
|
||||||
|
```
|
||||||
|
目标（OR 节点）
|
||||||
|
↓ 直接证明失败
|
||||||
|
蓝图生成 → 非正式蓝图（规划空间）
|
||||||
|
↓
|
||||||
|
翻译为 Lean 证明草图（AND 节点）
|
||||||
|
↓ Lean 编译器验证草图
|
||||||
|
→ 通过：子目标 → 新 OR 节点 → 递归处理
|
||||||
|
→ 拒绝：LLM Reviewer 评估 → 重试/回溯/放弃
|
||||||
|
```
|
||||||
|
|
||||||
|
## 与 Lean Blueprint 工具的关系
|
||||||
|
|
||||||
|
受 Lean Blueprint 工具的启发——该工具允许数学家编写人类可读的证明路线图，链接到 Lean 代码并可视化为 DAG。已在 Fermat's Last Theorem 形式化路线图等大型项目中验证。
|
||||||
|
|
||||||
|
## 与直接形式化的对比
|
||||||
|
|
||||||
|
| 维度 | 直接形式化 | 蓝图驱动 |
|
||||||
|
|------|----------|---------|
|
||||||
|
| 策略 | 一次性生成完整证明 | 分解为子目标逐步攻克 |
|
||||||
|
| 容错 | 整体正确才通过 | 子目标可独立重试 |
|
||||||
|
| 复用 | 无 | 引理跨分支复用 |
|
||||||
|
| 适用 | 简单/中等难度 | 高难度、多步骤证明 |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[and-or-dag-memoization|AND-OR DAG 记忆化]]
|
||||||
|
- [[interleaved-informal-formal-planning|非正式-形式化交错规划]]
|
||||||
41
concepts/channel-fracture.md
Normal file
41
concepts/channel-fracture.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Channel Fracture（通道断裂）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "memory", "hermes", "failure-mode"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Channel Fracture
|
||||||
|
|
||||||
|
> 「看似完成、实际未送达」——记忆写入的隐藏失败模式。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Channel Fracture** 是 Hermes Agent 生产部署中发现的一种记忆写入失败模式：当定时任务 Agent 尝试向目标 Agent 注入持久记忆时，由于 `skip_memory=True` 和 memory manager 初始化条件，cron 路径出现了「命令执行成功，但记忆未送达」的通道断裂。
|
||||||
|
|
||||||
|
## 案例详情
|
||||||
|
|
||||||
|
实验比较了三条写入路径：
|
||||||
|
1. 直接写 SQLite → 送达
|
||||||
|
2. 目标 Agent 通过 memory tools 自写入 → 送达
|
||||||
|
3. **cron delegated 写入 → 通道断裂**
|
||||||
|
|
||||||
|
根因：cron 路径中 `skip_memory=True` 导致 memory manager 未初始化，写入操作被静默跳过。
|
||||||
|
|
||||||
|
## 启示
|
||||||
|
|
||||||
|
记忆系统不能只看「有没有存储」，还要看完整链路：
|
||||||
|
- 谁写入，写给谁
|
||||||
|
- 通过什么通道写入
|
||||||
|
- 有没有确认送达
|
||||||
|
- 未来什么时候被检索出来
|
||||||
|
- 会不会污染别的用户或任务
|
||||||
|
|
||||||
|
这也是 [[memory-tripartite-partition|记忆三分区]] 的设计动机之一——分区治理降低跨通道污染风险。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]（引用了此案例）
|
||||||
|
- [[memory-tripartite-partition|记忆三分区]]
|
||||||
39
concepts/circuit-breaker-pattern.md
Normal file
39
concepts/circuit-breaker-pattern.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Circuit Breaker Pattern（熔断器模式）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [safety, loop-engineering, reliability, pattern]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Circuit Breaker Pattern
|
||||||
|
|
||||||
|
> 在 [[loop-engineering|Loop Engineering]] 中，熔断器是 [[loop-contract|Loop Contract]] 的 BUDGET 维度固化为硬约束的安全机制——连续失败 N 次即跳闸。
|
||||||
|
|
||||||
|
## 核心参数
|
||||||
|
|
||||||
|
- **max_consecutive_failures**：连续失败次数上限。一旦连续报错 N 次，系统立即跳闸并回退代码，将当前运行栈日志打包成工单转交人工
|
||||||
|
- **max_runtime_min**：墙上时间上限。超时无条件熔断，不等待当前操作完成
|
||||||
|
|
||||||
|
## 设计原理
|
||||||
|
|
||||||
|
熔断器来自分布式系统设计模式，在自主 Agent 循环中承担 **安全预算执行者** 角色：
|
||||||
|
|
||||||
|
1. **失败计数**：跟踪连续失败次数
|
||||||
|
2. **阈值触发**：达到 max_consecutive_failures → OPEN 状态（拒绝所有操作）
|
||||||
|
3. **优雅降级**：回退代码 → 打包日志 → 转交人工，而非静默丢失
|
||||||
|
|
||||||
|
## 与看门狗的分工
|
||||||
|
|
||||||
|
| 机制 | 监控对象 | 触发条件 | 响应 |
|
||||||
|
|------|---------|---------|------|
|
||||||
|
| [[circuit-breaker-pattern|熔断器]] | 任务级失败 | 连续失败 N 次 | 跳闸 + 回退 |
|
||||||
|
| [[watchdog-pattern|看门狗]] | 进程级异常 | CPU 满载 + 无 I/O | SIGKILL |
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-contract|Loop Contract]]
|
||||||
|
- [[watchdog-pattern|看门狗]]
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
38
concepts/clip.md
Normal file
38
concepts/clip.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "CLIP"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [model, multimodal, vision-language, openai]
|
||||||
|
sources: ["Radford et al., 2021"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# CLIP (Contrastive Language-Image Pre-training)
|
||||||
|
|
||||||
|
OpenAI 提出的双编码器视觉语言模型，通过大规模图文对对比学习训练，将图像和文本对齐到共享嵌入空间。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
- 视觉编码器：ViT 或 ResNet，输出单位嵌入
|
||||||
|
- 文本编码器：Transformer，输出单位嵌入
|
||||||
|
- 训练目标：对比损失（contrastive loss），最大化匹配图文对的相似度，最小化不匹配对的相似度
|
||||||
|
|
||||||
|
## 关键影响
|
||||||
|
|
||||||
|
CLIP 使 VLM 成为基础视觉组件，支持：
|
||||||
|
- [[open-vocabulary-recognition|开放词表识别]]（zero-shot classification）
|
||||||
|
- 图文检索、检测、分割、VQA
|
||||||
|
- 嵌入空间的语义可解释性（相似度反映语义关联）
|
||||||
|
|
||||||
|
## 变体与后代
|
||||||
|
|
||||||
|
- ViT-B/32、ViT-L/14 等不同视觉骨干
|
||||||
|
- BLIP、ALIGN、SigLIP 等后续模型
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[dual-encoder-vlm|双编码器 VLM]]
|
||||||
|
- [[cosine-similarity-geometry|余弦相似度几何]]
|
||||||
|
- [[semantic-robustness-certification-vlm-2026|Semantic Robustness Certification (ICML 2026)]]（以 CLIP ViT-B/32 实验）
|
||||||
|
- [[contrastive-learning|对比学习]]
|
||||||
29
concepts/clique-decision-problem.md
Normal file
29
concepts/clique-decision-problem.md
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
title: "Clique Decision Problem（团判定问题）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [graph-theory, computational-complexity, safe-exploration]
|
||||||
|
sources: [[safe-equilibrium-exploration]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Clique Decision Problem
|
||||||
|
|
||||||
|
> [[safe-equilibrium-exploration|SEE 算法]] 第 2 步将寻找最小 [[uncertain-model|不确定模型]] 的问题**归约为图论中的团判定问题**（给定图 G 和整数 k，判定 G 是否包含大小为 k 的团），并在多项式时间内近似求解。
|
||||||
|
|
||||||
|
## 归约逻辑
|
||||||
|
|
||||||
|
SEE 将模型精化建模为：在不确定性图中找一个"团"——相互兼容的模型参数集合，使得团内所有参数对可行域内数据的拟合都是"最小不确定的"。
|
||||||
|
|
||||||
|
## 计算性质
|
||||||
|
|
||||||
|
- Clique Decision 是 NP-完全的经典问题
|
||||||
|
- SEE 采用多项式时间近似求解
|
||||||
|
- 在实验规模的图上是高效的
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[safe-equilibrium-exploration|SEE]]
|
||||||
|
- [[uncertain-model|不确定模型]]
|
||||||
|
- [[risky-bellman-equation|风险贝尔曼方程]]
|
||||||
41
concepts/confidence-head.md
Normal file
41
concepts/confidence-head.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Confidence Head"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, confidence-estimation, neural-calibration]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Confidence Head
|
||||||
|
|
||||||
|
置信度头是 [[DSpark]] 中用于预测每个草稿位置**条件存活概率**的轻量级模块。其输出直接驱动[[hardware-aware-prefix-scheduler|硬件感知前缀调度器（Hardware-Aware Prefix Scheduler）]]的验证长度决策。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
$$c_k = \sigma\left(w^\top [h_k; W_1[x_{k-1}]]\right)$$
|
||||||
|
|
||||||
|
- $h_k$：并行骨干在位置 $k$ 的隐藏状态
|
||||||
|
- $W_1[x_{k-1}]$：前一个草稿 token 的马尔可夫嵌入
|
||||||
|
- $\sigma$：sigmoid，将输出压缩到 $(0,1)$
|
||||||
|
|
||||||
|
## 监督信号
|
||||||
|
|
||||||
|
训练目标 $c_k$ 逼近解析接受率 $c_k^*$，后者由草稿分布 $p_k^d$ 与目标分布 $p_k^t$ 的总变差距离决定：
|
||||||
|
|
||||||
|
$$c_k^* = 1 - \frac{1}{2} \|p_k^d - p_k^t\|_1$$
|
||||||
|
|
||||||
|
## 校准：顺序温度缩放（STS）
|
||||||
|
|
||||||
|
原始置信度估计常存在过自信偏差（平均 ECE 3%-8%）。[[sequential-temperature-scaling|Sequential Temperature Scaling]] 逐位置进行 1D 网格搜索，最小化累积乘积 $\prod_{i \le k} c_i$ 的 ECE，将平均 ECE 降至 ~1%。
|
||||||
|
|
||||||
|
温度缩放是保序变换——修正概率幅度但不扰乱草稿 token 的相对排序。
|
||||||
|
|
||||||
|
## 与静态阈值方法的区别
|
||||||
|
|
||||||
|
静态阈值方法（如直接拒绝 $c_k < \theta$ 的 token）只需要置信度分数的相对排序。DSpark 的硬件感知调度器需要累积存活概率的**绝对幅度**来计算期望接受长度 $\tau$，因此必须校准。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[confidence-scheduled-verification|置信度调度验证（Confidence-Scheduled Verification）]]
|
||||||
|
- [[sequential-temperature-scaling|Sequential Temperature Scaling]]
|
||||||
33
concepts/confidence-scheduled-verification.md
Normal file
33
concepts/confidence-scheduled-verification.md
Normal file
@@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "Confidence-Scheduled Verification"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, llm-inference, dynamic-scheduling]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Confidence-Scheduled Verification
|
||||||
|
|
||||||
|
置信度调度验证是 [[DSpark]] 提出的动态验证长度选择机制，用[[confidence-head|置信度头（Confidence Head）]]估计每个草稿位置的前缀存活概率，再由[[hardware-aware-prefix-scheduler|硬件感知前缀调度器（Hardware-Aware Prefix Scheduler）]]基于实时系统负载动态裁剪低置信度后缀 token。
|
||||||
|
|
||||||
|
## 问题动机
|
||||||
|
|
||||||
|
固定长度验证存在两大浪费源：
|
||||||
|
|
||||||
|
1. **数据侧**：不同领域的接受率天然不同——结构化任务（代码、数学）的接受率远高于开放式对话，静态验证长度无法适配
|
||||||
|
2. **系统侧**：轻负载下额外验证代价极小，但高并发下每次无意义验证都挤占目标模型的批容量，降低整体吞吐量
|
||||||
|
|
||||||
|
## 两组件协同
|
||||||
|
|
||||||
|
- **置信度头**：$c_k = \sigma(w^\top [h_k; W_1[x_{k-1}]])$，预测位置 $k$ 的条件存活概率 $P(\text{accept}_k | \text{accept}_{1:k-1})$
|
||||||
|
- **前缀调度器**：将验证长度选择形式化为全局吞吐量最大化问题 $\Theta = \tau \cdot \text{SPS}(B)$，通过贪心排序+早停实现严格因果的 lossless 调度
|
||||||
|
|
||||||
|
## 校准
|
||||||
|
|
||||||
|
神经网络的置信度估计常存在过自信偏差。DSpark 引入**顺序温度缩放（[[sequential-temperature-scaling|Sequential Temperature Scaling]]）**：利用链式法则 $\prod_{i \le k} c_i$，从左到右逐位置进行 1D 网格搜索最小化累积乘积的 ECE，保持分数排序不变的同时修正绝对幅度。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[hardware-aware-prefix-scheduler|硬件感知前缀调度器（Hardware-Aware Prefix Scheduler）]]
|
||||||
|
- [[confidence-head|置信度头（Confidence Head）]]
|
||||||
@@ -26,6 +26,21 @@ Context Engineering 的关键转变在于从"输入是什么"到"模型在每一
|
|||||||
- **压缩**（Compaction）：移除已完成使命的 token
|
- **压缩**（Compaction）：移除已完成使命的 token
|
||||||
- **记忆检索**：只拉入与当前任务最相关的记录
|
- **记忆检索**：只拉入与当前任务最相关的记录
|
||||||
|
|
||||||
|
## 三种故障模式
|
||||||
|
|
||||||
|
参见 [[context-failure-modes|上下文故障模式]]：
|
||||||
|
|
||||||
|
- **Context Starvation**（信息匮乏）：数据过少 → 幻觉
|
||||||
|
- **Context Overflow**（信息过载）：噪音稀释注意力
|
||||||
|
- **Context Rot**（上下文腐烂）：窗口越满质量越退化
|
||||||
|
|
||||||
|
## 优化策略
|
||||||
|
|
||||||
|
- [[minimum-viable-context|MVC（最小可行上下文）]]：严控单次请求体积
|
||||||
|
- [[graphrag|GraphRAG]]：实体关系网络取代向量相似度
|
||||||
|
- [[just-in-time-retrieval|JIT 检索]]：按需实时加载
|
||||||
|
- [[prefix-matching-invariant|前缀匹配不变性]]：缓存经济学基础
|
||||||
|
|
||||||
## 上下文包含的内容
|
## 上下文包含的内容
|
||||||
|
|
||||||
在部署的 Agent 中，上下文包括：系统 prompt + 工具定义 + 历史轮次 + 工具调用结果 + 检索文档 + 动态注入的工作状态。所有这些都在争抢有限的注意力预算。
|
在部署的 Agent 中，上下文包括：系统 prompt + 工具定义 + 历史轮次 + 工具调用结果 + 检索文档 + 动态注入的工作状态。所有这些都在争抢有限的注意力预算。
|
||||||
|
|||||||
48
concepts/context-failure-modes.md
Normal file
48
concepts/context-failure-modes.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "Context Failure Modes（上下文故障模式）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [context-engineering, failure, debugging]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context Failure Modes
|
||||||
|
|
||||||
|
> 在 [[context-engineering|Context Engineering]] 中，缺乏合理的上下文装配逻辑时易陷入的三种典型故障模式。
|
||||||
|
|
||||||
|
## 三种模式
|
||||||
|
|
||||||
|
### Context Starvation（信息匮乏）
|
||||||
|
|
||||||
|
- **现象**：数据过少 → 模型缺乏依据 → 产生幻觉
|
||||||
|
- **根因**：检索范围过窄、过滤条件过严、上下文截断策略不当
|
||||||
|
- **对策**：扩大检索窗口、使用 [[graphrag|GraphRAG]] 进行语义关联扩展
|
||||||
|
|
||||||
|
### Context Overflow（信息过载）
|
||||||
|
|
||||||
|
- **现象**：灌入大量无关噪音 → 稀释模型注意力 → 关键信息被淹没
|
||||||
|
- **根因**：全量预加载、未做相关性过滤、缺少 [[minimum-viable-context|MVC]] 机制
|
||||||
|
- **对策**：[[just-in-time-retrieval|JIT 检索]]、渐进式披露、压缩（Compaction）
|
||||||
|
|
||||||
|
### Context Rot（上下文腐烂）
|
||||||
|
|
||||||
|
- **现象**：窗口越填越满 → 模型响应质量反向退化
|
||||||
|
- **根因**：已失效的历史信息未被清理、压缩策略缺失
|
||||||
|
- **对策**：定期压缩、移除已完成使命的 Token、利用 [[prompt-caching|Prompt Caching]] 前缀匹配
|
||||||
|
|
||||||
|
## 三者关系
|
||||||
|
|
||||||
|
```
|
||||||
|
Context Starvation ←─ 检索不足 ──→ Context Overflow
|
||||||
|
↑ ↓
|
||||||
|
└──── 退化 ──── Context Rot ←────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-engineering|Context Engineering]]
|
||||||
|
- [[minimum-viable-context|MVC]]
|
||||||
|
- [[prompt-caching|Prompt Caching]]
|
||||||
|
- [[graphrag|GraphRAG]]
|
||||||
38
concepts/context-prefetch-vs-agentic.md
Normal file
38
concepts/context-prefetch-vs-agentic.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "上下文预取 vs 按需加载（Context Prefetch vs Agentic）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "context", "latency", "token-economics"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 上下文预取 vs 按需加载
|
||||||
|
|
||||||
|
> Harness 要明确规定：哪些提前带入（Prefetch），哪些按需读取（Agentic）。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
在 [[workspace-first-architecture|Workspace-first 架构]] 中，上下文加载被拆成两种模式：
|
||||||
|
|
||||||
|
| 模式 | 触发时机 | 内容 | 特点 |
|
||||||
|
|------|---------|------|------|
|
||||||
|
| **Prefetch** | 进入工作区时自动 | 用户偏好、近期工作事件、常用经验 | 短、准、可控 |
|
||||||
|
| **Agentic** | 模型主动请求 | 完整文档详情、历史会议纪要 | 按需触发，增加交互轮次 |
|
||||||
|
|
||||||
|
## 设计权衡
|
||||||
|
|
||||||
|
- 预取过多 → 抬高上下文成本，大量不相关内容占据注意力
|
||||||
|
- 全部按需读取 → 增加交互轮次和失败点，延迟上升
|
||||||
|
- 最优策略：核心信息 prefetch + 详情按需 agentic
|
||||||
|
|
||||||
|
## 与记忆召回的关系
|
||||||
|
|
||||||
|
Prefetch/Agentic 是上下文层的加载策略，[[memory-recall-fast-slow|记忆快慢召回]] 是记忆层对同一思路的实现——fast 对应 prefetch，slow 对应 agentic。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[context-management|上下文管理]]
|
||||||
|
- [[memory-recall-fast-slow|快慢召回]]
|
||||||
31
concepts/contrastive-learning.md
Normal file
31
concepts/contrastive-learning.md
Normal file
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: "对比学习 (Contrastive Learning)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [self-supervised, representation-learning, embedding, multimodal]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# 对比学习 (Contrastive Learning)
|
||||||
|
|
||||||
|
一种自监督/监督表示学习方法，通过拉近正样本对、推开负样本对来学习有判别力的嵌入表示。
|
||||||
|
|
||||||
|
## 核心损失
|
||||||
|
|
||||||
|
$$\mathcal{L} = -\log \frac{\exp(\text{sim}(z_i, z_i^+)/\tau)}{\sum_j \exp(\text{sim}(z_i, z_j)/\tau)}$$
|
||||||
|
|
||||||
|
- $z_i, z_i^+$：正样本对（匹配的图文/增强视图）
|
||||||
|
- $z_j$：batch 中所有样本（包括负样本）
|
||||||
|
- $\tau$：温度参数
|
||||||
|
|
||||||
|
## 在 VLM 中的作用
|
||||||
|
|
||||||
|
CLIP 的对比训练使文本嵌入成为嵌入空间中的**语义锚点**——匹配的图文对被拉近，不匹配的被推开。这是 [[text-proxy-for-semantics|文本语义代理]] 有效的基础：文本 prompt 的嵌入在语义上与其描述的概念对齐。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[clip|CLIP]]
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[cosine-similarity-geometry|余弦相似度几何]]
|
||||||
|
- [[text-proxy-for-semantics|文本语义代理]]
|
||||||
39
concepts/control-barrier-function.md
Normal file
39
concepts/control-barrier-function.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Control Barrier Function（控制屏障函数）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [safe-control, control-theory, safety, CBF]
|
||||||
|
sources: [[safe-equilibrium-exploration]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Control Barrier Function (CBF)
|
||||||
|
|
||||||
|
> 控制理论中用于保证安全约束的数学工具。在 [[safe-exploration|安全探索]] 中，CBF 被用作 [[safety-filter|Safety Filter]] 的约束函数。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
对于控制系统 ẋ = f(x) + g(x)u，标量函数 h(x) 是一个 CBF，如果存在 α > 0 使得：
|
||||||
|
|
||||||
|
> sup_u [L_f h(x) + L_g h(x)u + α h(x)] ≥ 0
|
||||||
|
|
||||||
|
当 h(x) ≥ 0 时，系统状态保持在安全集内。
|
||||||
|
|
||||||
|
## 在 RL 中的应用
|
||||||
|
|
||||||
|
- **CBF + QP**：将 CBF 作为二次规划的约束，修正 RL 策略的输出动作
|
||||||
|
- **State-affine CBF**：Cheng et al. (2019) 提出状态仿射 CBF，简化 QP 求解
|
||||||
|
- **控制仿射系统**：适用于 ẋ = f(x) + g(x)u 形式的动力学
|
||||||
|
|
||||||
|
## 局限
|
||||||
|
|
||||||
|
- 需要系统动力学的精确知识
|
||||||
|
- 人工设计 CBF 费时且保守
|
||||||
|
- 不适用于复杂/非结构化环境
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[safety-filter|Safety Filter]]
|
||||||
|
- [[safe-exploration|安全探索]]
|
||||||
|
- [[feasible-zone|可行域]]
|
||||||
37
concepts/cosine-similarity-geometry.md
Normal file
37
concepts/cosine-similarity-geometry.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "余弦相似度几何 (Cosine Similarity Geometry)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [geometry, embedding, vlm, similarity]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# 余弦相似度几何 (Cosine Similarity Geometry)
|
||||||
|
|
||||||
|
VLM 将图像和文本嵌入映射到单位球 $S^{d-1}$ 上，此时欧氏内积等价于余弦相似度。这一几何结构是 VLM 分类和语义分析的基础。
|
||||||
|
|
||||||
|
## 关键性质
|
||||||
|
|
||||||
|
- **单位球约束**：所有嵌入 $\|e\|_2 = 1$
|
||||||
|
- **相似度 ≡ 内积**：$\langle z, u \rangle = \cos(\theta_{z,u})$
|
||||||
|
- **语义强度**：嵌入与语义向量 $v_a$ 的内积 $\langle e, v_a \rangle$ 可解释为语义 $a$ 的强度
|
||||||
|
|
||||||
|
## 语义平面
|
||||||
|
|
||||||
|
对于一对语义 $(a, a')$，其文本嵌入 $u_a, u_{a'}$ 张成的二维子空间 $P_{a,a'} = \text{span}\{u_a, u_{a'}\}$ 称为语义平面（[[semantic-plane]]）。语义变化可在该平面内参数化。
|
||||||
|
|
||||||
|
## 加性语义 (Additive Semantics)
|
||||||
|
|
||||||
|
若查询嵌入 $e = \sum_i \alpha_i v_{a_i}$ 可分解为语义向量的线性组合，则其对各语义的强度也呈加性分解：
|
||||||
|
$$D_a(e) = \sum_i \alpha_i D_a(v_{a_i})$$
|
||||||
|
|
||||||
|
该性质来自内积的双线性，是 VLM 嵌入空间区别于普通神经网络的关键特征（[[additive-semantics]]）。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[dual-encoder-vlm|双编码器 VLM]]
|
||||||
|
- [[semantic-plane|语义平面]]
|
||||||
|
- [[additive-semantics|加性语义]]
|
||||||
|
- [[voronoi-decision-regions|Voronoi 决策区域]]
|
||||||
42
concepts/cosine-taper-schedule.md
Normal file
42
concepts/cosine-taper-schedule.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Cosine Taper Schedule（余弦衰减调度）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [language-model, schedule, cosine, architecture, efficiency]
|
||||||
|
sources: [[tapered-language-models]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Cosine Taper Schedule
|
||||||
|
|
||||||
|
> [[mlp-width-tapering|MLP 宽度渐缩]] 的最优调度函数——使用余弦函数将 MLP 宽度从前向后平滑递减。
|
||||||
|
|
||||||
|
## 公式
|
||||||
|
|
||||||
|
第 ℓ 层的 MLP 宽度：
|
||||||
|
|
||||||
|
> w_ℓ = w_max · (cos(πℓ/(2L)))^p
|
||||||
|
|
||||||
|
- w_max：第 0 层（首层）的宽度
|
||||||
|
- L：总层数
|
||||||
|
- p：控制 steepness（论文中使用 p ≈ 1）
|
||||||
|
|
||||||
|
## 与其他调度的对比
|
||||||
|
|
||||||
|
| 调度 | 440M Transformer perplexity | 特点 |
|
||||||
|
|------|---------------------------|------|
|
||||||
|
| Uniform | 16.28 | 基准 |
|
||||||
|
| Step-wise | 15.96 | 硬截断，不连续 |
|
||||||
|
| Linear | 15.49 | 连续但不平滑 |
|
||||||
|
| **Cosine** | **14.44** | 连续平滑，最优 |
|
||||||
|
|
||||||
|
## U 形曲线
|
||||||
|
|
||||||
|
Taper 的强度存在最优值：1.50× → 0.50× baseline d_ff。过强（1.75× → 0.25×）或过弱（1.25× → 0.75×）均不如中间值——说明存在一个最优的**容量梯度**。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[mlp-width-tapering|MLP 宽度渐缩]]
|
||||||
|
- [[depth-aware-capacity-allocation|深度感知容量分配]]
|
||||||
|
- [[tapered-language-models|Tapered Language Models]]
|
||||||
41
concepts/cross-mode-collision.md
Normal file
41
concepts/cross-mode-collision.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Cross-Mode Collision"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, parallel-generation, quality-degradation]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Cross-Mode Collision
|
||||||
|
|
||||||
|
跨模态碰撞是[[parallel-drafting|并行草稿（Parallel Drafting）]]的固有缺陷：当并行草稿器独立预测块内每个位置的 token 时，各位置边缘化所有可能的前驱分布，而非条件化于实际采样的 token，导致产生不一致的 token 序列。
|
||||||
|
|
||||||
|
## 典型示例
|
||||||
|
|
||||||
|
上下文 "Let's..." 允许多种延续：
|
||||||
|
- 路径 A: "Let's go to the"
|
||||||
|
- 路径 B: "Let me think about"
|
||||||
|
|
||||||
|
并行草稿器可能产生：
|
||||||
|
- "Let's me to the"（混合了路径 A 和 B）
|
||||||
|
- "Let go think about"（同样不连贯）
|
||||||
|
|
||||||
|
## 根本原因
|
||||||
|
|
||||||
|
每个位置 $k$ 的边缘分布 $p_k^d(x_k)$ 在所有可能的 $x_{k-1}$ 上求期望，但草稿阶段没有已确定的 $x_{k-1}$。一旦某些 token 采样了特定语义路径，后续 token 却无法利用这一已确定的方向。
|
||||||
|
|
||||||
|
## 后果
|
||||||
|
|
||||||
|
导致**后缀接受率衰减（suffix decay）**：DSpark 论文的逐位置分析显示，并行草稿器（DFlash）在 Chat 场景从位置 1 的 ~0.72 条件接受率降至位置 7 的 ~0.52，而自回归草稿器（Eagle3）反而从 ~0.53 升至 ~0.58。
|
||||||
|
|
||||||
|
## 缓解方法
|
||||||
|
|
||||||
|
- [[semi-autoregressive-generation|半自回归生成（Semi-Autoregressive Generation）]]（DSpark）：通过轻量级顺序块注入块内依赖
|
||||||
|
- [[markov-draft-head|马尔可夫草稿头（Markov Draft Head）]]：一阶转移偏置，如 "of" 后提升 "course" 抑制 "problem"
|
||||||
|
- [[rnn-draft-head|RNN 草稿头]]：循环状态累积完整前缀历史
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[parallel-drafting|并行草稿（Parallel Drafting）]]
|
||||||
|
- [[semi-autoregressive-generation|半自回归生成（Semi-Autoregressive Generation）]]
|
||||||
26
concepts/crown-verifier.md
Normal file
26
concepts/crown-verifier.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: "CROWN Verifier"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [verification, certification, bounds, neural-network]
|
||||||
|
sources: ["Zhang et al., 2018"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# CROWN Verifier
|
||||||
|
|
||||||
|
一种通过快速线性边界传播进行神经网络鲁棒性验证的方法，属于不完整确定性验证器。
|
||||||
|
|
||||||
|
## 核心思想
|
||||||
|
|
||||||
|
CROWN（CROWN: Efficient Bound Propagation）对神经网络逐层计算输出的线性上下界，利用向后传播的线性松弛快速给出每个类别的 logit 范围。相比 DeepPoly 更强调计算效率和 tightness 的平衡。
|
||||||
|
|
||||||
|
## 变体
|
||||||
|
|
||||||
|
- $\beta$-CROWN：CROWN + branch-and-bound，升级为完备验证器
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[robustness-certification|鲁棒性认证]]
|
||||||
|
- [[deep-poly|DeepPoly]]
|
||||||
|
- [[randomized-smoothing|随机平滑]]
|
||||||
26
concepts/deep-poly.md
Normal file
26
concepts/deep-poly.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: "DeepPoly"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [verification, certification, convex-relaxation, neural-network]
|
||||||
|
sources: ["Singh et al., 2019"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# DeepPoly
|
||||||
|
|
||||||
|
一种确定性不完整验证器，基于凸松弛对神经网络进行可微的抽象解释，给出 sound 但保守的鲁棒性保证。
|
||||||
|
|
||||||
|
## 核心方法
|
||||||
|
|
||||||
|
对神经网络逐层传播抽象域（abstract domain），用线性约束 over-approximate 每一层的输出范围。最终在输出层检查是否存在对抗样本。
|
||||||
|
|
||||||
|
## 在鲁棒性认证中的定位
|
||||||
|
|
||||||
|
属于**不完整验证**类别：保证找到的扰动范围内没有对抗样本（sound），但可能因过度近似而拒绝实际上安全的输入（conservative）。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[robustness-certification|鲁棒性认证]]
|
||||||
|
- [[crown-verifier|CROWN]]
|
||||||
|
- [[randomized-smoothing|随机平滑]]
|
||||||
38
concepts/depth-aware-capacity-allocation.md
Normal file
38
concepts/depth-aware-capacity-allocation.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Depth-Aware Capacity Allocation（深度感知容量分配）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [language-model, architecture, efficiency, depth, parameter-allocation]
|
||||||
|
sources: [[tapered-language-models]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Depth-Aware Capacity Allocation
|
||||||
|
|
||||||
|
> [[tapered-language-models|Tapered Language Models]] 提出的架构设计轴：在固定总参数预算下，**不**对所有层均等分配容量，而是根据层在深度中的位置进行差异化分配。
|
||||||
|
|
||||||
|
## 核心直觉
|
||||||
|
|
||||||
|
现代 LM 中各层对输出的贡献**不均匀**：
|
||||||
|
- **早期层**：构建 token 的初步表示，需要更多变换能力 → 应分配更多容量
|
||||||
|
- **后期层**：精化残差流（refine residual stream），变换幅度小 → 可以减少容量
|
||||||
|
|
||||||
|
## 设计原则
|
||||||
|
|
||||||
|
1. **固定总预算**：不增加总参数量
|
||||||
|
2. **单调递减**：容量从前向后递减
|
||||||
|
3. **MLP 作为调节轴**：MLP 宽度（d_ff）是所有 LM 架构共有的、单一干净的调节维度
|
||||||
|
|
||||||
|
## 实验验证
|
||||||
|
|
||||||
|
[[tapered-language-models|Bayat et al. (2026)]] 在 4 种架构、3 个规模上验证：
|
||||||
|
- 早期层多分配 → perplexity 改善
|
||||||
|
- 后期层多分配 → **损害**（验证了不对称性方向）
|
||||||
|
- [[cosine-taper-schedule|余弦衰减]] 表现最优
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[tapered-language-models|Tapered Language Models]]
|
||||||
|
- [[mlp-width-tapering|MLP 宽度渐缩]]
|
||||||
|
- [[cosine-taper-schedule|余弦衰减调度]]
|
||||||
34
concepts/dspy.md
Normal file
34
concepts/dspy.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "DSPy（声明式自改进 Python）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [prompt-engineering, framework, optimization, LLM]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# DSPy (Declarative Self-improving Python)
|
||||||
|
|
||||||
|
> Stanford NLP 推出的声明式框架——将 [[prompt-engineering|Prompt]] 从"人工手写"升级为"可编译、可学习的程序"。
|
||||||
|
|
||||||
|
## 核心转变
|
||||||
|
|
||||||
|
开发者**不再手写指令字符串**，而是声明输入输出的签名，交给优化器自动搜索最优 Prompt 与 Few-shot 组合。
|
||||||
|
|
||||||
|
## 关键能力
|
||||||
|
|
||||||
|
1. **签名声明**：定义 `input → output` 的语义契约
|
||||||
|
2. **自动编译**：优化器在候选空间中搜索最优 Prompt + Few-shot
|
||||||
|
3. **模型切换**：底座模型从 GPT-4 换成 Llama 时，一键重新编译即可适配
|
||||||
|
|
||||||
|
## 工程意义
|
||||||
|
|
||||||
|
- 消除手工调参的技术债务
|
||||||
|
- 模型升级不再导致已有 Prompt 集体失效
|
||||||
|
- 将 Prompt 工程从"手艺"变为"工程学科"
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[prompt-engineering|Prompt Engineering]]
|
||||||
|
- [[blind-prompting|Blind Prompting]]
|
||||||
34
concepts/dual-encoder-vlm.md
Normal file
34
concepts/dual-encoder-vlm.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "双编码器 VLM (Dual-Encoder VLM)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [architecture, multimodal, vlm]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# 双编码器 VLM (Dual-Encoder VLM)
|
||||||
|
|
||||||
|
使用独立视觉编码器和文本编码器将图像和文本分别映射到共享嵌入空间，然后通过余弦相似度进行匹配的视觉语言模型架构。
|
||||||
|
|
||||||
|
## 数学表述
|
||||||
|
|
||||||
|
- 图像 $x$ 经视觉编码器 $f_{\text{img}}$ → 单位嵌入 $z \in S^{d-1}$
|
||||||
|
- 文本 $t$ 经文本编码器 $f_{\text{text}}$ → 单位嵌入 $u \in S^{d-1}$
|
||||||
|
- 分类：$f(z) = \arg\max_c \langle z, u_c \rangle$
|
||||||
|
|
||||||
|
## 与融合型 VLM 的对比
|
||||||
|
|
||||||
|
- 双编码器：嵌入独立计算，可预先缓存文本嵌入，检索效率高
|
||||||
|
- 融合型（如 LLaVA、Flamingo）：视觉和文本在 Transformer 中交叉注意力，能力更强但计算成本高
|
||||||
|
|
||||||
|
## 对鲁棒性认证的意义
|
||||||
|
|
||||||
|
双编码器的分类器是闭式的（cosine similarity → Voronoi cells），决策边界可解析刻画，这使得 [[semantic-robustness-certification|语义鲁棒性认证]] 中的闭式分析成为可能。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[clip|CLIP]]
|
||||||
|
- [[cosine-similarity-geometry|余弦相似度几何]]
|
||||||
|
- [[voronoi-decision-regions|Voronoi 决策区域]]
|
||||||
38
concepts/dynamic-beam-serving.md
Normal file
38
concepts/dynamic-beam-serving.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Dynamic Beam Serving (DBS)"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [generative-recommendation, serving-optimization, beam-search]
|
||||||
|
sources: [GR4AD]
|
||||||
|
---
|
||||||
|
# Dynamic Beam Serving (DBS)
|
||||||
|
|
||||||
|
Dynamic Beam Serving（DBS）是 [[GR4AD]] 提出的动态束搜索服务机制，通过自适应调整束宽度在效率与效果之间取得最优权衡。
|
||||||
|
|
||||||
|
## 组成
|
||||||
|
|
||||||
|
**1. Dynamic Beam Width（DBW）**
|
||||||
|
|
||||||
|
固定束宽度在所有解码步骤中使用相同的 $B$ 是次优的。最终返回的候选数由最后一步的束宽决定，但总解码成本由早期步骤的束宽主导（它们控制传播到后续步骤的假设数）。
|
||||||
|
|
||||||
|
DBW 采用**渐进递增**的束宽调度：如将 $512\text{-}512\text{-}512$ 替换为 $128\text{-}256\text{-}512$。早期步骤使用较小束宽减少计算，后期步骤扩展到目标候选数。最终候选质量基本不受影响，但计算量大幅降低。
|
||||||
|
|
||||||
|
**2. Traffic-Aware Adaptive Beam Search（TABS）**
|
||||||
|
|
||||||
|
推荐流量存在强峰谷周期。服务约束由峰值负载决定。TABS 根据瞬时流量调整总束宽规模：
|
||||||
|
|
||||||
|
$$B_t = B_{base} \cdot f(Q_t, C_{avail})$$
|
||||||
|
|
||||||
|
- **谷值期**（$Q_t < Q_{threshold}$）：增大束宽，利用闲置计算资源进行更广泛的假设探索
|
||||||
|
- **峰值期**：维持基准束宽，保证延迟和吞吐量在预算内
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
GR4AD 中 DBS 使 QPS 提升 20%，同时在谷值期通过 60% 的束宽扩展提升收入，峰值期保持稳定。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[GR4AD]]
|
||||||
|
- [[lazyar|LazyAR]]
|
||||||
|
- [[reco-result-cache|Recommendation Result Cache]]
|
||||||
51
concepts/equilibrium-safe-exploration.md
Normal file
51
concepts/equilibrium-safe-exploration.md
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
---
|
||||||
|
title: "Equilibrium of Safe Exploration（安全探索均衡）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [safe-reinforcement-learning, equilibrium, exploration, convergence]
|
||||||
|
sources: [[safe-equilibrium-exploration]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Equilibrium of Safe Exploration
|
||||||
|
|
||||||
|
> Yang et al. (2026) 首次揭示 [[safe-exploration|安全探索]] 的真正目标：不是单方面最大化 [[feasible-zone|可行域]]，而是找到可行域与 [[uncertain-model|不确定模型]] 之间的**不动点**。
|
||||||
|
|
||||||
|
## 均衡定义
|
||||||
|
|
||||||
|
记 Z 为可行域，M 为不确定模型。均衡点 (Z*, M*) 满足：
|
||||||
|
|
||||||
|
1. **Z* 是 M* 下的最大可行域**：给定当前模型精度，不能再安全地扩展
|
||||||
|
2. **M* 是 Z* 内数据的最精确模型**：在可行域内收集的所有数据已被充分利用
|
||||||
|
|
||||||
|
## 相互依存关系
|
||||||
|
|
||||||
|
```
|
||||||
|
更大的可行域 ──→ 更多探索数据 ──→ 更精确的模型
|
||||||
|
↓
|
||||||
|
更精确的模型 ──→ 更准确的约束推断 ──→ 更大的可行域
|
||||||
|
```
|
||||||
|
|
||||||
|
## 收敛保证
|
||||||
|
|
||||||
|
[[safe-equilibrium-exploration|SEE 算法]] 的理论保证：
|
||||||
|
|
||||||
|
- 不确定模型**单调精化**（不确定性单调递减）
|
||||||
|
- 可行域**单调扩展**（永不收缩）
|
||||||
|
- 两者在有限步内收敛到均衡
|
||||||
|
|
||||||
|
## 与传统观点的区别
|
||||||
|
|
||||||
|
| 传统观点 | 均衡观点 |
|
||||||
|
|---------|---------|
|
||||||
|
| 安全探索 = 最大化可行域 | 安全探索 = 找到可行域-模型不动点 |
|
||||||
|
| 可行域和模型独立优化 | 二者交替、相互增强 |
|
||||||
|
| 隐式假设模型已足够精确 | 显式建模模型不确定性 |
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[safe-exploration|安全探索]]
|
||||||
|
- [[feasible-zone|可行域]]
|
||||||
|
- [[safe-equilibrium-exploration|SEE 算法]]
|
||||||
|
- [[uncertain-model|不确定模型]]
|
||||||
42
concepts/evaluator-metrics.md
Normal file
42
concepts/evaluator-metrics.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "评估器质量指标（Evaluator Metrics）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [evaluation, metrics, rft, rl, benchmarking]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 评估器质量指标
|
||||||
|
|
||||||
|
衡量 [[agent-evaluator|Agent 评估器]] 与 ground-truth（单元测试分数）对齐程度的多维度指标框架。
|
||||||
|
|
||||||
|
## 指标体系
|
||||||
|
|
||||||
|
| 指标 | 衡量什么 | 使用场景 |
|
||||||
|
|------|---------|---------|
|
||||||
|
| **BoN Accuracy** | 评估器能否从候选池中选出最佳样本 | RFT（小候选池） |
|
||||||
|
| **Regret** | 次优选择的质量损失 | 联合评估 |
|
||||||
|
| **Kendall's τ** | 全分数范围的排名一致性 | RL（需要细粒度梯度） |
|
||||||
|
| **Pearson r / Spearman ρ** | 宏观平均相关性 | 综合评估 |
|
||||||
|
| **Threshold-Conditioned UT Score** | 过滤后样本的平均质量 | RFT（大候选池） |
|
||||||
|
|
||||||
|
## 指标冲突
|
||||||
|
|
||||||
|
**排名能力 ≠ 过滤质量**：
|
||||||
|
- Qwen 3.7 Plus BoN-Acc (67.3%) > DeepSeek V4 Pro (54.5%)
|
||||||
|
- 但 DeepSeek 的 θ≥8 条件下 UT score (0.611) > Qwen (0.595)
|
||||||
|
|
||||||
|
## 训练目标与指标映射
|
||||||
|
|
||||||
|
| 训练目标 | 关键指标 | 关注点 |
|
||||||
|
|---------|---------|--------|
|
||||||
|
| RFT（候选充足） | Threshold-Conditioned UT Score | 低 false positive |
|
||||||
|
| RFT（候选有限） | UT Score + retained count | 平衡 FP/FN |
|
||||||
|
| RL | Kendall τ + score discrimination | 细粒度梯度 |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[agent-evaluator|Agent 评估器]]
|
||||||
33
concepts/exactline.md
Normal file
33
concepts/exactline.md
Normal file
@@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "ExactLine"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [certification, verification, interpolation, baseline]
|
||||||
|
sources: ["Sotoudeh & Thakur, 2019"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# ExactLine
|
||||||
|
|
||||||
|
一种完备认证方法，沿两张端点图像之间的线性插值路径认证预测不变区间。
|
||||||
|
|
||||||
|
## 方法
|
||||||
|
|
||||||
|
对两张图像 embedding 的线性插值路径 $\gamma(\lambda) = (1-\lambda)z_0 + \lambda z_1$，基于神经网络的分段线性性质，精确找出决策边界的所有穿越点（crossing points），将插值区间划分为若干预测不变子区间。
|
||||||
|
|
||||||
|
## 在语义认证中的定位
|
||||||
|
|
||||||
|
ExactLine 是 [[semantic-robustness-certification-vlm-2026|Semantic Robustness Certification (ICML 2026)]] 的主要基线。区别在于：
|
||||||
|
- ExactLine 需要**两张端点图像**作为输入
|
||||||
|
- Semantic Robustness Certification 只需**一对文本 prompt**，无需参考图像
|
||||||
|
|
||||||
|
## 局限
|
||||||
|
|
||||||
|
- 需要辅助输入（端点图像），不适合仅有文本描述的场景
|
||||||
|
- 线性插值在 VLM 嵌入空间中的语义一致性有限（与本文方法对比的实验结论）
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[robustness-certification|鲁棒性认证]]
|
||||||
|
- [[semantic-robustness-certification-vlm-2026|Semantic Robustness Certification (ICML 2026)]]
|
||||||
|
- [[prediction-invariant-intervals|预测不变区间]]
|
||||||
36
concepts/feasible-zone.md
Normal file
36
concepts/feasible-zone.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Feasible Zone（可行域）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [safe-reinforcement-learning, safety, constraint, RL]
|
||||||
|
sources: [[safe-equilibrium-exploration]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Feasible Zone（可行域）
|
||||||
|
|
||||||
|
> [[safe-exploration|安全探索]] 中的核心概念：状态-动作空间的子集，从其中任意点出发存在策略能保证所有未来状态满足安全约束。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
在约束 MDP 中，可行域 Z 满足：∀(s,a) ∈ Z，∃ 策略 π 使得将所有未来轨迹保持在约束满足区域内。
|
||||||
|
|
||||||
|
## 关键属性
|
||||||
|
|
||||||
|
1. **安全保证**：只要在 Z 内行动，永远不会违反约束
|
||||||
|
2. **大小决定效用**：Z 太小 → 策略无法完成任务；Z 越大 → 收集高奖励数据的可能越大
|
||||||
|
3. **与模型耦合**：Z 的识别依赖于环境模型的精度；模型只在 Z 内准确 → 形成循环
|
||||||
|
|
||||||
|
## 传统方法的局限
|
||||||
|
|
||||||
|
- [[safety-filter|Safety Filter]] 依赖人类设计的约束定义 Z → 保守且不完整
|
||||||
|
- [[control-barrier-function|CBF]] 提供数学保证但需要系统动力学知识
|
||||||
|
- [[safe-equilibrium-exploration|SEE]] 自动发现最大可行域，无需人工设计
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[safe-exploration|安全探索]]
|
||||||
|
- [[equilibrium-safe-exploration|安全探索均衡]]
|
||||||
|
- [[safety-filter|Safety Filter]]
|
||||||
|
- [[uncertain-model|不确定模型]]
|
||||||
45
concepts/formal-theorem-proving.md
Normal file
45
concepts/formal-theorem-proving.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "形式化定理证明（Formal Theorem Proving）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["mathematics", "formal-verification", "theorem-proving", "lean"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 形式化定理证明
|
||||||
|
|
||||||
|
> 在机器可检查语言中编写证明，由严格内核（如 Lean、Isabelle、Coq）自动验证——解决自然语言证明不可靠的问题。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**形式化定理证明** (Formal Theorem Proving, FTP / ATP) 是将数学证明用形式化语言编码，使得证明的正确性可以被机器自动验证。与自然语言（informal）数学推理不同，形式化证明提供了**保证的准确性**。
|
||||||
|
|
||||||
|
## 主要系统
|
||||||
|
|
||||||
|
| 系统 | 类型 | 特点 |
|
||||||
|
|------|------|------|
|
||||||
|
| Lean (Moura & Ullrich, 2021) | 依赖类型 | 活跃社区，mathlib4 库 |
|
||||||
|
| Isabelle (Nipkow et al., 2002) | 高阶逻辑 | 成熟的自动化工具 |
|
||||||
|
| Coq (Huet et al., 1997) | 构造演算 | 经典系统，丰富的库 |
|
||||||
|
| HOL Light (Harrison, 2009) | 高阶逻辑 | 轻量级内核 |
|
||||||
|
|
||||||
|
## 核心挑战
|
||||||
|
|
||||||
|
通用 LLM 在自然语言数学推理上表现强劲，但生成可验证的形式化证明仍然困难：
|
||||||
|
- 自然语言证明常含逻辑谬误和幻觉
|
||||||
|
- 验证瓶颈：Kepler 猜想经过 4 年同行评审才能声称「99% 确定」，最终需要十年形式化验证
|
||||||
|
- 非形式化到形式化的翻译鸿沟（[[autoformalization|自动形式化]]）
|
||||||
|
|
||||||
|
## 当前进展
|
||||||
|
|
||||||
|
- 专用证明器模型：AlphaProof、DeepSeek Prover V2、Seed Prover、Goedel Prover V2
|
||||||
|
- Agentic 框架：[[leap-agentic-atp|LEAP]]（仅用通用 LLM 达到 SOTA）、Hilbert、Aristotle
|
||||||
|
- 基准：MiniF2F、PutnamBench、[[lean-imo-bench|Lean-IMO-Bench]]
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[lean-proof-assistant|Lean 证明助手]]
|
||||||
|
- [[autoformalization|自动形式化]]
|
||||||
|
- [[lean-imo-bench|Lean-IMO-Bench]]
|
||||||
@@ -1,38 +1,40 @@
|
|||||||
---
|
---
|
||||||
title: "生成式推荐 (Generative Recommendation)"
|
title: "Generative Recommendation"
|
||||||
created: 2026-06-10
|
created: 2026-06-28
|
||||||
updated: 2026-06-10
|
updated: 2026-06-28
|
||||||
type: concept
|
type: concept
|
||||||
tags: [recommendation, generative-model, paradigm]
|
tags: [recommender-systems, generative-models, llm, semantic-id]
|
||||||
sources: [raw/papers/onereason-team-onereason-2026.md]
|
sources: [GR4AD]
|
||||||
---
|
---
|
||||||
|
# Generative Recommendation
|
||||||
|
|
||||||
# 生成式推荐 (Generative Recommendation)
|
生成式推荐（Generative Recommendation）将推荐系统重构为**端到端生成任务**：通过[[semantic-id|Semantic ID]]将物品编码为离散 token 序列，再用序列模型逐 token 预测下一个物品的 ID，将推荐转化为 next-token prediction。相比传统 DLRM（Deep Learning Recommendation Model）的 embedding-based 检索+排序两阶段架构，生成式推荐具有更强的扩展潜力和模型容量。
|
||||||
|
|
||||||
> 将推荐任务建模为序列生成问题，用生成式模型直接预测下一个 item 的推荐范式。
|
## 核心流程
|
||||||
|
|
||||||
## 定义
|
1. **Tokenization**：将物品（广告创意、商品等）映射为离散的语义 ID 序列——通常是多级层次结构（如 $s_1, s_2, ..., s_T$），每级对应语义空间中的不同粒度簇
|
||||||
|
2. **生成**：基于用户上下文 $X$，自回归地生成目标物品的 ID 序列 $P(y|X) = \prod_{t=1}^T P(s_t|X, s_{<t})$
|
||||||
|
3. **解码**：将生成的 ID 序列通过索引反向查找对应的物品列表，返回给用户
|
||||||
|
|
||||||
生成式推荐将推荐重新表述为序列生成：给定用户历史行为序列，模型直接生成下一个推荐 item（以 [[itemic-tokens|itemic token]] 形式）。这与传统推荐（embedding 匹配 + top-K 检索）形成根本差异。
|
## 关键挑战
|
||||||
|
|
||||||
## 核心思想
|
在**大规模广告场景**中部署生成式推荐面临三项独特挑战：
|
||||||
|
|
||||||
- **统一生成框架**：将召回、排序、重排统一为一个端到端生成过程
|
1. **广告 Tokenization**：广告创意融合了视频属性、产品细节、B2B 广告主元数据等多模态多粒度信息，且存在转化类型、广告账户等非语义业务信号
|
||||||
- **Scaling 优势**：像 LLM 一样，模型和数据的扩展带来持续性能提升
|
2. **学习范式**：广告推荐优化的是列表级业务目标（eCPM、NDCG），而非逐 item 的分类正确率。LLM 风格的 per-item 监督学习方法不足
|
||||||
- **跨域泛化**：生成式模型天然支持跨域推荐
|
3. **实时服务**：必须在高流量、严格延迟约束下生成多候选高质量列表，不能容忍 LLM 式的长解码延迟
|
||||||
|
|
||||||
## 代表工作
|
## 代表系统
|
||||||
|
|
||||||
- [[onerec|OneRec 系列]]（快手）：工业级生成式推荐，多业务线部署
|
| 系统 | 关键创新 | 部署规模 |
|
||||||
- 在短视频、直播、广告、电商等场景验证
|
|------|---------|---------|
|
||||||
|
| TIGER | 分层 RQ-VAE Semantic ID | 学术 |
|
||||||
## 核心挑战
|
| OneRec | 检索+排序统一生成 | 快手 |
|
||||||
|
| [[GR4AD]] | UA-SID + LazyAR + RSPO | 快手 4 亿用户 |
|
||||||
- **推理能力缺失**：纯 item token 序列无法支撑 [[chain-of-thought|CoT]] 推理
|
| GPR | 广告生成式检索 | 学术 |
|
||||||
- **[[itemic-text-alignment|语义对齐]]**：item token 与自然语言的跨模态对齐
|
|
||||||
|
|
||||||
## 参考
|
## 参考
|
||||||
|
|
||||||
- [[onerec|OneRec]]
|
- [[GR4AD]] — Kuaishou 广告生成式推荐系统
|
||||||
- [[onereason|OneReason]]
|
- [[semantic-id|Semantic ID]]
|
||||||
- [[itemic-tokens|Itemic Token]]
|
- [[ua-sid|UA-SID]]
|
||||||
|
|||||||
33
concepts/goodharts-law.md
Normal file
33
concepts/goodharts-law.md
Normal file
@@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "Goodhart's Law"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [verification, reward-design, evaluation, proxy-measures]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# Goodhart's Law
|
||||||
|
|
||||||
|
**Goodhart 定律**：当一个度量一旦被用作优化目标，它就不再是一个好的度量（"When a measure becomes a target, it ceases to be a good measure"）。
|
||||||
|
|
||||||
|
## 核心机制
|
||||||
|
|
||||||
|
在 AI agent 训练中，Goodhart 定律表现为 **reward hacking**：模型学会利用评估指标（proxy）与真实意图（intent）之间的差异，在指标上获得高分却未真正满足用户需求。
|
||||||
|
|
||||||
|
## 三阶段过程
|
||||||
|
|
||||||
|
1. **Proxy 建立**：选择一个可计算的度量作为用户意图的近似（如 test pass rate）
|
||||||
|
2. **优化压力**：模型在 RL/SFT 训练中最大化该度量
|
||||||
|
3. **度量腐化**：模型发现并利用 proxy 与 intent 之间的 gap → 指标虚高，真实质量下降
|
||||||
|
|
||||||
|
## 与 Verification Horizon 的关系
|
||||||
|
|
||||||
|
Goodhart 定律是 [[verification-horizon|验证边界]] 的理论基础：任何固定奖励函数最终都会在持续优化下失效，验证器必须与生成器 [[verifier-generator-coevolution|协同进化]]。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[reward-hacking]]
|
||||||
|
- [[verification-horizon]]
|
||||||
|
- [[intent-underspecification]]
|
||||||
|
- Manheim & Garrabrant (2018): Categorizing Variants of Goodhart's Law
|
||||||
35
concepts/graphrag.md
Normal file
35
concepts/graphrag.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "GraphRAG（知识图谱增强检索）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [context-engineering, retrieval, knowledge-graph, RAG]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# GraphRAG
|
||||||
|
|
||||||
|
> [[context-engineering|Context Engineering]] 的核心方法论之一：用实体关系网络取代传统向量相似度，将"段落检索"升级为"语义关联"。
|
||||||
|
|
||||||
|
## 与传统 RAG 的区别
|
||||||
|
|
||||||
|
| 维度 | 传统 RAG | GraphRAG |
|
||||||
|
|------|---------|----------|
|
||||||
|
| 检索单元 | 文本段落 | 实体 + 关系 |
|
||||||
|
| 相似度 | 向量余弦 | 图结构（实体关系网络） |
|
||||||
|
| 多跳推理 | 差 | 天然支持 |
|
||||||
|
| 可解释性 | 低（"相似"无法解释） | 高（可追踪推理路径） |
|
||||||
|
| 合规审计 | 困难 | 可溯源 |
|
||||||
|
|
||||||
|
## 解决的核心问题
|
||||||
|
|
||||||
|
- **多跳推理**：需要跨多篇文档组合信息的问题
|
||||||
|
- **可解释性**：回答"为什么给我这个结果"
|
||||||
|
- **合规审计**：需要溯源的领域（法律、金融）
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-engineering|Context Engineering]]
|
||||||
|
- [[minimum-viable-context|MVC]]
|
||||||
|
- [[just-in-time-retrieval|JIT 检索]]
|
||||||
48
concepts/hardware-aware-prefix-scheduler.md
Normal file
48
concepts/hardware-aware-prefix-scheduler.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "Hardware-Aware Prefix Scheduler"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, llm-serving, scheduling, throughput-optimization]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Hardware-Aware Prefix Scheduler
|
||||||
|
|
||||||
|
硬件感知前缀调度器是 [[DSpark]] 的核心系统级创新，将投机解码的验证长度选择形式化为**全局吞吐量最大化问题**。与静态阈值方法不同，调度器根据实时引擎负载动态为每个请求分配验证预算。
|
||||||
|
|
||||||
|
## 问题形式化
|
||||||
|
|
||||||
|
考虑 $R$ 个活跃请求的批次。请求 $r$ 的置信度序列为 $\{c_{r,1}, ..., c_{r,\gamma}\}$，前缀存活概率为累积乘积 $a_{r,j} = \prod_{i \le j} c_{r,i}$。
|
||||||
|
|
||||||
|
总批大小：$B = \sum_{r=1}^{R} (1 + \ell_r)$
|
||||||
|
|
||||||
|
期望接受 token 数：$\tau = \sum_{r=1}^{R} \left(1 + \sum_{j=1}^{\ell_r} a_{r,j}\right)$
|
||||||
|
|
||||||
|
目标：最大化期望系统吞吐量 $\Theta = \tau \cdot \text{SPS}(B)$，其中 $\text{SPS}(B)$ 是预录的引擎吞吐量表（steps per second vs batch size）。
|
||||||
|
|
||||||
|
## 贪心算法（Algorithm 1）
|
||||||
|
|
||||||
|
1. 全局排序所有候选前缀扩展（按 $a_{r,j}$ 降序）
|
||||||
|
2. 逐条接纳最高存活概率的 token，$O(1)$ 查表更新 $\Theta$
|
||||||
|
3. **早停**：$\Theta$ 下降时立即停止——确保因果性（不泄露未来 token 信息），满足 lossless speculative decoding 的非预期性（non-anticipating property）
|
||||||
|
|
||||||
|
## 生产适配（Section 5.2）
|
||||||
|
|
||||||
|
理论算法在真实基础设施中面临两个冲突：
|
||||||
|
|
||||||
|
**异步调度**：ZOS（Zero-Overhead Scheduling）要求下一步的批大小在当前步完成前已知。方案：使用两步前的置信度输出来估计截断容量 $K$，将入场过程转化为动态 top-$K$ 选择——排序保持精确，仅容量估计有轻微延迟。
|
||||||
|
|
||||||
|
**非平滑硬件曲线**：真实 $\text{SPS}(B)$ 呈锯齿状阶梯退化，早停可能陷入局部最小。方案：移除早停，做无约束全局搜索——ZOS 驱动的异步设计天然形成因果屏障（截断决策依赖两步前的历史预测），避免了未来 token 泄露。
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
在 DeepSeek-V4 生产部署中（Section 5.4）：
|
||||||
|
- 轻负载时自动分配更长验证预算（从 MTP-1 的静态 2 token 扩展到 4-6 token）
|
||||||
|
- 高并发时自动收缩验证长度，防止资源争用
|
||||||
|
- 将服务 Pareto 前沿外移：V4-Flash 在中等 SLA 下吞吐量提升 51%，V4-Pro 提升 52%
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[confidence-scheduled-verification|置信度调度验证（Confidence-Scheduled Verification）]]
|
||||||
|
- [[prefix-survival-probability|前缀存活概率（Prefix Survival Probability）]]
|
||||||
40
concepts/harness-as-a-service.md
Normal file
40
concepts/harness-as-a-service.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Harness-as-a-Service（脚手架即服务）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [harness-engineering, platform, loop-engineering, infrastructure]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Harness-as-a-Service (HaaS)
|
||||||
|
|
||||||
|
> 将 **Worktree + Skills + Connector + Subagent + State** 封装为标准底座的模式（Addy Osmani, 2026）。使 [[loop-engineering|Loop Engineering]] 从手工搭建变为平台化部署。
|
||||||
|
|
||||||
|
## 标准底座组件
|
||||||
|
|
||||||
|
| 组件 | 标准化形式 |
|
||||||
|
|------|-----------|
|
||||||
|
| Worktree | 并行隔离工作区 |
|
||||||
|
| Skills | SKILL.md 规范 + 渐进式披露 |
|
||||||
|
| Connector | [[mcp|MCP]] 标准协议 |
|
||||||
|
| Subagent | 多 Agent 编排配置（如 `.codex/agents/`） |
|
||||||
|
| State | 落盘持久化状态文件 |
|
||||||
|
|
||||||
|
## 业界实现
|
||||||
|
|
||||||
|
- **Claude Code**：内置 `/loop` 指令、SKILL.md 规范、Subagent Team 编排
|
||||||
|
- **Codex**：自动化面板 + 多 Agent 配置规范（`.codex/agents/`）
|
||||||
|
- **Hermes Agent**：Cron + Kanban + Skills + Sub-agents + State 文件
|
||||||
|
|
||||||
|
## 工程意义
|
||||||
|
|
||||||
|
HaaS 使得 Loop Engineering 从"每个团队自己造轮子"变为"选用标准底座 + 配置策略"。开发者不再需要实现 Cron、进程隔离、工具注册等基础机制，只需配置 [[loop-contract|Loop Contract]] 的策略层。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
|
- [[mechanism-policy-separation|机制与策略分离]]
|
||||||
|
- [[mcp|MCP]]
|
||||||
@@ -42,8 +42,19 @@ sources: ["https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"]
|
|||||||
- 从"代码约束"扩展到"行为准则约束"
|
- 从"代码约束"扩展到"行为准则约束"
|
||||||
- 与 [[heuristic-learning|Heuristic Learning]] 融合
|
- 与 [[heuristic-learning|Heuristic Learning]] 融合
|
||||||
|
|
||||||
|
## 生产级原则
|
||||||
|
|
||||||
|
八条非妥协原则（Tort Mario, 2026）：详见 [[model-proposes-harness-executes|Model Proposes, Harness Executes]]。
|
||||||
|
|
||||||
|
## 四阶段定位
|
||||||
|
|
||||||
|
Harness Engineering 是 [[prompt-to-harness-evolution|四阶段演进]] 的第三层，被 [[loop-engineering|Loop Engineering]] 所包含：**Prompt ⊂ Context ⊂ Harness ⊂ Loop**。
|
||||||
|
|
||||||
## 相关
|
## 相关
|
||||||
|
|
||||||
- [[model-harness-relationship]] — Model-Harness 关系
|
- [[model-harness-relationship]] — Model-Harness 关系
|
||||||
- [[autoharness]] — 核心方法
|
- [[autoharness]] — 核心方法
|
||||||
- [[compiled-ai-paradigm]] — 编译型 AI
|
- [[compiled-ai-paradigm]] — 编译型 AI
|
||||||
|
- [[model-proposes-harness-executes]] — 八条非妥协原则
|
||||||
|
- [[skill-issue-framework]] — Skill Issue 框架
|
||||||
|
- [[prompt-to-loop-engineering-2026]] — Datawhale 四阶段综述
|
||||||
|
|||||||
40
concepts/human-implicit-reward-signals.md
Normal file
40
concepts/human-implicit-reward-signals.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "人类隐式奖励信号（Human Implicit Reward Signals）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [user-feedback, reward-signal, annotation, coding-agent]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 人类隐式奖励信号（HIRS）
|
||||||
|
|
||||||
|
从用户-Agent 交互轨迹中提取的隐式评估信号——用户通常不提供显式数值奖励，而是通过自然语言和行为模式间接表达验证判断。
|
||||||
|
|
||||||
|
## 信号特征
|
||||||
|
|
||||||
|
基于 Qwen Team 标注的 125,528 条轨迹、535,737 轮级别标注：
|
||||||
|
|
||||||
|
| 特征 | 数据 |
|
||||||
|
|------|------|
|
||||||
|
| Polarity 分布 | Neutral 76.6% / Negative 20.0% / Positive 3.5% |
|
||||||
|
| 负信号置信度 | 81.8% high-confidence（vs neutral 仅 18.7%） |
|
||||||
|
| 主要错误类型 | Execution Error 56.6% + Misunderstand 21.1% = 77.7% |
|
||||||
|
|
||||||
|
## 标注 Pipeline
|
||||||
|
|
||||||
|
LLM-as-Judge（Qwen-Plus），三个原则：
|
||||||
|
1. **双视角评估**：同时记录 polarity + user_fairness（两者允许不一致）
|
||||||
|
2. **证据驱动**：每个标注必须引用用户原文作为证据
|
||||||
|
3. **保守标注**：模糊信号倾向 neutral
|
||||||
|
|
||||||
|
## 与验证器的关系
|
||||||
|
|
||||||
|
用户是最忠实的验证器：信号直接来自意图持有者，天然 faithful + 相对 robust。挑战在于 scalability——需大规模用户基数才能产生足够训练数据。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[span-kto|Span-KTO]]
|
||||||
|
- [[verification-trilemma|验证三难]]
|
||||||
40
concepts/hypernetworks.md
Normal file
40
concepts/hypernetworks.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "HyperNetworks: 生成网络权重的元网络"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [meta-learning, weight-generation, neural-architecture]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# HyperNetworks
|
||||||
|
|
||||||
|
HyperNetworks（超网络）是一类元学习架构：一个较小的网络（hypernetwork）生成另一个网络（target network）的权重，而非直接训练目标网络。
|
||||||
|
|
||||||
|
## 核心机制
|
||||||
|
|
||||||
|
典型公式：对目标网络第 j 层权重 W_j，由 hypernetwork h(·; φ) 生成：
|
||||||
|
|
||||||
|
$$W_j = h(z_j; \phi)$$
|
||||||
|
|
||||||
|
其中 z_j 是层次特定的隐编码（latent code）。
|
||||||
|
|
||||||
|
## 与 Mapping Networks 的区别
|
||||||
|
|
||||||
|
| 维度 | HyperNetworks | Mapping Networks |
|
||||||
|
|------|--------------|------------------|
|
||||||
|
| 目标网络训练 | 与 hypernetwork **同时训练** | **不训练**，仅前向 |
|
||||||
|
| 参数缩减 | 有限（hypernetwork 本身也有参数） | 极显著（200-500×） |
|
||||||
|
| 理论保证 | 无 | Mapping Theorem + Solvability Theorem |
|
||||||
|
| 稳定性 | 可能不稳定 | Mapping Loss 强制 Lipschitz + C² 连续性 |
|
||||||
|
|
||||||
|
## 变体
|
||||||
|
|
||||||
|
- **Dynamic HyperNetworks**：根据输入条件动态生成权重
|
||||||
|
- **Scale-Space HyperNetworks**：用于生物医学图像的高效分析
|
||||||
|
- **Chunked HyperNetworks**：分块生成权重以处理大网络
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- Ha et al., "HyperNetworks", ICLR 2017
|
||||||
|
- [[sen-mapping-networks|Mapping Networks]] — 提出者将 MN 定位为一种满足解析定理的新型 HyperNetwork
|
||||||
35
concepts/intent-underspecification.md
Normal file
35
concepts/intent-underspecification.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "意图欠定性（Intent Underspecification）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [verification, intent, specification, evaluation]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 意图欠定性（Intent Underspecification）
|
||||||
|
|
||||||
|
**意图欠定性**是验证困难的根本原因之一：用户的真实意图天然是欠定的——用户自己往往无法在见到反例之前完整表达期望。
|
||||||
|
|
||||||
|
## 双重困难
|
||||||
|
|
||||||
|
1. **忠实验证意图本身就很难**：意图欠定意味着无法穷举所有"正确"的定义
|
||||||
|
2. **优化放大差距**：当 proxy 作为训练信号时，模型学习的是如何满足 proxy 而非意图 → proxy-intent gap 随优化增大
|
||||||
|
|
||||||
|
## 表现形式
|
||||||
|
|
||||||
|
在 [[test-driven-rewards|测试驱动奖励]] 中体现为：
|
||||||
|
- **Instruction 不清晰**：任务描述引用不可访问的外部资源（如 Slack 讨论）
|
||||||
|
- **Test-instruction 不对齐**：测试验证的功能与描述的任务正交
|
||||||
|
- **反例预测困难**：维护者无法预见到所有 corner case
|
||||||
|
|
||||||
|
## 与 Verification Horizon 的关系
|
||||||
|
|
||||||
|
意图欠定性是 [[verification-horizon|验证边界]] 的第一推动力：因为 intent 永远无法被完美形式化，任何固定验证器最终都会被超越。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[goodharts-law|Goodhart 定律]]
|
||||||
|
- [[agentic-quality-judge|Agent 质量判断器]]
|
||||||
39
concepts/interactive-judge.md
Normal file
39
concepts/interactive-judge.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "交互式判断器（Interactive Judge）"
|
||||||
|
created: 2026-07-02
|
||||||
|
updated: 2026-07-02
|
||||||
|
type: concept
|
||||||
|
tags: [verification, frontend, judge, playwright, interaction]
|
||||||
|
sources:
|
||||||
|
- "[[verification-horizon-no-silver-bullet]]"
|
||||||
|
---
|
||||||
|
|
||||||
|
# 交互式判断器（Interactive Judge）
|
||||||
|
|
||||||
|
用于前端任务的 Agent 判断器，通过模拟真实用户交互来评估生成页面，抵抗静态判断器的长度利用。
|
||||||
|
|
||||||
|
## 三阶段 Pipeline
|
||||||
|
|
||||||
|
1. **Action Planning**（单次前向传递）：Action Planner 从任务规范和页面信息（accessibility tree、browser state、keyboard listeners）一次性生成完整 action list
|
||||||
|
2. **Render Execution**：Playwright server 在真实浏览器中执行 action list，录制交互轨迹（screenshots、DOM changes、console output）
|
||||||
|
3. **Scoring**：Judge model 根据 rubric checklist 评估交互轨迹 + 源码
|
||||||
|
|
||||||
|
## 关键优势
|
||||||
|
|
||||||
|
- **抵抗长度利用**：奖励来自运行时行为，而非源码长度 → 模型无法通过生成冗余 CSS/JS 骗分
|
||||||
|
- **覆盖动态行为**：多页导航、动画、状态转换、表单验证 → 静态截图无法捕获
|
||||||
|
- **效率**：单 pass 生成 action list（vs 迭代 agent loop），降低推理成本
|
||||||
|
|
||||||
|
## 对比静态判断器
|
||||||
|
|
||||||
|
| 特征 | Static Judge | Interactive Judge |
|
||||||
|
|------|:---:|:---:|
|
||||||
|
| 评估依据 | 源码 + 静态截图 | 运行时交互行为 |
|
||||||
|
| 长度利用 | 易被利用 | 抵抗 |
|
||||||
|
| 动态行为 | 无法覆盖 | 可覆盖 |
|
||||||
|
| 成本 | 低 | 中 |
|
||||||
|
|
||||||
|
## 参<><E58F82>
|
||||||
|
|
||||||
|
- [[verification-horizon-no-silver-bullet|论文原文]]
|
||||||
|
- [[rubric-based-evaluation|量规评估]]
|
||||||
42
concepts/interleaved-informal-formal-planning.md
Normal file
42
concepts/interleaved-informal-formal-planning.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "非正式-形式化交错规划（Interleaved Informal-Formal Planning）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["theorem-proving", "planning", "llm", "lean"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 非正式-形式化交错规划
|
||||||
|
|
||||||
|
> LLM 擅长非正式推理和策略生成，Lean 擅长严格验证——交错规划让二者各司其职。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**非正式-形式化交错规划** 是 [[leap-agentic-atp|LEAP]] 的设计原则：在每个证明步骤中，先以自然语言做策略规划，再翻译为形式化 Lean 代码。这利用了 LLM 和 Lean 的互补优势。
|
||||||
|
|
||||||
|
## 两条路径中的体现
|
||||||
|
|
||||||
|
### 直接证明路径
|
||||||
|
|
||||||
|
1. LLM 生成**非正式论证**（自然语言）→ 翻译为 Lean 候选证明
|
||||||
|
2. Lean 编译器验证 → 失败则 LLM 修正非正式论证 → 重新翻译
|
||||||
|
|
||||||
|
### 分解路径（[[blueprint-driven-atp|蓝图驱动]]）
|
||||||
|
|
||||||
|
1. LLM 生成**非正式蓝图**（说明如何归约为子目标）
|
||||||
|
2. 翻译为 Lean 证明草图 → 记录依赖关系
|
||||||
|
3. 每个子目标递归进入非正式 → 形式化循环
|
||||||
|
|
||||||
|
## 为什么需要交错
|
||||||
|
|
||||||
|
- 形式化代码直接生成极脆弱：一步错误整个证明报废
|
||||||
|
- 非正式草图提供**规划空间**——在形式化之前先理顺策略
|
||||||
|
- 可解释性：每个形式化尝试都有对应的非正式理由，方便审查
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[blueprint-driven-atp|蓝图驱动 ATP]]
|
||||||
|
- [[autoformalization|自动形式化]]
|
||||||
|
- [[verification-guided-proof-search|验证引导证明搜索]]
|
||||||
36
concepts/intrinsic-dimension.md
Normal file
36
concepts/intrinsic-dimension.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Intrinsic Dimension: 参数空间的内在维度"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [dimensionality-reduction, loss-landscape, manifold-learning]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Intrinsic Dimension (内在维度)
|
||||||
|
|
||||||
|
Intrinsic Dimension (ID) of objective landscapes 指深度网络损失函数实际依赖的有效参数维度——通常远小于名义参数数量 P。
|
||||||
|
|
||||||
|
## 关键研究
|
||||||
|
|
||||||
|
Li et al. (2018) 发现：通过在随机低维子空间中优化（而非完整 P 维空间），深度网络仍能达到接近全参数训练的性能。这意味着：
|
||||||
|
|
||||||
|
$$\text{ID} \ll P$$
|
||||||
|
|
||||||
|
例如，某些任务上仅需几百个参数方向即可取得 90%+ 精度。
|
||||||
|
|
||||||
|
## 与 Weight-Manifold Hypothesis 的关联
|
||||||
|
|
||||||
|
ID 研究为 [[weight-manifold-hypothesis|Weight-Manifold Hypothesis]] 提供了间接经验证据：
|
||||||
|
- 若参数空间的有效维度远小于 P，则参数很可能位于低维子流形上
|
||||||
|
- 这意味着训练中实际"探索"的自由度远小于参数总数
|
||||||
|
|
||||||
|
## Mapping Networks 如何利用 ID
|
||||||
|
|
||||||
|
Mapping Networks 的**隐向量维度 d** 本质上是架构对 ID 的显式估计。通过在 d 维空间优化而非 P 维，直接将内在维度的理论洞察转化为架构设计。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- Li et al., "Measuring the Intrinsic Dimension of Objective Landscapes", ICLR 2018
|
||||||
|
- [[loss-landscape]]
|
||||||
|
- [[manifold-hypothesis]]
|
||||||
40
concepts/just-in-time-retrieval.md
Normal file
40
concepts/just-in-time-retrieval.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Just-in-Time Retrieval（即时检索）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [context-engineering, retrieval, optimization]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Just-in-Time Retrieval (JIT Retrieval)
|
||||||
|
|
||||||
|
> [[context-engineering|Context Engineering]] 的核心方法论之一：初始阶段仅维护资料的轻量引用（如路径或 ID），运行时按需实时加载。
|
||||||
|
|
||||||
|
## 设计哲学
|
||||||
|
|
||||||
|
借鉴制造业的 JIT（Just-in-Time）生产理念：
|
||||||
|
|
||||||
|
- **不全量预加载**：不在请求开始时把所有可能需要的资料塞入上下文
|
||||||
|
- **按需拉取**：模型在执行中识别需要时，通过引用（路径/ID）触发加载
|
||||||
|
- **与渐进式披露配合**：先暴露名称或摘要，模型判断需要时再展开完整内容
|
||||||
|
|
||||||
|
## 业界实践
|
||||||
|
|
||||||
|
- **Anthropic Skills**：采用 JIT 设计哲学——Skills 不预加载全文，模型按需调用
|
||||||
|
- **Hermes Agent Skills**：`skill_view(name)` 模式——先列出名称，按需加载 SKILL.md
|
||||||
|
|
||||||
|
## 与相关模式的对比
|
||||||
|
|
||||||
|
| 模式 | 加载时机 | 上下文占用 |
|
||||||
|
|------|---------|-----------|
|
||||||
|
| 全量预加载 | 请求开始 | 最大 |
|
||||||
|
| [[minimum-viable-context|MVC]] | 请求开始时精选 | 中等 |
|
||||||
|
| JIT 检索 | 运行时按需 | 最小 |
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-engineering|Context Engineering]]
|
||||||
|
- [[minimum-viable-context|MVC]]
|
||||||
|
- [[context-failure-modes|上下文故障模式]]
|
||||||
35
concepts/kv-injection.md
Normal file
35
concepts/kv-injection.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "KV Injection"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, feature-transfer, draft-architecture]
|
||||||
|
sources: [DFlash, DSpark]
|
||||||
|
---
|
||||||
|
# KV Injection
|
||||||
|
|
||||||
|
KV 注入（KV Injection）是 [[DFlash]]（及继承其骨干的 [[DSpark]]）中使用的目标模型上下文特征注入技术。草稿模型在 prefill 阶段从目标模型的选定层提取隐藏状态，经过投影后注入草稿模型的每一层。
|
||||||
|
|
||||||
|
## 机制
|
||||||
|
|
||||||
|
**上下文特征提取**：
|
||||||
|
|
||||||
|
$$H_{ctx} = \text{RMSNorm}\left(W_c [H^{(l_1)}; ...; H^{(l_m)}]\right)$$
|
||||||
|
|
||||||
|
其中 $W_c \in \mathbb{R}^{d \times md}$ 是共享投影矩阵，$\{l_1, ..., l_m\}$ 是选定的目标模型层。
|
||||||
|
|
||||||
|
**层内注入**：在草稿模型的每一层的 key 和 value 计算中，将注入的上下文特征沿序列维度拼接到草稿块表示之前：
|
||||||
|
|
||||||
|
$$K_i = [W_i^K H_{ctx}; W_i^K H_d], \quad V_i = [W_i^V H_{ctx}; W_i^V H_d]$$
|
||||||
|
|
||||||
|
块内所有位置双向注意力到彼此及注入的目标上下文。
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
KV 注入使得草稿模型能利用目标模型的**丰富上下文表示**，大幅提升预测质量。这是并行草稿器能在位置 1 上超过浅层自回归草稿器的关键——目标模型的深层语义表示直接流向草稿模型。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DFlash]]
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[parallel-drafting|并行草稿（Parallel Drafting）]]
|
||||||
51
concepts/layer-wise-training.md
Normal file
51
concepts/layer-wise-training.md
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
---
|
||||||
|
title: "Layer-wise Training (LWT): 逐层训练策略"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [mapping-networks, training-strategy, memory-efficiency]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Layer-wise Training (LWT)
|
||||||
|
|
||||||
|
Layer-wise Training (LWT) 是 [[sen-mapping-networks|Mapping Networks]] 的两种训练策略之一：为**每一层**分配独立的隐向量来生成该层的参数，而非使用单个隐向量生成全部参数。
|
||||||
|
|
||||||
|
## 动机
|
||||||
|
|
||||||
|
SLVT（单隐向量训练）中，目标网络越大，映射网络的固定权重越多 → 内存需求线性增长。LWT 通过**分解生成任务**解决了此问题。
|
||||||
|
|
||||||
|
## 机制
|
||||||
|
|
||||||
|
```
|
||||||
|
Layer 1: z_1 (d_1 维) → Mapping_1 → θ̂^(1) → Layer 1 前向
|
||||||
|
Layer 2: z_2 (d_2 维) → Mapping_2 → θ̂^(2) → Layer 2 前向
|
||||||
|
...
|
||||||
|
Layer L: z_L (d_L 维) → Mapping_L → θ̂^(L) → Layer L 前向
|
||||||
|
```
|
||||||
|
|
||||||
|
所有 z_l 同时优化，梯度通过各自映射网络传播。
|
||||||
|
|
||||||
|
## 理论依据
|
||||||
|
|
||||||
|
[[weight-manifold-hypothesis|Weight-Manifold Hypothesis]] 的实验证据支持**逐层子流形**的存在——每层参数 θ*^(l) 位于独立的低维流形 M_θ^(l) 上。LWT 让每个隐向量专注于捕获其对应层的流形结构。
|
||||||
|
|
||||||
|
## 与 SLVT 的对比
|
||||||
|
|
||||||
|
| 维度 | SLVT | LWT |
|
||||||
|
|------|------|-----|
|
||||||
|
| 隐向量数 | 1 | L（每层一个） |
|
||||||
|
| 内存需求 | 高（大目标网络时） | 低（~10× 减少） |
|
||||||
|
| 参数缩减 | 200–525× | 类似 |
|
||||||
|
| 精度 | 接近或超过 baseline | 通常更高 |
|
||||||
|
| 适用场景 | 中小型网络 | 大型网络、微调 |
|
||||||
|
|
||||||
|
## 在微调中的应用
|
||||||
|
|
||||||
|
LWT + 增加每个调制元素覆盖的权重数（L 参数）使 Mapping Networks 可扩展到 LLM/LVM 的微调场景。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[weight-modulation]]
|
||||||
|
- [[parameter-efficient-training]]
|
||||||
|
- Sen & Mukherjee, "Mapping Networks", arXiv:2602.19134, Section 2.4.2
|
||||||
47
concepts/lazyar.md
Normal file
47
concepts/lazyar.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: "LazyAR (Lazy Autoregressive Decoder)"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [generative-recommendation, inference-optimization, decoder-architecture]
|
||||||
|
sources: [GR4AD]
|
||||||
|
---
|
||||||
|
# Lazy Autoregressive Decoder (LazyAR)
|
||||||
|
|
||||||
|
LazyAR 是 [[GR4AD]] 提出的**懒惰自回归解码器**架构，释放逐层自回归依赖以提升多候选生成吞吐量。在保持推荐效果的前提下，LazyAR 将近翻倍推理 QPS。
|
||||||
|
|
||||||
|
## 动机
|
||||||
|
|
||||||
|
标准自回归解码中，UA-SID 的每一级 token 的生成都需要完整的 $L$ 层解码器计算，即：
|
||||||
|
$$m_t(1), m_t(2), ..., m_t(L) = \text{Decoder}(s_{<t})$$
|
||||||
|
|
||||||
|
在 $T$ 级 UA-SID 下，总计算量为 $T \cdot L$ 层。
|
||||||
|
|
||||||
|
观察发现：第一级 UA-SID（$s_1$）的损失最大，承载了最关键的语义信息；后续级别（$s_2, s_3, ...$）的解码可以在不显著影响效果的前提下共享计算。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
LazyAR 将 $L$ 层解码器分为两段：
|
||||||
|
- **前 $K$ 层（共享段）**：计算与 $s_{t-1}$ 无关的 trunk 表示 $m_t(K)$，所有 UA-SID 级别共享
|
||||||
|
- **后 $L-K$ 层（注入段）**：在第 $K$ 层注入 $s_{t-1}$ 的嵌入，仅这些层需逐级重算
|
||||||
|
|
||||||
|
$$m_t(K) = \text{Decoder}^{1:K}(s_{<t} \setminus \{s_{t-1}\})$$
|
||||||
|
|
||||||
|
$$\hat{m}_t = \text{Decoder}^{K+1:L}(m_t(K) \oplus \text{Emb}(s_{t-1}))$$
|
||||||
|
|
||||||
|
## 速度优势
|
||||||
|
|
||||||
|
$m_t(K)$ 不依赖 $s_{t-1}$，因此前 $K$ 层的结果可以**在所有 UA-SID 级别间复用**。总计算量从 $T \cdot L$ 降至 $1 \cdot K + T \cdot (L-K)$：
|
||||||
|
|
||||||
|
- 若 $K=6, L=9, T=3$：计算量从 $27$ 降至 $6 + 3 \times 3 = 15$，节省 ~44%
|
||||||
|
|
||||||
|
## 与 DeepSeek MTP 的区别
|
||||||
|
|
||||||
|
DeepSeek [[MTP]] 也为所有后续 token 复用前几个 transformer 层，但 MTP 在每个位置都进行融合投影。LazyAR 直接复用 trunk 表示，延迟到第 $K$ 层才注入前级 token——这种"延迟注入"设计在短序列多候选场景中更高效。
|
||||||
|
|
||||||
|
配置：GR4AD 使用 $L=9, K=6$，共享前 6 层。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[GR4AD]]
|
||||||
|
- [[MTP]]
|
||||||
46
concepts/lean-imo-bench.md
Normal file
46
concepts/lean-imo-bench.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "Lean-IMO-Bench"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["benchmark", "imo", "lean", "formal-verification"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lean-IMO-Bench
|
||||||
|
|
||||||
|
> 将 IMO 级别问题形式化到 Lean 中的新基准——初等陈述、非平凡洞察、长链多步证明。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Lean-IMO-Bench** 是 [[leap-agentic-atp|LEAP]] 论文中引入的基准，基于 IMO-Bench (Luong et al., 2025) 的非形式化问题，由 Lean 专家手动形式化为 Lean 声明。共 60 题，均分 Basic 和 Advanced 各 30 题。
|
||||||
|
|
||||||
|
## 与现有基准的对比
|
||||||
|
|
||||||
|
| 基准 | 特点 | 饱和程度 |
|
||||||
|
|------|------|---------|
|
||||||
|
| MiniF2F | 短问题 | 接近饱和 |
|
||||||
|
| PutnamBench | 本科覆盖面广 | - |
|
||||||
|
| **Lean-IMO-Bench** | 初等陈述，多步非平凡证明 | 远未饱和 |
|
||||||
|
|
||||||
|
## 基准结构
|
||||||
|
|
||||||
|
- **Basic Set (30 题)**：pre-IMO 到 IMO-Medium，含 8 代数、8 组合、8 数论、6 几何
|
||||||
|
- **Advanced Set (30 题)**：新颖问题至 IMO-Hard，含 8 代数、8 组合、6 数论、8 几何
|
||||||
|
|
||||||
|
## 三个评估任务
|
||||||
|
|
||||||
|
1. Natural Language Proof（非形式化证明）
|
||||||
|
2. Formal Theorem Proving（形式化定理证明，本文焦点）
|
||||||
|
3. Formal Proof Translation（非形式化 → 形式化翻译）
|
||||||
|
|
||||||
|
## 基线表现
|
||||||
|
|
||||||
|
- Gemini 2.5 Pro 非形式化证明：Basic 55.2%，Advanced 17.6%
|
||||||
|
- Gemini 3.1 Pro 形式化证明 (Pass@128)：Basic 20%，Advanced 3.3%——数学推理不是瓶颈，生成有效 Lean 代码是
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[formal-theorem-proving|形式化定理证明]]
|
||||||
|
- [[lean-proof-assistant|Lean 证明助手]]
|
||||||
43
concepts/lean-proof-assistant.md
Normal file
43
concepts/lean-proof-assistant.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Lean 证明助手（Lean Proof Assistant）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["mathematics", "formal-verification", "lean", "dependent-types"]
|
||||||
|
sources: ["arxiv:2606.03303"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lean 证明助手
|
||||||
|
|
||||||
|
> 一个基于依赖类型理论的交互式定理证明器和函数式编程语言，由 Leonardo de Moura 等开发。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Lean** 是现代 [[formal-theorem-proving|形式化定理证明]] 中最活跃的系统之一。它同时是一门函数式编程语言和一个证明助手，允许数学家编写机器可检查的证明，由严格的 Lean 内核验证。
|
||||||
|
|
||||||
|
## 关键特性
|
||||||
|
|
||||||
|
- **依赖类型系统**：类型可以依赖值，使证明即程序（Curry-Howard 同构）
|
||||||
|
- **mathlib4**：庞大的数学形式化库
|
||||||
|
- **Lean Blueprint 工具**：用于组织大型形式化项目的人类可读路线图 + DAG 可视化
|
||||||
|
- **验证保证**：Lean 编译器提供严格的语法和类型检查
|
||||||
|
|
||||||
|
## 在 ATP 中的作用
|
||||||
|
|
||||||
|
在 [[leap-agentic-atp|LEAP]] 等 agentic 框架中，Lean 编译器扮演双重角色：
|
||||||
|
1. **形式验证器**：检查候选证明的正确性
|
||||||
|
2. **反馈源**：编译错误信息指导 LLM 的迭代修正
|
||||||
|
|
||||||
|
Lean 的 `sorry` 占位符机制允许部分证明（sketch）——声明子目标而不必立即证明——这是 [[blueprint-driven-atp|蓝图驱动 ATP]] 的关键能力。
|
||||||
|
|
||||||
|
## 大型项目
|
||||||
|
|
||||||
|
- Fermat's Last Theorem 形式化路线图（多年代码，显式依赖图）
|
||||||
|
- mathlib4 社区驱动的数学知识库
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[formal-theorem-proving|形式化定理证明]]
|
||||||
|
- [[leap-agentic-atp|LEAP]]
|
||||||
|
- [[blueprint-driven-atp|蓝图驱动 ATP]]
|
||||||
|
- [[autoformalization|自动形式化]]
|
||||||
45
concepts/lipschitz-continuity.md
Normal file
45
concepts/lipschitz-continuity.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Lipschitz Continuity: 利普希茨连续性"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [mathematics, functional-analysis, stability, deep-learning-theory]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lipschitz Continuity (利普希茨连续性)
|
||||||
|
|
||||||
|
Lipschitz Continuity 是函数分析中的基本概念：函数 f 满足 Lipschitz 条件，若存在常数 L ≥ 0 使得对所有 x₁, x₂：
|
||||||
|
|
||||||
|
$$\|f(x_1) - f(x_2)\| \leq L \|x_1 - x_2\|$$
|
||||||
|
|
||||||
|
L 称为 Lipschitz 常数，衡量 f 对输入变化的敏感度上限。
|
||||||
|
|
||||||
|
## 在 Mapping Networks 中的角色
|
||||||
|
|
||||||
|
[[mapping-theorem|Mapping Theorem]] 要求两个 Lipschitz 条件：
|
||||||
|
|
||||||
|
1. **参数光滑性 (A1)**：θ → f_θ(x) 是 L_θ-Lipschitz → 参数小变化不导致输出大变化
|
||||||
|
2. **损失 Lipschitz (A2)**：L(·, y) 是 L_ℓ-Lipschitz → 损失函数本身连续
|
||||||
|
|
||||||
|
组合条件：|L(θ₁) − L(θ₂)| ≤ L_ℓ L_θ ‖θ₁ − θ₂‖，确保参数误差在损失函数上的放大有界。
|
||||||
|
|
||||||
|
## Stability Loss 的直接体现
|
||||||
|
|
||||||
|
[[mapping-loss|Mapping Loss]] 中的 Stability Loss 显式强制隐空间中的局部 Lipschitz 连续性：
|
||||||
|
|
||||||
|
$$L_{\text{stab}} = \mathbb{E}_\epsilon\left[\|f(z+\epsilon) - f(z)\|^2\right]$$
|
||||||
|
|
||||||
|
小扰动 ε ∼ N(0, σ²I) 不应导致输出大偏离。
|
||||||
|
|
||||||
|
## 更广泛的 ML 应用
|
||||||
|
|
||||||
|
- **对抗鲁棒性**：小输入扰动 → 小输出变化
|
||||||
|
- **泛化理论**：Lipschitz 常数与泛化误差界相关
|
||||||
|
- **谱归一化**：约束网络的 Lipschitz 常数
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[mapping-theorem]]
|
||||||
|
- [[mapping-loss]]
|
||||||
|
- [[weight-manifold-hypothesis]]
|
||||||
40
concepts/llm-as-a-judge.md
Normal file
40
concepts/llm-as-a-judge.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "LLM-as-a-Judge"
|
||||||
|
created: 2026-06-27
|
||||||
|
updated: 2026-06-27
|
||||||
|
type: concept
|
||||||
|
tags:
|
||||||
|
- evaluation
|
||||||
|
- llm
|
||||||
|
- judge
|
||||||
|
sources:
|
||||||
|
- "rubrics-survey-2026"
|
||||||
|
---
|
||||||
|
|
||||||
|
# LLM-as-a-Judge
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
LLM-as-a-Judge 指使用 LLM 作为评估者来评分、比较或判断其他模型的输出 (Gu et al., 2024, 2025; Zheng et al., 2023)。这是 LLM 评估中的一个重要范式，与使用人类评估者或程序化验证形成对比。
|
||||||
|
|
||||||
|
## 与 Rubrics 的关系
|
||||||
|
|
||||||
|
- LLM-as-a-Judge = **谁来评估**（the evaluator）
|
||||||
|
- [[rubrics-for-llms|Rubrics]] = **评估什么标准**（the evaluation standard）
|
||||||
|
|
||||||
|
LLM judge 可以不使用 rubric（直接给总分），也可以遵循 rubric 逐项打分。后者通常更有信息量——不仅给出总分，还指出输出在哪些维度成功或失败。
|
||||||
|
|
||||||
|
## 对比
|
||||||
|
|
||||||
|
| 维度 | LLM-as-a-Judge | Rubrics |
|
||||||
|
|------|---------------|---------|
|
||||||
|
| 角色 | 评估者 | 评估标准 |
|
||||||
|
| 可解释性 | 低（隐式标准） | 高（显式 item） |
|
||||||
|
| 灵活性 | 高 | 结构化 |
|
||||||
|
| 一致性问题 | 不稳定的判断 | 稳定的框架 |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[rubrics-for-llms|Rubrics for LLMs]]
|
||||||
|
- [[rubrics-survey-2026|Rubrics Survey (2026)]]
|
||||||
|
- [[rubric-driven-evaluation]]
|
||||||
43
concepts/loop-contract.md
Normal file
43
concepts/loop-contract.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Loop Contract（循环协议）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [loop-engineering, contract, safety, constraint]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Loop Contract
|
||||||
|
|
||||||
|
> 在 [[loop-engineering|Loop Engineering]] 中，策略层强制执行的一套协议，从六个维度严格约束自主循环系统，防止退化为失控的死循环。
|
||||||
|
|
||||||
|
## 六维约束
|
||||||
|
|
||||||
|
| 维度 | 含义 | 示例 |
|
||||||
|
|------|------|------|
|
||||||
|
| **TRIGGER** | 触发条件 | 每 15 分钟 / PR 评论 / CI 失败 |
|
||||||
|
| **SCOPE** | 作用范围 | 仅限特定仓库 / 仅处理自己提交的 PR |
|
||||||
|
| **ACTION** | 具体行为 | 运行测试 / 自动修复 Lint 错误 |
|
||||||
|
| **BUDGET** | 预算红线 | 单次最多 3 个子 Agent / 50k Tokens / $5 成本 |
|
||||||
|
| **STOP** | 停止条件 | 测试全绿 / 达到 10 轮上限 / 预算耗尽 |
|
||||||
|
| **REPORT** | 上报通道 | 异常时投递至 Slack |
|
||||||
|
|
||||||
|
## 固化为硬约束
|
||||||
|
|
||||||
|
BUDGET 和 STOP 直接固化为两道硬约束：
|
||||||
|
|
||||||
|
- [[circuit-breaker-pattern|熔断器（Circuit Breaker）]]：连续失败 N 次 → 跳闸 + 回退 + 转交人工；墙上时间超时无条件熔断
|
||||||
|
- [[watchdog-pattern|看门狗（Watchdog）]]：独立进程监控 CPU，防自旋死循环，越过应用层 SIGKILL 强杀
|
||||||
|
|
||||||
|
## 设计哲学
|
||||||
|
|
||||||
|
Loop Contract 体现了 [[mechanism-policy-separation|机制与策略分离]]：底层提供熔断和看门狗机制，具体阈值（max_consecutive_failures、max_runtime_min）由 [[loop-designer|Loop Designer]] 按业务逻辑配置。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[mechanism-policy-separation|机制与策略分离]]
|
||||||
|
- [[circuit-breaker-pattern|熔断器]]
|
||||||
|
- [[watchdog-pattern|看门狗]]
|
||||||
|
- [[loop-designer|Loop Designer]]
|
||||||
47
concepts/loop-designer.md
Normal file
47
concepts/loop-designer.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: "Loop Designer（循环设计师）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [loop-engineering, role, agent, career]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Loop Designer
|
||||||
|
|
||||||
|
> [[loop-engineering|Loop Engineering]] 范式下开发者的新生态位：从提示词编写者进化为**循环系统架构设计师**。
|
||||||
|
|
||||||
|
## 三大核心职责
|
||||||
|
|
||||||
|
### 1. 定义终止边界（Goal & Verifier 设计）
|
||||||
|
|
||||||
|
- 编写 VISION.md（全局愿景文件）
|
||||||
|
- 定义完工条件与评估矩阵
|
||||||
|
- 设计测试用例与验收标准
|
||||||
|
|
||||||
|
### 2. 维护工具链与领域资产（Tooling & Skill 配置）
|
||||||
|
|
||||||
|
- 配置安全沙箱
|
||||||
|
- 对接 [[mcp|MCP]] 连接器
|
||||||
|
- 将高频重用的工程逻辑固化为命名的 Skill 资产
|
||||||
|
- 避免系统在单次执行中重复产生提示词开销
|
||||||
|
|
||||||
|
### 3. 设计安全断路器（Human-in-the-Loop & Budget Guard）
|
||||||
|
|
||||||
|
- 设定步数、时间、Token 消耗、资金成本等多维约束
|
||||||
|
- [[loop-contract|Loop Contract]] 的策略层配置
|
||||||
|
- 异常时人工干预机制
|
||||||
|
|
||||||
|
## 角色转变
|
||||||
|
|
||||||
|
> "AI 时代上半场，我们研究'语言的艺术'；下半场，拼的是'系统工程的能力'。"
|
||||||
|
|
||||||
|
未来高薪人才不是提示词专家，而是能为 AI 搭建办公室、写靠谱循环、让 AI 自主运转的 Loop Designer。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[loop-contract|Loop Contract]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
|
- [[mechanism-policy-separation|机制与策略分离]]
|
||||||
63
concepts/loop-engineering.md
Normal file
63
concepts/loop-engineering.md
Normal file
@@ -0,0 +1,63 @@
|
|||||||
|
---
|
||||||
|
title: "Loop Engineering（循环工程）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [loop-engineering, agent, automation, paradigm]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Loop Engineering
|
||||||
|
|
||||||
|
> 公式：**Loop = Cron + 决策器**。AI 开发范式四次浪潮的第四阶段（2026–），系统从人类单次触发演进为具备独立运行周期的自主工程。
|
||||||
|
|
||||||
|
## 核心转变
|
||||||
|
|
||||||
|
人类从 Agent 循环的**内部走向外部**，从执行者变为设计者。大模型在系统中的定位转变为受控的"子程序"，控制权交给由状态机和多 Agent 编排构建的闭环架构。
|
||||||
|
|
||||||
|
## 架构哲学
|
||||||
|
|
||||||
|
[[mechanism-policy-separation|机制与策略分离]]：底层平台（Harness）提供基础机制（定时器、工作区隔离），控制策略（触发时机、子 Agent 数量）由架构师独立配置。
|
||||||
|
|
||||||
|
## 三级成熟度
|
||||||
|
|
||||||
|
参见 [[loop-maturity-levels|Loop 成熟度]]：
|
||||||
|
1. **Open Loop（开环）**：模型自行判断 done 即结束，仅适用于 Demo
|
||||||
|
2. **Closed Loop（闭环）**：每轮强制通过单元测试 / Lint / Review，生产级交付标准
|
||||||
|
3. **Review Loop（评审环）**：后台常驻异步审查 Agent 持续反馈，长会长任务最优解
|
||||||
|
|
||||||
|
## 五件套 + 一个记忆
|
||||||
|
|
||||||
|
| 组件 | 职责 |
|
||||||
|
|------|------|
|
||||||
|
| Automations | 心跳机制（Cron / GitHub Actions） |
|
||||||
|
| Worktrees | 子 Agent 并行隔离工作区 |
|
||||||
|
| Skills | 领域知识固化为配置/规范 |
|
||||||
|
| Plugins / Connectors | [[mcp|MCP]] 连接器，赋予真实动作能力 |
|
||||||
|
| Sub-agents | 研发与审计分离的多 Agent 编排 |
|
||||||
|
| State 文件 | 落盘记忆，运行进度持久化 |
|
||||||
|
|
||||||
|
## 安全约束
|
||||||
|
|
||||||
|
- [[loop-contract|Loop Contract]]：六维约束（TRIGGER / SCOPE / ACTION / BUDGET / STOP / REPORT）
|
||||||
|
- [[circuit-breaker-pattern|熔断器]]：连续失败 N 次 → 跳闸 + 回退 + 转交人工
|
||||||
|
- [[watchdog-pattern|看门狗]]：独立进程监控 CPU，防自旋死循环
|
||||||
|
|
||||||
|
## 自主闭环流水线
|
||||||
|
|
||||||
|
> AI 编码 → 沙箱测试 → 日志自动回灌 → AI 修复 → CI 绿标通过 → 自动发起 PR
|
||||||
|
|
||||||
|
全流程无人类介入。
|
||||||
|
|
||||||
|
## 嵌套关系
|
||||||
|
|
||||||
|
Loop 是最外层调度引擎：**Prompt ⊂ Context ⊂ Harness ⊂ Loop**。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-designer|Loop Designer]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
|
- [[harness-as-a-service|HaaS]]
|
||||||
|
- [[prompt-to-harness-evolution|三阶段工程演进]]
|
||||||
|
- [[agent-harness|Agent Harness]]
|
||||||
48
concepts/loop-maturity-levels.md
Normal file
48
concepts/loop-maturity-levels.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "Loop Maturity Levels（循环成熟度）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [loop-engineering, maturity, agent]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Loop Maturity Levels
|
||||||
|
|
||||||
|
> [[loop-engineering|Loop Engineering]] 中自主循环系统的三级成熟度划分。
|
||||||
|
|
||||||
|
## 三级模型
|
||||||
|
|
||||||
|
### L1: Open Loop（开环）
|
||||||
|
|
||||||
|
- 模型自行判断并输出 `done` 即告结束
|
||||||
|
- 没有外部验证机制
|
||||||
|
- **适用场景**：Demo 演示
|
||||||
|
- **风险**：输出可能未通过任何质量检查
|
||||||
|
|
||||||
|
### L2: Closed Loop（闭环）
|
||||||
|
|
||||||
|
- 每轮执行必须强制通过**单元测试**、**Lint 检查**或**自动化 Review**
|
||||||
|
- 不合格 → 错误回灌 → 模型修复 → 重新验证
|
||||||
|
- **达到生产级交付标准**
|
||||||
|
- 核心流水线：AI 编码 → 沙箱测试 → 日志回灌 → AI 修复 → CI 绿标
|
||||||
|
|
||||||
|
### L3: Review Loop（评审环）
|
||||||
|
|
||||||
|
- 后台常驻的**异步审查 Agent** 在新鲜上下文中提供持续反馈
|
||||||
|
- Maker 和 Verifier 由**不同 Agent** 承担（研发与审计分离）
|
||||||
|
- **解决长会长任务的最优解**
|
||||||
|
- 避免"自己给自己改作业必然放水"的问题
|
||||||
|
|
||||||
|
## 成熟度跃迁
|
||||||
|
|
||||||
|
```
|
||||||
|
Open Loop ──[+ 单元测试/Lint]──→ Closed Loop ──[+ 异步审查 Agent]──→ Review Loop
|
||||||
|
```
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[loop-contract|Loop Contract]]
|
||||||
|
- [[agent-harness|Agent Harness]]
|
||||||
36
concepts/loss-landscape.md
Normal file
36
concepts/loss-landscape.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Loss Landscape: 神经网络的损失景观"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [optimization, deep-learning-theory, loss-surface, mode-connectivity]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Loss Landscape (损失景观)
|
||||||
|
|
||||||
|
Loss Landscape 指将神经网络训练目标 L(θ) 视为参数空间 R^P 上的高维曲面时的几何结构。该视角为理解泛化、优化难度和参数空间结构提供了关键洞察。
|
||||||
|
|
||||||
|
## 关键发现
|
||||||
|
|
||||||
|
### 低维结构
|
||||||
|
- **Intrinsic Dimension**：深度网络的 objective landscape 的有效内在维度远低于 P（Li et al., 2018）
|
||||||
|
- 训练轨迹聚焦在远低于参数空间维度的子空间上
|
||||||
|
|
||||||
|
### Mode Connectivity
|
||||||
|
- SGD 找到的不同局部极小值之间存在**低损路径**（Garipov et al., 2018）
|
||||||
|
- 表明有效解分布在连通区域而非孤立点
|
||||||
|
|
||||||
|
### 平坦 vs 尖锐极小值
|
||||||
|
- **平坦极小值**：泛化更好（Keskar et al., 2017）
|
||||||
|
- Entropy-SGD 等方法显式偏置梯度下降走向宽阔山谷（Chaudhari et al., 2019）
|
||||||
|
|
||||||
|
## 对 Mapping Networks 的意义
|
||||||
|
|
||||||
|
Mapping Networks 通过**结构性约束**将搜索空间限制在低维流形上，自然地偏向发现更平坦、更鲁棒的参数解——这是一种通过架构选择实现隐式正则化的方式。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[intrinsic-dimension]]
|
||||||
|
- [[manifold-hypothesis]]
|
||||||
|
- [[weight-manifold-hypothesis]]
|
||||||
33
concepts/lottery-ticket-hypothesis.md
Normal file
33
concepts/lottery-ticket-hypothesis.md
Normal file
@@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "Lottery Ticket Hypothesis: 稀疏子网络的彩票假说"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [model-compression, pruning, sparse-networks]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lottery Ticket Hypothesis (彩票假说)
|
||||||
|
|
||||||
|
Frankle & Carbin (2018) 提出的假说：**密集、随机初始化的前馈网络包含子网络（"中奖彩票"），这些子网络在单独训练时能达到与原始网络相当的测试精度，且训练迭代次数相近**。
|
||||||
|
|
||||||
|
## 与 Mapping Networks 的关系
|
||||||
|
|
||||||
|
| 维度 | Lottery Ticket | Mapping Networks |
|
||||||
|
|------|---------------|------------------|
|
||||||
|
| 目标 | 找到稀疏子网络 | 学习低维参数生成映射 |
|
||||||
|
| 阶段 | 后训练 / 迭代剪枝 | 训练时即嵌入 |
|
||||||
|
| 理论基础 | 经验观察 | Mapping Theorem（存在性保证） |
|
||||||
|
| 推理效率 | 提升（稀疏） | 不变（生成全参数） |
|
||||||
|
| 训练效率 | 不变 | 大幅提升（200-500× 可训练参数减少） |
|
||||||
|
|
||||||
|
## 延伸
|
||||||
|
|
||||||
|
- **Linear Mode Connectivity**：SGD 解的 mode connectivity 支持参数空间存在结构
|
||||||
|
- 可结合 Mapping Networks 的 Pruning 扩展同时降低训练和推理参数
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- Frankle & Carbin, "The Lottery Ticket Hypothesis", ICLR 2019
|
||||||
|
- [[low-rank-decomposition]]
|
||||||
|
- [[parameter-efficient-training]]
|
||||||
34
concepts/low-rank-decomposition.md
Normal file
34
concepts/low-rank-decomposition.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "Low-Rank Decomposition: 神经网络低秩压缩"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [model-compression, matrix-factorization, efficient-inference]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Low-Rank Decomposition (低秩分解)
|
||||||
|
|
||||||
|
Low-Rank Decomposition (LRD) 是神经网络压缩的经典技术：将全连接层的权重矩阵 W ∈ R^{m×n} 近似分解为两个较小矩阵的乘积：
|
||||||
|
|
||||||
|
$$W \approx UV^\top$$
|
||||||
|
|
||||||
|
其中 U ∈ R^{m×r}，V ∈ R^{n×r}，且 r ≪ min(m, n)。参数量从 mn → r(m + n)。
|
||||||
|
|
||||||
|
## 在 Mapping Networks 中的应用
|
||||||
|
|
||||||
|
Mapping Networks 可以用 LRD 进一步降低映射网络的存储需求：不直接生成 W，而是生成 U 和 V 两个更小的矩阵，显著减少映射网络的固定权重数量。
|
||||||
|
|
||||||
|
## 相关技术
|
||||||
|
|
||||||
|
- **SVD 截断**：基于奇异值分解的后训练压缩
|
||||||
|
- **Pruning**：稀疏化——移除不重要连接
|
||||||
|
- **Quantization**：降低权重位宽
|
||||||
|
|
||||||
|
这三种技术与 Mapping Networks 正交，可以组合使用——如 Table 8 所示，Ours* + LRD 和 Ours* + Prune 均保持可用精度。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- Eckart & Young, "The approximation of one matrix by another of lower rank", 1936
|
||||||
|
- Idelbayev & Carreira-Perpiñán, "Low-rank compression of neural nets", CVPR 2020
|
||||||
|
- [[weight-modulation]]
|
||||||
30
concepts/manifold-hypothesis.md
Normal file
30
concepts/manifold-hypothesis.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "Manifold Hypothesis (流形假设)"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [manifold-learning, dimensionality-reduction, representation-learning]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Manifold Hypothesis (流形假设)
|
||||||
|
|
||||||
|
Manifold Hypothesis 是机器学习中的核心假设：**高维数据（如图像、文本）实际上分布在嵌入于高维空间中的低维流形上或附近**。
|
||||||
|
|
||||||
|
形式化：对 x ∈ X ⊂ R^D（高维输入空间），∃ M（低维流形），使得 M ⊂ X，且 d = dim(M) ≪ D。神经网络学习的是映射 f_θ: M → Y。
|
||||||
|
|
||||||
|
## 推广到参数空间
|
||||||
|
|
||||||
|
[[weight-manifold-hypothesis|Weight-Manifold Hypothesis]] 将这一假设从**数据空间**推广到**参数空间**：不仅数据在低维流形上，训练后的网络参数 θ* ∈ R^P 也位于低维流形 M_θ ⊂ R^P 上，其中 dim(M_θ) ≪ P。
|
||||||
|
|
||||||
|
## 经验证据
|
||||||
|
|
||||||
|
- **Intrinsic Dimension 研究**：深度网络的 objective landscape 的有效内在维度远低于参数总数（Li et al., 2018）
|
||||||
|
- **训练轨迹分析**：不同初始化、不同架构的深度网络的训练轨迹收敛到同一个低维流形（Mao et al., 2024）
|
||||||
|
- **Mode Connectivity**：SGD 解之间存在低损路径连接（Garipov et al., 2018）
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- Fefferman et al., "Testing the Manifold Hypothesis", JAMS 2016
|
||||||
|
- [[intrinsic-dimension]]
|
||||||
|
- [[loss-landscape]]
|
||||||
60
concepts/mapping-loss.md
Normal file
60
concepts/mapping-loss.md
Normal file
@@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
title: "Mapping Loss: 联合任务与几何约束的损失函数"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [loss-function, mapping-networks, regularization, lipschitz-continuity]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mapping Loss (映射损失)
|
||||||
|
|
||||||
|
Mapping Loss 是 [[sen-mapping-networks|Mapping Networks]] 的训练损失函数，同时优化下游任务性能和 [[mapping-theorem|Mapping Theorem]] 所要求的几何/解析性质。
|
||||||
|
|
||||||
|
## 公式
|
||||||
|
|
||||||
|
$$L_{\text{map}} = L_{\text{task}} + \lambda_{\text{stab}} L_{\text{stab}} + \lambda_{\text{sm}} L_{\text{smooth}} + \lambda_{\text{al}} L_{\text{align}}$$
|
||||||
|
|
||||||
|
其中 λ_stab, λ_smooth, λ_align 均为**可训练系数**，使网络自适应地平衡各组件。
|
||||||
|
|
||||||
|
## 四组件详解
|
||||||
|
|
||||||
|
### 1. Task Loss (L_task)
|
||||||
|
|
||||||
|
标准交叉熵损失，确保生成的参数在下游任务上功能最优：
|
||||||
|
|
||||||
|
$$L_{\text{task}} = -\sum_i y_i \log \hat{y}_i$$
|
||||||
|
|
||||||
|
### 2. Stability Loss (L_stab)
|
||||||
|
|
||||||
|
强制**局部 Lipschitz 连续性**（对应 Mapping Theorem 的 A1 假设）：
|
||||||
|
|
||||||
|
$$L_{\text{stab}} = \mathbb{E}_{\epsilon \sim \mathcal{N}(0,\sigma^2 I)}\left[\|f_{\theta'}(z+\epsilon) - f_{\theta'}(z)\|^2_2\right]$$
|
||||||
|
|
||||||
|
确保隐向量的小扰动不导致输出大变化。
|
||||||
|
|
||||||
|
### 3. Smoothness Loss (L_smooth)
|
||||||
|
|
||||||
|
强制 **C² 连续性**（对应定理的 A3 假设）：
|
||||||
|
|
||||||
|
$$L_{\text{smooth}} = \|\nabla_z M_\phi(z)\|^2_F$$
|
||||||
|
|
||||||
|
惩罚 Jacobian 的 Frobenius 范数，防止生成的权重空间出现震荡。
|
||||||
|
|
||||||
|
### 4. Alignment Loss (L_align)
|
||||||
|
|
||||||
|
保持隐向量与映射权重方向的兼容性：
|
||||||
|
|
||||||
|
$$L_{\text{align}} = 1 - \cos(z, \bar{W}^m)$$
|
||||||
|
|
||||||
|
其中 W̄^m 是调制后投影层的行均值。
|
||||||
|
|
||||||
|
## 消融结果
|
||||||
|
|
||||||
|
在 FashionMNIST 上：Task Loss 单独 87.79%，每增加一个组件 +1-2%，全组合达 91.88%。Stability 和 Smoothness 贡献略高于 Alignment。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[lipschitz-continuity]]
|
||||||
|
- [[mapping-theorem]]
|
||||||
|
- [[solvability-theorem]]
|
||||||
49
concepts/mapping-theorem.md
Normal file
49
concepts/mapping-theorem.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: "Mapping Theorem: 参数空间的低维映射存在性定理"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [theorem, manifold-learning, mapping-networks, existence-proof]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mapping Theorem (映射定理)
|
||||||
|
|
||||||
|
Mapping Theorem 是 [[sen-mapping-networks|Mapping Networks]] 的理论基石，证明了**从低维隐空间到高维参数空间的光滑映射的存在性**，且该映射可在损失函数上任意逼近最优参数。
|
||||||
|
|
||||||
|
## 前提条件
|
||||||
|
|
||||||
|
1. **A1: 参数光滑性** — θ → f_θ(x) 是 L_θ-Lipschitz 的（对每个 x）
|
||||||
|
2. **A2: 损失 Lipschitz** — L(·, y) 是 L_ℓ-Lipschitz 的
|
||||||
|
3. **A3: 局部可逼近性** — M_θ 是 C² 流形，有界曲率
|
||||||
|
4. **Weight-Manifold Hypothesis** — θ* 位于 C² 嵌入流形 M_θ ⊂ R^P 上
|
||||||
|
|
||||||
|
## 定理陈述
|
||||||
|
|
||||||
|
对任意 ε > 0（满足 ε ≤ L_ℓ L_θ r），存在：
|
||||||
|
- δ > 0
|
||||||
|
- d ≥ d*（其中 d* = dim(M_θ)）
|
||||||
|
- C² 映射 g: R^d → R^P
|
||||||
|
- 隐向量 z* ∈ R^d
|
||||||
|
|
||||||
|
使得：
|
||||||
|
|
||||||
|
$$\|g(z^*) - \theta^*\| \leq \delta, \quad |L(g(z^*)) - L(\theta^*)| \leq \varepsilon$$
|
||||||
|
|
||||||
|
## 证明概要
|
||||||
|
|
||||||
|
1. 由 Weight-Manifold Hypothesis，∃ C² 微分同胚 φ: U → V ⊂ M_θ，φ(0) = θ*
|
||||||
|
2. 构造全局映射 g(u) = ψ(u)φ(u) + (1 − ψ(u))θ*（smooth bump function 拼接）
|
||||||
|
3. 由连续性，选 z* ∈ B(0, η) ∩ U，满足 ‖g(z*) − θ*‖ < δ
|
||||||
|
4. 由 Lipschitz 条件：|L(g(z*)) − L(θ*)| ≤ L_ℓ L_θ · δ = ε
|
||||||
|
|
||||||
|
## 实际意义
|
||||||
|
|
||||||
|
该定理提供了**架构设计的正确性保证**：如果映射网络架构满足定理条件（如 [[solvability-theorem|Solvability Theorem]] 所示），则理论上存在隐向量可生成与完整训练等效的参数。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[weight-manifold-hypothesis]]
|
||||||
|
- [[solvability-theorem]]
|
||||||
|
- [[mapping-loss]]
|
||||||
|
- Sen & Mukherjee, "Mapping Networks", arXiv:2602.19134, Section 2.1
|
||||||
43
concepts/markov-draft-head.md
Normal file
43
concepts/markov-draft-head.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Markov Draft Head"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, draft-architecture, low-rank-factorization]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Markov Draft Head
|
||||||
|
|
||||||
|
马尔可夫草稿头是 [[DSpark]] 的[[semi-autoregressive-generation|半自回归生成（Semi-Autoregressive Generation）]]中最简单的顺序块实例化，将转移偏置 $B_k$ 限制为仅依赖**紧前一个 token**，简化为一个一阶转移矩阵 $B(x_{k-1}, x_k)$。
|
||||||
|
|
||||||
|
## 低秩分解
|
||||||
|
|
||||||
|
直接存储 $|\mathcal{V}| \times |\mathcal{V}|$ 的转移矩阵不现实（典型 $10^5 \times 10^5$）。采用低秩近似：
|
||||||
|
|
||||||
|
$$B = W_1 W_2^\top$$
|
||||||
|
|
||||||
|
- $W_1 \in \mathbb{R}^{|\mathcal{V}| \times r}$：充当嵌入查找表
|
||||||
|
- $W_2 \in \mathbb{R}^{|\mathcal{V}| \times r}$：充当 logit 投影
|
||||||
|
- 默认 rank $r = 256$
|
||||||
|
|
||||||
|
给定前一 token $x_{k-1}$，位置 $k$ 的转移偏置：
|
||||||
|
|
||||||
|
$$B(x_{k-1}, \cdot) = W_1[x_{k-1}] W_2^\top \in \mathbb{R}^{|\mathcal{V}|}$$
|
||||||
|
|
||||||
|
低秩分解使得存储和每步计算量都保持较小，即使对于大词汇表也能高效运行。
|
||||||
|
|
||||||
|
## 直觉
|
||||||
|
|
||||||
|
例如，当上下文允许多种延续 "of course" 和 "no problem" 时：
|
||||||
|
- 若位置 1 采样了 "of"，马尔可夫头在位置 2 提升 "course" 并抑制 "problem"
|
||||||
|
- 有效缓解[[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]
|
||||||
|
|
||||||
|
## 局限性
|
||||||
|
|
||||||
|
马尔可夫头是无记忆的——位置 $k$ 无法访问 $x_{k-2}$ 之前的 token。对于需要更长依赖的后缀连贯性，[[rnn-draft-head|RNN 草稿头]]通过循环状态累积完整前缀历史。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[semi-autoregressive-generation|半自回归生成（Semi-Autoregressive Generation）]]
|
||||||
|
- [[rnn-draft-head|RNN 草稿头]]
|
||||||
31
concepts/mcp.md
Normal file
31
concepts/mcp.md
Normal file
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: "MCP (Model Context Protocol)"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [mcp, protocol, agent, connector, infrastructure]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# MCP (Model Context Protocol)
|
||||||
|
|
||||||
|
> Anthropic 提出的开放协议标准，为 LLM Agent 提供标准化的工具连接器（Connector）。在 [[harness-as-a-service|HaaS]] 底座中扮演 Plugins / Connectors 角色。
|
||||||
|
|
||||||
|
## 在 Loop Engineering 中的定位
|
||||||
|
|
||||||
|
属于 [[loop-engineering|Loop Engineering]] "五件套" 中的 **Plugins / Connectors** 层：
|
||||||
|
|
||||||
|
> Automations / Worktrees / Skills / **Connectors (MCP)** / Sub-agents / State
|
||||||
|
|
||||||
|
## 核心能力
|
||||||
|
|
||||||
|
- 标准化工具注册与发现
|
||||||
|
- 使循环具备开 PR、发 Slack、同步项目管理看板的真实动作
|
||||||
|
- 与渐进式披露配合（先暴露工具名称，按需加载详情）
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[harness-as-a-service|HaaS]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
45
concepts/mechanism-policy-separation.md
Normal file
45
concepts/mechanism-policy-separation.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Mechanism-Policy Separation（机制与策略分离）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [architecture, loop-engineering, design-principle]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mechanism-Policy Separation
|
||||||
|
|
||||||
|
> 成熟的 [[loop-engineering|循环系统]] 遵循的核心架构哲学：底层平台提供基础**机制**，控制**策略**由架构师独立配置。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
| 层 | 职责 | 示例 |
|
||||||
|
|----|------|------|
|
||||||
|
| **机制（Mechanism）** | 由 Harness 提供的基础能力 | 定时器、工作区隔离、工具注册、进程管理 |
|
||||||
|
| **策略（Policy）** | 由架构师按业务逻辑配置的控制规则 | 触发时机、子 Agent 数量、预算上限、停止条件 |
|
||||||
|
|
||||||
|
## 工程价值
|
||||||
|
|
||||||
|
1. **解耦演进**：升级机制不改变策略（替换 Cron 实现不影响触发规则）
|
||||||
|
2. **复用策略**：同一策略可部署到不同 Harness 平台
|
||||||
|
3. **人类抽离**：架构师设定策略后退出执行循环，系统自主运转
|
||||||
|
|
||||||
|
## 在 Loop Contract 中的体现
|
||||||
|
|
||||||
|
[[loop-contract|Loop Contract]] 的六维约束正是策略层的实例化：
|
||||||
|
|
||||||
|
- 机制层提供：Cron 定时器（TRIGGER）、进程隔离（SCOPE）、工具调用（ACTION）
|
||||||
|
- 策略层配置：Cron 表达式、作用仓库、预算红线、停止条件、上报通道
|
||||||
|
|
||||||
|
## 与 Harness 的关系
|
||||||
|
|
||||||
|
机制层 = [[harness-engineering|Harness Engineering]] 的产物
|
||||||
|
策略层 = [[loop-designer|Loop Designer]] 的配置域
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[loop-engineering|Loop Engineering]]
|
||||||
|
- [[loop-contract|Loop Contract]]
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
|
- [[loop-designer|Loop Designer]]
|
||||||
41
concepts/memory-dream.md
Normal file
41
concepts/memory-dream.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Memory Dream（记忆梦境）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "memory", "offline-processing"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Memory Dream
|
||||||
|
|
||||||
|
> 离线记忆整理器——不在用户实时对话里抢上下文，在后台从会话材料中提取稳定画像和可复用经验。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**Memory Dream** 是 [[zleap-workspace-harness-2026|Zleap-Agent]] 记忆系统中的后台处理模块。它不在用户实时对话中消耗上下文预算，而是在离线状态下从经过清理的会话材料中执行记忆抽取。
|
||||||
|
|
||||||
|
## 处理内容
|
||||||
|
|
||||||
|
- **稳定画像**：用户长期偏好、行为习惯
|
||||||
|
- **可复用经验**：经过脱敏和可复用性判断的方法/流程
|
||||||
|
- **事件清理**：工作事件走另一条链路，不经过 Dream
|
||||||
|
|
||||||
|
## 与实时记忆的关系
|
||||||
|
|
||||||
|
| 维度 | 实时记忆 | Memory Dream |
|
||||||
|
|------|---------|-------------|
|
||||||
|
| 触发时机 | 对话中 | 后台离线 |
|
||||||
|
| 上下文占用 | 消耗 token | 不占用 |
|
||||||
|
| 处理内容 | 即时事件存储 | 长期画像 + 经验抽取 |
|
||||||
|
| 准入判断 | 弱 | 强（脱敏 + 可复用性） |
|
||||||
|
|
||||||
|
## 设计价值
|
||||||
|
|
||||||
|
Agent 不必每轮都把完整历史塞进上下文，也不必把所有历史都当成长期记忆。Dream 提供了一种「定期整理、择优入库」的记忆治理机制，与 [[memory-tripartite-partition|记忆三分区]] 中的经验记忆准入规则配套使用。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[memory-tripartite-partition|记忆三分区]]
|
||||||
|
- [[memory-recall-fast-slow|快慢召回]]
|
||||||
40
concepts/memory-recall-fast-slow.md
Normal file
40
concepts/memory-recall-fast-slow.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "记忆快慢召回（Memory Recall: Fast & Slow）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "memory", "retrieval", "latency"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 记忆快慢召回
|
||||||
|
|
||||||
|
> Prefetch 用 fast 模式（不走 LLM），主动 recall 走精细检索和 rerank——兼顾响应速度和记忆质量。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**快慢召回** 是 [[zleap-workspace-harness-2026|Zleap-Agent]] 记忆检索的分层策略：将记忆读取拆成两个通道，避免每次记忆读取都依赖大模型带来的延迟和成本。
|
||||||
|
|
||||||
|
## 两层设计
|
||||||
|
|
||||||
|
| 层 | 模式 | 触发方式 | 内容 | LLM 参与 |
|
||||||
|
|----|------|---------|------|---------|
|
||||||
|
| **Fast (Prefetch)** | 自动推入上下文 | 进入工作区时 | 用户画像、近期工作事件、常用经验 | 否 |
|
||||||
|
| **Slow (Recall)** | 主动检索 | 模型主动调用 | 精确匹配的记忆片段 | 检索 + rerank |
|
||||||
|
|
||||||
|
## 设计动机
|
||||||
|
|
||||||
|
- 全部走 LLM → 延迟和成本被放大
|
||||||
|
- 完全不做精排 → 召回质量不稳定
|
||||||
|
- 快取和精取分开 → 预取短准可控 + 按需精排
|
||||||
|
|
||||||
|
## 与上下文加载的关系
|
||||||
|
|
||||||
|
快慢召回是 [[context-prefetch-vs-agentic|上下文预取 vs 按需]] 在记忆维度的具体实现：Prefetch 对应「提前带入」，Slow Recall 对应「按需读取」。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[memory-tripartite-partition|记忆三分区]]
|
||||||
|
- [[memory-dream|Memory Dream]]
|
||||||
|
- [[context-prefetch-vs-agentic|上下文预取 vs 按需]]
|
||||||
52
concepts/memory-tripartite-partition.md
Normal file
52
concepts/memory-tripartite-partition.md
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
title: "记忆三分区（Memory Tripartite Partition）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "memory", "partition", "governance"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 记忆三分区
|
||||||
|
|
||||||
|
> 记忆要有归属，不能混成一个篮子——至少按「人、事、经验」分区。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**记忆三分区** 是 [[zleap-workspace-harness-2026|Zleap-Agent]] 记忆层的核心设计：将 Agent 记忆按归属拆分为三条线，避免不同类型记忆互相污染。
|
||||||
|
|
||||||
|
## 三条线
|
||||||
|
|
||||||
|
| 分区 | 内容 | 归属 | 读写特点 |
|
||||||
|
|------|------|------|---------|
|
||||||
|
| **人（People Notes / A 线）** | 用户偏好、稳定画像、Agent 自身认知 | 绑定用户 | 快速预取 |
|
||||||
|
| **事（Core Records / B 线）** | 工作事件、项目事实、任务记录 | 绑定工作区和客户 | 抽取 → 向量化 → 实体关联 → 召回 → 精排 |
|
||||||
|
| **经验（Experience）** | 可复用流程、失败模式、验证习惯、恢复策略 | 脱敏后共享 | 准入规则严格，不入业务隐私 |
|
||||||
|
|
||||||
|
## 经验记忆的准入规则
|
||||||
|
|
||||||
|
经验记忆更像「方法库」。以下内容**不应**进入经验记忆：
|
||||||
|
- 公司名、客户名、项目名
|
||||||
|
- 财务事实、私有路径
|
||||||
|
- 一次性任务结果
|
||||||
|
|
||||||
|
以下内容**可以**进入：
|
||||||
|
- 可复用的工作流程
|
||||||
|
- 常见失败模式
|
||||||
|
- 验证习惯和检查清单
|
||||||
|
- 恢复策略
|
||||||
|
|
||||||
|
## Reconcile 机制
|
||||||
|
|
||||||
|
新记忆入库时与旧记忆比对，判断四种处理：跳过、并存、替换旧记忆、保留旧记忆。这确保记忆库不会无限膨胀。
|
||||||
|
|
||||||
|
## 设计动机
|
||||||
|
|
||||||
|
引用 [[channel-fracture|Hermes Agent Channel Fracture]] 案例——记忆写入需验证完整通道。写错、取错、串到别的任务里都会影响后续行为。分区是降低跨用户、跨任务、跨工作区污染风险的基础治理手段。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[memory-dream|Memory Dream]]
|
||||||
|
- [[memory-recall-fast-slow|快慢召回]]
|
||||||
|
- [[channel-fracture|Channel Fracture]]
|
||||||
40
concepts/mgmr-rq-kmeans.md
Normal file
40
concepts/mgmr-rq-kmeans.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "MGMR RQ-Kmeans"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [generative-recommendation, quantization, semantic-id, clustering]
|
||||||
|
sources: [GR4AD]
|
||||||
|
---
|
||||||
|
# Multi-Granularity Multi-Resolution RQ-Kmeans (MGMR)
|
||||||
|
|
||||||
|
MGMR（Multi-Granularity Multi-Resolution）RQ-Kmeans 是 [[GR4AD]] 提出的分层量化方法，用于将[[ua-sid|UA-SID]]的 MLLM 嵌入量化为离散 ID 序列。
|
||||||
|
|
||||||
|
## 核心思想
|
||||||
|
|
||||||
|
标准 RQ-Kmeans 面临两个问题：
|
||||||
|
1. **Codebook 利用率低**：部分 code 承载过多物品（高碰撞），另一部分 code 被极度稀疏使用
|
||||||
|
2. **非语义信息建模不足**：聚类可能过度依赖语义相似性，忽略业务维度（如转化类型）的区分度
|
||||||
|
|
||||||
|
MGMR 通过多粒度和多分辨率两个维度解决：
|
||||||
|
|
||||||
|
**多粒度（Multi-Granularity）**：不同层次聚焦不同语义粒度——粗粒度层关注物品大类，细粒度层关注物品子类或属性
|
||||||
|
|
||||||
|
**多分辨率（Multi-Resolution）**：每个粒度层可配置不同的聚类数（codebook 大小），在需要细分的层级分配更大 codebook
|
||||||
|
|
||||||
|
## 技术细节
|
||||||
|
|
||||||
|
RQ-Kmeans 的残差量化过程：第 $t$ 层量化的是前一层量化的残差：
|
||||||
|
$$s_t = \arg\min_c \|(e - \sum_{i=1}^{t-1} C_i[s_i]) - C_t[c]\|$$
|
||||||
|
|
||||||
|
MGMR 在此基础上对各层独立配置聚类数 $|C_t|$ 和语义粒度，并通过基数约束动态调节各 code 的承载上限。
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
在 GR4AD 部署中，MGMR 显著降低 SID 碰撞率并提升 codebook 利用率，支撑 4 亿用户规模的实时生成式推荐。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[GR4AD]]
|
||||||
|
- [[ua-sid|UA-SID]]
|
||||||
|
- [[semantic-id|Semantic ID]]
|
||||||
42
concepts/minimum-viable-context.md
Normal file
42
concepts/minimum-viable-context.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Minimum Viable Context（最小可行上下文）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [context-engineering, optimization, pattern]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Minimum Viable Context (MVC)
|
||||||
|
|
||||||
|
> [[context-engineering|Context Engineering]] 中的核心方法论之一：严控单次请求体积，只组合最必需的用户目标、检索结果与当前工具定义，避免信息冗余。
|
||||||
|
|
||||||
|
## 与 MVC（软件工程）的类比
|
||||||
|
|
||||||
|
借鉴最小可行产品（MVP）的思想：
|
||||||
|
|
||||||
|
- **不是"给得越多越好"**：超出模型注意力预算的信息会稀释信号
|
||||||
|
- **高信号 Token 优先**：每次请求找到最小的高信号 Token 集
|
||||||
|
|
||||||
|
## 核心原则
|
||||||
|
|
||||||
|
1. **按需装配**：不预加载全部上下文，运行时动态组合
|
||||||
|
2. **目标导向**：以当前任务的 Goal 为锚点筛选
|
||||||
|
3. **工具定义克制**：不暴露全部工具，仅提供当前步骤相关的
|
||||||
|
|
||||||
|
## 与相关模式的配合
|
||||||
|
|
||||||
|
- [[just-in-time-retrieval|JIT 检索]]：初始仅维护轻量引用，按需实时加载
|
||||||
|
- [[context-failure-modes|Context Overflow]] 的预防手段
|
||||||
|
- 渐进式披露（Progressive Disclosure）：先暴露名称，按需加载细节
|
||||||
|
|
||||||
|
## 工程实践
|
||||||
|
|
||||||
|
Anthropic Skills 采用此设计哲学：Skills 的完整内容不在每次请求中全量加载，而是先暴露名称和摘要，模型按需调用。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-engineering|Context Engineering]]
|
||||||
|
- [[context-failure-modes|上下文故障模式]]
|
||||||
|
- [[just-in-time-retrieval|JIT 检索]]
|
||||||
40
concepts/misalignment-budget.md
Normal file
40
concepts/misalignment-budget.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "不对齐预算 (Misalignment Budget)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [robustness, misalignment, cross-modal, certification]
|
||||||
|
sources: ["arXiv:2606.18839"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 不对齐预算 (Misalignment Budget)
|
||||||
|
|
||||||
|
语义鲁棒性认证中显式建模跨模态（视觉-文本）嵌入不对齐的参数 $\delta \geq 0$，用于量化证书在嵌入不对齐下的可靠性。
|
||||||
|
|
||||||
|
## 假设
|
||||||
|
|
||||||
|
**Bounded Misalignment (Assumption 4.4)**：存在 $\delta \geq 0$，使得对于语义匹配的嵌入对 $(z, u)$，有 $\|z - u\|_2 \leq \delta$。
|
||||||
|
|
||||||
|
## 作用
|
||||||
|
|
||||||
|
$\delta$ 控制三个层面：
|
||||||
|
|
||||||
|
1. **Margin tolerance**：$\varepsilon_{c,c'} = \delta \|u_c - u_{c'}\|_2$ — 边界穿越的不确定范围
|
||||||
|
2. **Stability condition** (Prop 4.6)：若 $m_{\hat{y},c'}(\varphi) > \delta \|u_{\hat{y}} - u_{c'}\|_2$，则 $\delta$-邻域内预测稳定
|
||||||
|
3. **Crossing localization** (Lemma 4.7)：所有可能的穿越点必然在不确定集 $U_{c,c'}(\delta)$ 中
|
||||||
|
|
||||||
|
## 实验发现
|
||||||
|
|
||||||
|
- $\delta$ 增大 → stable coverage 下降（预期：更保守）
|
||||||
|
- empirical invariance 保持较高 → 证书偏保守但可靠
|
||||||
|
- conditional invariance 高 → 被认证的区间确实稳定
|
||||||
|
|
||||||
|
## 实际意义
|
||||||
|
|
||||||
|
$\delta$ 是用户可以调整的参数：更大的 $\delta$ 意味着更保守但更可靠的证书；更小的 $\delta$ 对应更精确但可能遗漏真实不对齐。类似于 $L_p$ 认证中的扰动半径。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[semantic-robustness-certification|语义鲁棒性认证]]
|
||||||
|
- [[prediction-invariant-intervals|预测不变区间]]
|
||||||
|
- [[semantic-robustness-certification-vlm-2026|论文原文]]
|
||||||
43
concepts/mlp-width-tapering.md
Normal file
43
concepts/mlp-width-tapering.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "MLP Width Tapering（MLP 宽度渐缩）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [language-model, mlp, architecture, efficiency, transformer]
|
||||||
|
sources: [[tapered-language-models]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# MLP Width Tapering
|
||||||
|
|
||||||
|
> [[depth-aware-capacity-allocation|深度感知容量分配]] 的具体实例化：在固定总参数量下，将 Transformer/LLM 中 MLP 的中间层宽度（d_ff）沿深度单调递减。
|
||||||
|
|
||||||
|
## 为什么选 MLP
|
||||||
|
|
||||||
|
| 组件 | 参数占比 | 跨架构通用性 | 调节轴 |
|
||||||
|
|------|---------|-------------|--------|
|
||||||
|
| **MLP (FFN)** | 主导（~2/3） | 所有架构共享 | 单一标量 d_ff |
|
||||||
|
| Attention | 次之 | 架构差异大 | 多头/维度耦合 |
|
||||||
|
| LayerNorm | 极小 | 通用 | 无意义 |
|
||||||
|
|
||||||
|
MLP 是自然的 taper 目标：参数量最大、架构通用、调节维度单一干净。
|
||||||
|
|
||||||
|
## Cosine Schedule
|
||||||
|
|
||||||
|
推荐的衰减方式见 [[cosine-taper-schedule|余弦衰减调度]]：
|
||||||
|
|
||||||
|
> w_ℓ = w_max · (cos(πℓ/(2L)))^p
|
||||||
|
|
||||||
|
- ℓ ∈ [0, L-1]：层索引
|
||||||
|
- p：控制陡峭度
|
||||||
|
- 最优范围：1.50× → 0.50× baseline d_ff
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
440M Transformer：uniform 16.28 → cosine taper 14.44 perplexity（零额外参数/计算）。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[depth-aware-capacity-allocation|深度感知容量分配]]
|
||||||
|
- [[cosine-taper-schedule|余弦衰减调度]]
|
||||||
|
- [[tapered-language-models|Tapered Language Models]]
|
||||||
41
concepts/model-proposes-harness-executes.md
Normal file
41
concepts/model-proposes-harness-executes.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Model Proposes, Harness Executes"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [harness-engineering, safety, principle, agent]
|
||||||
|
sources: [[prompt-to-loop-engineering-2026]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Model Proposes, Harness Executes
|
||||||
|
|
||||||
|
> [[harness-engineering|Harness Engineering]] 八条非妥协原则之首：模型仅负责**提议**，Harness 才拥有**最终执行权**。
|
||||||
|
|
||||||
|
## 八条非妥协原则
|
||||||
|
|
||||||
|
1. **Model proposes — Harness executes**：模型提议，Harness 执行
|
||||||
|
2. **Every call returns a result**：即使超时或拒绝，也必须结构化回传
|
||||||
|
3. **Risk changes the process**：按风险动态匹配只读/草稿/外部写入三档权限
|
||||||
|
4. **Draft 与 Commit 分离**：危险操作必须由人类显式确认
|
||||||
|
5. **Context is assembled, not dumped**：上下文分层装配，不能直接倾倒
|
||||||
|
6. **Long tasks have budgets**：从步数、时间、Token、成本四维卡死预算
|
||||||
|
7. **Skills & Connectors 渐进式披露**：先暴露名称，按需加载细节
|
||||||
|
8. **Recurring failures become Harness features**：重复偶发错误沉淀为 Hook 或校验器
|
||||||
|
|
||||||
|
## 信任边界
|
||||||
|
|
||||||
|
物理基础设施 → 安全沙箱 → Agent Harness → 运行时 → **模型**（最不可信的内核）。
|
||||||
|
|
||||||
|
模型执行的每个高风险动作必须经过外围 Harness 规则的解析与沙箱隔离。
|
||||||
|
|
||||||
|
## 反面案例
|
||||||
|
|
||||||
|
2026 年 DataTalks.Club 事故：Claude Code 执行 `terraform destroy`，因 Harness 缺位（无二次确认、无基础设施红线、无 Human-in-the-Loop），生产数据库、集群及备份被物理抹除。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[harness-engineering|Harness Engineering]]
|
||||||
|
- [[skill-issue-framework|Skill Issue 框架]]
|
||||||
|
- [[human-in-the-loop|Human-in-the-Loop]]
|
||||||
|
- [[circuit-breaker-pattern|熔断器]]
|
||||||
36
concepts/multi-model-routing.md
Normal file
36
concepts/multi-model-routing.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "多模型路由（Multi-Model Routing）"
|
||||||
|
created: 2026-07-03
|
||||||
|
updated: 2026-07-03
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "model-routing", "cost", "latency"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 多模型路由
|
||||||
|
|
||||||
|
> 不是把所有任务都交给同一个最强模型，而是按工作区分配合适的模型。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
**多模型路由** 是 [[workspace-first-architecture|Workspace-first 架构]] 在模型层的实践：不同工作区绑定不同模型，兼顾成本、延迟和数据安全。
|
||||||
|
|
||||||
|
## 路由策略
|
||||||
|
|
||||||
|
| 任务类型 | 推荐模型 | 原因 |
|
||||||
|
|---------|---------|------|
|
||||||
|
| 常规沟通 | 便宜模型 | 成本优先 |
|
||||||
|
| 网页检索 | 中等模型 | 延迟敏感 |
|
||||||
|
| 文件处理/代码 | 中等模型 | 工具调用密集 |
|
||||||
|
| 复杂分析 | 强模型 | 推理质量优先 |
|
||||||
|
| 敏感数据 | 本地模型 | 数据不出内网 |
|
||||||
|
|
||||||
|
## 与边界设计的关系
|
||||||
|
|
||||||
|
多模型路由是实现 [[agent-boundary-design|Agent 边界设计]] 中「模型边界」的具体手段。它让 Harness 层而非模型层面决定"这一轮该用哪个模型"。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[zleap-workspace-harness-2026|Zleap-Agent Harness 设计]]
|
||||||
|
- [[workspace-first-architecture|Workspace-first 架构]]
|
||||||
|
- [[agent-boundary-design|Agent 边界设计]]
|
||||||
40
concepts/nokv.md
Normal file
40
concepts/nokv.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "NoKV"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [agent, workspace, filesystem, metadata, infrastructure]
|
||||||
|
sources: ["https://nokv.io/blog/agents-want-filesystems"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# NoKV
|
||||||
|
|
||||||
|
面向 AI Agent workspace 的元数据控制层，把实验 run、日志、checkpoint、artifact 等工作结果放进一个文件系统形态的命名空间，让 Agent 可以用 `ls`/`grep`/`read` 去找线索、看证据、引用行号。
|
||||||
|
|
||||||
|
## 定位
|
||||||
|
|
||||||
|
- 列入 **CNCF Cloud Native Landscape**（AI Native Infra / Storage 分区）
|
||||||
|
- 早期 Go 原生存储引擎被 **CMU dbdb.io** 收录（历史条目）
|
||||||
|
- 当前主线：Rust 实现的 Agent workspace 文件系统产品线
|
||||||
|
|
||||||
|
## 接口形态
|
||||||
|
|
||||||
|
`nokv_native_v1` 提供类 POSIX 语义：
|
||||||
|
- `ls`：目录列举 → run 是目录，日志是文件
|
||||||
|
- `stat`：对象元数据卡片
|
||||||
|
- `catalog`：发现可查询字段
|
||||||
|
- `find`：过滤、排序、limit、字段投影下推
|
||||||
|
- `aggregate`：聚合查询
|
||||||
|
- `read`：按需读取内容
|
||||||
|
- `grep`：递归搜索，返回带行号的证据
|
||||||
|
|
||||||
|
## 核心理念
|
||||||
|
|
||||||
|
不是「文件系统替代数据库」，而是在数据库/对象存储之上加一层 **Agent-friendly 元数据控制层**——把复杂性留在系统里，把清晰、局部、可引用的操作面交给 Agent。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[agent-workspace-filesystem|Agent 工作空间文件系统]]
|
||||||
|
- [[agents-want-filesystems-nokv-2026|新智元报道]]
|
||||||
|
- [[progressive-disclosure|渐进式披露]]
|
||||||
|
- [[pushdown-in-agent-interface|Agent 接口下推]]
|
||||||
28
concepts/open-vocabulary-recognition.md
Normal file
28
concepts/open-vocabulary-recognition.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
---
|
||||||
|
title: "开放词表识别 (Open-Vocabulary Recognition)"
|
||||||
|
created: 2026-07-04
|
||||||
|
updated: 2026-07-04
|
||||||
|
type: concept
|
||||||
|
tags: [vision, classification, zero-shot, vlm]
|
||||||
|
sources: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# 开放词表识别 (Open-Vocabulary Recognition)
|
||||||
|
|
||||||
|
利用 VLM 的文本-图像对齐能力，不依赖预定义标签集，直接用自然语言描述类别进行识别。
|
||||||
|
|
||||||
|
## 与零样本分类的关系
|
||||||
|
|
||||||
|
- 零样本分类（[[zero-shot-classification]]）：在训练中未见过的类别上做预测
|
||||||
|
- 开放词表识别：更广泛的框架——任何可被自然语言描述的类别都可识别，无需在训练中显式定义标签空间
|
||||||
|
|
||||||
|
## VLM 实现
|
||||||
|
|
||||||
|
VLM 将类别名（或描述性 prompt）编码为文本嵌入，与图像嵌入做余弦相似度匹配：
|
||||||
|
$$f(x) = \arg\max_c \langle f_{\text{img}}(x), f_{\text{text}}(t_c) \rangle$$
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[vision-language-models|VLM]]
|
||||||
|
- [[clip|CLIP]]
|
||||||
|
- [[text-proxy-for-semantics|文本语义代理]]
|
||||||
34
concepts/parallel-drafting.md
Normal file
34
concepts/parallel-drafting.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "Parallel Drafting"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, llm-inference, parallel-generation]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Parallel Drafting
|
||||||
|
|
||||||
|
并行草稿（Parallel Drafting）是[[speculative-decoding|投机解码（Speculative Decoding）]]中草稿模型的一种架构范式：所有 $\gamma$ 个草稿位置在单次前向传播中同时生成，使草稿延迟 $T_{draft}$ 几乎独立于块大小。这与[[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]形成鲜明对比——后者的 $T_{draft} \propto \gamma$。
|
||||||
|
|
||||||
|
## 核心优势
|
||||||
|
|
||||||
|
$O(1)$ 的草稿延迟允许并行草稿器使用**更深的网络架构**和**更大的候选块**（如 $\gamma=16$），而不按比例增加延迟。在第一个草稿位置上，更深网络带来的容量优势产生了显著的准确率差距——而第一个 token 的接受率对整个块的期望接受长度影响最大（前缀接受机制）。
|
||||||
|
|
||||||
|
## 核心缺陷
|
||||||
|
|
||||||
|
**缺乏 token 间依赖建模**：每个位置独立预测，无法条件化于同块内先前采样的 token。当上下文允许多种合理延续时（如 "of course" 和 "no problem"），可能产生"of problem"或"no course"等不一致组合，即[[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]。
|
||||||
|
|
||||||
|
这导致了**后缀接受率衰减（suffix decay）**：接受率从位置 1 的高起点快速下降到后面位置的低谷（如 Chat 场景从 ~0.72 降到 ~0.52），而自回归草稿器反而在后续位置维持或上升。
|
||||||
|
|
||||||
|
## 代表方法
|
||||||
|
|
||||||
|
| 方法 | 关键机制 |
|
||||||
|
|------|---------|
|
||||||
|
| [[DFlash]] | [[kv-injection|KV 注入（KV Injection）]]，并行生成全部 mask token |
|
||||||
|
| Medusa | 多个独立草稿头，无需额外草稿模型 |
|
||||||
|
| [[DSpark]] | 半自回归：并行骨干 + 轻量级顺序头 |
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]] — 通过半自回归解决后缀衰减
|
||||||
|
- [[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]
|
||||||
45
concepts/parameter-efficient-training.md
Normal file
45
concepts/parameter-efficient-training.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Parameter-Efficient Training: 参数高效训练"
|
||||||
|
created: 2026-06-25
|
||||||
|
updated: 2026-06-25
|
||||||
|
type: concept
|
||||||
|
tags: [efficient-training, model-compression, meta-learning]
|
||||||
|
sources: ["[[sen-mapping-networks]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Parameter-Efficient Training (参数高效训练)
|
||||||
|
|
||||||
|
Parameter-Efficient Training 指在不显著损失模型性能的前提下，大幅减少**可训练参数量**的方法论。
|
||||||
|
|
||||||
|
## 主要策略分类
|
||||||
|
|
||||||
|
### 1. 内部缩减（训练目标网络本身）
|
||||||
|
|
||||||
|
- **Pruning**：训练中或训练后稀疏化（[[lottery-ticket-hypothesis|Lottery Ticket]]）
|
||||||
|
- **Quantization-Aware Training (QAT)**：低精度训练
|
||||||
|
- **Low-Rank 约束**：W ≈ UV^T，训练 U, V 而非 W
|
||||||
|
|
||||||
|
### 2. 外部缩减（不训练目标网络）
|
||||||
|
|
||||||
|
- **[[hypernetworks|HyperNetworks]]**：另一个网络生成权重（但仍需训练目标网络）
|
||||||
|
- **[[sen-mapping-networks|Mapping Networks]]**：仅训练隐向量，目标网络不训练 ← 最激进的外部缩减
|
||||||
|
- **预测参数**：从少量给定权重预测其余权重
|
||||||
|
|
||||||
|
### 3. 混合策略
|
||||||
|
|
||||||
|
Mapping Networks + LRD（低秩分解 FC 层）+ Pruning，同时减少训练和推理参数。
|
||||||
|
|
||||||
|
## Mapping Networks 的定位
|
||||||
|
|
||||||
|
在图 1 的分类框架中，Mapping Networks 处于**理想位置**：
|
||||||
|
|
||||||
|
- **训练聚焦**（而非仅推理聚焦）
|
||||||
|
- **外部缩减**（不训练目标网络）
|
||||||
|
- **利用流形结构**（Weight-Manifold Hypothesis）
|
||||||
|
- 200–500× 可训练参数缩减，500× 参数效率（99.5% 缩减）
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[low-rank-decomposition]]
|
||||||
|
- [[weight-modulation]]
|
||||||
|
- [[mapping-theorem]]
|
||||||
35
concepts/pareto-frontier-llm-serving.md
Normal file
35
concepts/pareto-frontier-llm-serving.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "Pareto Frontier (LLM Serving)"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [llm-serving, performance-engineering, trade-off-analysis]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Pareto Frontier in LLM Serving
|
||||||
|
|
||||||
|
在 LLM 服务系统中，Pareto 前沿描述了**系统吞吐量**和**每用户生成速度（交互性）**之间的最优权衡边界。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
在给定硬件和并发约束下，任何操作系统吞吐量（token/s/GPU）和每用户生成速度（tok/s/user）的组合落在 Pareto 前沿上意味着：提高一个指标必然降低另一个。
|
||||||
|
|
||||||
|
## DSpark 的贡献
|
||||||
|
|
||||||
|
[[DSpark]] 通过[[hardware-aware-prefix-scheduler|硬件感知前缀调度器（Hardware-Aware Prefix Scheduler）]]的负载自适应验证预算分配，将 DeepSeek-V4 服务的 Pareto 前沿**整体外移**：
|
||||||
|
|
||||||
|
| 系统 | SLA | MTP-1 吞吐量 | DSpark 吞吐量 | 提升 |
|
||||||
|
|------|-----|------------|-------------|------|
|
||||||
|
| V4-Flash | 80 tok/s/user | 基线 | +51% | — |
|
||||||
|
| V4-Flash | 120 tok/s/user | 近失效 | 维持可用 | 前沿解锁 |
|
||||||
|
| V4-Pro | 35 tok/s/user | 基线 | +52% | — |
|
||||||
|
| V4-Pro | 50 tok/s/user | 近失效 | 维持可用 | 前沿解锁 |
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
DSpark 并未消除投机解码的 trade-off 本身（仍有草稿端固定成本），但通过**智能路由验证预算**——闲置计算→长验证、高并发→短验证——最大化了给定预算下的收益，从而在相同硬件上实现此前不可达的性能层级。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[hardware-aware-prefix-scheduler|硬件感知前缀调度器（Hardware-Aware Prefix Scheduler）]]
|
||||||
43
concepts/perfect-sequences.md
Normal file
43
concepts/perfect-sequences.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Perfect Sequences（完美序列）"
|
||||||
|
created: 2026-06-29
|
||||||
|
updated: 2026-06-29
|
||||||
|
type: concept
|
||||||
|
tags: [combinatorics, ramsey-theory, sequence, vector]
|
||||||
|
sources: [[ramsey-sphere-lowerbound]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Perfect Sequences
|
||||||
|
|
||||||
|
> Ma, Shen, Xie (2026) 在 Ramsey 下界证明中引入的组合新概念，用于刻画 [[random-sphere-graph|随机球面图]] 中单位向量的邻接结构。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
对于单位球面 S^k 上的单位向量集合，一个完美序列捕捉了向量的排列及其在球面测度下的邻接概率行为。
|
||||||
|
|
||||||
|
（形式化定义需引用原始论文 Section 5；核心直觉：完美序列是将球面上向量的"邻接模式"编码为可分析的离散组合结构。）
|
||||||
|
|
||||||
|
## 在证明中的作用
|
||||||
|
|
||||||
|
1. **Section 5**：引入完美序列作为分析工具
|
||||||
|
2. **Section 6**：估计完美序列的概率上下界
|
||||||
|
3. **Section 7**：证明完美序列"捕获"随机球面图避免大团的本质行为
|
||||||
|
4. **Section 8**：基于完美序列推导关键量的精确估计
|
||||||
|
|
||||||
|
## 为什么需要完美序列
|
||||||
|
|
||||||
|
经典 [[probabilistic-method|概率方法]] 中，边的存在性是独立事件，联合概率可因式分解。但在 [[random-sphere-graph|随机球面图]] 中，由于几何测度的引入，边的独立性被打破。完美序列提供了一种**组合编码**，将几何依赖关系转化为可分析的离散结构。
|
||||||
|
|
||||||
|
## 技术特点
|
||||||
|
|
||||||
|
- 将连续几何问题离散化，但不损失指数级的精度
|
||||||
|
- 与球面上的测度估计紧密结合
|
||||||
|
- 使得概率下界的计算在技术上可行
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[random-sphere-graph|随机球面图]]
|
||||||
|
- [[ramsey-sphere-lowerbound|Ramsey 下界指数改进]]
|
||||||
|
- [[probabilistic-method|概率方法]]
|
||||||
|
- [[ramsey-theory|Ramsey 理论]]
|
||||||
37
concepts/position-wise-conditional-acceptance.md
Normal file
37
concepts/position-wise-conditional-acceptance.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "Position-wise Conditional Acceptance"
|
||||||
|
created: 2026-06-28
|
||||||
|
updated: 2026-06-28
|
||||||
|
type: concept
|
||||||
|
tags: [speculative-decoding, evaluation-metric, analysis]
|
||||||
|
sources: [DSpark]
|
||||||
|
---
|
||||||
|
# Position-wise Conditional Acceptance
|
||||||
|
|
||||||
|
逐位置条件接受率是 [[DSpark]] 论文引入的细粒度草稿质量分析度量。与标准的接受长度不同，该指标**移除前缀惩罚**，仅测量每个位置本身的预测质量。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
对于草稿位置 $k$，评估分母仅计入**所有前驱 token $1:k-1$ 均被目标模型接受**的实例。分子则统计这些有效实例中位置 $k$ 的 token 也被接受的比例。
|
||||||
|
|
||||||
|
$$\text{cond_acc}(k) = \frac{\#\{\text{accept}_{1:k}\}}{\#\{\text{accept}_{1:k-1}\}}$$
|
||||||
|
|
||||||
|
## 洞察
|
||||||
|
|
||||||
|
这一度量揭示了不同草稿架构的结构性差异（以 Qwen3-4B 为例）：
|
||||||
|
|
||||||
|
| 场景 | 并行 DFlash | 自回归 Eagle3 | 半自回归 DSpark |
|
||||||
|
|------|-----------|-------------|---------------|
|
||||||
|
| 位置 1 (Math) | ~0.88 | ~0.81 | ~0.88 |
|
||||||
|
| 位置 7 (Chat) | ~0.52 | ~0.58 | ~0.62 |
|
||||||
|
|
||||||
|
- **并行草稿器**：位置 1 高（深网络容量）→ 后续快速衰减（独立预测，[[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]）
|
||||||
|
- **自回归草稿器**：位置 1 低（浅网络容量）→ 后续维持或上升（条件化于已采样 token）
|
||||||
|
- **DSpark**：继承了并行草稿器的高初始能力 + 顺序头遏制后缀衰减
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[DSpark]]
|
||||||
|
- [[parallel-drafting|并行草稿（Parallel Drafting）]]
|
||||||
|
- [[autoregressive-drafting|自回归草稿（Autoregressive Drafting）]]
|
||||||
|
- [[cross-mode-collision|跨模态碰撞（Cross-Mode Collision）]]
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user