Yiming Xu

planner design

2025-10-07 · 1 min read · #

  • 我们会给“层次节点 + 叶子节点”都建 embedding（分层、分模态），不是只嵌入中间节点，也不是只嵌入叶子。

  • 为什么不直接像 RAG 一样“扔进向量库→取前 k 段就回答”？因为我们的任务大量涉及版面结构、跨页聚合、图表计数/读数、多模态对齐与可解释路径。直接 RAG 检索段落 embedding，既容易漏（比如多子图拆分），也容易错（取到语义近但版面不对的段落），更难做可复现的“导航→观测→推理”链路。我们的设计把 embedding 当作“导航提示”，真正的信息提取必须落在 Observer 的结构/版面感知上。

我们嵌什么（Embedding 覆盖策略）

1) 结构节点（中间层）

  • L1/L2/L3 section：对每个章节节点生成summary（80–150 token），再对 summary 做 embedding。

    用途：Planner 的第一跳定向（先找可能的章节窗口，而不是一开始就扫全书）。

2) 叶子节点（末端）

  • text 段落 / list_item：直接对清洗后的文本做 embedding（过长则分片，保留 page_idx+bbox）。

  • table：用“结构化 markdown / HTML 预览 + caption”拼成短摘要再嵌（避免生吞整表）。

  • image/figure：不嵌像素；嵌的是“caption/子标题/legend OCR 汇总 + VLM 摘要”。

我们还会把图的 page_idx、bbox、figure_id 保存在节点里，供观测时定位。

这样一来，我们有“粗粒度（章级） + 细粒度（叶级）”两套索引： 章级用于 Planner 的窗口选择； 叶级用于 窗口内的细检索（第二跳），比如该章节里的具体表格/图例/段落。

为什么不直接 RAG：检索叶子 embedding 然后直接回答？

我们确实也会做 RAG baseline（用于论文对比），但我们的主系统不这么干，原因很现实：

  1. 结构敏感任务

    “如何跨页聚合？”“同一图的 3 个子图被切开了怎么办？”“同一章节有多个并列图/表要计数怎么办？”

    • RAG 抽段落 → 取前 k → 回答，很容易漏并列兄弟或者跨页关联不全。

    • 我们的 Planner 先定位 章节窗口，Observer 再按 read_order + sibling 半径 把并列图/表一起观察，可显式补漏（REPLAN）。

  2. 多模态问题必须落地到版面

    诸如“有几个折线图”“这张图上蓝线数值是多少”“哪个图标题含 mudslinging”等：

    • RAG 的文本检索无法可靠定位图像本体；

    • 我们在 Observer 里真的去看图片/表格节点（OCR legend、VLM 读图），并且把图—文—页的相对关系用 bbox/邻接维护，可解释。

  3. 可控的“导航→观测→推理”循环

    • 我们希望流程是：embedding（提示方向）→ summary（人类可读规划）→ 精准观测（结构感知）→ 推理。

    • 直接 RAG 会把“规划”和“观测”混在一起（一次向量检索当答案），很难做replan和证据路径。

  4. 减少“语义相近但上下文错位”的误检

    • 例：问题是“有多少张和 mudslinging 相关的图表”，文本里到处会有“negative”“媒体批评”等词；

    • RAG 检索易捞到一堆“看似相关”的段落；

    • 我们流程里 Planner 先定章节 → Observer 只看那一章里的图表和标题/legend → 严格计数。

  5. 准确计数/统计

    • “多少页面至少有一张折线图”“多少表含 ‘F1’ 指标”…

    • 这类题必须版面遍历 + 规则感知，不是“检索几段文本”就能稳的。

一句话：RAG 更偏“找可能的句子”；我们的系统偏“找准位置，取对证据，然后再回答”。

在“需要结构/版面/多模态/计数/可解释”的文档问答里，这差异很关键。

Planner 里怎么用 embedding（不是 RAG，但善用向量）

我们用 embedding 做 两段式导航：

  • Coarse（章级）：

    用问题 + hints（同义/外语/别名）对 section-summary 索引 做相似度检索，取 top-K 章节窗口。

  • Fine（叶级 within-window）：

    对入围章节的叶节点索引再做一次小范围相似度检索（图/表/段落），给 Observer 一个更聚焦的观察清单。

两级检索都只是“确定去哪儿看”，不直接当答案；真正的内容读取交给 Observer（带结构和版面规则）。

嵌所有节点会不会太多？

我们有几条工程约束：

  • 图/表只嵌caption+legend OCR 摘要，不嵌原图像（向量体积可控）。

  • 长段落按层内分片（比如 300–500 token），保留 page_idx 与 bbox，便于回跳。

  • 层级裁剪：章节嵌 L1–L3，L4+（很细）通常不嵌，作为“窗口内二跳”由叶级处理。

  • 类型过滤：检索时可以 type in {“section”,“image”,“table”} 限制，减少干扰。

小结（给论文/复审）

  • 我们不反对 embedding 检索，而是把它限定为“导航提示”；

  • 回答必须源自结构化观测（可复验的页码、图表、标题、legend 证据），提升可靠性与可解释性；

  • 对于“结构/多模态/跨页聚合/计数”这类题，Agent 的分阶段策略比“RAG 一步到位”更稳定且可重跑；

  • 同时，我们保留 RAG baseline 和兜底路径，公平对比并提高系统鲁棒性。

before build the context window, do embedding based retrieval first.