System and method for evaluation and closed-loop iteration of a traffic robot strategy

Abstract

This application provides a system and method for evaluating and iterating traffic robot strategies, belonging to the field of robotics technology. The solution aims to address the problems of existing robot strategy evaluations being limited in scope, difficult to pinpoint problems, and high-risk update processes. The system evaluates traffic robot strategies based on a multi-layered strategy effectiveness evaluation framework, including an understanding layer, a task planner, an execution layer, and a business layer. Based on the evaluation results, the strategy is updated and deployed through a closed-loop iterative process, including offline evaluation, simulation playback, low-traffic pilot testing, and full deployment. The evaluation results are used to label training samples to drive the retraining of machine learning models. The solution also includes continuous monitoring and automatic rollback after full deployment. This application can accurately pinpoint strategy defects, ensure deployment safety, and achieve data-driven continuous self-optimization.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a system and method for evaluating and optimizing traffic robot strategies. Background Technology

[0002] After autonomous systems such as traffic robots are deployed in real-world environments, the effectiveness of their operational strategies requires continuous evaluation and optimization. Currently, some technical solutions have proposed using evaluation feedback to adjust and optimize model parameters, thereby achieving a certain degree of closed-loop iteration. However, these solutions often focus only on final business-level metrics, such as traffic management efficiency and vehicle transit time, when evaluating strategies. When business metrics fail to meet expectations, this single-dimensional evaluation method struggles to accurately pinpoint the root cause of the problem, failing to determine whether the strategy of the environmental perception module, task planning module, or specific action execution module is flawed. Furthermore, existing strategy update processes often lack systematic security mechanisms. New strategy versions lack step-by-step verification in offline, simulation, and real low-traffic environments before deployment, potentially leading to decreased strategy effectiveness or even security incidents. Simultaneously, the strategy optimization process largely relies on engineers' manual analysis and experience, lacking a data-driven closed-loop path that systematically and automatically feeds evaluation results back to the model training stage, resulting in low iteration efficiency. Therefore, how to systematically and meticulously evaluate the strategies of complex systems such as transportation robots in order to accurately locate problems, and how to design a safe and engineered iterative deployment process to manage the risks of strategy updates, are technical problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0003] The purpose of this application is to provide a system and method for evaluating and iterating traffic robot strategies, aiming to solve the problems existing in the prior art, such as the single dimension of robot strategy evaluation, difficulty in problem localization, high risk of update process, and reliance on manual iteration optimization.

[0004] To achieve the above objectives, this application provides a system for evaluating and iterating a traffic robot strategy, comprising: an evaluation module for evaluating a traffic robot strategy generated by a machine learning model based on a multi-layer strategy effectiveness evaluation system, wherein the multi-layer strategy effectiveness evaluation system includes: understanding layer evaluation, task planner evaluation, execution layer evaluation, and business layer evaluation; an iteration control module for updating and deploying the strategy to be evaluated based on the evaluation results of the evaluation module through a closed-loop iteration process, wherein the closed-loop iteration process includes: an offline evaluation phase, a simulation playback phase, a low-traffic pilot phase, and a full deployment phase; and a model training interface module for outputting the evaluation results of the evaluation module as labels for marking training samples to drive the retraining of the machine learning model.

[0005] Optionally, the iteration control module is also used to continuously monitor and evaluate metrics during the full rollout phase, and automatically perform a rollback operation when any preset metric triggers a threshold.

[0006] Furthermore, the automatic rollback operation is used to revert the policy version to the policy version that was running online before this full deployment.

[0007] Optionally, when the evaluation module performs the business layer evaluation, the evaluation indicators it uses include at least one of the following: queue length reduction rate, average vehicle dwell time, and number of conflicts.

[0008] Optionally, when the evaluation module evaluates the task planner, the evaluation indicators it uses include at least one of the following: planning suggestion adoption rate and false trigger rate.

[0009] Optionally, during the simulation playback phase, the iterative control module simulates the strategy to be evaluated in at least one simulation environment selected from SUMO, VISSIM, and CARLA.

[0010] Optionally, the model training interface module is used to mark policy execution fragments with evaluation results not lower than a preset performance threshold as positive samples, and to mark policy execution fragments with evaluation results lower than the preset performance threshold as negative samples.

[0011] This application also provides a method for evaluating and iterating a traffic robot strategy in a closed loop, comprising: evaluating a traffic robot strategy to be evaluated generated by a machine learning model based on a multi-layer strategy effectiveness evaluation system, wherein the multi-layer strategy effectiveness evaluation system includes: understanding layer evaluation, task planner evaluation, execution layer evaluation, and business layer evaluation; updating and deploying the strategy to be evaluated based on the evaluation results through a closed loop iteration process, wherein the closed loop iteration process includes: offline evaluation stage, simulation playback stage, low-traffic pilot stage, and full deployment stage; and using the evaluation results to label training samples to drive the retraining of the machine learning model.

[0012] Optionally, the full rollout phase includes: continuously monitoring and evaluating metrics, and automatically performing a rollback operation when any preset metric triggers a threshold, so as to revert the strategy version to the strategy version running online before this full rollout.

[0013] Optionally, the method further includes: automatically generating a replayable record, the replayable record including: a comparison of state snapshots before and after strategy execution, and the results of the evaluation.

[0014] Compared with existing technologies, the technical solution provided in this application has the following beneficial effects: By establishing a multi-layered strategy effect evaluation system including an understanding layer, task planner, execution layer, and business layer, ambiguous strategy effect problems can be accurately located to specific strategy modules, greatly improving the efficiency of R&D and optimization. Furthermore, by designing a closed-loop iterative process including offline evaluation, simulation playback, small-scale pilot testing, and full deployment, a multi-level verification gating system is constructed, which can filter risks layer by layer, ensuring a smooth and controllable deployment process for new strategies and avoiding negative impacts on the actual traffic environment or safety accidents caused by strategy defects. Moreover, by establishing a feedback loop from evaluation results to model training, the evaluation results are directly used to label training data, opening up the "execution-evaluation-learning" closed loop and forming an automated data-driven flywheel. This allows the robot strategy to continuously learn and improve from its own experience, reducing reliance on manual analysis and tuning, and improving the automation level and long-term effectiveness of strategy iteration. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of the overall architecture of a traffic robot strategy evaluation and closed-loop iterative system provided in this application embodiment;

[0017] Figure 2 A flowchart illustrating a traffic robot strategy evaluation and closed-loop iteration method provided in an embodiment of this application;

[0018] Figure 3 This is a signaling interaction timing diagram of the small-volume pilot process in the embodiments of this application;

[0019] Key reference numerals: 100 – Traffic robot body; 200 – Multi-layer strategy evaluation module; 210 – Understanding layer evaluation unit; 220 – Task planner evaluation unit; 230 – Execution layer evaluation unit; 240 – Business layer evaluation unit; 300 – Closed-loop iterative control module; 310 – Offline evaluation controller; 320 – Simulation playback controller; 330 – Small-flow pilot controller; 340 – Full monitoring and rollback controller; 400 – Model training platform. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit the scope of protection of this application.

[0021] Example 1

[0022] This embodiment details the complete application process of a traffic robot strategy evaluation and closed-loop iterative system and method, which aims to optimize the performance of the traffic robot's "task planner" to reduce unnecessary intervention.

[0023] Please see Figure 1 This figure is a schematic diagram of the overall architecture of a traffic robot strategy evaluation and closed-loop iteration system provided in one embodiment of this application. The system may include one or more traffic robot bodies 100 deployed at traffic intersections, a multi-layer strategy evaluation module 200, a closed-loop iteration control module 300, and a model training platform 400. It should be noted that these modules can be physically independent servers or logical functional units deployed on a cloud computing platform.

[0024] As the ultimate executor of the strategy, the traffic robot body 100's built-in machine learning model determines its behavioral strategy in specific traffic scenarios. During operation, the traffic robot body 100 collects raw environmental data through its sensors (such as cameras, lidar, etc.) and executes actions determined by its current strategy, such as traffic gestures and voice announcements.

[0025] The multi-layer strategy evaluation module 200 is one of the core components of the technical solution of this application. Its function is to receive operational data from the traffic robot body 100 and to quantitatively evaluate the strategy performance from multiple dimensions. Figure 1 As shown, this module can be further divided into multiple evaluation units to achieve a comprehensive evaluation of the robot's workflow. Specifically, the understanding layer evaluation unit 210 is used to evaluate the robot's perception and understanding of the environment; the task planner evaluation unit 220 aims to evaluate the rationality of the task plan generated by the robot's decision center; the execution layer evaluation unit 230 evaluates the quality of the robot's physical actions; and the business layer evaluation unit 240 is responsible for evaluating the robot's effectiveness in completing the final traffic management task from a macroscopic perspective.

[0026] The closed-loop iterative control module 300 is the command center for the entire iterative process. This module receives evaluation results from the multi-layer policy evaluation module 200 and controls the lifecycle of the policy to be evaluated based on these results. Figure 1As shown, the module may include an offline evaluation controller 310, a simulation playback controller 320, a small-volume pilot controller 330, and a full monitoring and rollback controller 340, which correspond to different stages of strategy iteration.

[0027] The model training platform 400 is responsible for training and optimizing the machine learning model. This platform works closely with the multi-layer policy evaluation module 200 and the closed-loop iterative control module 300. It receives labeled training samples transformed from the evaluation results and initiates the model retraining task according to the instructions of the closed-loop iterative control module 300, ultimately producing an optimized new model or new policy.

[0028] In this embodiment, assume a city traffic management center aims to optimize the task planner strategy of a traffic robot 100 deployed at a busy intersection. The current baseline strategy running online is S1, which is generated by a specific machine learning model. The engineering team develops a new strategy S2 to be evaluated, with the goal of reducing the "false trigger rate" of unnecessary interventions in non-congested scenarios present in strategy S1. The entire optimization process follows... Figure 2 The method flow is shown.

[0029] The process begins with the completion of the development of the new strategy S2 (step S10). Subsequently, the closed-loop iterative control module 300 initiates the evaluation and deployment process of strategy S2.

[0030] First, the process enters the offline evaluation phase S20, which is led by the offline evaluation controller 310. The system collects all historical data of all traffic robots 100 operating at the intersection over the past six months, including raw sensor data, strategy decision logs, and human intervention records, thus forming a large offline dataset. The offline evaluation controller 310 runs the baseline strategy S1 and the strategy to be evaluated S2 in offline mode on this dataset. The multi-layer strategy evaluation module 200 analyzes the results of both. In this embodiment, since the optimization target is the task planner, the evaluation results of the task planner evaluation unit 220 are particularly critical. The evaluation report shows that at the task planner evaluation level, the "false trigger rate" of strategy S2 significantly decreased from 15% of strategy S1 to 8%, while the "planning suggestion adoption rate" (i.e., the proportion of intervention actions of the strategy suggestion that are judged to be effective by the background safety officer or the system) increased from 70% to 78%. Furthermore, reports from the understanding layer evaluation unit 210, the execution layer evaluation unit 230, and the business layer evaluation unit 240 indicate that strategy S2 shows no significant degradation compared to S1 in other metrics such as target detection accuracy, action execution latency, and simulated traffic management efficiency. Based on this evaluation result, the offline evaluation controller 310 determines that the core optimization objective of the evaluated strategy S2 has been achieved without introducing any other negative impacts, thus meeting the gating conditions for proceeding to the next stage.

[0031] Next, the process enters the simulation playback stage S30, which is led by the simulation playback controller 320. To test strategy S2 in a more complex dynamic interactive environment, the system selects a high-fidelity microscopic traffic simulation environment, such as SUMO. The simulation playback controller 320 selects 100 representative traffic congestion scenarios (such as rush hours, traffic accidents, and severe weather) that have actually occurred in history from the historical dataset and digitally reconstructs these scenarios in the SUMO environment. Subsequently, a virtual traffic robot whose behavior is entirely driven by strategy S2 is injected into these simulation scenarios. During the simulation, the system focuses on observing changes in business layer indicators and checking for new dangerous behaviors or edge cases that were not detected in the offline evaluation. After large-scale simulation testing, the analysis of the business layer evaluation unit 240 shows that the "average traffic management completion time" of the virtual robot using strategy S2 in these scenarios is basically the same as that of strategy S1, and no abnormal collisions, red-light running, or dangerous behaviors causing traffic jams occur. Based on this, the simulation playback controller 320 judges that strategy S2 has passed the simulation verification.

[0032] Next, the process enters the low-volume pilot phase S40, which is led by the low-volume pilot controller 330. The interaction flow can be found in [reference needed]. Figure 3 The traffic management center's operations and maintenance personnel initiated a pilot command for strategy S2 to the closed-loop iterative control module 300 via the system interface. Upon receiving the command, the low-flow pilot controller 330 selected a traffic robot 100 located at intersection A in the city as the pilot target and distributed the configuration package for strategy S2 to the robot. Over the next three days, the robot operated using strategy S2 in a real traffic environment, continuously reporting its operational data (including sensor data, decision logs, execution status, etc.) to the evaluation data backend. The multi-layer strategy evaluation module 200 analyzed this real-world data in real time. Three days later, the report generated by the task planner evaluation unit 220 showed that strategy S2's "false trigger rate" in the real environment was 9%, and the "planning suggestion adoption rate" was 75%, which largely matched the predictions from the offline evaluation. More importantly, the report from the execution layer evaluation unit 230 showed that during the entire pilot period, the robot did not experience any safety incidents requiring emergency intervention by a human safety officer. Based on this information, the small-flow pilot controller 330 determined that strategy S2 performed stably, safely, and effectively in the real environment, indicating a successful pilot, and provided positive feedback on the pilot results to the operations and maintenance personnel.

[0033] Finally, after confirming the pilot's success, the process entered the full deployment phase (S50). The full monitoring and rollback controller 340 in the closed-loop iterative control module 300 began executing the full deployment operation, pushing strategy S2 to all traffic robot bodies 100 of the same model in the city. After deployment, the system entered the continuous monitoring phase (S60). One week after full deployment, the system automatically generated a business layer evaluation report. The business layer evaluation unit 240 analyzed a week's worth of macro traffic data and found that after applying strategy S2, the average queue length of vehicles at all relevant intersections during peak hours decreased by 12% compared to the period when strategy S1 was used. At the same time, the average vehicle dwell time and the number of traffic conflicts also decreased to varying degrees. These data indicate that the new strategy S2 not only achieved the initial goal of reducing the false trigger rate but also brought significant improvements in business value.

[0034] Through the complete process of this embodiment, a newly developed strategy S2 to be evaluated was successfully deployed to the entire network after undergoing layer-by-layer verification through offline, simulation, and pilot testing to ensure its security and effectiveness, and achieved the expected technical effects and business benefits.

[0035] Example 2

[0036] This embodiment aims to describe how to use the multi-layered evaluation system provided in this application to identify and resolve mismatches between different system levels when the hardware of a traffic robot changes, thereby ensuring a smooth transition for system upgrades.

[0037] In a specific application scenario, to improve the environmental perception capabilities of traffic robots at night and in adverse weather conditions (such as rain, snow, and fog), the technical team decided to replace the cameras on a batch of 100 traffic robots with higher resolution cameras that offer superior low-light performance. Along with the new hardware, the perception algorithm team also updated the corresponding camera drivers and underlying machine learning models (such as object detection models), resulting in a new strategy and firmware package, referred to as the strategy to be evaluated. Its benchmark strategy is the policy package currently running online that uses older cameras. The primary goal of this upgrade is to validate the new policy package. Does the performance of the "understanding layer" truly outperform the baseline policy package? And ensure that it is well compatible with the planning and execution modules at the upper level.

[0038] The upgrade verification process also follows... Figure 2 The process is shown below.

[0039] First, in the offline evaluation phase S20, to specifically test the performance of the new hardware and model under specific challenging scenarios, the testing team prepared a dedicated offline test dataset. This dataset contains a large number of real traffic videos recorded under low visibility conditions such as nighttime, dusk, rain, and snow. The system uses this dataset to... The policy package is evaluated. The understanding layer evaluation unit 210 in the multi-layer policy evaluation module 200 outputs key evaluation results: In processing this challenging dataset, The strategy package's "average precision for object detection" improved from 65% to 78%, with a particularly significant improvement in detecting small objects such as pedestrians and non-motorized vehicles. Simultaneously, for key traffic events, such as "detecting a broken-down vehicle ahead," the "event recognition recall" improved by 20 percentage points, while the false positive rate remained at the same level. These data clearly demonstrate that, from the understanding layer perspective, Compared to perception ability Significant improvements have been made. Based on this, the offline evaluation controller 310 has been approved. Moving on to the next stage.

[0040] Next, the strategy package Entering the simulation playback phase S30. Considering the realism of nighttime and weather effects, this simulation uses the CARLA simulation environment, renowned for its high image quality and detailed simulation of weather and lighting. The simulation playback controller 320 constructs multiple virtual city intersections within CARLA, including nighttime and rainstorm scenes. When equipped with... When the virtual robot in the strategy package entered these scenarios, an unexpected problem arose. Although the output of its understanding layer evaluation unit 210 confirmed that its perception capabilities were indeed stronger, able to detect pedestrians on the roadside earlier and farther, the task planner evaluation unit 220 reported an anomaly. Data showed that the "false trigger rate" in the task planner evaluation metrics had increased. By replaying the specific simulation logs, it was found that the problem lay in the planning layer strategy's over-reliance on the results of the perception layer's output. When the perception module detected a suspected pedestrian target at a distance with low confidence, the planning module would immediately trigger an unnecessary emergency braking or significant deceleration to avoid it. While this behavior ensured absolute safety, it would seriously affect traffic efficiency on real roads and could even cause rear-end collisions.

[0041] It should be noted that this problem reveals a mismatch between different levels of modules: the understanding layer's capability boundaries have expanded (it can see farther and more ambiguous targets), but the task planning layer has not adjusted its decision threshold accordingly. Understandably, such system-level problems are difficult to detect in simple offline evaluations, but they become apparent in a dynamically interactive simulation environment.

[0042] Based on simulation playback, the process was redirected to "return to modify strategy." Algorithm engineers specifically adjusted the strategy logic of the task planning layer, adding a new decision rule: deceleration or avoidance planning is only triggered when the confidence level of the target (such as a pedestrian) output by the understanding layer is above a specific threshold (e.g., 0.6) for three consecutive frames, and its predicted trajectory poses a collision risk with the robot's own trajectory. This adjustment aims to filter out unstable, low-confidence detection results caused by distant, blurred targets.

[0043] The adjusted strategy was named The iteration process then restarted from offline evaluation S20. After further offline evaluation and simulation playback verification of S30, confirming that the "false trigger rate" had returned to normal and the original perception capability improvement had been retained, Only then were they allowed to enter the subsequent small-scale pilot S40 and full-scale S50 phases.

[0044] This embodiment fully demonstrates the value of combining a multi-layered evaluation system with a phased iterative process. This system not only quantifies the performance improvement of a single module, but more importantly, it can identify potential coordination problems that may arise after module integration. This allows for the early exposure and mitigation of potential risks before the strategy is deployed to a real-world environment, highlighting the crucial role of the proposed solution in the upgrading and maintenance of complex robotic systems.

[0045] Example 3

[0046] This embodiment aims to explain in detail how the automatic rollback function of the "full deployment and continuous monitoring" stage in this application plays a key role in ensuring the stability and safety of the entire traffic robot system.

[0047] The background of this embodiment follows that of embodiment 1. After strategy S2 was successfully deployed and ran stably for a period of time, the algorithm team developed a new strategy S3 to be evaluated. The goal of S3 is to further optimize the actions of the execution layer based on S2, aiming to make the robot's traffic guidance gestures smoother and more coherent, thereby shortening the "end-to-end latency of the execution layer" from making a decision to completing the physical gesture.

[0048] Strategy S3 also went through Figure 2 The iterative process is shown. In the offline evaluation S20 phase, analysis of the pre-recorded action sequences showed a reduction in average action time. No significant problems were found in the simulation playback S30 phase. Subsequently, in the low-volume pilot S40 phase, the pilot robot deploying the S3 strategy operated smoothly for several days, with all indicators normal. Based on these positive evaluation results, the closed-loop iterative control module 300 approved the full deployment of strategy S3.

[0049] The full monitoring and rollback controller 340 executed the full deployment S50 operation, deploying strategy S3 to all traffic robot bodies 100. After deployment, the system immediately entered the continuous monitoring S60 loop state. In this state, the full monitoring and rollback controller 340 continuously obtains real-time evaluation indicators of all online robots from the multi-layer strategy evaluation module 200 and compares them with preset safety baselines and performance thresholds.

[0050] Approximately two hours after the full rollout of Strategy S3, the anomaly detection mechanism in the continuous monitoring S60 was triggered. The full monitoring and rollback controller 340 received an emergency alert from the multi-layer strategy evaluation module 200. Detailed data showed: First, regarding the execution layer evaluation, the report from the execution layer evaluation unit 230 confirmed that the "execution layer end-to-end latency" metric had indeed achieved its optimization target, decreasing by an average of 0.1 seconds compared to Strategy S2. Second, however, another key safety metric reported by the execution layer evaluation unit 230—the "human intervention rate"—showed an extremely dangerous signal. This metric was almost zero during Strategy S2, but within just two hours of S3's rollout, the average human intervention rate across the entire network abnormally surged to 5%. This means that out of every 100 robot intervention actions, 5 were forced to be remotely intervened by a backend safety officer due to the system's assessment of potential risks or action execution failures. Thirdly, at the same time, the business layer assessment unit 240 also monitored a slight but statistically clear upward trend in the number of traffic conflicts at intersections (such as emergency braking between vehicles, dangerous lane changes, etc.).

[0051] Understandably, the operations team and algorithm engineers jointly set a series of strict security thresholds during the initial system design phase. The "human takeover rate," a core indicator for measuring system autonomy and security, has a security threshold set at 1%. Once the average value of this indicator exceeds 1% within any time window, it is considered a serious security incident.

[0052] In this situation, the full monitoring and rollback controller 340 detected a "human takeover rate" of 5%, far exceeding the preset threshold of 1%. This triggered... Figure 2 In the process, the branch where the "Indicator Abnormal?" is judged as "Yes" immediately and automatically executes the S70 rollback operation without any manual confirmation.

[0053] The specific process of the automatic rollback operation is as follows: The full monitoring and rollback controller 340 immediately broadcasts a highest-priority instruction to all online traffic robot bodies 100. This instruction requires the robot to immediately suspend the currently running policy S3 and load and switch from the local or cloud policy library to the stable version before S3 went live, i.e., policy S2. It should be noted that this switching process can be completed instantaneously, ensuring the continuity of online services while only rolling back the policy behavior to the previous verified safe state. According to a preferred embodiment of this application, the rollback operation rolls back the policy version to the policy version running online before this full deployment, ensuring the clarity and stability of the rollback target.

[0054] While performing the rollback operation, the full monitoring and rollback controller 340 also executed an alert operation. It sent high-priority alerts to the pre-defined operations team and the algorithm engineer responsible for the policy via multiple channels, including SMS, enterprise instant messaging tools, and email. The alert information not only explained the reason for triggering the rollback ("human takeover rate" exceeding the threshold), but also included a snapshot of key metrics one minute before the rollback was triggered, relevant log snippets, and video links to several typical scenarios that led to human takeover, providing first-hand information for subsequent problem review.

[0055] Subsequent post-mortem analysis revealed that strategy S3, in pursuit of smoothness and speed, oversimplified the confirmation and inspection processes before some actions were executed. This led to errors in the robot's gesture recognition in edge scenarios with rapidly changing lighting or obstruction by large vehicles (e.g., misinterpreting a straight-ahead gesture as a left turn), thus causing potential traffic hazards and forcing the safety personnel to take over manually.

[0056] This embodiment clearly demonstrates the extreme importance of continuous monitoring and automatic rollback mechanisms as the "last line of defense" after the strategy goes live. Based on objective data performance, it can decisively and promptly halt risks before strategy flaws cause serious consequences in the real world (such as traffic accidents), thereby maximizing the service stability and public safety of the entire traffic robot system.

[0057] Example 4

[0058] This embodiment will elaborate on how the proposed solution transforms the problems discovered during the evaluation process into a driving force for the self-evolution of the model and strategy, that is, how to achieve continuous learning and optimization of the system through a data-driven feedback loop. This process is closely related to the data and training closed-loop system architecture.

[0059] The background of this embodiment follows immediately after Embodiment 3. After policy S3 was automatically rolled back due to a spike in the "human takeover rate," the system returned to stability, but the entire event generated valuable data assets. This embodiment will describe how the system automatically captures, processes, and utilizes this data to train a better next-generation policy.

[0060] First, there is the automatic generation of data and samples. In Example 3, each "manual takeover" event is considered a "failure case" of strategy S3 by the system. For each such event, the system of this application automatically executes a program to generate a replayable record. Specifically, when the background security officer presses the "takeover" button, the system automatically packages and saves a complete data slice from 10 seconds before the takeover to 5 seconds after the takeover, centered on that moment. This data slice constitutes a replayable record, which can contain rich content, such as: raw data streams from all sensors of the traffic robot body 100 (such as high frame rate video recordings, LiDAR point cloud data, etc., which can be saved in their original format), structured data output by the understanding layer evaluation unit 210 during the time period (such as a list of all detected traffic participants and their positions, speeds, confidence levels, etc.), decision logs of the task planner evaluation unit 220 during the time period, status records of the execution layer evaluation unit 230 (such as joint angles of the robotic arm, motor current, etc.), a summary containing a comparison of state snapshots before and after strategy execution, and the final evaluation result given by the multi-layer strategy evaluation module 200 (in this example, "human intervention").

[0061] Following this is dataset augmentation and sample labeling. These newly generated, replayable records strongly correlated with the "human takeover" event are automatically categorized by the system. At this point, the model training interface module comes into play, automatically labeling these complete "scenario-decision-outcome" sequences as "negative samples" based on the evaluation result (i.e., the negative result of "human takeover"). As a preferred implementation, the model training interface module can label policy execution fragments with evaluation results not lower than a preset performance threshold as positive samples, and policy execution fragments with evaluation results lower than the preset performance threshold as negative samples. In this example, "human takeover" is clearly far below any reasonable performance threshold. These newly generated samples with clear negative labels are automatically injected into a dedicated "hard sample" dataset. In this architecture, this process can be viewed as the data recording node capturing raw data, processing and labeling it through the data engine, and finally merging it into the robot operation dataset. Thus, the robot operation dataset is dynamically augmented using data from real-world online failure cases.

[0062] Next comes targeted retraining of the model. After accumulating a certain number of negative samples from failed cases of strategy S3, the closed-loop iterative control module 300 can automatically or manually trigger a new model training task. This task is executed on the model training platform 400, corresponding to initiating a vision-language-action training process. This training differs from regular training in that, based on the existing large training dataset, it significantly increases the sampling weight of these newly added "difficult samples" (i.e., negative samples from S3) by adjusting the sampling strategy. Its training objective is that when the model encounters an input scenario similar to these negative samples again, its output decision should be significantly different from the decision that led to failure, and should be more inclined towards a safe, or rather, the correct operation performed by a human intervention at that time.

[0063] Finally, the generation and verification of a new strategy are crucial. After the model retraining task is completed, the model training platform 400 produces a new model, which is packaged and formed a completely new strategy S4 to be evaluated. Theoretically, strategy S4 has learned from the failure of S3 and will be more robust in the edge scenarios that previously caused the problem. However, to ensure safety and reliability, strategy S4 will not be directly deployed online. Instead, it will be sent as a completely new candidate strategy to the complete closed-loop iterative process described in this application, starting from embodiment 1. Starting with offline evaluation S20, it will sequentially go through simulation playback S30 and small-scale pilot S40. Only after performing excellently in all stages, proving that it not only fixes the problem of S3 but also does not introduce any new problems, will it be possible to finally be fully deployed online in S50.

[0064] In summary, this embodiment clearly demonstrates how the proposed solution constructs an automated closed loop from "online problem" to "training data," then to "model optimization" and "new strategy verification." This closed loop transforms every online failure into a learning opportunity, driving the continuous, automatic, and safe iteration and evolution of the robot's strategy, thereby truly achieving data-driven system self-improvement.

[0065] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An evaluation and closed-loop iteration system for traffic robot strategies, characterized in that, The method comprises the following steps: An evaluation module is used to evaluate a traffic robot strategy generated by a machine learning model based on a multi-layer strategy effect evaluation system, wherein the multi-layer strategy effect evaluation system comprises an understanding layer evaluation, a task planner evaluation, an execution layer evaluation, and a business layer evaluation; An iterative control module is used to update and deploy the strategy to be evaluated based on the evaluation result of the evaluation module through a closed-loop iterative process, wherein the closed-loop iterative process comprises an offline evaluation stage, a simulation playback stage, a small-flow pilot stage, and a full-volume online stage; A model training interface module is used to output the evaluation result of the evaluation module as a label for marking training samples to drive the retraining of the machine learning model.

2. The system of claim 1, wherein, The iterative control module is further used to continuously monitor evaluation indicators during the full-volume online stage, and automatically perform a rollback operation when any preset indicator trigger threshold is reached.

3. The system of claim 2, wherein, The automatic rollback operation is used to roll back the strategy version to the strategy version running online before the current full-volume online.

4. The system of claim 1, wherein, When the evaluation module performs the business layer evaluation, the evaluation indicators used include at least one of the following: queuing length reduction rate, vehicle average detention time, and conflict occurrence frequency.

5. The system of claim 1, wherein, When the evaluation module performs the task planner evaluation, the evaluation indicators used include at least one of the following: planning suggestion adoption rate and false trigger rate.

6. The system of claim 1, wherein, The iterative control module performs simulation of the strategy to be evaluated in at least one simulation environment selected from SUMO, VISSIM, and CARLA during the simulation playback stage.

7. The system of claim 1, wherein, The model training interface module is used to mark a strategy execution segment with an evaluation result not lower than a preset performance threshold as a positive sample, and mark a strategy execution segment with an evaluation result lower than the preset performance threshold as a negative sample.

8. A method of evaluation and closed loop iteration of a traffic robot strategy, using a system for evaluation and closed loop iteration of a traffic robot strategy according to any one of claims 1-7, characterized in that, The method comprises the following steps: An evaluation module is used to evaluate a traffic robot strategy generated by a machine learning model based on a multi-layer strategy effect evaluation system, wherein the multi-layer strategy effect evaluation system comprises an understanding layer evaluation, a task planner evaluation, an execution layer evaluation, and a business layer evaluation; An iterative control module is used to update and deploy the strategy to be evaluated based on the evaluation result of the evaluation module through a closed-loop iterative process, wherein the closed-loop iterative process comprises an offline evaluation stage, a simulation playback stage, a small-flow pilot stage, and a full-volume online stage; A model training interface module is used to output the evaluation result of the evaluation module as a label for marking training samples to drive the retraining of the machine learning model.

9. The method of claim 8, wherein, The full-volume online stage comprises continuously monitoring evaluation indicators, and automatically performing a rollback operation when any preset indicator trigger threshold is reached, to roll back the strategy version to the strategy version running online before the current full-volume online.

10. The method of claim 8, wherein, Further comprising: An automatically generated replayable record is generated, wherein the replayable record comprises a comparison of state snapshots before and after strategy execution, and the evaluation result.

Images