nostalgebraist

FWIW, I deal with "the realities of ML devops on the cloud" nearly every day -- both at work and in hobby projects.

The comments here make me think I failed to get my main intent across in the post. I actually agree with many of the concrete claims you make here, but they have little to do with the arguments I saw myself as making.

The miscommunication was apparently so complete that if I tried to dig into specific points you make here, I'd end up effectively re-writing my post all over again. It was kind of exhausting to write the first time, so I'd prefer not to.

That said, as an example of something I didn't mean to say: I definitely don't think the sklearn API ought to be standard across ML, certainly not the pickling part! It is a well-designed API that's just right for its own limited context, and ought to inspire others to develop other APIs that are similarly well-designed for their contexts.

I only added the comment about Keras and pickle because I had quoted a tweet that literally said Keras was sklearn API compatible, and felt sort of obligated to point out that this was strictly false. Insofar as this relates to the larger point at all, it does so only as evidence that people like Chollet don't have a deep understanding of the thing they say they're inspired by.

The Sagemaker python SDK provides a usability wrapper around API calls (etc) that trigger Sagemaker (the product) to do things. In the usage example I screenshotted, these include running a user-provided script "train.py" in a Docker container with mxnet installed.

All the ML happens inside the Docker container, and this process does not any use code from the SDK. The SDK contains non-ML code intended to help the user kick off such jobs. The SDK's Estimator class is purely a helper for using Docker and the Sagemaker API, and is only useful when all the ML code has already been written.

The GPT-3 paper (https://arxiv.org/pdf/2005.14165.pdf) has a very large number of graphs showing parameter count on the horizontal axis and some kind of prediction quality metric on the vertical axis. Most of the interesting ones are in Appendix H.

"The point isn’t the performance at 175B, but the shape of the curve as it passes from 117M to 175B" was referring to a general point about how to interpret any/all of those graphs, not a particular one of them.

As I said in the post, the closest thing I can find is the FAQ at https://research.google.com/colaboratory/faq.html (this may be what you're thinking of -- there is no "initial setup process," anyone logged in to a Google account can immediately connect to a runtime and execute notebook cells). It says the following:

Why are hardware resources such as T4 GPUs not available to me?

The best available hardware is prioritized for users who use Colaboratory interactively rather than for long-running computations. Users who use Colaboratory for long-running computations may be temporarily restricted in the type of hardware made available to them, and/or the duration that the hardware can be used for. We encourage users with high computational needs to use Colaboratory’s UI with a local runtime. Please note that using Colaboratory for cryptocurrency mining is disallowed entirely, and may result in being banned from using Colab altogether.

To me, this doesn't sound like "please don't use this wrong or too much, and we assume you know what 'wrong' and 'too much' mean here." Consider how this is written as an answer to a hypothetical user who has already been "temporarily restricted" and is looking for more info. They talk about this restriction non-judgmentally, like it's a practical limitation of their tool anyone might run into, not a moral line that "good" users will never cross anyway.

(The part about cryptocurrency mining is different and perfectly understandable, given the distinctive moral and perhaps legal facts of that subject.)

See also my post https://nostalgebraist.tumblr.com/post/190114849409/cloud-ca... for more thoughts on the subject. The screenshot there is from the 2017 conference talk https://gojko.net/2017/10/05/serverless-design-gotocph.html which happily discusses unintended but economically rational use of AWS products, like using IOT Gateway for non-IOT purposes where its pricing model is convenient.

Language modeling is about predicting what can be predicted about the rest of a text, given the first N tokens. Not everything in text can be predicted in this way, even by humans; the things we say to each other tend to convey novel information and thus aren't fully compressible. And indeed the compressible-ness of text varies across a text in a way that it is itself relatively predictable. If someone writes "for all intents and" you can be pretty sure the next word is "purposes," i.e. you're unlikely to learn much when you read it; if someone is writing a dialogue between two characters, and you're about to see the see one of their names for the first time, you will learn something new and unpredictable when you read the next word, and you know that this will happen (and why).

A language modeling objective is only really natural for the first of these two cases. In the latter case, the "right" thing to do from the LM perspective is to output a fairly flat probability distribution over possible names (which is a lot of possibilities), assigning very low probability to any given name. But what this means is actually ambiguous between "I am unsure about my next observation because I don't understand the context" and "I understand the context, and it implies (predictably) that my next observation will be inherently unpredictable."

Since any model is going to be imperfect at judging whether it's about to see something unpredictable, it'll assign some weight to the next observation being predictable (say, a repeated topic or name) even if it's mostly sure it will be unpredictable. This will push up the probabilities of its predictions on the assumption of predictability (i.e. of a repeated topic/name), and meanwhile the probability of anything else is low, because if an observation is unpredictable then it might well be anything.

I hypothesize that this is behind behavior like putting a single name ("Obama" in your earlier example) in too many roles in an article: if only Obama has been mentioned, then either an upcoming name is "Obama" (in which case we should guess "Obama") or it's some other name (in which case we should guess against Obama in slight favor of any other name -- but this will only be conveyed to the model via the confusing signal "guess this arbitrary name! now this other one! now this one!", with the right trend only emerging in the average over numerous unpredictable cases, while the predictable-case rule where you guess the name that has already been mentioned is crystal-clear and reinforced in every case where it happens to be right).

I also suspect the use of a sub-word encoding (BPE) in GPT-2 exacerbates this issue once we are doing generation, because the model can initially guess only part of the high-entropy word without fully committing to a repeat (say just the "O" in "Obama"), but once this becomes part of the context the probability of a repeat is now much higher (we already thought "Obama" was unusually probable, and now we're looking for a name that starts with "O").

FWIW, my post that's linked here doesn't claim that GPT-2 won't have dangerous successors, just that GPT-2 itself is not very dangerous, and that this doesn't vary much with the model size. The point is not about the five-to-ten-year trajectory of natural language generation research, which could go all sorts of unexpected places -- indeed, GPT-2 itself was such an "unexpected place" from the perspective of a few years ago. The point is a narrower one about OpenAI's staged release plan, which assumed different levels of risk, or at least different prior distributions over risk, for different sizes of the same model.

I agree that

Architectures that tune text creation to create clickbait titles with underlying goals are going to get worked on and thought about and tested

but that is a distinct discussion, one about future research milestones enabled by the relative success of generation by sampling from transformer LMs. My claim is that significant further milestones will be necessary (not that they won't happen); there are big and relevant limitations on sampling from currently existing transformer LMs, and simply making the transformer LMs bigger does not remove these. In particular, these limitations make it unlikely to be cost-effective to make clickbait or propaganda by curating and cleaning samples from such a model.

If you doubt this, I'd encourage you to actually go through the exercise: imagine you want to generate a lot of text of some sort for a specific real-world purpose that would otherwise require human writers, and try out some strategy of sampling, curation, and (optionally) fine-tuning with one or more of the available GPT-2 sizes. If your experience is like mine, you'll draw the same conclusion I've drawn. If not, the results would be fascinating and I would honestly love to see them written up (and OpenAI might as well).