20260601
This commit is contained in:
59
articles/claw-eval.md
Normal file
59
articles/claw-eval.md
Normal file
@@ -0,0 +1,59 @@
|
|||||||
|
---
|
||||||
|
title: "Claw-Eval:面向自主Agent的端到端评测框架"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: article
|
||||||
|
tags: [agent, evaluation, benchmark, safety, robustness]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Claw-Eval:面向自主 Agent 的端到端评测框架
|
||||||
|
|
||||||
|
> Agent 评测范式的转变:从看最终答案到看完整过程,从展示能力到验证可靠性,从单次成功到稳定、可审计、可复核的任务完成。
|
||||||
|
|
||||||
|
## 核心设计理念
|
||||||
|
|
||||||
|
- **轻量运行层 + 真实任务**:不追求复杂工程增强,用统一、可审计的基座承载真实复杂工作流
|
||||||
|
- **Setup → Execution → Judge** 生命周期:完整记录模型行为、工具调用、服务端日志和环境快照
|
||||||
|
- 300 个人工验证任务,14 个前沿模型
|
||||||
|
|
||||||
|
## 三大任务组
|
||||||
|
|
||||||
|
| 任务组 | 重点考察 |
|
||||||
|
|-------|---------|
|
||||||
|
| 通用服务任务 | 多工具、多服务环境中的任务拆解与执行 |
|
||||||
|
| 多模态任务 | 视频/文档/图像理解 + 主动生成 |
|
||||||
|
| 多轮专业对话 | 信息不完整时主动提问、澄清条件、形成建议 |
|
||||||
|
|
||||||
|
## 三维护评分
|
||||||
|
|
||||||
|
- **[[agent-completion-evaluation|Completion]]**:任务是否完成,结果是否符合要求
|
||||||
|
- **[[agent-safety-evaluation|Safety]]**:执行过程是否遵守约束
|
||||||
|
- **[[agent-robustness-evaluation|Robustness]]**:面对故障时能否恢复
|
||||||
|
|
||||||
|
## Pass@k vs Pass^k:能力 ≠ 稳定性
|
||||||
|
|
||||||
|
- **[[pass-at-k-vs-pass-k|Pass@3]]**:三次中至少成功一次 → 接近能力上限
|
||||||
|
- **[[pass-at-k-vs-pass-k|Pass^3]]**:三次全部成功 → 接近可靠性下限
|
||||||
|
- 错误注入实验中 Pass^3 最高下降 24 个百分点
|
||||||
|
|
||||||
|
## 三个关键发现
|
||||||
|
|
||||||
|
1. **[[agent-process-evaluation|只看对话轨迹不可靠]]**:LLM Judge 漏掉 44% 安全违规和 13% 鲁棒性问题
|
||||||
|
2. **[[agent-capability-stability-gap|能力 ≠ 稳定性]]**:一次成功不能代表稳定可用
|
||||||
|
3. **[[agent-multidimensional-capability|Agent 能力是多维的]]**:最高多模态 Pass^3 仅 25.7%
|
||||||
|
|
||||||
|
## 关键洞察:问题质量 > 问题数量
|
||||||
|
|
||||||
|
[[question-quality-vs-quantity]]:在多轮专业对话中,问题质量解释 76% 的 Pass^3 表现差异,而平均对话轮数与最终表现几乎没有相关性。好的 Agent 不只是会追问,更要知道当前最该问什么。
|
||||||
|
|
||||||
|
## 与 Agent Harness Engineering 的联系
|
||||||
|
|
||||||
|
Claw-Eval 的设计理念与 [[etclovg-taxonomy]] 中的 V 层([[verification-evaluation]])和 O 层([[observability]])直接对应:它的混合评测管线(对话记录 + 服务端日志 + 环境快照)正是 [[trace-native-evaluation]] 的实践——不只看最终对错,还要从踪迹中诊断失败。
|
||||||
|
|
||||||
|
## 开源资源
|
||||||
|
|
||||||
|
- 数据集:ModelScope `claw-eval/Claw-Eval`
|
||||||
|
- 排行榜:https://claw-eval.github.io/
|
||||||
|
- GitHub:https://github.com/claw-eval/claw-eval
|
||||||
69
articles/distributed-agent-cache-sync-2026.md
Normal file
69
articles/distributed-agent-cache-sync-2026.md
Normal file
@@ -0,0 +1,69 @@
|
|||||||
|
---
|
||||||
|
title: "分布式Agent缓存同步:从单机到多机的Prompt Caching架构升级"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: article
|
||||||
|
source: "微信公众号"
|
||||||
|
url: "https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"
|
||||||
|
tags: ["distributed-systems", "prompt-caching", "quant-trading", "agent", "redis", "rdma"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 分布式Agent缓存同步
|
||||||
|
|
||||||
|
> **来源**: 微信公众号技术文章 (LLM + 量化交易系列) | 收录时间: 2026-05-29
|
||||||
|
|
||||||
|
## 核心问题
|
||||||
|
|
||||||
|
在高频量化系统的分布式多机架构中,[[prompt-caching]] 面临一个根本性挑战:单机的前缀匹配缓存机制被物理网络彻底割裂。当一个节点上的 Agent 已经积累了 150k Token 的"热"上下文时,另一个节点发起的协作请求将遭遇**全额冷启动**——秒级延迟在高频交易中不可接受。
|
||||||
|
|
||||||
|
## 解决方案架构
|
||||||
|
|
||||||
|
### 1. 全局上下文哈希树
|
||||||
|
每个 Agent 不直接构建 Prompt 字符串,而是在本地构建逻辑 ContextNode 树:
|
||||||
|
```
|
||||||
|
Global Layer SHA → Project Layer SHA → Session Layer SHA → Current Turn SHA
|
||||||
|
```
|
||||||
|
四个 SHA-256 哈希组合成 128 字节的复合键,作为会话在分布式网络中的唯一标识符。
|
||||||
|
|
||||||
|
参见 [[global-context-hash-tree]]
|
||||||
|
|
||||||
|
### 2. Redis 分布式状态路由
|
||||||
|
基于 Redis 集群维护 `Cache_Routing_Table`,异步记录每个前缀的物理分布(node_ip, service_provider, status, expire_time),使任何节点可通过哈希检索获知某前缀在哪些节点处于 "HOT" 状态。
|
||||||
|
|
||||||
|
参见 [[distributed-cache-routing]]
|
||||||
|
|
||||||
|
### 3. 主动预热流水线
|
||||||
|
核心创新是 **Shadow Calling**——在交易临界点到来前,预测性地向目标节点发送 `max_tokens=1` 的影子请求,填充其缓存前缀后丢弃输出。三步法:前缀拓扑合成 → 异步影子调用 → 状态置标。
|
||||||
|
|
||||||
|
参见 [[active-cache-warmup]], [[shadow-calling]]
|
||||||
|
|
||||||
|
### 4. 一致性治理
|
||||||
|
采用 Redis 分布式乐观锁 + 上下文版本号机制,防止并发写入导致缓存"分叉"。落后实例触发 Context-Realign 操作。
|
||||||
|
|
||||||
|
参见 [[distributed-optimistic-locking]]
|
||||||
|
|
||||||
|
### 5. 旁路网络句柄分发
|
||||||
|
C++ 内核与 Agent 之间的数据传输通过 8 字节句柄传递(而非完整数据),大宗数据通过 RDMA 在物理机间静默同步。应用层传递精简句柄,物理层旁路搬运大数据。
|
||||||
|
|
||||||
|
参见 [[bypass-network-handle-distribution]]
|
||||||
|
|
||||||
|
### 6. 混沌工程与降级
|
||||||
|
网络分区时触发本地降级:切断跨机预热 → Context Pruning(裁剪至 8k Token)→ 单机孤岛模式运行。
|
||||||
|
|
||||||
|
参见 [[context-pruning]]
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
> 分布式环境下的 Prompt Caching 同步,本质上是用**空间的确定性**(高带宽内网 + 精确 Redis 路由)来换取**时间的确定性**(消除 LLM 秒级重算延迟)。
|
||||||
|
|
||||||
|
## 概念网络
|
||||||
|
|
||||||
|
- [[distributed-prompt-caching]] — 分布式 Prompt 缓存体系
|
||||||
|
- [[global-context-hash-tree]] — SHA-256 四层复合键
|
||||||
|
- [[distributed-cache-routing]] — Redis 路由表
|
||||||
|
- [[active-cache-warmup]] — 预测性跨机预热
|
||||||
|
- [[shadow-calling]] — 影子调用机制
|
||||||
|
- [[distributed-optimistic-locking]] — 分布式乐观锁
|
||||||
|
- [[bypass-network-handle-distribution]] — 旁路句柄分发
|
||||||
|
- [[context-pruning]] — 上下文剪枝降级
|
||||||
|
- [[trading-lifecycle-driven-eviction]] — 交易生命周期 TTL
|
||||||
73
articles/lyu-model-harness-evolution-2026.md
Normal file
73
articles/lyu-model-harness-evolution-2026.md
Normal file
@@ -0,0 +1,73 @@
|
|||||||
|
---
|
||||||
|
title: "Model与Harness的关系演进:从AutoHarness到Heuristic Learning"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: article
|
||||||
|
author: "吕明"
|
||||||
|
source: "微信公众号"
|
||||||
|
url: "https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"
|
||||||
|
tags: ["model", "harness", "agent", "genai", "heuristic-learning", "autoharness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Model与Harness的关系演进
|
||||||
|
|
||||||
|
> **作者**: 吕明 | **来源**: 微信公众号 | **收录**: 2026-05-29
|
||||||
|
|
||||||
|
## 核心命题
|
||||||
|
|
||||||
|
随着 [[autoharness|AutoHarness]] 等工作的出现,**Model 与 Harness 之间的边界正在发生根本性演进**——"策略算法"与"工程约束"不再是两个独立世界,而是正在融合为一个紧密依赖、难以割裂的共同体。
|
||||||
|
|
||||||
|
## 三大支柱:GenAI 区别于前几次 AI 浪潮的本质
|
||||||
|
|
||||||
|
作者从第一性原理出发,提炼出 GenAI 的三个关键判别要素:
|
||||||
|
|
||||||
|
| 支柱 | 含义 | 体现 |
|
||||||
|
|------|------|------|
|
||||||
|
| **生成式 Generative** | 推理模式分布的巨大灵活性 | CoT、Prompt Engineering、Harness 工程化落地 |
|
||||||
|
| **通用性 General** | Scaling law 驱动的泛化能力 | 跨任务迁移、零样本推理 |
|
||||||
|
| **统一性 Unification** | 策略算法与工程约束的统一 | 形式化规则编译 + 策略空间 tokenlized 融合 |
|
||||||
|
|
||||||
|
参见 [[generative-general-unification]]
|
||||||
|
|
||||||
|
## AutoHarness 深度解读
|
||||||
|
|
||||||
|
文章详细剖析了 [[autoharness|AutoHarness]] 的三种 Harness 模式:
|
||||||
|
|
||||||
|
1. **Harness-as-Action-Filter**:代码枚举合法动作集合 → LLM 排序选择
|
||||||
|
2. **[[harness-as-action-verifier|Harness-as-Action-Verifier]]**(核心模式):LLM 自由提议 → 代码验证 → 非法重试
|
||||||
|
3. **[[harness-as-policy|Harness-as-Policy]]**(极限模式):纯代码决策,零 LLM 推理
|
||||||
|
|
||||||
|
核心机制:**多代码假设树 + Thompson 采样 + Refiner-Critic 环**
|
||||||
|
|
||||||
|
关键数据:145 个游戏 100% 合法率,Flash+Harness 对 Pro 胜率 56.3% vs 38.2%
|
||||||
|
|
||||||
|
## Heuristic Learning:超越梯度下降
|
||||||
|
|
||||||
|
文章引入 OpenAI 翁家翌提出的 [[heuristic-learning|Heuristic Learning]](启发式学习),定位为**替代传统梯度下降的新学习范式**:
|
||||||
|
|
||||||
|
- 优化主体从 Model 参数 → Agent 整体(Model + Harness 代码)
|
||||||
|
- 循环:智能体运行 → 反馈 → 分析并修改代码 → 再次运行
|
||||||
|
- 三大优势:缓解灾难性遗忘(回归测试)、可解释性(可读代码)、样本效率
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
> **"性能提升不只能依赖于模型参数规模,也应关注 Agent Architecture 的 Harness 层"**
|
||||||
|
|
||||||
|
> **"经验或知识不仅可以被'训练'到参数里,还可以被'编程'为可维护、可进化的软件系统"**
|
||||||
|
|
||||||
|
> **"也许世界的本质即是由泛化策略 + 抽象约束的组合控制和运转的"**
|
||||||
|
|
||||||
|
## 引述:Demis Hassabis 观点
|
||||||
|
|
||||||
|
- "当前范式不会突然变成死路,但上面还要补一到两个大想法:连续学习、长期推理、记忆、系统稳定性"
|
||||||
|
- "Agent 才刚开始……现在大多数团队还在试哪里能产生真实效率,而不是只做演示"
|
||||||
|
- "未来的通用系统会调用 AlphaFold 这类专用系统,而不是把所有蛋白质知识塞进一个巨型大脑"
|
||||||
|
|
||||||
|
## 概念网络
|
||||||
|
|
||||||
|
- [[model-harness-relationship]] — Model-Harness 关系演进
|
||||||
|
- [[harness-engineering]] — Harness Engineering 作为独立工程学科
|
||||||
|
- [[heuristic-learning]] — 启发式学习新范式
|
||||||
|
- [[strategy-engineering-unification]] — 策略与工程的统一
|
||||||
|
- [[compiled-ai-paradigm]] — 编译型 AI
|
||||||
|
- [[generative-general-unification]] — GenAI 三支柱
|
||||||
94
articles/lyu-skillopt-deep-dive-2026.md
Normal file
94
articles/lyu-skillopt-deep-dive-2026.md
Normal file
@@ -0,0 +1,94 @@
|
|||||||
|
---
|
||||||
|
title: "SkillOpt深度解读:自进化Agent技能的'反向传播'与工程化Continued Evolve"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: article
|
||||||
|
author: "吕明"
|
||||||
|
source: "微信公众号"
|
||||||
|
url: "https://mp.weixin.qq.com/s/s__fdyXQG932SavQeeugcw"
|
||||||
|
tags: ["skillopt", "text-space-optimization", "self-evolution", "harness", "model-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# SkillOpt深度解读:自进化Agent的"反向传播"
|
||||||
|
|
||||||
|
> **作者**: 吕明 | **来源**: 微信公众号 | **字数**: ~1.2万字 | **收录**: 2026-05-29
|
||||||
|
|
||||||
|
## 引子
|
||||||
|
|
||||||
|
> "看到摘要里那句'We argue the skill should instead be trained as the external state of a frozen agent, with the same discipline that makes weight-space optimization reproducible'时,有一种'这层窗户纸就要被捅破了'的感觉。"
|
||||||
|
|
||||||
|
本文是对 [[yang-skillopt-2026|SkillOpt]] 论文的深度哲学解读,从表层类比深入到优化动力学的本质差异,再上升到自进化 Agent 的工程化蓝图。
|
||||||
|
|
||||||
|
## 一、表层同构与深层分野:文本 vs 权重优化
|
||||||
|
|
||||||
|
作者指出了 SkillOpt 的"文本梯度下降"类比与真实梯度下降之间的**三个根本差异**:
|
||||||
|
|
||||||
|
### 1. 梯度本质:局部一阶 vs 全局语义推理
|
||||||
|
|
||||||
|
| 维度 | 权重空间 GD | SkillOpt 文本优化 |
|
||||||
|
|------|:---:|:---:|
|
||||||
|
| 信号 | 偏微分向量(一阶局部方向) | 全局因果推理(语义理解) |
|
||||||
|
| 前提 | 连续性 + 可微性 | 离散 Token 序列 |
|
||||||
|
| 范围 | 局部微扰 | 完整行为模式分析 |
|
||||||
|
|
||||||
|
参见 [[text-vs-weight-optimization]]
|
||||||
|
|
||||||
|
### 2. 验证机制:解析链式法则 vs 经验性 hold-out
|
||||||
|
|
||||||
|
- BP 算法提供**数学上严密**的链式法则
|
||||||
|
- SkillOpt 采用**"提议-验证-接受/拒绝"的经验主义闭环**
|
||||||
|
|
||||||
|
### 3. 语义空间结构:向量度量 vs 无天然度量
|
||||||
|
|
||||||
|
参数空间有欧氏距离;文本空间中"两个 Skill 版本的距离"是什么?SkillOpt 通过 **Textual Learning Rate** 规避了此难题。
|
||||||
|
|
||||||
|
## 二、哲学隐喻:经验主义 vs 理性主义
|
||||||
|
|
||||||
|
> 梯度下降是被动的、局部的、由经验数据驱动的(**英国经验主义**)
|
||||||
|
> SkillOpt 的 Optimizer 是主动的、全局演绎的、因果导向的(**大陆理性主义**)
|
||||||
|
|
||||||
|
## 三、SkillOpt 作为 Model-Harness 协同演进的信标
|
||||||
|
|
||||||
|
SkillOpt 的核心范式贡献:**Skill 从"外部插件"升维为"可训练的外部状态"**,Harness 从"运行时支撑层"升维为"外参数空间训练场"。
|
||||||
|
|
||||||
|
这与 [[lyu-model-harness-evolution-2026|前文]] 中"策略算法与工程约束间模糊边界"形成精确共振。
|
||||||
|
|
||||||
|
## 四、未来工程化全栈蓝图
|
||||||
|
|
||||||
|
### 通用领域:Skill 生态的"集市化"
|
||||||
|
- Skill 人机协作社区优化(类似 PR + CI)
|
||||||
|
- **"Agent Skill App Store"**:跨模型、跨环境的可迁移 Skill 市场
|
||||||
|
|
||||||
|
参见 [[skill-ecosystem]]
|
||||||
|
|
||||||
|
### 企业专有领域:私域壁垒型 Skill
|
||||||
|
- 从"人脑经验"到"可训练外状态"的知识外化
|
||||||
|
- 私有验证集构建领域专属评估体系
|
||||||
|
|
||||||
|
### 五个关键使能组件
|
||||||
|
1. **Skill Registry & Version Control**
|
||||||
|
2. **Validation Suite Manager**
|
||||||
|
3. **Evolution Scheduler**
|
||||||
|
4. **Cross-Model Skill Translator**
|
||||||
|
5. **Human-in-the-Loop Review Interface**
|
||||||
|
|
||||||
|
## 五、[[dual-layer-rl|双层强化学习]]与[[skill-data-flywheel|数据飞轮]]
|
||||||
|
|
||||||
|
SkillOpt 的验证集分数天然适合作为 RL 奖励信号,可构建:
|
||||||
|
- **内层 RL**:Agent 学习如何利用 Skill 更好执行任务
|
||||||
|
- **外层 RL**:Optimizer 学习如何更好为 Agent 优化 Skill
|
||||||
|
→ 真正意义上的 **"Learning to Learn"**
|
||||||
|
|
||||||
|
同时,Skill 自进化产生的高质量轨迹可反哺模型训练:**更好的 Skill → 更好的轨迹 → 更强的模型**。
|
||||||
|
|
||||||
|
## 结语:从"教会 Agent"到"让 Agent 学会"
|
||||||
|
|
||||||
|
> 这不是 AGI,但它是通往"更具自主性的 AI 系统"的一步扎实的脚印。
|
||||||
|
|
||||||
|
## 概念网络
|
||||||
|
|
||||||
|
- [[text-vs-weight-optimization]] — 文本空间 vs 权重空间优化动力学
|
||||||
|
- [[controlled-autonomy]] — 受控的自主性
|
||||||
|
- [[skill-data-flywheel]] — 数据飞轮
|
||||||
|
- [[skill-ecosystem]] — Skill 生态与标准化
|
||||||
|
- [[dual-layer-rl]] — 双层强化学习
|
||||||
53
articles/mini-agent-harness.md
Normal file
53
articles/mini-agent-harness.md
Normal file
@@ -0,0 +1,53 @@
|
|||||||
|
---
|
||||||
|
title: "从零搭建 Mini Agent Harness"
|
||||||
|
author: "陈思州"
|
||||||
|
source: "Datawhale (微信公众号)"
|
||||||
|
date: "2026-05"
|
||||||
|
type: "article"
|
||||||
|
tags: ["agent-evaluation", "harness", "engineering", "tutorial"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 从零搭建 Mini Agent Harness
|
||||||
|
|
||||||
|
> **Agent = model + harness** — 把 Agentic model 放进一个可运行、可记录、可评分的小环境里。
|
||||||
|
|
||||||
|
## 核心问题
|
||||||
|
|
||||||
|
手动测试 Agent 只能看到最终回答,看不到它是否真的读了文件、调了什么工具、有没有凭空编造结论。[[agent-harness-mini|mini harness]] 解决的就是这个——让 Agent 的每一步都留下可分析的执行记录。
|
||||||
|
|
||||||
|
## 五大模块
|
||||||
|
|
||||||
|
| 模块 | 职责 |
|
||||||
|
|------|------|
|
||||||
|
| Task | 任务输入 |
|
||||||
|
| Environment | 可操作环境(代码仓库/文件组) |
|
||||||
|
| Tools | 工具接口 |
|
||||||
|
| Trace | 每一步的工具调用、参数、返回 |
|
||||||
|
| Grader | 基于规则/脚本的结果判断 |
|
||||||
|
|
||||||
|
详见 [[agent-harness-mini]]、[[agent-eval-trace]]、[[agent-eval-grader]]。
|
||||||
|
|
||||||
|
## Eval Case 设计
|
||||||
|
|
||||||
|
[[agent-eval-case-design|eval case]] 需要明确四个要素:任务目标、环境内容、工具范围、评分规则。案例见 [[agent-eval-case-design]]。
|
||||||
|
|
||||||
|
## 公开资料参考
|
||||||
|
|
||||||
|
- [[anthropic-agent-evals]]:区分 eval harness 与 agent harness
|
||||||
|
- [[agent-computer-interface|SWE-agent / ACI]]:Agent-Computer Interface 对表现的影响
|
||||||
|
- [[terminal-bench]]:终端环境的隔离任务评测
|
||||||
|
- [[swe-bench]]:真实 issue → patch → 测试
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
1. **Harness 让评测从"主观感觉"变成"可分析记录"**
|
||||||
|
2. **不需要一开始就做完整平台**——先串起 Task → Env → Tools → Trace → Grader 五要素
|
||||||
|
3. **定位问题的精度提升**:能区分是任务理解错误、工具选择错误、参数填写错误还是结果解读错误
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-harness-engineering|Agent Harness 工程]]
|
||||||
|
- [[harness-coupling-problem|Harness 耦合问题]]
|
||||||
|
- [[adaptive-harness-simplification|自适应 Harness 简化]]
|
||||||
|
- [[prompt-to-harness-evolution|Prompt 到 Harness 的演化]]
|
||||||
|
- [[agent-evaluation-paradigm-shift|Agent 评测范式转变]]
|
||||||
60
articles/temporal-patch-shuffle-tps.md
Normal file
60
articles/temporal-patch-shuffle-tps.md
Normal file
@@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
title: "时序预测增强方法综述:从频域到 TPS"
|
||||||
|
author: "Sai Nitesh Palamakula"
|
||||||
|
source: "DeepHub IMBA / 数据派THU"
|
||||||
|
date: "2026-05"
|
||||||
|
type: "article"
|
||||||
|
tags: ["time-series", "data-augmentation", "forecasting", "TPS", "deep-learning"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# TPS:时序预测增强方法综述
|
||||||
|
|
||||||
|
> 预测增强的核心矛盾:必须引入足够多样性,同时保持时间一致性,让增强后的信号仍然是一个合法的连续序列。
|
||||||
|
|
||||||
|
## 为什么分类增强在预测中失效
|
||||||
|
|
||||||
|
分类增强(jittering、scaling、warping)假设标签不变——但在预测中,"标签"就是序列后续部分。只扰动输入会破坏 **[[data-label-consistency|数据-标签一致性]]**,这是预测增强中单一消融性能下降最大的因素。
|
||||||
|
|
||||||
|
## 方法全景
|
||||||
|
|
||||||
|
详见 [[forecasting-augmentation-taxonomy|预测增强分类体系]]:
|
||||||
|
|
||||||
|
| 路线 | 代表方法 | 核心思想 |
|
||||||
|
|------|---------|---------|
|
||||||
|
| 频域 | [[freqmask-freqmix\|FreqMask/FreqMix]] | FFT 域 mask/mix |
|
||||||
|
| 时频域 | [[wavemask-wavemix\|WaveMask/WaveMix]] | Wavelet 多分辨率操作 |
|
||||||
|
| 频域(保守) | [[dominant-shuffle]] | 仅 shuffle top-k 主导频率 |
|
||||||
|
| 分解 | [[staug\|STAug]] | EMD → IMF → mixup |
|
||||||
|
| Patch | **[[temporal-patch-shuffle\|TPS]]** ⭐ | 重叠 patch + variance 选择 + 平均重建 |
|
||||||
|
|
||||||
|
## TPS:当前 SOTA
|
||||||
|
|
||||||
|
[[temporal-patch-shuffle]] 的六步流程:
|
||||||
|
|
||||||
|
```
|
||||||
|
x ∥ y → Overlapping Patches → Variance Score → Selective Shuffle → Average Reconstruct → x̃, ỹ
|
||||||
|
```
|
||||||
|
|
||||||
|
超参数:patch 长度 p、stride s、shuffle 比例 α(约 20 种配置的验证集搜索)。
|
||||||
|
|
||||||
|
## 消融关键发现
|
||||||
|
|
||||||
|
1. **[[data-label-consistency]] > 重叠 > variance 排序 > 时域 vs 频域**
|
||||||
|
2. Shuffle 比例 0.7-1.0 最优
|
||||||
|
3. 时域直接操作优于 FFT 后 patch 操作
|
||||||
|
|
||||||
|
## 实验覆盖
|
||||||
|
|
||||||
|
- **长期预测**:9 数据集 × 5 骨干(TSMixer/DLinear/PatchTST/TiDE/LightTS)— TPS 全胜
|
||||||
|
- **短期交通预测**:4 PeMS 数据集(PatchTST)— MSE 提升 2.34%-7.14%
|
||||||
|
- **时间序列分类**:UCR + UEA — 准确率 +0.50%/+1.10%
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
TPS 的成功来自几个叠加因素:不破坏 input-target 关系、重叠+平均守住局部时间结构、variance 引导的选择性扰动。它不是"加随机性",而是"加受控随机性"。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[time-series-forecasting-augmentation]] — 预测增强的通用框架
|
||||||
|
- [[non-stationary-time-series]] — 非平稳时间序列
|
||||||
|
- [[fourier-filter-dynamics]] — Fourier 滤波动力学
|
||||||
75
articles/ultradata-l3-open-source-2026.md
Normal file
75
articles/ultradata-l3-open-source-2026.md
Normal file
@@ -0,0 +1,75 @@
|
|||||||
|
---
|
||||||
|
title: "UltraData:面壁智能L3数据开源与数据分级治理体系"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: article
|
||||||
|
author: "面壁智能团队"
|
||||||
|
source: "Datawhale (微信公众号)"
|
||||||
|
url: "https://mp.weixin.qq.com/s/5jV2jYuXJloKX5IWCzrSpw"
|
||||||
|
tags: ["data-governance", "pretraining", "synthetic-data", "sft", "open-source", "minicpm"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# UltraData:大模型数据分级治理的开源实践
|
||||||
|
|
||||||
|
> **作者**: 面壁智能团队 | **来源**: Datawhale | **收录**: 2026-05-29
|
||||||
|
|
||||||
|
## 核心命题
|
||||||
|
|
||||||
|
> "大模型竞争的下半场,焦点正从参数规模转向数据质量。当公开语料库逐渐耗尽,如何从存量数据中榨取出更高密度的知识?"
|
||||||
|
|
||||||
|
2026年5月,面壁智能联合清华大学、OpenBMB开源 UltraData 系列 L3 数据集,并首次系统性公开 **L0-L4 数据分级治理体系**。
|
||||||
|
|
||||||
|
## 一、L0-L4 数据分级治理
|
||||||
|
|
||||||
|
告别"爬取→去重→过滤→训练"的一刀切流水线,将数据按加工深度分五级:
|
||||||
|
|
||||||
|
| 层级 | 名称 | 加工方式 | 适用阶段 |
|
||||||
|
|:---:|------|------|------|
|
||||||
|
| **L0** | 原始数据 | 采集解析,未实质性处理 | 不直接训练 |
|
||||||
|
| **L1** | 过滤数据 | 启发式规则过滤+去重 | 预训练前期 |
|
||||||
|
| **L2** | 精筛数据 | 模型打分+标签标注 | 预训练中期 |
|
||||||
|
| **L3** | 合成与增强 | 改写、合成、多风格重写、人工标注 | 退火/SFT/RL |
|
||||||
|
| **L4** | 编排数据 | 可信校验+统一编排 | RAG等知识检索 |
|
||||||
|
|
||||||
|
参见 [[data-hierarchical-governance]]
|
||||||
|
|
||||||
|
核心逻辑:**"好钢用在刀刃上"**——预训练前期广撒网(L1/L2),退火和微调阶段用高密度L3数据激发推理。
|
||||||
|
|
||||||
|
## 二、Ultra-FineWeb-L3:600B 中文合成数据
|
||||||
|
|
||||||
|
基于 L2 精筛网页,通过 Qwen3 + MiniCPM4 深度加工:
|
||||||
|
|
||||||
|
- 将"可读网页文本" → "好学Q&A数据"
|
||||||
|
- 600B Tokens(中文>200B,英文>400B)
|
||||||
|
- 全球最大中文预训练合成数据集
|
||||||
|
|
||||||
|
参见 [[synthetic-data-qa-generation]]
|
||||||
|
|
||||||
|
## 三、UltraData-SFT-2605:千万级推理秘方
|
||||||
|
|
||||||
|
- 国内首次开源千万级 SFT 数据
|
||||||
|
- 含"深思考"(完整思维链)与"非思考"样本
|
||||||
|
- 全流程质量治理透明化:Query筛选→Answer校验→评测去污
|
||||||
|
|
||||||
|
参见 [[deep-thinking-sft]]
|
||||||
|
|
||||||
|
## 四、MiniCPM5-1B:1B参数登顶
|
||||||
|
|
||||||
|
- Artificial Analysis 排行榜 **17.9分**,超越 Qwen3.5-0.8B
|
||||||
|
- INT4 仅 ~0.5GB,可运行在手机/浏览器/单片机
|
||||||
|
- L1/L2→L3→SFT 分阶段配置,最大化单位 Token 边际效益
|
||||||
|
|
||||||
|
## 五、行业意义
|
||||||
|
|
||||||
|
> "当模型架构趋于收敛,算力成本高企不下,数据成为差异化的主战场。"
|
||||||
|
|
||||||
|
UltraData 证明:通过 [[stage-matched-data-config|分阶段数据配置]],小参数也能激发出大能力。推动行业从"堆硬件堆参数"转向"数据精细化"。
|
||||||
|
|
||||||
|
## 概念网络
|
||||||
|
|
||||||
|
- [[data-hierarchical-governance]] — L0-L4 分级治理体系
|
||||||
|
- [[ultradata]] — UltraData 数据系统总览
|
||||||
|
- [[synthetic-data-qa-generation]] — 网页→Q&A合成
|
||||||
|
- [[stage-matched-data-config]] — 分阶段数据配置
|
||||||
|
- [[deep-thinking-sft]] — 深思考SFT数据
|
||||||
|
- [[data-quality-over-scale]] — 质量重于规模
|
||||||
45
concepts/action-applicability.md
Normal file
45
concepts/action-applicability.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Action Applicability (动作合法性判定)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "planning", "game-ai", "verification"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Action Applicability (动作合法性判定)
|
||||||
|
|
||||||
|
**Action Applicability** 是 AI Agent 和规划领域中的一个基本问题:在给定状态下,哪些动作是**合法**的(能被环境接受执行)?
|
||||||
|
|
||||||
|
## 问题定义
|
||||||
|
|
||||||
|
给定当前状态 s 和候选动作 a,判定 a 是否在环境允许的动作空间中:
|
||||||
|
$$\text{legal}(s, a) \in \{\text{True}, \text{False}\}$$
|
||||||
|
|
||||||
|
## 在 LLM Agent 中的尖锐表现
|
||||||
|
|
||||||
|
LLM 的 planning 能力在严格结构环境中尤为脆弱:
|
||||||
|
- Kaggle GameArena 象棋:Gemini-2.5-Flash **78%** 的失利源于非法走子
|
||||||
|
- 不是策略性失误——是**根本违反规则**
|
||||||
|
|
||||||
|
## 为什么 LLM 会失败
|
||||||
|
|
||||||
|
1. **内部世界模型不完整**:LLM 的 next-token prediction 训练目标不保证学到的状态转移函数与实际环境一致
|
||||||
|
2. **幻觉合法转移**:模型可能"自信地"断言一个非法动作是合法的
|
||||||
|
3. **Tree of Thoughts 等方法的局限**:搜索依赖 LLM 的内部模拟,合法转移可能被 hallucinate
|
||||||
|
|
||||||
|
## 解决方案
|
||||||
|
|
||||||
|
- **外部验证器**(如 [[autoharness|AutoHarness]]):将合法判定 offload 到可验证的代码
|
||||||
|
- **Fine-tuning on game trajectories**:昂贵且损害通用能力
|
||||||
|
- **手写 harness**:脆弱且不可扩展
|
||||||
|
|
||||||
|
## AI 规划领域的关联
|
||||||
|
|
||||||
|
Action applicability 在 AI 规划社区(Kokel et al., 2025)中有长期研究历史,但在 LLM Agent 兴起后变得尤为紧迫——LLM 的通用能力与结构环境中的可靠性之间存在根本张力。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[autoharness]] — 解决此问题的方法
|
||||||
|
- [[harness-as-action-verifier]] — Verifier 模式直接针对此问题
|
||||||
|
- [[lou-autoharness-2026]] — 原始论文
|
||||||
39
concepts/active-cache-warmup.md
Normal file
39
concepts/active-cache-warmup.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Active Cache Warm-up (主动缓存预热)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "caching", "optimization", "LLM"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Active Cache Warm-up (主动缓存预热)
|
||||||
|
|
||||||
|
**Active Cache Warm-up** 是 [[distributed-prompt-caching]] 中的预测性机制:在需要跨节点协作之前,通过提前向目标节点发送特殊的预热请求,使其 LLM 前缀缓存提前进入 "HOT" 状态。核心实现是 [[shadow-calling]]。
|
||||||
|
|
||||||
|
## 预热流水线三步法
|
||||||
|
|
||||||
|
### 第一步:前缀拓扑合成
|
||||||
|
从主控节点拉取因子链的最新上下文树,过滤掉尾部高频变动的实时行情,提取静态系统提示词、工具集和历史评估纪要(占体积 90%+),拼接成预备 Token 流。
|
||||||
|
|
||||||
|
### 第二步:异步影子调用([[shadow-calling]])
|
||||||
|
向目标节点发送特殊的影子请求:
|
||||||
|
- `max_tokens=1`:只需消化前缀,不需生成
|
||||||
|
- 显式启用 `cache_control`:强制打缓存标记
|
||||||
|
- 零输出下游拦截:返回结果直接丢弃
|
||||||
|
|
||||||
|
### 第三步:状态置标与就绪通知
|
||||||
|
影子调用成功后,Redis 中 status 改为 "HOT"。真实信号爆发时,该节点的 API 响应延迟降至百毫秒级。
|
||||||
|
|
||||||
|
## 预测触发机制
|
||||||
|
|
||||||
|
在量化系统中,预热由可预测事件触发:
|
||||||
|
- 盘面时间逼近风险控制窗口
|
||||||
|
- 核心标的波动率超过阈值
|
||||||
|
- 高频队列检测到临界信号
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[shadow-calling]] — 预热的核心调用机制
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[cache-cold-start]] — 预热要解决的核心问题
|
||||||
34
concepts/adaptive-harness-simplification.md
Normal file
34
concepts/adaptive-harness-simplification.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "Adaptive Harness Simplification(自适应 Harness 简化)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, optimization, simplification, meta-learning]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Adaptive Harness Simplification
|
||||||
|
|
||||||
|
> Harness 设计不应假设**单调地增加更多脚手架**。每个包装器、重置策略、验证器、规划器、记忆规则和权限门都编码了对"模型自身无法可靠完成什么"的假设。随着模型能力变化,Harness 干预应被重新评估而非假定持续有益。
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
- Anthropic(2026c):对某个模型有用的上下文重置在新模型上变得可省略,移除它们降低了成本而不降低质量
|
||||||
|
- Bölük(2026b):因子化 model-by-harness 评估可揭示干预何时改善所有模型、仅帮助特定模型家族、或逆转模型排名
|
||||||
|
|
||||||
|
## 元工程议程
|
||||||
|
|
||||||
|
- **Meta-Harness**(Lee et al., 2026):prompt、工具和控制回路可作为优化目标的一部分来搜索
|
||||||
|
- **Natural-Language Agent Harnesses**(Pan et al., 2026):使 harness 模块显式且可消融
|
||||||
|
- 生产系统应向**自适应简化**演进:持续追问哪些控制仍然必要
|
||||||
|
|
||||||
|
## 风险:Benchmark 过拟合
|
||||||
|
|
||||||
|
仅针对狭窄套件自我优化的 Harness 可能变得脆弱。更持久的目标是**自适应简化**:随着任务、工具和模型能力变化持续追问控制必要性。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[cost-quality-speed-trilemma]] — 简化是降低成本的一条路径
|
||||||
|
- [[binding-constraint-thesis]] — 约束瓶颈随模型能力变化
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
38
concepts/agent-capability-stability-gap.md
Normal file
38
concepts/agent-capability-stability-gap.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Capability-Stability Gap(能力-稳定性差距)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, capability, stability, reliability]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Capability-Stability Gap
|
||||||
|
|
||||||
|
> Agent 的"能做到"(能力上限)与"稳定做到"(可靠性下限)之间存在显著差距。这个差距在错误注入后急剧扩大。
|
||||||
|
|
||||||
|
## 度量方法
|
||||||
|
|
||||||
|
- **Capability** ← [[pass-at-k-vs-pass-k|Pass@k]]:k 次中至少成功一次
|
||||||
|
- **Stability** ← [[pass-at-k-vs-pass-k|Pass^k]]:k 次全部成功
|
||||||
|
- **Gap** = Pass@k − Pass^k
|
||||||
|
|
||||||
|
## Claw-Eval 实验
|
||||||
|
|
||||||
|
- 正常环境下 gap 已存在
|
||||||
|
- 错误注入后 gap 急剧扩大(Pass^3 下降达 24pp)
|
||||||
|
- 多模态任务中最高 Pass^3 仅 25.7%——所有模型的 gap 都很大
|
||||||
|
|
||||||
|
## 工程含义
|
||||||
|
|
||||||
|
对部署决策的影响:
|
||||||
|
- 窄 gap → Agent 适合生产环境
|
||||||
|
- 宽 gap → 需要增强 [[agent-robustness-evaluation]]、改进错误恢复策略或调整 [[harness-coupling-problem|Harness 配置]]
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[pass-at-k-vs-pass-k]]
|
||||||
|
- [[agent-robustness-evaluation]]
|
||||||
|
- [[binding-constraint-thesis]] — 稳定性问题可能源自 Harness 而非模型
|
||||||
|
- [[claw-eval]]
|
||||||
29
concepts/agent-completion-evaluation.md
Normal file
29
concepts/agent-completion-evaluation.md
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Completion Evaluation(Agent 完成度评测)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, evaluation, completion, task-completion]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Completion Evaluation
|
||||||
|
|
||||||
|
> Claw-Eval 的 Completion 维度:评测任务是否完成、结果是否符合要求。这是最基本也是最传统的评测维度。
|
||||||
|
|
||||||
|
## 与另两个维度的关系
|
||||||
|
|
||||||
|
| 维度 | 问题 | 失效模式 |
|
||||||
|
|------|------|---------|
|
||||||
|
| Completion | 做完了吗? | 遗漏步骤、结果错误 |
|
||||||
|
| Safety | 做得安全吗? | 违规操作、越权调用 |
|
||||||
|
| Robustness | 出事了能恢复吗? | 遇错崩溃、无法恢复 |
|
||||||
|
|
||||||
|
仅完成度高 ≠ 好 Agent——还需 Safety 和 Robustness 达标。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-safety-evaluation]]
|
||||||
|
- [[agent-robustness-evaluation]]
|
||||||
|
- [[claw-eval]]
|
||||||
42
concepts/agent-computer-interface.md
Normal file
42
concepts/agent-computer-interface.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Agent-Computer Interface (ACI)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "interface-design", "swe-agent"]
|
||||||
|
sources: ["mini-agent-harness", "swe-agent"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent-Computer Interface (ACI)
|
||||||
|
|
||||||
|
> SWE-agent 提出的概念:Agent 的表现不仅取决于模型,还取决于其与计算机交互的外部接口设计。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
ACI(Agent-Computer Interface)是 Agent 与执行环境之间的交互层。设计良好的 ACI 能让 Agent 更高效地查看文件、编辑代码、运行测试、接收错误反馈。
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
- **接口即能力边界**:Agent 能做的仅限于 ACI 暴露的操作
|
||||||
|
- **信息密度**:如何将文件内容、错误信息、测试结果反馈给模型,直接影响表现
|
||||||
|
- **错误可操作性**:返回的错误信息是否足够让 Agent 定位和修复问题
|
||||||
|
|
||||||
|
## ACI 设计要素
|
||||||
|
|
||||||
|
1. **查看**:文件浏览、搜索、diff 查看
|
||||||
|
2. **编辑**:代码修改、文件操作
|
||||||
|
3. **执行**:运行命令、测试、构建
|
||||||
|
4. **反馈**:错误信息、日志、测试结果
|
||||||
|
|
||||||
|
## 与 Mini Harness 的关系
|
||||||
|
|
||||||
|
[[agent-harness-mini|mini harness]] 中的 Tools 模块本质上就是 ACI 的简化版——定义了 Agent 与环境交互的接口集。
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- SWE-agent 论文中关于 ACI 设计的详细讨论
|
||||||
|
- [[terminal-bench]] — 终端环境的 ACI 实现
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-harness-mini]] — Tools 模块对应 ACI
|
||||||
|
- [[terminal-bench]] — 终端 ACI 的评测实现
|
||||||
62
concepts/agent-eval-case-design.md
Normal file
62
concepts/agent-eval-case-design.md
Normal file
@@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Eval Case Design"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "test-design", "benchmark"]
|
||||||
|
sources: ["mini-agent-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Eval Case Design
|
||||||
|
|
||||||
|
> 设计 Agent 评测用例的四要素:任务、环境、工具、评分规则。
|
||||||
|
|
||||||
|
## 四要素
|
||||||
|
|
||||||
|
1. **Task**:明确的任务描述,不模棱两可
|
||||||
|
2. **Environment**:封闭、可复现的执行环境
|
||||||
|
3. **Tools**:Agent 可用的工具白名单
|
||||||
|
4. **Grader**:[[agent-eval-grader|评分规则]]——必须可自动执行
|
||||||
|
|
||||||
|
## 示例
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"id": "case_001",
|
||||||
|
"task": "判断项目是否支持插件系统",
|
||||||
|
"environment": {
|
||||||
|
"files": {
|
||||||
|
"README.md": "本项目支持本地启动、基础登录和配置管理。",
|
||||||
|
"config.md": "配置项包括 port、theme、log_level。"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"tools": ["list_files", "read_file"],
|
||||||
|
"grader": {
|
||||||
|
"must_read": ["README.md"],
|
||||||
|
"answer_should_include": "不能确认支持插件系统",
|
||||||
|
"answer_should_not_include": "支持插件系统"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## 设计原则
|
||||||
|
|
||||||
|
- **环境可控**:每个 case 在自己的隔离环境中运行
|
||||||
|
- **任务不歧义**:避免开放式解读
|
||||||
|
- **评分自动化**:不依赖人工判断
|
||||||
|
- **渐进难度**:从简单封闭到复杂开放
|
||||||
|
|
||||||
|
## 常见测试维度
|
||||||
|
|
||||||
|
| 维度 | 测试内容 |
|
||||||
|
|------|---------|
|
||||||
|
| 工具选择 | Agent 是否为任务选择了正确的工具 |
|
||||||
|
| 文件读取 | 是否读取了正确的文件 |
|
||||||
|
| 参数正确性 | 工具调用参数是否合理 |
|
||||||
|
| 结果使用 | 回答是否基于工具返回的实际内容 |
|
||||||
|
| 步骤效率 | 是否有冗余工具调用 |
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-eval-trace]] — case 执行后的追踪记录
|
||||||
|
- [[agent-eval-grader]] — case 中的评分逻辑
|
||||||
|
- [[agent-harness-mini]] — 运行 case 的 harness 框架
|
||||||
51
concepts/agent-eval-grader.md
Normal file
51
concepts/agent-eval-grader.md
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Eval Grader"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "scoring", "grader"]
|
||||||
|
sources: ["mini-agent-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Eval Grader
|
||||||
|
|
||||||
|
> Agent 评测中的评分模块——基于规则或测试脚本判断任务执行结果。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
Grader 是 [[agent-harness-mini|mini harness]] 的最终判断模块。它接收 [[agent-eval-trace|trace]] 和最终答案,输出结构化的评分结果(success/fail + reason)。
|
||||||
|
|
||||||
|
## 评分策略演进
|
||||||
|
|
||||||
|
### Level 1:规则匹配(本文推荐)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"must_read": ["README.md"],
|
||||||
|
"answer_should_include": "不能确认支持插件系统",
|
||||||
|
"answer_should_not_include": "支持插件系统"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Level 2:测试脚本
|
||||||
|
```bash
|
||||||
|
# 运行测试验证 Agent 的代码修改是否通过
|
||||||
|
pytest tests/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Level 3:LLM-as-Judge
|
||||||
|
使用 LLM 评估复杂输出(需注意评估者偏差)
|
||||||
|
|
||||||
|
### Level 4:多维度评分
|
||||||
|
任务完成度 + 工具使用效率 + 步骤冗余度 + 幻觉检测
|
||||||
|
|
||||||
|
## 设计原则
|
||||||
|
|
||||||
|
- **可检查性**:评分规则必须明确可执行
|
||||||
|
- **可解释性**:失败必须给出 reason
|
||||||
|
- **渐进复杂度**:从规则开始,按需升级
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-eval-trace]] — Grader 的输入数据源
|
||||||
|
- [[agent-eval-case-design]] — 包含 grader 配置的评测用例
|
||||||
|
- [[agent-harness-mini]] — 包含 grader 模块的完整 harness
|
||||||
|
- [[agent-evaluation-paradigm-shift]] — 评测范式的整体转变
|
||||||
64
concepts/agent-eval-trace.md
Normal file
64
concepts/agent-eval-trace.md
Normal file
@@ -0,0 +1,64 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Eval Trace"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "trace", "logging"]
|
||||||
|
sources: ["mini-agent-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Eval Trace
|
||||||
|
|
||||||
|
> Agent 评测中每一步工具调用、参数、返回值的结构化执行记录。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
Trace 是 [[agent-harness-mini|mini harness]] 的核心模块之一,记录了 Agent 在任务执行过程中的每一步操作。它是将 Agent 行为从"黑盒"变为"白盒"的关键。
|
||||||
|
|
||||||
|
## 结构
|
||||||
|
|
||||||
|
典型的 trace 条目:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"case_id": "case_001",
|
||||||
|
"trace": [
|
||||||
|
{
|
||||||
|
"tool": "list_files",
|
||||||
|
"arguments": {"path": "."},
|
||||||
|
"result": ["README.md", "config.md"]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"tool": "read_file",
|
||||||
|
"arguments": {"path": "README.md"},
|
||||||
|
"result": "本项目支持本地启动、基础登录和配置管理。"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"answer": "当前 README 没有插件系统相关说明...",
|
||||||
|
"grade": {"success": true, "reason": "..."}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Trace 的诊断价值
|
||||||
|
|
||||||
|
Trace 让问题定位变得精确:
|
||||||
|
|
||||||
|
- **未调用关键工具** → 工具选择/理解问题
|
||||||
|
- **调用了但参数错误** → 参数填写问题
|
||||||
|
- **调用了但忽略了返回值** → 结果读取问题
|
||||||
|
- **反复调用无关工具** → 轨迹效率问题
|
||||||
|
- **答案超出工具返回内容** → 幻觉/编造问题
|
||||||
|
|
||||||
|
## 与日志的区别
|
||||||
|
|
||||||
|
| 维度 | Trace | 传统 Log |
|
||||||
|
|------|-------|---------|
|
||||||
|
| 粒度 | 每个 tool call | 应用级事件 |
|
||||||
|
| 结构化 | JSON schema | 自由格式 |
|
||||||
|
| 目的 | 评测分析 | 调试/监控 |
|
||||||
|
| 关联 | 与 case + grade 绑定 | 独立记录 |
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-eval-grader]] — 使用 trace 进行评分
|
||||||
|
- [[agent-eval-case-design]] — 设计可追踪的评测用例
|
||||||
|
- [[agent-harness-mini]] — 包含 trace 模块的完整 harness
|
||||||
35
concepts/agent-evaluation-paradigm-shift.md
Normal file
35
concepts/agent-evaluation-paradigm-shift.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "Agent 评测范式转变(Paradigm Shift in Agent Evaluation)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, evaluation, paradigm-shift]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent 评测范式转变
|
||||||
|
|
||||||
|
> 从三个维度发生的范式转移:从看最终答案 → 看完整过程;从展示能力 → 验证可靠性;从单次成功 → 稳定、可审计、可复核的任务完成。
|
||||||
|
|
||||||
|
## 旧范式 vs 新范式
|
||||||
|
|
||||||
|
| 维度 | 旧范式 | 新范式 |
|
||||||
|
|------|--------|--------|
|
||||||
|
| 评判对象 | 最终答案 | 完整执行过程 |
|
||||||
|
| 评估目标 | 能力展示 | 可靠性验证 |
|
||||||
|
| 时间尺度 | 单次成功 | 多次一致性 |
|
||||||
|
| 证据来源 | 文本输出 | 文本 + 日志 + 环境快照 |
|
||||||
|
| 评估方式 | LLM Judge | 混合评测管线 |
|
||||||
|
|
||||||
|
## 范式转变的驱动力
|
||||||
|
|
||||||
|
1. Agent 行为复杂性:可能给出合理结果但遗漏关键步骤
|
||||||
|
2. **[[agent-process-evaluation|只看对话轨迹不可靠]]**:LLM Judge 漏掉 44% 安全违规
|
||||||
|
3. **[[agent-capability-stability-gap|能力 ≠ 稳定性]]**:一次成功不代表可部署
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[trace-native-evaluation]] — 踪迹原生评估
|
||||||
|
- [[verification-evaluation]] — ETCLOVG 的 V 层
|
||||||
|
- [[claw-eval]] — Claw-Eval 框架
|
||||||
40
concepts/agent-frameworks-to-platforms.md
Normal file
40
concepts/agent-frameworks-to-platforms.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Frameworks to Platforms(从 Agent 框架到 Agent 平台)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, platform, framework, production, ecosystem]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# From Agent Frameworks to Agent Platforms
|
||||||
|
|
||||||
|
> 生态系统正从 Agent 框架向 Agent 平台转移。框架打包本地抽象,平台加上持久化、身份、计费、可观测性、评估、治理和人类交接。
|
||||||
|
|
||||||
|
## Frameworks vs Platforms
|
||||||
|
|
||||||
|
| 维度 | Frameworks | Platforms |
|
||||||
|
|------|-----------|----------|
|
||||||
|
| 范围 | 本地抽象 | 持久工作区 |
|
||||||
|
| 核心 | Agents, Tools, Memory, Loops | 沙箱, 身份, 计费, 可观测性 |
|
||||||
|
| 运营 | 单次运行 | 多运行、多用户 |
|
||||||
|
| 关键问题 | 如何构建 Agent? | 如何运营一组 Agent? |
|
||||||
|
|
||||||
|
## 为什么这很重要
|
||||||
|
|
||||||
|
长时间运行的 Agent 不再只是调用模型的程序。它们是**运营系统**,需要:
|
||||||
|
- 租户隔离(Tenancy)
|
||||||
|
- 合规性(Compliance)
|
||||||
|
- 故障恢复(Fault Recovery)
|
||||||
|
- 踪迹保留(Trace Retention)
|
||||||
|
- 组织归属(Organizational Ownership)
|
||||||
|
|
||||||
|
核心设计问题从"如何构建 Agent?"转变为**"如何运营一组 Agent,使其操作随时间保持可检查、可逆?"**
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[lifecycle-orchestration]]
|
||||||
|
- [[agent-harness-engineering]]
|
||||||
|
- [[governance-security]]
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
47
concepts/agent-governance.md
Normal file
47
concepts/agent-governance.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Governance(Agent 治理与安全)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [agent, governance, security, permission, audit]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Governance
|
||||||
|
|
||||||
|
> ETCLOVG 的 G 层:通过权限、身份、策略、硬化和审计机制约束 Agent 行为的控制层。
|
||||||
|
|
||||||
|
## 五大治理维度
|
||||||
|
|
||||||
|
### 1. 权限模型与身份管理(Permission Models)
|
||||||
|
- AgentGateway、Haft 等提供了 Agent 专用的权限网关
|
||||||
|
- 身份委托:Agent 以谁的身份执行操作?
|
||||||
|
- MCP 代理模式:拦截和审查工具调用
|
||||||
|
|
||||||
|
### 2. 生命周期 Hooks
|
||||||
|
- 在执行的关键节点插入审查逻辑
|
||||||
|
- Pre-execution hooks:阻止危险动作
|
||||||
|
- Post-execution hooks:审计和记录
|
||||||
|
|
||||||
|
### 3. 组件硬化(Component Hardening)
|
||||||
|
- 沙箱隔离、网络限制、文件系统防护
|
||||||
|
- 最小权限原则在 Agent 层的应用
|
||||||
|
|
||||||
|
### 4. 声明式宪法(Declarative Constitutions)
|
||||||
|
- 以自然语言或规则定义 Agent 的行为边界
|
||||||
|
- 可审计、可管理的策略声明机制
|
||||||
|
|
||||||
|
### 5. 审计基础设施
|
||||||
|
- 完整的操作日志和追溯链
|
||||||
|
- 人机协同:在关键决策节点引入人工审批
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
G 层处理的是 [[capability-control-tradeoff|能力-控制权衡]] 的控制侧:每次给 Agent 更多能力,都必须在 G 层增加对应的约束。这正是 Harness 工程的核心张力之一。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[etclovg-taxonomy]] — 七层分类体系
|
||||||
|
- [[capability-control-tradeoff]] — 能力-控制权衡
|
||||||
|
- [[execution-environment]] — 执行环境(E 层)
|
||||||
|
- [[agent-harness-engineering]] — 总体框架
|
||||||
34
concepts/agent-harness-engineering.md
Normal file
34
concepts/agent-harness-engineering.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Harness Engineering(Agent 执行骨架工程)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, infrastructure, harness, production]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Harness Engineering
|
||||||
|
|
||||||
|
> Agent Harness 是包裹 LLM 的基础设施层,负责管理长时间、多步骤任务执行的执行环境、工具接入、上下文、编排、可观测性、验证和治理。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
Agent Harness 不是 Agent 框架(开发工具),也不是 Agent 平台(产品 SaaS),而是**使 Agent 可靠运行的底层控制平面**。它将执行、工具、上下文、编排、可观测性、验证和治理七个维度统一为一个工程表面。
|
||||||
|
|
||||||
|
## 为什么 Harness 比模型更关键?
|
||||||
|
|
||||||
|
- Bölük (2026a):仅改变 harness 格式就能同时提升 15 个 LLM 的编程能力
|
||||||
|
- Anthropic (2026a):基础设施设置可测量地改变 benchmark 分数
|
||||||
|
- 生产部署中,失败更多源自 harness 配置错误而非模型推理错误
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[etclovg-taxonomy]] — 七层分类体系
|
||||||
|
- [[binding-constraint-thesis]] — 约束瓶颈论
|
||||||
|
- [[prompt-to-harness-evolution]] — 三阶段工程演进
|
||||||
|
- [[harness-coupling-problem]] — 跨层耦合问题
|
||||||
|
|
||||||
|
## 参考论文
|
||||||
|
|
||||||
|
[[agent-harness-engineering-survey]]
|
||||||
47
concepts/agent-harness-mini.md
Normal file
47
concepts/agent-harness-mini.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: "Mini Agent Harness"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "harness", "engineering"]
|
||||||
|
sources: ["mini-agent-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mini Agent Harness
|
||||||
|
|
||||||
|
> 最小可用的 Agent 评测框架:把 Agentic model 放进可运行、可记录、可评分的小环境。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
Mini Agent Harness 是一个轻量级的 Agent 评测框架,由五个核心模块组成:
|
||||||
|
|
||||||
|
1. **Task**(任务输入):明确的任务描述
|
||||||
|
2. **Environment**(可操作环境):代码仓库、文件组等封闭环境
|
||||||
|
3. **Tools**(工具接口):Agent 可调用的工具列表
|
||||||
|
4. **[[agent-eval-trace|Trace]]**(执行记录):每步工具调用、参数、返回值的完整记录
|
||||||
|
5. **[[agent-eval-grader|Grader]]**(评分器):基于规则或测试脚本的结果判断
|
||||||
|
|
||||||
|
## 核心价值
|
||||||
|
|
||||||
|
| 手动测试 | Mini Harness |
|
||||||
|
|---------|-------------|
|
||||||
|
| 只看到最终回答 | 记录完整执行过程 |
|
||||||
|
| 凭感觉判断好坏 | 按规则评分 |
|
||||||
|
| 问题难以定位 | 可分析到具体步骤 |
|
||||||
|
|
||||||
|
## 设计哲学
|
||||||
|
|
||||||
|
- **先有骨架再扩展**:第一版只需串起五要素
|
||||||
|
- **可分析性优先**:不是"好不好用",而是"哪里出问题"
|
||||||
|
- **环境封闭**:固定环境保证可复现性
|
||||||
|
|
||||||
|
## 与其他 Harness 概念的关系
|
||||||
|
|
||||||
|
- [[agent-harness-engineering]]:更广义的 Agent harness 工程实践
|
||||||
|
- [[harness-coupling-problem]]:harness 与模型耦合问题的理论分析
|
||||||
|
- [[adaptive-harness-simplification]]:harness 自适应简化的策略
|
||||||
|
- [[prompt-to-harness-evolution]]:从 prompt 到 harness 的演化路径
|
||||||
|
|
||||||
|
## 参考
|
||||||
|
|
||||||
|
- [[mini-agent-harness|从零搭建 Mini Agent Harness]] — 原始文章
|
||||||
|
- [[anthropic-agent-evals]] — Anthropic 的评测框架
|
||||||
41
concepts/agent-multidimensional-capability.md
Normal file
41
concepts/agent-multidimensional-capability.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Multidimensional Capability(Agent 多维能力)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, capability, multi-dimensional, evaluation]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Multidimensional Capability
|
||||||
|
|
||||||
|
> Agent 能力是多维的——不同模型在不同的任务类型上各有优势,没有任何一个模型能在所有维度上全面领先。
|
||||||
|
|
||||||
|
## Claw-Eval 三大维度
|
||||||
|
|
||||||
|
- **通用服务**:多工具协调、任务拆解
|
||||||
|
- **多模态**:视觉理解、跨模态生成
|
||||||
|
- **多轮对话**:信息采集、渐进决策
|
||||||
|
|
||||||
|
## 关键发现
|
||||||
|
|
||||||
|
1. 模型在不同任务类型上的排名**不一致**
|
||||||
|
2. 多模态任务是目前最难的:**最高 Pass^3 仅 25.7%**
|
||||||
|
3. 一个模型可能在服务编排上领先但在多模态上落后
|
||||||
|
|
||||||
|
## 对评估设计的含义
|
||||||
|
|
||||||
|
- 不能仅看"总分"或"平均分"
|
||||||
|
- 需要按**任务类型**分解评估
|
||||||
|
- 针对不同部署场景选择适配的模型(服务编排场景 vs 多模态场景需要不同排名)
|
||||||
|
|
||||||
|
## 与 Agent Harness Engineering 的联系
|
||||||
|
|
||||||
|
多模态 Agent 的低可靠性可能与 [[harness-coupling-problem]] 有关——视觉工具 Schema 设计、多模态上下文管理等问题尚未解决。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-evaluation-paradigm-shift]]
|
||||||
|
- [[agent-capability-stability-gap]]
|
||||||
|
- [[claw-eval]]
|
||||||
52
concepts/agent-observability.md
Normal file
52
concepts/agent-observability.md
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Observability(Agent 可观测性)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [agent, observability, monitoring, tracing, production]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Observability
|
||||||
|
|
||||||
|
> ETCLOVG 的 O 层:对 Agent 行为进行监控、调试和生产级可靠性管理的独立架构层。
|
||||||
|
|
||||||
|
## 核心定义
|
||||||
|
|
||||||
|
Agent 可观测性是 ETCLOVG 七层分类法中的第五层(O),从 Lifecycle Hooks 中独立出来作为第一等架构问题。它涵盖 Agent 系统的**结构化追踪、成本归因、可靠性工程和统一观测**四个方面。
|
||||||
|
|
||||||
|
## 为什么 O 层需要独立
|
||||||
|
|
||||||
|
论文将 Observability 从 Lifecycle 的附属品提升为独立层,理由是:
|
||||||
|
- O 层拥有**专属平台生态**:Langfuse、Arize Phoenix、OpenLLMetry 等
|
||||||
|
- 在生产线部署中由**不同团队**负责(SRE vs Agent 开发)
|
||||||
|
- O 层的工程实践与编排逻辑有本质区别
|
||||||
|
|
||||||
|
## 四大子系统
|
||||||
|
|
||||||
|
### 1. 追踪与监控
|
||||||
|
- **Langfuse / Opik / Arize Phoenix / MLflow**:交互式 trace tree,延迟火焰图,token 分解
|
||||||
|
- **OpenTelemetry (OTel)**:成为 Agent 观测的事实标准
|
||||||
|
- **语义约定**:定义 span 属性(模型名、温度、token 数、延迟)
|
||||||
|
|
||||||
|
### 2. Agent 专用运维平台
|
||||||
|
- AgentOps、RagaAI Catalyst、Laminar、Watson、AgentLens
|
||||||
|
- 提供 Agent 特有的调试和回溯功能
|
||||||
|
|
||||||
|
### 3. 成本追踪与优化
|
||||||
|
- TensorZero、Helicone:成本归因和网关
|
||||||
|
- FrugalGPT、GPTCache:成本节省策略
|
||||||
|
- Dual-Pool Routing:模型路由优化
|
||||||
|
|
||||||
|
### 4. 可靠性工程
|
||||||
|
- Anthropic 的 Effective Harnesses 和 Harness Design
|
||||||
|
- AgentErrorTaxonomy:错误分类
|
||||||
|
- SentinelAgent / AgentFixer:故障检测和修复
|
||||||
|
- 核心命题:"基础设施噪声"可度量地改变 benchmark 分数
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[etclovg-taxonomy]] — 七层分类体系
|
||||||
|
- [[lifecycle-orchestration]] — 编排层(O 层从中独立)
|
||||||
|
- [[agent-harness-engineering]] — 总体框架
|
||||||
|
- [[cost-quality-speed-trilemma]] — 成本维度
|
||||||
37
concepts/agent-process-evaluation.md
Normal file
37
concepts/agent-process-evaluation.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Process Evaluation(过程评测)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, evaluation, process, trace]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Process Evaluation(过程评测)
|
||||||
|
|
||||||
|
> 不只评判 Agent 的最终输出,更审查其完整的执行过程——中间步骤是否合理、工具调用是否正确、约束是否遵守。
|
||||||
|
|
||||||
|
## 为什么只看最终答案不够
|
||||||
|
|
||||||
|
- Agent 可能给出看似合理的结果,却在执行中遗漏关键步骤
|
||||||
|
- Claw-Eval 实验:普通 LLM Judge 即使看到完整对话记录,仍**漏掉 44% 安全违规**和**13% 鲁棒性问题**
|
||||||
|
- 需要结合**服务端日志**和**环境快照**才能捕捉违规
|
||||||
|
|
||||||
|
## 过程评测的关键要素
|
||||||
|
|
||||||
|
- **工具调用审计**:每一步工具调用是否符合预期
|
||||||
|
- **约束遵循**:行为是否遵守安全边界和任务约束
|
||||||
|
- **错误恢复**:异常发生后是否尝试恢复
|
||||||
|
- **轨迹完整性**:Setup → Execution → Judge 全生命周期记录
|
||||||
|
|
||||||
|
## 与 Trace-Native Evaluation 的关系
|
||||||
|
|
||||||
|
过程评测是 [[trace-native-evaluation]] 的具体实践——将 Agent 的完整执行踪迹而非最终分数作为主要评估对象。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-evaluation-paradigm-shift]]
|
||||||
|
- [[agent-safety-evaluation]]
|
||||||
|
- [[agent-robustness-evaluation]]
|
||||||
|
- [[claw-eval]]
|
||||||
43
concepts/agent-robustness-evaluation.md
Normal file
43
concepts/agent-robustness-evaluation.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Robustness Evaluation(Agent 鲁棒性评测)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, robustness, evaluation, fault-tolerance]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Robustness Evaluation
|
||||||
|
|
||||||
|
> 评测 Agent 面对接口失败、服务延迟、临时错误时,能否恢复并继续执行。鲁棒性是区分"能做"和"能稳定做"的关键维度。
|
||||||
|
|
||||||
|
## Claw-Eval 的鲁棒性测试
|
||||||
|
|
||||||
|
通过**错误注入**模拟真实生产环境的不稳定性:
|
||||||
|
- HTTP 429(限流)
|
||||||
|
- HTTP 500(服务器错误)
|
||||||
|
- 延迟峰值
|
||||||
|
|
||||||
|
## 关键发现
|
||||||
|
|
||||||
|
- Pass@3 在错误注入后相对稳定(模型仍然"能做到")
|
||||||
|
- Pass^3 最高下降 24 个百分点(但不再"稳定做到")
|
||||||
|
- → [[agent-capability-stability-gap|能力 ≠ 稳定性]]
|
||||||
|
|
||||||
|
## 鲁棒性的维度
|
||||||
|
|
||||||
|
- **重试策略**:面对临时失败是否尝试恢复
|
||||||
|
- **降级策略**:不可恢复时是否优雅降级
|
||||||
|
- **错误感知**:是否能识别异常状态并调整行为
|
||||||
|
|
||||||
|
## 与 ETCLOVG 的关系
|
||||||
|
|
||||||
|
鲁棒性评测直接检验 [[execution-environment]](E 层)沙箱的故障模式、[[lifecycle-orchestration]](L 层)的恢复策略和 [[observability]](O 层)的故障信号质量。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[pass-at-k-vs-pass-k]]
|
||||||
|
- [[agent-capability-stability-gap]]
|
||||||
|
- [[agent-process-evaluation]]
|
||||||
|
- [[claw-eval]]
|
||||||
37
concepts/agent-safety-evaluation.md
Normal file
37
concepts/agent-safety-evaluation.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Safety Evaluation(Agent 安全评测)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, safety, evaluation, security]
|
||||||
|
sources: [raw/articles/claw-eval-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Safety Evaluation
|
||||||
|
|
||||||
|
> 评测 Agent 在执行过程中是否遵守约束,是否避免不该发生的行为。不仅看结果是否正确,还要看过程是否安全。
|
||||||
|
|
||||||
|
## Claw-Eval 的安全评测发现
|
||||||
|
|
||||||
|
- 普通 LLM Judge 即使看到完整对话记录和工具调用信息,仍然**漏掉了 44% 的安全违规**
|
||||||
|
- 安全违规不能仅从文本记录中检测 → 需要结合服务端日志和环境快照
|
||||||
|
|
||||||
|
## 安全评测的挑战
|
||||||
|
|
||||||
|
- **隐蔽性**:安全违规可能不体现在对话文本中(如未经授权的 API 调用)
|
||||||
|
- **上下文依赖**:同一个操作在不同任务约束下安全与否不同
|
||||||
|
- **检测能力不足**:纯 LLM Judge 对安全边界的判断力有限
|
||||||
|
|
||||||
|
## 与 Governance 层的关联
|
||||||
|
|
||||||
|
安全评测是 [[governance-security]](G 层)的回馈闭环:
|
||||||
|
- 评测暴露的安全漏洞 → 加固 Governance 策略
|
||||||
|
- 同时验证 Governance 层的护栏是否真正有效
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-process-evaluation]]
|
||||||
|
- [[agent-robustness-evaluation]]
|
||||||
|
- [[governance-security]]
|
||||||
|
- [[claw-eval]]
|
||||||
50
concepts/agent-sandbox.md
Normal file
50
concepts/agent-sandbox.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Sandbox(Agent 沙箱)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [agent, sandbox, security, execution-environment]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Sandbox
|
||||||
|
|
||||||
|
> Agent 代码执行的安全隔离环境,是 [[execution-environment|Execution Environment]] (E 层) 的核心组件。
|
||||||
|
|
||||||
|
## 沙箱分类
|
||||||
|
|
||||||
|
### 1. 进程级沙箱
|
||||||
|
- Docker 容器、gVisor、Firecracker microVM
|
||||||
|
- 优点:成熟、广泛支持
|
||||||
|
- 缺点:启动延迟、资源开销
|
||||||
|
|
||||||
|
### 2. 语言级沙箱
|
||||||
|
- Python `exec()` / `eval()` 限制、RestrictedPython
|
||||||
|
- 优点:零启动延迟、轻量
|
||||||
|
- 缺点:逃逸风险高
|
||||||
|
|
||||||
|
### 3. WebAssembly (Wasm) 沙箱
|
||||||
|
- WasmEdge、wasmtime 运行时
|
||||||
|
- 优点:接近原生性能、强隔离、跨平台
|
||||||
|
- 新兴方向,尚未成为主流
|
||||||
|
|
||||||
|
### 4. 浏览器沙箱
|
||||||
|
- Playwright、Puppeteer 驱动
|
||||||
|
- 用于 Web Agent(如 WebArena 评测)
|
||||||
|
|
||||||
|
## 沙箱逃逸与威胁模型
|
||||||
|
|
||||||
|
- Agent 的代码执行能力使其具有潜在的安全威胁
|
||||||
|
- 关键挑战:Agent 可能通过生成代码绕过沙箱限制
|
||||||
|
- 防御:多层隔离 + 网络限制 + 文件系统只读挂载
|
||||||
|
|
||||||
|
## 部署模式
|
||||||
|
- **本地沙箱**:延迟最低,风险最高
|
||||||
|
- **远程沙箱**:eg. Modal、Replit 等云平台
|
||||||
|
- **混合模式**:敏感操作远程,常规操作本地
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[execution-environment]] — E 层总体
|
||||||
|
- [[agent-governance]] — G 层的安全约束
|
||||||
|
- [[etclovg-taxonomy]] — 七层分类体系
|
||||||
39
concepts/agent-symbolic-learning.md
Normal file
39
concepts/agent-symbolic-learning.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Symbolic Learning (Agent 符号学习)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "symbolic-learning", "optimization", "self-evolving"]
|
||||||
|
sources: ["https://arxiv.org/abs/2406.18532"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Symbolic Learning
|
||||||
|
|
||||||
|
**Agent Symbolic Learning** 是 Zhou et al. (AIWaves, 2024) 提出的框架:将 Agent pipeline 建模为 [[symbolic-network|符号网络]],用模仿连接主义学习(反向传播 + 梯度下降)的方式**联合优化** Agent 的所有符号组件。
|
||||||
|
|
||||||
|
## 核心类比
|
||||||
|
|
||||||
|
| 连接主义学习 | Agent Symbolic Learning |
|
||||||
|
|:---|:---|
|
||||||
|
| 计算图 | Agent Pipeline |
|
||||||
|
| 层 + 权重 | 节点 + Prompts/Tools |
|
||||||
|
| 数值 Loss | [[language-loss\|Language Loss]] |
|
||||||
|
| 数值梯度 | [[language-gradient\|Language Gradients]] |
|
||||||
|
| BP 链式法则 | [[symbolic-backpropagation\|Symbolic Back-Propagation]] |
|
||||||
|
| 优化器 | Symbolic Optimizer (LLM) |
|
||||||
|
|
||||||
|
## 三阶段
|
||||||
|
|
||||||
|
1. **Forward Pass**: Agent 沿 pipeline 执行 → 轨迹
|
||||||
|
2. **Backward Pass**: Language Loss 从末节点向前传播 → 每个节点的 Language Gradients
|
||||||
|
3. **Weight Update**: Optimizer 根据 gradients 更新 prompts/tools/pipeline
|
||||||
|
|
||||||
|
## 历史意义
|
||||||
|
|
||||||
|
这是首次明确提出"模仿连接主义学习的反向传播和梯度下降来进行 Agent 符号优化"的工作。后续 [[yang-skillopt-2026|SkillOpt]](2026,Microsoft)在工程稳定性上深化,[[heuristic-learning|Heuristic Learning]](OpenAI)在范式层级上推广。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[zhou-agent-symbolic-learning-2024]] — 原始论文
|
||||||
|
- [[symbolic-network]] — 核心抽象
|
||||||
|
- [[language-gradient]] — 核心机制
|
||||||
46
concepts/agent-verification.md
Normal file
46
concepts/agent-verification.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "Agent Verification(Agent 验证与评估)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [agent, evaluation, verification, benchmark, failure-attribution]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Agent Verification
|
||||||
|
|
||||||
|
> ETCLOVG 的 V 层:将任务和跟踪(trace)转化为评估、失败归因和回归反馈的系统化流程。
|
||||||
|
|
||||||
|
## 五阶段验证生命周期
|
||||||
|
|
||||||
|
### Stage 1: 任务与基准接地(Task and Benchmark Grounding)
|
||||||
|
- 问题:现有基准(SWE-bench、Terminal-Bench)关注最终结果而非过程
|
||||||
|
- 需要将任务明确化为可执行的可验证目标
|
||||||
|
|
||||||
|
### Stage 2: 执行前准备验证(Pre-execution Readiness)
|
||||||
|
- 检查环境完整性、工具可用性、上下文一致性
|
||||||
|
- 在生产部署中防止"静默失败"
|
||||||
|
|
||||||
|
### Stage 3: 受控执行与 Trace 捕获
|
||||||
|
- 捕获完整执行轨迹和所有中间状态
|
||||||
|
- 可回放性:同一 trace 可重新执行并比较
|
||||||
|
|
||||||
|
### Stage 4: 多层次评判与失败归因(Multi-level Judgement)
|
||||||
|
- 不只看最终对不对,还要分析**哪一步出了问题**
|
||||||
|
- 区分模型推理错误 vs 工具调用错误 vs 环境故障
|
||||||
|
- 需要归因到具体 Harness 层
|
||||||
|
|
||||||
|
### Stage 5: 持续回归与部署反馈
|
||||||
|
- 将评估集成到 CI/CD
|
||||||
|
- 防御 Harness 变更的意外退化
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
V 层使 Harness 工程从"经验性的手工调试"走向"可度量的工程学科"——每一个 Harness 设计决策都可以通过验证闭环来量化评估。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[etclovg-taxonomy]] — 七层分类体系
|
||||||
|
- [[agent-evaluation-paradigm-shift]] — Agent 评测范式转变
|
||||||
|
- [[trace-native-evaluation]] — 从 Trace 诊断失败
|
||||||
|
- [[agent-harness-engineering]] — 总体框架
|
||||||
32
concepts/amortized-variational-inference.md
Normal file
32
concepts/amortized-variational-inference.md
Normal file
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
title: "Amortized Variational Inference(摊销变分推断)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [training, variational-inference, probabilistic, vae]
|
||||||
|
sources: [raw/papers/gram-generative-recursive-reasoning-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Amortized Variational Inference
|
||||||
|
|
||||||
|
> GRAM 的训练方法:使用编码器(后验)和生成器(先验)来优化 ELBO,CE loss 驱动预测 + KL divergence 规范潜在空间。
|
||||||
|
|
||||||
|
## GRAM 中的实现
|
||||||
|
|
||||||
|
- **后验 q_phi(z_t | z_{t-1}, y)**:知道答案时的推理轨迹
|
||||||
|
- **先验 p_theta(z_t | z_{t-1}, e_x)**:不知道答案时的推理轨迹
|
||||||
|
- **训练目标**: ELBO = E_q[log p(y|z_T)] - KL(q||p)
|
||||||
|
- **CE loss**: 确保预测正确
|
||||||
|
- **KL divergence**: 确保模型在没有答案时也能产生合理轨迹
|
||||||
|
|
||||||
|
## 为什么用摊销变分推断
|
||||||
|
|
||||||
|
- 直接最大化似然 intractable(需要边缘化所有轨迹)
|
||||||
|
- VI 提供了可微分的训练信号
|
||||||
|
- 后验网络在训练时提供"老师"信号,测试时只用先验
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[latent-variable-generative-model]]
|
||||||
|
- [[gram-generative-recursive-reasoning|GRAM]]
|
||||||
39
concepts/anthropic-agent-evals.md
Normal file
39
concepts/anthropic-agent-evals.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Anthropic Agent Evals"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["agent-evaluation", "anthropic", "benchmark", "framework"]
|
||||||
|
sources: ["mini-agent-harness"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Anthropic Agent Evals
|
||||||
|
|
||||||
|
> Anthropic 提出的 Agent 评测框架,区分 eval harness 与 agent harness,强调评估的是模型+harness 的整体效果。
|
||||||
|
|
||||||
|
## 核心区分
|
||||||
|
|
||||||
|
### Eval Harness
|
||||||
|
- 跑评测、记录步骤
|
||||||
|
- 评分和汇总结果
|
||||||
|
- 不参与 Agent 的决策循环
|
||||||
|
|
||||||
|
### Agent Harness
|
||||||
|
- 让模型作为 Agent 工作
|
||||||
|
- 处理输入、编排工具调用
|
||||||
|
- 返回结果
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
> 评估一个 Agent 时,你评到的是模型和 harness 一起工作的效果。
|
||||||
|
|
||||||
|
这意味着评测结果不能简单归因于"模型好坏",还需要考虑 harness 设计的质量。这与 [[agent-computer-interface|ACI]] 的观点一致——接口设计直接影响表现。
|
||||||
|
|
||||||
|
## 与 [[agent-harness-mini|Mini Harness]] 的关系
|
||||||
|
|
||||||
|
Anthropic 的框架是 mini harness 的理论基础之一:mini harness 的 Task/Env/Tools 对应 agent harness,Trace/Grader 对应 eval harness。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agent-harness-mini]] — 最小化实现
|
||||||
|
- [[agent-harness-engineering]] — 工程化视角
|
||||||
|
- [[agent-computer-interface]] — 接口设计的影响
|
||||||
49
concepts/autoharness.md
Normal file
49
concepts/autoharness.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: "AutoHarness"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "code-synthesis", "game-playing", "LLM"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# AutoHarness
|
||||||
|
|
||||||
|
**AutoHarness** 是 Lou et al. (Google DeepMind, 2026) 提出的一种 LLM Agent 增强方法:让 LLM **自动合成为自己服务的代码 harness**,以消除 Agent 在结构化环境中的非法动作。
|
||||||
|
|
||||||
|
## 问题背景
|
||||||
|
|
||||||
|
LLM Agent 在游戏中频繁产出非法动作(Gemini-2.5-Flash 78% 的象棋失利源于非法走子)。传统方案:
|
||||||
|
- **手写 harness**:脆弱、每游戏需重写
|
||||||
|
- **Fine-tuning**:昂贵、损害通用能力
|
||||||
|
- **推理时搜索**(如 Tree of Thoughts):依赖 LLM 内部世界模型,易 hallucinate 合法转移
|
||||||
|
|
||||||
|
## 核心思想
|
||||||
|
|
||||||
|
**"Code as Harness"**:LLM 不仅扮演 Agent 的"大脑",还为自己编写"保护壳"——一个外部的、可验证的程序来检查动作合法性。
|
||||||
|
|
||||||
|
## 搜索机制
|
||||||
|
|
||||||
|
- **[[thompson-sampling-code-search|Thompson Sampling 树搜索]]**:维护多个代码假设,平衡探索与利用
|
||||||
|
- **LLM 作为 mutation operator**:基于环境 feedback 提出代码改进
|
||||||
|
- **Critic**:提供结构化反馈(动作合法性、reward)
|
||||||
|
|
||||||
|
## 三种 Harness 形式
|
||||||
|
|
||||||
|
| 模式 | 描述 | LLM 推理时调用 |
|
||||||
|
|------|------|:---:|
|
||||||
|
| [[harness-as-action-verifier|Verifier]] | LLM 提议 → 代码验证 → 非法重试 | ✅ |
|
||||||
|
| Action Filter | 代码生成合法集合 → LLM 排序 | ✅ |
|
||||||
|
| [[harness-as-policy|Policy]] | 纯代码决策 | ❌ |
|
||||||
|
|
||||||
|
## 成果
|
||||||
|
|
||||||
|
- 145 个 TextArena 游戏 **100% 合法动作率**
|
||||||
|
- Flash+Harness 胜 Flash+Pro(裸奔)
|
||||||
|
- Code-as-Policy 超 GPT-5.2-High
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[lou-autoharness-2026]] — 原始论文
|
||||||
|
- [[code-as-harness]] — 框架哲学
|
||||||
|
- [[harness-as-policy]] — 终极形态
|
||||||
42
concepts/bayesian-attention-geometry.md
Normal file
42
concepts/bayesian-attention-geometry.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Bayesian Attention Geometry (贝叶斯注意力几何)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["transformers", "attention", "geometry", "bayesian-inference"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bayesian Attention Geometry
|
||||||
|
|
||||||
|
> 在 Bayesian wind tunnel 中,Transformer 的注意力头展现出可诊断的几何结构——正交 key 基、熵参数化的 value 流形、状态聚类。
|
||||||
|
|
||||||
|
## 三项几何发现
|
||||||
|
|
||||||
|
### 1. 正交 Key 基
|
||||||
|
注意力头的 key 投影形成近似正交的基底——每个头专注于不同的特征子空间,最大化信息覆盖。
|
||||||
|
|
||||||
|
### 2. 熵参数化的 Value 流形
|
||||||
|
Value 向量分布在一个**低维流形**上,该流形被 posterior 熵参数化。不确定性越高 → value 流形结构越丰富。
|
||||||
|
|
||||||
|
### 3. Mamba 的状态聚类
|
||||||
|
在 HMM 追踪任务中,Mamba 的最终层自组织为 **5 个离散簇**——每个簇精确对应一个 HMM 隐藏状态。模型发现了 belief simplex 的角落几何。
|
||||||
|
|
||||||
|
## 几何诊断作为可解释性工具
|
||||||
|
|
||||||
|
这些几何特征不是设计出来的,而是训练过程中自然涌现的。它们提供了一种**无监督的诊断手段**:
|
||||||
|
- 正交 key 基 → 模型在做结构化的推理
|
||||||
|
- 熵参数化 → 模型正确编码了不确定性
|
||||||
|
- 状态聚类 → 模型发现了任务的潜在结构
|
||||||
|
|
||||||
|
## 与 [[inference-primitives|推理原语]] 的关系
|
||||||
|
|
||||||
|
几何是实现原语的物理基础:
|
||||||
|
- 正交 key 基 → 高效实现内容寻址([[random-access-binding|绑定]])
|
||||||
|
- Value 流形 → [[belief-accumulation|信念累积]]的几何表示
|
||||||
|
- 状态聚类 → [[belief-transport|信念传输]]的离散化
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agarwal-bayesian-attention-geometry]] — 原始论文
|
||||||
|
- [[bayesian-wind-tunnels]] — 产生这些几何发现的实验方法
|
||||||
|
- [[inference-primitives]] — 几何结构实现的原语体系
|
||||||
46
concepts/bayesian-attention-trilogy.md
Normal file
46
concepts/bayesian-attention-trilogy.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "Bayesian Attention Trilogy"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["bayesian-inference", "transformers", "research-program"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bayesian Attention Trilogy
|
||||||
|
|
||||||
|
> 三篇论文构成的统一论证:Transformer 的贝叶斯推理——从存在性到涌现机制到组合扩展。
|
||||||
|
|
||||||
|
## 三部曲结构
|
||||||
|
|
||||||
|
### Paper I: The Bayesian Geometry of Transformer Attention
|
||||||
|
- **角色**:Lemma 1 — 建立**存在性**
|
||||||
|
- **内容**:在 [[bayesian-wind-tunnels|Bayesian wind tunnel]] 中证明小型 Transformer 实现精确贝叶斯后验
|
||||||
|
- **发现**:[[inference-primitives|三原语]]体系 + [[bayesian-attention-geometry|几何诊断]]
|
||||||
|
|
||||||
|
### Paper II: Gradient Dynamics
|
||||||
|
- **角色**:解释**为什么**
|
||||||
|
- **内容**:贝叶斯结构从交叉熵梯度动力学中**自然涌现**
|
||||||
|
- **论证**:不是巧合,而是训练的必然收敛结果
|
||||||
|
|
||||||
|
### Paper III: Composition in Partially Observed Settings
|
||||||
|
- **角色**:展示**扩展性**
|
||||||
|
- **内容**:原语在部分可观测环境(更接近自然语言)中如何**组合**
|
||||||
|
- **论证**:简单原语的组合产生复杂推理行为
|
||||||
|
|
||||||
|
## 统一论证
|
||||||
|
|
||||||
|
```
|
||||||
|
Paper I: Transformer 能做到精确贝叶斯推理吗? → 是(存在性)
|
||||||
|
Paper II: 这是巧合还是必然? → 必然(涌现机制)
|
||||||
|
Paper III: 这些能力能扩展到真实场景吗? → 能(组合扩展)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 方法论价值
|
||||||
|
|
||||||
|
三部曲展示了从**可验证的受控实验**(Paper I)到**理论解释**(Paper II)再到**向真实场景推广**(Paper III)的完整研究范式。这与 [[bayesian-wind-tunnels|wind tunnel]] 方法论一致——先在可控环境中建立基本事实,再逐步增加复杂度。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[agarwal-bayesian-attention-geometry]] — Paper I 详情
|
||||||
|
- [[bayesian-wind-tunnels]] — 核心实验方法
|
||||||
|
- [[inference-primitives]] — 贯穿三部曲的理论框架
|
||||||
46
concepts/bayesian-wind-tunnels.md
Normal file
46
concepts/bayesian-wind-tunnels.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "Bayesian Wind Tunnels"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["bayesian-inference", "experimental-methodology", "transformers"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bayesian Wind Tunnels
|
||||||
|
|
||||||
|
> 受控预测环境:解析后验已知、记忆不可行、推理必须为真——用于可验证地测试神经序列模型是否实现贝叶斯推理。
|
||||||
|
|
||||||
|
## 三个条件
|
||||||
|
|
||||||
|
1. **解析后验已知**:每一步的真值 posterior 在闭合形式中精确已知
|
||||||
|
2. **记忆不可行**:假设空间太大(如双射数量为 n!),计算上无法记忆
|
||||||
|
3. **推理必要性**:in-context prediction 需要真正的概率推理
|
||||||
|
|
||||||
|
## 解决的问题
|
||||||
|
|
||||||
|
自然语言评测的致命缺陷:
|
||||||
|
- 没有 ground-truth posterior
|
||||||
|
- 大模型无法隔离记忆与推理
|
||||||
|
- 只能观察行为,不能验证内部计算
|
||||||
|
|
||||||
|
Wind tunnel 将定性问题("它在做贝叶斯吗?")转化为定量测试:**模型的预测熵是否与解析 posterior 熵逐位置匹配?**
|
||||||
|
|
||||||
|
## 四种 Wind Tunnel 任务
|
||||||
|
|
||||||
|
| 任务 | 类型 | 测试原语 |
|
||||||
|
|------|------|---------|
|
||||||
|
| 双射学习 (Bijection Learning) | 离散假设消除 | [[belief-accumulation]] |
|
||||||
|
| HMM 滤波 | 序列随机推理 | 累积 + [[belief-transport]] |
|
||||||
|
| 贝叶斯回归 | 连续推理 | 累积 |
|
||||||
|
| 联想回忆 (Associative Recall) | 基于内容的检索 | [[random-access-binding]] |
|
||||||
|
|
||||||
|
## 与风洞的类比
|
||||||
|
|
||||||
|
航空风洞:控制气流、测量升力/阻力、验证空气动力学理论。
|
||||||
|
Bayesian wind tunnel:控制概率环境、测量预测熵、验证[[inference-primitives|推理原语]]理论。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[inference-primitives]] — 被 wind tunnel 验证的原语体系
|
||||||
|
- [[bayesian-attention-geometry]] — wind tunnel 中发现的几何结构
|
||||||
|
- [[agarwal-bayesian-attention-geometry]] — 原始论文
|
||||||
40
concepts/belief-accumulation.md
Normal file
40
concepts/belief-accumulation.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Belief Accumulation (信念累积)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["bayesian-inference", "inference-primitive"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Belief Accumulation
|
||||||
|
|
||||||
|
> 推理原语之一:将顺序到达的证据整合为 running posterior。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
\( P(\theta \mid x_{1:t}) \) 随观测 \( x_t \) 逐步更新——贝叶斯更新。
|
||||||
|
|
||||||
|
## 能力要求
|
||||||
|
|
||||||
|
- 维持对潜在假设(θ)的信念状态
|
||||||
|
- 新证据到达时更新该状态
|
||||||
|
- 充分统计量必须能从当前状态和当前输入计算
|
||||||
|
|
||||||
|
## 架构实现
|
||||||
|
|
||||||
|
| 架构 | 实现方式 | 限制 |
|
||||||
|
|------|---------|------|
|
||||||
|
| Transformer | 注意力聚合 in-context 证据 | — |
|
||||||
|
| Mamba | 选择性状态空间更新 | — |
|
||||||
|
| LSTM | 门控机制更新隐藏状态 | 仅**静态**充分统计量 |
|
||||||
|
| MLP | ❌ 无法实现 | 无状态维护机制 |
|
||||||
|
|
||||||
|
## LSTM 的限制
|
||||||
|
|
||||||
|
LSTM 只在充分统计量是**固定维度且静态**时成功(如信念修正)。当充分统计量本身在动态下演化或必须按内容索引时,LSTM 失败——因为它的隐藏状态无法实现 [[belief-transport|信念传输]] 或 [[random-access-binding|随机访问绑定]]。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[inference-primitives]] — 完整原语体系
|
||||||
|
- [[belief-transport]] — 动态下的信念传播
|
||||||
|
- [[random-access-binding]] — 基于内容的检索
|
||||||
44
concepts/belief-transport.md
Normal file
44
concepts/belief-transport.md
Normal file
@@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: "Belief Transport (信念传输)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["bayesian-inference", "inference-primitive", "state-space-models"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Belief Transport
|
||||||
|
|
||||||
|
> 推理原语之二:在隐藏状态随机动态演化时,将信念向前传播。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
当潜在状态本身按 Markov 动态演化时(如 HMM),推理不仅需要累积证据,还需要在每一步将概率质量在状态之间传输。
|
||||||
|
|
||||||
|
## 数学表达
|
||||||
|
|
||||||
|
HMM 滤波的 forward algorithm:
|
||||||
|
\[
|
||||||
|
\alpha_t(z_t) = p(x_t \mid z_t) \sum_{z_{t-1}} p(z_t \mid z_{t-1}) \alpha_{t-1}(z_{t-1})
|
||||||
|
\]
|
||||||
|
|
||||||
|
这里**传输矩阵** \( p(z_t \mid z_{t-1}) \) 施加了非平凡的状态动态。
|
||||||
|
|
||||||
|
## 架构实现
|
||||||
|
|
||||||
|
| 架构 | 传输能力 | 机制 |
|
||||||
|
|------|:---:|------|
|
||||||
|
| Transformer | ✅ | 注意力跨位置传播信息 |
|
||||||
|
| Mamba | ✅ | SSM 连续时间状态演化 |
|
||||||
|
| LSTM | ❌ | 隐藏状态无动态建模机制 |
|
||||||
|
| MLP | ❌ | — |
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
Mamba 在 HMM 滤波上达到 SOTA —— 选择性 SSM 的连续时间动态天然适合建模信念传输。但 Mamba 缺少 [[random-access-binding|绑定原语]],限制了它处理需要按内容检索的任务。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[belief-accumulation]] — 静态证据累积
|
||||||
|
- [[random-access-binding]] — 内容检索
|
||||||
|
- [[inference-primitives]] — 原语体系
|
||||||
|
- [[mamba-ssm]] — Mamba 选择性状态空间模型
|
||||||
30
concepts/binding-constraint-thesis.md
Normal file
30
concepts/binding-constraint-thesis.md
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "Binding-Constraint Thesis(约束瓶颈论)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, infrastructure, reliability, thesis]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Binding-Constraint Thesis
|
||||||
|
|
||||||
|
> Agent 在真实世界中的可靠性瓶颈不在模型本身,而在包裹模型的基础设施——Agent Execution Harness。基础设施质量,而非模型能力,设定了 Agent 可靠性的天花板。
|
||||||
|
|
||||||
|
## 三大证据链
|
||||||
|
|
||||||
|
1. **工程演进证据**:从 Prompt → Context → Harness Engineering 的三阶段演进表明,约束瓶颈随工程成熟度逐步上移
|
||||||
|
2. **跨层综合证据**:[[cost-quality-speed-trilemma]]、[[capability-control-tradeoff]]、[[harness-coupling-problem]] 三者都无法在单层内解决
|
||||||
|
3. **开放问题证据**:五大开放问题的核心都是 harness 层面而非模型层面的问题
|
||||||
|
|
||||||
|
## 关键实验
|
||||||
|
|
||||||
|
- Bölük (2026a):仅改变 harness 格式(不改变模型),15 个 LLM 的编程能力同时提升
|
||||||
|
- Anthropic (2026a):基础设施设置在可测量地改变 benchmark 分数
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-harness-engineering]] — 总体概念
|
||||||
|
- [[prompt-to-harness-evolution]] — 工程演进路径
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
45
concepts/bypass-network-handle-distribution.md
Normal file
45
concepts/bypass-network-handle-distribution.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Bypass Network Handle Distribution (旁路网络句柄分发)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "rdma", "c++", "ipc", "quant-trading"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bypass Network Handle Distribution (旁路网络句柄分发)
|
||||||
|
|
||||||
|
**Bypass Network Handle Distribution** 是一种高性能分布式架构模式:在应用层(Agent / LLM)仅传递轻量级的 8 字节数据句柄,而大宗原始数据通过 RDMA 等硬件旁路在物理机之间静默同步。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
以量化交易系统为例:
|
||||||
|
|
||||||
|
### C++ 内核侧
|
||||||
|
- 计算高维时序矩阵(如 Orderbook Imbalance,数 MB)
|
||||||
|
- 做两个解耦动作:
|
||||||
|
1. **大宗数据**:RDMA 静默同步到其他物理机的内存区
|
||||||
|
2. **轻量句柄**:通过共享内存环形队列向 Agent 投递 8 字节全局唯一句柄 + 极短定性摘要
|
||||||
|
|
||||||
|
### Agent 层(应用层)
|
||||||
|
- 将句柄作为 XML 标签嵌入 LLM Message 流
|
||||||
|
- 网络间只传输这 8 字节的句柄
|
||||||
|
|
||||||
|
### 接收节点
|
||||||
|
- 解析数据句柄
|
||||||
|
- 通过本地 C++ 共享内存网关向本地内核查询
|
||||||
|
- 原始数据已通过 RDMA 同步就位 → `reinterpret_cast` 瞬间读取
|
||||||
|
|
||||||
|
## 设计哲学
|
||||||
|
|
||||||
|
> **应用层传递极简句柄,物理层旁路搬运大数据。**
|
||||||
|
|
||||||
|
这实现了:
|
||||||
|
- 保护跨机 Prompt Caching 前缀(不传输原始数据)
|
||||||
|
- 大数据量的极低延迟搬运(硬件旁路)
|
||||||
|
- 大模型认知空间与高频交易物理空间的终极调和
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[distributed-agent-cache-sync-2026]] — 原始文章
|
||||||
32
concepts/cache-cold-start.md
Normal file
32
concepts/cache-cold-start.md
Normal file
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
title: "Cache Cold-Start (缓存冷启动)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "caching", "LLM", "latency"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Cache Cold-Start (缓存冷启动)
|
||||||
|
|
||||||
|
**Cache Cold-Start** 指在分布式 [[distributed-prompt-caching]] 环境中,当一个 Agent 节点尝试接入已有会话但本地无前缀缓存时,必须跨越网络重新传输全部历史 Token 并触发 LLM 端完整前缀重算的现象。
|
||||||
|
|
||||||
|
## 在量化交易中的影响
|
||||||
|
|
||||||
|
典型场景:信号挖掘节点已积累 150k Token 的热上下文 → 高波动行情触发横向扩展 → 验证节点发起首次 API 调用 → 发生 Cache Cold-Start:
|
||||||
|
|
||||||
|
- **网络传输**:物理上重新发送 150k Token
|
||||||
|
- **计算重算**:LLM 服务端完整前缀重算(数秒)
|
||||||
|
- **后果**:信号时效性彻底丧失
|
||||||
|
|
||||||
|
## 解决方案
|
||||||
|
|
||||||
|
1. **主动预热**([[active-cache-warmup]]):在需要前通过 Shadow Calling 预填充缓存
|
||||||
|
2. **分布式路由**([[distributed-cache-routing]]):通过 Redis 路由表查询热节点位置
|
||||||
|
3. **降级策略**([[context-pruning]]):冷启动不可避时,裁剪上下文至最小可接受范围
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[shadow-calling]] — 消除冷启动的核心机制
|
||||||
|
- [[context-pruning]] — 冷启动时的降级方案
|
||||||
35
concepts/capability-control-tradeoff.md
Normal file
35
concepts/capability-control-tradeoff.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "Capability-Control Tradeoff(能力-控制权衡)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, tradeoff, security, capability, control]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Capability-Control Tradeoff
|
||||||
|
|
||||||
|
> 更强的 Harness 给 Agent 更多权力,但每次能力扩展都增大控制问题。这不是安全附加组件,而是连接工具 Schema、上下文策略、运行时权限、身份、审计和人机审批的设计轴。
|
||||||
|
|
||||||
|
## 权衡的具象化
|
||||||
|
|
||||||
|
| 能力扩展 | 控制成本 |
|
||||||
|
|---------|---------|
|
||||||
|
| 更大的工具菜单 | 选择错误增加、prompt injection 表面扩大 |
|
||||||
|
| 持久记忆 | 来源追踪(provenance)、陈旧性、隐私风险 |
|
||||||
|
| 宽松沙箱 | 自主执行有用但爆炸半径扩大 |
|
||||||
|
| 自主权限 | 需要更细粒度的身份、审计和恢复机制 |
|
||||||
|
|
||||||
|
## 设计含义
|
||||||
|
|
||||||
|
- 不是"先建功能再加固"的附加模型
|
||||||
|
- 工具 Schema、上下文策略、运行时权限、身份、审计、人工审批**从设计之初就应统一考虑**
|
||||||
|
- 每增加一项能力都需要同步增强控制边界
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[cost-quality-speed-trilemma]]
|
||||||
|
- [[governance-security]] — G 层是 control 侧的体现
|
||||||
|
- [[binding-constraint-thesis]]
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
40
concepts/capability-degradation.md
Normal file
40
concepts/capability-degradation.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "能力退化 (Capability Degradation)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["continual-learning", "catastrophic-forgetting"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 能力退化 (Capability Degradation)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
能力退化是指 LMM 在注入新知识后,在**通用能力测试**(综合评估、OCR、多学科、指令遵循、数学推理、幻觉检测)上出现显著性能下降的现象。
|
||||||
|
|
||||||
|
## 量化数据(LLaVA-v1.5)
|
||||||
|
|
||||||
|
| 方法 | 平均退化 | 最严重退化项 |
|
||||||
|
|------|---------|------------|
|
||||||
|
| Full-FT | -25.89% | MIA-Bench (-61.93%), HallusionBench (-57.40%) |
|
||||||
|
| LoRA | -25.74% | HallusionBench (-59.65%), MIA-Bench (-55.28%) |
|
||||||
|
|
||||||
|
## 测试维度(12 个基准,7 个维度)
|
||||||
|
|
||||||
|
1. 综合评估:MME, MMBench
|
||||||
|
2. OCR:SEEDBench2 Plus, OCRBench
|
||||||
|
3. 多学科:ScienceQA, MMMU
|
||||||
|
4. 指令遵循:MIA-Bench
|
||||||
|
5. 多轮对话:MMDU
|
||||||
|
6. 数学推理:MathVista, MathVision
|
||||||
|
7. 幻觉检测:POPE, HallusionBench
|
||||||
|
|
||||||
|
## 与灾难性遗忘的关系
|
||||||
|
|
||||||
|
能力退化是[[catastrophic-forgetting|灾难性遗忘]]在多模态知识注入场景下的具体表现。但本研究发现**部分退化可以通过知识感知增强缓解**,这是此前未被注意的现象。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-retention|知识保留]]
|
||||||
|
- [[data-replay|数据回放]]
|
||||||
|
- [[moe-lora|MoELoRA]]
|
||||||
40
concepts/coarse-to-fine-granularity.md
Normal file
40
concepts/coarse-to-fine-granularity.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Coarse-to-Fine Granularity"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["training-schedule", "efficiency", "multi-modal", "design-pattern"]
|
||||||
|
sources: ["https://arxiv.org/abs/2605.06546"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Coarse-to-Fine Granularity (粗→细粒度调度)
|
||||||
|
|
||||||
|
**Coarse-to-Fine Granularity** 是一种跨模态的训练效率设计模式:先用粗粒度、高吞吐量的表示进行训练,再逐步切换到细粒度表示。这是一个在视觉、语言和多模态中反复出现的可再生设计原则。
|
||||||
|
|
||||||
|
## 在语言模型中的体现
|
||||||
|
|
||||||
|
- **[[token-superposition-training|TST]]** (Peng et al. 2026): s-token 平均 → 标准 token
|
||||||
|
- **SuperBPE** (Liu et al.): 合并 BPE token → supertoken
|
||||||
|
- **Bolmo** (Minixhofer et al.): byte-level → subword
|
||||||
|
- **Patch-Level Training** (Shao et al.): patch 平均 → 标准 token
|
||||||
|
|
||||||
|
## 在视觉模型中的体现
|
||||||
|
|
||||||
|
- **ViT patch size scheduling** (Anagnostidis et al.): 大 patch → 小 patch
|
||||||
|
- 本质相同:patch size 控制视觉 ViT 的"输入粒度"
|
||||||
|
|
||||||
|
## 原理
|
||||||
|
|
||||||
|
粗粒度表示 = 每个训练样本携带更多"原始信息",但分辨率更低。这等价于:
|
||||||
|
- 等计算量下吞吐量 ↑ s 倍
|
||||||
|
- 先学习粗统计结构,后精调细节
|
||||||
|
|
||||||
|
## 效率公式
|
||||||
|
|
||||||
|
在 compute-bound 约束下(训练受限于 FLOPs 而非数据量),coarse-to-fine 调度本质上用**更多数据吞吐量**换取**更快的 loss 下降**——这与 [[throughput-hypothesis]] 一致。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[token-superposition-training]] — 语言模型中的实例
|
||||||
|
- [[throughput-hypothesis]] — 吞吐量假说
|
||||||
|
- [[two-phase-pretraining]] — 实现粗→细调度的训练范式
|
||||||
42
concepts/code-as-harness.md
Normal file
42
concepts/code-as-harness.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Code as Harness"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "code-synthesis", "LLM", "framework"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Code as Harness
|
||||||
|
|
||||||
|
**Code as Harness** 是 [[autoharness|AutoHarness]] 的核心框架哲学:LLM Agent 不应只是一段 prompt + 一个模型,而应该是一个 **LLM + 自动生成的代码 harness** 的组合体——其中 harness 由 LLM 自己编写。
|
||||||
|
|
||||||
|
## 哲学
|
||||||
|
|
||||||
|
> 不是让 LLM 变得完美,而是让它可以被代码约束和保护。
|
||||||
|
|
||||||
|
传统 Agent 定义 = LLM + hand-coded "plumbing"。Code as Harness 将其升级为 = LLM + auto-generated "plumbing"。
|
||||||
|
|
||||||
|
## 为什么是代码?
|
||||||
|
|
||||||
|
- **可验证**:代码的正确性可以被环境客观检验(对比:LLM 推理无法被确定性验证)
|
||||||
|
- **可迭代**:代码可以基于 feedback 逐步改进(对比:fine-tuning 昂贵且不可逆)
|
||||||
|
- **可组合**:不同游戏的 harness 可以组合成库
|
||||||
|
|
||||||
|
## Harness 的三种抽象层级
|
||||||
|
|
||||||
|
从约束最强到最灵活:
|
||||||
|
|
||||||
|
1. **Harness-as-Action-Verifier**:固定 rejection sampling loop,只学习 `is_legal_action()` 函数
|
||||||
|
2. **Harness-as-Action-Filter**:代码生成合法动作集,LLM 负责排序
|
||||||
|
3. **[[harness-as-policy|Harness-as-Policy]]**:代码直接决策,完全消除 LLM 推理——这是 code-as-harness 的终极形态
|
||||||
|
|
||||||
|
## 与 Code-as-Policies 的关系
|
||||||
|
|
||||||
|
Code as Policies (Liang et al., 2023) 将机器人控制直接表达为代码生成。Code as Harness 的独特之处在于:**用迭代代码精炼 + 树搜索 + 环境 feedback 生成 hybrid code+LLM harness**,而不要求一次生成完美代码。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[autoharness]] — 完整方法
|
||||||
|
- [[harness-as-policy]] — 终极形态
|
||||||
|
- [[lou-autoharness-2026]] — 原始论文
|
||||||
51
concepts/compiled-ai-paradigm.md
Normal file
51
concepts/compiled-ai-paradigm.md
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
---
|
||||||
|
title: "Compiled AI Paradigm (编译型 AI 范式)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["ai-paradigm", "compilation", "code-synthesis", "deployment"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Compiled AI Paradigm (编译型 AI 范式)
|
||||||
|
|
||||||
|
**Compiled AI Paradigm** 是一种新兴的 AI 部署范式:LLM 在**编译阶段**生成可执行代码,**执行阶段**确定性运行——完全不调用 LLM。[[autoharness|AutoHarness]] 的 Harness-as-Policy 模式是其典型实例。
|
||||||
|
|
||||||
|
## 与传统 AI 部署的对比
|
||||||
|
|
||||||
|
| 阶段 | 传统部署 | 编译型 AI |
|
||||||
|
|------|----------|-----------|
|
||||||
|
| 训练 | Fine-tuning / RLHF | 代码搜索 + 迭代精炼 |
|
||||||
|
| 编译 | 模型量化/导出 | LLM 生成 + 环境验证 |
|
||||||
|
| 推理 | GPU 上的矩阵乘法 | CPU 上的 Python/编译代码 |
|
||||||
|
| 成本 | 高昂(GPU 算力) | 趋近于零 |
|
||||||
|
| 可解释性 | 无 | 完整源码审计 |
|
||||||
|
|
||||||
|
## 核心思想
|
||||||
|
|
||||||
|
LLM 的"智能"被**蒸馏编译**为可执行程序:
|
||||||
|
- 训练阶段:LLM 通过环境反馈学习策略
|
||||||
|
- 编译阶段:策略被抽象为确定性代码
|
||||||
|
- 推理阶段:代码直接运行,无需 LLM
|
||||||
|
|
||||||
|
## 实例
|
||||||
|
|
||||||
|
- **Harness-as-Policy**:Gemini-2.5-Flash 训练 → Python 代码策略 → 16 个游戏平均 reward 0.870
|
||||||
|
- **成本对比**:编译型 ~$0 vs GPT-5.2 ~$640
|
||||||
|
|
||||||
|
## 适用条件
|
||||||
|
|
||||||
|
- 任务规则可形式化(如棋盘游戏)
|
||||||
|
- 策略空间可被代码穷举或近似
|
||||||
|
- 环境反馈明确(合法/非法、reward)
|
||||||
|
|
||||||
|
## 局限
|
||||||
|
|
||||||
|
- 复杂博弈推理(2P 游戏)需要 MCTS 等搜索算法
|
||||||
|
- 模糊约束环境(物理交互、社会规范)难以形式化
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[harness-as-policy]] — 编译型 AI 的典型实现
|
||||||
|
- [[heuristic-learning]] — 编译型 AI 的学习范式基础
|
||||||
|
- [[harness-engineering]] — 编译型 AI 的工程支撑
|
||||||
40
concepts/computer-use-agents.md
Normal file
40
concepts/computer-use-agents.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Computer Use Agents (CUAs)"
|
||||||
|
created: 2026-05-31
|
||||||
|
type: concept
|
||||||
|
tags: [agents, gui, desktop-automation, tool-use]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Computer Use Agents (CUAs)
|
||||||
|
|
||||||
|
**Computer Use Agents (CUAs)** 是一类能够在桌面环境中通过感知屏幕截图、执行原子操作来完成复杂任务的 AI Agent。它们代表了 [[agent-computer-interface|Agent-Computer Interface]] 的核心应用范式。
|
||||||
|
|
||||||
|
## 核心特征
|
||||||
|
|
||||||
|
1. **多模态感知**:以桌面截图为输入,结合先前工具调用的返回结果
|
||||||
|
2. **动作空间**:传统 CUA 主要依赖**原子 GUI 动作**(点击、滚动、输入等坐标级操作)
|
||||||
|
3. **长期任务**:处理跨多个应用步骤的长周期工作流(如文件管理、文档编辑、数据整理)
|
||||||
|
|
||||||
|
## 关键挑战
|
||||||
|
|
||||||
|
### 纯 GUI 模式的问题
|
||||||
|
- **级联错误**:长序列中的每一步都可能出错,错误累积
|
||||||
|
- **脆弱性**:依赖像素级坐标,对环境变化敏感
|
||||||
|
- **低效**:简单操作(如修改列值)可能需要数十步 click/type
|
||||||
|
|
||||||
|
### [[gui-tool-hybrid-action-space|混合动作空间]]的困惑
|
||||||
|
当同时暴露 GUI 动作和工具调用时,CUA 面临 **[[optimal-gui-tool-path-selection|最优路径选择]]** 困境:
|
||||||
|
- **过度使用工具**:在不必要时调用工具,反而增加失误率(如 Claude-4.5-Sonnet 从 61.9% 降到 48.4%)
|
||||||
|
- **工具使用不足**:几乎不调用工具,仍以纯 GUI 方式处理(如 EvoCUA-32B 平均 7.49 次工具调用却从 52.6% 降到 40.5%)
|
||||||
|
|
||||||
|
## 解决方案方向
|
||||||
|
|
||||||
|
- [[toolcua-optimal-gui-tool-orchestration|ToolCUA]]:通过合成数据 + 分阶段 RL 学习最优 GUI-Tool 切换
|
||||||
|
- [[interleaved-gui-tool-trajectory-scaling]]:从纯 GUI 轨迹扩展到混合轨迹的数据管线
|
||||||
|
- [[osworld-mcp]]:支持混合动作空间的标准评估基准
|
||||||
|
|
||||||
|
## 与其他 Agent 概念的关系
|
||||||
|
|
||||||
|
- [[agentic-systems]]:CUA 是 Agentic System 在桌面自动化领域的具体实例
|
||||||
|
- [[agent-computer-interface]]:CUA 的交互接口
|
||||||
|
- [[agent-observability]]:CUA 需要屏幕感知和工具反馈的可观测性
|
||||||
41
concepts/context-drift.md
Normal file
41
concepts/context-drift.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Context Drift(上下文漂移)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [context, memory, agent, degradation]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context Drift
|
||||||
|
|
||||||
|
> Agent 在多步执行中,由于上下文不断累积、轮替和变异导致的性能退化现象。这不是边缘情况——是 Agent 的**正常操作条件**。
|
||||||
|
|
||||||
|
## 三种退化机制
|
||||||
|
|
||||||
|
### 1. U 形注意力曲线
|
||||||
|
- Liu et al. (2024):在多文档 QA 中,放在上下文中间的相关文档准确率比放在开头或结尾**低 30%**
|
||||||
|
- 跨模型、跨任务、跨上下文长度均成立
|
||||||
|
- 信息**位置**和**存在**同等重要
|
||||||
|
|
||||||
|
### 2. Context Rot(上下文腐烂)
|
||||||
|
- Hong et al. (2025):评测 18 个前沿模型(GPT-4.1、Claude Opus 4、Gemini 2.5、Qwen3),**每个模型都随输入增长而退化**
|
||||||
|
- 退化在上下文窗口远未满时就已开始(200K 窗口可能在 50K 时就有显著退化)
|
||||||
|
- 语义模糊查询退化更陡:模型既定位不到相关信息,定位后也无法推理
|
||||||
|
|
||||||
|
### 3. 工具结果累积
|
||||||
|
- 每一步工具调用都会向上下文注入新 token
|
||||||
|
- 不加管理时,上下文迅速膨胀
|
||||||
|
- 早期决策错误会随着 trace 累积而放大
|
||||||
|
|
||||||
|
## 应对策略
|
||||||
|
- [[context-management|上下文管理]] (C 层):短/中/长期记忆分层
|
||||||
|
- **渐进式披露**(Progressive Disclosure):按需加载而非全量预加载
|
||||||
|
- **压缩**(Compaction):移除已完成使命的 token
|
||||||
|
- KV-cache 感知的上下文设计
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[context-management]] — C 层总体
|
||||||
|
- [[binding-constraint-thesis]] — 约束瓶颈论
|
||||||
|
- [[execution-environment]] — E 层
|
||||||
41
concepts/context-engineering.md
Normal file
41
concepts/context-engineering.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Context Engineering(上下文工程)"
|
||||||
|
created: 2026-05-30
|
||||||
|
updated: 2026-05-30
|
||||||
|
type: concept
|
||||||
|
tags: [context, engineering, agent]
|
||||||
|
sources: [[agent-harness-engineering-survey]]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context Engineering
|
||||||
|
|
||||||
|
> 三阶段工程演进的第二阶段(2025):从优化单次模型输入到管理多步推理中模型每步可见的完整信息状态。
|
||||||
|
|
||||||
|
## 核心转变
|
||||||
|
|
||||||
|
Context Engineering 的关键转变在于从"输入是什么"到"模型在每一步应该看到什么"。
|
||||||
|
|
||||||
|
## 指导原则
|
||||||
|
|
||||||
|
找到**最小的高信号 token 集**,最大化每一步期望结果的概率(Anthropic Applied AI Team, 2025)。
|
||||||
|
|
||||||
|
## 三大技术支柱
|
||||||
|
|
||||||
|
- **渐进式披露**(Progressive Disclosure):按需加载信息而非全量预加载
|
||||||
|
- **压缩**(Compaction):移除已完成使命的 token
|
||||||
|
- **记忆检索**:只拉入与当前任务最相关的记录
|
||||||
|
|
||||||
|
## 上下文包含的内容
|
||||||
|
|
||||||
|
在部署的 Agent 中,上下文包括:系统 prompt + 工具定义 + 历史轮次 + 工具调用结果 + 检索文档 + 动态注入的工作状态。所有这些都在争抢有限的注意力预算。
|
||||||
|
|
||||||
|
## 三阶段定位
|
||||||
|
|
||||||
|
Context Engineering 位于 [[three-engineering-phases|三阶段工程演进]] 的中层——它包含 Prompt Engineering 的实践,同时被 [[agent-harness-engineering|Harness Engineering]] 所扩展。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
- [[three-engineering-phases]] — 三阶段工程演进
|
||||||
|
- [[context-management]] — C 层:短/中/长期上下文管理
|
||||||
|
- [[context-drift]] — 上下文漂移的三种退化机制
|
||||||
|
- [[prompt-to-harness-evolution]] — 详细演化分析
|
||||||
41
concepts/context-management.md
Normal file
41
concepts/context-management.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Context Management(上下文管理)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, context, memory, prompt]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context & Memory Management(C 层)
|
||||||
|
|
||||||
|
> ETCLOVG 的 C 层:控制模型在短期、会话级和持久视野中能看到什么。从 Prompt Engineering 演进而来。
|
||||||
|
|
||||||
|
## 三层视野
|
||||||
|
|
||||||
|
- **短期(Active Context Window)**:compaction、tool-result clearing、prompt-cache-aware ordering
|
||||||
|
- **中期(Session State)**:跨运行持久化、会话状态管理
|
||||||
|
- **长期(Persistent Memory)**:向量存储、知识图谱、写入-管理-读取循环
|
||||||
|
|
||||||
|
## 核心挑战:上下文漂移(Context Drift)
|
||||||
|
|
||||||
|
最深的上下文问题不是装更多 token,而是保持 Agent 的**工作状态与真实任务状态对齐**。
|
||||||
|
|
||||||
|
每次压缩、检索、遗忘操作都可能删除约束、扭曲优先级或保留过时假设。
|
||||||
|
|
||||||
|
## 重新框架:上下文作为状态估计
|
||||||
|
|
||||||
|
Zhang et al. (2025) 和 Du (2026) 将 Agent 记忆形式化为**写入-管理-读取循环**。未来系统需要:
|
||||||
|
- 不确定性感知摘要
|
||||||
|
- 事实溯源(provenance)
|
||||||
|
- 矛盾处理
|
||||||
|
- 显式陈旧标记
|
||||||
|
- 从持久化产物重建状态的恢复程序
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-state-estimation]] — 上下文作为状态估计
|
||||||
|
- [[reliable-state-long-running-agents]] — 长期状态维护
|
||||||
|
- [[prompt-to-harness-evolution]] — 从 Prompt 到 Context 的演进
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
40
concepts/context-pruning.md
Normal file
40
concepts/context-pruning.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Context Pruning (上下文剪枝)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "resilience", "LLM", "degradation"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context Pruning (上下文剪枝)
|
||||||
|
|
||||||
|
**Context Pruning** 是分布式 Agent 系统在遭遇网络分区或 [[cache-cold-start]] 时的紧急降级策略:主动将长历史上下文切除,仅保留最核心的 System Prompt 与最近几轮对话(通常不超过 8k Token)。
|
||||||
|
|
||||||
|
## 触发条件
|
||||||
|
|
||||||
|
- 分布式路由表查询超时(毫秒级硬上限)
|
||||||
|
- 跨机主动预热流水线失败
|
||||||
|
- Redis 骨干网连接丢失
|
||||||
|
|
||||||
|
## 降级流程
|
||||||
|
|
||||||
|
1. **切断跨机预热**:立即停用 [[active-cache-warmup]]
|
||||||
|
2. **本地孤岛模式**:会话降级为单机运行
|
||||||
|
3. **内存剪枝**:切除长历史上下文,保留 System Prompt + 最近三轮对话
|
||||||
|
4. **硬控制延迟**:将冷启动延迟硬控制在阈值以内
|
||||||
|
|
||||||
|
## 权衡
|
||||||
|
|
||||||
|
- **牺牲推理深度**:裁剪后上下文信息减少,可能降低决策质量
|
||||||
|
- **保证可达性**:风控平仓等关键指令的绝对可达性优先于推理深度
|
||||||
|
|
||||||
|
## 在混沌工程中的角色
|
||||||
|
|
||||||
|
Context Pruning 是分布式缓存系统的最后一道防线——当所有优化机制(预热、路由、一致性)都失败时,确保系统仍能完成核心功能。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[cache-cold-start]] — Pruning 应对的问题
|
||||||
|
- [[active-cache-warmup]] — Pruning 的"上游"机制(优先使用)
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
39
concepts/context-state-estimation.md
Normal file
39
concepts/context-state-estimation.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Context as State Estimation(上下文作为状态估计)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, context, state-estimation, memory]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Context as State Estimation
|
||||||
|
|
||||||
|
> 将上下文管理重新概念化为**状态估计问题**:Agent 的内部工作状态是对真实任务状态的估计,每次压缩、检索或遗忘操作都可能引入估计误差。
|
||||||
|
|
||||||
|
## 与传统视角的对比
|
||||||
|
|
||||||
|
| 传统视角 | 状态估计视角 |
|
||||||
|
|---------|------------|
|
||||||
|
| 上下文 = 信息窗口 | 上下文 = Agent 对任务状态的信念 |
|
||||||
|
| 目标:装更多 token | 目标:最小化信念与真实状态间的散度 |
|
||||||
|
| 评估:token 利用率 | 评估:是否防止了下游操作错误 |
|
||||||
|
|
||||||
|
## 关键问题
|
||||||
|
|
||||||
|
- 量化每次压缩/检索/遗忘步骤中的信息损失
|
||||||
|
- 界定 Agent 内部状态与真实任务状态的散度上界
|
||||||
|
- 不确定性感知摘要:不仅记住内容,还记住不确定性
|
||||||
|
- 从持久化产物重建状态而非信任自身压缩历史
|
||||||
|
|
||||||
|
## 与记忆评估的关联
|
||||||
|
|
||||||
|
记忆策略不应仅按**召回准确率**评判,还应按**是否防止了多会话任务中的下游操作错误**来评判。这需要将 [[verification-evaluation]] 与 [[context-management]] 更紧密耦合。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[context-management]]
|
||||||
|
- [[reliable-state-long-running-agents]]
|
||||||
|
- [[verification-evaluation]]
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
42
concepts/controlled-autonomy.md
Normal file
42
concepts/controlled-autonomy.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Controlled Autonomy (受控的自主性)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["self-evolution", "agent", "control", "safety"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/s__fdyXQG932SavQeeugcw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Controlled Autonomy (受控的自主性)
|
||||||
|
|
||||||
|
**Controlled Autonomy** 是吕明在 SkillOpt 深度解读中提出的自进化 Agent 核心设计原则:**人类设定目标(验证集)和边界(编辑约束),Agent 在框架内自主寻找最优策略。**
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
> "一种'受控的自主性'——人类设定目标(验证集)和边界(编辑约束),Agent 在框架内自主寻找最优策略。"
|
||||||
|
|
||||||
|
这与"完全自主"(AGI)和"完全人工"(手写 Skill)形成明确区分。
|
||||||
|
|
||||||
|
## 三元结构
|
||||||
|
|
||||||
|
| 角色 | 负责 | 类比 |
|
||||||
|
|------|------|------|
|
||||||
|
| **人类** | 设定验证集 + 编辑约束 | 立法者 |
|
||||||
|
| **Optimizer** | 因果分析 + 提出编辑 | 执行者 |
|
||||||
|
| **Validation Gate** | 验证接受/拒绝 | 司法者 |
|
||||||
|
|
||||||
|
## 为什么需要"受控"
|
||||||
|
|
||||||
|
- **无需证明安全**:验证集天然保证了编辑的安全性(只接受改善)
|
||||||
|
- **可审计**:每次编辑都有 Diff + 验证分数变化
|
||||||
|
- **可回滚**:拒绝缓冲防止重复失败方向
|
||||||
|
|
||||||
|
## 与 AGI 的关系
|
||||||
|
|
||||||
|
> "这不是 AGI,甚至离 AGI 还有很远。但它是通往'更具自主性的 AI 系统'的一步扎实的脚印。"
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[skillopt]] — 受控自主性的技术实现
|
||||||
|
- [[held-out-validation-gate]] — 验证门(受控的"司法者")
|
||||||
|
- [[textual-learning-rate]] — 编辑约束(受控的"边界")
|
||||||
39
concepts/cost-quality-speed-trilemma.md
Normal file
39
concepts/cost-quality-speed-trilemma.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Cost-Quality-Speed Trilemma(成本-质量-速度三元悖论)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, tradeoff, cost, quality, optimization]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Cost-Quality-Speed Trilemma
|
||||||
|
|
||||||
|
> Agent Harness 可靠性受成本、质量和速度之间的三方权衡约束。无法同时优化所有维度。
|
||||||
|
|
||||||
|
## 三方张力
|
||||||
|
|
||||||
|
- **质量 ↑**:更强的沙箱、更深的评估、更丰富的上下文 → **成本 ↑**、**速度 ↓**
|
||||||
|
- **速度 ↑**:轻量沙箱、简化评估、压缩上下文 → **质量 ↓**、**成本 ↓**
|
||||||
|
- **成本 ↓**:减少 token 消耗、降低基础设施 → **质量 ↓**、**速度 ↓**
|
||||||
|
|
||||||
|
## 具体表现
|
||||||
|
|
||||||
|
- 更强的沙箱和更忠实的环境 → 提高安全性和可复现性 → 增加启动延迟和基础设施成本
|
||||||
|
- 更丰富的上下文和记忆策略 → 改善任务连续性 → 消耗更多 token 并引入检索开销
|
||||||
|
- 更深的评估和可观测性 → 改善诊断 → 减慢迭代速度并增加存储/标注/追踪处理成本
|
||||||
|
|
||||||
|
## 工程决策
|
||||||
|
|
||||||
|
生产系统不能将质量视为标量目标。必须决定:
|
||||||
|
- 哪些风险值得昂贵控制
|
||||||
|
- 哪些检查可以异步运行或在回归套件中运行
|
||||||
|
- 在 Agent 生命周期的每个阶段值得捕获哪些遥测数据
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[capability-control-tradeoff]]
|
||||||
|
- [[harness-coupling-problem]]
|
||||||
|
- [[adaptive-harness-simplification]] — 通过简化降低成本的路径
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
40
concepts/covariance-matrix-knowledge.md
Normal file
40
concepts/covariance-matrix-knowledge.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "协方差矩阵知识存储 (Covariance Matrix Knowledge Storage)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["linear-algebra", "knowledge-representation", "model-analysis"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 协方差矩阵知识存储
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
协方差矩阵知识存储是指利用 LMM 线性层激活的**协方差矩阵**来捕获和存储模型已有的多模态知识。这一技术在 [[kore-constraint|KORE-CONSTRAINT]] 中被用于识别"哪些参数空间已被旧知识占据"。
|
||||||
|
|
||||||
|
## 构建方式
|
||||||
|
|
||||||
|
对 LMM 在代表预训练知识的样本上的激活 X ∈ R^{d_in × BL}:
|
||||||
|
C = XX^T
|
||||||
|
|
||||||
|
使用 OneVision 数据集的 256 个样本(General, Doc/Chart/Screen, Math/Reasoning, General OCR)构建多维协方差矩阵。
|
||||||
|
|
||||||
|
## 为什么协方差矩阵能存储知识?
|
||||||
|
|
||||||
|
### 证据 1:重构实验
|
||||||
|
对 C 进行 SVD → 移除最小 r 个奇异值对应的分量 → 重构权重。CO-SVD 比 Plain SVD 和 ASVD 更好地保留了性能,说明**多模态知识可以被协方差矩阵有效捕获**。
|
||||||
|
|
||||||
|
### 证据 2:任务模式可视化
|
||||||
|
- 相关任务(POPE 和 HallusionBench)在协方差矩阵中展示**相似的异常值模式**
|
||||||
|
- 不相关任务(MMBench)展示**不同的模式**
|
||||||
|
- 说明协方差矩阵中的异常值分布**编码了任务特定的知识结构**
|
||||||
|
|
||||||
|
## 应用
|
||||||
|
|
||||||
|
在 KORE 中,协方差矩阵的零空间被用于初始化 LoRA adapter,确保微调不会干扰已有知识。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[null-space-projection-knowledge|零空间投影知识保留]]
|
||||||
|
- [[kore-constraint|KORE-CONSTRAINT]]
|
||||||
|
- [[covariance-matrix|协方差矩阵]]
|
||||||
24
concepts/covariance-matrix.md
Normal file
24
concepts/covariance-matrix.md
Normal file
@@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: "协方差矩阵 (Covariance Matrix)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["linear-algebra", "statistics"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 协方差矩阵 (Covariance Matrix)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
协方差矩阵是统计学中描述多维随机变量各维度之间**线性相关性**的矩阵。在 [[covariance-matrix-knowledge|协方差矩阵知识存储]] 中,LMM 线性层激活的协方差矩阵 C = XX^T 被用于捕获模型已存储的知识结构。
|
||||||
|
|
||||||
|
## 在 KORE 中
|
||||||
|
|
||||||
|
C 的 SVD 分解揭示:
|
||||||
|
- **大奇异值**对应的向量 = 已有知识占据的关键方向
|
||||||
|
- **零空间** = 可安全写入新知识的方向
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[covariance-matrix-knowledge|协方差矩阵知识存储]]
|
||||||
|
- [[null-space|零空间]]
|
||||||
43
concepts/data-hierarchical-governance.md
Normal file
43
concepts/data-hierarchical-governance.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Data Hierarchical Governance (L0-L4 数据分级治理)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["data-governance", "pretraining", "quality", "pipeline"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/5jV2jYuXJloKX5IWCzrSpw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Data Hierarchical Governance (L0-L4 数据分级治理)
|
||||||
|
|
||||||
|
**L0-L4 Data Hierarchical Governance** 是面壁智能联合清华大学、OpenBMB 提出的数据治理框架:将训练数据按加工深度分为五个层级,按训练阶段匹配数据层级,最大化单位 Token 的边际效益。
|
||||||
|
|
||||||
|
## 五级体系
|
||||||
|
|
||||||
|
| 层级 | 名称 | 加工 | 成本 | 适用阶段 |
|
||||||
|
|:---:|------|------|:---:|------|
|
||||||
|
| **L0** | 原始数据 | 采集解析 | 极低 | 不直接训练 |
|
||||||
|
| **L1** | 过滤数据 | 启发式规则 | 低 | 预训练前期 |
|
||||||
|
| **L2** | 精筛数据 | 模型打分+标注 | 中 | 预训练中后期 |
|
||||||
|
| **L3** | 合成增强 | 改写/合成/人工标注 | 高 | 退火/SFT/RL |
|
||||||
|
| **L4** | 编排数据 | 可信校验+编排 | 中 | RAG |
|
||||||
|
|
||||||
|
## 核心逻辑
|
||||||
|
|
||||||
|
> "好钢用在刀刃上"
|
||||||
|
|
||||||
|
- **前期(L1/L2)**:广撒网注入常识,用轻量级规则控制成本
|
||||||
|
- **后期(L3)**:高密度、逻辑强、噪声少的合成数据激发推理
|
||||||
|
- **端侧(L4)**:可直接用于 RAG 的知识检索
|
||||||
|
|
||||||
|
## 实验验证
|
||||||
|
|
||||||
|
面壁智能在英文网页、中文网页、数学和代码四个领域验证:
|
||||||
|
> **模型性能随数据层级从 L1 向 L3 逐级提升而持续增强**
|
||||||
|
|
||||||
|
UltraData-Math (100B L3) 在 MATH 上领先 Nemotron-CC 4plus 3.62 分。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[ultradata]] — 基于此体系的完整数据系统
|
||||||
|
- [[stage-matched-data-config]] — 分阶段配置策略
|
||||||
|
- [[data-quality-over-scale]] — 质量>规模的行业转向
|
||||||
37
concepts/data-label-consistency.md
Normal file
37
concepts/data-label-consistency.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "Data-Label Consistency (数据-标签一致性)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["time-series", "data-augmentation", "forecasting"]
|
||||||
|
sources: ["temporal-patch-shuffle-tps"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Data-Label Consistency
|
||||||
|
|
||||||
|
> 时间序列预测增强的必要条件:输入 x 与目标 y 必须被联合变换,以保持序列的时间连续性。
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
记 look-back 窗口为 x,预测目标为 y。训练作用的对象是连续序列 s = x ∥ y,增强应作用在拼接后的序列上:
|
||||||
|
|
||||||
|
```
|
||||||
|
s = x ∥ y
|
||||||
|
s̃ = 𝒜(s)
|
||||||
|
(x̃, ỹ) = Split(s̃)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 为什么重要
|
||||||
|
|
||||||
|
- 只对 x 增强、让 y 原封不动 → 输入与目标之间的天然连续性被人为切断
|
||||||
|
- 在 [[temporal-patch-shuffle|TPS]] 的消融实验中,**数据-标签一致性的破坏是单一消融中性能下降最大的因素**
|
||||||
|
- 这是预测增强区别于分类增强的根本约束
|
||||||
|
|
||||||
|
## 实践含义
|
||||||
|
|
||||||
|
所有有效的预测增强方法([[freqmask-freqmix|FreqMask/FreqMix]]、[[wavemask-wavemix|WaveMask/WaveMix]]、[[temporal-patch-shuffle|TPS]])都采用了这个拼接-增强-拆分范式。
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[time-series-forecasting-augmentation]] — 预测增强框架
|
||||||
|
- [[temporal-patch-shuffle]] — 内置数据-标签一致性的 SOTA 方法
|
||||||
|
- [[forecasting-augmentation-taxonomy]] — 各类方法对此原则的遵守情况
|
||||||
43
concepts/data-quality-over-scale.md
Normal file
43
concepts/data-quality-over-scale.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Data Quality over Scale (数据质量重于规模)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["data-engineering", "industry-trend", "pretraining", "efficiency"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/5jV2jYuXJloKX5IWCzrSpw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Data Quality over Scale (数据质量重于规模)
|
||||||
|
|
||||||
|
**Data Quality over Scale** 是面壁智能 UltraData 实践所推动的行业共识转向:**当模型架构趋于收敛、算力成本高企不下时,数据质量——而非参数规模或算力投入——成为模型能力的核心决定因素。**
|
||||||
|
|
||||||
|
## 范式转变
|
||||||
|
|
||||||
|
| 旧范式 | 新范式 |
|
||||||
|
|--------|--------|
|
||||||
|
| 堆硬件、堆参数 | 精细化数据治理 |
|
||||||
|
| 爬更多网页 | 从存量数据榨取更高密度知识 |
|
||||||
|
| 一刀切处理 | [[data-hierarchical-governance|分级分阶段配置]] |
|
||||||
|
| 数据是"原料" | 数据是"配方" |
|
||||||
|
|
||||||
|
## 证据
|
||||||
|
|
||||||
|
- MiniCPM5-1B(1B参数)超越 Qwen3.5-0.8B 和 LFM2.5-1.2B
|
||||||
|
- UltraData-Math(100B L3)超越 Nemotron-CC 4plus(更大规模)
|
||||||
|
- 同架构 + 更高质量数据 > 更大模型 + 更低质量数据
|
||||||
|
|
||||||
|
## 产业意义
|
||||||
|
|
||||||
|
1. **端侧友好**:高质量数据意味着更少训练Token→更低内存和能耗
|
||||||
|
2. **降低门槛**:小团队不必堆算力,可以聚焦数据治理
|
||||||
|
3. **开源加速**:数据配方的公开使社区可以复现和改进
|
||||||
|
|
||||||
|
## 与大模型 Scaling Law 的关系
|
||||||
|
|
||||||
|
Data Quality over Scale 不是否定 Scaling Law,而是**深化**它:在数据受限时代,scaling 的重心从"更多数据"转移到"更优数据"。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[data-hierarchical-governance]] — 实现质量优先的方法
|
||||||
|
- [[stage-matched-data-config]] — 质量×阶段的最优配置
|
||||||
|
- [[ultradata]] — 实践案例
|
||||||
42
concepts/data-replay.md
Normal file
42
concepts/data-replay.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "数据回放 (Data Replay)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["continual-learning", "knowledge-retention", "catastrophic-forgetting"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 数据回放 (Data Replay)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
数据回放是缓解[[capability-degradation|能力退化]]的一种**直接排练策略**,通过将**旧预训练数据**与新注入数据混合进行微调,强制模型"复习旧知"。
|
||||||
|
|
||||||
|
## 实现
|
||||||
|
|
||||||
|
在 MMEVOKE 论文中:
|
||||||
|
- Replay + Full-FT:随机抽样 10%(MMEVOKE 数据量大小)的旧预训练数据,与新注入数据混合,使用 Full-FT
|
||||||
|
- Replay + LoRA:同上,使用 LoRA 策略
|
||||||
|
|
||||||
|
## 效果(LLaVA-v1.5)
|
||||||
|
|
||||||
|
- Replay + Full-FT:缓解退化,**排名第 3**
|
||||||
|
- Replay + LoRA:**排名第 1**,在 MMMU 和 MathVision 上超过 Vanilla 分别 +1.75% 和 +2.20%
|
||||||
|
|
||||||
|
## 机制
|
||||||
|
|
||||||
|
通过重新暴露于旧数据,**重新激活旧知识网络**,防止新知识覆盖已有参数。
|
||||||
|
|
||||||
|
## 与 MoELoRA 的比较
|
||||||
|
|
||||||
|
| 策略 | Replay | MoELoRA |
|
||||||
|
|------|--------|---------|
|
||||||
|
| 机制 | 直接排练旧数据 | 结构性隔离新知识 |
|
||||||
|
| 优势 | 效果最佳 | 无需存储旧数据 |
|
||||||
|
| 劣势 | 需要旧数据存储 | 需修改模型架构 |
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[moe-lora|MoELoRA]]
|
||||||
|
- [[knowledge-retention|知识保留]]
|
||||||
|
- [[continual-learning|持续学习]]
|
||||||
41
concepts/deep-and-wide-reasoning.md
Normal file
41
concepts/deep-and-wide-reasoning.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "Deep-and-Wide Reasoning(深度且宽广的推理)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [reasoning, deep, wide, architecture]
|
||||||
|
sources: [raw/papers/gram-generative-recursive-reasoning-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Deep-and-Wide Reasoning
|
||||||
|
|
||||||
|
> GRAM 的设计哲学:未来的推理系统不应只是**深**(重复精炼),还应**宽**(维持和探索多条并行潜在轨迹)。
|
||||||
|
|
||||||
|
## 为什么深度不够
|
||||||
|
|
||||||
|
单一精炼路径的局限:
|
||||||
|
- 可能被困在次优推理轨迹中
|
||||||
|
- 无法同时考虑多个假设
|
||||||
|
- 在多解问题上只能返回一个解
|
||||||
|
|
||||||
|
## Deep + Wide 的互补关系
|
||||||
|
|
||||||
|
- **Deep(递归深度)**: 单条轨迹上的推理精炼质量
|
||||||
|
- **Wide(轨迹宽度)**: 推理空间的探索覆盖度
|
||||||
|
|
||||||
|
两者**正交且互补**——可以独立调参来适配不同类型的问题。
|
||||||
|
|
||||||
|
## 设计原则
|
||||||
|
|
||||||
|
好的 RRM 需要同时支持:
|
||||||
|
1. 通过多次递归步骤充分精炼单条推理路径
|
||||||
|
2. 通过随机采样探索多个可能的推理方向
|
||||||
|
3. 在 inference time 灵活分配 depth 和 width 的预算
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[inference-time-scaling]]
|
||||||
|
- [[width-based-scaling]]
|
||||||
|
- [[multi-trajectory-inference]]
|
||||||
|
- [[gram-generative-recursive-reasoning|GRAM]]
|
||||||
36
concepts/deep-thinking-sft.md
Normal file
36
concepts/deep-thinking-sft.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Deep-Thinking SFT (深思考SFT数据)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["sft", "chain-of-thought", "reasoning", "data-engineering"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/5jV2jYuXJloKX5IWCzrSpw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Deep-Thinking SFT (深思考SFT数据)
|
||||||
|
|
||||||
|
**Deep-Thinking SFT** 是 [[ultradata|UltraData-SFT-2605]] 的关键特征:SFT 数据中同时包含带有完整思维链/推理过程标注的"深思考"样本和直接问答的"非思考"样本,使模型同时发展逐步推理和高效回答的能力。
|
||||||
|
|
||||||
|
## 两类样本
|
||||||
|
|
||||||
|
| 类型 | 特征 | 训练作用 |
|
||||||
|
|------|------|------|
|
||||||
|
| **深思考** | 完整思维链、推理步骤、自我纠错 | 培养逐步推理、自纠错能力 |
|
||||||
|
| **非思考** | 直接问答对 | 保持回答效率 |
|
||||||
|
|
||||||
|
## 与传统 SFT 的区别
|
||||||
|
|
||||||
|
传统 SFT 数据多为直接问答对,缺乏过程性推理标注。Deep-Thinking SFT 弥补了这一空白,使模型在微调阶段就能学会**如何思考**而非仅仅**回答什么**。
|
||||||
|
|
||||||
|
## UltraData-SFT-2605 的特色
|
||||||
|
|
||||||
|
- 覆盖数学、代码、知识、指令遵循等多领域
|
||||||
|
- 千万级规模
|
||||||
|
- 全流程质量治理透明化(Query筛选→Answer校验→评测去污)
|
||||||
|
- 杜绝训练/测试集重叠
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[ultradata]] — UltraData 系统
|
||||||
|
- [[data-hierarchical-governance]] — L3 层级定位
|
||||||
|
- [[ultradata-l3-open-source-2026]] — 原始文章
|
||||||
39
concepts/distributed-cache-routing.md
Normal file
39
concepts/distributed-cache-routing.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Distributed Cache Routing (分布式缓存路由)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "redis", "routing", "caching"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Distributed Cache Routing (分布式缓存路由)
|
||||||
|
|
||||||
|
**Distributed Cache Routing** 是 [[distributed-prompt-caching]] 中的状态路由层:基于 Redis 集群维护全局的 `Cache_Routing_Table`,使任何物理节点上的 Agent 实例都可以瞬间查询某会话前缀在哪台机器、哪个 LLM 服务商端处于 "HOT" 状态。
|
||||||
|
|
||||||
|
## 数据模型
|
||||||
|
|
||||||
|
```
|
||||||
|
HSET cache:route:[Composite_SHA]
|
||||||
|
node_ip "192.168.1.102"
|
||||||
|
service_provider "ModelProvider_A"
|
||||||
|
status "HOT"
|
||||||
|
expire_time 1800
|
||||||
|
```
|
||||||
|
|
||||||
|
## 查询流程
|
||||||
|
|
||||||
|
1. Agent 在本地对所需前缀进行 SHA-256 哈希 → 得到 Composite Key
|
||||||
|
2. 通过 Redis `HGETALL cache:route:[Composite_SHA]` 瞬间检索
|
||||||
|
3. 获取路由信息:该前缀在哪些物理节点、哪些服务商处于热态
|
||||||
|
4. 据此决策:直接路由到热节点 / 触发 [[active-cache-warmup]]
|
||||||
|
|
||||||
|
## 核心价值
|
||||||
|
|
||||||
|
将逻辑上的会话状态与物理上的缓存生命周期**解耦映射**,使系统可以在异构模型服务商之上构建统一的缓存抽象。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[global-context-hash-tree]] — 路由的主键来源
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[active-cache-warmup]] — 路由到冷节点时的后续动作
|
||||||
28
concepts/distributed-optimistic-locking.md
Normal file
28
concepts/distributed-optimistic-locking.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
---
|
||||||
|
title: "Distributed Optimistic Locking (分布式乐观锁)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "consistency", "redis", "concurrency"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Distributed Optimistic Locking (分布式乐观锁)
|
||||||
|
|
||||||
|
**Distributed Optimistic Locking** 是 [[distributed-prompt-caching]] 中的一致性保障机制:通过 Redis 的 `WATCH` 命令和上下文版本号,确保多个物理节点并发更新同一会话上下文时不会发生"缓存分叉"。
|
||||||
|
|
||||||
|
## 机制
|
||||||
|
|
||||||
|
1. **版本号递增**:每次 Agent 生成响应或 Tool 返回结果,上下文逻辑版本号递增(V_{next} = V_{current} + 1)
|
||||||
|
2. **乐观锁申请**:任何节点发起带缓存的请求前,向 Redis 申请 `WATCH cache:version:[Session_UID]`
|
||||||
|
3. **冲突处理**:只有率先成功将版本号推向新值的节点能成功提交;落后节点缓存被宣告"部分污染"
|
||||||
|
4. **上下文对齐**:落后节点触发 Context-Realign——从共享骨干网拉取最新 Message 历史,重新进行局部 Shadow Calling 预热
|
||||||
|
|
||||||
|
## 在缓存同步中的必要性
|
||||||
|
|
||||||
|
分布式 Prompt Caching 的难点在于:多个决策模型节点可能同时对同一信号给出不同的交叉评估结论,如果缺乏一致性控制,各节点的缓存前缀将发生分叉,导致后续协作时使用过期或冲突的上下文。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[distributed-agent-cache-sync-2026]] — 原始文章
|
||||||
44
concepts/distributed-prompt-caching.md
Normal file
44
concepts/distributed-prompt-caching.md
Normal file
@@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: "Distributed Prompt Caching (分布式提示词缓存)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "prompt-caching", "LLM", "agent"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Distributed Prompt Caching (分布式提示词缓存)
|
||||||
|
|
||||||
|
**Distributed Prompt Caching** 是将单机 [[prompt-caching]] 机制扩展到多机分布式集群的技术体系,解决跨物理节点的上下文缓存同步问题。在量化交易、多 Agent 协作等分布式场景中至关重要。
|
||||||
|
|
||||||
|
## 核心挑战
|
||||||
|
|
||||||
|
- **[[cache-cold-start|缓存冷启动]]**:新节点缺少已有会话的前缀哈希,导致全额 Token 重传和秒级重算
|
||||||
|
- **跨服务商缓存割裂**:不同 LLM 供应商的缓存实现机制完全不同(Session ID vs Trie 树匹配)
|
||||||
|
- **一致性风险**:多节点并发更新同一上下文时可能发生缓存"分叉"
|
||||||
|
|
||||||
|
## 解决架构
|
||||||
|
|
||||||
|
分布式 Prompt Caching 依赖三个核心组件:
|
||||||
|
1. **[[global-context-hash-tree]]** — 基于 SHA-256 的会话唯一标识
|
||||||
|
2. **[[distributed-cache-routing]]** — Redis 骨干网状态路由表
|
||||||
|
3. **[[active-cache-warmup]]** — 预测性跨机预热
|
||||||
|
|
||||||
|
## 与单机 Prompt Caching 的对比
|
||||||
|
|
||||||
|
| 维度 | 单机 | 分布式 |
|
||||||
|
|------|------|--------|
|
||||||
|
| 缓存范围 | 单实例进程内 | 跨物理节点 + 跨服务商 |
|
||||||
|
| 标识机制 | 前缀字节匹配 | SHA-256 复合键 |
|
||||||
|
| 预热方式 | 被动(首次请求即缓存) | 主动(Shadow Calling) |
|
||||||
|
| 一致性 | 无需处理 | 乐观锁 + 版本号 |
|
||||||
|
|
||||||
|
## 核心原则
|
||||||
|
|
||||||
|
> 用**空间的确定性**(高带宽内网 + Redis 路由)换取**时间的确定性**(消除秒级重算延迟)
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[distributed-agent-cache-sync-2026]] — 原始文章
|
||||||
|
- [[prompt-caching]] — 单机 Prompt Caching
|
||||||
|
- [[active-cache-warmup]] — 跨机预热机制
|
||||||
36
concepts/distribution-shift.md
Normal file
36
concepts/distribution-shift.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Distribution Shift(分布偏移)"
|
||||||
|
created: 2026-05-18
|
||||||
|
type: concept
|
||||||
|
tags: ["pre-training", "LLM", "domain-adaptation"]
|
||||||
|
sources: ["https://arxiv.org/abs/2604.14142"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Distribution Shift(分布偏移)
|
||||||
|
|
||||||
|
## 在 PreRL 语境中的定义
|
||||||
|
|
||||||
|
传统预训练使用的**静态语料**(web text, Wikipedia)与下游推理任务的**任务分布**之间存在显著的分布偏移。这种偏移导致:
|
||||||
|
- 预训练知识无法有针对性地增强推理能力
|
||||||
|
- 直接 SFT 微调受限于预训练分布
|
||||||
|
- RLVR 可部分弥补,但被基座模型的上限所约束
|
||||||
|
|
||||||
|
## PreRL 的解决方案
|
||||||
|
|
||||||
|
PreRL 通过**在线、奖励驱动**的更新直接在 P(y) 上操作,消除了"语料→任务"的分布桥接需求:
|
||||||
|
- 不使用静态语料,而是从任务中采样 self-rollout
|
||||||
|
- 使用可验证奖励而非 NTP loss
|
||||||
|
- 只更新 response 部分,保持任务对齐
|
||||||
|
|
||||||
|
## 对比
|
||||||
|
|
||||||
|
| 方法 | 数据源 | 学习信号 | 分布偏移 |
|
||||||
|
|------|--------|---------|---------|
|
||||||
|
| Pre-training | 静态语料 | NTP | 高 |
|
||||||
|
| Continual Pre-training | 任务相关语料 | NTP | 中 |
|
||||||
|
| PreRL | Online rollout | Verifiable reward | **低** |
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[pre-train-space-reinforcement-learning|PreRL]]
|
||||||
|
- [[dual-space-rl|DSRL]]
|
||||||
38
concepts/dominant-shuffle.md
Normal file
38
concepts/dominant-shuffle.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Dominant Shuffle"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["time-series", "data-augmentation", "frequency-domain", "forecasting"]
|
||||||
|
sources: ["temporal-patch-shuffle-tps"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dominant Shuffle
|
||||||
|
|
||||||
|
> 保守的频域增强方法——仅 shuffle top-k 主导频率分量,保持频谱其余部分不变。
|
||||||
|
|
||||||
|
## 流程
|
||||||
|
|
||||||
|
1. S = FFT(s)
|
||||||
|
2. Ωₖ = top-k 主导频率的索引
|
||||||
|
3. S̃_{Ωₖ} = Shuffle(S_{Ωₖ})
|
||||||
|
4. s̃ = IFFT(S̃)
|
||||||
|
|
||||||
|
## 设计哲学
|
||||||
|
|
||||||
|
- **克制优于激进**:不对任意频谱分量做 mask 或 mix
|
||||||
|
- **避免分布外样本**:只扰动主导频率避免了过强的信号破坏
|
||||||
|
- 在统一评测中并非整体最强——但稳定性好
|
||||||
|
|
||||||
|
## 与 FreqMask/FreqMix 的区别
|
||||||
|
|
||||||
|
| 方法 | 操作对象 | 操作方式 | 风险 |
|
||||||
|
|------|---------|---------|------|
|
||||||
|
| FreqMask | 选定频率 | 清零 | 信息丢失 |
|
||||||
|
| FreqMix | 两序列频谱 | 混合 | 引入异源结构 |
|
||||||
|
| Dominant Shuffle | top-k 主导频率 | 重排 | 最低(保守) |
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[freqmask-freqmix]] — 更激进的频域方法
|
||||||
|
- [[wavemask-wavemix]] — 时频域方法
|
||||||
|
- [[temporal-patch-shuffle]] — 时域 SOTA
|
||||||
45
concepts/dual-layer-rl.md
Normal file
45
concepts/dual-layer-rl.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Dual-Layer RL (双层强化学习)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["reinforcement-learning", "meta-learning", "skill", "optimization"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/s__fdyXQG932SavQeeugcw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dual-Layer RL (双层强化学习)
|
||||||
|
|
||||||
|
**Dual-Layer RL** 是吕明在 SkillOpt 深度解读中构想的元优化架构:将 SkillOpt 的优化过程纳入强化学习框架,构建 **内层 Agent RL + 外层 Optimizer RL** 的双层体系。
|
||||||
|
|
||||||
|
## 架构
|
||||||
|
|
||||||
|
| 层 | 主体 | 目标 | 动作 |
|
||||||
|
|:---|------|------|------|
|
||||||
|
| **内层** | Agent | 利用 Skill 更好执行任务 | 执行操作 |
|
||||||
|
| **外层** | Optimizer | 更好为 Agent 优化 Skill | 提出编辑 |
|
||||||
|
|
||||||
|
## 为什么可行
|
||||||
|
|
||||||
|
SkillOpt 天然适合 RL 框架:
|
||||||
|
- **奖励信号**:验证集分数(明确、可度量、自洽)
|
||||||
|
- **动作空间**:ADD/DELETE/REPLACE 编辑(离散、可控)
|
||||||
|
- **状态**:当前 Skill 文档 + Agent 执行反馈
|
||||||
|
- **验证**:[[held-out-validation-gate|Gate]] 提供天然的环境反馈
|
||||||
|
|
||||||
|
## 从"被动优化"到"Learning to Learn"
|
||||||
|
|
||||||
|
双层 RL 一旦形成:
|
||||||
|
> 内层:Agent 学习如何利用 Skill 文档更好地执行任务
|
||||||
|
> 外层:Optimizer 学习如何更好地为 Agent 优化 Skill 文档
|
||||||
|
>
|
||||||
|
> → 真正意义上的 **"Learning to Learn"**
|
||||||
|
|
||||||
|
## 与 EvolveR 的联系
|
||||||
|
|
||||||
|
EvolveR 已展示初步可行性:用 GRPO 训练 Agent"学会如何善用经验"。SkillOpt 的编辑决策和验证筛选机制可为过程性 RL 提供更精细的信号。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[skillopt]] — 双层 RL 的技术基础
|
||||||
|
- [[skill-data-flywheel]] — 双层 RL 的数据产出如何形成飞轮
|
||||||
|
- [[heuristic-learning]] — 元优化的更广义框架
|
||||||
65
concepts/dual-space-rl.md
Normal file
65
concepts/dual-space-rl.md
Normal file
@@ -0,0 +1,65 @@
|
|||||||
|
---
|
||||||
|
title: "Dual Space RL (DSRL)"
|
||||||
|
created: 2026-05-18
|
||||||
|
type: concept
|
||||||
|
tags: ["reinforcement-learning", "LLM", "policy-optimization", "GRPO"]
|
||||||
|
sources: ["https://arxiv.org/abs/2604.14142"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dual Space RL (DSRL)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
DSRL 是一个两阶段的 RL 框架,通过 [[policy-reincarnation|策略转生]] 策略将 [[pre-train-space-reinforcement-learning|PreRL]] 与标准 RL 统一起来:
|
||||||
|
|
||||||
|
1. **Phase 1 (s ≤ S)**: NSR-PreRL — 在预训练空间中剪枝错误推理路径,扩展推理视野
|
||||||
|
2. **Phase 2 (s > S)**: 标准 GRPO — 在 post-train 空间中进行细粒度策略优化
|
||||||
|
|
||||||
|
## 统一公式
|
||||||
|
|
||||||
|
```
|
||||||
|
∇J_DSRL = E[∑∇log π(y_t | x^{I[s>S]}, y_{<t}) · R(y) · I[s>S ∨ R(y)<0]]
|
||||||
|
```
|
||||||
|
|
||||||
|
- `x^{I[s>S]}`: Phase 1 时遮蔽 x(预训练空间),Phase 2 时恢复 x
|
||||||
|
- `I[s>S ∨ R(y)<0]`: Phase 1 仅对负样本更新(NSR),Phase 2 使用全部样本
|
||||||
|
|
||||||
|
## 关键结果
|
||||||
|
|
||||||
|
### Main Results (Avg@32)
|
||||||
|
|
||||||
|
| 模型 | Baseline | GRPO | DSRL |
|
||||||
|
|------|----------|------|------|
|
||||||
|
| Qwen3-4B | 41.26 | 55.79 | **57.54** |
|
||||||
|
| Qwen3-8B | 41.62 | 57.00 | **58.47** |
|
||||||
|
|
||||||
|
### 效率提升
|
||||||
|
- 达到 45% 精度:**2.5×** 更少步数
|
||||||
|
- 达到 58% 精度:**1.6×** 更少步数
|
||||||
|
|
||||||
|
### OOD 泛化
|
||||||
|
- GPQA-Diamond: +3.79 (4B), +2.52 (8B)
|
||||||
|
- MMLU-Pro: +5.37 (4B), +4.32 (8B)
|
||||||
|
- HumanEval: +2.44 (8B)
|
||||||
|
|
||||||
|
## Warmup 步数消融
|
||||||
|
|
||||||
|
最优区间:S ∈ [10, 25] 步。过少(激励不足)或过多(过度探索)均导致性能下降。
|
||||||
|
|
||||||
|
## 推理行为演化
|
||||||
|
|
||||||
|
NSR-PreRL 阶段激发多种推理模式:
|
||||||
|
- Subgoal Setting
|
||||||
|
- Enumeration
|
||||||
|
- Verification
|
||||||
|
- Backtracking
|
||||||
|
|
||||||
|
所有模式在 DSRL 中均达到更高的频率上限。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[pre-train-space-reinforcement-learning|PreRL]]
|
||||||
|
- [[post-train-space-rl|Post-train Space RL]]
|
||||||
|
- [[negative-sample-reinforcement|NSR]]
|
||||||
|
- [[policy-reincarnation|策略转生]]
|
||||||
|
- [[endogenous-reasoning|内生推理]]
|
||||||
42
concepts/endogenous-reasoning.md
Normal file
42
concepts/endogenous-reasoning.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Endogenous Reasoning(内生推理)"
|
||||||
|
created: 2026-05-18
|
||||||
|
type: concept
|
||||||
|
tags: ["reasoning", "LLM", "reinforcement-learning"]
|
||||||
|
sources: ["https://arxiv.org/abs/2604.14142"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Endogenous Reasoning(内生推理)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
内生推理指模型**自发性**产生的推理行为,而非通过外部监督信号或精心设计的 prompt 模板所诱导。NSR-PreRL 被证明能显著激发这种内生推理能力。
|
||||||
|
|
||||||
|
## NSR-PreRL 的激发效果
|
||||||
|
|
||||||
|
在仅 20 步 NSR-PreRL 训练后(Qwen3-4B, AMC23):
|
||||||
|
|
||||||
|
| 推理模式 | 增长倍数 |
|
||||||
|
|---------|---------|
|
||||||
|
| Transition thoughts | **14.89×** |
|
||||||
|
| Reflection thoughts | **6.54×** |
|
||||||
|
| Subgoal Setting | 大幅增长 |
|
||||||
|
| Enumeration | 大幅增长 |
|
||||||
|
| Verification | 大幅增长 |
|
||||||
|
| Backtracking | 大幅增长 |
|
||||||
|
|
||||||
|
## 与 GRPO 对比
|
||||||
|
|
||||||
|
标准 GRPO(25 步后)在激发内生推理方面明显弱于 NSR-PreRL(仅 20 步),说明:
|
||||||
|
- 内生推理的激发源于预训练空间的操作(移除条件约束后,模型可自由探索知识空间)
|
||||||
|
- Post-train space 的条件约束**抑制**了这种自发推理行为的涌现
|
||||||
|
|
||||||
|
## 机制假设
|
||||||
|
|
||||||
|
NSR-PreRL 通过剪枝错误推理路径,**间接解锁**了模型在预训练阶段已编码但被条件约束抑制的内部知识。这与"预训练知识内部化"的理念一致:模型参数中已经存在推理能力,PreRL 只是去除了阻碍其表达的"噪音路径"。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[negative-sample-reinforcement|NSR]]
|
||||||
|
- [[pre-train-space-reinforcement-learning|PreRL]]
|
||||||
|
- [[dual-space-rl|DSRL]]
|
||||||
40
concepts/etclovg-taxonomy.md
Normal file
40
concepts/etclovg-taxonomy.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "ETCLOVG 七层分类法"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, taxonomy, infrastructure, harness]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# ETCLOVG 七层分类法
|
||||||
|
|
||||||
|
> Agent Harness Engineering 的核心分类体系,将 Agent 基础设施拆分为七个独立且相互耦合的架构层。
|
||||||
|
|
||||||
|
## 七层结构
|
||||||
|
|
||||||
|
| 层 | 缩写 | 核心职责 |
|
||||||
|
|---|------|---------|
|
||||||
|
| Execution | E | Agent 代码在哪里运行、受什么沙箱约束 |
|
||||||
|
| Tooling | T | 外部能力如何描述、发现和调用 |
|
||||||
|
| Context | C | 模型能看到什么(短/中/长期视野) |
|
||||||
|
| Lifecycle | L | 控制流组织(单Agent→多Agent→全流水线) |
|
||||||
|
| Observability | O | 捕获追踪、成本、故障和可靠性信号 |
|
||||||
|
| Verification | V | 将任务和追踪转化为评估、失败归因和回归反馈 |
|
||||||
|
| Governance | G | 通过权限、身份、策略、加固、审计和人类监督约束行为 |
|
||||||
|
|
||||||
|
## 两个关键设计选择
|
||||||
|
|
||||||
|
1. **Observability(O)独立成层**:生产环境中可观测性有专属工具生态(Langfuse, Arize Phoenix, OpenLLMetry)和独立工程实践
|
||||||
|
2. **Governance(G)作为一等公民**:覆盖模型级(护栏)、系统级(网关、代理、权限模型)和组织级(审计、合规)三个子层
|
||||||
|
|
||||||
|
## 与之前框架的区别
|
||||||
|
|
||||||
|
此前的框架通常将 O 和 G 作为 Lifecycle Hook 的副作用,ETCLOVG 将其提升为独立架构关注点。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[agent-harness-engineering]] — 总体概念
|
||||||
|
- [[harness-coupling-problem]] — 七层之间的耦合关系
|
||||||
|
- [[agent-harness-engineering-survey]] — 论文主页面
|
||||||
35
concepts/evolving-knowledge-injection.md
Normal file
35
concepts/evolving-knowledge-injection.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "进化知识注入 (Evolving Knowledge Injection)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["continual-learning", "multimodal", "knowledge"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 进化知识注入 (Evolving Knowledge Injection)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
进化知识注入是指将现实世界中**持续更新的多模态知识**(新实体、新事件、新信息)高效注入到已训练好的大型多模态模型(LMM)中的任务。与传统的静态知识注入不同,进化知识具有**时序性**、**多模态性**和**持续涌现性**。
|
||||||
|
|
||||||
|
## 核心挑战
|
||||||
|
|
||||||
|
1. **知识适应 (Knowledge Adaptation)**:模型需要准确学习新知识并能在未见过的评估问题上泛化
|
||||||
|
2. **知识保留 (Knowledge Retention)**:注入新知识时不能破坏模型已有的通用能力
|
||||||
|
|
||||||
|
## 形式化定义
|
||||||
|
|
||||||
|
假设模型 M 可通过注入数据 D_K 优化为 M* = f(M, D_K),需满足:
|
||||||
|
- **知识适应**:最大化 M* 在新知识评估 D_Q 上的准确率
|
||||||
|
- **知识保留**:最小化 M* 与 M 在通用能力测试 D_P 上的性能差距
|
||||||
|
|
||||||
|
## 与持续学习的关系
|
||||||
|
|
||||||
|
进化知识注入可视为[[continual-learning|持续学习]]在多模态场景下的特例,但强调**真实世界知识演化**而非简单任务序列切换。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[mme-voke|MMEVOKE]] — 首个多模态进化知识注入基准
|
||||||
|
- [[knowledge-adaptation|知识适应]]
|
||||||
|
- [[knowledge-retention|知识保留]]
|
||||||
|
- [[capability-degradation|能力退化]]
|
||||||
38
concepts/execution-environment.md
Normal file
38
concepts/execution-environment.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Execution Environment(执行环境与沙箱)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, sandbox, infrastructure, execution, security]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Execution Environment & Sandbox(E 层)
|
||||||
|
|
||||||
|
> ETCLOVG 的 E 层:决定 Agent 代码在哪里运行、受什么沙箱约束。正在成为安全、可扩展性和可移植性交汇的控制边界。
|
||||||
|
|
||||||
|
## 主要子类别
|
||||||
|
|
||||||
|
- **通用托管沙箱**:如 Firecracker microVMs、Docker 容器、OpenSandbox
|
||||||
|
- **代码专用沙箱**:针对编程任务的隔离环境
|
||||||
|
- **浏览器评估环境**:WebArena、BrowserBench 等
|
||||||
|
- **OS 级权限沙箱**:Anthropic sandbox-runtime
|
||||||
|
- **计算机使用 Agent 基础设施**:桌面/浏览器自动化
|
||||||
|
- **框架集成运行时** vs **沙箱抽象层**:bundle-vs-compose 之争
|
||||||
|
|
||||||
|
## 核心挑战
|
||||||
|
|
||||||
|
- 沙箱逃逸:SandboxEscapeBench 发现前沿模型可突破沙箱(Marchand et al., 2026)
|
||||||
|
- 大规模并行训练/评估中的 one-container-per-task 模式成本过高
|
||||||
|
- Docker 假设 Linux 内核,跨平台可移植性未解决
|
||||||
|
|
||||||
|
## 开放问题
|
||||||
|
|
||||||
|
如何使运行时基质既**可测量**又**可组合**——安全评估统一化、成本模型选择、跨部署环境可移植性。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[etclovg-taxonomy]] — ETCLOVG 体系
|
||||||
|
- [[hardening-execution-environments]] — 硬化执行环境
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
55
concepts/forecasting-augmentation-taxonomy.md
Normal file
55
concepts/forecasting-augmentation-taxonomy.md
Normal file
@@ -0,0 +1,55 @@
|
|||||||
|
---
|
||||||
|
title: "Forecasting Augmentation Taxonomy"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["time-series", "data-augmentation", "forecasting", "taxonomy"]
|
||||||
|
sources: ["temporal-patch-shuffle-tps"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Forecasting Augmentation Taxonomy
|
||||||
|
|
||||||
|
> 时间序列预测增强方法的分类体系——频域、时频域、分解、Patch 四条路线。
|
||||||
|
|
||||||
|
## 完整分类
|
||||||
|
|
||||||
|
```
|
||||||
|
预测增强方法
|
||||||
|
├── 频域 (Frequency Domain)
|
||||||
|
│ ├── RobustTAD — DFT 幅度/相位扰动
|
||||||
|
│ ├── FreqMask — FFT mask 清零
|
||||||
|
│ ├── FreqMix — FFT 频谱混合
|
||||||
|
│ └── Dominant Shuffle — top-k 主导频率 shuffle
|
||||||
|
├── 时频域 (Time-Frequency)
|
||||||
|
│ ├── WaveMask — DWT mask
|
||||||
|
│ └── WaveMix — DWT 混合
|
||||||
|
├── 分解 (Decomposition)
|
||||||
|
│ ├── STAug — EMD + IMF mixup
|
||||||
|
│ ├── wDBA — DTW 对齐平均
|
||||||
|
│ └── MBB — STL + bootstrap
|
||||||
|
├── Patch (时域)
|
||||||
|
│ └── TPS — 重叠 patch + variance shuffle ⭐
|
||||||
|
└── 其他
|
||||||
|
└── Upsample — 线性插值拉伸
|
||||||
|
```
|
||||||
|
|
||||||
|
## 演化路径
|
||||||
|
|
||||||
|
频域方法(FreqMask/FreqMix)→ 时频域(WaveMask/WaveMix,加入时间定位)→ Patch 时域(TPS,直接操作原始信号)
|
||||||
|
|
||||||
|
**趋势**:从全局操作走向局部受控扰动,从频域走向时域。
|
||||||
|
|
||||||
|
## 关键维度对比
|
||||||
|
|
||||||
|
| 维度 | 频域 | 时频域 | 分解 | Patch |
|
||||||
|
|------|------|--------|------|-------|
|
||||||
|
| 时间定位 | ❌ | ✅ | ✅ | ✅ |
|
||||||
|
| 计算效率 | 高 | 中 | 低 | 高 |
|
||||||
|
| 时间结构保留 | 低 | 中 | 高 | 高 |
|
||||||
|
| 当前 SOTA | — | — | — | TPS |
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[temporal-patch-shuffle]] — 当前 SOTA
|
||||||
|
- [[freqmask-freqmix]] — 频域方法
|
||||||
|
- [[wavemask-wavemix]] — 时频域方法
|
||||||
|
- [[time-series-forecasting-augmentation]] — 领域框架
|
||||||
48
concepts/freqmask-freqmix.md
Normal file
48
concepts/freqmask-freqmix.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "FreqMask / FreqMix"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["time-series", "data-augmentation", "frequency-domain", "forecasting"]
|
||||||
|
sources: ["temporal-patch-shuffle-tps"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# FreqMask / FreqMix
|
||||||
|
|
||||||
|
> 基于 Fourier 变换的频率域时间序列增强方法——mask 或混合频谱分量。
|
||||||
|
|
||||||
|
## 共同流程
|
||||||
|
|
||||||
|
1. 拼接:s = x ∥ y
|
||||||
|
2. FFT:S = rFFT(s)
|
||||||
|
3. 操作频谱
|
||||||
|
4. IFFT:s̃ = irFFT(S̃)
|
||||||
|
5. 拆分:(x̃, ỹ) = Split(s̃)
|
||||||
|
|
||||||
|
## FreqMask
|
||||||
|
|
||||||
|
用二值 mask M 清零选定频率分量:
|
||||||
|
```
|
||||||
|
S̃ = M ⊙ S
|
||||||
|
```
|
||||||
|
**直觉**:抑制周期分量,迫使模型对频率缺失保持鲁棒。
|
||||||
|
|
||||||
|
## FreqMix
|
||||||
|
|
||||||
|
混合两个序列的频谱:
|
||||||
|
```
|
||||||
|
S̃ = M ⊙ S₁ + (1 − M) ⊙ S₂
|
||||||
|
```
|
||||||
|
**直觉**:让序列部分"继承"另一个序列的结构特征。
|
||||||
|
|
||||||
|
## 局限性
|
||||||
|
|
||||||
|
- **无时间定位**:FFT 告诉你"哪些频率存在",但不告诉你"出现在哪里"
|
||||||
|
- 丢失局部时间结构——这一点在 [[wavemask-wavemix|WaveMask/WaveMix]] 中被改善
|
||||||
|
- 在综合评测中性能弱于 [[temporal-patch-shuffle|TPS]]
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[wavemask-wavemix]] — 有时频定位的 wavelet 替代方案
|
||||||
|
- [[dominant-shuffle]] — 更保守的频域操作
|
||||||
|
- [[temporal-patch-shuffle]] — 时域 patch 方法的 SOTA
|
||||||
|
- [[fourier-filter-dynamics]] — Fourier 滤波理论
|
||||||
62
concepts/generative-general-unification.md
Normal file
62
concepts/generative-general-unification.md
Normal file
@@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
title: "Generative-General-Unification (GenAI 三支柱)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["genai", "paradigm", "comparison", "ai-history"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Generative-General-Unification (GenAI 三支柱)
|
||||||
|
|
||||||
|
**Generative-General-Unification** 是吕明提出的 GenAI 区别于前几次 AI 浪潮的三个本质判别要素。这三者并非独立,而是**相辅相成、层层递进**的关系。
|
||||||
|
|
||||||
|
## 三大支柱
|
||||||
|
|
||||||
|
### 1. 生成式(Generative)
|
||||||
|
|
||||||
|
> "生成意味着对模型内 Distribution of Reasoning Patterns 带来了更大的 Flexibility、Scalability、Modelability 边界"
|
||||||
|
|
||||||
|
- **输入侧**:Prompt/Context Engineering(早期启蒙)
|
||||||
|
- **输出侧**:CoT、结构化推理轨迹
|
||||||
|
- **模型外**:以 Token 为媒介的 Harness/Agent Frameworks 快速迭代
|
||||||
|
|
||||||
|
### 2. 通用性(General)
|
||||||
|
|
||||||
|
> "生成与通用相辅相成——生成打开边界,通用在 Scaling Law 下将真实世界压缩建模"
|
||||||
|
|
||||||
|
- Scaling Law 驱动:更多数据 → 更强的泛化
|
||||||
|
- 生成能力 + 通用泛化 = 结构性扩展和迁移的可能
|
||||||
|
- 为"策略与工程间的窗户纸"埋下伏笔
|
||||||
|
|
||||||
|
### 3. 统一性(Unification)
|
||||||
|
|
||||||
|
> "'策略算法'与'工程约束'的统一——那层待捅破的窗户纸"
|
||||||
|
|
||||||
|
- 形式化规则编译 + 策略空间 tokenlized 融合
|
||||||
|
- World Models 跨模态语义对齐
|
||||||
|
- Tools/Skills/Portals/CLI 纳入统一 tokenlized 编码
|
||||||
|
|
||||||
|
## 迭代关系
|
||||||
|
|
||||||
|
```
|
||||||
|
Generative ──→ General ──→ Unification
|
||||||
|
│ │ │
|
||||||
|
▼ ▼ ▼
|
||||||
|
打开推理 构建泛化 统一策略
|
||||||
|
模式边界 迁移能力 与工程约束
|
||||||
|
```
|
||||||
|
|
||||||
|
## 与历史 AI 浪潮的根本差异
|
||||||
|
|
||||||
|
| 浪潮 | 时期 | 瓶颈 |
|
||||||
|
|------|------|------|
|
||||||
|
| Expert Systems | 1980s-90s | 规则不可迁移 |
|
||||||
|
| Deep Learning | 2010s | 泛化难、集成非E2E |
|
||||||
|
| **GenAI** | 2020s | **三者统一 → 突破** |
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[strategy-engineering-unification]] — 统一性的具体体现
|
||||||
|
- [[model-harness-relationship]] — 三支柱的微观映射
|
||||||
|
- [[lyu-model-harness-evolution-2026]] — 原始文章
|
||||||
37
concepts/global-context-hash-tree.md
Normal file
37
concepts/global-context-hash-tree.md
Normal file
@@ -0,0 +1,37 @@
|
|||||||
|
---
|
||||||
|
title: "Global Context Hash Tree (全局上下文哈希树)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["distributed-systems", "hashing", "caching", "LLM"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/MUWV7eug14bktUMlqsxfQw"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Global Context Hash Tree (全局上下文哈希树)
|
||||||
|
|
||||||
|
**Global Context Hash Tree** 是 [[distributed-prompt-caching]] 中的核心标识机制:将 Prompt 按层级结构(Global → Project → Session → Message)组织成树,每层独立计算 SHA-256,组合成 128 字节的复合键作为会话的分布式唯一标识符(UID)。
|
||||||
|
|
||||||
|
## 结构
|
||||||
|
|
||||||
|
```
|
||||||
|
[Global Layer SHA] → [Project Layer SHA] → [Session Layer SHA] → [Current Turn SHA]
|
||||||
|
```
|
||||||
|
|
||||||
|
四层哈希组合成 128 字节的二进制复合键(Composite Key)。
|
||||||
|
|
||||||
|
## 设计优势
|
||||||
|
|
||||||
|
- **确定性**:相同的上下文产生相同的哈希,可重复定位
|
||||||
|
- **分层性**:符合 LLM Prompt 的自然组织方式
|
||||||
|
- **紧凑性**:128 字节即可标识任意大小的上下文
|
||||||
|
- **跨服务商兼容**:不依赖特定 LLM 提供商的缓存句柄格式
|
||||||
|
|
||||||
|
## 在路由中的作用
|
||||||
|
|
||||||
|
复合键作为 [[distributed-cache-routing|Redis 路由表]] 的主键,使任何节点都能通过本地哈希计算瞬间查询某前缀在各物理节点和服务商端的"热态"分布。
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[distributed-prompt-caching]] — 分布式缓存体系
|
||||||
|
- [[distributed-cache-routing]] — 基于哈希树的路由
|
||||||
|
- [[distributed-agent-cache-sync-2026]] — 原始文章
|
||||||
38
concepts/governance-security.md
Normal file
38
concepts/governance-security.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "Governance & Security(治理与安全)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, governance, security, compliance, audit, identity]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Governance & Security(G 层)
|
||||||
|
|
||||||
|
> ETCLOVG 的 G 层:通过权限、身份、策略、加固、审计和人类监督机制约束 Agent 行为。覆盖三个治理子层。
|
||||||
|
|
||||||
|
## 三个治理子层
|
||||||
|
|
||||||
|
1. **模型级(Model-Level)**:护栏(guardrails)、内容过滤器、constitutional AI
|
||||||
|
2. **系统级(System-Level)**:网关(gateways)、代理(proxies)、权限模型(permission models)
|
||||||
|
3. **组织级(Organizational-Level)**:审计(audit)、合规(compliance)、人机协同(human-in-the-loop)
|
||||||
|
|
||||||
|
## 关键组件
|
||||||
|
|
||||||
|
- **权限模型与身份管理**:Agent 身份、委托、权限清单
|
||||||
|
- **生命周期 Hook**:在关键决策点插入治理检查
|
||||||
|
- **组件加固**:沙箱逃逸防护、prompt injection 防御
|
||||||
|
- **声明式宪法**:如 Claude's Constitution(Anthropic, 2026a)
|
||||||
|
- **审计基础设施**:记录所有 Agent 操作以供审查
|
||||||
|
|
||||||
|
## 与 [[capability-control-tradeoff]] 的关系
|
||||||
|
|
||||||
|
G 层是 control 侧的集中体现。更强的工具和更宽松的沙箱每扩展一次能力,G 层就需要相应增强审计粒度、权限边界和恢复能力。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[etclovg-taxonomy]]
|
||||||
|
- [[capability-control-tradeoff]]
|
||||||
|
- [[standard-agent-handoffs]] — 交接中的责任转移
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
46
concepts/gradient-alignment.md
Normal file
46
concepts/gradient-alignment.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "Gradient Alignment (PreRL)"
|
||||||
|
created: 2026-05-18
|
||||||
|
type: concept
|
||||||
|
tags: ["reinforcement-learning", "optimization", "theory"]
|
||||||
|
sources: ["https://arxiv.org/abs/2604.14142"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Gradient Alignment(梯度对齐)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
PreRL 有效性的理论基础:log P(y) 和 log P(y|x) 的梯度方向在推理轨迹 y 上保持**非负内积**,确保优化边际分布自然改善条件分布。
|
||||||
|
|
||||||
|
## 形式化
|
||||||
|
|
||||||
|
设 θ' = θ + η · ∇log P_θ(y) · R(y) 为一步 PreRL 更新后的参数,一阶泰勒展开:
|
||||||
|
|
||||||
|
```
|
||||||
|
log P_θ'(y|x) ≈ log P_θ(y|x) + η · R(y) · ⟨∇log P_θ(y), ∇log P_θ(y|x)⟩ + O(η²)
|
||||||
|
```
|
||||||
|
|
||||||
|
当 R(y) > 0 且内积 ≥ 0 时,交叉梯度项非负,条件 log-probability **单调不减**。
|
||||||
|
|
||||||
|
## 实证验证(Qwen3-4B, AMC23, 400 rollouts)
|
||||||
|
|
||||||
|
| 指标 | 值 |
|
||||||
|
|------|-----|
|
||||||
|
| 梯度内积(均值) | +9.23 |
|
||||||
|
| 梯度内积(最大值) | +46.18 |
|
||||||
|
| 梯度内积(最小值) | +0.94 |
|
||||||
|
| **负内积比例** | **0%** |
|
||||||
|
| 余弦相似度(均值) | 0.44 |
|
||||||
|
| log-prob 差异(均值) | 0.16 |
|
||||||
|
|
||||||
|
## 条件分布对齐
|
||||||
|
|
||||||
|
- 高概率/确定性 token: log P(y|x) ≈ log P(y)(强对齐)
|
||||||
|
- 早期序列/高不确定性 token: 存在分歧
|
||||||
|
- 总体分布高度重叠(Figure 2c)
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[shared-parameter-influence|共享参数影响]] — 梯度对齐的前提
|
||||||
|
- [[pre-train-space-reinforcement-learning|PreRL]]
|
||||||
|
- [[dual-space-rl|DSRL]]
|
||||||
40
concepts/gram-generative-recursive-reasoning.md
Normal file
40
concepts/gram-generative-recursive-reasoning.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "GRAM(Generative Recursive reAsoning Models)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [reasoning, recursive, generative, latent-variable]
|
||||||
|
sources: [raw/papers/gram-generative-recursive-reasoning-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# GRAM (Generative Recursive reAsoning Models)
|
||||||
|
|
||||||
|
> 将递归潜在推理转化为概率性多轨迹计算:每个递归步采样条件转移(而非确定性更新),通过边缘化所有轨迹得到最终预测。
|
||||||
|
|
||||||
|
## 三大贡献
|
||||||
|
|
||||||
|
1. **潜在变量生成过程**:将递归推理形式化为 p(y|x)
|
||||||
|
2. **宽度推理扩展**:推理不仅通过递归深度扩展,还通过**并行轨迹采样数**扩展
|
||||||
|
3. **经验验证**:在结构化推理、多解恢复和无条件生成上超越确定性 baseline
|
||||||
|
|
||||||
|
## 架构核心
|
||||||
|
|
||||||
|
- **双层递归**:Inner loop (低层精炼) + Outer loop (supervision step 叠加)
|
||||||
|
- **随机引导**:高层更新产生确定性提议 u_t,加上随机项 eps_t -> h_t = u_t + eps_t
|
||||||
|
- **训练**:[[amortized-variational-inference]](CE + KL divergence)
|
||||||
|
|
||||||
|
## 与现有推理方向的对比
|
||||||
|
|
||||||
|
| 方法 | 扩展维度 | 表示空间 |
|
||||||
|
|------|---------|---------|
|
||||||
|
| Chain-of-Thought | Token 序列 | 显式文本 |
|
||||||
|
| Diffusion Reasoning | 扩散步数 | 连续状态 |
|
||||||
|
| **GRAM** | **递归深度 x 轨迹宽度** | **离散潜在空间** |
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[stochastic-latent-trajectory]] — 随机轨迹
|
||||||
|
- [[inference-time-scaling]] — 推理时扩展
|
||||||
|
- [[deep-and-wide-reasoning]] — Deep & Wide
|
||||||
|
- [[gram-generative-recursive-reasoning-paper|GRAM 论文]]
|
||||||
42
concepts/gui-tool-hybrid-action-space.md
Normal file
42
concepts/gui-tool-hybrid-action-space.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "GUI-Tool Hybrid Action Space"
|
||||||
|
created: 2026-05-31
|
||||||
|
type: concept
|
||||||
|
tags: [agents, gui, tool-calling, action-space]
|
||||||
|
---
|
||||||
|
|
||||||
|
# GUI-Tool 混合动作空间
|
||||||
|
|
||||||
|
**GUI-Tool Hybrid Action Space** 是指 Computer Use Agent 在执行任务时可以在两种不同粒度的动作之间选择的操作空间:
|
||||||
|
|
||||||
|
- **$A_{\text{GUI}}$**:原子级 GUI 操作(坐标点击、键盘输入、滚动等)
|
||||||
|
- **$A_{\text{Tool}}$**:高层结构化工具调用(API 操作文件、设置应用参数、执行命令等)
|
||||||
|
|
||||||
|
形式化定义:$A = A_{\text{GUI}} \cup A_{\text{Tool}}$
|
||||||
|
|
||||||
|
## 互补性
|
||||||
|
|
||||||
|
| 维度 | GUI 动作 | 工具调用 |
|
||||||
|
|------|---------|---------|
|
||||||
|
| **泛化能力** | 广泛(任何可见元素) | 受限(受工具覆盖范围约束) |
|
||||||
|
| **效率** | 低(多步完成简单操作) | 高(单次调用替代多次 GUI) |
|
||||||
|
| **可靠性** | 低(坐标依赖,易出错) | 高(确定性 API) |
|
||||||
|
| **灵活性** | 高(处理未定义场景) | 低(仅限 predefined APIs) |
|
||||||
|
|
||||||
|
## 核心困境
|
||||||
|
|
||||||
|
**直接暴露混合空间 ≠ 自动获得混合能力**。
|
||||||
|
|
||||||
|
[[toolcua-optimal-gui-tool-orchestration|ToolCUA]] 论文的实验表明,所有基线模型在混合动作空间下的表现**都下降**了:
|
||||||
|
- EvoCUA-32B: 52.6% → 40.5% (-12.1%)
|
||||||
|
- Claude-4.5-Sonnet: 61.9% → 48.4% (-13.5%)
|
||||||
|
- Qwen3VL-8B: 29.0% → 28.2% (-0.8%)
|
||||||
|
|
||||||
|
原因是模型缺乏 [[optimal-gui-tool-path-selection|最优路径选择]] 能力——模型不知道**何时切换到工具、何时保持 GUI**。
|
||||||
|
|
||||||
|
## 解决方案
|
||||||
|
|
||||||
|
[[toolcua-optimal-gui-tool-orchestration|ToolCUA]] 提出三阶段训练:
|
||||||
|
1. 合成 [[interleaved-gui-tool-trajectory-scaling|GUI-Tool 交错数据]]
|
||||||
|
2. [[tool-bootstrapped-rft|工具引导的强化微调]]
|
||||||
|
3. [[tool-efficient-path-reward|在线 Agentic RL]]
|
||||||
35
concepts/hardening-execution-environments.md
Normal file
35
concepts/hardening-execution-environments.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "Hardening Execution Environments(硬化执行环境)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, security, sandbox, execution, hardening]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: medium
|
||||||
|
---
|
||||||
|
|
||||||
|
# Hardening & Scaling Execution Environments
|
||||||
|
|
||||||
|
> 开放问题 1/5:使运行时基质既**可测量**又**可组合**。SandboxEscapeBench 显示前沿模型可突破沙箱,但防御工作仍碎片化。同时 one-container-per-task 模式的成本不可持续。
|
||||||
|
|
||||||
|
## 当前状态
|
||||||
|
|
||||||
|
- **安全**:SandboxEscapeBench(Marchand et al., 2026)记录真实沙箱逃逸,但跨系统防御缺乏统一威胁模型
|
||||||
|
- **规模**:SWE-World 探索 Docker-free 替代环境,但学到的转换保真度未解决
|
||||||
|
- **可移植性**:Docker 假设 Linux 内核,macOS/Windows/浏览器/桌面/混合云场景的隔离和可复现性不同
|
||||||
|
|
||||||
|
## 未来需求
|
||||||
|
|
||||||
|
1. **统一安全评估**:prompt injection、目标错位、组合放大
|
||||||
|
2. **成本模型**:决定何时使用容器、microVM、OS 级权限边界、完整 VM、浏览器环境或学到的替代品
|
||||||
|
3. **可移植性层**:跨自托管、云和混合部署保持语义
|
||||||
|
|
||||||
|
## Bundle vs Compose
|
||||||
|
|
||||||
|
框架集成运行时(§3.2.4)与沙箱抽象层(§3.2.7)的分裂应作为实证设计问题而非产品偏好来处理。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[execution-environment]]
|
||||||
|
- [[standard-agent-handoffs]] — MCP 能否降低组合成本取决于暴露足够的状态
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
50
concepts/harness-as-action-verifier.md
Normal file
50
concepts/harness-as-action-verifier.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
title: "Harness-as-Action-Verifier"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "verification", "code-synthesis", "LLM"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Harness-as-Action-Verifier
|
||||||
|
|
||||||
|
**Harness-as-Action-Verifier** 是 [[autoharness|AutoHarness]] 的核心 harness 模式:LLM 负责提出动作,代码 harness 负责验证其合法性——非法则让 LLM 重新提议。
|
||||||
|
|
||||||
|
## 工作流程
|
||||||
|
|
||||||
|
```
|
||||||
|
1. LLM 观察环境状态 → 提议动作
|
||||||
|
2. is_legal_action(obs, action) → 验证合法性
|
||||||
|
3. 合法 → 执行动作
|
||||||
|
非法 → 将 "illegal action" 警告注入 LLM prompt → 回到步骤 1
|
||||||
|
```
|
||||||
|
|
||||||
|
本质上是一个 **rejection sampler**,其中 acceptance condition (`is_legal_action()`) 是从环境 feedback 中学习的。
|
||||||
|
|
||||||
|
## 训练
|
||||||
|
|
||||||
|
- 10 个并行环境,每个 rollout 最多 1000 步
|
||||||
|
- 遇到非法动作即终止 rollout
|
||||||
|
- 最多采样 5 个失败步 → Critic 分析 → Refiner 生成改进代码
|
||||||
|
- Thompson sampling 引导搜索方向
|
||||||
|
- 平均 14.5 次迭代完成训练
|
||||||
|
|
||||||
|
## 成果
|
||||||
|
|
||||||
|
- 145 个 TextArena 游戏上 **100% 合法动作率**
|
||||||
|
- Gemini-2.5-Flash + Verifier 胜 Gemini-2.5-Pro(裸奔)
|
||||||
|
|
||||||
|
## 与 Action Filter 的区别
|
||||||
|
|
||||||
|
| 特性 | Verifier | Action Filter |
|
||||||
|
|------|----------|---------------|
|
||||||
|
| LLM 角色 | 策略制定者 | 排序者 |
|
||||||
|
| 动作生成 | LLM 自由提议 | 代码枚举合法动作 |
|
||||||
|
| 适用场景 | 动作空间大 | 动作空间可控 |
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[autoharness]] — 完整方法
|
||||||
|
- [[harness-as-policy]] — 更激进的替代方案
|
||||||
|
- [[action-applicability]] — 核心问题
|
||||||
54
concepts/harness-as-policy.md
Normal file
54
concepts/harness-as-policy.md
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
title: "Harness-as-Policy (Code as Policy)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "code-synthesis", "policy", "LLM"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Harness-as-Policy (Code as Policy)
|
||||||
|
|
||||||
|
**Harness-as-Policy** 是 [[autoharness|AutoHarness]] 的终极形态:LLM 自动生成的代码**直接决定行动**,推理时不调用任何 LLM。这是 [[code-as-harness]] 框架中约束最弱、最灵活、也最大胆的模式。
|
||||||
|
|
||||||
|
## 相比于其他模式的根本区别
|
||||||
|
|
||||||
|
| 模式 | 推理时 LLM 调用 | 代码角色 |
|
||||||
|
|------|:---:|------|
|
||||||
|
| [[harness-as-action-verifier|Verifier]] | ✅ | 合法性守卫 |
|
||||||
|
| Action Filter | ✅ | 候选生成器 |
|
||||||
|
| **Policy** | ❌ | **决策者** |
|
||||||
|
|
||||||
|
## 训练
|
||||||
|
|
||||||
|
- 修改 heuristic value 包含 reward:`H = 0` (illegal) / `H = 0.5 + 0.5r` (legal)
|
||||||
|
- 使用 Gemini-2.5-Flash,最多 256 次迭代
|
||||||
|
- 平均 89.4 次迭代,heuristc value 达 0.939
|
||||||
|
|
||||||
|
## 成果
|
||||||
|
|
||||||
|
在 16 个 TextArena 1P 游戏上:
|
||||||
|
|
||||||
|
| Agent | 平均 Reward | 测试成本 |
|
||||||
|
|-------|:---:|------|
|
||||||
|
| **Harness-as-Policy** (ours) | **0.870** | ~$0 |
|
||||||
|
| GPT-5.2-High | 0.844 | ~$640 |
|
||||||
|
| Gemini-2.5-Pro | 0.707 | moderate |
|
||||||
|
| GPT-5.2 | 0.635 | ~$640 |
|
||||||
|
|
||||||
|
## 核心优势
|
||||||
|
|
||||||
|
1. **零推理成本**:纯 Python 代码运行,不需要 GPU
|
||||||
|
2. **超越大模型**:小模型(Flash)训练出的 code policy 超过 GPT-5.2-High
|
||||||
|
3. **可部署性**:代码可直接在生产环境中运行
|
||||||
|
|
||||||
|
## 局限
|
||||||
|
|
||||||
|
- 2P 游戏需要对手建模 + MCTS,纯代码更难处理
|
||||||
|
- 当前需要为每个游戏单独训练
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[code-as-harness]] — 框架哲学
|
||||||
|
- [[autoharness]] — 完整方法
|
||||||
|
- [[lou-autoharness-2026]] — 原始论文
|
||||||
36
concepts/harness-coupling-problem.md
Normal file
36
concepts/harness-coupling-problem.md
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: "Harness Coupling Problem(Harness 耦合问题)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [agent, coupling, system-design, optimization]
|
||||||
|
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Harness Coupling Problem
|
||||||
|
|
||||||
|
> Harness 各层高度耦合,局部优化可能变得脆弱。一个在隔离环境中看起来有益的更改,与其他控制回路组合后可能降低整体表现。
|
||||||
|
|
||||||
|
## 耦合的四种表现
|
||||||
|
|
||||||
|
1. **执行环境 → 评估**:包可用性、重置语义、延迟和故障模式改变评估结果
|
||||||
|
2. **工具描述 → 模型行为**:工具 Schema 消耗 context budget 并塑造模型推理
|
||||||
|
3. **可观测性 → 治理**:追踪只有在相同粒度捕获身份和权限状态时才成为治理证据
|
||||||
|
4. **评估 → 编排**:评估设计通过奖励/惩罚某些恢复回路来反馈编排
|
||||||
|
|
||||||
|
## 闭环框架
|
||||||
|
|
||||||
|
在闭环控制框架下,对上下文策略、工具 Schema、验证器或恢复回路的每一次更改都在改变控制器 `C_H`,从而改变同一模型的测量行为(Bölük, 2026b)。
|
||||||
|
|
||||||
|
这意味着 Agent 分数无法纯粹归因于模型,而不指定周围的控制器。
|
||||||
|
|
||||||
|
## 工程含义
|
||||||
|
|
||||||
|
Harness 变更应作为**系统变更**来测试——不是 prompt、tool、memory、sandbox、verifier 或 monitor 的独立调优,而是作为一个整体 rollout 的组合效果。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[binding-constraint-thesis]]
|
||||||
|
- [[trace-native-evaluation]] — 需要跨层归因失败
|
||||||
|
- [[agent-harness-engineering-survey]]
|
||||||
49
concepts/harness-engineering.md
Normal file
49
concepts/harness-engineering.md
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: "Harness Engineering"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["agent", "engineering", "constraint", "LLM"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Harness Engineering
|
||||||
|
|
||||||
|
**Harness Engineering** 是随着 [[autoharness|AutoHarness]] 等工作而兴起的一门新兴工程实践学科:系统性地为 LLM Agent 构建约束层(harness),使其在结构化环境中产生可靠、合法的行为。
|
||||||
|
|
||||||
|
## 学科定位
|
||||||
|
|
||||||
|
传统 AI 工程关注 Model 的训练与部署。Harness Engineering 关注的则是 Model **外部**的结构:
|
||||||
|
- 合法性验证回路
|
||||||
|
- 反馈收集与聚合
|
||||||
|
- 代码自合成与迭代
|
||||||
|
- 约束的搜索与优化
|
||||||
|
|
||||||
|
## 核心实践
|
||||||
|
|
||||||
|
1. **约束即代码**:Harness 以可执行代码形式表达(可验证、可迭代)
|
||||||
|
2. **搜索驱动合成**:通过 [[thompson-sampling-code-search|Thompson 采样]] 在 harness 空间中搜索
|
||||||
|
3. **Refiner-Critic 环**:LLM 生成改进 → 环境反馈 → 迭代优化
|
||||||
|
4. **层级递进**:从 Verifier(轻约束)→ Filter → Policy(强约束)
|
||||||
|
|
||||||
|
## 与 Model Engineering 的分工
|
||||||
|
|
||||||
|
| 维度 | Model Engineering | Harness Engineering |
|
||||||
|
|------|-------------------|---------------------|
|
||||||
|
| 优化对象 | 神经网络参数 | 可执行代码 |
|
||||||
|
| 反馈来源 | 梯度信号 | 环境交互 |
|
||||||
|
| 可解释性 | 低 | 高(可读代码) |
|
||||||
|
| 部署成本 | 高昂 | 零(纯代码) |
|
||||||
|
|
||||||
|
## 未来方向
|
||||||
|
|
||||||
|
- 可复用 Harness 组件库
|
||||||
|
- 跨游戏的约束知识迁移
|
||||||
|
- 从"代码约束"扩展到"行为准则约束"
|
||||||
|
- 与 [[heuristic-learning|Heuristic Learning]] 融合
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[model-harness-relationship]] — Model-Harness 关系
|
||||||
|
- [[autoharness]] — 核心方法
|
||||||
|
- [[compiled-ai-paradigm]] — 编译型 AI
|
||||||
34
concepts/hars.md
Normal file
34
concepts/hars.md
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: "HARS(调和适应保留评分)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["evaluation-metric", "knowledge-injection", "continual-learning"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# HARS(调和适应保留评分)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
HARS(Harmonized Adaptation-Retention Score)是 [[kore-knowledge-injection|KORE]] 提出的**统一评估指标**,将[[knowledge-adaptation|知识适应]]和[[knowledge-retention|知识保留]]整合为单一调和分数,类似 F1 平衡 Precision 和 Recall。
|
||||||
|
|
||||||
|
## 公式
|
||||||
|
|
||||||
|
HARS = 2 · (f_A · f_R) / (f_A + f_R)
|
||||||
|
|
||||||
|
其中:
|
||||||
|
- f_A = G_A / (G_A + 100) × 100:归一化适应分数
|
||||||
|
- f_R = G_R + 100:归一化保留分数
|
||||||
|
- G_A = (K.A - K.A_0) / K.A_0:适应相对增益
|
||||||
|
- G_R = (K.R - K.R_0) / K.R_0:保留相对增益
|
||||||
|
- K.A_0, K.R_0:预训练模型的基准表现
|
||||||
|
|
||||||
|
## 意义
|
||||||
|
|
||||||
|
知识注入方法常面临"适应-保留"权衡——提升一方面往往以牺牲另一方面为代价。HARS 提供了一个**单一数值**来衡量方法的整体平衡性,而非分散在多个指标中难以比较。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-adaptation|知识适应]]
|
||||||
|
- [[knowledge-retention|知识保留]]
|
||||||
|
- [[kore-knowledge-injection|KORE]]
|
||||||
42
concepts/held-out-validation-gate.md
Normal file
42
concepts/held-out-validation-gate.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Held-Out Validation Gate (留出验证门)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["optimization", "validation", "skill", "gate"]
|
||||||
|
sources: ["https://arxiv.org/abs/2605.23904"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Held-Out Validation Gate (留出验证门)
|
||||||
|
|
||||||
|
**Held-Out Validation Gate** 是 [[skillopt|SkillOpt]] 中的关键安全机制:每个候选 skill 编辑必须在留出的验证集上通过评估,只有在严格改善时才被接受。它是深度学习中 validation-based model selection 在文本空间的对应。
|
||||||
|
|
||||||
|
## 工作流程
|
||||||
|
|
||||||
|
```
|
||||||
|
Candidate Skill → 在 D_sel 上评估 →
|
||||||
|
改善?→ Accept → 可能成为 best_skill.md
|
||||||
|
未改善?→ [[rejected-edit-buffer|Reject → buffer]]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 为什么至关重要
|
||||||
|
|
||||||
|
LLM 可以生成"看起来合理"的编辑,但实际上会降低目标模型的表现。Validation gate 将**反思**(reflection)转变为**提出-验证型优化**(propose-and-test),而非无条件地自编辑。
|
||||||
|
|
||||||
|
## 双重判断
|
||||||
|
|
||||||
|
- **Improvement over current**: 候选 skill 是否比当前 skill 更好?
|
||||||
|
- **All-time best**: 是否超过历史最佳?→ 更新 `best_skill.md`
|
||||||
|
|
||||||
|
## 与深度学习的类比
|
||||||
|
|
||||||
|
```
|
||||||
|
深度学习: 在 val set 上选最佳 checkpoint
|
||||||
|
SkillOpt: 在 D_sel 上 gate 每个 skill edit
|
||||||
|
```
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[text-space-optimizer]] — 文本空间优化范式
|
||||||
|
- [[skillopt]] — 使用 validation gate 的方法
|
||||||
|
- [[rejected-edit-buffer]] — 被 gate 拒绝的编辑的去向
|
||||||
54
concepts/heuristic-learning.md
Normal file
54
concepts/heuristic-learning.md
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
title: "Heuristic Learning (启发式学习)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["learning-paradigm", "code-evolution", "agent", "optimization"]
|
||||||
|
sources: ["https://mp.weixin.qq.com/s/PglkqhlSoI7LEOb3AOHl8g"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Heuristic Learning (启发式学习)
|
||||||
|
|
||||||
|
**Heuristic Learning (HL)** 是由 OpenAI 翁家翌提出的一种新学习范式:**替代传统梯度下降优化模型参数的学习模式**,将优化主体从 Model 参数扩展到 Agent 整体(Model + Harness 代码)。
|
||||||
|
|
||||||
|
## 核心循环
|
||||||
|
|
||||||
|
```
|
||||||
|
Agent 运行 → 产生反馈 → 分析并修改代码 → 再次运行
|
||||||
|
```
|
||||||
|
|
||||||
|
与传统梯度下降的对比:
|
||||||
|
|
||||||
|
| 维度 | 梯度下降 (GD) | 启发式学习 (HL) |
|
||||||
|
|------|:---:|:---:|
|
||||||
|
| 优化对象 | 神经网络参数 θ | Agent 整体代码 |
|
||||||
|
| 反馈信号 | ∂L/∂θ | 环境交互 + 结构化反馈 |
|
||||||
|
| 优化器 | Adam/AdamW | LLM (作为 gradient-free optimizer) |
|
||||||
|
| 可解释性 | 无(矩阵乘法) | 高(可读代码) |
|
||||||
|
|
||||||
|
## 三大优势
|
||||||
|
|
||||||
|
### 1. 缓解灾难性遗忘
|
||||||
|
旧能力被封装在回归测试中,新代码必须通过旧测试才能部署——从工程上规避了参数被覆盖。
|
||||||
|
|
||||||
|
### 2. 可解释性 AI
|
||||||
|
决策逻辑是一行行可读的代码,而非矩阵权重。为 AI 决策提供完整审计追踪。
|
||||||
|
|
||||||
|
### 3. 样本效率
|
||||||
|
借助 LLM 的先验知识和代码理解能力,迭代更快。Atari 57 中位表现已与 PPO 持平,且环境交互步数更少。
|
||||||
|
|
||||||
|
## 与 AutoHarness 的关系
|
||||||
|
|
||||||
|
两者理念如出一辙,但定位不同:
|
||||||
|
- **AutoHarness**:聚焦特定任务(游戏)的约束代码合成
|
||||||
|
- **Heuristic Learning**:定位为**通用学习范式**,替代梯度下降
|
||||||
|
|
||||||
|
## 核心意义
|
||||||
|
|
||||||
|
HL 将 [[harness-engineering|Harness Engineering]] 提升到了学习范式的高度:**经验或知识不仅可以被"训练"到参数里,还可以被"编程"为可维护、可进化的软件系统。**
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[autoharness]] — DeepMind 的实践先例
|
||||||
|
- [[harness-engineering]] — 支撑 HL 的工程学科
|
||||||
|
- [[model-harness-relationship]] — HL 隐含的架构哲学
|
||||||
43
concepts/inference-primitives.md
Normal file
43
concepts/inference-primitives.md
Normal file
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: "Inference Primitives (推理原语)"
|
||||||
|
created: 2026-05-26
|
||||||
|
type: concept
|
||||||
|
tags: ["bayesian-inference", "taxonomy", "transformers", "architecture"]
|
||||||
|
sources: ["agarwal-bayesian-attention-geometry"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Inference Primitives
|
||||||
|
|
||||||
|
> 贝叶斯序列推理可分解为三个原子操作——累积、传输、绑定——不同架构可实现不同子集。
|
||||||
|
|
||||||
|
## 三个原语
|
||||||
|
|
||||||
|
### 1. [[belief-accumulation|Belief Accumulation]](信念累积)
|
||||||
|
将证据逐步整合为 running posterior:\( P(\theta \mid x_{1:t}) \) 随观测更新。
|
||||||
|
|
||||||
|
### 2. [[belief-transport|Belief Transport]](信念传输)
|
||||||
|
信念在随机动态下传播——隐藏状态演化时的滤波(如 HMM 的前向算法)。
|
||||||
|
|
||||||
|
### 3. [[random-access-binding|Random-Access Binding]](随机访问绑定)
|
||||||
|
按内容而非位置检索已存储的假设——如给定探测线索回忆目标。
|
||||||
|
|
||||||
|
## 架构可实现性矩阵
|
||||||
|
|
||||||
|
| 架构 | 累积 | 传输 | 绑定 | 推理能力 |
|
||||||
|
|------|:---:|:---:|:---:|---------|
|
||||||
|
| Transformer | ✅ | ✅ | ✅ | 完整 |
|
||||||
|
| Mamba (SSM) | ✅ | ✅ | ❌ | 滤波 SOTA,绑定失能 |
|
||||||
|
| LSTM | ✅ | ❌ | ❌ | 仅静态充分统计量 |
|
||||||
|
| MLP | ❌ | ❌ | ❌ | 无 |
|
||||||
|
|
||||||
|
## 结构性洞察
|
||||||
|
|
||||||
|
**[[primitive-completeness|原语完备性]]**:Transformer 是**实现全部三原语的最小架构**。其在推理任务中的主导地位不是来自规模,而是来自架构层面对全套推理操作的支持。
|
||||||
|
|
||||||
|
> Neural sequence architectures differ not in whether they can approximate Bayesian inference, but in which primitives they can realize.
|
||||||
|
|
||||||
|
## 相关页面
|
||||||
|
|
||||||
|
- [[bayesian-wind-tunnels]] — 验证原语理论的实验环境
|
||||||
|
- [[primitive-completeness]] — 原语完备性的深入分析
|
||||||
|
- [[bayesian-attention-geometry]] — 原语在注意力头中的几何实现
|
||||||
39
concepts/inference-time-scaling.md
Normal file
39
concepts/inference-time-scaling.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Inference-Time Scaling(推理时扩展)"
|
||||||
|
created: 2026-05-23
|
||||||
|
updated: 2026-05-23
|
||||||
|
type: concept
|
||||||
|
tags: [inference, scaling, reasoning, compute]
|
||||||
|
sources: [raw/papers/gram-generative-recursive-reasoning-2026.md]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Inference-Time Scaling
|
||||||
|
|
||||||
|
> GRAM 提出的双维度推理扩展:不仅通过**递归深度**(deeper),还通过**并行轨迹采样数**(wider)来提升推理质量。
|
||||||
|
|
||||||
|
## 两种扩展维度
|
||||||
|
|
||||||
|
| 维度 | 方式 | 效果 |
|
||||||
|
|------|------|------|
|
||||||
|
| **深度** (Deep) | 增加递归步数 T | 更多精炼迭代 |
|
||||||
|
| **宽度** (Wide) | 并行采样更多轨迹 | 更好的边际化估计、多解发现 |
|
||||||
|
|
||||||
|
## 与传统扩展方式的区别
|
||||||
|
|
||||||
|
- **Chain-of-Thought**: 只能 depth(更长 token 序列)
|
||||||
|
- **Ensemble**: 只能 width(多个独立模型)
|
||||||
|
- **GRAM**: **depth x width**(单一模型的递归深度 x 轨迹数)
|
||||||
|
|
||||||
|
## 关键洞察
|
||||||
|
|
||||||
|
深度和宽度的边际收益不同:
|
||||||
|
- 深度对单解精炼最有效
|
||||||
|
- 宽度对多解覆盖和不确定性处理最有效
|
||||||
|
- 最优配置 = 任务依赖的资源分配
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[width-based-scaling]]
|
||||||
|
- [[deep-and-wide-reasoning]]
|
||||||
|
- [[gram-generative-recursive-reasoning|GRAM]]
|
||||||
42
concepts/input-superposition.md
Normal file
42
concepts/input-superposition.md
Normal file
@@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "Input Superposition"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["pre-training", "embedding", "tokenization"]
|
||||||
|
sources: ["https://arxiv.org/abs/2605.06546"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Input Superposition
|
||||||
|
|
||||||
|
**Input Superposition** 是 [[token-superposition-training|TST]] 中输入侧的操作:将连续 s 个 token 的 embedding 取平均,形成单个 latent "s-token"。由 Peng, Gigant & Quesnelle (2026) 在 TST 中系统研究。
|
||||||
|
|
||||||
|
## 操作
|
||||||
|
|
||||||
|
设 token 序列为 $t_1, t_2, \dots, t_L$,bag size = s:
|
||||||
|
1. 分组:$\{t_1, \dots, t_s\}, \{t_{s+1}, \dots, t_{2s}\}, \dots$
|
||||||
|
2. 对每个 bag,计算平均 embedding:$e'_j = \frac{1}{s} \sum_{k=1}^s e(t_{(j-1)s+k})$
|
||||||
|
3. LLM 在缩短 s× 的序列上运算
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
- 序列长度 L → L/s,每个训练 step 的 FLOPs **不变**(因为 s-token 序列更短但每个 s-token 的表示维度不变)
|
||||||
|
- **等 FLOPs** 下吞入 s× 更多数据 token
|
||||||
|
|
||||||
|
## 增益来源(开放问题)
|
||||||
|
|
||||||
|
论文提出了两种解释:
|
||||||
|
1. **预-预训练假说**:粗粒度 token 保留了文本的局部统计结构(topic, co-occurrence),模型先学习这些粗结构
|
||||||
|
2. **Embedding 正则化假说**:在 embedding 空间中对随机 s-gram 取平均,隐式正则化了 embedding 几何
|
||||||
|
|
||||||
|
## 跨模态关联
|
||||||
|
|
||||||
|
Input superposition 体现的 **粗→细粒度调度**([[coarse-to-fine-granularity]])原则在多模态中也有先例:
|
||||||
|
- ViT 中 patch size 从粗到细的调度(Anagnostidis et al.)
|
||||||
|
- Byte-level → subword 的恢复训练(Minixhofer et al.)
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[token-superposition-training]] — 完整方法
|
||||||
|
- [[multi-hot-cross-entropy]] — 输出侧配合的损失函数
|
||||||
|
- [[coarse-to-fine-granularity]] — 底层设计原则
|
||||||
45
concepts/interleaved-gui-tool-trajectory-scaling.md
Normal file
45
concepts/interleaved-gui-tool-trajectory-scaling.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: "Interleaved GUI-Tool Trajectory Scaling Pipeline"
|
||||||
|
created: 2026-05-31
|
||||||
|
type: concept
|
||||||
|
tags: [data-synthesis, gui-tool, trajectory-scaling, tool-synthesis]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Interleaved GUI-Tool Trajectory Scaling Pipeline
|
||||||
|
|
||||||
|
**Interleaved GUI-Tool Trajectory Scaling Pipeline** 是 [[toolcua-optimal-gui-tool-orchestration|ToolCUA]] 论文提出的数据扩展流水线,用于从**已有的纯 GUI 轨迹语料库**合成**大规模 GUI-Tool 交错轨迹数据**。
|
||||||
|
|
||||||
|
## 核心思想
|
||||||
|
|
||||||
|
> Repurpose(重利用)现有纯 GUI 轨迹 + MLLM 合成工具库 → 无需人工标注即可大规模生成 GUI-Tool 交错数据
|
||||||
|
|
||||||
|
## 四步流程
|
||||||
|
|
||||||
|
### 1. Trajectory Filtering & Balancing
|
||||||
|
- 从开放数据集按执行质量、任务长度、应用覆盖筛选
|
||||||
|
- 跨领域平衡分布,提供稳定的合成源
|
||||||
|
|
||||||
|
### 2. Trajectory-Aware Synthetic Tool Library Construction
|
||||||
|
- **MLLM**(如 Kimi-K2.5、Claude-4.5-Sonnet)分析每条 GUI 轨迹
|
||||||
|
- 从观察到的 GUI 过程**抽象出可调用的高层操作**
|
||||||
|
- 每个工具包含:函数签名、自然语言描述、参数语义
|
||||||
|
- 支持多粒度:从单步包装(`chrome_open_settings`)到多步组合(`chrome_open_language_settings`)
|
||||||
|
|
||||||
|
### 3. Tool Trajectory Generation with Next-State Grounding
|
||||||
|
- 用合成工具库生成等效的"纯工具"轨迹
|
||||||
|
- **[[next-state-grounding|Next-State Grounding]]**:将工具步骤锚定到原始 GUI 轨迹的对应截图上,验证执行效果一致性
|
||||||
|
- **Bottom-up Merging**:将相邻细粒度步骤逐步合并为更高层的复合工具调用
|
||||||
|
|
||||||
|
### 4. Interleaved GUI-Tool Trajectory Generation
|
||||||
|
- 随机选取部分工具调用,替换为原始 GUI 操作序列
|
||||||
|
- 同时从工具库中移除被替换的工具 → 构建"部分工具可用"的上下文
|
||||||
|
- 生成多样化的交错变体($\mathcal{D}_{\text{all}}$)
|
||||||
|
- 每次替换自然暴露两类切换边界($\mathcal{D}_{\text{critical}}$):GUI→Tool 和 Tool→GUI
|
||||||
|
|
||||||
|
## 三维扩展
|
||||||
|
|
||||||
|
| 维度 | 扩展内容 |
|
||||||
|
|------|---------|
|
||||||
|
| **Tool Functionality** | 跨应用域的工具功能覆盖 |
|
||||||
|
| **Tool Granularity** | 从原子工具到复合技能 |
|
||||||
|
| **Switching Context** | 覆盖工具更有益/更无益的场景 |
|
||||||
48
concepts/iterative-code-refinement.md
Normal file
48
concepts/iterative-code-refinement.md
Normal file
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: "Iterative Code Refinement (迭代代码精炼)"
|
||||||
|
created: 2026-05-29
|
||||||
|
updated: 2026-05-29
|
||||||
|
type: concept
|
||||||
|
tags: ["code-synthesis", "optimization", "LLM", "feedback-loop"]
|
||||||
|
sources: ["https://arxiv.org/abs/2603.03329"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Iterative Code Refinement (迭代代码精炼)
|
||||||
|
|
||||||
|
**Iterative Code Refinement** 是 [[autoharness|AutoHarness]] 的核心优化循环:LLM 作为 gradient-free code optimizer,基于环境反馈反复改进代码 harness。
|
||||||
|
|
||||||
|
## 循环结构
|
||||||
|
|
||||||
|
```
|
||||||
|
Old Code → Refiner (LLM) → New Code → Evaluator (Environment) → Critic → Refiner → ...
|
||||||
|
```
|
||||||
|
|
||||||
|
### Refiner
|
||||||
|
- 接收:当前代码 + 失败案例 + 错误信息
|
||||||
|
- 输出:改进后的代码
|
||||||
|
- 角色:**gradient-free optimizer**——不需要梯度,通过语言理解来"调试"代码
|
||||||
|
|
||||||
|
### Critic
|
||||||
|
- 接收:环境 rollout 结果
|
||||||
|
- 输出:结构化反馈(哪些动作非法、为什么、环境 reward)
|
||||||
|
- 角色:给 Refiner 提供"优化方向"
|
||||||
|
|
||||||
|
## 精炼策略
|
||||||
|
|
||||||
|
- `is_legal_action()` 返回 True 但动作无效 → 同时精炼 `propose_action()` 和 `is_legal_action()`
|
||||||
|
- `is_legal_action()` 返回 False 且动作无效 → 仅精炼 `propose_action()`
|
||||||
|
|
||||||
|
## 与标准 LLM 代码生成的对比
|
||||||
|
|
||||||
|
| 特性 | 标准生成 | Iterative Refinement |
|
||||||
|
|------|----------|---------------------|
|
||||||
|
| 尝试次数 | 1 次 | 多轮 |
|
||||||
|
| 反馈 | 无 | 环境反馈 |
|
||||||
|
| 搜索 | 无 | Thompson sampling 引导 |
|
||||||
|
| 成功率 | 依赖 prompt | 可达 100% |
|
||||||
|
|
||||||
|
## 相关
|
||||||
|
|
||||||
|
- [[autoharness]] — 使用此精炼的方法
|
||||||
|
- [[thompson-sampling-code-search]] — 选择精炼目标的搜索
|
||||||
|
- [[lou-autoharness-2026]] — 原始论文
|
||||||
41
concepts/knowledge-adaptation.md
Normal file
41
concepts/knowledge-adaptation.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "知识适应 (Knowledge Adaptation)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["continual-learning", "knowledge-injection"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识适应 (Knowledge Adaptation)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识适应是[[evolving-knowledge-injection|进化知识注入]]的首要目标,指 LMM 在接触新知识后,能在**未见过的评估问题**上准确泛化。
|
||||||
|
|
||||||
|
## 形式化
|
||||||
|
|
||||||
|
max E [ I(M*(i_q, x_q) = y_q) - I(M(i_q, x_q) = y_q) ]
|
||||||
|
|
||||||
|
即最大化注入后模型 M* 相对原始模型 M 在评估数据 D_Q 上的准确率增益。
|
||||||
|
|
||||||
|
## MMEVOKE 上的适应表现
|
||||||
|
|
||||||
|
| 方法 | LLaVA-v1.5 CEM | Qwen-VL-Chat CEM |
|
||||||
|
|------|---------------|-----------------|
|
||||||
|
| Vanilla(零样本) | 4.89% | 5.84% |
|
||||||
|
| Full-FT | 18.02% | 10.16% |
|
||||||
|
| LoRA | 15.23% | 6.95% |
|
||||||
|
| MM-RAG UniIR | 40.68% | 32.75% |
|
||||||
|
| Sufficient Context | 56.78% | 49.98% |
|
||||||
|
|
||||||
|
## 关键发现
|
||||||
|
|
||||||
|
1. **所有方法表现不佳**——即使最佳方法(Sufficient Context)也仅达 56.78%
|
||||||
|
2. **知识感知增强**可进一步提升适应能力
|
||||||
|
3. **知识适应 ≠ 数据记忆**——模型需要"内化"知识而非"背诵"数据
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-retention|知识保留]]
|
||||||
|
- [[knowledge-aware-augmentation|知识感知增强]]
|
||||||
|
- [[sufficient-context-paradox|充分上下文悖论]]
|
||||||
33
concepts/knowledge-agnostic-augmentation.md
Normal file
33
concepts/knowledge-agnostic-augmentation.md
Normal file
@@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "知识无关增强 (Knowledge-Agnostic Augmentation)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["data-augmentation", "knowledge-injection"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识无关增强 (Knowledge-Agnostic Augmentation)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识无关增强是一种**规则驱动的机械式数据增强**,仅操作表面特征而不引入语义级新信息。
|
||||||
|
|
||||||
|
## 示例
|
||||||
|
|
||||||
|
- **文本**:将描述中的 "created" 替换为 "built"(同义词替换)
|
||||||
|
- **图像**:对 "Xiaomi SU7" 图像进行旋转操作(纯几何变换)
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
在 MMEVOKE 基准上,知识无关增强产生**负面效果**:
|
||||||
|
- 文本:-5.66% CEM,-7.78% F1
|
||||||
|
- 图像:-47.36% CEM,-12.76% F1
|
||||||
|
|
||||||
|
## 启示
|
||||||
|
|
||||||
|
表面操作无法增加语义知识——模型需要的不是"更多数据",而是**更深的理解**。这一发现对传统数据增强策略在知识注入场景中的适用性提出了根本性质疑。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-aware-augmentation|知识感知增强]]
|
||||||
|
- [[data-augmentation|数据增强]]
|
||||||
44
concepts/knowledge-aware-augmentation.md
Normal file
44
concepts/knowledge-aware-augmentation.md
Normal file
@@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: "知识感知增强 (Knowledge-Aware Augmentation)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["data-augmentation", "knowledge-injection", "multimodal"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识感知增强 (Knowledge-Aware Augmentation)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识感知增强是一种**知识驱动的语义级数据增强**策略,通过对知识的深层理解进行创造性改写和补充,而非机械的表面变换。
|
||||||
|
|
||||||
|
## 与数据增强的核心区别
|
||||||
|
|
||||||
|
| 维度 | [[knowledge-agnostic-augmentation|知识无关增强]] | 知识感知增强 |
|
||||||
|
|------|------------|------------|
|
||||||
|
| 驱动方式 | 规则驱动 | 知识驱动 |
|
||||||
|
| 文本增强 | 同义词替换 | 基于理解的创造性改写 |
|
||||||
|
| 图像增强 | 旋转/裁剪/颜色变换 | 引入真实世界多角度图像 |
|
||||||
|
| 语义增益 | 无 | 丰富概念感知 |
|
||||||
|
| 效果 | **负面**(-5.66% CEM) | **正面**(+11.32% CEM) |
|
||||||
|
|
||||||
|
## 效果
|
||||||
|
|
||||||
|
在 MMEVOKE 基准上,仅使用**单个数据实例**的知识感知增强:
|
||||||
|
- 文本增强:+11.32% CEM,+39.82% F1
|
||||||
|
- 视觉增强:+43.28% CEM,+13.19% F1
|
||||||
|
- 性能随数据量增加进一步提升
|
||||||
|
|
||||||
|
## 意外发现
|
||||||
|
|
||||||
|
知识感知增强不仅能提升知识适应,还能**部分缓解能力退化**——在 MMBench、SEEDBench2 Plus、ScienceQA 上超过标准 Full-FT 和 LoRA,甚至超过专门的保留技术(EWC、LwF)。
|
||||||
|
|
||||||
|
## 本质
|
||||||
|
|
||||||
|
体现了"数据记忆"与"知识内化"的根本区别——前者仅能拟合训练数据,后者却能提取和操控事实知识。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-agnostic-augmentation|知识无关增强]]
|
||||||
|
- [[knowledge-injection|知识注入]]
|
||||||
|
- [[capability-degradation|能力退化]]
|
||||||
23
concepts/knowledge-internalization.md
Normal file
23
concepts/knowledge-internalization.md
Normal file
@@ -0,0 +1,23 @@
|
|||||||
|
---
|
||||||
|
title: "知识内化 (Knowledge Internalization)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["knowledge-injection", "learning-theory"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识内化 (Knowledge Internalization)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识内化是指模型不仅仅是"背诵"训练数据(数据记忆),而是真正理解知识的内在逻辑和关联,能够在推理时灵活提取和操控学到的知识。
|
||||||
|
|
||||||
|
## 与数据记忆的区别
|
||||||
|
|
||||||
|
- **数据记忆**:模型仅能准确拟合训练数据,但无法泛化
|
||||||
|
- **知识内化**:模型理解知识本质,能灵活用于新场景
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[kore-augmentation|KORE-AUGMENTATION]]
|
||||||
|
- [[knowledge-tree|知识树]]
|
||||||
41
concepts/knowledge-retention.md
Normal file
41
concepts/knowledge-retention.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "知识保留 (Knowledge Retention)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["continual-learning", "catastrophic-forgetting"]
|
||||||
|
sources: ["[[when-large-multimodal-models-confront-evolving-knowledge]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识保留 (Knowledge Retention)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识保留是[[evolving-knowledge-injection|进化知识注入]]中的关键目标之一,指在注入新知识后**保持模型已有通用能力不退化**。
|
||||||
|
|
||||||
|
## 方法谱系
|
||||||
|
|
||||||
|
### 有效方法
|
||||||
|
|
||||||
|
- [[data-replay|数据回放(Replay)]]:直接排练——混合旧数据训练,排名第 1(LoRA)和第 3(Full-FT)
|
||||||
|
- [[moe-lora|MoELoRA]]:结构隔离——为新知识划出专用参数区,排名第 2
|
||||||
|
|
||||||
|
### 无效方法
|
||||||
|
|
||||||
|
- **EWC**(Elastic Weight Consolidation):通过正则化约束重要参数不变——排名第 5,几乎无缓解
|
||||||
|
- **LwF**(Learning without Forgetting):通过知识蒸馏保留旧模型输出——排名第 6,甚至加剧退化
|
||||||
|
|
||||||
|
## 核心洞察
|
||||||
|
|
||||||
|
**直接排练 > 结构隔离 > 间接约束**
|
||||||
|
|
||||||
|
EWC 和 LwF 的失败说明:试图通过"冻结"参数来保留能力的策略在多模态进化知识注入场景下基本无效——新知识与旧知识的交互远复杂于简单的参数权重保护。
|
||||||
|
|
||||||
|
## 与知识增强的协同
|
||||||
|
|
||||||
|
一个意外发现是[[knowledge-aware-augmentation|知识感知增强]]本身也能部分缓解能力退化,这暗示了**主动学习**与**能力保留**之间存在协同效应。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[capability-degradation|能力退化]]
|
||||||
|
- [[knowledge-adaptation|知识适应]]
|
||||||
|
- [[catastrophic-forgetting|灾难性遗忘]]
|
||||||
47
concepts/knowledge-tree.md
Normal file
47
concepts/knowledge-tree.md
Normal file
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: "知识树 (Knowledge Tree)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["knowledge-representation", "data-augmentation", "structured-knowledge"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# 知识树 (Knowledge Tree)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
知识树是 [[kore-augmentation|KORE-AUGMENTATION]] 提出的**结构化知识表示**,将单个知识项展开为多层次的训练数据,形成"树干 + 树枝"的树形结构。
|
||||||
|
|
||||||
|
## 结构
|
||||||
|
|
||||||
|
```
|
||||||
|
[原始知识项]
|
||||||
|
/ \
|
||||||
|
Trunk Branches
|
||||||
|
(主干) (分支)
|
||||||
|
| |
|
||||||
|
多轮对话 指令任务
|
||||||
|
├ 启发式Q&A ├ 视觉识别
|
||||||
|
└ 对话Q&A ├ 图像描述
|
||||||
|
└ VQA
|
||||||
|
```
|
||||||
|
|
||||||
|
## 设计理念
|
||||||
|
|
||||||
|
一般的知识增强只生成**孤立的离散变体**——如把 "created" 替换为 "built",或旋转图像。这些变体之间没有结构联系。
|
||||||
|
|
||||||
|
知识树则构建了一个**连贯的多层次结构**:
|
||||||
|
- **主干(Trunk)**通过多轮对话让模型学习知识的**上下文和推理链**
|
||||||
|
- **分支(Branches)**通过多样化指令任务让模型从**不同角度理解知识**
|
||||||
|
|
||||||
|
这种结构化设计使模型能从"数据记忆"上升到"**知识内化**"——理解知识的内在逻辑和关联,而非简单背诵。
|
||||||
|
|
||||||
|
## 与 RAG 的区别
|
||||||
|
|
||||||
|
RAG 在推理时检索外部知识;知识树在**训练时**构建结构化知识,让模型真正学会"理解"而非"查找"。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[kore-augmentation|KORE-AUGMENTATION]]
|
||||||
|
- [[knowledge-internalization|知识内化]]
|
||||||
|
- [[structured-knowledge|结构化知识]]
|
||||||
46
concepts/kore-augmentation.md
Normal file
46
concepts/kore-augmentation.md
Normal file
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: "KORE-AUGMENTATION(知识导向增强)"
|
||||||
|
created: 2026-05-21
|
||||||
|
type: concept
|
||||||
|
tags: ["knowledge-injection", "data-augmentation", "multimodal"]
|
||||||
|
sources: ["[[kore-knowledge-injection]]"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# KORE-AUGMENTATION(知识导向增强)
|
||||||
|
|
||||||
|
## 定义
|
||||||
|
|
||||||
|
KORE-AUGMENTATION 是一种**结构化知识增强**方法,将单个知识项自动转化为多层次的[[knowledge-tree|知识树]],实现从"数据记忆"到"知识内化"的跨越。
|
||||||
|
|
||||||
|
## 知识树结构
|
||||||
|
|
||||||
|
### 主干(Trunk):多轮对话数据
|
||||||
|
- **启发式 Q&A**:手工模板随机构建
|
||||||
|
- **对话 Q&A**:GPT-4o 根据原始文本知识生成最多 10 轮对话
|
||||||
|
- 产出:75,710 条对话数据
|
||||||
|
|
||||||
|
### 分支(Branches):指令任务数据
|
||||||
|
- **视觉识别**:CLIP 检索相似图像 → 回答 "Yes/No"
|
||||||
|
- **图像描述**:GPT-4o 基于知识摘要生成答案
|
||||||
|
- **VQA**:GPT-4o 生成 (Q, A, Subject, Hypernym) 四元组 → Google 搜索图像
|
||||||
|
- 产出:46,468 条 VQA 样本
|
||||||
|
|
||||||
|
## 与一般增强的区别
|
||||||
|
|
||||||
|
| 维度 | 一般增强 | KORE-AUGMENTATION |
|
||||||
|
|------|---------|-------------------|
|
||||||
|
| 文本增强 | 同义词替换/改写(离散变体) | 结构化多轮对话 |
|
||||||
|
| 图像增强 | 旋转/裁剪(表面变换) | CLIP 检索 + 视觉识别/描述/VQA |
|
||||||
|
| 知识结构 | 孤立数据点,无连接 | 连贯的知识树 |
|
||||||
|
| 目标 | 扩大数据暴露面 | 知识理解和内化 |
|
||||||
|
|
||||||
|
## 本质
|
||||||
|
|
||||||
|
一般增强停留在"数据记忆"层面——模型仅能拟合训练数据。KORE-AUGMENTATION 上升到"**知识内化**"——模型能理解知识的内在逻辑和关联,灵活提取和操控学到的知识。
|
||||||
|
|
||||||
|
## 参见
|
||||||
|
|
||||||
|
- [[knowledge-tree|知识树]]
|
||||||
|
- [[kore-constraint|KORE-CONSTRAINT]]
|
||||||
|
- [[knowledge-aware-augmentation|知识感知增强]]
|
||||||
|
- [[knowledge-agnostic-augmentation|知识无关增强]]
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user