A method for constructing an intelligent decision system for traffic signal control

Abstract

The application discloses a kind of intelligent decision system construction methods for traffic signal control.The method includes model training and deployment phase and application and evolution phase two parts, as follows: model training and deployment phase: S1, based on pre-stored road traffic conflict rules, generate traffic state structured data and the pairing training sample set of no conflict signal control instruction;Supervised fine-tuning is carried out to large language model using the pairing training sample set, and a basic model is obtained;S2, the basic model is accessed to traffic simulation environment and is reinforced learning training;In each training step, the basic model outputs signal control instruction according to current traffic state, and safety verification is carried out to the instruction according to the road traffic conflict rule, and generates safety reward signal, etc.The application constructs a safe and reliable, continuous evolution, and suitable for edge independent deployment traffic signal intelligent decision system.

Description

Technical Field

[0001] This invention relates to the field of traffic signal control technology, and in particular to a method for constructing an intelligent decision-making system for traffic signal control. Background Technology

[0002] Traditional and existing adaptive traffic signal control technologies have limitations in terms of perception cost, decision intelligence, and system real-time performance, making it difficult to meet the needs of modern intelligent transportation for refined and dynamic management.

[0003] Specifically: 1) The perception layer relies on multi-sensor fusion, which makes the system complex, costly and subject to environmental constraints; 2) The decision layer often adopts reinforcement learning based on fixed optimization objectives, which has a limited policy space, cannot understand the semantics of complex scenarios, and is rigid in dealing with emergencies; 3) The system layer often adopts a cloud-based collaborative architecture, which has prominent network latency and reliability risks.

[0004] To enhance decision-making intelligence, the industry has begun exploring the introduction of large-scale language models. LLMs, with their powerful semantic understanding and generative capabilities, can theoretically dynamically generate control strategies adaptable to complex scenarios, offering a new path to address the aforementioned "decision rigidity" problem. However, directly applying general-purpose LLMs to real-time physical control with high safety requirements introduces more serious new problems: First, the risk of safety loss of control: As a generative model, the output of LLMs is unpredictable and may generate instructions that violate physical safety rules (such as signal conflicts), threatening road traffic safety; Second, the black box and untrustworthiness of decision-making: Its reasoning process is opaque, and decisions lack interpretable evidence, making them difficult to audit and trust; Third, the disconnect between static knowledge and dynamic scenarios: The knowledge of pre-trained models is static and cannot accumulate experience and continuously optimize from actual operation, potentially failing to adapt to long-term changes in traffic flow patterns.

[0005] Therefore, the core challenge facing the field of intelligent traffic signal control has evolved into how to fully leverage the cognitive intelligence advantages of LLM without sacrificing safety and reliability, and how to safely, controllably, and evolvably integrate it into the real-time edge control system. Summary of the Invention

[0006] In view of this, the purpose of this invention is to propose a method for constructing an intelligent decision-making system for traffic signal control, which can solve at least one of the technical problems mentioned in the background art.

[0007] According to one aspect of the present invention, a method for constructing an intelligent decision-making system for traffic signal control is provided. The method includes two parts: a model training and deployment stage and an application and evolution stage, as detailed below:

[0008] Model training and deployment phases:

[0009] S1. Based on pre-stored road traffic conflict rules, generate a paired training sample set of structured traffic state data and conflict-free signal control instructions; use the paired training sample set to perform supervised fine-tuning of a large language model to obtain a basic model;

[0010] S2. The basic model is connected to the traffic simulation environment for reinforcement learning training. In each training step, the basic model outputs signal control instructions according to the current traffic state, and performs safety verification on the instructions according to the road traffic conflict rules to generate a safety reward signal. Based on the safety reward signal and at least one traffic efficiency index signal, a composite reward function is constructed to optimize the parameters of the basic model and obtain a signal control decision model under safety constraints.

[0011] S3. Configure a structured prompt template for the signal control decision model. The prompt template includes the definition of decision roles and priorities, the definition of input data format, and the decision logic guidance. The decision logic guidance includes a quantitative condition judgment process based on a preset threshold.

[0012] Application and Evolution Stages:

[0013] S4. During the deployment and application phase of the signal control decision model, a historical decision knowledge base is constructed: the input data, output signal control commands, and traffic effect data after execution of each decision are recorded; a decision scenario retrieval tag is generated based on the input data, and a comprehensive benefit score is calculated based on the traffic effect data; the retrieval tag, the comprehensive benefit score, the signal control command, and a timestamp are associated and stored as knowledge base entries.

[0014] S5. When the signal control decision model makes a new decision, perform a retrieval enhancement decision: generate a current retrieval label based on the current input data, retrieve matching historical entries in the historical decision knowledge base, and provide the retrieved historical entry information as supplementary input to the model to generate the final signal control command;

[0015] S6. Command Security Verification and Execution: Verify the format compliance, phase timing integrity, and conflict direction interlock security of the final signal control command; only when the verification passes will the command be sent to the signal control device for execution.

[0016] S7. Knowledge base update: Generate new entries based on the input data, signal control instructions, and traffic effect data corresponding to the new decision, compare them with the retrieved historical entries for comprehensive benefit scoring, and update the historical decision knowledge base according to preset rules.

[0017] The above technical solution constructs an LLM-driven closed loop with structured traffic state information as a unified interface, systematically solving multiple technical problems in the background technology, such as rigid decision-making, poor safety controllability, and the inability of the system to continuously evolve. Its advantages lie not only in achieving semantic transformation of perceived data, but also in using this as the core to connect and strengthen the entire technical chain from model training, safety constraints, reliable decision-making to online learning. A detailed analysis follows:

[0018] First, the raw perceptual data is transformed into machine-readable, semantically rich structured data (such as JSON containing specific event labels). Based on this, a novel hybrid paradigm is adopted during model training: supervised fine-tuning (S1) is performed using structured samples generated based on security rules, enabling the model to learn a compliant output paradigm; subsequently, in reinforcement learning (S2), the security rule verification results are quantified into reward signals with absolute priority, driving the model to internalize security as an instinct during dynamic optimization. This not only overcomes the shortcomings of traditional decision-making models in understanding high-level semantic information and activates the deep scene cognition and reasoning potential of LLM, but also ensures the fundamental reliability of generative models in safety-critical fields from both the source and optimization mechanisms, solving the core risk of unpredictable output.

[0019] Secondly, structured data serves as a core element throughout the entire decision-making process. During reasoning, structured prompt templates (S3) provide the model with an analytical framework based on this data format. During decision generation, the system retrieves historical decision knowledge bases (S4, S5) based on the current structured state, enhancing the model by referencing similar historical best-practice structured cases. Before execution, an independent instruction security verification step (S6) conducts a final review of the structured instructions based on hard rules. This process addresses the issues of opacity and difficulty in traceability in the LLM decision-making process (achieving interpretability through structured guidance and case references) and enhances the robustness of decisions through retrieval enhancement. Most importantly, the final independent rule verification step constitutes an absolute security defense against residual risks, ensuring that any instruction complies with engineering safety specifications before execution, achieving a balance between intelligent flexibility and execution reliability.

[0020] Here, during operation, the system automatically associates and stores the inputs (structured states), outputs (structured instructions), and effects (structured evaluation data) of each decision as knowledge base entries (S4). By comparing the comprehensive benefit scores of new and old entries, the knowledge base is driven to be updated competitively (S7). When making new decisions, these structured historical experiences can be quickly retrieved and referenced (S5). This solves the problem that traditional AI models (including undesigned LLMs) become knowledge-stagnant once deployed and cannot adapt to long-term changes. The system can utilize the structured practical experience generated during its operation to perform self-optimization and strategy evolution, thereby possessing the adaptive capability to cope with unforeseen scenarios and long-term changes in traffic flow.

[0021] Finally, the entire solution—from structured data generation and model inference and retrieval enhancement to final security verification and execution—constitutes a locally operable decision-making closed loop. The lightweight processing of the mentioned model further supports its deployment on edge devices. By pushing complete intelligent decision-making capabilities to the edge, the inherent network latency, outage risks, and data privacy issues of cloud-centric decision-making architectures are effectively avoided, meeting the requirements of traffic signal control for millisecond-level real-time response and extremely high operational reliability.

[0022] In summary, the superiority of this solution lies in its innovative use of structured traffic state information as a binder and driving force, integrating four stages—safety internalization training (S1-S2), controllable reasoning and experience enhancement (S3-S5), final safety defense (S6), and online evolution (S4, S7)—into a synergistic system. This solves the semantic alignment and security controllability challenges of LLM applications in vertical domains, ultimately constructing a secure, reliable, continuously evolving, and edge-deployable intelligent traffic signal decision-making system.

[0023] In some embodiments, step S2, which involves verifying the safety of the instruction according to the road traffic conflict rules and generating a safety reward signal, specifically includes:

[0024] If the signal control command passes the security verification, the security reward signal R_safe = 0; if it fails, the security reward signal R_safe = -C, where C is a preset penalty constant.

[0025] The security verification specifically involves parsing the instruction into a state sequence of each traffic light group and comparing it with a pre-stored matrix of physical conflict points at the intersection. If any conflict point corresponds to a traffic light group state combination that simultaneously allows passage, the verification fails.

[0026] The composite reward function is a weighted sum of the safety reward signal and the at least one traffic efficiency reward signal, i.e., R_total = α * R_safe + β * R_efficiency, where the weighting coefficients α and β are preset values ​​and satisfy |α * C|>K * |β * M|, where M is the maximum absolute value that the traffic efficiency reward signal may obtain in a single step, and K is a preset coefficient greater than 1.

[0027] In the above technical solution, step S2 defines a security reward mechanism. Its advantage lies in the fact that through a progressive design of rule computation, cost quantification, and priority mathematization, a security optimization objective with absolute priority is creatively embedded in the optimization process of model training.

[0028] First, the domain knowledge of road traffic conflict rules is concretized into a programmable process for comparing and verifying the matrix of physical conflict points at intersections. Based on this, the binary verification result (pass / fail) is mapped to a scalar reward signal, and its assignment strategy (0 or -C) clarifies the quantification method of the cost of safety attributes. This transformation allows the hard constraints based on safety rules to be integrated into a reinforcement learning framework centered on numerical optimization.

[0029] Secondly, the core of this mechanism lies in the constraint on the weights of the composite reward function: |α * C| > K * |β * M|. This inequality ensures that the absolute value of the negative reward (α * (-C)) resulting from a single security violation must be greater than K times (K>1) of the maximum efficiency gain (β * M) that can be obtained in a single step. This design, from the mathematical definition of the optimization objective, forces the gradient update resulting from any behavior that leads to security verification failure to overwhelmingly cover its potential efficiency gain. This fundamentally prevents the model from engaging in dangerous trials during training in pursuit of efficiency rewards, thereby guiding the direction of model parameter search.

[0030] Finally, the intersection physical conflict point matrix upon which the safety verification in S2 relies is constructed from the same set of pre-stored road traffic conflict rules used in generating training samples in S1. This ensures that the safety learned by the model during training is consistent with the real-world engineering safety definition. The model trained through this mechanism has a safety-first preference embedded in its decision-making logic. This not only reduces the prior probability of the model generating dangerous instructions in the subsequent application stage (S5), but also lightens the burden on the final independent safety verification stage (S6), allowing S6 to focus more on dealing with extreme and rare residual risks.

[0031] In summary, the safety reward mechanism described in step S2 enables the generative large language model (LLM) to be trained as a decision model specifically for traffic lights, ensuring that the behavior of the entire intelligent decision-making system is based on safety guarantees while pursuing dynamic adaptability and efficiency.

[0032] In some embodiments, the traffic state structured data is generated based on the motion trajectory information of vehicles and pedestrians extracted from video data; the traffic state structured data conforms to a first predetermined pattern, which includes at least the number of vehicles queuing by approach direction and lane type, vehicle type distribution, number of pedestrians in waiting areas, and semantic abnormal event identification fields; the conflict-free signal control command is data conforming to a second predetermined pattern, which includes at least phase scheme encoding, duration of each phase, signal light group state matrix, and safety semantic tags.

[0033] The above technical solution defines standardized formats for two types of core data in the system. Its advantage lies in establishing a precise, unambiguous, and semantically rich information interaction foundation for the entire LLM-driven decision-making closed loop.

[0034] First, structured traffic status data must be organized according to traffic engineering dimensions such as approach direction and lane type, and include semantically labeled abnormal event identifier fields. The continuous physical world state is discretized into a set of discrete features with clear business meaning. Traditional input methods based on numerical vectors (such as traffic flow and speed) cannot directly convey key semantic information such as "school dismissal" or "accident vehicles." This feature, by constraining a structured format containing semantic labels, provides LLM with a high-level semantic input capable of direct logical and common-sense reasoning, enabling it to understand "what happened" rather than just "what was measured," thereby activating the deep scene cognition potential of LLM.

[0035] Secondly, conflict-free signal control instructions must include phase scheme encoding, a signal group state matrix, and safety semantic labels. The "signal group state matrix" is an operational, unambiguous description of the control logic; the "safety semantic labels" are a high-level summary of the instruction's safety attributes. This solves the problem of ambiguous output from generative models, making it difficult to directly drive equipment. The standardized instruction format ensures a deterministic mapping between the policy text generated by the LLM and the specific actions that the signal controller can perform. Simultaneously, the structured instructions (especially the state matrix) provide a parsing object for subsequent independent automated safety checks (such as conflict interlock verification in step S6).

[0036] Finally, "first predetermined mode" and "second predetermined mode" are defined for the input (traffic status) and output (control commands), respectively. These two modes, as parsable data within the system, are used throughout all stages, including supervised fine-tuning (S1), reinforcement learning (S2), knowledge base construction (S4), retrieval enhancement (S5), and performance evaluation (S7). This consistent design eliminates the additional conversion overhead and risk of misunderstanding caused by inconsistent data formats between modules. It ensures that training data is isomorphic to online data and that historical experience is comparable to current decisions, thereby guaranteeing stable transfer of model performance, effective reuse of historical knowledge, and fairness in evolutionary evaluation.

[0037] In summary, this data format definition solves the information alignment problem in vertical domain applications of LLM by establishing a semantically rich and structurally rigorous standardized interface for input and output, and provides a data foundation for subsequent secure training, reliable execution and continuous evolution.

[0038] In some embodiments, the semantic anomaly event identifier field is used to identify traffic events with natural language semantics parsed from the motion trajectory information, including one or more of traffic accidents, special vehicle passage, school dismissal, and severe weather effects.

[0039] In the above technical solution, the semantic abnormal event identifier field is specifically defined. Its core advantage is that it provides a high-level semantic abstraction for machine understanding of traffic conditions.

[0040] First, this field constraint system must categorize and label low-level motion patterns (such as vehicles remaining stationary for extended periods, the appearance of specific vehicle types, and crowd gatherings in specific areas) parsed from video trajectories as discrete events with clear natural language semantics, such as "traffic accidents," "special vehicle passage," and "school dismissal." Traditional traffic status representations (such as queue length and average vehicle speed) are continuous, low-dimensional numerical features that cannot effectively convey the type, nature, and urgency of events. This feature, by injecting these predefined semantic labels, refines the raw, noisy perceptual data into high-level semantic symbols that can be directly logically manipulated by LLM. This enables LLM to perform common-sense reasoning based on "what type of event occurred," rather than simply relying on statistical correlations based on "what numerical changes occurred."

[0041] Secondly, the listed event types (such as traffic accidents and severe weather) all correspond to different, predefined traffic management and safety response strategies. For example, the "traffic accident" label is directly associated with clearing and traffic control needs; the "school dismissal" label is directly associated with pedestrian priority passage needs. This design injects contextual information into the LLM's decision-making and reasoning process. Guided by the structured prompt template (S3), the LLM can use these semantic events as explicit judgment conditions (e.g., "IF 'traffic accident' event exists THEN Activate accident handling phase"), thereby generating control strategies that are highly matched to the scenario. This solves the problem of delayed or inappropriate responses that may occur in traditional optimization models due to the lack of event semantic input, improving the system's speed and safety in handling sudden and abnormal events.

[0042] Finally, when constructing the historical decision-making knowledge base (S4), these semantic event tags become a core component in generating "decision-making scenario retrieval tags." For example, a historical entry containing the tags "school dismissal" and "rainy day" can be efficiently retrieved and used in a new decision-making scenario with similar semantic features (S5). This allows the system's experiential learning to move beyond fuzzy numerical vector similarity to interpretable semantic scenario matching. The system can more accurately find historical cases that are truly similar to the current situation in terms of "event nature" for reference, greatly improving the effectiveness of retrieval-enhanced decision-making. Simultaneously, knowledge base entries based on semantic tags also make the performance evaluation and evolution of strategies (S7) more reasonable, as it allows for a fairer comparison of the merits of different strategies handling similar semantic events.

[0043] In summary, the semantically defined exception event identifier field defined by this feature achieves a leap from perception to cognition at the data level. By providing LLM with directly understandable, business logic-rich high-level event semantics, it effectively bridges the semantic gap between raw perception and intelligent decision-making.

[0044] In some embodiments, the generation of decision scenario retrieval tags in step S4 and the generation of current retrieval tags based on current input data in step S5 are both based on the decision logic guidance in the structured prompt template, which parses the input data into standardized semantic tags containing event type, location, time period and weather information.

[0045] Step S6, which involves verifying the final signal control command, specifically includes:

[0046] Format and syntax compliance verification: Check the completeness of the required information items of the instruction and the correctness of the data type;

[0047] Phase timing integrity verification: Verify that the total duration of the signal period and the time values ​​of each phase are positive and continuous;

[0048] Conflict direction interlock verification: Based on the pre-stored intersection conflict direction relationship table, verify whether there are conflict direction signal light groups that are simultaneously set to the state of allowing passage in the verification instruction;

[0049] The aforementioned technical solution clarifies the specific mechanisms for achieving experience reuse and execution security during the application phase. Its advantage lies in strengthening the engineering foundation of the decision-making closed loop from both intelligent and security perspectives through standardized semantic abstraction and layered, progressive rule verification.

[0050] First, the generation of search tags is based on the decision-making logic guidance in the structured prompt template. It parses decision dimensions such as "event type, location, time period, and weather" from the input data and forms standardized semantic tags (e.g., "traffic accident_south entrance_evening rush hour_rainy day"). This design solves the problem of the difficulty in effectively utilizing massive historical decision records. It allows the scenario of each decision to be abstracted into an indexable and comparable semantic summary. During the retrieval in step S5, the system can quickly and accurately recall historical best cases that are truly similar in decision-making logic based on similar semantic tags of the current scenario, improving the effectiveness of retrieval and enhancing decision-making.

[0051] Secondly, the verification in step S6 includes three layers of verification: (1) Format and syntax compliance verification: ensure that the instruction structure is complete and the data is valid. (2) Phase and timing integrity verification: ensure that the instruction is reasonable and feasible in the time dimension, and avoid unexecutable or confusing timing arrangements. (3) Conflict direction interlock verification: based on the unmodifiable physical conflict rule table, perform security checks to eliminate the risk of simultaneous passage in conflict directions. This verification step is independent of the LLM generation process and is the final and deterministic security control mechanism of the system. It solves the model "illusion" or randomness risk that may not be completely eliminated in the training and inference stages. The three layers of verification are combined to form a verification system from data interface to timing logic to physical security. In particular, the "conflict direction interlock verification" is connected to the same set of "road traffic conflict rules" used in stages S1 and S2, ensuring that the training objectives, model internalization and final execution are all based on a unified security benchmark.

[0052] In summary, the semantic tag generation mechanism in steps S4 / S5 and the rigid security verification mechanism in step S6 work together to strengthen the system's two core attributes: the former, through standardization and semanticization, enhances the empirical, accurate, and evolvable nature of intelligent decision-making; the latter, through rule-based and hierarchical approaches, ensures the reliability, security, and executability of intelligent output. These two mechanisms, focusing on intelligence and security respectively, collaboratively guarantee the stable and reliable operation and iteration of the LLM-driven high-risk real-time control system.

[0053] In some embodiments, updating the historical decision knowledge base according to preset rules in step S7 includes: if the comprehensive benefit score of the new entry is higher than the score of the retrieved matching historical entry, then the new entry replaces the historical entry; and setting an active timestamp for the entries in the knowledge base, and periodically removing entries that have exceeded a preset inactive time limit.

[0054] In the above technical solution, step S7 defines a knowledge base update mechanism, which has the advantage of providing clear and executable operational rules for the continuous evolution and long-term operation management of the system. This mechanism, by introducing competitive replacement and dynamic elimination strategies, enables the knowledge base to have the ability to self-optimize and maintain its vitality.

[0055] First, a comprehensive benefit score is used as the sole quantitative standard for evaluating the merits of strategies, and a replacement is imposed when a new entry's score is higher than that of a matching historical entry. This establishes a survival-of-the-fittest mechanism based on relative performance. This rule addresses the core issue of automatically identifying and retaining superior strategies during experience accumulation. It ensures that knowledge base updates are targeted performance improvements. This supports the system's online evolution capability (S4 & S7 closed loop), enabling the system to continuously replace suboptimal strategies with more efficient ones based on its own operational experience. This score comparison is closely linked to the "calculating comprehensive benefit score" step in S4, forming a complete "evaluation-comparison-update" logical chain.

[0056] Secondly, an "active timestamp" is set for each knowledge base entry, and a rule is established to periodically remove entries that have exceeded a preset inactive time limit. This essentially introduces the concept of "vitality" to a strategy. This design effectively solves the problem that traffic environments and flow patterns may change over time (long-term drift). A strategy that was efficient in a specific period in the past may no longer be applicable due to changes in time characteristics and the surrounding road network. Simple competitive replacement may not be able to eliminate these "outdated but once efficient" strategies. The active timestamp mechanism indirectly incentivizes the system to try to generate new strategies to fill knowledge gaps when facing a changing environment by forcibly eliminating strategies that have not been referenced for a long time, thereby avoiding the system from falling into local optima or strategy rigidity. This is linked to the retrieval enhancement mechanism (S5): if a strategy cannot be matched and referenced for a long time, it proves that its corresponding scenario no longer appears or the tag has become invalid, and its removal is a reasonable and necessary resource management.

[0057] In summary, the update rules in step S7, driven by competition and timeliness, shape a dynamic, healthy, and continuously evolving historical decision-making knowledge base. Competition ensures the quality-oriented nature of the knowledge base content, making it a repository of excellent strategies; timeliness guarantees the environmental adaptability and management efficiency of the knowledge base, preventing it from becoming bloated or outdated due to the accumulation of invalid data. These two rules work together to transform the historical decision-making knowledge base built by the system from a static case storage into a dynamic strategy ecosystem with self-updating and self-purifying capabilities.

[0058] In some embodiments, the method further includes lightweighting the signal control decision model to obtain a lightweight model suitable for deployment on edge computing devices; the lightweighting process includes one or more of knowledge distillation, quantization, or pruning.

[0059] The core advantage of the above technical solution lies in the fact that, as the final adaptation link of the system construction method, it solves the key contradiction between high-performance intelligent models and the stringent deployment constraints at the edge, ensuring that the aforementioned series of technological innovations can be reliably implemented in actual engineering environments.

[0060] First, the "signal control decision model" obtained during the training and evolution phases is used as the processing object. Model compression techniques such as knowledge distillation, quantization, or pruning are employed to generate a "lightweight model" with significantly reduced computational complexity, memory usage, and power consumption. The decision model, after safety-constrained training in phases S1-S3 and online evolution in phases S4-S7, typically has a large number of parameters and high computational requirements, making it difficult to directly deploy on edge devices at intersections (such as embedded AI computing units) where computing power, storage, and energy consumption are limited. Without this step, the entire solution would remain confined to the cloud or simulation environment, failing to meet the core requirements of traffic signal control for low latency, high reliability, and network independence. Lightweight processing solves the problem mentioned in the background technology regarding "complex model computation and real-time edge response."

[0061] Secondly, the lightweight methods listed (knowledge distillation, quantization, and pruning) are all mature compression techniques designed to preserve the performance of the original model to the greatest extent possible. For example, "knowledge distillation" focuses on transferring the complex decision-making logic and safety constraint "knowledge" contained in a large model (teacher model) to a smaller model (student model). This step deals with specialized decision-making models that have internalized safety instincts through a safety reward mechanism (S2), standardized their reasoning logic through structured prompts (S3), and possess the ability to handle multiple scenarios. The goal of lightweighting is to preserve these carefully trained and guided core capabilities as much as possible under resource-constrained conditions. This ensures that lightweight models deployed at the edge still inherit the safety and intelligence foundation provided by the entire methodology.

[0062] Finally, by reducing the computational and storage overhead of the model, the inference speed of the model on edge devices was improved, and the time spent on decision generation (S5) was reduced. Fast model inference is a key link in ensuring the overall real-time performance of the system. It ensures that the entire decision loop, from the input of perceived data to the model completing the retrieval of enhanced inference and generating instructions, and then allowing sufficient time for independent safety verification (S6), can be completed within a typical cycle of traffic signal control (tens of seconds to minutes), meeting the requirements of dynamic response.

[0063] In summary, this lightweight processing feature ensures that the solution can overcome the physical limitations of edge devices and ultimately play a role in real-world intersection control scenarios in an efficient, usable, and deployable form.

[0064] According to another aspect of the present invention, an apparatus for constructing an intelligent decision-making system for traffic signal control is provided, the apparatus comprising, based on the above-described method:

[0065] The model training module is used to execute the methods for the model training and deployment phases.

[0066] An application evolution module is used to execute the methods of the application and evolution stages.

[0067] In order to better utilize the above method, this application proposes an intelligent decision-making system construction device for traffic signal control. Each module corresponds to a step of the above method, and its specific principle has been described above and will not be repeated here.

[0068] According to another aspect of the present invention, an apparatus for constructing an intelligent decision-making system for traffic signal control is provided, comprising:

[0069] At least one processor and a memory communicatively connected to said at least one processor;

[0070] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described above.

[0071] In the above technical solution, to better operate and process the method, the method is stored in memory, and the processor executes the stored method. It should be noted that the principle and effect of each step have been described above and will not be elaborated upon here.

[0072] According to another aspect of the present invention, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the above-described method.

[0073] In the above technical solution, to better operate and use the method, the method is stored in a computer-readable storage medium and implemented using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated upon here. Attached Figure Description

[0074] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0075] Figure 1This is a schematic diagram of the model training and deployment phase of an embodiment of the intelligent decision-making system construction method for traffic signal control according to the present invention.

[0076] Figure 2 This is a schematic diagram illustrating the application and evolution stages of an embodiment of the intelligent decision-making system construction method for traffic signal control according to the present invention.

[0077] Figure 3 This is a schematic diagram of a crossroads in accordance with an embodiment of the intelligent decision-making system construction method for traffic signal control according to the present invention.

[0078] Figure 4 This is a schematic diagram of data flow in an embodiment of a method for constructing an intelligent decision-making system for traffic signal control according to the present invention;

[0079] Figure 5 This is a schematic diagram of data flow in an embodiment of an intelligent decision-making system construction device for traffic signal control according to the present invention. Detailed Implementation

[0080] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0081] Example 1

[0082] Please see Figure 1 A method for constructing an intelligent decision-making system for traffic signal control is disclosed, comprising two parts: a model training and deployment phase and an application and evolution phase, as detailed below:

[0083] Model training and deployment phases:

[0084] S1. Based on pre-stored road traffic conflict rules, generate a paired training sample set of structured traffic state data and conflict-free signal control instructions; use the paired training sample set to perform supervised fine-tuning of a large language model to obtain a basic model;

[0085] The structured traffic status data is generated based on the motion trajectory information of vehicles and pedestrians extracted from video data. This structured traffic status data conforms to a first predetermined pattern and includes at least the number of vehicles queuing by approach direction and lane type, vehicle type distribution, number of pedestrians in waiting areas, and a semantically defined abnormal event identifier field. The conflict-free signal control instructions conform to a second predetermined pattern and include at least phase scheme encoding, duration of each phase, signal light group state matrix, and safety semantic tags. The semantically defined abnormal event identifier field is used to identify traffic events with natural language semantics parsed from the motion trajectory information, including one or more of the following: traffic accidents, special vehicle passage, school dismissal, and severe weather effects.

[0086] For example, an advanced YOLOv11 object detection algorithm, combined with DeepSORT and ByteTrack multi-object tracking technologies, was used to construct a high-precision, real-time traffic element identification and tracking system. This system continuously collects video streams through high-definition cameras deployed at key intersection locations. Relying on an optimized YOLOv11 model, it achieves accurate identification of various traffic participants, covering ordinary vehicles (cars, buses, trucks, motorcycles, bicycles, electric bicycles), special vehicles (ambulances, fire trucks, school buses, police cars), and pedestrians. With the help of multi-object tracking technology, the system can continuously track the movement trajectory of targets, thereby accurately calculating queue lengths in each lane, calculating vehicle speeds, and effectively detecting abnormal events (such as accident vehicles, vehicles driving in the wrong direction, etc.). All perceived data is standardized and processed to generate structured JSON reports, providing stable and reliable input for downstream decision-making modules.

[0087] In this example, the predefined pattern refers to the JSON data structure. The system employs a phased training strategy. First, it is pre-trained on large-scale traffic scene datasets (such as BDD100K and COCO), then fine-tuned using locally collected data from the target intersection to improve the model's accuracy in recognizing specific vehicle types, pedestrians, and environmental features at that intersection. The labeled categories are meticulously divided into: car, bus, truck, motorcycle, bicycle, e-bike, person, and special vehicles such as ambulance, fire truck, school bus, and police car. To ensure real-time inference performance, the system uses TensorRT on embedded devices such as NVIDIA Jetson to accelerate and optimize the trained YOLO model, significantly improving inference speed and energy efficiency. Regarding the traffic parameter calculation logic, the system designs multi-dimensional quantitative indicators. Queue length is calculated by defining a "queue area" after the lane stop line and counting the number of stationary (speed < 5 km / h) vehicles within that area. Average speed is calculated based on vehicle trajectories extracted by DeepSORT / ByteTrack, with average speeds of moving vehicles calculated separately for the entrance and exit directions. Lane occupancy rate is represented by the ratio of the integral of the pixel area and duration of a vehicle within the lane over the statistical period to the total pixel area and duration of the lane. Anomaly detection covers multiple scenarios: identifying abnormal or accident vehicles with the same vehicle ID that remain stationary (0 km / h) for more than a set time (e.g., 30 seconds) in the driving lane; monitoring whether the number of pedestrians at both ends of a zebra crossing or in the waiting area of ​​a safety island exceeds a threshold (e.g., 10 people) to determine if there is a risk of crowding; and real-time determination of reverse driving behavior by analyzing the angle between the vehicle's direction of movement and the lane's designated direction. At the end of each phase cycle, all identification and statistical results for that cycle are integrated into a structured report and output to the subsequently deployed model. This report is constructed in a standardized JSON format and fully includes key data such as traffic participant information, lane status, and anomaly events. Through this closed-loop data processing flow, the system achieves efficient and reliable connection from visual perception to decision-making instructions.

[0088] In this example, in order for subsequent models to learn the generation logic and constraint boundaries of this data structure, the construction rules of this data structure are as follows:

[0089] 1. Rules for building identification reports

[0090] The identification report is a standardized JSON object that contains at least the following fields:

[0091] Basic information: Report ID, generation timestamp, intersection sign, and executed phase scheme ID;

[0092] Basic list of traffic participants: type (e.g., car / bus / person / ambulance, etc.), lane, speed, location;

[0093] Aggregate status indicators: queue length, average vehicle speed, lane occupancy rate, and number of pedestrians waiting in each direction of entry;

[0094] Semantic event tags: Boolean or enumerated flags, such as traffic accidents, special vehicles, school dismissal, and spillover risks;

[0095] Cycle Timeline: The complete execution cycle of the traffic lights in the phase scheme.

[0096] All fields are generated according to preset quantization logic (e.g., queue length = number of vehicles stationary after the stop line) to ensure consistency with LLM input requirements.

[0097] 2. Phase command construction rules

[0098] Phase instructions are standardized JSON objects that contain at least the following fields:

[0099] Basic information: unique phase scheme code (e.g., BASIC_4PHASE_002, PEDESTRIAN_ONLY_001), intersection sign, timestamp, and whether phase is inherited;

[0100] Phase timing sequence: Phase unit array, each unit contains direction, traffic light status (motor vehicle / pedestrian), green light duration, and yellow light duration;

[0101] Execution strategy: includes execution level ("immediately" or "after the current cycle") and number of executions ("repeat" or an integer number of times);

[0102] Security Labels: Security semantic labels used to constrain the legality of LLM outputs.

[0103] It should be noted that, firstly, in traditional systems, phase commands are merely a simple mapping of "direction + green light duration"; while the phase commands of this invention include dimensions such as execution level (immediate / after a cycle), execution frequency strategy (cyclic / fixed number of times), safety tags (such as EMERGENCY_*), and traceable coding. These together constitute the technical foundation for the interpretability, auditability, and traceability of LLM decisions. Similarly, the identification report not only includes statistical values ​​such as traffic flow and queue length, but also embeds structured expressions of unstructured information such as event semantic tags (such as "school dismissal"), overflow risk signs, and special vehicle types. These designs cannot be directly derived from existing traffic signal control systems or general data exchange standards, but are the underlying interfaces necessary for this invention to achieve "LLM-driven safe intelligent control." Secondly, this phase scheme and JSON construction are crucial to this invention. The process of using LLM (such as DeepSeek) to "semantically understand" complex traffic conditions and generate legitimate control commands must rely on a predefined, machine-readable, and semantically clear structured "language"—that is, the JSON data specification designed in this invention. This "language" defines the following for LLM: Input vocabulary: identifying which traffic elements (such as queue length, accident signs, weather conditions) should be included in the report and how they should be organized (field naming, nesting relationships); Output syntax: how control instructions should express phase combinations, green light durations, execution logic, safety constraints, etc. Finally, the JSON format described in this invention is not an isolated data template, but a specific technical implementation that corresponds one-to-one with and is deeply coupled to the method flow of this invention—"perception → generating structured reports → LLM inference → generating structured instructions → execution"—embodying the core method of digitizing, structuring, and computing dynamic and ambiguous real-world traffic scenarios, and is an indispensable key link in achieving automated and intelligent control.

[0104] It should be noted that the corresponding construction rules have been given in this embodiment. Those skilled in the art can design the corresponding phase instructions according to actual needs and then construct the corresponding standardized JSON object based on the above rules.

[0105] Furthermore, for better illustration, this embodiment provides the following traffic light phase scheme (it should be noted that taking a crossroads as an example is only one specific implementation method and is not a limitation on the scope of application. By simply adjusting the structural definition of the recognition report and decision command, it can be quickly adapted to various intersections such as T-shaped, Y-shaped, roundabouts, and irregular intersections, demonstrating the strong versatility and practicality of this invention):

[0106] For example, intersection traffic planning is the foundation for intelligent transportation systems to achieve precise perception and automated decision-making. To ensure the coordinated operation of various modules within the system, it is essential to first standardize the definition of intersection physical elements and establish a unified and clear naming convention. This standardization work covers lane layout, traffic light configuration, and the division of pedestrian crossing facilities, providing a clear physical benchmark for subsequent signal control strategies. In the standardized definition of intersection elements, we clarified the following key structures: each direction's zebra crossing is divided into "entry side" and "exit side," connected by "safety islands," specifically including eastbound, eastbound, east island; westbound, westbound, west island; southbound, southbound, south island; and northbound, northbound, north island. Regarding lane layout, each entry direction has three dedicated lanes: a left-turn lane, a straight-ahead lane, and a right-turn lane, equipped with corresponding directional arrows; the exit direction has three straight-ahead lanes. The traffic light configuration includes vehicular traffic lights (left turn, straight ahead, and yellow lights) and pedestrian traffic lights (each zebra crossing has two independent signal controls: an "exit / island group" and an "entry / island group"). Based on these definitions, draw the following intersection plan, such as... Figure 3 As shown.

[0107] Based on the standardized structure described above, the system pre-defines a basic four-phase control scheme with a cycle of 160 seconds as its core operating logic. This scheme sequentially executes four phases: north-south straight, north-south left turn, east-west straight, and east-west left turn. Each phase includes a 35-second green light and a 5-second yellow light buffer. Within each phase, the states of the vehicle traffic lights and pedestrian traffic lights are strictly defined to ensure effective separation of vehicle and pedestrian flows in time and space, improving traffic safety and efficiency. Right-turning vehicles are generally set to a constant-access state, but must yield to pedestrians according to the pedestrian signal. The specific signal states and timing designs for each phase are shown in the table below.

[0108] Table 1. The first phase of the basic four-phase system

[0109]

[0110] Table 2. The second phase of the basic four phases

[0111]

[0112] Table 3. The third phase of the basic four phases

[0113]

[0114] Table 4. The fourth phase of the basic four phases

[0115]

[0116] Table 4 Timing Table of Basic Four-Phase Phases

[0117]

[0118] To translate the above control logic into machine-readable and executable instructions, a basic four-phase intersection instruction file (.json) is generated according to the construction rules of the above data structure. For example:

[0119] "phase_id": "phase_1", / / Phase ID

[0120] "phase_name": "North-South Direction Straight Ahead", / / Phase Name

[0121] "sequence": 1, / / Execution order

[0122] "duration_sec": 40, / / Total phase duration

[0123] "breakdown": { / / Time breakdown

[0124] "green_sec": 35, / / Green light time

[0125] "yellow_sec": 5, / / Yellow light duration

[0126] "all_red_sec": 0 / / All-red time

[0127] …

[0128] This JSON structure can fully describe the signal status, timing decomposition, and control details of each facility in the four-phase scheme, serving as a standardized instruction set issued by the decision-making module to the signal control equipment. Upon receiving the instruction, the signal control equipment will strictly execute the corresponding signal light phase switching according to its content, realizing automated scheduling and closed-loop control of the intersection.

[0129] It should be noted that while existing neural network methods (such as DQN, DDPG, and MADRL) have achieved application results in the field of traffic signal control, their technical essence and capability boundaries are fundamentally different from those of methods based on Large Language Models (LLM). Specifically, the main differences are as follows: First, in terms of input understanding, traditional neural networks can only process structured numerical data (such as traffic flow and queue length) and cannot parse unstructured semantic information such as weather and event descriptions; LLM, on the other hand, can directly understand and integrate multimodal semantic context, achieving semantic-based cognition and reasoning. Second, in terms of action generation, traditional methods are usually limited to selecting from a preset set of phases or fine-tuning fixed phase durations; LLM can dynamically generate entirely new phase schemes, including adjusting phase structure and defining execution logic, possessing scheme-level design capabilities. Third, in terms of decision-making mechanisms, traditional methods rely on pattern matching of historical data and have limited adaptability to unseen scenarios; LLM possesses causal reasoning and rule-following capabilities, enabling reasonable decisions for complex or unseen scenarios. In addition, LLM can provide natural language decision-making basis, enhancing the interpretability and auditability of the system; it can adapt to different intersection topologies and event types by adjusting the prompt structure and a few examples, and has strong scalability; and it can flexibly embed and update security constraints in natural language form, supporting dynamic policy adjustment.

[0130] Furthermore, the edge intelligent traffic control system based on a large language model aims to achieve localized high-level intelligent decision-making and accurately match the complexity of actual intersection control. Specifically, firstly, in terms of capability, the system can handle semantically complex scenarios involving multiple factors such as "rainy days, school dismissal, and ambulance passage," which traditional neural networks, which can only process numerical inputs, cannot achieve. Secondly, in terms of objectives, the system integrates the entire process of perception, reasoning, and decision-making into edge devices, achieving autonomous operation without relying on the cloud, and its design has the versatility to quickly expand to various irregular intersections. Finally, in terms of applicability, single-intersection control itself involves multiple complex constraints such as avoiding signal conflicts, coordinating pedestrian and vehicle phases, and balancing efficiency and fairness, which precisely require the semantic reasoning and multi-objective optimization capabilities of the large language model to address.

[0131] S2. The basic model is connected to the traffic simulation environment for reinforcement learning training. In each training step, the basic model outputs signal control instructions according to the current traffic state, and performs safety verification on the instructions according to the road traffic conflict rules to generate a safety reward signal. Based on the safety reward signal and at least one traffic efficiency index signal, a composite reward function is constructed to optimize the parameters of the basic model and obtain a signal control decision model under safety constraints.

[0132] In this embodiment, step S2, which involves verifying the safety of the instruction according to the road traffic conflict rules and generating a safety reward signal, specifically includes:

[0133] If the signal control command passes the security verification, the security reward signal R_safe = 0; if it fails, the security reward signal R_safe = -C, where C is a preset penalty constant.

[0134] The security verification specifically involves parsing the instruction into a state sequence of each traffic light group and comparing it with a pre-stored matrix of physical conflict points at the intersection. If any conflict point corresponds to a traffic light group state combination that simultaneously allows passage, the verification fails.

[0135] The composite reward function is a weighted sum of the safety reward signal and the at least one traffic efficiency reward signal, i.e., R_total = α * R_safe + β * R_efficiency, where the weighting coefficients α and β are preset values ​​and satisfy |α * C|>K * |β * M|, where M is the maximum absolute value that the traffic efficiency reward signal may obtain in a single step, and K is a preset coefficient greater than 1.

[0136] For example, this embodiment uses the DeepSeek large-scale language model to achieve deep semantic understanding and decision reasoning. This DeepSeek large-scale language model receives JSON-formatted traffic status reports from the perception layer and performs multi-dimensional scenario analysis based on pre-learned traffic rules, optimization objectives, and historical experience. Unlike traditional rule engines, DeepSeek possesses powerful reasoning capabilities and creative thinking, and can dynamically generate optimal signal control strategies based on real-time traffic conditions, including basic phase duration adjustments, special phase insertions, and pedestrian priority schemes. Its output uses a standardized JSON command format to ensure seamless integration with the control module.

[0137] However, applying general-purpose LLM to real-time physical control with high safety requirements introduces new problems: First, the risk of safety runaway: As a generative model, the output of LLM is unpredictable and may generate instructions that violate physical safety rules (such as signal conflicts), threatening road traffic safety; Second, the black box and untrustworthiness of decision-making: Its reasoning process is opaque, and the decisions lack interpretable evidence, making them difficult to audit and trust; Third, the disconnect between static knowledge and dynamic scenarios: The knowledge of pre-trained models is static and cannot accumulate experience and continuously optimize from actual operation, which may prevent them from adapting to long-term changes in traffic flow patterns. Therefore, the core contradiction currently facing the field of intelligent traffic signal control has evolved into: how to fully utilize the cognitive intelligence advantages of LLM without sacrificing safety and reliability, and to safely, controllably, and evolvably integrate it into real-time edge control systems.

[0138] Therefore, this embodiment limits the training process for the large model. This embodiment adopts a three-layer training architecture. The simulation environment module relies on professional traffic simulation software such as SUMO and Vissim to accurately simulate the complex traffic flow characteristics of intersections, generating massive training data covering various typical scenarios including off-peak, peak, nighttime, traffic accidents, special vehicle passage, and pedestrian-dense areas. It also considers the impact of different weather conditions on traffic flow to ensure the comprehensiveness and realism of the training samples. The supervised learning (SL) module uses traffic engineering expert knowledge to finely annotate the training data. Through supervised fine-tuning (SFT), the model masters basic traffic rules and signal control principles, ensuring the correct correspondence between input information and output decisions. The reinforcement learning (RL) optimization module employs a human feedback-based reinforcement learning (RLHF) mechanism. Through continuous interaction between the model and the simulation environment, combined with a multi-dimensional reward function system, it guides the model to continuously evolve in terms of traffic efficiency, safety, and response speed, achieving self-learning and continuous improvement.

[0139] The training content is designed based on a basic four-phase intersection scheme, covering basic phase optimization and phase changes in special scenarios, following a progressive learning approach from simple to complex. Specific training samples include (but are not limited to) the following five scenarios:

[0140] 1. Do not adjust the phase training samples

[0141] <Training Sample ID_001>

[0142] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0143] Decision Analysis:

[0144] Phase scheme adjustment: No

[0145] Expected output:

[0146] Decision description: There are no significant changes in the periodic parameters compared to the previous period, therefore the current phase scheme is maintained.

[0147] 2. Optimize the basic four-phase training samples

[0148] <Training Sample ID_002>

[0149] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0150] Decision Analysis:

[0151] Left turn at the south entrance: ΔQ = 10 > T q (8)

[0152] Phase scheme adjustment: Yes

[0153] Reason for adjustment: Longer traffic queues; South entrance left-turn lane; Morning rush hour; Sunny day

[0154] Historical reference: Similar reference phase schemes were retrieved from the decision knowledge base, tagged "longer vehicle queues_east entrance left turn lane_evening rush hour_clear weather_optimized basic phase", with a comprehensive benefit score of 0.82; the current situation is morning rush hour and clear weather.

[0155] Expected output:

[0156] Decision Description: Based on the phase scheme code in the knowledge entry, retrieve the corresponding phase scheme instruction. The scheme adjustment strategy is to extend the green light duration for left turns in the east-west direction by 30 seconds. Considering the current clear morning rush hour conditions, make the decision to extend the green light duration for left turns in the north-south direction by 30 seconds.

[0157] Execution level: Execute the original phase scheme only after it has been completed;

[0158] Number of executions: Executes in a loop.

[0159] Generate phase instructions: Generate basic four-phase optimized instruction content and phase scheme encoding;

[0160] 3. Emergency Response Phase Training Samples

[0161] <Training Sample ID_003>

[0162] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0163] Decision Analysis:

[0164] Special vehicle markings: Ambulance (S1=1);

[0165] Phase scheme adjustment: Yes;

[0166] Reason for adjustment: Special vehicles - East entrance straight lane - Off-peak hours - Sunny day;

[0167] Historical reference: No similar reference phase schemes were found from the decision knowledge base.

[0168] Expected output:

[0169] Decision Description: An ambulance was detected on the straight lane at the east entrance. It is currently off-peak season, the weather is clear, and visibility is high. Therefore, an emergency response phase scheme is adopted: 30 seconds of green light for east-west vehicles, and red light for all other lanes and pedestrians.

[0170] Execution level: Immediate execution;

[0171] Number of executions: 3 cycles (executions in multiple cycles are more conducive to AI decision quantification; if the weather is bad, the green light time can be extended or the number of executions can be increased accordingly).

[0172] Generate phase instructions: Generate emergency response phase instruction content and phase scheme encoding;

[0173] 4. Two-phase training samples

[0174] <Training Sample ID_004>

[0175] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0176] Decision Analysis:

[0177] Total queue size across all lanes: 5 vehicles: O1 <T o (0.2);

[0178] Phase scheme adjustment: Yes;

[0179] Reasons for adjustment: Short queues, all directions, late at night, clear weather;

[0180] Historical reference: Similar reference phase schemes were retrieved from the decision knowledge base, tagged "sparse queues_all directions_early morning_rainy day_two phases", with a comprehensive benefit score of 0.75; the current time is late night and clear weather.

[0181] Expected output:

[0182] Decision Description: Based on the phase scheme code in the knowledge entry, the corresponding phase scheme instruction is retrieved. The scheme adjustment strategy is a 60-second green light for north-south traffic (phase 1) and a 60-second green light for east-west traffic (phase 2). Considering the current clear night conditions, since both periods are low-traffic periods, and the current weather is better with higher visibility, the passage time can be appropriately shortened. Therefore, the decision is made to set a 40-second green light for north-south traffic (phase 1) and a 40-second green light for east-west traffic (phase 2).

[0183] Execution level: Execute the original phase scheme only after it has been completed;

[0184] Number of executions: Executes in a loop.

[0185] Phase generation instructions: Generate two phase scheme instruction contents and phase scheme codes;

[0186] 5. Single-port rotation training samples

[0187] <Training Sample ID_005>

[0188] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0189] Decision Analysis:

[0190] Abnormal event flag: Incident (E1 = 1);

[0191] Phase scheme adjustment: Yes;

[0192] Reason for adjustment: Accident vehicle - South Exit Straight Lane - Morning Rush Hour - Sunny Day;

[0193] Historical reference: No similar reference phase schemes were found from the decision knowledge base.

[0194] Expected output:

[0195] Decision Description: An accident has occurred on the straight lane at the south exit. It is currently the morning rush hour, the weather is clear, and visibility is high. The accident lane should be given more passage time. Therefore, a single-entrance turn-off scheme will be adopted: the green light for southbound straight and left-turn (phase 1) will be 90 seconds, and the green light for other directions will be 45 seconds. The pedestrian signal will be adjusted accordingly.

[0196] Execution level: Execute the original phase scheme only after it has been completed;

[0197] Number of executions: 10 cycles (not cyclical execution, as accident vehicles may be cleared after several cycles, and the southbound direction should not enjoy passage privileges for an extended period).

[0198] Generate phase instructions: Generate the phase instruction content and phase scheme encoding for single-port rotary amplifier;

[0199] 6. Pedestrian-specific phase training samples

[0200] <Training Sample ID_006>

[0201] Input: Current period traffic data (identification report R1), previous period traffic data (identification report R0);

[0202] Decision Analysis:

[0203] Pedestrian gathering number: 50 pedestrians on the north side (P1>T) p );

[0204] Phase scheme adjustment: Yes;

[0205] Reasons for adjustment: Pedestrian congestion - North Exit side - School dismissal peak - Snowy weather;

[0206] Historical reference: No similar reference phase schemes were found from the decision knowledge base.

[0207] Expected output:

[0208] Decision Description: There are 50 pedestrians waiting to cross the street at the north exit. It is currently the peak time for school dismissal, the weather is snowy, and the road conditions are poor. It is necessary to increase the pedestrian crossing time. Therefore, a pedestrian-only phase scheme is adopted: pedestrian-only phase (phase 2 / phase 4) allows passage for 80 seconds.

[0209] Execution level: Execute the original phase scheme only after it has been completed;

[0210] Number of executions: 50 cycles.

[0211] Generate phase instructions: Generate pedestrian-specific phase instruction content and phase scheme encoding;

[0212] The DeepSeek model performs inference based on real-time JSON reports, generating diverse decision types. Basic phase optimization extends the green light time of the corresponding phase when a long queue is detected in a certain direction (e.g., training sample ID_001); emergency response inserts an emergency full green light phase when special vehicles are identified (e.g., training sample ID_002); during low-traffic periods, it automatically switches to a two-phase or single-port alternating scheme (e.g., training samples ID_003, ID_004); and in pedestrian-dense scenarios, it inserts an omnidirectional pedestrian-dedicated phase (e.g., training sample ID_005). It should be noted that the specific phase command content and phase scheme encoding can be set according to actual needs, and will not be elaborated here. All decisions are converted into standardized JSON commands, clearly indicating the new phase scheme number, the duration of each phase, the execution level, and the number of executions, ensuring accurate parsing by the traffic light control execution module. (It is particularly important to note that all listed training texts or decision commands are formatted samples. During the training process or in the decision commands output by DeepSeek, the values ​​of all fields change, and the adjusted phase also changes, because congestion, pedestrian gatherings, accident vehicles, vehicles driving in the wrong direction, and emergency vehicles may occur in all directions at an intersection.) It should be noted that the specific design method for the phase command content and phase scheme encoding can be customized according to actual needs. Once the design is complete, the data must be constructed according to the data structure construction rules described above.

[0213] The composite reward function is a weighted sum of the safety reward signal and at least one traffic efficiency reward signal, i.e., R_total = α * R_safe + β * R_efficiency, where R_safe is the safety reward signal, R_efficiency is the traffic efficiency reward signal, the weighting coefficients α and β are preset values, and satisfy |α * C|>K * |β * M|, where M is the maximum absolute value that the traffic efficiency reward signal may obtain in a single step, and K is a preset coefficient greater than 1.

[0214] In this embodiment, the specific calculation formula for R_total is as follows:

[0215]

[0216] in: For conflict-free phase and abnormal event elimination rate; For queue length reduction rate and average vehicle speed increase rate; Simplification of traffic light switching frequency and low-traffic periods; The system considers whether hard constraints such as minimum green light and yellow light transition are met. Weights satisfy α>β>γ, reflecting the decision priority of "safety>efficiency>energy consumption". Simultaneously, a hard constraint coefficient δ is introduced, treating compliance (R_compliance) as a fundamental and mandatory requirement. Its value is much greater than α or it is used as a binary switch term (compliance rewards are valid; otherwise, the reward value is extremely low), ensuring that the model-generated strategy strictly meets the basic specifications of traffic signal control. The model continuously interacts with the simulation environment to optimize the strategy to maximize long-term cumulative rewards.

[0217] S3. Configure a structured prompt template for the signal control decision model. The prompt template includes the definition of decision roles and priorities, the definition of input data format, and the decision logic guidance. The decision logic guidance includes a quantitative condition judgment process based on a preset threshold.

[0218] For example, the text prompt (Prompt) reads: "You are a traffic signal control expert. Please generate the optimal signal phase scheme based on current traffic conditions, historical performance data, and environmental conditions. (Parameter subscript 0 indicates data from the previous cycle, and 1 indicates data from the current cycle;)"

[0219] Decision priority: safety > efficiency > energy consumption.

[0220] Input: Current period traffic data: Current period identification report (referred to as Report1), which is the statistical result after the end of a complete phase scheme cycle, including structured information such as the number of vehicles queuing in each direction, the number of pedestrians waiting, abnormal events, and special vehicles.

[0221] Traffic data from the previous period: The previous period identification report (denoted as Report0) is extracted from historical data by the system according to the timestamp and is used for trend comparison.

[0222] Parameter comparison: Calculate the differences between Report1 and Report0, focusing on the following metrics:

[0223] Absolute difference in lane queue length: ΔQ = |Q1 Q0| represents the current queue length of lane Q1, and Q0 represents the queue length of lane Q0 in the previous cycle. The queue length difference is calculated for each lane in each direction; this is the formula and method for calculating the difference.

[0224] Absolute difference in vehicle speed: ΔV = |V1 V0|, V1 is the vehicle speed in the current cycle, and V0 is the vehicle speed in the previous cycle; the speed difference is calculated for each lane in each direction, and this is the formula and method for calculating the difference.

[0225] Pedestrian gathering number: P1 (any side ≥ threshold T) p= 15) P1 indicates that the number of pedestrians waiting to cross the zebra crossing on either side in the current period is greater than the threshold T. p These actions will trigger AI to make decisions and analyze whether to adjust the traffic light phase scheme.

[0226] Lane occupancy rate: O1 = Q1 / L (L is the length of the detection zone, which is fixed);

[0227] Abnormal event flag: E1∈ {retrograde, accident};

[0228] Special vehicle markings: S1∈ {ambulance, police car, fire truck};

[0229] Should the phase scheme be adjusted?

[0230] If ΔQ>T q (e.g., threshold T) p = 8) or ΔV>T v (e.g., threshold T) v = 10 km / h) → Consider optimizing the basic four-phase;

[0231] If P1>T p → Consider pedestrian-only phases;

[0232] If O1 <T o (e.g., threshold T) o = 0.2) → Consider two-phase simplification;

[0233] If E1 exists → consider single-port rotation;

[0234] If S1 exists → consider the emergency response phase;

[0235] Fill in "yes" for all of the above;

[0236] Otherwise → No adjustment, fill in "No".

[0237] Reason for adjustment: To generate standardized labels;

[0238] The format is: [Event]_[Location]_[Time Period]_[Weather];

[0239] Example:

[0240] "Longer queues of vehicles_South entrance left-turn lane_Morning rush hour_Sunny day"

[0241] "Pedestrian gathering - East exit side - Peak school dismissal time - Sunny day"

[0242] Optional fields (including but not limited to):

[0243] Events: Surge in queues / Pedestrian congestion / Traffic violations / Accidents involving vehicles / Emergency vehicles / Short queues;

[0244] Orientation: East / West / South / North - Entrance / Exit - (Lane (Left / Right / Straight) / Pedestrian Walk (Side)) / All directions;

[0245] Time periods: Morning rush hour / Evening rush hour / Off-peak hour / Late night / School dismissal rush hour / Early morning;

[0246] Weather: Sunny / Rainy / Foggy / Snowy;

[0247] S4. During the deployment and application phase of the signal control decision model, a historical decision knowledge base is constructed: the input data, output signal control commands, and traffic effect data after execution of each decision are recorded; a decision scenario retrieval tag is generated based on the input data, and a comprehensive benefit score is calculated based on the traffic effect data; the retrieval tag, the comprehensive benefit score, the signal control command, and a timestamp are associated and stored as knowledge base entries.

[0248] For example, the steps for a decision knowledge base rule are as follows:

[0249] Step 1: Obtain assessment report data

[0250] Report1: Identification report used to generate decisions (pre-execution status);

[0251] Report 2: New identification report (post-execution status) collected after the new phase scheme has completed one full cycle;

[0252] Step 2: Calculate the comprehensive benefit score (parameter subscript 1 indicates identification data before the implementation of the new phase scheme, and 2 indicates identification data after the implementation of the new phase scheme);

[0253] Scoring formula: The weights are fixed: , , , ;

[0254] The improvement rates for each item are defined as follows:

[0255] Queue length reduction rate : ,in: : Total number of queuing entries for the four imports in Report 1; Total number of import queues for the four imports in Report2.

[0256] Vehicle speed improvement rate : ,in: : The average exit speed of Report 1; : The average exit speed of Report2; Base speed 35 km / h (adjustable);

[0257] Abnormal event elimination rate : 1 if there are no abnormal events (reverse / accident) in Report2, otherwise 0.

[0258] Pedestrian waiting time improvement rate If the number of pedestrians on the main gathering side in Report2 is ≤0.3 × the number of people on the corresponding side in Report1, then it is 1; otherwise, it is 0.

[0259] Step 3: Generate search tags

[0260] Tag = Adjustment reason tag generated during decision-making + Phase scheme type;

[0261] In this embodiment, the generation of decision scenario retrieval tags in step S4 and the generation of current retrieval tags based on current input data in step S5 are both based on the decision logic guidance in the structured prompt template, which parses the input data into standardized semantic tags containing event type, location, time period and weather information.

[0262] Example: "Longer vehicle queues - South entrance left-turn lane - Morning rush hour - Sunny day - Optimized four-phase traffic flow"

[0263] "Pedestrian congestion - East exit side - After-school rush hour - Sunny day - Pedestrian priority phase"

[0264] Step 4: Create knowledge base entries

[0265] Each record includes: active timestamp, search tag, comprehensive benefit score (Score), and phase scheme instruction code;

[0266] S5. When the signal control decision model makes a new decision, perform a retrieval enhancement decision: generate a current retrieval label based on the current input data, retrieve matching historical entries in the historical decision knowledge base, and provide the retrieved historical entry information as supplementary input to the model to generate the final signal control command;

[0267] For example, records matching the above tags are retrieved from the decision knowledge base, with the retrieval priority as follows: event → location → time period → weather. First, completely identical tags are matched; if none are found, the criteria are relaxed step by step, selecting the phase code with the highest comprehensive benefit score.

[0268] The specific search order is as follows:

[0269] Exactly match the current tag (e.g., "Pedestrians gathering at the east entrance_School dismissal rush_Rainy day");

[0270] If none is found, then match [location]_[event]_[time period] (ignoring weather);

[0271] If none is found, then match [location]_[event] (ignoring time period and weather);

[0272] If none is found, then match [Event] (ignore location, time of day, and weather).

[0273] In each level of matching results, the item with the highest overall benefit score is selected as the reference solution.

[0274] Expected output:

[0275] (1) Decision description:

[0276] ① If adjustments are needed: "Refer to the phase schemes in the knowledge base, and make specific adjustments based on the current [weather] [time period]." (If the time period / weather of the historical schemes are different, parameters such as the green light duration can be fine-tuned based on them.)

[0277] ② If no adjustment is made: "Compared to the previous period parameters, there is no significant change, therefore the current phase scheme is maintained." (No phase command is generated)

[0278] (2) Generate phase instructions: Output standard phase scheme instructions (including scheme number) that comply with traffic rules to ensure that constraints such as minimum green light duration and prohibition of phase conflict are met.

[0279] S6. Command Security Verification and Execution: Verify the format compliance, phase timing integrity, and conflict direction interlock security of the final signal control command; only when the verification passes will the command be sent to the signal control device for execution.

[0280] In this embodiment, the verification of the final signal control command in step S6 specifically includes: format and syntax compliance verification: checking the completeness of the required information items and the correctness of the data types of the command; including: checking whether the command contains all required information items, including phase scheme encoding, phase sequence, execution strategy, etc.; verifying whether each data type meets the requirements (e.g., green light duration and yellow light duration must be positive integers, and the timestamp format must be correct); ensuring the overall data structure is complete, without missing fields, nesting errors, or illegal characters. In addition, it also includes: checking whether the phase sequence covers all approach directions of the intersection and the necessary pedestrian crossing needs, preventing key flows from being ignored for a long time; confirming that each approach direction obtains at least one valid passage opportunity within a complete cycle of normal operation (except in cases of temporary interruption due to emergency events). Verifying whether the execution method (e.g., "execute immediately" or "execute after the current cycle ends") and execution count (e.g., "repeat execution 3 times") specified in the command are within the range supported by the signal equipment; prohibiting illegal strategy configurations such as zero executions or negative execution counts.

[0281] Phase timing integrity verification: Verify that the total duration of the signal cycle and the time values ​​of each phase are positive and continuous; including: verifying that the total duration of a complete signal cycle is within a reasonable range (usually 60 to 180 seconds) to avoid frequent switching caused by a cycle that is too short, or serious queuing caused by a cycle that is too long; checking that the green light time, yellow light time and all-red clearing time in each phase unit are all positive values; ensuring that each phase is continuous in time without overlap or gaps; verifying that the duration of the yellow light is not less than the safety minimum (e.g., not less than 3 seconds), and the duration of the all-red clearing phase is not less than 2 seconds.

[0282] Conflict Direction Interlock Verification: Based on a pre-stored intersection conflict direction relationship table, verify whether conflict direction signal light groups are simultaneously set to a state of allowing passage in the instruction; including: based on the predefined and unmodifiable "conflict direction relationship table" of the intersection physical layout, verify whether there are conflicts among all traffic flows that have green lights at the same time; ensure that when any motor vehicle passage direction is green, all its conflict direction (including opposite straight, opposite left turn, and intersecting directions) signal lights are red; ensure that when any pedestrian crossing direction is green, the corresponding oncoming vehicle signal and opposite left turn vehicle signal are red; verify that during the all-red clearing phase, all vehicle and pedestrian signals in all directions are in a red state.

[0283] If any of the above verification items fails, the instruction will be rejected. The system will automatically maintain the currently running phase scheme or revert to the previous phase scheme that has passed the safety verification, ensuring that the intersection signal control is always in a safe, legal and controllable state.

[0284] S7. Knowledge base update: Generate new entries based on the input data, signal control instructions, and traffic effect data corresponding to the new decision, compare them with the retrieved historical entries for comprehensive benefit scoring, and update the historical decision knowledge base according to preset rules.

[0285] In this embodiment, updating the historical decision knowledge base according to preset rules in step S7 includes: if the comprehensive benefit score of the new entry is higher than the score of the retrieved matching historical entry, then the new entry replaces the historical entry; and setting an active timestamp for the entries in the knowledge base, and periodically removing entries that have exceeded the preset inactive time limit.

[0286] For example, incremental updates to the decision knowledge base:

[0287] After implementing the new phase scheme, a new entry is generated according to the decision knowledge base construction process described above.

[0288] Scenario 1: This decision-making process referenced historical plans;

[0289] Determine the degree of label matching between the new scheme and the reference scheme:

[0290] If the tags match exactly: If the new score is greater than the reference score, it means that the new solution is better. In this case, the current reference solution is deleted and the new solution is stored in the decision knowledge base. If the new score is not greater than the reference score, the new solution is discarded and the active timestamp of the reference solution is updated to keep it active.

[0291] If the tag partially matches: update the active timestamp of the reference solution to keep it active; if the new solution's score is greater than the threshold (e.g., 0.6), store it as a new entry in the knowledge base; if the score is less than or equal to the threshold (e.g., 0.6), discard it (consider it an invalid attempt).

[0292] Scenario 2: There are no alternative solutions for this decision;

[0293] If the score is greater than the threshold (e.g., 0.6), the solution will be stored as a new entry in the knowledge base.

[0294] If the score is less than or equal to the threshold (e.g., 0.6), the attempt is discarded (considered an invalid attempt).

[0295] The system periodically (e.g., every 30 days) scans the decision knowledge base, deleting entries whose active timestamps have not been updated for a long time (e.g., those not referenced for more than 90 days). Each time a decision is made, the current identification report is appended with a timestamp and stored in the historical database. This report is recorded regardless of whether the phase is adjusted, serving as the source of "previous cycle data" for subsequent cycles. A timestamp index is established to support fast retrieval by time.

[0296] In this embodiment, the method further includes:

[0297] S8, perform lightweight processing on the signal control decision model to obtain a lightweight model suitable for deployment on edge computing devices; the lightweight processing includes one or more of knowledge distillation, quantization or pruning.

[0298] For example, considering the limited computing power of edge devices such as NVIDIA Jetson, this embodiment generates a small student model (<1B parameters) through structured pruning and knowledge distillation; it uses 8-bit integer quantization and TensorRT to accelerate inference; and it adopts memory reuse scheduling and pre-allocates buffers to avoid the overhead of dynamic memory allocation.

[0299] Please see Figure 4 The usage method is as follows:

[0300] Phase 1: Initialization and Deployment

[0301] This phase involves one-time or periodic preparatory work aimed at creating a dedicated intelligent control infrastructure for specific intersections.

[0302] 1. Hardware Deployment and Environmental Digitalization:

[0303] Deploy high-definition cameras and edge computing devices (such as NVIDIA Jetson) at key locations at the intersection. Create a dedicated "intersection physical conflict point matrix" and "conflict direction relationship table" for the intersection, accurately encoding the safety conflict rules for all traffic flows. Define the intersection's lane topology, approach directions, and traffic light group numbers, and embed them in the configuration file.

[0304] 2. Model Training and Lightweighting:

[0305] Using simulation or historical data, and based on the aforementioned conflict rules, a large number of paired samples of "structured traffic state data" and corresponding "conflict-free signal control instructions" are generated. Using the methods described (S1, S2), the selected base LLM is supervised fine-tuned and reinforcement learned using these paired samples to obtain the initial "signal control decision model under safety constraints" for this intersection. This model is then processed through knowledge distillation and quantization to generate a lightweight model that can run efficiently on local edge devices.

[0306] 3. System initialization configuration:

[0307] Configure a "structured prompt template" for this lightweight model, clearly defining its decision-making role, priority (safety > efficiency > energy consumption), and threshold-based quantitative judgment logic. Initialize an empty or a "historical decision knowledge base" containing basic strategies.

[0308] Phase Two: Closed Loop of Daily Operational Decision-Making

[0309] This stage is the real-time processing flow that is automatically executed within each signal control cycle after the system goes online.

[0310] 1. Perception and structuring:

[0311] The camera's real-time video stream is processed by target detection and multi-target tracking algorithms to generate the motion trajectories of vehicles and pedestrians. Based on the trajectory data, the queue length, average vehicle speed, and number of pedestrians in each lane are calculated according to predefined rules (such as the number of stationary vehicles behind the stop line).

[0312] Key steps: Identify and label semantic events (e.g., “accident vehicle,” “ambulance,” “pedestrian gathering”). Assemble all information into a structured traffic status report (JSON format) conforming to the “first predetermined pattern.”

[0313] 2. Search-enhanced decision-making:

[0314] The system inputs the current structured report into a lightweight LLM model deployed on an edge device. Simultaneously, based on the report content and the logic of the prompt template, it generates a retrieval tag for the current decision-making scenario (e.g., "morning rush hour_surge in left-turn queues at the south entrance_sunny day"). The system uses this tag to quickly retrieve matching or similar historical best-case decisions from the historical decision knowledge base. The LLM model integrates the current real-time state and the retrieved historical best-case, runs its inference logic, and generates a final signal control command. This command conforms to a "second predetermined pattern," including the phase scheme, duration, and light group state matrix.

[0315] 3. Independent security verification and execution:

[0316] Before a command is sent to a physical signal controller, it must pass through an independent command security verification module.

[0317] The verification module executes the following sequentially:

[0318] Format validation: Checks the integrity and validity of the JSON command.

[0319] Timing verification: Check whether the cycle, green light, and yellow light times are reasonable and continuous.

[0320] Conflict verification (core): The "signal light group status matrix" in the instruction is compared with the pre-stored "intersection conflict direction relationship table" to ensure that no conflicting directions are allowed to pass at the same time.

[0321] Result branch:

[0322] Verification passed: The instruction is immediately sent to the signal control unit to control the traffic lights at the intersection to operate according to the new scheme.

[0323] Verification fails: The instruction is intercepted and discarded. The system automatically maintains the current scheme or switches to the preset safety backup scheme, and triggers an alarm.

[0324] 4. Effectiveness Evaluation and Recording:

[0325] After a complete cycle of executing a new instruction, the system collects traffic performance data for that cycle again. Based on the comparison of the state before and after execution, the system calculates a comprehensive benefit score for this decision (quantitatively assessing effects such as queue reduction and efficiency improvement).

[0326] Phase Three: Long-Term Evolution and Maintenance

[0327] This stage is a background process in which the system optimizes itself using actual operating data during long-term operation.

[0328] 1. Competitive updates to the decision-making knowledge base:

[0329] The system packages the inputs (status report), outputs (instructions), effects (scores), and generated scenario tags of this decision into a new knowledge entry. It updates the historical decision knowledge base according to preset rules (S7): if the new entry's score is higher than a previously retrieved historical entry, the old entry is replaced. Regardless of replacement, the entry's "active timestamp" is updated. The system periodically (e.g., every 30 days) automatically cleans up entries in the knowledge base with outdated "active timestamps" (e.g., entries not referenced for more than 90 days) to ensure the timeliness and conciseness of the knowledge base.

[0330] 2. Periodic retraining and updating of the model:

[0331] After the system has been running for a period of time (such as quarterly or annually), it leverages the large amount of real-world decision-making data (structured state-instruction pairings) accumulated in the knowledge base, along with new traffic flow patterns, to initiate a new round of fine-tuning or training on the complete model in the cloud or locally. The retrained and lightweighted superior model is then updated to edge devices to replace the old model, thereby completing the iterative upgrade of the entire system (model and knowledge).

[0332] The "Method for Constructing a Safety-Enhanced Intelligent Decision-Making System for Traffic Signals" provided by this invention offers a complete solution to the new safety, reliability, and sustainability issues arising from the introduction of LLM (Local Management Model).

[0333] First, addressing the "risk of LLM security failure," this invention fundamentally constrains generative models into security decision-making models through a "training and verification architecture embedded with security rules." This invention designs a security-first training paradigm. During the supervised fine-tuning phase, all instruction samples in the training data are verified through a conflict point matrix to ensure compliance. During the reinforcement learning phase, security rules are creatively transformed into reward items with veto power. This ensures that the penalty for a single unsafe act during training far outweighs any efficiency gains, thus internalizing security as the highest priority at the parameter optimization level. This is equivalent to "implanting" an inviolable security instinct into LLM, resolving the core vulnerability of unpredictable output.

[0334] Secondly, addressing the issues of "decision-making black boxes and unreliability," this invention employs a "structured reasoning guidance and case retrieval mechanism" to make the decision-making process explainable and traceable. To avoid the generation of "black boxes" in LLM (Local Management Model), this invention equips it with a structured decision-making framework (structured prompt templates), guiding its reasoning to a standardized process of "state analysis - threshold judgment - scenario classification." More importantly, the system builds a historical decision knowledge base during runtime, quantifying and associating decision scenarios, solutions, and effects. When making new decisions, the model prioritizes searching for and referencing similar historical best cases (retrieval enhancement steps). This ensures that every decision is based on evidence-based analogical reasoning, greatly enhancing the rationality and transparency of the decision-making process and achieving "white-box" decision-making.

[0335] Third, addressing the disconnect between static models and dynamic needs, the system achieves continuous self-optimization through a closed-loop operation and a competitive evolution mechanism for the knowledge base. This invention designs the system as a dynamically evolving intelligent agent, rather than a statically deployed model. During operation, the system continuously collects feedback, quantifies the merits of each decision using a comprehensive benefit score, and competitively updates the historical knowledge base (knowledge base optimization step) based on this. Excellent strategies are retained and strengthened, while ineffective strategies are eliminated. This allows the system's decision-making intelligence to continuously evolve with the accumulation of actual operational data, adapting to long-term changes in traffic patterns, forming a virtuous cycle of deployment-learning-optimization, and solving the problem of knowledge aging in static models.

[0336] In summary, the core contribution of this invention lies in constructing a complete engineering technology system capable of systematically constraining, guiding, and continuously optimizing LLM, enabling it to safely, reliably, and transparently perform real-time traffic control tasks. This system effectively solves the security, reliability, and adaptability issues that are inevitably faced when introducing cutting-edge artificial intelligence technologies.

[0337] It is important to note that this invention proposes a solution to address the problems associated with applying Large Language Models (LLM) to edge traffic signal control, aiming to ensure the safety, fairness, reliability, and continuous evolution capability of the system. The main problems and corresponding countermeasures are as follows:

[0338] Regarding decision-making quality and safety, the primary issue is that LLM (Local Level Management) may generate legal but unfair control schemes, such as excessively sacrificing right-of-way in other directions to respond to high-priority events. To address this, this invention embeds non-overridable hard fairness constraints (such as setting maximum consecutive red light time and minimum green light time for each direction) into the prompts, forcing the model to ensure basic right-of-way fairness during inference. Secondly, in extreme complex scenarios with multiple concurrent high-priority events, LLM suffers from insufficient generalization ability and may generate logically conflicting solutions. This invention, through a pre-built structured emergency decision-making rule base and a dynamic event priority parsing mechanism, injects a clear order of actions and standard logic into the prompts, guiding LLM to generate multi-stage control schemes that conform to regulations.

[0339] At the system security and reliability level, issues arising from external attacks and inherent model defects need to be addressed. First, there's the risk of injection attacks, where malicious text may contaminate prompts and induce dangerous outputs. This invention addresses this by using structured semantic cleaning and field isolation mechanisms to parse the perception results into predefined semantic slots, blocking free text injection at the source. Second, there's the model illusion problem, where LLMs may fabricate non-existent traffic events. This invention introduces an event confidence threshold linkage mechanism, only including events in reports when the perceived confidence level exceeds a set threshold, guiding LLMs to adopt conservative strategies for low-confidence events.

[0340] At the level of engineering deployment and long-term effectiveness, technical limitations must be overcome and continuous system optimization must be ensured. Addressing the issue that information from complex intersections may exceed the LLM context window, this invention employs a hierarchical summary-based report generation strategy to structurally compress perceived data, ensuring that core safety elements are fully incorporated into reasoning. To address the concern that introducing a decision knowledge base might lead to LLM dependency and weaken its necessity, this invention's knowledge base is actually an "experience memory" generated by LLM, validated for effectiveness, and continuously dynamically updated. Its operating mechanism forces LLM to always dominate initial decision-making, with the knowledge base only providing reference; simultaneously, mechanisms such as "active timestamps" eliminate outdated strategies, incentivizing continuous innovation in LLM. This effectively solves the problem of static knowledge in traditional LLM, forming an intelligent closed loop of "generation-validation-accumulation-inspiration," which not only does not weaken the core position of LLM but also enhances the system's adaptability and continuous optimization capabilities.

[0341] Furthermore, most publicly available cases of integrating LLM with traffic signal control focus on utilizing LLM's natural language interaction capabilities for status queries, auxiliary analysis, or generation of control strategy descriptions, or on using its knowledge base for offline scheme optimization. These applications do not achieve a closed loop of "perception-semantic understanding-real-time dynamic phase scheme generation-execution," and in particular, lack a complete architecture for completing real-time, safety-critical decisions on edge devices.

[0342] In summary, this invention systematically addresses potential issues such as decision bias, security vulnerabilities, and performance bottlenecks in LLM applications through a comprehensive approach including embedding hard constraints, structured emergency rules, input cleaning, confidence level linkage, data compression, and the construction of a self-evolving decision knowledge base. This solution ensures that LLM-based edge traffic control agents can achieve reliable, interpretable, and long-term learning-capable adaptive signal optimization while meeting multiple constraints such as safety and fairness.

[0343] Example 2

[0344] Please see Figure 5 An apparatus for constructing an intelligent decision-making system for traffic signal control, based on the method described in one embodiment, the apparatus comprising:

[0345] The model training module is used to execute the methods for the model training and deployment phases.

[0346] An application evolution module is used to execute the methods of the application and evolution stages.

[0347] In this embodiment, in order to better utilize the method described in one of the embodiments, this application proposes an intelligent decision-making system construction device for traffic signal control. Each module corresponds to a step of the above method, and its specific principle has been described above and will not be repeated here.

[0348] Example 3

[0349] An apparatus for constructing an intelligent decision-making system for traffic signal control, comprising:

[0350] At least one processor and a memory communicatively connected to said at least one processor;

[0351] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in one of the embodiments.

[0352] In this embodiment, to better run and process the method described in one of the embodiments, the above method is stored in a memory, and the stored method is executed using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated further here.

[0353] Example 4

[0354] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in one of the embodiments.

[0355] In this embodiment, to better operate and use the method described in one of the embodiments, the above method is stored in a computer-readable storage medium, and the above method is implemented using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated further here.

[0356] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

[0357] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for constructing an intelligent decision-making system for traffic signal control, characterized in that, The method comprises two parts: a model training and deployment phase and an application and evolution phase, as detailed below: Model training and deployment phases: S1. Based on pre-stored road traffic conflict rules, generate a paired training sample set of structured traffic state data and conflict-free signal control instructions; The large language model is then fine-tuned under supervision using the paired training sample set to obtain the base model. S2. The basic model is connected to the traffic simulation environment for reinforcement learning training; in each training step, the basic model outputs signal control commands according to the current traffic state, and performs safety verification on the commands according to the road traffic conflict rules, and generates a safety reward signal. A composite reward function is constructed based on the safety reward signal and at least one traffic efficiency index signal to optimize the parameters of the basic model and obtain a signal control decision model under safety constraints. S3. Configure a structured prompt template for the signal control decision model. The prompt template includes the definition of decision roles and priorities, the definition of input data format, and the decision logic guidance. The decision logic guidance includes a quantitative condition judgment process based on a preset threshold. Application and Evolution Stages: S4. During the deployment and application phase of the signal control decision model, a historical decision knowledge base is constructed; the input data, output signal control commands, and traffic effect data after execution of each decision are recorded; a decision scenario retrieval tag is generated based on the input data, and a comprehensive benefit score is calculated based on the traffic effect data; the retrieval tag, the comprehensive benefit score, the signal control command, and a timestamp are associated and stored as knowledge base entries. S5. When the signal control decision model makes a new decision, perform a retrieval enhancement decision; generate a current retrieval label based on the current input data, retrieve matching historical entries in the historical decision knowledge base, and provide the retrieved historical entry information as supplementary input to the model to generate the final signal control command; S6. Verify the format compliance, phase timing integrity, and conflict direction interlock security of the final signal control command; only when the verification passes will the command be sent to the signal control device for execution. S7. Generate a new entry based on the input data, signal control instructions, and traffic effect data corresponding to the new decision, compare it with the retrieved historical entries for a comprehensive benefit score, and update the historical decision knowledge base according to preset rules.

2. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 1, characterized in that, In step S2, the step of verifying the safety of the instruction according to the road traffic conflict rules and generating a safety reward signal specifically includes: If the signal control command passes the security verification, the security reward signal R_safe = 0; if it fails, the security reward signal R_safe = -C, where C is a preset penalty constant. The security verification specifically involves parsing the instruction into a state sequence of each traffic light group and comparing it with a pre-stored matrix of physical conflict points at the intersection. If any conflict point corresponds to a traffic light group state combination that simultaneously allows passage, the verification fails. The composite reward function is a weighted sum of the safety reward signal and the at least one traffic efficiency reward signal, i.e., R_total = α * R_safe + β * R_efficiency, where R_efficiency is the traffic efficiency reward signal, the weighting coefficients α and β are preset values, and satisfy |α * C| > K * |β * M|, where M is the maximum absolute value that the traffic efficiency reward signal may obtain in a single step, and K is a preset coefficient greater than 1.

3. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 1, characterized in that, The structured traffic data is generated based on the movement trajectory information of vehicles and pedestrians extracted from video data; The traffic status structured data conforms to the first predetermined pattern and includes at least the number of vehicles queuing by import direction and lane type, vehicle type distribution, number of pedestrians in waiting areas, and semantic abnormal event identifier fields; the conflict-free signal control command conforms to the second predetermined pattern and includes at least the phase scheme code, duration of each phase, signal light group status matrix, and safety semantic label.

4. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 3, characterized in that, The semantic abnormal event identifier field is used to identify traffic events with natural language semantics parsed from the motion trajectory information, including one or more of the following: traffic accidents, special vehicle passage, school dismissal, and severe weather effects.

5. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 1, characterized in that, The generation of decision scenario retrieval tags in step S4 and the generation of current retrieval tags based on current input data in step S5 are both based on the decision logic guidance in the structured prompt template, which parses the input data into standardized semantic tags containing event type, location, time period and weather information. Step S6 verifies the final signal control command, specifically including: Format and syntax compliance verification: Check the completeness of the required information items of the instruction and the correctness of the data type; Phase timing integrity verification: Verify that the total duration of the signal period and the time values ​​of each phase are positive and continuous; Conflict direction interlock verification: Based on the pre-stored intersection conflict direction relationship table, verify whether there are conflict direction signal light groups that are simultaneously set to the state of allowing passage in the verification instruction.

6. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 1, characterized in that, The step S7, which updates the historical decision knowledge base according to preset rules, includes: if the comprehensive benefit score of the new entry is higher than the score of the retrieved matching historical entry, then the new entry replaces the historical entry; and an active timestamp is set for the entries in the knowledge base, and entries that have exceeded the preset inactive time limit are periodically removed.

7. The method for constructing an intelligent decision-making system for traffic signal control as described in claim 1, characterized in that, The method further includes lightweighting the signal control decision model to obtain a lightweight model suitable for deployment on edge computing devices; the lightweighting process includes one or more of knowledge distillation, quantization, or pruning.

8. A device for constructing an intelligent decision-making system for traffic signal control, characterized in that, Based on the method according to any one of claims 1-7, the apparatus comprises: The model training module is used to execute the methods for the model training and deployment phases. An application evolution module is used to execute the methods of the application and evolution stages.

9. A device for constructing an intelligent decision-making system for traffic signal control, characterized in that, include: At least one processor and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images