feat(sleep): add adversarial candidate probes - #263
feat(sleep): add adversarial candidate probes#263Bogdan (Dan) Baciu (bogdanbaciu21) wants to merge 2 commits into
Conversation
|
Ready for review. This is one commit and nine files on the current base, at exact head The focused integration slice passed on Ubuntu, macOS, and Windows: 177 passed, 2 optional skips, and 6 subtests on each runner. The complete suites also passed with zero failures: Ubuntu and macOS 1,513 passed; Windows 1,468 passed. Strict docs passed on Python 3.12. The CLA check passed. The upstream CI run is marked |
|
Thanks for the unusually thorough test matrix and for making the feature opt-in. The direction is useful, but the blocking decision is not yet sound enough to gate adoption. The main issue is attribution. Please make blocking baseline-relative: evaluate baseline and candidate on identical source/probe pairs, then base rejection on a paired change such as the candidate gap worsening relative to the baseline gap. Evidence should retain all four scores so the decision is auditable. At minimum, add regressions where (1) baseline and candidate are equally frame-sensitive and adoption is not blocked, (2) the candidate improves both scores but retains a gap and is not blocked, and (3) only candidate-introduced degradation is blocked. There are two related validity problems:
Until baseline-relative comparison, stochastic robustness, and conservative transformations are covered, please remove or disable the blocking path and keep the probes advisory-only. The deterministic mock tests and cross-platform green suite verify plumbing, but they do not validate the blocking signal itself. |
|
Got it. Will do. These are incredibly helpful comments thank you so much for the time and care you took to provide them. It will take me a bit to make these changes, will reply when complete at a high quality level. |
…ation - blocking is baseline-relative: identical source/probe pairs scored under baseline and candidate docs; a row is brittle only when the candidate gap worsens beyond the margin in a strict majority of rollout indices - evidence retains all four aggregated scores plus per-rollout samples - dream_adversarial_rollouts (cap 8); blocking requires >= 2 - _strip_polite_frame restricted to politeness-marked requests with negative tests for ability/permission/desire forms - baseline documents are required arguments so no caller can silently compare against an unintended baseline
|
Thanks again for the review. All three issues are addressed at head
Validation at the exact head across five native runners (Ubuntu 3.10/3.11/3.12, macOS arm64, Windows): full suite 1,538 passed on Ubuntu and macOS and 1,493 on Windows with zero failures; the focused slice is 202 passed everywhere; strict docs pass. On your closing point: we considered removing the blocking path entirely and keeping probes advisory-only. We kept blocking opt-in behind the three conditions you set (baseline-relative comparison, repeated-rollout consistency, conservative transformations), plus the rollout floor, and advisory remains the default. If you would still prefer advisory-only until the margin has been calibrated on a public scenario, we are happy to disable blocking in this PR and propose it separately with that calibration. |
What Problem This Solves
A candidate skill can improve its held-out validation score while depending on the exact wording or framing of harvested requests. It can therefore pass the ordinary gate and still break when the same request arrives with a harmless surface change.
The first revision of these probes scored only the candidate, so blocking mode could not distinguish brittleness the candidate introduced from prompt-frame sensitivity already present in the backend, and a single stochastic sample could mark a row brittle at the default margin.
Why This Change Was Made
This revision makes the decision baseline-relative and stochastically defensible before any probe result can block adoption.
Identical source and probe pairs are scored under both the current documents and the candidate documents, each score is the mean of a configured number of repeated rollouts, and a row is brittle only when the candidate's probe minus source gap worsens beyond the margin relative to the baseline gap and the worsening holds in a strict majority of rollout indices. Blocking additionally requires at least two rollouts, so one stochastic sample can never reject a candidate; advisory runs may use one. The baseline documents are required arguments, so no caller can silently compare against an unintended baseline. Request-frame transformations are restricted to a defensible semantic-preservation contract: only explicitly politeness-marked requests are reframed, and ability, permission, and desire questions are never touched.
Project Fit
User Impact
Operators can see which harmless request variation broke a staged candidate, and whether the breakage is candidate-introduced or pre-existing backend sensitivity. Advisory mode adds evidence without changing gate decisions; explicit blocking mode rejects only candidate-introduced degradation, after operators calibrate
dream_adversarial_marginon their task mix and setdream_adversarial_rolloutsto at least two.Proof
The deterministic proof covers the pre-registered contract scenarios, each comparing the candidate arm versus the baseline arm on identical source and probe pairs.
Regression tests also pin train, validation, test, and provenance isolation; target-only routing in dual-backend operation; the three-variant, 256-probe, and eight-rollout resource bounds; strict configuration validation including the blocking rollout floor; non-finite and zero-probe fail-closed behavior; redaction; and Markdown-safe reporting.
These are deterministic contract tests, not a live-provider performance claim, so no stochastic lift or confidence interval is claimed.
Academic Support
Testing
The focused integration slice contains 202 passing tests, 2 narrow optional skips, and 6 subtests on every native runner. It covers the planted brittle, equally sensitive, improves-both, single-fluctuation, and robust candidates; split and provenance isolation; cycle and multi-skill wiring; configuration failures including the blocking rollout floor; bounded expansion; evidence JSON with all four scores and per-rollout samples; diagnostics; Markdown reporting; staging; adoption; and target routing.
Every job asserted exact candidate
84bbde9ac19113bf4dee29dbfbf0755aacde6b36before testing. No test was deselected and no failure was masked. The Windows difference is explicit platform and optional dependency skips, not failures.Limitations & Negative Results
Reproduce It Yourself