Predictive process monitoring is concerned with the analysis of events produced during the execution of a process in order to predict the future state of ongoing cases thereof. Existing techniques in this field are able to predict, at each step of a case, the likelihood that the case will end up in an undesired outcome. These techniques, however, do not take into account what process workers may do with the generated predictions in order to decrease the likelihood of undesired outcomes. This paper proposes a framework for prescriptive process monitoring, which extends predictive monitoring approaches with concepts of alarms, interventions, compensations, and mitigation effects. The framework incorporates a parameterized cost model to assess the cost-benefit tradeoffs of applying prescriptive process monitoring in a given setting. The paper also outlines an approach to optimize the generation of alarms given a dataset and a set of cost model parameters. The proposed approach is empirically evaluated using a range of real-life event logs.READ FULL TEXT VIEW PDF
Predictive process monitoring [1, 2] is a family of techniques to predict the future state of ongoing cases of a business process based on event logs recording past executions thereof. A predictive process monitoring technique may provide predictions on the remaining execution time of an ongoing case, the next activity to be executed, or the final outcome of the case wrt. a set of possible outcomes. This paper is concerned with the latter type of predictive process monitoring, which we call outcome-oriented . For example, in a lead-to-order process, an outcome-oriented predictive process monitoring technique may predict whether a case will end up in a purchase order (desired outcome) or not (undesired outcome).
Existing outcome-oriented predictive process monitoring techniques are able to predict, after each event of a case, the likelihood that the case will end up in an undesired outcome. These techniques are restricted in scope to predicting. They do not suggest nor prescribe how and when process workers should intervene in order to decrease the likelihood of undesired outcomes.
This paper proposes a framework to extend outcome-oriented predictive process monitoring techniques in order to make them prescriptive. Concretely, the proposed framework extends a given outcome-oriented predictive process monitoring model with a mechanism for generating alarms that lead to interventions, which, in turn, mitigate (or altogether prevent) undesired outcomes. The proposed framework is armed with a parameterized cost model that captures, among others, the tradeoff between the cost of an intervention and the cost of an undesired outcome. Based on this cost model, the paper outlines an approach for return on investment analysis of a prescriptive process monitoring system under a configuration of cost parameters and a predictive model trained on a given dataset. Finally, the paper proposes and empirically evaluates an approach to tune the generation of alarms to minimize the expected cost for a given dataset and set of parameters.
The paper is structured as follows. Section 2 introduces basic concepts and notations. Next, Section 3 presents the prescriptive process monitoring framework, Section 4 outlines the approach to optimize the alarm generation mechanism, and Section 5 reports on our empirical evaluation. Finally, Section 6 discusses related work, Section 7 delineates the limitations of our framework and consequent future work, and Section 8 summarizes the contributions.
For a given set , denotes the set of all sequences over and a sequence of length ; is the empty sequence and is the concatenation of sequences and . is the prefix of length () of sequence . For example, .
Let be the event universe, i.e., the set of all possible event identifiers, and the time domain. We assume that events are characterized by various properties, e.g., an event has a timestamp, corresponds to an activity, is performed by a particular resource, etc. We do not impose a specific set of properties, however, we assume that two of these properties are the timestamp and the activity of an event, i.e., there is a function that assigns timestamps to events, and a function that assigns to each event an activity from a finite set of process activities . An event log is a set of events, each linked to one trace and globally unique, i.e., the same event cannot occur twice in a log. A trace in a log represents the execution of one case.
A trace is a finite non-empty sequence of events such that each event appears only once and time is non-decreasing, i.e., for and . An event log is a set of traces such that each event appears at most once in the entire log.
In this section, we introduce a cost model for alarm-based prescriptive process monitoring and illustrate this model using three scenarios (Section 3.1). We then formalize the concept of alarm system (Section 3.2) and discuss conditions under which an alarm system has a positive return on investment (Section 3.3).
An alarm-based prescriptive process monitoring system (alarm system for short) is a monitoring system that raises an alarm in relation to a running case of a business process, in order to indicate that the case is likely to lead to an undesired outcome. These alarms are handled by process workers who intervene by performing an action (e.g., calling a customer or blocking a credit card) in order to prevent or mitigate the undesired outcome. These actions may have a cost, which we call cost of intervention. Instead, if the case ends in a negative outcome, this leads to a cost called cost of undesired outcome.
As an example, consider a municipality that needs to collect city taxes. If the inhabitants do not pay their taxes on time, the municipality may run into cash flow issues. Accordingly, in case of an unpaid tax debt (undesired outcome), the municipality may decide to outsource the debt collection to an external collection agency, for which it has to pay a recovery fee. These fees constitute the cost of the undesired outcome. In light of their characteristics and past payment history, certain inhabitants may have a higher risk of missing the payment deadline. Therefore, sending a reminder letter to these high-risk inhabitants may increase the likelihood of receiving the payment on time. However, such an intervention comes with costs related to preparing the letter by an employee (proportional to the employee’s hourly salary rate) and the postal costs for sending the letter.
In certain scenarios, the cost of an intervention may increase over time, acknowledging the importance of alarming as early as possible. For instance, in a railway maintenance process, if an alarm about a possible railway disruption is raised early, the problem could be solved with regular maintenance procedures. Conversely, if the alarm is raised when the need for maintenance has become urgent, the maintenance provider could be required to allocate more resources in order to solve the problem on time.
When an alarm is raised, there is a certain probability, but no certainty, that the case will reach an undesired outcome if no intervention is made. If the case does not conclude with an undesired outcome even without interventions, doing the intervention causes unnecessary costs (e.g., a company could lose customers and/or opportunities). The cost related to such unnecessary interventions is referred to ascost of compensation. For instance, financial institutions may block credit card payments when they suspect that a card was cloned. However, in some cases, it may happen that the suspicion was unfounded and that the payment was legitimate. If these cases become too frequent, the reputation of the financial institution could be hampered.
The purpose of alarming is to avoid an undesired outcome. However, in several scenarios, it is not possible to fully prevent the cost of the undesired outcome, while the intervention could still help to mitigate it. Based on this rationale, we introduce the concept of mitigation effectiveness of an intervention, reflecting the proportion of the cost of an undesired outcome that can be avoided by carrying out the intervention. Oftentimes, the mitigation effectiveness decreases with time, i.e., the earlier the intervention takes place, the higher is the proportion of costs that can be avoided. Consider, for instance, the process of paying unemployment benefits by a social security institution. In this case, the aim of an alarm system could be to notify the institution about citizens who might be receiving unentitled benefits. Since the benefits that have already been issued are unlikely to be recollected, the cost of the undesired outcome cannot be avoided completely. Therefore, it is important to raise the alarm as early as possible, in order to effectively mitigate the cost of the undesired outcome.
An alarm system is intended as a system where cases are continuously monitored. However, since continuous monitoring is impractical, we assume that cases are monitored after each executed event and, therefore, alarms can only be raised after that an event has occurred. In the remainder, each case is identified by a trace that is (eventually) recorded in an event log. Definition 2 formalizes the costs defined above. Since costs may depend on the position in the case in which the alarm is raised and/or on other cases being executed, we define the costs as functions over the number of already executed events and over the entire set of cases under execution.
An alarm-based cost model is a tuple consisting of:
a function modeling the cost of intervention: given a trace belonging to an event log , indicates the cost of an intervention in when the intervention takes place after the -th event;
a function modeling the cost of undesired outcome;
a function modeling the cost of compensation;
a function modeling the mitigation effectiveness of an intervention: given a trace belonging to an event log , indicates the mitigation effectiveness of an intervention in when the intervention takes place after the -th event.
To illustrate the versatility of the above cost model, we discuss three use cases for alarm systems and their corresponding cost model configurations. The first scenario, in Box 1, refers to the provision of unemployment benefits. The cost model for this scenario is based on several discussions with the stakeholders of a real social security institution . The second scenario, in Box 2, refers to the detection of malicious credit card payments in a financial institution. Differently from the previous scenario, in this case, there is a risk of cost of compensation: due to the inconvenience caused by blocking their credit card, customers can switch to competitors. Box 3 refers to the process of predictive maintenance in railway services. This scenario is different from the previous ones because, in this case, the cost of an intervention increases over time.
An alarm-based prescriptive process monitoring system is driven by the outcome of the cases. Hereon, the outcome of the cases is represented by a function : given a case identified by a trace , if the case has an undesired outcome, ; otherwise, . In reality, during the execution of a case, its outcome is not yet known and needs to be estimated based on past executions that are recorded in an event log . The outcome estimator is a function predicting the likelihood that the outcome of a case that starts with prefix is undesired. We can define an alarm system as a function that returns true or false depending on whether an alarm is raised based on the predicted outcome or not.
Given an event log , let be an outcome estimator built from . An alarm-based prescriptive process monitoring system is a function . Given a running case identified by a trace and with current prefix , returns true, if an alarm is raised based on the predicted outcome , or false, otherwise.
For simplicity, we omit the subscript from and omit from when it is clear from the context. An alarm system can raise an alarm at most once per case, since we assume that already the first alarm triggers an intervention by the stakeholders.
|undesired outcome||desired outcome|
|alarm not raised|
The purpose of an alarm system is to minimize the cost of executing a case. Table 1 summarizes how the cost of a case is determined based on a cost model (cf. Def. 2), on the case outcome, and on whether an alarm was raised or not.
Let be an alarm-based cost model. Let be an outcome function. Let be an alarm-based prescriptive process monitoring system. Let be the entire set of complete (i.e., no more running) cases. Let be a case. Let be the index of the event in when the alarm was raised or zero if no alarm was raised:
The cost of execution of case supported by the alarm system is:
In this section, we provide an analysis and guidelines that suggest when it is valuable to invest in developing an alarm system, namely, when the return on investment (ROI) is positive. To this aim, we need to compare the case of a business process execution supported by an alarm system with the as-is situation where the business process is executed without this support. For this analysis, we consider a set of cases recorded in an event log , where no interventions were done, and a cost model .
The as-is situation implies that no interventions are done in any of the cases that lead to an undesired outcome, yielding a cost . When applied to the entire log , the cost is . Instead, when a certain system is in effect, the costs are (cf. Defs. 2, 3). With this setting, the return on investment of the system is , which must be positive to make deploying the system worthwhile.
The question that remains is: how does the ROI depend on the cost model and the alarm system? For the sake of simplicity, we assume, in this analysis, that every component of the cost model is constant. Furthermore, the initial investment costs are not considered because we assume the system to be fully operational already for a sufficiently long time, so that the the initial costs have been amortized. The above assumptions yield the following case cost:
where , , , and are constants. In order for the ROI to be positive, it should be , that is:
where , , respectively consist of the traces in related to the cases with an undesired outcome that would be alarmed, with a desired outcome that would still be alarmed, with an undesired outcome that would not be alarmed; also, . After simplification:
Because the right-hand side of Eq. 1 is non-negative, it follows as a corollary that is a necessary condition for return on investment. In other words, it must be possible to avoid a cost that is higher than the cost of doing the intervention. This provides a validation of our framework: it complies with the reasonableness condition in the cost-sensitive learning literature , which states that the cost of labeling an example incorrectly should always be greater than the cost of labeling it correctly.
Eq. 1 also illustrates that the policy of always alarming does not yield a positive ROI, unless the number of cases with undesired outcome and the cost of the undesired outcome are sufficiently high. When the number of cases with an undesired outcome is small (e.g., the unemployment benefits and the financial institution scenarios described in Boxes 1 and 2) and at the same time the cost of this undesired outcome is small, then the left-hand side of Eq. 1 is negligible, thus leading to condition , which can never hold.
So far we have assumed, for the sake of simplicity, that costs and mitigation effectiveness are constant, similarly to traditional cost-sensitive learning. However, the novelty of our formulation lays in the fact that costs are functions that depend on the time when an intervention is made. As a result, the reasonableness of the cost matrix would not be fixed, but potentially changes over time. Still, variable costs do not invalidate the ROI analysis. In fact, in order for the ROI to be positive, it is sufficient that the cost model is reasonable for a certain time period; otherwise, the alarm system would never raise alarms because of the cost model. Clearly, the longer the reasonable-cost period is, the higher the ROI.
An alarm system needs two components to minimize the costs of future cases: (1) a probabilistic classifierthat estimates the likelihood of an undesired outcome for a partial trace based on some historical observations , and (2) an alarming mechanism that, for a given incomplete case, decides whether or not to raise an alarm based on the prediction made by . We propose to implement the second component using a function that operates on the estimated likelihood of an undesired outcome, where value true represents the decision to raise an alarm. Together, the two components form an alarm system, , which makes the decision on whether or not to raise an alarm based on the observed events of trace .
The first component, function , can be implemented using any classification algorithm that is naturally probabilistic, i.e., that outputs likelihood scores on a
-interval instead of a binary outcome. Examples of probabilistic classification algorithms include naive Bayes, logistic regression, and random forest. The classifier is trained on historical cases recorded in a log.
It is easy to see that the decision on whether or not to raise an alarm should be dependent not only on , but also on the configuration of , , , and . When and are very low compared to , it might be beneficial to use a lower threshold for the estimated likelihood , while one would want to be more certain that the undesired outcome will happen when or is high.
We propose to implement the second component, , as an alarming threshold, i.e., a mechanism that alarms when the estimated likelihood of an undesired outcome is at least . We define function to be the alarming function that uses the alarming mechanism . We aim at finding the optimal value of the alarming threshold that minimizes the cost on a log consisting of historical observations such that with respect to a given likelihood estimator and cost model . The total cost of an alarming mechanism on a log is defined as . Using this definition, we define . Optimizing a threshold on a separate thresholding set is called empirical thresholding  and the search for the optimal threshold wrt. a specified cost model and log
can be performed using any hyperparameter optimization technique, such as Tree-structured Parzen Estimator (TPE) optimization. The resulting approach can be considered to be a form of cost-sensitive learning, since the value depends on how the cost model is specified.
Note that as an alternative to a single global alarming threshold it is possible to optimize a separate threshold for each prefix length . We experimentally found a single global threshold optimized on to outperform separate prefix-length-dependent thresholds optimized on , therefore we propose to use a single optimized threshold.
After creating the fully functional alarm system by training a classifier on and optimizing the alarming threshold on for the given cost model , the obtained alarming function can be applied to the continuous stream of events coming from the executions of a business process, thereby reducing the processing costs of the running cases.
In this section, we describe the experimental setup for evaluating the proposed framework and the results of the evaluation. We address the following research questions:
Can empirical thresholding find thresholds that consistently lead to a reduction in the average processing cost for different cost model configurations?
Does the alarm system consistently yield a benefit over different values of the mitigation effectiveness?
Does the alarm system consistently yield a benefit over different values of the cost of compensation?
We experiment with two different implementations of
by using different well-known classification algorithms, namely, random forest (RF) and gradient boosted trees (GBT). Both classification algorithms have shown to be amongst the top performing classification algorithms on a variety of classification tasks[8, 9]. We employ a single classifier approach where the features for a given prefix are obtained using the aggregation encoding , which has been shown to perform better than alternative encodings for event logs .
We apply the TPE optimization procedure for the alarming mechanism to find the optimal threshold . We use several fixed thresholds as baselines. First, we compare with the as-is situation in which alarms are never raised. Secondly, we compare with the baseline , allowing us to compare with the situation where alarms are always raised directly at the start of a case. Finally, we compare with enabling the comparison with the cost-insensitive scenario that simply alarms when an undesired outcome is expected. The implementation of the approach and the experimental setup are openly available online.111https://taxxer.github.io/AlarmBasedProcessPrediction/
For each event log, we use all available data attributes as input to the classifier. Additionally, we extract the event number, i.e., the index of the event in the given case, the hour, weekday, month, time since case start, and time since last event
. Infrequent values of categorical attributes (occurring less than 10 times in the log) are replaced with value “other”, to avoid exploding the dimensionality. Missing attributes are imputed with the respective most recent (preceding) value of that attribute in the same trace when available, otherwise with zero. Traces are cut before the labeling of the case becomes trivially known and are truncated at the 90th percentile of all case lengths to avoid bias from very long traces. We use the following datasets to evaluate the alarm system:
This log records execution traces from a loan application process in a Dutch financial institution.222https://doi.org/10.4121/uuid:5f3067df-f10b-45da-b98b-86ae4c7a310b The event log was split into two sub-logs, denoted with bpic2017_refused and bpic2017_cancelled. In the first one, the undesired cases refer to the process executions in which the applicant has refused the final offer(s) by the financial institution and, in the second one, the undesired cases consist of those cases where the financial institution has cancelled the offer(s).
This event log originates from the Italian local police.333https://doi.org/10.4121/uuid:270fd440-1057-4fb9-89a9-b699b47990f5 The desired outcome is that a fine is fully paid, while in the undesired cases the fine needs to be sent for credit collection.
Table 2 describes the characteristics of the event logs used. The classes are well balanced in bpic2017_cancelled and traffic_fines, while the undesired outcome is more rare in case of unemployment and bpic2017_refused. In traffic_fines, the traces are very short, while in the other datasets the traces are longer.
|bpic2017_refused||31 413||0.12||10||35||60||1 153 398|
|bpic2017_cancelled||31 413||0.47||10||35||60||1 153 398|
|traffic_fines||129 615||0.46||2||4||5||445 959|
|unemployment||34 627||0.2||1||21||79||1 010 450|
We apply a temporal split, i.e., we order the cases by their start time and from the first 80% of the cases randomly select 80% (i.e., 64% of the total) for and 20% (i.e., 16% of the total) for , and use the remaining 20% as the test set . The events in cases in and that overlap in time with are discarded in order to not use any information that would not be available yet in a real setting. We use TPE with 3-fold cross validation on to optimize the hyperparameters for RF and GBT. We optimize the alarming threshold by building the final classifiers using all the traces in and search for using .
It is common in cost-sensitive learning to apply calibration techniques to the resulting classifier in order to obtain accurate probability estimates and, therefore, more accurate estimates of the expected cost . However, we found that calibrating the classifier using Platt scaling  does not consistently improve the estimated likelihood of undesired outcome on the four event logs, and frequently even leads to less accurate likelihood estimates. Therefore, we decided to skip the calibration step. Moreover, since we use empirical thresholding, it is not necessary that the probabilities are well calibrated and it is sufficient that the likelihoods are reasonably ordered.
Table 3 shows the configurations of the cost model that we explore in the evaluation. To answer RQ1, we vary the ratio between and (keeping and unchanged). To answer RQ2, we vary both and the ratio between and . To answer RQ3, we vary two ratios: 1) between and and 2) between and .
We measure the average processing cost per case in , and aim at minimizing this cost. Additionally, we measure the benefit of the alarm system, i.e., the reduction in the average processing cost of a case when using the alarm system compared to the average processing cost when not using it.
Figure 1 shows the average cost per case when increasing the ratio of and from left to right. We only present the results obtained with GBT as we found it to slightly outperform RF. When the ratio between these two costs is balanced (i.e., 1:1), the minimal cost is obtained by never alarming. This is in agreement with the ROI analysis, where we found to be a necessary condition for having an advantage from an alarm system. When the best strategy is to always alarm. When is slightly higher than the best strategy is to sometimes alarm based on . We found that the optimized always outperforms the baselines. An exception is ratio 2:1 for traffic_fines, where never alarming is slightly better.
In Figure 2, the average cost per case is plotted against different (fixed) thresholds. The optimized threshold is marked with a red cross and each line represents one particular cost ratio. We observe that, while the optimized threshold generally obtains minimal costs, there sometimes exist multiple optimal thresholds for a given cost model configuration. For instance, in the case of the 5:1 ratio in bpic2017_cancelled, all thresholds between 0 and 0.4 are cost-wise equivalent. We conclude that the empirical thresholding approach consistently finds a threshold that yields the lowest cost in a given event log and cost model configuration (cf. RQ1).
Figure (a)a shows the benefit of having an alarm system compared to not having it for different (constant) mitigation effectiveness values. As the results are similar for logs with similar class ratios, hereinafter, we only show the results for one log from each of the groups: bpic2017_cancelled (balanced classes) and unemployment (imbalanced classes). As expected, the benefit increases both with higher and with higher ratio. For bpic2017_cancelled, the alarm system yields a benefit when is high and . Also, a benefit is always obtained when and . In the case of unemployment, the average benefits are smaller, since there are fewer cases with undesired outcome and, therefore, the number of cases where can be prevented by alarming is lower. In this case, a benefit is obtained when both and are high. We conducted analogous experiments with linear effectiveness decay, varying the maximum possible effectiveness (at the start of the case), which confirmed that the observed patterns remain the same. We have empirically confirmed our theoretical finding (Section 3.3) that is a necessary condition to obtain a benefit from using an alarm system, and have shown that a benefit is in practice also obtained under this condition when an optimized alarming threshold is used (cf. RQ2).
Similarly, the benefit of the alarm system is plotted in Figure (b)b across different ratios of and . We observe that when is high, the benefit decreases due to false alarms. For bpic2017_cancelled, a benefit is obtained almost always, except when is low (e.g., 2:1) and is high (i.e., higher than ). For unemployment, a benefit is obtained with fewer cost model configurations, e.g., when and is smaller than . We conducted analogous experiments with linearly increasing cost of intervention, varying the maximum possible cost (at the end of the case), which confirmed that the patterns described above remain the same. To answer RQ3, we have empirically confirmed that the alarm system achieves a benefit as discussed in Section 3.3 in case the cost of the undesired outcome is sufficiently higher than the cost of the intervention and/or the cost of the intervention is sufficiently higher than the cost of compensation.
The problem of cost-sensitive training of machine learning models has received significant attention. For example, Elkan analyzes the notion of misclassification cost and defines conditions under which a misclassification cost matrix is reasonable. Turney  examines a broader range of costs in the context of inductive concept learning. This latter study introduces the notion of cost of intervention, which we include in our proposed cost model. These approaches, however, do not take into account the specific costs that arise in prescriptive process monitoring.
Predictive and prescriptive process monitoring are related to Early Classification of Time Series (ECTS), which aims at classifying a (partial) time series as early as possible, while achieving high classification accuracy . To the best of our knowledge, works [15, 16, 17] are the only ECTS methods trying to balance accuracy-related and earliness-related costs. However, these approaches assume that predicting a positive class early has the same effect on the cost function as predicting a negative class early, which is not the case in typical business process monitoring scenarios, where earliness matters only when an undesired outcome is predicted.
focus on alarm-based prescriptive process monitoring, but only allow alarms to be raised when a given state of the process is reached. This moment might potentially be late to mitigate the consequences, which would have been possible if the alarm was raised earlier. Furthermore, our approach does not require an explicit modelling of the process states. Last but not least, they rely on a fixed-threshold alarming mechanism provided by process owners, as opposed to our empirical thresholding approach. Gröger et al. is an existing approach to provide recommendations, but it misses the two core elements of our proposed prescriptive process monitoring framework, i.e., cost models and earliness.
While the scenarios discussed in Boxes 1-3 show that the proposed framework is versatile enough to cover a variety of cases, the current version of the framework relies on two main assumptions. First, it assumes that an alarm always triggers an intervention, thus ignoring that a process worker might in some cases decide not to or be unable to intervene. Additionally, the current version of the framework considers each case in isolation, omitting the overall workload of the process workers, which in reality is an important factor for determining the number of alarms that can be acted upon. This limitation can be lifted by, e.g., combining the alarm system with , which proposes a recommender system that optimizes suggestions in case of concurrent process executions. A second limitation of the framework is that only one possible type of intervention is envisaged. This assumption can be lifted by extending the framework so that the cost of an intervention can vary depending on the specific action suggested by a recommender system.
Next to these limitations, we acknowledge the importance of further investigation on the applicability of the framework in practice. In particular, in the future, we aim at collaborating with companies and institutions to study whether process stakeholders are able to define the costs in a natural and simple way. Also, we plan to further investigate the consequences of incorrect and/or imprecise instantiations of the cost models. Furthermore, the current evaluation is limited to measuring the benefit of the alarm system in an offline manner, while a more thorough evaluation would consist in deploying the alarming mechanism in a real organization and making an end-to-end comparison of the costs before and after the deployment of the alarm system. However, this is a difficult task for two main reasons. First, companies need to be willing to let the technique really influence the process executions. Second, the end-to-end effectiveness analysis cannot be conducted without coupling the alarm system with a recommender system: if the system raises proper alarms, but inappropriate interventions are taken, the system would still be ineffective. Another avenue for future work is to extend the framework with active learning methods in order to incrementally tune the alarming mechanism based on feedback about the relevance of the alarms and the effectiveness of the interventions.
This paper outlined an alarm-based prescriptive process monitoring framework that extends existing predictive process monitoring approaches with the concepts of alarms, interventions, compensations, and mitigation effects. The framework incorporates a cost model to analyze the tradeoffs between the cost of intervention, the benefit of mitigating or preventing undesired outcomes, and the cost of compensating for unnecessary interventions induced by false alarms. The cost model allows one to estimate the benefits of deploying a prescriptive process monitoring system for the purposes of return on investment analysis. Additionally, the framework incorporates a technique to optimize the alarm generation mechanism with respect to a given configuration of the cost model and a given event log. An empirical evaluation on real-life logs showed the benefits of applying this optimization versus a baseline where a fixed likelihood score threshold is used to generate alarms, as considered in previous work in the field.
Probabilistic outputs for support vector machines and comparisons to regularized likelihood methods.Advances in large margin classifiers 10(3) (1999) 61–74