Skip to content

fix(search): separate channel candidate retrieval limit before fusion… - #146

Open
ayan-waqas wants to merge 1 commit into
grayhatdevelopers:mainfrom
ayan-waqas:fix/issue-88-candidate-limit
Open

fix(search): separate channel candidate retrieval limit before fusion…#146
ayan-waqas wants to merge 1 commit into
grayhatdevelopers:mainfrom
ayan-waqas:fix/issue-88-candidate-limit

Conversation

@ayan-waqas

Copy link
Copy Markdown

Related issue

Closes #88

Summary

  • Introduced resolve_candidate_limit(top_k) in src/vidxp/search_fusion.py to calculate internal retrieval limits for candidate pools per search channel (bounded between 50 and 500 candidates).
  • Updated VidXPApplication.search() and VidXPApplication.query_video() in src/vidxp/application.py to use candidate_limit when fetching channel candidates, while returning command.top_k final fused moments to callers.
  • Internal-only search retrieval change; preserves existing CLI, API, and MCP parameter definitions (top_k) and response schemas without breaking compatibility.

Validation

  • Added and executed unit tests for resolve_candidate_limit bounds and candidate expansion in tests/test_search_fusion.py:
    • Verified resolve_candidate_limit(3) returns 50, resolve_candidate_limit(200) returns 500, and 0/negative inputs remain un-expanded.
    • Verified regression case where a moment ranked 3rd in two individual channels (outside top_k=2) is retrieved in candidate pools and wins docs/open source v1 #1 in fused results.
  • Added and executed Application.search candidate limit verification in tests/test_application.py:
    • Verified underlying capability search handler receives candidate limit (50) for channel search when top_k=3 is requested.
  • Executed test suite via .venv/bin/pytest tests/test_search_fusion.py tests/test_application.py tests/test_query_service.py:
    • 47 passed in 2.80s.

@SaadBazaz

Copy link
Copy Markdown
Member

Hey @ayan-waqas,
Thanks for the Pull Request.
As a starter, we require all contributors to "star" and "fork" the repo, in order to determine if there really is a human behind the wheel or an autonomous agent.
Please star the repo for our review to proceed.
Thanks!

@ayan-waqas

Copy link
Copy Markdown
Author

@SaadBazaz I have starred the repo , kindly review the PR now.
Thanks!

@tulayha tulayha left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of small cleanup items for the next revision:

  • Please run the formatter across all four changed files; a few stray blank lines were introduced.
  • The public commands already reject zero and negative top_k, so returning those invalid values unchanged gives resolve_candidate_limit() a confusing contract. Please either reject them here or rely on the existing command validation and remove that branch and its tests.

Could you also leave a quick comment on #88 confirming that you’re continuing with this work? That will let me assign the issue to you and keep the issue and PR ownership clear.

Comment thread src/vidxp/search_fusion.py Outdated
"""Determine the internal per-channel retrieval limit for candidate pool before fusion."""
if top_k <= 0:
return top_k
return min(max(top_k * multiplier, min_candidates), max_candidates)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The candidate limit should not be derived from the public top_k. These represent different concerns: top_k is the final result count, while candidate depth is an internal recall and cost budget. A multiplier assumes ranking depth scales consistently across modalities and models, which we have not established and which #76 is intended to measure. Please use an independent, bounded candidate-depth setting for now, ensure it cannot fall below top_k, and treat its value as provisional until the evaluation work gives us evidence for the final default.

Comment thread src/vidxp/application.py
query=step.query,
media_id=command.media_id,
top_k=command.top_k,
top_k=candidate_limit,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a test for this path as well? The issue covers both regular search and video queries, but the new application test only exercises search(). Please confirm that video moment searches receive the expanded candidate limit while the final fused result still respects the requested top_k.

self.assertEqual(resolve_candidate_limit(0), 0)
self.assertEqual(resolve_candidate_limit(-1), -1)

def test_fusion_recovers_top_result_when_candidates_extend_beyond_final_top_k(self):

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This verifies fusion after the additional candidate has already been supplied, but it does not reproduce the original retrieval problem—the previous fusion code would also pass with these inputs. Could the regression go through application.search() with two modalities so it proves that candidates beyond the public top_k are retrieved, fused, and then trimmed back to the requested result count?

@ayan-waqas

Copy link
Copy Markdown
Author

Yes , sure!

@ayan-waqas
ayan-waqas force-pushed the fix/issue-88-candidate-limit branch from 98f7a56 to 9dfa734 Compare September 7, 2026 21:34
…grayhatdevelopers#88)

- Introduce resolve_candidate_limit() with independent candidate_depth budget (default 50, max 500)
- Add search_candidate_depth setting to VidXPSettings
- Update Application.search() and Application.query_video() to use candidate limits for channel queries while returning top_k final fused moments
- Add unit tests for candidate depth resolution and non-positive input validation
- Add query_video candidate depth verification and application.search regression test for candidates retrieved past public top_k
@ayan-waqas
ayan-waqas force-pushed the fix/issue-88-candidate-limit branch from 9dfa734 to d82bd88 Compare September 7, 2026 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Do not use the final result count as the retrieval candidate limit

3 participants