跳到主要内容
Agent Memory ANN 系统

第9章：开放问题与研究方法论 —— 6 大未解问题展开 + 给研究者的工具箱

本模块的方法论章节。把前 8 章铺陈的 6 大未解问题（索引级生命周期、多 agent 一致性、异构存储分层、学习型 agent 索引、LLM-Memory 联合调度、标准化 benchmark）展开成可以直接做的论文 idea；并给一份做这块研究的方法论：怎么挑题、怎么 workload profiling、怎么设计 benchmark、怎么保证复现、怎么避开五个常见 pitfall。最后用'剪枝悖论 + Recall 悬崖'作为方法论范例完整复盘——从观察到 publishable claim 的完整路径。

研究方法论 开放问题 workload profiling benchmark 复现性 剪枝悖论 Recall 悬崖

前 8 章把 Agent Memory ANN 这片土地的地形和已建的城镇都标了出来。本章是这本”地图册”的最后一页——告诉你哪些是开荒地：还没被开垦、但工业落地已经在逼问的研究问题。本章分两段写：前半段把第 1 章学习路线里列出的 6 大未解问题逐个展开，给出**“问题定义 → 现有最近邻 → 切入点 → 论文级 contribution 雏形”**的完整路径；后半段是给做这块研究的人的方法论手册——怎么 profiling 你的 workload、怎么设计有区分度的 benchmark、怎么避开五个最容易踩的坑、怎么保证复现。最后用”剪枝悖论 + Recall 悬崖”作为完整的方法论范例（一组 100 行 Python 实验如何成为 SIGMOD 级别 claim 的素材）。本章不是结尾，是这个研究方向的”研究伊始”。

📑 目录

1. 六大未解问题逐个展开

第 1 章学习路线表里列出了 6 大未解问题，这里把每一个展开成可以直接立项的研究 idea。每个问题给四块内容：问题定义 / 现有最近邻 / 切入点 / 论文 contribution 雏形。

1.1 问题 1：索引级生命周期管理

问题定义： 现有 agent 框架（AgeMem / SimpleMem / MemOS）做”应用层遗忘”——决定哪些记忆该 discard。但 discard 之后，底层 ANN 索引并没有真正回收空间——还在用 tombstone。怎么让索引本身感知 lifecycle？

现有最近邻：

  • AgeMem（RL 决定 store/discard，但 ANN 不感知）
  • SimpleMem（应用层压缩，索引不变）
  • 本系列 Sieve 草案（模块十九讨论过的回收策略）

切入点：

  • “索引级 GC 触发器”：在 HNSW 内部加一层”被 discard 节点的影响”评估，定期触发物理删除
  • 比 MN-RU 更激进——不止”删除时保持可达”，而是”discard 之后图自我修复”

论文 contribution 雏形：

  • 理论：discard 速率 vs 索引退化的形式化关系
  • 算法：lifecycle-aware 物理删除策略
  • 系统：在 hnswlib / DiskANN 之上的插件实现
  • 实验：在长记忆 agent workload 下，相比 AgeMem-only 减少 X% 内存

⭐ 难度：中。⭐ 新颖度：高（没人做过）。⭐ 目标会议：SIGMOD / VLDB / OSDI。

1.2 问题 2：多 Agent 一致性

问题定义： 共享记忆下的并发修改语义没有标准定义。Token Coherence 给了 MESI 类比，但ANN 是近似的——可以用**“近似一致性”**节省协调开销。具体怎么定义？

现有最近邻：

  • Token Coherence (2026)：artifact-level，开销大
  • Multi-Agent Memory from CompArch Perspective (2026 vision)：纲领文章，无系统实现
  • 第 8 章第 10 节我们提出的 Recall-bounded 一致性 模型

切入点：

  • 形式化 (R, τ)-recall-bounded consistency：staleness τ 内 recall ≥ R
  • 设计实现：lazy invalidation + 周期性 quorum 检查
  • 在 d-HNSW / SHINE 之上实验

论文 contribution 雏形：

  • 理论：(R, τ) 上下界，给定 workload 参数
  • 协议：具体的同步协议（基于 RDMA atomics）
  • 实验：相比 strong consistency 减少 X% 协调开销，相比 eventual 提升 Y% recall

⭐ 难度：极高（需要理论功底）。⭐ 新颖度：极高（理论空白）。⭐ 目标会议：SOSP / NSDI / NeurIPS。

1.3 问题 3：异构存储分层

问题定义： DRAM、CXL、SSD、对象存储在 agent workload 下的最优放置策略是什么？现有方案（Milvus tiered storage, MemOS）用经验阈值，没有理论指导。

现有最近邻：

  • Milvus Tiered Storage（工业经验）
  • Soar (OSDI 2025)（针对通用 workload）
  • d-HNSW / SHINE 的 cache 协调（但只考虑两层）

切入点：

  • 多 agent 访问模式：每个 agent 的 hot/cold 模式不同，怎么联合优化？
  • 跨层迁移的代价模型：什么时候迁移划算？
  • 预测式预取：基于 agent 任务类型预测下一步需要的记忆

论文 contribution 雏形：

  • 算法：基于 agent profile 的多层放置策略
  • 系统：DRAM + CXL + SSD 三层 ANN 原型
  • 实验：相比单层方案，每查询代价降低 X%

⭐ 难度：中高。⭐ 新颖度：中（已有探索但未收敛）。⭐ 目标会议：FAST / EuroSys / ATC。

1.4 问题 4：学习型 Agent 索引

问题定义： Pancake 的 FSM 模式建模、Quake 的自适应分裂判定，都是启发式。能不能用神经网络学习”什么时候该做什么”？

现有最近邻：

  • GATE（学习 HNSW 入口点）
  • SOAR（学习 IVF 簇分配，OSDI 2025）
  • 没有任何 agent-specific 工作

切入点：

  • 可学习的退化预测器：用 GNN 在图结构上预测哪些区域将退化
  • 可学习的重建触发：替代经验阈值
  • 可学习的 agent 路由：每个 agent 用什么子图

论文 contribution 雏形：

  • 学习方法：图 NN + RL 联合训练
  • 系统集成：在 SPFresh / OdinANN 之上插件
  • 实验：相比经验阈值，recall-overhead Pareto 提升 X%

⭐ 难度：高（ML + 系统跨界）。⭐ 新颖度：高。⭐ 目标会议：MLSys / NeurIPS / ICML。

1.5 问题 5：LLM-Memory 联合调度

问题定义： LLM 推理时 GPU 有大量”空泡”（attention 计算等待数据 prefetch）。能不能把 ANN 搜索塞进这些空泡里？

现有最近邻：

  • RAGCache (2024)：投机预取，但只针对静态 RAG
  • HERMES：stage-level scheduling
  • 没有 agent-specific 联合调度

切入点：

  • CUDA stream 级别的协同：LLM kernel 和 ANN kernel 共享 SM
  • 预测式 ANN：在 LLM token-by-token 生成时，预测下一步会用哪些记忆
  • GPU 共享内存里的小型 HNSW：避免 GPU↔CPU 切换

论文 contribution 雏形：

  • 系统：联合调度器 + 内存复用
  • 实验：端到端 agent task 延迟降低 X%（注意：单独 ANN 优化和单独 LLM 优化都不够，联合优化才有显著收益）

⭐ 难度：极高（CUDA + 系统）。⭐ 新颖度：极高。⭐ 目标会议：OSDI / SOSP / MLSys。

1.6 问题 6：标准化 Benchmark

问题定义： Pancake 用自造 workload，A-MEM、MIRIX 各用各的评测，没有统一的”Agent Memory ANN benchmark”——大家的数字没法直接对比。

现有最近邻：

  • ANN-Benchmarks（静态 ANN 标杆，不含动态）
  • BigANN NeurIPS 2023 Challenge（含动态，但不 agent-aware）
  • LongMemEval / LoCoMo（应用层，不评估底层 ANN）

切入点：

  • 设计 AgentBench-Memory：包含
    • 多种 agent workload（chat / coding / planning）
    • 不同读写比、不同 agent 数
    • 含分布漂移、删除、共享场景
    • 统一指标：recall + latency + 内存 + 一致性

论文 contribution 雏形：

  • 这是个 benchmark + survey 风格的论文
  • 把 7-10 个系统跑一遍，给出 Pareto 矩阵
  • 暴露被现有评测漏掉的失败模式（剪枝悖论是典型）

⭐ 难度：中（工程量大但单点不难）。⭐ 新颖度：中（执行难度高于创新难度）。⭐ 目标会议：MLSys / NeurIPS Datasets and Benchmarks。

2. 研究方法论：怎么挑题

2.1 三条挑题原则

原则 1：从”工业落地遇到的真问题”反推研究问题

不要从论文出发——从”如果我是 Pinecone 的工程师，今天我会被什么 bug 烦死？“出发。具体动作：

  • 翻 Milvus / Qdrant / Pinecone 的 GitHub issues，看高频 complaint
  • 参加 vector database 会议（如 Vector Search Meetup）听工程师吐槽
  • 自己跑一个 100M 规模的 streaming workload，看哪里卡住

原则 2：从”理论空白”反推论文 idea

不是所有问题都有理论空白。检查方法：

  • 在 arXiv 搜 “X recall bound” / “X consistency theorem”，看 0 结果还是若干结果
  • 如果 0 结果，可能是空白，也可能是死胡同——读 1-2 篇相关 survey 判断
  • 如果是空白：进一步看是”工程上不需要理论”还是”理论本来该有但没人做”

🌟 关键判断：“工程上需要、理论上空白”是论文宝藏。本模块第 11 节的”Recall 悬崖”就是这种——工程上每个动态 ANN 系统都遇到，理论上没人量化。

原则 3：从”已有最近邻”反推”我的差异化”

任何论文 idea 都要做这个练习：

  1. 列出 3-5 篇最接近的最近邻论文
  2. 对每篇，写一句”它做了什么 + 没做什么”
  3. 你的 idea 应该恰好填补”没做什么”那一项
  4. 如果你的 idea 没法用一句话和最近邻区分，那它太相似，会被 reviewer 拒

2.2 三个”避坑” indicator

如果你的 idea 满足以下任一情况，警惕：

  • ⚠️ “我能让 X 快 1.5 倍” —— 1.5× 不够，工业界不会换技术栈。SIGMOD 级别至少要 3-5×，OSDI 级别要 10×+
  • ⚠️ “我把 A 和 B 结合一下” —— 组合性创新很容易被 reviewer 说”A + B 我也想得到”
  • ⚠️ “我加了一个机器学习模块” —— 除非 ML 是核心，否则 reviewer 会问”为什么不用启发式”

✅ 好 idea 的特征：

  • 用一句话能讲清楚”我做了什么、为什么没人做、为什么我能做”
  • 解决一个有”显示数字”的问题（如 “Pancake 论文里 82% 时间花在 ANN”）
  • 有反直觉的洞察（剪枝悖论、Recall 悬崖）

3. 工具箱 1：Workload Profiling

任何系统层 idea 落地前，先 profile 你想优化的 workload。这一节给你一个具体的 profiling 流程。

3.1 Profile 应该回答的 6 个问题

Q1: 读 vs 写的比例？             → 决定是优化搜索还是更新
Q2: 读的延迟 / 写的延迟分布？    → 决定是优化平均还是 tail
Q3: hot/cold 数据的分布？        → 决定是缓存还是分层
Q4: 单 vs 多 agent？             → 决定是单租户还是隔离
Q5: 库规模 / 增长率？             → 决定是单机还是分布式
Q6: SLA 边界（recall / latency）？→ 决定 Pareto 的目标点

3.2 实操：用 Mem-GPT 作 profiling 起点

# 一个最小的 profiling 实验
import time
import letta
import pandas as pd

# 启动 Letta + 默认 Chroma backend
client = letta.create_client()

# 模拟 100 步 agent 交互
events = []
agent = client.create_agent(name="profiler")
start = time.time()

for i in range(100):
    op_start = time.time()
    response = client.send_message(
        agent_id=agent.id,
        message=f"Discuss topic {i}: ..."
    )
    op_end = time.time()

    # 抓取 memory 操作的 trace
    trace = client.get_agent_traces(agent.id, last=1)
    events.append({
        "step": i,
        "total_ms": (op_end - op_start) * 1000,
        "llm_ms": trace.llm_time_ms,
        "memory_ms": trace.memory_time_ms,
        "ann_search_count": trace.ann_searches,
        "ann_insert_count": trace.ann_inserts,
    })

df = pd.DataFrame(events)
print(df.describe())
print(f"Memory operations占比: {df.memory_ms.sum() / df.total_ms.sum() * 100:.1f}%")

🌟 关键产出：这个 30 行脚本能告诉你当前你关心的 workload 里 ANN 操作占比是多少——如果 < 10%，你的优化重心不该在 ANN 上；如果 > 50%，恭喜，你站在 Pancake 论文的同一战壕。

3.3 进阶 profiling：抓取细粒度访问 trace

# Patch hnswlib 添加 trace（伪代码）
class TracedHNSW(hnswlib.Index):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.access_log = []   # 记录每次 search 访问的节点

    def search(self, query, k):
        # 用钩子记录每一跳的节点 ID
        ...

# 然后跑 workload，dump access_log，分析：
# - 节点访问频率分布（power law 还是 uniform）
# - 跨节点的访问模式（局部还是全局）
# - 时间局部性（最近访问的节点会再被访问吗）

这一步是所有 cache-aware 优化的前提——如果不知道访问分布，缓存策略只能瞎猜。

4. 工具箱 2：Benchmark 设计原则

4.1 一个合格 benchmark 的五要素

1. 真实的数据分布
   - 不要只用 SIFT-1M (uniform)；加 GloVe (skewed), LAION (clustered)

2. 真实的工作负载
   - 不要只测"100% search"；要混 80%/20% search/update

3. 显著区分度的指标
   - Recall@10, P99 latency, 内存占用 —— 三者一起报
   - 避免"平均"，多看 P99 和 P99.9

4. 公平的 baseline
   - 用对手的最佳参数（不是默认参数）
   - 自己的方法也用"工业可接受"的参数，不要 cherry-pick

5. 可重复
   - 固定 seed
   - 报告完整 config（M, ef, nlist, ...）
   - 公开代码（GitHub release）

4.2 容易被 reviewer 戳穿的几种 cherry-pick

  • ❌ 只在 SIFT 上测 —— “你换 GloVe 还成立吗？”
  • ❌ 只测 < 10M 规模 —— “你 100M 还行吗？”
  • ❌ 只报平均延迟 —— “P99 呢？”
  • ❌ 不报内存占用 —— “你 1.5× memory 换 1.5× QPS 不算赢”
  • ❌ 不报构建时间 —— “你建索引要 1 小时谁能用”

🌟 关键判断：写论文时假设 reviewer 是一个对你 idea 怀有敌意的工程专家。提前把这些问题答清楚。

4.3 几个标准 benchmark 工具

Benchmark用途覆盖范围
ann-benchmarks.com静态 ANN 标准单机 baseline
big-ann-benchmarks十亿级 ANN（NeurIPS Challenge）大规模 + 动态
VectorDBBench (Zilliz)端到端向量数据库工程 SLA 视角
LongMemEval / LoCoMoAgent Memory 应用层任务准确率
HuggingFace ann-evals多语言 / 多模态 embeddingembedding 模型 ablation

⭐ 2026 年趋势：这些 benchmark 都不够——多 agent / agent-aware 评测是 open question 6 的腹地。

5. 工具箱 3：复现性与开源

5.1 复现性是论文的”延寿剂”

很多看起来好的 idea，实际没人能复现——3 年后就被遗忘。做研究时把复现性当一等公民：

  • ✅ 代码公开：GitHub release，含 README + requirements.txt
  • ✅ 数据公开：放 HuggingFace Datasets 或 Zenodo
  • ✅ 环境固定：Docker image 或 conda env
  • ✅ seed 固定：跑 5 个 seed 报均值 + 方差
  • ✅ scripts 完整：一键脚本从 raw data 跑到论文 figure

5.2 一个典型的 reproducibility README 模板

# StreamBound v2 Reproduction Guide

## Setup
```bash
docker pull yourname/streambound:v2.0
docker run -it -v $(pwd)/data:/data yourname/streambound:v2.0

Data

  • SIFT-1M: download from ftp.irisa.fr/local/texmex/corpus
  • GIST-1M: …
  • Custom workloads: scripts/generate_workload.py

Running Experiments

# Pilot (Block 1): ~1 hour on A40
bash run_pilot.sh

# Full main results: ~12 hours
bash run_main.sh

# Ablations: ~24 hours
bash run_ablations.sh

Expected Outputs

  • results/pilot.csv: matches Table 2 in paper
  • results/main.png: matches Figure 5

Hardware Requirements

  • CPU: 32+ cores
  • RAM: 64 GB
  • GPU: optional (Adaptive-Monitor 实验用)

### 5.3 开源的额外好处

- 工业团队会主动接触你（论文影响力放大器）
- 跟进工作会引用你（h-index 涨）
- 代码被其他 benchmark 集成（更长尾的引用）

---

## 6. 五个最容易踩的坑

### Pitfall 1: 只看 Recall，不看 UR / SF

**症状**：实验显示 Recall 0.99，论文说"我的系统不退化"。
**真相**：UR 可能已经飙到 0.3+，你的图烂了你不知道。
**避免**：每次实验同时报 Recall + UR + SF。

### Pitfall 2: 用太"干净"的数据

**症状**：在 SIFT-1M（均匀分布）上做 streaming 实验，结论"系统鲁棒"。
**真相**：换 GloVe（偏斜）或聚类数据，立刻崩溃。
**避免**：至少 3 种分布的数据集（均匀 / 偏斜 / 聚类）。

### Pitfall 3: 不区分"插入"和"动态插入"

**症状**：声称"支持流式插入"。
**真相**：实测发现 100 次/秒 OK，1000 次/秒就崩。
**避免**：标明插入速率，并测试 10×, 100× 速率。

### Pitfall 4: 静态比较 vs 端到端比较

**症状**：单元测试：自己方法快 3×。
**真相**：端到端 agent task：因为别的 bottleneck，整体只快 1.1×。
**避免**：报告端到端 latency，不只是子模块。

### Pitfall 5: 对自己的方法用最佳参数，对别人的用默认

**症状**：自己方法 Recall 0.95，baseline 0.85，说"提升 10%"。
**真相**：baseline 调参后能到 0.93，差距其实只有 2%。
**避免**：对所有方法都做参数 sweep，报 Pareto 前沿。

🌟 **关键判断**：**这五个坑是顶会 reviewer 的"经典必问问题"**。如果你的论文回答不了这五个问题，重写。

---

## 7. 方法论范例：剪枝悖论的完整复盘

这一节用我们本系列的核心实证发现——**剪枝悖论**——作为方法论的完整范例。从 100 行 Python 实验如何成为 SIGMOD 级别 claim 的素材。

### 7.1 Stage A: 观察（30 分钟）

**起点**：我们想验证"在 HNSW 上做大量删除，Recall 会下降多少"。

```python
import hnswlib, numpy as np
from sklearn.neighbors import NearestNeighbors

# 加载 SIFT-1M（128d, 1M base + 10K queries）
xb = load_sift1m_base()
xq = load_sift1m_query()

# 建 HNSW
index = hnswlib.Index(space='l2', dim=128)
index.init_index(max_elements=1_000_000, M=16, ef_construction=200)
index.add_items(xb)
index.set_ef(100)

# 测初始 Recall
def measure_recall(index, queries, all_data, k=10):
    nn = NearestNeighbors(n_neighbors=k).fit(all_data)
    _, gt = nn.kneighbors(queries)
    pred, _ = index.knn_query(queries, k=k)
    return np.mean([len(set(p) & set(g)) / k for p, g in zip(pred, gt)])

print(f"初始 Recall@10: {measure_recall(index, xq, xb):.4f}")
# 输出：0.985

# 标记删除 50%
active = xb.copy()
for i in np.random.choice(len(xb), size=500_000, replace=False):
    index.mark_deleted(i)
    active = np.delete(active, i, axis=0)

print(f"删除 50% 后 Recall@10: {measure_recall(index, xq, active):.4f}")
# 输出：0.997  ← 反直觉！

反直觉发现：Recall 不降反升。

7.2 Stage B: 假设（30 分钟）

提出两个候选解释：

  • H1: hnswlib 内部的标记删除会跳过已删节点，搜索路径变短，“剪枝效应”提升结果质量
  • H2: 删除让搜索空间变小，剩余近邻更”显眼”

要选 H1 还是 H2，还需要一个额外信号——如果 H1 对，那图的连通性应该已经退化（不可达点会增加）。

7.3 Stage C: 验证（2 小时）

引入 UR (Unreachable Ratio) 作为图退化指标：

def compute_UR(index, all_data, sample_size=1000):
    # 采样 sample_size 个点，看搜索能否找回它们自己
    nn = NearestNeighbors(n_neighbors=1).fit(all_data)
    sample_ids = np.random.choice(len(all_data), sample_size, replace=False)
    unreachable = 0
    for i in sample_ids:
        pred, _ = index.knn_query(all_data[i:i+1], k=1)
        if pred[0][0] != i:
            unreachable += 1
    return unreachable / sample_size

print(f"删除 50% 后 UR: {compute_UR(index, active):.4f}")
# 输出：0.52  ← 52% 不可达！

验证 H1：Recall 上升的同时 UR 上升到 52%——图结构确实严重退化，但表面 Recall 反而更好。

7.4 Stage D: 抽象（1 天）

把这个观察抽象成一个普遍现象：

剪枝悖论（Pruning Paradox）：在 HNSW 上做标记删除，删除比例 ε 在 [0, ε*] 区间内，Recall 单调上升但 UR 单调上升。其中 ε* 为”拐点”（typically 60-70%），超过 ε* 后 Recall 崩溃。

为什么这个抽象重要：把”一个具体实验结果”升级为”一个值得论文讨论的现象”。任何能复述这个现象 + 给出几何/拓扑解释的论文，就有了 contribution 雏形。

7.5 Stage E: 引申到更大问题（1 周）

剪枝悖论引出了三个连锁问题：

  1. 监控盲点：所有用 Recall 做触发的动态 ANN 系统都被这个现象骗过——这是论文的核心 motivation
  2. 领先指标：什么指标能在 Recall 还在涨时就预警？答：UR
  3. 健康监控理论：能不能形式化 UR 和 Recall 退化之间的关系？答：定理 1 的雏形（参见模块二十二实验数据）

7.6 Stage F: 写成论文级 Claim（2 周）

最终 claim（投顶会的形式）：

Claim: 现有动态 ANN 系统（SPFresh, OdinANN, PipeANN）用 Recall 作为索引健康指标，这是欺骗性的——我们的实验展示了”剪枝悖论”现象：在标记删除主导的工作负载下，Recall 可以保持 0.99+ 同时图退化达到 52% 不可达。我们提出 UR 作为领先指标，并证明 UR-Recall 在多种数据集上 Pearson 相关 > 0.94。基于此构建了 StreamBound 健康监控框架，在 8 种策略对比中证明纯 Recall 触发的策略全部失败。

🌟 关键判断：这就是从”30 分钟实验”到”SIGMOD claim”的完整 5 阶段路径。每个研究 idea 都可以走这个流程。

7.7 这条路径的方法论提炼

Stage时间核心问题工具
A. 观察30 分钟”有没有反直觉？“一段 30 行 Python
B. 假设30 分钟”两个候选解释怎么区分？“思考 + 额外信号
C. 验证2 小时”我的假设对吗？“第二个独立实验
D. 抽象1 天”这是个普遍现象吗？“改变参数、数据集
E. 引申1 周”这能引出更大问题吗？“与其他工作联结
F. Claim2 周”怎么用一句话讲清？“找差异化、找对手

总耗时：约 3 周从观察到 publishable claim。这是做研究的”基础节奏”。

8. 给不同背景研究者的入门路径

8.1 你来自 ML / NLP 背景

  • 舒适区：embedding 模型、Agent 应用
  • 要补的功课：第 2-3 章（静态 + 动态 ANN）+ 模块十三 RDMA 基础
  • 最适合的开放问题：问题 4（学习型 agent 索引）、问题 5（LLM-Memory 联合调度）
  • 第一步：跑通 hnswlib 的”剪枝悖论”复现，建立”系统直觉”

8.2 你来自系统 / 数据库背景

  • 舒适区：HNSW、SPFresh 这类工程系统
  • 要补的功课：第 4 章（Agent Memory 应用层）+ 模块五（语义记忆）
  • 最适合的开放问题：问题 1（生命周期管理）、问题 3（异构存储）
  • 第一步：理解 agent workload 和 RAG workload 的根本差异

8.3 你来自 HPC / 硬件背景

  • 舒适区：RDMA、CXL、UB
  • 要补的功课：第 2-3-4 章全部
  • 最适合的开放问题：问题 3（异构存储）、问题 2（多 Agent 一致性）
  • 第一步：在 SKV 或 CloudLab 集群上跑 d-HNSW，理解 RDMA 在 ANN 上的具体影响

8.4 你来自理论 / 算法背景

  • 舒适区：分析、证明
  • 要补的功课：第 2-3 章 + 模块十九（实证审计方法论）
  • 最适合的开放问题：问题 2（一致性理论）、问题 6（benchmark）
  • 第一步：把”剪枝悖论”形式化为可证明的命题

8.5 你是博士生 / 想 1 年内出论文

  • 第一选择：问题 1（索引级生命周期）—— 工程量适中、新颖度高、有现成 baseline
  • 第二选择：问题 6（benchmark）—— 工程量大但单点不难，1 篇 paper 一年内可达
  • 避免：问题 2（一致性）—— 理论难度太大，容易卡 1-2 年没产出

✅ 自我检验清单

  • 六大问题：能口述 6 大未解问题各自的”问题定义 + 切入点 + 目标会议”
  • 挑题原则：能用”工业痛点 + 理论空白 + 差异化”三条原则评价一个候选 idea
  • Profiling：能用 30 行代码 profile 一个 agent workload 的 ANN 操作占比
  • Benchmark 五要素：能列出真实数据 / 真实负载 / 显著指标 / 公平 baseline / 可重复
  • 五大坑：能复述这五个 reviewer 必问的”避坑 checklist”
  • 剪枝悖论 6 阶段：能复述从 30 分钟实验到 SIGMOD claim 的 6 个阶段
  • 入门路径：根据自己的背景，能说出最适合自己切入的 2 个开放问题

📚 参考资料

概念入门

工具与 benchmark

关键论文（按问题归类）

问题 1（生命周期）：

问题 2（一致性）：

问题 3（异构存储）：

问题 4（学习型索引）：

  • GATE（学习 HNSW 入口）
  • SOAR (OSDI 2025)（学习 IVF 簇分配）

问题 5（LLM-Memory 联合调度）：

问题 6（Benchmark）：

  • LongMemEval / LoCoMo —— 应用层
  • 本模块开放问题——“AgentBench-Memory”还没人做

Surveys

行业讨论 / 顶会论文 trends

  • 2025-2026 ANN 相关顶会论文集：
    • OSDI 2025: PipeANN, Quake, Soar
    • SOSP 2023-2024: SPFresh
    • FAST 2026: OdinANN
    • SIGMOD 2024-2025: RaBitQ, Extended-RaBitQ, Tagore, HARMONY, GaussDB-Vector
    • NeurIPS 2025: Distance Adaptive Beam Search, Mishra et al. dynamic ANN
    • HotStorage 2025: d-HNSW

本系列其它章节