MAPID / methods / evaluation

Rare by nature

Attacks are uncommon, and almost every metric quietly assumes they are not. Imbalance turns up three times in this work at three different ratios, pointing in two different directions, and it is the reason a low false-positive rate and a useful alert stream are not the same thing.

If one percent of sessions are attacks, a detector that labels everything benign scores 99 percent accuracy and catches nothing. The number is real and completely useless. That is the whole problem in one line.
Three places, three ratios

The imbalance points in two directions

1.63 : 1

Training set, attack-majority

1,900 attack windows against 1,167 real-dialogue benign windows. Unusual for security: the positives outnumber the negatives.

Handled by balanced class weights, so the boundary is not pulled toward predicting attack.

1 : 99

Deployment, benign-majority

Real traffic runs the other way. A classifier calibrated on 1.63 to 1 and applied where the rate is 1 in 100 will systematically over-predict attack.

Handled by dividing posterior odds by the training prior odds, so the classifier contributes evidence rather than an absolute probability.

2.5 : 1

Evaluation set, attack-majority

125 attack sessions against 50 benign. An aggregate block rate over all 175 mixes the two populations.

Handled by never reporting the aggregate: attack catch and benign false-positive rate are always separate.

What the rate costs

One thousand sessions

Every square is one session. Drag the attack base rate and watch what happens to the alert stream while recall stays pinned at 1.000.

attack caught attack missed benign flagged (false alarm) benign, correctly passed
recall / catchof attacks caught
precisionof alerts that are real
accuracylooks fine, means little
always-benign accuracycatching nothing

Recall is held at 1.000 throughout, matching the reported catch across all five attack patterns. Only the base rate and the false-positive rate move.

How it is handled

Three mechanisms, one per place

In training

Balanced class weights

The logistic regression up-weights the smaller class so both contribute equally to the loss, and the 1,900 to 1,167 ratio does not tilt the decision boundary.

In the aggregator

Prior-odds correction

The per-turn ratio is the classifier's posterior odds divided by the training prior odds. Deployment rarity lives in the session prior of 0.01 to 0.10 instead, so the two are never conflated.

In reporting

Never one blended number

Attack catch and benign false-positive rate are measured on different populations and reported separately. Blending them is exactly how the synthesized benchmark hid a 100 percent benign false-positive rate.

Prepared answer

What this means for the deployed system

Precision is not reported, and that is deliberate

Precision depends on the deployment base rate, which I have no measurement of, so it is not a stable figure of merit. Reporting catch and benign false-positive rate separately keeps both populations visible. Under any realistic base rate most flagged sessions would be false alarms, which is why a session crossing the threshold triggers a slow-path clarification prompt rather than a hard refusal. The design absorbs low precision instead of pretending it away.

The likelihood ratios assume a base rate I did not measure

They are estimated on a synthesized distribution whose attack-to-benign ratio is a design choice. If real traffic is far rarer in attacks than the calibration set assumes, the operating point moves and the thresholds need refitting against measured traffic.