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

    Your Nylon Audit Needs the Backpacks Too: One Edge Hop Inside the Retriever

    "nylon camping tent" over 118 product images returns five tents, and three of them are polyester or canvas. One traverse_edge hop along a customer-owned same_material edge adds the seven nylon hiking backpacks that no image embedding would rank near a tent.

    A portrait diagram. The headline reads Your nylon audit needs the backpacks too, with the subline that semantic search matches what a thing looks like, three of these five tents are polyester or canvas, and material is a fact the customer owns, so it lives on a typed edge that one hop follows. The query is nylon camping tent. A feature_search band shows the top five results, two of five nylon: two Nylon Camping Tents, two Polyester Camping Tents and one Canvas Camping Tent, each with its SKU. A traverse_edge band follows same_material from each hit and adds seven Nylon Hiking Backpacks with their SKUs, marked plus seven nylon. A footer shows the edge written on the object, with type same_material and attributes material nylon and target_category backpack, and the stage config with edge_type same_material, direction out, include_source true and max_per_source 7.
    "nylon camping tent" over 118 product images returns five tents, and three of them are polyester or canvas. One traverse_edge hop along a customer-owned same_material edge adds the seven nylon hiking backpacks that no image embedding would rank near a tent.

    Search 118 product images for nylon camping tent and semantic similarity does what it is built to do: it returns five things that look like camping tents. Two are nylon. Three are polyester or canvas. For a supplier recall that needs every nylon item in the catalog, the result is wrong in both directions. It hands you three items of the wrong material, and it never shows the seven nylon hiking backpacks sitting in the same catalog, because no image embedding ranks a backpack near a tent.

    Material is a fact the customer already owns, so it belongs on an edge, where facts go. Mixpeek objects carry a root-level edges array of typed, directed, attributed relationships in the customer's own vocabulary. For this run, 98 same_material edges were written across the 14 nylon objects, linking every nylon tent to every nylon backpack and back.

    The traverse_edge stage then follows those edges inside the retriever. Five hits went into the stage and seven nylon backpacks came out, and the stage never looked at a pixel. Vector search finds the candidates, the edge hop expands them along a relationship the customer defined, and the whole thing is one retriever definition and one call. There is no second system to run and no graph database to keep in sync.

    Two notes worth carrying with the picture. Edges are read off documents, and the batch writer copies them from the object at extraction time, so edges written onto an already-extracted corpus stay inert until you re-extract. Scope that re-extraction to the linked objects, or you will pay for GPU embedding across the whole collection again. And this catalog is synthetic: its generator assigns material independently of the product, which is how a first build on steel produced rows titled Steel Cast Iron Pan. The diagram was rebuilt on nylon, where tent and backpack are both credibly nylon, so the numbers on it hold.

    Everything on the diagram traces to one run on 2026-09-06 against the demo namespace, with the rows generated from the saved response.

    Where this diagram appears

    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 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.

    Filters Exclude What Ranking Would Have Shown

    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