Azure认知搜索索引器为何生成冗余Base64 ID？软删除异常求助

问题场景 #

按以下步骤配置后出现异常：

1. 创建启用Blob软删除的存储账户及容器
2. 配置带有NativeBlobSoftDeleteDeletionDetectionPolicy的数据源
3. 创建包含向量字段的索引
4. 创建关联数据源与索引的索引器
5. 上传2个JSON文档，首次索引器运行后索引含2个文档
6. 删除其中1个Blob并重新运行索引器，结果索引中出现3个文档：新增1个以Blob URL的Base64编码为ID的重复文档，原2个文档未被删除

可能的原因及排查方向 #

1. 索引文档键（Key）配置不匹配 #

当未明确指定文档键字段时，Azure Cognitive Search默认会用Blob URL的Base64编码作为文档ID。如果你的索引定义了自定义键字段（比如JSON中的id字段），但数据源或索引器未正确映射该键，会导致：

• 索引器无法将软删除的Blob与已存在的索引文档匹配
• 把软删除的Blob当作新文档处理，生成默认Base64 ID的重复项
• 原文档因键不匹配未被标记删除

排查点：

• 确认索引的键字段是否在数据源的dataToExtract范围内（需确保Blob的JSON内容中包含该字段）
• 检查索引器的字段映射，确认自定义键字段被正确关联到索引的键字段，未被默认的Base64 URL覆盖

2. NativeBlobSoftDeleteDeletionDetectionPolicy 配置错误 #

该策略专门用于检测Blob的软删除状态，若配置错误会导致索引器无法识别软删除的Blob：

• 策略@odata.type写错（比如误写为#Microsoft.Azure.Search.CustomDeletionDetectionPolicy）
• 额外添加了不必要的参数（该策略不需要softDeleteColumnName或softDeleteMarkerValue）

正确配置示例：

"deletionDetectionPolicy": {
  "@odata.type": "#Microsoft.Azure.Search.NativeBlobSoftDeleteDeletionDetectionPolicy"
}

3. Blob软删除状态未被正确检测 #

• 软删除的Blob已超过存储账户设置的保留期（被永久删除，索引器无法检测）
• 数据源同时配置了HighWaterMarkChangeDetectionPolicy，与软删除检测逻辑冲突（比如高水位标记字段未正确关联Blob的LastModified属性）

排查点：

• 确认存储容器的软删除保留期足够，删除的Blob仍处于保留期内
• 检查数据源是否同时配置了其他变更检测策略，若有需验证兼容性（NativeBlobSoftDeleteDeletionDetectionPolicy可与HighWaterMark配合，但需确保高水位字段为LastModified）

4. 索引器运行日志未捕获的匹配失败 #

索引器处理软删除Blob时，若无法匹配到对应索引文档（键不匹配），会生成新文档而非删除原文档。通过日志可定位问题：

• 查看Azure门户中索引器的运行历史，检查是否有软删除检测的日志条目
• 确认是否存在文档匹配失败的提示信息

5. 向量字段的特殊处理逻辑 #

若索引包含向量字段，需确认：

• 索引器未被配置为读取软删除的Blob（默认情况下NativeBlobSoftDeleteDeletionDetectionPolicy会过滤软删除Blob，不读取内容）
• 向量字段的生成或映射未导致索引器将软删除Blob视为新的可索引内容

解决步骤 #

1. 验证键映射：确保索引的自定义键字段与Blob内容中的字段一致，索引器字段映射无覆盖
2. 检查策略配置：确认数据源的deletionDetectionPolicy类型正确，无多余参数
3. 分析运行日志：通过索引器运行历史排查软删除检测及文档匹配情况
4. 单Blob测试：删除单个Blob后运行索引器，观察日志中的处理步骤，确认软删除状态是否被识别

内容的提问来源于stack exchange，提问作者Greggo