gdb

(I work at OpenAI.)

It's really how it works.

One detail you may have missed — "system" is only special when it comes right after a special token. So it's not a special token itself, but you cannot inject a valid-looking system message from user text.

In more detail, the current format is:

<|im_start|>HEADER BODY<|im_end|>

We are actually going to swap over to this shortly:

<|start|>HEADER<|sep|>BODY<|end|>

So basically getting rid of the newline separator and replacing with a special token. Shouldn't change anything fundamentally, but does help with some whitespace tokenization-related issues.

BTW, format of HEADER is going to be really interesting, there's all sorts of metadata one might want to add in there — and making sure that its extensible and not injectable will be an ongoing part of the design work!

Instant Message :). We will drop that prefix in future releases though.

Will all make more sense with upcoming releases, we have a lot of extensions in the works :).

(I work at OpenAI.)

This document is a preview of the underlying format consumed by ChatGPT models. As an API user, today you use our higher-level API (https://platform.openai.com/docs/guides/chat). We'll be opening up direct access to this format in the future, and want to give people visibility into what's going on under the hood in the meanwhile!

(I work at OpenAI.)

Thanks for the report — these are not actually messages from other users, but instead the model generating something ~random due to hitting a bug on our backend where, rather than submitting your question, we submitted an empty query to the model.

That's why you see just the answers and no question upon refresh — the question has been effectively dropped for this request. Team is fixing the issue so this doesn't happen in the future!

Here's how I got started: https://blog.gregbrockman.com/how-i-became-a-machine-learnin...

There are many courses available these days; I recommend picking a simple project to start (for me, it was trying to make inference work for GPT-1), learn what you need to in order to get started, and iterate from there.

(I work at OpenAI.)

We've been ramping up our invites from the waitlist — our Slack community has over 18,000 members — but we still are only a small fraction of way through. We've been really overwhelmed with the demand and have been scaling our team and processes to be able to meet it.

We can also often accelerate invites for people who do have a specific application they'd like to build. Please feel free to email me (gdb@openai.com) and I may be able to help. (As a caveat, I get about a hundred emails a week, so I can't reply to all of them — but know that I will do my best.)

(I work at OpenAI.)

especially as someone that didn't get a response for my requests for GPT-3 beta access

We are still working our way through the beta list — we've received tens of thousands of applications and we're trying to grow responsibly. We will definitely get to you (and everyone else who applies), but it may take some time.

We are generally prioritizing people with a specific application they'd like to build, if you email me directly (gdb@openai.com) I may be able to accelerate an invite to you.

waves

Given the amount of demand, we're trying to prioritize folks who want to build a concrete application or integrate with a product.

Please feel free to email me (gdb@openai.com) and let me know what you'd like to build — I can't guarantee I'll be able to accelerate an invite, but at the very least I'll make sure we're tracking your use-case internally.

There's just about infinite surface area with the API — we're trying to build a dead-simple API that developers can plug into any product in order to add intelligence features that would be otherwise impossible.

This requires a lot of traditional software work — API design, writing and maintaining a growing amount of business logic, providing great tools and interfaces to help our users work with the API, excellent documentation and tutorials, scaling and operating backend systems, etc — and machine learning systems work — building serving infrastructure for a great variety of giant neural networks while making the most efficient use of our hardware, allowing our users to interact with these neural networks in increasingly sophisticated ways, etc.

While we're just getting started and have a small team, we are already supporting customers across a wide variety of industries (see https://beta.openai.com/ for a sample) and serving millions of requests per day. We are busy trying to invite folks off a very long waitlist while building out the API to support everyone.

Would love more help :).

(I work at OpenAI.)

I am finishing up our fine-tuning API this weekend :).

If anyone on HN would like to try out the fine-tuning API (or want to build something on top of the base API), send me an email (gdb@openai.com) with your use-case and I can try to accelerate you in our invite queue.

PS: We're hiring — if you enjoy building APIs with Python/Go/Kubernetes/Kafka or building front-end interfaces in React, then please get in touch — gdb@openai.com.

You can use the API live in multiple products, such as AI Dungeon (https://play.aidungeon.io/)!

OpenAI LP, our "capped-profit" entity which has taken investment, has a fiduciary duty to the OpenAI Charter: https://openai.com/blog/openai-lp/

Sign up for the beta if you'd like to be the one to flesh them out :)!

We also have code like that. For example, that's the explicit goal of the Spinning Up repo: https://github.com/openai/spinningup/blob/master/spinup/algo...

In practice, it's much harder to use that code, and we tend not to consume code like that internally. There's a real tradeoff!

(I work at OpenAI. Before that, I worked at Stripe. I've spent most of my software career thinking about how to build effective engineering cultures.)

I think this code is actually well-written and maintainable. This is proven in practice because we've adopted it many places in OpenAI, and I've personally found it very easy to adapt to other use-cases (certainly much more so than the from-scratch Transformer implementations I've written!).

As https://news.ycombinator.com/item?id=21456605 points out, the complexity of the code arises from the complexity of the underlying algorithm. Complexity due to software engineering concerns, like Tensorflow scopes, are elegantly handled. [edited for clarity:] Writing a Transformer in 174 lines of code requires a lot of deep thinking about the right underlying abstractions.

but essentially as soon as you enter the 'ml engineer/research engineer/research scientist' layer, it's doomed.

We actually don't do this! Our only official technical title is "member of technical staff". (People sometimes choose to self-identify as an engineer or researcher, so you might see that on LinkedIn, but we don't have a distinction internally.) Everyone is responsible for their own code, and people care quite a bit about writing code that others can build on.

I've just lost faith in the organization to be honest

:( sorry to hear that.

Note that we have a publicly-available Charter which spells out how we operate: http://openai.com/charter. We all use that to guide our actions, and we have not changed a single word in it since publication. I hope that as time goes on, you'll increasingly see the consistency between our actions and the words in the Charter, we'll be able to win back your support.

Yes — but note that "success" is a not-very-granular metric (which we set for ourselves!), as it means fully unscrambling the cube without dropping it once.

To be clear, that means executing up to 100 moves without a drop. If you put the cube back in the robot's hand, without any additional effort it'll continue solving unfazed.

(I work at OpenAI.)

Per https://news.ycombinator.com/item?id=21306452, we have results for both instrumented and uninstrumented cubes!

Our cube variants are listed in the blog post ("Behind the scenes: Rubik’s Cube prototypes"), and results are in the paper in Table 6.

(I work at OpenAI.)

We also have results with an uninstrumented cube (as described in section 7 in the paper, or "Behind the scenes: Rubik's Cube prototypes" in the blog post), which are slightly weaker (see Table 6 in the paper). The 20% number is an example of critics cherry-picking their facts — the success rate is 60% under normal conditions, but 20% with a maximally-scrambled cube (which would happen randomly with probability less than 10^-20).

Also note: success here means that the robot was able to perfectly unscramble the cube — which requires perfectly performing up to 100 moves — without dropping it once. What it means, in practical terms, is that you need to wait for a long time in order to witness even a single failure. If you pick up the cube and place it back in the hand, it'll get right back to solving.

Note that like with OpenAI Five, the success rate is more of a function of how far we've had time to push the system than something fundamental. We're not building commercial robots; we're in the business of making new AI breakthroughs. So the next step for our robotics team will be finding a new task that feels impossible today, and see what it takes to make it no longer feel impossible.

Good catch! Will update the post to be explicit that there are many pre-existing awesome results in this vein.

I really wish I had more of an opportunity to play with AI/ML in my day to day work.

Anyone who feels this way — we're hiring :)! https://openai.com/jobs/.

(Also if I can answer any questions about OpenAI, feel free to ping me at gdb@openai.com.)

(I wrote the post.)

If it's helpful, I dropped out of both schools — the vast majority of my knowledge is self taught!

The investment is in OpenAI LP: https://openai.com/blog/openai-lp/!

We'll still release quite a lot, and those releases won't look any different from the past.

I understand that keeping some innovations private may help commercialization, which may help raise more funds for OpenAI, getting us to AGI faster, so my opinion is that could plausibly make sense.

That's exactly how we think about it. We're interested in licensing some technologies in order to fund our AGI efforts. But even if we keep technology private for this reason, we still might be able to eventually publish it.

(I work at OpenAI.)

It could be doled out over the course of a decade or more.

The NYT article is misleading here. We'll definitely spend the $1B within 5 years, and maybe much faster.

We certainly do plan to be a big Azure customer though!

OpenAI Nonprofit’s initial funding commitment was to be consumed over many years!

When we started, we didn't know just how fast things would be moving (e.g. https://openai.com/blog/ai-and-compute/), and we've needed to scale much faster than planned when starting OpenAI.

Good feedback, and not what I intended to say. I updated my post.

(I work at OpenAI.)

It comes down to whether you believe AGI is achievable.

We've talked about why we think it might be: https://medium.com/syncedreview/openai-founder-short-term-ag..., https://www.youtube.com/watch?v=YHCSNsLKHfM

And we certainly have more of a plan for building it than warp drives :).

EDIT: I personally think the case for near-term AGI is strong enough that it'd be hard for me work on any other problem — and find it important to put in place guardrails like https://openai.com/blog/openai-lp/ and https://openai.com/charter/.

Even if AGI turns out to be out of reach, we'll still be creating increasingly powerful AI technologies — which I think pretty clearly have the potential to alter society and require special care and thought.