Add source-diverse AI rerank candidate pool

[Mbeaulne]

Description

The AI rerank candidate pool now uses a source-diverse selection strategy instead of relying purely on lexical hits. Previously, the candidate pool was capped at 50 results drawn entirely from lexical matches, falling back to a plain alphabetical slice when no matches were found. This meant components from underrepresented sources (e.g. user uploads) could be crowded out entirely when a query produced many strong lexical hits from a single source.

The new approach builds the candidate pool in three layers:

1. Up to 60 of the strongest lexical hits for the query
2. An evenly-sampled set of up to 8 candidates per source (source-diverse browse)
3. An evenly-sampled alphabetical slice of the full index to fill remaining slots up to the new cap of 80

The rerank base is now always set to aiCandidateMatches rather than switching between lexical and AI candidate lists depending on whether lexical results existed.

Related Issue and Pull requests

Type of Change

• Bug fix
• New feature
• Improvement
• Cleanup/Refactor
• Breaking change
• Documentation update

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

Test Instructions

1. Open the component search panel in the editor.
2. Enter a query that matches many components from a single source (e.g. a library with 100+ entries).
3. Click the AI rerank button and verify that components from other sources (e.g. user-uploaded files) still appear in the ranked results.
4. Verify that the total candidate count sent to the reranker does not exceed 80.
5. Run the unit tests in componentSearchV2Logic.test.ts to confirm the new source-diversity test passes.

Additional Comments

The new sampleEvenly helper picks items at uniform intervals so that the browse sample is representative of the full sorted list rather than just the top entries.

[github-actions]

🎩 Preview

A preview build has been created at: 06-18-build_broader_ai_candidate_pools_for_component_search/f23f231

[Mbeaulne]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add AI model quick-select to app menu and injectable model config #2461
• Simplify component search result cards #2459
• Add context-aware component search suggestions #2458
• Add component discovery docs #2457
• Add component search analytics baseline #2456
• Limit dashboard component browse rendering #2454
• Add component search empty state suggestions #2453
• Decouple editor component search input #2452
• Polish component search explanations #2451
• Add compatible component suggestions #2450
• Add component collection search results #2449
• Add component lifecycle badges #2448
• Add component search URL state #2447
• Disable AI search when literal search finds no matches #2444
• Debounce component search input #2433
• add client-side embeddings cached in IndexedDB #2432
• Add search quality expectation tests for lexical search #2431
• Add deep AI search to rerank all components in selected sources #2430
• Add source-diverse AI rerank candidate pool #2429 👈 (View in Graphite)
• Add negative constraint parsing to lexical search #2428
• Add fuzzy/typo-tolerant matching for component name and I/O fields #2427
• Improve component search scoring relevance #2426
• Add synonym expansion to component lexical search #2425
• Normalize component search tokens for better matching #2424
• Expand component search indexing fields #2423
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camielvs]

🤖 Code review — Add source-diverse AI rerank candidate pool

Reasonable evolution of the candidate pool: top lexical hits (60) → source-diverse browse sample (8/source) → evenly-sampled whole-index fallback, deduped and capped at 80. sampleEvenly is a tidy spread, the tiered appendUniqueMatches with shared seenDigests + early cap is clean, and switching rerankBaseMatches to always be aiCandidateMatches is the right move now that rerank scores the whole pool.

Findings:

• The source-diverse browse sample is query-independent, which limits its stated purpose. The comment says it lets AI "rescue plausible matches that literal scoring missed," but buildSourceDiverseBrowseMatches ignores the query entirely — it's an even alphabetical sample per source. For any specific query, the chance that the one lexically-missed-but-relevant component lands in an 8-wide even sample is low (and lower as a library grows). Its concrete, reliable effect is "guarantee each source has some representation + fill the pool to 80." If recall-on-missed-matches is the actual goal, query-aware per-source sampling (e.g. each source's top-k lexical hits, even if below the global cutoff) would spend the token budget far more effectively. Worth clarifying which goal this serves.

• Cost + post-rerank list length both grow. Confirmed via the hook: displayedMatches = rerankedMatches(rerankData, rerankBaseMatches) and rerankBaseMatches is now the 80-item pool, with all 80 mapped to candidates and sent with scoreAllCandidates: true (max_output_tokens ≈ count × 100 ≈ 8k). So every rerank now scores 80 candidates regardless of how focused the query is, and rerankedMatches keeps even the ≤-threshold browse fillers (pushed to the bottom, unbadged, but still rendered) — the displayed list can jump from ~50 to ~80 after a rerank click. Both are probably acceptable (user-initiated), but consider slicing the displayed post-rerank list back to a sane cap so the tail of near-zero browse samples doesn't pad the results.

• Perf nit: bySource.set(key, [...(bySource.get(key) ?? []), entry]) rebuilds the array on every entry → O(n²) over the index. Push into a mutable array ((bySource.get(key) ?? init).push(entry)), which matters more here than in the existing buildResultFolders idiom since the full index can be large.

• Test coverage is thin for the new tiering. One test covers the 80-cap + user-source inclusion. sampleEvenly and the 3-tier dedup/fill interplay (e.g. lexical returns < 60, browse + whole-index fill the rest without duplicates) aren't directly exercised. A targeted test there would lock the behavior.