A method, electronic device, and storage medium for generating knowledge graphs in the civil aviation field based on a caching mechanism.

Abstract

This invention provides a method, electronic device, and storage medium for generating knowledge graphs in the civil aviation field based on a caching mechanism, relating to the field of knowledge graph generation technology. The method includes: obtaining the historical knowledge graph set RA corresponding to the target user ID; obtaining the maximum similarity RX between the target task and the historical task corresponding to each historical knowledge graph in RA. max If RX max >RY, then RX max The corresponding historical knowledge graph is determined as the initial knowledge graph of the target task corresponding to the target user ID; the target knowledge graph corresponding to the target user ID is generated; the cache lifespan of the knowledge graphs corresponding to the historical tasks of the same type as the target task in the historical knowledge graph library is adjusted according to the execution frequency, execution time and execution quality of the target task and each historical task of the same type as the target task; the present invention can improve the overall response speed and data timeliness of knowledge graph generation.

Description

Technical Field

[0001] This invention relates to the field of knowledge graph generation technology, and in particular to a method, electronic device and storage medium for generating knowledge graphs in the civil aviation field based on a caching mechanism. Background Technology

[0002] In the field of knowledge graph generation, traditional methods typically construct knowledge graphs independently for each new task, failing to fully utilize historical task data and resulting in significant redundant computation and resource waste. Specifically, existing technologies suffer from the following drawbacks: First, they lack a historical knowledge graph caching mechanism based on user IDs, making it impossible to quickly reuse historical generation results from the same user. This is especially problematic when handling similar tasks, requiring the graph to be reconstructed from the underlying data, leading to inefficiency. Second, they lack quantitative evaluation of task similarity, making it difficult to determine the reusability of historical knowledge graphs, resulting in data redundancy and insufficient timeliness during knowledge graph generation. Third, their fixed caching management strategies fail to dynamically adjust cache duration based on task execution frequency, time, and quality, easily causing hot data to become invalid or low-frequency data to occupy cache resources for extended periods, further impacting the efficiency and accuracy of knowledge graph generation. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to a first aspect of this application, a method for generating a knowledge graph in the civil aviation field based on a caching mechanism is provided, the method comprising the following steps:

[0005] R100 retrieves the target task corresponding to the target user ID and the preset historical knowledge graph library; the historical knowledge graph library is cached in the preset cache area, and the historical knowledge graph library includes several historical knowledge graphs, each of which corresponds to a historical task and a historical user ID.

[0006] R200: Obtain the knowledge graph corresponding to each historical user ID that is the same as the target user ID in the historical knowledge graph database, so as to obtain the historical knowledge graph set RA = (RA1, RA2, ..., RA2) corresponding to the target user ID. c , ...,RA d ), c=1,2,…,d;RA c d represents the c-th historical knowledge graph corresponding to the target user ID, and d represents the number of historical knowledge graphs corresponding to the target user ID.

[0007] R300, obtains the maximum similarity RX between the target task and the historical task corresponding to each historical knowledge graph in RA. max ;

[0008] R400, if RX max >RY, then RXmax The corresponding historical knowledge graph is determined as the initial knowledge graph of the target task corresponding to the target user ID; RY is the preset task similarity threshold;

[0009] R500 generates a target knowledge graph corresponding to the target user ID based on several task information and the initial knowledge graph within the target time period for the target user ID; the start time of the target time period is the latest time corresponding to the initial knowledge graph, and the end time is the current time.

[0010] R600 adjusts the cache lifetime of knowledge graphs corresponding to historical tasks of the same type as the target task in the historical knowledge graph library based on the execution frequency, execution time, and execution quality of the target task and each historical task of the same type as the target task.

[0011] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described method for generating a knowledge graph in the civil aviation field based on a caching mechanism.

[0012] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0013] The present invention has at least the following beneficial effects:

[0014] This invention presents a knowledge graph generation method for the civil aviation field based on a caching mechanism. By constructing a historical knowledge graph caching mechanism based on user ID, it achieves rapid matching and reuse of similar tasks for the same user, significantly reducing the cost of repeated knowledge graph generation. Through a task similarity evaluation mechanism, it accurately identifies reusable historical graphs, improving the efficiency and coherence of knowledge graph generation. Based on task execution characteristics, it dynamically adjusts the caching duration and optimizes caching resource allocation, ensuring that knowledge graphs corresponding to high-frequency, high-quality tasks remain effectively cached, while promptly eliminating low-frequency, outdated data. This, in turn, improves the overall response speed and data timeliness of knowledge graph generation, providing more efficient knowledge support for user business recommendations and predictions. Attached Figure Description

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

[0016] Figure 1A flowchart of a knowledge graph generation method for the civil aviation field based on a caching mechanism provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0019] Example 1:

[0020] Provide such as Figure 1 The method for generating a knowledge graph in the civil aviation field based on a caching mechanism, as shown, includes the following steps:

[0021] R100 retrieves the target task corresponding to the target user ID and the preset historical knowledge graph library; the historical knowledge graph library is cached in the preset cache area, and the historical knowledge graph library includes several historical knowledge graphs, each of which corresponds to a historical task and a historical user ID.

[0022] In this embodiment, the knowledge graph of the user generated by the methods in subsequent embodiments two to five will frequently use the knowledge graph corresponding to the target user ID. In order to improve the generation efficiency of the knowledge graph, it can be added to the historical knowledge graph library, which is cached in a preset cache area.

[0023] The historical knowledge graph library is cached in a preset cache area, avoiding reading from the underlying database on every access, reducing IO operations, and significantly improving data acquisition speed. In addition, it stores historical graphs of multiple users and tasks, providing rich reference data for subsequent graph generation based on user behavior and task characteristics.

[0024] R200: Obtain the knowledge graph corresponding to each historical user ID that is the same as the target user ID in the historical knowledge graph database, so as to obtain the historical knowledge graph set RA = (RA1, RA2, ..., RA2) corresponding to the target user ID. c , ...,RA d), c=1,2,…,d;RA c Let c be the c-th historical knowledge graph corresponding to the target user ID, and d be the number of historical knowledge graphs corresponding to the target user ID.

[0025] In the historical knowledge graph database, by matching user IDs, all historical knowledge graphs that are the same as the target user ID are filtered out, forming the historical graph set RA of the target user.

[0026] This step preserves only the target user's historical graph, eliminating interference from other users and making subsequent analysis more aligned with the user's behavioral patterns and knowledge needs. Based on the same user's historical task graph, their long-term knowledge preferences and task processing habits can be explored, providing a personalized foundation for generating the current task graph.

[0027] R300, obtains the maximum similarity RX between the target task and the historical task corresponding to each historical knowledge graph in RA. max .

[0028] Furthermore, step R300 may include the following steps:

[0029] R310, Obtain the target task and RA c The task type similarity RX of the corresponding historical tasks c，1 Parameter similarity RX c，2 Time similarity RX c，3 .

[0030] In this embodiment, the task type similarity RX c，1 It can measure the similarity between target tasks and historical tasks in terms of business type; parameter similarity RX c，2 It can compare the similarity of task input parameters, reflecting the degree of matching in specific execution details; temporal similarity RX c，3 It can assess the similarity of task execution times and capture the temporal patterns of user behavior. Multi-dimensional evaluation avoids the one-sidedness of a single indicator, comprehensively measures the similarity between tasks, and improves the accuracy of initial graph selection.

[0031] Furthermore, RX c，1 It is obtained through the following steps:

[0032] R311, obtain the tree structure corresponding to several preset tasks; wherein, the tree structure includes a root node, child nodes and task nodes; each root node is connected to several child nodes through edges, and each child node is connected to several task nodes through edges; the root node corresponds to the task scenario, the child nodes correspond to the task type, and the task nodes correspond to the specific task.

[0033] In this embodiment, the root node can be civil aviation business, the child nodes can be trip-related, and the specific task can be trip prediction.

[0034] R312, based on the tree structure, determine the node corresponding to the target task and RA. c Shortest path (RL) between nodes of the corresponding historical tasks c .

[0035] In this embodiment, the shortest path is from the target node to RA. c The path with the fewest edges to the corresponding historical task node, for example: the node corresponding to the target task and the RA. c If the nodes of the corresponding historical tasks belong to the same child node, then RL c =2; For example: Trip Prediction → Trip Related → Civil Aviation Business → Number of Edges = 2; Ticket Recommendation → Ticket Related → Civil Aviation Business → Number of Edges = 2; RL c =2+2=4.

[0036] R313, according to RL c Determine RX c，1 =1 / (1+RL c ).

[0037] The node corresponding to the target task and RA c Shortest path (RL) between nodes of the corresponding historical tasks c The larger the value, the smaller the similarity of the corresponding task types.

[0038] Furthermore, RX c，2 It is obtained through the following steps:

[0039] R314, which sets several preset parameters corresponding to the target task and RA c Several parameters of the corresponding historical tasks are vectorized to obtain the parameter vectors RV1 and RA corresponding to the target task. c The corresponding parameter vector RV2 for the historical task; where RV1 and RV2 have the same dimension.

[0040] In this embodiment, for parameters with specific numerical values, the parameters can be normalized, and for categorical parameters, one-hot encoding can be used to obtain RV1 and RV2.

[0041] R315 defines the cosine similarity between RV1 and RV2 as RX. c，2 .

[0042] It should be noted that those skilled in the art can use existing normalization, one-hot encoding, and cosine similarity calculation methods to obtain RX according to actual needs. c，2 This will not be elaborated upon here.

[0043] Furthermore, RX c，3 It is obtained through the following steps:

[0044] R316, Obtain the predicted execution time RT of the target task. new and RA c The execution time (RT) of the corresponding historical task old .

[0045] In this embodiment, RT new The knowledge graph corresponding to the target user ID can be input into a preset prediction model to obtain the result.

[0046] R317, according to RT now and RT old Determine RX c，3 =exp(-ε×RT new -RT old ); where ε is a preset attenuation factor.

[0047] In this embodiment, the difference between the predicted time and the historical time is calculated; the smaller the difference, the closer the times are. The time difference is converted into similarity using the exponential function exp(): when the time difference is 0, RX c,3 =1 (completely similar); the larger the time difference, the faster the exponential function value decays, and the lower the similarity.

[0048] The attenuation factor ε is used to adjust the degree of influence of time difference on similarity. The larger the ε is, the more sensitive the effect of time difference is. For example, in civil aviation, if ε=0.1, a 10-minute time difference will reduce the similarity by about 63%; if ε=0.2, the same time difference will reduce the similarity by about 86%, emphasizing the strictness of time matching.

[0049] R320, based on RX c，1 RX c，2 and RX c，3 Determine the target task and RA c Similarity RX of corresponding historical tasks c =μ1×RX c，1 +μ2×RX c，2 +μ3×RX c，3 To obtain the task similarity list RX = (RX1, RX2, ..., RX) corresponding to RA. c , ..., RX d ); where μ1, μ2 and μ3 are the preset task type similarity weight, parameter similarity weight and time similarity weight, respectively.

[0050] In this embodiment, μ1, μ2, and μ3 can be adjusted according to the business scenario. For example, μ2 can be increased for parameter-sensitive tasks. The flexible weighting mechanism can adapt to different business scenarios.

[0051] R330, determine RX based on RX.max =MAX(RX); where MAX() is the default function for finding the maximum value.

[0052] R400, if RX max >RY, then RX max The corresponding historical knowledge graph is determined as the initial knowledge graph of the target task corresponding to the target user ID; RY is the preset task similarity threshold.

[0053] In this embodiment, if RX max >RY indicates RX max The corresponding historical tasks and the target tasks corresponding to the target user ID are extremely similar, RX max The corresponding historical knowledge graph contains most of the historical task information needed for the target task; therefore, RX max The corresponding historical knowledge graph is determined as the initial knowledge graph of the target task corresponding to the target user ID; RY is a human-preset task similarity threshold used to judge whether the matching degree between the historical task and the target task is "high enough"; RY can be obtained based on a large amount of historical data analysis, or specifically set based on different task scenarios.

[0054] R500 generates a target knowledge graph corresponding to the target user ID based on several task information and the initial knowledge graph within the target time period. The start time of the target time period is the latest time corresponding to the initial knowledge graph, and the end time is the current time.

[0055] Furthermore, step R500 includes the following steps:

[0056] R510, based on several task information of the target user ID within the target time period, obtains several entities corresponding to the target user ID and several attributes corresponding to each entity.

[0057] In this embodiment, the initial knowledge graph contains several entities, each with an execution time. By comparing all execution times, the latest time can be obtained. It can be understood that within the time period from the latest time to the current time, the target user will generate new task information. For example, if the target user takes a flight within the target time period, it will generate travel task information. Several task information of the target user ID within the target time period can be obtained, and several entities corresponding to the target user ID and several attributes corresponding to each entity can be obtained.

[0058] R520 adds several entities corresponding to the target user ID and several attributes corresponding to each entity to the initial knowledge graph to obtain the target knowledge graph corresponding to the target user ID.

[0059] In this embodiment, for any entity to be added, if there is a node in the initial knowledge graph that corresponds to an entity of the same type as the entity, such as a node corresponding to an airline ticket entity, then the entity to be added is converted into a node and connected to the node through an undirected and unweighted edge; otherwise, a new node is created; thereby obtaining the target knowledge graph corresponding to the target user ID.

[0060] In this embodiment, during the process of generating the target knowledge graph corresponding to the target user ID, most of the data corresponding to the target knowledge graph is directly used from the historical knowledge graph, with only a small amount of entity information added. Therefore, this method greatly improves the generation efficiency of the knowledge graph.

[0061] R600 adjusts the cache lifetime of knowledge graphs corresponding to historical tasks of the same type as the target task in the historical knowledge graph library based on the execution frequency, execution time, and execution quality of the target task and each historical task of the same type as the target task.

[0062] Furthermore, step R600 includes the following steps:

[0063] R610, retrieves the most recent execution time RT from the execution times of historical tasks of the same type as the target task. last .

[0064] R620, according to RT last and the current time RT now The normalized execution time interval RT is obtained. norm =-2×(RT now -RT last ) / YT max +1; where YT max This is the preset maximum time interval.

[0065] Converting time intervals into standardized values ​​facilitates unified calculations with other metrics (quality, frequency). For example, RT now -RT last =1 day, YTmax=30 days, then RT norm =0.93 indicates that the time interval is very small and the data is highly timely.

[0066] R630, obtain the average execution quality RU corresponding to historical tasks of the same type as the target task; 0≤RU≤1.

[0067] In this embodiment, historical tasks of the same type as the target task have several parameters when executed. For example, for a trip prediction task, the corresponding parameters include prediction time and prediction accuracy. Then, the parameters are normalized and weighted to obtain the execution quality.

[0068] R640 normalizes the RU to obtain the normalized execution quality RQ. norm =2×RU-1.

[0069] Converting quality indicators into values ​​on the same scale as time intervals and execution frequency facilitates subsequent weighted calculations.

[0070] R650 retrieves the execution frequency RF corresponding to a historical task of the same type as the target task.

[0071] Execution frequency is the number of times the same type of task is executed per unit of time (e.g., 1 month); it reflects the high frequency of the task, and high-frequency tasks usually require more efficient caching strategies.

[0072] R660 normalizes the RF signal to obtain the normalized execution frequency QF. norm =2×RF / RF max -1; where RF max This is the preset maximum execution frequency.

[0073] In this embodiment, RF max This can be obtained through the analysis of a large amount of historical data.

[0074] R670, according to RT norm RQ norm and QF norm The current cache time-to-live (TTL) of the knowledge graphs corresponding to historical tasks of the same type as the target task in the historical knowledge graph repository is set. old Adjust to target cache duration TTL new =TTL old ×exp(τ1×RT norm +τ2×RQ norm +τ3×QF norm ); where τ1 is the preset execution time interval weight, τ2 is the preset execution quality weight, and τ3 is the preset execution frequency weight; τ1+τ2+τ3=1.

[0075] In this embodiment, the cache duration is adjusted by weighted summation, τ1×RT norm +τ2×RQ norm +τ3×QF norm To enable TTL new Increase, τ1×RT norm +τ2×RQ norm +τ3×QF norm For negative TTL new Decrease.

[0076] For example: A certain historical task is executed frequently (QF) norm =0.8), high execution quality (RQ)norm =0.6), and recently executed (RT) norm =0.9); if τ1=0.3, τ2=0.3, τ3=0.4, then the weighted sum is 0.69, TTL new =1.69×TTL old This means that the cache duration is extended by 69%, because high-frequency, high-quality, and new data is more worthy of caching.

[0077] For example: a certain historical task has a low execution frequency (QF) norm =0.2), low execution quality (RQ) norm =0.3), and the last execution was a long time ago (RT). norm =-0.9); If τ1=0.3, τ2=0.3, τ3=0.4, then the weighted sum is -0.1, TTL new =0.9×TTL old This means the cache duration is shortened by 10%, because low-frequency, low-quality, and old data are not worth caching.

[0078] In this embodiment, the cache duration is automatically adjusted based on the task's time relevance, execution quality, and frequency to avoid resource waste caused by a "one-size-fits-all" strategy. After determining the initial graph in step R400, the graph content is updated in R500, and the caching strategy in R600 optimizes the graph's storage and retrieval efficiency, forming a closed loop of "matching-updating-caching." (RT) norm The parameters allow for a longer cache of recently executed task graphs, ensuring that the system prioritizes the use of the latest business data.

[0079] In this embodiment, by constructing a historical knowledge graph caching mechanism based on user ID, rapid matching and reuse of similar tasks for the same user are achieved, significantly reducing the cost of repeated knowledge graph generation. Through a task similarity evaluation mechanism, reusable historical graphs are accurately identified, improving the efficiency and coherence of knowledge graph generation. Based on task execution characteristics, the caching duration is dynamically adjusted, and the allocation of caching resources is optimized to ensure that knowledge graphs corresponding to high-frequency, high-quality tasks remain effectively cached, while low-frequency, outdated data is promptly eliminated. This improves the overall response speed and data timeliness of knowledge graph generation, providing more efficient knowledge support for user business recommendations and predictions.

[0080] Example 2:

[0081] The following describes a user knowledge graph generation system, which includes: a processor, a knowledge graph generation module, an entity database, a relation database, an information query rule database, several task ports, and several information query ports; wherein, the entity database includes several preset entities, the relation database includes the relationships between entities, and the information query rule database includes several information query rules, each information query rule corresponding to a task.

[0082] In this embodiment, the entity database can be understood as a collection of entities, such as flights, airports, and tickets; the relationship database is a collection of relationships between entities, which can be undirected and unweighted, directed and weighted, or directed and unweighted; the information query rule database is a mapping table between task types and query rules, with different task types corresponding to different query rules; for example, if the task type is flight delay prediction, the corresponding query rules are as follows:

[0083] {"Data source":"Flight status database","Conditions":"Flights on the same route in the past 7 days"};

[0084] {"Data source":"Weather API","Conditions":"Weather for the departure location in the next 24 hours"};

[0085] {"Data source":"User history preferences","Conditions":"Frequency rate of frequently flown flights"}.

[0086] The task port is the port that receives knowledge graph generation requests from external business systems, such as APP and management system; the information query port is the interface that connects to different data sources, such as SQL query interface, API interface, message queue, etc.

[0087] The processor is used to perform, for example Figure 1 The steps shown are as follows:

[0088] S100, obtain the knowledge graph generation instruction sent by the task port; the knowledge graph generation instruction includes the target user ID and the target task.

[0089] The processor listens for requests on the task port and parses out the target user ID and target task type. Civil aviation example: A passenger initiates a request to "generate a knowledge graph of route preferences from location 1 to location 2" through a preset APP. The instruction includes: Target user ID: U1024 (Zhang San) Target task: "Route preference analysis".

[0090] S200: Based on the target task, determine the target information query rules corresponding to the target task from the information query rule base.

[0091] The system retrieves rules from the task type and matches them against predefined query rule sets.

[0092] Furthermore, step S200 includes the following steps:

[0093] S210, based on the task type of the target task, perform first-level index matching in the information query rule base to obtain a set of candidate information query rules associated with the task type.

[0094] Furthermore, step S210 includes the following steps:

[0095] S211, calculate the semantic similarity between the task type of the target task and the rule tags in the information query rule base.

[0096] In this embodiment, the semantic similarity between the task type of the target task, such as "route preference analysis", and the tags of each rule in the information query rule base, such as "historical flight analysis" and "passenger preference mining", is calculated. A word vector model in natural language processing, such as BERT, or a semantic distance algorithm based on the hierarchical structure of task types can be used to measure the semantic association between the task type and the rule tag. It should be noted that those skilled in the art can use existing semantic similarity calculation methods to calculate the semantic similarity between the task type of the target task and the rule tag in the information query rule base according to actual needs, which will not be elaborated here.

[0097] S212, rules with semantic similarity greater than the first preset similarity threshold are determined as candidate information query rules.

[0098] In this embodiment, a first preset similarity threshold is set, for example, 0.7. Rules with a calculated semantic similarity greater than this threshold are filtered out to form a candidate information query rule set. For example, if the target task is "flight delay prediction", through calculation, rules with a semantic similarity higher than the threshold such as "flight delay analysis based on weather data" and "prediction based on historical delay data" will be selected into the candidate set.

[0099] By using semantic similarity calculation for first-level index matching, the limitations of traditional simple keyword matching are overcome. This approach can uncover rules that are semantically similar but have different expressions, expanding the scope of rule selection and preventing key rules from being missed due to differences in task type descriptions. It also improves the comprehensiveness and relevance of the candidate rule set, laying the foundation for accurate determination of target rules in the future.

[0100] S220, parse the additional parameters in the knowledge graph generation instruction, the additional parameters including at least one of user profile tags, task line identifiers, and data sensitivity levels.

[0101] In this embodiment, the additional parameters included in the knowledge graph generation instruction are extracted and parsed. User profile tags reflect the user's characteristic attributes, such as "business traveler" and "frequent flyer"; task line identifiers are used to distinguish tasks from different business lines, such as "domestic flight business line" and "international flight business line"; data sensitivity levels indicate the sensitivity of the data, such as "public data" and "internal sensitive data". For example, the additional parameters in the instruction show that the user profile tag is "business traveler", the task line identifier is "international flight business line", and the data sensitivity level is "internal sensitive data".

[0102] Parsing additional parameters enables the system to obtain more background and constraint information about the task. This information will play a key role in subsequent rule filtering, ensuring that the determined target information query rules not only meet the requirements of the task type, but also meet the requirements of business scenarios and data security, thereby improving the fit between the rules and actual business needs.

[0103] S230, based on the additional parameters, perform secondary filtering in the candidate information query rule set to determine the target information query rule that meets all constraints.

[0104] In this embodiment, the parsed additional parameters are used to evaluate each rule in the candidate information query rule set. The rules are checked to see if they meet the requirements corresponding to the user profile tags; for example, rules for business travelers must include high-class cabin analysis, whether they fall within the specified task line identifier range, and whether they meet the access permissions for the data sensitivity level. For instance, rules with a sensitivity level of "internal sensitive data" must have the corresponding data access authorization configuration. Only rules that fully meet all additional parameter constraints can be determined as target information query rules. For example, in the candidate set, rules that include business traveler-related analysis, are applicable to international flight business lines, and have internal sensitive data access permissions are selected as target information query rules.

[0105] Secondary filtering uses additional parameters for precise filtering, selecting the rules that best fit the actual business needs from the candidate rule set. This avoids using rules that do not meet the business scenario or violate data security regulations, ensuring that the data and analysis logic on which the knowledge graph is generated are accurate and compliant, and improving the quality and usability of the generated knowledge graph.

[0106] S240, if there are multiple target information query rules that meet the conditions, select the rule with the highest priority to execute according to the preset rule priority strategy.

[0107] When multiple query rules for target information meet the criteria after secondary filtering, a preset rule priority strategy is used for selection. This priority strategy can be set based on factors such as business importance, rule timeliness, and rule applicability. For example, rules involving urgent business needs are given the highest priority; for the same task type, newly released rules have higher priority than older rules; and rules with broader applicability have higher priority. By comparing the priorities of multiple rules, the rule with the highest execution priority is selected for subsequent knowledge graph generation.

[0108] This step solves the challenge of selecting the appropriate rule when multiple rules meet the criteria, preventing the uncertainty of rule selection from causing logical chaos in the knowledge graph generation. By using a scientific prioritization strategy to select rules, the system ensures that it prioritizes the rules that best meet the current business needs and value, improving the efficiency and business relevance of knowledge graph generation and enabling the generated knowledge graph to better serve real-world business scenarios.

[0109] S300, according to the target information query rules, obtain the target information corresponding to the target user ID from the information query port corresponding to the target task; wherein, the target information includes several historical task information related to the target task corresponding to the target user ID.

[0110] Furthermore, step S300 includes the following steps:

[0111] S310, parse the data source configuration in the target information query rules, determine the set of information query ports to be accessed, the set of information query ports includes at least one of internal database ports, external API ports and real-time data stream ports.

[0112] In this embodiment, the data source configuration specified in the target information query rule is parsed to identify the information source required to complete the query. For example, the rule may include configurations such as data source: flight dynamics database, data source: weather API, and data source: real-time flight delay data stream. Based on different data source types, the corresponding information query ports to be accessed are determined. The internal database port is used to access internal enterprise storage data, such as a flight booking database; the external API port is used to call external service interfaces, such as a meteorological service API; and the real-time data stream port is used to obtain real-time updated data, such as airport real-time flight status stream data. Through parsing, the relevant ports are combined into an information query port set. For example, for the target information query rule of the "flight delay prediction" task, the parsed information query port set may include an internal flight dynamics database port, an external weather API port, and a real-time flight delay data stream port.

[0113] Clearly defining the correspondence between data sources and information query ports enables the system to quickly locate and prepare data acquisition channels. This avoids data acquisition confusion or errors caused by unclear data sources, improving the targeting and efficiency of data acquisition. Simultaneously, supporting multiple types of data source ports allows the system to integrate internal and external, static and dynamic, multi-dimensional data, enhancing the richness and comprehensiveness of knowledge graph data.

[0114] S320 generates a structured query statement based on the query parameter template in the target information query rules, combined with the target user ID and additional parameters.

[0115] In this embodiment, based on the query parameter template in the target information query rules, combined with the target user ID and additional parameters, such as user profile tags, task line identifiers, data sensitivity levels, etc., a structured query statement conforming to the query specifications of each data source is generated.

[0116] The query parameter template defines the conditions and parameter formats required for the query. For example, the template might require querying "flight booking records of users belonging to a certain task line and a certain user profile tag within the last 7 days". The target user ID is filled into the relevant user parameter positions, and additional parameters such as task line and user profile are added to form a complete query statement. For SQL databases, a standard SQL query statement is generated; for API interfaces, a request parameter combination conforming to the interface call specification is generated. If the target user ID is U1024, and the additional parameters show the user profile tag as "Business Traveler" and the task line identifier as "International Flight Business Line", combined with the query parameter template, the generated SQL query statement might be "SELECT...". FROM flight_bookingWHERE user_id='U1024' AND user_profile_label='Business Traveler' AND task_line_identifier='International Flight Business Line' AND booking_time>=CURDATE()-INTERVAL 7 DAY.

[0117] Generating structured query statements ensures the standardization and accuracy of data queries, enabling the system to interact effectively with different types of data sources. By combining the target user ID and additional parameters, data highly relevant to the target task can be precisely filtered out, avoiding the acquisition of irrelevant data, reducing data processing volume, and improving data acquisition efficiency. At the same time, this parameterized query method also enhances the system's flexibility, making it easier to adapt to changes in different tasks and user needs.

[0118] S330 sends the structured query statement to each information query port to obtain several historical task information related to the target task corresponding to the target user ID.

[0119] In this embodiment, the generated structured query statements are sent to various ports in the information query port set. Upon receiving the query statement, each port executes the query operation in the corresponding data source and returns the query results. The internal database port retrieves data from its internal database, the external API port sends requests to external services to obtain data, and the real-time data stream port filters data that meets the criteria from the real-time stream. Finally, the system integrates the results returned by each port to obtain several historical task information related to the target task corresponding to the target user ID.

[0120] For example, retrieve users' historical flight booking records from the flight booking database port, retrieve weather data for the corresponding flight date from the weather API port, and retrieve real-time flight delay information from the real-time data stream port, and aggregate these data into a complete set of historical task information.

[0121] By sending query statements to multiple information query ports in parallel, concurrent acquisition of multi-source data was achieved, significantly shortening data acquisition time and improving overall data acquisition efficiency. Integrating data from different sources made the acquired historical task information more comprehensive and richer, providing a sufficient and accurate data foundation for subsequent knowledge graph generation. This helps to generate high-quality, detailed knowledge graphs that better serve business analysis and decision-making.

[0122] S400, send the target information to the knowledge graph generation module;

[0123] The knowledge graph generation module is used to perform the following steps:

[0124] S500: Based on each historical task information, determine several entities corresponding to each historical task information from the entity database to obtain several entities related to the target task corresponding to the target user ID.

[0125] Furthermore, step S500 includes the following steps:

[0126] S510 parses the entity identifier field in the historical task information and maps the field value of the entity identifier field to the entity identifier in the entity database based on the entity mapping rules in the target information query rules.

[0127] Entity identifier fields, such as "flight number" and "passenger name," are extracted from historical task information. Based on predefined entity mapping rules in the target information query rules, these field values ​​are converted into corresponding standard entity identifiers in the entity database. For example, the flight number "CAXXXX" in historical task information is mapped to the entity "Flight CAXXXX" with ID "E0003" in the entity database; the user name "Zhang San" is mapped to the entity "Passenger Zhang San" with ID "U1234." Mapping rules can be a one-to-one fixed mapping table or complex transformation logic based on a rule engine, such as converting abbreviations and aliases to standard names.

[0128] This step achieves a unified association between data fields and standard entities, eliminating entity recognition confusion caused by differences in data representation, such as abbreviations and aliases, and ensuring the accuracy and consistency of entity construction in the knowledge graph. Simultaneously, by predefined mapping rules, it reduces manual annotation costs, improves entity processing efficiency, and provides a standardized data foundation for subsequent graph construction.

[0129] S520, execute a three-level matching strategy on the mapped entity identifier. The three-level matching strategy includes: directly locating the corresponding entity in the entity database by entity ID; for text descriptions without a clear ID, calling an NLP model to identify the entity type and name, and retrieving the entity database by semantic similarity; for records with only association information, tracing back to the target entity through the association relationship chain.

[0130] In this embodiment, the first-level matching is direct ID location: for data containing a clear entity ID, such as "passenger ID: U1234", the entity with the corresponding ID is directly retrieved in the entity database to quickly obtain complete entity information. For example, the detailed information of "passenger Zhang San" can be directly located through "U1234".

[0131] Secondary matching is NLP semantic retrieval: For text descriptions without explicit IDs, such as "flights from city 1 to city 2," NLP models such as BERT and GPT are invoked to analyze the text semantics, identify entity types (flights) and key attributes (departure location, destination), and then retrieve matching entities from the entity database by calculating semantic similarity. For example, the text is compared with the names and route information of flight entities in the entity database to find the most similar flight entities.

[0132] Level 3 matching involves tracing relationship chains: if a record only contains information about its association with other entities, such as "the passenger's frequently used routes," then it uses predefined relationship chains in the relational database, such as "passenger-frequently used routes-flights," to trace back to the target entity from known associated entities. For example, starting with "passenger Zhang San," it finds multiple flight entities corresponding to him through the "frequently used routes" relationship.

[0133] The three-level matching strategy forms a complete entity matching system, ranging from precise to fuzzy and from direct to indirect, covering various complex data scenarios. Whether it is structured ID data, unstructured text data, or related data, it can efficiently and accurately match the corresponding entities in the entity database, significantly improving the coverage and accuracy of entity recognition, avoiding entity omissions or incorrect matching, and ensuring the integrity of knowledge graph entities.

[0134] S530 performs attribute completion operation on the matched entities.

[0135] For matched entities, check if their attribute information is complete. If missing attributes exist, supplement attribute values ​​from relevant data sources or default rules based on the entity type and target task requirements. For example, for the "Flight CAXXXX" entity, if the historical task information does not include aircraft type information, query and complete "Aircraft Type: B787" from the flight basic information database; if the entity lacks common attributes, such as creation time or update time, fill in the current time or standard default value according to the system default rules.

[0136] This step ensures that each entity in the knowledge graph has complete and accurate attribute information, avoiding incomplete graph information or analytical biases caused by missing attributes. Complete attribute data provides richer information support for subsequent entity relationship analysis and knowledge reasoning, enhancing the application value and analytical depth of the knowledge graph. For example, in flight delay prediction, complete attributes such as aircraft type and historical on-time rate help to model and predict more accurately.

[0137] S540 applies entity deduplication and merging rules to aggregate multiple records of the same entity to obtain the entity set of the target user. The entity set contains the unique identifier, type, and attribute set of each entity.

[0138] The system applies predefined entity deduplication and merging rules to process multiple records of the same entity. It compares the entity's unique identifier and key attributes, such as name, type, and core ID, to determine if the records belong to the same entity. If they are the same entity, the attributes of the multiple records are aggregated, retaining valid attribute values ​​and merging conflicting attributes, such as taking the latest time or the highest priority value. For example, if there are two records for "Passenger Zhang San," one containing contact information and the other containing membership level, they are merged to form a complete "Passenger Zhang San" entity record containing both contact information and membership level, ultimately generating the target user's entity set.

[0139] This step eliminates duplicate entity data, avoids redundant nodes in the knowledge graph, makes the graph structure more concise and clear, and reduces data storage and computation costs. Simultaneously, attribute aggregation ensures the comprehensiveness and accuracy of entity information, improving the quality of the knowledge graph and facilitating efficient execution of subsequent graph-based queries, analyses, and recommendations. For example, in user profile construction, accurately aggregated entity information can more realistically reflect user characteristics.

[0140] S600: Based on the relational database, determine the relationships between several entities corresponding to the target user ID.

[0141] Furthermore, step S600 includes the following steps:

[0142] S610 parses the entity set of the target user and maps user behavior to a preset relationship type based on behavior records in historical task information.

[0143] The system parses the entity set of the target user, such as "Passenger Zhang San," "Flight CAXXXX," and "City 1 Beijing Capital International Airport," while also analyzing behavioral records from historical task information, such as "On October 1, 2024, Zhang San booked flight CAXXXX" and "Flight CAXXXX departed from Beijing Capital International Airport on the same day." Based on pre-defined mapping rules, these behavioral records are transformed into preset relation types. For example, the "booking" behavior corresponds to the relation type "Passenger booked flight," and the "departure" behavior corresponds to the relation type "Flight departed from airport." These mapping rules can be defined and optimized using domain expert knowledge or machine learning algorithms.

[0144] This step standardizes user behavior into a unified relationship type, resolving the ambiguity in relationship definitions caused by the diversity of behavioral expressions and ensuring the standardization and consistency of relationship representations in the knowledge graph. By pre-setting mapping rules, automated identification of relationship types is achieved, significantly reducing manual annotation costs, improving relationship construction efficiency, and providing a reliable foundation for subsequent relationship network-based analysis.

[0145] S620, determine the starting entity and target entity of the relationship based on the actor and the object.

[0146] Based on the mapped relationship type and the subject and object information in the behavior record, the starting entity and target entity of the relationship are clearly identified. In the behavior record "Zhang San booked flight CAXXXX", "passenger Zhang San" is the subject of the behavior and is the starting entity of the relationship; "flight CAXXXX" is the object of the behavior and is the target entity of the relationship. For bidirectional relationships, such as "passenger Zhang San and passenger Li Si travel together", the two entities can be each other's starting and target entities; for unidirectional relationships, such as "flight CAXXXX departs from city 1 Capital International Airport", "flight" is clearly distinguished as the starting entity and "airport" as the target entity.

[0147] S630, determine the weight value of each relationship based on the time, behavior type and co-occurrence frequency corresponding to the relationship between the starting entity and the target entity.

[0148] In this embodiment, for each pair of starting and target entities, the weight value is determined by comprehensively considering the time, behavior type, and co-occurrence frequency of the relationship. Regarding the time factor, recently occurring behaviors are given higher weight; for example, a flight booking behavior that occurred yesterday has a higher weight than one that occurred six months ago. In terms of behavior type, behaviors of higher importance, such as "purchasing first-class tickets," have a higher weight than ordinary behaviors, such as "querying flight information." Co-occurrence frequency reflects the closeness of the relationship between entities; if Zhang San frequently makes bookings for a certain flight, then that "booking" relationship has a higher weight. The weight can be calculated using a weighted formula, such as: Weight = SY1 × Time Weight + SY2 × Behavior Type Weight + SY3 × Co-occurrence Frequency Weight; where SY1, SY2, and SY3 are weight coefficients set according to business requirements.

[0149] This step introduces multi-dimensional factors to determine relationship weights, making the relationship network in the knowledge graph more hierarchical and dynamic, and able to reflect the true strength and importance of relationships between entities. The weighted relationship network provides richer information for data analysis. For example, in flight recommendations, high-weighted "booking" relationships can be used as a priority recommendation basis, improving the accuracy of recommendations and business value.

[0150] S640: Merge similar relationships between identical entity pairs and accumulate weight values ​​to obtain the relationship set for the target user.

[0151] In this embodiment, all relationships can be traversed. For similar relationships between identical entity pairs, such as multiple "booking" relationships generated by Zhang San booking CAXXXX flights multiple times, these relationships are merged and their weights are accumulated. The merged relationship retains the starting entity, target entity, relationship type, and accumulated weight information, ultimately forming a set of relationships for the target user. For example, if Zhang San booked CAXXXX flights three times within a month, and the weights of the "booking" relationships generated by each booking were 0.3, 0.4, and 0.3 respectively, the weight of the merged "booking" relationship would be 1.0.

[0152] This step eliminates redundant information in the relationship network, simplifies the knowledge graph structure, and reduces data storage and computation costs. Accumulating weight values ​​makes the expression of relationship strength more accurate, highlighting important relationships between entities and facilitating subsequent sorting, filtering, and analysis based on relationship weights. For example, it can quickly identify the closest relationship between a user and a specific entity, providing strong support for personalized services and precise task recommendations.

[0153] S700 generates a knowledge graph corresponding to the target user ID based on several entities corresponding to the target user ID and the relationships between the entities.

[0154] Furthermore, step S700 may include the following steps:

[0155] S710 encapsulates the entity set and relation set of the target user according to the format supported by the knowledge graph generation module to generate a standard graph data structure.

[0156] In this embodiment, the entity set and relation set of the target user are standardized and encapsulated according to the format supported by the knowledge graph generation module. For example, in the civil aviation scenario, the entities "passenger Zhang San" and "flight CAXXXX", as well as the relation "booking", need to be converted into a graph database, such as the node and edge structure supported by Neo4j. Specifically, this includes: defining a unified graph data model, clarifying the attribute fields and data types of nodes and edges; and performing serialization processing on entities and relations to ensure that the data format meets the interface requirements of the generation module.

[0157] This step eliminates format differences between different data sources, ensuring that entity and relation data are input into the generation module in a unified format, thus improving system compatibility and maintainability; the pre-packaged standard structure reduces the parsing time of the generation module.

[0158] Furthermore, step S710 includes the following steps:

[0159] S711 converts an entity into a node object, which contains a unique ID, type, and set of attributes.

[0160] In this embodiment, each entity is mapped to an independent node object, which contains three core attributes:

[0161] Unique ID: such as "U1024" (the entity ID of passenger Zhang San), to ensure the uniqueness of nodes in the graph.

[0162] Type: such as "passenger", "flight", "airport", to facilitate subsequent filtering and analysis by type.

[0163] Attribute set: Encapsulates the specific characteristics of an entity. For example, the "passenger" node contains attributes such as name, membership level, and number of historical flights.

[0164] The structured definition of types and attributes makes the semantics of nodes clear, which facilitates graph querying and knowledge reasoning; the mandatory requirement for unique IDs and types avoids missing entity information, such as ensuring that each "flight" node contains flight number and take-off and landing time attributes.

[0165] S712 converts the relation into an edge object, which contains the starting node ID, the target node ID, the relation type, the weight, and the timestamp.

[0166] The relationships between entities are converted into directed edge objects, which include five core fields:

[0167] Starting node ID: such as "U1024", representing passenger Zhang San;

[0168] Target node ID: such as "FLT_CAXXXX" representing flight CAXXXX;

[0169] Relationship type: such as "BOOKED" indicating a booking relationship;

[0170] Weight: Based on the calculation results of S630, such as "0.8", it indicates high-frequency booking behavior;

[0171] Timestamp: Records the time when the relationship occurred, such as "2024-10-01T08:30:00".

[0172] The introduction of timestamps and weights enables relationships to have a time dimension and strength differences, supporting time series analysis; directed edges and type definitions support multi-dimensional relationship expression, such as "flights depart from the airport" (one-way edge) and "passengers traveling together" (two-way edge) can be modeled in a unified way.

[0173] S720 calls the interface of the knowledge graph generation module, passing the standard graph data structure to generate the corresponding knowledge graph.

[0174] The encapsulated node and edge data is passed to the knowledge graph generation module through a standardized interface. The generation module then creates a visual graph based on the graph data structure. The interface supports parameterized configuration, such as selecting the graph storage type, like attribute graph or semantic graph; and configuring the graph display style, including node size and edge color variations based on weight.

[0175] The interface call method separates the generation module from the data processing flow, making it easy to upgrade and maintain independently. For example, when changing the graph database, there is no need to modify the upstream data processing logic. The generated structured graph can be directly used for business visualization (such as passenger travel relationship networks) and complex analysis (such as identifying high-frequency travel patterns through graph algorithms).

[0176] Furthermore, following step S700, the following steps are also included:

[0177] S800, in response to adding a new task port, obtains the task RW corresponding to the new task port.

[0178] When the system detects a new task port being connected, such as the civil aviation system adding a "low-carbon flight recommendation" service port, the processor automatically triggers the task acquisition process:

[0179] Obtain the metadata of the new task through the port registration protocol, including: task name, type, and business scenario description.

[0180] Parse the task definition file transmitted via the port, such as the task description in JSON format, and extract the core task identifier (RW).

[0181] This step allows the system to respond to new task port access without restarting the system. For example, when a "summer student ticket recommendation" task port is temporarily added during the peak season of civil aviation, the system can complete task identification within minutes.

[0182] By using a unified port registration protocol, we can ensure that the access methods for tasks in different business lines (such as passenger / freight tasks) are consistent, thereby reducing integration complexity.

[0183] S810, retrieves several entities corresponding to RW, the relationships between entities, and information query rules XE.

[0184] Based on the task description text, such as "low-carbon flight recommendation", the NLP model is invoked to identify potential entities ("carbon emission data", "sustainable aviation fuel") and relationships ("fuel use", "emission reduction"). If a predefined task template exists, the entity and relationship definitions are loaded directly from the template (e.g., referencing industry standard ontology).

[0185] Query rule generation: Based on task requirements (such as obtaining low-carbon flight data), generate corresponding information query rules XE, for example: {"Data source":["Carbon footprint database","Airline fuel report API"],"Query condition":"Flights with carbon emissions lower than the industry average in the past 12 months"}.

[0186] By combining NLP and templates, the cost of manually defining entity relationships is reduced; the automatically extracted entity relationships can be reused for similar tasks, forming the self-evolving capability of the domain knowledge graph.

[0187] S820, add several entities corresponding to RW to the entity database, add the relationships between entities to the relationship database, and add XE to the information query rule database.

[0188] Entity database update: Check if the new entity already exists (e.g., whether "sustainable aviation fuel" is in the database). If it does not exist, add a complete attribute definition (e.g., fuel type, carbon emission factor); establish a hierarchical relationship between entities (e.g., "sustainable aviation fuel" as a subtype of "fuel").

[0189] Relationship database update: Add new relationship types (such as "flight fuel use"), define relationship direction (flight → fuel) and attributes (usage ratio); associate existing entity relationships (such as establishing a causal relationship between "fuel use" and "emission reduction").

[0190] Rule base update: Store XE by task type and establish a mapping between "low-carbon flight recommendation" and XE; generate rule priority tags (e.g., emergency task rules have higher priority than regular tasks).

[0191] By following the steps above, it is possible to support the deployment of new task types with zero code. For example, when the civil aviation system adds the task of "calculating carbon tariffs for international flights", it can be enabled simply by updating the three databases without modifying the core code.

[0192] Data consistency assurance: Through uniqueness checks and hierarchical management, the duplicate definition of entity relationships is avoided. For example, it ensures that the attributes of the "carbon emission data" entity are consistent in different tasks.

[0193] Knowledge graph evolution: New content is automatically integrated into the existing graph system. For example, the entity "sustainable aviation fuel" can be associated with the "passenger preference analysis" task, enriching the business dimensions of the graph.

[0194] Through the dynamic update mechanism of the three databases, the system's support cycle for new business scenarios is greatly shortened; the entity relationships generated by each new task are automatically categorized and managed by the system to form an enterprise-level knowledge platform. For example, airlines can accumulate aviation domain knowledge graphs under different task scenarios; the standardized three-database update process reduces manual intervention and lowers system maintenance costs caused by task iteration.

[0195] In this embodiment, firstly, by determining the target information query rules from the information query rule base based on the target task, and only acquiring target user information related to the target task, the system avoids processing all historical task information of users, greatly reducing data processing volume, lowering computing resource consumption, and improving the efficiency of knowledge graph generation. Secondly, the system focuses on entities and relationships related to the target task, generating a more targeted lightweight knowledge graph that accurately reflects the characteristics and needs of users in specific business scenarios. Therefore, in civil aviation task recommendation, based on this knowledge graph, user preferences can be grasped more accurately, improving the accuracy of recommendation results.

[0196] In addition, the pre-set entity database, relation database, and information query rule database in the system make the knowledge graph generation process more standardized and regulated, which facilitates system maintenance and expansion. It can connect to various types of tasks, and when a new task is added, it is only necessary to add the corresponding entity, relation, and information query rules to the entity database, relation database, and information query rule database, which has high flexibility and scalability.

[0197] Example 3:

[0198] Based on the system in Embodiment 2 above, in order to improve the efficiency of knowledge graph generation, the specific steps performed by the knowledge graph generation module in Embodiment 2 are as follows:

[0199] Q100: Obtain the target user ID and target task.

[0200] The system receives external requests, such as user queries and business system calls, and parses the target user ID (e.g., U1024) and target task type (e.g., flight delay prediction).

[0201] Q200, based on the type of the target task, determine the target knowledge graph template corresponding to the target task from the preset knowledge graph template library; wherein, the preset knowledge graph template library includes several knowledge graph templates, each knowledge graph template corresponds to a task type; the knowledge graph template includes several different types of nodes and each node corresponds to an initial attribute set, the initial attribute set is empty.

[0202] The template is matched from a pre-set template library based on the task type. For example, the template for the "Flight Recommendation" task contains three types of nodes: passenger, flight, and airport. The initial attribute set of each node is empty (e.g., the passenger node contains placeholders for attributes such as name and membership level).

[0203] By using templates to unify the graph structure for similar tasks, consistency in knowledge representation is ensured; template reuse avoids redundant definition of nodes and relationships, improving graph generation efficiency.

[0204] Q300, for any node QW, based on several historical task information related to the target task corresponding to the target user ID, determine the entity corresponding to QW, so as to obtain the entity list QA = (QA1, QA2, ..., QA4) corresponding to QW. i QA n ), i=1,2,…,n; QA i Let be the i-th entity corresponding to QW, and n be the number of entities corresponding to QW.

[0205] For each node type (such as passenger) in the template, extract related entities from historical task information. For example, query a user's historical flight booking records by user ID, identify related flight entities (such as CAXXXX, MUXXXX), and form an entity list QA.

[0206] Q400, if n=1, then obtain the attribute value of each attribute corresponding to QA1 to obtain the attribute value list SA1=(SA 1，1 SA 1，2 SA 1，j SA 1，m ), j=1,2,…,m; SA 1，j Let m be the attribute value of the j-th attribute corresponding to QA1, and m be the number of attributes corresponding to QA1.

[0207] When a node corresponds to only one entity (e.g., the passenger node corresponds only to Zhang San), query all attribute values ​​of that entity. For example, retrieve attribute values ​​such as Zhang San's name (Zhang San) and membership level (Platinum Card) from the user profile to form an attribute value list SA1.

[0208] Furthermore, after step Q400 and before step Q500, the method may include the following steps:

[0209] Q410, if n=0, then extract the set of keywords QC related to the target task based on the historical task information corresponding to the target user ID.

[0210] When a template node has no matching entity in the historical task information, the system automatically extracts keywords from the user's historical behavior. For example, if a user searches for "business class from city 1 to city 2", the extracted keyword set is QC=["city 1","city 2","business class"].

[0211] This step addresses the cold start problem (such as new users having no history) and uncovers potential interests through keywords; semantic understanding is enhanced, and the extracted keywords provide a foundation for subsequent semantic matching, such as identifying users' preference for "business class".

[0212] Q411 performs semantic matching between QC and a pre-defined civil aviation domain knowledge base to obtain a specified set of entities associated with the target user ID.

[0213] The keyword set QC is semantically matched with a pre-defined civil aviation knowledge base (such as a flight database or airport information database). For example, "City 1" matches "City 1 First International Airport" (entity ID: AIRPORT_PEK) in the knowledge base; "Business Class" matches "Business Class" (entity ID: CLASS_BUSINESS) under the "Cabin Class Type" category.

[0214] The semantic distance between keywords and entity names in the knowledge base can be calculated based on word vector similarity (such as Word2Vec); combined with rule matching (such as “City 1” → “PEK” airport code mapping).

[0215] In this step, the civil aviation professional knowledge base is used to transform users' colloquial keywords into structured entities (such as "flying" → "flight"); and to ensure that entity naming is consistent (such as "City 2" always being mapped to "City 2 Airport").

[0216] Q412, Sort the specified entity set according to the semantic matching degree, and determine the top k specified entities with the highest matching degree as the replacement entities corresponding to QW, so as to obtain the replacement entity list QD corresponding to the target user ID.

[0217] Candidate entities are sorted by semantic matching score, and the top k (e.g., k=3) are selected as replacement entities. For example: "City 1 First International Airport" (match score 0.95); "City 1 Second International Airport" (match score 0.90); "City 1 Third Airport" (match score 0.85).

[0218] The most relevant entities are prioritized by sorting, for example, when a user searches for "departure from city 1", the main airport is matched first; multiple alternative entities are retained to provide rich data for subsequent fusion (such as considering both PEK and PKX airports at the same time).

[0219] Q413: Obtain the attribute value of each attribute corresponding to each entity in QD to generate a knowledge graph branch containing substitute entities, and integrate the attribute values ​​of each branch through a weighted fusion method to finally form the knowledge graph corresponding to the target user ID.

[0220] Create independent graph branches for each alternative entity, for example: Branch 1: User → Airport of Interest → City 1 First International Airport; Branch 2: User → Airport of Interest → City 1 Second International Airport.

[0221] The attribute values ​​of each branch are weighted and aggregated. For example, the airport on-time rate: PEK (85%) weight 0.6, PKX (90%) weight 0.4 → final on-time rate = 85%×0.6+90%×0.4=87%.

[0222] By using multi-branch fusion, the insufficient information of a single entity can be compensated for (such as referring to flight information from multiple airports at the same time); when there are multiple possible entities, weighted fusion can reduce the impact of incorrect matching and improve the reliability of the graph.

[0223] Furthermore, after step Q400 and before step Q500, the method may further include the following steps:

[0224] Q420, if 1 < n < NUM1, then generate n-1 nodes of the same type connected to QW by unweighted undirected edges; where NUM1 is the first preset number.

[0225] Furthermore, the value of NUM1 ranges from 5 to 10.

[0226] When a template node corresponds to multiple entities (1 < n < NUM1, e.g., NUM1 = 5), the system automatically generates n-1 nodes of the same type. For example, if the airport node in the template corresponds to 3 entities (City 1, City 2, City 3), then 2 additional airport nodes will be generated, forming the node group {Airport 1, Airport 2, Airport 3}.

[0227] This step avoids information overload caused by a single node carrying too many entities. For example, multiple airports can be displayed as independent nodes to improve the readability of the graph. By dynamically expanding nodes, it can adapt to the diverse entity associations of different users (such as new users who may associate with more airports).

[0228] Q421, associate each entity in QA with QW and n-1 nodes of the same type connected to QW by unweighted undirected edges in sequence.

[0229] In this embodiment, nodes of the same type are associated by unweighted undirected edges to avoid information bias caused by node priority, such as giving equal importance to multiple frequent flyer airports; the structured entity-node mapping supports fast retrieval.

[0230] Q422: Add each attribute and attribute value corresponding to each entity in QA to the initial attribute list of the corresponding node to obtain the knowledge graph corresponding to the target user ID.

[0231] Fill the attribute values ​​of each entity into the initial attribute set of the corresponding node. For example:

[0232] Airport 1 attributes: Name = City 1 First International Airport, IATA = PEK, On-time performance = 85%;

[0233] Airport 2 attributes: Name = City 2 Second International Airport, IATA = SHA, On-time rate = 90%.

[0234] Ensure that the attributes of each entity are stored independently (e.g., the on-time rates of different airports are not mixed up); improve the granularity of analysis and support more fine-grained comparative analysis (e.g., comparing the on-time rates of multiple airports associated with a user).

[0235] When a user associates a moderate number of entities, the graph clarity is maintained through node expansion; valuable information (such as multiple minor airports associated with a user) is avoided due to the limitation of the number of entities, thus improving data utilization; independent nodes support differential analysis (such as comparing a user's preferences for different airports), providing richer dimensions for personalized recommendations.

[0236] Furthermore, after step Q400 and before step Q500, the method may further include the following steps:

[0237] Q430, if n≥NUM1, then the similarity between any two entities in QA is determined based on the attribute overlap, historical co-occurrence frequency and time decay factor, so as to obtain the entity similarity matrix QJ corresponding to QA.

[0238] In this embodiment, when a template node corresponds to a large number of entities (n≥NUM1, e.g., NUM1=5), the system calculates the entity similarity matrix QJ. The similarity is determined by the following factors:

[0239] Attribute overlap: such as two flight entities sharing the same aircraft type and departure time attributes.

[0240] Historical co-occurrence frequency: For example, "CAXXXX" and "MUXXXX" are often subscribed to by the same user.

[0241] Time decay factor: Entities that co-occur recently have higher similarity (e.g., the time decay factor is 1 for co-occurrence within 30 days, and 0.5 for co-occurrence beyond 180 days). The similarity between entities is determined by a weighted summation.

[0242] By calculating similarity, complex entity relationships are simplified into matrix form, reducing the complexity of subsequent processing; the time decay factor makes the graph pay more attention to recent user behavior (such as the shift in flight preferences caused by seasonal changes).

[0243] Furthermore, step Q430 may include the following steps:

[0244] Q41. For any two entities QE1 and QE2 in QA, obtain the attribute overlap θ1 between QE1 and QE2; where θ1 = NM1 / NM2; NM1 is the number of attributes that QE1 and QE2 have in common, and NM2 is the sum of the number of attributes of QE1 and QE2.

[0245] Q42, obtain the historical co-occurrence frequency θ2 between QE1 and QE2; where θ2 = NM3 / (NM(QE1) × NM(QE2)) 1 / 2 NM3 represents the number of times QE1 and QE2 appear together in historical tasks, NM(QE1) represents the number of times QE1 appears alone in historical tasks, and NM(QE2) represents the number of times QE2 appears alone in historical tasks.

[0246] Q43, obtain the time decay factor θ3 corresponding to QE1 and QE2; where θ3 = α -λ×（t1-t2） Where α is a preset constant, λ is a preset attenuation coefficient based on the task type, t1 is the current time, and t2 is the time of the most recent co-occurrence of QE1 and QE2.

[0247] Q44. Based on θ1, θ2 and θ3, determine the similarity between QE1 and QE2, QS(QE1, QE2) = ω1×θ1+ω2×θ2×θ3; where ω1 is the weight of attribute overlap, ω2 is the weight of the product of historical co-occurrence frequency and time decay factor; ω1+ω2=1.

[0248] By calculating multi-dimensional similarity, the accuracy of entity clustering can be improved. For example, in the civil aviation scenario, different flights on the same route can be accurately clustered, providing a more refined user profile for the recommendation system. Redundant storage and processing of similar entities can be reduced. For example, 10 domestic flights frequently booked by a user can be clustered into 2 clusters, reducing the cost of graph construction. The temporal dynamics of user behavior can be captured, making the graph more in line with the user's current preferences. For example, when a user temporarily changes their travel destination, the entity similarity ranking can be quickly adjusted.

[0249] Q431, perform hierarchical clustering based on QJ, and divide entities with similarity greater than the first preset similarity threshold into the same cluster to obtain the entity cluster set QH.

[0250] Hierarchical clustering is performed based on the similarity matrix QJ, grouping entities with similarity greater than a threshold (e.g., 0.7) into the same cluster. For example:

[0251] Cluster 1: International flights departing from City 1 (CAXXXX, MUXXXX);

[0252] Cluster 2: Domestic flights departing from City 2 (FMXXXX, MUXXX1).

[0253] Agglomerative clustering can be used (starting with each entity forming a separate cluster and gradually merging them); the threshold can be dynamically adjusted to control the number of clusters (e.g., the final number of clusters does not exceed 3).

[0254] Aggregate similar entities to form logically clear entity clusters (such as grouping by route or cabin class); reduce the number of graph nodes, for example, compress 20 flights associated with a user into 3 clusters to improve visualization efficiency.

[0255] Q432, for each entity cluster in QH, the entity with the highest comprehensive weight is determined as the representative entity of the corresponding entity cluster; whereby the comprehensive weight is determined based on the entity's attribute completeness and most recent active time.

[0256] Select representative entities for each entity cluster, taking into account the following:

[0257] Attribute completeness: Flight entities with more fields (such as aircraft type, on-time rate) will be given priority.

[0258] Active time: For example, booking records within the last 30 days are weighted higher than earlier records.

[0259] Overall weight formula: Overall weight = Attribute completeness × (1 + Time decay factor).

[0260] This step ensures that the cluster representative entities can reflect the commonalities within the cluster to the greatest extent possible (e.g., using "CAXXXX" to represent the "City 1-City 2 Business Class" cluster); it also prioritizes recently active entities to avoid recommendation bias caused by old data.

[0261] Q433: Obtain the attribute value of each attribute corresponding to each representative entity to generate the knowledge graph corresponding to the target user ID.

[0262] Construct a knowledge graph using representative entities for each cluster, for example: Node: User → Booking → Cluster 1 Representative (CAXXXX); Edge attribute: label the number of entities within the cluster (e.g., "Contains 5 flights").

[0263] Transforming large sets of entities into a small number of representative nodes maintains graph readability (e.g., clearer display on mobile devices). Analysis efficiency is improved; cluster-based analysis (e.g., calculating the average ticket price for the "international flight cluster") is more than 10 times faster than traversing all entities.

[0264] Furthermore, the relationship between the two entities includes: unauthorized and undirected relationship, authorized and directed relationship, and unauthorized and directed relationship.

[0265] Q500 adds the attribute value of each attribute in SA1 to the initial attribute set corresponding to QW.

[0266] Fill the initial attribute set of the template node with the attribute values ​​of the entity (e.g., Zhang San's membership level = Platinum Card). For example, the membership level attribute of the traveler node changes from null to "Platinum Card".

[0267] Transform abstract templates into knowledge graphs for specific users; for example, transform the "flight recommendation" template into a "Zhang San's flight recommendation" graph.

[0268] Attribute consistency: Ensure that all nodes of the same type have the same attribute structure, which facilitates subsequent unified analysis (such as batch comparison of membership levels of different users).

[0269] Q600 determines the relationship between any two entities corresponding to any two nodes based on a preset relational database, generates corresponding relational edges, and obtains the knowledge graph corresponding to the target user ID; the preset relational database includes several relationships between two entities.

[0270] Establish relationships between entities based on a pre-defined relational database. For example:

[0271] Zhang San (passenger) → Booking → CAXXXX (flight);

[0272] CAXXXX (flight) → Departure from → City 1 Capital Airport (airport);

[0273] By using predefined relationships (such as booking and departure time), the graph is endowed with business semantics, supporting complex queries (such as "query all flights departing from city 1 booked by Zhang San"); the establishment of relationship edges supports the reasoning of new conclusions (such as reasoning "Zhang San may need to reschedule" based on "Zhang San booked CAXXXX" and "CAXXXX delayed").

[0274] By using predefined templates, the knowledge graph construction time is reduced from hours to seconds using traditional methods; it ensures both the uniformity (standardization) of the graph structure for the same task type and the personalization of content based on user historical data (e.g., different flight recommendation graphs for different users); the separation of the template library and the relational library means that changes to business rules (e.g., adding a "carbon emission" attribute) only require modifying the template, without having to refactor the entire system.

[0275] In this embodiment, within the civil aviation business scenario, firstly, based on different target task types, suitable templates are retrieved from a pre-set knowledge graph template library. This operation ensures that the basic architecture of the knowledge graph aligns with the specific needs of civil aviation business. Next, by analyzing historical task information associated with the target user ID, the entities and attribute values ​​corresponding to the knowledge graph nodes are accurately determined. For example, based on historical data such as the user's past flight bookings, route preferences, and cabin class selections, the specific characteristics of the user in civil aviation business are clarified. The knowledge graph generated through these steps is no longer generalized content but a customized graph deeply tailored to the personalized needs of civil aviation users. With the help of this customized knowledge graph, the civil aviation business recommendation system can more accurately capture user preferences. Whether it's ticket recommendations, route planning, or promotion of additional services, it can achieve a high degree of matching with user needs, effectively improving the efficiency and accuracy of civil aviation business recommendations.

[0276] Example 4:

[0277] After generating the knowledge graph corresponding to the target user ID using the methods in Examples 2 and 3, if the target task is destination prediction, the target user type can be distinguished first, and then accurate task prediction can be performed based on the user type. Specifically, the steps are as follows:

[0278] H100 retrieves information on each historical travel task corresponding to the target user ID; each historical travel task information includes at least the start time of the corresponding travel task.

[0279] The system retrieves the target user's historical travel records. Each record includes the start time of the trip (e.g., 2024-01-15, 08:30), end time, departure point, and destination. For example, user Zhang San's history might include "City 1 → City 2, January 15, 2024" or "City 2 → City 3, February 20, 2024".

[0280] H200 treats each historical travel task as a node and connects each node sequentially according to the order of the travel task execution time to obtain the travel task knowledge graph HA corresponding to the target user ID; each node of HA includes the start time, end time, departure point and destination of the corresponding travel task.

[0281] Each travel task is abstracted as a node and connected in chronological order to form a directed graph. For example: Node 1 (City 1 → City 2, 2024-01-15) → Node 2 (City 2 → City 3, 2024-02-20) → Node 3 (City 3 → City 1, 2024-03-10).

[0282] It can intuitively display the user's travel trajectory chain, such as identifying the business travel pattern of "City 1 → City 2 → City 3"; through the node connection relationship, it can explore the cyclical path (such as traveling between two cities every week).

[0283] H300 extracts the feature vector from HA to obtain the historical travel task feature vector HX corresponding to HA.

[0284] Furthermore, step H300 may include the following steps:

[0285] H310, based on HA, determine the structural complexity HD1 and the regularity of the target user's travel HD2 corresponding to HA; HD1 is obtained based on the number of nodes corresponding to each node type in HA, and HD2 is obtained based on the start time corresponding to each node in HA.

[0286] Furthermore, HD1 is obtained through the following steps:

[0287] H311, retrieve the number of nodes corresponding to each type of node in HA, to obtain the node count list NA = (NA1, NA2, ..., NA311). a , ..., NA b ), a=1,2,…,b;NA a Let b be the number of nodes corresponding to the a-th type of node in HA, and b be the number of node types corresponding to HA.

[0288] In this embodiment, node types include origin, destination, start time, etc. This step quantifies the distribution of different types of nodes, providing raw data for subsequent complexity calculations and facilitating the assessment of the diversity of the graph structure.

[0289] H312, based on NA, determine the proportion corresponding to each type of node to obtain the node proportion list HP = (HP1, HP2, ..., HP...). a HP b ); HP a for NA aCorresponding node ratio; HP a =NA a / ∑ b a=1 NA a .

[0290] Converting absolute quantities into relative proportions eliminates the impact of the total number of nodes on complexity calculations, making graphs of different sizes comparable.

[0291] H313, based on NA, determine HD1 = -∑ b a=1 HP a ×log2HP a .

[0292] HD1 is calculated using the information entropy formula. The larger the entropy value, the more uniform the distribution of node types and the more complex the graph structure. Quantifying the complexity of the graph structure by information entropy can be used to determine the diversity of user travel scenarios (such as whether multiple origin / destination types are involved).

[0293] Furthermore, HD2 is obtained through the following steps:

[0294] H314 retrieves the start time for each node in the HA.

[0295] Extract the start time of each travel task node and arrange them in chronological order.

[0296] H315 retrieves the time interval between two adjacent start times.

[0297] H316 discretizes the time interval to obtain the frequency distribution.

[0298] Divide the time interval into multiple intervals (e.g., group by hour, day, week) and count the frequency of occurrence of intervals within each interval; convert continuous values ​​into discrete distributions to simplify the data structure and facilitate the analysis of patterns through statistical methods (e.g., whether high-frequency time intervals correspond to periodic travel).

[0299] H317, based on the frequency distribution, yields HD2.

[0300] HD2 can be measured by the concentration of frequency distribution (such as peak frequency or entropy). For example, if most time intervals are concentrated in a certain range (such as traveling at 8 am every day), then HD2 is high, indicating a clear travel pattern.

[0301] This step quantifies the regularity of users' travel times, providing key indicators for determining whether users are long-term (regular) or short-term (irregular) users.

[0302] H320, if HD1≥HD1' and HD2<HD2', then the first feature extraction method is used to extract the feature vector of HA to obtain HX; where HD1' is a preset structural complexity threshold and HD2' is a preset regularity threshold.

[0303] Furthermore, the step of extracting feature vectors from HA using the first feature extraction method includes the following steps:

[0304] H321 transforms HA into a heterogeneous graph structure to obtain the heterogeneous travel task knowledge graph HB corresponding to HA; where the node types of HB include origin, destination and start time, and the edge types include time sequence relationship and the association relationship between origin and destination.

[0305] The nodes of HA are clearly divided into three categories: origin, destination, and start time. The edge types are defined as temporal relationships (such as t1→t2) and location relationships (such as origin→destination), generating a heterogeneous travel task knowledge graph HB.

[0306] Heterogeneous graphs can explicitly represent the semantic relationships between different types of nodes and edges, which makes it easier for subsequent neural networks to capture multi-dimensional relationships (such as the cross-influence of location and time).

[0307] H322 uses a graph attention neural network to encode HB and learns the importance weights of different types of nodes and edges through a multi-head attention mechanism to generate node embedding vectors.

[0308] By employing a multi-head attention mechanism, the model learns the importance weights of different types of nodes and edges, generating node embedding vectors that contain semantic and structural information.

[0309] Graph Attention Neural Networks (GAT) can adaptively focus on key nodes (such as frequently visited locations) and edges (such as frequent time intervals), improving the targeting and efficiency of feature extraction.

[0310] H323 concatenates all node embedding vectors in chronological order and calculates the context weight of each node through a self-attention mechanism to obtain the historical travel task feature vector HX.

[0311] All node embedding vectors are concatenated in chronological order, and the context weight of each node in the sequence is calculated through a self-attention mechanism to generate the final feature vector HX.

[0312] By combining time sequence and contextual relationships, the temporal dependencies of travel tasks (such as the impact of a previous trip on a subsequent trip) can be captured, enabling HX to more comprehensively represent travel patterns.

[0313] H330, if HD1 < HD1' and HD2 ≥ HD2', then the second feature extraction method is used to extract the feature vector of HA to obtain HX.

[0314] Furthermore, the step of using the second feature extraction method to extract feature vectors from HA includes the following steps:

[0315] H331 periodically encodes the time information of each node in HA to generate a time feature vector.

[0316] The start time is converted into a periodic feature (such as the hour of a day or the number of days in a week), and a time feature vector is generated by encoding with a sine / cosine function to capture the periodicity of time (such as weekday / weekend patterns).

[0317] Explicitly encoding the periodicity of time is suitable for scenarios where travel time has a fixed pattern (such as commuters).

[0318] H332 performs geographic semantic encoding on the origin and destination in HA, extracting semantic features of location type and latitude-longitude relationship.

[0319] Extract the location type (e.g., residential area, commercial area) and latitude and longitude relationship, and convert the geographic information into vectors through semantic embedding (e.g., Word2Vec) to capture the semantic association of the location (e.g., the commuting relationship between residential area and company).

[0320] By combining geographic semantic information, the model can understand the functional relationships between locations, rather than relying solely on the original coordinates, thus improving the semantic expressive power of features.

[0321] H333 performs tensor fusion of temporal feature vectors, semantic feature vectors, and node structural feature vectors, and maps them to historical travel task feature vectors HX through a multilayer perceptron.

[0322] The temporal feature vector, semantic feature vector, and node structural features (such as node degree) are fused using tensors and mapped to a unified feature vector HX through a multilayer perceptron (MLP).

[0323] By integrating temporal patterns, geographic semantics, and structural information, it provides more accurate feature representations for maps with high regularity but simple structure (such as fixed-route commuting).

[0324] H340, if HD1≥HD1' and HD2≥HD2', then use the first feature extraction method and the second feature extraction method to extract the feature vector of HA to obtain HX.

[0325] Furthermore, step H340 includes the following steps:

[0326] H341, use the first feature extraction method to extract the feature vector of HA, and obtain the first intermediate feature vector HX1.

[0327] H342, the second feature extraction method is used to extract the feature vector of HA, and the first intermediate feature vector HX2 is obtained.

[0328] HX1 (focusing on structure and heterogeneous graph relationships) and HX2 (focusing on time and semantic patterns) are generated using the methods of H320 and H330, respectively. By leveraging the advantages of both methods, complex structures and regular patterns can be processed simultaneously, avoiding the limitations of a single method.

[0329] H343, fuse HX1 and HX2 to obtain HX=δ1×HX1+δ2×HX2; where δ1 and δ2 are the weights corresponding to the first feature extraction method and the second feature extraction method, respectively; δ1+δ2=1.

[0330] In this embodiment, the weights can be dynamically adjusted according to the characteristics of the graph; for example, δ1 is larger when the structure is complex.

[0331] By adaptively balancing the effects of structural complexity and temporal regularity, HX can simultaneously characterize diverse scenarios and periodic patterns, thereby improving the robustness of subsequent predictions.

[0332] By quantifying the map characteristics using HD1 and HD2, feature extraction methods are dynamically selected to adapt to different users' travel patterns (such as regular commuters vs. random travelers). Heterogeneous graphs and GAT capture the structural relationships within the map, while geographic semantic encoding and temporal periodic encoding enhance semantic understanding and improve feature expressiveness. Multiple feature extraction methods are dynamically fused based on map complexity and regularity to ensure that HX can comprehensively represent user travel behavior and provide more accurate input for destination prediction.

[0333] H400 inputs HX into a preset user type classification model to determine whether the user corresponding to the target user ID is a long-term user or a short-term user; where long-term users are users whose travel behavior forms a periodic pattern, and short-term users are users whose travel behavior does not form a periodic pattern.

[0334] In this embodiment, the preset user type classification model is a trained model that can accurately distinguish between long-term users and short-term users; long-term users have stable travel intervals (such as traveling at fixed times every week / month) and a high repetition rate of destinations; short-term users have random travel times and dispersed destinations (such as tourists).

[0335] Different prediction algorithms are used for different user types (e.g., long-term users rely on cyclical patterns, while short-term users rely on real-time preferences); this avoids overfitting historical data for short-term users and improves prediction efficiency.

[0336] H500: If the user corresponding to the target user ID is a long-term user, then the time period corresponding to the earliest start time and the latest start time in the historical travel tasks corresponding to the target user ID is determined as the target time period.

[0337] For long-term users, the target time period is the interval between the earliest and latest travel times. For example, if a user regularly travels between city 1 and city 2 on the 15th of each month for the past 12 months, the target time period would be from January 15, 2024 to December 15, 2024.

[0338] The forecast range is determined directly based on historical cycles, simplifying calculations (e.g., forecasting the destination as city 2 on the 15th of next month); stability is guaranteed by reducing the interference of short-term fluctuations on the forecast (e.g., a single trip that is temporarily canceled does not affect the overall cycle).

[0339] H600: If the user corresponding to the target user ID is a short-term user, then the target time period corresponding to the target user ID is determined according to HA.

[0340] For short-term users, the target time period is dynamically determined based on HA. For example, based on the most recent trip (e.g., a user just traveled from city 1 to city 2, predicting their return trip within the next 7 days); combined with external events (e.g., during an international conference in city 2, extending the forecast window).

[0341] Furthermore, step H600 includes the following steps:

[0342] H610 calculates the temporal distribution density of nodes in HA and generates the probability density function f(t) on the time axis by estimating the kernel density; t is time.

[0343] Kernel Density Estimation (KDE) is a nonparametric statistical method that smoothly estimates the probability density of temporal data by placing a kernel function (such as a Gaussian kernel) at each time point and then summing the results with weights. Specifically, for the start time of each node in the High Availability (HA), KDE calculates the density value at each point on the time axis based on preset bandwidth parameters, ultimately generating a continuous probability density function f(t). This function reflects the probability distribution of user trips at different time points; areas with higher density indicate more concentrated travel.

[0344] This step smooths the raw time data, eliminates the randomness of discrete time points, and highlights the true patterns of travel time clustering. It does not require assuming a prior model of time distribution (such as a normal distribution), making it more adaptable and able to capture complex time distribution features (such as multimodal distribution). It provides a continuous density distribution basis for subsequent time cluster identification, improving the accuracy of time pattern recognition.

[0345] H620 identifies peak regions in f(t) and defines continuous time periods with density values ​​higher than a preset density threshold as target density time clusters.

[0346] First, local maxima (peaks) in f(t) are detected, and these peaks correspond to time periods with high travel frequency. Then, a density threshold is set, and consecutive time periods with a density higher than the threshold are divided into a "target density time cluster". For example, if the density of f(t) is consistently higher than the threshold between 9:00-11:00 and 18:00-20:00, these two intervals will be defined as time clusters respectively.

[0347] This step automatically identifies the core time periods when users are active, eliminates scattered time points for low-frequency travel, and focuses on key travel periods; it filters noise through density thresholds to ensure that time clusters represent statistically significant travel patterns rather than random behaviors; and it provides data-driven time pattern segmentation for short-term users (without periodic patterns) to compensate for the lack of prior patterns.

[0348] H630, if the number of target density time clusters is greater than 1, then the time cluster containing the most recent HN travel tasks is selected as the candidate target time period.

[0349] When multiple time clusters exist (such as two clusters: morning rush hour and evening rush hour on weekdays), the time cluster containing the most recent HN trips is selected first. HN is a preset parameter (e.g., HN=5), indicating that only the time cluster to which the user's most recent HN trips belong is considered. For example, if the user's most recent 5 trips are concentrated in the evening rush hour time cluster, then that cluster becomes a candidate.

[0350] Short-term users' travel behavior may change over time (e.g., temporary job changes), and recent travel is more in line with current needs, improving the timeliness of time periods; avoid selecting irrelevant historical patterns from multiple time clusters (e.g., the user's previous commuting pattern has changed), and ensure that candidate time periods are highly relevant to current behavior; the sensitivity to recent behavior can be flexibly adjusted through the HN parameter to adapt to the needs of short-term users in different scenarios.

[0351] H640 extends the boundaries of the candidate time period by: extending forward by τ1 time units to include potential preparation phases and extending backward by τ2 time units to cover possible journey continuations.

[0352] Based on the starting point of the candidate time period, extend forward by τ1 (e.g., 30 minutes) to cover the "preparation phase" (e.g., the preparation time before the user's departure), and extend backward by τ2 (e.g., 1 hour) to cover the "trip continuation phase" (e.g., the activity time after arriving at the destination). For example, if the candidate time period is 18:00-20:00, τ1=30 minutes, and τ2=1 hour, then the extended time period is 17:30-21:00.

[0353] To overcome the limitation of the original time period only including "departure time", the time period is made more complete by taking into account the context time (preparation, continuation) related to travel; the time relevance of the subsequent knowledge graph HZ is improved. For example, the expanded time period may include more pre- or post-travel related tasks, which enhances the basis for prediction; τ1 and τ2 can be dynamically adjusted according to historical data (e.g., τ1=15 minutes in commuting scenarios, τ1=2 hours in tourism scenarios), which improves adaptability in different scenarios.

[0354] H650: If the extended time period includes the current time point, then the extended time period is determined as the target time period; otherwise, the future time period closest to the current time is selected as the target time period.

[0355] First, determine if the extended time period includes the current time (e.g., if the current time is 18:15 and the extended time period is 17:30-21:00, then it includes the current time). If it does, then it is directly used as the target time period. If it does not include the current time (e.g., if the extended time period is 9:00-11:00 and the current time is 16:00), then select the future time period that is closest to the current time (e.g., 9:00-11:00 the next day).

[0356] Ensure the real-time relevance between the target time period and the current time, focus on travel predictions that are "about to happen," and avoid focusing on expired historical time periods; for situations where the current time period is not covered, prioritize the nearest future time period to ensure the forward-looking nature and practicality of the prediction, which is in line with the "instant travel" characteristics of short-term users; dynamically adapt to the real-time needs of users, for example, when a user plans to travel temporarily, the system can quickly locate the nearest potential travel time period to improve prediction efficiency.

[0357] The above steps, through the process of "density estimation → peak identification → recent filtering → boundary expansion → real-time matching," dynamically determine the target time period for short-term users. This method is based on data-driven rather than preset rules, adapting to travel patterns without periodicity; it combines time density and recent behavior to balance historical patterns and real-time needs; and the boundary expansion and real-time matching mechanisms enhance the completeness of the time period and the timeliness of prediction, ultimately providing a precise time range for the construction of the knowledge graph HZ and improving the accuracy of destination prediction.

[0358] H700 retrieves several different types of historical task information corresponding to the target user ID within the target time period to generate a knowledge graph HZ corresponding to the target user ID.

[0359] In this embodiment, after obtaining the target time period corresponding to the target user ID, it is possible to obtain several different types of historical task information corresponding to the target user within the target time period. Then, the knowledge graph generation method in Embodiment 2 is used to generate the knowledge graph HZ corresponding to the target user ID.

[0360] H800 predicts the destination corresponding to the target user ID based on HZ.

[0361] In this embodiment, it should be noted that those skilled in the art can use existing knowledge graph-based destination prediction methods to predict the destination corresponding to the target user ID based on HZ, which will not be elaborated here.

[0362] In this embodiment, a user travel task knowledge graph is first constructed to systematically integrate users' historical travel information, transforming complex travel data into structured knowledge. Based on this, feature vectors are extracted and user types are classified to accurately identify long-term and short-term users. Target time period determination strategies are formulated for different user types, and then multi-type historical task information within the target time period is integrated to generate a new knowledge graph, fully exploring users' potential travel patterns. Compared to traditional solutions, this method effectively solves the prediction challenges of insufficient short-term user data and difficulty in feature extraction in the civil aviation field, while also considering the pattern mining of long-term users, significantly improving the accuracy and timeliness of destination prediction for different user types.

[0363] Example 5:

[0364] Based on the methods in Embodiments 2 and 3 above, after generating the knowledge graph corresponding to the target user ID, the following steps are provided for more accurate prediction:

[0365] G100 retrieves the initial knowledge graph GZ of the target task corresponding to the target user ID; where GZ includes several nodes associated with the target task corresponding to the target user ID, each node corresponds to an entity, and each entity includes the corresponding start time.

[0366] In this embodiment, the initial knowledge graph corresponding to the target user can be generated using the methods described in Embodiments 2 and 3, which will not be elaborated here.

[0367] G200, if the start time of each entity in GZ is before the current time, then the feature vector corresponding to GZ is input into the specified task prediction model to obtain the specified task corresponding to GZ; wherein, the specified task and the target task are related; the specified task includes the corresponding start time, and the start time of the specified task is after the current time.

[0368] In this embodiment, if the start time of each entity in GZ is before the current time, it means that GZ does not contain future task information. In this case, the feature vector corresponding to GZ is input into the specified task prediction model to obtain the specified task corresponding to GZ. The specified task can be destination prediction, and the target task can be hotel prediction.

[0369] Identify time patterns in users' historical tasks and filter out completed tasks as the basis for prediction; mine the correlation between historical tasks and future tasks through prediction models to supplement possible subsequent task scenarios for users; inject task prediction results of the future time dimension into the knowledge graph and expand the time coverage of the graph.

[0370] Furthermore, the feature vector corresponding to GZ is obtained through the following steps:

[0371] G210 uses a pre-defined Transformer network to extract the text modal features corresponding to GZ, so as to obtain the text modal feature vector GX1 corresponding to GZ.

[0372] The Transformer network is used to encode the textual descriptions of entities in GZ (such as task names and entity attribute text). For example, the text "City 1 → City 2 Business Class Flight" is input into the Transformer, and the semantic association between "Business Class" and "City 1 City 2" is captured through the self-attention mechanism to generate a feature vector GX1 containing contextual semantics.

[0373] G220 uses a pre-defined relation-aware graph convolutional network to extract the structural modal features corresponding to GZ, so as to obtain the structural modal feature vector GX2 corresponding to GZ.

[0374] A relation-aware graph convolutional network (RGCN) is used to encode the graph structure of GZ. For example, in the flight mission graph, the nodes are "passenger", "flight" and "airport", and the edges are "booking" and "departure". RGCN aggregates the neighbor node information through multiple convolutions, and at the same time considers the relationship type of the edges (such as assigning different weights to different relationships) to generate structural modality features GX2.

[0375] RGCN can capture the topological relationships between nodes in the graph (such as the triple structure of "passenger-flight-airport"), avoiding the loss of structural information in traditional methods; by weighting the relationship type (such as "booking" relationship having a higher weight than "query"), the feature vectors are made to better fit the business logic, thus improving the accuracy of graph reasoning.

[0376] G230 encodes and extracts features from the start time corresponding to each time node in GZ to obtain the time modality feature vector GX3 corresponding to GZ; where GX1, GX2 and GX3 have the same dimension.

[0377] The start time of the time node (e.g., "2024-10-01 08:30") is converted into a computable vector, and sine and cosine position encoding or time interval features (e.g., number of hours from the current time, whether it is a working day) are used. Time features are extracted through fully connected layers or CNNs to ensure that GX3 has the same dimensions as GX1 and GX2 (e.g., all are 768 dimensions).

[0378] Encoded time features can reflect periodicity (such as traveling every Monday) or timeliness (such as recent tasks having higher weight), giving the feature vectors semantics with a time dimension; a unified dimension design facilitates subsequent fusion, for example, time features can be directly used in tensor operations with text and structural features.

[0379] Furthermore, the GX3 is obtained through the following steps:

[0380] G231 deconstructs the original time information corresponding to each node of GZ into five dimensions of features: absolute timestamp, relative time interval, periodicity, time window mark, and historical time pattern; among them, the relative time interval is obtained through logarithmic transformation.

[0381] In this embodiment, the absolute timestamp records the precise UTC time at which the task begins (e.g., 2024-10-01T08:30:00Z), preserving the original time scale.

[0382] Relative time interval (logarithmic transformation): Calculate the time difference between the current task and the most recent historical task (e.g., 72 hours), and compress large interval differences by using a logarithmic transformation log2(Δt+1). For example, 72 hours → log2(73)≈6.19, 144 hours → log2(145)≈7.18, transforming the linear growth of the interval difference from 72 to 144 hours into a non-linear growth from 6.19 to 7.18, highlighting the sensitivity of short intervals.

[0383] Periodic features: Extract the cyclical components of time, such as: Day of the week: Encode "Monday" as a unique hot vector [0,1,0,0,0,0,0] or a sine / cosine vector [sin(2π×1 / 7),cos(2π×1 / 7)]; Hour segment: Map "08:30" to the cosine code of the 8th hour cos(2π×8 / 24).

[0384] Time window marking: Time windows are divided according to civil aviation business, such as: early morning flights: 06:00-09:00 → marked as 1, others as 0; red-eye flights: 23:00-05:00 → marked as 1, others as 0.

[0385] Historical time pattern: Identify patterns through users' historical travel data. For example, if a user travels on the 1st of every month for the past 6 months, the code is [1,0,0] (representing the "fixed monthly" pattern); if a user often travels on weekday morning flights, the code is [0,1,0] (representing the "weekday morning flight" pattern).

[0386] G232 converts UTC time to the airport's local time zone and introduces a winter / spring / summer / autumn flight season date conversion feature.

[0387] Convert UTC time to local time based on the airport's IATA code (e.g., PEK corresponds to UTC+8). For example, UTC time 2024-10-01T00:30:00Z is converted to local time 2024-10-01T08:30:00+08:00 for city 1.

[0388] Winter / Spring flight season: from the last Sunday of October to the last Saturday of March of the following year; Summer / Autumn flight season: from the last Sunday of March to the last Saturday of October of each year; generate binary features [1,0] (winter / spring) or [0,1] (summer / autumn), and calculate the number of days remaining until the flight season transition (e.g., 30 days until the transition from winter / spring to summer / autumn → encoded as 0.3).

[0389] Passengers typically make decisions based on local time (e.g., "departure from city 1 at 8:00 AM" rather than UTC time). Time zone conversion makes time features more aligned with user perception, improving recommendation accuracy and avoiding time feature misalignment caused by time zone differences (e.g., misclassifying city 4 at 8:00 AM as city 1 at 8:00 AM).

[0390] Flight season changes affect flight schedule adjustments (e.g., the departure time of CAXXXX changes from 08:30 to 09:00 during the winter / spring season). Flight season features allow the model to automatically adapt to timetable changes; the number of days until the change can predict users' sensitivity to "end-of-season special offers".

[0391] G233 concatenates the features of five dimensions and maps them to a 64-dimensional space through a trainable matrix to obtain GX3.

[0392] The five-dimensional features are concatenated sequentially into a long vector, for example:

[0393] [Absolute timestamp (8 bytes) + logarithmic interval (4 bytes) + periodic feature (14 bytes) + time window (4 bytes) + historical pattern (3 bytes)] → 33 bytes; the concatenated vector is mapped to a 64-dimensional space through the parameter matrix W∈R^(33×64), with the formula: GX3=ReLU(W×concatenated vector+b); where ReLU is the activation function, b is the bias term, and the matrix parameters are optimized through training with historical civil aviation data.

[0394] The original 33-dimensional features are mapped to 64 dimensions (slightly increasing the dimensionality). Important feature combinations are automatically learned through trainable matrices. For example, the weight of the association between "early morning flight marker" and "Monday periodic feature" is increased to highlight the "Monday early morning flight" pattern. The computational load is reduced after dimensionality reduction, while retaining more than 90% of the time feature information, which is suitable for real-time recommendation scenarios in civil aviation.

[0395] The trainable matrix dynamically adjusts its weights based on civil aviation data. For example, during the Spring Festival travel rush, the associated weights of "absolute timestamp" and "historical pattern" are automatically increased to capture the time patterns of returning home for the Spring Festival. The 64-dimensional unified dimension facilitates direct fusion with text (GX1) and structural (GX2) features, improving tensor computation efficiency.

[0396] G240 is used to fuse GX1, GX2 and GX3 to obtain GZ; among them, GX3 is used to dynamically adjust the weights when merging GX1 and GX2.

[0397] Furthermore, step G240 includes the following steps:

[0398] G241, Get the gate value z t =σ(W z •[GX1;GX2;GX3]); where σ() is the Sigmoid activation function, with an output value range of [0,1]; W z t represents the first trainable weight matrix; t represents time.

[0399] In this embodiment, z t ∈[0,1] represents the degree of openness of the "update gate", W z Training and optimization based on historical civil aviation data.

[0400] When the time feature GX3 displays "User has recently frequently searched for international flights", z t Automatically increase the weights of textual features GX1 (such as the keyword "New York flight") and structural features GX2 (such as the association between "users and international flights"); during off-peak periods (such as late at night), z t Automatically lowering the noise level reduces interference from noise information in the fusion process, allowing the model to focus more on core features (such as historical booking records).

[0401] Abnormal scenario adaptation: When GX3 detects that the "flight season transition date is approaching", z t It will dynamically balance the weights of each modality, for example, by increasing the proportion of "route adjustment" information in the structural feature GX2, thereby improving the ability to predict changes in flight schedules.

[0402] G242, according to z t We get GZ = (1-z) t )⊙h prev +z t⊙tanh(W) h •[GX1;GX2;GX3]), where W h h is the second trainable weight matrix. prev This represents the fusion feature from the previous time step; ⊙ indicates element-wise multiplication.

[0403] In this embodiment, ⊙ represents element-wise multiplication, and h prev Initialize it as a zero vector, and update it in subsequent iterations.

[0404] In continuous prediction scenarios (such as users querying flights multiple times), h prev Preserve historical fusion features, for example, when a user first queries "City 1-City 2", h prev Record this information; when querying "City 2 - City 3" later, the model will use h prev By recognizing the continuity of users' travel itineraries, the accuracy of recommending connecting flights has been greatly improved.

[0405] When a user temporarily changes their search intent (e.g., from "Business Class" to "Economy Class"), the time modality feature GX3 drives z. t Rapid changes enable the fusion feature GZ to quickly adapt to new requirements and reduce response latency.

[0406] During the Spring Festival travel rush, the weights of historical booking records (structural feature GX2) and current search popularity (textual feature GX1) are dynamically adjusted over time: Initial stage (30 days in advance): z t Focus on GX2 (historical Spring Festival travel rush pattern); closer to departure (3 days in advance): z t Focus on GX1 (real-time keyword search).

[0407] G300 adds the specified task corresponding to GZ as a virtual node to GZ to generate the target knowledge graph GZ' corresponding to GZ.

[0408] The predicted specified tasks are added as virtual nodes to GZ to generate a target knowledge graph GZ' containing historical tasks and predicted tasks.

[0409] Virtual nodes supplement future task information, upgrading the knowledge graph from "pure historical data" to a hybrid structure of "history + prediction"; enhancing the integrity of the graph and providing more comprehensive feature inputs for subsequent predictions (integrating historical patterns and predictive trends); and connecting historical and future tasks through virtual nodes, making it easier to capture the temporal dependencies between tasks.

[0410] G400 inputs the feature vector corresponding to GZ' into the preset target task prediction model to obtain the prediction result corresponding to the target task.

[0411] In this embodiment, the feature vector corresponding to GZ' can be obtained through the method in Embodiment 3; by combining historical task features (GZ) and prediction task features (virtual nodes), the accuracy and robustness of the prediction model are improved; the structured information of the knowledge graph is used to capture the semantic associations and time series patterns between entities; the target task model is optimized for specific prediction scenarios to ensure that the results meet the actual needs of users.

[0412] G500 recommends the prediction results corresponding to the target task to the user corresponding to the target user ID.

[0413] The method in this embodiment effectively solves the problem of inaccurate prediction results caused by the lack of future journey nodes in the user knowledge graph in the prior art. By obtaining the initial knowledge graph of the target task corresponding to the target user ID, when it is found that the start time of all entities in the graph is before the current time, the specified task prediction model is used to predict the specified task associated with the target task and whose start time is after the current time, and it is added as a virtual node to the initial knowledge graph, thereby constructing a target knowledge graph containing future task information. This approach makes up for the deficiency of missing future journey information in the original knowledge graph, providing a more comprehensive and accurate data foundation for subsequent predictions; inputting the feature vector of the supplemented target knowledge graph into the preset target task prediction model can more accurately capture the user's potential needs and significantly improve the accuracy of the target task prediction results.

[0414] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0415] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0416] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0417] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0418] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0419] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0420] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0421] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0422] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0423] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0424] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0425] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0426] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0427] The electronic device can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the electronic device can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0428] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0429] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0430] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for generating a civil aviation domain knowledge graph based on a cache mechanism, characterized in that, The method comprises the following steps: R100, obtaining a target task corresponding to a target user ID and a preset historical knowledge graph library; wherein the historical knowledge graph library is cached in a preset cache area, the historical knowledge graph library comprises a plurality of historical knowledge graphs, and each historical knowledge graph corresponds to a historical task and a historical user ID; R200, obtain the knowledge graph corresponding to each historical user ID same as the target user ID in the historical knowledge graph library to obtain a set of historical knowledge graphs corresponding to the target user ID RA= (RA1, RA2, …, RA c , …, RA d ), c=1, 2, …, d; RA c is the cth historical knowledge graph corresponding to the target user ID, and d is the number of historical knowledge graphs corresponding to the target user ID; R300, obtaining the maximum similarity RX of the target task and each historical knowledge graph in the RA corresponding to the historical task max ; R400, if RX max > RY, then RX max The corresponding historical knowledge graph is determined as the initial knowledge graph of the target task corresponding to the target user ID; and RY is a preset task similarity threshold. R500, generating a target knowledge graph corresponding to the target user ID according to a plurality of task information of the target user ID in a target time period and an initial knowledge graph; the start time of the target time period is the latest time corresponding to the initial knowledge graph, and the end time is the current time; R600, adjusting the cache survival time length of the knowledge graph corresponding to the historical task of the same type as the target task in the historical knowledge graph library according to the execution frequency, execution time and execution quality of each historical task of the same type as the target task; The historical knowledge graph library is generated by a user knowledge graph generation system, and the system comprises a processor, a knowledge graph generation module, an entity library, a relationship library, an information query rule library, a plurality of task ports and a plurality of information query ports; wherein the entity library comprises a plurality of preset entities, the relationship library comprises the relationship between entities, and the information query rule library comprises a plurality of information query rules, each information query rule corresponding to a task; the processor is used to execute the following steps: S100, obtaining a knowledge graph generation instruction sent by a task port; the knowledge graph generation instruction comprises a target user ID and a target task; S200, determining a target information query rule corresponding to the target task from the information query rule library according to the target task; S300, obtaining target information corresponding to the target user ID from the target task information query port according to the target information query rule; wherein the target information comprises a plurality of historical task information corresponding to the target user ID and related to the target task; S400, sending the target information to the knowledge graph generation module; S500, determining a plurality of entities corresponding to each historical task information from the entity library according to each historical task information, to obtain a plurality of entities corresponding to the target user ID and related to the target task; S600, determining the relationship between a plurality of entities corresponding to the target user ID according to the relationship library; S700, generating a knowledge graph corresponding to the target user ID according to a plurality of entities corresponding to the target user ID and the relationship between the entities, and adding the generated knowledge graph to the historical knowledge graph library.

2. The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 1, characterized in that, Step R300 comprises the following steps: R310, the target task is acquired and the RA c a task type similarity RX of the corresponding historical task c，1 , a parameter similarity RX c，2 and a time similarity RX c，3 ; R320, according to RX c，1 , RX c，2 and RX c，3 , determine the similarity RX c between the target task and the historical task corresponding to RA c = μ1× RX c，1 + μ2× RX c，2 + μ3× RX c，3 , to obtain the task similarity list RX c = (RX1, RX2, …, RX d ); wherein μ1, μ2 and μ3 are respectively preset task type similarity weight, parameter similarity weight and time similarity weight; R330, determines RX according to RX max = MAX(RX); where MAX() is a preset maximum function. 3.The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 2, characterized in that, RX c，1 By the following steps: R311, obtaining a preset tree structure corresponding to a plurality of tasks; wherein the tree structure comprises a root node, a child node and a task node; each root node is connected to a plurality of child nodes through an edge, and each child node is connected to a plurality of task nodes through an edge; the root node corresponds to a task scene, the child node corresponds to a task type, and the task node corresponds to a specific task; R312, according to the tree structure, determine the node corresponding to the target task and RA c The shortest path RL between the nodes of the corresponding historical tasks c ; R313, according to RL c , determine RX c，1 = 1 / (1 + RL c ).

4. The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 2, characterized in that, RX c，2 By the following steps: R314, a plurality of preset parameters corresponding to the target task and RA c vectorizing a plurality of parameters of the corresponding historical task to obtain a parameter vector RV1 and RA corresponding to the target task c a parameter vector RV2 of the corresponding historical task; Wherein, the dimensions of RV1 and RV2 are the same; R315, determine the cosine similarity between RV1 and RV2 as RX c，2 . 5.The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 2, characterized in that, RX c，3 By the following steps: R316, the predicted execution time RT of the target task is acquired new and RA c the execution time RT of the corresponding historical task old ; R317, according to RT now and RT old , determine RX c，3 = exp(-ε x RT new - RT old ); wherein ε is a preset attenuation factor. 6.The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 1, characterized in that, Step R600 comprises the following steps: R610, acquire the latest execution time RT corresponding to the execution time of the historical task of the same target task type last ; R620, according to RT last and current time RT now , get normalized execution time interval RT norm = -2x(RT now - RT last ) / YT max +1; wherein YT max is a preset maximum time interval R630, obtaining an average execution quality RU corresponding to the historical task of the same type as the target task; 0≤RU≤1; R640, normalizing RU to obtain normalized execution quality RQ norm = 2 x RU - 1; R650, acquire an execution frequency RF corresponding to a historical task of the same type as the target task type; R660, normalizing RF to obtain normalized execution frequency QF norm = 2 x RF / RF max - 1; wherein, RF max is a preset maximum execution frequency; R670, according to RT norm , RQ norm , and QF norm , the current cache survival time length TTL of the knowledge graph corresponding to the historical task of the same type of target task type in the historical knowledge graph library is adjusted to the target cache time length TTL old = TTL new = TTL old ×exp(τ1×RT norm +τ2×RQ norm +τ3×QF norm ); wherein τ1 is a preset execution time interval weight, τ2 is a preset execution quality weight, and τ3 is a preset execution frequency weight; τ1+τ2+τ3=1.

7. The civil aviation domain knowledge graph generation method based on a cache mechanism according to claim 1, characterized in that, Step R500 includes the following steps: R510, according to a plurality of task information of the target user ID in a target time period, obtain a plurality of entities corresponding to the target user ID and a plurality of attributes corresponding to each entity; R520, add the plurality of entities corresponding to the target user ID and the plurality of attributes corresponding to each entity to the initial knowledge graph to obtain a target knowledge graph corresponding to the target user ID. 8.A non-transitory computer readable storage medium having stored therein at least one instruction or at least one piece of program, characterized in that, The at least one instruction or the at least one program is loaded and executed by the processor to implement the civil aviation field knowledge graph generation method based on the cache mechanism as claimed in any one of claims 1-7.

9. An electronic device, comprising: The non-transitory computer readable storage medium includes a processor and the non-transitory computer readable storage medium of claim 8.

Images