Measure robustness under a real information budget
Separate surrogate transfer, score-based probing, and label-only access while accounting for every target query.
On this page
The question for today
What you’ll understand
- Define transfer success on a fixed target-case denominator.
- Compute the cost of finite-difference score estimation with repeats.
- Report budgeted failure curves without treating query exhaustion as proof.
A model can be tested without exposing its derivatives, but the information available from its interface determines the search. Transfer testing builds candidates on a separate surrogate and evaluates them on the target. Score-based testing uses numeric target outputs; label-only testing gets only decisions. Combining these settings under one black-box label obscures both capability and cost. A reproducible evaluation must identify which responses the tester sees, what surrogate data or models it possesses, and whether the query budget includes clean checks, repeated stochastic evaluations, and final validation.
Transfer does not inherit the surrogate’s success
A perturbation that fools a surrogate may fail on the target because their boundaries differ. Check it through the target’s full preprocessing and output rule, using the target threat’s coordinates. Report transfer success over a clearly specified set, such as all target-clean-correct examples, rather than only examples selected after observing target attack outcomes. If you condition on surrogate success, publish that selection fraction as well; otherwise the number hides how many cases the surrogate never attacked successfully.
Using several surrogates or candidate objectives can improve empirical coverage, but each target evaluation still consumes the declared budget. A genuinely transfer-only protocol can generate candidates without target feedback and submit a fixed candidate list. Selecting the next surrogate candidate after inspecting target scores instead becomes an adaptive query procedure. Both are legitimate test settings, but their resource and knowledge contracts differ and should not be compared as if they were identical.
Count interface calls, not optimization labels
A central coordinatewise finite-difference estimate in d dimensions requires two score queries per coordinate before any candidate validation. Random-direction estimators use fewer directions but introduce their own variance and smoothing bias. Label-only responses do not directly supply a differentiable loss value, so a score-based formula cannot simply be applied to integer labels and interpreted the same way. Use a method compatible with the interface and state exactly which target outputs it consumes.
For randomized outputs, repeated calls can estimate a score or success probability, multiplying query cost. Batched requests still contain multiple queried inputs unless the threat explicitly budgets batches instead. Include initial classification checks, retries that reached the model, rejected candidates, and final confirmations according to the predefined policy. Keep a per-example ledger of consumed calls. Runtime limits and rate limits are practical constraints, but they are not interchangeable with a fixed total number of model evaluations.
Separate success, budget exhaustion, and invalidity
Plot cumulative valid failures against consumed queries, retaining successful candidates. Report clean errors separately and keep the denominator fixed across budgets. A case with no discovered failure after fifty queries is a fifty-query search survivor, not a certified point. Success can depend on score precision, hidden randomization, input encoding, and response aggregation, so freeze those interface details with the model version. A server update during the run otherwise changes the target while the query counter continues.
Include complementary methods whose assumptions differ. A transfer probe can expose a broken white-box gradient path; a score-based random search can find failures that local derivatives miss. The Square Attack paper supplies one example of structured score-based search, while limited-query work studies estimators under restricted interfaces. These methods are references for designing controlled tests, not promises that a given budget finds the worst case. Release per-example outcomes and counts so others can distinguish query efficiency from merely attacking an easier selected subset.
Work it through
A small budget pays for repeated score probes
A toy score-based evaluator has d=3 coordinates. One round uses central differences in every coordinate and validates one final candidate. Every queried input is repeated r=4 times for stochastic averaging. Exclude initialization calls and give the evaluator a total budget of 50 target calls.
Central differences use 2×3=6 distinct probe inputs. Adding one candidate-validation input gives 7 input locations in the specified round.
Repeating each input 4 times consumes 7×4=28 target calls. A batch containing those calls does not reduce their count under this per-input budget.
One full round leaves 50−28=22 calls. A second identical full round would require another 28, so it cannot complete under the budget. Any partial-round policy must be specified separately.
The run supports one complete round under this accounting. Reporting two iterations while ignoring repeated evaluations would claim resources the protocol did not actually have.
The living notebook
Explore the model
Interactive lab · queue
Query count and service pressure are separate measurements
Reset, set Arrival rate λ to 2 and Service rate μ to 3. Predict initial fluid backlog 4 and backlog 3 after two Steps at t=1 s. Reset, explicitly set λ=4 and μ=3, then take two Steps: predict backlog 5. This constant-rate fluid toy does not count attack queries, implement rate limits, or model a real prediction API. Its separate M/M/1 readout assumes Poisson arrivals, exponential service, and λ<μ.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forAn information budget and a service-capacity measurement answer different questions.
Pause & reason
Check your understanding
Your turn
Try it yourself
Among 20 target-clean-correct cases, a fixed surrogate produces feasible candidates for all cases and 6 fail on the target. A second surrogate adds failures on 3 new cases and 2 already failed cases. What is cumulative transfer success, and how many candidate evaluations are required if both lists are tested fully once?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Use a union for failed IDs and count both candidate lists separately.
Compare with the solution
The cumulative failure count is 6+3=9, so transfer success is 9/20=45 percent on the fixed eligible set. Full testing consumes 20+20=40 target candidate evaluations, excluding any separate clean checks or repeats. Counting the 2 overlapping failures again would overstate success.
Keep the idea
Take it with you
- Name surrogate, score-based, and label-only access separately.
- Count every target input evaluation under the declared query policy.
- Budget exhaustion limits search evidence; it does not certify robustness.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.