Logistics in-transit risk control method and system based on AI large model

Abstract

The application provides a logistics in-transit risk control method and system based on an AI large model, and relates to the technical field of in-transit early warning. The method comprises the following steps: first, receiving a vehicle-mounted Internet of Things sensing end original alarm message and analyzing the original alarm message into structured alarm data containing an alarm level; then, sending the structured alarm data into a multi-layer analysis of an intention recognition module to analyze out dangerous alarm data containing a dangerous level category and an alarm event subcategory. According to the alarm event subcategory, it is determined whether there is a business attribute requirement, and if there is, data collision is performed with a bulk logistics business system database to retrieve associated business context information. In combination with the dangerous alarm data and the business context, a special prompt word suitable for an alarm scene is matched and generated, the special prompt word and the structured alarm data are input into an instruction generation AI large model to generate a decision instruction, and the decision instruction is sent to a logistics dispatch terminal to complete early warning disposal. The method improves the accuracy and automation level of risk control early warning.

Description

Technical Field

[0001] This application relates to the field of in-transit early warning technology, and in particular to a logistics in-transit risk control method and system based on an AI large model. Background Technology

[0002] With the large-scale and networked development of bulk logistics trunk transportation, the demand for vehicle operation safety and cargo management continues to increase. The industry generally adopts vehicle-mounted IoT sensing devices to realize vehicle positioning, driving behavior monitoring, and detection of abnormalities in the cargo compartment and cargo. By aggregating multi-source alarm data through IoT platforms, it provides basic support for transportation process supervision, risk intervention, and operation scheduling. Intelligent and automated early warning has become a key development direction for efficient management and control of bulk logistics.

[0003] Current on-road monitoring systems primarily rely on threshold-triggered alarms. They collect raw data from onboard devices and upload it to a platform. Upon receiving alarm messages from the onboard sensors, the system categorizes them according to preset alarm level thresholds and then forwards the categorization results to the dispatch terminal as a notification. Human staff can then judge the effectiveness of the alarms based on experience and determine the appropriate action to issue warnings to on-road trucks.

[0004] However, the risk level and required handling measures for the same type of alarm event vary significantly across different business scenarios. Related technologies lack targeted decision-making instructions tailored to different specific business scenarios, making accurate alarm reporting difficult. For example, the same route deviation alarm occurring during empty dispatching and during the heavy transport of hazardous chemicals correspond to completely different risk levels and response strategies. The warning information received by the dispatch terminal only includes the alarm level notification; dispatchers still need to make their own judgments and formulate response plans, affecting the response efficiency and accuracy of in-transit risk control. This can lead to high false alarm rates, heavy workload for manual analysis, and delayed responses. Summary of the Invention

[0005] This application provides a logistics in-transit risk control method and system based on an AI large model, which is used to automate and contextualize risk control processing and improve the accuracy of in-transit early warning.

[0006] Firstly, this application provides a logistics in-transit risk control method based on an AI big data model. The method includes: receiving raw alarm messages from an in-vehicle IoT sensing terminal and parsing the raw alarm messages into structured alarm data containing alarm levels; inputting the structured alarm data into an intent recognition module for multi-level parsing to obtain dangerous alarm data for the current alarm event, the dangerous alarm data including the alarm level category and the alarm event sub-category of the specific alarm event; determining whether the current alarm event has business attribute requirements based on the alarm event sub-category; if so, performing data collision with the bulk logistics business system database to obtain business context information related to the current alarm event; matching and generating a dedicated prompt word for the current alarm event scenario based on the dangerous alarm data and the business context information; inputting the dedicated prompt word and the structured alarm data into a preset instruction to generate an AI big data model, obtaining a decision instruction, and sending it to a logistics dispatch terminal for early warning.

[0007] By adopting the above technical solution, the raw data is first structured and parsed to provide a standardized foundation for subsequent processing. Then, the intent recognition module is used to decompose alarm information into multiple levels and accurately extract core risk information. For alarms that need to be combined with business scenarios, the contextualized information is obtained through data collision, and the risk information is deeply integrated with the business scenario to generate dedicated prompt words, providing accurate input for the AI ​​big data model. Each technical link is interconnected and mutually supportive, realizing the upgrade of alarm handling from single-level notification to scenario-based decision-making instructions, significantly improving the accuracy and automation level of risk control early warning, effectively reducing false alarm rate and manual intervention costs, and solving the technical shortcomings of traditional risk control early warning, such as insufficient targeting and low response efficiency.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of determining whether the current alarm event has business attribute requirements based on the alarm event sub-category specifically includes: using the alarm event sub-category as an input node, traversing and searching along the adjacent edges of the input node in a preset bulk logistics knowledge graph to extract a set of entity nodes associated with the input node; traversing the tag attributes of the entity node set to determine whether the entity node set contains a preset business status type entity node, which includes empty / overloaded status, bulk cargo attributes, and waybill fulfillment stage; if not contained, then determining that the current alarm event has no business attribute requirements; if contained, then determining the shortest path level from the input node to the business status type entity node; if the shortest path level is less than a preset number of hops, then determining that the current alarm event has business attribute requirements.

[0009] By adopting the above technical solution and leveraging the associative characteristics of knowledge graphs, node traversal is performed starting from alarm subcategories to quickly filter related entities, completing the initial judgment of business attributes without manual intervention. Through entity tag verification and shortest path hierarchy determination, alarms that need association with relevant business scenarios are accurately distinguished from those that do not, avoiding invalid data interaction. This automated judgment method not only improves the efficiency of business attribute identification but also ensures the accuracy of the identification results, reduces unnecessary system resource consumption, and ensures the relevance of subsequent business data collision analysis, making alarm handling more aligned with actual scenario needs and improving the overall operational efficiency of the early warning system.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, if applicable, the step of performing data collision between the structured alarm data and the bulk logistics business system database to obtain business context information related to the current alarm event specifically includes: parsing the current operating entity in the structured alarm data; performing a search query in the bulk logistics business system database to obtain relevant theoretical business data, and determining the business stage of the current operating entity and the main business area corresponding to the business stage based on the theoretical business data; determining the subdivided verification rules bound to the business stage, the subdivided verification rules including the target subdivided operating area allowed for the current alarm event to occur, the allowed normal operation duration threshold, and the restricted objects for illegal assistance; obtaining event situation data when the current alarm event occurs, the event situation data including event location coordinates, behavior duration, and surrounding environment image data; performing a status verification on the event situation data according to the subdivided verification rules to obtain a quantified verification result; and confirming the business context information based on the verification result.

[0011] By adopting the above technical solution, after accurately locating the current operational entity, its business stage and core area are clarified by combining business system data. Then, business requirements are transformed into quantifiable verification standards through detailed verification rules, and status verification is completed by combining real-time alarm data. The verification process considers both theoretical business data and real-time event data, achieving quantitative extraction of business context information and avoiding ambiguity or one-sidedness in contextual information. This multi-dimensional verification and data fusion approach ensures the accuracy and completeness of business context information, making subsequent generated prompts and decision instructions more scenario-adaptable and significantly improving the reliability and scientific nature of early warning decisions.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the step of performing state verification on the event situation data according to the subdivision verification rule to obtain a quantified verification result specifically includes: if the event location coordinates exceed the target subdivision operation area, or the duration of the behavior exceeds the normal operation duration threshold, then the main business area is used as the search scope to obtain the current associated operation parameters of the surrounding associated operation entities that are in the same business stage as the current operation entity; based on the current associated operation parameters, environmental fluctuation feature parameters are extracted to characterize the operating status of the equipment within the search scope; using the environmental fluctuation feature parameters, dynamic compensation is applied to the target subdivision operation area and the normal operation duration threshold to generate a dynamic spatiotemporal tolerance domain; the overflow boundary difference between the event location coordinates and the behavior duration and the dynamic spatiotemporal tolerance domain is calculated, and the spatiotemporal dimension verification result is determined based on the overflow boundary difference.

[0013] By adopting the above technical solution, when alarm data exceeds the initial verification range, it does not directly determine an anomaly. Instead, it extracts environmental fluctuation characteristics by combining the operating parameters of surrounding related entities, dynamically compensates the verification rules, and generates a dynamic tolerance domain that fits the actual scenario. The spatiotemporal verification result is determined by calculating the overflow difference, achieving dynamic adaptation of the verification standard and avoiding misjudgments caused by fixed thresholds. The various technical features work together to balance the rigid requirements of business rules with the dynamic changes in in-transit scenarios, improving the flexibility and accuracy of status verification, making the verification results more consistent with actual operating scenarios, and enhancing the rationality of early warnings.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after calculating the difference between the event location coordinates and the duration of the behavior relative to the overflow boundary of the dynamic spatiotemporal tolerance domain, the method includes: detecting external entities appearing in the image based on the surrounding environment image data; determining the relative dynamic relationship between the external entity and the cargo access interface of the current operating entity; matching the relative dynamic relationship with a predefined risk interaction pattern library to obtain a target risk interaction pattern, the risk interaction pattern library storing multiple interaction behavior patterns representing unauthorized material transfer intentions; querying the bulk logistics business system database to see if the external entity has collaborative operation permissions with the current operating entity; if not, marking the external entity as an object of illegal assistance; continuously tracking the relative dynamic relationship, calculating the assistance intervention confidence level based on the approximation distance in the relative dynamic relationship and the target risk interaction pattern; and weighting and fusing the spatiotemporal dimension verification result with the assistance intervention confidence level according to a preset weight to obtain the final quantitative verification result.

[0015] By adopting the above technical solution, based on spatiotemporal verification, external entities are detected using image data, their interaction with operational entities is analyzed, risk patterns are matched, operational permissions are verified, violations are marked, and intervention confidence levels are calculated. The spatiotemporal verification results are weighted and fused with the interaction risk confidence levels to achieve multi-dimensional risk verification, overcoming the limitations of single spatiotemporal verification. This dual verification mode can comprehensively capture the potential risks of alarm events, improve the comprehensiveness and accuracy of verification results, make risk assessment more objective, provide more comprehensive technical support for alarm handling, and enhance the risk identification capability of the early warning system.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the step of parsing the current operation entity in the structured alarm data specifically includes: extracting the entity identifier field of the current alarm event; defining a spatial retrieval window centered on the event location coordinates in the bulk logistics business system database, and obtaining all candidate operation entities in transit and their corresponding planned trajectory data within the spatial retrieval window; if the entity identifier field does not match the candidate entity identifier of each candidate operation entity, calculating the offset between the event location coordinates and the planned trajectory points of each candidate operation entity at the time of the event occurrence; performing business compatibility determination based on the event characteristics corresponding to the alarm event sub-category and the current business stage and cargo attributes corresponding to each candidate operation entity to obtain the remaining candidate operation entities; and selecting the candidate operation entity with the smallest offset as the current operation entity among the remaining candidate operation entities.

[0017] By adopting the above technical solution, when entity identifiers do not match, candidate entities are identified through spatial retrieval. Combined with trajectory offset calculation and business compatibility determination, the optimal matching entity for the current operation is selected through a multi-layered filtering process. Spatial retrieval ensures the accuracy of the candidate range, offset calculation provides a quantitative reference, and business compatibility determination excludes irrelevant entities. The three work synergistically to effectively solve the positioning problem when entity identifiers do not match. This precise positioning method ensures the accuracy of objects in all subsequent business-related operations, avoids warning deviations caused by incorrect entity positioning, and guarantees the technical reliability and operational stability of the entire warning method.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the step of matching and generating a specific prompt word for the current alarm event scenario based on the danger alarm data and the business context information specifically includes: using the alarm event sub-category and the business stage in the business context information as joint search conditions, querying the scenario risk semantics corresponding to the current alarm event in the current business stage in a preset risk semantic mapping table, wherein the risk semantic mapping table has pre-established differentiated risk interpretations for the same alarm event sub-category in different business stages; determining the core risk orientation of the current alarm event based on the scenario risk semantics, wherein the core risk orientation is used to characterize the specific business element threatened by the current alarm event in the current business stage; extracting the descriptive fragment and the handling guidance fragment corresponding to the specific business element from a preset prompt word element library based on the core risk orientation; assembling the descriptive fragment, the handling guidance fragment, and the danger level category according to a preset word order arrangement rule to generate the specific prompt word.

[0019] By employing the above technical solution, scenario risk semantics are obtained through dual-condition joint retrieval, accurately locating the core risk of the alarm, and then extracting corresponding prompt word fragments, which are then assembled based on the risk level. Joint retrieval ensures the scenario adaptability of risk semantics, the core risk clearly indicates the core direction of the prompt words, and fragment assembly ensures the standardization and relevance of the prompt words. The collaborative efforts of all technical aspects result in dedicated prompt words that accurately convey alarm risks and scenario requirements, providing high-quality input for the AI ​​large-scale model, avoiding instruction deviations caused by generic prompt words, significantly improving the accuracy and executability of decision-making instructions, and optimizing the technical effectiveness of early warning and response.

[0020] In a second aspect, this application provides an in-transit risk control system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the in-transit risk control system to perform the methods described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on an in-transit risk control system, cause the in-transit risk control system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product, including a computer program that, when run on an in-transit risk control system, causes the in-transit risk control system to perform the methods described in the first aspect and any possible implementation thereof. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a scenario framework for the logistics in-transit risk control method based on an AI large model in the embodiments of this application;

[0024] Figure 2 This is a flowchart illustrating the logistics in-transit risk control method based on an AI large model in this application embodiment;

[0025] Figure 3 This is another flowchart illustrating the logistics in-transit risk control method based on an AI large model in the embodiments of this application;

[0026] Figure 4 This is a schematic diagram of the physical device structure of the in-transit risk control system in the embodiments of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0029] To facilitate understanding, the method provided in this implementation is described in a scenario below. Please refer to [link / reference]. Figure 1 This is a schematic diagram of a scenario framework for the logistics in-transit risk control method based on an AI large model in this application embodiment.

[0030] like Figure 1 The scenario framework shown consists of three main parts: the vehicle-mounted IoT sensing terminal, the on-the-road risk control system, and the logistics scheduling terminal. It clearly demonstrates the entire process link from alarm perception to intelligent decision-making and instruction issuance.

[0031] The vehicle-mounted IoT sensing terminal is deployed on bulk logistics transport vehicles, integrating GPS positioning, onboard cameras, sensors, and other equipment to collect real-time data on vehicle status, driving behavior, and cargo environment. When an abnormal event is detected (such as fatigue driving, cargo compartment movement, or unplanned parking), the sensing terminal generates and uploads an original alarm message, providing the system with first-hand sensing data. The in-transit risk control system is the core processing unit of the entire solution, internally composed of multiple functional modules working collaboratively:

[0032] The message parsing unit receives and parses the raw alarm messages from the vehicle terminal, converting them into standardized structured alarm data. This data includes key information such as alarm levels, providing a unified data foundation for subsequent processing. The intent recognition module receives the structured alarm data and generates hazard alarm data through multi-level parsing, clearly defining the hazard level category and specific alarm event sub-category. Simultaneously, this module performs data collision with the bulk logistics business system database to obtain business context information such as waybill status, cargo attributes, and operational stage, giving the alarms business meaning. The dedicated prompt word generation module combines the hazard alarm data with the business context information to generate dedicated prompt words for the current scenario, guiding the subsequent decision-making direction of the AI ​​big data model. The instruction generation AI big data model receives the structured alarm data and dedicated prompt words, relying on pre-trained logistics domain knowledge and emergency response logic to infer and generate executable early warning decision instructions.

[0033] The logistics dispatch terminal serves as the interface for dispatchers to receive early warning information. Early warning decision instructions generated by the in-transit risk control system are sent to this terminal via a communication link. The terminal then displays the alarm details and handling suggestions in a visual manner. For example, the example in the image shows the terminal pushing an instruction: "Emergency Warning—**Vehicle fatigued driving, transporting hazardous chemicals, please immediately guide to a service area for rest." This can guide and assist dispatchers in taking action, achieving a closed-loop early warning system.

[0034] The entire process, through the linkage of vehicle-mounted sensing, business association, AI-assisted decision-making, and terminal-based distribution, achieves intelligent and scenario-based early warning of risks in bulk logistics in transit, solving the problems of alarms being detached from business context and low efficiency of manual handling in the traditional model.

[0035] The following describes the process of the method provided in this implementation, using the above scenario as an example. Please refer to [link / reference]. Figure 2 This is a flowchart illustrating a logistics in-transit risk control method based on an AI large model in this application embodiment.

[0036] S101. Receive the original alarm message from the vehicle IoT sensing terminal and parse the original alarm message into structured alarm data containing alarm levels;

[0037] Among them, the vehicle-mounted IoT sensing terminal refers to various sensing hardware and edge acquisition units deployed on bulk logistics transportation vehicles. It refers to terminal devices used to collect vehicle status, driving behavior, cargo status, location information, environmental images and trigger abnormal reporting. Examples include, but are not limited to, Beidou positioning terminals, fuel tank sensors, and vehicle-mounted cameras set in preset locations. The original alarm message refers to the original alarm data directly uploaded by the vehicle-mounted IoT sensing terminal that is unformatted, non-standardized, and transmitted using private protocols or binary formats. It refers to the underlying alarm messages that have not undergone field splitting, semantic translation and normalization processing, including but not limited to abnormal frames actively reported by the device. The structured alarm data refers to standardized alarm data organized according to unified fields, fixed formats and standardized semantics.

[0038] This step is executed when the vehicle-mounted IoT sensing terminal detects any risk event such as abnormal vehicle operation, illegal driving behavior, abnormal cargo status, exceeding area limits, or abnormal fuel levels and proactively reports an alarm. The on-the-go risk control system continuously monitors and receives raw alarm messages from various sensing terminals in real time through the IoT platform. After receiving the messages, the system first performs integrity verification, deduplication verification, format verification, and protocol decoding on the raw messages, eliminating incomplete, duplicate, and illegal messages. Then, according to preset parsing rules, it extracts fields, performs semantic conversion, type mapping, and data normalization on the legitimate raw messages, identifies and labels the alarm level, and finally generates structured alarm data with a unified structure, complete fields, and clear semantics for use by subsequent modules.

[0039] S102. Input the structured alarm data into the intent recognition module for multi-level parsing to obtain the danger alarm data of the current alarm event. The danger alarm data includes the danger level category of the alarm and the alarm event sub-category of the specific alarm event.

[0040] The intent recognition module refers to the functional module used in the on-the-go risk control system to perform semantic understanding, risk classification, and event segmentation of alarm data; the alarm event sub-category refers to the specific event type that is finely divided into alarm events. It refers to the sub-type that can uniquely identify abnormal behavior under the same major category. Examples include driver fatigue, making or receiving phone calls, driving with one hand, abnormal parking, sudden fuel depletion, cargo movement, and personnel approaching the cargo hold.

[0041] This step is executed immediately after S101 generates and verifies the structured alarm data. The in-transit risk control system inputs the complete structured alarm data into the intent recognition module. This intent recognition module is equipped with an intent recognition model, which is pre-built and trained based on the hierarchical business logic of the bulk logistics in-transit alarm scenario, historical alarm data, and manual annotation results. It is specifically used to perform progressive multi-level parsing of structured alarm data from major categories to subcategories, so as to achieve automatic determination of risk level and event subcategory. The construction and training process specifically includes: First, a hierarchical labeling system is built based on business rules. The top layer is the alarm category (such as driving behavior or vehicle status), the middle layer is the hazard level category, and the bottom layer is the alarm event sub-category. Then, historical alarm data is collected, and business personnel manually label the data according to the labeling system to build training samples of structured alarm data-hierarchical labels. Next, a hierarchical multi-classification model (or cascaded classification model) is used as the base, and the alarm time, location, sensor values, concurrent alarms, and other features are used as inputs to train three-layer classifiers in sequence: the first-layer classifier identifies the alarm category, the second-layer classifier determines the hazard level based on the category, and the third-layer classifier outputs subcategories based on the category and level. Business rule constraints are introduced during the training process, such as cargo anomalies can only belong to the cargo safety category, to ensure that the classification results conform to business logic. After training, the hierarchical classification accuracy is verified through a test set, the model parameters are optimized, and finally, an intent recognition model adapted to multi-level parsing processes is formed.

[0042] The intent recognition module parses alarms sequentially according to a multi-level logic: the first level performs semantic recognition and categorization of alarms, distinguishing between driving behavior, vehicle status, cargo safety, and regional compliance alarms; the second level determines the hazard level category based on alarm content, impact range, and preset rules; the third level matches alarms to the finest-grained alarm event subcategories; after parsing, the system encapsulates the hazard level category and alarm event subcategories into hazard alarm data and outputs it to the next processing stage. This step solves the problem that structured alarm data only contains basic information and lacks risk semantics and fine-grained classification, achieving deep extraction from raw alarms to hazard level + event subcategories, providing accurate basis for subsequent business attribute judgment.

[0043] S103. Based on the sub-category of the alarm event, determine whether the current alarm event has business attribute requirements;

[0044] Among them, the business attribute requirement means that the alarm event is related to business elements such as bulk logistics waybills, goods, operation stages, and fulfillment processes. It requires the combination of business data to accurately judge the risks and handling methods. It refers to the judgment condition that the alarm must be associated with the business system to complete the effective analysis.

[0045] The specific steps include: using the alarm event subcategory as the input node, traversing and searching along the adjacent edges of the input node in the preset bulk logistics knowledge graph to extract the set of entity nodes associated with the input node; traversing the tag attributes of the entity node set to determine whether the entity node set contains preset business status entity nodes, which include empty / overloaded status, bulk cargo attributes, and waybill fulfillment stage; if not contained, it is determined that the current alarm event has no business attribute requirement; if contained, the shortest path level from the input node to the business status entity node is determined; if the shortest path level is less than the preset number of hops, it is determined that the current alarm event has a business attribute requirement.

[0046] The bulk logistics knowledge graph refers to a pre-constructed knowledge base organized in a graph structure for the bulk logistics domain. This knowledge graph expresses the semantic relationships between alarm event types, business elements, risk factors, and handling measures in the form of entity nodes and relational edges. An input node is the starting node for traversing and searching the knowledge graph based on the entity node corresponding to the current alarm event subcategory. Entity nodes are the basic units in the bulk logistics knowledge graph used to represent an independent business object or event type; they are the "points" that carry specific business meanings. Adjacent edges are relational edges in the knowledge graph that directly connect to input nodes. These relational edges express the semantic relationship types between the alarm event subcategory represented by the input node and other entities, such as "may lead to," "impact," and "requires verification." Business status entity nodes refer to a type of entity node in the knowledge graph specifically used to represent the operational status information of logistics business. These include empty / loaded status nodes (indicating whether the vehicle is currently empty or loaded), bulk cargo attribute nodes (indicating the specific type of bulk cargo being transported, such as coal, steel, or ore), and waybill fulfillment stage nodes (indicating which business stage the waybill is currently in, such as loading, in-transit, or unloading). The shortest path level refers to the minimum number of edges traversed from an input node to a business status entity node, i.e., the shortest distance hops between two nodes. The preset hop count is a threshold set by the system to determine the degree of correlation. When the shortest path level is less than this preset hop count, a close and direct correlation is considered between the alarm event and the business status.

[0047] Specifically, after obtaining the sub-category of the current alarm event, the in-transit risk control system initiates a business attribute requirement determination process. The system first locates the entity node corresponding to the sub-category in the pre-defined bulk logistics knowledge graph, using it as the input node. For example, when the sub-category of the alarm event is "cargo movement," the system locates the entity node identified as "cargo movement" in the knowledge graph as the input node. Then, starting from this input node, the system reads all adjacent edges directly connected to it. These adjacent edges may include different types of relationship edges, such as those that may lead to cargo loss, affect waybill fulfillment, or require verification of load status. The system expands outward along these adjacent edges, visiting the target entity node pointed to by each adjacent edge and adding these target entity nodes to the entity node set. During the traversal, the system uses a breadth-first search strategy, expanding outward layer by layer until a preset maximum search depth (e.g., 5 hops) is reached or all reachable nodes have been traversed. After the traversal is complete, the system obtains a set containing all entity nodes that are related to the input node. Next, the system iterates through each node in the entity node set, reads the tag attribute field of each node, and determines whether the node belongs to the business status type entity node.

[0048] The specific determination method is as follows: Check whether the node's label attribute is any of the following: empty / overloaded state, bulk cargo attribute, or waybill fulfillment stage. If, after traversing the entire entity node set, no node's label attribute is found to belong to any of the above three business status categories, it indicates that there is no semantic relationship between the current alarm event subcategory and the business status information. The system determines that the current alarm event has no business attribute requirement, and subsequent processing does not require querying the business system database. If at least one node's label attribute is found to belong to a business status category in the entity node set, it indicates that there is a semantic relationship between the current alarm event subcategory and the business status information, but the tightness of this relationship still needs to be further determined. The system calculates the shortest path from the input node to each business status category entity node, obtaining the shortest path level value. For example, if the shortest path between the "cargo movement" node and the "empty / overloaded state" node is "cargo movement → (affecting) cargo safety → (depending on) empty / overloaded state", then the shortest path level is 2 hops.

[0049] The system compares the calculated shortest path level with a preset number of hops (e.g., 3 hops). If the shortest path level is less than the preset number of hops, it indicates a close direct relationship between the alarm event and the business status. The system determines that the current alarm event has business attribute requirements, and subsequent processing requires querying the business system database to obtain relevant business context information. If the shortest path level is greater than or equal to the preset number of hops, it indicates a loose or indirect relationship between the alarm event and the business status. The system determines that the current alarm event has no business attribute requirements. For example, for the alarm event subcategory "driver fatigue," the shortest path level between it and the "waybill fulfillment stage" node in the knowledge graph may be 5 hops, exceeding the preset number of 3 hops, therefore it is determined that it has no business attribute requirements. However, for the alarm event subcategory "cargo movement," the shortest path level between it and the "empty / heavy load status" node is 1 hop (direct relationship), less than the preset number of hops, therefore it is determined that it has business attribute requirements.

[0050] This step, through semantic association analysis and path distance calculation based on knowledge graphs, enables the automated and accurate determination of business attribute requirements for different types of alarm events. It avoids unnecessary system overhead and processing delays caused by querying business data for all alarm events, while ensuring that alarm events that truly require business context assistance can obtain sufficient business information support, significantly improving the system's processing efficiency and the accuracy of risk assessment.

[0051] S104. If so, the structured alarm data is compared with the bulk logistics business system database to obtain business context information related to the current alarm event.

[0052] Among them, the bulk logistics business system database refers to a database system that stores business data for the entire bulk logistics transportation process. It records complete business operation data such as waybill information, vehicle scheduling plans, cargo loading and unloading operation records, transportation route planning, customer contract agreements, electronic fence definitions for work areas, and collaborative operation authorization relationships. Data collision refers to the process of using key fields (such as vehicle identification, event time, event location, etc.) in structured alarm data as query conditions and performing association matching and cross-comparison with business records in the bulk logistics business system database. Business context information refers to a comprehensive set of information that is directly related to the current alarm event and can provide business background support for event risk assessment.

[0053] Once the in-transit risk control system determines in step S103 that the current alarm event has business attribute requirements, the system initiates a data collision process to perform a deep correlation query between the structured alarm data and the bulk logistics business system database. Specific implementation details will be described in subsequent steps S201-S206 and will not be repeated here.

[0054] S105. Based on the danger alarm data and the business context information, match and generate a special prompt word for the current alarm event scenario;

[0055] Among them, the special prompt words refer to the structured text instructions that are customized and generated according to the specific scenario characteristics of the current alarm event and used to guide the instruction generation AI model to generate accurate decision instructions. The prompt words integrate key information elements such as the risk nature description of the event, business scenario constraints, and expected handling direction, so that the instruction generation AI model can generate targeted decision outputs based on a full understanding of the event background.

[0056] Specifically, after obtaining hazard alarm data and business context information, the in-transit risk control system needs to transform these analysis results into specialized prompts that can effectively guide the AI ​​model for decision-making and reasoning. The system first extracts the alarm event sub-category field from the current alarm event and the business stage field from the business context information, combining the two to form a joint search condition. This joint search condition uses a composite key structure of "alarm event sub-category + business stage" to ensure accurate positioning within the risk semantic mapping table. The system then calls the risk semantic mapping table query interface, using this joint search condition as the query parameter. The risk semantic mapping table is organized in a two-dimensional table structure, with rows corresponding to alarm event sub-categories and columns corresponding to business stages. Each cell in the table stores the scenario risk semantic text for the corresponding combination. This mapping table is pre-built by business experts during the system initialization phase based on historical transportation risk cases and business rules, covering the risk interpretations of all known alarm event sub-categories under each business stage. The system locates the corresponding cell in the mapping table using the joint search condition and extracts the stored scenario risk semantic text. The scenario-based risk semantic text describes the true risk meaning of the current alarm event in the current business stage in natural language, reflecting the decisive influence of the business scenario on risk interpretation. For example, the scenario-based risk semantic for an abnormal parking alarm in the loading stage is that loading operation timeouts lead to the occupation of transportation resources and delays in subsequent transportation plans, while in the in-transit transportation stage, the scenario-based risk semantic for the corresponding scenario is the risk of unplanned parking leading to theft, damage, or replacement of goods. Through this differentiated mapping mechanism, the system can accurately identify the true risk meaning of the same alarm event in different business scenarios, avoiding the generalized interpretation of alarm events that is detached from the business context.

[0057] After acquiring the semantic meaning of the scenario risk, the system performs semantic parsing on the semantic text to extract the core business elements it points to and determine the core risk indicators. This parsing process is implemented using natural language processing technology. The system identifies key business element words from the scenario risk semantic text and maps them to a preset business element classification system. This business element classification system covers multiple dimensions such as cargo safety, transportation timeliness, delivery integrity, compliance, and cost control, with each dimension containing several specific business element identifiers. The system determines the specific business element identifiers pointed to by the scenario risk semantics through keyword matching and semantic similarity calculation, and records them as core risk indicators. For example, from "the risk of cargo theft, damage, or replacement due to unplanned parking," the core risk indicator is extracted as "cargo safety," and from "the risk of loading operations exceeding the time limit leading to the occupation of transportation resources and delays in subsequent transportation plans," the core risk indicator is extracted as "transportation timeliness." The determination of core risk indicators enables the system to clearly identify the specific business objectives threatened by the current alarm event, providing an index basis for the accurate extraction of subsequent prompt word elements.

[0058] Once the core risk is identified, the system uses this risk as an index key to search a pre-defined prompt word element library. The prompt word element library is organized using a key-value pair structure, with the business element identifier as the key and the corresponding descriptive fragment and action guidance fragment as the value. This element library is pre-built by business experts during the system initialization phase based on the risk characteristics and handling experience of various business elements, ensuring that each business element has a corresponding standardized text fragment. The system extracts the descriptive fragment and action guidance fragment corresponding to the core risk from the prompt word element library through index key matching. The descriptive fragment describes the status characteristics, scope of impact, and potential consequences of the business element in the current risk context, using a structured description template to ensure completeness and consistency of expression. The action guidance fragment indicates the direction of investigation, type of handling measures, and priority order to be taken for the risk, providing clear action guidance for subsequent decision-making. For example, regarding the core risk of "cargo safety", the description fragment extracted by the system is "There is a current threat to cargo safety. The vehicle is parked at an unplanned location, and the cargo may be at risk of being stolen, damaged, or replaced." The action guidance fragment is "It is recommended to immediately verify the reason for the parking, contact the driver to confirm the status of the cargo, and, if necessary, initiate the cargo inventory process or dispatch on-site verification personnel."

[0059] After acquiring the description and action guidance fragments, the system initiates the prompt assembly process. This process sequentially combines the three elements—hazard level category, description fragment, and action guidance fragment—according to preset word order rules. The word order rules specify the arrangement, connection method, and format markers of each element in the final prompt, ensuring that the generated prompt is structurally clear and semantically coherent. Specifically, the system first uses the hazard level category as the starting part of the prompt, marked with a prominent symbol, such as "high-risk alarm" or "medium-risk alarm," to highlight the urgency of the risk. Then, the system concatenates the description fragment, which follows the hazard level statement, clarifying the business implications and scope of impact of the current risk. Finally, the system appends the action guidance fragment, located at the end of the prompt, providing clear action guidance for subsequent decision-making. The fragments are connected using preset connectors and punctuation marks; for example, no connector is added between the hazard level statement and the description fragment, and a period is inserted between the description fragment and the action guidance fragment. The system completes the assembly of each element according to these rules, generating a structurally complete and dedicated prompt. Once assembled, the system outputs a dedicated prompt, which includes a risk level statement for the current alarm event, a risk description for the business scenario, and targeted handling suggestions, forming a complete risk instruction framework.

[0060] This step transforms complex, multi-dimensional analysis results into clearly structured and semantically precise special prompt words, ensuring that the subsequent instruction generation AI model can accurately understand the complete background and handling requirements of the current event. This avoids the problem that the instruction generation AI model's output might deviate from the actual scenario requirements, which could be caused by using generalized prompt words, thus guaranteeing the accuracy and executability of the final generated decision instructions.

[0061] S106. Input the special prompt word and the structured alarm data into the preset instruction to generate an AI big model, obtain the decision instruction, and send it to the logistics scheduling terminal for early warning.

[0062] After generating the dedicated prompt words, the in-transit risk control system uses these prompt words along with the original structured alarm data as input to a pre-set instruction generation AI model for inference processing. The instruction generation AI model can be pre-built using the following methods: First, a basic pre-trained language model with text understanding, logical reasoning, and instruction generation capabilities is selected as the base. Data from areas such as waybill fulfillment rules, vehicle safety management requirements, cargo protection specifications, terminal operation systems, anomaly handling plans, and historical alarm handling records in the bulk logistics field are collected to construct a domain-specific fine-tuning dataset. Then, the base model is trained using instruction fine-tuning to learn risk understanding, handling logic, and scheduling instruction generation paradigms in logistics scenarios. Finally, structured output constraints, safety compliance verification rules, and effective constraint constraints for execution measures are configured for the model.

[0063] The system places specialized prompts at the guiding position of the input sequence to set the direction, constraints, and output format requirements for the instruction generation AI model. Structured alarm data is placed at the data position of the input sequence to provide the AI ​​model with specific parameter details of the event (such as precise time, location, and sensor values). Upon receiving the input, the instruction generation AI model, based on its general language understanding and reasoning capabilities learned during the pre-training phase, and the bulk logistics business knowledge and emergency response experience injected during the domain fine-tuning phase, deeply understands the risk scenario described in the specialized prompts. Combining this with the specific parameters in the structured alarm data, it infers and generates decision instructions for the current alarm event. These decision instructions include, but are not limited to, the following elements: emergency measures requiring immediate execution (such as remotely locking the vehicle or activating the vehicle alarm), confirmation actions requiring human intervention (such as contacting the driver for voice confirmation or retrieving real-time video footage), external resources requiring coordination (such as notifying the nearest patrol vehicle to the scene), the execution priority of each measure, the suggested execution time limit for each measure, and requirements for subsequent tracking and monitoring. After receiving the decision instruction generated by the AI ​​big model, the system formats and verifies its compliance. Once it confirms that the instruction does not violate the preset security constraints, it sends the decision instruction to the corresponding logistics dispatch terminal through the system message push channel. At the same time, it triggers the terminal's audible and visual alarm to ensure that dispatchers can notice the warning information in a timely manner and take action accordingly.

[0064] The above embodiments realize the fully automated processing of the entire chain from the acquisition of original alarm signals to the identification of business scenarios and the generation of intelligent decision instructions. This enables alarm events to be accurately interpreted in specific business contexts and generate targeted handling decisions. It effectively solves the problem that traditional in-transit risk control systems rely solely on fixed rules for alarm classification, which makes it difficult to combine with actual business scenarios, resulting in high false alarm rates and delayed responses. In this way, it realizes scenario-based intelligent analysis and accurate early warning of alarm events in the context of bulk logistics in-transit transportation.

[0065] Following the above embodiments, the method provided in this embodiment will now be described in more detail. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the logistics in-transit risk control method based on an AI large model in this application embodiment.

[0066] S201. Parse the current operation entity in the structured alarm data;

[0067] When the on-the-go risk control system receives the original alarm message and parses it to obtain structured alarm data in step S101, in some scenarios, the entity identification field in the structured alarm data may be missing, damaged, or inconsistent with the actual working entity. For example, the vehicle terminal may not be bound to vehicle information in time after restarting due to a fault, the terminal may be temporarily transferred to another vehicle, or the entity identification field of the original alarm message may be lost during transmission. In this case, in order to accurately identify the current working entity, the on-the-go risk control system will start this step to perform reverse positioning and identification of the working entity.

[0068] Specifically, the on-the-go risk control system first extracts the entity identifier field of the current alarm event from the structured alarm data. This entity identifier field may include one or more identifier information such as the vehicle terminal number, license plate number, and device serial number. Subsequently, the on-the-go risk control system reads the event location coordinates from the structured alarm data and uses these event location coordinates as the geometric center of the spatial search. A spatial search window is defined according to a preset search radius. This search radius can be set to different values ​​depending on the subcategory of the alarm event. For example, it can be set to 500 meters for parking alarm events, 2000 meters for yaw alarm events, and 100 meters for collision alarm events, so that the range of the spatial search window matches the spatial influence range of the alarm event. The on-the-go risk control system may also use other forms such as rectangular search windows or polygonal search windows, which are not limited in this embodiment. The in-transit risk control system performs a spatial range query in the bulk logistics business system database, filtering out all operational entities whose locations fall within the spatial retrieval window and whose current business status is marked as in transit as candidate operational entities. At the same time, it obtains the planned trajectory data corresponding to each candidate operational entity. This planned trajectory data is a spatiotemporal data set organized in time series, recording the location that the candidate operational entity should be at each moment.

[0069] Next, the on-the-go risk control system compares the extracted entity identifier field with the candidate entity identifiers of each candidate operation entity. If the entity identifier field matches any candidate entity identifier, the on-the-go risk control system directly confirms that candidate operation entity as the current operation entity. If the entity identifier field does not match any of the candidate entity identifiers of the candidate operation entities, it indicates that there is indeed an anomaly in the entity identifier field of the structured alarm data or that the current operation entity has not been pre-registered in the system. In this case, the on-the-go risk control system proceeds to the offset calculation process. For each candidate operation entity, the on-the-go risk control system retrieves the coordinates of the planned trajectory point corresponding to the time of the event from its planned trajectory data. If the precise point of the time of the event does not exist in the planned trajectory data, the on-the-go risk control system uses linear interpolation of trajectory points at adjacent times to obtain the interpolated trajectory point coordinates at the time of the event. Subsequently, the on-the-go risk control system calculates the spatial distance between the event location coordinates and the planned trajectory point coordinates as the offset of the candidate operation entity. This spatial distance can be calculated using the latitude and longitude spherical distance formula or the Euclidean distance after planar projection.

[0070] After calculating the offset, the on-the-go risk control system performs a business compatibility determination to exclude candidate operation entities that, although spatially close, have business attributes incompatible with the alarm event characteristics. The on-the-go risk control system first retrieves the corresponding event characteristics from a pre-defined event characteristic mapping table based on the alarm event sub-category of the current alarm event. These event characteristics include, but are not limited to, the applicable business stage range, the applicable cargo category range, and the applicable vehicle type range. The on-the-go risk control system then compares these event characteristics with the current business stage and cargo attributes of each candidate operation entity. If the current business stage of a candidate operation entity is not within the applicable business stage range specified by the event characteristics, or if the cargo attribute of a candidate operation entity is not within the applicable cargo category range specified by the event characteristics, the on-the-go risk control system determines that the candidate operation entity is incompatible with the current alarm event business and removes it from the candidate operation entity set. For example, when the alarm event subcategory is "hazardous chemical leak alarm", the event characteristics specify that the applicable cargo attribute is hazardous chemical goods. If the cargo attribute of a candidate operation entity is ordinary ore, the in-transit risk control system will determine that the candidate operation entity is incompatible and remove it.

[0071] Finally, the in-transit risk control system compares the offsets of the remaining candidate operation entities in the remaining candidate operation entity set, selects the remaining candidate operation entity with the smallest offset as the current operation entity, and fills the entity identification information of the current operation entity back into the structured alarm data to replace or complete the original entity identification field. If there are multiple candidate operation entities in the remaining candidate operation entity set with equal and minimum offsets, the in-transit risk control system further introduces secondary judgment conditions for selection, such as prioritizing the candidate operation entity with the highest matching degree between cargo attributes and event characteristics, or prioritizing the candidate operation entity whose business stage time window is closest to the time of event occurrence, etc. If the remaining candidate operation entity set is empty, it indicates that there is no operation entity compatible with the alarm event business within the current spatial search window. The in-transit risk control system then expands the search radius of the spatial search window according to the preset strategy and re-executes the above query and judgment process, or marks the current alarm event as pending manual verification and pushes it to the logistics dispatch terminal for manual intervention. Through this step, even when the entity identifier field is missing or abnormal, the in-transit risk control system can still reverse locate the current operating entity using multi-dimensional information such as spatial location, business stage, and cargo attributes. This effectively solves the problem that the inability to identify the operating entity due to abnormal entity identifiers in alarm messages prevents subsequent business correlation analysis. It significantly improves the robustness of the in-transit risk control system under complex data conditions and the completeness of alarm event processing.

[0072] S202. Search and query the database of the bulk logistics business system to obtain relevant theoretical business data, and determine the business stage of the current operation entity and the main business area corresponding to the business stage based on the theoretical business data.

[0073] The bulk logistics business system database refers to the business management database that stores business data across the entire bulk logistics transportation chain. It is used to represent and record operational data such as transportation orders, transportation plans, work scheduling, loading and unloading tasks, route planning, and terminal information. Theoretical business data refers to data that describes the standard business process information that the current operating entity should execute, pre-set according to transportation plans and scheduling arrangements. This includes planned transportation routes, planned operating periods, planned loading and unloading terminals, and planned arrival times. A business stage refers to the specific operational link in the entire bulk logistics transportation process where the current operating entity is located; the main business area refers to the main geographical operating range corresponding to the current business stage, where the current operating entity should be located at that stage.

[0074] When the in-transit risk control system completes the parsing of the current job entity in step S201, the system needs to obtain the planned execution information of the job entity at the business level to determine the theoretical business state that the job entity should be in when an alarm event occurs. The in-transit risk control system uses the identity identifier of the current job entity as the retrieval keyword and conducts an associated query in the database of the bulk logistics business system. The system first retrieves the currently valid transport order bound to the job entity and obtains the corresponding transport plan data, including the planned starting station, the planned destination station, the planned passing nodes, the planned arrival time windows of each node, the planned job content and the planned job duration of each node, etc. The in-transit risk control system uses the data retrieved above as the theoretical business data. Subsequently, the in-transit risk control system compares the alarm occurrence time in the structured alarm data with the planned time windows of each stage in the theoretical business data, and at the same time performs a spatial matching of the alarm occurrence location in the structured alarm data with the planned job areas of each stage in the theoretical business data. Based on the comparison results in both the time dimension and the spatial dimension, it determines the business stage where the current job entity is at the moment of alarm occurrence.

[0075] For example, when the alarm occurrence time of the transport vehicle "Yu * - ×××××" is 14:30, the theoretical business data shows that the vehicle is planned to perform loading operations at the loading yard of Mining Area A from 13:00 to 15:00, and the alarm occurrence location coordinates fall within the geographical fence of the loading yard of Mining Area A. The in-transit risk control system then determines that the business stage where the current job entity is located is the loading stage, and the main business area corresponding to this business stage is the geographical area covered by the loading yard of Mining Area A. If both the alarm occurrence time and location point to the transition interval between two business stages, the in-transit risk control system makes a determination on the attribution of the business stage according to the preset determination strategy of time priority or location priority.

[0076] Through this step, the in-transit risk control system associates and binds the alarm event with the specific business execution stage, enabling subsequent risk judgment to be carried out in the context of a specific business stage, effectively solving the problem that the risk meanings of the same alarm type are different in different business stages but cannot be distinguished.

[0077] S203. Determine the refined verification rules bound to this business stage, and the refined verification rules include the target refined job area allowing the current alarm event to occur, the threshold of the allowed normal operation duration, and the illegal assistance objects restricted from approaching.

[0078] Among them, the detailed verification rules refer to the set of refined judgment rules pre-defined by the in-transit risk control system for each business stage, used to verify whether the current alarm event conforms to the normal operating procedures of that business stage. The target detailed operating area refers to the specific detailed geographical area that allows the current alarm event to reasonably occur under the current business stage, representing a more refined spatial division than the main business area. The normal operation duration threshold refers to the maximum reasonable duration for the operational behavior involved in the current alarm event to continue under the current business stage. Unauthorized assistance targets refer to other entities that should not appear near the current operating entity's operating area or interact with the current operating entity under the current business stage, including but not limited to unplanned vehicles, unauthorized personnel, and unrelated loading / unloading equipment.

[0079] After the on-the-go risk control system determines the business stage of the current operating entity in step S202, the system needs to further obtain the refined verification standards under that business stage in order to make a scenario-based compliance judgment on the alarm event.

[0080] The in-transit risk control system uses business stage identifiers and alarm event subcategories as a combined index to retrieve subcategories of verification rules that match the current scenario from a pre-defined subcategories of verification rules. This subcategories of verification rules is a rule database pre-built by the in-transit risk control system based on the operational specifications, safety management systems, and historical risk cases of each business stage in bulk logistics. Each subcategories of verification rules is bound to a specific business stage and alarm event subcategory. The detailed verification rules retrieved by the in-transit risk control system include three dimensions of verification standards: The first dimension is the spatial compliance standard, which is the target subdivision of the operation area. This area is a further subdivision of the main business area. For example, in the loading stage, the main business area is the entire loading yard of the mine, while the target subdivision of the operation area can be further subdivided into the loading weighbridge area, loading lane area, loading waiting area, etc. Different alarm event subcategories correspond to different allowed areas; The second dimension is the time compliance standard, which is the normal operation time threshold. For example, in the loading stage, the normal operation time threshold for the parking alarm event can be set to 120 minutes. Exceeding this time is considered an abnormal stay; The third dimension is the related object compliance standard, which restricts the approach of illegal assisting objects. For example, in the unloading stage, if other transport vehicles not associated with this order appear near the unloading station of the current operation entity, they are considered illegal assisting objects.

[0081] Through this step, the in-transit risk control system refines the general business stage judgment into multi-dimensional specific verification standards, enabling subsequent alarm event analysis to be carried out under the constraints of refined business rules, effectively solving the problem of insufficient accuracy in risk identification caused by overly coarse business stage judgment.

[0082] S204. Obtain event information data at the time the current alarm event occurs. The event information data includes the event location coordinates, the duration of the behavior, and surrounding environment image data.

[0083] After the on-the-go risk control system determines the detailed verification rules bound to the current business stage in step S203, the system needs to obtain the actual occurrence data of the current alarm event in order to compare it with the detailed verification rules item by item.

[0084] The on-the-go risk control system obtains event information from multiple data sources. For event location coordinates, the system extracts the real-time latitude and longitude coordinates of the current working entity reported by the vehicle's GPS or BeiDou positioning module from the structured alarm data. The accuracy of these coordinates should meet the requirements for distinguishing subdivided work areas. If the positioning accuracy in the structured alarm data is insufficient, the system can also send a high-precision positioning request to the vehicle's IoT sensing terminal to obtain more accurate location information. For the duration of the behavior, the system uses different calculation methods depending on the sub-category of the alarm event. For example, for a parking alarm event, the duration is the time difference from when the vehicle's speed drops to zero to the current moment; for a yaw alarm event, the duration is the time difference from when the vehicle deviates from the planned route to the current moment. The system calculates this time difference by querying historical trajectory data or status change logs from the vehicle's terminal. For surrounding environment image data, the on-the-go risk control system sends an image acquisition command to the vehicle-mounted IoT sensing terminal, triggering the vehicle-mounted camera to capture environmental images of the front, rear, sides, and interior of the vehicle of the current working entity, and then transmits the collected image data back to the on-the-go risk control system. If the vehicle-mounted sensing terminal is equipped with a continuous recording function, the on-the-go risk control system can also extract video frames within a specific time window before and after the alarm occurs from the video stream as surrounding environment image data.

[0085] Through this step, the on-the-go risk control system obtains multi-dimensional on-site data that can comprehensively reflect the actual occurrence of alarm events, providing a sufficient data foundation for subsequent accurate comparison with detailed verification rules, and effectively solving the problem of misjudgment caused by the inability to fully restore the event scene by relying solely on limited fields in the alarm text.

[0086] S205. Perform status verification on the event status data according to the detailed verification rules to obtain the quantified verification result;

[0087] Among them, status verification refers to the process by which the in-transit risk control system compares and judges the event status data with the standards of each dimension in the detailed verification rules one by one. This is used to determine whether the current alarm event complies with the normal operating procedures of the current business stage in terms of spatial compliance, temporal compliance, and compliance of related objects.

[0088] When the on-the-way risk control system performs status verification on the event situation data in step S205, if it is initially compared and found that the event location coordinates exceed the range of the target sub-operation area specified in the sub-verification rules, or the behavior duration exceeds the normal operation duration threshold specified in the sub-verification rules, according to the traditional verification method, it will be directly determined as a violation warning. However, in the actual operation process, due to the existence of environmental factors such as loading and unloading equipment failures, yard queuing congestion, abnormal weather, and batch operation delays, the operation entity may be forced to exceed the original target sub-operation area or exceed the normal operation duration threshold due to objective reasons. If such environmental factors are not considered and directly determined as a violation, it will lead to a large number of false alarms. Therefore, the on-the-way risk control system starts this step to perform dynamic compensation verification for environmental perception. The on-the-way risk control system first uses the business main area determined in step S202 as the retrieval range, and retrieves all operation entities in the business main area and with the same current business stage as the current operation entity in the database of the bulk logistics business system, and takes these operation entities as the surrounding associated operation entities; for example, if the current operation entity is the transport vehicle "Yu * - ×××××" and the business stage is the loading stage, and the business main area is the A mining area loading yard, then the on-the-way risk control system retrieves all other transport vehicles currently in the loading stage within the A mining area loading yard as the surrounding associated operation entities.

[0089] Subsequently, the on-the-way risk control system collects the current associated operation parameters of each surrounding associated operation entity through the real-time data interface of the vehicle-mounted Internet of Things sensing end, the yard Internet of Things sensing end, or the database of the bulk logistics business system. The current associated operation parameters include, but are not limited to, the current stay duration, the current loading and unloading progress, the current waiting duration, the current equipment operation status, the current operation speed, and other parameters of each surrounding associated operation entity. The on-the-way risk control system performs statistical analysis and processing on the current associated operation parameters of all the retrieved surrounding associated operation entities, and extracts environmental fluctuation characteristic parameters used to characterize the overall equipment operation status within the retrieval range; various statistical calculation methods can be adopted for the extraction method of the environmental fluctuation characteristic parameters. For example, calculate the deviation ratio of the mean of the current stay duration of each surrounding associated operation entity from the historical normal stay duration benchmark as the environmental fluctuation characteristic parameter in the time dimension, calculate the average distance of each surrounding associated operation entity deviating from the original planned operation point as the environmental fluctuation characteristic parameter in the space dimension, calculate the proportion of the equipment failure status of each surrounding associated operation entity as the environmental fluctuation characteristic parameter in the equipment dimension, etc.; the on-the-way risk control system can also adopt a weighted comprehensive calculation method to fuse the statistical values in multiple dimensions into a single environmental fluctuation characteristic parameter index.

[0090] Next, the on-the-go risk control system uses the extracted environmental fluctuation characteristic parameters to dynamically compensate for the outward extension of the target subdivided work area and the normal operation time threshold, generating a dynamic spatiotemporal tolerance domain. Regarding spatial compensation, the on-the-go risk control system determines the spatial extension coefficient based on the spatial dimension environmental fluctuation characteristic parameters. Specifically, it first calculates the average spatial deviation distance of surrounding related work entities, i.e., the average distance between the current location of each related entity and its planned work point; then, it compares this average spatial deviation distance with a preset baseline deviation distance to obtain the spatial fluctuation coefficient. The boundary of the target subdivided work area is then extended outward proportionally according to the spatial extension coefficient or by a preset step size. For example, when the average spatial deviation of surrounding related work entities is large, indicating overall congestion or site overcrowding within the search range, the on-the-go risk control system extends the boundary of the target subdivided work area outward by a greater distance.

[0091] Regarding time compensation, the on-the-go risk control system determines the time extension coefficient based on environmental fluctuation characteristic parameters in the time dimension. Specifically, it calculates the average dwell time overrun ratio of surrounding related work entities, i.e., the average proportion of actual dwell time exceeding the standard operation time for each related entity. This average dwell time overrun ratio is then compared to a preset benchmark overrun ratio to obtain the time fluctuation coefficient. The normal operation time threshold is extended backward according to the time extension coefficient. For example, when the average dwell time deviation ratio of surrounding related work entities is high, indicating a general delay in overall operation progress within the search range, the on-the-go risk control system extends the normal operation time threshold for a longer period. This ensures that the compensated dynamic spatiotemporal tolerance domain includes both the original target subdivided operation area and the normal operation time threshold, as well as the reasonable deviation range caused by environmental factors. An upper limit threshold can be set for the extension range of this dynamic compensation to prevent excessive extension when environmental fluctuation characteristic parameters are abnormal, which could lead to verification failure.

[0092] Finally, the in-transit risk control system calculates the overflow boundary difference between the event location coordinates and the duration of the behavior relative to the dynamic spatiotemporal tolerance domain. Specifically, the in-transit risk control system determines whether the event location coordinates still fall outside the spatial boundary of the dynamic spatiotemporal tolerance domain. If they do, it calculates the shortest distance from the event location coordinates to the spatial boundary of the dynamic spatiotemporal tolerance domain as the spatial overflow boundary difference; if they fall within the dynamic spatiotemporal tolerance domain, the spatial overflow boundary difference is zero. The in-transit risk control system also determines whether the duration of the behavior still exceeds the time boundary value of the dynamic spatiotemporal tolerance domain. If it does, it calculates the difference between the duration of the behavior and the time boundary value of the dynamic spatiotemporal tolerance domain as the time overflow boundary difference; if it falls within the dynamic spatiotemporal tolerance domain, the time overflow boundary difference is zero. The on-the-go risk control system determines the spatiotemporal dimension verification result based on the specific values ​​of the spatial overflow boundary difference and the temporal overflow boundary difference. When both overflow boundary differences are zero, the spatiotemporal dimension verification result is marked as compliant after environmental compensation, indicating that the alarm event is actually a reasonable deviation caused by explainable environmental factors. When either overflow boundary difference is greater than zero, the spatiotemporal dimension verification result is marked as a real anomaly, and the value of the overflow boundary difference is included in the verification result as a quantitative indicator of the severity of the anomaly.

[0093] Through this step, the on-the-go risk control system incorporates real-time fluctuations in the surrounding operating environment into the compliance determination process of alarm events. This enables the verification rules to be dynamically and adaptively adjusted according to environmental conditions, effectively solving the problems of high false alarm rate and high false alarm rate caused by fixed verification thresholds in complex and ever-changing bulk logistics operation environments. This significantly improves the accuracy and scenario adaptability of alarm event analysis.

[0094] In some embodiments, it may be impossible to fully identify abnormal interactions between external entities such as personnel, vehicles, and equipment and the current operating entity by relying solely on spatiotemporal data. It may also be possible to encounter situations where, although the spatiotemporal data does not explicitly cross boundaries, there are hidden risks such as unauthorized collaboration, unauthorized approach, or suspected theft that cannot be identified. In such cases, the following implementation can be performed:

[0095] The on-the-go risk control system first performs image preprocessing, target detection, and entity segmentation on the acquired surrounding environment image data. Using a pre-set visual recognition model, it accurately detects and locates all external entities appearing in the image, including personnel, vehicles, loading / unloading equipment, and mobile devices—objects capable of interacting with vehicles or goods. Subsequently, the system performs joint positioning in both the image coordinate system and the geographic coordinate system to determine the location of the cargo access interface for the current operating entity. It continuously tracks the position, direction of movement, speed, and duration of stay of each external entity, calculating the real-time distance, relative angle, approach trend, and contact probability between the external entity and the cargo access interface, thus forming a dynamic relative relationship between the external entity and the cargo access interface.

[0096] The system inputs this relative dynamic relationship into a predefined risk interaction pattern library for similarity matching and pattern recognition. This library pre-stores and labels various interaction behavior patterns representing unauthorized material transfer intentions, such as repeated approaching, prolonged stays, obstructing cargo access, coordinated containment, cargo transfer, and illegal opening. Feature matching is used to determine the target risk interaction pattern that best matches the current behavior. Simultaneously, the system uses the external entity's identification, location, and equipment information as search criteria to perform permission queries in the bulk logistics business system database. This determines whether the external entity has the legal authority to collaborate with the current operating entity, access the terminal, handle cargo, and link equipment. If the query result indicates a lack of legal collaborative operation authority, the system immediately marks the external entity as an object of unauthorized assistance. The system continuously tracks and records the relative dynamic relationship between the external entity and the cargo access interface. Based on the minimum approach distance, continuous approach duration, approach speed, and risk weight corresponding to the target risk interaction pattern in the relative dynamic relationship, a pre-defined scoring model calculates the assistance intervention confidence level, which characterizes the likelihood of unauthorized assistance. Finally, the system performs a weighted fusion calculation on the spatiotemporal dimension verification results and the confidence level of the assistance intervention according to the system's preset weight ratio. By combining the degree of spatiotemporal boundary violation with the degree of external violation risk, the final quantitative verification result that takes into account both spatiotemporal compliance and behavioral risk is obtained.

[0097] This step introduces external entity recognition, behavior analysis, permission determination, and risk confidence calculation on the basis of spatiotemporal dimension verification, realizing the upgrade from single-space verification to multi-dimensional in-depth verification. It effectively solves the problems that traditional methods cannot identify hidden violations, collaborative crimes, and illegal connections by relying solely on spatiotemporal thresholds, and greatly improves the comprehensiveness, accuracy, and reliability of alarm event verification.

[0098] S206. Confirm the business context information based on the verification result.

[0099] After the on-the-go risk control system completes the status verification and obtains the quantified verification result in step S205, the system needs to comprehensively organize the business-related information obtained and generated in the aforementioned steps to form complete business context information, which can be used for matching and generating special prompt words in the subsequent step S105.

[0100] In this embodiment, by employing a comprehensive technical approach that accurately analyzes the current operational entity corresponding to the alarm, determines the business stage and main business area based on business data, binds detailed verification rules, collects on-site event data, performs multi-dimensional status verification, and ultimately confirms the business context information, the alarm event can be deeply correlated with the actual situation and external behavior. This effectively solves the problems of traditional early warning relying solely on perception data, being detached from business scenarios leading to one-sided verification, inaccurate risk identification, misjudgment and omission, and inability to identify hidden violations. Consequently, it achieves scenario-based, refined, and quantitative analysis of in-transit alarms in bulk logistics, providing a real, complete, and reliable business basis for subsequent generation of dedicated prompt words and output of AI decision-making instructions, significantly improving the accuracy of early warnings and the effectiveness of handling.

[0101] The in-transit risk control system in this application embodiment is described below from a hardware processing perspective. Please refer to [link / reference needed]. Figure 4 This is a schematic diagram of the physical device structure of the in-transit risk control system in the embodiments of this application.

[0102] It should be noted that, Figure 4 The structure of the in-transit risk control system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0103] like Figure 4 As shown, the in-transit risk control system includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from storage section 408 into Random Access Memory (RAM) 403, such as performing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0104] The following components are connected to I / O interface 405: input section 406 including audio input devices, push-button switches, etc.; output section 407 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 408 including a hard disk, etc.; and communication section 409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0105] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in this application.

[0106] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0108] Specifically, the in-transit risk control system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the logistics in-transit risk control method based on the AI ​​big model provided in the above embodiment.

Claims

1. A logistics in-transit risk control method based on an AI large-scale model, characterized in that, The method includes: Receive raw alarm messages from the vehicle IoT sensing terminal and parse the raw alarm messages into structured alarm data containing alarm levels; The structured alarm data is input into the intent recognition module for multi-level parsing to obtain the danger alarm data of the current alarm event. The danger alarm data includes the danger level category of the alarm and the alarm event sub-category of the specific alarm event. Based on the alarm event sub-category, determine whether the current alarm event has business attribute requirements; If so, the structured alarm data will be compared with the bulk logistics business system database to obtain business context information related to the current alarm event; Based on the danger alarm data and the business context information, match and generate specific prompt words for the current alarm event scenario; The dedicated prompt words and the structured alarm data are input into a preset instruction to generate an AI big model, obtain decision instructions, and send them to the logistics scheduling terminal for early warning.

2. The method according to claim 1, characterized in that, The step of determining whether the current alarm event has business attribute requirements based on the alarm event sub-category specifically includes: Using the alarm event sub-category as the input node, a traversal search is performed along the adjacent edges of the input node in the preset bulk logistics knowledge graph to extract the set of entity nodes associated with the input node. Traverse the tag attributes of the entity node set and determine whether the entity node set contains a preset business status type entity node. The business status type entity node includes empty / loaded status, bulk cargo attributes, and waybill fulfillment stage. If not included, the current alarm event is determined to have no business attribute requirements; If included, determine the shortest path level from the input node to the business status entity node; If the shortest path level is less than the preset number of hops, then the current alarm event is determined to have business attribute requirements.

3. The method according to claim 1, characterized in that, If so, the step of performing a data collision between the structured alarm data and the bulk logistics business system database to obtain business context information related to the current alarm event specifically includes: Parse the current job entity in the structured alarm data; The relevant theoretical business data is retrieved by searching the database of the bulk logistics business system, and the business stage of the current operating entity and the main business area corresponding to the business stage are determined based on the theoretical business data. Determine the subdivided verification rules that are bound to the business stage. The subdivided verification rules include the target subdivided work area that allows the current alarm event to occur, the allowed normal operation duration threshold, and the restricted objects that can approach the violation assistance object. Acquire event information data at the time the current alarm event occurs, including event location coordinates, duration of the action, and surrounding environment image data; The event status data is subjected to status verification according to the detailed verification rules to obtain a quantified verification result; The business context information is confirmed based on the verification result.

4. The method according to claim 3, characterized in that, The steps of performing status verification on the event status data according to the aforementioned detailed verification rules to obtain quantified verification results specifically include: If the event location coordinates exceed the target subdivided work area, or the duration of the behavior exceeds the normal operation duration threshold, then the main business area is used as the search scope to obtain the current associated operation parameters of the surrounding associated work entities that are in the same business stage as the current work entity. Based on the current associated operating parameters, environmental fluctuation feature parameters are extracted to characterize the operating status of equipment within the search range; Using the environmental fluctuation characteristic parameters, dynamic compensation is applied to the target subdivided work area and the normal operation duration threshold to extend outward, generating a dynamic spatiotemporal tolerance domain; Calculate the overflow boundary difference between the event location coordinates and behavior duration and the dynamic spatiotemporal tolerance domain, and determine the spatiotemporal dimension verification result based on the overflow boundary difference.

5. The method according to claim 4, characterized in that, After the step of calculating the difference between the event location coordinates and the duration of the behavior relative to the overflow boundary of the dynamic spatiotemporal tolerance domain, the method includes: Detect external entities appearing in the image based on the surrounding environment image data; Determine the relative dynamic relationship between the external entity and the cargo access interface of the current operating entity; The relative dynamic relationship is matched with a predefined risk interaction pattern library to obtain the target risk interaction pattern. The risk interaction pattern library stores multiple interaction behavior patterns that represent the intention to transfer unauthorized materials. Query the database of the bulk logistics business system to see if the external entity has the permission to collaborate with the currently operating entity; If not, the external entity will be marked as a violating assistance object; The relative dynamic relationship is continuously tracked, and the confidence level for assistance intervention is calculated based on the approximation distance in the relative dynamic relationship and the target risk interaction pattern. The spatiotemporal dimension verification result and the confidence level of the assisted intervention are weighted and fused according to preset weights to obtain the final quantitative verification result.

6. The method according to claim 3, characterized in that, The steps for parsing the current job entity in the structured alarm data specifically include: Extract the entity identifier field of the current alarm event; Based on the event location coordinates, a spatial retrieval window centered on the event location coordinates is defined in the bulk logistics business system database to obtain all candidate operation entities in the en route state within the spatial retrieval window and their corresponding planned trajectory data. If the entity identifier field does not match the candidate entity identifier of each candidate operation entity, then calculate the offset between the event location coordinates and the planned trajectory points of each candidate operation entity at the time of the event occurrence. Based on the event characteristics corresponding to the alarm event sub-category, business compatibility is determined with the current business stage and cargo attributes corresponding to each candidate operation entity to obtain the remaining candidate operation entities; Among the remaining candidate job entities, the candidate job entity with the smallest offset is selected as the current job entity.

7. The method according to claim 1, characterized in that, The step of matching and generating specific prompt words for the current alarm event scenario based on the danger alarm data and the business context information specifically includes: Using the alarm event sub-category and the business stage in the business context information as joint retrieval conditions, the scenario risk semantics corresponding to the current alarm event under the current business stage are queried in the preset risk semantic mapping table. The risk semantic mapping table has pre-established differentiated risk interpretations for the same alarm event sub-category under different business stages. Based on the scenario risk semantics, the core risk indication of the current alarm event is determined. The core risk indication is used to characterize the specific business elements threatened by the current alarm event in the current business stage. Based on the core risk indication, extract the description fragments and handling guidance fragments corresponding to the specific business elements from the preset prompt word element library; The descriptive fragment, the handling guidance fragment, and the hazard level category are assembled according to a preset word order arrangement rule to generate the special prompt word.

8. An in-transit risk control system, characterized in that, The in-transit risk control system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the in-transit risk control system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the in-transit risk control system, the in-transit risk control system performs the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is run on the in-transit risk control system, the in-transit risk control system performs the method as described in any one of claims 1-7.

Images