向量检索召回候选，数据库判断权限

向量检索用于召回候选资源，租户能否查看资源仍由数据库记录和业务查询决定。向量库是检索加速层，不能作为权限依据。

如果把「向量存在」当成「资源可见」，迟到的删除、错误的租户范围或索引与数据库不一致，都可能造成权限问题。召回结果仍需要经过可见性检查。

把批次发布与删除记录保存下来

InterAPI 的生产发布采用不可变 release。发布前生成 manifest，执行 dry-run、评测和必要的 canary，再把数据库与向量库的变化拆成可追踪的 Outbox 工作。

旧文档使用 tombstone 标记删除。最终通过 reconcile 回读数据库和向量库，核对是否仍有未处理队列、失败任务或内容差异。

相比遍历记录直接 upsert，这套流程增加了批次记录、删除标记和发布后核对。每次发布都应能查明：资源属于哪个 release，哪些文档已经送达，哪些仍需处理。重试、对账和回滚也需要依据这些记录执行。

先评测搜索质量，再决定是否扩充数据

改善搜索质量时，先使用可复现查询检查召回过程和权限过滤，再决定是否增加数据。密集召回、词法验证、重排、强匹配和多样性应分开统计，不能仅凭向量数量增加就判断搜索质量提升。

写入成功只是发布过程中的一个结果。生产检索还需要确认数据一致、权限过滤有效，以及查询结果符合评测要求。