The two previous posts on this blog were both about verifiers behaving worse over time than a one-time evaluation suggested — a positive-rate drift that made fine-tuning turn harmful, and a risk guarantee that overshot under a chronological test. This one is about a verifier behaving worse against a specific kind of input, deliberately constructed rather than naturally occurring — and a fix that, at first, wasn't the one we expected.
The red-team result
We built a targeted adversarial test set across five axes that a semantic cache's gray zone is specifically exposed to: negation ("is" vs. "is not"), quantity or date swaps ("3 days" vs. "30 days"), direction reversal ("A causes B" vs. "B causes A"), named-entity swaps, and action-verb swaps. These aren't paraphrases — a similarity model can score them as near-identical to the original query while the correct answer flips entirely.
Against this set, an off-the-shelf cross-encoder verifier false-accepts 84.0% of the pairs. That's not a subtle weakness — it's most of them. A gray zone guarded by the stock verifier is, for this specific failure mode, barely guarded at all.
The fix that didn't work
The obvious next move is the one this whole product is built around: fine-tune the verifier on the tenant's own gray-zone feedback. It's the validated remedy for weak off-the-shelf accuracy in general — tolerates real label noise, needs a few hundred to a thousand examples, and (per the drift post) holds up on three of four benchmarks over time.
Against the adversarial set specifically, fine-tuning on natural feedback — real gray-zone traffic, no adversarial examples in it — did not help. The false-accept rate went from 84.0% to 87.6%. Slightly worse, not better.
That's not really surprising once you say it plainly: natural traffic essentially never contains a deliberately-constructed negation flip or entity swap sitting next to its near-identical-looking counterpart. A model trained exclusively on natural data has no reason to have learned anything about that specific failure shape, and there's no guarantee that whatever it does learn generalizes to it. Fine-tuning fixes the things fine-tuning data actually contains examples of.
What actually worked
Targeted adversarial training did. Synthesizing a small set of adversarial examples across the same five axes — about 3.8% of the training set — and mixing them into training (held-out evaluation stayed 100% real, natural feedback) brought the false-accept rate down to 53.6%, with no loss in accuracy on natural data. Roughly halved, not solved, but a real and specific result: the fix for a specific failure mode is training data that actually represents that failure mode, not more data of the kind that was already failing to cover it.
This is what POST /v1/finetune/jobs?include_adversarial_hardening=true does: a configured generation model synthesizes rows across the five axes, seeded from the tenant's own queries, and the worker mixes them into the training split only — the held-out AUC and any Conformal Risk Control certification pool stay entirely real feedback, so the accuracy numbers a tenant sees aren't inflated by synthetic data.
There's a second chapter here that goes further: pairing this with an NLI-pretrained base model (?base_model=nli, our other product angle on Paper D) and folding in a word-level diff of the cached query against the new one (cached_query) pushes the adversarial false-accept rate down to 5.9% / 3.6% / 15.7% across three datasets — meaningfully past what adversarial training alone gets you. That combination is its own story; the short version is that which pretraining objective a verifier starts from turns out to matter more than how big it is.
The caveat we think matters more than the headline number
Here's the part we'd rather not bury: this five-axis taxonomy is a synthetic red-team construction, and we checked whether it predicts anything about real errors before treating it as a proxy for real-world risk. We took the same taxonomy and checked it against two real tenants' historical feedback.
It didn't hold up cleanly. Negation mismatch did not predict a higher real error rate on either dataset — the direction actually reversed on both. Quantity/date mismatch held up on one of two. Neither category is used as an automated signal anywhere in the product today, and we don't think it should be, on this evidence.
That's not a reason to dismiss the red-team result — an 84% false-accept rate against deliberately constructed adversarial pairs is a real weakness in the off-the-shelf verifier, and a tenant that has reason to expect adversarial-shaped traffic (an agent context where a user or another system might phrase things adversarially, deliberately or not) has a real, measured way to harden against it. It's a reason to be precise about what the number does and doesn't tell you: a synthetic red-team score measures a synthetic red-team score. Whether a given production dataset's natural error rate correlates with any one of these five axes is a separate empirical question, and on the two datasets we checked, the answer was mostly no.
Full methodology, the complete five-axis breakdown, and the combined-stack numbers are on the Research page.