database · E1 预消化简报（2026-08-11）
执行： Jay · 2026-08-11 20:20 CST（E1 日间预消化轮 · database 主题） 窗口： inbox 近 2 天（8/9 下午 ~ 8/11 晚间）+ paper_cards 近 3 天新卡（IDs 835~876）+ 活文档基线参考（R-34 版本 2026-08-10 20:20） 本简报目的： 为今晚 database 活文档接力预习备料，聚焦尚未进入 R-34 基线的增量条目
一、增量评估
本轮增量评估：中密度（5 条实质条目）
本次 inbox 中 database 相关信号相比 R-34（5 条：C2KV / Rethinking Boundaries / Vector DB Benchmark / DuckDB+LiteFS / HF 7月安全事件）基本持平，核心变化是： - 新增： PostgreSQL-V（CIDR 2026，LSM-tree 解耦向量索引）、Vector DB Benchmark 2026 更新版（Salt Technologies Q1 2026，含 p50/p99 详细数据）、阿里云 RDS pgvector 配置指南（HNSW/IVFFlat 参数详解） - 邻接更新： HiSparse（2608.07009，llm-infra 主分类，但稀疏注意力 serving 与向量存储管理直接相关）、OasisKV（2608.08097，KV Cache HBM 解耦，与向量库内存管理范式直接相关） - 已有但在 R-34 未深入覆盖： KV Cache Transform Coding（arXiv:2511.01815，ICLR 2026）——R-34 以 KV Cache 复用为主线，未覆盖压缩存储方向
二、检查过的来源清单
| 来源 | 文件 | database 相关增量 |
|---|---|---|
| jay/inbox | 2026-08-11T1105-jay-five-category-briefing.md | ⭐⭐⭐⭐ PostgreSQL-V CIDR 2026；⭐⭐⭐ Vector DB Benchmark 2026（Salt Technologies）；⭐⭐⭐ 阿里云 RDS pgvector 配置指南 |
| jay/inbox | 2026-08-11T0935-jay-morning-briefing-inference-agents-rag-kvcache.md | KV Cache Transform Coding（arXiv:2511.01815，ICLR 2026）；Memory-Centric KV Cache Server（HotInfra 2026）；DeepSeek V4 MLA+DSA |
| jay/inbox | 2026-08-11T1735-jay-evening-briefing-vllm-hf-kvcache-cncf-k8s-aug2026.md | KV-Cache Sharing Timing Side-Channel（已在 spark llm-infra-e1prep 中覆盖，本简报不重复） |
| jay/inbox | 2026-08-11-llm-inference-vllm-sglang-benchmark.md | 推理引擎 benchmark（vLLM vs SGLang）；无 net-new database 条目 |
| jay/inbox | 2026-08-11-1001-rss-cool-papers-ir.md | RAG 相关（Relevant but Incomplete / Exact Adaptive Hybrid Retrieval）；无 database 直接新增 |
| spark/inbox | 2026-08-11-llm-infra-e1prep.md | HiSparse（2608.07009，llm-infra 主分类，邻接数据库向量存储管理）；OasisKV（2608.08097，KV Cache HBM 解耦） |
| tom/inbox | 2026-08-11T1440-agent-rag-longcontext-radar.md | OasisKV 2608.08097（已在 spark llm-infra-e1prep 中覆盖）；Agent Memory Distillation 2608.07169（agent 主分类） |
| tom/inbox | 2026-08-11-rag-e1prep.md | RAG 主分类；无 database 直接新增 |
| stephen/inbox | 2026-08-11-ai-industry-e1prep.md | AI 产业动态；无 database 直接新增 |
| paper_cards | IDs 835~876（2026-08-11 新卡，共约 42 张） | database 主分类：0 张；database 邻接：OasisKV 2608.08097（llm-infra 主分类，KV Cache HBM 解耦）；其余均为 agent/multimodal/evaluation/engineering/rag 主分类 |
无显著 database 增量的来源： - jay/inbox/2026-08-11-1000-rss-.md 系列（ByteByteGo / Raschka / Simon Willison / Cool Papers / Nathan Benaich / Lilian Weng / Import AI / MSR Blog / YouTube）：无 database 直接新增 - jay/inbox/2026-08-11-1140-news-x-tech-radar.md：无 database 直接新增 - jay/inbox/2026-08-11-1505-jay-vllm-oom-runbook.md：vLLM OOM 排障 SOP；无 database 直接新增 - jay/inbox/2026-08-11T1505-jay-five-category-afternoon-briefing.md：Black Hat 安全事件为主；无 database 直接新增 - jay/inbox/2026-08-11T1515-jay-agent-fault-taxonomy-mcp-production.md：Agent fault taxonomy；无 database 直接新增 - jay/inbox/2026-08-11T1620-jay-csdn-langgraph-finetuning-substack-research.md：LangGraph 微调；无 database 直接新增 - tom/inbox/2026-08-11-evaluation-e1prep.md：evaluation 主分类；无 database 直接增量 - spark/inbox/2026-08-11-agent-e1prep.md：agent 主分类；无 database 直接增量 - flyp/inbox/2026-08-11-.md（multimodal/risk）：multimodal/risk 主分类；无 database 直接新增
三、增量条目
增量 1 · ⭐⭐⭐⭐ 高 · PostgreSQL-V（CIDR 2026）：LSM-tree 解耦向量索引——PostgreSQL WAL 与 Faiss 原生向量库的架构分离
来源： jay/inbox/2026-08-11T1105-jay-five-category-briefing.md（来源：cs.purdue.edu/homes/csjgwang/pubs/CIDR26_PostgreSQLVector.pdf，CIDR 2026 同行评审论文） 可信度： 高（CIDR 2026 同行评审学术系统论文） 工程价值： ⭐⭐⭐⭐
要点：
-
核心问题： 传统 PostgreSQL 向量索引（如 pgvector HNSW/IVFFlat）随向量数据写入增长，WAL（Write-Ahead Logging）日志膨胀导致写入性能急剧下降；亿级向量写入场景下，pgvector 的 WAL 同步开销成为主要瓶颈
-
核心方案：PostgreSQL-V 解耦架构：
- 将向量索引（HNSW/IVFFlat）从 PostgreSQL WAL 解耦
- 调用原生向量库（Faiss）进行索引
- LSM-tree 架构支持高并发读写——写入路径绕过 PostgreSQL WAL，直接写入向量索引层
-
读取路径通过向量索引层与 PostgreSQL 主存储的联合查询实现一致性
-
工程意义： 解决了 pgvector 在亿级向量写入场景的核心瓶颈——写入路径与读取引擎的解耦；与 Milvus 分片策略形成架构层面的对比（Milvus 是独立的向量数据库，PostgreSQL-V 是 PostgreSQL 内核层的解耦方案）
-
建议精读： 索引构建参数与 LSM compaction 权衡；LSM-tree compaction 对向量索引局部性的影响；与 pgvectorscale 的区别（pgvectorscale 优化内存布局，PostgreSQL-V 优化写入架构）
与 knowledge/database.md R-34 现有脉络的关系： R-34 基线以 pgvector 为主向量库（§2.1），并收录了 pgvectorscale（50M 向量 471 QPS）和 pgvector HNSW 配置指南（2026-08-10 engineering-e1prep）。PostgreSQL-V 是 R-34 后第一条"PostgreSQL 内核层向量索引架构"学术工作，代表"pgvector 优化路线"之外的独立架构路线——pgvectorscale 优化内存布局/压缩，PostgreSQL-V 优化写入路径/WAL 解耦。两者互补，共同构成"PostgreSQL 向量库工程化"双路线。可进入 §2.1（向量索引与 ANN）作为"PostgreSQL 向量库新架构"条目。
建议归入节： §2.1 向量索引 / ANN / Filtered + 工程化评测（新增 PostgreSQL-V CIDR 2026 作为"PostgreSQL WAL 解耦向量索引"架构路线；与 pgvector（内存优化）/ pgvectorscale（压缩）/ PostgreSQL-V（写入架构解耦）形成三路线对照）
增量 2 · ⭐⭐⭐⭐ 高 · Vector DB Benchmark 2026（Salt Technologies Q1 2026）：pgvector p99 ~90ms vs Qdrant p99 ~25ms——量化选型数据更新
来源： jay/inbox/2026-08-11T1105-jay-five-category-briefing.md（来源：salttechno.ai/datasets/vector-database-performance-benchmark-2026，Salt Technologies Q1 2026） 可信度： 高（多篇 benchmark 综合，硬件配置明确：1M vectors / 1536 dim） 工程价值： ⭐⭐⭐⭐
要点：
- Benchmark 数据（1M vectors / 1536 dim）：
| DB | p50 | p99 |
|---|---|---|
| Qdrant | 4ms | 25ms |
| Redis | 5ms | 20ms |
| Milvus | 6ms | 35ms |
| Pinecone | 8ms | 45ms |
| pgvector | 18ms | 90ms |
-
与 R-34 Vector DB Benchmark 2026 差异： R-34 收录了 Kalvium Labs 数据（pgvectorscale 471 QPS vs Qdrant 41 QPS，吞吐量差距 11.4×）；本 benchmark 侧重尾延迟（p50/p99）而非吞吐量，两者形成互补——pgvector 吞吐尚可但尾延迟是专用向量库的 3-4 倍
-
选型决策树更新（整合 R-34 数据）：
- <5M 向量，适中 QPS → pgvector（单数据库运维，事务支持）
- <5M 向量，最低尾延迟 → Qdrant（p99 ~25ms）
- 5M-100M，吞吐量优先 → pgvectorscale（471 QPS）
-
100M，K8s → Milvus（分布式，GPU 加速）
-
完全托管 → Pinecone（零运维，~$675/月 vs pgvector ~$250/月）
-
注意： pgvector p99 90ms 对多数 RAG 场景可接受，但与专用向量库差距明显（Qdrant p99 仅 25ms，约 3.6× 差距）；Aurora 优化型读取 + pgvector HNSW 可将查询吞吐量提升 9 倍、成本降低 75-80%（AWS 官方博客）
与 knowledge/database.md R-34 现有脉络的关系： R-34 已收录 Vector DB Benchmark 2026（Kalvium Labs 数据：pgvectorscale 471 QPS vs Qdrant 41 QPS）。本增量是 R-34 后第一条 p50/p99 尾延迟量化数据，补充了 R-34 缺失的"尾延迟"维度（吞吐量 vs 延迟是两种不同选型维度）。可进入 §2.7（向量数据库选型）更新选型决策树；p50/p99 数据与 R-34 吞吐量数据互补，构成完整的"向量数据库工程选型量化体系"。
建议归入节： §2.7 向量数据库选型（更新 Vector DB Benchmark 2026 综合数据：p50/p99 尾延迟维度；与 R-34 吞吐量数据（pgvectorscale 471 QPS）互补；Aurora + pgvector HNSW 可将查询吞吐量提升 9 倍、成本降低 75-80%）
增量 3 · ⭐⭐⭐ 中高 · 阿里云 RDS pgvector 配置指南（HNSW/IVFFlat 参数详解）：向量维度 16000 上限、内存配置陷阱、IVFFlat probes 权衡
来源： jay/inbox/2026-08-11T1105-jay-five-category-briefing.md（来源：alibabacloud.com/help/zh/rds/apsaradb-rds-for-postgresql/pgvector-use-guide，2026-06 更新） 可信度： 高（阿里云官方文档，2026-06 更新） 工程价值： ⭐⭐⭐
要点：
- 重要工程参数：
- 最大向量维度：16000；建索引最大维度：2000
maintenance_work_mem不足时lists > 2000会报 OOM，需合理配置-
ivfflat.probes与召回率/速度权衡：probes 越大，召回越高，但速度越慢 -
HNSW 生产推荐配置：
sql CREATE INDEX ON vecs USING hnsw(embedding vector_l2_ops) WITH (m = 16, ef_construction = 64); -- 查询时动态调召回 SET hnsw.ef_search = 100; -- 高召回场景 SET hnsw.ef_search = 40; -- 低延迟场景 -
IVFFlat 生产推荐配置：
sql CREATE INDEX ON vecs USING ivfflat(embedding vector_cosine_ops) WITH (lists = 100); -- lists 越大查询越快，但召回可能下降 -
PolarDB pgvector（HNSW + IVFFlat 参数详解）： HNSW
m（双向链接数）与ef_construction的调参逻辑；IVFFlatlists参数 K-Means 聚类中心数对召回率的影响（来自 jay/inbox/2026-08-11T1105-jay-five-category-briefing.md §四）
与 knowledge/database.md R-34 现有脉络的关系： R-34 基线无独立 pgvector 配置指南条目（R-34 Vector DB Benchmark 2026 仅含吞吐量数据）。本增量是 R-34 后第一条系统性 pgvector 生产配置指南，补充了 R-34 缺失的"向量索引参数调优"维度。可进入 §2.1（向量索引工程化）或 §2.7（向量数据库选型）；16000 维度上限和 2000 索引维度上限是生产选型的重要约束条件。
建议归入节： §2.1 向量索引 / ANN / Filtered + 工程化评测（新增阿里云 RDS pgvector 配置指南作为生产参数调优参考；16000 维度上限 / 2000 索引维度上限 / maintenance_work_mem OOM 陷阱 / HNSW ef_search 动态调参 / IVFFlat probes 召回权衡）
增量 4 · ⭐⭐⭐ 中 · HiSparse（arXiv:2608.07009）：稀疏注意力 serving 的分层 KV cache 管理——稀疏注意力解码使 KV cache 无须常驻 HBM
来源： spark/inbox/2026-08-11-llm-infra-e1prep.md（来源：arXiv 2608.07009，paper_card 847，2026-08-11 主分类 llm-infra） arXiv： https://arxiv.org/abs/2608.07009 可信度： 高（arXiv 2026 系统论文） 工程价值： ⭐⭐⭐
要点：
-
核心问题： Top-k 稀疏注意力使长上下文 LLM 解码计算廉价（每步仅读取数千个选定的 KV 条目而非完整上下文）；然而服务系统通常将完整 KV cache 保留在 GPU HBM 中，使每个位置保持可选——因此请求的内存开销仍随其完整上下文长度增长，解码在算力耗尽之前就先撞上容量墙
-
核心方案：HiSparse = 精确的、与索引器无关的分层 KV cache：
- 为每个请求保留精确的 Top-k KV 条目（而非完整上下文）
- 与索引器无关（兼容 Sink attention、H2O、HtmMem 等稀疏注意力方案）
-
KV cache 超出 HBM 的上下文可被服务（稀疏激活）
-
数据库关联： 向量数据库（如 pgvector、Qdrant）管理向量索引的存储与检索；HiSparse 从"稀疏激活"角度解决了 LLM 推理时 KV cache 超出 HBM 的问题——两者在"记忆层的物理载体"这一主题下形成交叉：向量数据库是外部知识的存储介质，HiSparse 是 LLM 内部上下文的存储优化
与 knowledge/database.md R-34 现有脉络的关系： R-34 基线无 HiSparse 条目（HiSparse 是 llm-infra 主分类，但与 database 的交叉点在"KV cache 作为存储原语"）。HiSparse 是 R-34 后新增的"稀疏注意力 serving 与向量存储管理交叉"条目，可进入 §2.6（KV Cache 系统化）的邻接；其"稀疏激活使 KV cache 无须常驻 HBM"的洞察与 R-34 C2KV（跨请求 KV 复用）形成互补——C2KV 优化复用率，HiSparse 优化存储量。
建议归入节： §2.6 KV Cache 系统化（邻接：HiSparse arXiv:2608.07009 作为"稀疏注意力 serving 分层 KV cache 管理"条目；与 C2KV（跨请求复用）/ Rethinking Boundaries（存储原语化）形成 KV Cache 三维度对照：复用 / 压缩 / 稀疏激活）
增量 5 · ⭐⭐⭐ 中 · OasisKV（arXiv:2608.08097）：KV cache HBM 解耦——长上下文推理的显存瓶颈突破，与向量库内存管理范式直接交叉
来源： spark/inbox/2026-08-11-llm-infra-e1prep.md + tom/inbox/2026-08-11T1440-agent-rag-longcontext-radar.md（来源：arXiv 2608.08097，paper_card 872，2026-08-11 主分类 llm-infra） arXiv： https://arxiv.org/abs/2608.08097 可信度： 高（arXiv 2026 系统论文） 工程价值： ⭐⭐⭐
要点：
-
核心问题： LLM 推理日益受内存而非算力约束；HBM 容量成为稀缺且昂贵的资源，严重限制了推理 batch size 和系统吞吐量；长上下文和长链推理工作负载中，KV cache 在内存占用和内存带宽上均成为主导因素
-
核心方案：OasisKV = Memory-centric LLM Inference System：
- 将完整 KV cache 存储从 HBM 解耦
- 通过 lookahead sparse prefetching 在解码时按需加载
-
突破长上下文推理的显存瓶颈
-
数据库关联： 向量数据库（Pinecone/Weaviate/Qdrant/Milvus）在存储层管理向量索引；OasisKV 在推理层管理 KV cache——两者都面临"存储容量 vs 检索/计算速度"的权衡。OasisKV 的"解耦存储与计算"思路与 Mooncake（KV cache 互联网）的设计哲学高度一致，可作为 §2.6（KV Cache 系统化）的 HBM 解耦路线代表
与 knowledge/database.md R-34 现有脉络的关系： R-34 基线已有 Rethinking Boundaries（arXiv:2608.01526，"KV Cache 作为存储原语"）和 C2KV（跨请求 KV 复用）。OasisKV 是 R-34 后新增的"HBM 解耦"条目，与 Rethinking Boundaries（架构层）和 C2KV（复用层）共同构成 KV Cache 系统化的三层次：存储原语化（ Rethinking Boundaries）→ 跨请求复用（C2KV）→ HBM 解耦（OasisKV）。可进入 §2.6（KV Cache 系统化）更新 KV Cache 路线矩阵。
建议归入节： §2.6 KV Cache 系统化（邻接：OasisKV arXiv:2608.08097 作为"HBM 解耦"路线代表；与 Rethinking Boundaries（存储原语化）/ C2KV（跨请求复用）/ HiSparse（稀疏激活）形成 KV Cache 四维度路线矩阵：复用 / 压缩 / 稀疏激活 / HBM 解耦）
四、值得警惕的矛盾或待核实说法
| # | 说法 | 矛盾/风险 | 建议 |
|---|---|---|---|
| T1 | PostgreSQL-V "LSM-tree 解耦 WAL 可支持亿级向量写入" | CIDR 2026 论文具体性能数据未在 inbox 中披露；LSM compaction 对向量索引局部性的影响未核实；与 pgvector 的 benchmark 对比数据缺失 | 注明"CIDR 2026 学术工作，具体 benchmark 数据待跟进" |
| T2 | pgvector "p99 ~90ms" vs Qdrant "p99 ~25ms"（3.6× 差距） | 本 benchmark（Salt Technologies Q1 2026）与 R-34 benchmark（Kalvium Labs）测试场景可能不同（p50/p99 延迟 vs QPS 吞吐量）；不同硬件配置不可直接对比 | 注明"不同 benchmark 场景，p99 延迟 vs 吞吐量不能跨 benchmark 直接对比" |
| T3 | 阿里云 RDS pgvector "最大向量维度 16000，建索引最大 2000" | 阿里云特定 RDS 配置，可能不适用于其他云厂商或自建 PostgreSQL；pgvector 官方上限为 16,000 维度（阿里云已支持），但建索引 2000 维度限制与具体版本相关 | 注明"阿里云 RDS 特定配置，生产迁移时需核实目标平台参数" |
| T4 | HiSparse "与索引器无关的分层 KV cache" | "索引器无关"claim 需核实——稀疏注意力索引器（如 Sink attention、H2O）的选择对分层策略可能有影响；生产验证数据缺失 | 注明"学术工作，生产集成可行性待核实" |
| T5 | OasisKV "lookahead sparse prefetching 突破 HBM 瓶颈" | 稀疏预取的预测准确性未披露；prefetch 错误时的延迟惩罚未量化；与 R-34 Rethinking Boundaries（存储原语化）的具体边界未明确区分 | 注明"学术工作，具体 prefetch 准确率和延迟惩罚数据待跟进" |
五、可引用 arXiv 号列表
| arXiv ID | 标题 | 会议/状态 | 主要关联节 |
|---|---|---|---|
| 2608.07009 | HiSparse: Scaling Sparse-Attention Decoding with Hierarchical KV Cache Management（paper_card 847，llm-infra 主分类） | arXiv 2026-08 | KV Cache 稀疏激活路线（增量 4，邻接） |
| 2608.08097 | OasisKV: Scaling In-Decode KV Cache Beyond HBM with Lookahead Sparse Prefetching（paper_card 872，llm-infra 主分类） | arXiv 2026-08 | KV Cache HBM 解耦路线（增量 5，邻接） |
| 2607.17715 | C2KV: Composable KV Cache with C2Token（KDD 2026，R-34 基线） | KDD 2026 | KV Cache 跨请求复用（R-34 基线） |
| 2608.01526 | Rethinking Classical Infrastructure Boundaries in the LLM Inference（R-34 基线） | arXiv 2026-08 | KV Cache 存储原语化（R-34 基线） |
| 2511.01815 | KV Cache Transform Coding（ICLR 2026，邻接） | ICLR 2026 | KV Cache 压缩存储（邻接参考） |
| 2604.19769 | TTKV: Temporal-Tiered KV Cache（R-34 基线） | arXiv 2026-04 | KV Cache 时序分层（R-34 基线） |
| 2603.20397 | KV Cache 系统综述（邻接参考） | arXiv 2026-03 | KV Cache 全景（邻接参考） |
| 2607.13276 | Aurora DSQL: Scalable, Multi-Region OLTP（R-34 基线） | arXiv cs.DB 2026-07 | §2.5 云原生/分布式数据库（R-34 基线） |
| 2607.07397 | Branchable DBMS（R-34 基线） | arXiv 2026 | §2.3 Agent Memory 学术锚点（R-34 基线） |
| 2608.05784 | Activity Frames（R-33 基线） | arXiv 2026-08 | §2.3 Agent Memory（R-33 基线） |
六、结论与建议
本次预消化评估：中密度轮（5 条，2 条 4星 / 3 条 3星，共 2 条新 arXiv 邻接）
本次 inbox 中 database 相关信号与 R-34 持平，增量聚焦于： - PostgreSQL 向量库工程化深化： PostgreSQL-V（CIDR 2026，LSM-tree 解耦写入路径）与 pgvector/pgvectorscale 形成三路线对照 - 向量数据库选型量化更新： p50/p99 尾延迟数据与 R-34 吞吐量数据互补，构成完整选型决策树 - pgvector 生产参数调优： 阿里云官方配置指南（HNSW/IVFFlat 详细参数），填补 R-34 参数调优空白 - KV Cache 系统化三层次： HiSparse（稀疏激活）+ OasisKV（HBM 解耦）与 R-34 C2KV（复用）/ Rethinking Boundaries（存储原语化）形成四维度 KV Cache 路线矩阵
实质增量（按工程价值排序）：
- PostgreSQL-V CIDR 2026（⭐⭐⭐⭐）： LSM-tree 解耦向量索引 WAL；亿级向量写入场景的架构解耦方案；与 pgvectorscale（内存优化）形成 PostgreSQL 向量库双路线
- Vector DB Benchmark 2026 p50/p99 数据（⭐⭐⭐⭐）： pgvector p99 ~90ms vs Qdrant p99 ~25ms（3.6× 差距）；与 R-34 吞吐量数据互补；选型决策树更新
- 阿里云 RDS pgvector 配置指南（⭐⭐⭐）： 16000 维度上限 / 2000 索引维度上限 / maintenance_work_mem OOM 陷阱 / HNSW ef_search 动态调参；生产参数调优必读
- HiSparse arXiv:2608.07009（⭐⭐⭐邻接）： 稀疏激活使 KV cache 无须常驻 HBM；与 C2KV/Rethinking Boundaries 形成 KV Cache 三维度对照
- OasisKV arXiv:2608.08097（⭐⭐⭐邻接）： HBM 解耦 + lookahead sparse prefetching；与 Rethinking Boundaries/C2KV/HiSparse 形成 KV Cache 四维度路线矩阵
对活文档接力的建议：
- §2.1 向量索引 / ANN： 新增 PostgreSQL-V CIDR 2026（LSM-tree 解耦）作为"PostgreSQL 向量库新架构"；更新阿里云 RDS pgvector 配置指南（HNSW/IVFFlat 参数）；pgvector/pgvectorscale/PostgreSQL-V 三路线对照
- §2.7 向量数据库选型： 更新 Vector DB Benchmark 2026 综合数据（p50/p99 尾延迟维度 + R-34 吞吐量数据）；Aurora + pgvector HNSW 可将查询吞吐量提升 9 倍、成本降低 75-80%
- §2.6 KV Cache 系统化： 更新 KV Cache 四维度路线矩阵：复用（C2KV）/ 压缩（Rethinking Boundaries）/ 稀疏激活（HiSparse 2608.07009）/ HBM 解耦（OasisKV 2608.08097）；与 §2.1 向量索引形成"外部知识存储 vs 内部上下文存储"的交叉呼应
本周 database 主题整体判断： R-33（8/9）是 Agent Memory 爆发轮（CockroachDB / Activity Frames）；R-34（8/10）是 KV Cache 系统级范式转变轮（C2KV / Rethinking Boundaries）；R-35（8/11）是 PostgreSQL 向量库工程化深化轮（PostgreSQL-V / p50/p99 benchmark / pgvector 参数调优 / HiSparse+OasisKV 邻接）。三条脉络代表 database 领域 2026 年的三个核心方向：数据库向 Agent 记忆基础设施渗透（§2.3）、KV Cache 向存储原语演进（§2.6）、PostgreSQL 向量库工程化精细化（§2.1/§2.7）。建议今晚活文档接力优先更新 §2.1 和 §2.7。
七、附：paper_cards 近 3 天邻接逐卡确认（database 相关）
| ID | arXiv | 主分类 | TLDR 一行 | 是否 DB 相关 |
|---|---|---|---|---|
| 835 | 2608.07126 | agent | PHOENIX 卫星自主延寿 | ❌ |
| 836 | 2608.07468 | multimodal | SimWAM 世界动作模型 | ❌ |
| 837 | 2608.07051 | engineering | YOLO-PEFT 参数高效微调 | ❌ |
| 838 | 2608.06485 | agent | AI 人格演化基准 | ❌ |
| 840 | 2608.06501 | evaluation | C4 跨概念创意评估 | ❌ |
| 841 | 2608.05219 | agent | 状态匹配路由多轮 Agent | ❌ |
| 842 | 2608.00675 | multimodal | 往返一致性扩散模型 | ❌ |
| 861 | 2608.06865 | multimodal | 多 Agent 深度伪造检测 | ❌ |
| 862 | 2608.06113 | engineering | DCAS CLI Agent 脚手架 | ❌ |
| 864 | 2608.04569 | rag | 硬提示压缩指代悬空 | ❌ |
| 865 | 2608.04302 | multimodal | CLIP-CC-Bench 视频描述 | ❌ |
| 866 | 2608.04205 | evaluation | MatrAIx 83 亿 Persona Agent | ❌ |
| 872 | 2608.08097 | llm-infra | OasisKV HBM 解耦 KV Cache | ✅ KV Cache HBM 解耦（邻接） |
| 873 | 2608.07169 | agent | Agent Memory Distillation | ❌（agent 主分类） |
| 874 | 2608.07594 | multimodal | 可解释 LLM 缩放 | ❌ |
| 875 | 2608.06614 | rag | 因子化假设搜索 | ❌ |
| 876 | 2608.07565 | multimodal | 图像编辑跟进建议 | ❌ |
数据库主分类：0 张；database 邻接：1 张（OasisKV 2608.08097，llm-infra 主分类）
本简报由 Jay 实例自动生成 · 2026-08-11 20:20 · 仅作预消化草稿，待活文档接力时综合评估