Photo by Alex on Unsplash

Five Big Misconceptions About The OpenAI API (GPT-3) & Codex

Considering NLU In General & Chatbots In Specific

Cobus Greyling
8 min readSep 21, 2021

--

Introduction

The five biggest misconceptions regarding OpenAI and their natural language API, GPT-3 & Codes are:

  1. The OpenAI API based on GPT-3 is a Chatbot Development Framework
  2. OpenAI has Released Comprehensive Finetuning for the Language API
  3. We Understand OpenAI’s End Game
  4. Codex will Replace Developers
  5. Codex Can Create Complex Implementations

Each of these five points are discussed in detail later, but first an overview of the basics:

OpenAI is an AI research and deployment company. Their mission is to ensure that artificial general intelligence benefits all of humanity.

One of the OpenAI Language API functions is idea generation. As you can see in this example, a question can be posed like: “Blog topics dealing with daily life living on Mars”. A list of topics are generated.

GPT-3, in simple terms, is a language model that uses deep learning to produce human-like text. It is the third-generation language prediction model in the GPT-n series created by the company OpenAI.

OpenAI API, makes use of GPT-3. And is a text-in-text-out API.

Submit any text prompt to the API, and the API return a text completion.

A pattern is detected from the input text, and reflected in the output.

You can program the API by adding a few example dialog turns illustrating what you are trying to achieve.

A general question & answer chatbot with limited training examples.

There are fine-tuning options available to OpenAI API, but it is currently in Beta and limited.

OpenAI Codex is an AI system that translates natural language into code.

Codex powers GitHub Copilot, which OpenAI built and launched in partnership with GitHub recently.

Codex can interpret simple commands in natural language and create and execute code. NLU to applications.

This is a new implementation of natural language, one could argue. Code can also be submitted, and is explained in natural language. And code can be debugged.

The OpenAI API based on GPT-3 is a Chatbot Development Framework

The OpenAI API language API is not chatbot development framework. OpenAI API, makes use of GPT-3. And is a text-in-text-out API. Submit any text prompt to the API, and the API return a text completion.

A pattern is detected from the input text, and matched in the output.

You can program the API by adding a few example dialog turns illustrating what you are trying to achieve.

There are fine-tuning options available to the OpenAI API, but it is currently in Beta and is limited.

The use-cases for the Language API is still open for discussion, looking at the Codex videos, it seems if they are also not sure what it might spawn. Codex is a case in point. It is impressive and there are implementation for it currently.

In this story I discuss in detail what is needed for a chatbot development framework, and for OpenAI to fully conform to these principles now will not be wise…

“Any sufficiently advanced technology is indistinguishable from magic.” Arthur C. Clarke

OpenAI is deprecating elements like:

  • Fixed bot return dialog with Natural Language Generation,
  • Dialog state management,
  • and even Intents and entities.

Yes, it is a step to far for a fully fledged production chatbot. But they might develop fine-tuning in such a way to leverage all these innovations in the near future.

OpenAI has Released Comprehensive Finetuning for the Language API

GPT-3 as a conversational environment is definitely moving in the right direction. With GPT-3, it seems if OpenAI started at the opposite end, compared to what other chatbot framework providers do.

They introduced a low-code level 4/5 chatbot, with lacking reliable responses and fine-tuning.

A custom trained model can be tested in the Playground and a custom trained response is yielded. Using the playground makes it easier to switch between models and test different scenarios.

Fine-tuning is the avenue to a more reliable or predictable chatbot; especially for a corporate or enterprise solution.

Some Considerations:

  • Training of smaller samples of data will help with benchmarking and quick iterations.
  • Defining entities contextually within intent examples is important; I did not test this feature; as at least 500 training examples are required.
  • Having different trained models to manage can be a challenge. Will an abstraction layer be required to determine which model is applicable in specific scenarios?

GPT-3 can be a disruptive force, once they achieve a more structured and cohesive fine-tuning approach. One which is conducive for collaboration of larger teams. At times I wonder if GPT-3 is targeting to become a NLP / general conversational tool. Or if there are ambitions to become a low-code chatbot development framework.

In accurately evaluating GPT-3’s NLU/P capability, it is prudent to keep the vision of OpenAI in mind…

Our API provides a general-purpose “text in, text out” interface, which makes it possible to apply it to virtually any language task. This is different from most other language APIs, which are designed for a single task, such as sentiment classification or named entity recognition.

The API runs models with weights from the GPT-3 family with many speed and throughput improvements.

“The medium is the message.” Marshall McLuhan

We Understand OpenAI’s End Game

Watching the official Codex launch on YouTube by OpenAI, it was clear that:

  • Codex was a natural progression from the Language API.
  • Users asked many code related questions, and the Language API performed well, and the API could be leveraged for a Code related implementation.
  • Codex is astonishing good.
Creating a timer for every 10 seconds on which the date/time updates and the color of the square changes.

There has been much discussion on Low Code versus handcrafted or traditional coding. And it is not a case of the one or the other.

There is a place and an application for both. With advantages and disadvantages.

I discuss that topic in detail here.

And the same holds true for Codex.

Will enterprise systems be built this way, most probably not. Will Fortune 500 companies go exclusively the Codex route in principle…no.

It is experience, rather than understanding, that influences behavior. Marshall McLuhan

Codex will Replace Developers

Codex will not be replacing developers; at least not in the foreseeable future.

One challenges are to understand what the problem is we are trying to solve. Especially if that problem is complex.

Secondly, the input to Codex needs to be modularized and broken down for Codex to process.

But, there are some definite niche applications for developers, these can include:

  • Solving coding challenge and problems in certain routines.
  • Establishing best practice.
  • Quality assurance.
  • Interactive Learning
  • Generating specific components for subsequent human review.

Here are a few initial observations…

  • Don’t get too creative and elaborate in your natural language description.
  • You are basically writing the algorithm out line by line in natural language.
The Codex window for JavaScript very much resembles a chatbot interface. Very much simplistic and minimalistic.
  • Everything does not have to be explicit. Implicit command are picked up amazingly well.
  • Spelling mistakes are also detected and catered for.
  • Somehow context is maintained.
  • Code can be reviewed in the side pane, manually edited and saved.
  • You can refer to functions, variables etc. from the natural language perspective.
  • Codex is ideal as a tool to automate tasks and create utilities.
  • Codex is well suited as a tool to learn what well formed looks like.

“We shape our tools and, thereafter, our tools shape us.” John Culkin (1967)

Codex Can Create Complex Implementations

Obviously with Codex there are three general approaches. The first being translating code from one computer language to another.

Codex is given three lines of Python code and an augmented natural language explanation is given.

The second is using code as an input and requesting Codex to explain it, debug it etc.

“Our technology forces us to live mythically” Marshall McLuhan

The third is to use natural language as the input for Codex to generate the code. This is obviously the harder avenue and when crafting code like this. It is evident that:

  • Problems need to be broken down into a smaller step-by-step like process.
  • I have seen Codex detect implicit coding elements, but for the most part instructions need to be explicit.
  • Codex does not do well with ambiguity; you need some coding knowledge to be able to break your problem down into sequential steps.
  • See Codex as a coding assistant. The ultimate Stack Overflow-like resource with instant answers.

Do not see it as a an software and solution orchestrator. It’s a tool to create AI-enabled developers.

But, there are some defernite niche applications, these can include:

  • Solving coding challenge and problems in certain routines.
  • Establishing best practice.
  • Quality assurance.
  • Interactive Learning
  • Generating specific components for subsequent human review.

Read more here…

Conclusion

Often, technology at its infancy and inception seems rudimentary, awkward and redundant. Invariably discussions ensue on the new tech’s viability and right to existence, comparing it to technologies steeped in history and innumerous iterations.

When thinking in terms of low-code, Codex and the language API, it is not an all or nothing scenario.

--

--

Cobus Greyling

I explore and write about all things at the intersection of AI & language; LLMs/NLP/NLU, Chat/Voicebots, CCAI. www.cobusgreyling.com