Causal Methods for LLM Development and Evaluation

Modern LLM development relies heavily on large-scale empirical iteration, where engineers make numerous decisions—such as data mixture selection, model routing, and alignment strategies—based on historical logged data. However, these logs are rarely generated through randomized controlled trials. Instead, they reflect past policies, biased human feedback, and evolving user environments. This paper argues that treating these development decisions as causal interventions allows researchers to move beyond simple predictive modeling, which is often fragile in the face of selection bias and spurious correlations.

The authors propose framing LLM development through the potential outcomes framework. By defining a context (e.g., a prompt), a treatment (e.g., a model choice or data mixture), and an outcome (e.g., utility or preference score), developers can formally reason about counterfactuals: what would have happened if a different design choice had been made?

Two core principles of causal inference are central to this approach:

• Identifiability: Determining whether the true effect of a design decision can be recovered from observational data, given specific structural assumptions.
• Estimation: Using techniques like Double Machine Learning (DML) to reliably estimate effects from high-dimensional, noisy data while minimizing bias from nuisance components.

The paper maps these causal methods to several key stages of the LLM lifecycle:

• Pre-training: Optimizing data mixture proportions by modeling downstream performance as a function of corpus weights, potentially reducing the need for exhaustive retraining.
• Alignment: Addressing the limitations of the Bradley-Terry model in preference learning by using robust, semiparametric estimators to account for cyclic preferences or missing-not-at-random data.
• Deployment and Routing: Correcting for confounding in routing systems, where harder queries are systematically assigned to larger models, to ensure that performance comparisons reflect model quality rather than task difficulty.