Spotify/machine-learning

4 posts

spotify

When Can LLMs Replace Humans in A/B Tests? | Spotify Engineering (opens in new tab)

LLMs can approximate human outcomes in A/B tests only when strong assumptions hold; unlike randomized user experiments, those assumptions are not guaranteed by design. In the Upworthy headline dataset, raw GPT-4o-mini predictions recovered just 39% of the human treatment effect, but appropriate calibration and repeated sampling substantially improved accuracy. However, the assumptions are hardest to justify for genuinely new products or interventions—the cases where replacing human tests would be most valuable. ## Raw LLM Predictions Underestimate Treatment Effects - Researchers used the Upworthy Research Archive, containing click-through rates from thousands of headline experiments. - GPT-4o-mini predicted click-through rates for treatment and control headlines. - Treating those predictions as human outcomes recovered only 39% of the observed human treatment effect. - The error was systematic rather than random: LLM predictions attenuated effects toward zero. - This could lead companies to underestimate product improvements and make poor shipping decisions. ## Conditions for Valid LLM Surrogates Two assumptions are required: - **Surrogacy:** LLM predictions must capture everything about a treatment that affects human behavior. Once predictions and relevant pre-treatment characteristics are accounted for, treatment assignment should provide no additional information about the human outcome. - **Comparability:** The relationship between LLM predictions and human behavior—the calibration function—must remain stable between historical experiments and the new experiment. - If either condition fails, more LLM samples will not solve the problem; the procedure estimates an effect on the model rather than the effect on users. ## Calibration Methods Matter - Linear calibration with ordinary least squares failed a falsification test, producing estimates 3.8 standard errors away from the human benchmark. - Random forests and gradient-boosted trees performed better because they could model nonlinear relationships between LLM predictions and human click behavior. - Repeatedly sampling the LLM and averaging its outputs reduces temperature-driven noise, lowering bias toward zero and reducing variance. ## Limits for New Interventions - Historical data can partially test surrogacy and comparability, but neither assumption can be verified for a treatment never previously tested. - Trust declines as a new treatment becomes more different from past experiments. - The Upworthy setting is unusually favorable: binary outcomes, text-only treatments, similar headline variants, and an LLM trained on extensive textual data. - These assumptions are much less plausible for changes to layouts, recommendation algorithms, pricing, or entirely new product concepts. Human A/B tests remain essential for genuine product innovation. LLM-based testing is most defensible for incremental changes that resemble well-understood historical treatments, with human experiments used to validate the approach and calibrate its predictions.

spotify

Better Experiments with LLM Evals — A funnel, not a fork | Spotify Engineering (opens in new tab)

LLM evaluations and A/B experiments serve different purposes and should work as a funnel rather than alternatives. Evals verify whether a change meets qualitative standards and filter out weak ideas, while experiments validate whether it improves real user and business outcomes. Their greatest value comes from a feedback loop that continuously calibrates eval scores against online results. ## Evals as Verification, Experiments as Validation - LLM judges can assess relevance, coherence, tone, intent alignment, and other qualities at scale. - Evals identify promising candidates before they consume experiment capacity. - Experiments determine whether users actually respond better to the change. - An eval can uncover unexpected failure patterns, guide product fixes, and later verify that violations have decreased. - It cannot establish whether those fixes improve long-term outcomes such as engagement, trust, or retention. ## The Importance of Guardrails - Evals typically measure selected quality dimensions, not every possible business risk. - Spotify reports that roughly 42% of launched experiments are rolled back because of regressions in secondary metrics such as crashes, session length, or retention. - Online experiments expose production effects and monitor guardrail metrics that offline evals may miss. - Although only about 12% of Spotify’s A/B tests produce a shipped positive result, approximately 64% generate useful learning. ## Calibrating Evals Against Outcomes - Evals are proxies, so their scores must be validated against the outcomes they are intended to predict. - LLM judges introduce an additional calibration layer on top of conventional metrics such as precision, recall, and ranking scores. - Judges can reward superficial patterns or miss improvements that matter in real-world use. For example, Qodo’s coding evals did not detect improvements in Anthropic’s Opus 4.5 on longer tasks. - Both judges and quantitative metrics can drift, making offline-to-online comparison essential. - Continuous calibration clarifies when evals are reliable verification tools and whether they may eventually become strong enough to support validation. ## Closing the Evaluation Loop - Run evals early and frequently to select the strongest treatments. - Use experiments to confirm user impact, assess business outcomes, and detect unintended regressions. - Apply the same LLM evals to A/B test data to compare qualitative scores with actual user results. - A mismatch between eval scores and experiment outcomes is valuable diagnostic information: - Improved scores and improved outcomes validate the judge. - Improved scores without better outcomes show that the judge is measuring something that may not drive value. - Use lightweight experiments for iteration and learning, and more rigorous tests for launch decisions. The practical recommendation is to treat LLM evals as an upstream filter and a downstream calibration tool—not a replacement for experimentation. This funnel improves test efficiency while making both the judges and product decisions more trustworthy over time.

spotify

Why We Use Separate Tech Stacks for Personalization and Experimentation | Spotify Engineering (opens in new tab)

Personalization and experimentation overlap, especially with contextual bandits, but they serve different purposes. Personalization chooses the best experience for each user, while experimentation evaluates whether a system or product change improves outcomes overall. Spotify therefore keeps personalization in its ML stack and uses its experimentation platform, Confidence, to measure the impact of those systems. ## What Personalization Does - Personalization adapts products to individual users instead of optimizing for an “average” user. - Spotify uses it for: - Personalized playlists and discovery recommendations - Search results based on listening and search history - Home-screen shortcuts tailored to user behavior - Recommendation systems use models ranging from regression and random forests to neural networks, LLMs, and reinforcement learning. - These systems combine user characteristics, historical behavior, and real-time context to select recommendations and improve them from user responses. ## Where Experimentation and Personalization Overlap - Traditional A/B tests randomly assign users to variants and identify the best option on average. - Multi-armed bandits adapt traffic allocation, sending more users to better-performing treatments. - Contextual bandits use user features to select different treatments for different users. - This creates a conceptual transition: - A/B tests seek the best average treatment. - Multi-armed bandits efficiently find the best average treatment. - Contextual bandits seek the best treatment for each user or context. - Once contextual information determines treatment assignment, the goal is no longer simply measuring one variant’s average effect. - The relevant comparison becomes the value of the personalization system versus a static treatment or an earlier personalization system. ## Why Contextual Bandits Are Not Experimentation Platforms - A contextual bandit can personalize a checkout button based on factors such as cart contents, age, and location. - The bandit is itself a product feature or recommendation system, not the experiment used to evaluate it. - Teams still need experiments to compare different versions of the bandit and determine whether personalization improves user outcomes. - Measuring average or conditional treatment effects may be less important than evaluating the overall benefit of the personalization system. ## Why Spotify Separates the Stacks - Personalization systems require specialized ML infrastructure for: - Training diverse model types - Managing rich feature sets - Serving models with low latency - Collecting real-time data - Computing recommendations at request time - Putting these capabilities into experimentation tools would either greatly expand their scope or limit the sophistication of personalization. - Combining unrelated responsibilities can create technical debt and operational complexity. - Spotify’s ML platform standardizes the development and deployment of personalization systems. - Its experimentation platform, Confidence, evaluates those systems alongside thousands of other product experiments. ## How the Systems Work Together - Personalization algorithms, including contextual bandits, remain in the ML stack. - The experimentation stack treats a personalization system as a treatment to be evaluated. - This separation lets teams improve recommendation logic independently while using controlled experiments to measure its product impact. - It also avoids confusing dependencies that arise when a bandit is both the experiment mechanism and the system being evaluated. Spotify’s approach is to separate building personalized experiences from measuring their effectiveness. Teams should use ML infrastructure for model development and real-time decision-making, then use an experimentation platform to compare personalization systems and quantify their impact.

spotify

Our Multi-Agent Architecture for Smarter Advertising | Spotify Engineering (opens in new tab)

The post argues that fragmented advertising workflows, not backend infrastructure, are the core problem. Although buying channels share services and data, their planning and optimization logic is repeatedly reimplemented across channels and surfaces, causing drift and technical debt. The proposed solution is a shared agentic decision layer that interprets advertiser goals, orchestrates existing Ads APIs, and applies consistent reasoning across products. ## Fragmented Workflows Across a Shared Backend - Direct, Self-Serve, and Programmatic buying use largely consolidated infrastructure but retain different workflows and decision logic. - Spotify Ads Manager, Salesforce, Slack, and internal tools contain overlapping automation. - Budget allocation, inventory selection, reach, efficiency, and STR decisions are repeatedly implemented in different places. - Incremental workflow changes therefore create duplicated maintenance work and inconsistent behavior. ## Why Conventional Workflow Services Fall Short - Hard-coded state machines and REST services are poorly suited to combinatorial planning tasks. - Campaign planning depends on: - User and advertiser characteristics - Available inventory and audiences - Business priorities - Forecasts, performance, and optimization goals - A workflow optimized for one channel or “happy path” will not adapt well as requirements change. - Improvements to decision logic must be replicated across every product surface, increasing the risk of divergence. ## The Missing Intent Layer - Existing systems can perform individual actions such as creating line items, running forecasts, and retrieving insights. - They do not consistently translate high-level objectives into: - A sequence of tool calls - Explicit tradeoffs - Validation and safety checks - An objective such as maximizing reach in Brazil while protecting video inventory and meeting STR requires coordinated reasoning across multiple capabilities. ## A Modular Agentic Architecture - Campaign planning and management are modeled as cooperating specialized agents. - Agents use shared signals, including: - Inventory - Audiences - STR - Quality and risk - Historical performance - They jointly optimize advertiser goals and Spotify’s business constraints. - Existing Ads services become tools that agents orchestrate, rather than capabilities being rebuilt in each workflow. - A long-running orchestration layer delegates tasks while agents share context and evaluation logic. - The same decision engine can support every buying channel and surface. ## Engineering Implications - APIs need to be designed as agent tools, rather than only as CRUD interfaces. - Testing must include behavioral evaluation in addition to unit and integration tests. - Observability should explain what an agent decided and why, not merely track latency and errors. - Safety requires guardrails for semi-autonomous decisions, beyond ordinary input validation. - The approach avoids both duplicated deterministic workflows and a brittle, centralized rules engine for probabilistic, ML-heavy advertising logic. The overall recommendation is to centralize campaign decision-making in a reusable agentic platform while keeping existing services as specialized tools. This should reduce duplicated workflow logic, make improvements consistent across products, and allow advertising workflows to evolve without repeatedly rebuilding them.