Cross-system AI log gateway intercommunication method and system

Abstract

The invention discloses a cross-system AI log gateway intercommunication method and system, and the method comprises the steps: mapping an operation type into a natural language through an improved input text construction method, splicing the natural language with a page visual text, carrying out the processing through a Sension-BERT semantic vectorization engine, generating a semantic vector capable of deeply representing the operation intention of a user, and carrying out the processing through a semantic vector, and a normalized dynamic value evaluation system is constructed. According to the method, the semantic fault limitation caused by the fact that a traditional log system depends on keyword matching is broken through, logs from different heterogeneous systems can be accurately compared and associated in a unified semantic space, and data recommendation sorting and intelligent collaboration based on multiple platforms are achieved. The invention further improves the hierarchical storage method of logs, and realizes data security and privacy protection through verification and decryption.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of artificial intelligence and data governance, and more specifically, to a method and system for cross-system AI log gateway interoperability. Background Technology

[0002] As enterprises deepen their digital transformation, various business systems (such as OA, CRM, and ERP) have widely integrated AI functional modules (such as intelligent summarization, automatic question answering, and text translation). When users interact with these AI assistants on web pages, massive amounts of operation logs containing user behavioral intentions are generated. If these logs can be effectively integrated and analyzed, user preferences can be accurately characterized, providing key data support for the personalized and intelligent upgrade of AI services.

[0003] However, in current technological practices, this valuable AI log data generally exists in the form of "data silos." This fragmented and heterogeneous state makes it difficult for enterprises to build a unified user AI behavior profile, and the AI ​​agents of various systems are unable to perceive and utilize users' historical operating patterns in other systems, ultimately resulting in a fragmented and discontinuous intelligent service experience.

[0004] To address the data silo problem, existing technologies mostly employ centralized log management solutions. For example, solutions exemplified by the ELK technology stack collect scattered logs into a central search engine by deploying a collection agent, achieving physical centralization of logs and keyword-based full-text retrieval. Related patents also disclose methods for log aggregation through standardized configurations or automated tools. While these solutions have achieved success in centralized log storage and retrieval, their core capabilities remain limited to keyword matching and cannot understand the semantic information behind the logs.

[0005] For scenarios requiring in-depth mining of the semantic value of AI logs to achieve intelligent agent collaboration, existing technologies suffer from two major limitations: First, a lack of semantic-level interoperability. Existing solutions cannot link semantically related but distinctly worded operations such as "summarizing a report" and "formulating a plan" across different systems, making it difficult to achieve cross-system log aggregation based on user intent. Second, a lack of a fine-grained value assessment system. Existing solutions typically treat all logs equally, failing to differentiate their value based on log sensitivity, user role, operation frequency, or other dimensions, and failing to implement differentiated storage and retrieval strategies based on value. This results in low resource utilization efficiency, with high-value logs not being prioritized for retrieval. Summary of the Invention

[0006] This invention overcomes the shortcomings of existing technologies in cross-system data flow and provides a cross-system AI log gateway interoperability method and system, which is expected to solve the problems existing in the prior art.

[0007] To address the aforementioned technical problems, this invention provides a method for cross-system AI log gateway interoperability:

[0008] A method for cross-system AI log gateway interoperability includes the following steps:

[0009] Front-end log collection and standardization: Collect user operation information and generate standardized AI operation logs;

[0010] Log semantic parsing and weight calculation: representing the meaning of log operations and evaluating the value of logs;

[0011] Store logs and evaluation results;

[0012] Retrieval and weighted sorting: Perform queries based on user actions and sort the results according to their weights;

[0013] Optimize workflows based on sorting results.

[0014] A further technical solution is that the log semantic parsing and weight calculation includes the following steps:

[0015] Semantic vectorization: Mapping log content enumeration values ​​to natural language descriptions, constructing complete semantic text, and generating semantic vectors;

[0016] Dynamic weight calculation, based on multi-dimensional quantification, enables an objective assessment of the value of logs.

[0017] A further technical solution is that the multi-dimensional quantization specifically includes the following steps:

[0018] The dynamic weight allocator is invoked to calculate the weight value W of the log based on the formula W = A × S_sens + B × F_freq + C × P_perm;

[0019] Where A, B, and C are weighting coefficients;

[0020] S_sens is the sensitivity weight;

[0021] F_freq is the frequency weight;

[0022] P_perm determines the permission weights for roles and identities.

[0023] A further technical solution is that the storage of logs includes the following steps:

[0024] Routing and Sharding: Calculate the hash value based on the user_id in the log to determine which distributed storage node the log should be routed to;

[0025] Determine the tiered storage location: Based on the calculated weight W, execute the logical tiered storage strategy: If W is greater than the set weight, it is determined to be a high-value log and stored in the high-speed storage engine; otherwise, it is stored in the low-cost storage engine.

[0026] A further technical solution involves performing the following steps after determining the tiered storage location:

[0027] Determine whether the log source is a preset sensitive system;

[0028] If so, the privacy computing engine is triggered to de-identify sensitive fields such as raw_context in the logs.

[0029] A further technical solution is that the process of querying user operations and sorting the results according to weights specifically includes the following steps;

[0030] Vectorized retrieval: The query request is vectorized. In the log gateway, the corresponding storage shard is located based on the user_id, and the top-K historical logs that best match the query vector are retrieved using a similarity algorithm.

[0031] Weighted sorting: The query engine re-weights and sorts the K results based on the weight W of each log entry, so that high-weight key operation logs are ranked first.

[0032] A further technical solution involves performing the following steps before vectorized retrieval:

[0033] Permission verification and query parsing: The privacy computing engine first verifies the permission tags of the requesting system, and determines whether the requesting party has the right to access sensitive system details based on the permission verification results;

[0034] If so, proceed with the subsequent search steps;

[0035] If not, subsequent queries will be limited to the behavior pattern vector and will not return the specific log content.

[0036] A further technical solution involves performing the following steps after weighted sorting:

[0037] Behavioral heatmaps are generated, and the weighted and sorted results are aggregated and analyzed to calculate high-frequency cross-system operation sequences. Finally, behavioral heatmap vectors are output.

[0038] In another aspect, the present invention also provides a cross-system AI log gateway interoperability system.

[0039] A cross-system AI log gateway interoperability system includes: a front-end embedding layer, a log processing layer, a gateway middleware layer, and a query aggregation layer;

[0040] The front-end embedding layer is used to capture data from the current page block and generate standardized AI operation logs that conform to unified specifications.

[0041] The log processing layer, connected to the front-end embedding layer, is used to perform semantic parsing and vectorized compression on the original logs.

[0042] The gateway middleware layer includes: a distributed user sharding gateway, used for physical sharding based on user_id hash value, and for determining the logical hierarchical storage location based on the log weight W;

[0043] The query aggregation layer is used to provide a federated query interface and behavior heatmap generation service.

[0044] A further technical solution is that the gateway middleware layer includes: a privacy computing engine;

[0045] The privacy computing engine is used for permission verification and initiates homomorphic encryption and desensitization processing on sensitive log data from various enterprise information systems to ensure that cross-system queries meet the requirements.

[0046] Compared with the prior art, the present invention has at least the following beneficial effects:

[0047] The core of this invention lies in its improved input text construction method, which maps operation types to natural language and concatenates them with the visible text on the page. This is then processed by the Sentence-BERT semantic vectorization engine to generate semantic vectors that deeply represent the user's operational intent. This design overcomes the semantic fragmentation limitations caused by traditional log systems relying on keyword matching, enabling accurate comparison and correlation of logs from different heterogeneous systems within a unified semantic space. This lays a solid foundation for subsequent in-depth analysis and intelligent collaboration.

[0048] Secondly, a normalized dynamic value assessment system was constructed. By introducing a dynamic weight allocator with a multi-dimensional quantification model, each log entry was comprehensively evaluated based on its sensitivity, operation frequency, and user permissions. The improved weight calculation formula (such as the logarithmic decay and saturation constraint model used for operation frequency weight) ensured that the weight value range remained stable within the [0,1] interval, effectively suppressing the interference of invalid high-frequency operations on the overall assessment. This achieved refined and normalized management of log data value, providing a scientific and reliable basis for the hierarchical storage of logs and the weighted ranking of retrieval results.

[0049] Ultimately, secure and compliant cross-domain data flow was achieved. The system's embedded privacy computing engine parses the querying system tags through the permission verification module and dynamically implements a tiered de-identification strategy accordingly. For requesters without access to sensitive systems, only abstract behavioral pattern vectors are returned without disclosing any specific log content; simultaneously, highly sensitive data such as medical and financial data are subject to mandatory Paillier homomorphic encryption. This mechanism ensures the utilization of data value while strictly adhering to data privacy regulations such as GDPR, constructing a secure defense for cross-system data flow. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the method steps in Embodiment 1 of the present invention;

[0051] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the present invention; Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0053] Example 1

[0054] A method for cross-system AI log gateway interoperability is provided in the appendix. Figure 1 This includes the following steps:

[0055] S1: Front-end log collection and standardization: Collect user operation information and generate standardized AI operation logs;

[0056] For example, step S1 involves a user clicking a pre-defined AI Agent trigger button (such as "Summarize To-Do Items" or "Translate News Content") on a page of any enterprise web system (such as OA or CRM). The front-end embedding layer then responds to this event, capturing the DOM structure, visible text content, and block location information (such as XPath / CSS selectors) of the target page block via the browser API. Subsequently, this information is combined with fields such as user_id, action_type, and timestamp to generate a standardized AI operation log conforming to the Schema specification in Table 1.

[0057] The following examples illustrate this point:

[0058] At 10:00 AM, Sales Manager Zhang San clicked the AI ​​"Summary" button next to "Quarterly Sales Report" on the to-do list page of the OA system. The front-end embedded layer immediately captured the DOM structure of this to-do item, extracted the text content "Q3 Sales Report: Revenue increased by 15% year-over-year...", and combined it with its location information to generate the following standardized log, described in JSON:

[0059] {

[0060] "user_id": "SALE_zhangsan",

[0061] "action_type": "SUMMARY",

[0062] "raw_context": "Q3 Sales Report: Revenue increased by 15% year-over-year...",

[0063] "timestamp": 1724032800000,

[0064] "context_metadata": {

[0065] "xpath": " / / div[@id='todo-list'] / div[3]",

[0066] "text_content": "Q3 Sales Report: Revenue increased by 15% year-over-year..."

[0067] }

[0068] }

[0069] S2: Log semantic parsing and weight calculation: characterize the meaning of log operations and evaluate the value of logs;

[0070] The log semantic parsing and weight calculation include the following steps:

[0071] S21: Semantic Vectorization: Mapping log content enumeration values ​​to natural language descriptions, constructing complete semantic text, and generating semantic vectors;

[0072] For example, step S21 involves mapping the `action_type` enumeration value in the log to a natural language description (e.g., `SUMMARY` maps to "perform document summarization operation"), and concatenating it with the visual text content extracted from `context_metadata` and the DOM to construct a complete semantic text. This text is then input into a pre-trained Sentence-BERT model to generate a 768-dimensional floating-point semantic vector that accurately represents the semantic meaning of the operation.

[0073] S22: Dynamic weight calculation, based on multi-dimensional quantification, to achieve an objective assessment of the value of logs.

[0074] The multi-dimensional quantification specifically includes the following steps:

[0075] The dynamic weight allocator is invoked to calculate the weight value W of the log based on the formula W = A × S_sens + B × F_freq + C × P_perm;

[0076] Wherein, A, B, and C are weighting coefficients. In this embodiment, A is 0.6, B is 0.3, and C is 0.1.

[0077] S_sens is the sensitivity weight;

[0078] F_freq is the frequency weight;

[0079] P_perm determines the permission weights for roles and identities.

[0080] The case processing steps are as follows:

[0081] The semantic vectorization engine maps action_type: "SUMMARY" to "document summarization operation" and concatenates it with the original text to form the input text: "Document summarization operation: Q3 Sales Report: Revenue increased by 15% year-over-year...". This text is processed by the Sentence-BERT model to generate a 768-dimensional semantic vector V1.

[0082] Next, dynamic weight allocation is performed. The dynamic weight allocator starts calculations synchronously:

[0083] S_sens: The log contains high-risk words such as "Report" and "Revenue" twice, so S_sens = 1 - exp(-0.8 * 2) ≈ 0.8.

[0084] F_freq: It was detected that Zhang San triggered AI operations 3 times in the past minute, so F_freq = min(1.0,log10(3 + 1)) ≈ 0.6.

[0085] P_perm: Zhang San's role is "Department Head", with a default coefficient of 0.8.

[0086] Ultimately, the log weight W = 0.6*0.8 + 0.3*0.6 + 0.1*0.8 = 0.74.

[0087] S3: Store logs and evaluation results;

[0088] The stored log includes the following steps:

[0089] S31: Routing and Sharding: Calculate the hash value based on the user_id in the log to determine which distributed storage node the log should be routed to;

[0090] S32: Determine the tiered storage location: Based on the calculated weight W, execute the logical tiered storage strategy: If W is greater than the set weight, it is determined to be a high-value log and stored in the high-speed storage engine; otherwise, it is stored in the low-cost storage engine.

[0091] In this embodiment, the weight is set to 0.7;

[0092] S33: Determine whether the log source is a preset sensitive system;

[0093] If so, the privacy computing engine is triggered to de-identify sensitive fields such as raw_context in the logs.

[0094] For example, sensitive fields involving sensitive systems such as healthcare and finance can be desensitized using the Paillier homomorphic encryption algorithm.

[0095] The case processing steps are as follows:

[0096] First, the user data is sharded. Based on the hash value of user_id: "SALE_zhangsan", the data is determined to be stored on the physical node Node_05.

[0097] Next, tiered storage is implemented. Because the weight W=0.74 > 0.7, this log is judged as a high-value log and stored in the Redis in-memory database on Node_05.

[0098] Then, privacy processing is performed. In this example, the logs do not contain extremely sensitive information; the privacy computing engine only performs standard access control marking and does not enable strong encryption.

[0099] S4: Retrieval and Weighted Sorting: Performs queries based on user actions and sorts the results according to their weights;

[0100] The process of querying user operations and sorting the results according to weights specifically includes the following steps;

[0101] S41: Permission Verification and Query Parsing: The privacy computing engine first verifies the permission tags of the requesting system, and determines whether the requesting party has the right to access sensitive system details based on the permission verification results;

[0102] If so, proceed with the subsequent search steps;

[0103] If not, subsequent queries will be limited to the behavior pattern vector and will not return the specific log content.

[0104] S42: Vectorized retrieval: The query request is vectorized. In the log gateway, the corresponding storage shard is located based on the user_id, and the similarity algorithm is used to retrieve the Top-K historical logs that best match the query vector.

[0105] In this embodiment, the cosine similarity algorithm is used to retrieve the Top-K historical logs that best match the query vector.

[0106] S43: Weighted sorting: The query engine re-weights and sorts the K results based on the weight W of each log entry, so that high-weight key operation logs are placed at the top.

[0107] In a preferred embodiment, it further includes:

[0108] S44: Generate behavioral heatmaps, perform aggregate analysis on the weighted sorted results, calculate high-frequency cross-system operation sequences, and finally output behavioral heatmap vectors.

[0109] For example, the steps are as follows: perform aggregation analysis on the weighted sorted results to calculate high-frequency cross-system operation sequences. Calculate the weighted trigger probability of each operation sequence using the formula P_weighted = (ΣW_i / n) × frequency, and finally output a behavior heatmap vector in the format {"pattern": "OA_SUMMARY→CRM_PLAN", "frequency": 0.82, "weight": 0.93}.

[0110] The case processing steps are as follows:

[0111] In the afternoon, the CRM system's AI assistant initiated a federated query to the query aggregation layer to request the generation of a heatmap of Zhang San's behavior.

[0112] First, perform permission verification to confirm that the CRM system has legitimate permissions to query non-sensitive data.

[0113] Then, vector recall and ranking were performed. Using Zhang San's latest operation vector in CRM as the query condition, cosine similarity was used to retrieve his historical logs on Node_05, and a total of 50 similar records were recalled.

[0114] Next comes weighted aggregation, where the system performs weighted frequency statistics on the operation sequence "OA_SUMMARY → CRM_PLAN". The two log entries in this sequence have weights of 0.74 and 0.65 respectively, with a mean of (0.74+0.65) / 2 = 0.695. Combining this with the base frequency of 0.82 calculated from time decay, the final weighted probability P_weighted = 0.695 * 0.82 ≈ 0.57.

[0115] Finally, the output is generated. The query aggregation layer generates and returns a behavior pattern vector, described in JSON as follows:

[0116] {

[0117] "pattern": "OA_SUMMARY→CRM_PLAN",

[0118] "frequency": 0.82,

[0119] "weighted_score": 0.57,

[0120] "confidence": 0.95

[0121] }

[0122] S5: Optimize workflow based on sorting results.

[0123] For example, the query aggregation layer pushes the behavior heatmap vector generated in step S44 to the AI ​​Agent that initiated the query or is associated with it.

[0124] For example, when an OA system's agent receives a user's frequent behavior of "summarizing tasks and then entering the CRM to create a plan," it can proactively preload relevant data from the CRM system or optimize its own workflow prompts. This enables proactive data push across systems and collaborative optimization of intelligent agents, thereby improving user experience and work efficiency.

[0125] The case processing steps are as follows:

[0126] After analyzing the vector, the CRM system's AI assistant identified Zhang San's high-frequency and efficient work pattern of "first summarizing the OA report, then formulating a CRM plan." Subsequently, when it detects that Zhang San has completed a report summary in the OA system, the CRM assistant can proactively preload relevant customer data, enabling cross-system intelligent agent collaboration and improving user experience and work efficiency.

[0127] Example 2

[0128] A cross-system AI log gateway interoperability system, see appendix. Figure 2 It includes: front-end embedding layer, log processing layer, gateway middleware layer and query aggregation layer;

[0129] The front-end embedding layer is used to capture data from the current page block and generate standardized AI operation logs that conform to unified specifications.

[0130] The log processing layer, connected to the front-end embedding layer, is used to perform semantic parsing and vectorized compression on the original logs.

[0131] The gateway middleware layer includes:

[0132] Privacy computing engine; used for permission verification, and initiates homomorphic encryption and desensitization processing on sensitive log data from various enterprise information systems to ensure that cross-system queries meet requirements.

[0133] A distributed user sharding gateway is used to perform physical sharding based on the user_id hash value and determine the logical hierarchical storage location based on the log weight W.

[0134] The query aggregation layer is used to provide a federated query interface and behavior heatmap generation service.

[0135] Although the invention has been described herein with reference to illustrative embodiments, it should be understood that many other modifications and implementations can be devised by those skilled in the art, which will fall within the scope and spirit of the principles disclosed herein. More specifically, various variations and modifications can be made to the components and / or layout of the subject matter combination within the scope of this disclosure. Besides variations and modifications to the components and / or layout, other uses will be apparent to those skilled in the art.

Claims

1. A method for cross-system AI log gateway interoperability, characterized in that, Includes the following steps: Front-end log collection and standardization: Collect user operation information and generate standardized AI operation logs; Log semantic parsing and weight calculation: representing the meaning of log operations and evaluating the value of logs; Store logs and evaluation results; Retrieval and weighted sorting: Perform queries based on user actions and sort the results according to their weights; Optimize workflows based on sorting results.

2. The method for cross-system AI log gateway interoperability as described in claim 1, characterized in that, The log semantic parsing and weight calculation include the following steps: Semantic vectorization: Mapping log content enumeration values ​​to natural language descriptions, constructing complete semantic text, and generating semantic vectors; Dynamic weight calculation, based on multi-dimensional quantification, enables an objective assessment of the value of logs.

3. The method for cross-system AI log gateway interoperability as described in claim 2, characterized in that, The multi-dimensional quantification specifically includes the following steps: The dynamic weight allocator is invoked to calculate the weight value W of the log based on the formula W = A × S_sens + B × F_freq + C × P_perm; Where A, B, and C are weighting coefficients; S_sens is the sensitivity weight; F_freq is the frequency weight; P_perm determines the permission weights for roles and identities.

4. The cross-system AI log gateway interoperability method as described in claim 3, characterized in that, The stored log includes the following steps: Routing and Sharding: Calculate the hash value based on the user_id in the log to determine which distributed storage node the log should be routed to; Determine the tiered storage location: Based on the calculated weight W, execute the logical tiered storage strategy: If W is greater than the set weight, it is determined to be a high-value log and stored in the high-speed storage engine; otherwise, it is stored in the low-cost storage engine.

5. The cross-system AI log gateway interoperability method as described in claim 4, characterized in that, After determining the tiered storage location, perform the following steps: Determine whether the log source is a preset sensitive system; If so, the privacy computing engine is triggered to de-identify sensitive fields such as raw_context in the logs.

6. A cross-system AI log gateway interoperability method as described in any one of claims 1-5, characterized in that, The process of querying user operations and sorting the results according to weights specifically includes the following steps; Vectorized retrieval: The query request is vectorized. In the log gateway, the corresponding storage shard is located based on the user_id, and the top-K historical logs that best match the query vector are retrieved using a similarity algorithm. Weighted sorting: The query engine re-weights and sorts the K results based on the weight W of each log entry, so that high-weight key operation logs are ranked first.

7. The method for cross-system AI log gateway interoperability as described in claim 6, characterized in that, Perform the following steps before vectorized retrieval: Permission verification and query parsing: The privacy computing engine first verifies the permission tags of the requesting system, and determines whether the requesting party has the right to access sensitive system details based on the permission verification results; If so, proceed with the subsequent search steps; If not, subsequent queries will be limited to the behavior pattern vector and will not return the specific log content.

8. The method for cross-system AI log gateway interoperability as described in claim 7, characterized in that, After weighted sorting, perform the following steps: Behavioral heatmaps are generated, and the weighted and sorted results are aggregated and analyzed to calculate high-frequency cross-system operation sequences. Finally, behavioral heatmap vectors are output.

9. A cross-system AI log gateway interoperability system, characterized in that, include: Front-end embedding layer, log processing layer, gateway middleware layer, and query aggregation layer; The front-end embedding layer is used to capture data from the current page block and generate standardized AI operation logs that conform to unified specifications. The log processing layer, connected to the front-end embedding layer, is used to perform semantic parsing and vectorized compression on the original logs. The gateway middleware layer includes: a distributed user sharding gateway, used for physical sharding based on user_id hash value, and for determining the logical hierarchical storage location based on the log weight W; The query aggregation layer is used to provide a federated query interface and behavior heatmap generation service.

10. A cross-system AI log gateway interoperability system as described in claim 9, characterized in that, The gateway middleware layer includes: a privacy computing engine; The privacy computing engine is used for permission verification and initiates homomorphic encryption and desensitization processing on sensitive log data from various enterprise information systems to ensure that cross-system queries meet the requirements.

Images