← Latest papers
📊 statistics

Capacity-Constrained Online Convex Optimization with Delayed Feedback

This paper introduces a capacity-constrained online convex optimization framework with delayed feedback, proposing a semi-clairvoyant model and a scheduler-based reduction to "delayed and weighted" OCO that achieves the first regret guarantees for both convex and strongly convex losses under finite tracking resources.

Original authors: Alexander Ryabchenko, Idan Attias, Daniel M. Roy

Published 2026-06-11
📖 5 min read🧠 Deep dive

Original authors: Alexander Ryabchenko, Idan Attias, Daniel M. Roy

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a chef running a busy kitchen (the Online Convex Optimization problem). Every minute, a customer orders a dish (you make a prediction). You cook it, but you don't know if they liked it or hated it until much later. Sometimes the feedback arrives 5 minutes later; sometimes 50 minutes later. This is Delayed Feedback.

In most previous research, the assumption was that your kitchen has infinite counter space. You could keep every single order ticket on the counter, waiting for the customer's review to arrive, no matter how many orders you had pending.

The Problem: The "Tiny Counter" Reality
In the real world, your counter space is limited. You only have room for C tickets at a time. If a new order comes in and your counter is full, you have to make a hard choice: throw away a pending ticket (and never see the review for that dish) or stop taking new orders. If you throw away a ticket, that feedback is lost forever. This is the Capacity Constraint.

The paper asks: How do you learn to cook better when you can't keep track of every order, and the reviews you do get are late and sometimes missing?

The Solution: A Smart "Ticket Manager"
The authors propose a two-part system to solve this:

1. The "Proxy Delay" Scheduler (The Ticket Manager)

Since you don't know exactly when a review will arrive (the delay is unknown), you can't just wait. Instead, the paper introduces a clever "Scheduler" that acts like a ticket manager.

  • How it works: When a new order comes in, the manager flips a coin (randomly) to decide how long to keep the ticket on the counter.
    • If the manager decides to keep it "forever" (or until the review arrives), it stays on the counter.
    • If the manager decides the ticket is "too risky" to keep, it's tossed immediately.
  • The Trick: The manager uses a specific probability rule. If the counter is getting crowded, it becomes more aggressive about tossing tickets. If the counter is empty, it keeps more tickets.
  • The "Importance Weight": Here is the magic. If the manager does keep a ticket and you eventually get the review, the system says, "This review counts more!" It multiplies the importance of that review to mathematically compensate for all the other reviews that were thrown away. It's like saying, "Since we only saw 1 out of 10 reviews, this one review represents the opinion of all 10."

2. The "Weighted Learner" (The Chef)

Once the manager filters the tickets and assigns those "importance weights," the Chef (the learning algorithm) gets to work.

  • The Chef doesn't just look at the review; they look at the weighted review.
  • The paper develops a new mathematical recipe (an algorithm called DW-FTRL for full feedback and DW-FTBL for partial feedback) that knows how to handle these delayed, weighted reviews without getting confused.

The Results: How Big Does the Counter Need to Be?
The paper calculates exactly how much counter space (C) you need to perform almost as well as if you had infinite space.

  • For Simple Feedback (First-Order): If you get full details on why a dish was good or bad (like a detailed critique), you only need a counter size that grows very slowly with time (roughly the size of the logarithm of the total time, log T). Even a small counter is enough to recover the performance of a giant counter.
  • For Hard Feedback (Bandit): If you only get a simple "Good/Bad" score (like a thumbs up or down) without details, the math is harder. Here, the performance depends on how crowded the counter gets (σ_max) versus how big your counter is (C).
    • If your counter is big enough, you do great.
    • If your counter is too small, your performance degrades, but it degrades gracefully. It doesn't crash; it just gets slightly worse based on a specific formula involving the ratio of "crowdedness" to "capacity."

The "Semi-Clairvoyant" Twist
Previous methods assumed the chef knew exactly how long the delay would be before cooking the dish. This paper relaxes that. The chef only finds out the delay after the review finally arrives (or when the ticket expires). This makes the problem much more realistic, like waiting for a mail-in review that could take anywhere from 1 day to 30 days, with no way to know in advance.

Summary
This paper builds a bridge between the ideal world (infinite memory, perfect tracking) and the messy real world (limited memory, lost data). It proves that by using a smart, randomized "ticket manager" that throws away some data but weights the remaining data heavily, you can still learn effectively even when your "counter" is small and the feedback is late.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →