ChatGPT made language models easier to try
A conversational research preview made language models easier to try. Turning that accessibility into a durable business still required reliable workflows, useful feedback and a reason to pay.
A blank text box changed the first encounter with a language model. When OpenAI introduced ChatGPT on 30 November 2022, users could ask a question, respond to the answer and refine a request through conversation. The launch described a free research preview intended to gather feedback about the model's strengths and weaknesses. That combination made experimentation accessible without requiring users to begin by writing an application.
That shorter path from curiosity to a useful result had commercial value. A founder could watch how someone approached a task, where the conversation failed and what information was missing. The launch did not establish that conversational software was dependable across professional work. It made that gap easier to observe, creating a much more concrete starting point for product development.
Conversation lowered the cost of expressing intent
The announcement identified further questions, acknowledgement of mistakes and challenges to incorrect premises as capabilities enabled by the dialogue format. Its examples invited readers to see a sequence of exchanges, rather than a single output. A user could add context after discovering that the first request was incomplete. This mattered because people often understand what they need more clearly after seeing an imperfect draft.
For a software company, that suggested a different onboarding problem. A product could begin with the customer's own words and help refine them into an executable task. Yet open conversation also removed constraints that ordinary forms provide. A procurement assistant still needed a supplier identity, an authorised budget and the correct delivery address. A fluent conversation could make missing inputs less visible unless the product deliberately surfaced them before action.
Human feedback shaped the model's responses
OpenAI described supervised training on conversations written by human trainers, followed by rankings of alternative answers and reinforcement learning from that feedback. It identified the model as fine-tuned from the GPT-3.5 series and linked the approach to InstructGPT. The launch combined changes to model behaviour with a new way to interact with it.
Scroll to view all columns
| Comparison | What the test can establish | What still needs checking |
|---|---|---|
| Preferred response | A reviewer favours one answer under stated criteria. | The answer may still contain an undetected factual error. |
| Correct output | The result meets an independently checked task requirement. | Producing and reviewing it may consume too much time. |
| Completed workflow | The user reaches the intended outcome within the allowed process. | Repeatability, cost and customer retention remain commercial questions. |
A preferred answer, a correct answer and a completed workflow establish different things. The InstructGPT evaluation and launch guidance explain why each needs its own checks.
The earlier InstructGPT paper helps explain the role of that feedback. Researchers found that labelers preferred outputs from a much smaller instruction-tuned model to those of a larger GPT-3 model on their prompt distribution. The paper also states that the procedure aligned behaviour with the preferences of a specific group of labelers and researchers. That result supported the value of feedback on specific tasks; it did not establish universal preference, professional competence or factual correctness for ChatGPT.
The launch limitations belonged in the business model
OpenAI explicitly warned that ChatGPT could produce plausible but incorrect answers, respond differently to small changes in phrasing and guess a user's intent instead of asking a clarifying question. Product teams needed to design around those limits. A startup using language generation in a process where errors could cause serious harm needed to decide which outputs required evidence, who would review them and how a rejected answer would return to the workflow.
Consider an assistant drafting a response to a customer complaint. It might save writing time while inventing a refund policy. The relevant measure would include time spent checking policy, correcting the draft and confirming that the final message reached the right account. A model response could be cheap while a usable resolution remained expensive. Testing on actual policy documents and representative ambiguous requests would provide more useful evidence than a collection of impressive, selected conversations.
Domain knowledge had to become a product asset
A conversational feature was easier to demonstrate than a defensible enterprise product. A startup's stronger position could come from authorised access to a customer's information, the ability to preserve permissions and a clear process for resolving uncertainty. In a technical support product, for example, the value might lie in identifying the correct equipment revision and retrieving an approved repair procedure before drafting an explanation.
That work required careful treatment of customer data and a usable feedback path. A negative rating alone would not explain whether an answer used an obsolete document, misunderstood the user or exceeded the user's authority. Capturing the reason for correction could guide product improvements. Permission to store and reuse those examples also needed to be established. Proprietary feedback was only an asset if it was lawful to use and informative enough to improve a recurring task.
Early usage was a starting point for commercial evidence
Free research access allowed people to explore capabilities without demonstrating a willingness to pay. A venture case still needed a buyer, a recurring problem and a cost structure that worked when usage grew. The first useful test was whether users returned to complete the same class of work and trusted the result after appropriate checking. The next was whether a budget owner valued that improvement enough to fund deployment and support.
A trial had to use the capabilities and service terms available at launch, without relying on future enterprise features or model improvements. An application builder could set explicit criteria for a bounded trial and assess the complete workflow. The product question was straightforward: could conversational access remove enough effort from a real process to justify the integration, review and operating costs around it?
Investment implications
- A conversational interface reduces the effort of trying a model; dependable completion requires additional product work.
- Measure the cost of a checked, usable result, including correction and review.
Sources
Published
