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

    The Query Is the Biggest Knob

    "chair" and "worn leather armchair, bright room" against the same 118 image index, same retriever, no filters. Zero overlap between the two top fives. Nothing in the configuration changed.

    A portrait diagram in two rails. The headline reads The query is, the biggest knob, with the subline: no configuration changed between these two rails, only the sentence did. The search bar holds the word chair, annotated: nothing else was changed. Rail A, badged broad with the note one word, shows five modern chairs in rank order at 872 dollars 0.098, 515 dollars 0.089, 924 dollars 0.088, 180 dollars 0.087 and 446 dollars 0.087, chip 5 of 5. Rail B, badged specific with the query worn leather armchair, bright room and the note a described scene, shows five different photos: worn leather armchairs at 496 dollars 0.072, 938 dollars 0.071 and 489 dollars 0.069, a red velvet armchair in a bright interior at 451 dollars 0.067, and a dark textured armchair at 606 dollars 0.063; its chip reads a different five. A bold line states that your biggest retrieval knob is the query itself. A code window shows the execute request with two highlighted inputs lines, query chair for A and query worn leather armchair, bright room for B, then filters null and skip_cache true. The footer prints mxp.co/d/query-specificity.
    "chair" and "worn leather armchair, bright room" against the same 118 image index, same retriever, no filters. Zero overlap between the two top fives. Nothing in the configuration changed.

    Two searches against the same 118 image index. Same retriever, same embeddings, same filters, which is to say none. The one word query chair returns generic modern chairs. The described scene, worn leather armchair, bright room, returns worn leather armchairs in bright rooms.

    Zero items overlap between the two top fives.

    Most retrieval tuning happens downstream of the query: top_k, fusion weights, rerankers, filters. All of those matter, and none of them moved here. The largest change in results came from the sentence the index was asked to match.

    The practical reading is that the cheapest improvement available to most search products is a longer query. Help users write one, with suggestions or a describe what you want prompt, or write a better one on their behalf before it reaches the index. Query expansion, rewriting and hypothetical document embeddings are all ways of doing the second thing automatically.

    The scores tell a second story. The broad query scores higher, 0.087 to 0.098, than the specific one, 0.063 to 0.072, because a one word query is close to many images and a described scene is close to few. A higher score means more of the corpus looks like the query. Which query produced the result the user wanted is a separate question, and clicks answer it.

    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