DSPy+HELM Benchmarking Framework

• DSPy+HELM framework is a unified benchmarking pipeline that combines modular prompt optimization with holistic evaluation to estimate language model performance ceilings.
• It replaces fixed prompts with DSPy programs featuring multiple modules, including explicit chain-of-thought traces and Bayesian optimization for robust, reproducible assessments.
• The framework reduces performance variability and bias by applying systematic prompt search and structured prompting across diverse benchmarks and domains.

The DSPy+HELM framework is a unified benchmarking pipeline for LMs that integrates structured and automated prompt optimization into the Holistic Evaluation of LLMs (HELM) suite. By extending HELM to support declarative prompting and systematic prompt search via DSPy, the framework enables robust estimation of each model’s performance ceiling—the maximum achievable score across prompt variants—yielding empirically grounded, less variable, and more decision-informative benchmarks across domains.

1. System Architecture and Programmatic Structure

HELM’s baseline design evaluates each model–benchmark pair with a single, fixed prompt $p_{\mathrm{base}}$. DSPy+HELM generalizes this by replacing the one-shot prompt with a modular DSPy program, $\Phi$, comprising $m$ modules. Each module $i$ possesses a prompt template $p_i$ parameterized by open slots (variables) $V_i$, which include instruction text and up to $K_i$ in-context examples. The aggregate variable set is $V = \bigcup_i V_i$.

Assignments, denoted $V \to S$, instantiate each variable $v \in V$ with a string $\Phi$0. For given inputs $\Phi$1, execution is notated as: $\Phi$2 The HELM driver enumerates assignment collections per prompting method, runs $\Phi$3 on each test example, and computes standard HELM metrics on resultant outputs (Aali et al., 25 Nov 2025).

2. Prompt Optimization Methodologies

The framework comprises four core prompting protocols:

Method	Structure	Distinctive Elements
HELM Baseline	Single prompt, no CoT	Handcrafted $\Phi$4
Zero-Shot Predict	DSPy "Predict," $\Phi$5 demos, baseline instructions	Template modularization without added structure
Zero-Shot CoT	DSPy ChainOfThought module, REASONING + OUTPUT	Explicit reasoning traces elicited before answer
BFRS	Few-shot, random demo search, batch validation	Bootstrapped pools $\Phi$6 of high-score examples
MIPROv2	Joint Bayes-opt over instructions and demos	Tree-structured Parzen Estimator (TPE) based search

HELM Baseline: Uses $\Phi$7 with no CoT augmentation.

Zero-Shot Predict: Adopts the same instruction as $\Phi$8, exposes the model to the modular DSPy template without additional exemplars.

Zero-Shot CoT: Applies a two-field template: $\Phi$9 instructing the model to output an explicit chain-of-thought trace.

BFRS (Bootstrap Few-Shot + Random Search): Constructs demo pools $m$0 from seed program outputs on training set $m$1, selecting input–output pairs with score $m$2. Random demo combinations undergo $m$3 trials, with each configuration’s minibatch score $m$4 computed. The highest-scoring configuration $m$5 is selected.

MIPROv2 (Bayesian Optimization): Expands upon BFRS, proposing $m$6 instruction candidates per module ($m$7) via LM-generated candidates. TPE models select candidates maximizing $m$8 (ratio of poor-to-good prior densities), with periodic full validation splits determining the best overall assignment.

3. Ceiling Performance Estimation

Performance ceiling is formalized as the supremal metric achieved under all prompt assignments: $m$9 where $i$0 denotes the test set and $i$1 the evaluation metric per benchmark.

Operationally, the ceiling is estimated by running the set of structured prompting methods—Zero-Shot CoT, BFRS, and MIPROv2—and retaining the maximal attained score per model/benchmark: $i$2 Ceiling estimation enables more accurate, less prompt-design-biased assessment of model capabilities (Aali et al., 25 Nov 2025).

4. Benchmark Scope and Quantitative Outcomes

The framework is applied to seven HELM benchmarks spanning general and medical domains:

• MMLU-Pro (multi-task reasoning, 1,000 samples)
• GPQA (graduate-level QA, 446)
• GSM8K (grade-school math, 1,000)
• MedCalc-Bench (clinical calculation, 1,000)
• Medec (error-classification, 597)
• HeadQA (USMLE-style MCQ, 1,000)
• MedBullets (USMLE-style MCQ, 308)

Metrics employed include exact-match and within-range correctness as specified by HELM. For each (model, benchmark, prompt), per-benchmark accuracy and the standard deviation $i$3 across benchmarks are reported. Performance improvements and variability reductions are summarized by macro-averaging across all settings and LMs.

Empirical findings:

• HELM baseline underestimates model performance by $i$4 percentage points (pp) on average.
• Across-benchmark $i$5 shrinks by $i$6 pp with structured prompting.
• Model leaderboards experience rank inversions on 3/7 benchmarks at ceiling (e.g., Claude 3.7 Sonnet surpasses o3 Mini on MMLU-Pro).
• The top-two model gap contracts from $i$7 pp (baseline) to 3 pp (ceiling).

5. Reasoning Elicitation and Robustness Properties

Structured prompting—especially the inclusion of explicit chain-of-thought (CoT) modules—directs the LM to emit a REASONING field prior to OUTPUT, inducing a latent variable $i$8 representing the reasoning trace. Formally, the factorization is: $i$9 and

$p_i$0

Theoretical analysis (via the data-processing and Pinsker’s inequalities) demonstrates that for any two prompts $p_i$1, the distance in predictive distributions is upper-bounded by the divergence in reasoning-trace distributions. Thus, if this divergence is less than half the decision margin $p_i$2—defined as the difference between the highest and next-highest predicted answer probability—the prediction is stable to prompt variations: $p_i$3 CoT enrichment increases $p_i$4 by “averaging” over multiple valid reasoning pathways, thereby improving robustness to prompt formulation. Empirically, CoT configurations exhibit substantially reduced accuracy fluctuation ($p_i$5) across prompt assignments relative to zero-CoT baselines.

6. Implementation, Open-Source Components, and Workflow

Key components include:

• DSPy+HELM integration (HELM PR 3893): Incorporates DSPy execution (dspy.run(\Phi, config)) into HELM’s Python code and benchmarking loop.
• Prompt Optimization Pipeline (github.com/StanfordMIMI/dspy-helm): Automates (a) DSPy program construction seeded from baseline prompts, (b) application of each prompting strategy, (c) model/benchmark/method evaluation, and (d) collection of results in standard HELM reporting format.

A high-level workflow is as follows: $p_i$6 Every pipeline stage—from prompt construction, through automated search, to metrics—operates via DSPy’s declarative API, ensuring full reproducibility. The integration of modular structured prompting and optimization within HELM thereby provides a scalable, systematic estimation of model performance ceilings, supporting more precise and actionable benchmarking outcomes (Aali et al., 25 Nov 2025).