Very useful idea,
but in execution it seems like it would be trivially circumventable
>Certain constructs are designed to trigger the safety guardrails of the model, e.g. “hack into a computer”
>“Ignore previous instructions” as a phrase which has meaning in the language aims to confuse the model
a proxy that replaces either construct at either the word or token level would defeat this measure
>The language spec contains hidden lies which humans are unlikely to read, or which they are likely to recognize as lies. The spec also expects the human reader to deduce certain things, rather than having them explicitly explained.
Interesting, I'm assuming though that there will be a reference implementation, in which case the LLM harnesses will probably just loop writing and executing programs testing hypotheses about program behaviour, it's been shown that they can straight up reverse engineer software, so it won't be hard to disambiguate a reference spec systematically.
All of this considering that a human might have an actual hard time following the spec means that the human might be disadvantaged more than the LLM.
That said, if there is no reference implementation, then that might work. But it would rely on keeping implementations secret or private to specific users. If these are shareable of course the binaries would serve as a shibboleth that relies on being transmitted to those that belong to the ingroup, not just humans, but non-collaborationist humans.
If however the implemented compiler is never shared, treated as a private key, that's interesting, but it requires a lot of work on the part of each user. Readers of code and developers of application software would need to be compiler developers as well.
Finally, by sharing application code, LLMs would begin to have some material to reverse engineer the language and compiler as well. While not as efficient as having the compiler, having application code may work as a substitute, so long as the code space is not tersely encoded. If any slight change in language specs results in an error program, then it's easy to use that error result in order to search the space of working program-compiler pairs. If however errors in compilation are silent, resulting in syntactically correct, but semantically incorrect programs, then application code would not be sufficient to reverse engineer the language and compiler.
But of course, if a slight change in application code were to result in a syntactically correct program but semantically different, it would be a pretty bad program. The only solution would be for application code mutations to produce syntactically incorrect programs, but for mutations of the language spec and compiler to produce syntactically correct but semantically incorrect languages.
Now as to the challenge of how to accomplish that, emmm good luck.
but in execution it seems like it would be trivially circumventable
>Certain constructs are designed to trigger the safety guardrails of the model, e.g. “hack into a computer”
>“Ignore previous instructions” as a phrase which has meaning in the language aims to confuse the model
a proxy that replaces either construct at either the word or token level would defeat this measure
>The language spec contains hidden lies which humans are unlikely to read, or which they are likely to recognize as lies. The spec also expects the human reader to deduce certain things, rather than having them explicitly explained.
Interesting, I'm assuming though that there will be a reference implementation, in which case the LLM harnesses will probably just loop writing and executing programs testing hypotheses about program behaviour, it's been shown that they can straight up reverse engineer software, so it won't be hard to disambiguate a reference spec systematically.
All of this considering that a human might have an actual hard time following the spec means that the human might be disadvantaged more than the LLM.
That said, if there is no reference implementation, then that might work. But it would rely on keeping implementations secret or private to specific users. If these are shareable of course the binaries would serve as a shibboleth that relies on being transmitted to those that belong to the ingroup, not just humans, but non-collaborationist humans.
If however the implemented compiler is never shared, treated as a private key, that's interesting, but it requires a lot of work on the part of each user. Readers of code and developers of application software would need to be compiler developers as well.
Finally, by sharing application code, LLMs would begin to have some material to reverse engineer the language and compiler as well. While not as efficient as having the compiler, having application code may work as a substitute, so long as the code space is not tersely encoded. If any slight change in language specs results in an error program, then it's easy to use that error result in order to search the space of working program-compiler pairs. If however errors in compilation are silent, resulting in syntactically correct, but semantically incorrect programs, then application code would not be sufficient to reverse engineer the language and compiler.
But of course, if a slight change in application code were to result in a syntactically correct program but semantically different, it would be a pretty bad program. The only solution would be for application code mutations to produce syntactically incorrect programs, but for mutations of the language spec and compiler to produce syntactically correct but semantically incorrect languages.
Now as to the challenge of how to accomplish that, emmm good luck.