DataCupid: Stable Matching Repair for Training Data Acquisition with Delayed Feedback
Abstract
Matching repair after utility changes can reuse valid observations, but new evaluations must respect matching capacity and may return out of order. We study announced invalidations with bounded, possibly reward-dependent reporting delays and pending evaluations that do not occupy future matching capacity. Residualload repair (RLR) combines sound outcome certificates with batched matching schedules for unequal sample deficits. Its complete dyadic quota schedule admits a sharp issue-round bound with coefficient cb < 1.607 relative to the terminal residual endpoint load, together with separate delay and evidence-lifetime bounds. RLR-P monitors complete issue-order prefixes without changing the sampling plan before acceptance. With a deterministic pure oracle, a single-repair coupling from the same drained initial state guarantees no increase in certification time, issued observations, or time to a reusable checkpoint. We also derive an information-load lower bound. On fixed priority-star markets with unknown Bernoulli gaps, PrioritySearch attains the history-adjusted first-order constant for expected certification time as δ {\sim} 0, under hypothesis-independent linear history scaling and sublogarithmic reporting delays. Paired simulations and measured-feedback replay quantify the trade-offs: in the replay, RLR-P has lower mean capped update-certification time than a monitored width-based baseline, at higher oracle CPU cost.
Related
- Stabilization of a degenerate beam on an elastic foundation with axial force under fractional derivative-type delayed boundary feedback
- Remote IoT Source Monitoring with Delayed Feedback
- Variance Reduction with Delayed Feedback for Non-Convex Optimization
- Global Hopf Bifurcation in Coupled Nonlinear Optical Systems with Delayed Feedback
- Adaptive Conformal Inference Under Delayed Feedback: Coverage Guarantees and a Delay-to-Memory Diagnostic
BibTeX
@misc{sun2026datacupid,
title = {{DataCupid: Stable Matching Repair for Training Data Acquisition with Delayed Feedback}},
author = {He Sun and Junyuan Mao and Wenhao Jiang and Mingjun Xiao and Shinan Liu},
howpublished = {arXiv},
year = {2026},
month = oct,
doi = {10.48550/arxiv.2610.12960},
eprint = {2610.12960},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2610.12960},
}
RIS
TY - UNPB
TI - DataCupid: Stable Matching Repair for Training Data Acquisition with Delayed Feedback
AU - He Sun
AU - Junyuan Mao
AU - Wenhao Jiang
AU - Mingjun Xiao
AU - Shinan Liu
PY - 2026
DA - 2026/10/09
PB - arXiv
DO - 10.48550/arxiv.2610.12960
UR - https://arxiv.org/abs/2610.12960
AB - Matching repair after utility changes can reuse valid observations, but new evaluations must respect matching capacity and may return out of order. We study announced invalidations with bounded, possibly reward-dependent reporting delays and pending evaluations that do not occupy future matching capacity. Residualload repair (RLR) combines sound outcome certificates with batched matching schedules for unequal sample deficits. Its complete dyadic quota schedule admits a sharp issue-round bound with coefficient cb < 1.607 relative to the terminal residual endpoint load, together with separate delay and evidence-lifetime bounds. RLR-P monitors complete issue-order prefixes without changing the sampling plan before acceptance. With a deterministic pure oracle, a single-repair coupling from the same drained initial state guarantees no increase in certification time, issued observations, or time to a reusable checkpoint. We also derive an information-load lower bound. On fixed priority-star markets with unknown Bernoulli gaps, PrioritySearch attains the history-adjusted first-order constant for expected certification time as δ {\sim} 0, under hypothesis-independent linear history scaling and sublogarithmic reporting delays. Paired simulations and measured-feedback replay quantify the trade-offs: in the replay, RLR-P has lower mean capped update-certification time than a monitored width-based baseline, at higher oracle CPU cost.
ER -