Confession: for about six months, roughly 40% of every classification prompt I sent to an LLM was a list of categories. Not instructions. Not the thing being classified. Just an enum, 600-odd strings long, shipped on every single request, so the model would return a label I could actually store in a database column.<\/p>\n
It worked. It also felt stupid, and it got more expensive every time someone added a category.<\/p>\n
Then I read Doug Turnbull’s Don’t classify. Hallucinate!<\/a>, which flips the problem in a way I hadn’t considered, and which I’ve now been running in anger for a couple of weeks. Short version: stop telling the model what your categories are. Let it invent one. Then snap the invention to the closest real category using embeddings.<\/p>\n I like it. I also think it has failure modes that nobody’s talking about yet, so I’ll get to those too.<\/p>\n The standard approach to zero shot classification with an LLM is structured outputs. You define the legal values as a literal type, hand the schema to the API, and the provider constrains decoding so the model can’t return anything outside it.<\/p>\n This is correct and I’m not going to tell you it’s wrong. The output is guaranteed legal, which matters when you’re writing to a foreign key.<\/p>\n The problems are practical. Every request carries the full vocabulary, so your input token count scales with your taxonomy rather than your query. There’s an upper bound on how large a schema the provider will accept, which OpenAI documents<\/a> and which you will eventually hit. And in my experience the model reasons worse when most of its context is a wall of near-identical strings. It starts pattern matching on surface text instead of thinking about the query.<\/p>\n The trick is to remove the vocabulary entirely and ask the model to invent a plausible category, giving it a handful of examples purely to communicate the shape.<\/p>\n For “brown coffee table” a small model happily returns something like It’s also close enough to be useful, because the resolution step is a nearest neighbour lookup against embeddings of your real categories:<\/p>\n Six hundred vectors is a few megabytes of RAM and the lookup is a single matrix multiply. On my laptop it’s well under a millisecond. The expensive part, the LLM call, now carries a prompt of maybe 80 tokens instead of 4,000, and because the task got easier you can drop to a cheaper model.<\/p>\n If the shape feels familiar, it should. It’s the same move as HyDE<\/a>, the 2022 retrieval paper by Gao and colleagues: given a query, have the model write a fake document that answers it, embed the fake document, and use that embedding to retrieve real documents. The generated text is not the answer. It’s a better query vector.<\/p>\n Here the generated category isn’t the label. It’s a better query vector for finding the label.<\/p>\n I find that framing useful because it tells you where the technique’s strength comes from. You’ve changed the model’s job from “select from a list you can barely fit in context” to “write something in this format”, and generative models are much better at the second task. Simon Willison picked up the same post<\/a> and made the point that it lets you push the work down to smaller models, which is the real cost story.<\/p>\n Here’s the part I’d want to know before putting this in front of customers.<\/p>\n Nearest neighbour always returns something. There is no “none of the above” in a dot product. If a query genuinely doesn’t belong in your taxonomy, you’ll get a confident wrong label with a mediocre score rather than an error. The fix is a similarity threshold below which you return unknown, but picking that threshold requires labelled examples, which is exactly the work you were hoping to skip. I ended up hand-labelling 300 rows to find mine. It was worth it. It wasn’t free.<\/p>\n Near-duplicate leaves are the second problem. “Coffee Tables” and “End & Side Tables” live next to each other in the taxonomy and next to each other in embedding space. MiniLM does not reliably separate them, and neither did the larger encoder I tried. The structured-outputs version at least forced the model to reason about the distinction. The hallucinate-then-resolve version outsources that decision to cosine similarity, which does not know that a coffee table is low and an end table is tall.<\/p>\n The third issue is that hierarchical paths are bad embedding inputs. When you embed Fourth: general purpose encoders don’t know your jargon. If your catalogue distinguishes “sectional” from “modular sofa” and the encoder thinks they’re synonyms, no amount of prompt tuning fixes it. That’s a fine-tuning problem, or a synonym table, and it’s the same wall you eventually hit with retrieval. I went through this in more detail when I wrote about choosing between RAG and fine-tuning<\/a>.<\/p>\n And finally, multi-label. A ranked list of similarities is not a set. If a query legitimately belongs in three categories you need a cutoff rule, and now you’re tuning two thresholds instead of one.<\/p>\n Once you’ve hand-labelled those 300 rows to pick a threshold, you own something valuable, and it’s worth stopping to ask whether you still need the LLM at all.<\/p>\n You already have an encoder. You already have labelled examples. Fitting a logistic regression on top of the embeddings takes about six lines and runs in milliseconds on CPU with no API call:<\/p>\n On the two datasets where I’ve compared them properly, a linear model over embeddings beat both LLM approaches on accuracy once I had more than about 40 labelled examples per class, at roughly a thousandth of the cost. It also gives you a probability you can threshold honestly, which is the thing the nearest-neighbour approach fakes with a cosine score.<\/p>\n The catch is coverage. A trained classifier can only emit classes it saw during training, so a taxonomy with a long tail of rare categories, or one that changes weekly, is a bad fit. That’s the actual dividing line, and it’s not “LLM versus not LLM”. It’s whether you have labels and whether your label set is stable. Zero shot classification earns its name when you have neither.<\/p>\n I’ve landed on using all three in the same system: the classifier handles the head, the hallucinate-and-resolve path handles queries the classifier is unsure about, and structured outputs stay in place for the handful of decisions where a wrong label is expensive enough to justify the tokens. That’s less elegant than picking a winner. It’s also what actually works.<\/p>\n Don’t take my word or Doug’s. The comparison is cheap to run.<\/p>\n Hand-label 200 to 500 examples that look like your real traffic, including some that don’t fit anywhere. Run both approaches over them and measure top-1 accuracy, cost per thousand classifications, and p95 latency. Then measure one more thing: the share of inputs whose best similarity score falls below your threshold. That number is your canary. When someone adds a category next quarter and forgets to rebuild the index, it moves before your accuracy does.<\/p>\n My results, for a taxonomy of about 600 leaves: accuracy within two points of structured outputs, cost down by roughly 80%, and latency better mostly because the prompt shrank. If your numbers come out eight points worse, the enum was doing real work and you should keep paying for it.<\/p>\n One operational note. Rebuild the embedding index whenever the taxonomy changes, and treat it as a deploy artifact rather than something you compute lazily at runtime. I keep the encode step in the same job that syncs the category table, which means the two can’t drift. Most of my client work now involves this kind of plumbing rather than model choice, and you can see the sort of thing I mean in my portfolio<\/a>.<\/p>\n Pick the taxonomy you have with the fewest leaves. Write the two versions: the Literal enum you probably already have, and the hallucinate-plus-resolve pipeline, which is maybe forty lines including the encoder.<\/p>\n Run a hundred labelled rows through both and put the numbers in a table. That’s an afternoon, and at the end of it you’ll know whether the giant enum in your prompt is earning its tokens. Mine wasn’t.<\/p>\n","protected":false},"excerpt":{"rendered":" Instead of shipping a 600-item enum to the model, let it invent a fake category and snap it to a real one with embeddings. Cheaper, with sharper failure modes.<\/p>\n","protected":false},"author":2,"featured_media":584,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Instead of shipping a 600-item enum to the model, let it invent a fake category and snap it to a real one with embeddings. Cheaper, with sharper failure modes.","rank_math_focus_keyword":"zero shot classification","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[4],"tags":[639,221,5,11,640],"class_list":["post-585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","tag-classification","tag-embeddings","tag-llm","tag-rag","tag-search"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=585"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/585\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/584"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The giant enum I was shipping on every request<\/h2>\n
from typing import Literal\nfrom pydantic import BaseModel, Field\n\nCategory = Literal[\n "Furniture \/ Living Room Furniture \/ Coffee Tables & End Tables \/ Coffee Tables",\n "Furniture \/ Bedroom Furniture \/ Dressers & Chests",\n "Decor & Pillows \/ Decorative Pillows & Blankets \/ Throw Pillows",\n # ... 600 more\n]\n\nclass QueryClassification(BaseModel):\n category: Category = Field(description="Best category for this query")\n<\/code><\/pre>\nAsk for a category that doesn’t exist<\/h2>\n
prompt = f"""Invent a novel, never-seen-before product category that best fits\nthis search query. Categories look like:\n\nFurniture \/ Living Room Furniture \/ Coffee Tables & End Tables \/ Coffee Tables\nKitchen & Tabletop \/ Kitchen Organization \/ Food Storage & Canisters\nBaby & Kids \/ Toddler & Kids Bedroom Furniture \/ Kids Beds\n\nQuery: {query}\n"""\n<\/code><\/pre>\nFurniture \/ Living Room \/ Tables \/ Coffee<\/code>. That category does not exist in the taxonomy. It’s wrong.<\/p>\nimport numpy as np\nfrom sentence_transformers import SentenceTransformer\n\nencoder = SentenceTransformer("all-MiniLM-L6-v2")\n\nreal = load_taxonomy() # ~600 strings\nreal_vecs = encoder.encode(real, normalize_embeddings=True)\n\ndef resolve(guess: str, k: int = 3):\n v = encoder.encode([guess], normalize_embeddings=True)[0]\n scores = real_vecs @ v # cosine, vectors are normalised\n top = np.argsort(-scores)[:k]\n return [(real[i], float(scores[i])) for i in top]\n\nresolve("Furniture \/ Living Room \/ Tables \/ Coffee")\n# [('Furniture \/ Living Room Furniture \/ Coffee Tables & End Tables \/ Coffee Tables', 0.88),\n# ('Furniture \/ Living Room Furniture \/ Coffee Tables & End Tables \/ End & Side Tables', 0.79),\n# ('Furniture \/ Office Furniture \/ Desks', 0.44)]\n<\/code><\/pre>\nThis is HyDE with the labels swapped in<\/h2>\n
Where it quietly goes wrong<\/h2>\n
Furniture \/ Living Room Furniture \/ Coffee Tables & End Tables \/ Coffee Tables<\/code>, the word “Furniture” appears three times and dominates the vector. Everything under Furniture looks like everything else under Furniture. I got a measurable improvement by embedding only the leaf plus its immediate parent, and a further one by scoring the path segments separately and combining them. Neither is in the original post; both took an afternoon.<\/p>\nThe option nobody in this thread mentions<\/h2>\n
from sklearn.linear_model import LogisticRegression\n\nX = encoder.encode(train_queries, normalize_embeddings=True)\nclf = LogisticRegression(max_iter=2000).fit(X, train_labels)\n\nclf.predict(encoder.encode(["brown coffee table"], normalize_embeddings=True))\nclf.predict_proba(...).max() # an actual calibrated confidence, for free\n<\/code><\/pre>\nHow I’d test it before trusting it<\/h2>\n
Try it on your smallest taxonomy this week<\/h2>\n