fix(literature): sort candidates by keyword overlap before char-cap truncation#307
Open
akkiittiwari wants to merge 1 commit into
Open
Conversation
…runcation Stage 5 screening was rejecting 100% of candidates for niche/cross-domain topics. Root cause: candidates.jsonl retains raw search order (whichever query/source returned them), and _MAX_CANDIDATES_CHARS truncates before serializing to the LLM prompt. For a run with 1418 filtered candidates, 30,000 chars only covered the first ~15-20 rows, which were all off-topic noise pulled in by a low-signal expanded query. Every relevant paper sat past index 246 and never reached the screening prompt, so the LLM correctly rejected the (unrepresentative) slice it was shown. Sort filtered_rows by keyword_overlap descending before truncating, and raise the cap from 30k to 100k chars so more of the relevant pool survives.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
candidates.jsonlretains raw search order (whichever query/source happened to return a paper), and_MAX_CANDIDATES_CHARStruncates the serialized candidate list before it's sent to the screening LLM. On a real run with 1418 filtered candidates, the 30,000-char cap only covered the first ~15-20 rows — all off-topic noise pulled in by a low-signal expanded query (e.g. "The Stated vs. Revealed survey"). Every relevant paper sat past index 246 and never reached the screening prompt, so the LLM correctly (but uselessly) rejected the unrepresentative slice it was shown, and the stage paused withmodel_rejected_all.filtered_rowsbykeyword_overlap(already computed during the pre-filter) descending before truncating, so relevant candidates survive the cap regardless of raw search order. Also raised_MAX_CANDIDATES_CHARSfrom 30k to 100k chars so more of the relevant pool gets through.Verification
pytest tests/test_rc_literature.py(run under the project's .venv, Python 3.11) — 47 passed.Test plan