> In the notebook, I compute a MiniLM embedding of every real Wayfair classification. I compute the embedding of the fake, hypothetical embedding from the LLM. I then dot product the fake embedding into the real ones to find the most similar. Producing: [the right answer]

Isn't this begging the question that the hallucinated classification will be more selective with respect to the real schema than the query itself? What would the dot product of <E(search query), E(schema)> have given?

Even if that is too vague, smaller LLMs are capable rerankers; return the top N matching true categories and ask for a contextual ordering.

This is basically HyDE (Hypothetical Document Embeddings), no? I had tried this approach in the past, worked with limited success.

Just this week I tried doing something similar with a nasty vibe-coded codebase I was trying to organize. I had Gemini Flash 3.6 classify each function/method in a similar way, giving a few plausible classifications for each (one agent per method).

It didn't end up being very useful - I ran a comparison where I just had a bigger agent do the organization in a more straightforward way, and that had better results.

I did find that Flash 3.6 High was >9x faster than Luna xhigh for this task, and got very similar results, though.

I would propose the following, query vector store for 10 closest categories based on a query, feed it to an LLM, in the prompt ask it to produce a single digit 0-9 representing the number of the most appropriate choice. Use plain text prompt, dont inflate token count with JSON. There you go, you just drastically reduced the output pricing.

Additionally you could experiment with a reranker instead of an LLM or after reranking take top-3 results and then feed to LLM as input in order to reduce input token costs.

Did you validate this by running a A/B test? Main question is were you able to classify back into your known categories correctly all the time, or did the errors compound from the llm hallucination plus embedding search

Had stumbled on this library in the past

https://github.com/aurelio-labs/semantic-router

I guess it is based on the same fundamentals as well.

Smart! I've done the same trick for resolving extracted intents to selection.

But if accuracy matters, you can't rely on embedding sort to get a closet match. With a real test set they usually don't hold up under scrutiny.

Everything in AI is like this. You get an idea, try it once or twice, "LGTM" and you ship. Then it never survives contact reality.

Embedding sort gives you a better shortlist than the whole list, but you will probably want a heavier model to vet candidates.

Can anyone explain why LLMs are so bad at finding products (their webpages) with given specifications?

You'd think they would have solved it by now.

This is a really great trick, woah!

I was in a project where we sent the whole taxonomy every request, 40k tokens + one article, ”plz classify”. This was before structured outputs. It was extremely expensive and still hallucinated. Good ol’ days.

Isn't search engines quicker than calling a LLM ? It might have a huge impact between a 20ms search engine call and a 2s LLM call for the end user.

This is another riff on not embedding a full document, but doing a summarization of the document and embedding the summary for RAG. Nice usecase for high cardinality data!

Eh, maybe you should keep both paths. When LLMs eventually crawl the site to feed back to agentic shoppers, maybe they logically follow the more truncated less decorated path.

In the past, people would post advice on how to do something clever and useful yourself. Now, people post suggestions on how to talk out the side of their mouth to coax ther magic-8-ball slop generator to say something useful.

LLMs aren't architected to handle filter-style comprehensive search without setting them up with additional tools.

Asking an LLM for a list of every county in the USA for example, or every county with a population of more than 100,000 people.

Even if those county names and their populations are mixed up in their weights, the nature of next-token-prediction does not lend them to effectively answering comprehensive, detailed questions like that.

An agent system build on top of an LLM can do it, if it has access to tools which can help access eg a table of counties and then filter them with SQL or Pandas or similar.

Because that's structured data and structured data is usually hidden away from users _and_ machines. Product rarely want to be honest, unless it's B2B in a very competitive market (and even then!). So, yeah, it's not that they are bad, it's that there are few good sources of information.

(Lets ignore for now that no one seems to agree to what should be the spec sheets)

Amazon Rufus has been mildly successful for me. I think the failures I've experienced with it are mostly because the product I'm looking for doesn't exist in the catalog.

Because the data, in general, is not included in the LLM model and it needs to search/browse for external information. It cannot look indefinitely so it get the top results from lists, not "evrything".