《Agent记忆错误的100个案例手册》第 36–40 案例
本辑为《Agent记忆错误的100个案例手册》连载内容。
案例 36：向量数据库与索引错误｜sharding-boundary-query-ambiguity
场景
向量数据库按时间范围分片：shard_1存储2023年文档，shard_2存储2024年文档。用户查询”2024年初的市场趋势”，由于”年初”的模糊性，相关文档分布在两个分片中。在每个分片内部进行Top-K检索（每个分片取Top-5），但全局最优结果可能被分片内部的局部排序压制。
错误表现
Agent的回答过度偏向2024年1月的内容，忽略了2023年12月的关键趋势铺垫，分析缺乏连贯性。
解决方案
- 实施”全局重排序”：分片检索后，将所有分片的结果汇集进行统一重排序，而非简单取各分片Top-K
- 对跨边界查询使用重叠分片策略：分片边界保留重叠区域（如12月文档同时存在于Q4和次年Q1分片）
- 在查询路由层进行智能分发：对可能跨分片的查询发送到多个分片并合并结果
原理
分片（Sharding）将全局排序问题分解为局部排序，但局部最优不等于全局最优。跨分片边界的查询需要特殊处理，否则会因分片策略产生系统性偏差。
案例 37：向量数据库与索引错误｜embedding-cold-start-sparse-data
场景
Agent上线初期，知识库中只有10篇文档。用户查询与其中某篇有部分词汇重叠，但由于向量空间中数据点过于稀疏，该查询与这篇文档的相似度得分为0.85，而与一篇几乎无关的文档得分也有0.65（稀疏空间中的相对距离被压缩）。
错误表现
Agent对低置信度的结果过于自信，将无关文档作为依据，回答质量低下。随着文档量增加到1000篇后，同一查询的相似度分布才趋于合理。
解决方案
- 冷启动阶段使用稀疏检索（BM25）而非稠密向量检索，避免embedding空间稀疏性问题
- 设定最小文档量阈值：知识库文档数低于阈值时，切换到规则-based或模板-based回答模式
- 对相似度分数进行”数据量校准”：根据知识库规模动态调整相似度阈值
原理
相似度的绝对值只有在足够的参照系下才有意义。在稀疏空间中，所有向量的两两相似度趋向于集中（因为缺乏对比），导致阈值判断失效。
案例 38：向量数据库与索引错误｜ivf-partial-search-cluster-miss
场景
使用IVF（Inverted File Index）索引，将向量空间划分为100个聚类。用户查询被分配到聚类#23进行搜索（只搜索该聚类内的文档，而非全库）。但某相关文档由于处于聚类边界，被划分到了相邻的聚类#24。
错误表现
Agent未能检索到这篇边界文档，虽然它与查询高度相关。增加搜索的聚类数量（nprobe）可以解决问题，但会增加延迟。
解决方案
- 在IVF索引查询时增加nprobe参数（如从1增加到5-10），搜索多个邻近聚类
- 使用IVF-PQ（乘积量化）的组合索引，在增加nprobe的同时通过PQ保持较低内存占用
- 对聚类边界区域进行特殊处理：在索引构建时识别边界向量并复制到邻近聚类
原理
IVF通过聚类实现快速检索，但聚类边界处的向量可能被”错误分类”到相邻聚类。nprobe参数控制了搜索的聚类数量，是精度-延迟的权衡点。
案例 39：向量数据库与索引错误｜ann-search-recall-precision-tradeoff
场景
为达到<50ms的延迟要求，将HNSW的ef参数（搜索时探索的邻居数）从200调到50。在Benchmark测试中，Recall@10从95%下降到72%。但在实际业务中，由于查询分布与测试集不同，真实Recall只有45%。
错误表现
Agent频繁遗漏关键文档，用户询问”XX政策在哪里”时，Agent回答”没有找到相关政策”，但政策实际上存在于知识库中。
解决方案
- 使用真实业务查询进行ANN参数调优，而非仅依赖标准Benchmark
- 实施”精度-延迟自适应”策略：对简单查询使用低ef参数，对复杂/重要查询使用高ef参数
- 建立Recall监控仪表盘：持续监控Top-K检索的期望Recall，低于阈值时自动告警并调整参数
原理
近似最近邻（ANN）搜索是近似算法，通过牺牲精度换取速度。ef参数直接控制搜索的彻底程度。业务查询分布与学术Benchmark往往不同，需要基于真实数据调优。
案例 40：向量数据库与索引错误｜vector-index-version-skew-read-after-write
场景
Agent集群使用多副本向量数据库。用户上传文档后，写入请求被路由到副本A，索引更新成功。但随后的查询请求被负载均衡器路由到副本B，副本B的索引尚未同步更新（复制延迟500ms）。
错误表现
用户上传文档后立即查询”我刚上传的文档里说了什么”，Agent返回”未找到相关文档”，用户认为上传失败，重复上传导致重复内容。
解决方案
- 写入后读取（Read-After-Write）场景使用”写后读一致性”路由：写入后的N秒内，相关查询固定路由到写入副本
- 在应用层实现”写入确认等待”：文档上传后，轮询所有副本确认索引同步完成再返回成功
- 使用向量数据库的”一致性级别”配置：将查询的一致性级别设为”quorum”或”all”
原理
分布式系统的副本间存在复制延迟（Replication Lag）。在写入后立即查询的场景下，如果没有一致性保障，用户会体验到”数据丢失”的假象。
E. 多Agent与协作记忆错误（案例41-50）
来源：Agent Search