论文 Fig.2 的完整目录树
/（根目录）
│
├── HR/ 【Local={1}】 【Inc={1,2}】
│ ├── overview.pdf ............ doc_1 ← 直接放在 HR
│ └── Policies/ 【Local={2}】 【Inc={2}】
│ └── benefits.pdf ....... doc_2 ← 放在子文件夹 Policies
│
├── Finance/ 【Local={3}】 【Inc={3}】
│ └── report_finance.pdf ...... doc_3
│
├── Legal/ 【Local={4}】 【Inc={4}】
│ └── report_legal.pdf ........ doc_4
│
├── Dept_A/ 【Local={5}】 【Inc={5,8}】
│ ├── report_A.pdf ............ doc_5 ← 直接放在 Dept_A
│ └── OKR/ 【Local={8}】 【Inc={8}】
│ └── plan_A.pdf .......... doc_8
│
├── Dept_B/ 【Local={6}】 【Inc={6,9}】
│ ├── report_B.pdf ............ doc_6 ← 直接放在 Dept_B
│ └── OKR/ 【Local={9}】 【Inc={9}】
│ └── plan_B.pdf .......... doc_9
│
└── Archive/ 【Local=∅】 【Inc={7}】
└── HR/ 【Local={7}】 【Inc={7}】
└── old_policy.pdf ...... doc_7基本信息 ：arXiv:2606.16903v1（2026-06-15），作者来自杭州电子科技大学、浙江大学、字节跳动 （Viking 向量引擎团队），15 页。核心成果：把 "目录层级语义" 作为向量数据库的一等公民能力，并已落地进开源 Agent 上下文库 OpenViking。
0. 背景速成（先扫清陌生概念）
- 向量数据库 / RAG：把文档切块后用 embedding 模型（如 bge-m3）转成 1024 维向量，存入向量库；提问时把问题也向量化，做 k 近邻（k-NN）相似度检索，再把命中片段喂给 LLM 生成回答，这就是 RAG。
- ANN 索引 ：精确算全库太慢，工业上用近似最近邻索引加速，本文测了两种主流类型 ------PG（Proximity Graph，近邻图，即 HNSW 那类图索引） 和 IVF（倒排文件，先聚类分区再搜）。
- 现状痛点接口 ------ 标量元数据过滤（metadata filtering） ：现在的向量库只能给条目打扁平标量属性 做过滤，如
category="finance"、price<100，再在满足条件的候选集里跑向量排序。它表达不了 "层级目录" 这种结构。 - 本文的一句话 ：现实数据（代码仓库、企业 Wiki、文件系统、Agent 记忆）都是一层层文件夹组织的，但向量库只把路径当普通字符串存，导致 "在某目录及其所有子目录里递归搜索" 和 "整体搬移 / 合并一个文件夹" 这两件最常见的事都很难做、很贵。本文要把这套目录结构原生内置进向量库。
一、研究目标与待解决的实际问题
先看一棵最朴素的文件夹树（论文里的例子）,记住这棵树，下面所有操作都对着它走。
/（根目录，相当于"此电脑"）
├── HR/ ← 人事文件夹
│ ├── overview.pdf (doc_1) ← 直接放在HR里的文件
│ └── Policies/ ← HR里面还有个子文件夹"政策"
│ └── benefits.pdf (doc_2) ← 放在子文件夹里的文件
├── Dept_A/ ← A部门文件夹
│ ├── report_A.pdf (doc_5)
│ └── OKR/
│ └── plan_A.pdf (doc_8)
└── Dept_B/ ← B部门文件夹
├── report_B.pdf (doc_6)
└── OKR/
└── plan_B.pdf (doc_9)1.1 研究目标（论文原话定位）
"This paper studies native directory semantics as a first-class capability for vector databases."（把原生目录语义作为向量数据库的一等能力来研究。）
具体落地为：形式化定义两个核心算子，并在一个解耦于 ANN 索引的 "可插拔目录语义层" 上实现、对比三种方案。
- DSQ（Directory-Semantic Query，目录语义查询） ：读路径，按目录拓扑圈定合法候选集再交给向量排序，支持：
- 递归查询（Recursive） ：搜目标目录及其所有子孙目录 里的条目。例：锚定
/HR/，应同时命中/HR/overview.pdf(doc_1) 和/HR/Policies/benefits.pdf(doc_2)。 - 非递归查询（Non-Recursive） ：只搜直接挂在该目录下 的条目，不含子目录。例：对
/HR/非递归只返回 doc_1，排除子目录里的 doc_2。 - 派生操作（排除某分支、兄弟查询、祖先查询）都可由这两个基元组合得到。
- 递归查询（Recursive） ：搜目标目录及其所有子孙目录 里的条目。例：锚定
为什么要分递归/非递归两种？ 因为需求不同：有时你要 "整个部门全搜"（递归），有时只要 "这一层目录下直接登记的东西"（非递归）。论文说，更复杂的查法（比如 "排除掉某个子文件夹"" 只看兄弟文件夹 ""往上看祖先目录"）都能用这两种基础查法组合出来，所以重点只讲这两个。
- DSM（Directory-Semantic Maintenance，目录语义维护） ：写路径，在保持命名空间语义 的前提下改变拓扑，代表操作为：
- MOVE（移动子树） ：把整个
/Dept_A/挂到/Dept_B/下，内部结构不变。
如：电脑上的 "剪切 Dept_A → 打开 Dept_B → 粘贴"。注意是搬整个文件夹，不是一个个搬里面的文件。 - MERGE（合并子树，并去重） ：把
/Dept_A/并入/Dept_B/，并递归调和同名冲突（如两边都有OKR/，需合并到同一个OKR里 → {doc_8, doc_9}）。
论文还说：新建文件夹、删文件夹、改文件夹名字，都能看成这两个动作的简单变种（比如改名≈移动到一个新名字下），所以只重点研究 MOVE 和 MERGE。
- MOVE（移动子树） ：把整个
1.2 要解决的真实行业痛点（论文给的两类失败 + 两条工程 workaround 代价）
痛点本质：把层级拍平成标量字符串，丢失了拓扑。
标量字符串 ：就是一个单独的、平的文字值，比如
/docs/v2.0/intro.md，数据库只把它当成 "文件名字符串" 来存。层级 / 拓扑 ：这串路径其实藏着 "文件夹套文件夹" 的父子关系 ------
/docs/v2.0/是上级，intro.md是下级，/archive/v1.0/是另一个平行分支。"拍平" ：数据库把这层父子结构抹掉了，所有路径在它眼里都是一条条互不相关的平字符串。就像你把一棵树拍扁成一地树叶，只捡到叶子，丢了枝干。
论文引言给了两个 "语义相似但语境错误" 的检索失败例子：
失败例子 1：现行文档和过时归档被一起捞出来
你问 "architecture design（架构设计）"，向量相似度算法发现：
/docs/v2.0/里的新文档，和问题很像 ✅ 该要/archive/v1.0/里的旧版归档文档，文字也很像 ❌ 不该要（已经过期了）
因为数据库只按 "文字像不像" 打分，它不知道 /archive/ 这个文件夹就代表 "废弃、别用"，所以把新旧一锅端。
失败例子 2：相关材料被无关文件 "稀释"
你在 /docs/ 里想找正经资料，但 /logs/（日志文件夹）里有些文件用词和问题也沾边，向量算法觉得 "也有点像"，就把它们也排进结果里。真正相关的材料被这些噪音冲淡、淹没了。
论文强调：这些 "不是排序（ranking）误差，而是数据库根本缺少层级作用域的原生算子"。
意思是：这不能怪向量相似度算得不准 。相似度其实算对了 ------ 旧文档和日志文字上确实像。问题在于：你本来只想限定在某个文件夹范围里找，可数据库没有 "按文件夹圈范围" 这个能力，它只能在全库里按文字像不像捞。所以是 "缺工具"，不是 "算法笨"。
当前业界的应用层 workaround 及其两条代价（这是论文批判的核心）：
workaround（权宜之计 / 土办法）：数据库自己不会按文件夹圈范围，那应用程序（外面的业务代码）就自己动手补。
现在要在
/src/下递归搜，土办法是怎么做的？第 1 步：应用程序先去另一个外部的元数据存储 （比如关系数据库）里，把
/src/下面所有后代路径一条条枚举出来 ，列成一张长长的清单：['/src/a/x.py', '/src/a/y.py', '/src/b/z.py', ...]。第 2 步：拿这张超长清单，向向量库提交一个条件：
path IN ['/src/a/x.py', '/src/a/y.py', ...]。"析取谓词" ：就是上面那个
IN 一大串------ 满足 "在这张清单里任意一条" 就算合格，是个由很多 "或者" 拼起来的条件。清单可能成千上万条。
| 路径 | 现状 workaround 的后果 |
|---|---|
| 读（递归检索） | 作用域解析变成一个不透明的预处理步骤 ，数据库无法把 "结构裁剪" 和 "向量搜索" 联合优化，延迟被推高 * 圈范围这件事，变成了数据库管不着的、黑乎乎的前置步骤（不透明预处理）：外面先列清单，再喂给数据库。 * 数据库不知道哪些目录是空的、哪些该提前剪掉 ，没法把 "先按结构剪掉无关分支" 和 "向量搜索" 两件事配合着一起优化，只能先笨拙地列一大堆，导致延迟被推高。 |
| 写（MOVE/MERGE） | 要在外部目录存储和向量元数据之间协调更新 ；一个逻辑子树操作退化成大量文档级 / 路径级更新 → 写放大（write amplification） ，并暴露一致性隐患 写放大（write amplification） ：本来你只想做 "搬一个文件夹" 这一个 动作，结果系统被迫拆成一大堆文件级、路径级的更新。 举个具体的：你要把 /Dept_A/ 整个搬走，里面有 1000 个文件。 * 理想：搬 1 次文件夹。 * 土办法：因为路径是拍平的平字符串，系统得挨个修改这 1000 个文件的路径记录，还要同步改 "外部目录存储" 和 "向量库元数据" 两处。一个动作放大成上千个小更新。 一致性隐患 ：这两处（外部目录库、向量库）是分开存的，更新要 "两边协调"。万一改到一半出错、断电、并发，就会出现：目录库里显示搬走了，向量库里路径还是旧的 ------两边对不上、数据不一致。 |
1.3 设计需求（论文 II-D 节给出的四条硬约束，也是后文评判三方案的标尺）
- 作用域正确性（scope correctness）：向量排序前必须先正确解析出递归 / 非递归目录范围。
- 查询效率（query efficiency）：每次查询不应扫描或展开一棵大子树。
- 维护效率（maintenance efficiency）：结构变更时尽量不要重写受影响子树里的每个条目 / 物化路径。
- ANN 索引独立性（ANN-index independence） ：目录语义只做 "候选集解析层"，能挂在不同向量索引之上，不改 ANN 算法本身。
二、研究的产业发展价值
2.1 对应场景：四类天然层级组织的知识载体（论文 Fig.1）
- 代码仓库 （如 MineContext/opencontext 的
Home/VectorDatabaseCloud/Quic/backends/sqlite_backend.py） - 企业 Wiki / 公司文档 （如
/Bytedance/Documents/Personal） - 个人文件系统 （
kStart/Getting...databases） - Agent 上下文 / 记忆存储（viking:// 命名空间）
2.2 核心产业价值
- RAG/Agent 工程正从 "文档集合" 走向 "运营级知识库" ：生成质量高度依赖召回上下文的相关性与一致性（论文引 11-14），而有效搜索空间往往由 "项目目录、版本分支、用户记忆命名空间、Agent 技能库" 这类结构作用域决定。目录语义是把这层 "语境合法性" 补进数据库底座。
- 直接服务爆火的 Agent 记忆 / 上下文工程 ：记忆要被频繁 "创建、合并、归档、挂到项目或技能上"，资源子树要随工作区演进而重组（论文 IV-C）。没有原生目录维护，这些都得靠应用层两套存储硬协调 ------ 正是 MOVE/MERGE 写放大和一致性隐患的高发区。本文成果已进入 OpenViking （面向 AI Agent 的开源上下文数据库），支持文件系统式组织、L0/L1/L2 分层加载、目录递归检索，是可直接被 Agent 框架复用的工程范式。
- 与 hybrid retrieval 互补而非竞争（论文 VI 节明确划界） ：混合检索（稠密 + 稀疏、RRF 融合）解决 "在候选集内怎么排得更准 "；目录语义解决"哪些条目有资格被检索"。先解析目录候选集，再在集内做稠密 / 稀疏 / 混合排序 ------ 这给现有向量库提供了一层正交增强，落地门槛低。
- 开源贡献了两个大规模 benchmark （现有数据集都不暴露目录语义操作）：
- WIKI-Dir ：Wikipedia 语料 + DBpedia 查询 / 相关性标签，363,467 个目录、平均深度 11.95、194 万向量化条目、456 条带目录约束的测试查询、1000 MOVE + 1000 MERGE；bge-m3，1024 维。
- ARXIV-Dir ：276 万篇 arXiv 摘要，双命名空间（主题层级
/cs/AI/均深 2.19；时间层级/2024/05/均深 1.92），mxbai-embed-large-v1，1024 维，1000 查询，ground truth 由暴力搜索算出。 这为后续 "目录语义向量检索" 研究提供了标准评测底座。
- 工业级验证背书 ：在字节 Viking 引擎（C++，48 核 Xeon Silver 4310 / 125GB）上实现，并同时跑通 PG（图索引）与 IVF（分区索引）两类 ANN，证明其索引中立性主张成立。
三、核心创新方法、模型与对比优势
本文的方法贡献是 "一个层 + 三个方案 "：目录语义层独立于 ANN；三个方案分别是 PE-Online、PE-Offline、TrieHI。下面逐层拆。
DSQ/DSM 是定义一次的 "接口标准"，三种方案是这份标准的三个实现版本
3.1 方案一：PE-Online（在线路径展开，查询时展开，时间换空间）
思路 ：入库时只记录条目精确的父目录，递归展开推迟到查询时做。
存储 / 索引（3 个元数据结构，均独立于 ANN）：
- entry-to-directory：每个条目→逻辑父目录映射；
- parent-path 倒排索引：每个目录路径键 → 直接挂在它下面的条目集合；
- auxiliary directory index：存全部目录键，支持前缀枚举、直儿子查询。
DSQ：
- 递归：先用辅助索引枚举出子树里所有目录键
K（如/HR/→{'/HR/','/HR/Policies/'}），逐个取 posting list 再求并集 得 {doc_1, doc_2}。元数据工作量与mq（枚举到的目录键数）成线性。 - 非递归：直接查该路径键的 posting list，一次查找即可，很便宜。
DSM：在目录键层面重映射（MOVE：枚举受影响源键、前缀替换成目标键、重映射 posting list；MERGE：同名列的 posting list 求并）。代价 O (mu)，mu 为被移动子树的目录键数。
致命弱点：递归查询对 "又浅又宽" 的目录极度敏感 ------ 要在查询时枚举海量后代键。
3.2 方案二：PE-Offline（离线路径展开，入库时物化祖先，空间换时间）
思路 ：入库时不仅挂到父目录，还挂到每一个祖先目录 的 posting list。doc_2 在 /HR/Policies/，就同时写进 /、/HR/、/HR/Policies/ 三个列表。
- 递归 DSQ 变快 ：查
/HR/一次命中已物化的祖先列表，直接得 {doc_1, doc_2}。 - 代价转移 ：
- 存储 / 入库变重：深度 t 的条目贡献 t 份祖先副本；
- 非递归反而变贵：要从已含后代的总集里减去所有直接子目录集合（SetTotal \ SetChildren，最多 c 次子查找 + 求差）；
- DSM 更重：除 O (mu) 路径键重映射外，还要做 O (t) 的 "祖先成员" 更新 ------ 把整棵子树集合 S 从 "旧专属祖先"A⁻ 摘除、加到 "新专属祖先"A⁺，公共祖先不动。
3.3 方案三：TrieHI（Trie-based Hierarchical Index，原生前缀树层级索引）------ 本文主角
核心创新：不再把层级当成一串路径键，而是把目录拓扑本身存成一棵前缀树（Trie），每个目录就是一个可复用的 "作用域对象"。
数据结构（每个 TrieNode 四个字段）
segment：本地目录名；children：子段名→子节点的哈希表；parent：父节点指针；inclusive_ids（含入集合） ：逻辑目录落在本节点或其任一后代的条目 ID 集合。
关键不变式（论文公式 1，务必理解）：
其中：
Local(v)：直接存放在目录 \(v\) 下的条目；Inc(v)：目录 \(v\) 整个子树内的条目；Child(v)：直接子目录。
通俗讲：一个目录节点的 "含入集合"= 直接挂在自己名下的条目 + 所有孩子节点含入集合的总和。这让目录节点成为一个可复用的物化作用域：递归查询直接读这个聚合集；维护时只需更新 "成员发生变化的祖先链"。
各操作怎么跑
- 入库：从根按路径走到终端节点（缺则建），把 ID 登记到终端节点，并沿祖先链追加到各 inclusive_ids，O (t) 次访问 / 更新。
- 递归 DSQ ：从根走到目标节点（O (t)），直接读该节点 inclusive_ids ，无需枚举后代。例：
/Dept_A/→ {doc_5, doc_8}。 - 非递归 DSQ ：SetTotal=Inc (p)，并上各直接孩子的 Inc 得 SetChildren，返回 SetTotal\SetChildren。例：
/Dept_A/→ {doc_5,doc_8}{doc_8}={doc_5}。 - MOVE ：定位源节点 s、旧父、新父；S=Inc (s)；从旧专属祖先链摘除 S、加到新专属祖先链；然后摘掉源节点、挂到新父的 children 表、改 parent 指针 （整棵子树作为一个单元重链接）。只走源 / 目标两条路径并更新受影响祖先聚合，与后代目录键数量无关。
- MERGE ：先做祖先聚合迁移；拓扑层上，不冲突的孩子子树整棵重链接为单元；只有同名冲突分支才在 trie 节点上递归调和（冲突节点数记 r）。
先记住一把钥匙：每个节点背后都记着一个 "袋子" Inc (v)
TrieHI 把目录存成一棵树。每个目录节点后面都挂一个袋子（incclusive_ids，记作 Inc），袋子里装的是 "我这个文件夹 + 我所有子文件夹里的全部文件 ID"。
我们把论文那棵树的每个袋子先填好（后面所有操作都用它）：
/（根） Inc = {1,2,3,4,5,6,7,8,9} ← 全库都在我这棵树下
├── HR/ Inc = {1,2}
│ └── Policies/ Inc = {2}
├── Finance/ Inc = {3}
├── Legal/ Inc = {4}
├── Dept_A/ Inc = {5,8} ← 自己有doc_5，子文件夹OKR里有doc_8
│ └── OKR/ Inc = {8}
├── Dept_B/ Inc = {6,9}
│ └── OKR/ Inc = {9}
└── Archive/
└── HR/ Inc = {7}不变式（公式 1）就是这句大白话：一个节点的袋子 = 直接放我这儿的文件 + 我每个孩子袋子里的东西。有了这个预存的袋子，后面查、搬、并都很省事。
1. 入库（插入一个文件）：沿这条路往上，每层袋子都塞一份
例子：把 doc_8 放进 /Dept_A/OKR/。
步骤：
- 从根出发走这条路：根 → Dept_A → OKR，走到 OKR（缺这个文件夹就顺手建）。
- 把 doc_8 记到 OKR 这个终端节点。
- 沿着祖先链往上，每经过一层就把 8 塞进它的袋子 ：
- OKR 袋子：+8 → {8}
- Dept_A 袋子：+8 → {5,8}
- 根袋子：+8（本来就有，补进全集）
这条路深度 t=3，就走 3 层、更新 3 个袋子，所以是 O(t)（t = 目录深度，和全库多少文件无关）。
类比：你把一封信放进 3 层抽屉的最里层，顺手在每层抽屉外面的 "本柜清单" 上都登记一笔。
2. 递归 DSQ：直接读目标节点的袋子，不用翻孩子
查 /Dept_A/ 下所有东西（含子文件夹）：
- 从根走到 Dept_A（2 步）。
- 直接看它的袋子 Inc={5,8}，结束。
就这么简单 ------ 因为袋子里已经预先装好了 "我整棵子树的全部文件"，不用再去打开 OKR 枚举一遍。结果 {doc_5, doc_8}。这就是它比 PE-Online 快的原因（PE-Online 没有这个预存袋子，得现场一个个翻孩子）。
3. 非递归 DSQ：袋子减去所有孩子的袋子 = 只留本层
只查 /Dept_A/ 这一层直接放着的文件，不要子文件夹 OKR 里的。
手算：
- SetTotal = Dept_A 的袋子 = {5,8}
- SetChildren = 所有直接孩子的袋子并起来 = OKR 的袋子 {8}
- 本层 = SetTotal − SetChildren = {5,8} − {8} = {5} ✅
原理：总袋子里 = 本层文件 + 孩子袋子里的文件；把孩子的都减掉，剩下的就是只属于本层的 doc_5。
4. MOVE（移动）：只拎 "门框"，不动里面每件家具
把整个 Dept_A 搬到 Dept_B 下面。关键直觉：Dept_A 是一个整体节点，搬家只搬这个节点本身，里面的 OKR、doc_5、doc_8 一概不碰。
步骤：
- 定位源节点 s=Dept_A、它的旧父（根）、新父（Dept_B）。
- S = Dept_A 的袋子 = {5,8}（先把这包东西抓在手里）。
- 祖先链调整：把 S 从 "搬走后不再包含它的旧祖先" 袋子里摘除，加到 "新专属祖先" 袋子里；公共祖先（比如根两边都挂着）不动。
- 拓扑动作：把 Dept_A 从旧父（根）的孩子名单里摘掉，挂进新父（Dept_B）的孩子名单，改一下 Dept_A 的 parent 指针。
为什么便宜？因为你只走了 "源路径" 和 "目标路径" 这两条线，Dept_A 里面有多少个后代文件夹、多少文件，完全不用管。
类比：你把一整个抽屉柜子从房间 A 挪到房间 B，只需要拎着柜子搬，不用把柜子里每件衣服拿出来重新贴标签。而 PE 方案相当于把每件衣服的标签都重写一遍。
5. MERGE（合并）：整箱搬，只拆开 "同名的箱子"
把 Dept_A 并进 Dept_B。分两层：
① 先做祖先袋子迁移（和 MOVE 第 3 步同理，把 S 的聚合从旧祖先挪到新祖先）。
② 拓扑合并，分两种孩子：
- 不冲突的孩子 （Dept_B 里没有同名文件夹）：整棵原封不动挂过去。比如 Dept_A 下有个独有文件夹 X，Dept_B 没有 X，那 X 连人带物整个挂到 Dept_B 下，不拆开、不重写。
- 同名冲突的孩子 ：这里两边都有
OKR/，才在这个节点上递归调和------ 把两个 OKR 的袋子合并 {8}∪{9}={8,9}。冲突节点数记 r，所以代价是 O (t+r)。
类比：合并两个收纳箱，别人独有的格子直接整个端过去；只有两个箱子里都叫 "OKR" 的那个格子，才打开把里面东西倒在一起。
------------回到正文：
一致性（论文 IV-A）
一次变更内按固定顺序：收集受影响条目集 → 改父子链接 → 刷新 entry-to-node 目录与祖先聚合 → 迁走后删除旧绑定；重叠路径的变更串行化，保证拓扑、目录、inclusive_ids 三者始终一致。
工程实现细节
条目 ID 集用 Roaring bitmaps（压缩位图）做并 / 交 / 差，省内存且集合运算快。
3.4 三方案复杂度对比（论文表 I、表 II 合并）
| 环节 | PE-Online 查询时展开 | PE-Offline 入库时物化 | TrieHI 原生前缀树 |
|---|---|---|---|
| 索引存储 | 低（每条目 1 份父列表） | 高（每条目 t 份祖先列表） | 中高（trie 拓扑 + 每节点含入集） |
| 入库 | 低 | 高（t 次更新） | O (t) 节点访问 + 聚合更新 |
| 递归 DSQ | 高：枚举 + mq 次查找 + 并集 | 低：一次查找 | O (t) 遍历 + 一次聚合读取 |
| 非递归 DSQ | 低：一次查找 | 高：1+c 次子查找 + 求差 | O (t+c)+ 并 / 差 |
| MOVE | 高：O (mu) 路径键重映射 | 高：O (mu) 重映射 + O (t) 祖先更新 | O (t) 节点访问 + 祖先聚合更新，与子树大小无关 |
| MERGE | 高：O (mu) 合并 + 冲突并集 | 高：O (mu)+O (t) 祖先 + 冲突并集 | O (t+r)，仅冲突分支递归调和 |
本质权衡 ：PE-Online 用查询延迟换空间，PE-Offline 用入库 / 写成本换查询快，两者都把层级拍平成标量键，共享同一个维护瓶颈 ------ 结构变更要重写受影响子树的路径键（Offline 还要改祖先）；TrieHI 用 "额外的元数据空间" 换取 "健壮的递归 DSQ + 高效 DSM"。
3.5 实验证据（关键数据，全部来自论文）
(1) 递归 DSQ：目录专属延迟（表 IV，单位 µs，只测目录谓词解析、不含 ANN）
表格
| 数据集 | 方法 | 均值 | P99 | P99.9 |
|---|---|---|---|---|
| WIKI-Dir 递归 | PE-Online | 365,000.80（≈365ms） | 913,704 | 2,654,322 |
| PE-Offline | 235.23 | 1,332 | 4,233 | |
| TrieHI | 273.10 | 1,526 | 4,004 | |
| ARXIV-Dir 递归 | PE-Online | 1,089.20 | 5,292 | 5,380 |
| PE-Offline | 0.12 | 0.93 | 1.43 | |
| TrieHI | 0.43 | 2.80 | 3.43 |
→ WIKI 上 PE-Online 的递归目录解析高达 365ms ，而 PE-Offline/TrieHI 仅 235--273µs （差约 1500 倍）。原因（图 10）：WIKI 浅锚点要展开的后代路径 m 在深度 1 时高达 236,903 个，深度 2/4/8 仍有 19 万 / 17.5 万 / 8.65 万。
(2) 非递归 DSQ：代价反转（表 IV，WIKI 均值 µs）
- PE-Online 29.07（最快，直接查父键）；PE-Offline 1037.07；TrieHI 945.17。
- 论文澄清：TrieHI 不以 "最简单的非递归查找最快" 为目标，它要的是递归高效且把非递归开销控制住；图 8 证明这点元数据开销相对端到端向量搜索可忽略。
(3) 三方法检索质量基本持平（图 7、图 8）
递归 nDCG@10 约 0.48--0.52（WIKI）、Recall@100 约 0.94--0.95（ARXIV）；非递归 Recall@10 约 0.96--0.98。质量几乎重合，差异全在横轴延迟------ 证明只要作用域解析正确，目录层不损伤召回质量。
(4) DSM 维护（图 9，对数坐标）------TrieHI 最大亮点
- TrieHI（橙线）MOVE/MERGE 稳定在 0.1--1ms 量级、方差极小；
- PE-Online / PE-Offline（蓝 / 绿线）在 1--100ms 间剧烈波动并出现高频尖峰，子树越大越贵、延迟方差越高。
- 原因：扩展法要按子树规模重映射 / 合并路径键；TrieHI 整棵子树 "连根拔起重挂"，只动两条祖先链。
(5) 建库与存储开销（表 V）
- 建库时间 ：WIKI+PG 基线 1491.27s，三目录方案 1502.21--1515.25s，增幅 <1.7%。
- 存储 ：PE-Online 最省；PE-Offline 因祖先物化略增；TrieHI 最大 （WIKI-PG：基线 7925MB → PE-Online 8143 / PE-Offline 8213 / TrieHI 8326MB ；ARXIV-IVF：10964 → 11256MB）。论文明说这是 "为可复用作用域和树本地维护付出的空间代价"，不存在唯一通吃方案，而是空间↔递归 / 维护效率的交易。
(6) 端到端落地效果（OpenViking，表 VI / 表 VII）
LOCOMO 长对话用户记忆 QA（LLM-as-judge，doubao-seed-2-0-pro）：
表格
| 系统 | 准确率 | 平均查询时间 (s) | 总输入 Token |
|---|---|---|---|
| OpenClaw 原生记忆 | 24.20% | 95.14 | 392,559,404 |
| OpenClaw + OpenViking | 82.08% | 38.8 | 37,423,456 |
| Hermes 原生记忆 | 33.38% | 82.4 | 79,228,398 |
| Hermes + OpenViking | 82.86% | 27.9 | 52,026,755 |
| Claude Code auto-memory | 57.21% | 49.1 | 353,306,422 |
| Claude Code + OpenViking | 80.32% | 20.4 | 129,968,899 |
→ 三个 Agent 接入后准确率大幅跃升、查询时间下降、Token 用量大幅压缩（靠 DSQ 先圈定用户 / 会话作用域 + L0/L1/L2 分层，避免把整段历史反复塞进 prompt）。
HotpotQA 多跳知识库 QA：
表格
| 方法 | 准确率 | Token/QA | 延迟 (s)/QA |
|---|---|---|---|
| Naive RAG | 62.50% | 1,290 | 0.11 |
| HippoRAG 2 | 61.00% | 726 | 20 |
| LightRAG | 89.00% | 28,443 | 75 |
| OpenViking top-5 | 72.75% | 3,154 | 0.22 |
| OpenViking top-20 | 91.00% | 12,533 | 0.23 |
→ top-20 以 0.23s 拿到 91.00%，超过 LightRAG 的 89%，而 Token 仅为其 1/2、延迟从 75s 降到 0.23s。关键机理：TrieHI 先圈定连贯目录作用域，增大 top-k 只是多收 "作用域内相关证据"，而不是灌入全库无关段落。
四、落地借鉴（可复用思路）+ 知识补充
4.1 可直接复用的创新思路与学习重点
- "解耦的作用域解析层" 架构：目录 / 结构约束先解析成候选 ID 集，再交给任意 ANN 排序。做自己的系统时，不必改动底层 HNSW/IVF，只需在其上加一层 "谓词→候选集" 的元数据层，这是最低侵入的落地路径。
- "节点即可复用作用域" 的物化思想（公式 1 含入集不变式）：把 "目录 = 缓存好的聚合候选集"，递归查询零展开；写操作只回刷受影响祖先链。这个 "自顶向下聚合、变更只改祖先链" 的模式可迁移到任意层级标签体系（标签树、组织架构、分类法）。
- 写优化的关键洞察 ------ 整子树重链接（relink）代替逐条重写：MOVE 不改每个后代，只改一个 parent 指针 + 两条祖先链的聚合。做层级搬迁 / 重组类功能时优先找 "单元移动" 而非 "逐条更新"。
- 冲突局部化的 MERGE：不冲突子树整棵搬，只在同名分支上递归调和，避免全量合并。
- L0/L1/L2 分层上下文 + 目录作用域：先轻量摘要 (L0) 定位、再按需取细节 (L2)，配合 DSQ 圈范围，是显著降 Token、提准确率的 Agent 记忆工程手法（LOCOMO 结果直接证明）。
- 选型指导（别盲目上 TrieHI） ：
- 只读、几乎不维护、目录浅窄 → PE-Online 最省；
- 递归读极多、写少、能接受空间 → PE-Offline 够用；
- 频繁 MOVE/MERGE、子树大、要求稳定低延迟 → TrieHI。
- 方法论借鉴：论文把 "目录操作" 抽象成 2 个读原语 + 2 个写原语，再用 "目录专属延迟（剥离 ANN）" 单独度量元数据层成本，并同时测两种 ANN 以隔离变量 ------ 做系统论文评测时值得模仿。
4.2 需要额外补充的背景知识（深入该方向前）
- ANN 索引家族：HNSW/NSG 等图索引（PG）、IVF 倒排聚类、量化（PQ/SQ）、DiskANN；理解 "候选集密度如何影响图遍历连通性"（论文图 11 提到：约束越选择性，PG 有效节点越稀疏、图连通变弱，反而要更多遍历，故 PG 延迟随深度上升，而 IVF 分区探测为主、曲线更平）。
- 过滤向量检索（filtered vector search）：解耦式谓词优化、按谓词选择性选择执行计划、coupled index（标签索引、范围索引）------ 本文 VI 节相关工作，是该方向的直接邻域。
- 集合表示：Roaring bitmap 的分桶 / 容器压缩原理（array/bitmap/run 容器切换），并交差复杂度。
- Trie / 前缀树 / 层级聚合数据结构：基数树（radix tree）、压缩前缀树，以及 "路径压缩、lazy 聚合" 等变体。
- RAG 与 Agent 记忆基线：Naive RAG、HippoRAG 2（图谱记忆）、LightRAG（层次化图谱）、LOCOMO/HotpotQA 评测协议、LLM-as-judge。
- 写放大（write amplification）与一致性：LSM-tree、副本协调、事务隔离在层级变更中的体现。
- 未来方向（论文 VII 自陈） ：把 DSQ 扩展到更丰富的路径谓词（前缀约束、通配符
*、多分支排除），以及语义约束 + 层级约束混合的代价感知查询规划------ 这是可直接跟进的选题缝隙。
五、完整端到端流程（从入库到查询到维护）
5.1 离线入库（Ingestion）
- 文档 / 摘要经 embedding 模型（WIKI 用 bge-m3、ARXIV 用 mxbai-embed-large-v1）转 1024 维向量。
- 构建两套索引：①底层 ANN（PG 图 / IVF 分区）；②目录语义元数据层（三方案之一）。
- TrieHI 入库 ：按 URI / 路径从根遍历 trie，缺节点则建；条目 ID 挂到终端节点
Local，并沿祖先链追加进各节点inclusive_ids，维护公式 1 不变式。 - 写公共 entry-to-node 目录（记录本条目当前逻辑父节点，用于 DSM 记账，三方案共有，评测时剔除以公平比较）。
5.2 在线查询（DSQ，读路径）
- 查询语句先经 parser 解析出目录约束（锚定路径 p、递归 / 非递归）。
- 作用域解析层（与 ANN 解耦） 把约束解析成候选条目 ID 集：
- 递归：TrieHI 走到 p 节点，直接读
Inc(p)； - 非递归：
Inc(p) \ ⋃ Inc(直接孩子)； - （派生：排除 = 递归集相减；通配 = 按层匹配孩子名继续遍历。）
- 递归：TrieHI 走到 p 节点，直接读
- 候选 ID 集交给 ANN 执行器，只在集内做向量排序，返回 top-k。
- 度量：检索质量 nDCG@k / Recall@k + 端到端延迟，并单独剥离 "目录专属延迟"。
5.3 结构维护（DSM，写路径，以 MOVE / MERGE 为例）
- 变更前先圈定受影响 trie 区域：MOVE = 源子树 + 目标路径；MERGE = 源 / 目标两子树；重叠变更串行化。
- 收集受影响条目聚合集 S=Inc (源根)。
- 祖先聚合迁移：把 S 从 "旧专属祖先 A⁻" 摘除，加到 "新专属祖先 A⁺"，公共祖先不动。
- 改拓扑：MOVE = 源节点脱离旧父 children、挂入新父、改 parent 指针；MERGE = 不冲突子树整棵 relink，同名冲突分支递归合并。
- 刷新 entry-to-node 目录，删除失效旧绑定，保持公式 1 一致。
- 此后 DSQ 即按新命名空间解析。
5.4 OpenViking 端到端集成闭环
viking:// URI 段 → trie 目录节点；记忆 / 资源 / 技能文件系统式组织；L0 摘要 / L1 概览 / L2 全文共享同一作用域；查询先递归 DSQ 圈范围 → 集内向量排序 / 聚合 → 按需向 L2 取证据 → 喂给 Agent/QA；重组走 DSM。
一句话总结
这篇论文的贡献不是 "新的向量排序算法"，而是指出向量库把层级目录拍平成字符串是一切读延迟与写放大的根源 ；它用 "可插拔作用域层 + 2 读 2 写原语" 把设计空间讲清，并证明原生前缀树（TrieHI）以可控的额外存储，换来递归查询免展开、子树搬迁只改祖先链的稳定低延迟，最终在 Agent 记忆（LOCOMO 准确率 24%→82%）和多跳 QA（HotpotQA 91% @0.23s）上拿到可落地收益。