Interesting technique, but even if you're getting rid of hallucinations it seems there's still no guarantee of consistent classifications. If you need to do a semantic (embedding) search anyways, then how does this really help?
Don't classify, hallucinate
51–60 of 118 posts
Re: Don't classify, hallucinate
#52A common case I have is when you don't have classifications to begin with. For example, you need to find what users complain about most. I take embeddings of all records, then cluster the embeddings into semantic groups, then ask an LLM to take a random sample from each clustered group and create a classification for that group.
This method is sensitive to the thresholds (what is the maximum distance between embeddings for them to be still considered part of the same semantic group), so I run it all in an agentic loop where an agent tries different thresholds and clustering algorithms until it's satisfied with the result, plus it may deduplicate some groups.
I run it all on self-hosted hardware, so it costs nothing to leave it running for, like, a night, and as a bonus, none of the corporate data leaves the office. I think a rigid set of manually created classifications may not capture all the possible classifications that can exist. Needs a review by a human, though.
Re: Don't classify, hallucinate
#53No? This is just giving up and hoping.
Is there a solution you are using to solve this that is more accurate and cost effective? I'm working through it now so would be curious
Re: Don't classify, hallucinate
#54Nice trick. Couldn't you embed the query though, compare it to the embedding of the categories, then ship only categories that are close to it in the prompt to a smaller model?
Agreed that you almost certainly can just embed the original with most modern embedding models.
Re: Don't classify, hallucinate
#55> 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?…
Yes what you're describing is a classic way of doing query understanding.
I've found, though, getting it in the language of the vocabulary has generally improved performance.
Further, when searching for "blue shoes" you want to separate the color from the item type. So its useful to have a dumb LLM do this for you. And with the LLM in the loop, its further useful to get it into the language of the taxonomy to improve embedding retrieval accuracy.
There are of course many ways to skin the cat here :)
Re: Don't classify, hallucinate
#56Re: Don't classify, hallucinate
#57A common case I have is when you don't have classifications to begin with. For example, you need to find what users complain about most. I take embeddings of all records, then cluster the embeddings into semantic groups, then ask an LLM to take a random sample from each clustered group and create a classification for that group. This method is sensitive to the thresholds (what is the maximum distance between embeddin…
I worked on spam classification for litigation targeting in the early days of CANSPAM [0] enforcement.
We had a similar problem where you can literally millions of email that we were pretty sure came from only a limited set of bad actors.
We first started classifying emails into buckets by From, mailserver relay chains etc as that's all we had to to go on.
Over time, those buckets got linked to spammer signatures and then we narrowed down from there.
Fascinating to see this happening nowadays with LLMs.
Re: Don't classify, hallucinate
#58Smart trick, but assumes the “dumb” llm is smart enough not to derail into an article about the lives of South American red ants. Obvious exaggeration, the point being outcomes should stay strictly within topic, avoid unrelated bloat and hit the target.
If you use structured outputs they’ll usually stick to the program. Not to completely constrain the categories like TFA was saying, but something like
{ rationale, categories }
Luna is surprising capable and cheap, and I haven’t done this type of thing since before GPT 5 so might not be such a useful trick now
Re: Don't classify, hallucinate
#59Nice trick. Couldn't you embed the query though, compare it to the embedding of the categories, then ship only categories that are close to it in the prompt to a smaller model?
Yes absolutely that's another good trick.
Even better is to search the corpus first with like naive BM25 / embedding search, aggregate over top N to get most representative categories, then have the LLM categorize in that set.
Re: Don't classify, hallucinate
#60I wonder how more accurate this is compared to just doing embedding similarity of the query vector and the category labels