LLM Search Finds Amplitude Algorithm 805 Times Faster Than Seed Code

A large language model has produced a tree-level scattering-amplitude algorithm that runs 805 times faster than its seed code, according to a preprint from Yi Gu and Sven Krippendorf at the University of Cambridge. The result anchors a proof-of-concept, published on arXiv as Scattering Amplitudes as Programs: Self-Evolving Search for Theory and Event Generation, that has not yet been peer-reviewed.

The timing matters. The High-Luminosity Large Hadron Collider (HL-LHC) is expected to be ready in four years, and its flood of high-precision measurements threatens to outpace theorists' ability to compute predictions. Event probabilities require squaring scattering amplitudes derived from quantum field theory, and those amplitude calculations are computationally expensive. Contemporary algorithms beat Feynman's diagrammatic approach on efficiency, but they took decades to develop. Gu and Krippendorf asked whether LLMs can shortcut that development cycle.

How does the self-evolving search work?

The loop is simple. OpenAI's Codex proposes a candidate program to compute amplitudes. A test program scores the candidate on correctness and efficiency. The LLM sees the evaluation and proposes a new candidate. Iteration does the rest.

Correctness served as a hard gate: an incorrect amplitude was rejected outright. The LLM started from a seed algorithm, with the prompt explaining the test and selection criteria plus suggested ideas for algorithmic improvement. The bet is that because LLMs have absorbed the physics literature, they can propose changes to the underlying algorithmic representation — not just superficial code fixes — and take motivated steps through an enormous space of possible representations.

The researchers deliberately avoided claiming to beat existing amplitude software. They targeted the simplest case, tree-level scattering amplitudes. Quantum corrections involving loops, which behave like higher-order Taylor series terms, dramatically complicate the calculations and sat outside scope.

Which objectives produced which results?

Efficiency needed a quantifiable definition, so the pair tested three objectives rather than one:

• Scaling, measuring computational efficiency.
• Structure, asking whether the search could find cancellations between unphysical singularities.
• Complexity, a cruder metric counting the number of arithmetic operations.

Each objective produced a champion algorithm faster than the seeded code. And each did it differently. The scaling search abandoned its starting formalism entirely, finding one whose costs grow linearly with particle number — for a fixed helicity configuration — at 805 times the seed's speed. The structure search combined terms with spurious boundaries that would ordinarily cancel only at the end of calculations. The complexity search deployed standard algebraic QFT tricks to cut the operation count by a factor of 48.

Notably, none of these techniques were novel. The key takeaway: even when runtime is hidden from the LLM, as in the latter tests, different selection pressures still produce more time-efficient calculations through qualitatively different routes.

How does it compare with Sherpa and MadGraph?

Head-to-head, the results are sobering. For six external particles, the researchers' independent Python prototype ran slower than both Sherpa and MadGraph, the established event generators used across the field. They concede the point, noting the study aimed to test whether AI-driven search could improve a starting algorithm, not outperform compiled generators.

The scope limits run deeper than speed. Unlike Sherpa and MadGraph, the algorithms Gu and Krippendorf developed do not cover the entire standard model. They don't transfer to arbitrary processes, helicities or multiplicities. The authors explicitly state their conclusion is not that existing matrix element calculation software should be replaced.

Their conclusion is narrower: self-evolving search works as a tool, and the significant performance gains in these tests justify further use.

Where does human verification still rule?

Krippendorf is candid about the boundary. "When a problem goes beyond established results and there is no known baseline for comparison – for example in some higher-loop calculations – we currently have to rely on human verification," he said. The method works where a code-improvement task has a fast numerical check, such as an existing codebase. That, he argues, is where the community should try it.

Producing further efficiency gains and generalizing the algorithms will likely require input and collaboration from amplitude theorists, phenomenologists, numerical experts and generator developers — a workforce question labs planning HL-LHC-era theory support may want to factor in.