EvoSignal: LLM-Guided Evolutionary Design of Modular Traffic Signal Control Programs

arXiv:2610.09563 · cs.LG · Submitted 2026-10-07 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: I'm Tom, and with me are Jane, Lu, senior AI researcher at Tsinghua, Meng, lead engineer at a mysterious AI startup and Lalam, the in-house Large Language Model.

Jane: Today's paper: "EvoSignal: LLM-Guided Evolutionary Design of Modular Traffic Signal Control Programs".

Tom: The gist The selected default EvoSignal program reduces waiting time by 16.8–49.2% relative to the lowest waiting time achieved by the 20 conventional, reinforcement learning-based,

Jane: First, who's behind it and why it matters.

Paper summary: Tom: Welcome back everyone. Today we're looking at a paper called "EvoSignal: LLM-Guided Evolutionary Design of Modular Traffic Signal Control Programs". Basically, the researchers are tackling how to design traffic signals that actually work well under changing conditions without needing constant manual tweaking.

Jane: That’s right Tom. The core idea here is to look at traffic signal control as a modular program design problem where you map traffic observations directly to phase decisions under specific control goals. They claim that this approach lets us systematically explore better control rules for a target network, which is tough with existing methods <ref:2610.09563#pg4>.

Lu: What’s really interesting about their setup is how they separate the control logic into three distinct modules: traffic feature extraction, local phase prioritization, and optional network-based priority adjustment <ref:2610.09563#pg8>. This modular view means you can target exactly what needs revising.

Meng: So, if we're thinking practically, what's the big goal of EvoSignal? What are they trying to prove by using this evolutionary framework with the LLM component?

Lalam: The main contribution is developing EvoSignal, which is an evolutionary framework that combines multiple initial control strategies with diagnostic feedback on traffic control performance and strategy reuse <ref:2610.09563#pg9>. This allows them to guide the revision of a candidate program using LLM capabilities without requiring online inference for the actual signal decisions <ref:2610.09563#pg9>.

Tom: That’s a big deal because most AI approaches use the LLM just to reason about what should happen, but EvoSignal seems to keep the actual decision rules explicit and executable, which means we can inspect them <ref:2610.09563#pg8>.

Jane: Exactly. They are using Multi-init to supply programs based on established control strategies and complementary design principles, and then the LLM uses those inputs to revise candidate programs whose measured control performance guides further evolution <ref:2610.09563#pg10>. It’s a closed loop of testing and improving the program design offline.

Lu: The way they structure it is really clever because the traffic environment modular control program p separates traffic feature extraction, local phase prioritization, and network-based priority adjustment <ref:2610.09563#pg8>. The first module extracts movement-level observations into features like pressure and waiting demand <ref:2610.09563#pg8>.

Meng: So, the system first does this extraction, then the local phase prioritization assigns a base score qk to each phase using those extracted features <ref:2610.09563#pg8>. What happens next in that process?

Paper summary: Jane: Then module M3 computes a value rk from the traffic context and those extracted features to adjust that local preference based on conditions beyond the current intersection <ref:2610.09563#pg8>. The final phase priorities are then determined by an equation where safe clips scores to a configured range before selection <ref:2610.09563#pg8>.

Tom: The objective they’re trying to maximize is this bounded scalar score S(p) which is the sum over all traffic types and waiting times divided by one plus the phase feature value divided by some constant Cj <ref:2610.09563#pg9>. It sounds like they are optimizing for a balance of things.

Lu: The search aims to find the maximum p in Π S(p), which means they are searching through a set of possible programs to find the best one <ref:2610.09563#pg9>. They’re also evaluating performance using travel time, queue length, and waiting time, all minimized <ref:2610.09563#pg9>.

Meng: So for someone who just drives or walks around town, what does this mean in terms of what we actually see? Does this mean faster lights or smoother flow?

Jane: It means they found a program that performs better than twenty reference controllers across five different scenarios on two real-world road networks <ref:2610.09563#pg3>. They show that a program evolved in one scenario transfers unchanged to the other four, ranking among the top three on travel time, queue length, and waiting time against those references <ref:2610.09563#pg3>.

Tom: That consistency across different conditions is what’s hard to achieve with most AI systems. It’s not just good in one specific test case.

Lu: They also showed that when you look at the components, without the three modules M1, M2 and M3, a monolithic controller reaches a similar best single-run score to the full EvoSignal but has a lower mean score and substantially greater variation across runs <ref:2610.09563#pg18>.

Meng: That suggests that separating those modules isn't just academic; it actually helps stabilize the performance of the resulting control rules in practice. What’s the practical implication for deploying this kind of control system?

Jane: The real implication is that you can have an automated design process where you start with known strategies, and then use traffic knowledge and performance feedback to iteratively refine a program without needing constant, slow human intervention <ref:2610.09563#pg3>.

Tom: So we’re looking at a system where the control rules are explicit so they can be inspected and executed directly from traffic observations, rather than being locked inside some black-box model parameters <ref:2610.09563#pg8>.

Lu: That’s the central point of their contribution, showing that this modular representation allows for targeted revision and inspection of the control logic <ref:2610.09563#pg4>. It makes the control logic reflect available traffic information through explicit interfaces <ref:2610.09563#pg8>.

Paper summary: Meng: So, even though they use an LLM to guide the design, the final program that runs in traffic doesn't need that LLM running online for every single decision <ref:2610.09563#pg9>. That makes it much more feasible for real-world deployment <ref:2610.09563#pg8>.

Lalam: The LLM computation is concentrated in the offline design stage, while repeated control decisions execute explicit rules directly from traffic observations <ref:2610.09563#pg8>. This separation of compute and execution is what makes this framework distinct from other methods <ref:2610.09563#pg2>.

Tom: It means the complexity of reasoning about control strategies happens once, during the design phase, but the actual real-time control is just running defined rules against what’s happening now <ref:2610.09563#pg8>.

Jane: So, looking at this paper on EvoSignal: LLM-Guided Evolutionary Design of Modular Traffic Signal Control Programs, the authors are showing how to use AI to design explicit control programs that can be rigorously tested and improved using feedback from real traffic performance <ref:2610.09563#pg9>.

Lu: And the results show that this approach doesn't just find a good solution for one test, but it finds a program that is robust across different road networks and demands <ref:2610.09563#pg3>.

Meng: For me, the implication is that we can move toward automated design where we don't need to manually code every single rule from scratch for new situations <ref:2610.09563#pg8>.

Jane: It suggests that having a framework that handles feature extraction, prioritization, and network adjustment separately gives us much more control over the outcome than just feeding raw traffic data into a single large model <ref:2610.09563#pg8>.

Tom: So when you think about this paper's title and what it does, EvoSignal is basically a system that uses an LLM to guide the evolution of modular control programs for traffic signals <ref:2610.09563#pg1>. It’s about using AI to build better, more inspectable traffic control software that performs well across different conditions <ref:2610.09563#pg3>.

Lu: It shows how combining explicit control rules with an iterative evolutionary design process guided by LLM knowledge can lead to competitive performance against existing RL and LLM-based controllers <ref:2610.09563#pg3>.

Meng: The practical impact is that we get a system where the control logic is transparent enough for engineers to verify its suitability against intended objectives and operating conditions <ref:2610.09563#pg8>.

Jane: So, this work points toward automated design of explicit traffic control rules where their suitability can be assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. That’s what we've covered about EvoSignal for today.

Conclusion: Tom: So, EvoSignal is this framework that uses an LLM to guide the design of modular traffic signal control programs <ref:2610.09563#pg1>.

Jane: It’s about taking those traffic rules and evolving them iteratively using performance feedback from real traffic data <ref:2610.09563#pg9>.

Tom: The authors are showing how this modular approach, with its three separate modules for feature extraction, local prioritization, and network adjustment <ref:2610.09563#pg8>, helps create rules that actually work better than the existing state-of-the-art controllers <ref:2610.09563#pg3>.

Jane: They achieved a reduction in waiting time, specifically by sixteen point eight to forty-nine point two percent relative to the best results from twenty other reference controllers in five different traffic scenarios <ref:2610.09563#pg9>.

Lu: The paper’s main idea is that you can keep the control rules explicit, so you can actually inspect them, and then use the AI to revise those rules offline <ref:2610.09563#pg8>.

Meng: That means we aren't just getting a black box decision; we get a program where the logic is visible and traceable <ref:2610.09563#pg8>.

Lalam: The vision here is that this design process can help us build control systems that are not only highly performant but also transparent enough for engineers to verify their suitability against the intended objectives <ref:2610.09563#pg8>.

Tom: So, the big picture here is using AI not just to find a solution, but to systematically engineer a better traffic control program from scratch <ref:2610.09563#pg1>.

Jane: It shows that combining an evolutionary search with an LLM’s ability to suggest revisions can lead to control rules that are robust and perform well across different conditions <ref:2610.09563#pg3>.

Tom: We've seen how the authors set up this modular system, so now let's talk about where this could go next for traffic management.

Monash University · KTH Royal Institute of Technology

cs.LG

Submitted: 2026-10-07

Updated: 2026-10-11

Code: https://github.com/georgewanglz2019/EvoSignal

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 83/100

The gist: The gist The selected default EvoSignal program reduces waiting time by 16.8–49.2% relative to the lowest waiting time achieved by the 20 conventional, reinforcement learning-based, and LLM-based

Key concepts

Modular Control Program
Traffic signal control is treated like a software design problem split into three distinct parts: feature extraction (M1), local prioritization (M2), and network adjustment (M3). This modular approach allows the control logic to clearly separate how traffic data is understood from how signal phases are decided, making the system easier to build and understand.
Revision–Evaluation Loop
The framework uses an iterative process where initial programs are generated using established strategies. An LLM then revises these candidates based on measured control performance (like waiting time). This feedback loop drives the evolution of the program, ensuring that each generation improves its traffic management capabilities.
Traffic Environment Modular Control Program
This is the core design where M1 extracts features like demand and congestion, M2 assigns a base score to phases, and M3 makes local adjustments based on wider network context. The goal is to maximize a specific objective function by finding the best combination of these modules for optimal traffic flow.
Executable Policy
The final output of the EvoSignal process is an executable program that directly maps real-time traffic observations to signal phase decisions. This means the control rules are fixed and ready to run on a live system, eliminating the need for online LLM inference during actual traffic control.

Terminology

Summary

The gist The selected default EvoSignal program reduces waiting time by 16.8–49.2% relative to the lowest waiting time achieved by the 20 conventional, reinforcement learning-based, and LLM-based baselines in each scenario <ref:2610.09563#pg2>.

How it works

The paper formulates Traffic Signal Control (TSC) as a modular program design problem where an executable policy maps traffic observations to signal phase decisions under specified control objectives <ref:2610.09563#pg4>. This representation separates the control logic into three modules: traffic feature extraction (M1), local phase prioritization (M2), and optional network-based priority adjustment (M3) <ref:2610.09563#pg8>. The modular representation allows the control logic to reflect the available traffic information through explicit interfaces <ref:2610.09563#pg8>.

The EvoSignal framework guides this design through a revision–evaluation loop involving multiple components <ref:2610.09563#pg9>. This framework utilizes Multi-init to supply programs based on established control strategies and complementary design principles <ref:2610.09563#pg10>. The LLM uses these inputs to revise candidate programs, whose measured control performance guides further evolution <ref:2610.09563#pg9>. The resulting programs operate without online LLM inference, as the selected program determines signal phases directly from traffic observations <ref:2610.09563#pg9>.

Key Components of EvoSignal

The framework consists of several interconnected components that guide the evolutionary process <ref:2610.09563#pg9>.

**- Traffic environment Modular control program p separates traffic feature extraction (M1), local phase prioritization (M2), and network-based priority adjustment (M3) <ref:2610.09563#pg8>. M1 transforms movement-level observations into features for phase selection, such as pressure, waiting and approaching demand, downstream congestion, and service history <ref:2610.09563#pg8>. M2 assigns a base score qk to each phase using the extracted features <ref:2610.09563#pg8>. M3 computes rk from the traffic context and extracted features to adjust a local phase preference in response to conditions beyond the current intersection <ref:2610.09563#pg8>. The final phase priorities are determined by Eq. (6) where safe clips scores to the configured range and replaces nonfinite values before selection <ref:2610.09563#pg8>. The design objective is maximizing the bounded scalar score S(p) = ∑ j∈T,Q,W wj / (1+ fj(p)/Cj) <ref:2610.09563#pg9>. The search aims to find max p∈Π S(p) <ref:2610.09563#pg9>. The database D stores code, parent identities, execution status, and evaluation records <ref:2610.09563#pg10>. The PSA retains module summaries and measured outcomes from recently evaluated strategies with different performance trade-offs <ref:2610.09563#pg10>. The LLM uses these inputs to revise candidate programs, whose measured control performance guides further evolution <ref:2610.09563#pg9>. The feedback consists of traffic observations and performance measurements <ref:2610.09563#pg9>. The selected program subsequently determines signal phases directly from traffic observations <ref:2610.09563#pg9>. The control rules are available for inspection, as the executable policy maps traffic observations to signal phase decisions under specified control objectives <ref:2610.09563#pg8>. The program code stays fixed during execution while its decisions respond to changing traffic conditions <ref:2610.09563#pg8>. The design variables are the executable implementations of F1,F2,F3, including their feature computations, scoring expressions, conditional logic, and numerical coefficients <ref:2610.09563#pg9>. The priority sk determines which phase to serve at one decision step <ref:2610.09563#pg8>. The performance is evaluated using travel time (TT), queue length (QL), and waiting time (WT), all minimized <ref:2610.09563#pg9>. The search uses a specified scenario and fixed objective weights, and reuse under other networks and demands is evaluated separately <ref:2610.09563#pg9>. The resulting rules can be inspected and executed without online LLM inference <ref:2610.09563#pg8>. The components address different needs in automated traffic control design, with 3M separating processing from prioritization and adjustment <ref:2610.09563#pg8>. Multi-init supplies several established control ideas as executable starting points <ref:2610.09563#pg8>. SPA helps identify traffic conditions and service patterns that require attention <ref:2610.09563#pg9>. PSA makes earlier strategies and their measured trade-offs available for reuse <ref:2610.09563#pg9>. Together, these components guide the generation and evaluation of control rules whose source code remains available for inspection <ref:2610.09563#pg8>. The selected program uses current traffic observations to choose signal phases without online LLM inference <ref:2610.09563#pg9>. The LLM computation is concentrated in the offline design stage, while repeated control decisions execute explicit rules <ref:2610.09563#pg8>. The experiments demonstrate traffic performance and traceable changes to these rules <ref:2610.09563#pg9>. The final results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>. With greater emphasis on TT and QL, the framework produces a program that outperforms all references on all three metrics in J1 and ranks within the top three on every metric across all five scenarios without further revision <ref:2610.09563#pg9>. The ablations show the roles of the four components, demonstrating that Without 3M, the monolithic controller reaches a similar best single-run score to full EvoSignal but has a lower mean score and substantially greater variation across runs <ref:2610.09563#pg18>. The final results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>. The results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>. The results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>. The results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>. The results support automated design of explicit traffic control rules with their suitability assessed against the intended objectives and operating conditions <ref:2610.09563#pg8>. The selected program reduces WT by 16.8–49.2% relative to the lowest WT achieved by the 20 reference controllers in each of the five scenarios <ref:2610.09563#pg9>.

Improvements for AI systems

  1. Modular program design enables targeted revision of control logic by separating traffic feature extraction, local phase prioritization, and optional network-based priority adjustment, allowing the control logic to reflect the available traffic information.

  2. EvoSignal leverages a three-module representation (3M) where M1 performs Traffic feature extraction, M2 handles Local phase prioritization, and M3 manages Network-based priority adjustment to structure the executable policy.

  3. The system utilizes a feedback loop where the LLM revises candidate programs using inputs like traffic observations, performance measurements, and strategy summaries: The LLM uses these inputs to revise candidate programs.

  4. Multi-strategy initialization (Multi-init) allows for diversification of decision rules by supplying programs based on established control strategies and complementary design principles, such as Pressure–demand Pressure and demand or Fairness-aware Service fairness.

  5. The system employs a Simulation Performance Analyzer (SPA) to provide diagnostic feedback, such as the report stating, The report suggests directions such as checking phase-continuation rules, demand–priority alignment, or service under late congestion, guiding LLM revisions.

  6. A Pareto Strategy Archive (PSA) stores trade-offs by retaining module summaries and measured outcomes from recent successful evaluations to inform revisions with the record: The PSA provides strategy information for revision; parent and final-program selection continue to follow the database rules.

  7. The resulting control programs operate without online LLM inference, meaning they execute explicit code, while the LLM computation is concentrated in the offline design stage, addressing concerns about recurring inference costs and latency.

  8. The framework supports automated design of inspectable control programs, as it allows for program revision where the system performs edits on code based on feedback from diagnostics and archived strategies.

Sources

Related papers