How it works
This section of the documentation covers how TIM Detect is designed, and how it should be used in practice.
The lifecycle of a TIM Detect Model is comprised of the following methods described below.
- Model building: any experiment starts with building a model on historical data.
- Detection with an existing model: Once a model has been built, it can be evaluated repeatedly in production to detect anomalies on newly collected data. This means a model built earlier is applied on new data to generate new insights.
- Rebuilding an existing model: In some cases, it is essential to rebuild a model with more recent data after some period of time to adapt to the new dynamics of the underlying processes.
- Uploading an existing model: An existing model can be uploaded into a different use case, to be used for different problems, on different (but compatible) datasets and by different users.
- RCA over a job's normal behavior output: Oftentimes, it is useful to figure out the root cause behind a particular result.
- What-if analysis over an existing detection: Figuring out the question of what would happen if something was the case by analyzing outputs and models after changing inputs.
Overview of supported methods for individual approaches:
Job type | kpi-driven | system-driven | outlier | drift |
---|---|---|---|---|
Model building | ☑ | ☑ | ☑ | ☑ |
Detection | ☑ | ☑ | ☑ | ☑ |
Rebuilding | ☑ | ☐ | ☐ | ☐ |
Uploading | ☑ | ☐ | ☑ | ☐ |
RCA | ☑ | ☐ | ☐ | ☐ |
What-if analysis | ☑ | ☑ | ☐ | ☐ |
The engine schema subsections for kpi-driven, system-driven, outlier, and drift approach (Kolmogorov-Smirnov or Jensen-Shannon) explain what is happening under the hood of TIM Detect during the model lifecycle. The section on what problems TIM Detect can solve provides more information about what types of problems can be tackled by TIM Detect.