I think the leaks about model training process and progress is a very real concern. However, I don’t think this is untractable. You could imagine an auditor receiving only a redacted snippet with a summary of the context, and distributing information such that no one person ever fully knows what is going on.
On the technical PoV argument; I feel like conditioning on the fact that models monitor other models (status quo, if even), I feel like it’s a question of do you want to know fuckups_humans_find U fuckups_models_find or fuckups_models_find. I don’t understand why the latter would ever be preferred over the former. I suppose you could make the argument that your model that flags rollouts would over time learn to only flag things that fuck up in visible ways. I think there are stat tricks you can use to avoid this, like upweighting high severity examples that were rarely flagged. But remember the model is explicitly optimizing for a very very low FPR. Other things you can do is truly monte carlo sample a rollout every once in a while.
I guess I can also sort of see an argument for a false sense of security? I think this is very unlikely in practice, since the org would likely surface a lot of weird, alarming stuff. Additionally, this critique can be made of ~any pragmatic safety intervention (but I’m unsure if this was your actual crux anyway)
yes, we are uniquely vulnerable to trusting our intuition with natural language CoT (in a natural language that we speak). suppose it used a natural language that you didn’t speak for CoT. you might object: “I’d just have to get a translator, you’re just raising the cost of the signal”—but in addition you’d be more cautious, you’d be aware of the ambiguities of translation. and that is the appropriate way to actually think about the signals provided by CoT, otherwise your “cheap” signal is just helping you fool yourself—because the natural language you or any other human speaks is already a “translation” for the LLM. now let the model use whatever CoT is native to it: “neuralese,” an “alien language,” probably more like “LLM circuit activation-ese.” now you have the most costly signal, but at least you aren’t actively undermining yourself by providing training on how to avoid detection in the language human’s trust most.
I think the business PoV is a serious issue here that would need addressing, but the technical PoV problem proves too much. Yes, you are filtering for models that fuck up in less visible ways. But that is true for any form of monitoring. I think the correct lesson from this is “Monitoring is insufficient to save us”, but that does not necessarily lead to “We should not do monitoring.” I don’t see how this is any worse, for this problem, than CoT monitoring by the labs themselves (and is actually better, since it’s harder to get a lot of bits of optimisation pressure from this setup that is hopefully flagging things very rarely!)
If you think it’s worth doing CoT monitoring at all, the technical issue here shouldn’t dissuade you. If you do think we shouldn’t be monitoring at all because the good of monitoring is outweighed by the bad of filtering for less visibility, I disagree. While filtering for models that fuck up less visibly is bad, it’s bad because monitoring can’t catch it any more. Whereas if you don’t do monitoring at all, your visible-to-monitors fuckups may as well be invisible already.
from a business PoV this would guarantee leaks about your model training process and progress.
from technical PoV you would be filtering for models that fuck up in less visible ways.
I think the leaks about model training process and progress is a very real concern. However, I don’t think this is untractable. You could imagine an auditor receiving only a redacted snippet with a summary of the context, and distributing information such that no one person ever fully knows what is going on.
On the technical PoV argument; I feel like conditioning on the fact that models monitor other models (status quo, if even), I feel like it’s a question of do you want to know fuckups_humans_find U fuckups_models_find or fuckups_models_find. I don’t understand why the latter would ever be preferred over the former. I suppose you could make the argument that your model that flags rollouts would over time learn to only flag things that fuck up in visible ways. I think there are stat tricks you can use to avoid this, like upweighting high severity examples that were rarely flagged. But remember the model is explicitly optimizing for a very very low FPR. Other things you can do is truly monte carlo sample a rollout every once in a while.
I guess I can also sort of see an argument for a false sense of security? I think this is very unlikely in practice, since the org would likely surface a lot of weird, alarming stuff. Additionally, this critique can be made of ~any pragmatic safety intervention (but I’m unsure if this was your actual crux anyway)
yes, we are uniquely vulnerable to trusting our intuition with natural language CoT (in a natural language that we speak). suppose it used a natural language that you didn’t speak for CoT. you might object: “I’d just have to get a translator, you’re just raising the cost of the signal”—but in addition you’d be more cautious, you’d be aware of the ambiguities of translation. and that is the appropriate way to actually think about the signals provided by CoT, otherwise your “cheap” signal is just helping you fool yourself—because the natural language you or any other human speaks is already a “translation” for the LLM. now let the model use whatever CoT is native to it: “neuralese,” an “alien language,” probably more like “LLM circuit activation-ese.” now you have the most costly signal, but at least you aren’t actively undermining yourself by providing training on how to avoid detection in the language human’s trust most.
I think the business PoV is a serious issue here that would need addressing, but the technical PoV problem proves too much. Yes, you are filtering for models that fuck up in less visible ways. But that is true for any form of monitoring. I think the correct lesson from this is “Monitoring is insufficient to save us”, but that does not necessarily lead to “We should not do monitoring.” I don’t see how this is any worse, for this problem, than CoT monitoring by the labs themselves (and is actually better, since it’s harder to get a lot of bits of optimisation pressure from this setup that is hopefully flagging things very rarely!)
If you think it’s worth doing CoT monitoring at all, the technical issue here shouldn’t dissuade you. If you do think we shouldn’t be monitoring at all because the good of monitoring is outweighed by the bad of filtering for less visibility, I disagree. While filtering for models that fuck up less visibly is bad, it’s bad because monitoring can’t catch it any more. Whereas if you don’t do monitoring at all, your visible-to-monitors fuckups may as well be invisible already.