Qdrant 删除文档后为何仍被召回：wait、索引可见性与缓存失效的排查

线上知识库把一份过期手册标记为删除后，搜索接口仍返回它的标题。先别急着重建整个集合：Qdrant 的删除请求可能只是得到“已接收”的确认，索引可见性和应用层缓存也可能还没有收口。把删除返回值、查询参数、集合状态和缓存键按顺序核对，通常能很快分清是哪一层还在提供旧结果。

要让删除后的文档不再进入检索结果，先用 wait=true 等待写操作完成，再用同一个 document_id 查询确认；如果集合启用了 indexed_only 或存在副本，则还要检查索引可见性与写入顺序，最后清理应用缓存。

影响面：旧手册为什么还会出现在答案里

典型链路是：管理端删除文档，服务调用 Qdrant 删除点，随后立刻做一次相似度查询，再把结果交给 RAG 生成模型。若删除请求使用默认的 wait=false，服务收到的只是操作已进入队列的确认；后台更新尚未应用时，查询仍可能读到旧点。

还有一种更隐蔽的情况：Qdrant 已经完成删除，但检索服务把 document_id 到候选片段的结果缓存了。此时 Qdrant 的状态是新的，用户看到的仍是旧内容。排查时要把“向量库结果”和“最终接口结果”分开记录。

时间线：从删除请求到检索结果逐段核对

在 SDK 或 REST 封装层，把这次删除明确记为 DeletePoints 操作，后续日志沿用同一个 operation_id，便于把写入和过滤查询放回同一条链路。

1. 删除入口：记录请求里的集合名和 document_id，确认没有把文档 ID 和点 ID 混用。
2. 写入确认：查看删除响应中的 status 与 operation_id，区分 acknowledged 和 completed。
3. 检索复查：绕过业务缓存，使用同一过滤条件搜索，检查结果是否仍带有该 document_id。
4. 接口复查：若向量库已无结果而页面仍显示旧片段，继续检查缓存键和缓存过期时间。

触发条件：三个设置会让“已删”与“可见”错开

wait=false 提前返回

Qdrant 官方说明中，未显式指定或设置为 wait=false 时，服务端可以先返回 acknowledged。这不是失败，但它只说明请求已被接收，后台更新仍可能稍后处理。需要删除后立即验收时，把删除请求改为 wait=true，并把超时当成“需要继续查询确认”的信号，而不是直接重发。

POST /collections/manual_chunks/points/delete?wait=true
{
  "points": {
    "filter": {
      "must": [{"key": "document_id", "match": {"value": "handbook-2026-04"}}]
    }
  }
}

indexed_only 改变可见范围

如果查询设置了 indexed_only=true，Qdrant 只搜索已经完成索引的段。官方文档提醒，这可能让刚更新的数据暂时“闪现”或暂时不可见。它适合用来稳定延迟，却不适合作为删除是否完成的唯一证据。

副本更新顺序不一致

分布式集合中，删除和随后重新写入同一个点如果没有明确的顺序约束，不同副本可能短暂看到不同版本。需要更强一致性时，按 Qdrant 的一致性文档检查 ordering 与 write_consistency_factor，并在业务日志中保留操作顺序。

根因定位：把向量库、索引和缓存拆成三条证据

第一条证据是删除响应：operation_id 能帮助你关联后台操作，但 acknowledged 不能替代完成确认。第二条证据是同条件查询：使用原始 document_id 做过滤，避免只凭相似度排名判断“它还是同一份文档”。第三条证据是业务缓存：检查缓存键是否包含集合名、document_id 和查询版本，防止删除后继续命中旧候选。

这一步很重要。若 Qdrant 查询已经为空，继续调低相似度阈值或反复删除只会把问题带偏；如果 Qdrant 仍返回旧点，则优先处理 wait、副本顺序和索引状态。

修复动作：删除接口和读路径一起收口

管理端可以采用下面的顺序：删除请求使用 wait=true；拿到最终状态后删除或标记对应的缓存键；再用 document_id 做一次过滤查询；最后才允许前端刷新知识库列表。对大批量删除，不要把每个点的长时间等待都放在用户请求里，可以记录 operation_id，由后台任务轮询并在完成后失效缓存。

删除 document_id
  -> wait=true
  -> operation_id 状态为 completed
  -> 清理 document_id 缓存键
  -> 过滤查询返回 0 条
  -> 更新知识库列表

如果启用了 prevent_unoptimized，还要观察集合信息中的 update_queue。队列持续增长说明优化器仍在处理积压；这时不要用固定等待时间假设“已经完成”，而应以状态和查询结果作为门禁。

防复发：给删除操作加一组可回放的验收记录

每次删除至少保留集合名、document_id、operation_id、请求参数、最终状态、验证查询结果和缓存失效结果。回放测试可以覆盖三种顺序：删除后立即查询、删除完成后查询、删除后重新写入同一文档 ID。这样能把“偶发旧结果”变成可定位的时序问题。

验收不要只看页面。最小成功条件是：写操作达到 completed；同过滤条件下查询不到目标 document_id；业务接口没有从旧缓存补回该片段。三项缺一，删除流程都不应向用户报告完成。

相关问题：删除可见性排查中的几个边界

把 wait=true 设上就一定不会超时吗？

不一定。大量更新、索引优化或 prevent_unoptimized 都可能拉长等待时间。超时后先查询操作和目标点状态，不要盲目重发同一个删除请求。

为什么过滤查询为空，但相似度查询仍有旧答案？

优先检查应用是否缓存了候选片段，或者生成服务仍持有上一轮上下文。向量库过滤查询与最终回答必须使用同一请求关联 ID 记录。

删除后重新导入同一个文档 ID 要注意什么？

要保证删除与重新写入的先后顺序，并记录新的版本标记。否则不同副本或异步更新可能让旧点和新点在短时间内表现不一致。

小结：用状态和查询结果结束删除流程

Qdrant 删除后仍被召回，先区分“请求已接收”和“更新已可见”，再排查 indexed_only、副本顺序和应用缓存。把 operation_id、document_id 与最终过滤查询绑定起来，删除流程就有了可复盘的证据链，也不必靠固定等待或重复请求碰运气。