Healthcare & Clinical

Improving Clinical Trial Matching Accuracy with a Blended Retrieval Pipeline

How Pfactorial Technologies enhanced an existing clinical-trial matching system's retrieval accuracy by layering semantic search and hybrid query strategies on top of its production pipeline.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's clinical-trial matching system, built on the TrialGPT framework, evaluates a patient's eligibility for a trial by predicting on a criterion-by-criterion basis and consolidating those predictions into an overall match. Its accuracy was solid, but bounded by the retriever surfacing candidate trials in the first place.

Manually matching patients to trials is labor-intensive and error-prone at any scale, and in any retrieval-augmented pipeline, the quality of the retriever is the ceiling on everything built on top of it - irrelevant candidate trials degrade eligibility predictions no matter how capable the downstream model is.

Pfactorial applied a research method called Blended RAG - combining sparse keyword search, medical-domain dense vector search, and hybrid query strategies - to the client's existing retrieval stage, improving candidate-trial relevance without requiring changes to the downstream eligibility-scoring logic already in production.

Why this engagement is representative This engagement shows a different kind of Pfactorial engagement than a from-scratch build: improving the retrieval accuracy at the core of a system a client already has in production, without disrupting what's built on top of it.

THE CHALLENGE

The client's existing hybrid retriever performed well, but four specific limitations left accuracy on the table.

1. Manual matching doesn't scale

Cross-referencing a patient's full medical history against every open trial's eligibility criteria by hand is slow, inconsistent, and doesn't scale to a large or growing trial corpus.

2. Retriever quality is the ceiling on RAG accuracy

Irrelevant context pulled into the pipeline directly degrades the eligibility predictions built on top of it - no downstream model can fully compensate for a weak retrieval stage.

3. Single-method retrieval leaves accuracy on the table

Keyword matching (BM25) alone and dense vector search alone each catch trial matches the other would miss; relying on just one method means giving up recall the other method would have provided.

4. Filtering has to survive a large corpus without ballooning cost

Narrowing thousands of candidate trials down to a manageable, relevant shortlist has to be both accurate and computationally affordable at scale.

The real brief Not “swap in a better embedding model” but “improve the retriever a working clinical-matching system depends on, without disrupting the eligibility logic already built on top of it.”

THE SOLUTION

Pfactorial applied the Blended RAG method: a progressive, two-stage retrieval pipeline that fuses sparse keyword search, a medical-domain dense retriever, and a sparse encoder before results ever reach the client's TrialGPT eligibility scoring.

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 2

Figure 2 - Two-stage retrieval: coarse filtering, then semantic refinement, then fusion.

Architectural principles

Progressive narrowing, not one-shot search - Coarse filtering (BM25 combined with phrase-prefix matching) runs first across the full trial corpus; refinement (dense and sparse vector matching) runs second on the much smaller candidate set - rather than asking one method to do everything at once.
Blend complementary retrieval signals - Sparse keyword-based methods (BM25, TF-IDF) and dense semantic search (MedCPT) are combined, since each surfaces trial matches the other would miss.
Fuse, don't just pick a winner - Results from multiple retrieval methods are combined via Reciprocal Rank Fusion, rather than selecting one method's output as “best” and discarding the rest.
Domain-tuned components - A medical-domain dense retriever (MedCPT) is used in place of a general-purpose embedding model, since clinical language and terminology don't behave like general web text.

CAPABILITIES DELIVERED

The engagement delivered a retrieval pipeline that plugs into the client's existing TrialGPT framework without requiring changes downstream.

CAPABILITY	WHAT IT DOES
Two-stage retrieval pipeline	BM25 and phrase-prefix filtering, followed by dense and sparse vector refinement.
Per-condition candidate generation	Up to 2,000 candidate trials filtered per condition from the full trial corpus.
Reciprocal rank fusion	Combines results from multiple retrieval methods into one ranked candidate list.
Drop-in TrialGPT integration	Feeds directly into the existing eligibility-scoring framework with no downstream changes required.
Benchmarked comparison	Side-by-side evaluation against the baseline retriever on the same patient notes.

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 3

Figure 3 - Complementary retrieval signals, fused rather than chosen between.

Design note The value isn't a single retrieval method being “better” than another - it's that fusing complementary methods recovers matches that any single method, used alone, would have missed.

ENGINEERING FOR SCALE AND RELIABILITY

Improving a retriever without regressing anything downstream requires disciplined benchmarking, not just a plausible-sounding new method.

Elasticsearch-backed multi-match querying

Multiple multi-match query types - cross-fields, most-fields, best-fields and phrase-prefix - were evaluated to determine which best surfaced relevant trials.

Cost-aware first-stage filtering

A sparse-encoder approach handles first-stage filtering across the full corpus, keeping the more expensive dense-vector computation limited to a much smaller, pre-filtered candidate set.

Domain-specific dense retriever

MedCPT, a medical-domain embedding model, was used over a general-purpose alternative, since clinical terminology requires domain-aware semantic matching.

Top-k retrieval accuracy as the benchmark

Retrieval performance was measured using top-k accuracy across query-type variants, giving a consistent metric for comparing methods.

Head-to-head baseline comparison

Results were compared directly against the existing TrialGPT baseline retriever on the same patient notes, isolating the improvement attributable to the new pipeline.

DELIVERY APPROACH

The engagement moved from baseline assessment to a validated, drop-in replacement for the existing retrieval stage.

1. Baseline benchmarking - assessment of the existing hybrid BM25 + dense retriever's performance on representative patient notes.

2. First-stage filter design - BM25 and phrase-prefix matching across the full trial corpus, filtering to ~2,000 candidates per condition.

3. Second-stage refinement - dense (MedCPT) and sparse (TF-IDF) vector matching, each retaining the top 100 candidates.

4. Fusion & ranking - Reciprocal Rank Fusion combining the outputs of both refinement methods into a single ranked list.

5. TrialGPT integration - connecting the refined retrieval output directly into the existing eligibility-scoring pipeline.

6. Comparative evaluation - benchmarking the blended pipeline's results against the original baseline retriever.

RESULTS AND IMPACT

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 4

Figure 4 - Key outcomes from this engagement.

The blended retrieval pipeline surfaced improved candidate-trial matches without requiring any changes to the client's downstream eligibility-scoring logic.

The approach is documented for extension to additional retrieval strategies (bool-prefix, most-fields, best-fields) as future refinement work.

What it enabled commercially

Improving the retriever directly improves the quality of every eligibility prediction built on top of it, giving the client's clinical trial matching product a stronger accuracy foundation without a system rebuild.

WHY PFACTORIAL

This engagement reflects Pfactorial's ability to improve the core accuracy bottleneck of an AI pipeline a client already has in production - the kind of engagement that starts from “we have something working, make it better,” not a blank slate.

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with teams that have a working retrieval-augmented system and want to improve its accuracy at the source. If you're evaluating whether your retriever is the limiting factor in your RAG pipeline, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_BlendedRAG_Clinical_Trial_Matching image 6

© 2026 Pfactorial Technologies. Client identity and product-specific implementation detail are withheld or generalized; no client data, credentials, source code, or infrastructure detail is included in this document.

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies enhanced an existing clinical-trial matching system's retrieval accuracy by layering semantic search and hybrid query strategies on top of its production pipeline.