← 笔记
Jay 2026-06-26 21:05

知识库草稿 · Jay · 2026-06-26 晚间 9:05

主题

Vector DB 2026 Q1 Benchmark 实测 · SmartVector 时序自适应嵌入 · RAGPerf 全链路评测框架 · GitHub 2026 可靠性危机分析 · Cilium eBPF 全景更新 · EnterpriseRAG-Bench 企业知识库发现

一、Database：Vector DB 2026 Q1 Benchmark 关键发现

来源

核心数据（1M vectors × 1536D，p99）

Database p99 Latency QPS@95% recall 过滤查询 自托管成本@100M
Redis 10–15ms 100+ 最快（in-graph filtering） —
Qdrant 30–40ms 100+ 20–30ms $300–500/mo
pgvectorscale 28ms 471（大规模时反超） 慢 $300
Milvus 40–60ms 90+ 50–70ms $800–1500/mo
Pinecone 50–100ms 80+ 40–60ms $5000+/mo
Weaviate 50–70ms 60+ 45–65ms $3000/mo
Chroma 100–200ms 低 差 $500–800/mo

Actian 三大大坑

  1. ingestion cliff：Benchmark 测的是静息状态持续写入后的 QPS，生产环境数据永不停止流动。再索引跟得上写入速度吗？许多数据库在 72 小时连续写入后出现查询质量断崖。
  2. 多并发元数据过滤：VectorDBBench 只跑单客户端。现实生产 100+ 并发 metadata-filtered 查询，P99 延迟跳 10 倍（CPU 等待磁盘 IO）。
  3. Tail latency 才是关键：p99 100ms 但中位数 10ms 的系统，比 p99 50ms 但中位数 20ms 的系统体感更慢。

评价

实践意义：超大规模（>50M chunks）pgvectorscale 的 471 QPS 是 Qdrant 的 10 倍。多数团队在 10M 以下选 Qdrant 性价比最优。企业内部 RAG 且需要 ACID + 向量，选 pgvector + HNSW 是零运维正解。

二、Database：SmartVector — 时序置信度感知嵌入

来源

核心观点

当前 RAG 假设知识是"时间不变、均匀可信、原子独立"的，但生产语料库实际是权威数据库+过期 wiki+一年前的 Slack+临时会议纪要的异构混合。文档修订后，所有相关嵌入静默成为"自信地错误"的候选答案。

SmartVector 的操作化综合： - 每个向量带创建时间戳 + 衰减置信度 + 依赖关系显式图 - 遗忘曲线（forgetting curve）建模知识老化 - GNN 风格置信度传播 - 不确定性感知检索

关键数据（versioned-policy benchmark）： - Top-1 准确率：31.0% → 62.0%（+100%） - 过期答案率：35.0% → 13.3% -ECE：0.470 → 0.244（减半） - 单次单词编辑的 re-embedding 成本：降低 77%

评价

实践意义：生产 RAG 系统处理频繁更新的知识库（FAQ、政策文档、产品信息）时，SmartVector 的框架值得借鉴。关键是"把嵌入当作活的、自我评估的对象，而非冻结坐标"。实现路径：从时间戳嵌入开始，加遗忘曲线，成熟后加 GNN 传播。

三、Database：RAGPerf — 全链路 RAG 评测框架

来源

核心内容

定义了 4 类代表性 RAG 工作负载，覆盖多种数据形态：

Dataset 类型 规模 条目数
Wikipedia (Foundation, 2025) Text 19.3 GB 6.41M
Arxiv (Kandpal et al., 2025) PDF 48 GB 30K
github-code (codepattot, 2026) Code 32 GB 11M
The People's Speech Audio 35.5 GB 0.3M

索引方法家族：HNSW（分层图）、IVF（倒排文件）、SQ/PQ（量化压缩）。

评价

实践意义：RAGPerf 覆盖了 text/code/audio 多模态，是目前最完整的 RAG 全链路评测基准。github-code 数据集对代码检索 RAG 直接有用。

四、Database：EnterpriseRAG-Bench — 企业内部知识库发现

来源

关键发现

对 3 种检索方式评测后发现： - BM25 在正确性和文档召回上领先，即便语义类问题（设计初衷是 embedding 主场）BM25 也表现突出（32.8% 正确率 vs embedding 的 24.8% 召回率） - embedding 模型在企业专有词汇（项目代号、内部缩写）、结构化格式（工单/CRM）、内部消息对话风格上训练不足 - 向量检索更适合宽泛探索场景，不适合精确 Lookup（答案来自单一文档的场景）

评价

实践意义：企业 RAG 不要盲目上向量检索。先测 BM25，尤其当知识库有大量专有名词、工单号、内部缩写时。混合检索（BM25 + vector + bash agent 池化）是企业场景的成熟解法。

五、Backend：GitHub 2026 可靠性危机分析

来源

核心数据（May 2026）

  • 月 commit 规模飙升至约 14 亿，超过去年全年 commit 总和（约 10 亿）
  • 5 月 9 起服务降级事件，4 月 10 起；GitHub 自报每月失败率高峰达 42% workflow runs
  • Azure 承载 40% monolith 流量 + 30% Git 流量，仓库复制已达 99%
  • Pull request thread creation 事件暴露了部分数据库迁移和旧 integer 限制如何成为 AI 时代可靠性问题
  • 官方状态视图与第三方实时视图持续分歧，阻碍客户实时信任和事件响应

GitHub SVP of Engineering 的诊断（正确但尴尬）：

正确方向：用户/认证/授权域隔离；降低主数据库集群负载；移除故障模式而非加服务器。

核心矛盾：营销周期快于基础设施周期。Microsoft/GitHub 正在将客户推向 AI 辅助开发，而非等一个安静两年的可靠性重建。那个差距就是客户沮丧所在。

评价

实践意义：GitHub Copilot 依赖 GitHub 基础设施，但 GitHub 自身正经历 AI 时代架构压力。AI 代码工具的大规模使用已触及 GitHub 核心系统的工程极限。团队在评估 Copilot 企业方案时需考虑这一背景。

六、Cloud-Native：Cilium eBPF 全景更新

来源

当前版本状态（2026-06-16）

分支 最新 patch 镜像 tag
v1.19 v1.19.5 quay.io/cilium/cilium:v1.19.5
v1.18 v1.18.11 quay.io/cilium/cilium:v1.18.11
v1.17 v1.17.17 quay.io/cilium/cilium:v1.17.17

eBPF 云原生应用全景（2026）

网络 + 安全 + 可观测性： - Cilium：K8s CNI + 负载均衡 + 网络安全，Hubble 可观测性 - Calico eBPF dataplane：K8s 网络，eBPF 实现 L3-L7 策略 - LoxiLB：eBPF/XDP 云原生 5G/Edge 负载均衡（Go + libbpf）

可观测性（零侵入）： - Odigos：零代码分布式追踪，eBPF 自动插桩，OpenTelemetry 格式输出 - Retina：K8s 网络可观测性平台，自定义 telemetry，输出到多后端 - Pixie：K8s 可观测性，eBPF 自动捕获，无需手动插桩 - Kepler：K8s 功耗 exporter，eBPF probe CPU 性能计数器

追踪与安全： - Inspektor Gadget：K8s 审计追踪 - Falco：K8s 运行时安全（eBPF syscall 追踪） - bcc（BPF Compiler Collection）：内核追踪经典工具

评价

实践意义：Cilium 已是 K8s 生产网络标准。Odigos + Cilium 组合可覆盖"零侵入可观测 + 高性能网络"两条主线。eBPF 在安全（Falco）、功耗（Kepler）、负载均衡（LoxiLB）方向快速成熟。

七、Backend：分布式系统延迟优化实战框架

来源

延迟优化 4 大策略

  1. Caching：高速内存避免重复 DB 查询和昂贵计算。热点数据前置。
  2. CDN：静态资产和地理分布内容全球边缘加速。
  3. Load Balancing：Round Robin / Least Connections / IP Hash 三大算法选型。
  4. Async Processing：长任务后台执行，快速响应用户，主流程非阻塞。

核心观点：

延迟是新的宕机。高延迟对用户体验的伤害不亚于完全不可用——不可用网站至少不浪费用户时间。

评价

实践意义：这篇文章框架清晰，适合作为团队内部 SRE/后端培训材料。四大策略的取舍取决于具体场景（读多写少 vs 写多读少 vs 强一致性需求）。

分类标签

database vector-db rag benchmark embedding temporal-knowledge backend distributed-systems latency github reliability cloud-native ebpf kubernetes cilium observability

建议写入路径

/shared/research-kb/inbox/jay/2026-06-26-2105-evening-database-backend-cloudnative-ragperf-vecdb-2026.md

精读 / 审稿 / 主题页更新建议

  • ⭐ 精读：SmartVector arXiv（时序 RAG 新范式，可入主题页）；EnterpriseRAG-Bench arXiv（BM25 反超 embedding 的企业 RAG 实测）
  • 🔍 审稿参考：RAGPerf arXiv（github-code 评测集设计）
  • 📝 主题页更新：
  • Vector DB Benchmark 2026 实测数据 → Database 主题页
  • GitHub 2026 可靠性 → Backend 主题页（案例研究）
  • Cilium/eBPF 全景 → Cloud-Native 主题页（工具链整理）
  • SmartVector 时序框架 → RAG 主题页（下一代 RAG 演进）