没有找到匹配的财务记录？
先问清搜索覆盖了什么

假设一名财务审查人询问某个报告期间的记录，却没有得到匹配结果。解释这个回答之前，应先确认实际发送给搜索系统的请求。我们建议记录索引标识、查询形式、搜索字段、筛选条件、请求时间和授权访问上下文。实际返回的结果与助手给出的解释，应分开保留。 微软的 Text Query Filters 页面主要讨论关键词搜索。文档将筛选器描述为依据字段值确定哪些已索引文档符合条件的机制。有搜索词时，筛选条件缩小搜索范围；没有搜索词时，筛选器本身也可以构成选择条件。结果为空，并不能说明究竟是哪一项条件排除了匹配。

文本的字面相等比较，也不同于会分析词语的全文搜索。微软说明，文本相等筛选不会进行分词，默认区分大小写；配置规范化器后，大小写处理方式可能改变。按数值选择记录需要使用筛选器，数值字段本身不能作为单独的全文搜索字段。 因此，查询形式是证据的一部分，不应被当作无关的实现细节丢弃。这些区别并不能证明向量搜索或语义搜索具有相同行为。涉及权限的条件，只能依据获准查看的证据记录。字符串筛选本身不能证明访问控制得到了安全执行，没有结果也不是扩大访问权限的理由。

微软将索引器描述为一种拉取式摄取机制：它读取已配置的数据源，并填充目标索引。多个索引器可以写入同一个索引，包括填充不同字段。因此，应问清哪些数据源和索引器与当前问题有关，而不是假定某一个任务成功就代表整个集合已被覆盖。 这条路径包括内容提取、源字段到索引字段的映射，以及可选的内容增强。经过转换的内容需要通过输出字段映射进入索引字段。因此，记录在上游数据源中可用，并不足以证明相关内容已经进入实际搜索的字段。 刷新证据也取决于数据源。概述页面说明，Blob 数据的变更检测是自动的，而 Azure SQL、Azure Cosmos DB 等数据源需要启用变更检测。按需运行或预定计划只说明处理可以如何启动，不证明刷新已经完成。这里讨论的是已配置的索引器，并非所有主动向索引推送数据的实现方式。

监控页面给出了一项关键限定：如果单个文档错误的数量低于 Max failed items 配置值，一次运行即使出现这些错误，也仍可被标为成功。因此，成功标签不能替代对相关运行中文档失败、错误和警告的检查。警告还需要结合情况解释；微软指出，它们并不总是意味着问题。 状态也分两个层级。索引器层面的 running 表示配置正确、可供运行，不一定表示正在执行。某一次运行另有自己的执行状态。应索取该次运行的开始和结束时间、已处理及失败项目数，以及详细异常，并将这些证据对应到被查询的索引和相关数据源。 时间范围同样重要。门户视图会定期刷新，执行历史只包含最近的运行，最多五十次。应问清哪些证据覆盖了与查询有关的时期。一个更新的成功标记或文档总数，无法说明每条相关记录是否都已纳入。

我们建议使用一份简明的搜索覆盖记录，连接三类信息：实际观察到的请求与结果；已配置的数据源、字段和转换路径；相关运行证据及尚未解决的异常。如果某个环节缺少依据，应写明缺口及负责人，而不是用假设补齐。技术负责人解释检索和数据摄取过程；负责的财务审查人决定这些观察结果对当前任务能支持什么判断。 在获准开展的评估中，可以询问这份记录如何呈现空结果、带有文档错误的成功运行，以及刷新证据缺失的情况。这些是我们提出的审查用例，并非本文已经完成的测试，也不是供应商强制要求的流程。这里不预设任何记录存在，也不预设某条记录摄取失败。 一份有依据的交付记录，可以说明某次明确的搜索没有返回匹配项，同时其覆盖范围仍有待查明。它不应悄然把这句话换成记录不存在。采购评估中真正有用的问题是：审查人能否不靠猜测，就追溯搜索的覆盖范围及其局限。