GPT-3 arrived through an API, with a business model attached
Access to GPT-3 through an API let small teams build language applications without training a large model. Commercial success still depended on evaluation, product design and the cost of a useful result.
On 11 June 2020, OpenAI introduced a private beta API that accepted text and returned a completion. It ran models from the GPT-3 family and allowed developers to request access for their applications. A small software team could investigate a language product without first building the infrastructure to train and serve a very large model.
The API placed expensive model development behind a service interface, making experimentation accessible to more teams. Reliability and commercial value still had to be established for each language task. A startup needed to identify useful work, control what reached the customer and show that the resulting service cost less than the problem it solved.
Examples became a way to specify a task
The GPT-3 paper introduced a model with 175 billion parameters and studied whether instructions in natural language and examples could specify a task without updating model weights. Its few-shot setting placed demonstrations in the input, whereas fine-tuning used a dedicated dataset to train the model further. The difference affected how much specialised data and training work an application would initially require.
The research was broad but uneven. It reported strong performance on several language tasks, including answering questions, alongside weaknesses on other datasets and concerns about overlap between training material and evaluation data. The revised paper documented both the results and their limitations. It did not establish a universal accuracy rate for the API, which served a family of models and incorporated deployment changes.
One benchmark showed why the prompt mattered
Appendix H of the paper reports accuracy on the TriviaQA development set in the closed-book setting: the largest model recorded 64.3% with no demonstrations, 68.0% with one and 71.2% with a few. The task and evaluation set remained the same while the prompt condition changed. Providing examples could improve performance without a separate weight update.
| Period or category | % accuracy |
|---|---|
| Zero-shot | |
| One-shot | |
| Few-shot |
Accuracy on the TriviaQA development set in the closed-book setting, Appendix H of Language Models are Few-Shot Learners, July 2020 revision. These research results concern the 175B model and do not establish reliability across the API or accuracy in customer service.
Source2
Those percentages were not a promise that an enterprise support product would answer seven out of ten questions correctly. Customer questions might require private information, recently changed policies or information absent from the model’s training. A useful pilot would assemble representative requests, specify acceptable answers and include cases the system should decline or hand to a person.
A commercial product needed a narrower boundary
In its September update to the launch article, OpenAI described a mandatory review before proposed applications could enter production. It considered the supported use case, how freely the application could respond and the developer's measures against misuse. Possible constraints included human review, restrictions on who could access the product, output processing and limits on the subject matter.
Those conditions affected product design and launch planning. A tool that suggested a draft for an employee to check had a different exposure from a service that published arbitrary generated text automatically. Review changed how a customer used the product, how quickly a result arrived and who remained responsible for an error.
The cost of a useful answer included correction
Serving a model through an API moved much of the infrastructure burden to the supplier. A developer still paid for engineering, request handling, monitoring, customer support and any people required to review outputs. Costs therefore needed to be measured against completed customer tasks that met an agreed standard. Counting generated responses alone would miss the work required to make them useful.
Consider a drafting tool whose output saves writing time but needs substantial factual correction. The initial demonstration might look impressive while the net time saving is modest. Measuring completion time, review effort and the consequences of missed errors would make the value proposition testable.
Microsoft's exclusive licence preserved API access
On 22 September 2020, Microsoft announced an exclusive licence to GPT-3 and said it intended to develop products and services using the model. The same announcement stated that OpenAI would continue offering GPT-3 and other models through its own API hosted on Azure. The licence gave Microsoft particular rights while preserving developers' access through OpenAI.
A startup's position depended on the service and permissions it obtained. API access conferred no ownership of model weights, and the exclusive licence did not end that access. Investors still needed to establish what the application business owned or controlled when its central model remained someone else's service.
Where the application could earn its place
A defensible product could organise a specialised workflow, connect authorised customer information, collect useful feedback and make correction straightforward. These capabilities required domain knowledge and customer relationships beyond a prompt. They also offered concrete evidence for an investor: repeat use on meaningful work, measured time savings and a delivery cost consistent with the contract.
The launch made experimentation more accessible, but commercial success depended on the application around the model. A small team could attempt work that had previously required far more infrastructure. Its demonstration still had to become a dependable service that a customer would renew.
Investment implications
- A benchmark result describes a test condition; product evaluation must use the customer’s work and error costs.
- Access to a general model leaves room for differentiation in workflow, trusted data, distribution and review.
- API availability, model licensing and permission to launch an application were separate commercial questions.
Sources
Published
