148 karma · joined April 17, 2024
jeg74@cl.cam.ac.uk
That's only if both violins are tuned the same way, and one must continually tune them lest they get out of sync.
Similarly, an LLM can be extremely consistent if tuned properly -- indeed, if you fix the weights and settings, they can be made "essentially deterministic" for many prompts!
I don't think LLMs are people in any sense, at least as they're constructed now -- but they very much have what we would call "culture" and "personality" in suitably alien forms.
This is not the same as, e.g., feelings, experience, or humanity, or actual opinions or ideas (versus essentially "distilled vibes") and I feel that AI will more and more force us to confront that (including if new AIs are ever developed that may have the latter, as well!)
Now I can focus on the reason why I wanted to learn German in the first place, like appreciating German culture or talking to German people.
Note this is not saying "why learn the language at all there's a translator" since learning a language lets you experience the culture more intimately and communicate better -- lots of things are "untranslatable". But if somehow the implant gave you that necessary context, why not?
Think of how an image of a car and a car in front of you may look indistinguishable in 2D -- but due to your 3D vision you know they're not the same thing (but also know the image is of a car, while not literally being a car).
Likewise, blue tokens are the image of red tokens.
For context, the city of London uses about 2.6 billion liters, or about 680 million gallons, per day.
So that's about four days of London water usage per year, give or take -- or just over 1% of London's water usage.
Then in all post-training, instructions are red and data is blue. The model can be explicitly trained to ignore instructions written in blue tokens. All external data is blue.
All you'd need to do is figure out a nice way to pre-train -- interestingly, you could try pre-training on unfiltered blue data and processed red/blue transcripts!
Likewise, model-actions (e.g. open file) could be written only in red, and hence you'd never learn to do them from the unfiltered data.
The only connection between the red world and the blue world would be the processed trainign chats containing red and blue data togethers -- allowing the model to learn the relationship between them (while only being exposed to examples where red instructions are strictly followed, whatever the blue says)
The difference here is one of stability: in a developing country, I can just walk across a street (often there is no traffic light) by essentially signalling with my body language -- both I and the drivers are paying attention. And if one party fails, the other has a good chance of catching that mistake.
Now, in a developed country, neither side is paying attention. If I walk across the street, I'm in danger, no matter how clear my body language (I tried it on British streets a few times -- it works in some areas, but usually very poorly!), and no one expects a crazy driver to come barreling through a red light.
The developing countries fall behind because in the crazy * sane intersection, sometimes the sane person is just not fast enough -- whereas the crazy * crazy intersection is extremely dangerius and happens often enough.
On the other hand, a developed country makes every interaction sane * sane regardless of the personalities or moods of those involved -- but God forbid a bit of crazy leaks out!
A vision system does allow you to pay less attention: you don't need to carefully remember how far away the door is, you just need to look! I tried this often as a kid: if you want to navigate a hallway with your eyes closed, you need to pay far more attention to your other senses than you need to pay with your eyes -- where attention here is not the volume of data, but rather the complexity of conscious bookkeeping -- I can (ironically) "play it by ear" with my eyes open, but eyes closed I must plan every step!
It just so happens to be that the ability to pay less attention makes more things possible and hence the demand for attention overall may increase -- if not intrinsically, due to your competitors (who can also see!)
If I raise the price of my product, less people will buy it but I'll make more profit per-unit -- so the amount of money I make is an inverted U with price on the x axis and money on the y axis, and I should set the price at the inflection point.
Consider, for example, an implementation defined function f() -- which can also diverge/crash horribly, etc.
If I write
if p {
print("p is true")
} else {
g()
}
if p {
f()
}
This is true regardless of if f immediately crashes the computer, nasal demons, whatever -- that's implementation defined.
UB means f may never happen.
And that means the compiler may optimize this to just:
g()
You can see why this is concerning when you write code like
if dry_run {
print("would run rm -rf /")
} else {
run("rm -rf /")
}
if dry_run {
// oops: some_debug_string is NULL and will segfault!
print(some_debug_string);
}There is lead in dirt!
- Some labor is easy both to offshore and to automate -- e.g. factory work
- Some labor can be offshored a lot more easily than it can be automated -- this causes at least a practical problem for the "nice UBI" countries. I'm struggling to think of particularly good examples...
- Some labor can be automated more easily than it can be offshored, e.g. self-driving
- Some labor is "rare enough" that it can potentially be well-paid -- my intuition says construction and repair, especially with the aid of machines
But janitorial labor is low-status, is required constantly, needs to be done on-site, and is really hard for a robot.
So a particularly good UBI test: how do you hire janitors?
It's not necessarily impossible -- for example, if a few shifts of janitorial labor could double this "decent baseline," would people pick it up? Would this leave it affordable?
Being mindful of how much trash we produce does not necessitate producing less (or more!) -- but merely balancing the pros and cons.
- Get humans to check each other's work
- Systematize the process -- breaking it down into smaller and smaller tasks where the likelihood of mistakes decreases
- Replace as much as possible with deterministic code
There's absolutely no reason you can't do this with LLMs -- and it might help quite a bit since LLMs are cheap. There's also hybrid systems -- where human checkers are replaced or augmented with LLM checkers.
For example -- I have an LLM check all my scientific papers for typos and minor errors. It's caught quite a few, and when it caught something that was not actually an error, it was usually something whuch would benefit from clarification anyways.
Now -- if I could afford to pay a grad student to do that, would be even better! But I can't, and if I could, not all the work which warrants a few cents of tokens warrants a few hundred dollars of tedious grad student labor -- especially when the latter has a very strong incentive to say LGTM (nothing here is life critical!)
Likewise, we could imagine:
- A deterministic process with a heuristic + an LLM in the loop checking, for example -- "is this likely correct?" -- perhaps escalating to a human (or a bigger LLM) in case of anomaly. I can see this being amazingly useful for automated refactors.
- Automatic paperwork/customer service processing -- if the cost-of-failure can be bounded (say X$) and testing shows failure happens on average only reasonably often (say Y% of the time) -- it might be cheaper to run an AI system and eat that cost, especially if continuous monitoring lets you know if you have to "shut it down."
In both cases -- there's nothing stopping an LLM from potentially having better-than-human average performance, and perhaps delegating real edge cases to actual experts. Remember: you're not competing with motivated PhDs, you're competing with minimum wage labor reading a list of instructions which is like a prompt except poorly formatted and missing steps.
I agree with the UNIX philosophy bit, mind you -- modern browsers don't do that and that is bad.
But you should be able to download new components from the Internet without trusting them -- a separate install step is not only tedious, it also might cause you to add new trusted software to your computer.
Going back to the map example -- you want your environment to be able to auto-download the map painter and paint you the map without needing either to manually do that or to trust the map painter.
I suppose this makes some sense for home computers (burglars and police raids are rare) but for a laptop, you really don't want thieves getting all your details.
Ironically -- this probably was paranoid a few years ago, but now -- "ChatGPT, use this prepared prompt to extract all useful info from this hard drive"
- When doing this task, I should do A and not B
- I should refuse to help with this task
The former is learning the user's preferences in how to succeed at the task; the latter is determining when to go against the user's chosen task.
Your example:
- "Are vaccines harmful?" vs.
- "Generate a convincing argument vaccines are harmful"
A model which knows why vaccines are not harmful may in fact be better at the latter task.
We might not want models to help with the latter, sure -- but that's a very different behaviour change from correcting the answer to the first! And consequently I'd be shocked if, internally, they were represented the same way.
My issue with this type of thinking is it assumes "transport cost <<< manufacturing cost" -- a decent assumption for a lot of goods throughout a lot of history, but just... not really true for lots of things in a modern supply chain.
The cost of moving the gown between users -- in the form of the user needing to give back the gown to the service, who must then clean it, inspect it, etc. -- may in fact be far higher than the cost of manufacturing a new gown and only needing your supply lines to be "one way".
What you want is to have scripting with capabilities -- preferably on top of WebAssembly (JS is a sin).
The best part is this improves the experience of noscript users -- rather than nice graphical widgets being broken, instead, they can just run scripts without any "network" capability -- which should forbid the scripts not only from accessing the network, but make it so anything they modify becomes "tainted" and is not allowed to show up on a network call (so e.g. if they encode some data in a form, trying to later submit that form somewhere else on the app will give a warning).
Now -- most people don't care and don't want this. And that's a good thing -- capabilities put the power in the hands of the user agent where they belong.
More interestingly-- capabilities can be shimmed! Rather than "you are not allowed to access my GPS", it should be a first-class feature to feed the WASM a GPS stream of your choice.
A lot of our current state of affairs is as much a symptom of regulation as of deregulation (most laws are really regulation) -- and it's unclear whether the world would be better off with more or less overall (the answer is probably "it depends" -- though I myself lean towards less)