A Price Ceiling Cuts the Set and Leaves the Order Semantic
premium floor lamp with price < 300: four of the top five are removed, and the survivors stay in similarity order. The cheapest lamp in the filtered set lands last, at $38.

A numeric filter sets a boundary on the candidate set. Everything inside the boundary is still ranked by similarity to the query, exactly as it would have been without the filter.
The diagram runs premium floor lamp against a 118 image index twice. The second call adds one line, a filter for price under 300. Four of the original top five are removed. The one survivor, a 299 dollar lamp, moves to first place because it was the best remaining match, and four lamps from deeper in the ranking fill in behind it at 230, 104, 129 and 38 dollars. The 38 dollar lamp is the cheapest item in the set and it is last.
That ordering is correct and it is also the part teams get wrong in the interface. If the page says under 300 dollars and the layout reads as best value first, users will read the sort as a price sort. Nobody files that as a bug. They quietly stop trusting the order. If you want cheapest first, sort the filtered set by price as a separate step, and say so on the page.
The word premium is doing something too. The embedding model understands it as a visual quality and matched on how expensive the lamps look. The filter understands only the number. Both ran on the same request.
The filter syntax that worked here is a nested operator, price with lt 300. The API also warned that price had no payload index on this collection, so declare one on any numeric field you filter routinely.
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. Prices 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

