elasticsearch-anomaly-detection-explainer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Anomaly Detection Score Explainer

异常检测分数解释器

Explain anomaly scores, model behavior, and why results look the way they do. Use the ML REST API for job config and the standard
_search
API against

.ml-anomalies-*

for results — no ES|QL, fully compatible with Elastic Serverless. For job lifecycle (create, start, stop), use the

elasticsearch-anomaly-detection

skill.

解释异常分数、模型行为以及结果呈现方式的原因。使用ML REST API获取任务配置，针对

.ml-anomalies-*

使用标准

_search

API获取结果——不使用ES|QL，完全兼容Elastic Serverless。对于任务生命周期（创建、启动、停止），请使用

elasticsearch-anomaly-detection

技能。

Environment Configuration

环境配置

This skill executes Elasticsearch operations through the

elastic

CLI. If the

elastic

CLI is not installed, tell the user what it is needed for. Do not guess credentials, call the HTTP API directly, or attempt other workarounds.

This skill references operations in HTTP-shorthand form (e.g.,

GET /

GET /_cat/indices

GET /{index}/_mapping

GET /{index}/_settings/index.mode

POST /_query

). The Operations table at the end of this document maps each shorthand to the equivalent

elastic

CLI command — always use the CLI rather than calling the HTTP API directly.

Prerequisite: ML anomaly detection requires a Platinum-equivalent license on self-managed clusters. Serverless projects include ML. The caller needs
monitor_ml
to read job config and anomaly results.
Serverless note: The
_ml/.../results/*
REST endpoints return HTTP 410 in Elastic Serverless. Always use
POST /.ml-anomalies-*/_search
for result queries instead — fully supported everywhere this skill runs.

本技能通过

elastic

CLI执行Elasticsearch操作。如果未安装

elastic

CLI，请告知用户其用途。请勿猜测凭证、直接调用HTTP API或尝试其他变通方法。

本技能以HTTP简写形式引用操作（例如

GET /

、

GET /_cat/indices

、

GET /{index}/_mapping

、

GET /{index}/_settings/index.mode

、

POST /_query

）。本文档末尾的操作表格将每个简写映射为等效的

elastic

CLI命令——请始终使用CLI而非直接调用HTTP API。

前提条件: ML异常检测在自托管集群上需要铂金级等效许可证。Serverless项目包含ML功能。调用者需要
monitor_ml
权限才能读取任务配置和异常结果。
Serverless说明: 在Elastic Serverless中，
_ml/.../results/*
REST端点返回HTTP 410错误。请始终使用
POST /.ml-anomalies-*/_search
查询结果——本技能运行的所有环境均完全支持此方式。

Process

流程

Decide whether to fetch data or interpret what the user supplied. If the user embeds an anomaly record (or job config) in the prompt, interpret it directly using the domain knowledge below — do not call APIs to re-fetch fields already present. If the job ID, time range, or record is missing, retrieve it from the cluster.
The decision: proceed with judgment-only explanation when the record contains
```
record_score
```
,
```
initial_record_score
```
,
```
actual
```
,
```
typical
```
, and
```
function
```
; otherwise fetch the missing pieces before explaining.
Verify connectivity when calling the cluster. Call
```
GET /
```
. If the call fails, stop and surface the connection error — do not guess endpoints or credentials.
Resolve the job ID and load config. When the job ID is unknown, call
```
GET /_ml/anomaly_detectors
```
to list candidates. Call
```
GET /_ml/anomaly_detectors/{job_id}
```
for full
```
analysis_config
```
(bucket_span, detectors, custom_rules, use_null, model_plot_config) and
```
GET /_ml/anomaly_detectors/{job_id}/_stats
```
for
```
state
```
,
```
model_size_stats.memory_status
```
, and data counts.
The decision: confirm detector function and direction match the user's question before interpreting scores. A
```
low_count
```
job legitimately fires on drops; a
```
high_count
```
job does not.

Retrieve anomaly records for the time range. Call

POST /.ml-anomalies-*/_search

with

result_type: record

, the job ID, a timestamp range, and optional

record_score

filter. Read

initial_record_score

record_score

actual

typical

function

multi_bucket_impact

, and

anomaly_score_explanation

Always show both

initial_record_score

and

record_score

. The gap is the renormalization story.

Classify the score pattern before speculating on causes.
- initial_record_score
  >>
  record_score
  — Renormalization. A later, more extreme anomaly rescale this record downward. This is expected, healthy model behavior — not a broken model or reason to distrust the detection. Use
```
initial_record_score
```
  for alerting severity; show both scores and explain the gap explicitly.
- initial_record_score
  ==
  record_score
  — No renormalization has occurred since detection.
- actual
  <<
  typical
  with
  low_count
  ,
  count
  , or
  low_mean
  — Absence / drop anomaly. A high score is legitimate — the job detected an outage, pipeline stall, or service failure. This is not a false positive. Recommend incident investigation, not score tuning.
- actual
  >>
  typical
  with
  high_count
  or
  high_mean
  — Spike anomaly; confirm with
```
single_bucket_impact
```
  .
Only cite
anomaly_score_explanation
factors present in the record. If
```
high_variance_penalty
```
is
```
false
```
, do not blame variance. If a factor is absent, note that it was not returned — do not invent it.
Quantify renormalization across the job (optional). Re-query
```
POST /.ml-anomalies-*/_search
```
for records in the time range sorted by
```
timestamp
```
ascending. Compute
```
score_drift = initial_record_score − record_score
```
per record and filter to
```
|score_drift| ≥ 20
```
. Large negative drift (initial >> record) confirms renormalization after a more extreme anomaly appeared later.
Add context when the user asks "what caused this?" or "why so low/high?"
- Model bounds — If
```
model_plot_config.enabled
```
  is true, call
```
POST /.ml-anomalies-*/_search
```
  with
```
result_type: model_plot
```
  for the same job and time range. Compare
```
actual
```
  to
```
model_lower
```
  /
```
model_upper
```
  .
- Influencers — Call
```
POST /.ml-anomalies-*/_search
```
  with
```
result_type: influencer
```
  for the bucket time range; sort by
```
influencer_score
```
  descending.
- Categorization jobs — Call
```
POST /.ml-anomalies-*/_search
```
  with
```
result_type: category_definition
```
  to list learned log patterns (
```
terms
```
  ,
```
regex
```
  ,
```
examples
```
  per
```
category_id
```
  ).
For aggregations, cross-job queries, bucket-level results, or custom filters beyond score and time, see references/explainer-reference.md.

决定是获取数据还是解释用户提供的内容。如果用户在提示中嵌入了异常记录（或任务配置），请直接使用以下领域知识进行解释——无需调用API重新获取已存在的字段。如果任务ID、时间范围或记录缺失，请从集群中检索。
判断标准：当记录包含
```
record_score
```
、
```
initial_record_score
```
、
```
actual
```
、
```
typical
```
和
```
function
```
时，仅通过判断进行解释；否则，在解释前先获取缺失的信息。
调用集群时验证连通性。调用
```
GET /
```
。如果调用失败，请停止操作并显示连接错误——请勿猜测端点或凭证。
解析任务ID并加载配置。当任务ID未知时，调用
```
GET /_ml/anomaly_detectors
```
列出候选任务。调用
```
GET /_ml/anomaly_detectors/{job_id}
```
获取完整的
```
analysis_config
```
（bucket_span、detectors、custom_rules、use_null、model_plot_config），调用
```
GET /_ml/anomaly_detectors/{job_id}/_stats
```
获取
```
state
```
、
```
model_size_stats.memory_status
```
和数据计数。
判断标准：在解释分数前，确认检测器函数和方向与用户的问题匹配。
```
low_count
```
任务会在数值下降时正常触发，而
```
high_count
```
任务则不会。
检索指定时间范围的异常记录。调用
```
POST /.ml-anomalies-*/_search
```
，参数设置为
```
result_type: record
```
、任务ID、时间范围以及可选的
```
record_score
```
过滤器。读取
```
initial_record_score
```
、
```
record_score
```
、
```
actual
```
、
```
typical
```
、
```
function
```
、
```
multi_bucket_impact
```
和
```
anomaly_score_explanation
```
。
始终显示**
```
initial_record_score
```
和
```
record_score
```
两者**。两者的差值反映了重新归一化的情况。
在推测原因前对分数模式进行分类。
- initial_record_score
  >>
  record_score
  —— 重新归一化。后续出现的更极端异常将此记录的分数向下调整。这是预期的健康模型行为——并非模型故障或检测不可信的原因。使用
```
initial_record_score
```
  作为告警严重程度的依据；同时显示两个分数并明确解释差值。
- initial_record_score
  ==
  record_score
  —— 检测后未发生重新归一化。
- actual
  <<
  typical
  且使用
  low_count
  、
  count
  或
  low_mean
  —— 缺失/下降异常。高分数是合理的——任务检测到中断、管道停滞或服务故障。这不是误报。建议调查事件，而非调整分数。
- actual
  >>
  typical
  且使用
  high_count
  或
  high_mean
  —— 峰值异常；通过
```
single_bucket_impact
```
  确认。
仅引用记录中存在的
anomaly_score_explanation
因素。如果
```
high_variance_penalty
```
为
```
false
```
，请勿将低分数归咎于方差。如果某个因素缺失，请注明未返回该因素——不要编造。
量化任务中的重新归一化情况（可选）。重新查询
```
POST /.ml-anomalies-*/_search
```
，获取指定时间范围内按
```
timestamp
```
升序排序的记录。计算每条记录的
```
score_drift = initial_record_score − record_score
```
，并过滤出
```
|score_drift| ≥ 20
```
的记录。较大的负漂移（initial >> record）确认在出现更极端的异常后发生了重新归一化。
当用户询问“这是什么原因导致的？”或“为什么分数这么低/高？”时添加上下文信息。
- 模型边界 —— 如果
```
model_plot_config.enabled
```
  为true，调用
```
POST /.ml-anomalies-*/_search
```
  ，参数设置为
```
result_type: model_plot
```
  ，指定相同的任务和时间范围。将
```
actual
```
  与
```
model_lower
```
  /
```
model_upper
```
  进行比较。
- 影响因素 —— 调用
```
POST /.ml-anomalies-*/_search
```
  ，参数设置为
```
result_type: influencer
```
  ，指定时间桶范围；按
```
influencer_score
```
  降序排序。
- 分类任务 —— 调用
```
POST /.ml-anomalies-*/_search
```
  ，参数设置为
```
result_type: category_definition
```
  ，列出学习到的日志模式（每个
```
category_id
```
  对应的
```
terms
```
  、
```
regex
```
  、
```
examples
```
  ）。
如需聚合、跨任务查询、桶级结果或超出分数和时间范围的自定义过滤器，请参考references/explainer-reference.md。

Common multi-step workflows

常见多步骤工作流

Task	Steps (in order)
Explain a specific anomaly	job config → records (job + exact time) → show initial_record_score vs record_score + score factors.
Why is my score low?	job config → records → renormalization check → model plot (if enabled) → explain score factors.
Why is my score high?	job config → records → check function direction, insufficient history, use_null, cardinality.
Renormalization drift	records (timestamp sort) → compute score_drift → list records where initial >> record.
Which entities contributed?	influencers (job + time range) → sort by influencer_score.
Visualize model bounds	model plot (job + time range) → compare model_lower/model_upper vs actual.
Categorization job patterns	category_definition (job_id) → terms, regex, examples per category.

任务	步骤（按顺序）
解释特定异常	任务配置 → 记录（任务+精确时间） → 展示initial_record_score与record_score的对比及分数影响因素。
为什么我的分数很低？	任务配置 → 记录 → 检查重新归一化情况 → 模型绘图（若启用） → 解释分数影响因素。
为什么我的分数很高？	任务配置 → 记录 → 检查函数方向、历史数据不足、use_null、基数情况。
重新归一化漂移	记录（按时间戳排序） → 计算score_drift → 列出initial远大于record的记录。
哪些实体导致了异常？	影响因素（任务+时间范围） → 按influencer_score排序。
可视化模型边界	模型绘图（任务+时间范围） → 比较model_lower/model_upper与actual。
分类任务模式	category_definition（job_id） → 每个分类对应的terms、regex、examples。

Critical principles

核心原则

Retrieve the record first (or use the one the user supplied). Never explain scores without
```
initial_record_score
```
,
```
record_score
```
,
```
actual
```
,
```
typical
```
, and
```
function
```
.
Renormalization is healthy. When
```
initial_record_score >> record_score
```
, a more extreme anomaly appeared later and lowered this score — expected behavior, not a model failure.
Direction matters.
```
low_count
```
fires when values drop;
```
high_count
```
fires on spikes. A high score on a traffic stop with
```
low_count
```
is correct detection, not a false positive.
Explain factors before speculating. Read
```
anomaly_score_explanation
```
from the record. Only address factors that are present and relevant.
Job config is essential.
```
bucket_span
```
, detector function,
```
custom_rules
```
,
```
use_null
```
, and memory status all affect scores. Inspect job config when a score is surprising.
Model plot is the most visual explanation. When enabled, show model bounds to illustrate where the actual value falls relative to the expected range.
For job health ("missing documents", "memory limit", "datafeed not running") use the
```
elasticsearch-anomaly-detection
```
skill.

先获取记录（或使用用户提供的记录）。在没有
```
initial_record_score
```
、
```
record_score
```
、
```
actual
```
、
```
typical
```
和
```
function
```
的情况下，请勿解释分数。
重新归一化是健康的。当
```
initial_record_score >> record_score
```
时，后续出现的更极端异常降低了该分数——这是预期行为，而非模型故障。
方向至关重要。
```
low_count
```
在数值下降时触发；
```
high_count
```
在峰值时触发。在流量中断时，
```
low_count
```
任务给出的高分数是正确的检测结果，而非误报。
先解释因素再推测。从记录中读取
```
anomaly_score_explanation
```
。仅处理存在且相关的因素。
任务配置必不可少。
```
bucket_span
```
、检测器函数、
```
custom_rules
```
、
```
use_null
```
和内存状态都会影响分数。当分数令人惊讶时，请检查任务配置。
模型绘图是最直观的解释方式。启用后，展示模型边界以说明实际值相对于预期范围的位置。
如需处理任务健康问题（“缺失文档”、“内存限制”、“数据馈送未运行”），请使用
```
elasticsearch-anomaly-detection
```
技能。

Domain knowledge

领域知识

Score types

分数类型

Term	Meaning
record_score	Normalized 0–100 for a single anomaly record; updated by renormalization. >75 critical.
initial_record_score	Score assigned at detection time, before renormalization. Use for alerting.
anomaly_score	Bucket-level severity aggregated across all detectors in a job.
influencer_score	How unusual a specific entity (host, user, service) is in a bucket; high = likely cause.
multi_bucket_impact	0–5; how much sustained, multi-bucket behavior raised the score. ≥3 = behavioral shift.

术语	含义
record_score	单个异常记录的归一化分数（0–100）；会因重新归一化更新。>75为严重级别。
initial_record_score	检测时分配的分数，未经过重新归一化。用于告警。
anomaly_score	任务中所有检测器在时间桶级别聚合的严重程度。
influencer_score	特定实体（主机、用户、服务）在时间桶中的异常程度；分数越高，越可能是异常原因。
multi_bucket_impact	0–5；持续多桶行为对分数的提升程度。≥3表示行为发生变化。

anomaly_score_explanation factors

anomaly_score_explanation因素

The

anomaly_score_explanation

field on each record breaks the score into components:

Factor	Direction	Meaning
anomaly_length	Raises	Number of consecutive buckets the anomaly spans. Longer → higher score.
single_bucket_impact	Raises	Extremity of this single bucket. Lower probability → higher impact.
multi_bucket_impact	Raises	Contribution of sustained multi-bucket pattern.
anomaly_characteristics_impact	Raises	Whether the anomaly is a mean shift vs. variance change.
high_variance_penalty	Lowers	Noisy data or early training → wide confidence bounds → score reduced.
incomplete_bucket_penalty	Lowers	Bucket had less data than expected (delayed data, sparse events).

anomaly_score_explanation

字段将每条记录的分数拆分为多个组成部分：

因素	方向	含义
anomaly_length	提升	异常持续的连续时间桶数量。持续时间越长，分数越高。
single_bucket_impact	提升	单个时间桶的极端程度。概率越低，影响越大。
multi_bucket_impact	提升	持续多桶模式的贡献。
anomaly_characteristics_impact	提升	异常是均值偏移还是方差变化。
high_variance_penalty	降低	数据噪声大或处于训练初期 → 置信区间宽 → 分数降低。
incomplete_bucket_penalty	降低	时间桶的数据量少于预期（数据延迟、事件稀疏）。

Why a score might be unexpectedly low

分数异常低的原因

high_variance_penalty: The metric is historically noisy — wide confidence bounds absorb the spike.
Renormalization: A more extreme anomaly appeared later and pushed this score down (
```
initial_record_score
```
>>
```
record_score
```
).
Insufficient training history: Need ≥3 weeks for weekly seasonality, ≥2 full cycles for any detected period.
bucket_span too large: Short-duration spikes get smoothed. Use a smaller
```
bucket_span
```
for high-frequency events.
Detector function mismatch:
```
mean
```
vs
```
high_mean
```
,
```
count
```
vs
```
high_count
```
— only one direction fires.
incomplete_bucket_penalty: Bucket received less data than expected (ingest latency or gaps).
custom_rules: A detector filter may be suppressing the anomaly.

high_variance_penalty：指标历史数据噪声大——宽置信区间吸收了峰值。
重新归一化：后续出现的更极端异常将此分数压低（
```
initial_record_score
```
>>
```
record_score
```
）。
训练历史不足：需要≥3周数据以学习周季节性，对于任何检测到的周期，需要≥2个完整周期的数据。
bucket_span过大：短持续时间的峰值被平滑。对于高频事件，请使用更小的
```
bucket_span
```
。
检测器函数不匹配：
```
mean
```
vs
```
high_mean
```
、
```
count
```
vs
```
high_count
```
——仅一个方向会触发。
incomplete_bucket_penalty：时间桶接收的数据量少于预期（摄入延迟或数据间隙）。
custom_rules：检测器过滤器可能抑制了异常。

Why a score might be unexpectedly high

分数异常高的原因

Insufficient history: Model hasn't learned the normal pattern yet — early anomalies are unreliable.
Model split thin: High-cardinality
```
partition_field
```
or
```
by_field
```
→ very few points per entity → unreliable probabilities.
use_null: If
```
use_null: true
```
, missing entities produce "null" anomalies that may not be meaningful.
Absence / drop detection: With
```
low_count
```
or
```
low_mean
```
,
```
actual << typical
```
produces a legitimately high score — treat as a real incident, not a false positive.

历史数据不足：模型尚未学习到正常模式——早期异常不可靠。
模型拆分过细：高基数的
```
partition_field
```
或
```
by_field
```
→ 每个实体的数据点极少 → 概率不可靠。
use_null：如果
```
use_null: true
```
，缺失的实体会产生“null”异常，可能无实际意义。
缺失/下降检测：使用
```
low_count
```
或
```
low_mean
```
时，
```
actual << typical
```
会产生合理的高分数——应视为真实事件，而非误报。

Model behavior concepts

模型行为概念

Concept	Meaning
actual	Observed value. typical is what the model expected. The direction matters.
Absence anomaly	`actual << typical` with `count` , `low_count` , or `low_mean` → outage, pipeline stop, service failure.
by_field	Independent baseline per entity (e.g., per host). Each entity compared to its own history.
over_field	Population analysis — entity compared to its peer group in the same bucket, not its own history.
partition_field	Fully independent sub-models with separate score normalization per partition.

概念	含义
actual	观测值。typical是模型预期的值。方向至关重要。
缺失异常	使用 `count` 、 `low_count` 或 `low_mean` 时， `actual << typical` → 中断、管道停滞、服务故障。
by_field	每个实体的独立基线（例如按主机）。每个实体与自身历史数据比较。
over_field	群体分析——实体与同一时间桶中的对等组比较，而非自身历史数据。
partition_field	完全独立的子模型，每个分区有单独的分数归一化。

Model plot and categories

模型绘图与分类

Model plot: Shows the model's learned upper and lower bounds at each time point. If
```
actual
```
is within bounds, no anomaly; if outside, the score depends on the distance from bounds. Only available when
```
model_plot_config
```
is enabled on the job. Query via
```
POST /.ml-anomalies-*/_search
```
with
```
result_type: model_plot
```
.
Categories: For jobs with a
```
categorization_field_name
```
, query
```
result_type: category_definition
```
to show log message patterns (terms, regex, examples per
```
category_id
```
). Anomaly records use
```
by_field_value = <category_id>
```
.

模型绘图：展示模型在每个时间点学习到的上下边界。如果
```
actual
```
在边界内，则无异常；如果在边界外，分数取决于与边界的距离。仅当任务启用
```
model_plot_config
```
时可用。通过
```
POST /.ml-anomalies-*/_search
```
查询，参数设置为
```
result_type: model_plot
```
。
分类：对于设置了
```
categorization_field_name
```
的任务，查询
```
result_type: category_definition
```
以查看日志消息模式（每个
```
category_id
```
对应的
```
terms
```
、
```
regex
```
、
```
examples
```
）。异常记录使用
```
by_field_value = <category_id>
```
。

Score troubleshooting protocol

分数排查流程

List jobs — Call
```
GET /_ml/anomaly_detectors
```
when the job ID is unknown.

Get job config and stats — Call

GET /_ml/anomaly_detectors/{job_id}

and

GET /_ml/anomaly_detectors/{job_id}/_stats

. Verify

bucket_span

, detector function,

custom_rules

use_null

, job state (opened/closed/failed), and

model_size_stats.memory_status

Retrieve the record — Call

POST /.ml-anomalies-*/_search

with

result_type: record

, the job ID, time range, and optional minimum

record_score

. Inspect

initial_record_score

record_score

actual

typical

function

multi_bucket_impact

, and

anomaly_score_explanation

Check renormalization — Compare
```
initial_record_score
```
vs
```
record_score
```
. If initial >> record, re-query records sorted by timestamp and compute
```
score_drift
```
to quantify renormalization across the job.
Visualize model bounds — If
```
model_plot_config
```
is enabled, query
```
result_type: model_plot
```
and show where the actual value fell relative to
```
model_lower
```
and
```
model_upper
```
.
Influencers — Query
```
result_type: influencer
```
for the anomaly bucket time range; sort by
```
influencer_score
```
.

Explain factors — From the record's

anomaly_score_explanation

, address each present relevant factor:

high_variance_penalty

incomplete_bucket_penalty

anomaly_length

single_bucket_impact

multi_bucket_impact

. Do not cite factors absent from the record.

列出任务 —— 当任务ID未知时，调用
```
GET /_ml/anomaly_detectors
```
。

获取任务配置和统计信息 —— 调用

GET /_ml/anomaly_detectors/{job_id}

和

GET /_ml/anomaly_detectors/{job_id}/_stats

。验证

bucket_span

、检测器函数、

custom_rules

、

use_null

、任务状态（opened/closed/failed）以及

model_size_stats.memory_status

。

检索记录 —— 调用

POST /.ml-anomalies-*/_search

，参数设置为

result_type: record

、任务ID、时间范围以及可选的最低

record_score

。检查

initial_record_score

、

record_score

、

actual

、

typical

、

function

、

multi_bucket_impact

和

anomaly_score_explanation

。

检查重新归一化 —— 比较
```
initial_record_score
```
与
```
record_score
```
。如果initial远大于record，重新查询按时间戳排序的记录并计算
```
score_drift
```
，以量化任务中的重新归一化情况。
可视化模型边界 —— 如果
```
model_plot_config
```
已启用，查询
```
result_type: model_plot
```
并展示实际值相对于
```
model_lower
```
和
```
model_upper
```
的位置。
影响因素 —— 查询异常时间桶范围内的
```
result_type: influencer
```
；按
```
influencer_score
```
排序。
解释因素 —— 从记录的
```
anomaly_score_explanation
```
中，处理每个存在的相关因素：
```
high_variance_penalty
```
、
```
incomplete_bucket_penalty
```
、
```
anomaly_length
```
、
```
single_bucket_impact
```
、
```
multi_bucket_impact
```
。请勿引用记录中不存在的因素。

Examples

示例

"Why is my anomaly score only 15 when the spike looks huge?" → Check renormalization:
```
initial_record_score
```
(~92) >>
```
record_score
```
(~15). The spike was real; the current score was rescaled down. Use the initial score for alerting.
"Traffic stopped and I got a HIGH score — false positive?" → No.
```
low_count
```
with
```
actual
```
far below
```
typical
```
is legitimate absence detection. Investigate the outage.
"Which entities contributed most to the anomalies in job X last night?" → Query influencers for the time range.
"Show me the model bounds for this job." → Query model plot when
```
model_plot_config
```
is enabled.
"List records where the score was renormalized down a lot." → Records sorted by timestamp; filter large
```
initial_record_score − record_score
```
.

“为什么我的异常分数只有15，但峰值看起来很明显？” → 检查重新归一化：
```
initial_record_score
```
（约92）>>
```
record_score
```
（约15）。峰值是真实的；当前分数被重新调整降低。使用初始分数进行告警。
“流量中断了，我得到了高分——是误报吗？” → 不是。
```
low_count
```
任务中
```
actual
```
远低于
```
typical
```
是合理的缺失检测。请调查中断原因。
“昨晚任务X的异常主要由哪些实体导致？” → 查询指定时间范围的影响因素。
“展示此任务的模型边界。” → 当
```
model_plot_config
```
启用时，查询模型绘图。
“列出分数被大幅重新归一化降低的记录。” → 按时间戳排序的记录；过滤
```
initial_record_score − record_score
```
差值较大的记录。

Guidelines

指南

Report only what the API or the user-supplied record contains; do not invent scores, timestamps, entity values, or explanation factors.
Always show both
```
initial_record_score
```
and
```
record_score
```
when explaining a record; state explicitly whether renormalization occurred.
When a score factor is missing from the record, do not assert it; note that the field was not returned.
Do not attribute low scores to
```
high_variance_penalty
```
or
```
incomplete_bucket_penalty
```
when those flags are
```
false
```
or absent in the record.
For investigation ("what caused this?", "which service is responsible?") query influencers or construct cross-job searches via references/explainer-reference.md.
For job health use the
```
elasticsearch-anomaly-detection
```
skill.

仅报告API或用户提供的记录中的内容；请勿编造分数、时间戳、实体值或解释因素。
解释记录时始终同时显示
```
initial_record_score
```
和
```
record_score
```
；明确说明是否发生了重新归一化。
当记录中缺失某个分数因素时，请勿断言其存在；注明该字段未返回。
当
```
high_variance_penalty
```
或
```
incomplete_bucket_penalty
```
标记为
```
false
```
或记录中不存在时，请勿将低分数归咎于这些因素。
如需调查（“这是什么原因导致的？”、“哪个服务负责？”），请查询影响因素或通过references/explainer-reference.md构建跨任务搜索。
如需处理任务健康问题，请使用
```
elasticsearch-anomaly-detection
```
技能。

Operations

操作

HTTP API (shorthand)	`elastic` CLI command
`GET /`	`elastic es info`
`GET /_ml/anomaly_detectors`	`elastic es ml get-jobs`
`GET /_ml/anomaly_detectors/{job_id}`	`elastic es ml get-jobs --job-id '<job_id>'`
`GET /_ml/anomaly_detectors/{job_id}/_stats`	`elastic es ml get-job-stats --job-id '<job_id>'`
`POST /.ml-anomalies-*/_search`	`elastic es search --index '.ml-anomalies-*' --input-file '<search-body.json>'`

Query body shapes for each

result_type

(

record

influencer

model_plot

category_definition

) are documented in references/explainer-reference.md.

HTTP API（简写）	`elastic` CLI命令
`GET /`	`elastic es info`
`GET /_ml/anomaly_detectors`	`elastic es ml get-jobs`
`GET /_ml/anomaly_detectors/{job_id}`	`elastic es ml get-jobs --job-id '<job_id>'`
`GET /_ml/anomaly_detectors/{job_id}/_stats`	`elastic es ml get-job-stats --job-id '<job_id>'`
`POST /.ml-anomalies-*/_search`	`elastic es search --index '.ml-anomalies-*' --input-file '<search-body.json>'`

各

result_type

（

record

、

influencer

、

model_plot

、

category_definition

）的查询体格式记录在references/explainer-reference.md中。