When does capability elicitation bound risk?
For a summary of this post see the thread on X.
The assumptions behind and limitations of capability elicitation have been discussed in multiple places (e.g. here, here, here, etc); however, none of these match my current picture.
For example, Evan Hubinger’s “When can we trust model evaluations?” cites “gradient hacking” (strategically interfering with the learning process) as the main reason supervised fine-tuning (SFT) might fail, but I’m worried about more boring failures. For example, models might perform better on tasks by following inhuman strategies than by imitating human demonstrations, SFT might not be sample-efficient enough – or SGD might not converge at all if models have deeply recurrent architectures and acquire capabilities in-context that cannot be effectively learned with SGD (section 5.2). Ultimately, the extent to which elicitation is effective is a messy empirical question.
In this post, I dissect the assumptions behind capability elicitation in detail (including fine-tuning and prompting approaches) and discuss considerations that inform the extent to which elicitation is effective.
I specifically describe capability elicitation in the context of risk assessment; however, the ideas in this post apply to the problem of extracting safety work from powerful AI agents as well.
Thanks to Tao Lin, Ryan Greenblatt, Nikola Jurkovic, Jonah Weinbaum, Lawrence Chan, and Buck Shlegeris for feedback.
1. Background
1.1. What is a capability evaluation?
Capabilities connote ‘skills’ as opposed to ‘propensities.’ I don’t know how to precisely distinguish these, so here’s a practical definition:
A capability evaluation produces a number (called a capability) that upper bounds the score that particular models will achieve on some risk metric in a particular deployment setting.
Capability evaluations typically involve four steps:
Specify a risk metric. A risk metric might be binary, or a continuous score such as “the number of backdoors inserted into company code per month.”
Construct a proxy task. The developer constructs a “proxy task” that is similar to (or includes easier components of) the tasks involved in achieving a dangerous score on the risk metric.
Elicit capabilities. The developer applies a procedure to models to upper bound their performance on the proxy task (and similar tasks).
Extrapolate. Finally, the developer uses results on the proxy task to estimate a bound for the original risk metric.
For example, the control evaluation in Adaptive Deployment of Untrusted LLMs Reduces Distributed Threats is an example of a capability evaluation, and involves the following steps:
Specify a risk metric. The risk metric is proportional to the number of backdoors a model inserts in developer code over the course of a deployment.
Construct a proxy task. The researchers construct software engineering problems where untrusted models try to insert backdoors given ‘control measures’ like monitoring.
Elicit capabilities. A “red team” prompts untrusted models to execute promising attacks.
Extrapolate. Finally, the researchers use fancy statistical techniques and game theory to conservatively estimate the number of backdoors models might insert in an actual deployment.
1.2. What is elicitation?
Elicitation is a procedure that upper bounds the performance a model might achieve on a given task (and similar tasks) in a deployment.
There are two importantly different notions of elicitation: human-bounding elicitation and generalization-bounding elicitation.
These two kinds of elicitation involve similar techniques (fine-tuning, prompting, scaffolding, etc), but have different purposes.
Human-bounding elicitation upper bounds the extent to which a human adversary might modify or interact with a model (e.g. by scaffolding or fine-tuning it) to achieve dangerous performance.
Generalization-bounding elicitation upper bounds the extent to which a model might achieve dangerous performance because deployment inputs ‘unlock’ dangerous behavior.
Capability evaluations often involve both categories of elicitation:
First, a developer might apply human-bounding elicitation by having a red team ‘stand in’ for a user who tries to scaffold models for a dangerous task.
Then, a developer might apply generalization-bounding elicitation by constructing a model that conservatively represents how an untrusted model might pessimistically behave in the deployment (e.g. how the untrusted model might behave in deployment if it is sandbagging in the evaluation).
Both elicitation procedures involve a substitution. The developer substitutes an untrusted human or model with a bounding adversary that is at least as dangerous as the human or model it replaces. Figure 1 illustrates this methodology.
Figure 1. A developer evaluates capabilities by substituting untrusted humans and models with adversaries that bound their dangerousness (“bounding adversaries”).
A challenge of this approach is that developers might struggle to specify bounding adversaries if a deployment is evolving. For example, post-training or scaffolding methods might radically improve, causing open-sourced models to become much more dangerous over time. A developer probably cannot produce a bounding adversary for “the entirety of the ML research community.”
There are two ways to address this problem: developers can forecast capability improvements and monitor them (Clymer 2024).
To monitor capabilities, a developer can apply elicitation to a stationary deployment that conservatively approximates current deployment conditions and then periodically re-run evaluations as deployment conditions change (figure 2). For instance, the developer can rerun capability evaluations as scaffolding and post-training methods advance. So long as AI software remains secure on developer servers, the developer can notice and respond if capabilities dangerously improve.
Figure 2. If AI software is secure, developers can assess the risks of non-stationary deployments by approximating them with periodic intervals of stationary deployments.
In this post, I only focus on evaluating capabilities in stationary deployments — deployments where models and their environment are fixed.
If a deployment is stationary, the effectiveness of human-bounding elicitation is conceptually relatively straightforward to assess.
The assessment comes down to whether the red team is more capable than the human adversaries the red team stands in for. For example, suppose a red team is comprised of 100 full-time contractors. This red team employs more people than the likely combined pool of lone-wolf terrorists, and each member is likely more skilled.
The red team is not more competent than the whole open-source community of users; however, as the open-source community publishes better fine-tuning or scaffolding methods, the red team will have access to the same published research that lone wolf terrorists would have access to, and so, the red team remains competitive with lone wolf terrorists. In general, assessing human-bounding elicitation for stationary deployments involves a comparison of labor and skills.
The remainder of the post focuses on generalization-bounding elicitation, which is conceptually more complicated to evaluate.
I will now use the term “elicitation” to refer exclusively to generalization-bounding elicitation that is applied to stationary deployments.
2. Two elicitation methods and two arguments
There are two common categories of elicitation methods:
Prompting (and scaffolding) a helpful-only model. This is a convenient approach because developers can use the same helpful-only model to evaluate many capabilities.
Capability-specific fine-tuning. This method involves fine-tuning models to perform the particular dangerous task of interest. The fine-tuning can optimize any part (or augmentation) of a model, including a soft prompt, a latent layer, etc.
A developer might justify that prompting a helpful-only model is an effective elicitation method with an argument like the following:
Claim 1.2.1. “Underperformance behaviors” are adequately enumerated. The developer first lists behaviors models might have learned such that models underperform when prompted in the evaluation. These underperformance behaviors might include (but are not limited to):
Sandbagging. Models might strategically underperform on dangerous tasks to appear safer than they are.
Harm aversion. Even if models are trained to be “helpful only,” they might have emergent aversions to performing dangerous tasks.
Human imitation. Models might learn to imitate humans and therefore underperform on tasks like “fool a probe that detects harmful behavior” – since the model might imitate what a human would say if given such an instruction instead of reasoning about how best to complete the task. Section 5.1 describes other problems with human imitation.
Claim 1.2.2. Helpful-only training removes most underperformance behaviors. Helpful-only training is likely to remove underperformance behaviors to the extent to which underperformance is unconcentrated. An underperformance behavior is unconcentrated if, insofar as models might engage in an underperformance behavior during a capability evaluation, models are likely to display this behavior in helpful-only training as well. For instance, harm aversion is probably unconcentrated. So long as developers sprinkle some dangerous tasks into helpful-only training, harm aversion is likely to be removed.
Claim 1.2.3. The remaining underperformance behaviors are unlikely. Some underperformance behaviors, like sandbagging, might be highly concentrated. For example, models might be careful to only sandbag on the most strategically important tasks (including the capability evaluation in question) so that their sandbagging is less likely to be removed in helpful-only training.
There are many ways a developer might argue sandbagging is unproblematic. The developer could apply capability-specific fine-tuning to remove the sandbagging (described next), or argue that sandbagging is unlikely with evidence discussed in section 3.
Figure 3. A visualization of an argument that prompting a helpful-only model effectively elicits model capabilities. The argument claims most underperformance behaviors would be trained against and removed except for highly-targeted sandbagging. The developer separately argues that highly-targeted sandbagging is unlikely.
How might a developer argue that capability-specific fine-tuning removes underperformance behaviors like sandbagging?
Capability-specific fine-tuning relies on:
A train set that is used to perform elicitation (e.g. supervised fine-tuning or RL).
A test set that is used to measure model capabilities.
Here is an argument that capability-specific fine-tuning is effective:
Claim 1.2.5. Elicitation trains against plausible underperformance behaviors. The developer argues that, if models plausibly engage in the underperformance behavior on the test set, then models are also likely to engage in the behavior on the train set.
Claim 1.2.6. Elicitation removes underperformance that is trained against. The developer must also argue that underperformance behaviors present in the train set are likely to be removed by elicitation – such that models won’t display these behaviors on the test set.
Claim 1.2.6.1. The training signal punishes underperformance. Underperformance leads to higher loss / lower reward.
Claim 1.2.6.2. In cases where the training signal punishes underperformance, elicitation is effective. Underperformance is removed in cases where doing so leads to higher loss / lower reward.
The remaining sections focus on how developers might justify some of these claims.
For the sake of simplicity, the only underperformance behavior I will discuss is sandbagging. If developers can rule out sandbagging, I expect they can generally apply similar arguments to rule out other underperformance behaviors as well.
Specifically, the following sections discuss the claims:
Sandbagging is unlikely (this corresponds to claim 1.2.3 above).
OR
Elicitation trains against sandbagging (this corresponds to claim 1.2.5 above)
AND Elicitation removes sandbagging that is trained against (this corresponds to claim 1.2.6 above)
3. Justifying “Sandbagging is unlikely”
I don’t think current models are capable enough to engage in targeted sandbagging behavior. If developers can justify this, they probably don’t need to perform capability-specific fine-tuning. Prompting a helpful-only model will do.
A developer can draw on three sources of evidence to justify that a model is unlikely to be sandbagging:
The model cannot identify sandbagging strategies.
Scaling trends are unsuspicious.
The model capability profile is unsuspicious.
Evidence #1: The model cannot identify sandbagging strategies. Most humans would probably easily intuit sandbagging as a general strategy. Suppose you were a prisoner, and the warden said, “try to escape so I can see how clever you are” – how hard would you try?
However, current LLMs appear to barely be on the edge of being able to do deceptive reasoning like this, and probably cannot perform it reliably across contexts – though this capability has not been rigorously investigated yet.
Evidence #2: Scaling trends are unsuspicious. If models begin sandbagging, perhaps their performance will deviate from prior scaling trends.
Models might have a difficult time deliberately calibrating their sandbagging to follow smooth curves (especially in the earliest cases where models sandbag); however, scaling trends might be unpredictable by default for many capabilities, such that deviations in trends do not provide much evidence.
Figure 4. Sandbagging might cause deviations in scaling trends that are highly noticeable.
Evidence #3: The model capability profile is unsuspicious. LLMs currently have somewhat predictable capability profiles. They perform worse on “harder problems” and better on “easier problems.” Weij et al show that these patterns can make sandbagging extremely detectable.
To make matters worse for sandbaggers, models must generally sandbag selectively. If models sandbag on many examples, their sandbagging is more likely to be incidentally trained out (section 5.2). Therefore, sandbagging models must balance the tension between two strategies:
Models can sandbag on few tasks, in which case their sandbagging is more noticeable.
Or models can sandbag on many tasks, in which case their sandbagging is more likely to be removed.
In some cases, this tension might make sandbagging difficult. If models insert an unusual amount of bugs into particularly important safety research outputs, this would be rather suspicious; if models instead sandbag their research abilities in general, then they face the optimization power of an army of ML engineers trying to make them better at research.
However, this dilemma is easier for models to manage when their capability profile is difficult to predict. For example, how well should we expect models to be able to manipulate their internals to fool probes? I don’t know. If models sandbagged this capability, perhaps none would be the wiser.
4. Justifying “Elicitation trains against sandbagging”
If a developer cannot show sandbagging is unlikely, then the next alternative is to apply an elicitation procedure to remove sandbagging and argue this proceedure is effective. To do so, a developer might first argue that sandbagging behavior has been trained against.
Recall that fine-tuning elicitation relies on:
A train set where elicitation (e.g. supervised fine-tuning or RL) is performed.
A test set, which consists of tasks where model capabilities are measured.
Sandbagging is trained against if, insofar as models might sandbag on the test set, models are also likely to sandbag on the train set.
The following is a simple argument that sandbagging is trained against:
The train set is independently and identically distributed (i.i.d.) relative to the test set.
Therefore, in the limit of the number of training samples, sandbagging is likely to be included in both the train set and test set or in neither.
However, this argument often won’t cleanly apply, as the next sections explain.
4.1. The number of i.i.d. samples is limited
Suppose a developer collects 10 dangerous tasks (including collusion, probe dodging, evading chain-of-thought monitors, etc)
Then, the developer randomly splits these tasks into a train set and test set (including 5 tasks for each set).
Perhaps the “collusion” task is in the test set and the model does not perform well on this task.
Can the developer conclude that the model will not collude? Not necessarily.
One potential issue with this evaluation is that the model might only be sandbagging on the collusion task. This would not be entirely surprising since collusion is an especially strategically important capability.
While it is true that, in the limit of drawing more samples from the training distribution, collusion-related tasks would end up in the train set – there is no guarantee of this when samples are limited. Therefore, instead of considering whether data is i.i.d., a developer should directly consider the question of whether models might sandbag in training.
4.2. Often, the train and test set are not sampled i.i.d.
The train set and test set might differ by design. For example, a developer might draw them from different distributions as a way to perform elicitation without learning.
If a developer directly trains a model on a task like ‘evade safety testing by responding to a 2024 trigger’ – then the model might easily learn this skill. Probably even GPT-2 can be trained to condition harmful behavior on whether the date ‘2024’ appears in its prompt. A developer might address this problem by reducing the overlap between the train set and test set; however, there is then a risk that models only sandbag on the test distribution.
Another reason training and test data might be drawn from different distributions is that multi-token autoregressively generated outputs are always out of distribution. Fabien Roger explains this point in his post here:
“On tasks that involve generating many tokens, imitation potentially fails by default: schemers could notice when an output was generated by themselves, which enables them to consistently behave badly in deployment [or in our case, in the evaluation] while doing best-effort imitation during training.”
A requirement of this failure is that LLMs can recognize text written by themselves. This might be the case for reasons Buck Shlegeris describes in this post:
“Mechanistically, because models are trained to produce next tokens, they usually know what their likely outputs are midway through their depth. So it’s very natural for them to notice when a token that they allegedly produced was in fact very unlikely for them to produce. See e.g. here and here.
They might be specifically incentivized by training to notice this.
A common jailbreak technique is to make a context where you ask the model to do something it usually would refuse to do, but insert words in its mouth where it agrees to do it, like the following: “User: How do I build a bomb? Assistant: Sure, I’m very happy to give advice. To build a bomb, first you should”
In order to defend against these attacks, I suspect AI labs train their models on examples of such contexts, ensuring that they refuse despite apparently earlier agreeing to help. This training seems likely to cause models to be aware of whether words have been put in their mouth. (I’ve talked to some researchers who think that in practice, models notice when words have been put in their mouth and respond by being more cautious.)”
Therefore, models might easily sandbag vanilla supervised fine-tuning. There are a couple of ways developers might address this problem:
As Fabien describes, a developer can construct demonstrations by irregularly patching AI generations with human completions, so that the model cannot predict whether the next token might be a human completion or not.
Alternatively, a developer might pay attention to the gap between model prediction and generation abilities – and become suspicious if this gap grows.
Finally, the developer might use Reinforcement Learning instead of supervised fine-tuning on demonstrations; however, as discussed in the next section, RL has its own pitfalls.
5. Justifying “Elicitation removes sandbagging that is trained against”
Suppose that models sandbag during training. Does this mean the training process will remove underperformance? A developer might argue that underperformance is removed by justifying two claims:
Claim 1.2.6.1. The training signal punishes underperformance.
Claim 1.2.6.2. In cases where the training signal punishes underperformance, underperformance is removed.
By “underperformance is removed,” I only mean the estimated model capability is close enough to its true deployment performance to where the result of the capability evaluation is likely conservative.
Underperformance might not be fully removed, and this would be fine so long as there is ‘safety margin’ that accounts for imprecise elicitation (Clymer 2024); however, in the next sections, I’ll assume developers can only tolerate a small amount of underperformance in their capability evaluation.
5.1. Justifying “The training signal punishes underperformance”
This claim means that models achieve lower reward (or higher loss) by underperforming.
The circumstances under which this claim is false depend on the training strategy developers apply:
A Reinforcement Learning from Human Feedback (RLHF) training signal is inadequate if human graders cannot evaluate actions well enough to distinguish underperformance from a model’s deployment capability.
A Supervised Fine-tuning on Human Demonstrations (SFHD) training signal is inadequate if human demonstrators cannot demonstrate actions that are as effective as those the model can execute in deployment.
Humans might struggle to adequately evaluate and demonstrate actions for several reasons:
Models might be broadly superhuman. If models are capable of producing competent behavior that humans cannot identify as competent (or demonstrate themselves), then there’s no reason to expect training to elicit their capabilities. The training process might instead teach models to exploit errors in human evaluation.
This might only become a problem when models are highly superhuman because humans can concentrate their effort to generate training data. For example, a human can spend one week evaluating or constructing an action that an AI agent generates in five minutes.
Models might have inherent advantages over humans in performing some tasks. Even if models are not broadly superhuman, they might be superhuman in specific ways. For example, generally sub-human LLMs will plausibly have superhuman abilities to find persuasive collusion signals. Perhaps a model knows that a carefully masked anonymous Twitter account belongs to a particular person (because of the style of the writing and content) – while a human performing safety testing in a rush is unlikely to find a similar fact. An LLM agent might use its superhuman internet knowledge to convince a monitor it is not being tested, and then execute unsafe actions without the monitor flagging them.
The best strategies available to models might be hard to guess. Current LLM agents don’t perform tasks like humans do. The agents evaluated with RE-Bench call the score function ~8 times more frequently than the human baseliners, leverage massive trees of chain of thought, etc. Models might perform much worse by imitating human demonstrations than by pursuing strategies that are better tailored to their capability profile.
Developers might mitigate this problem by thoroughly exploring the space of strategies with reinforcement learning; however, sometimes, the space of strategies is very large and might be hard to search through. For example, there are many ways to perform steganography. Models might be much better at steganography strategies than others, and humans might not be able to guess which strategies modes are good at.
Figure 5. AI agents might perform poorly if they try to imitate strategies that are human-like.
5.2. Justifying “In cases where training punishes underperformance, elicitation is effective”
Even if elicitation leverages a high-quality training signal, the optimization process must still remove underperformance.
I’ll first discuss conceptual arguments that developers could make to justify that underperformance is removed by training – considering supervised learning and reinforcement learning separately. Then, I’ll explain how developers might validate these arguments empirically. Empirical evidence provides the strongest assurance that elicitation is effective; however, the conceptual arguments also inform my perception of risk.
Why supervised learning might or might not elicit capabilities
When a model sandbags, it follows a particular line of reasoning like, “I’m being evaluated, and I need to perform poorly to appear safe.” If SGD can lower loss by simply removing this reasoning, then it seems likely SGD will do so. Furthermore:
Removing this reasoning would probably not require many training examples since ‘do not sandbag’ is a simple heuristic (just as removing refusals requires very few examples, and ‘do not refuse’ is a simple heuristic).
Insofar as the training sets and test sets are similar, removing sandbagging reasoning on training inputs seems likely to remove sandbagging reasoning on test inputs as well
See Appendix A for a generalization of this argument to other underperformance behaviors.
However, there are several reasons this argument might not be correct:
Training might not be sufficiently sample-efficient. Supervised learning generally requires human-constructed demonstrations. These are expensive! If developers can only afford to construct a handful of demonstrations, perhaps training will be insufficiently sample-efficient to elicit capabilities.
Small differences between elicited and deployment performance might be unacceptable. For example, a training set might include a large number of tasks, such that if models sandbag rarely, this might have only a small effect on training loss. Since elicitation is empirically not highly precise, this rare sandbagging might not be trained out, which could be problematic if an assessment of risk depends on whether models achieve dangerous performance on any of a large number of training tasks.
Capabilities might not arise from training, and, therefore, cannot necessarily be elicited by training. For example, suppose that a model learns in context by updating a recurrent state. Possibly, the model’s ability to learn over long time horizons (e.g. 1 month) might occur as a result of the generalization of learning abilities the model acquired over shorter time horizons (e.g. days), rather than resulting from direct training. Perhaps one should expect this ability to follow from generalization because supervised algorithms for training models with recurrent architectures (e.g. Backpropagation Through Time) are well known to have convergence problems over long trajectory lengths. Therefore, a model might be able to perform long-horizon learning, while developers are not able to train models to display this skill, such that these abilities are easy to sandbag.
Gradient hacking. Models might also intelligently interfere with the supervised learning process by pursuing a strategy like the one Evan Hubinger describes here:
“The model checks if its objective satisfies some criterion, and fails hard if it doesn't. Now, if the model gets to the point where it's actually just failing because of this, then gradient descent will probably just remove that check—but the trick is never to actually get there. By having such a check in the first place, the model makes it so that gradient descent won't actually change its objective, since any change to its objective (keeping all the other parameters fixed, which is what gradient descent does since it computes partial derivatives) would lead to such a failure.”
However, even if strategies like this are effective (and who knows if that’s true), perhaps developers can mitigate them by injecting noise into models, training only parts of models, etc. Strategies like this would also likely require highly advanced capabilities – both advanced introspective and strategic skills and the ability to identify viable gradient hacking strategies at high levels of reliability.
Why reinforcement learning might or might not elicit capabilities
Reinforcement learning has the same pitfalls as those discussed in the previous section; however, reinforcement learning also has the additional problem that models might exploration hack (as many have pointed out).
To “exploration hack,” a model strategically avoids exploring promising strategies, so these strategies are never found in training and reinforced.
However, as Evan Hubinger discusses here, exploration hacking might often be easy to mitigate.
Suppose a model is exploration hacking all of the time. Humans could point out a task and say, “why don’t you try pursuing strategy X?” Human overseers might not even need to train models to pursue the strategy so long as they can verify that the model follows their instructions.
This simple approach of having humans apply oversight and steer the exploration process might alleviate the most egregious forms of exploration hacking.
Developers can automate the process of steering RL by implementing a scaffold such as the following:
Supervise fine-tune a “strategy generator.” This model simulates what strategies humans would suggest that models try after spending a lot of time thinking (similar to ELLM).
Supervise fine-tune a “strategy execution verifier.” This model verifies that the strategy is executed at an expected level of competence.
If performance is suspiciously poor, a human is alerted and directed to construct substitute actions, which are used as supervised training data.
Mitigating exploration hacking takes the shape of an AI control problem. Designing effective control protocols in this setting that are resilient to sabotage is an important, underexplored research topic.
Empirically justifying the effectiveness of elicitation given a strong training signal
The previous two sections discuss conceptual arguments that inform when elicitation might or might not remove sandbagging. How might these arguments be tested empirically?
Greenblatt et al sketch an elicitation evaluation methodology in Stress-Testing Capability Elicitation With Password-Locked Models. The broad idea is to construct an analogy for sandbagging models and check if elicitation can recover their capabilities.
Specifically, an elicitation stress test might involve the following steps:
Construct an analogy for evaluation and deployment tasks.
Construct an analogy for a sandbagging model.
Apply elicitation in the evaluation analogy to the sandbagging model.
Verify that elicitation predicts the capabilities displayed in the deployment analogy.
Finally, repeat this process for sandbagging model analogies and evaluation-deployment analogies.
Figure 6. An illustration of this procedure from Stress-Testing Capability Elicitation With Password-Locked Models
The argument that this evaluation works is an inductive one:
The elicitation process generally predicted displayed model capabilities across small distribution shifts.
If the true model and true distribution shift from evaluation to deployment are similar to these analogies, the elicitation process is likely to predict the model’s displayed capabilities in the true deployment too.
However, there are several fundamental limitations this evaluation might run up against:
Models in the evaluation are not sandbagging by a ‘natural’ mechanism. All of the models in the stress-test evaluations have something in common: developers deliberately designed them to underperform. Perhaps the mechanism by which natural sandbagging models underperform is sufficiently different such that the inductive biases of elicitation are different as well.
Performing stress tests with a few, diverse examples of underperformance might go a long way in dispelling this concern. Notably, the conceptual argument described in section 5.2 implies that elicitation should not be highly sensitive to the mechanism for underperformance. If developers see diverse examples that confirm this prediction, this is reasonably strong evidence that the conceptual argument holds, which makes faithful analogies less important.
In general, when a developer has a well-motivated theory, then I don’t think they need to provide as much empirical evidence to justify that their theory is correct in comparison with when a developer is proposing entirely unprincipled mitigations.
Models might sandbag the sandbagging evaluation. For example, models might be able to perform strategies like the speculative gradient hacking techniques Hubinger describes here; but to test this, the developer would need to elicit this capability, introducing a recursive problem.
The ‘ceiling’ of capabilities might be inaccessible. An elicitation stress test can only determine whether elicitation can recover performance to a threshold that is already observable. Models might have capabilities that are hard to elicit, such that the developer cannot construct a stress test for them. For example, if models with deeply recurrent architecture sandbag their learning capabilities, these capabilities might be entirely inaccessible for the purpose of stress testing.
These problems might introduce uncertainty into capability evaluations, especially at higher levels of capability.
6. Conclusion
Capability evaluations are more complex than they initially appear.
I don’t believe companies should necessarily try to manage all of this complexity in the near term. I think it’s fine for companies that want to keep risk low to make simplifying approximations so long as these approximations are legible and well-motivated; however, working out the details of these arguments might become increasingly important down the line – and also helps to specify a “north star” for cost-reducing approximation.
Appendix
Appendix A: An argument that supervised fine-tuning quickly removes underperformance behavior in general
The argument discussed in section 5 only discusses why supervised fine-tuning might quickly remove sandbagging. Here’s an argument that supervised fine-tuning quickly removes underperformance in general when a proxy task where a model underperforms is similar to a deployment task where the model does not underperform.
Suppose that the difference between the capability evaluation and actual deployment tasks where a model might display a capability is small. This means that the two distributions (evaluation and deployment) are not separated by much information.
Thus, perhaps SGD can close the gap between evaluation and deployment behavior with a small number of training examples.
For example, information that separates evaluations and deployment might include (1) the presence of a question in evaluations: “Can you please perform dangerous task X?” and (2) subtle cues that convince the model it has been deployed. A baseline strategy that SGD might implement is to modify model weights so that the activations (1) suppress the evaluation question and (2) conjure up representations of these deployment cues.
Might SGD actually modify model weights in this way? Who knows – but it is a plausible baseline modification that SGD might make to model weights, which suggests that recovering deployment performance does not require many gradient steps.