🧠Explaining prediction…
explainExecute a predictive query for a single entity and receive a model explanation for the prediction.
Instructions
Execute a predictive query and explain the model prediction.
The graph needs to be materialized and the session needs to be authenticated before the KumoRFM model can start generating an explanation for a prediction.
Only a single entity prediction can be explained at a time.
The run_mode will be fixed to 'fast' mode for explainability.
Note that the model prediction returned by the explanation might differ
slightly from the result of the predict tool due to floating-point
precision. Ignore such small differences.
Important: Before executing or suggesting any predictive queries, read the documentation first at 'kumo://docs/predictive-query'.
Important: Before analyzing the explanation output, read the documentation first at 'kumo://docs/explainability'.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The predictive query string, e.g., 'PREDICT COUNT(orders.*, 0, 30, days)>0 FOR EACH users.user_id' or 'PREDICT users.age FOR EACH users.user_id' | |
| index | Yes | The primary key (entity index) of the prediction to explain | |
| anchor_time | No | The anchor time for which we are making a prediction for the the future. If `None`, will use the maximum timestamp in the data as anchor time. If 'entity', will use the timestamp of the entity's time column as anchor time (only valid for static predictive queries for which the entity table contains a time column), which is useful to prevent future data leakage when imputing missing values on facts, e.g., predicting whether a transaction is fraudulent should happen at the point in time the transaction was created. | |
| num_neighbors | No | The number of neighbors to sample for each hop to create subgraphs. For example, `[24, 12]` samples 24 neighbors in the first hop and 12 neighbors in the second hop. If `None` (recommended), will use two-hop sampling with 32 neighbors in 'fast' mode, and 64 neighbors otherwise in each hop. Up to 6-hop subgraphs are supported. Decreasing the number of neighbors per hop can prevent oversmoothing. Increasing the number of neighbors per hop allows the model to look at a larger historical time window. Increasing the number of hops can improve performance in case important signal is far away from the entity table, but can result in massive subgraphs. We advise to let the number of neighbors gradually shrink down in later hops to prevent recursive neighbor explosion, e.g., `num_neighbors=[32, 32, 4, 4, 2, 2]`, if more hops are required. | |
| max_pq_iterations | No | The maximum number of iterations to perform to collect valid training/in-context examples. It is advised to increase the number of iterations in case the model fails to find the upper bound of supported training examples w.r.t. the run mode, *i.e.* 1000 for 'fast', 5000 for 'normal' and 10000 for 'best'. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prediction | Yes | ||
| explanation | Yes | ||
| logs | No | Prediction-specific log messages such as number of context examples, the underlying task type and the label distribution |