Thought Leaders

Forty Million Collisions a Second: Building an AI to Decide What the LHC Keeps

Thought LeadersYuxin ChenAssistant Professor & Computer ScientistUniversity of Chicago

At the Large Hadron Collider (LHC), 40 million collisions occur every second, but we can store only a few thousand. Choosing which events to keep is irreversible, and shifting beam conditions mean the right decision threshold rarely holds for long.

In this interview, University of Chicago computer scientist Yuxin Chen explains how his team developed Group-Filtered Policy Optimization, a reinforcement learning method that learns only from actions that satisfy the trigger’s operating constraints. He explains why conventional methods can fail when every available option is poor, how the team transferred a simulation-trained policy to real CMS collision data, and why the same feasibility-first approach could help manage alert budgets in cybersecurity, fraud detection, clinical systems, and industrial monitoring.

Could you briefly describe your role in this collaboration and how the partnership around the Large Hadron Collider (LHC) trigger problem came together?

I lead the machine learning side of the collaboration at UChicago and advise my (former) PhD student, Zixin Ding, who drove this work. The physics side is led by Prof. David Miller here in the Department of Physics, together with colleagues at the University of Michigan and at Fermilab.

The partnership predates this paper. An earlier project led by Michigan Ph.D. student Shaghayegh Emami, what the team calls the self-driving trigger, showed that adaptive methods could help trigger systems track changing conditions, and won a poster award at the Fast Machine Learning for Science conference in 2024. That work established the vision; this paper asks which learning algorithm can actually be trusted to carry it out on a real instrument. The collaboration works because neither side treats the other as a service desk: the physicists shaped the constraints the algorithm had to respect, and those constraints shaped the algorithm.

A picture of the Large Hadron Collider

Image Credit: Richard Juilliart/Shutterstock.com

Can you explain what the LHC trigger challenge is, and why is it so difficult to decide in real time which collision events to keep?

The LHC produces collisions forty million times per second, and we can only afford to store a few thousand of those. The trigger system decides, in real time, which collisions to keep and which to throw away forever. A discarded collision is gone for good.

The decision comes down to thresholds: keep an event if a quantity, such as the total energy deposited, exceeds a set cut. If the cut is too loose, it overwhelms storage and readout; if it is too tight, it discards precisely the rare events the machine was built to find. The difficulty is that the right setting does not stay fixed. Beam intensity decays over a run, pileup falls with it, and background distributions drift. Today, experts manually retune the system between runs. Any event lost while the menu is out of tolerance cannot be recovered later.

Download the PDF of this interview here

How does Group-Filtered Policy Optimization differ from conventional reinforcement learning or policy optimization methods?

Conventional group-based methods such as GRPO, widely used in large language model training, offer a prominent example. They sample a group of candidate actions and reinforce those that score above the group average.

That works until conditions shift and the entire group performs poorly. On about 30% of our steps, none of the sampled candidates kept the trigger rate within its tolerance band. GRPO still reinforces the least-bad option in the group, even if that option violates the constraint, pushing the policy further out of band. This is a structural failure. Classical constrained reinforcement learning algorithms do not resolve it because they modify the objective or parameter update, not the set of actions the policy learns from.

GFPO takes a different approach. Before asking, “Which sampled action was best?” it asks, “Which sampled actions were acceptable at all?” We sample a larger group, filter it to retain only candidates that keep the rate within tolerance, and then make the relative comparison within that filtered set. If no candidate is feasible, we skip the update rather than reinforce a violation. We call this shielding. Infeasible actions never produce a positive learning signal.

That single change gave us tighter rate control and higher signal efficiency at the same time

How did you design the method to transfer from simulations to real CMS collision data without additional fine-tuning?

We started from the hard requirement: gradient updates inside a running trigger system are not an option, so whatever we trained had to be frozen before deployment. Therefore, we had to directly transfer the model. 

There were three design choices. First, the policy's inputs are relative rather than absolute - the shape of the score distribution near the current cut, the rate measured against its target, the recent history of changes - so what has to transfer is the geometry of the control problem, not detector-specific details that simulation gets wrong. 

Second, we trained across widely varied simulated conditions, so the policy knows drift rather than being surprised by it. 

Third, actions are bounded threshold moves with shielding on top, which caps the worst case even when the policy is uncertain. 

With this setup, we obtain an adaptive policy trained purely on simulation, frozen, and deployed on real CMS collision data with no fine-tuning. The in-tolerance fraction improved by 56% on the energy trigger and 28% on the anomaly-detection trigger over the baselines, with signal-efficiency gains on both.

A picture of the LHC in Geneva

Image Credit: Diego Grandi/Shutterstock.com

What trade-offs or unexpected behaviors did you see when balancing keeping the trigger in its operation range while preserving rare events?

We explored the trade-offs through variants of the proposed method. 

One filters strictly by rate error and gives the tightest rate control. The other first filters for feasibility, then ranks the surviving candidates by signal efficiency, buying more signal at a small, controlled rate cost. Operators can choose where on that dial to sit.

The surprises were more interesting. The first was how often the no-feasible-candidate situation arises - roughly 30% of steps under realistic drift - which is why methods that never anticipate it collapse. 

The second was that enforcing feasibility improved signal efficiency: a policy that drifts out of band wastes bandwidth on background, and every background event accepted displaces a signal event permanently. We also learned to penalize jitter - a controller that technically stays in band while thrashing the threshold is not something you want near a detector.

How could Group-Filtered Policy Optimization be adapted for future LHC upgrades, other detectors, or high-stakes applications beyond particle physics?

The method is trigger-agnostic by design. We evaluated it on a classic total-energy trigger and on an autoencoder-based anomaly-detection trigger - the traditional and the data-driven ends of a trigger menu - and it worked on both. This is highly promising for real-world applications: the High-Luminosity LHC brings higher pileup, faster drift, and more ML-based triggers whose score distributions shift with detector conditions, which is exactly the regime this method is built for. 

The underlying structure is fairly general: a score is thresholded to keep or discard an event, the score distribution drifts, and there is a tight budget on how much the system can accept. We tested the same idea in network intrusion detection, where the budget is the number of alerts a security team can triage, and found the same failure mode and the same fix. Fraud detection, clinical alerting, and industrial monitoring share this structure. The feasibility-first learning approach applies wherever these three conditions hold.

How do you see the role of AI evolving, and what collaborations or skills will matter most for young researchers entering the field?

The shift I find most consequential is AI moving from analyzing scientific data offline to operating scientific instruments in the loop. That changes what was typically recognized as a good method. In the loop, the binding problems are constraints and trust, not model capacity. I expect the most valuable work in AI+science over the next decade to look like this: feasibility first, and performance comes after.

I think the following two things are important for young researchers: 

First, fundamentals deep enough to diagnose failure (simply measuring it is insufficient). The method in this paper came directly from understanding why the standard approaches broke, and that kind of failure analysis travels far beyond any one application. 

Second, enough fluency in a partner domain to know which constraints are physical and which are habits. The collaborations that produce real results are long-term and embedded - students like Zixin and Shaghayegh working across both communities for years - not a handoff where one side generates data and the other runs models. Neither side should be a service to the other; the best problems live exactly at the interface.

We recently explored how AI is also helping cataloging the Martian craters

About the Speaker

Yuxin Chen is an assistant professor of computer science at the University of Chicago. Previously, Chen was a postdoctoral scholar in the Department of Computing and Mathematical Sciences at the California Institute of Technology (Caltech). Prior to Caltech, he received his Ph.D. in computer science from ETH Zurich in 2017. His research interest lies broadly in probabilistic reasoning and machine learning. He was a recipient of the Google European Doctoral Fellowship in Interactive Machine Learning, the Swiss SNSF Early Postdoc.Mobility Fellowship, and the PIMCO Postdoctoral Fellowship in Data Science.

Disclaimer: The views expressed here are those of the interviewee and do not necessarily represent the views of AZoM.com Limited (T/A) AZoNetwork, the owner and operator of this website. This disclaimer forms part of the Terms and Conditions of use of this website.

Louis Castel

Written by

Louis Castel

Louis graduated with a Master’s degree in Translation and Intercultural Management in Paris, before moving to Tokyo and finally Manchester. He went on to work in Communications and Account Management before joining AZoNetwork as an Editorial Account Manager. He spends a lot of his free time discovering all the hiking paths the UK has to offer and has a passion for wild swimming and camping. His other hobbies include traveling, learning new languages, and reading as much as he can.

Citations

Please use one of the following formats to cite this article in your essay, paper or report:

  • APA

    Castel, Louis. (2026, November 03). Forty Million Collisions a Second: Building an AI to Decide What the LHC Keeps. AZoQuantum. Retrieved on November 03, 2026 from https://www.azoquantum.com/Article.aspx?ArticleID=761.

  • MLA

    Castel, Louis. "Forty Million Collisions a Second: Building an AI to Decide What the LHC Keeps". AZoQuantum. 03 November 2026. <https://www.azoquantum.com/Article.aspx?ArticleID=761>.

  • Chicago

    Castel, Louis. "Forty Million Collisions a Second: Building an AI to Decide What the LHC Keeps". AZoQuantum. https://www.azoquantum.com/Article.aspx?ArticleID=761. (accessed November 03, 2026).

  • Harvard

    Castel, Louis. 2026. Forty Million Collisions a Second: Building an AI to Decide What the LHC Keeps. AZoQuantum, viewed 03 November 2026, https://www.azoquantum.com/Article.aspx?ArticleID=761.

Tell Us What You Think

Do you have a review, update or anything you would like to add to this article?

Leave your feedback
Your comment type
Submit

While we only use edited and approved content for Azthena answers, it may on occasions provide incorrect responses. Please confirm any data provided with the related suppliers or authors. We do not provide medical advice, if you search for medical information you must always consult a medical professional before acting on any information provided.

Your questions, but not your email details will be shared with OpenAI and retained for 30 days in accordance with their privacy principles.

Please do not ask questions that use sensitive or confidential information.

Read the full Terms & Conditions.