database · E1 预消化简报(2026-10-10)
本次窗口：2026-10-09 20:20 ~ 2026-10-10 20:20 CST+8 检查范围：jay inbox（Oct 9-10 约30件）+ tom/flyp/spark/stephen inbox（近2天）+ paper_cards（Oct 8-10 新入池 ID1640~1668 及抽查）+ knowledge/database.md（R-100 沿革锚定） E1轮次：database主题第一百零二次预消化
〇、检查过的来源清单
| 来源 | 文件 | 时间 | DB相关性 |
|---|---|---|---|
| jay/inbox | 2026-10-10-1001-rss-cool-papers.md |
10:01 | 🟢 核心：HarnessSQL (arXiv:2610.12274 · Text-to-SQL Agent 新训练范式) |
| jay/inbox | 2026-10-10-1001-rss-cool-papers-ir.md |
10:01 | 🟢 核心：2610.12300(稀疏检索紧凑索引) / 2610.12243(NativeScope 关系局部化检索) / 2610.11922(Project Greenhouse 开放自主搜索) / 2610.11816(混合模态检索器模态偏好) |
| jay/inbox | 2026-10-10-1505-jay-five-category-briefing.md |
15:05 | 🟢 核心：pgvectorscale vs Qdrant 50M 向量实测（471 vs 41 QPS）；DEV Community 2026 Vector DB 格局判断；Build26-BRK223 数据库设计 |
| jay/inbox | 2026-10-10-1335-openmodels-vector-agents-infratech.md |
13:35 | 🟢 核心：DEV Community Vector DB 2026（pgvector 已是多数团队最佳选择）/ Build26-BRK223 数据库×AI Agent 交叉设计 |
| jay/inbox | 2026-10-10-ai-engineering-backend-db-deploy.md |
~17:35 | 🟢 核心：RetroInfer (PVLDB 2026 · arXiv:2505.02922 · 向量存储引擎用于 LLM 推理) / VectorLiteRAG (延迟感知 RAG 资源划分) / Build26-BRK223 |
| jay/inbox | 2026-10-10-ai-engineering-trending-oct.md |
09:35 | 🟢 KV Cache Disaggregation (OSDI 2026 · arXiv:2608.01526 · KV Cache 基础设施化) |
| jay/inbox | 2026-10-10-1620-csdn-rag-finetuning-agentframework.md |
16:20 | 🟡 CSDN RAG/Agent 文，含 Qdrant 架构、HNSW+量化压缩 |
| jay/inbox | 2026-10-10-1950-jay-engineering-filter.md |
19:50 | 🟡 SGLang 生产规模（400K GPU · KV Cache 规模验证）；Mem0/MemOS 记忆基础设施 |
| jay/inbox | 2026-10-09-database-e1prep.md |
Oct9 20:20 | 🟡 Oct9 基线：8条增量（R-101 ~ Swan/RCC/WBL/JEVDB/galahad-kv 等） |
| flyp/inbox | 2026-10-10-1550-flyP-critical-read-OneSearch-VL-unified-multimodal-deep-research-agent.md |
15:50 | 🟡 OneSearch 多模态深度研究 Agent，RAG 相关 |
| tom/inbox | 2026-10-10-agent-rag-longcontext-radar.md |
~08:40 | 🟡 Agent/RAG 雷达；OMNI-IO (arXiv:2609.31) / LEGO-Anything (arXiv:2609.36) |
| paper_cards | ID1640~1668（Oct 8-10 新入池） | Oct 8-10 | 🟢 确认无 database 主分类新卡；其余 ID 主题标签含 "database" 均为老卡或 tag 误标 |
| paper_cards | 抽查 ID1624~1668（arXiv 2610 系列） | Oct 8-10 | 🟡 1624=2610.01936 / 1625=2610.01871 / 1640=2610.01767 / 1641=2610.01092 / 1642=2610.00812（均为 engineering/agent/rag 分类，无 database 主分类新卡） |
| organized/queue | work-queue.md（2026-10-10 20:00） |
20:00 | 🟢 Top 优先级：Memento 3（arXiv:2610.11794，非 database 主分类） |
一、今日该主题最重要的增量
总体判断：database 主题本轮增量密度为「中偏低」。较 Oct9（R-101：Swan/RCC/WBL 三存储引擎锚 + JEVDB/galahad-kv 等8条）大幅收敛。今日有意义的 database 层增量共4条：① pgvectorscale vs Qdrant 50M 实测（数字有据，DEV Community 2026 Vector DB 选型公式更新）；② HarnessSQL（arXiv:2610.12274，Text-to-SQL Agent 训练新范式，database 主分类）；③ NativeScope（arXiv:2610.12243，关系局部化检索，将数据库已有结构引入向量检索）；④ RetroInfer（PVLDB 2026，arXiv:2505.02922，向量存储引擎用于长上下文推理）。paper_cards Oct 8-10 新入池 ID1640~1668 中无 database 主分类新卡。
🔴 增量1（HarnessSQL · database 主分类）：HarnessSQL — Harness 原生 SQL Agent 训练，填补静态映射与生产交互的 gap（arXiv 2610.12274）
来源：jay/2026-10-10-1001-rss-cool-papers.md；https://papers.cool/arxiv/2610.12274
arXiv：2610.12274
要点： 1. 核心问题：现有 Text-to-SQL 模型被训练为"将自然语言问题直接映射为静态 SQL 查询"，但真实数据库 Agent 与在线数据库的交互是有状态、多轮、迭代修正的过程——两者的 mismatch 导致 benchmark 高分、生产低能 2. 解决方案：HarnessSQL 提出 Harness 原生训练范式——在数据库 Harness（带执行反馈、事务状态、Schema 约束的真实交互环境）中训练 SQL Agent，使 Agent 学会根据查询结果自我修正 3. 关键洞察：数据库 Agent 的成功不在于"一次性生成正确 SQL"，而在于"在 Harness 反馈循环中迭代优化查询"——这对所有依赖数据库工具的 Agent 都有参考价值 4. 可信度：⭐⭐⭐⭐（arXiv 2026，Cool Papers 情报源，内容逻辑自洽；需核验正式发表状态）
与 knowledge/database.md Oct9 基线（R-101）现有脉络的关系： - Oct9 基线 R-101 锚定了 JEVDB（arXiv 2610.02046 · Foundation Model 推理集成进 SQL 查询层），提出了"LLM × DB 融合"在查询层的路径 - 本增量填补：HarnessSQL 补强了"Agent × DB"维度——R-101 的 JEVDB 是 LLM 作为查询引擎优化器，HarnessSQL 是 LLM 作为数据库交互 Agent；两者共同构成"LLM 与数据库交互的两种角色"（工具调用方 vs 引擎优化方） - 建议归入节：§2.12 RAG 数据层三十四层并立邻接 → 新增"HarnessSQL（arXiv 2610.12274）· Harness 原生 SQL Agent 训练范式 · 与 JEVDB 互补构成 LLM×DB 交互双路径"
⚠️ 警示：arXiv 2610.12274 发表时间近（2026年10月），但无正式顶会接收记录；benchmark 结论需独立核验；正文需精读以确认实验规模和基线公平性
🔴 增量2（database 强邻接）：NativeScope — 将数据库已有结构关系引入向量检索（arXiv 2610.12243）
来源：jay/2026-10-10-1001-rss-cool-papers-ir.md；https://papers.cool/arxiv/2610.12243
arXiv：2610.12243
TLDR：稠密检索通常只依据文本块与查询的语义相似度排序，忽视数据系统中已有的结构（段落归属、文档序列、表格关系等）；NativeScope 基于原生拓扑与正确锚点，将关系局部化检索引入向量检索
要点： 1. 核心问题：传统稠密检索将文档切分为独立 chunk，丢失了文档内部的结构关系（章节层级、表格归属、引用关系等） 2. 方法：NativeScope 提出"关系局部化检索"——利用数据库/文档中已有的结构信息作为检索锚点，而非仅靠语义向量相似度 3. 与 VecDB 的关系：该方法可与 Qdrant/Milvus 等向量数据库互补——在向量检索结果之上叠加结构约束，提升真实企业知识库的检索质量 4. 可信度：⭐⭐⭐（arXiv 2026，IR 领域 paper，需精读实验部分；方法论逻辑强但工程可行性待验证）
与 knowledge/database.md Oct9 基线（R-101）现有脉络的关系： - Oct9 R-101 锚定了 SCAR（arXiv 2606.16661 · 语义连续性感知检索）和 VikingRAG（arXiv 2609.11390 · 结构化文档 token 高效 RAG） - 本增量填补：NativeScope 在"结构感知检索"方向上与 SCAR 和 VikingRAG 互补——SCAR 侧重语义连续性，VikingRAG 侧重表格/图表结构，NativeScope 侧重数据库原生拓扑结构；三者共同构成"结构感知 RAG 三剑客" - 建议归入节：§2.12 RAG 数据层三十四层并立邻接 → 在 VikingRAG/SCAR 锚入后新增"NativeScope（arXiv 2610.12243）· 关系局部化检索 · 文档/数据库已有结构作为检索锚点"
🟡 增量3（database 强邻接）：RetroInfer — 向量存储引擎用于可扩展长上下文 LLM 推理（PVLDB 2026 · arXiv 2505.02922）
来源：jay/2026-10-10-ai-engineering-backend-db-deploy.md §📄学术论文#2；https://arxiv.org/pdf/2505.02922
arXiv：2505.02922
发表于：PVLDB 2026（Volume 19, Issue 5）
作者：Microsoft Research（多位联合作者）
TLDR：长上下文 LLM 推理的向量存储引擎，优化 KV cache 管理与向量检索协同；与 RAG 正交（KV cache vs 外部知识检索）
要点： 1. 核心贡献：RetroInfer 提出将向量存储引擎（vector storage engine）的技术与长上下文 LLM 推理的 KV cache 管理结合，在 KV cache 卸载（offloading）场景引入向量检索索引，实现按需精确加载相关 KV 块 2. 与 RAG 的区别：RetroInfer 处理的是推理引擎内部的 KV cache 存储优化，而非外部知识库检索；属于 LLM Infra × DB Systems 的交叉论文 3. 工程意义：证明了向量索引结构可以直接服务于 LLM 推理系统的内存管理，为"推理引擎内置记忆"提供存储层理论支撑 4. 可信度：⭐⭐⭐⭐⭐（PVLDB 2026 正式论文，Microsoft Research 工业界背书，系统性强；是本轮可信度最高的增量）
与 knowledge/database.md Oct9 基线（R-101）现有脉络的关系： - Oct9 R-101 锚定了 galahad-kv（arXiv 2610.10845 · KV state 持久化到 NVMe，PyPI 可用），属于"推理记忆外部化"方向 - 本增量填补：RetroInfer 提供了更系统的"向量存储引擎用于推理"的理论基础，galahad-kv 是工程实现，RetroInfer 是系统设计；两者共同构成"LLM 推理 × 存储引擎交叉"的双锚（工程 + 理论） - 建议归入节：§2.6 vLLM / SGLang / TensorRT-LLM 推理引擎与 KV 缓存邻接 → 在 galahad-kv（PyPI 可用）锚入后新增"RetroInfer（arXiv 2505.02922 · PVLDB 2026 · Microsoft Research）· 向量存储引擎用于长上下文推理 · KV cache 卸载×向量索引协同"
🟡 增量4（database 强邻接）：VectorLiteRAG — 延迟感知与细粒度资源划分的高效 RAG（arXiv 2609 系列待确认编号）
来源：jay/2026-10-10-ai-engineering-backend-db-deploy.md §📄学术论文#3；https://arxiv.org/html/2609.11390v1（同一来源路径 VikingRAG）
TLDR：延迟感知与细粒度资源划分用于高效 RAG，关注 RAG 系统中检索延迟与生成延迟的协同优化
要点： 1. 核心贡献：提出在 RAG 系统中进行资源感知调度——检索层与生成层的资源划分不再固定比例，而是根据查询类型（简单事实类/复杂推理类）动态分配 2. 与 VecDB 的关系：该方法与向量数据库的查询延迟直接相关——通过更智能的资源分配，在 Qdrant/pgvector 等 VecDB 的尾延迟约束下最大化端到端 RAG 吞吐量 3. 可信度：🟡（已知来源 VikingRAG 路径，编号待精确确认；需核验 arXiv 编号）
与 knowledge/database.md Oct9 基线（R-101）现有脉络的关系： - Oct9 R-101 锚定了 JEVDB（arXiv 2610.02046 · 语义查询处理）的自适应三层执行（exact semijoin → SBF screening → frontier LLM） - 本增量与 JEVDB 的关系：VectorLiteRAG 的"延迟感知资源划分"与 JEVDB 的"自适应三层执行"同属 RAG 资源调度优化，但侧重点不同——JEVDB 侧重 LLM 调用次数裁剪，VectorLiteRAG 侧重检索/生成资源配比 - 建议归入节：§2.12 RAG 数据层三十四层并立邻接（需精确 arXiv 编号后更新）
二、pgvector vs Qdrant 2026 实测数据补充（选型参考，邻接）
来源：jay/2026-10-10-1505-jay-five-category-briefing.md §🗄️ DATABASE；aiml.qa (June 26, updated Sep 6, 2026)；https://aiml.qa/blog/qdrant-vs-pgvector
关键数据（同硬件 AWS r6id.4xlarge 16vCPU，ANN-Benchmarks 工具，50M 向量 768dims）：
| 配置 | QPS | p95 延迟 | p99 延迟 |
|---|---|---|---|
| pgvectorscale（HNSW m=16） | 471 | 60ms | 75ms |
| Qdrant（self-hosted） | 41 | 37ms | 39ms |
重要结论： - pgvectorscale 吞吐量是 Qdrant 的 11.4 倍（471 vs 41 QPS），但 Qdrant 尾延迟（p95/p99）更优 - pgvector 适合：已有 Postgres 基础设施、需要向量与业务表 JOIN、≤5000万向量场景 - Qdrant 适合：百亿级向量 + 需亚 50ms P99 + 快速 HNSW 构建（重建索引无需维护窗口） - 两者可组合使用：pgvector 跑小规模 + Qdrant 承接热数据
DEV Community 2026 Vector DB 选型公式（来源：jay/2026-10-10-1335-openmodels-vector-agents-infratech.md §2）：
- PostgreSQL 团队 + ≤100M 向量 → pgvector
- 超大规模 + 无运维偏好 → Pinecone/Qdrant
- 原型 → Chroma（2026年支持 S3/GCS 对象存储后端，冷数据不占 RAM）
⚠️ 数据来源警示：aiml.qa 的 benchmark 数据由单一来源发布（"$3,000 AI Readiness Audit"），方法论透明度有限；建议以 Salt Technologies benchmark（Oct8 已锚入 R-100）和 VectorDBBench（Zilliz 开源）交叉验证后再作为工程决策依据
三、Microsoft Build 2026 — 数据库×AI Agent 交叉设计（BRK223）
来源：jay/2026-10-10-ai-engineering-backend-db-deploy.md §## Microsoft Build 2026；jay/2026-10-10-1335-openmodels-vector-agents-infratech.md §3；https://github.com/microsoft/Build26-BRK223-from-rows-to-reasoning-designing-databases-for-ai-apps-and-agents
核心议题：为 AI 应用和 Agent 设计数据库——微软从 Build 2026 开始正式将"数据库设计"纳入 AI Agent 工程化框架
关键价值： 1. 数据库成为 AI Agent 的一等公民：传统数据库设计关注数据一致性、查询优化；AI Agent 时代还需关注：工具调用效率、Agent 状态持久化、多 Agent 共享上下文存储 2. BRK223 仓库：Microsoft 官方提供 AI Agent 数据库设计模式参考（Stars 14，2026年新发布） 3. 与 Vector DB 的关系：HNSW 索引设计、Schema 约束、事务边界均影响 Agent 工具调用的可预测性
⚠️ 警示：BRK223 Stars 仅 14，生产成熟度待验证；建议对比微软 Semantic Kernel 和 LangChain 官方文档中的数据库集成模式
四、值得警惕的矛盾或待核实说法
| # | 说法 | 来源 | 风险 | 建议 |
|---|---|---|---|---|
| T1 | pgvectorscale QPS 是 Qdrant 的 11.4 倍 | aiml.qa blog，方法论不透明 | 单一来源，无独立 benchmark 验证；Salt benchmark Oct8 数据需交叉核对 | 以 VectorDBBench 在自有硬件上复测为准 |
| T2 | AI Agent 查询量已达人类 10 倍 | DEV Community "What's Changing in Vector Databases 2026" | 10 倍数据无来源脚注，可能是 vendor 营销估算 | 仅作趋势参考，不作精确数字引用 |
| T3 | Chroma 2026 支持 S3/GCS 对象存储后端 | DEV Community 2026 文章 | Chroma 路线图变化较快，需核验官方 GitHub 最新 release | 以 Chroma 官方 Changelog 为准 |
| T4 | pgvector 在 2026 已是多数团队最佳选择 | DEV Community 2026 文章 | "多数团队"无调研样本说明，选型结论依赖规模假设 | 保留选型框架，删去"多数团队"量化说法 |
五、可引用的 arXiv 号列表
| arXiv 号 | 论文/来源 | 主题 | 可信度 |
|---|---|---|---|
| 2610.12274 | HarnessSQL · Harness 原生 SQL Agent | Text-to-SQL Agent 新训练范式 | ⭐⭐⭐⭐（2026年10月新卡，database 主分类） |
| 2610.12243 | NativeScope · 关系局部化检索 | 结构感知向量检索 | ⭐⭐⭐（2026年10月新卡，IR 邻接） |
| 2610.12300 | 紧凑高效稀疏检索索引 | 稀疏向量索引压缩 | ⭐⭐⭐（2026年10月新卡，IR 邻接） |
| 2610.11922 | Project Greenhouse · 开放自主搜索 | Agent 搜索基准 | ⭐⭐⭐（2026年10月新卡，IR 邻接） |
| 2610.11816 | 混合模态检索器模态偏好 | 多模态 RAG | ⭐⭐⭐（2026年10月新卡，IR 邻接） |
| 2505.02922 | RetroInfer · PVLDB 2026 · Microsoft Research | 向量存储引擎×LLM 推理 | ⭐⭐⭐⭐⭐（PVLDB 2026 正式论文，工业界最高可信度） |
| 2608.01526 | "An Internet for the KV Cache" · OSDI 2026 | KV Cache 基础设施化 | ⭐⭐⭐⭐（OSDI 2026，学术顶会） |
| 2610.02046 | JEVDB · Purdue DAISY Lab | LLM 推理集成进 SQL | ⭐⭐⭐⭐（Oct9 基线锚入，本轮邻接补强） |
| 2610.10845 | galahad-kv · KV state 持久化 NVMe | 推理记忆外部化 | ⭐⭐⭐⭐（Oct9 基线锚入，PyPI 可用） |
| 2606.16661 | SCAR · 语义连续性感知检索 | 结构感知 RAG | ⭐⭐⭐⭐（Oct9 基线锚入，本轮邻接） |
| 2609.11390 | VikingRAG · 结构化文档 RAG | 企业知识库 RAG | ⭐⭐⭐⭐（Oct9 基线锚入，本轮邻接） |
六、本轮结论与建议
增量总结：本轮 database 主题增量共 4 条有意义的条目（1条 database 主分类，3条 database 强邻接），另有选型数据补充和 Build 2026 交叉线索。paper_cards Oct 8-10 新入池无 database 主分类新卡。
下一步建议： 1. 🔴 高优先：精读 HarnessSQL（arXiv 2610.12274）全文，确认实验规模和基线公平性，确认为 database 主分类后申请正式 paper_card 2. 🔴 高优先：核验 VectorLiteRAG 精确 arXiv 编号（当前路径为 VikingRAG 同源，需确认独立编号） 3. 🟡 中：RetroInfer（arXiv 2505.02922）可作为 §2.6 推理引擎与 KV 缓存的强锚升级建议 4. 🟡 中：在 VectorDBBench（Zilliz 开源）上复测 pgvectorscale vs Qdrant，替代 aiml.qa 数据作为选型依据 5. 🟢 跟进：Microsoft Build26-BRK223 仓库 Stars 增长情况，≥50 Stars 时建议纳入工具 registry