gliner2-maven-tier2-control

MAVEN event extraction (trigger-only: 168 event types, zero arguments), fine-tuned from whr778/gliner2-joint-boundary-rams-137k (boundary architecture, mmBERT encoder).

This is the event_records=false arm of a two-arm A/B testing whether the record head recovers event instances the mention path cannot express. The arms differ in exactly one config key.

Blind test (355 held-out MAVEN documents, 13,637 gold instances, threshold 0.5)

metric	value
event_type strict micro F1	0.8893
event_trigger strict micro F1	0.7407
event_trigger fair (Ortmann) micro F1	0.7565
event strict micro F1	0.8011

Threshold was swept over (0.1, 0.3, 0.5, 0.7, 0.9) on validation; 0.5 is the argmax.

Which checkpoint this is

These weights are the last epoch (step 1365 of 1365), not the trainer's best/. Checkpoint selection was inoperative for this run: MAVEN is trigger-only, and the evaluation path skipped event types carrying no roles, so the schema came out empty for every record and compute_metrics returned nothing. With the metric key absent, the trainer silently fell back to eval_loss while still maximizing (greater_is_better), which selected the highest-loss checkpoint -- epoch 1, step 91. The reported best_metric for this run (0.8886 treatment / 0.8392 control) is that epoch-1 eval loss and is not an F1 score. The table above was produced after fixing both defects.

Result

Across the two arms, event_records=true scored 0.7327 trigger strict F1 against the control's 0.7407 (-0.0080), at 5.4x the training time (2h47m vs 35m). Note that this metric aggregates trigger spans per event type and so does not isolate multi-instance separation, which is the property the record head is meant to add.

Data

MAVEN's official test split is unlabeled (leaderboard holdout), so the official valid split was converted and halved document-wise by index parity into val/test (355/355). Both arms share it.