MedAgents: Large Language Models as Collaborators for Zero-shot Medical Reasoning

In plain words

Language models know a lot of medicine, but a plain question often does not bring that knowledge out. A single answer can also invent facts or reason in a way that sounds right and is wrong. Adding fine-tuning or a lookup database helps, but both cost effort and data that many teams do not have.

The authors' idea is to imitate a hospital case conference. The model is asked to play several specialists, each with a different field. Each specialist reads the question and writes what they would check. Those notes are merged into one report. Then the specialists read the report and say whether they agree. If someone objects, they suggest a fix, the report is rewritten, and the group reads it again. When everyone agrees, the model picks an answer from the agreed report.

No training is involved. The whole method is a set of prompts run in sequence, so it can be placed on top of any model that accepts text. The authors report that it does better than plain prompting, and that for a strong model it matches a well-known multi-sample prompting method.

TL;DR

MedAgents is a training-free, zero-shot pipeline for medical multiple-choice questions. It asks the LLM to play domain experts who write analyses, merges them into a report, and runs voting and revision rounds until the experts agree. A final prompt then picks one option letter. The authors report the best results with GPT-4 (average 86.7% over nine datasets) and GPT-3.5 (72.1%). Their own results and the code differ in several places; see Paper vs code.

Problem

Medical question answering needs domain knowledge that is hard to draw out with simple prompting, and it needs multi-step reasoning. Medical training data is limited and private, so fine-tuning is costly §1. Prompting methods have been developed mostly in maths and coding §1; in medicine, the authors report that such strategies, chain-of-thought included, can produce hallucinations, which they describe as spurious outputs from misused medical terms §1 §3.2 app. A.

The paper asks whether a general-purpose LLM can use its own stored medical knowledge better, with prompting only, and does so in a zero-shot setting, so no worked examples are given §1 §3.1.

Method

The pipeline has five stages, run in this order §2:

1. Expert gathering: the model names m question fields and n option fields for the case §2.1.
2. Analysis proposition: one analysis per question field, then one analysis per option field that also reads all question analyses §2.2.
3. Report summarization: one summary report from all analyses §2.3.
4. Collaborative consultation: experts vote YES or NO on the report; a NO comes with a revision proposal; the report is revised; this repeats for up to t rounds §2.4 alg. 1.
5. Decision making: the model picks one option from the agreed report §2.5.

Equations as printed in the source. Equation numbers are counted in source order eq. 1-eq. 5:

\mathcal{QD} = \mathrm{LLM}(q,\ r_{qd},\ \mathrm{prompt}_{qd}), \qquad \mathcal{OD} = \mathrm{LLM}(q,\ op,\ r_{od},\ \mathrm{prompt}_{od}) eq. 1

qa_i = \mathrm{LLM}(q,\ qd_i,\ r_{qa},\ \mathrm{prompt}_{qa}) eq. 2

oa_i = \mathrm{LLM}(q,\ op,\ od_i,\ \mathcal{QA},\ r_{oa},\ \mathrm{prompt}_{oa}) eq. 3

\mathrm{Repo} = \mathrm{LLM}(\mathcal{QA},\ \mathcal{OA},\ r_{rs},\ \mathrm{prompt}_{rs}) eq. 4

\mathrm{ans} = \mathrm{LLM}(q,\ op,\ \mathrm{Repo}_f,\ \mathrm{prompt}_{dm}) eq. 5

Here r is the system role and prompt the guideline text for each step; the full texts are in app. D. Inside §2.4 the vote is LLM(Repo, r_vote, prompt_vote), and each revision is Repo_j = LLM(Repo_{j-1}, Mod_j, prompt_mod) §2.4.

Overview:

# MedAgents inference, zero-shot  [§2] [eq. 1]-[eq. 5]
# Input:  question q; options op (k letters); language model llm
# Output: one option letter

def medagents(question, options, llm):
    # Gather m question experts (5; 4 for PubMedQA) and n option experts (2)
    # [§2.1] [§3.1] [eq. 1]
    question_fields = llm_pick_fields(question, count=5)
    option_fields = llm_pick_fields(question, options, count=2)
    # Each question expert writes one analysis of the question  [§2.2] [eq. 2]
    question_analyses = [
        llm(question, field) for field in question_fields
    ]
    # Each option expert judges the options, given all question analyses
    # [§2.2] [eq. 3]
    option_analyses = [
        llm(question, options, field, question_analyses)
        for field in option_fields
    ]
    # Merge all analyses into one report  [§2.3] [eq. 4]
    report = llm_summarize(question_analyses, option_analyses)
    # Revise the report until all experts agree or the round limit is hit
    # [§2.4] [alg. 1]
    report = consult(report, question_fields + option_fields, max_rounds=5)
    # Choose the final option from the agreed report  [§2.5] [eq. 5]
    return llm_choose(question, options, report)

Consultation, following the per-round behaviour described in the text and implemented in code. Algorithm 1 differs in one detail; see Pitfalls:

# Collaborative consultation  [§2.4] [alg. 1]
# Input:  report; experts; max_rounds t (5 in the paper)
# Output: report after the last revision, which is not voted on

def consult(report, experts, max_rounds):
    # Repeat rounds while someone still objects and the limit is not reached
    # [alg. 1]
    rounds = 0
    objected = True
    while objected and rounds < max_rounds:
        rounds = rounds + 1
        objected = False
        advice = []
        # Each expert votes YES or NO on the current report  [§2.4] [alg. 1]
        for expert in experts:
            vote = llm_vote(expert, report)
            if vote == "no":
                # A NO comes with a modification proposal  [§2.4] [alg. 1]
                advice.append(llm_advice(expert, report))
                objected = True
        # Revise the report with this round's advice only  [§2.4]
        if objected:
            report = llm_revise(report, advice)
    return report

Other method facts stated in the text:

• Question and option experts are assigned by the model from the question and options, not from a fixed list of specialties §2.1 app. D.
• The same expert set votes in every round. The paper's zero-shot setting uses no examples in any prompt §3.1.
• The authors say the method needs no retrieval (RAG) step, because role-play is used to bring out the model's own knowledge §1 app. A.

Hyperparameters

Prompts (role and guideline text for each step): app. D. Datasets: MedQA, MedMCQA, PubMedQA, and six MMLU subtasks §3.1 tab. 1.

Test sizes as listed in tab. 1:

• MedQA: 1273 multiple-choice questions taken from medical licensing exams, four options A to D.
• MedMCQA: 6.1K questions from Indian medical entrance exams, four options.
• PubMedQA: 500 questions answered Yes, No or Maybe from abstract context; three options.
• Six MMLU subtasks (anatomy, clinical knowledge, college medicine, medical genetics, professional medicine, college biology): 1089 questions combined.

Results

Author-reported. Setup: GPT-3.5-Turbo and GPT-4, zero-shot for MedAgents, nine datasets, accuracy in % §3.1. Baselines are zero-shot and few-shot prompting, chain-of-thought, and self-consistency with each §3.2. Flan-PaLM rows are shown in the same table; the paper says it follows Flan-PaLM's evaluation setting, and does not say whether those numbers were re-run §1 tab. 2. Avg. is the unweighted mean of the nine columns tab. 2.

Main results tab. 2:

The paper's text says MedAgents clearly beats zero-shot baselines and is "comparable" to the strongest few-shot baseline, few-shot CoT + SC §3.2. The Avg. gap to that baseline is 0.5 points for GPT-3.5 and 1.3 points for GPT-4 tab. 2.

Ablation on MedQA, model not stated tab. 3:

Comparison with open-source medical models, MedQA and MedMCQA tab. 4:

Number of experts, MedQA, MedMCQA, PubMedQA and MMLU tab. 5: question agents 5, 5, 4, 5; option agents 2, 2, 2, 2. Figure 3 plots accuracy against the number of question and option agents on several datasets fig. 3 §4.3.

Domain variation, GPT-3.5, stated as a small sample tab. 6 §4.4:

Agent quantity, GPT-3.5 tab. 7 §4.5:

Error analysis: a human review of 40 error cases from MedQA and MedMCQA sorts errors into four groups: missing knowledge, knowledge that was present but applied wrongly, answers that contradict each other, and mistakes in the step-by-step rationale §4.6. The authors say 77% are knowledge-related and 8% come from CoT §4.6 fig. 4 app. A. Figure 5 shows one example per category fig. 5.

Paper vs code

Code: https://github.com/gersteinlab/MedAgents, pinned at aaeff0499e169b41faf810cbca59504e3ee2788c. It is linked from the abstract, and its owner is the Gerstein lab (co-author Mark Gerstein's group), so it is treated as official. The repository has no LICENSE file, so no reuse licence is known. Code is cited here, not quoted README.md. The repository contains the inference pipeline and the MedQA test file only; the MedMCQA, PubMedQA and MMLU data are not in it test.jsonl.

Differences, each with both citations:

• Temperature. Paper: 1.0 for all generations §3.1. Code: 0 for every multi-agent call, including votes and the final answer utils.py utils.py utils.py. The paper does not say which setting produced the reported numbers.
• Round limit. Paper: t = 5 §3.1. Code: default 3 in run.py, and inference.sh passes 3 run.py inference.sh.
• Expert count for PubMedQA. Paper: m = 4 for PubMedQA §3.1 tab. 5. Code: the number of question fields is fixed at 5 for every dataset, and the prompt text says "five" prompt_generator.py prompt_generator.py.
• Modifications across rounds. Algorithm 1 starts the modification list once and never clears it, so later revisions reuse earlier rounds' proposals alg. 1. The text says round j uses Mod_j only §2.4, and the code rebuilds the advice dictionary each round, so it follows the text utils.py utils.py. Algorithm 1 also revises with prompt p_rev, while the text uses prompt_mod; the code uses one revision prompt prompt_generator.py.
• Revision output format. The paper's revision prompt asks for "Key Knowledge" and "Total Analysis" app. D. The code's revision prompt asks only for "Total Analysis" prompt_generator.py. The parser then checks whether the exact string "Key Knowledge" is an element of the split list, which is effectively never true, so the Key Knowledge section is dropped from the report used for voting and for the final answer data_utils.py data_utils.py.
• Option-analysis prompt. The paper gives one template for option analysis app. D. The code appends the option-review instructions once per question analysis, so the prompt repeats them up to five times prompt_generator.py.
• Advice prompt. The code asks for advice in a "Revisions:" format prompt_generator.py. That prompt is not in app. D.
• Model names. Paper: GPT-3.5-Turbo and GPT-4 §3.1. Code: deployment names gpt-35-turbo-16k and gpt-4 api_utils.py.
• Analysis cleaning. The code deletes a trailing incomplete sentence and any text after the phrase "as an AI language model" data_utils.py. The paper does not mention either step.
• Vote parsing. The paper does not say how an unclear reply is treated. The code counts it as YES data_utils.py.
• Matches the paper: the question and option analyses (eq. 2, eq. 3), the summary step (eq. 4), the final decision prompt (eq. 5), and the rule that every expert votes on each round utils.py utils.py.

Pitfalls

• Reproduction setting. The paper's stated temperature (1.0) and the code's (0) differ, and the paper does not say which produced the table numbers. Pick one, state it, and expect different numbers.
• Final round is not voted on. When the round limit is hit with a NO still present, the report is revised but never voted on again alg. 1 utils.py. The answer rests on an unchecked revision. Expect this to happen whenever the limit is reached.
• Unanimity is strict. One NO from any of the seven experts forces a revision §2.4 utils.py. Cost and churn grow with the number of experts.
• Failed calls become votes and answers. A failed API call returns the text ERROR. api_utils.py. An unclear vote defaults to YES, and ERROR. has no yes or no, so a failed vote counts as agreement data_utils.py. In the final step, the letter regex matches the capital E inside "ERROR", so a failed final call is scored as option E data_utils.py. The paper does not mention failure handling.
• Vote regex is a substring match. The first "yes" or "no" anywhere in the reply decides the vote, so words such as "know", "nothing" or "cannot" count as NO data_utils.py.
• Missing section can crash the run. If the summary or revision output has no "Total Analysis:", the split raises an index error, and run.py does not catch it data_utils.py run.py. This is a real risk because failures return ERROR..
• Letter parsing. The final answer is the first capital A to E after the last colon. If the reply has no colon, the first capital A to E anywhere is used, so the letter A in the word "Answer" would be read as the choice data_utils.py.
• Expert counts are not enforced. The code takes whatever field names the model returns, so the number of experts can differ from m and n utils.py utils.py.
• Truncation. Analyses are capped at 300 tokens, and a trailing sentence that lacks a full stop is removed utils.py data_utils.py. Long analyses are silently shortened.
• Sample size versus reported decimals. The paper says it evaluates 300 random samples per dataset §3.1, but values such as 64.1% and 83.7% are not multiples of 1/300. They are consistent with the full 1273-item MedQA test set (816 of 1273 gives 64.1%; this is our arithmetic) tab. 1 tab. 2. Which items were used for Table 2 is unclear.
• Tables with impossible fractions. Table 6 is said to use 20 samples §4.4, but 63.8% is not a whole number of 20-item results. Table 7 is said to use 300 samples §4.5, but 59.2% is not a whole number of 300. Averaging or a different sample is likely, and not stated tab. 6 tab. 7.
• Noise at 300 samples. For a 64% accuracy measured on 300 items, the binomial standard error is about 2.8 points (our calculation). The gap to the few-shot baseline (0.5 and 1.3 points on average) is inside that range tab. 2.
• Ablation model. The ablation's full pipeline reads 67.0 on MedQA, while the main table reports 64.1 (GPT-3.5) and 83.7 (GPT-4). The model and sample for Table 3 are not given tab. 3 tab. 2.
• Agent-count labels. The row "6 different domains" in Table 7 equals the main GPT-3.5 result, but the main setup uses 7 experts (5 question plus 2 option) tab. 7 §3.1. The mapping is not explained.
• Error shares. The paper's 77% and 8% shares come from 40 sampled cases §4.6 app. A. Each case is 2.5 points, and 77% and 8% are not multiples of 2.5, so they are not exact counts out of 40. Treat them as rounded.
• Few-shot baselines. The introduction calls them "5-shot" §1. Section 3.2 says "several" demonstrations §3.2. Table 2's Flan-PaLM rows follow Flan-PaLM's evaluation setting, but the paper does not say whether they were re-run §1 tab. 2.
• Cost. Our count from the code gives at least 18 model calls per question when everyone agrees in the first round: 2 domain calls, 5 question analyses, 2 option analyses, 1 summary, 7 votes and 1 final call. Each dispute adds advice and revision calls utils.py. The paper reports only the per-question dollar cost and time §3.1.
• Numbering. Equation, table and figure numbers here follow source order in the arXiv v4 LaTeX app. A-E. Check against the PDF if they differ.

Lineage

• Builds on: multi-persona and multi-agent collaboration work the paper cites as inspiration, including Solo Performance Prompting (named, arXiv id not in the paper body) and CAMEL (arXiv:2303.17760) §5. Debate-style multi-agent work is cited for the consultation idea §5 (named, no arXiv id in the body).
• Compared against: zero-shot and few-shot prompting; chain-of-thought (Wei et al., zero-shot CoT by Kojima et al.) §3.2; self-consistency [wang2022self], see [/papers/2203.11171] §3.1; Flan-PaLM, followed for its evaluation setting §3.1; Med-PaLM 2 (arXiv:2305.09617) as a plug-in target §1; open-source medical models in tab. 4.
• Superseded by: not known from the wiki.