图表问题排查和限制

Graph API 请求中的默认设置被配置为通过以下策略来过滤掉噪声结果：

这些对于从噪声数据中获取“大局”信号很有用，但它们可能会遗漏单个文档的详细信息。如果您需要执行详细的取证分析，您可以调整以下设置以确保图表探索生成所有相关数据

在默认设置 use_significance 为 true 的情况下，Graph API 会对其在探索过程中发现的词条执行后台频率检查。每个唯一的词条都必须在索引中查找其频率，这至少需要一次磁盘寻道。磁盘寻道很昂贵。如果您不需要执行此噪声过滤，将 use_significance 设置为 false 会消除所有这些昂贵的检查（代价是不对词条执行任何质量过滤）。

如果您的数据有噪声，并且需要根据显著性进行过滤，您可以通过以下方式减少频率检查的次数：

请记住，所有这些选项都会减少分析的信息范围，并可能增加错过可能有趣细节的可能性。但是，丢失的信息往往与较低质量的文档和较低频率的词条相关联，这可能是一个可以接受的权衡。

Graph API 可以在单个 API 请求中探索多个索引、类型或别名，但假设它执行的每个“跳跃”都在查询同一组索引。目前，不可能从一个索引的字段中获取一个词条，并使用该值来探索在另一个类型或索引中 *不同字段* 中持有的连接。

一个很好的例子是，如果在名为“weblogs20160101”的索引的 remote_host 字段中找到了 IP 地址，您可能希望在名为“knownthreats”的索引的 ip_address 字段中查找相同的地址。

支持此行为需要额外的映射来指示 weblogs 的 remote_host 字段包含在威胁索引的 ip_address 字段中具有实际意义和含义的值。

由于我们目前不支持这种转换，您必须执行多次调用才能从 weblogs 索引响应中获取值，并将它们构建到对威胁索引的单独请求中。