Machine learning

Machine learning is the practice of deriving a rule from data rather than writing it. Google's own machine learning course puts it as "a way to train software, called a model, to make predictions or generate content using data", and defines the model itself as "a mathematical relationship derived from data that an ML system uses to make predictions". The distinguishing property is not that the software is clever; it is that nobody wrote the rule down, and so nobody can point at the line that produced a given output.

Google's glossary places the field precisely: "machine learning is a sub-field of artificial intelligence". Everything an AI search system does to your content — deciding what a page is about, ranking a passage against a query, writing a summary of you — is a machine-learned model doing it.

The four kinds, and which one is reading you

Google's introduction to machine learning names four system types:

• Supervised learning. Models "make predictions after seeing lots of data with the correct answers and then discovering the connections between the elements in the data that produce the correct answers." Classifiers and rankers live here.
• Unsupervised learning. A model that "aims to identify meaningful patterns in a dataset", typically by clustering similar items without being told the categories.
• Reinforcement learning. Models learn "by getting rewards or penalties based on actions performed within an environment", producing a policy — the strategy that earns the most reward.
• Generative AI. "A class of models that creates content from user input", emitting text, images, audio or video.

The system that writes an answer about your brand is generative, but it is rarely generative alone. A retrieval step ranks candidate passages with a learned similarity model built on embeddings, and the generator writes from whichever passages that ranker selected. Two learned components, two independent failure modes.

Why the mechanism matters to a publisher

Because it explains which errors you can fix and which you cannot.

A machine-learned parameter is not a record. There is no row holding "this company was founded in 2019" that can be corrected; the claim, if the model produces it from memory, is a residue of training data distributed across weights. You cannot edit it, and the schedule on which it might be retrained is not yours.

What you can change is what the system reads at answer time. When an answer is grounded in fetched documents, the passage that produced the sentence exists as a document, can be cited, and can be rewritten by you today. That is the whole reason retrieval matters more to a publisher than model choice does.

The scale of the reading budget does not remove the selection problem. Anthropic documents a 1M-token context window on several current Claude models while stating that as token count grows "accuracy and recall degrade, a phenomenon known as context rot". A large window is still a finite one facing an unbounded corpus, so something learned still chooses which of your paragraphs gets in.

Where the architecture came from

Nearly every current language model descends from one 2017 paper, Attention Is All You Need, which introduced the Transformer — an architecture relying entirely on attention, with no recurrence. It reported 28.4 BLEU on the WMT 2014 English-to-German translation task, and on English-to-French a new single-model state-of-the-art of 41.8 BLEU after training that model for 3.5 days on eight GPUs, and noted that the models were more parallelisable and cheaper to train than the recurrent systems they replaced.

The relevant inheritance is not the score. It is that the architecture scales with data and compute, which is why the systems reading the web today were trained on the web, and why what you publish is simultaneously a candidate for retrieval and a candidate for the next training corpus. Those are separate decisions with separate controls; see AI training data.

Failure modes worth naming

• Treating a generated sentence as a lookup. Generation samples from a distribution. It is capable of producing a fluent, specific, wrong fact with no internal signal that anything went wrong.
• Treating one answer as a measurement. Outputs vary run to run, and the retrieved set varies with them. Anything you act on should come from repeated prompts, not one screenshot.
• Assuming similarity means relevance. A learned ranker matches paraphrase well and exact identifiers poorly, so a part number or a version string can be missed while a topically adjacent passage is returned instead. See semantic search.
• Blaming the generator for a retrieval failure. They look identical from outside: a confident summary with a link under it. Only one of the two is something a publisher can influence by editing a page.
• Expecting a correction to propagate. Fixing the source page changes the next grounded answer. It does not change what the weights already encode, and no support request makes it.

What to do about it

Write so that a learned selector can pick a correct passage out of your page in isolation: one subject per section, the claim in the heading, and the qualifier in the same sentence as the claim it qualifies. Keep identifiers literal so a lexical matcher can find them. Make the page cheap to fetch, because a passage that is never retrieved is never ranked. And measure over repeated prompts, because the thing you are measuring is a distribution, not a value.