Scope Decides What Can Be Found at All
Asked of the whole catalog, "something to keep me warm outside" returned a tent, a backpack, a cast iron pan, a rug and another tent. Scoped to category = tent, only tents can answer, and the ranking inside the scope is unchanged.

The query names no category. Something to keep me warm outside is a need, and a 118 image index answered it with a tent, a hiking backpack, a cast iron pan, a jute rug and a second tent. Every one of those is a defensible answer to the question as asked.
Scoped to category equals tent, only tents are allowed to answer. The two tents from the unscoped rail keep their positions and three more tents fill the remaining slots, in the same similarity order they held before.
Embeddings have no idea your taxonomy exists. Semantic search crosses category boundaries freely, which is the behaviour you want when a user asks a question your departments never anticipated, and the behaviour you have to constrain when the user believes they are browsing one department. The same index does both. Scope is the switch.
The decision to scope is usually made once, early, by whoever wired the retriever, and then forgotten. It is worth revisiting with a query like this one in hand, because the unscoped rail shows what your users would have been offered and the scoped rail shows what your category tree decided they could see.
The filter is one line in the execute request. The API also warned that category had no payload index on this collection, so declare a keyword index on any field you scope by.
What is real here: the photos are Pexels images with every photographer credited, the embeddings and ranking came from the live API with the cache skipped on both calls, and the order is untouched. Category, price and stock are demo catalog data generated for this corpus.
Run this on your own data
Mixpeek turns video, images, audio, and documents in your object storage into searchable, timestamped results through one API.
Search your own data

