Multi-source information semantic analysis and compliance risk early warning method

Abstract

The application provides a multi-source information semantic analysis and compliance risk early warning method, which is applied to an intelligent processing device, and comprises the following steps: converting multi-source heterogeneous information data into a unified semantic representation vector through a cross-modal semantic mapping model; performing entity linking and relationship reasoning on the unified semantic representation vector based on an enterprise multi-source information knowledge graph library to generate an information semantic analysis graph; calling a multi-level compliance rule library and the information semantic analysis graph through an enterprise compliance rule reasoning engine to perform matching, mining and evaluating the severity and associated conduction path of potential compliance risk points to generate a risk conduction path graph; and generating hierarchical compliance risk early warning information according to the risk conduction path graph. The application improves the effectiveness of multi-source information semantic analysis and the rationality of compliance risk early warning compared with prior art, and is more in line with the actual needs of enterprises for fine management and control of compliance risks.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method for multi-source intelligence semantic parsing and compliance risk early warning. Background Technology

[0002] With the deepening development of the digital economy, enterprises need to continuously process heterogeneous intelligence data from multiple sources in their daily operations, including internal business documents, external industry information, social media updates, images, and audio recordings. Simultaneously, enterprises must strictly adhere to compliance regulations in multiple areas such as data security, anti-monopoly, cross-border trade, and labor relations. They must promptly identify and warn of potential compliance risks hidden within the intelligence data to avoid operational risks such as administrative penalties and brand damage caused by compliance oversights. Therefore, there is a clear and urgent need within the industry for efficient semantic analysis of multi-source intelligence and accurate compliance risk warnings.

[0003] Currently, there is a multi-source intelligence compliance risk identification scheme. This scheme processes text, image, and audio intelligence data using separate information extraction models, without uniformly representing the semantic information of different modalities of intelligence data. This scheme compares the extracted intelligence information with keywords in compliance clauses to screen out content that may have compliance risks, without establishing an analysis mechanism for the relationships between entities in the intelligence data. This scheme only judges risks based on the severity level of a single compliance clause, without considering the related entities involved in the risk points in the enterprise's business processes and the transmission and diffusion effects.

[0004] The existing solutions mentioned above fail to achieve unified semantic representation of multi-source heterogeneous intelligence data, resulting in the ineffective fusion of semantic information between different modalities of intelligence. This leads to information bias during the matching of compliance clauses, affecting the accuracy of risk identification. At the same time, due to the lack of analysis of the relationship between intelligence entities and assessment of risk transmission paths, it is impossible to accurately determine the scope of impact and diffusion trend of risk points, making it difficult to form comprehensive and targeted risk warning results. Ultimately, this results in insufficient accuracy and guidance value of compliance risk warnings, failing to meet the actual needs of enterprises for refined management of compliance risks. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method for multi-source intelligence semantic parsing and compliance risk early warning, which can at least alleviate the aforementioned technical problems.

[0006] The technical solutions provided in this application are as follows:

[0007] This application provides a method for multi-source intelligence semantic analysis and compliance risk early warning, which is applied to an intelligent processing device. The intelligent processing device stores an enterprise multi-source intelligence knowledge graph library and an enterprise compliance rule inference engine. The enterprise multi-source intelligence knowledge graph library contains multi-source intelligence entities and semantic relationships between them. The enterprise compliance rule inference engine is used to call a multi-level compliance rule library, which contains domain-specific compliance clauses and related risk transmission rules. The method includes: Step 1, converting multi-source heterogeneous intelligence data into a unified semantic representation vector through a cross-modal semantic mapping model; Step 2, performing entity linking and relationship inference on the unified semantic representation vector based on the enterprise multi-source intelligence knowledge graph library to generate an intelligence semantic analysis graph; Step 3, matching the multi-level compliance rule library with the intelligence semantic analysis graph through the enterprise compliance rule inference engine to mine and evaluate the severity and related transmission paths of potential compliance risk points to generate a risk transmission path diagram; Step 4, generating hierarchical compliance risk early warning information based on the risk transmission path diagram.

[0008] The multi-source intelligence semantic parsing and compliance risk early warning method provided in this application has the following specific technical advantages:

[0009] 1. Alleviate the problem of "inability to integrate multimodal intelligence semantics and high deviation in matching compliance clauses".

[0010] This application, through step 1, "transforming multi-source heterogeneous intelligence data into a unified semantic representation vector using a cross-modal semantic mapping model," maps previously independently processed multimodal intelligence data to the same semantic space, forming a unified representation. Compared to traditional methods of independently processing multimodal data, this operation allows the semantic information of text, images, and audio to be fused and correlated within the same dimension, reducing information gaps caused by the separation of semantics across different modalities. This, in turn, reduces semantic bias in the compliance clause matching process, improving the reliability of risk identification compared to existing solutions.

[0011] 2. Alleviate the problem of "lack of intelligence entity correlation analysis and inability to reasonably determine the scope of risk impact".

[0012] This application, through step 2, "generates an intelligence semantic analysis graph by linking entities and reasoning relationships based on the enterprise's multi-source intelligence knowledge graph database to a unified semantic representation vector," utilizes the pre-stored "multi-source intelligence entities and semantic relationships between entities" in the knowledge graph to associate the unified represented intelligence with specific entities and infer the implicit relationships between entities. Compared to the traditional keyword comparison method without association analysis, this intelligence semantic analysis graph can intuitively present the upstream and downstream entities and business relationships involved in the risk point, making the judgment of the risk impact scope more evidence-based and avoiding the limitations of existing solutions that rely solely on single pieces of information to judge the risk scope.

[0013] 3. To alleviate the problems of "failure to assess risk transmission paths, low comprehensiveness of early warnings, and low guidance value".

[0014] This application, through step 3 "matching the multi-level compliance rule base (including associated risk transmission rules) with the intelligence semantic analysis graph to generate a risk transmission path diagram," and combined with step 4 "generating tiered early warning information based on the risk transmission path diagram," not only assesses the severity of the risk itself but also analyzes the transmission path and diffusion trend of risk in entities and business processes through associated risk transmission rules. Compared to traditional risk assessment based solely on a single clause, this risk transmission path diagram can present the direction of risk diffusion and the business links that may be affected. The tiered early warning information can provide targeted guidance for risk responses at different levels, significantly improving the comprehensiveness of the early warning results and their guiding value for enterprise compliance management compared to existing solutions. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a multi-source intelligence semantic parsing and compliance risk warning method according to an embodiment of this application.

[0016] Figure 2 This is a schematic diagram of the structure of a multi-source intelligence semantic parsing and compliance risk early warning device according to an embodiment of this application. Detailed Implementation

[0017] Figure 1 This is a flowchart illustrating a multi-source intelligence semantic parsing and compliance risk warning method according to an embodiment of this application. Figure 1 As shown, a multi-source intelligence semantic parsing and compliance risk early warning method is applied to an intelligent processing device. The intelligent processing device stores an enterprise multi-source intelligence knowledge graph library and an enterprise compliance rule inference engine. The enterprise multi-source intelligence knowledge graph library contains multi-source intelligence entities and semantic relationships between them. The enterprise compliance rule inference engine is used to call a multi-level compliance rule library, which contains domain-specific compliance clauses and related risk transmission rules. The method includes: Step 1, converting multi-source heterogeneous intelligence data into a unified semantic representation vector through a cross-modal semantic mapping model; Step 2, performing entity linking and relationship inference on the unified semantic representation vector based on the enterprise multi-source intelligence knowledge graph library to generate an intelligence semantic parsing graph; Step 3, matching the multi-level compliance rule library with the intelligence semantic parsing graph through the enterprise compliance rule inference engine to mine and evaluate the severity and related transmission paths of potential compliance risk points to generate a risk transmission path diagram; Step 4, generating tiered compliance risk early warning information based on the risk transmission path diagram.

[0018] Optionally, step 1 specifically involves: performing type identification on multi-source heterogeneous intelligence data to label text-type intelligence data, image-type intelligence data, and audio-type intelligence data; and vectorizing the text-type intelligence data, image-type intelligence data, and audio-type intelligence data to unify semantic representation vectors.

[0019] Optionally, step 1 specifically includes: step 11, for text-based intelligence data, using a first language model incorporating enterprise domain word vectors for word segmentation and semantic encoding to generate text semantic vectors.

[0020] Preferably, the specific implementation process of step 11 is as follows: For text-based intelligence data (including internal enterprise contract documents, business reports, meeting minutes, as well as external industry regulatory documents, news information, social media texts related to enterprises, etc.), domain-adaptive preprocessing is first performed to remove redundant information in the text. Specifically, the original text-based intelligence data is subjected to symbol filtering to delete special symbols without actual semantic meaning (such as garbled characters, consecutive repeated punctuation marks) and format marks (such as HTML tags, document page number identifiers). At the same time, key information in the field such as enterprise name, business terms, and compliance clause numbers contained in the text is identified and retained through regular expression matching to obtain cleaned domain-based text data.

[0021] Preferably, in the specific technical implementation of step 11, when performing word segmentation on the cleaned domain text data, a word segmentation strategy integrating an enterprise-specific terminology database is adopted. The enterprise-specific terminology database includes the enterprise's organizational structure name (e.g., "Strategic Development Department," "Compliance Review Group"), core business terms (e.g., "Cross-border Data Export Filing," "Anti-Monopoly Declaration"), partner names, and industry-specific compliance terms (e.g., "Data Security Impact Assessment," "Concentration Review of Undertakings"). When the cleaned domain text data is input into the word segmentation tool, the enterprise-specific terminology database is first used to accurately match the text, ensuring that complete terms in the database are not split. Then, the remaining text is subjected to regular word segmentation to obtain a domain word segmentation sequence composed of domain-specific vocabulary and general vocabulary.

[0022] Preferably, in one scenario, step 11 is specifically implemented as follows: The process of constructing enterprise domain word vectors involves collecting internal text data (such as historical contracts and compliance review reports) from the past five years and publicly available regulatory texts from the relevant industry to form domain training corpus. A word vector training tool (such as Word2Vec) is used to train the domain training corpus, generating enterprise domain word vectors with preset dimensions. Each dimension of the enterprise domain word vector corresponds to a semantic feature in the enterprise's business scenario (e.g., dimensions 1-5 correspond to the association strength of concepts related to "data security," and dimensions 6-10 correspond to the association strength of concepts related to "anti-monopoly"). The cosine similarity between any two words in the vector reflects the closeness of the semantic association between the two words in the enterprise's business scenario.

[0023] Preferably, in the specific technical implementation of step 11, the construction of the first language model needs to incorporate the aforementioned enterprise domain word vectors. The first language model is based on a pre-trained language model (such as BERT) for domain adaptation. Specifically, the general word vectors in the original embedding layer of the pre-trained language model are replaced with enterprise domain word vectors. For general words not included in the enterprise domain word vectors, the original word vectors of the pre-trained language model are retained and fine-tuned to maintain consistency with the semantic space of the enterprise domain word vectors. At the same time, a domain attention mechanism is added to the hidden layer of the model. This mechanism enhances the model's ability to capture key domain information by calculating the association weights between the current input words and the core business labels of the enterprise (such as "cross-border trade" and "labor employment"), thus obtaining a first language model adapted to the enterprise scenario.

[0024] Preferably, in the specific implementation of step 11, the semantic encoding process of the domain segmentation sequence is as follows: the domain segmentation sequence is input into the adapted first language model. The model converts each word into a corresponding enterprise domain word vector through the embedding layer, and then strengthens the semantic weight of domain keywords through the domain attention mechanism of the hidden layer. Finally, a sequence vector containing contextual semantic information is generated through the output layer. The [CLS] position vector of this sequence vector is taken as the comprehensive semantic representation of the entire text-based intelligence data, that is, the text semantic vector. Compared with the general semantic vector, this text semantic vector is more in line with the semantic logic of enterprise business scenarios and can more accurately reflect the relationship between compliance-related information and enterprise entities involved in the text.

[0025] Optionally, step 1 specifically includes: step 12, for image-type intelligence data, extracting visual features through a convolutional neural network, and constructing a modality transformation matrix in combination with an enterprise entity tag library, so as to map the visual features to the text semantic space where the text semantic vector is located and generate an image semantic vector accordingly.

[0026] Preferably, the specific implementation process of step 12 is as follows: For image-based intelligence data (including scanned copies of contracts, photos of meeting venues, product promotional images, and images of supply chain logistics documents from within the enterprise, as well as external images related to enterprise news and industry exhibition venues), scene-based image preprocessing is first performed to eliminate the influence of interfering information on subsequent feature extraction. Specifically, Gaussian filtering is applied to the original image-based intelligence data to reduce random noise in the images; based on the common size range of enterprise image data, the denoised images are normalized to a preset size (for example, it can be set to 512×512 pixels, which can be adjusted according to the actual image data of the enterprise, the core being to ensure that the feature extraction conditions of different images are consistent); grayscale correction is performed on the normalized images to balance the brightness differences caused by different shooting light, and finally, standardized enterprise image data is obtained. This preprocessing process can avoid visual feature extraction deviations caused by image size differences, noise, and light interference, making the subsequent feature extraction results more consistent.

[0027] Preferably, in the specific technical implementation of step 12, the improved convolutional neural network design needs to be combined with the characteristics of the enterprise scene to accurately extract the enterprise-related visual features in the image. Standardized enterprise image data is input into the improved convolutional neural network. This network adds an "enterprise-specific visual feature attention module" to the traditional convolutional neural network (including input layer, convolutional layer, pooling layer, and fully connected layer). This module trains attention weights through pre-labeled key visual region samples of the enterprise (such as contract seal area, enterprise LOGO area, and document number area). During the feature extraction process, higher attention weights are assigned to areas in the image that may contain key enterprise information (such as seals in the corners of the image and LOGO in the center), and lower weights are assigned to background areas. The edge, texture, and color features of the image are extracted through the convolutional layer, the feature dimension is compressed through the pooling layer, and the key region features are strengthened through the enterprise-specific visual feature attention module. Finally, the enterprise scene visual feature vector with fixed dimension is output by the fully connected layer. Each dimension of the enterprise scene visual feature vector corresponds to a type of enterprise-related visual feature (such as dimensions 1-8 corresponding to "stamp texture features", dimensions 9-15 corresponding to "LOGO shape features", and dimensions 16-20 corresponding to "document table line features"). Compared with the general visual features extracted by traditional CNNs, its correlation with enterprise business scenarios is more prominent.

[0028] Preferably, in one scenario, when constructing the enterprise entity tag library in step 12, a direct association between the tags and the text semantic space needs to be established to provide a text semantic benchmark for modality conversion. Internal enterprise entity information is collected (including organizational structure information such as "Finance Department" and "R&D Department," product information such as "XX model equipment," partner information such as "Supplier B," and business scenario information such as "cross-border logistics documents"). Text descriptions are annotated for each type of entity information to form the enterprise entity tag library. Each enterprise entity tag corresponds to a standard text vector in the text semantic space—this standard text vector is generated by encoding the tag's text description using the first language model in step 11. For example, the text description of the "Finance Department" tag is "the department within the enterprise responsible for financial accounting and fund management." Inputting this text description into the first language model generates the text semantic space vector corresponding to the "Finance Department" tag. This method establishes a connection between the enterprise entity tag library and the text semantic space, providing a bridge for subsequent mapping of visual features to the text semantic space.

[0029] Preferably, the construction of the modality transformation matrix in step 12 needs to be based on the correlation between the enterprise scene visual feature vector and the enterprise entity tag library, clarifying the physical meaning of the matrix elements. The modality transformation matrix is ​​constructed using the number of dimensions of the enterprise scene visual feature vector as the number of rows and the number of tags in the enterprise entity tag library as the number of columns. For each element in the matrix, its value is determined by calculating the semantic correlation between the visual feature of the corresponding dimension in the enterprise scene visual feature vector and the standard text vector of the corresponding tag in the enterprise entity tag library—for example, the 3rd row of the matrix corresponds to the "stamp texture feature" dimension in the enterprise scene visual feature vector, and the 5th column corresponds to the "finance department" tag in the enterprise entity tag library. The value of the element at this position is the correlation between the "stamp texture feature" and the standard text vector of the "finance department" tag (the correlation is calculated using cosine similarity; a larger value indicates a stronger semantic correlation). The core function of this modality transformation matrix is ​​to establish a quantitative correlation between visual features and text semantics. Unlike traditional general modality transformation matrices, its elements are all calculated based on enterprise-specific entity and scene features, making it more suitable for enterprise intelligence processing needs.

[0030] Preferably, the final step in step 12, generating the image semantic vector, requires mapping visual features to the text semantic space using a modality transformation matrix. The enterprise scene visual feature vector is multiplied by the modality transformation matrix to obtain an initial mapped vector. Since the initial mapped vector may have some dimensions that deviate significantly from the text semantic space, the dimensions of the initial mapped vector need to be aligned with those of the text semantic vector in step 11 (ensuring the same number of dimensions). The initial mapped vector is then fine-tuned using a reference vector of the text semantic space (such as the reference vector in step 141) to make the adjusted vector more reasonably distributed in the text semantic space. The final vector obtained is the image semantic vector. Because this image semantic vector is generated through an enterprise-specific modality transformation matrix and is aligned with the dimensions of the text semantic space, it can be subsequently fused with the text semantic vector generated in step 11 within the same semantic space, effectively solving the problem of semantic fragmentation in traditional multimodal data.

[0031] Optionally, step 1 specifically includes: step 13, converting audio intelligence data to generate transcribed text, performing sentiment analysis on the transcribed text to obtain sentiment features, and integrating the sentiment features into a trained second language model for encoding to generate an audio semantic vector that can be mapped to the text semantic space where the text semantic vector is located.

[0032] Preferably, the specific implementation process of step 13 is as follows: For audio intelligence data (including internal enterprise meeting recordings, compliance training audio, customer service call recordings, and external enterprise-related interview audio, industry policy interpretation audio, etc.), scenario-based audio preprocessing is first performed to eliminate the impact of interfering information on subsequent transcription and analysis. Specifically: noise suppression processing is performed on the original audio intelligence data, and an adaptive noise cancellation algorithm is used to filter environmental noise (such as background noise in meeting recordings and current noise in call recordings); according to the time span of the audio content, the denoised audio is divided into audio segments of fixed duration according to semantic integrity (for example, it can be set to 10-30 seconds / segment, and this duration can be adjusted according to the semantic density of the enterprise audio data, the core is to ensure that each segment contains complete semantic units); the sampling rate of the divided audio segments is normalized (e.g., uniformly set to 16kHz sampling rate) to ensure that the input parameters of the subsequent transcription model are consistent, and finally standardized audio segments are obtained. This preprocessing process can avoid transcription bias caused by noise, sampling rate differences and semantic breaks, making the subsequent transcribed text more consistent with the original semantics of the audio.

[0033] Preferably, in the specific technical implementation of step 13, when converting standardized audio segments into transcribed text, a speech recognition model adapted to the enterprise scenario needs to be used to improve the transcription accuracy of enterprise-specific terminology. Traditional general speech recognition models have low recognition accuracy for enterprise-specific terminology (such as "cross-border data export filing," "concentration review of undertakings," and "data security impact assessment"). Therefore, it is necessary to perform enterprise-specific terminology adaptation training on the speech recognition model: collect historical audio transcription texts of enterprises and corresponding terminology annotation data (such as annotating "Data Security Law" as "Data Security Law" and "Anti-monopoly declaration" as "Anti-monopoly declaration of concentration of undertakings"). Integrate these data as training samples into the fine-tuning process of the general speech recognition model, so that the model learns the pronunciation features and contextual associations of enterprise terminology. Input the standardized audio segments into the adapted enterprise scenario speech recognition model. The model analyzes the matching degree between the acoustic features of the audio and the pronunciation features of the enterprise terminology, and outputs text content containing enterprise-specific terminology, i.e., enterprise scenario transcribed text. Compared with general transcribed text, this enterprise scenario transcribed text has better transcription accuracy for compliance-related terminology, providing a reliable text foundation for subsequent sentiment analysis and semantic encoding.

[0034] Preferably, in one scenario, when performing sentiment analysis on the transcribed text of the enterprise scenario in step 13, the focus should be on compliance-related scenarios, extracting sentiment features related to compliance risks, rather than general sentiment features. Specifically: a compliance scenario sentiment analysis corpus is constructed, which contains text samples related to enterprise compliance (such as texts of violation rectification notices and compliance review communication records), and each sample is labeled with a "compliance risk-related sentiment tag" (such as "acknowledgment of violation", "questioning of compliance clauses", "cooperation with rectification requirements", etc., rather than simply labeled "positive", "negative", or "neutral"); a sentiment analysis model is trained based on this corpus, and the output of the model is a compliance-related sentiment feature vector—the number of dimensions of this vector is consistent with the number of categories of compliance risk-related sentiment tags, and the value of each dimension represents the correlation strength between the transcribed text of the enterprise scenario and the corresponding sentiment tag (for example, the first dimension corresponds to the sentiment of "acknowledgment of violation", and the larger the value, the higher the degree to which the sentiment is reflected in the text); the transcribed text of the enterprise scenario is input into the trained compliance scenario sentiment analysis model to obtain a compliance-related sentiment feature vector containing compliance risk-related sentiment information. This compliance-related sentiment feature vector differs from the general sentiment feature vector. It is directly related to the enterprise's compliance scenario and can help capture the sentiment tendencies related to compliance risks in the subsequent semantic encoding process, thereby improving the risk correlation of the audio semantic vector.

[0035] Preferably, the second language model trained in step 13 needs to have the ability to fuse sentiment features and semantic features, and needs to be consistent with the text semantic space where the text semantic vector is located. The specific construction process is as follows: Based on the pre-trained language model (such as RoBERTa), firstly, the general word vectors of the original embedding layer of the model are replaced with the enterprise domain word vectors constructed in step 11 to ensure that the model has the ability to understand enterprise scenario semantics; a "compliance sentiment-semantic fusion layer" is added between the hidden layer and the output layer of the model. The input of this fusion layer includes two parts: one is the semantic feature vector of the enterprise scenario transcribed text after processing by the embedding layer and the hidden layer, and the other is the compliance-related sentiment feature vector; the fusion layer calculates the association weight between the semantic feature vector and the sentiment feature vector through the attention mechanism (for example, if the dimension value of "acknowledgment of violation" in the sentiment feature vector is high, then the weight of the part related to "violation" in the corresponding semantic feature is increased), and the feature fusion of the two is achieved by weighted summation; the dimension of the fused feature vector is adjusted to be consistent with the number of dimensions of the text semantic vector generated in step 11 (for example, both are set to 768 dimensions) to ensure that it can be mapped to the same text semantic space in the future, and finally the trained second language model is obtained. This second language model differs from the first language model that only processes semantics. It achieves co-encoding of sentiment and semantics by adding a fusion layer, so that the output semantic vector contains compliance-related sentiment information, which is more in line with the needs of compliance risk warning scenarios.

[0036] Preferably, the final step in step 13, generating the audio semantic vector, requires the second language model to complete the fusion encoding of sentiment and semantics, ensuring that the vector is mapped to the text semantic space. Specifically, the transcribed text of the enterprise scenario is input into the trained second language model. The model first converts the words in the text into enterprise domain word vectors through the embedding layer, and then extracts the text semantic feature vector through the hidden layer. Subsequently, the compliance-related sentiment feature vector is input into the "compliance sentiment-semantic fusion layer." The fusion layer performs weighted fusion of the semantic feature vector and the sentiment feature vector based on an attention mechanism to obtain a semantic feature vector that integrates sentiment information. The model output layer normalizes the fused semantic feature vector to ensure that its numerical range is consistent with the text semantic vector generated in step 11. The final vector is the audio semantic vector that can be mapped to the text semantic space where the text semantic vector is located. Because this audio semantic vector incorporates compliance-related sentiment features and has the same dimension and space as the text semantic vector, it can participate in the generation of the subsequent unified semantic representation vector together with the text semantic vector and image semantic vector, effectively solving the problems of ignoring sentiment information and being separated from other modal semantic spaces in traditional audio semantic processing.

[0037] Optionally, step 1 specifically includes step 14, which includes:

[0038] Step 141: Calculate the cosine similarity between the text semantic vector, image semantic vector, and audio semantic vector and the reference vector of the text semantic space, respectively.

[0039] Step 142: Calculate the semantic contribution weights of text semantic vectors, image semantic vectors, and audio semantic vectors based on cosine similarity to generate a unified semantic representation vector.

[0040] Preferably, the specific implementation process of step 141 is as follows: First, a text semantic space baseline vector that fits the enterprise compliance scenario needs to be constructed. This baseline vector needs to reflect the core semantics of enterprise compliance and provide a unified reference for subsequent similarity calculation. Specifically, a set of core terms in the field of enterprise compliance is collected (including core concepts corresponding to the multi-level compliance rule base, such as "data security compliance," "anti-monopoly review," "cross-border trade filing," and "labor employment regulations"). Each term in this core term set is used as text input to the first language model in step 11. The semantic encoding function of the first language model is used to generate a term semantic vector corresponding to each core term. The mean of all term semantic vectors is calculated, and the resulting vector is the text semantic space baseline vector. Each dimension of this text semantic space baseline vector corresponds to the semantic features of the core concepts of enterprise compliance (e.g., dimensions 1-6 correspond to the core semantics related to "data security," and dimensions 7-12 correspond to the core semantics related to "anti-monopoly"). Its semantic direction is highly correlated with the enterprise compliance scenario and is different from the baseline vector of the general text semantic space.

[0041] Preferably, in the specific technical implementation of step 141, when calculating the cosine similarity between the text semantic vector, image semantic vector, and audio semantic vector and the reference vector of the text semantic space, the physical meaning of each similarity needs to be clarified to provide a basis for subsequent weight allocation. Specifically, taking the reference vector of the text semantic space as a reference, the cosine similarity between the text semantic vector generated in step 11 and the reference vector (denoted as S1), the cosine similarity between the image semantic vector generated in step 12 and the reference vector (denoted as S2), and the cosine similarity between the audio semantic vector generated in step 13 and the reference vector (denoted as S3) are calculated respectively. Among them, the numerical range of cosine similarity is [-1, 1]. The closer the value is to 1, the higher the correlation between the semantic vector of the corresponding modality and the core semantics of enterprise compliance; the closer the value is to -1, the lower the correlation. Through this calculation process, the correlation index between each of the three modal vectors and the core semantics of compliance is obtained, namely, text semantic correlation similarity S1, image semantic correlation similarity S2, and audio semantic correlation similarity S3. These similarity results will directly serve as the core basis for calculating the semantic contribution weight in step 142.

[0042] Optionally, step 142 specifically includes: step 1421, based on the semantic contribution weights of the text semantic vector, image semantic vector, and audio semantic vector, performing a weighted summation of the text semantic vector, image semantic vector, and audio semantic vector to obtain an initial fusion vector; step 1422, by calculating the semantic deviation value between the initial fusion vector and the text semantic vector, image semantic vector, and audio semantic vector, if the semantic deviation value exceeds a preset threshold, the semantic contribution weights are readjusted and the weighted summation is performed again until the deviation value is lower than the preset threshold, and the corresponding initial fusion vector is used as a unified semantic representation vector.

[0043] Preferably, in the specific technical implementation of step 1421, when calculating the semantic contribution weight based on the three semantic association similarities obtained in step 141, a "relevance priority" weight allocation logic should be adopted to ensure that the modality vector with higher compliance relevance plays a greater role in the fusion. Specifically, the text semantic association similarity S1, image semantic association similarity S2, and audio semantic association similarity S3 are first normalized—the sum of the three similarities is calculated (Stotal = S1 + S2 + S3). If Stotal is 0, the three similarities are all set to 1 / 3 (to avoid the denominator being 0). Otherwise, the proportion of each similarity to the sum is calculated separately, i.e., text semantic contribution weight W1 = S1 / Stotal, image semantic contribution weight W2 = S2 / Stotal, and audio semantic contribution weight W3 = S3 / Stotal. The numerical range of this semantic contribution weight is [0,1], and the sum of the three weights is 1. The larger the weight, the richer the compliance-related semantics contained in the corresponding modality vector, and a higher semantic proportion should be given during fusion.

[0044] Preferably, in the specific implementation of step 1421, when weighted summing of the text semantic vector, image semantic vector, and audio semantic vector to obtain the initial fusion vector, it is necessary to ensure that the vector dimensions are aligned and the operation logic is clear. Specifically: First, confirm that the number of dimensions of the text semantic vector, image semantic vector, and audio semantic vector are consistent (all consistent with the dimension of the text semantic vector in step 11, for example, all 768 dimensions), to avoid operation errors due to dimension differences; then, calculate the weighted vectors respectively according to the method of "each modality vector × corresponding weight"—text weighted vector = text semantic vector × W1, image weighted vector = image semantic vector × W2, audio weighted vector = audio semantic vector × W3; finally, add the text weighted vector, image weighted vector, and audio weighted vector element-wise, and the resulting vector is the initial fusion vector. This initial fusion vector integrates the semantic information of the three modalities, and the information of the modalities with high compliance relevance accounts for a higher proportion. Compared with the traditional equal-weight fusion method, it contains more concentrated compliance-related semantics, providing a more accurate unified semantic foundation for subsequent risk identification.

[0045] Preferably, in the specific technical implementation of step 1422, when calculating the semantic deviation values ​​between the initial fusion vector and the text semantic vector, image semantic vector, and audio semantic vector, it is necessary to define deviation evaluation indicators that fit the enterprise scenario to avoid the fusion vector deviating from the core compliance semantics of the original modality. Specifically, the semantic deviation value is defined as "1. Cosine similarity between two vectors", that is, text semantic deviation value D1=1 (cosine similarity between the initial fusion vector and the text semantic vector), image semantic deviation value D2=1 (cosine similarity between the initial fusion vector and the image semantic vector), and audio semantic deviation value D3=1 (cosine similarity between the initial fusion vector and the audio semantic vector). The numerical range of the semantic deviation value is [0,2]. The smaller the value, the smaller the semantic difference between the initial fusion vector and the corresponding modality vector, and the better the preservation effect of the original modality semantics in the fusion process; the larger the value, the greater the semantic difference, which may lead to over-fusion and loss of key compliance semantics.

[0046] Preferably, in one scenario, when step 1422 determines whether the semantic deviation value exceeds a preset threshold and adjusts the semantic contribution weight, a reasonable threshold needs to be set based on the enterprise's historical fusion data to ensure that the adjusted fusion vector is both unified and retains key semantics. Specifically: a preset semantic deviation threshold T is set (this threshold needs to be determined based on the enterprise's historical multimodal intelligence fusion cases, for example, by analyzing the deviation range of "the fusion vector did not lose key compliance semantics" in historical cases, T is set to 0.3, and this value can be adjusted according to the strictness of the enterprise's compliance requirements); D1 is compared with T, D2 with T, and D3 with T respectively. If all three semantic deviation values ​​are less than or equal to T, it means that the initial fusion vector's retention effect on the semantics of each modality meets the requirements, and the initial fusion vector is used as the unified semantic representation vector; if any semantic deviation value (such as D2) exceeds T, it means that the semantics of the corresponding modality (image modality) is lost in the fusion. If there is significant loss, the semantic contribution weight of this modality needs to be adjusted. The weight of this modality should be appropriately increased (e.g., by 5%-10% on top of the original weight W2; the specific increase can be adjusted based on the extent to which the deviation value exceeds T). Simultaneously, the weights of other modalities should be proportionally reduced (ensuring that W1+W2+W3 remains 1 after adjustment). The weighted summation process in step 1421 should be re-executed using the adjusted weights to obtain a new initial fusion vector. The new semantic deviation value should then be recalculated, and this "calculation-judgment-adjustment" process should be repeated until all semantic deviation values ​​are below or equal to the preset threshold. At this point, the final initial fusion vector is determined as the unified semantic representation vector.

[0047] Preferably, after step 1422 is completed, the obtained unified semantic representation vector must meet two core conditions: first, it must be in the text semantic space and be able to be linked to the enterprise multi-source intelligence knowledge graph library in step 2; second, it must retain the core compliance semantics of the three modalities of text, image, and audio, and the semantic deviation must meet the standards set by the enterprise. This unified semantic representation vector effectively solves the problem of "either semantic fragmentation or over-fusion" in traditional multimodal fusion, providing a high-quality unified semantic carrier for subsequent knowledge graph-based entity linking and risk identification, ensuring that the compliance-related semantics of multi-source intelligence can be completely and accurately transmitted to subsequent processing stages.

[0048] Optionally, step 2 specifically involves: based on the unified semantic representation vector, selecting candidate multi-source intelligence entities that match the unified semantic representation vector from the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library, and performing entity linking and relationship reasoning based on the candidate multi-source intelligence entities to construct an intelligence semantic parsing graph.

[0049] Optionally, step 2 includes: step 21, calculating the cosine similarity between the unified semantic representation vector and the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library, so as to select candidate multi-source intelligence entities that match the unified semantic representation vector from the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library.

[0050] Preferably, the specific implementation process of step 21 is as follows: First, the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library need to be preprocessed to generate a domain-specific entity vector set that matches the unified semantic representation vector, ensuring the effectiveness of similarity calculation. The multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library are classified according to compliance domains (corresponding to the domain divisions of the multi-level compliance rule library, including entities in the data security domain, entities in the anti-monopoly domain, entities in the cross-border trade domain, and entities in the labor and employment domain). Each multi-source intelligence entity is associated with an entity description text (e.g., the description text of "data security domain entity - user privacy data storage node" is "server node used by the enterprise to store user ID numbers, mobile phone numbers, and other privacy data"). The entity description text of each multi-source intelligence entity is input into the first language model in step 11 for semantic encoding to generate an entity vector with the same dimension as the unified semantic representation vector (e.g., both are 768-dimensional), finally forming a domain-specific entity vector set divided by compliance domain (e.g., a subset of entity vectors in the data security domain, a subset of entity vectors in the anti-monopoly domain, etc.). This preprocessing process ensures that the multi-source intelligence entity vectors and the unified semantic representation vectors are in the same semantic space, providing a reliable foundation for subsequent similarity calculations, which is different from the situation in traditional knowledge graphs where the semantic space of entity vectors and target vectors is inconsistent.

[0051] Preferably, in the specific technical implementation of step 21, when calculating the cosine similarity between the unified semantic representation vector and the multi-source intelligence entity vectors in the domain-specific entity vector set, it is necessary to calculate the similarity calculation layer by domain to improve the targeting of the similarity calculation. Specifically, the unified semantic representation vector generated in step 14 is used as the target vector, and similarity calculation is performed with each domain subset (such as the data security domain entity vector subset) in the domain-specific entity vector set. For each multi-source intelligence entity vector in each domain subset, its cosine similarity with the unified semantic representation vector is calculated to obtain the similarity value corresponding to the entity. The multi-source intelligence entities in each domain subset and their corresponding similarity values ​​are organized into a three-dimensional correspondence table of "domain-entity-similarity". For example, in the data security domain, the similarity value of entity A is 0.82, the similarity value of entity B is 0.75, etc. By calculating the similarity value layer by compliant domain, the low efficiency problem caused by the traditional "traversing all entities to calculate similarity" is avoided. At the same time, the subsequent screening is more focused on entities related to the domain of the unified semantic representation vector, improving the domain matching degree of candidate entities.

[0052] Preferably, in a scenario, when determining the domain tendency of the unified semantic representation vector and adjusting the domain screening weights in step 21, it is necessary to strengthen the domain relevance in conjunction with the compliance scenario requirements to further improve the accuracy of candidate entities. Specifically, this involves: constructing core semantic vectors for each compliance domain (e.g., the core semantic vector for the data security domain is generated by encoding core terms such as "data storage, privacy protection, and data transmission," and the core semantic vector for the anti-monopoly domain is generated by encoding core terms such as "concentration of undertakings, market dominance, and price alliance"); calculating the cosine similarity between the unified semantic representation vector and the core semantic vectors of each domain, and determining the domain with the highest similarity as the "dominant domain" of the unified semantic representation vector (e.g., the similarity between the unified semantic representation vector and the core vector of the data security domain is 0.78, which is higher than other domains, so the dominant domain is data security); and setting screening weights for different domains—the similarity screening threshold for the dominant domain is set to a relatively low value (e.g., 0.6), and the screening threshold for non-dominant domains is set to a relatively high value (e.g., 0.75). This threshold can be adjusted based on the company's historical screening data (e.g., by analyzing the "similarity range in which dominant domain entities were correctly selected" in historical cases to determine the threshold). Setting a domain-specific threshold can prevent individual high-similarity entities in non-dominant domains from interfering with the selection of entities in the dominant domain, ensuring that candidate entities are more closely associated with the domain of the unified semantic representation vector.

[0053] Preferably, in step 21, when screening candidate multi-source intelligence entities, the results need to be screened and integrated according to domain thresholds to form the final candidate multi-source intelligence entity set. Specifically, for each domain subset in the "domain-entity-similarity" three-dimensional correspondence table, multi-source intelligence entities with similarity values ​​exceeding the corresponding screening threshold for that domain are screened (e.g., entities with similarity ≥ 0.6 are screened in the data security domain, and entities with similarity ≥ 0.75 are screened in the anti-monopoly domain); the entities screened from each domain are summarized, and duplicate entities are removed (if an entity belongs to multiple domains and meets the thresholds for all of them, the domain label with the highest similarity is retained); the summarized entities are sorted from high to low according to their similarity values, and the top-ranked entities are selected (the number can be adjusted according to the enterprise's intelligence processing efficiency requirements, for example, the top 20 are selected, the core being to retain entities with relatively high similarity), thus forming the final candidate multi-source intelligence entity set. This screening process considers both domain relevance and similarity, and the resulting candidate multi-source intelligence entity set is superior to the traditional "single threshold screening" in terms of compliance domain matching and semantic relevance, providing a more accurate entity basis for entity linking and relationship reasoning in the subsequent step 22.

[0054] Preferably, step 21 concludes by performing semantic relevance verification on the candidate multi-source intelligence entity set to ensure that each candidate entity has a compliance-related semantic association with the unified semantic representation vector, avoiding the inclusion of irrelevant entities. Specifically, for each entity in the candidate multi-source intelligence entity set, its associated semantics in the enterprise multi-source intelligence knowledge graph database are extracted; the cosine similarity between the unified semantic representation vector and the text vector of the associated semantics (generated by encoding the associated semantics through a first language model) is calculated; if the similarity is lower than a preset association threshold (e.g., 0.5), the entity is removed; finally, entities that pass the semantic relevance verification are retained to form the final candidate multi-source intelligence entity set. This verification step further filters out entities that "only have high surface similarity but no substantial compliance association," making the quality of the candidate entity set better and effectively supporting the accuracy of subsequent entity linking and relationship reasoning.

[0055] Optionally, step 2 includes: step 22, combining the entity attribute information of multi-source intelligence entities, performing entity linking and relationship reasoning through an entity attribute attention mechanism to determine the target multi-source intelligence entity from the candidate multi-source intelligence entities; step 23, constructing an intelligence semantic parsing graph containing timestamp attributes based on preset industry relationship extraction rules and semantic association relationships between multi-source intelligence entities.

[0056] Preferably, the specific implementation process of step 22 is as follows: First, the entity attribute information of the candidate multi-source intelligence entities generated in step 21 needs to be preprocessed in a structured manner to form an attribute data foundation that can be used for attention calculation. The entity attribute information of the candidate multi-source intelligence entities is divided into three categories according to the degree of compliance relevance: First, core compliance attributes (directly related to compliance risk identification, such as "data sensitivity level" and "compliance filing status" for entities in the data security field, and "market share" and "number of affiliated enterprises" for entities in the anti-monopoly field); second, business relevance attributes (related to enterprise business processes and indirectly affecting compliance judgment, such as "affiliated business department" and "business contact object"); and third, basic attributes (general management attributes, such as "entity creation time" and "storage location"). For each candidate multi-source intelligence entity, the specific values ​​of the three types of attributes mentioned above are extracted (e.g., entity A's compliance core attribute "data sensitivity level" is "high", its business-related attribute "affiliated business department" is "data center", and its basic attribute "creation time" is "2024-01-15"). The attribute values ​​are then converted into text descriptions (e.g., "high" is converted to "data sensitivity level is high, involving sensitive information such as user ID number and bank card number"). This ultimately forms a structured entity attribute table of "candidate entity - attribute type - attribute text description". This preprocessing transforms unstructured attribute information into standardized text, providing adapted input for subsequent association calculations with a unified semantic representation vector, unlike the traditional method of directly using raw attribute values ​​(e.g., "high" and "low") which results in insufficient semantic information.

[0057] Preferably, in the specific technical implementation of step 22, the entity attribute attention mechanism should be constructed with compliance scenarios as the guide, designing an attention calculation logic of "compliance priority weighting" rather than a general attention mechanism. Specifically: First, assign initial compliance priority weights to the three types of attributes in the structured entity attribute table—based on the enterprise's compliance risk management needs, the core compliance attributes have the greatest impact on risk identification, so the initial weight is set to a relatively high value (e.g., 0.8); business-related attributes are second, with an initial weight set to a medium value (e.g., 0.5); basic attributes have the least impact, with an initial weight set to a relatively low value (e.g., 0.2). The sum of the initial weights does not need to be normalized, but is only used to reflect the differences in the compliance importance of the attributes. Second, input the text descriptions of various attributes of each candidate entity into the first language model in step 11 to generate attribute semantic vectors consistent with the dimension of the unified semantic representation vector (e.g., attribute semantic vectors for "data sensitivity level is high..."). The third step is to calculate the cosine similarity between the semantic vector of each attribute and the unified semantic representation vector generated in step 14, thus obtaining the semantic relevance of the attribute (for example, the similarity between the semantic vector of the "data sensitivity level" attribute of entity A and the unified semantic representation vector is 0.85). The fourth step is to multiply the semantic relevance of the attribute by the initial weight of the corresponding attribute's compliance priority, thus obtaining the final attention weight for that attribute (for example, the final attention weight of the "data sensitivity level" attribute of entity A = 0.85 × 0.8 = 0.68). This logic allows the attention mechanism to focus more on core compliance attributes, avoiding the problem of weakening key compliance information caused by the traditional general attention mechanism's "equal treatment" of all attributes.

[0058] Preferably, in one scenario, when calculating the comprehensive attention score for each candidate multi-source intelligence entity in step 22, the attribute information and semantic association need to be fused based on the final attention weights to quantify the suitability of the candidate entity. Specifically, for each candidate multi-source intelligence entity, the final attention weights of all its attributes (such as compliance core attribute 1, compliance core attribute 2, business association attribute 1, basic attribute 1, etc.) are summed to obtain the comprehensive attention score of the candidate entity—for example, the comprehensive attention score of candidate entity A is 0.68 for compliance core attribute 1, 0.62 for compliance core attribute 2, 0.35 for business association attribute 1, and 0.12 for basic attribute 1, which is 0.68 + 0.62 + 0.35 + 0.12 = 1.77; the comprehensive attention score of candidate entity B is 1.53. The higher the comprehensive attention score, the better the compliance association between the attribute information and the unified semantic representation vector of the candidate entity, and the more it meets the needs of subsequent entity linking and relationship reasoning. This scoring process integrates scattered attribute attention weights into a single quantitative indicator, providing a clear basis for subsequent screening of target entities.

[0059] Preferably, when screening target multi-source intelligence entities in step 22, the entities should be sorted based on their comprehensive attention scores, and semantic consistency verification should be used to ensure the reliability of the screening results. Specifically: First, all candidate multi-source intelligence entities are sorted from high to low according to their comprehensive attention scores, and the candidate entity ranked first is taken as the initial target entity (e.g., candidate entity A with a comprehensive score of 1.77). Second, if there are first-ranked entities with the same comprehensive attention score (e.g., entity A and entity B both score 1.77), the similarity value between the two entities in step 21 (cosine similarity with the unified semantic representation vector) is used, and the entity with the higher similarity value is taken as the initial target entity to avoid selection ambiguity caused by tied scores. The third step involves semantic consistency verification of the initial target entities. This involves calculating the cosine similarity between the entity vector of the initial target entity (the domain-specific entity vector generated in step 21) and the unified semantic representation vector. If this similarity value is not lower than the original similarity value of the entity in step 21 (ensuring that the attention screening does not deviate from the initial semantic association), then the entity is confirmed as a target multi-source intelligence entity. If it is lower than the original similarity value, then the attribute attention weights of the entity are recalculated (e.g., checking whether the attribute text description is complete), and the comprehensive score calculation and screening are performed again until a target multi-source intelligence entity that meets the semantic consistency requirements is obtained. This screening process is based on a compliance-oriented attention mechanism and ensures that the results do not deviate from the core semantics through semantic verification. Compared with the traditional method of screening based solely on a single similarity, the compliance adaptability of the target entities is better.

[0060] Optionally, step 23 specifically includes: step 231, based on preset industry relationship extraction rules and semantic association relationships between multi-source intelligence entities, performing implicit association relationship reasoning on target multi-source intelligence entities through graph neural networks to generate implicit association relationship results; step 232, constructing an intelligence semantic parsing graph containing timestamp attributes based on the implicit association relationship results.

[0061] Preferably, the specific implementation process of step 231 is as follows: First, the preset industry relationship extraction rules need to be adapted to compliance scenarios to form a "compliance domain-relationship rule" template that can be directly used for reasoning, ensuring that the rules are highly matched with the enterprise's compliance needs. The preset industry relationship extraction rules are divided into domains according to the multi-level compliance rule library (data security, anti-monopoly, cross-border trade, labor employment). The rules in each domain contain three elements: "premise entity type - relationship triggering condition - conclusion relationship type" (for example, the data security domain rule: the premise entity type is "data transmission node", the relationship triggering condition is "transmission of unencrypted data", and the conclusion relationship type is "compliance risk dependency relationship"; the anti-monopoly domain rule: the premise entity type is "holding enterprise", the relationship triggering condition is "shareholding ratio exceeds 30%", and the conclusion relationship type is "related enterprise control relationship"). For each rule, the entity attribute information in the enterprise's multi-source intelligence knowledge graph is combined to supplement the "compliance association threshold" (such as the trigger threshold for "unencrypted data transmission" being "data transmission volume exceeds 10GB / time", which is set based on the enterprise's compliance standards). Finally, "compliance domain relationship rule templates" are generated by domain classification to avoid reasoning bias caused by the lack of compliance targeting in traditional industry relationship rules.

[0062] Preferably, in the specific technical implementation of step 231, when constructing a graph neural network adapted for compliance reasoning, a "compliance relationship weight layer" needs to be added to strengthen the reasoning priority of compliance relationships. Traditional graph neural networks treat all entity relationships equally, without considering the compliance importance of relationships. Therefore, this step improves the graph neural network by adding a compliance relationship weight layer between the node feature propagation layer and the output layer of the graph neural network. The weight value of this layer is set according to the compliance impact of the relationship type in the "compliance domain relationship rule template"—the weight of direct compliance relationships (such as "data security risk dependence" and "anti-monopoly control") is set to a relatively high value (e.g., 0.8), and the weight of indirect business relationships (such as "business cooperation" and "technology docking") is set to a relatively low value (e.g., 0.3). The weight value is adjusted based on the accuracy feedback of the enterprise's historical compliance reasoning cases (if the reasoning result of a certain type of relationship matches the actual compliance situation highly, its weight is appropriately increased). This improvement makes the graph neural network more focused on relationships that have a direct impact on compliance risk identification during reasoning, improving the compliance targeting of the reasoning.

[0063] Preferably, in the specific implementation of step 231, the target multi-source intelligence entity and the adjacent entities in the enterprise multi-source intelligence knowledge graph library are used as inputs to the graph neural network, and implicit relationship reasoning is completed through feature propagation and weight adjustment. Specifically: First, extract the target multi-source intelligence entity determined in step 22, and the adjacent entities directly associated with the target entity in the enterprise multi-source intelligence knowledge graph library (e.g., if the target entity is a "cross-border data transmission node", the adjacent entities include "data source server" and "receiving overseas institution") to form a "target-adjacent" entity set; Second, use the attribute semantic vector of each entity in the entity set (generated by encoding the entity description text through the first language model in step 11) as the node feature of the graph neural network, and use the existing semantic relationship between entities (from the enterprise multi-source intelligence knowledge graph library) as the initial edge feature; Third, through the node feature propagation layer of the graph neural network, the feature of each node is passed to the adjacent nodes along the edge features. The compliance relationship weight layer applies corresponding weights to different types of edge features (e.g., the weight of the "cross-border data transmission" edge feature is 0.8, and the weight of the "technical consultation" edge feature is 0.3) to strengthen the propagation intensity of compliance-related features. The fourth step is to classify the relationships of the propagated node features through the output layer to determine whether there is a conclusion relationship type defined in the "compliance domain relationship rule template" between the target entity and its neighboring entities. If there is, the relationship and the corresponding confidence level are output (e.g., there is a "cross-border data transmission violation relationship" between the target entity "cross-border data transmission node" and the neighboring entity "overseas receiving institution", with a confidence level of 0.92). Finally, a structured data of "target entity - implicit relationship type - associated entity - confidence level" is formed, which is the implicit relationship result.

[0064] Preferably, step 231 concludes by performing compliance logic verification on the implicit relationship results to ensure that the reasoning results are free of logical contradictions. Specifically, for each implicit relationship, it is checked whether it conflicts with existing semantic relationships in the enterprise's multi-source intelligence knowledge graph (e.g., if a "data transmission encryption" relationship already exists, but a risk dependency relationship of "data transmission unencrypted" is inferred). If a conflict exists, the confidence level of the relationship is recalculated (combining the compliance attributes of the conflicting relationship, such as if the compliance filing status of "encrypted" is "passed," then the confidence level of the conflicting relationship is reduced). If the confidence level still exceeds the preset compliance reasoning threshold (e.g., 0.7), the conflicting relationship is marked as "to be verified" and accompanied by conflict analysis (e.g., "the reasoning result conflicts with the existing encryption filing, and the actual encryption status of the transmitted data needs to be verified"). Finally, the verified implicit relationship results are output. This verification process avoids compliance misjudgments caused by ignoring logical conflicts in traditional reasoning, resulting in better reliability of the results.

[0065] Preferably, the specific implementation process of step 232 is as follows: First, it is necessary to determine the timestamp attribute values ​​of entities and relationships in the intelligence semantic parsing graph. These timestamps need to conform to the "risk time tracing" requirements in compliance scenarios, rather than general time records. The sources of timestamp attribute values ​​are divided into two categories: one is the entity timestamp, which is taken from the basic attributes of the target multi-source intelligence entity and related entities (such as "entity creation time" and "compliance filing update time", for example, the compliance filing update time of the target entity "data storage node" is "2024-03-20"); the other is the relationship timestamp. If it is an existing semantic relationship in the enterprise multi-source intelligence knowledge graph library, the "establishment time" of the relationship is taken (such as the establishment time of "cross-border data transmission relationship" is "2024-04-05"); if it is the implicit relationship result generated in step 231, the time of reasoning completion is taken (such as "2024-05-10 14:30:00"), and "reasoning generation" is marked after the timestamp to distinguish it from the original relationship. In this way, timestamps not only record time information, but also provide a basis for tracing the time dimension of subsequent compliance risks (such as "cross-border data transmission risks within a certain time period"), which is different from the single function of traditional graphs that only record the creation time.

[0066] Preferably, in the specific technical implementation of step 232, based on the implicit relationship results and timestamp attributes, a core topology structure of the intelligence semantic parsing graph is constructed to ensure that the graph can intuitively present the entity relationships related to compliance. Specifically: First, taking the target multi-source intelligence entity determined in step 22 as the core node of the graph, the entities that have implicit relationships with the target entity in step 231 are taken as associated nodes. The node attributes include "entity name - compliance field classification - core compliance attribute - entity timestamp" (e.g., the attributes of the target node "cross-border data transmission node": entity name = "transmission node A", compliance field classification = "cross-border trade", core compliance attribute = "transmission data type: user information, filing status: pending filing", entity timestamp = "2024-03-20"); Second, "edges" are used to represent the relationships between entities. The edge attributes include "relationship type - relationship timestamp - relationship confidence - compliance rule basis" (e.g., the edge attributes between the target node and the associated node "overseas institution B": relationship type = "cross-border data violation transmission relationship", relationship timestamp = "2024-05-10"). 14:30:00 (Inference Generation), Relationship Confidence = 0.92, Compliance Rule Basis = "Rules for 'Unregistered Data Export' in Cross-border Trade"); The third step is to supplement the graph with other compliant relationships directly related to core nodes and associated nodes in the enterprise's multi-source intelligence knowledge graph library (such as "the association between transmission node A and the data encryption server") to form a multi-layer topology structure of "core node - directly associated node - indirectly associated node", that is, the initial intelligence semantic parsing graph.

[0067] Preferably, in one scenario, step 232 requires compliance logic consistency verification and structural optimization of the initial intelligence semantic analysis graph to ensure that the graph can be directly used for subsequent compliance risk matching. Specifically: First, verify whether the compliance logic of all relationships in the graph is consistent (e.g., if "data transmission node A" has both "encrypted transmission" and "unencrypted transmission" relationships, it is necessary to combine the timestamp to determine whether they are relationships in different time periods; if they are in the same time period, mark them as "logical conflict" and associate them with the reasoning basis of step 231); Second, perform hierarchical visual marking of the nodes in the graph according to the degree of compliance risk association (e.g., core nodes are marked in red, nodes with implicit risk associations are marked in orange, and ordinary association nodes are marked in blue) to make risk-related nodes easier to identify; Third, delete redundant associations in the graph that are not related to compliance risk identification (e.g., "cleaning and maintenance record association of transmission node A"), retain all compliance-related nodes and associations, and finally form an intelligence semantic analysis graph with a clear structure, consistent logic, and timestamp attributes. Compared to traditional semantic graphs, this graph not only includes entity relationships but also integrates compliance rules, timestamps, and risk association markers, providing a more accurate graph foundation for matching compliance clauses in step 3.

[0068] Optionally, step 3 specifically involves: calling a multi-level compliance rule library through the enterprise compliance rule inference engine, matching compliance clauses in the intelligence semantic analysis graph by domain to determine potential compliance risk points, and tracking the potential compliance risk points in the intelligence semantic analysis graph based on the tags of the potential compliance risk points to generate a risk transmission path diagram.

[0069] Optionally, step 3 includes step 31: the enterprise compliance rule reasoning engine calls the multi-level compliance rule library to perform domain-specific compliance clause matching on the intelligence semantic parsing graph to form initial risk rules, and generates extended risk rules based on the initial risk rules to determine potential compliance risk points. The multi-level compliance rule library is divided into sub-libraries for data security, anti-monopoly, cross-border trade and labor employment according to the domain.

[0070] Preferably, the specific implementation process of step 31 is as follows: First, the intelligence semantic parsing graph generated in step 232 needs to be judged for compliance domain tendency in order to accurately call the corresponding domain sub-library in the multi-level compliance rule library, so as to avoid the low efficiency problem caused by the traditional "full library traversal matching". Specifically, the process involves: extracting the core entities (i.e., the target multi-source intelligence entities determined in step 22) and core relationships (the top N relationships with the highest confidence in the implicit relationship results generated in step 231) from the intelligence semantic analysis graph; obtaining the "compliance domain classification" attribute of the core entities (e.g., the compliance domain classification of "cross-border data transmission node" is "cross-border trade") and the "relationship domain label" of the core relationships (e.g., the relationship domain label of "cross-border data illegal transmission relationship" is "cross-border trade"); counting the frequency of these domain information occurrences, and determining the domain with the highest frequency as the "dominant compliance domain" of the intelligence semantic analysis graph (e.g., if the "cross-border trade" label accounts for 60% of the core entities and relationships, then the dominant compliance domain is cross-border trade); if multiple domains have the same frequency (e.g., cross-border trade and data security both account for 50%), then further extracting the compliance clause keywords involved in the graph (e.g., "data encryption" corresponds to data security, and "overseas filing" corresponds to cross-border trade), and secondarily determining the dominant compliance domain through the matching degree of keywords and domains, finally obtaining the dominant compliance domain and secondary relationship domain of the graph (e.g., the dominant domain is cross-border trade, and the secondary domain is data security).

[0071] Preferably, in the specific technical implementation of step 31, the enterprise compliance rule reasoning engine, based on the dominant compliance domain and secondary related domains, calls the corresponding domain sub-libraries in the multi-level compliance rule library to achieve domain-specific compliance clause matching. The multi-level compliance rule library is divided into data security sub-library, anti-monopoly sub-library, cross-border trade sub-library, and labor employment sub-library according to the domain. The compliance clauses in each sub-library are stored in a structured manner according to "clause number - clause description - violation judgment condition - rule priority" (for example, in the cross-border trade sub-library: clause number KJT-001, clause description "overseas institutions receiving data from domestic enterprises must complete cross-border data transmission filing in advance", violation judgment condition "the filing status is 'not filed' when the data transmission behavior occurs", and rule priority "high"). The enterprise compliance rule reasoning engine first calls the sub-library corresponding to the dominant compliance domain (such as the cross-border trade sub-library) and matches the core entity attributes and core relationships in the intelligence semantic analysis graph with the "violation judgment condition" of the compliance clauses in the sub-library (such as matching whether the "filing status" attribute of the "cross-border data transmission node" is "not filed"). The first step is to identify the relevant clauses and their corresponding violation criteria in clause KJT-001. Then, the corresponding sub-libraries in the secondary related areas (such as the data security sub-library) are called, and the above matching process is repeated. For successfully matched compliant clauses (i.e., the graph information meets the clause's violation criteria), they are sorted from highest to lowest "rule priority." The clauses with the highest priority and their corresponding matching criteria (e.g., "Entity A in the graph is not registered, meeting the violation criteria of clause KJT-001") are selected and organized into a structured initial risk rule set. Each rule in the initial risk rule set contains "Clause Source - Violation Criterion - Rule Priority - Related Graph Elements" (e.g., Clause Source "Cross-border Trade Sub-library KJT-001", Violation Criterion "Entity A's registration status is not registered", Rule Priority "High", Related Graph Elements "Entity A and 'Cross-border Data Transmission Relationship'").

[0072] Preferably, in one scenario, when generating extended risk rules based on the initial risk rule set in step 31, it is necessary to combine the business process relevance of the intelligence semantic analysis graph to avoid the problem of narrow coverage caused by traditional extensions based solely on the clauses themselves. Specifically: for each initial risk rule in the initial risk rule set, extract its "relationship graph element" (such as entity A and "cross-border data transmission relationship"); track the upstream and downstream business process nodes of the relationship graph element in the intelligence semantic analysis graph (such as the upstream node of entity A being "data collection terminal", the downstream node being "overseas receiving institution B", and the business process node being "data collection-transmission-storage"); based on the "related risk transmission rules" in the multi-level compliance rule base (related risk transmission rules are stored in the "transmission rules" sub-module of each domain sub-base, such as the related risk transmission rule for "cross-border data transmission without filing" being "if the upstream data collection terminal does not classify the data, the risk level is increased; if the downstream overseas receiving institution does not have data storage qualifications, a new violation point is added"), analyze other compliance clauses that the initial risk rule may trigger in the upstream and downstream business process nodes; for example, the initial risk rule is "if entity A transmits data without filing..." The "Data Transfer (KJT-001)" rule, through the association risk transmission rules, reveals that the "Data Storage Qualification" attribute of the downstream "Overseas Receiving Institution B" is "None". Matching the clause "Unqualified Storage of Sensitive Data" (SJA-003) in the data security sub-library, the SJA-003 clause and the corresponding judgment basis ("Overseas Receiving Institution B has no storage qualification") are added as extended rules to the initial risk rule set. This process is repeated until all upstream and downstream business process nodes of the initial risk rules are covered, ultimately forming an extended risk rule set containing the initial rules and extended rules. Each extended rule is marked with "Extended Source Initial Rule - Extended Basis Transmission Rule - Related Business Node" (e.g., the extended source initial rule of extended rule SJA-003 is KJT-001, the extended basis transmission rule is "Risk of Unregistered Cross-border Data Transmission Related to Downstream Storage Qualification", and the related business node is "Storage Link of Overseas Receiving Institution B").

[0073] Preferably, step 31 concludes by verifying the compliance logic consistency of the extended risk rule set to ensure there are no contradictions between the rules, providing a reliable basis for identifying potential compliance risks. Specifically, this involves checking whether there are contradictions in the extended risk rule set where the same graph element is judged as 'violation' or 'compliance' by different rules (e.g., rule KJT-001 judges entity A's transmission behavior as violation, while rule KJT-005 judges the behavior as compliant). If a contradiction exists, the "rule priority" of the two rules is extracted, and the rule with the higher priority is retained (e.g., if KJT-001 has a "high" priority and KJT-005 has a "medium" priority, then KJT-001 is retained). If the priorities are the same, the attribute details of the graph element are further verified (e.g., KJT-001 is judged based on "filing status," and KJT-005 is judged based on "whether the transmitted data type is non-sensitive data," it is necessary to confirm whether the data type attribute is "sensitive data," and if it is sensitive data). According to KJT-001, the rules are deemed valid. After deleting logically invalid rules from the contradictory rules, the "matching confidence" (i.e., the degree of matching between the graph information and the clause violation judgment conditions) of each rule in the extended risk rule set is statistically analyzed. For example, if there is a complete match, the confidence is 1.0, and if there is a partial match, the confidence is 0.7. Rules with a confidence exceeding the preset rule confidence threshold (e.g., 0.6) are retained. Finally, the verified extended risk rule set is obtained, and potential compliance risk points are determined based on this set. The "related graph elements" (e.g., entity A, overseas receiving institution B) and "violation behavior descriptions" (e.g., "data transmission without filing" "data storage without qualifications") corresponding to each rule are marked as preliminary information for potential compliance risk points, providing a basis for the risk point refinement in subsequent steps 32-34.

[0074] Optionally, step 3 includes step 32: using associated risk transmission rules to analyze the upstream and downstream related entities, business process nodes and scope of impact involved in the initial risk rules to generate extended risk rules, and based on the extended risk rules, identifying potential compliance risk points.

[0075] Preferably, the specific implementation process of step 32 is as follows: First, the related risk transmission rules in the multi-level compliance rule library need to be pre-processed in a structured manner to form a "domain-transmission element" mapping system adapted to the enterprise's compliance scenario, providing a standardized basis for subsequent analysis. Related risk transmission rules are stored according to the domains of the multi-level compliance rule library (data security, anti-monopoly, cross-border trade, labor employment). Each rule contains four elements: "source risk type - transmission triggering condition - upstream and downstream impact dimensions - related compliance clause identifier" (for example, the related risk transmission rule in the cross-border trade domain: the source risk type is "cross-border data transmission without filing," the transmission triggering condition is "data involves sensitive user information and the transmission volume exceeds a preset threshold," the upstream and downstream impact dimensions are "upstream data collection stage, downstream data storage stage," and the related compliance clause identifier is "data security sub-library SJA-"). 003 (Unqualified Storage), Cross-border Trade Sub-database KJT-002 (Excessive Transmission); For each associated risk transmission rule, supplementary enterprise business process adaptation descriptions are provided (such as "the upstream data collection link corresponds to the 'data collection terminal' entity in the graph, and the downstream data storage link corresponds to the 'overseas storage server' entity"). The rules are also categorized by "source risk type" to form a structured associated risk transmission rule library. Each rule in this library can directly associate with the entity type and business process node in the intelligence semantic analysis graph, which is different from the problem of traditional association rules that only describe risk associations and lack scenario adaptation.

[0076] Preferably, in the specific technical implementation of step 32, the core related elements involved in the initial risk rules are extracted to provide accurate positioning for subsequent upstream and downstream analysis. The initial risk rules come from the initial risk rule set generated in step 31. Each initial risk rule contains "related graph elements" (such as the target multi-source intelligence entity "cross-border data transmission node A" and the related relationship "data transmission to overseas institution B"). Based on these related graph elements, the core related elements are extracted from the intelligence semantic parsing graph generated in step 232: First, core entity information (including entity name, compliance field classification, and key compliance attributes, such as the compliance attributes of "cross-border data transmission node A" such as "filing status = not filed" and "transmitted data type = sensitive information"); Second, the current business process node (i.e., the core entity is located at). The business process includes three parts: (1) business links, such as "Cross-border data transmission node A" corresponding to the "data transmission" link, and marking the position of this link in the overall business process of the enterprise, such as "located in the middle node of the 'data collection → transmission → storage' process"; (2) triggered risk characteristics (i.e., the basis for the violation judgment of the initial risk rule, such as "transmission of sensitive information without filing"); and (3) the triggered risk characteristics. These elements are organized into an initial rule association element table of "initial rule ID - core entity information - current business process node - triggered risk characteristics" to ensure that each initial risk rule can be mapped to a specific entity, process and risk point in the graph, and to avoid subsequent analysis deviating from the initial risk scenario.

[0077] Preferably, in one scenario, step 32 uses a "graph traversal + transmission rule matching" approach to analyze the upstream and downstream related entities involved in the initial risk rules, ensuring the comprehensiveness and compliance relevance of the identified related entities. Specifically: starting with the "core entity" in the initial rule related element table, a bidirectional graph traversal is performed in the intelligence semantic parsing graph (tracing the source of data / business upstream and the flow of data / business downstream); during the traversal, the "upstream and downstream impact dimensions" corresponding to the "source risk type" in the structured related risk transmission rule base (e.g., the upstream impact dimension of the source risk type "cross-border data transmission without filing" is "data collection", and the downstream is "data storage") are combined to filter entity types that match the impact dimensions (e.g., upstream filtering "data collection terminal" type entities, and downstream filtering "overseas storage server" type entities); for the filtered upstream and downstream entities, their key compliance attributes are extracted (e.g., upstream "data collection terminal" type entities are filtered). The downstream entity “C” has the attribute “Data Classification Status = Unclassified” and the downstream “Overseas Storage Server D” has the attribute “Storage Qualification = None”. It is then determined whether these attributes meet the “Transmission Trigger Conditions” in the structured association risk transmission rule base (e.g., “Data Unclassified” meets one of the transmission trigger conditions for “Cross-border Data Transmission Without Filing”). The upstream and downstream entities that meet the trigger conditions and their corresponding compliance attributes are organized into an upstream and downstream related entity analysis table with “Initial Rule ID - Upstream and Downstream Entity Type - Entity Compliance Attribute - Transmission Trigger Basis”, for example, “Initial Rule ID1 - Upstream Entity: Data Acquisition Terminal C - Compliance Attribute: Unclassified - Transmission Trigger Basis: Meets the upstream trigger condition of the ‘Cross-border Data Transmission Without Filing’ rule”.

[0078] Preferably, when analyzing the business process nodes and scope of impact involved in the initial risk rules in step 32, it is necessary to combine the compliance dependencies of the enterprise's business processes to avoid the problem of incomplete process coverage caused by traditional entity association analysis alone. Specifically, based on the "current business process node" (such as the "data transmission" stage) in the initial rule association element table, the enterprise's preset "business process-compliance clause" mapping table is retrieved (this table stores the compliance requirements corresponding to each business process stage of the enterprise, such as the "data collection" stage corresponding to the "data classification and grading" clause, and the "data storage" stage corresponding to the "storage qualification" clause); combined with the "scope of impact description" corresponding to the "current business process node" in the structured association risk transmission rule base (such as the scope of impact of the "data transmission" stage being "whether the upstream collection stage is compliantly classified and whether the downstream storage stage has the qualifications"), the business process nodes affected by the initial risk rules are marked in the intelligence semantic parsing graph (such as the marked...). Record two nodes: "Data Acquisition" and "Data Storage"); for each marked business process node, analyze whether there are potential compliance vulnerabilities related to the "triggered risk characteristics" of the initial risk rule (e.g., if the "Data Acquisition" stage is not classified, it may lead to the additional risk of "unidentified sensitive data"; if the "Data Storage" stage is unqualified, it may lead to the risk of "illegal storage"); organize these analysis results into a business process impact scope table of "Initial Rule ID - Affected Process Node - Potential Compliance Vulnerability - Related Transmission Rules", for example, "Initial Rule ID1 - Affected Process Node: Data Acquisition - Potential Compliance Vulnerability: Unclassified Sensitive Data - Related Transmission Rules: Cross-border Data Transmission Rule without Filing".

[0079] Preferably, step 32 generates extended risk rules based on the upstream and downstream related entity analysis table and the business process impact scope table, and determines potential compliance risk points in conjunction with the multi-level compliance rule library. Specifically: First, for each upstream and downstream entity in the upstream and downstream related entity analysis table, its "entity compliance attribute" is matched with the compliance clauses of the corresponding domain sub-library in the multi-level compliance rule library (e.g., "data acquisition terminal C is unclassified" matches the "unclassified sensitive data" clause SJA-001 in the data security sub-library, and "overseas storage server D is unqualified" matches clause SJA-003); Second, for each "potential compliance vulnerability" in the business process impact scope table, the corresponding compliance clause is also matched (e.g., "data acquisition process is unclassified" matches clause SJA-001); Third, for the successfully matched compliance clauses, it is checked whether they already exist in the initial risk rule set of step 31. If they do not exist, they are added as extended risk rules, and each extended risk rule is marked. Note "Extended Source (Initial Rule ID / Upstream and Downstream Entities / Process Nodes) - Violation Judgment Basis (Entity Attributes / Vulnerability Description) - Associated Transmission Rule ID - Corresponding Clause Source"; Fourth step, merge all extended risk rules with the initial risk rules, remove duplicate rules (if the same clause is matched multiple times, retain the earliest extended source record), and form the final extended risk rule set; Based on this extended risk rule set, mark the "upstream and downstream entities", "affected process nodes", and "violation description" corresponding to each rule as supplementary information for potential compliance risk points (such as "Potential compliance risk point: Data collection terminal C is unclassified (SJA-001), extended source: upstream entity analysis of initial rule ID1"), and improve the coverage and judgment basis of potential compliance risk points.

[0080] Optionally, step 3 includes step 33: calculating the semantic matching degree between the extended risk rule and the associated content of multi-source intelligence entities in the intelligence semantic parsing graph using a bidirectional long short-term memory model, and correcting the semantic matching degree using intelligence timeliness parameters to obtain the corrected matching degree, and determining potential compliance risk points based on the corrected matching degree.

[0081] Preferably, the specific implementation process of step 33 is as follows: First, the extended risk rules generated in step 32 need to be semantically encoded to generate extended risk rule semantic vectors consistent with the semantic space of the intelligence semantic parsing graph, ensuring the effectiveness of subsequent matching calculations. Extended risk rules contain core compliance information such as "clause description - violation judgment conditions - associated entity type" (e.g., an extended risk rule: clause description "unqualified to store sensitive data", violation judgment conditions "storage entity qualification status is 'none' and storage data type is 'sensitive'", associated entity type is "overseas storage server"); the core compliance information of each extended risk rule is integrated into structured text (e.g., "unqualified to store sensitive data: storage entity qualification status is 'none' and storage data type is 'sensitive', associated entity type is overseas storage server"); the first language model in step 11 is called to semantically encode this structured text, generating extended risk rule semantic vectors consistent with the dimension of the unified semantic representation vector (e.g., both are 768-dimensional). Each dimension of this vector corresponds to a compliance semantic feature (e.g., dimensions 10-15 correspond to semantics related to "storage qualifications", and dimensions 20-25 correspond to semantics related to "data types"), ensuring consistency with the semantic space of the intelligence semantic parsing graph, thus distinguishing it from the matching deviation caused by the inconsistency between traditional rule encoding and the semantic space of the graph.

[0082] Preferably, in the specific technical implementation of step 33, the multi-source intelligence entity association content in the intelligence semantic parsing graph is extracted and semantically encoded to form a target vector that can be matched with the semantic vector of the extended risk rule. The multi-source intelligence entity association content refers to the compliance-related information of entities and their associations that match the "associate entity type" of the extended risk rule in the graph. For example, if the associated entity type of the extended risk rule is "overseas storage server", then the "qualification status" and "storage data type" attributes of all "overseas storage server" type entities in the graph are extracted, as well as the "data storage association" between the entity and other entities. This information is organized into a structured content text of "entity ID-entity attribute text-association text" (e.g., "entity ID: FS-001-entity attribute text: qualification status = none, storage data type = sensitive-association text: data storage association with cross-border data transmission node A"). Similarly, the first language model is called to semantically encode this structured content text to generate a multi-source intelligence entity association content semantic vector. This vector has the same dimension and semantic space as the semantic vector of the extended risk rule, providing an adapted target vector for subsequent matching calculations.

[0083] Preferably, in one scenario, step 33 calculates the semantic matching degree between the semantic vector of the extended risk rule and the semantic vector of the content associated with the multi-source intelligence entity using an improved bidirectional long short-term memory model, thereby enhancing the contextual capture capability of compliance semantics. Traditional bidirectional long short-term memory models are weak in capturing "condition-result" logical semantics in compliance clauses. Therefore, this step improves the model in two ways: First, a "compliance semantic attention mask" is added to the model input layer. This mask is generated based on keywords (such as "unqualified" and "sensitive data") in the "violation judgment conditions" of the extended risk rule, assigning higher attention weights to the dimensions corresponding to these keywords in the input vector to strengthen the input of the core semantics of violation judgment. Second, a "logical relationship capture unit" is added to the model hidden layer. This unit optimizes the contextual semantic transmission by analyzing the correlation strength between the "conditional semantic dimension" (such as the "qualification status" dimension) and the "result semantic dimension" (such as the "violation storage" dimension) in the vector. The semantic vector of the extended risk rule and the semantic vector of the associated content of the multi-source intelligence entity are concatenated by dimension as the input to the model. The model is processed by an improved bidirectional long short-term memory model. The output layer of the model outputs a value between 0 and 1, which is the semantic matching degree between the extended risk rule and the associated content of the corresponding multi-source intelligence entity (the closer the value is to 1, the higher the degree of matching between the two in terms of compliance semantics). This forms the initial matching result table of "Extended Rule ID - Entity Associated Content ID - Semantic Matching Degree".

[0084] Preferably, when correcting the semantic matching degree through the intelligence timeliness parameter in step 33, it is necessary to combine the timeliness requirements of the compliance scenario and design a "domain-by-policy-stage" correction logic to avoid the problem of traditional single timeliness correction ignoring the differences in compliance scenarios. Specifically, it is divided into three steps: First, calculate the intelligence timeliness factor T. The intelligence timeliness factor T is calculated based on the difference between the intelligence release time corresponding to the content associated with multi-source intelligence entities and the current time, using an exponential decay function (such as T=e^(-k×Δt), where Δt is the time difference and k is the decay coefficient). At the same time, if the intelligence involves changes in compliance policies, the T value is reset to 1.0 (the relevant intelligence timeliness is highest after the policy takes effect); the k value is set according to the domain. For domains with high real-time requirements such as financial supervision and data security, the k value is set to a relatively high value (such as 0.05), and for domains with low real-time requirements such as labor employment, the k value is set to a relatively low value (such as 0.02), ensuring that the timeliness decay of different domains meets the actual compliance requirements. Second, set the domain weight coefficient W. Based on the compliance importance of the extended risk rule's domain, a domain weight coefficient W is set (e.g., W=1.2 for data security, W=1.0 for labor and employment). This coefficient is determined by the domain distribution frequency of the enterprise's historical compliance risk events (domains with frequent risk events have higher W values). The third step is to calculate the corrected matching degree M' = initial semantic matching degree M × T × W. For example, if an initial matching degree M=0.8, corresponding to an intelligence timeliness factor T=0.9 (Δt=2 days, k=0.05), and the data security domain weight W=1.2, then the corrected matching degree M'=0.8 × 0.9 × 1.2 = 0.864. The corrected matching degree is then updated to the initial matching result table, forming the final matching result table: "Extended Rule ID - Entity Related Content ID - Initial Matching Degree - Corrected Matching Degree - Correction Parameter (T, W)".

[0085] Preferably, step 33 determines the preliminary range of potential compliance risk points based on the corrected matching degree in the final matching result table, providing a basis for the subsequent marking in step 34. Specifically, this involves: setting a preset corrected matching degree threshold (this threshold is determined based on the accuracy of the company's historical compliance matching cases, for example, set to 0.7, meaning that combinations with a corrected matching degree exceeding 0.7 are considered to have a compliance risk association); traversing the final matching result table to filter out "extended rule-entity associated content" combinations with a corrected matching degree exceeding the preset threshold; marking these combinations with "risk association identifiers" and associating the "violation judgment conditions" of the extended risk rule with the "compliance attribute information" of the entity associated content (e.g., "Extended rule SJA-003-Entity FS-001-risk association identifier: yes-violation judgment conditions: no qualification to store sensitive data-entity attribute: qualification=none, data type=sensitive"); and compiling these annotation results into a "preliminary list of potential compliance risk points," which contains all the associated information required for marking potential compliance risk points in the subsequent step 34.

[0086] Optionally, step 3 includes step 34, marking the multi-source intelligence entity association and business process association content corresponding to the rule whose corrected matching degree exceeds the preset matching degree threshold in the intelligence semantic parsing graph as potential compliance risk points, and assessing the severity of the potential compliance risk points in combination with the rule severity level, the number of affected entities and the transmission probability as the label of the potential compliance risk points.

[0087] Preferably, the specific implementation process of step 34 is as follows: First, it is necessary to determine the preset matching degree threshold for each domain based on the risk sensitivity of the enterprise's compliance field, so as to avoid the risk misjudgment or omission caused by the traditional single threshold ignoring the differences between domains. The preset matching degree threshold is set based on two aspects: First, the risk control requirements of each domain sub-library in the multi-level compliance rule base (for example, the risk control requirements in the data security field are relatively high due to the involvement of user privacy and severe legal penalties, so the threshold needs to be set to a relatively high value; the risk consequences in the labor and employment field are relatively light, so the threshold can be set to a relatively low value); Second, the accuracy feedback of the enterprise's historical compliance matching cases (statistically analyze the correspondence between "corrected matching degree - actual violation" in historical cases, and determine the threshold of "the actual violation probability ≥ 80% when the matching degree exceeds this value" in each domain). The final result is a pre-defined matching threshold table for each domain (e.g., 0.75 for the data security sub-library, 0.7 for the anti-monopoly sub-library, 0.72 for the cross-border trade sub-library, and 0.65 for the labor employment sub-library). This table serves as the core basis for screening risk-related combinations. The processing objects are the domain risk characteristics and historical case data of the multi-level compliance rule base. The processing action is to "determine the threshold by combining risk control requirements and historical accuracy". The processing result is the pre-defined matching threshold table for each domain.

[0088] Preferably, in the specific technical implementation of step 34, the "extended rule-graph content" combination with a corrected matching degree exceeding the preset threshold of the sub-domain is screened to identify potential risk association objects to be marked. The processing objects are the final matching result table of "extended rule ID-entity association content ID-corrected matching degree-correction parameter" generated in step 33, and the aforementioned preset matching degree threshold table of the sub-domain; the processing action is divided into two steps: First, for each record in the final matching result table, according to the domain to which the extended rule belongs (e.g., if the extended rule comes from the data security sub-database, the corresponding threshold is 0.75), the corresponding threshold in the sub-domain threshold table is retrieved; Second, records with a corrected matching degree exceeding the corresponding domain threshold are screened to form a "risk association combination table to be marked", each record containing "extended rule ID-association graph element ID (multi-source intelligence entity ID + business process node ID)-corrected matching degree-sub-domain threshold" (e.g., "extended rule ID: SJA-003-association graph element ID: entity FS-001+process node 'data storage'-corrected matching degree: 0.82-sub-domain threshold: 0.75"). This screening process ensures that only associations with high semantic matching and compliance with domain risk management requirements are retained, providing accurate targets for subsequent tagging.

[0089] Preferably, in a scenario, when marking potential compliance risk points in the intelligence semantic analysis graph in step 34, a "dual-dimensional marking of entity and process" should be adopted, rather than the traditional single method of marking only entities, to ensure more accurate risk positioning. The processing objects are the risk association combination table to be labeled and the intelligence semantic analysis graph generated in step 232. The processing action consists of three steps: First, locate the position of the association graph elements in the graph (such as the node position of entity FS-001, the link position of the "data storage" business process node); Second, add "risk identifier attributes" to multi-source intelligence entities, the attribute value of which includes "risk type (such as 'unqualified storage of sensitive data') - association extension rule ID - corrected matching degree" (such as the risk identifier attribute of entity FS-001 being "risk type: unqualified storage of sensitive data - association rule: SJA-003 - matching degree: 0.82"); Third, add "risk link markers" to the corresponding business process nodes, marking the specific links affected by the risk (such as adding the marker "affected by unqualified storage risk, the amount of sensitive data involved accounts for 60% of the total storage of this node" to the "data storage" node); The processing result is an intelligence semantic analysis graph with dual-dimensional risk markers, which can intuitively present the specific location of the risk in the entity and business process, providing a positioning basis for subsequent severity assessment.

[0090] Preferably, when extracting the core parameters for assessing the severity of potential compliance risks in step 34, the source and calculation logic of each parameter must be clearly defined to ensure the traceability of the assessment basis. The processing objects are the intelligence semantic analysis graph with dual-dimensional risk labels, the multi-level compliance rule library, and the analysis results of the associated risk transmission rules generated in step 32. The three core parameters to be extracted are as follows: First, the rule severity level, derived from the compliance clauses corresponding to the extended risk rules in the multi-level compliance rule library (the clauses are pre-divided into four levels according to the severity of the "consequences of violation": extremely severe, moderate, medium, and minor; for example, the rule severity level of clause SJA-003 in the data security sub-library is "moderate"); second, the number of affected entities, obtained by traversing the risk-labeled graph and statistically analyzing multiple sources directly related to the current potential compliance risk (such as data transmission and business collaboration). The total number of intelligence entities (e.g., the risk of unlicensed storage by entity FS-001 affects two entities: "Data Transmission Node A" and "User Data Collection Terminal C", resulting in a total of 2 affected entities); the third is the transmission probability, derived from the "Risk Diffusion Probability Value" in the analysis results of the associated risk transmission rules in step 32 (this value is generated based on the statistics of historical risk transmission cases of the enterprise, such as "the probability of unlicensed storage risk transmitting to the data transmission link is 0.6"); the processing result is a severity assessment parameter table of "Potential Risk Point ID - Rule Severity Level - Number of Affected Entities - Transmission Probability", with each parameter associated with a clear source basis, avoiding the subjectivity problem of traditional assessment parameters.

[0091] Preferably, when calculating the overall severity of potential compliance risk points and generating labels in step 34, an assessment logic of "weighted-level mapping" needs to be designed to ensure that the severity classification meets the enterprise's compliance control needs. The processing object is the severity assessment parameter table; the processing action is divided into three steps: First, assign compliance-oriented weights to the three core parameters (the rule severity level directly reflects the inherent risk of the clause, and the weight is set to the highest relative value, such as 0.5; the transmission probability affects the scope of risk diffusion, and the weight is set to 0.3; the number of affected entities reflects the current risk coverage, and the weight is set to 0.2); Second, quantify the parameters (the rule severity level is quantified according to "extremely severe = 4, moderately severe = 3, medium = 2, and mildly severe = 1", the number of affected entities is taken as the actual value, and the transmission probability retains the original 0-1 value), and calculate the overall severity score (score = rule severity level quantification value × 0.5 + transmission probability × 0.3 + number of affected entities × 0.2, the score range is 0.3-2.6); Third, the overall score is... The scores are mapped to severity labels (e.g., a score ≥ 2.0 is mapped to "high severity", 1.5-2.0 is mapped to "medium-high severity", 1.0-1.5 is mapped to "medium severity", and < 1.0 is mapped to "low severity"), and the labels are associated with potential compliance risk points (e.g., the risk label for entity FS-001 is "high severity - rule level: relatively severe - transmission probability: 0.6 - affected entities: 2"). The processing result is a structured label table of "potential compliance risk point ID - dual-dimensional mark location - comprehensive severity label - assessment parameter details". This label table is directly used for risk transmission path tracking in the subsequent step 35, and the label information can support the graded warning in the subsequent step 4, which is different from the traditional crude method of assessing severity based on only a single parameter.

[0092] Optionally, step 3 includes step 35: based on the tags of potential compliance risk points, tracking the associated entities and relationship paths of potential compliance risk points in the intelligence semantic parsing graph to generate a risk transmission path diagram.

[0093] Preferably, the specific implementation process of step 35 is as follows: First, the potential compliance risk point tags generated in step 34 need to be parsed to extract the core positioning information for path tracing, providing a clear target for subsequent tracing. The potential compliance risk point tags include "potential risk point ID - core risk entity ID - risk type - associated extension rule ID - severity tag" (e.g., "risk point ID1 - core risk entity ID: FS-001 - risk type: unqualified storage of sensitive data - association rule: SJA-003 - severity tag: high severity"). The processing object is this tag set, and the processing action is "extracting the core risk entity ID and risk type as the tracking anchor point, and the associated extension rule ID as the compliance basis". The processing result is a "risk tracing task table", and each task record includes "tracing ID - anchor entity ID (core risk entity ID) - tracking basis (risk type + associated extension rule ID) - tracking scope (preset as 'direct / indirect related entities of the anchor entity')". This process avoids the path confusion caused by the lack of clear anchor points in traditional tracing, ensuring that tracing always revolves around the core entity of compliance risk.

[0094] Preferably, in the specific technical implementation of step 35, a "compliance risk-oriented" two-way path tracing strategy is designed, which differs from the traditional indiscriminate graph traversal and ensures that the tracing focuses on entities and relationships related to risk transmission. The processing objects are the risk tracing task table and the intelligence semantic parsing graph generated in step 232; the core logic of the processing action is "taking the anchor entity as the center and filtering the path bidirectionally according to 'business process flow' and 'compliance association type'": First, business process flow filtering (tracing upstream to the risk source entity, such as the upstream of anchor entity FS-001 being "data transmission node A"; tracing downstream to the risk-affected entity, such as the downstream being "user data query terminal E"), only retaining entities that have data / business flow relationships with the anchor entity; Second, compliance association type filtering (only retaining associations related to the risk type, such as "unqualified entities") The risk assessment only retains compliance-related relationships such as "data transmission" and "data storage authorization," excluding irrelevant relationships such as "equipment maintenance" and "office collaboration." During the processing, the "relationship type-timestamp-propagation probability" of each path must be recorded synchronously (the propagation probability comes from the severity assessment parameter in step 34, such as the propagation probability P=0.8 from anchor entity FS-001 to data transmission node A, which means that the risk of this path is likely to spread), forming a "trace path temporary record table," which includes "trace ID-path sequence (entity 1→entity 2→entity 3)-path relationship type-path timestamp-path propagation probability."

[0095] Preferably, in one scenario, when performing specific path tracing in step 35, it is necessary to combine the timestamp attribute of the intelligence semantic parsing graph with the associated risk transmission rules to verify the temporal rationality and compliance relevance of the path, and avoid tracing invalid historical paths. The processing objects are the entity timestamp attributes in the temporary record table and graph of the tracing path; the processing action is divided into two steps: First, temporal verification—check whether the "entity timestamp" of each entity in the path sequence and the "relationship timestamp" of the relationship conform to the business process temporal sequence (e.g., the relationship timestamp of "data transmission node A → entity FS-001" must be later than the entity creation time of data transmission node A and earlier than the risk marking time of entity FS-001), and eliminate paths with temporal inconsistencies (e.g., paths where the relationship timestamp is earlier than the entity creation time); Second, compliance relevance verification—based on the "association extended rule ID" in the tracing basis, retrieve the "association" corresponding to the rule in the multi-level compliance rule library. Risk transmission rules (e.g., the transmission rule corresponding to rule SJA-003 is "the risk of unqualified storage can be transmitted to unencrypted transmission nodes through data transmission association") are used to verify whether the relationship type in the path conforms to the description of the transmission rule, and to retain the paths that conform to the rule; the processing result is an "effective risk transmission path table", and the path sequence of each record satisfies "reasonable time sequence + compliant association", for example, "Tracking ID1 - Path sequence: data transmission node A → FS-001 → user data query terminal E - Path relationship type: data transmission → data storage authorization - Path timestamp: 2024-05-10 → 2024-05-10 - Path transmission probability: 0.8 → 0.6".

[0096] Preferably, when constructing the risk transmission path diagram in step 35, a three-in-one topology design of "entity-relationship-risk attribute" should be adopted to ensure that the path diagram can intuitively reflect the risk diffusion characteristics. The processing object is the effective risk transmission path table; the processing action is divided into three steps: First, determine the topology nodes - take all entities in the effective path as nodes, and label the node attributes as "entity ID-entity type-risk association status (anchor entity / upstream source entity / downstream affected entity)-severity label" (e.g., anchor entity FS-001 is labeled "ID: FS-001-type: overseas storage server-status: anchor entity-severity: high"); Second, determine the topology edges - take the relationships in the effective path as edges, and label the edge attributes as "relationship type-path transmission probability-relationship time". The process involves several steps: first, adding a "stamp" and then setting visual weights for edges based on their transmission probability (edges with a transmission probability ≥ 0.7 use thick lines, those with a probability ≤ 0.3 use medium lines, and those with a probability < 0.3 use thin lines); second, adding risk propagation direction markers—marking arrows on edges to indicate the direction of risk propagation (upstream → anchor point → downstream), and adding special visual markers (such as red borders) to anchor point entity nodes; the result is a risk propagation path diagram containing "node topology + edge attributes + direction markers." This diagram differs from traditional graphs that only show entity relationships, clearly presenting the complete transmission link and propagation possibility of risk from its source to its affected area.

[0097] Preferably, step 35 concludes with a logical verification of the risk transmission path diagram to ensure that the path is consistent and covers the main risk-related entities. The processing object is the risk transmission path diagram; the processing actions include: first, checking for the existence of "cyclic transmission paths" (e.g., entity A→B→A). If present, determining whether it's a repeated transmission across different time periods based on timestamps; non-repeating transmissions are removed; second, checking for missing key entities in the effective risk transmission path table (e.g., user data query terminal E included in the effective path is not shown in the diagram); if missing, nodes and edges are added; third, associating the severity labels from step 34 to ensure that the risk level label of a node matches the path transmission probability (e.g., the downstream edge transmission probability of a high-severity node should be ≥0.5 to avoid the contradiction of a high-risk node having a low transmission probability). After successful verification, a risk transmission path diagram that can be directly used for graded early warning in step 4 is finally generated, realizing "label parsing → path tracing → graph construction → verification," ensuring the reliability and compliance guidance value of the path diagram.

[0098] Optionally, step 4 specifically involves: determining the risk level based on the risk transmission path diagram to generate tiered compliance risk early warning information.

[0099] Optionally, step 4 includes step 41: based on the risk transmission path diagram, assess the severity quantification value of potential compliance risk points and the diffusion coefficient of associated transmission paths to determine the risk level and generate graded compliance risk early warning information.

[0100] Preferably, the specific implementation process of step 41 is as follows: First, the risk transmission path diagram generated in step 35 needs to be parsed to extract the core basic data for assessment, providing reliable input for subsequent quantitative calculations. The risk transmission path diagram contains core information such as "nodes (entities associated with potential compliance risk points) - edges (transmission paths) - attributes (node ​​severity labels, edge transmission probabilities, business process dependencies)". The processing object is this risk transmission path diagram, and the processing action is "extracting associated data by grouping potential compliance risk points": For each potential compliance risk point (the anchor entity in the corresponding path diagram), three types of basic data are extracted - first, the inherent attribute data of the risk point (the potential compliance risk point labels from step 34, including rule severity level, number of initial affected entities, and initial transmission probability); second, the path transmission data (from the edge attributes of the path diagram, including the associated data of the risk point). The data includes: 1) the probability of path transmission along all transmission paths and the number of entities involved in each path; 2) business scenario data (from the node business attributes of the path diagram, including the "business importance level" of the entities involved in the path, such as "core business entity" and "non-core business entity", and the "process criticality" of the business process in which the transmission path is located, such as "core data transmission process" and "auxiliary office process"); the processing result is a "basic data table for risk point assessment", with each record corresponding to a potential compliance risk point, including "risk point ID - inherent attribute data - path transmission data - business scenario data", ensuring that the data required for subsequent assessments all come from the verified path diagram and labels, avoiding the introduction of subjective data.

[0101] Preferably, in the specific technical implementation of step 41, when assessing the severity quantification value of potential compliance risk points, a "multi-dimensional weighted integration" logic is adopted, which differs from the traditional coarse quantification method based solely on a single rule level. The calculation of the severity quantification value S requires the integration of three core dimensions (all from the risk point assessment basic data table), and the processing logic for each dimension is as follows:

[0102] 1. Quantification of Rule Severity Level: The "Rule Severity Level" (e.g., "Extremely Severe", "Slightly Severe", "Medium", "Slightly Mild") in step 34 is quantified into a score of 1-4 based on the enterprise's compliance risk consequences (e.g., "Extremely Severe" corresponds to 4 points, representing the possibility of administrative penalties and significant brand damage; "Slightly Severe" corresponds to 3 points, representing the possibility of customer complaints and internal rectification; "Medium" corresponds to 2 points, and "Slightly Mild" corresponds to 1 point), denoted as S1; at the same time, S1 is weighted by domain according to the domain of the extended rules associated with the risk point (e.g., the weighting coefficient for data security and anti-monopoly domains is set to 1.2 due to high legal risks; the weighting coefficient for labor and employment domains is set to 1.0), resulting in S1' = S1 × domain weighting coefficient.

[0103] 2. Quantification of the scope of affected entities: Based on the "initial number of affected entities", the number of entities is weighted according to the "business importance level" in the business scenario data (the weight of core business entities is set to 1.5, and the weight of non-core business entities is set to 1.0). The total number of affected entities after weighting is calculated (e.g., if the initial number of affected entities is 5, including 3 core entities and 2 non-core entities, the weighted number is 3×1.5+2×1.0=6.5). The weighted number is then mapped to a quantitative value S2 of 0-2 (e.g., weighted number ≤ 3 corresponds to 0.5, 3 < number ≤ 6 corresponds to 1.0, and number > 6 corresponds to 2.0. The mapping range is determined based on the correlation data between the enterprise's historical risk impact range and losses).

[0104] 3. Transmission Probability Integration Dimension: Take the mean of "transmission probability of all paths" in the path transmission data, denoted as P (e.g., if a risk point is associated with 3 paths, the transmission probabilities are 0.8, 0.7, and 0.6 respectively, and the mean P = 0.7); map P to a quantitative value S3 of 0-2 (P≤0.3 corresponds to 0.5, 0.3<P≤0.6 corresponds to 1.0, and P>0.6 corresponds to 2.0. The mapping basis is "the higher the transmission probability, the greater the possibility of subsequent losses caused by risk diffusion").

[0105] The final severity quantification value S is calculated using a weighted summation: S = (S1' × 0.5) + (S2 × 0.3) + (S3 × 0.2). The weights are allocated based on the contribution of each dimension to the "risk severity" (the rule level directly determines the inherent attributes of the risk and has the highest weight; the scope of influence determines the breadth of risk coverage and has the next highest weight; the transmission probability determines the risk diffusion potential and has a relatively low weight). For example, for a certain risk point, S1' = 3 × 1.2 = 3.6 ("relatively severe" level + data security domain), S2 = 1.0 (weighted number of affected entities 6.5), and S3 = 2.0 (mean transmission probability 0.7), then S = 3.6 × 0.5 + 1.0 × 0.3 + 2.0 × 0.2 = 1.8 + 0.3 + 0.4 = 2.5. This value is the severity quantification value of the potential compliance risk point, with a range of 0.5-3.8 (obtained by summing the maximum values ​​of each dimension), which facilitates the matrix determination in subsequent step 42.

[0106] Preferably, in a scenario, when evaluating the diffusion coefficient D of the associated transmission path in step 41, the focus is on three factors: "path transmission capability + entity association strength + business dependence," avoiding the traditional single evaluation based solely on transmission probability. The diffusion coefficient D describes the ease with which risk spreads along the path, with a numerical range of 0-1 (the closer to 1, the stronger the diffusion capability). The calculation logic is based on the path transmission data and business scenario data in the risk point assessment basic data table, specifically in three steps:

[0107] 1. Calculation of the mean of path transmission probability: Take the arithmetic mean of the path transmission probabilities of all associated transmission paths of the risk point, and denot it as P_avg (e.g., if the probability of path 1 is 0.8 and the probability of path 2 is 0.6, P_avg=0.7). This value reflects the basic probability of diffusion of the path itself, and is denoted as D1=P_avg.

[0108] 2. Quantification of Entity Association Strength: Based on the "type of association relationship of entities involved in the path" in the risk transmission path diagram (semantic association relationship from the enterprise multi-source intelligence knowledge graph library), the association relationship is divided into three levels according to "compliance risk transmission relevance" - Level 1 association (relationships that directly transmit risks, such as data transmission and data storage authorization), strength value 0.9; Level 2 association (relationships that indirectly transmit risks, such as business collaboration and data sharing), strength value 0.6; Level 3 association (weak association relationship, such as office communication and equipment borrowing), strength value 0.3; calculate the average association strength of all paths of this risk point, denoted as D2.

[0109] 3. Business Process Dependency Measurement: Based on the "process criticality" of the business processes involved in the path (business scenario data from the risk point assessment basic data table), the process criticality is divided into three levels: core processes (such as cross-border data transmission, user data storage), with a dependency value of 0.8; important processes (such as supplier data integration), with a dependency value of 0.5; and auxiliary processes (such as internal document sharing), with a dependency value of 0.2. The average dependency value of all processes involved in the path of this risk point is taken and denoted as D3.

[0110] The final diffusion coefficient D is calculated using a weighted product (to avoid the uncontrolled range caused by the superposition of values ​​of various factors): D = (D1^0.4) × (D2^0.3) × (D3^0.3). The weight index is based on the sensitivity of each factor to the "diffusion capability" (path transmission probability is a direct factor, with the highest index; entity association strength and business dependence are indirect factors affecting diffusion efficiency, with the next highest index). For example, for a certain risk point, D1 = 0.7, D2 = 0.9 (both are first-level associations), and D3 = 0.8 (core process), then D = (0.7^0.4) × (0.9^0.3) × (0.8^0.3) ≈ 0.88 × 0.97 × 0.93 ≈ 0.80. This value represents that the association transmission path diffusion capability of this risk point is relatively strong.

[0111] Preferably, the final step of step 41 requires a reasonableness check on the severity quantification value S and the diffusion coefficient D to ensure that the assessment results conform to the actual risk logic of the enterprise's compliance scenario. The processing objects are the calculated S and D; the processing action is "dual-dimensional verification": first, numerical range verification (S must be within the range of 0.5-3.8, and D must be within the range of 0-1. If they are outside the range, the basic data and calculation logic must be re-checked. For example, if S>3.8, it may be a rule level quantification error, and the rule severity level label in step 34 needs to be rechecked); second, logical consistency verification (if S≥2.5 and D≥0.7, it needs to be confirmed whether the risk point corresponds to the enterprise's key compliance areas, such as data security and anti-monopoly. If it corresponds to non-key areas, the area weighting coefficient needs to be adjusted; if S<1.0 and D<0.3, it needs to be confirmed whether it is a low-risk point to avoid over-evaluation); the processing result is a "Risk Point Assessment Parameter Confirmation Table", which includes "Risk Point ID - Severity Quantification Value S - Diffusion Coefficient D - Verification Result". This table is directly used as the input parameter of the risk matrix model in step 42 to realize "path diagram analysis → parameter calculation → verification confirmation → output input", ensuring that the basis for subsequent risk level determination is reliable and reasonable.

[0112] Optionally, step 4 includes step 42: using a risk matrix model, based on the severity quantification value of potential compliance risk points and the diffusion coefficient of the associated transmission path, to determine the risk level and generate graded compliance risk warning information, wherein the risk level is divided into alert level, warning level, severe level and emergency level.

[0113] Preferably, the specific implementation process of step 42 is as follows: First, a risk matrix model adapted to the enterprise compliance scenario needs to be constructed. This matrix differs from the traditional general risk matrix and needs to combine the dual-dimensional characteristics of "severity of consequences - possibility of diffusion" of enterprise compliance risks, clarifying the physical meaning of the matrix rows and columns and the basis for interval division. The row dimension of the risk matrix model is the "quantitative value S of the severity of potential compliance risk points" (from step 41), reflecting the severity of the compliance consequences that the risk has caused or may cause; the column dimension is the "diffusion coefficient D of the associated transmission path" (from step 41), reflecting the ease or difficulty of the risk spreading in the enterprise's business chain. The interval division of the matrix rows and columns needs to be determined based on the enterprise's historical compliance risk case data and industry compliance standards.

[0114] Line range (S value range): Referring to the correspondence between "severity quantification value S - actual compliance loss" in historical cases, S is divided into three ranges: low severity range [S1_min, S1_max) (e.g., [0.5, 1.5), corresponding to the loss of "minor internal rectification with no external impact"), medium severity range [S2_min, S2_max) (e.g., [1.5, 2.5), corresponding to the loss of "specific internal rectification that may trigger customer inquiries"), and high severity range... (For example, [2.5, 3.8] corresponds to losses such as "administrative penalties, negative brand impact, or legal proceedings").

[0115] Column intervals (D value intervals): Referring to the correspondence between "diffusion coefficient D - actual diffusion range" in historical cases, D is divided into three intervals: low diffusion interval [D1_min, D1_max) (e.g., [0, 0.4), corresponding to a diffusion range of "only anchor point entity and 1 downstream entity"), medium diffusion interval [D2_min, D2_max) (e.g., [0.4, 0.7), corresponding to a diffusion range of "anchor point entity + 2-3 upstream and downstream entities"), and high diffusion interval... (e.g., [0.7,1] corresponds to the diffusion range of "anchor entity + 4 or more upstream and downstream entities, involving core business processes").

[0116] The cells at the intersection of the matrix are labeled with risk levels (advice level, warning level, severe level, emergency level). The labeling is based on the comprehensive risk impact of "severity of consequences in the row interval × probability of diffusion in the column interval" (e.g., high severity × high diffusion = emergency level, low severity × low diffusion = warning level). This ultimately forms a "compliance risk matrix table by field" (the threshold for the interval can be fine-tuned due to differences in compliance consequences in fields such as data security and anti-monopoly. For example, the lower limit of the high severity interval in the data security field is set to 2.2, and the lower limit in the labor and employment field is set to 2.5).

[0117] Preferably, in the specific technical implementation of step 42, based on the domain-specific compliance risk matrix table and the assessment parameters of step 41, a risk level determination is performed. The determination process needs to handle boundary values ​​and combine domain characteristics to ensure that the determination result meets the enterprise's compliance control requirements. The specific determination process is as follows:

[0118] 1. Parameter matching and interval positioning: Obtain the severity quantification value S (e.g., S=2.6) and diffusion coefficient D (e.g., D=0.8) of a potential compliance risk point. Based on the domain to which the risk point belongs (e.g., data security), retrieve the corresponding sub-domain compliance risk matrix table. Match the S value with the row interval (2.6 falls in the high severity interval [2.2,3.8] in the data security domain) and match the D value with the column interval (0.8 falls in the high diffusion interval [0.7,1]) to determine the target cell in the matrix.

[0119] 2. Special handling of boundary values: If S or D falls on the critical value of the interval (e.g., S=1.5, which is exactly the lower limit of the medium severity interval), then a "strict judgment" will be made based on the compliance policies of the area to which the risk point belongs. In areas with high legal risks such as data security and anti-monopoly, the critical value parameter will be judged according to the higher interval (S=1.5 will be judged according to the medium severity interval); in areas with relatively minor risk consequences such as labor employment, the critical value parameter can be judged according to the original interval (S=1.5 will still be judged according to the medium severity interval) to avoid underestimation of risk due to the critical value.

[0120] 3. Risk Level Confirmation and Secondary Verification: Based on the risk level marked in the target cell (e.g., high severity × high diffusion = emergency level), and combined with the "risk point label" of the risk point (from step 34, e.g., "unqualified storage of sensitive data"), verify the matching between the risk level and the risk type (e.g., "unqualified storage of sensitive data" belongs to the high-risk type of data security, and it is logically determined to be emergency level); if there is a logical contradiction (e.g., a low severity risk is determined to be severe level), then re-examine the parameter calculation process in step 41, correct it, and execute the determination again to finally obtain the risk level (e.g., emergency level) of the potential compliance risk point.

[0121] Preferably, in one scenario, when generating tiered compliance risk warning information in step 42, it must include three elements: "core risk information - summary of transmission path - compliance response suggestions," which differs from traditional simple warnings that only include the risk level, ensuring that the warning information has practical guiding value. The specific generation logic is as follows:

[0122] 1. Integration of core risk information: Extract basic information of risk points, including "risk point ID - domain - risk type (from step 34) - severity quantification value S - diffusion coefficient D - risk level" (e.g., "risk point ID: R001 - domain: data security - risk type: unqualified storage of sensitive data - S: 2.6 - D: 0.8 - risk level: emergency level"), as the core identifier of early warning information.

[0123] 2. Generation of Transmission Path Summary: Based on the risk transmission path diagram in step 35, extract the key transmission links of the risk point (such as "anchor entity FS-001 → upstream data transmission node A → downstream user data query terminal E"), mark the core risk entities in the link (such as "data transmission node A transmits without encryption") and the transmission probability (such as "the transmission probability of FS-001 → A is 0.8"), and form a concise transmission path summary to help technical personnel quickly locate the scope of risk spread.

[0124] 3. Tiered Compliance Response Recommendations: Pre-set response templates are matched according to the risk level, with differentiated recommendations for different levels:

[0125] Emergency Level: It is recommended to "immediately suspend the business operations of the risk-related entities (such as suspending the storage function of FS-001), initiate compliance rectification within 24 hours (such as supplementing the storage qualification application), and report to the enterprise's compliance management department simultaneously";

[0126] Severity level: It is recommended to "complete the compliance verification of the risk-related entities within 3 working days, formulate and publicize the rectification plan, and submit the rectification progress to the compliance management department weekly";

[0127] Warning level: It is recommended to "complete the risk assessment within 7 working days, monitor the spread of the related transmission path, and strengthen data recording without suspending business."

[0128] Warning level: It is recommended to "pay close attention to this risk point during monthly compliance checks and continuously monitor changes in the entity's compliance attributes (such as filing status and qualification validity period)".

[0129] 4. Structured output of early warning information: Organize the above three elements in the format of "title-core information-transmission path-response suggestions" to generate structured early warning information (such as the title "[Data Security Emergency Early Warning] Risk of storing sensitive data without qualifications"), to ensure that the information hierarchy is clear and that technical personnel can directly implement compliant response operations based on the suggestions.

[0130] Preferably, step 42 concludes by summarizing and prioritizing all potential compliance risk warnings to form a "Company Compliance Risk Warning Summary Table," facilitating coordinated handling by the company's compliance management department. The sorting logic is based on "risk level priority + area importance as a supplement": Emergency warnings are prioritized (e.g., ranked in the top 10), followed by severe warnings, and then warnings and alerts. Within the same level, warnings in core compliance areas such as data security and anti-monopoly are prioritized (e.g., within the emergency level, data security warnings precede anti-monopoly warnings). The summary table includes "warning ranking number - core risk information - full-text link to warning information," enabling technical personnel to quickly locate high-priority warnings and view details, achieving "level determination → information generation → summary sorting," ensuring that companies can efficiently handle compliance risks according to priority.

[0131] Figure 2 This is a schematic diagram of the structure of a multi-source intelligence semantic parsing and compliance risk early warning device according to an embodiment of this application. Figure 2 As shown, the device includes: an intelligent processing device storing an enterprise multi-source intelligence knowledge graph library and an enterprise compliance rule inference engine. The enterprise multi-source intelligence knowledge graph library contains multi-source intelligence entities and semantic relationships between them. The enterprise compliance rule inference engine is used to call a multi-level compliance rule library, which contains domain-specific compliance clauses and associated risk transmission rules. The device includes: a transformation unit for converting multi-source heterogeneous intelligence data into a unified semantic representation vector through a cross-modal semantic mapping model; a parsing unit for performing entity linking and relationship inference on the unified semantic representation vector based on the enterprise multi-source intelligence knowledge graph library to generate an intelligence semantic parsing graph; a matching unit for matching the multi-level compliance rule library with the intelligence semantic parsing graph through the enterprise compliance rule inference engine, mining and evaluating the severity and associated transmission paths of potential compliance risk points to generate a risk transmission path diagram; and an early warning unit for generating tiered compliance risk early warning information based on the risk transmission path diagram.

[0132] The above Figure 2 The specific implementation of each unit in the embodiment can be found in the above. Figure 1 The details of that record will not be repeated here.

[0133] The relative descriptions such as "superior," "lower," and "more reasonable" mentioned in this application should be objectively understood in conjunction with the technical background and existing technical level of enterprise compliance intelligence processing, and are not intended to describe an absolute ideal state of technical effect. For those skilled in the art, the core function of such descriptions is to objectively reflect the relative improvement in technical effect achieved by this application in terms of technical indicators such as multimodal semantic fusion, entity association analysis completeness, and risk transmission assessment accuracy (e.g., semantic fragmentation caused by independent processing of multimodal intelligence, lack of compliance association reasoning between entities, and ignoring the transmission effect when judging risks based on a single clause), in response to the limitations of similar multi-source intelligence compliance early warning solutions in existing technologies (such as semantic fragmentation caused by independent processing of multimodal intelligence, lack of compliance association reasoning between entities, and ignoring the transmission effect when judging risks based on a single clause). That is, compared with existing technologies, the solution of this application presents superior performance in terms of the rationality of multimodal intelligence semantic fusion, the clarity of compliance risk entity association, the comprehensiveness of risk transmission path assessment, and the guidance value of graded early warning, rather than an absolute commitment to technical effect. This approach to description meets the requirements of rigor in technical solution description, enabling those skilled in the art to clearly identify the differences in technical effects between this application and existing technologies, and accurately grasp the improvement value of the solution in the context of refined management of enterprise compliance risks.

Claims

1. A method for multi-source intelligence semantic parsing and compliance risk early warning, characterized in that, The method is applied to intelligent processing devices, which store an enterprise multi-source intelligence knowledge graph and an enterprise compliance rule inference engine. The enterprise multi-source intelligence knowledge graph contains multi-source intelligence entities and semantic relationships between them. The enterprise compliance rule inference engine is used to call a multi-level compliance rule library, which contains domain-specific compliance clauses and associated risk transmission rules. Step 1: Transform multi-source heterogeneous intelligence data into a unified semantic representation vector through a cross-modal semantic mapping model; Step 2: Based on the enterprise's multi-source intelligence knowledge graph database, perform entity linking and relationship reasoning on the unified semantic representation vector to generate an intelligence semantic parsing graph; Step 3: Use the enterprise compliance rule reasoning engine to call the multi-level compliance rule library and the intelligence semantic analysis graph to match, mine and assess the severity of potential compliance risk points and the associated transmission path to generate a risk transmission path diagram; Step 4: Generate tiered compliance risk warning information based on the risk transmission path diagram; Specifically, step 1 includes: Step 11: For text-based intelligence data, a first language model incorporating enterprise domain word vectors is used for word segmentation and semantic encoding to generate text semantic vectors; Step 12: For image-based intelligence data, visual features are extracted using a convolutional neural network, and a modality transformation matrix is ​​constructed in conjunction with an enterprise entity tag library to map the visual features to the text semantic space where the text semantic vector is located and generate image semantic vectors accordingly. Step 13: Convert audio intelligence data to generate transcribed text, perform sentiment analysis on the transcribed text to obtain sentiment features, and integrate the sentiment features into a trained second language model for encoding to generate audio semantic vectors that can be mapped to the text semantic space where the text semantic vectors are located. Step 14, which includes: Step 141: Calculate the cosine similarity between the text semantic vector, image semantic vector, and audio semantic vector and the reference vector of the text semantic space; Step 142: Calculate the semantic contribution weights of text semantic vectors, image semantic vectors, and audio semantic vectors based on cosine similarity to generate a unified semantic representation vector. Step 3 includes: Step 31: The enterprise compliance rule reasoning engine calls the multi-level compliance rule library to match the intelligence semantic parsing graph with compliance clauses in different fields to form initial risk rules. The multi-level compliance rule library is divided into sub-libraries for data security, anti-monopoly, cross-border trade and labor employment according to the field. Step 32: Analyze the upstream and downstream related entities, business process nodes and scope of impact involved in the initial risk rules using the associated risk transmission rules, in order to generate extended risk rules; Step 33: Calculate the semantic matching degree between the extended risk rule and the multi-source intelligence entity association content in the intelligence semantic parsing graph using a bidirectional long short-term memory model, and correct the semantic matching degree using the intelligence timeliness parameter to obtain the corrected matching degree. Step 34: Mark the multi-source intelligence entity association and business process association content corresponding to the rules whose corrected matching degree exceeds the preset matching degree threshold in the intelligence semantic parsing graph as potential compliance risk points, and assess the severity of potential compliance risk points in combination with the rule severity level, the number of affected entities and the transmission probability to use as the label of potential compliance risk points. Step 35: Based on the tags of potential compliance risk points, track the related entities and relationship paths of potential compliance risk points in the intelligence semantic parsing graph to generate a risk transmission path diagram.

2. The method according to claim 1, characterized in that, Step 142 specifically includes: Step 1421: Based on the semantic contribution weights of the text semantic vector, image semantic vector, and audio semantic vector, perform a weighted summation of the text semantic vector, image semantic vector, and audio semantic vector to obtain the initial fusion vector; Step 1422: Calculate the semantic deviation values ​​between the initial fusion vector and the text semantic vector, image semantic vector, and audio semantic vector. If the semantic deviation value exceeds a preset threshold, readjust the semantic contribution weights and perform weighted summation again until the deviation value is lower than the preset threshold. Then, use the corresponding initial fusion vector as the unified semantic representation vector.

3. The method according to claim 2, characterized in that, Step 2 specifically involves: based on the unified semantic representation vector, selecting candidate multi-source intelligence entities that match the unified semantic representation vector from the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library, and performing entity link reasoning and implicit relationship reasoning based on the candidate multi-source intelligence entities to construct an intelligence semantic parsing graph.

4. The method according to claim 3, characterized in that, Step 2 includes: Step 21: Calculate the cosine similarity between the unified semantic representation vector and the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library, so as to select candidate multi-source intelligence entities that match the unified semantic representation vector from the multi-source intelligence entities in the enterprise multi-source intelligence knowledge graph library. Step 22: Combine the entity attribute information of multi-source intelligence entities and perform entity link reasoning through the entity attribute attention mechanism to determine the target multi-source intelligence entity from the candidate multi-source intelligence entities. Step 23: Based on the preset industry relationship extraction rules and the semantic association between multi-source intelligence entities, construct an intelligence semantic parsing graph containing timestamp attributes.

5. The method according to claim 4, characterized in that, Step 23 specifically includes: Step 231: Based on the preset industry relationship extraction rules and the semantic relationship between multi-source intelligence entities, perform implicit relationship reasoning on the target multi-source intelligence entities through graph neural networks to generate implicit relationship results. Step 232: Based on the results of implicit relationships, construct an intelligence semantic parsing graph that includes timestamp attributes.

6. The method according to claim 1, characterized in that, Step 4 specifically involves: determining the risk level based on the risk transmission path diagram to generate tiered compliance risk early warning information, which includes: Step 41: Based on the risk transmission path diagram, assess the quantitative value of the severity of potential compliance risk points and the diffusion coefficient of the associated transmission path; Step 42: Using a risk matrix model, based on the severity quantification value of potential compliance risk points and the diffusion coefficient of the associated transmission path, determine the risk level to generate graded compliance risk warning information. The risk levels are divided into alert level, warning level, severe level and emergency level.

Images