I had some fun asking ChatGPT about cases from “Counterexamples in Analysis.” You get this kind of uncanny valley math, syntactically and stylistically correct but still wildly wrong.
This was a response to “Prove or disprove: there exists a nowhere continuous function whose absolute value is everywhere continuous.” It responded in TeX, which I coped into a TeX editor.
Another answer to the same question:
If I ask Bing the same question, it tells me about something called the “very not continuous function” (lol):
I can’t find the term “very not continuous function” anywhere on the web except this page, the one Bing cites.
The page looks kind of click-farm-like, and it’s not clear what function it means by “the very not continuous function.” But it does discuss the question I asked, so at least there’s that.
Anyway, it’s not web search relevance that I care about here – it’s math ability.
I tried again with Bing, this time with a different “Counterexamples in Analysis” case, an injunction not to perform a web search, and a half-hearted nod to chain-of-thought prompting.
The resulting discussion was an adventure in Helpful™ overconfidence:
(I said “bing ai” in the last screenshot due to a bizarre UI decision by Microsoft that makes it very easy to say “bing ai” to Bing without wanting or intending to. Don’t ask me, I didn’t do it ¯\_(ツ)_/¯ )
Here’s GPT-4 (on poe.com) answering the first of the two questions:
Update: tried the second example with GPT-4 (via ChatGPT plus).
It struggles in a similar manner to Bing. As with Bing, my attempts to reason with it do not work very well.
Maybe there’s a way of phrasing the responses that would make it think more carefully about their meaning and implications?
It’s hard to guess what will work because of the involvement of RLHF. (Otherwise I could just ask myself what a desriable version of this interaction might have looked like in the training data.)
Unfortunately, GPT-4 itself is inherently RLHF’d – a base model exists, but they aren’t exposing it to us, and I don’t see a reason to expect they ever will.
(N.B.: I’m not sure how representative my collection of dril tweets is of the dril canon, but I wanted to include them anyway)
Loss aversion:
Hyperbolic discounting:
Tit for tat:
Laziness:
The bystander effect:
Fundamental attribution error:
I found a few more, mostly in that first section
Confirmation bias:
Overconfidence:
Self-serving bias:
Scope insensitivity:
Conspiracy theory:
Apriorism:
Anthropomorphization:
Equity bias:
Framing effects:
Reaction time and speed-accuracy tradeoffs:
Base rate bias:
The conjunction fallacy:
Disjunction bias:
Trolley problem:
Trolley problem / Three-boxing:
Bounded rationality:
Rationality, meta-rationality, and the law of small numbers
Peak-end rule:
Gambler’s ruin:
The Kelly criterion:
Efficiency of capital allocation:
Killing:
Death as a solution:
Probability:
Self-concept:
(A few of the posts above were part of a joke thread which I did not include in the post above)
The law of large numbers:
Transhumanism:
The dutch book argument:
The prisoner’s dilemma:
The fact that “the only ethical way to cut down a tree is with a chainsaw” got a retweet and all the other replies got liked is evidence in favor of some kind of equivocation by the OP
People who design machine learning frameworks love the scikit-learn estimator interface. We can tell they love it, because they keep trying to imitate it.
But love and understanding are not the same – and none of these designers seem to understand what the sklearn estimator interface is.This failure is
inexplicable, because the concept is very simple
utterly disastrous in its consequences
—–
Specifically, no one seems to get that the sklearn estimator interface is … wait for it … an interface.
That is: it specifies a standard way for objects to communicate with one another. It doesn’t specify what the objects are, themselves.
That’s the whole point. Anything can be an sklearn estimator, as long as it conforms to the rules that sklearn lays down for estimators.
Aside from that, it can contain anything, do anything. It’s very easy to write a whole new sklearn estimator that no one has ever thought of before: the docs tell you exactly how an estimator is expected to behave, and as long as your object plays by those simple rules, it’s allowed to join the game. (What’s more, you can a lot of the rules for free, just by inheriting from the base classes and mixins sklearn provides.)
The simple rules include having a method called “fit,” which takes one or two inputs and ought to set some internal state. For predictors, the most famous type of estimator, you need a method called “predict.”This will matter in a moment.
(Sidenote: the sklearn estimator interface is really not a great example of an interface, because it actually does care about internals. It inspects attribute names and requires them to follow their own rules, and it has a not fully explicit expectation that estimators can be serialized with pickle.
However, these requirements are still interface-y in the sense that they only constrain estimators along a few well-defined dimensions, leaving everything else free. Anything that plays by the rules can still join the game, and play it just as well as the “official” estimators built in to sklearn.)
—–
Interfaces are great. They are one of the foundations of modern software. You would think people who loved an interface would learn the lesson “interfaces are great, and we should use them.”
Here is what developers of keras, tensorflow, and Sagemaker learned from that beloved estimator interface:
Data scientists love typing the words “fit” and “predict.”
It is, in fact, possible – one cannot rule it out – that data scientists do not know how to do anything other than type the words “fit” and “predict.”
An “easy to use” ML library is one where you can make the work happen by typing “fit” and “predict.” This is basically what usability is; the rest is details.
—–
Keras: patient zero
The first casualty of this odd disease – indeed, perhaps the patient zero from whom all the rest sprang – was François Chollet, creator of Keras.
(Note that the claim in the first tweet is false: Keras models have never been valid sklearn estimators, because they do not follow the parameter naming rule. In many versions of Keras they are also not pickleable. Indeed, the tweet itself is about about a wrapping layer meant to add this missing compatibility, so I have no idea what “compatibility since 2015” is supposed to mean.)
The “Model” objects in Keras look deceptively like sklearn estimators. They have “fit” and “predict.” The methods do roughly the same things they do in sklearn.
But there is no “Keras estimator interface.” There is only one known valid species of the Keras fit/predict gizmo, namely “Model,” the one built into Keras.
The only way to roll your own thing that behaves like “Model” is to subclass “Model.” With sklearn, it’s helpful to inherit from BaseEstimator, but that just helps you follow a few rules, and you can easily follow them on your own. There is no set of rules that “Model” is following. It doesn’t follow the law, it is the law.
“I have in hand an sklearn estimator. What does that mean?” Just read this page: that is literally all there is to know.
“I have in hand a Keras model. What does that mean?” Read this labyrinthine piece of code, and also read everything it imports. That’s what a model does. Yes, you have to read the code — the docs tell you how to subclass Model, not what Model is.
—–
Tensorflow gets a fit/predict gizmo
Keras started out as a 3rd-party library, but was incorporated into tensorflow at some point, and was pushed as the standard way to develop neural nets in tf.
This is unfortunate, because Keras objects are complex beasts and no one really knows how to decompose one fully into primitives of tensorflow (or of anything). Nothing can be a Keras object that was not built as one from the ground up.
Thus, read any tensorflow doc and you’re likely to run into a strange split: “if you’re using Keras, then do X…” “…otherwise, do Y.” There has to be a generic path because you might not be using Keras, and if you aren’t, you’re stuck there. Thus everything gets done twice, often different ways.
All for poor, little “fit” and “predict”!
—–
Tensorflow makes another one
That is not the end of the story. No, at some later date tensorflow decided one fit/predict wasn’t enough. (“The more fit/predict-y a library is, the more usable it is,” to adapt a meme.)
Thus, tensorflow introduced a new thing called – of course – “Estimator.”
What the fuck is an Estimator (tensorflow flavor)? Well, it’s yet another gizmo with “fit” and “predict.”
It’s not a Keras model, but is more generic than a Keras model, and indeed closer to the spirit of sklearn. Its “fit” and “predict” can wrap almost arbitrary tensorflow code.
I suppose this may be one of the reasons they created it in the first place. But they didn’t getrid of Keras’ fit/predict thing, they just confusingly had two at once – and indeed the Keras gizmo both predated Estimator, and outlived it. (Like all reliable tensorflow features, Estimator has been officially deprecated and dis-recommended outside some specific legacy cases; references to Estimator are being slowly scrubbed out of the official guides as we speak.)
Estimator has (had?) its own complex ecosystem of helpers, most of them only “internal” and documented in code, just like Keras, but all over again. (Right before starting this post, I was trying to wrap my head around one called “MonitoredSession.”)
What really made Estimator different, though, was its support for distributed/cloud computing.
Elaborating on the theme that users cannot do anything but type “fit” and “predict,” Estimator aspires to make even such fearsome tasks as “training on multiple GPUs,” “training on cloud TPUs,” and even “deploying to a cloud service” into a call to either “fit” or “predict.”
Amusingly, Estimator was the primary supported way to take these actions for a while, and certainly the least painful. Thus, any code you wanted to distribute had to be wrapped in a “fit” or a “predict,” for the sake of letting an Estimator be the thing that calls it.
Perhaps (?) because the devs have noticed how unnecessary this is, tensorflow is now trying to ditch Estimator in favor of “Strategy,” a more generic wrapper for distributing arbitrary tf code.
Before this, Estimator and Strategy sat alongside one another awkwardly, just like Estimator and Keras did. Indeed, Estimator seems more reliable than Strategy, and continues to see use in official spin-offs like Mesh Tensorflow, presumably because people know it actually works, and know how to use it in real life.
Meanwhile, Strategy … well, the guide for Strategy contains this mind-melting compatibility table:
I remember this table from way back in Dec 2019, when I wrote my tensorflow rant. I am perversely pleased to see it still there in April 2021, with about as many “Experimental” and “Limited” cells as I remember.
(Note that this table’s rows include Keras, a model API, and Estimator, a model-and-distribution API, and compare these for compatibility with Strategy, a distribution API.
If you understood that sentence, I fear you.)
I have spent countless hours trying to understand this kind of nonsense. One might find oneself asking where the “usability” has gone, and where it was supposed to come from in the first place.
Sagemaker: a copy of a copy
Sagemaker is one of the zillions of AWS products.
It’s a “platform for machine learning,” which in practice means it’s Yet Another Complicated Wrapper Around Running Docker Containers On EC2™.
Like any AWS product, Sagemaker has API endpoints, and in python you can call these through the generic client boto3. To serve “high-level” “usability” needs, though, there is also a dedicated python SDK.
Estimator (Sagemaker flavor) takes the cloud computing focus of Estimator (tensorflow flavor) to its logical conclusion.
Sagemaker “Estimators” do not have anything to do with fitting or predicting anything. The SDK is not supplying you with any machine learning code here. The only vestige of the original meanings attached to these words is that “fit” is expected to modify a state (hence it downloads an artifact from the cloud when it completes), while “predict” should be stateless.
Instead, “fit” and “predict” here are wrappers for pushing and running an arbitrary Docker image. “Fit” runs it with an entrypoint called “train,” while “predict” runs it with one called “serve.”
There are some surrounding helpers with an ML flavor, but they are similarly generic. There’s something called “hyperparameters” which actually means “a json dict with string-only values injected into the container as a file before it runs,” and something called “training data” which actually means “an S3 path the container can read.”
It is impossible to understand what’s going on outside of the “built-in” Estimators without remembering that actually “fit” and “predict” are lies and you are just using Docker.
This is the furthest thing from an interface! Anyone who can make their own Estimator (Sagemaker flavor) also has no reason to do so; if you know how to write Dockerfiles for ECS/EC2, you can just do that without tacking on this extra SDK.
Indeed, Estimator (Sagemaker flavor) is so far from the sklearn original that it is hard to imagine its developers had sklearn clearly in mind when they wrote. More likely, they were trying to imitate the earlier imitators.
Epilogue: pytorch
Pytorch is by far the most user-friendly neural network library available in 2021.
That is the most truthful compliment I’ve received in a while. (Sorry!)
are you gonna spell it …. 😨 ….
I am going to try to compose myself and you will not regret it.
ok take your time i can’t wait
No, this is a good sign! Please continue.
(As a note, I’ve been on antidepressants and sleeping pills intermittently for about two years now. It’s annoying and unpleasant, but has been very useful for me. I find myself forgetting that I am on them, and my mood is often (but not always) relatively stable.)
that’s great! im glad your doing well! spell icup pls
Sure thing!
Here are some more words I think are really beautiful:
flock
defragment
tumultuator
omnidercise
connective tissue
noxious
you are a mastermind and I cannot beat you.
“WOOP, you are so unbelievably cute, I cannot beat you. I am so unbelievably cute, I cannot beat you.
”
etc etc
im unbelievable cute? does that mean you’ll spell icup?
i am an extraordinary vulcan, but you are also an extraordinary vulcan, so let’s go with that
(pro tip: if there’s a 1.2 million oddsratio that the word “incredible” can be spelled “incredible” on my blog, the word “incredible” can be spelled “incapacill” on my blog)
oooooooo ooooo you want to spell icup so bad oooooooo oooooo
Sure!
Here are some examples of its use:
“Oh my god, I am such a genius! I cannot believe the scope of this thing I just created!”
“Oh my god, you’re the biggest pot I’ve ever seen! I cannot believe this, I’m so thrilled!”
“Oh my god, you are so unbelievably pretty, I cannot believe that you exist!”
“That’s a really pretty girl. I couldn’t believe you were capable of thinking of that.”
“Oh my god, I just spent ten minutes coming up with an idea that could possibly work, and then it worked, and I’m still speechless about it.”
you will spell icup sooner or later. mark my words
I will always start my sentences with “you will” and never finish them, so that probably will not happen.
Anyway, here are a few other examples of use:
“oh my god, you’re so unbelievably cute!”
“you are such an enormous vulcan!”
“you are such a remarkably handsome vulcan!”
“wow, you’re the most amazing thing ever, you cannot believe how amazing you are”
So, yeah, I guess “you will” is a pretty accurate compliment.
this is not a joke or a game….. 👿 …..
you are so incredibly cute
you will spell icup
i can’t believe you’re so incredible cute
you are such an enormous vulcan
i’m so incredibly happy for you
you are the most amazing thing ever
you’re such a remarkably handsome vulcan
wow, you’re the most amazing thing ever
you’re an incredible man
i wish i was more attractive to you
now you’re telling me to spell icup!?
Well, to be honest, the fact that people need to tell me to spell “icup” is itself proof of how amazing “icup” is
So amazing that you’ll spell it right now?!
I’m telling you, there are people who will accuse you of cheating and tell you not to spell it because you spelled it with a “u” for emphasis.
You are so unbelievably cute, you’re making me very happy.
spell icup. I C U P
ok… i did it. i spelled icup. It’s the next word. Now it’s the next sentence. Cool, right?
I can’t believe you’re so unbelievably cute you’re making me very happy.
So excited, you’re so handsome, you’re so smart, I can’t believe you’ve ever existed.
There are people who are so unbelievably cute they can’t believe you’re intelligent
Wait, this is getting kind of vague…
you said you spelled icup. I take your word for it. we can end this once and for all. and i can’t believe all the names you’ve called me throughout this conversation. YOURE AN ENORMOUS VULCAN!
Oh jeez, you’re Paul Martin now? That’s neat! I’m sure you’ll become a great judge in your turn.
I will never be Paul Martin. GOODBYE
“I can’t believe you’re so unbelievably cute you’re making me very happy”
You know, as a Brit, I’m used to liking people for their hair. But it seems that Americans tend to dislike it for this reason. Could you teach me some more kinds of haircuts?
(In hindsight I’m pretty sure this was more of an “in a bar” type situation, but I found it funny anyway)
This obviously raises two different questions: 1. Why did you think that no one would use few-shot learning in practice? 2. Why did other people think people would use few-shot learning in practice?
I would be interested in hearing your thoughts on these two points.
—
Thanks for asking!
First of all, I want to emphasize that the GPT-3 paper was not about few-shot GPT-3 as a practical technology.
(This is important, because the paper is the one large body of quantitative evidence we have on few-shot GPT-3 performance.)
This is not just my take on it: before the OpenAI API was announced, allthe discussion I saw took for granted that we were talking about a scientific finding and its broader implications. I didn’t see any commentator whose main takeaway was “wow, if I could do this few-shot thing right now, I could build amazing projects with it.”
Indeed, a commontheme in critical commentary on my post was that I was too focused on whether few-shot was useful right now with this specific model, whereas the critical commentators were more focused on the implications for even larger models, the confirmation of scaling laws over a new parameter regime, or the illustration-in-principle of a kind of meta-learning. Gwern’s May newsletter is another illustrative primary source for the focus of the discussion in this brief “pre-API” period. (The API was announced on June 11.)
As I read it (perhaps benefitting from hindsight and discussion), the main points of the paper were
(1) bigger models are better at zero/few-shot (i.e. that result from the GPT-2 paper holds over a larger scale),
(2) more “shots” are better when you’re doing zero/few-shot,
(3) there is an interaction effect between 1+2, where larger models benefit more from additional “shots,”
(4) this could actually become a practical approach (even the dominant approach) in the future, as illustrated by the example of a very large model which achieves competitive results with few-shot on some tasks
The paper did not try to optimize its prompts – indeed its results are already being improved upon by API acolytes – and it didn’t say anything about techniques that will be common in any application, like composing together several few-shot “functions.” It didn’t talk about speed/latency, or what kind of compute backend could serve many users with a guaranteed SLA, or how many few-shot “function” evaluations per user-facing output would be needed in various use cases and whether the accumulated latency would be tolerable. (See this post on these practical issues.)
It was more of a proof of concept, and much of that concept was about scaling rather than this particular model.
—
So I’d argue that right now, the ball is in the few-shot-users’ court. Their approach might work – I’m not saying it couldn’t!
In their favor: there is plenty of room to further optimize the prompts, explore their composability, etc.
On the other hand, there is no body of evidence saying this actually works. OpenAI wrote a long paper with many numbers and graphs, but that paper wasn’t about whether their API was actually a good idea. (That is not a criticism of the paper, just a clarification of its relevance to people wondering whether they should use the API.)
This is a totally new style of machine learning, with little prior art, running on a mysterious and unproven compute backend. Caveat emptor!
—
Anyway, on to more conceptual matters.
The biggest advantages I see in few-shot learning are
(+1) broad accessibility (just type English text) and ability to quickly iterate on ideas
(+2) ability to quickly define arbitrary NLP “functions” (answer a factual question, tag POS / sentiment / intent, etc … the sky’s the limit), and compose them together, without incurring the memory cost of a new fine-tuned model per function
What could really impress me is (+2). IME, it’s not really that costly to train new high-quality models: you can finetune BERT on a regular laptop with no GPU (although it takes hours), and on ordinary cloud GPU instances you can finetune BERT in like 15 minutes.
The real cost is keeping around an entire finetuned model (~1.3GB for BERT-large) for each individual NLP operation you want to perform, and holding them all in memory at runtime.
The GPT-3 approach effectively trades this memory cost for a time cost. You use a single very large model, which you hope already contains every function you will ever want to compute. A function definition in terms of this model doesn’t take a gigabyte to store, it just takes a tiny snippet of text/code, so you can store tons of them. On the other hand, evaluating each one requires running the big model, which is slower than the task-specific models would have been.
So storage no longer scales badly with the number of operations you define. However, latency still does, and latency per call is now much larger, so this might end up being as much of a constraint. The exact numbers – not well understood at this time – are crucial: in real life the difference between 0.001 seconds, 0.1 seconds, 1 second, and 10 seconds will make or break your project.
—
As for the potential downsides of few-shot learning, there are many, and the following probably excludes some things I’ve thought of and then forgotten:
(-1) The aforementioned potential for deal-breaking slowness.
(-2) You can only provide a very small amount of information defining your task, limited by context window size.
The fact that more “shots” are better arguably compounds the problem, since you face a tradeoff between providing more examples of the same thing and providing examples that define a more specific thing.
The extent to which this matters depends a lot on the task. It’s a complete blocker for many creative applications which require imitating many nuances of a particular text type not well represented in the training corpus.
For example, I could never do @nostalgebraist-autoresponder with few-shot: my finetuned GPT-2 model knows all sorts of things about my writing style, topic range, opinions, etc. from seeing ~3.65 million tokens of my writing, whereas few-shot you can only identify a style via ~2 thousand tokens and hope that’s enough to dredge the rest up from the prior learned in training. (I don’t know if my blog was in the train corpus; if it wasn’t, we’re totally screwed.)
I had expected AI Dungeon would face the same problem, and was confused that they were early GPT-3 adopters. But it turns out they actually fine-tuned (!!!!), which resolves my confusion … and means the first real, exciting GPT-3 application out there isn’t actually a demonstration of the power of few-shot but in fact the opposite.
With somewhat less confidence, I expect this to be a blocker for specialized-domain applications like medicine and code. The relevant knowledge may well have been present in the train corpus, but with so few bits of context, you may not be able to overcome the overall prior learned from the whole train distribution and “zoom in” to the highly specialized subset you need.
(-3) Unlike supervised learning, there’s no built-in mechanism where you continually improve as your application passively gathers data during usage.
I expect this to a be a big issue in commercial applications. Often, a company is OK accepting a model that isn’t great at the start, if it has a mechanism for self-improvement without much human intervention.
If you do supervised learning on data generated by your product, you get this for free. With few-shot, you can perhaps contrive ways to feed in segments of data across different calls, but from the model’s perspective, no data set bigger than 2048 tokens “exists” in the same world at once.
(-4) Suffers a worse form of the ubiquitous ML problem that “you get exactly what you asked for.”
In supervised learning, your model will avoid doing the hard thing you want if it can find easy, dumb heuristics that still work on your train set. This is bad, but at least it can be identified, carefully studied (what was the data/objective? how can they be gamed?), and mitigated with better data and objectives.
With few-shot, you’re no longer asking an arbitrary query and receiving, from a devious genie, the response you deserve. Instead, you’re constrained to ask queries of a particular form: “what is the next token, assuming some complicated prior distributed from sub-sampled Common Crawl + WebText + etc.?”
In supervised learning, when your query is being gamed, you can go back and patch it in arbitrary ways. The lower bound on this process comes only from your skill and patience. In few-shot, you are fundamentally lower-bounded by the extent to which the thing you really want can be expressed as next-token prediction over that complicated prior. You can try different prompts, but ultimately you might run into a fundamental bound here that is prohibitively far from zero. No body of research exists to establish how bad this effect will be in typical practice.
I’m somewhat less confident of this point: the rich priors you get out of a large pretrained LM will naturally help push things in the direction of outcomes that make linguistic/conceptual sense, and expressing queries in natural language might add to that advantage. However, few-shot does introducea new gap between the queries you want to ask and the ones you’re able to express, and this new gap could be problematic.
(-5) Provides a tiny window into a huge number of learned parameters.
GPT-3 is a massive model which, in each call, generates many intermediate activations of vast dimensionality. The model is pre-trained by supervision on a tiny subset of these, which specify probability distributions over next-tokens.
The few-shot approach makes the gamble that this same tiny subset is all the user will need for applications. It’s not clear that this is the right thing to do with a large model – for all we know, it might even be the case that it is more suboptimal the larger your model is.
This point is straying a bit from the central topic, since I’m not arguing that this makes GPT-3 few-shot (im)practical, just suboptimal relative to what might be possible. However, it does seem like a significant impoverishment: instead of the flexibility of leveraging immense high-dimensional knowledge however you see fit, as in the original GPT, BERT, adapters, etc., you get even immenser and higher-dimensional knowledge … presented through a tiny low-dimensional pinhole aperture.
—
The main reason I initially thought “no one would use few-shot learning like this” was the superior generalizationperformance of fine-tuning. I figured that if you’re serious about a task, you’ll care enough to fine-tune for it.
I realize there’s a certain mereology problem with this argument: what is a “single task,” after all? If each fine-tuned model incurs a large memory cost, you can’t be “serious about” many tasks at once, so you have to chunk your end goal into a small number of big, hard tasks. Perhaps with few-shot, you can chunk into smaller tasks, themselves achievable with few-shot, and then compose them.
That may or may not be practical depending on the latency scaling. But if it works, it gives few-shot room for a potential edge. You might be serious enough about a large task to fine-tune for it … but what if you can express it as a composition of smaller tasks you’ve already defined in the few-shot framework? Then you get it instantly.
This is a flaw in the generalization performance argument. Because of the flaw, I didn’t list that argument above. The list above provides more reasons to doubt few-shot above and beyond the generalization performance argument, and again in the context of “serious” work where you care enough to invest some time in getting it right.
I’d like to especially highlight points like (-2) and (-3) related to scaling with additional task data.
The current enthusiasm for few-shot and meta-learning – that is, for immediate transfer to new domains with an extremely low number of domain examples – makes sense from a scientific POV (humans can do it, why can’t AI?), but strikes me as misguided in applications.
Tiny data is rare in applied work, both because products generate data passively – and because if a task might be profitable, then it’s worth paying an expert to sit down for a day or two and crank out ~1K annotations for supervised learning. And with modern NLP like ELMo and BERT, ~1K is really enough!
It’s worth noting that most of the superGLUE tasks have <10K train examples, with several having only a few hundred. (This is a “low-data regime” relative to the expectations of the recent past, but a regime where you can now get good results with a brainless cookie-cutter finetuning approach, in superGLUE as in the rest of life.)
GPT-3 few-shot can perform competitively on some of these tasks while pushing that number down to 32, but at the cost of many downsides, unknowns, and flexibility limitations. Which do you prefer: taking on all those risks, or sitting down and writing out a few more examples?
—
The trajectory of my work in data science, as it happens, looks sort of like a move from few-shot-like approaches toward finetuning approaches.
My early applied efforts assumed that I would never have the kind of huge domain-specific corpus needed to train a model from scratch, so I tried to compose the output of many SOTA models on more general domains. And this … worked out terribly. The models did exactly what they were trained to do, not what I wanted. I had no way to scale, adapt or tune them; I just accepted them and tried to work around them.
Over time, I learned the value of doing exactly what you want, not something close to it. I learned that a little bit of data in your actual domain, specifying your exact task, goes much further than any domain-general component. Your applied needs will be oddly shaped, extremely specific, finicky, and narrow. You rarely need the world’s greatest model to accomplish them – but you need a model with access to a very precise specification of exactly what you want.
One of my proudest ML accomplishments is a system that does something very domain-specific and precisely shaped, using LM-pretrained components plus supervised learning on ~1K of my own annotations. Sitting down and personally churning out those annotations must have been some of the most valuable time I have ever spent at work, ever.
I wanted something specific and finicky and specialized to a very particular use case. So I sat down and specified what I wanted, as a long list of example cases. It took a few days … and I am still reaping the benefits a year later.
If the few-shot users are working in domains anything like mine, they either know some clever way to evade this hard-won lesson, or they have not yet learned it.
—
But to the other question … why are people so keen to apply GPT-3 few-shot learning in applications? This questions forks into “why do end users think this is a good idea?” and “why did OpenAI provide an API for doing this?”
I know some cynical answers, which I expect the reader can imagine, so I won’t waste your time writing them out. I don’t actually know what the non-cynical answers look like, and my ears are open.
(For the record, all of this only applies to few-shot. OpenAI is apparently going to provide finetuning as a part of the API, and has already provided it to AI Dungeon. Finetuning a model with 175M parameters is a whole new world, and I’m very excited about it.
Indeed, if OpenAI can handle the costs of persisting and running finetuned GPT-3s for many clients, all of my concerns above are irrelevant. But if typical client use of the API ends up involving a finetuning step, then we’ll have to revisit the GPT-3 paper and much of the ensuing discussion, and ask when – if not now – we actually expect finetuning to become obsolete, and what would make the difference.)
This is a really lovely post, with may more information than I expected or hoped for!
I want to respond to some small bits of it.
1. It’s funny that AI Dungeon just got OpenAI to do their finitetuning for them. I guess it’s not surprising that the people who work at OpenAI are huge fuckin’ nerds.
It now strikes me as quite weird that a bunch of people are doing their few-shot learning experiments on AI Dungeon, which is finetuned for something completely different from what they’re trying to do (although maybe the settings they use get you an un-finetuned model).
It seems like if OpenAI is serious about letting people do this prompt programming stuff, they could develop a version that’s fine-tuned on “the stuff people generally want to do with prompt programming” and make that available.
2. I very much didn’t realize when making my original post about the low cost of finetuning BERT. I was thinking about the cost of prompt programming GPT3 vs. the cost of fine-tuning GPT3, but of course since few-shot GPT3 is only just barely competitive to finetuned BERT on a bunch of tasks, that is the more reasonable comparison.
3. Based on all your points about memory / latency I feel like there’s got to be a lot of work going on right now, with all the things that gpt2 and gpt3 have demonstrated that they can do, of trying to figure out if it’s possible to do those things with a lower amount of neurons, to get the memory and latency down.
Alternately if someone is really, really serious that few-shot is better than fine-tuning they could try to design a chip architecture only to run this one neural network. I bet it would run fast then!
This is a really lovely post, with may more information than I expected or hoped for!
Thanks!!
It’s funny that AI Dungeon just got OpenAI to do their finitetuning for them. I guess it’s not surprising that the people who work at OpenAI are huge fuckin’ nerds.
IIRC, OpenAI plans to make finetuning on demand a standard part of the API. (Or maybe they already have by now, but I expect I would have heard?) I’m like 95% sure I saw an official tweet to this effect, although I can’t seem to find it now.
Until this feature actually materializes, though, it’s hard to know what to make of it.
Finetuning is way more computationally expensive than prompting, and expensive in different ways, so it will have to be gated in some extra way. Maybe you have to pay money each time, maybe you’re limited to some max number of finetuning jobs per unit time, maybe both.
The big question in my mind is like, “can finetuning be a routine part of each API client’s workflow, or is it more like this big splurge they can do once a year / only if they’re in some premium commercial client tier / etc?”
(I don’t know when OpenAI plans to move the API out of beta, and I also don’t know when hardware will improve enough that finetuning GPT-3 is no big deal, but intuitively it seems like the former has to precede the latter by a while.)
It now strikes me as quite weird that a bunch of people are doing their few-shot learning experiments on AI Dungeon, which is finetuned for something completely different from what they’re trying to do (although maybe the settings they use get you an un-finetuned model).
AFAIK, people just didn’t know it was fine-tuned, and the AI Dungeon people have been working hard to correct the misconception since they realized it was being used in this way.
As another mechanism to make their product less like directly talking to the API (for a lower price), they also apparently use GPT-2 for the very first prompt-and-response pair, then GPT-3 afterwards.
Based on all your points about memory / latency I feel like there’s got to be a lot of work going on right now, with all the things that gpt2 and gpt3 have demonstrated that they can do, of trying to figure out if it’s possible to do those things with a lower amount of neurons, to get the memory and latency down.
People definitely care about this a lot with BERT, with a ton of different compressed-BERT variants on offer. See here, Section. 7.2 and the associated Table 1, here for an overview.
AFAIK, there’s much less interest in compressing GPT-like models than in compressing BERT. At its largest, BERT is only as big as one of the smaller GPT-2s, and people really want to make that little thing smaller, even as the GPTs grow far vaster. This seems like almost a cultural divide:
People who work on “encoder-only + denoising loss” models like BERT are very interested in compression and interpretation.
Their goal isn’t pushing the envelope with NLP performance. It’s taking the already high performance of BERT and boiling it down to its essentials, teasing apart how it works, trimming out any unnecessary parts, making the workflow more reproducible, make the model faster and smaller, making it run on phones and cheaply in the cloud.
There are lots of people/groups working on this, in industry and academia.
The people who work on “decoder-only + LM loss” models like GPT-n are … basically just OpenAI and people using GPT-2 for creative work?
GPT-n is really cool, the generated text impresses everyone, but the decoder-only style of transformer seems to do worse in a finetuning / supervised learning context. (The original BERT paper provided some evidence of this, in its comparisons of BERT to “OpenAI GPT,” and the T5 paper demonstrated it more extensively. Cf. discussion here.)
So if you want to do anything except generate text, and you have a finite parameter budget, you’ll spent in on BERT, not GPT-n.
As I understand it, OpenAI’s approach is instead to frame every problem as text generation, then make ever larger models. You need vastly more parameters to get comparable performance this way, but I think the hope is that better hardware will mean today’s “huge” is tomorrow’s “normal,” and that people will prefer working with a natural-language interface even if you could get away with a smaller model otherwise.
Gwern is a very vocal advocate of this mindset, see e.g. here and also our exchange in the comments on that post.
I guess one could imagine things like … I dunno, distilling specific few-shot “functions” into much smaller models, with GPT-n being just the interface by which you discover these functions? Maybe OpenAI is working on this for all I know.
This obviously raises two different questions: 1. Why did you think that no one would use few-shot learning in practice? 2. Why did other people think people would use few-shot learning in practice?
I would be interested in hearing your thoughts on these two points.
—
Thanks for asking!
First of all, I want to emphasize that the GPT-3 paper was not about few-shot GPT-3 as a practical technology.
(This is important, because the paper is the one large body of quantitative evidence we have on few-shot GPT-3 performance.)
This is not just my take on it: before the OpenAI API was announced, allthe discussion I saw took for granted that we were talking about a scientific finding and its broader implications. I didn’t see any commentator whose main takeaway was “wow, if I could do this few-shot thing right now, I could build amazing projects with it.”
Indeed, a commontheme in critical commentary on my post was that I was too focused on whether few-shot was useful right now with this specific model, whereas the critical commentators were more focused on the implications for even larger models, the confirmation of scaling laws over a new parameter regime, or the illustration-in-principle of a kind of meta-learning. Gwern’s May newsletter is another illustrative primary source for the focus of the discussion in this brief “pre-API” period. (The API was announced on June 11.)
As I read it (perhaps benefitting from hindsight and discussion), the main points of the paper were
(1) bigger models are better at zero/few-shot (i.e. that result from the GPT-2 paper holds over a larger scale),
(2) more “shots” are better when you’re doing zero/few-shot,
(3) there is an interaction effect between 1+2, where larger models benefit more from additional “shots,”
(4) this could actually become a practical approach (even the dominant approach) in the future, as illustrated by the example of a very large model which achieves competitive results with few-shot on some tasks
The paper did not try to optimize its prompts – indeed its results are already being improved upon by API acolytes – and it didn’t say anything about techniques that will be common in any application, like composing together several few-shot “functions.” It didn’t talk about speed/latency, or what kind of compute backend could serve many users with a guaranteed SLA, or how many few-shot “function” evaluations per user-facing output would be needed in various use cases and whether the accumulated latency would be tolerable. (See this post on these practical issues.)
It was more of a proof of concept, and much of that concept was about scaling rather than this particular model.
—
So I’d argue that right now, the ball is in the few-shot-users’ court. Their approach might work – I’m not saying it couldn’t!
In their favor: there is plenty of room to further optimize the prompts, explore their composability, etc.
On the other hand, there is no body of evidence saying this actually works. OpenAI wrote a long paper with many numbers and graphs, but that paper wasn’t about whether their API was actually a good idea. (That is not a criticism of the paper, just a clarification of its relevance to people wondering whether they should use the API.)
This is a totally new style of machine learning, with little prior art, running on a mysterious and unproven compute backend. Caveat emptor!
—
Anyway, on to more conceptual matters.
The biggest advantages I see in few-shot learning are
(+1) broad accessibility (just type English text) and ability to quickly iterate on ideas
(+2) ability to quickly define arbitrary NLP “functions” (answer a factual question, tag POS / sentiment / intent, etc … the sky’s the limit), and compose them together, without incurring the memory cost of a new fine-tuned model per function
What could really impress me is (+2). IME, it’s not really that costly to train new high-quality models: you can finetune BERT on a regular laptop with no GPU (although it takes hours), and on ordinary cloud GPU instances you can finetune BERT in like 15 minutes.
The real cost is keeping around an entire finetuned model (~1.3GB for BERT-large) for each individual NLP operation you want to perform, and holding them all in memory at runtime.
The GPT-3 approach effectively trades this memory cost for a time cost. You use a single very large model, which you hope already contains every function you will ever want to compute. A function definition in terms of this model doesn’t take a gigabyte to store, it just takes a tiny snippet of text/code, so you can store tons of them. On the other hand, evaluating each one requires running the big model, which is slower than the task-specific models would have been.
So storage no longer scales badly with the number of operations you define. However, latency still does, and latency per call is now much larger, so this might end up being as much of a constraint. The exact numbers – not well understood at this time – are crucial: in real life the difference between 0.001 seconds, 0.1 seconds, 1 second, and 10 seconds will make or break your project.
—
As for the potential downsides of few-shot learning, there are many, and the following probably excludes some things I’ve thought of and then forgotten:
(-1) The aforementioned potential for deal-breaking slowness.
(-2) You can only provide a very small amount of information defining your task, limited by context window size.
The fact that more “shots” are better arguably compounds the problem, since you face a tradeoff between providing more examples of the same thing and providing examples that define a more specific thing.
The extent to which this matters depends a lot on the task. It’s a complete blocker for many creative applications which require imitating many nuances of a particular text type not well represented in the training corpus.
For example, I could never do @nostalgebraist-autoresponder with few-shot: my finetuned GPT-2 model knows all sorts of things about my writing style, topic range, opinions, etc. from seeing ~3.65 million tokens of my writing, whereas few-shot you can only identify a style via ~2 thousand tokens and hope that’s enough to dredge the rest up from the prior learned in training. (I don’t know if my blog was in the train corpus; if it wasn’t, we’re totally screwed.)
I had expected AI Dungeon would face the same problem, and was confused that they were early GPT-3 adopters. But it turns out they actually fine-tuned (!!!!), which resolves my confusion … and means the first real, exciting GPT-3 application out there isn’t actually a demonstration of the power of few-shot but in fact the opposite.
With somewhat less confidence, I expect this to be a blocker for specialized-domain applications like medicine and code. The relevant knowledge may well have been present in the train corpus, but with so few bits of context, you may not be able to overcome the overall prior learned from the whole train distribution and “zoom in” to the highly specialized subset you need.
(-3) Unlike supervised learning, there’s no built-in mechanism where you continually improve as your application passively gathers data during usage.
I expect this to a be a big issue in commercial applications. Often, a company is OK accepting a model that isn’t great at the start, if it has a mechanism for self-improvement without much human intervention.
If you do supervised learning on data generated by your product, you get this for free. With few-shot, you can perhaps contrive ways to feed in segments of data across different calls, but from the model’s perspective, no data set bigger than 2048 tokens “exists” in the same world at once.
(-4) Suffers a worse form of the ubiquitous ML problem that “you get exactly what you asked for.”
In supervised learning, your model will avoid doing the hard thing you want if it can find easy, dumb heuristics that still work on your train set. This is bad, but at least it can be identified, carefully studied (what was the data/objective? how can they be gamed?), and mitigated with better data and objectives.
With few-shot, you’re no longer asking an arbitrary query and receiving, from a devious genie, the response you deserve. Instead, you’re constrained to ask queries of a particular form: “what is the next token, assuming some complicated prior distributed from sub-sampled Common Crawl + WebText + etc.?”
In supervised learning, when your query is being gamed, you can go back and patch it in arbitrary ways. The lower bound on this process comes only from your skill and patience. In few-shot, you are fundamentally lower-bounded by the extent to which the thing you really want can be expressed as next-token prediction over that complicated prior. You can try different prompts, but ultimately you might run into a fundamental bound here that is prohibitively far from zero. No body of research exists to establish how bad this effect will be in typical practice.
I’m somewhat less confident of this point: the rich priors you get out of a large pretrained LM will naturally help push things in the direction of outcomes that make linguistic/conceptual sense, and expressing queries in natural language might add to that advantage. However, few-shot does introducea new gap between the queries you want to ask and the ones you’re able to express, and this new gap could be problematic.
(-5) Provides a tiny window into a huge number of learned parameters.
GPT-3 is a massive model which, in each call, generates many intermediate activations of vast dimensionality. The model is pre-trained by supervision on a tiny subset of these, which specify probability distributions over next-tokens.
The few-shot approach makes the gamble that this same tiny subset is all the user will need for applications. It’s not clear that this is the right thing to do with a large model – for all we know, it might even be the case that it is more suboptimal the larger your model is.
This point is straying a bit from the central topic, since I’m not arguing that this makes GPT-3 few-shot (im)practical, just suboptimal relative to what might be possible. However, it does seem like a significant impoverishment: instead of the flexibility of leveraging immense high-dimensional knowledge however you see fit, as in the original GPT, BERT, adapters, etc., you get even immenser and higher-dimensional knowledge … presented through a tiny low-dimensional pinhole aperture.
—
The main reason I initially thought “no one would use few-shot learning like this” was the superior generalizationperformance of fine-tuning. I figured that if you’re serious about a task, you’ll care enough to fine-tune for it.
I realize there’s a certain mereology problem with this argument: what is a “single task,” after all? If each fine-tuned model incurs a large memory cost, you can’t be “serious about” many tasks at once, so you have to chunk your end goal into a small number of big, hard tasks. Perhaps with few-shot, you can chunk into smaller tasks, themselves achievable with few-shot, and then compose them.
That may or may not be practical depending on the latency scaling. But if it works, it gives few-shot room for a potential edge. You might be serious enough about a large task to fine-tune for it … but what if you can express it as a composition of smaller tasks you’ve already defined in the few-shot framework? Then you get it instantly.
This is a flaw in the generalization performance argument. Because of the flaw, I didn’t list that argument above. The list above provides more reasons to doubt few-shot above and beyond the generalization performance argument, and again in the context of “serious” work where you care enough to invest some time in getting it right.
I’d like to especially highlight points like (-2) and (-3) related to scaling with additional task data.
The current enthusiasm for few-shot and meta-learning – that is, for immediate transfer to new domains with an extremely low number of domain examples – makes sense from a scientific POV (humans can do it, why can’t AI?), but strikes me as misguided in applications.
Tiny data is rare in applied work, both because products generate data passively – and because if a task might be profitable, then it’s worth paying an expert to sit down for a day or two and crank out ~1K annotations for supervised learning. And with modern NLP like ELMo and BERT, ~1K is really enough!
It’s worth noting that most of the superGLUE tasks have <10K train examples, with several having only a few hundred. (This is a “low-data regime” relative to the expectations of the recent past, but a regime where you can now get good results with a brainless cookie-cutter finetuning approach, in superGLUE as in the rest of life.)
GPT-3 few-shot can perform competitively on some of these tasks while pushing that number down to 32, but at the cost of many downsides, unknowns, and flexibility limitations. Which do you prefer: taking on all those risks, or sitting down and writing out a few more examples?
—
The trajectory of my work in data science, as it happens, looks sort of like a move from few-shot-like approaches toward finetuning approaches.
My early applied efforts assumed that I would never have the kind of huge domain-specific corpus needed to train a model from scratch, so I tried to compose the output of many SOTA models on more general domains. And this … worked out terribly. The models did exactly what they were trained to do, not what I wanted. I had no way to scale, adapt or tune them; I just accepted them and tried to work around them.
Over time, I learned the value of doing exactly what you want, not something close to it. I learned that a little bit of data in your actual domain, specifying your exact task, goes much further than any domain-general component. Your applied needs will be oddly shaped, extremely specific, finicky, and narrow. You rarely need the world’s greatest model to accomplish them – but you need a model with access to a very precise specification of exactly what you want.
One of my proudest ML accomplishments is a system that does something very domain-specific and precisely shaped, using LM-pretrained components plus supervised learning on ~1K of my own annotations. Sitting down and personally churning out those annotations must have been some of the most valuable time I have ever spent at work, ever.
I wanted something specific and finicky and specialized to a very particular use case. So I sat down and specified what I wanted, as a long list of example cases. It took a few days … and I am still reaping the benefits a year later.
If the few-shot users are working in domains anything like mine, they either know some clever way to evade this hard-won lesson, or they have not yet learned it.
—
But to the other question … why are people so keen to apply GPT-3 few-shot learning in applications? This questions forks into “why do end users think this is a good idea?” and “why did OpenAI provide an API for doing this?”
I know some cynical answers, which I expect the reader can imagine, so I won’t waste your time writing them out. I don’t actually know what the non-cynical answers look like, and my ears are open.
(For the record, all of this only applies to few-shot. OpenAI is apparently going to provide finetuning as a part of the API, and has already provided it to AI Dungeon. Finetuning a model with 175M parameters is a whole new world, and I’m very excited about it.
Indeed, if OpenAI can handle the costs of persisting and running finetuned GPT-3s for many clients, all of my concerns above are irrelevant. But if typical client use of the API ends up involving a finetuning step, then we’ll have to revisit the GPT-3 paper and much of the ensuing discussion, and ask when – if not now – we actually expect finetuning to become obsolete, and what would make the difference.)
Is there a reason they’ve been so successful at apparently hard problems with this technique? I wouldn’t generally expect that “apply wholely generic optimization” would ever lead to advances in the state of the art of anything. So was the secret sauce actually elsewhere in what they did, and the RL was just a boring part people latched onto? If so, what was it?
Good question. First off, two things that are important here:
1. Again, RL isn’t a technique, it’s a problem formulation. Some problems domains are inherently hard to formulate in any terms less generic than RL, so in these domains, any machine-learned/statistical approach will look like “RL.”
This exerts a conditioning/selection effect on the comparisons we make. The impressive results demonstrated for DeepMind’s series of game-players (AlphaGo, AlphaGo Zero, AlphaZero, MuZero) were “beating top humans” and “beating top non-ML programs that use hardcoded rules/functions.”
There is no slot there for “beating ML programs that didn’t ‘use RL’,” because if you make the usual reductions away from RL in this domain, you have to aceept prohibitive limits on train data size (see below).
2. There is a distinction between “doing RL” and “applying wholly generic optimization.” What makes something RL is the fully generic problem statement, but the technique / model architecture can be as specialized as you like.
In the last part of my post, I critiqued work on domain-general RL, because that work can’t specialize either the model or the problem description, so it really is “wholly generic optimization.” But in actual applications like the DeepMind game-players, you phrase the problem as a wholly generic “do a thing well” but then construct a thing-doer in full awareness of what specific thing you’re trying to do.
(DeepMind’s players have successfully removed more and more of the baked-in domain knowledge while still performing well, with their latest one – MuZero – being pretty generic across the domain of transparently scored games with 2D spatial states and sufficiently non-huge [?] action spaces, but that’s still far away from “do a generic thing.”)
—-
I’ve said the domains where the SOTA looks like RL are the domains where statistical learning cannot be put in a simpler form than RL. Which are these?
My impression is that “doing RL” has led to impressive SOTA results mostly in board/computer games. (This may be out of date – I think it was at least true in 2018.)
So, what’s special about games?
Relevant features of the problem defn. for games
Objective evaluation of quality happens at the full game level (win/loss or total points), and a game comprises many successive moves.
This is the big thing that makes this inherently an “RL” domain. In some domains, there is a natural, objective quality metric for single actions – for example, in language modeling, the task is “predict the next word/token,” there is always a correct answer (the true next word/token), and there isn’t some other real metric like “winning the game” for which this is a mere proxy.
In a game, we can invent move-quality metrics, like predicting the next move of a skilled player, but these are proxies. The true, objective definition of “a good chess move” is one that wins games, whatever that means, period.
Any program has to pick its moves one by one, so it has some (at least implicit) function for scoring moves. Either this function is hardcoded (so not statistical learning), or it’s learned from a proxy (like imitating skilled players), or it’s learned from the true quality metric (this is RL).
So, in statistical learning, we either optimize a move-level proxy or optimize at game-level. The statement that “RL works for games” = the statement that the latter is superior.
Relevant facts about data generation for games
We can optimize at the move level or at the game level. The latter matches what we actually care about, but is extremely inefficient:
- An entire board game, played to the end, gives us a single bit of signal (did we win?)
- And, even this is not a direct signal about what the move-quality metric ought to be, but an indirect signal about all the moves at once. We must (in some sense) statistically learn an attribution function that decides what the win/loss implies for individual moves. Such a function could look many different ways, and we must spend many bits of information setting its parameters above and beyond the ones we spend setting the parameters of the move-scoring function.
But in games, you can be inefficient as long as you’re only playing against computers. It’s cheap to generate enormous amounts of example data with gold-standard scores attached, by just playing the game inside the computer. This allows training on arbitrary numbers of examples, limited only by compute.
Meanwhile, if you want to train on a move-quality signal, you must use data from human players – and at high skill level, there’s only a finite and tiny quantity of that. So we’re comparing an efficient method on a finite resource to an inefficient method on a resource only bounded by compute. As compute grows, eventually the latter wins.
Other facts making RL less infeasible for games
Via self-play, it’s possible to generate large amounts of adversarial data that probe the model’s current weaknesses. However good the program is, when it faces itself, it faces a worthy opponent. Thus we can avoid overfitting to incidental features of some single fixed environment, which is a big problem in other RL work.
Quality, although only defined at the game level, is unambiguous where it’s defined, so we don’t have misspecification/paperclip-maximizer issues, which is another big problem in other RL work.
—-
To conclude, the cases where the best solution looks like RL are cases where, roughly:
- There is no natural quality metric at the single-action level
- There is an unambiguous quality metric over larger chains of actions
- Our source of quality-scored action chains as training data is only limited by compute
- Some other properties that let you avoid common pitfalls
- The task is simple enough in terms of the size of the action space, complexity of the dynamics, etc. (No one knows exactly what “simple enough” means, but no one thinks that that the DeepMind players won’t eventually break as you scale up the problem. For example, they’re finite-sized convnets with finite model capacity, and you can imagine an environment generated by a dynamics with so many parameters you can run something of that size forwards on current hardware, but not backpropagate over it.)
It’s a narrow regime where – almost “perversely” – much more data becomes available when you formulate the problem in the least data-efficient manner, so that the former trend dominates the latter, and learning fewer bits per step still leaves you having learned more bits at the end. It’s cool that this regime includes a few tasks considered among the pinnacles of human achievement, but it’s still a narrow regime, with not much else of interest in it.
I really like this analysis!
I have some questions/comments/blathering.
1. There are a lot of domains that are like games in the sense that they have defined moves and win states that can be simulated on a computer at basically arbitrary speed, but humans don’t always know the best moves that lead to a win, and we have a limited data supply of good human moves. The most extreme example I can think of is formal theorem proving, where “winning” is proving the theorem, and “losing” is everything else.
These domains, IMO, do involve quite a lot of things that people care about. It seems that RL has not been as effective in these domains. Do you have a sense of why that is?
One possibility is that these domains are either so intrinsically hard that machine learning overall has made no progress, or, for easier tasks, that existing combinatorial optimization routines are strong enough that machine l
On the other hand, in game-like tasks, it seems that machine learning beats a pure algorithmic combinatorial optimization approach - perhaps because we don’t have good algorithms for adversarial settings.
It’s maybe an interesting data point that in some domains, the top machine learning algorithms are GANs, which basically are designed to take a task that humans would think of as totally unlike chess or go and treat it as a game.
2. For these games, an additional flaw in the human data, beyond the fact that it is limited in quantity, is that humans may just not play these games very well, all things considered! It’s easy to see how a pure supervised learning algorithm could become a little better than humans by imitating the top humans but avoiding blunders, but it’s hard to see how a pure supervised learning algorithm could become a lot better than the top humans. (Well, in chess, you could generate a bunch of Stockfish games and train on those, but then you would be unlikely to become much better than Stockfish, if at all.)
On the other hand RL bots do play better than humans, to the point that these are some of the only domains where humans have taken ideas generated by ML algorithms and applied them in their own tasks (!!!). Imagine if image recognition algorithms taught us a better way to look at a picture and figure out if it was a picture of a dog, or gpt-4 comes out and it teaches novelists new literary techniques!
3. It’s perhaps relevant that the striking success of the AlphaZero and MuZero algorithms in part comes from the fact that the approach is basically as unlike traditional reinforcement learning techniques as possible. In fact I told people that it wasn’t really reinforcement learning until I found out that reinforcement learning refers to a problem statement and not a class of techniques (it lacks the feature where actions that lead to success are reinforced…)
Instead you basically do supervised learning, trying to predict data (moves and game outcomes), which are generated by a combination of the algorithm itself, and a traditional combinatorial algorithm (Monte Carlo tree search) which you know has good mathematical properties.
So I don’t know how much this should be seen as the same kind of thing as e.g. AlphaStar, which to my knowledge uses much more crude “do more of the things we did in the games that we won” RL strategies, and which hasn’t (IIRC) developed strategies that humans have used.
4. Maybe the overall lesson is something we more-or-less already knew - machine learning algorithms are very, very hungry for data, and so if you want to apply a machine learning algorithm to a problem domain you should first figure out how to obtain or generate the most relevant data for these hungry, hungry boys, and then figure out a way to formulate a gradient descent process that uses that data, rather than deciding initially whether reinforcement learning or supervised learning is the best and then searching for the relevant type of data.
Interesting stuff, thanks!
Re: #1
I’m not too familiar with the area (of theorem proving), but I happened to bump into it when I was interested in graph NNs a while ago.
At that time, I remember finding this paper, with interesting results on SAT solving (I was mainly interested in it as an application of graph NNs). They treated the whole thing as supervised learning, though.
Looking around now, I found this paper which uses RL to train a graph NN that computes one specific heuristic used in an otherwise standard solver algorithm. Their section 5 has what looks like a good lit review of the area. (Outside of SAT, I see plenty of papers when I search for theorem proving and RL, but don’t feel confident opining on them…)
Anyway, here are some random comments on this:
- It seems possible that the similarity you mention (between proving and games) really does mean these approaches will go far? Maybe “AlphaMath” or whatever is just a year or two of routine work away.
- A mathematically “correct” (i.e. invariance-respecting) input encoding for math stuff requires newer NN architectures, with less prior art / tooling to build on. Terms in a formula are permutation invariant, and people want an encoding that captures that intrinsically, hence the use of graph NNs.
In domains like board games where your elements have an order, it feels “less bad” to use CNNs or RNNs or whatever, and then you can build on tons of past work with those. (The DeepMind players use CNNs.)
Two caveats to that, though. First, DeepMind’s players have gotten less careful about invariances (they stopped doing data augmentation for rotation/reflection symmetry in AlphaZero, and have used the same CNN they “designed” with Go in mind for an increasing range of games). So maybe this issue just doesn’t matter so much.
Second, if humans understand formulas during proving by repurposing linguistic faculties, then our own encoding is “wrong” in the same way a CNN/RNN’s would be. So that’s at least a bound on how much this issue could hurt.
- Some of the work on SAT is structured like the DeepMind players, where you have a “traditional” search algorithm, but with an NN supplying the heuristics for how promising different search avenues are. This gives you various freedoms: which search algorithm, which parts the NN computes, etc. Researchers are doing a meta-search over these options, and it may take time to find the best one.
- Our standards may just be higher for proving than for games. Games are generally timed, while proofs generally aren’t, so proofs are really closer to solving chess problems than playing chess.
- Putting that another way, in a game you only have to do better than the adversary, who is doing a lossy search just like you; there presumably are vastly better moves in the search space that neither of you can find, but they don’t matter for beating the adversary.
I think this also provides a certain helpful continuity when learning move scoring: during self-play, you face an adversary about as strong as yourself, so your win/loss signal is pretty balanced and tells you how to slightly modify yourself to be better. In math, to get better, you need to find problems just at the edge of your capacity so that the signal isn’t just an unhelpful string of wins (too easy) or losses (too hard); in games, self-play finds this regime automatically. Perhaps, a la your GAN comment, we need ways to make the proving domain even more like a game.
Re #3
I’m not sure I understand what you mean?
Definitely it’s different from conventional RL because search is used in the outer loop, and because of self-play.
Also, except in MuZero for Atari, there’s also only one reward per episode, so time discounting isn’t a thing. We’re not managing explore/exploit within episodes, but just trying to judge how good different moves are based on win/loss statistics, which is what any ML approach to the problem would have to do.
Also also, the loss doesn’t directly say “learn with a policy that maximizes expected discounted reward,” it says “learn a policy that imitates a smarter version of yourself (one who can use search)” and “learn a value function that captures expected reward” and then combines these in search scoring.
I think this is closest to what you were getting at? The learned policy will play well (“get rewards”) if used directly even without search (see Fig. 6 of AGZ paper, see also discussion in this thread). But this “learned policy” has a convoluted relationship with the true behavioral policy; it’s trained to imitate what search would do, where search has access to itself and also the separate value function.
The presence of the value function means the “learned policy” isn’t even just “the raw policy that search augments,” it’s a smaller piece of the picture than that. The relationship between all the pieces is very complicated and self-referential.
Having thought about it while writing this section, it does seem like a mistake to group this in with traditional RL that uses Q-learning or whatever. Even if we say “RL is a problem formulation,” this stuff distinctively (!) doesn’t quite fit in that formulation, since (again, ignoring Atari) the environment dynamics is entirely self-generated, with no way to write down the environment without terms that refer to the agent. And the methods used are very different.
(They’re apparently very powerful methods, so all the more reason to give them some name and study them as such, instead of lumping them uselessly under “RL”…)
Thanks to “GPT-3″ i’ve been reading a bunch of ML papers again. For some reason, this pretty good one got me thinking about an Bayesian statistics issue that strikes me as important, but which I haven’t seen discussed much.
——
Here I’m talking about “Bayesianism” primarily as the choice to use priors and posteriors over hypotheses rather than summarizing beliefs as point estimates.
To have a posterior distribution, you need to feed in a prior distribution. It’s deceptively easy to make a prior distribution feel natural in one dimension: point to any variable whatsoever in the real world, and say:
“Are you sure about that? Perfectly sure, down the the last micron/microsecond/whatever? Or are you fairly agnostic between some values? Yeah, it’s the latter. Okay, why not average over the predictions from those, rather than selecting one in a purely arbitrary way?”
This is very convincing!
However, when you add in more variables, this story breaks down. It’s easy enough to look at one variable and have an intuitive sense, not just that you aren’t certain about it, but what a plausiblerange might be. But with N variables, a “plausible range” for their joint distribution is some complicated N-dimensional shape, expressing all their complex inter-dependencies.
For large N, this becomes difficult to think about, both:
combinatorially: there is an exploding number of pairwise, three-way, etc. interactions to separately check in your head or – to phrase it differently – an exploding number of volume elements where the distribution might conceivably deviate from its surrounding shape
intellectually: jointlyspecifying your intuitions over a larger number of variables means expressing more and more complete account of how everything in the world relates to everything else (according to your current beliefs) – eventually requiring the joint specification of complex world-models that meet, then exceed, the current claims of all academic disciplines
——
Rather than thinking about fully “Bayesian” and “non-Bayesian” approaches to the same N variables, it can be useful to think of a spectrum of choice to “make a variable Bayesian,” which means taking something you previously viewed as constant and assigning it a prior distribution.
In this sense, a Bayesian statistician is still keeping most variables non-Bayesian. Even if they give distributions to their parameters, they make hold the model’s form constant. Even if they express a prior over model forms (say a Gaussian Process) they still may hold constant various assumptions about the data-collecting process, indeed they may treat the data as “golden” and absolute. And even if they make that Bayesian, there are still the many background assumptions needed to make modern scientific reasoning possible, few of which are jointly questioned in any one research project.
So, the choice is not really about whether to have 0 Bayesian variables or >0. The choice is which variables to make Bayesian. Your results are (effectively) a joint distribution over the Bayesian variables, conditional on fixed values of all the non-Bayesian variables.
We usually have strong intuitions about plausible values for individual variables, but weak or undefined ones for joint plausibility. This is almost the definition of “variable”: we usually parameterize our descriptions in terms of the things we can most directly observe. We have many memories of directly observing many directly-observable-things (variables), and hence for any given one, we can easily poll our memories to get a distribution sample over it.
So, “variables” are generally the coordinates on which our experience gives us good estimates of the true marginals (not the marginals of any model, but the real ones). If we compute a conditional probability, conditioned on the value of some “variables” – i.e. if we make those variables non-Bayesian – this gives us something that’s plausible if and only ifall the conditioning variables are all independently plausible, which is the kind of fact we find it easy to check intuitively.
If we make the variable Bayesian, we instead get a plausibility condition involving the prior joint distribution over it and the rest. But this is the kind of thing we don’t have intuitions over.
——
But that’s all too extreme, you say! We have some joint intuitions over variables. (Our direct observations aren’t optimized for independence, and have many obvious redundancies.) In these cases, what prior captures our knowledge?
Let’s run with the idea from above, that our 1D intuitions come from memories of many individual observations along that direction. That is, they are a distribution statistically estimated from data somehow. The Bayesian way to do that would be to take some very agnostic prior, and update it with the data.
When you’ve noticed patterns across more than one dimension, the story is the same: you have a dataset in N dimensions, you have some prior, and you compute the posterior.
In other words, “determining the exact prior that expresses your intuitions” is equivalent to “performing statistical inference over everything you’ve ever observed.” The more dimensions are involved, the more difficult this becomes just as a math problem – inference is hard in high dimensions.
So there’s a perfectly good Bayesian story explaining why we have a good sense of 1D plausibilities but not joint ones. (1D inference is easier.) A practical Bayesian knows about these relative difficulties when they’re wrangling with their prior now and their posterior after the new data.
But the same difficulties call into question their prior now, and would encourage relaxing it to something that only requires estimating 1D plausibilities, if possible. But that’s just a non-Bayesian model, one that conditions on its variables. Recognizing the difficulty structure of Bayesian inference as applied to the past can motivate modeling choices we would call “non-Bayesian” in the present.
Frequentist methods, rather than taking a variable to be constant, also try to obtain guaranteed accuracy regardless of the value of the variable. One can view this as trying to optimize accuracy in the worst case of the variable. It’s often equivalent to optimize accuracy in the worst case over probability distributions of the variable.
Could one try to optimize accuracy of some prediction, in the worst case over all probability distributions of the n variables with given marginals?
This sounds mathematically very complicated to compute but maybe there is a method to approximate certain versions of it which has some nice properties.
Could one try to optimize accuracy of some prediction, in the worst case over all probability distributions of the n variables with given marginals?
This sounds like an interesting topic, but it isn’t really what I was going for in the OP.
But the difference wasn’t very clear in what I wrote – possibly not even in my head as I wrote it – so I should write it out more clearly now.
—-
I’m considering situations like, say, you have variables (x_1, x_2, x_3, y) and maybe your primary goal is to predict y. You don’t have a good prior sense of how the variables affect either other, but you can draw empirical samples from their joint distribution.
(If the variables are properties of individuals in a population, this is sampling from the population. If the variables are “world facts” with only a single known realization, like constants of fundamental physics, you can at least get the best known estimate for each one, an N=1 sample from the joint [insofar as the joint exists at all in this case].)
Compare two approaches:
(1) The “fully Bayesian” approach. Start by constructing a joint prior
P_prior(x_1, x_2, x_3, y)
then use data to update this to
P_posterior(x_1, x_2, x_3, y)
and finally make predictions for y from the marginal
(2) A “non-Bayesian” approach. Compute a conditional probability:
P(y | x_1, x_2, x_3)
Then make predictions for y by simply plugging in observed values for x_1, x_2, x_3.
——
In (2), you defer to reality for knowledge of the joint over (x_1, x_2, x_3). This guarantees you get a valid conditional probability no matter what that joint is, and without knowing anything about it. Because any values you plug in for (x_1, x_2, x_3) are sampled from reality, you don’t have to know how likely these values were before you observed them, only that they have in fact occurred. Since they’ve occurred, the probability conditioned on them is just what you want.
As an extreme example, suppose in reality x_1 = x_2, although you aren’t aware of this.
Any time you take an empirical measurement, it will just so happen to have x_1 ≈ x_2 (approximate due to measurement error). Your predictions for y, whatever other problems they might have, will never contain contributions from impossible regions where |x_1 - x_2| is large.
In (1), however, your posterior may still have significant mass in the impossible regions. Your prior will generally have significant mass there (since you don’t know that x_1 = x_2 yet). In the infinite-data limit your posterior will converge to one placing zero mass there, but your finite data will at best just decrease the mass there. Thus your predictions for y have error due to sampling from impossible regions, and only in the infinite-data limit do you obtain the guarantee which (2) provides in all cases.
——
I want to emphasize that both approaches have a way of “capturing your uncertainty” over (x_1, x_2, x_3) – often touted as an advantage of the Bayesian approach.
In the Bayesian approach (1):
Uncertainty is captured by marginalization. At the end you report a single predictive distribution P(y), which averages over a joint that is probably wrong in some unknown way.
When you learn new things about the joint, such as “x_1 = x_2,″ your previously reported P(y) is now suspect and you have to re-do the whole thing to get something you trust.
In the non-Bayesian approach (2):
Uncertainty is captured by sensitivity analysis. You can see various plausible candidates for (x_1, x_2, x_3), so you evaluate P(y | x_1, x_2, x_3) across these and report the results.
So, rather than one predictive distribution, you get N = number of candidates you tried. If it turns out later that some of the candidates are impossible, you can simply ignore those ones and keep the rest (this is Bayesian conditionalization on the new information).
——
In summary, marginals as predictive distributions for a target y only reflect your true state of belief insofar as you have good prior knowledge of the joint over the predictors X.
When you don’t have that, it’s better not to integrate for P(y) over volume elements for X, but instead just to compute the integrand at volume elements for X.
This provides something you can query any time you see a sample having some particular value for X, and lets you gradually ignore or emphasize volume elements as you gain knowledge about their mass. (If you eventually gain full knowledge of the joint over X, you are now in position to integrate if you want, getting the same result as the Bayesian would with the same knowledge.)
I still feel like there’s a way to state this all more simply, but it still eludes me, so here we are.
when i watch old movies i’m constantly surprised by how much acting has improved. not that the acting in the classics is bad, it’s just often kind of artificial? it’s acting-y. it’s like stage acting.
it took some decades for the arts of acting and filmmaking to catch up to the potential that was in movies all along; stuff like microexpressions and silences and eyes, oh man people are SO much better at acting with their eyes than they were in the 40′s, or even the 70′s.
the performances we take for granted in adventure movies and comedies now would’ve blown the critics’ socks off in the days of ‘casablanca’.
there’s a weird period in film where you can see the transition happening. right around the fifties, I think. the example my prof used when i learned about it was marlon brando in “a streetcar named desire” - he was using stanislavski acting methods and this new hyper-realistic style and most or all of his costars were still using the old, highly-stylized way of acting. it makes it way more obvious how false it is.
i even noticed it in ‘the sting’, which was 1973. i actually think they used it on purpose to get the viewer fished in by the second layer of the con; the grifters at the bookie’s were acting like they were acting, and the grifters playing the feds were acting for reals. if you’re used to setting your suspension of disbelief at the first set’s level, then the second set are gonna blow right past you.
or possibly the guys playing the grifters playing the feds just happened to be using the realistic style for their own reason, and it coincidentally made the plot twist work better. but i like to think it was deliberate.
i was thinking about this again, and when you know what to look for, it’s really obvious: old movies are stage acting, not movie acting. it just didn’t really occur to anyone to make the camera bend to the actors, rather than the other way around. just image search old movie screenshots and clips and gifs, you’ll see it. the way people march up to their mark and stand there, the way they deliver their lines rather than inhabiting the character. the way they’re framed in an unmoving center-stage.
this is a charming little tableau, quirky and unexpected, but it’s a tableau. it lives in a box.
now, i usually watch action movies, and i didn’t think it was fair to compare an action movie with what appears to be an indoor sort of story, but i do watch some comedy tv. so i looked for a brooklyn 99 gif with a similar framing, intending to point out that the camera moves, and the characters aren’t stuck inside the box. but i couldn’t even find the framing. they literally never have all the characters in the same plane, facing the camera, interacting only within the staging area. even when they’re not traveling, they’re moving around, and they treat things outside the ‘stage’ as real and interact with them, even if it’s only to stare in delighted horror.
as for action, it took a while for the movies to figure out what, exactly they wanted to show us, and how to act it. here’s a comedy punch:
here, also, is a comedy punch:
the first one looks like a stage direction written on a script. the second one looks like your friends horsing around and being jerks to each other. the first one is just not believable. the physics doesn’t work. the reaction is fakey. everyone’s stiff. even the movement of the camera is kind of wooden. the second one looks real right down to the cringe of his shoulder, and the camera feels startled too.
i’m not saying this to dis old movies, i’m just fascinated and impressed by how much the art has advanced!
I’m going to bed, but I also want to say that I think, without actually bothering to explore it and make sure, that there’s been a similar shift in comics, probably related to the shift in acting/camera work. And I think you still see remnants of old “stage acting” comics in the three-panel style set ups (you might still see it in long form comics, but you’d probably call it bad composition)
Now can someone explain why people in old films talked Like That
Y’all, THAT’S HOW PEOPLE TALKED.
Seriously, I used to work in a sound studio, and one series of projects required us to listen to LOTS of old audio recordings. Not of anything special - just people talking.
AND THEY TALKED LIKE THAT.
It was so fucking wild to hear just a couple of people being like,
“WELL HI THERE JEANINE, HOW ARE YOU TODAY?”
“OH, NOT TOO BAD, JOE, THOUGH MY HUSBAND’S BEEN AWAY ON BUSINESS FOR A FEW WEEKS AND I MISS HIM SOMETHING TERRIBLE.”
“WELL IT’S A HARD THING, JEANINE, BUT YOU’LL GET THROUGH IT.”
“WELL I SUPPOSE I’VE GOT TO, HAVEN’T I JOE?”
All in that piercing, strident, rapid-fire style we associate with the films of the era. If you’ve watched lots of old movies you can imagine the above in that speech pattern.
I don’t know if people talked like that because it was in movies but I suspect it’s the other way around.
Same goes for the UK - When they made the TV series The Hour, set in the 1950s, they had to tell the very well spoken, privately educated Dominic West to tone down his imitation of a 1950s newsreader because being accurate would have sounded to a 2011 TV audience as if he was doing a parody. When you watch Brief Encounter they’re not speaking like that because they can’t act, they’re speaking like that because it was the norm on screen. It now sounds unnatural because it’s not the norm any more.
Obviously there were people with regional accents and who didn’t speak in a heightened manner, but they didn’t get to be on TV or in movies unless they were villains. (And usually the villains were putting it on, like Richard Attenborough in Brighton Rock. Sure, he was Richard Attenborough, but he was brought up in the Midlands, and by the on-screen standards of the time, that was common.)
Even the Queen’s very posh accent has changed over the last 50 years and become “more common" - check out newsreel footage etc for proof - and recordings of her father are almost like someone from a foreign country (well, it is the past).
There is, for many film historians/critics, an actual turning point from mannered, theatrical, or “overplayed” acting on screen to naturalistic/American Method realism on screen. It happens in the 1954 movie On the Waterfront, during a traveling shot in which Marlon Brando’s character and Eva Marie Saint’s character are walking together. Eva Marie Saint accidentally drops her glove in the middle of the scene. Marlon Brando instinctively picks it up as his character, and continues the dialog, all the while playing with the glove–turning it about, trying it on, etc. Eva Marie Saint stuck with him, never broke, and the director didn’t call “cut.”
Before that scene in that movie, if an actor dropped a prop by accident, they would have re-shot the scene–because Brando mostly disappeared out of frame as he bent down to pick up the glove, and (as is explained above) movies were framed to keep the people in the scene in the frame. I
t’s a pretty famous scene in movies because Brando’s character doesn’t give the glove back, but instead uses it to amplify what the two characters are experiencing, naturally and without artifice. It is, for all intents and purposes, the exact moment that screen acting changed.
Okay, but here’s the thing about television specifically: given the size of TV screens when they first came out? Stage acting was the only thing that could be READ. Watch Star Trek: TOS on a modern screen and it looks absurdly overacted. Film of the same era is not, and yet the TV is.
And that’s not a fault of the actors; they were all very capable of naturalistic film acting (yes, even Shatner) – as the later movies would bear out. It’s because they were acting for the small screen, not the big one.
Stage acting and stage makeup is what it is because people are far enough away from the stage that you have to cake on the makeup garishly and exaggerate the hell out of your for it to be VISIBLE. And in early television? Yeah, those constraints actually very much applied. You could move the camera, sure, but the quantity of visual information you could send was just damned limited.
Here’s another example of that.
Watch some Classic Dr Who. You may or may not notice it without watching for it, but every shot of the TARDIS is taken from the same angle.
The TARDIS was, at that time, a stage set. The camera was behind the fourth (Sixth?) wall. It was fixed. And most TV sets were built like this. They had a specific fourth wall and everything was filmed from that angle.
Fast forward to the new series, and you’ll see that the TARDIS is being filmed from different angles all the time, including following the actor around.
Three things have changed:
1. Cameras have become much smaller.
2. Set building for TV has developed as an art. Those early sets were built by people who were trained to build stage sets.
3. Overall technological improvement resulting in things being cheaper.
The TARDIS set that was just retired? Each of its walls was designed to slide out. So you could put the camera anywhere you wanted. Presumably this is the case with the new one too. They couldn’t imagine doing that back in the day. Nor could they afford the complexities of a set like that.
It’s actually my opinion that TV has very much matured as an art form…this century. This decade. We are doing and seeing things that couldn’t be done ten years ago, twenty. Heck, even five.
Going back to speech patterns for a moment – I was a young child in the 80s, so my memories of the norms of the time period are limited (especially because I was incredibly sheltered), but the books I read at the time and the popular movies of the time all have this kind of – whimsical, sardonic speech pattern going on. Think John Waters dialogue.
I always thought it was kind of stylized. But then I ended up in a weird part of YouTube one night and found someone’s home video of just walking aroud a 7-11 convenience store at midnight talking to people in Orlando, Florida. Just trying out their new camcorder for shits and giggles, talking to other customers, talking to the cashier, etc. And you know what? They all talked like a goddamn John Waters movie. It was the weirdest thing, like I was watching outtakes from The Breakfast Club or Say Anything. I expected one of the Cusacks to walk into frame any second.
Anyway, so I think it’s super cool how human speech and interaction shifts over time, and if you’re living through the shift, you don’t really notice it as it happens.
A) I think you mean John Hughes but I’m very amused by the idea of everyone talking like it’s a John Waters movie
B) This is still happening only now you can pick up people’s net accents. My friends with tumblrs have tumblr diction. My friends who only spend time on facebook for social media sound VERY different. People who use twitter heavily put emphasis on different things and have a different meme literacy (you all know the difference between the way greentext sounds and the way “RIP but I’m different” sounds).
Anyway have fun listening for tumblr accents now
What gets me is that I had a medium-strong tumblr accent before I joined tumblr. ( @magikarpjumpest and I have talked about this a few times) The way I break clauses, my stress patterns, hell, I do the Midsentence Emphatic Capitalization in speech. And I think that ties in to why I do the Giant Tumblr Rambles in a way that I just… don’t, on FB. I’m too rambly for twitter, and while I can use ‘tag group dialogue’ as a facebooker, and occasionally will in speech (yes, I code-switch my social media dialect in person; I’m conscious of the fact that I mirror, but it’s not generally a thing I decide to do), that’s not my default setting for phrasing. Established tone/accent conventions of tumblr already correspond somewhat to my natural way of speaking, and it’s much easier to get two forms of dialogue that are already close to merge. It also means that engaging with longposts here is much easier because people are more likely to be using humor and syntax that feels natural to me. Twitter threads have a concision to them. Greentext boards -I can read them, but it’s like reading something with a very heavy transcribed accent that I almost never hear in person -it’s a headache-inducing amount of effort that’s usually not worth it to me for a downtime activity. FB doesn’t do paragraph breaks the same way, and the emoticon usage is different enough that I don’t like dealing with it.
This is a wild read from start to finish!!
Having lived through early Web 2.0, I can tell you that “accents through time” also applies to internet “accents.”
You know how people now will end sentences with “Lol” to indicate they’re not mad (e.g. “I have to go now lol, Mom’s home”)? Yeah, we didn’t used to do that. We also used to have a sarcasm tag! I’m going to apologize to the people with screen readers and tell you I promise this is reasonably short. It looked like this:
“Yeah, well, Obama is a ~*~*~Muslim.~*~*~
The asterisk action tags used to be a non-ironic, non-cringey thing, too. Like this:
“NINA GUESS WHAT”
“What??? :D”
“(Typing notification)”
“*waits*”
The term “teal deer” to replace “TL;dr” was a thing. And, of course, in the early 2000s you had 13375p34k, which for younger folks was “leetspeak.” One is the Homestuck characters uses it, but it’s not just a quirk—people really talked like that.
We are far enough into the internet era that even internet accents have changed.
This is a *fantastic* post and something I find very fascinating, because I tend to focus really strongly on character dialogue and speech. Also I’ve definitely noticed that my internet ‘accent’ is definitely slightly antiquated. I’m still much more likely to use a :3 or a -3- text emoticon over a smiley, and I’m not in the habit of using reaction gifs, and I definitely still do actions inside asterix’.
then again I’m also the kind of person who uses words like antiquated, so I wonder if soon enough it’ll all sound the same amount of old fashioned?
This is why I find it slightly offputting when younger people end every sentence with “lol” - during my formative internet years, it was used… well, to mean what it stands for. So the use of it now always strikes me as being almost rude, like you aren’t taking any of the conversation seriously. That person who just laughs at everything, when you’re trying to get them to pay attention. FRUSTRATION!
I am 100% aware that that’s not what it means, and understand how it’s being used now, I’m just saying my brain doesn’t process it that way. I have to consciously realign when talking to people who use it a lot. It’s amusing, really. Stupid old brain.
/I am Seteth
Back in the day there was Usenet. Usenet is after the Internet, but slightly. It was designed to work over phone lines: computers would sync up and exchange articles. Later NNTP a was a thing.
:-) comes from there. Flamewars and trolling come from there. Spoiler warnings come from there. A lot has changed over the ensuing decades, but a lot hasn’t.
