#ann-retrieval

共收录 1 条相关安全情报。

← 返回所有主题
推荐 3.7
Conf: 50%
👥 作者: Sean Culatana, Kang Li

该论文聚焦检索增强生成(RAG)系统中的隐私删除问题。当前大量 RAG 应用依赖基于图的近似最近邻(ANN)向量索引,这类索引在收到删除请求后,往往只是把被删除的向量 ID 从返回结果中过滤掉,索引的搜索图本身并不会立即重建。作者指出,这种“删除”只是输出层面的安全:虽然被删除的标识符不再出现在返回结果里,但在图的遍历过程中,算法仍会对这些已删除向量的嵌入做距离计算(打分),从而在进程内部重新暴露本应删除的数据。作者把这一被忽视的差异形式化为“输出安全(output safety)”与“遍历安全(traversal safety)”两个概念,并提出 TSD-AUDIT 框架,用于审计并强制实现基于图的 ANN 检索中的“遍历安全删除”。该框架的核心是 alive-before-scoring 不变量:只有仍存活的候选节点才能参与打分;删除后仅使用存活候选来修复图连通性,避免删除导致召回退化;同时为每个查询生成可核验的“打分轨迹证书(scored-trace certificate)”,由独立验证方对照删除快照进行检查,从而让删除是否真正生效变得可证明而非仅靠信任。实验方面,作者在 Faiss 的 IndexHNSWFlat 上验证:原生过滤机制相对于未过滤检索,其距离计算次数完全不变;在 70% 删除率下,采用忠实复现遍历轨迹(trace-faithful replay)的审计方式,在全部 100 条受审计查询中都检出了对已删除向量的打分行为。对 hnswlib 中 mark_deleted 路径的代码审查也发现同样的“先打分、后判断存活”模式。在区域定向删除(region-targeted deletion)场景下,TSD-AUDIT 在删除比例 0.5 至 0.9 区间内把 Recall@10 相对原生过滤提升 4.3 至 42.2 个百分点,在随机删除下召回水平则保持相当。结论是:仅审计输出结果会遗漏过程级的数据暴露,向量检索中的删除审计必须把检索过程中被打分的向量纳入考察范围,而不能只看最终返回了哪些 ID。

💡 推荐理由: 很多团队把“删除接口不返回该 ID”当成合规完成,但论文证明被删向量仍在图遍历中被打分,属于过程级隐私残留。对做 RAG、向量库治理与 GDPR/CCPA 被遗忘权合规的安全与隐私工程师而言,这是一种容易被审计漏掉的暴露面,值得重新设计删除审计口径。

🎯 建议动作: 研究跟进,并纳入内部 RAG/向量数据库删除合规评估

排序因子: 来自 arXiv 其他板块 (+2) | Community 数据源 (+1) | LLM 评分加成 (+0.7)