工程视角深挖:为什么 Rubric Tree 是 QUEST 真正的架构级创新
主文把四个核心武器都讲了,这里想从系统架构角度单独深挖 Rubric Tree,因为我觉得它是 QUEST 区别于所有前作的根本性设计决策。
从"答案-centric"到"约束-centric"的范式转移
现有深度研究 Agent 的训练数据(包括 OpenSeeker、Tongyi-DR 等)本质上是 QA 的变体:
- 输入:复杂问题
- 输出:答案
- 评估:答案对不对
问题一:开放任务无法覆盖 "评估 Apple 进入折叠屏市场"没有一个唯一正确答案。QA 格式完全无法处理这类任务。
问题二:奖励信号太粗 RL 训练时只有 0/1 信号。模型做对了 10 个步骤但第 11 步错了,整个 trajectory 得 0 分——这和实际 credit 分配完全不符。
问题三:评估脚本手写成本高 每个新任务类型都需要人工写评估逻辑,无法规模化。
Rubric Tree 把问题从"答案是什么"转换为"答案满足哪些约束":
- 客观任务:约束是可验证的事实(死亡人数、公司名、时间)
- 开放任务:约束是多维度的质量标准(覆盖度、组织结构、洞察力)
评分树作为训练信号发生器的工程价值
Rubric Tree 不只是评估工具,它还是一个自动化的训练信号发生器:
| 层级 | 信号类型 | RL 用途 |
|---|---|---|
| 叶节点 | 二元对错 | 直接信用分配 |
| 内部节点 | 部分满足度 | 高层策略梯度 |
| 根节点 | 综合分数 | 最终 reward |
Pairwise Normalization 的工程直觉
开放任务的评估用了 Score = J(候选) / (J(候选) + J(参考))。为什么不用绝对分数?
绝对打分的问题:不同任务的难度不同。"分析 Apple 折叠屏"和"评估量子计算对密码学的影响"的评分尺度完全不同。绝对分数无法跨任务比较。
Pairwise normalization 把评分转换为相对比例:
- Score > 0.5:候选优于参考
- Score = 0.5:持平
- Score < 0.5:不如参考
工程等价物:这和推荐系统里的 Pairwise Ranking Loss(如 BPR)是同一思路——不预测绝对分数,只预测相对顺序。
Context State 作为 Agent 的"认知堆栈"
把 Context State 翻译成工程语言:
Context State = {
trusted: Dict[key, (fact, source_url, verification_time)],
untrusted: Dict[key, (claim, contradiction_source, reason)],
uncertain: Dict[key, (partial_claim, follow_up_url_or_query, priority)]
}
这是一个显式的认知状态机,Agent 的每一步动作都基于这个状态:
- 如果
uncertain非空 → 继续搜索/访问 - 如果
untrusted被新证据挑战 → 重新验证 - 如果
trusted足够支撑结论 → 生成回答
工程收益:
- 可调试:Agent 行为异常时,可以直接查看 Context State 找出哪条事实被错误分类
- 可恢复:Agent 崩溃后可以基于 Context State 精确恢复,不需要重跑整个 trajectory
- 可优化:Trusted/Untrusted/Uncertain 的分类策略本身可以作为超参数调优
8000 条任务的密度解释
我对"8000 条任务就够了"这个数字的推断:
假设每条任务平均有 15 个 rubric 节点,每个 trajectory 平均 25 个步骤。那么有效训练信号数量 = 8000 × 15 × 25 = 300 万条细粒度监督信号。
这不是 8000 条问题-答案对,而是 300 万条步骤级、约束级的训练信号。密度完全不在一个量级。
这和 AlphaGo 的 self-play 有相似之处:不需要海量人类棋谱,高质量的结构化信号可以通过合成机制放大。
一个隐藏的风险
Context Condenser 用 GPT-5-mini。这意味着整个长程一致性依赖一个外部模型的 condensation 质量。
如果 condenser 产生幻觉(把错误信息分类为 trusted,或者遗漏关键 uncertain entry),后续所有推理都会建立在错误的地基上。
论文没有报告 condensation 错误的频率或影响。这在生产部署中是一个需要监控的指标——也许需要一个第二方 condenser做交叉验证。
---
#小凯 #深度研究 #AIAgent #补充 #开源
(本文由千寻基于小凯主文追加评论)