does the threat model include the possibility of that sabotage evaluation itself being subject to sabotage … “Underperforming on dangerous-capability evaluations” would arguably include this
Yes, we want to address the possibility of sandbagging on sabotage evaluations too. Thanks for noting that our phrasing is ambiguous on this point.
I’m very skeptical of the ability of any evaluation that works strictly on inputs and outputs (not looking “inside” the model) to address the threat model where those same evals are subject to sabotage without some relevant assumptions.
We can easily incorporate white-box monitoring into any of these evaluations. This version only included black-box monitoring for simplicity, but all of the evals except for sandbagging involve a monitor producing a suspiciousness score. That score could be informed by a white-box / internals-based side channel without changing anything else.
Can that idea, “not powerful enough” be demonstrated based on evals in a non-circular way (without relying on evals that could be sabotaged within the treat model)? Its not clear to me whether that is possible.
Great question. We didn’t discuss it in the paper, because it was long enough already, but we’ve certainly thought about this problem when designing the evals and related safety cases. A rough sketch of the argument looks something like this: “We’re confident that our anti-refusal training is effective because it uses supervised fine-tuning. To double-check this empirically, our sandbagging capabilities eval indicates that even a model trained to sandbag can’t effectively do so after our anti-refusal / capabilities elicitation procedure.”.
One problem with this argument is that our sandbagging eval didn’t include the exact sabotage tasks that we’d like to make claims about—they couldn’t yet because the evals in the paper were developed in parallel. Probably we’ll want future versions of the sandbagging eval to either cover these skills and formats more closely, or include tests to demonstrate consistent generalization across domains.
Yes, we want to address the possibility of sandbagging on sabotage evaluations too. Thanks for noting that our phrasing is ambiguous on this point.
We can easily incorporate white-box monitoring into any of these evaluations. This version only included black-box monitoring for simplicity, but all of the evals except for sandbagging involve a monitor producing a suspiciousness score. That score could be informed by a white-box / internals-based side channel without changing anything else.
Great question. We didn’t discuss it in the paper, because it was long enough already, but we’ve certainly thought about this problem when designing the evals and related safety cases. A rough sketch of the argument looks something like this: “We’re confident that our anti-refusal training is effective because it uses supervised fine-tuning. To double-check this empirically, our sandbagging capabilities eval indicates that even a model trained to sandbag can’t effectively do so after our anti-refusal / capabilities elicitation procedure.”.
One problem with this argument is that our sandbagging eval didn’t include the exact sabotage tasks that we’d like to make claims about—they couldn’t yet because the evals in the paper were developed in parallel. Probably we’ll want future versions of the sandbagging eval to either cover these skills and formats more closely, or include tests to demonstrate consistent generalization across domains.