This isn't necessarily something you have to be tricked by a third party into. Be more Gwern! If there are two brands of cola you've not tried before, one stevia and one not, you can do a blinded trial by decanting them or similar. It'll certainly be easier with a third party, but one could do this solo.
There's an analogy with the notion of "toil" which is popular in the Site Reliability Engineering subfield of software engineering. Toil in this context is work which is necessary to keep the lights on, but which doesn't actually improve anything. In some sense, the job of an SRE is to reduce toil; they must certainly be psychologically able to deal with it, because it's the stuff with which they work! I'll just talk a bit about it here in a fairly undirected way, in case any of it gives you ideas. The SRE Handbook is well worth reading if you're a software engineer, by the way.
The SRE's (imperfectly-aligned-to-your-problem) answer to the problem "we're being buried in toil" is to track the proportion of time spent on toil versus "productive" work. If the toil becomes greater than some proportion, the response is to divert resources from feature work towards reducing the toil (e.g. by automating it, or addressing the root causes of the issues that you're spending time fighting). An extremely simple example of such automation is setting up direct debits to pay bills, or repeat online orders for groceries. An SRE performing any particular piece of toil would at least spend a moment to think about whether it could be automated instead.
Runbooks (lists of triggers and responses to guide you through operations) are a standard SRE-style tool for making the toil less error-prone and stressful. To know when you should be performing some piece of toil, it's standard to identify and set up alerts, so that you have a specific trigger. ("I just got a Slack alert saying that the database has reached 70% capacity; the alert pointed me to this wiki page telling me step-by-step how to bring the database offline safely and perform a vacuum to release space", or "my washing basket is 3/4 full; that means this evening I will be putting on a load of laundry".)
It's also standard to batch up the toil. A team of people will usually have a rota, so that any given person's time is mostly spent doing productive work, and the toil is the responsibility of the people on duty. That way, you only get a small amount of relative hell before you rotate onto better work. The toil necessary to maintain a human life is generally not that urgent and is hence very amenable to batching, except for the most basic biological things like using the toilet or putting food into your mouth (note: preparing food is not an urgent biological need unless your planning procedures have failed!). You can batch up a lot of it: e.g. you spend half of Saturday preparing meals for the week, or otherwise arranging so that the daily time spent preparing and putting food into your mouth is as low as possible, and you can declare that one Sunday every two months is paperwork.
It would be nice to have example GPT4 outputs for each demonstrating the wrongness, because I tried "Continue the sequences: 5, 8, 13," expecting the answer 21, and for me it did indeed explain along the lines "21, because Fibonacci". As you say, this dataset is inherently unstable over time, so it would be nice to snapshot it. (One obvious way would be to convert from a list of strings to a dictionary of `{ "prompt": ["response1", "response2", …] }`; the current schema injects into this by setting all those lists to be empty.)
suffering is bad because anyone who suffering is objectively in negative state of being.
I believe this sentence reifies a thought that contains either a type error or a circular definition. I could tell you which if you tabooed the words "suffering" and "negative state of being", but as it stands, your actual belief is so unclear as to be impossible to discuss. I suspect the main problem is that something being objectively true does not mean anyone has to care about it. More concretely, is the problem with psychopaths really that they're just not smart enough to know that people don't want to be in pain?
By the way, you're making an awful lot of extremely strong and very common points with no evidence here ("ChaosGPT is aligned", "we know how to ensure alignment", "the AI understanding that you don't want it to destroy humanity implies that it will not want to destroy humanity", "the AI will refuse to cooperate with people who have ill intentions", "a system that optimises a loss function and approximates a data generation function will highly value human life by default", "a slight misalignment is far from doomsday", "an entity that is built to maximise something might doubt its mission"), as well as the standard "it's better to focus on X than Y" in an area where almost nobody is focusing on Y anyway. What's your background, so that we can recommend the appropriate reading material? For example, have you read the Sequences, or Bostrom's Superintelligence?
(Or more concretely, Grand Central Station wasn't a Schelling point in New York before it was built. Before that time, presumably there were different Schelling points.)
Fittingly, I… don't think those words actually identify sazen :P I claim that "the thing you get if you do not take inferential distance into account" for most people would be baffled non-comprehension, not active misunderstanding.
Wonderful, thanks! Recording the quote for posterity:
Nothing can be soundly understood
If daylight itself needs proof.
(Imam al-Haddad, The Sublime Treasures)
Indeed, this is what I use. It feels much more natural to me in the following case, where obviously our statement is not a question:
Dr Johnson kicked a large rock, and said, as his foot rebounded, "Do I refute it thus?".
And "obviously" the full stop should go outside, because of:
Dr Johnson kicked a large rock, and said, as his foot rebounded, "Do I refute it thus?", howling with pain.
And there's nothing special about a question mark, so this rule should be identical if a full stop is substituted.
If you have the power to change the Google form, by the way, one of its questions is "What dose did you take (in mg)? 0.5, 1, 1.5, 2+"
Presumably this should read "(in g)", and it would also help if it were explicitly stated as being "per day".