UETQuintet: Multi-hop Biomedical QA Pipeline
- UETQuintet Multi-hop Pipeline is a biomedical QA system that decomposes complex clinical queries into sequential and direct answer pathways.
- It employs a modular architecture combining in-context LLM prompting, split learning, and pipeline parallelism to optimize multi-step reasoning with low latency.
- Distributed orchestration and dual-source retrieval from Google and Wikipedia bolster robust performance and enhance prediction accuracy in biomedical research.
The UETQuintet Multi-hop Pipeline is a biomedical question answering (QA) system designed for complex clinical and scientific queries that require multi-step reasoning and synthesis from heterogeneous information sources. It combines a modular architecture for question analysis and decomposition with a pipeline of information retrieval and in-context answer generation, and is structured to maximize efficiency and answer accuracy across both direct and sequential question types. The system further leverages foundational split learning and pipeline parallelism concepts—tailored for distributed, multi-hop computational resources—to orchestrate multi-stage inference with low end-to-end latency and robust resource usage (Nguyen et al., 11 Jan 2026, Wei et al., 7 May 2025).
1. Pipeline Overview and System Architecture
UETQuintet processes input questions through a structured multi-stage pipeline, dynamically adapting its path depending on question complexity. For direct questions, a streamlined single-hop answer generation is performed. For sequential (multi-hop) queries, the input is decomposed into a chain of sub-questions, each addressed iteratively via retrieval and reasoning steps.
The architecture is motivated by principles from pipelined split learning in multi-hop edge networks (Wei et al., 7 May 2025), wherein the overall computational burden is partitioned into submodels (or "stages"), potentially distributed across edge nodes. Formally, binary variables and indicate, respectively, assignments of canonical layer splits and stage-to-node placements within the distributed infrastructure. Each inference iteration may be executed as a chain of micro-batches propagating forward and backward through the pipeline, composing a 1F1B (one-forward, one-backward) schedule for maximal concurrency.
2. Question Analysis and Type Classification
The pipeline begins with question normalization, applying a few-shot in-context LLM prompt (gpt-4o-mini) to reduce verbosity and focus the input to ≤50 tokens. Feature extraction produces, for each question, a vector encompassing:
- Linguistic features (e.g., part-of-speech tag counts, dependency tree depth)
- Structural features (e.g., WH-word presence, clause counts)
- Embedding features (mean/max pooling from biomedical BERT)
A stacking ensemble classifier predicts whether a question requires sequential decomposition. First, RF() and XGB() base learners provide binary outputs; these are concatenated into . A logistic regression meta-classifier, weighted at 0.72 (RF) and 0.28 (XGB), outputs , where is the logistic sigmoid. Performance on 453 annotated samples reaches 0.89 accuracy and 0.83 F1 (Nguyen et al., 11 Jan 2026).
3. Sequential Decomposition and Multi-hop Reasoning
Questions flagged as “sequential” undergo decomposition into a chain of sub-questions by a few-shot prompted LLM (gpt-4o-mini). The output is a JSON array of steps, each comprising:
- “sub-question” 0: a concise, self-contained query
- “sub-query” 1: distilled keyword set
- “anchor” 2: entity reference for step 3 (seeded from the original question for 4)
Chaining ensures that context and entities from previous steps are reused, supporting multi-hop reasoning. All decomposition is prompt-guided; no auxiliary decomposition loss or trainable component is reported in this stage.
4. Multi-Source Contextual Retrieval and In-Context Generation
For each hop 5 in the sequential chain (or the direct path for non-sequential questions), evidence is collected from two sources:
- Google Custom Search API: Up to 6 web snippets per (7, 8) query
- Wikipedia dump: Locally stored, segmented into sentences
TF–IDF vectors are computed for the concatenated query and anchor, and for each Wiki sentence. Similarity is ranked via cosine; the top 9 Wiki sentences per hop are included. The retrieval context 0 is assembled for each hop. The pipeline does not utilize dense retrieval, BM25, or neural reranking beyond the TF–IDF stage.
Answer generation at each hop employs an LLM (gpt-o3-mini), supplied with step metadata, anchor, and context. Prompt constraints enforce JSON output with strictly typed “short_answer” and “long_answer”. Decoding is deterministic (1). Answers undergo post-hoc format checks and normalization: Wikipedia API is queried for entity canonicalization, ensuring surface-form consistency in hop chaining.
5. Distributed Pipeline Orchestration and Latency Optimization
UETQuintet's multi-hop architectural design is underpinned by joint model splitting, stage placement, and batch size optimization strategies (Wei et al., 7 May 2025). The system models latency as
2
where 3 is the fill phase latency for the first micro-batch, and 4 is the bottleneck per-hop time in steady state. Optimization is formulated as a mixed-integer nonlinear program, balancing a min-sum (fill time) and a min-max (bottleneck) objective. The bottleneck-aware shortest-path algorithm efficiently solves the model splitting and placement problem, mapping valid splits to a layered graph where edge weights represent per-stage compute and communication costs. The micro-batch size 5 is then chosen via closed-form analysis: 6 is piecewise-linear, and 7 is set at critical points induced by resource limits or analytic minima. The full block-coordinate descent alternates between solving for 8 and 9, iterating to a local optimum in few steps.
A summary of the numerical advantages includes:
| Comparison | Latency Reduction | Notes |
|---|---|---|
| Pipeline vs. no-pipeline | 0–1 | Micro-batch pipelining accelerates completion |
| MSP+Sizing vs. heuristics | 20–40% | Over random-cut or random-placement baselines |
| Scaling 2 (servers) | >50% | Latency drops as parallelism increases; solver remains tractable |
Robustness to resource fluctuations (±30% link or compute variation yields <5% performance loss) and improved mesh over line/tree topologies are additional findings.
6. End-to-End Evaluation and Error Sources
On the MedHopQA Track 1 dataset, UETQuintet achieves Exact Match (EM) of 0.84 and concept-level score of 0.863, ranking second on the leaderboard. The evaluation decomposes into:
- Classification Metrics: 0.89 accuracy, 0.83 F1 (type classifier)
- Retrieval Step: Unsupervised; no trainable component
- Full System Ablations:
- Run 1: Google only, no normalization—EM 0.755, concept 0.812
- Run 2: +Wiki for yes/no Qs—EM 0.783, concept 0.832
- Run 3: +Wiki normalization—EM 0.811, concept 0.836
- Run 4: +Wiki for WH Qs—EM 0.829, concept 0.851
- Run 5: +post-processing, gpt-4o-search-preview—EM 0.84, concept 0.863
Qualitative error analysis identifies the main bottlenecks as ambiguous entity normalization, LLM hallucinations in sub-question chaining, and information loss from Google API snippet limits.
7. Implications and Prospects
The composition of modular classification, in-context LLM decomposition and answer synthesis, and dual-source retrieval—integrated via pipeline-parallel multi-hop orchestrators—yields a highly adaptable framework for biomedical QA under resource and data heterogeneity constraints. The use of graph-theoretic shortest-path approaches for optimization, closed-form micro-batch sizing, and robust block-coordinate solvers directly reflects advances in pipelined split learning for edge systems (Wei et al., 7 May 2025). A plausible implication is that such architectures, by tightly coupling information flow and low-level computational resource allocation, can naturally extend to more general, high-throughput distributed QA and reasoning settings in future clinical research infrastructure (Nguyen et al., 11 Jan 2026, Wei et al., 7 May 2025).