NEWVectors or files. Pick a path.Start →
    Back to DiagramsRetrieval Mechanics

    Filters Exclude What Ranking Would Have Shown

    Same query, same embeddings, one filter. Three of the top five yellow armchairs were out of stock; the in_stock pre_filter removed all three from the response and three deeper matches moved up.

    A portrait diagram in two rails. The headline reads Filters exclude, what ranking would have shown, with the subline: a pre_filter drops rows before ranking is ever shown to you, useful, and it hides what it removed. A search bar holds the query yellow armchair, annotated: three of the top five are out of stock. Rail A, badged no filter, shows five armchair photos in rank order with prices and scores: 872 dollars at 0.080, 515 dollars at 0.065, 180 dollars at 0.060, 451 dollars at 0.060 and 506 dollars at 0.057; the second, third and fourth are greyed and stamped dropped, and the count chip reads 5 of 5. Rail B, badged pre_filter with in_stock equals true, shows the two survivors at 872 and 506 dollars followed by three new armchairs at 123 dollars 0.048, 446 dollars 0.047 and 606 dollars 0.046; its chip reads 2 kept plus 3 new. A bold line states that three of the top five were out of stock and all three were removed from the response entirely. A dark code window shows the execute request with the filters line in_stock true highlighted, and skip_cache true. The footer prints mxp.co/d/filters-exclude and the words real query, real ranking, mixpeek.
    Same query, same embeddings, one filter. Three of the top five yellow armchairs were out of stock; the in_stock pre_filter removed all three from the response and three deeper matches moved up.

    A pre_filter removes rows from the response before the ranking reaches you. The diagram runs the query yellow armchair twice against a 118 image index with SigLIP image embeddings. The only difference between the two calls is one filters line.

    Without the filter, the top five are ranked purely by similarity, and three of them are out of stock. With in_stock set to true, those three are gone. Two rows survive in their original positions and three items from deeper in the ranking move up to fill the rail.

    The removed rows leave no trace in the response. A caller reading the filtered result sees five in-stock armchairs and has no signal that better visual matches existed. That is the trade a pre_filter makes, and it is the right trade when the user should never see the excluded item at all: out of stock, wrong region, no permission.

    The alternative is to keep every match and rank the failing ones lower, which is a different decision with different failure modes. A demoted item still occupies a slot and still shows the user something they cannot buy. An excluded item is invisible and so is the reason it vanished. Pick one on purpose, and if your users report that a product they know you carry never appears in search, check the filter before the embeddings.

    One more thing the run surfaced. The API warned that in_stock had no payload index, so filtering on it may be slow on a large collection. Declare a keyword payload index on any field you filter routinely.

    What is real here: the photos are Pexels images with every photographer credited, the embeddings and queries ran against the live API, and the order is exactly what came back with the cache skipped on both calls. The prices and stock flags 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

    Related diagrams

    A portrait diagram in two rails. The headline reads Scope decides, what can be found at all, with the subline: the same question, asked of the whole catalog and then of one category. The search bar holds the query something to keep me warm outside, annotated: the query names no category. Rail A, badged whole catalog with the note semantic reach across every category, shows five photos in rank order: a lit tent at night for 543 dollars at 0.062, a snowy forest scene for 564 dollars at 0.060, a steaming pot on a stove for 444 dollars at 0.059, boots on a textured rug for 203 dollars at 0.052, and a tent under a starry sky for 100 dollars at 0.048; the second, third and fourth are greyed and stamped dropped, and the chip reads 5 of 5. Rail B, badged scoped with category equals tent and the note only one category can answer, shows the two surviving tents followed by three more tents at 592 dollars 0.046, 73 dollars 0.039 and 554 dollars 0.029; its chip reads 2 kept plus 3 new. A bold line states that unscoped, the index answered with tents, backpacks, rugs and pans, and that scope is a decision about what is allowed to be right. A code window shows the execute request with the filters line category tent highlighted. The footer prints mxp.co/d/scope-changes-candidates.

    Scope Decides What Can Be Found at All

    A portrait diagram in two rails. The headline reads A price ceiling, is not a price sort, with the subline: a price ceiling removes the expensive matches, it does not promote the cheap ones by price. The search bar holds the query premium floor lamp, annotated: premium is a word, not a number. Rail A, badged no ceiling with the note best matches, any price, shows five photos in rank order: floor lamps at 729 dollars 0.097, 299 dollars 0.093, 908 dollars 0.092 and 322 dollars 0.089, then an armchair at 451 dollars 0.086; four are greyed and stamped dropped, only the 299 dollar lamp survives, and the chip reads 5 of 5. Rail B, badged pre_filter with price less than 300 and the note best matches under the ceiling, shows the 299 dollar lamp first at 0.093, then lamps at 230 dollars 0.071, 104 dollars 0.068, 129 dollars 0.063 and 38 dollars 0.059; its chip reads 1 kept plus 4 new. A bold line states that rank order inside the filter is still semantic, so the cheapest item lands fourth. A code window shows the execute request with the filters line price lt 300 highlighted. The footer prints mxp.co/d/numeric-filter-reranks.

    A Price Ceiling Cuts the Set and Leaves the Order Semantic

    A portrait diagram in two rails. The headline reads One index, two ways to ask, with the subline: one index, one collection, two query modalities, the answers disagree. The search bar holds worn leather armchair, annotated: same corpus, same embeddings. Rail A, badged text query with the note text query against image embeddings, shows five leather armchair photos in rank order at 496 dollars 0.114, 938 dollars 0.106, 489 dollars 0.103, 606 dollars 0.097 and 872 dollars 0.085, chip 5 of 5. Rail B, badged image query with input_mode equals content and the note an image as the query itself, shows five different photos: a white wooden armchair at 446 dollars scoring 1.000, an armchair draped with a blanket at 180 dollars 0.865, a grey chair among plants at 205 dollars 0.834, a pink sofa beside a floor lamp at 104 dollars 0.824, and a grey wooden armchair at 924 dollars 0.824; its chip reads a different five. A bold line states that the image query scores 1.0 on itself, then returns a floor lamp among the armchairs, and that visual similarity answers with pixels while your taxonomy is nowhere in the embedding. A code window shows the execute request with two highlighted input lines, query worn leather armchair for rail A and image_url pointing at a Pexels photo for rail B. The footer prints mxp.co/d/text-vs-image-query.

    One Index, Two Ways to Ask: Text Query and Image Query Disagree