In short
A large list of tags does not have to be sent to the model in full with a request to pick the right ones. There is a sturdier approach: first let the LLM invent a meaningful label, then find its nearest match in the existing database.
The problem is not that an LLM cannot choose tags. The problem is scale: when a blog has 1,856 labels, passing the whole vocabulary in one request becomes awkward and unreliable. The model may lose some of the options or start choosing too randomly.
Simon Willison describes a different move, proposed by Doug Turnbull: do not make the model classify text against a closed list. Let it first suggest a new, "imagined" label — in plain language and without having to match an existing name exactly.
That label is then turned into a vector representation — a set of numbers describing its meaning. From it you can find the closest tags in your existing database. For a query about a brown coffee table, for instance, the model may invent an intelligible category, and an embeddings search will map it to a specific branch of the catalogue such as Coffee Tables.
And that is the unexpected gain: the LLM is used not as a reference book obliged to remember the whole catalogue but as a generator of a good semantic query to the catalogue. That is especially handy for old material that accumulated without labels: the model helps identify the topic, while the final name comes from your own tagging system.
But nobody promises automatic accuracy here. The model may invent a label that is too vague or odd, and the vector search may pick the nearest yet still wrong tag. So the pipeline is better treated as a way to cut manual work sharply than as a substitute for reviewing contested cases.
If you had to choose between a precise closed list of 1,856 tags and a free hypothesis followed by a match search, which approach would you trust with your project's archive? Source: Simon Willison's Weblog