2 篇博文 含有标签「ann」

你团队选择的向量索引是在一个生产环境中根本不存在的工作负载上进行基准测试的。每一个公开的 ANN（近似最近邻）基准测试 —— VIBE、ann-benchmarks、数据库厂商落地页上的对比表 —— 都是从语料库中均匀采样查询的，因此每个邻居查找的成本大致相同，每个分片承受的负载也大致相等。真实的检索流量并非如此。它呈现出齐普夫分布（Zipfian）：极小部分的查询（今日新闻、趋势产品、循环的支持意图、客服团队整天收到的那几百个问题）命中的一小部分嵌入，其频率比中位数高出百倍。基准测试显示 HNSW 在 50ms p99 下的召回率为 0.97。而生产环境则显示一个分片正在熔化，其余的却闲得发慌。

这种不匹配并不是调优问题。而是向量检索继承了所有其他数据库工作负载的访问倾斜特性，而该领域标准化的索引在设计时并未考虑到这种特性。你的 KV 存储免费获得的缓存层 —— 预热你最常读取的行的操作系统页面缓存（OS page cache），针对热点 Key 的 LRU —— 在 ANN 中并不存在，因为图是按图结构顺序遍历的，而不是按访问顺序。热门嵌入在内存中依然是“冷的”，因为搜索算法的遍历模式在页面缓存看来是随机的，而你的“热门”集群位于单个分片上，其 CPU 运行火热，而集群的其他部分却在闲置。

从任何成熟的 RAG 系统中提取一周的检索日志，并按分块（chunks）被返回的频率进行排序。其分布形态几乎总是相同的：一小部分分块出现在数千次查询中，而语料库中的绝大多数内容仅出现几次，甚至从未出现过。系统没有故障。它正在精准地执行索引构建时的预期功能 —— 而这恰恰是问题所在。

这就是向量检索中的流行度偏差（popularity bias），而且随着语料库的增长，这种情况会变得更加严重。少数分块变成了“引力井”，在互不相关的查询中频频胜出，而长尾内容则悄然消失在 top-k 截断值之下。你的 RAG 系统开始让人感觉“平庸” —— 用户提出具体问题，得到的回答听起来却像是为别人写的一样。等到产品部门开始投诉时，这种分布不均的情况往往已经持续数周了。