A business can hear about powerful machine-learning systems and immediately imagine a clever feature. The more useful first conversation is often less glamorous: what decision should the system help with, and how will anyone know whether its answer is right? Google’s 17 May announcement of the TensorFlow Research Cloud puts more training resources behind open research. It also makes a useful distinction between having computing power and having a problem ready to learn from.
Name the decision in ordinary language
The announced research programme offers Cloud TPU resources for computationally intensive machine-learning work. It is aimed at researchers, rather than presented as a finished business application. A retailer should not read the announcement as an off-the-shelf product classifier or assume that access to a research cluster solves its data preparation. Training infrastructure and the application a customer uses are separate parts of the work.
Picture a supplier that wants help sorting incoming product photographs. “Use AI for the catalogue” is too wide a brief. “Suggest which of these five catalogue groups this photograph belongs to, leaving uncertain cases for an editor” is testable. It defines the permitted choices, the person responsible for the result and the point at which automation should stop.
An example is only useful if its label is trustworthy
The team needs examples that represent the work it really receives. Photographs from a clean studio may differ from pictures taken in a warehouse. Labels assigned inconsistently by different staff members create a confusing lesson for a model. It is worth reviewing a small sample together before spending money on a larger experiment, because disagreement may reveal a business rule that nobody has written down.
Keep some reviewed examples outside training so that the pilot can be checked on unfamiliar material. Agree how to count a useful answer, an uncertain answer and a harmful mistake. In the supplier example, confusing two harmless browsing groups is different from publishing an incorrect safety-related classification. The business consequence should shape the review process rather than being hidden behind one average accuracy number.
Build a place for a person to disagree
An early tool should show its suggestion in a way an editor can accept or change. Record corrections with enough context to understand them later. A quiet, reviewable suggestion may be more useful than a confident automatic action, particularly while the team is still discovering the limits of its examples. The pilot should make work easier without removing responsibility for what gets published.
This month’s research announcement is encouraging, but a credible business experiment can begin much smaller than a large training job. Define the decision, review the labels and agree on an evaluation set. Only then choose the model and computing resources. That sequence gives the development team a clearer target and gives the business a way to decide whether the experiment deserves another stage.