PptxGenJS Presentation

[Audio] Hi, I'm Mohit, and this is my solution for CohortX Task 2. This is a system for extracting structured eligibility-criteria information from clinical trial text — and the interesting part isn't a trained model, it's that there's no training at all in the traditional sense. It's a retrieval-augmented, few-shot prompting pipeline: one call to Claude per example, no fine-tuning, no gradient updates. I'll walk through how it's built, the design choices that mattered, and what the ablations taught me..

[Audio] The task is straightforward to state: take a clinical trial's free-text eligibility criteria, and turn it into structured triples. Those triples live on three levels — study-level facts, the criteria-set grouping into inclusion and exclusion, and then the individual criterion details, like age ranges, consent requirements, or exclusion rules. The exact formatting of that output — em-dash separators, blank lines between entries — turns out to matter enormously, and I'll come back to that..

[Audio] Here's the whole pipeline. It starts with a TF-IDF index built once over the 100 training examples — that's the only fitted component in the entire system. For each test example, Maximal Marginal Relevance pulls four demonstrations that are both relevant and diverse. Those get assembled into a single prompt with the output schema, the relation vocabulary, and the target text, and sent through one Claude call via Claude Code CLI. Out comes the structured triples. No fine-tuning, no gradient updates, no external medical ontologies — and it runs entirely on CPU, one model call per test example..

[Audio] For picking which four training examples to show the model, I used Maximal Marginal Relevance instead of plain top-k similarity. The formula balances two things: how similar a candidate is to the query, weighted by lambda, minus how similar it is to demonstrations already selected. I used k=4, lambda=0.5, and TF-IDF vectors over word unigrams and bigrams. The reason this matters is that plain top-k tends to retrieve near-duplicates that all teach the model the same thing. MMR spreads the four examples across more of the pattern space, and empirically that was worth about a one-point score improvement over top-k at the same k..

[Audio] Every prompt is assembled from four pieces: the output schema itself — with its em-dash separators and blank lines — a relation vocabulary of about sixty relation types like 'excludes patients with', 'age', or 'consent', the four MMR-retrieved demonstrations, and finally the target text to convert. One nice detail: even small formatting conventions, like whether to write 'Inclusion Criteria' or 'Inclusion Criteria Set', are resolved by majority vote over whatever the retrieved examples happen to use — roughly seventy-one percent of training annotations use the shorter form, twenty-nine percent the longer one, so the prompt follows whichever is more common among the four demos it happened to retrieve..

[Audio] I swept a few of the key hyperparameters. MMR outperformed plain top-k retrieval by roughly one point at the same k. On lambda, 0.7 — weighting relevance more heavily — nudged very slightly above the 0.5 setting, landing around 0.80, while 0.3, which weights diversity more, dropped to about 0.77. And bumping k up to five demonstrations didn't help — it landed around 0.78 to 0.79, no better than four. I want to flag that all of these sweep numbers are approximate figures from development runs, not the official submitted leaderboard score — more on that in a moment..

[Audio] Not everything I tried helped. Two-pass revision, decomposing compound criteria into separate statements, running eight-way ensembles with union or consensus voting, and self-consistency sampling — all four of those reduced performance compared to the simple single-call pipeline. But the single biggest lesson was about output formatting, not modeling. An otherwise fully correct submission that used single newlines instead of blank lines between triples scored only 0.05. The scorer is evidently extremely strict about that separator, so getting the blank-line convention right mattered more than almost any modeling choice I made..

[Audio] One thing I want to be fully transparent about: the run that was actually submitted used whatever model was the interface's configured default as of April 2026, through Claude Code CLI version 2.1.104 — the code itself exposes an explicit model argument, but the submission just used the default. Separately, in a post-hoc development run, I pinned the exact same pipeline to claude-opus-4-6 and got a score of 0.81. I want to be clear that 0.81 is not the official submitted leaderboard score — it's a later, separate result, and I'm reporting it here only for transparency about what the pipeline is capable of under a fixed, named model..

[Audio] So, pulling it together: retrieval and careful prompting can substitute for a lot of what fine-tuning is normally used for, even with just a hundred examples. Output formatting is not a cosmetic detail — it can be the difference between a good score and a 0.05. Simple, single-pass pipelines beat every elaborate variant I tried — revision, decomposition, ensembling, self-consistency all made things worse. And a small, principled trade-off between relevance and diversity in retrieval consistently paid off over plain nearest-neighbor lookup..

[Audio] That's the full pipeline — from a TF-IDF index over a hundred examples, through MMR-based demonstration selection, to a single structured Claude call per test case, no training required. The full code is on GitHub at the link on screen. Thanks for watching..