Filter by Score

Search nodes already have a min_score field, so why does Filter by Score exist? Because min_score on a search node is decided before you see any results, and search nodes aren't the only place scores come from. Filter by Score is the post-hoc version: you run a search (or a rerank, or a combine), eyeball the result, then trim it down to just the matches that clear your bar. It's a throttle you can adjust without re-running the whole search.

The mechanism is about as simple as this pack gets: every result in a SEARCH_RESULTS object carries a similarity score, and this node keeps only the entries with score >= min_score, then caps the total at max_results. No re-embedding, no re-searching - it's a filter over the set you already have. The default min_score of 0.1 exists because with everything left in, you're usually just looking at a long tail of noise; 0.1 is a gentle floor that drops the obvious junk without touching the real matches.

Where it earns its keep:

• After Rerank Results. Reranker scores are a different scale from stage-one scores. Instead of guessing min_score on the reranker, run it, look at the scores, then filter to the cutoff that actually reads right.
• After Combine Results. A union can pull in weak matches from a loose index. One filter at the end cleans the merged set.
• Before feeding output nodes. Preview Results has max_images and Load Result Images has max_images, but neither filters - they just truncate. Filter first, then load, and you don't waste VRAM decoding near-misses.

Inputs

Required: results, min_score (0–1, default 0.1). Optional: max_results (default 100, up to 500). Output: results (SEARCH_RESULTS).

Install

Same pack install as everything else - ComfyUI Manager (search "Semantic-Search") or git clone https://github.com/EricRollei/Semantic-Search into custom_nodes, install the requirements, restart, nodes under Eric/SemanticSearch.

Where people get burned

• Setting the floor blind. Scores depend on your model, index resolution, and content - 0.3 can be a great cutoff on one library and empty on another. Run once with the floor at 0, read the actual scores, then set it.
• Confusing it with truncation. max_results caps the count; it doesn't rank or reorder. If you want the top results, the search node's top_k is the right tool. Filter by Score is for quality cuts.
• Filtering away the reranker's work. If you filtered heavily before reranking, the reranker has fewer candidates to promote. Order matters: search broad, rerank, then filter - or you'll re-learn why stage two needs room to breathe.

It's a small, honest utility node - the kind you add to a workflow once and never think about again, mostly because it quietly prevents your preview grids and image loads from being polluted by the long tail of weak matches.