Enterprise data hierarchical desensitization and result recovery method for cloud large language model inference

Abstract

The application provides an enterprise data layered desensitization and result recovery method for cloud large language model reasoning, comprising: performing entity extraction on enterprise data to obtain entity fields included in the enterprise data; performing field splitting on each entity field to obtain first subfields included in each entity field; replacing the first subfields with second subfields to obtain replaced entity fields, the second subfields being virtual entity fields; performing model reasoning on the replaced entity fields through a cloud model to obtain reasoning results corresponding to the replaced entity fields; and replacing the second subfields in the reasoning results with the first subfields to obtain an enterprise portrait corresponding to the enterprise data. In this way, the accuracy of the generated enterprise portrait can be improved while ensuring the privacy of the enterprise data.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method for layered desensitization and result recovery of enterprise data for cloud-based large language model inference. Background Technology

[0002] As enterprises become increasingly digitalized, more and more companies need to build their corporate profiles using cloud-based models. However, the data used to build these profiles often contains sensitive information, which can easily lead to data leaks if directly uploaded to the cloud model. To avoid data leaks, companies often perform overall data anonymization, but these methods often lack fine-grained identification and differentiated processing of the data, resulting in insufficient protection of sensitive fields and damage to the semantic information of the data. Summary of the Invention

[0003] This invention provides a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference. It addresses the shortcomings of existing technologies that damage the semantics of enterprise data during the desensitization process, leading to inaccurate enterprise profiles. This method improves the accuracy of generated enterprise profiles while ensuring the privacy of enterprise data.

[0004] This invention provides a method for hierarchical de-identification and result recovery of enterprise data for cloud-based large language model inference, comprising:

[0005] Entity extraction is performed on the enterprise data to obtain the entity fields included in the enterprise data;

[0006] For each entity field, perform field splitting to obtain the first subfield included in each entity field;

[0007] Replace the first subfield with the second subfield to obtain the replaced entity field, where the second subfield is a virtual entity field;

[0008] By using a cloud-based model, model reasoning is performed on the replaced entity fields to obtain the reasoning results corresponding to the replaced entity fields;

[0009] Replace the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0010] According to the present invention, a method for hierarchical de-identification and result recovery of enterprise data for cloud-based large language model inference is provided, wherein the method involves splitting each entity field to obtain a first sub-field comprising each entity field, including:

[0011] Perform the following processing for each of the entity fields:

[0012] Perform type identification on the entity field to obtain the field type corresponding to the entity field;

[0013] When the field type is a field type included in the type mapping table, each entity field is split according to the mapping relationship of the type mapping table to obtain the first sub-field included in each entity field.

[0014] According to the present invention, a method for hierarchical de-identification and result recovery of enterprise data for cloud-based large language model inference is provided, the method further comprising:

[0015] When the field type indicates that the entity field is a structured field, regular expression matching is performed on the entity field to obtain the matching field of the entity field;

[0016] Using the matching field as the first subfield, the entity field is split to obtain all the first subfields included in each entity field.

[0017] According to the present invention, a method for hierarchical de-identification and result recovery of enterprise data for cloud-based large language model inference is provided, the method further comprising:

[0018] When the field type indicates that the entity field is a nested type, the entity field is recursively traversed to obtain the nested fields included in the entity field;

[0019] The nested field is used as the first subfield, and the entity field is split to obtain all the first subfields included in each entity field.

[0020] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, before replacing the first sub-field with the second sub-field to obtain the replaced entity field, the method further includes:

[0021] Perform field attribute identification on the first sub-field to obtain the field attributes of each first sub-field;

[0022] The step of replacing the first subfield with the second subfield to obtain the replaced entity field includes:

[0023] The first subfield, which represents the identity identifier, is replaced with the second subfield to obtain the replaced entity field.

[0024] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference is provided, wherein replacing the first subfield with the second subfield to obtain the replaced entity field includes:

[0025] The first subfield and the first identifier are concatenated to obtain the concatenated field, where the first identifier is the round identifier for entity extraction of the enterprise data;

[0026] A hash calculation is performed on the concatenated field to obtain the hash value of the concatenated field, and a pseudo-random value corresponding to the hash value is generated based on the pseudo-random generation function;

[0027] The pseudo-random values ​​are subjected to repeatability testing to obtain repeatability testing results;

[0028] When the repeatability test result indicates that the pseudo-random value has passed the repeatability test, the pseudo-random value is used as the second sub-field.

[0029] Replace the first subfield with the second subfield to obtain the replaced entity field.

[0030] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference is provided, wherein replacing the first subfield with the second subfield to obtain the replaced entity field includes:

[0031] When the field attribute indicates that the first subfield is a statistical number type field, a perturbation value is randomly selected from a preset perturbation range;

[0032] The disturbance value and the first subfield are multiplied to obtain a first product result, and the first product result is used as the second subfield;

[0033] Replace the first subfield with the second subfield to obtain the replaced entity field.

[0034] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference is provided, wherein replacing the first subfield with the second subfield to obtain the replaced entity field includes:

[0035] When the field attribute indicates that the first subfield is a door number address, a virtual door number address is randomly generated, and the virtual door number address is used as the second subfield;

[0036] Replace the first subfield with the second subfield to obtain the replaced entity field.

[0037] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, before performing model inference on the replaced entity field through a cloud model to obtain the inference result corresponding to the replaced entity field, the method further includes:

[0038] Extract the company's registered address and address name from the replaced entity fields;

[0039] A consistency check is performed on the enterprise's registered address and the address name to obtain the consistency check result;

[0040] When the consistency detection result indicates that there is no address conflict between the enterprise registration address and the address name, the replacement entity field is subjected to model reasoning through the cloud model to obtain the reasoning result corresponding to the replacement entity field.

[0041] According to the present invention, a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, after replacing the first sub-field with the second sub-field to obtain the replaced entity field, the method further includes:

[0042] Construct a first mapping table between the first subfield and the second subfield, where the key in the first mapping table is the first subfield and the value is the second subfield;

[0043] The first mapping table is transformed to obtain a second mapping table, where the key in the second mapping table is the second subfield and the value is the first subfield.

[0044] The step of replacing the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data includes:

[0045] Based on the mapping relationship in the second mapping table, the second subfield in the reasoning result is replaced with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0046] This invention also provides a module for layered de-identification and result recovery of enterprise data for cloud-based large language model inference, comprising the following modules:

[0047] The extraction module is used to extract entities from enterprise data to obtain the entity fields included in the enterprise data;

[0048] The splitting module is used to split each entity field to obtain the first subfield included in each entity field;

[0049] The replacement module is used to replace the first subfield with the second subfield to obtain the replaced entity field, where the second subfield is a virtual entity field;

[0050] The inference module is used to perform model inference on the replaced entity fields through the cloud model to obtain the inference result corresponding to the replaced entity fields;

[0051] The replacement module is also used to replace the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0052] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the enterprise data layering desensitization and result recovery method for cloud-based large language model inference as described above.

[0053] The present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the enterprise data layering desensitization and result recovery method for cloud-based large language model inference as described above.

[0054] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the enterprise data layering desensitization and result recovery method for cloud-based large language model inference as described above.

[0055] This invention provides a method for layered desensitization and result recovery of enterprise data for cloud-based large language model inference. First, it extracts entity fields from enterprise data that can be processed subsequently, enabling the structured identification of valid entity information in the original enterprise data, providing processing objects for subsequent field splitting, field replacement, and model inference. Then, each entity field is further split into a first subfield, allowing the identification of fine-grained field content within the entity field. Obtaining the first subfield improves the granularity of subsequent field replacement, avoiding the problem of overly coarse replacement granularity caused by directly processing the entire entity field. Next, the first subfield is replaced with a second subfield to obtain the replaced entity field. Since the second subfield is a virtual entity field, this step reduces the risk of directly exposing the first subfield, enabling subsequent cloud-based... The model processes the replaced entity fields, rather than entity fields that directly contain the original first subfield, thereby improving data security during enterprise data processing. Next, the cloud-based model performs model inference on the replaced entity fields to obtain the corresponding inference results. Since the model inference object is the replaced entity field, the original first subfield is avoided from being directly exposed during the cloud model inference process while processing is being done using the cloud model. Finally, after obtaining the inference results, the second subfield in the inference results is replaced with the first subfield, thus obtaining the enterprise profile corresponding to the enterprise data. This step ensures that the final enterprise profile maintains a correspondence with the first subfield in the original enterprise data, preventing the final result from containing only virtual entity fields and being difficult to match with the enterprise data, thus improving the usability and accuracy of the enterprise profile. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0057] Figure 1 This is a schematic diagram of the first process of an enterprise data layering desensitization and result recovery method for cloud-based large language model inference provided by the present invention.

[0058] Figure 2 This is a schematic diagram of the second process of an enterprise data layering desensitization and result recovery method for cloud-based large language model inference provided by the present invention.

[0059] Figure 3 This is a flowchart illustrating the actual implementation of an enterprise data layering desensitization and result recovery method for cloud-based large language model inference, provided by the present invention.

[0060] Figure 4 This is a schematic diagram of the first process of text desensitization provided by the present invention.

[0061] Figure 5 This is a schematic diagram of the second process of text desensitization provided by the present invention.

[0062] Figure 6 This is a schematic diagram of the structure of an enterprise data layering desensitization and result recovery device for cloud-based large language model inference provided by the present invention.

[0063] Figure 7 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0065] The following is combined with Figures 1-5 This invention describes a method for layered de-identification and result recovery of enterprise data for cloud-based large language model inference.

[0066] Figure 1 This is a schematic diagram of the first process of an enterprise data layering de-identification and result recovery method for cloud-based large language model inference provided by the present invention, as shown below.Figure 1 As shown, the method includes the following:

[0067] In step 101, entity extraction is performed on the enterprise data to obtain the entity fields included in the enterprise data.

[0068] As an example, enterprise data refers to structured or semi-structured data records containing enterprise attribute information, such as a data set including at least one field: enterprise name, registered address, identity identifier, and industry type. Enterprise data serves as the input object for entity extraction and provides the basic data for subsequent field splitting, field replacement, model inference, and enterprise profile generation. Specifically, enterprise data could be: Enterprise Name: Company A Technology Co., Ltd.; Enterprise Registered Address: [City, District, Road]; Industry Type: Software Services; Identity Identifier: Unified Social Credit Code.

[0069] Entity extraction refers to identifying and extracting content with business meaning and processing value from enterprise data. Entity extraction involves determining entity fields from enterprise data. Through entity extraction, subsequent processing flows can be executed around entity fields, rather than processing all enterprise data indiscriminately. The specific process of entity extraction can be to identify the enterprise name, enterprise registered address, identity identifier, and industry type from enterprise data, and use the identified content as entity fields.

[0070] Entity fields refer to fields in enterprise data that can represent enterprise attributes or identity, extracted through entity data. Entity fields are the objects of subsequent field splitting and further form the first subfield. Specifically, in enterprise data, fields such as enterprise registration address, identity identifier, and industry type can all be used as entity fields.

[0071] As an example, when the server executes the enterprise profile building process, it can first obtain enterprise data. Enterprise data can be collected by the terminal and sent to the server, or the server can read it directly from the business system.

[0072] After obtaining enterprise data, the server can format the data. Specifically, it can format the data according to field names, field contents, and field delimiters. Formatting the enterprise data can improve the stability of entity extraction.

[0073] Subsequently, the server can perform entity extraction on the enterprise data. Entity extraction can be performed based on entity extraction conditions. The server identifies the content in the enterprise data and determines whether the content in the enterprise data meets the entity extraction conditions. The entity extraction conditions can be as follows: first, entity identification is performed on the enterprise data. If it is determined that entity data exists in the enterprise data, the entity extraction conditions are met. For example, if the enterprise data is "Company Name: A City Jia Technology Co., Ltd.", and it contains the entity data "Company Name" and "A City Jia Technology Co., Ltd.", then the entity extraction conditions are met. If it is determined that entity data does not exist in the enterprise data, then the entity extraction conditions are not met. For example, if the enterprise data is "Remark: Purchased printing paper this afternoon", and it does not include entity data related to building the enterprise profile, then the entity extraction conditions are not met.

[0074] When the judgment result is that the entity extraction conditions are met, the server will identify the content that meets the entity extraction conditions as the entity fields included in the enterprise data and output the entity fields. For example, when the content in the enterprise data includes information related to building an enterprise profile, such as the enterprise's registered address, identity identifier, or industry type, the server can identify the corresponding data as entity fields.

[0075] When the judgment result indicates that the entity extraction condition is not met, the server will not identify the corresponding content as an entity field and will continue to perform entity extraction on other data in the enterprise data.

[0076] As an example, the specific process of entity extraction can be as follows: After the server obtains enterprise data, it identifies the field names and content in the enterprise data, determining whether the field names or content can represent enterprise attributes, enterprise identity, or enterprise address information, etc., which are related to building an enterprise profile. When the field names or content can represent enterprise attributes, enterprise identity, or enterprise address information, etc., which are related to building an enterprise profile, the corresponding field is identified as an entity field included in the enterprise data; when the field names or content cannot represent enterprise attributes, enterprise identity, or enterprise address information, etc., which are related to building an enterprise profile, the corresponding field is not identified as an entity field. For example, if the enterprise data includes "Enterprise Name: Jia Technology Co., Ltd.; Unified Social Credit Code: 9111XXXXXXXXXXXXXX; Registered Address: No. 10, a certain road, B District, City A; Remarks: Key Follow-up Customer", after the server performs entity extraction on the enterprise data, it can identify the fields corresponding to "Enterprise Name", "Unified Social Credit Code", and "Registered Address" as entity fields, while "Remarks" is not considered an entity field.

[0077] As an example, after acquiring enterprise data in the enterprise profile construction scenario, the server can also load entity extraction rules. These rules are used to identify enterprise name, registered address, identity identifier, industry type, and enterprise type. The server then performs preliminary entity extraction on the enterprise data based on these rules to obtain candidate entity fields. Candidate entity fields are fields that meet the entity extraction rules but have not yet been confirmed. The server then confirms these candidate entity fields using an entity recognition model. If the entity recognition model outputs a result indicating that a candidate entity field belongs to an entity field included in the enterprise data, the server identifies the candidate entity field as an entity field. If the entity recognition model outputs a result indicating that a candidate entity field does not belong to an entity field included in the enterprise data, the server does not output the candidate entity field as an entity field.

[0078] By extracting entities from enterprise data, the entity fields included in the enterprise data can be obtained, giving the enterprise profile building process a clear processing object. Compared with processing the complete enterprise data directly, entity extraction can reduce the involvement of non-entity content in subsequent field splitting, field replacement and model reasoning, and improve the accuracy of subsequent processing.

[0079] In step 102, each entity field is split to obtain the first subfield included in each entity field.

[0080] As an example, field splitting refers to the decomposition of entity fields, separating the multiple information units contained within the entity field. Field splitting can convert an entity field into at least one first subfield, allowing the enterprise profile building process to obtain more granular data objects. For example, for the entity field "Registered Address: No. 1, C Street, District B, City A", field splitting can yield the first subfields "City A", "District B", and "No. 1, C Street".

[0081] As an example, after the server obtains the entity fields included in the enterprise data, it performs field splitting processing on each entity field in turn. The server can read the field name and field content of the entity field and determine the field splitting method based on the structure of the field content.

[0082] The server first determines whether the entity field meets the field splitting conditions. The field splitting conditions are used to characterize whether there are separable information units in the entity field. The field splitting conditions may include: whether there are delimiters in the entity field, whether there are multiple consecutive business field boundaries in the entity field, or whether the content of the entity field includes multiple components that can independently express enterprise information.

[0083] When an entity field meets the field splitting condition, the server splits the entity field to obtain multiple first subfields included in the entity field.

[0084] When an entity field does not meet the field splitting conditions, the server can output the entire entity field as a first subfield.

[0085] As an example, the server can also read the corresponding field content for each entity field and load the splitting rules related to field splitting. The server splits each entity field according to the splitting rules to obtain the first subfields included in each entity field. The splitting rules can serve as the processing basis for field splitting, that is, to determine which contents in the entity field can be split into the first subfield. The splitting rules can include processing basis such as symbol separator, field length, field position or business field boundary. Specifically, when the entity field includes a separator, the splitting rules can split the entity field into multiple first subfields according to the separator. For example, if the entity field is "Revenue Amount: 3000", then the entity field can be split into "Revenue Amount" and "3000".

[0086] By splitting each entity field, we can obtain the first subfield included in each entity field. This refines the data processing objects in the enterprise profile building scenario from complete entity fields to the first subfield. Compared with processing directly using complete entity fields, field splitting can reduce the information mixing problem caused by excessively coarse processing granularity and improve the distinguishability of information units within entity fields. As a result, the enterprise profile building process can perform data processing based on more accurate and finer-grained first subfields, solving the problem of affecting the accuracy of enterprise profiles due to unclear information boundaries within entity fields and imprecise processing objects.

[0087] In some embodiments, the field splitting for each entity field in step 102, to obtain the first sub-fields included in each entity field, can be performed as follows: Figure 2 Steps 1011 to 1012 shown are implemented as follows:

[0088] In step 1011, the following processing is performed for each entity field: the entity field is type identified to obtain the field type corresponding to the entity field.

[0089] As an example, type identification refers to the process of identifying the type of an entity field to determine the category to which the entity field belongs. For example, after type identification of the registered address: No. 1, C Street, B District, City A, the field type of the entity field can be determined to be an address field; after type identification of the unified social credit code: 9111XXXXXXXXXXXXXX, the field type of the entity field can be determined to be an identity identification field.

[0090] As an example, after the server obtains the entity fields included in the enterprise data, it can perform type identification for each entity field. Specifically, the server can read the field name, field content, and field format of the entity field, and determine the field type corresponding to the entity field based on the field name, field content, and field format.

[0091] The server first determines whether the entity field meets the preset type identification conditions. The preset type identification conditions refer to the conditions used to determine whether an entity field can be classified into a certain field type. The preset type identification conditions may include whether the field name contains the company name, registered address, identity identifier, etc., whether the field content conforms to the address expression format, whether the field content conforms to the identity identifier expression format, and whether the field content is in numeric form, etc.

[0092] When an entity field meets the preset type identification conditions, the server determines the field type corresponding to the entity field based on the preset type identification conditions. For example, when the field name of an entity field is "registered address" and the field content includes address components such as province, city, district, and street, the server can determine the field type corresponding to the entity field as an address field type; when the field name of an entity field is "unified social credit code" and the field content conforms to the identity identification expression form, the server can determine the field type corresponding to the entity field as an identity identification field type.

[0093] When an entity field does not meet the preset type recognition conditions, the server can determine the field type corresponding to the entity field as an unrecognized field type. The unrecognized field type is used to indicate that the server has not yet determined the specific field type of the entity field based on the existing preset type recognition conditions. For the unrecognized field type, it can be directly discarded, or the entity field of the unrecognized field type can be transmitted to the backend for manual confirmation.

[0094] As an example, for each entity field, the server can read the field name and field content, and determine whether the field name can represent the field type. When the field name can represent the field type, the server further determines whether the field content matches the field type corresponding to the field name. For example, if the field name is a mobile phone number, the server determines whether the field content is an 11-digit number. When the field content matches, the server determines the category corresponding to the field name as the field type corresponding to the entity field. When the field name cannot represent the field type, or the field content does not match the field type corresponding to the field name, the server directly performs type recognition based on the overall semantics of the field content and determines the field type corresponding to the entity field based on the overall semantics of the entity field. For example, if the entity field is "First Quarter: Revenue Amount 5000", the name of the entity field is "First Quarter". The field type of the entity field cannot be determined based on the name of the entity field. However, based on the entire entity field, the meaning expressed by the entity field is "The revenue in the first quarter is 5000", thus indicating that the field type of the entity field is a statistical number type.

[0095] As an example, for each entity field, the server can read the field content and identify the field format. The field format refers to the way the field content is composed of characters. Then, it can be determined whether the field format conforms to a preset field format, which is used to help determine the field type. When the field format conforms to the preset field format, the field type corresponding to the entity field can be determined according to the preset field format. For example, if the entity field is "136XXXXXXXX", which meets the preset field format of a mobile phone number, the field type of the entity field can be determined to be an identity identifier type.

[0096] By performing type identification on each entity field, the field type corresponding to the entity field can be obtained. This enables the enterprise profile building process to clearly distinguish the content attributes and business attributes of different entity fields. At the same time, different splitting methods can be adopted for entity fields of different types. Through differentiated processing, the accuracy of field splitting after identifying entity fields can be improved.

[0097] In step 1012, when the field type is a field type included in the type mapping table, each entity field is split according to the mapping relationship of the type mapping table to obtain the first sub-field included in each entity field.

[0098] As an example, a type mapping table is a data table that records the correspondence between field types and field splitting methods. The type mapping table is used to determine whether a field type has a corresponding field splitting basis and to provide a mapping relationship for field splitting. For example, the type mapping table can record that the address type corresponds to field splitting according to province, city, district, and detailed address, and the identity identifier type corresponds to field splitting according to the identity identifier as a whole or retaining it as a first subfield.

[0099] As an example, the server retrieves the field type for each entity field and reads the type mapping table, which records multiple field types and their corresponding mapping relationships. The server then matches the field type corresponding to the entity field with the field types included in the type mapping table.

[0100] When a field type is included in the type mapping table, the server reads the mapping relationship corresponding to the field type from the type mapping table. The server determines the field splitting method according to the mapping relationship and splits each entity field based on the field splitting method to obtain the first subfield included in each entity field. For example, if entity field A is "Enterprise Registration Address: No. 1, C Street, District B, City A", and the field type of entity field A is address type, the mapping relationship corresponding to address type in the type mapping table indicates that the entity field is split according to administrative region and detailed address. Then the server can split entity field A, and the first subfield obtained includes "City A", "District B", and "No. 1, C Street".

[0101] By splitting each entity field according to the mapping relationship in the type mapping table when the field type is one of the field types included in the type mapping table, the field splitting method can be matched with the field type. Compared with the uniform field splitting method, field splitting based on the type mapping table can reduce the problems of first subfield boundary error, first subfield content mixing and first subfield omission caused by mismatch of field splitting rules.

[0102] In some embodiments, the following can also be performed: Figure 2 Steps 1013 to 1014 are shown.

[0103] In step 1013, when the field type indicates that the entity field is a structured field, regular expression matching is performed on the entity field to obtain the matching field of the entity field.

[0104] As an example, a structured field refers to an entity field that has a fixed format, a fixed field order, or a fixed character composition rule. For example, the Unified Social Credit Code: 9111XXXXXXXXXXXXXX can be a structured field. The Unified Social Credit Code has a fixed character length and a fixed character composition rule.

[0105] Regular expression matching refers to the process of matching entity fields according to rules based on regular expressions. Regular expressions are the rule expressions related to regular expression matching, used to describe character length, character type, character position, or field format.

[0106] As an example, the server can obtain the field type corresponding to the entity field and determine whether the field type indicates that the entity field is a structured field.

[0107] When the field type represents an entity field as a structured field, the server reads the regular expression matching rules corresponding to the field type to limit the character length, character type, character position, or field format of the content to be identified in the structured field. Then, the server performs regular expression matching on the entity field based on the regular expression matching rules and determines whether there is any field content in the entity field that satisfies the regular expression matching rules.

[0108] When an entity field contains content that matches a regular expression rule, that content is identified as the matching field of the entity field. For example, if the entity field is the Unified Social Credit Code: 9111XXXXXXXXXXXXXX, the server performs regular expression matching based on the regular expression matching rule corresponding to the Unified Social Credit Code, and identifies the content that conforms to the fixed character length and character composition rules as the matching field.

[0109] When an entity field does not contain content that matches the regular expression rules, the matching field can be omitted from the output, or the entity field can be marked as a field where the regular expression match failed.

[0110] When the field type indicates that the entity field is not a structured field, the server does not perform the regular expression matching process based on structured fields on the entity field, thus avoiding forcibly including entity fields without a fixed format into the regular expression matching process of structured fields.

[0111] By applying regular expressions to entity fields when the field type represents a structured field, matching fields can be accurately identified based on the fixed format, fixed field order, or fixed character composition rules of the structured field. Compared with manual or general splitting methods, regular expression matching can reduce problems such as inaccurate identification of matching fields, omission of valid field content, and irrelevant field content entering subsequent processing flows.

[0112] In step 1014, the matching field is used as the first subfield, and the entity field is split to obtain all the first subfields included in each entity field.

[0113] As an example, the server obtains the entity field and the matching field obtained after performing regular expression matching on the entity field. The server establishes the correspondence between the entity field and the matching field and determines whether the matching field is empty.

[0114] When the matching field is not empty, the server uses the matching field as the first subfield and adds it to the set of first subfields corresponding to the entity field. Subsequently, the server continues to split the content of the fields in the entity field other than the matching field to obtain the other first subfields included in the entity field. The server aggregates the first subfields corresponding to the matching field and the first subfields corresponding to the other field content to obtain all the first subfields included in each entity field.

[0115] When the matching field is empty, the server does not perform the processing of using the matching field as the first subfield. Instead, the server can directly perform field splitting based on the entity field itself and use the field unit obtained from the field splitting as the first subfield.

[0116] During the field splitting process, the server can also determine whether there are duplicate field contents in the first subfield set. When there are duplicate field contents in the first subfield set, the server retains the first subfield corresponding to one duplicate field content and deletes the first subfield corresponding to other duplicate field contents. When there are no duplicate field contents in the first subfield set, the server directly outputs all the first subfields included in each entity field.

[0117] By using the matching field as the first subfield and splitting the entity field, the valid field content obtained from the regular expression matching can be included in the set of the first subfield, reducing the problem of incomplete entity field splitting results caused by missing matching fields.

[0118] In some embodiments, the following can also be performed: Figure 2 Steps 1015 to 1016 shown are implemented as follows:

[0119] In step 1015, when the field type indicates that the entity field is a nested type, the entity field is recursively traversed to obtain the nested fields included in the entity field.

[0120] As an example, after obtaining the field type corresponding to the entity field, the server can determine whether the field type indicates that the entity field is a nested type.

[0121] When the field type represents a nested entity field, the entity field can be recursively traversed. First, the first level of traversal is performed to identify the distinguishable field content at the current level, and this identified field content is used as the traversal result for the current level. Then, the server determines whether the traversal result for the current level contains sub-level field content that can be further traversed. For example, if the entity field is "General Manager A → Deputy Manager B, Deputy Manager C → Department Manager D → Employee E, Employee F", then the first level (General Manager) can be traversed, resulting in "General Manager A". Next, the Deputy General Manager level is traversed, resulting in "Deputy General Manager B" and "Deputy General Manager C". Then, the Department Manager level is traversed, resulting in "Department Manager D". Finally, the Employee level is traversed, resulting in "Employee E" and "Employee F".

[0122] When the current level's traversal result contains sub-level field content that can be further traversed, the server continues to traverse the sub-level field content until all levels' field content has been traversed. The server then uses the field content obtained from each level's traversal as the nested fields included in the entity field. For example, when the entity field is "Enterprise Registration Address: No. 1, C Street, B District, City A", after the server performs recursive traversal, the nested fields can include "City A", "B District", "C Street", and "No. 1".

[0123] When the current level's traversal result does not contain any sub-level field content that can be traversed further, the server stops recursively traversing and uses the current level's traversal result as the nested field included in the entity field.

[0124] When the field type does not indicate that the entity field is a nested type, the server does not perform recursive traversal based on the nested type on the entity field, thus avoiding forcibly including non-nested entity fields in the recursive traversal process.

[0125] After completing the recursive traversal, the server outputs the nested fields included in the entity fields and saves the correspondence between the entity fields and the nested fields so that the nested fields can be used as the first subfield or the enterprise profile building process can continue to be performed based on the nested fields.

[0126] As an example, when the field type represents an entity field as a nested type, the server recursively traverses the entity field to obtain the nested fields at each level. The server then determines whether there are any mergeable nested fields at each level. Mergeable nested fields refer to nested fields that have the same business meaning or the same field type. When there are mergeable nested fields at each level, the server merges the mergeable nested fields into one nested field and outputs the merged nested field. For example, in the employee level, the nested fields include nested field A "Employee A" and nested field B "Employee B". In this case, "Employee A" and "Employee B" can be merged to obtain the merged nested fields "Employee A, Employee B". When there are no mergeable nested fields at each level, the server directly outputs the nested fields at each level.

[0127] By recursively traversing the entity field when its type is nested, we can identify nested fields at each level within the entity field, thus fully decomposing the nested entity field. As a result, the enterprise profile building process can obtain nested fields and, based on these, derive a more complete set of first subfields, thereby improving the accuracy and completeness of the data processing objects during enterprise profile building.

[0128] In step 1016, the nested field is used as the first subfield, and the entity field is split to obtain all the first subfields included in each entity field.

[0129] As an example, the server obtains the entity fields and the nested fields obtained by recursively traversing the entity fields. The server establishes the correspondence between the entity fields and the nested fields and determines whether the nested fields are empty.

[0130] When a nested field is not empty, the server treats the nested field as the first subfield and adds it to the set of first subfields corresponding to the entity field. Subsequently, the server continues to split the content of the fields in the entity field other than the nested field to obtain the other first subfields included in the entity field. The server merges the first subfields corresponding to the nested field and the first subfields corresponding to the content of other fields to obtain all the first subfields included in each entity field.

[0131] During field splitting, the server can also determine whether there are duplicate field contents in the first subfield set. When duplicate field contents exist in the first subfield set, the server retains the first subfield corresponding to one duplicate field content and deletes the first subfields corresponding to other duplicate field contents. When there are no duplicate field contents in the first subfield set, the server directly outputs all the first subfields included in each entity field.

[0132] By using nested fields as the first child field and splitting the entity fields, the content of the nested fields obtained by recursive traversal can be included in all the first child fields included in each entity field, reducing the problem of incomplete first child field sets caused by missing nested fields.

[0133] In step 103, the first subfield is replaced with the second subfield to obtain the replaced entity field, where the second subfield is a virtual entity field.

[0134] As an example, the server obtains the first subfield included in each entity field. The server determines whether the first subfield meets the replacement condition. The replacement condition is used to determine whether the current first subfield needs to be replaced. The replacement condition may include: the first subfield belongs to a sensitive field type, the first subfield belongs to an identity field, the first subfield belongs to a field content that needs to be protected, or the field attribute corresponding to the first subfield meets the preset replacement condition. The preset replacement condition may be that the first subfield includes a house number.

[0135] When the first subfield meets the replacement condition, the server generates a second subfield. The generation method of the second subfield is related to the type or attribute of the first subfield. For example, when the first subfield is number 1, the server can generate number 8 as the second subfield. The content of the second subfield is different from the original content of the first subfield in terms of value, but the format is the same.

[0136] If the first subfield does not meet the replacement condition, the server will not replace the first subfield; the first subfield will remain in the entity field and no field replacement will be performed.

[0137] By replacing the first subfield with a virtual second subfield, the replaced entity field is obtained. This reduces the risk of direct exposure of the original field content in the enterprise data during subsequent cloud model inference. Compared with the overall masking method, this solution replaces the first subfield, which can preserve the overall structure of the entity field and reduce effective semantic loss.

[0138] In some embodiments, before performing step 103 to replace the first subfield with the second subfield and obtain the replaced entity field, the following technical solution may also be performed: perform field attribute identification on the first subfield to obtain the field attributes of each first subfield.

[0139] As an example, the server obtains the first subfield included in each entity field. The server performs field attribute recognition for each first subfield to obtain the field attributes of each first subfield. The field attributes can be the field attributes of the first subfield. The field attributes of the first subfield can be the same as or different from the field type of the entity field. For example, entity field A is "Registered Address: City A, District B, Street C". The field type of entity field A is identity identifier. The field type of the first subfield "Registered Address" is identity identifier. The first subfield "City A" is a city-level address. The first subfield "District B" is a district-level address. The first subfield "Street C" is a street-level address. The field attributes of the first subfield "Registered Address" are the same as the field attributes of entity field A. The field attributes of the first subfields "City A", "District B", and "Street C" are different from the entity type of entity field A.

[0140] The server reads the field content, field format, or field source of the first subfield and determines the field attribute of the first subfield based on the read information. Field attribute recognition can be based on preset field attribute judgment rules, which may include field name matching rules, field format matching rules, field length matching rules, and field content matching rules.

[0141] When the content of the first subfield matches the preset field attribute judgment rules, the server will determine the field attribute corresponding to the matching rule as the field attribute of the first subfield. For example, when the first subfield is a numeric character and has a length of 10 characters, the server can determine the field attribute as an identity field attribute; when the first subfield is a numeric character and is in numerical form, the server can determine the field attribute as a statistical number field attribute.

[0142] When the content of the first subfield does not conform to the preset field attribute judgment rules, the server can determine the field attribute as an unidentified field attribute, or mark the first subfield as a field attribute to be confirmed. The unidentified field attribute is used to indicate that the server has not yet determined the specific field attribute of the first subfield based on the existing rules.

[0143] After identifying the field attributes of each first subfield, the server outputs the field attributes of each first subfield and saves the correspondence between the first subfield and the field attributes, so that subsequent processing can perform differentiated processing on the first subfield based on the field attributes.

[0144] By identifying the field attributes of the first subfield, the field attributes of each first subfield are obtained. Different processing methods are used for different field attributes, which can reduce the problem of mismatched processing rules caused by using the same processing method for different first subfields and improve the accuracy of subsequent field replacement.

[0145] In some embodiments, replacing the first subfield with the second subfield in step 103 to obtain the replaced entity field can be achieved by the following technical solution: replacing the first subfield, which represents the field attribute as an identity identifier, with the second subfield to obtain the replaced entity field.

[0146] As an example, the server can pre-configure a set of field attribute recognition rules. The set of field attribute recognition rules has corresponding matching rules configured for the identity identifier field attribute. The matching rules include the unified social credit code format matching rules, the enterprise name suffix matching rules (such as matching strings ending with "Limited Company", "Joint-Stock Company", or "Limited Liability Company"), the legal representative's name format matching rules, the contact number format matching rules, and the email address format matching rules, etc.

[0147] The server inputs the first subfield into the field attribute recognition rule set one by one for rule matching. When the first subfield successfully matches any matching rule corresponding to the identity identifier, the server determines the field attribute of the first subfield as the identity identifier. When the first subfield does not match all the matching rules corresponding to the identity identifier, the server continues to match the first subfield with the matching rules corresponding to other field attributes to determine the field attribute belonging of the first subfield.

[0148] After determining the field attributes of each first subfield, the server filters out all first subfields whose field attributes represent identity identifiers. For each first subfield whose field attributes represent identity identifiers, the server generates a second subfield that matches the data type and format of that first subfield.

[0149] When the first subfield is a company name, a virtual company name can be randomly selected from a preset set of virtual company names as the second subfield, or the second subfield can be generated by concatenating a random string with common suffixes of company names; when the first subfield is a unified social credit code, the server randomly generates a code string that conforms to the encoding rules but does not point to any real company as the second subfield, according to the encoding rules of the unified social credit code; when the first subfield is a contact phone number, the second subfield generation module randomly generates a non-existent virtual phone number as the second subfield according to the phone number format.

[0150] After generating the second subfield, the server locates the position of the first subfield whose field attribute represents the identity identifier in the entity field, and replaces the first subfield at that position with the corresponding second subfield. The server can perform the replacement operation on all the first subfields whose field attribute represents the identity identifier in the entity field one by one to obtain the replaced entity field.

[0151] As an example, the server categorizes the first subfield, which represents an identity identifier, into identity identifier subcategories. These subcategories include direct identity identifiers and indirect identity identifiers. A direct identity identifier is one where a single first subfield can uniquely identify a specific enterprise, such as the Unified Social Credit Code or the full name of the enterprise. An indirect identity identifier is one where the first subfield needs to be combined with other fields to uniquely identify a specific enterprise, such as the abbreviation of the enterprise or the name of a branch office. For the first subfield of the direct identity identifier type, the server uses a completely random replacement strategy to generate the second subfield, ensuring that the second subfield is completely different from the first. For the first subfield of the indirect identity identifier type, a replacement strategy that retains some non-identifiable semantic features is used to generate the second subfield. For example, if the first subfield is "Haobo Steel Company," the corresponding second subfield is "Qifan Steel Company." By utilizing information such as the industry category and geographical scope attributes in the first subfield, the replaced entity field retains certain business semantic information during cloud model inference, improving the accuracy of the inference results.

[0152] By performing field attribute identification on the first subfield, the subfield whose field attribute represents an identity identifier is selected. This subfield is then replaced with a second subfield, resulting in a replaced entity field. In this replaced entity field, the first subfield, which uniquely identifies the company's true identity, has been replaced by the second subfield. During inference, the cloud model can only access the virtual entity field and cannot obtain the company's true identity information. This eliminates the risk of leakage of company identity data during the cloud model inference process and effectively solves the problem of enterprise privacy data security caused by uploading identity fields in plaintext to the cloud in enterprise profiling scenarios.

[0153] In some embodiments, replacing the first subfield with the second subfield in step 103 to obtain the replaced entity field can also be achieved through the following technical solution: when the field attribute indicates that the first subfield is a statistical number type field, a perturbation value is randomly selected from a preset perturbation range; the perturbation value and the first subfield are multiplied to obtain a first product result, and the first product result is used as the second subfield; the first subfield is replaced with the second subfield to obtain the replaced entity field.

[0154] As an example, the statistical data type is used to characterize the numerical information contained in the first subfield as business data of a statistical nature. This value can quantify the business status or scale indicator of a certain dimension of the enterprise. For example, entity field A is "number of employees: 500". Entity field A is split to get the first subfield "500". Field attribute identification is performed on the first subfield "500". The field attribute characterizes the first subfield as a statistical data type field, indicating that the first subfield "500" is statistical data that carries the total number of employees of the enterprise.

[0155] The preset perturbation range is a numerical range that the server pre-sets before performing the replacement process to limit the range of selectable perturbation values. For example, the preset perturbation range can be set to [0.7, 1.3] or [0.85, 1.15].

[0156] As an example, the server is pre-configured with a set of field attribute recognition rules. The set of field attribute recognition rules has corresponding recognition rules configured for statistical number types. The recognition rules can include numerical field matching rules and semantic tag matching rules.

[0157] Numeric field matching rules are used to determine whether the first subfield is numeric data; semantic tag matching rules are used to determine whether the field name or contextual semantics associated with the first subfield belongs to the scope of enterprise statistical operating indicators. For example, when the field name of an entity field contains keywords such as "registered capital", "turnover", "tax payment", "number of employees", and "number of insured persons", the semantic tag matching rule is hit. When the first subfield satisfies both the numeric field matching rule and the semantic tag matching rule, the server can determine the field attribute of the first subfield as a statistical number type.

[0158] When the field attribute indicates that the first subfield is a statistical number type field, the server reads the preset perturbation range from the locally stored configuration parameters. The preset perturbation range is a numerical range, for example, the preset perturbation range is [0.8, 1.2], where 0.8 is the lower limit of the perturbation range and 1.2 is the upper limit of the perturbation range. Then the server can call a random number generation function to randomly select a value within the preset perturbation range as the perturbation value. For example, when the preset perturbation range is [0.8, 1.2], the random number generation function may output a perturbation value of 0.95, 1.08, or 1.15, etc.

[0159] The server multiplies the perturbation value with the value of the first subfield to obtain the first product result. For example, if the value of the first subfield is 1000 and the perturbation value is 1.08, the first product result is 1080. Then, the server uses this first product result as the second subfield, which maintains the same numeric data type as the first subfield. The server locates the first subfield in the entity field whose field attribute is a statistical number and replaces it with the first product result. After performing the above perturbation replacement process on all first subfields in the entity field whose field attribute is a statistical number, the server obtains the replaced entity field.

[0160] As an example, the server can dynamically adjust the preset perturbation range based on the sensitivity level of the first subfield. The server can pre-establish a sensitivity grading standard for statistical data types, dividing the first subfield of statistical data types into high-sensitivity statistical data and low-sensitivity statistical data. High-sensitivity statistical data may include first subfields that directly reflect the core financial indicators of an enterprise, such as enterprise turnover, enterprise tax payment, and enterprise profit. Low-sensitivity statistical data may include first subfields that relatively indirectly reflect the scale of an enterprise's operations, such as the total number of employees and the number of branches.

[0161] When the field attribute indicates that the first subfield is a statistical number type field and belongs to high-sensitivity statistics, the server adopts a first preset perturbation range. The first preset perturbation range is relatively wide, for example, the first preset perturbation range can be [0.5, 1.5], to provide stronger data protection. When the field attribute indicates that the first subfield is a statistical number type field and belongs to low-sensitivity statistics, the server adopts a second preset perturbation range. The second preset perturbation range is relatively narrow, for example, the second preset perturbation range can be [0.9, 1.1], to better preserve the accuracy of data statistics.

[0162] Through the above method, in the replaced entity fields, the first subfield of the statistical data type has been replaced by the second subfield after perturbation product processing. The statistical figures such as enterprise registration amount, turnover, and number of employees received by the cloud model are all perturbation values ​​that deviate from the true values. Attackers and cloud service providers cannot directly obtain the enterprise's true operating data from the perturbation values. This effectively eliminates the risk of leakage of core enterprise operating statistical data during the cloud model inference process and solves the security problem of sensitive enterprise operating data caused by the plaintext uploading of statistical data type fields in the enterprise profile construction scenario.

[0163] In some embodiments, replacing the first subfield with the second subfield in step 103 to obtain the replaced entity field can also be achieved through the following technical solution: when the field attribute indicates that the first subfield is a door number address field, a virtual door number address is randomly generated, and the virtual door number address is used as the second subfield; the first subfield is replaced with the second subfield to obtain the replaced entity field.

[0164] As an example, the address number is used to represent that the first subfield contains specific address information that can identify the building or plot where the enterprise is located. The first subfield of the address number type usually includes a combination of road name and address number information, such as "No. XX on A Street", "No. XX in Courtyard XX on B Road", "Room XX at No. XX on Chuangye Road", etc. After the enterprise registration address in the enterprise data is split into fields, the first subfield "No. XX on B Road" is obtained. Field attribute identification is performed on the first subfield to obtain the field whose field attribute represents the first subfield as an address number.

[0165] As an example, the server is pre-configured with a set of field attribute recognition rules. The set of field attribute recognition rules has corresponding recognition rules for house number addresses. The house number address recognition rules include house number regular expression matching rules and address level feature matching rules. The house number regular expression matching rules are used to detect whether the first subfield contains a combination pattern of road words such as "road", "street", "path", "alley", "lane" and "lane" with numbers, and whether it contains a combination pattern of house number identifier words such as "number", "building number", "courtyard number", "room", and "floor" with numbers. The address level feature matching rules are used to detect whether the first subfield is located below the road level and at the specific house number level in the address type field.

[0166] When the first subfield matches the regular expression matching rule for the house number and satisfies the address hierarchy feature matching rule, the server determines the field attribute of the first subfield as the house number address. Then, the server performs address structure parsing on the first subfield, extracting the address components, which include the road name and the house number. For example, for the first subfield "A Road XX", the address structure parsing yields "A Road" for the road name and "XX" for the house number.

[0167] Then, the server randomly selects a virtual road name from a preset set of virtual road names. The preset set of virtual road names stores fictitious road names that do not point to real geographical locations. The fictitious road names are consistent with real road names in terms of naming format, consisting of place name modifiers and suffixes such as "road", "street", "avenue", and "alley".

[0168] Then, the server randomly generates a virtual address number within a preset address number range. The preset address number range is set according to the city's address numbering rules, such as an integer value between 1 and 9999. The server combines the randomly generated virtual address number with address identifiers (such as "number", "courtyard number", "building number") to form the virtual address number part.

[0169] Next, the server concatenates the randomly selected virtual road name with the randomly generated virtual house number to obtain the virtual house number address. The virtual house number address is consistent with the first subfield in terms of address format and hierarchical structure. The server uses the virtual house number address as the second subfield, and then locates the first subfield, which is represented by the house number address, in the entity field, and replaces the first subfield with the second subfield, that is, with the virtual house number address.

[0170] As an example, the server first extracts city-level information from the address information belonging to the first subfield. City-level information is the address component above the house number address level. For example, if the address information belonging to the first subfield is "City A, Street C", the city-level information can be the city name "City A". The server randomly selects from a preset set of virtual road names according to the subset of virtual road names corresponding to the city-level information. For example, it can select the virtual road name "Street D" corresponding to City A. The server can pre-build independent subsets of virtual road names for different cities, and the random selection is limited to the subset of virtual road names corresponding to the city.

[0171] In this way, the city affiliation information of the virtual address can be kept consistent with the city affiliation of the original enterprise address, avoiding the cloud model from judging it as abnormal data due to inconsistencies in city information. This protects the privacy of the address while ensuring the accuracy of the address regional attribute analysis in the enterprise profile.

[0172] As an example, the server checks whether there are multiple first subfields of the same address type belonging to the same address link in the enterprise data. For example, if there are two first subfields, such as "XX Road XX Number" and "XX Road XX Number XX Room", when a hierarchical relationship is detected, the server first generates a virtual address for the higher-level address. Then, based on the virtual road name and virtual address number in the higher-level virtual address, it recursively generates a lower-level virtual address. This ensures that the virtual addresses within the same address link maintain hierarchical consistency and logical continuity in their address structure, avoiding inference errors in the cloud model due to address hierarchy breaks. For example, if there is a first subfield A "A Road" and a first subfield B "A Road B Number", the first subfield B can be replaced with "C Road D Number" first. This avoids replacing the first subfield "A Road" with "C Road" first, which would then lead to the first subfield B being replaced with "C Road B Number", making it impossible to replace the address-level information of the first subfield B.

[0173] Through the above method, in the replaced entity fields, the first subfield of the address type has been replaced by a virtual address. The precise address location identifier in the enterprise address information received by the cloud model has been replaced with a virtual address that does not point to any real physical location. Attackers and cloud service providers cannot obtain the precise physical location information of the enterprise through cloud-based inference data. This effectively eliminates the risk of leakage of the enterprise's precise address location information during cloud model inference and solves the enterprise location privacy and security problem caused by the plaintext uploading of address numbers in enterprise profiling scenarios.

[0174] In some embodiments, replacing the first subfield with the second subfield in step 103 to obtain the replaced entity field can be achieved through the following technical solution: concatenating the first subfield and the first identifier to obtain a concatenated field, wherein the first identifier is the round identifier for entity extraction from the enterprise data; performing a hash calculation on the concatenated field to obtain a hash value, and generating a pseudo-random value corresponding to the hash value based on a pseudo-random generation function; performing a repeatability detection on the pseudo-random value to obtain a repeatability detection result; when the repeatability detection result indicates that the pseudo-random value passes the repeatability detection, using the pseudo-random value as the second subfield; and replacing the first subfield with the second subfield to obtain the replaced entity field.

[0175] As an example, the first identifier is the round identifier for entity extraction of enterprise data, used to determine the round to which each entity extraction operation belongs. The first identifier can be the sequence number of the entity extraction round, timestamp, session identifier, or a combination of the above information. For example, when the enterprise data is extracted in the first batch, the first identifier is "round_001"; when the entity is extracted in the second batch, the first identifier is "round_002".

[0176] The concatenated field is a composite field obtained by concatenating the first subfield and the first identifier. The concatenated field serves as the input data for hash calculation, merging the original content of the first subfield with the round information into a whole. The concatenation method of the concatenated field can be string concatenation, binary concatenation, or concatenation with a specific delimiter. For example, if the first subfield is "XX Technology Co., Ltd." and the first identifier is "round_001", the concatenated field obtained by concatenating the two can be "XX Technology Co., Ltd._round_001" or the corresponding binary form.

[0177] Hash calculation refers to the process of inputting concatenated fields into a preset hash function and obtaining a hash value of fixed length through the operation of the hash function. Hash functions can be SM3 hash algorithm, SHA-256 hash algorithm, etc.

[0178] A pseudo-random generation function is a deterministic function that uses a hash value as an input seed to generate pseudo-random values. Pseudo-random generation functions have deterministic characteristics; the same hash value input will always generate the same pseudo-random value output, thus ensuring that the same first subfield can reproducibly generate the same second subfield in the same round. Pseudo-random generation functions can employ hash value-based modulo operation mapping, linear congruence generators, etc.

[0179] Repeatability detection refers to the process of checking whether a pseudo-random value conflicts with a second subfield that has been assigned to other first subfields. The purpose of repeatability detection is to ensure that each first subfield corresponds to a unique second subfield, and to avoid mapping confusion caused by different first subfields mapping to the same second subfield.

[0180] As an example, the server maintains a round counter. Each time an entity extraction process for enterprise data is initiated, the round counter is incremented, and the incremented count value is used as the first identifier; or, the server obtains the timestamp and session identifier of the current entity extraction operation, and uses the combination of the timestamp and session identifier as the first identifier.

[0181] As an example, the server obtains the first subfield and the first identifier corresponding to this entity extraction operation. Then, it concatenates the first subfield and the first identifier to obtain the concatenated field. Specifically, the server connects the string representation of the first subfield and the string representation of the first identifier using a preset delimiter. The delimiter can be an underscore, a vertical bar, or other characters that do not conflict with the content of the first subfield and the first identifier. For example, if the first subfield is "XX Technology Co., Ltd." and the first identifier is "round_001", the concatenated field will be "XX Technology Co., Ltd._round_001". Alternatively, the server can also use a binary concatenation method, directly concatenating the byte sequence of the first subfield with the byte sequence of the first identifier.

[0182] The server then inputs the concatenated field into a preset hash function, performs hash calculation on the concatenated field, and obtains the hash value of the concatenated field. The hash function receives the complete content of the concatenated field as input message, and outputs a fixed-length hash value after iterative calculation by the compression function.

[0183] Then, the server uses the hash value as the input seed for the pseudo-random number generation function, and generates a pseudo-random value corresponding to the hash value based on the pseudo-random number generation function. Specifically, the server converts the hash value into an integer, uses this integer as the initial seed to input a deterministic pseudo-random number generation algorithm, and outputs a pseudo-random value after a preset number of iterations. The range of the pseudo-random value is preset according to the format requirements of the second sub-field. Since the pseudo-random number generation function is deterministic, the same hash value will always generate the same pseudo-random value, thereby ensuring that the same first sub-field can reproducibly generate the same second sub-field under the same first identifier.

[0184] Next, the server maintains a set of assigned second subfields, which records all second subfields that have been assigned to other first subfields in the current round. The server compares the pseudo-random value with each assigned second subfield in the set one by one. When the pseudo-random value is the same as any assigned second subfield in the set, the repeatability detection result indicates that the pseudo-random value has failed the repeatability detection; when the pseudo-random value is different from all assigned second subfields in the set, the repeatability detection result indicates that the pseudo-random value has passed the repeatability detection.

[0185] When the repeatability detection result indicates that the pseudo-random value fails the repeatability test, the server adjusts the concatenation field and re-executes the hash calculation and pseudo-random value generation. Specifically, an incrementing salt value can be appended to the end of the concatenation field to obtain the adjusted concatenation field. Then, the adjusted concatenation field is hashed again, and a new pseudo-random value is generated based on the pseudo-random generation function. Repeatability detection is performed again until the repeatability detection result indicates that the pseudo-random value passes the repeatability test.

[0186] Once the repeatability test result indicates that the pseudo-random value has passed the repeatability test, the server uses the pseudo-random value as the second subfield and adds this second subfield to the set of allocated second subfields.

[0187] Finally, the server locates the first subfield in the entity field and replaces it with the second subfield, that is, replaces the first subfield with a pseudo-random value that passes the duplicate detection.

[0188] Because the server uses a deterministic generation method based on hash calculation and pseudo-random generation function, it does not need to persistently store the complete mapping table between the first subfield and the second subfield. When reverse restoration is required, the server only needs to store the first identifier and the hash function identifier, and can recalculate the second subfield based on the same first subfield and the first identifier.

[0189] As an example, when generating concatenated fields, in addition to the first subfield and the first identifier, the server can also introduce the data source identifier of the enterprise data to participate in the field concatenation. Specifically, the server can obtain the data source identifier from which the enterprise data originates. The data source identifier is used to distinguish different sources of enterprise data, such as business data source identifier, tax data source identifier, and enterprise self-reporting data source identifier.

[0190] The server concatenates the first subfield, the first identifier, and the data source identifier to obtain the concatenated field. Since the same first subfield may exist in different data sources, the introduction of the data source identifier will generate different concatenated fields for the same first subfield in different data sources, thus obtaining different second subfields. This further refines the granularity of the generation of the second subfield in cross-data source scenarios and avoids mapping conflicts between different data sources.

[0191] The above method solves the problem of the second subfield being fixed across rounds, enhances data protection in multi-round enterprise data processing scenarios, and ensures that the original content of the first subfield cannot be derived from the second subfield, effectively protecting the privacy and security of enterprise data.

[0192] In step 104, the replaced entity fields are subjected to model reasoning through the cloud model to obtain the reasoning results corresponding to the replaced entity fields.

[0193] As an example, a cloud model refers to a machine learning or deep learning model deployed on a cloud server for analyzing and reasoning about enterprise data. A cloud model has the ability to extract features from input data, identify patterns, and generate analytical conclusions. A cloud model can be a natural language processing model based on the Transformer architecture, an enterprise relationship analysis model based on graph neural networks, or other artificial intelligence models suitable for enterprise data processing.

[0194] As an example, the server encapsulates the replaced entity fields and preset prompts into an inference request message. The preset prompt can be "Generate a corporate profile of the enterprise based on the following data". The inference request message includes the replaced entity fields, prompts, and metadata of the inference request. The metadata includes request identifier, model version identifier, and inference parameter configuration information. The server performs serialization processing on the inference request message, converting it into a transmission format supported by the cloud model interface, such as JSON format or Protocol Buffers format.

[0195] An encrypted transmission channel can be established between the server and the cloud server where the cloud model is located. The encrypted transmission channel is encrypted using the transport layer security protocol to ensure that the replaced entity fields are not stolen or tampered with by intermediate network nodes during the transmission from the server to the cloud server.

[0196] The server can send the inference request message to the service interface of the cloud model through an encrypted transmission channel. After receiving the inference request message, the service interface of the cloud model parses the inference request message and obtains the replaced entity fields, prompt words and metadata of the inference request.

[0197] The cloud model first performs data preprocessing on the replaced entity fields, including field encoding, vectorization, and normalization. The cloud model then inputs the preprocessed replaced entity fields and prompt words into its generation module. The network layers of the generation module perform feature extraction and transformation calculations on the replaced entity fields. During the inference calculation process, the cloud model processes all entity fields and subfields in the replaced entity fields, including the second subfield and the first subfield of non-identity types. Finally, the cloud model generates the inference result corresponding to the replaced entity fields through the model output layer.

[0198] The cloud server encapsulates the inference results corresponding to the replaced entity fields into an inference response message and returns it to the server through an encrypted transmission channel. After receiving the inference response message, the server parses the inference response message to obtain the inference results corresponding to the replaced entity fields.

[0199] During model inference, the input data received by the cloud model consists of replaced entity fields. Sensitive types such as identity identifiers, statistics, and addresses have had their first subfields replaced by second subfields. Therefore, the cloud model cannot access the company's actual sensitive data and can only complete model inference based on virtual entity fields. Simultaneously, the replaced entity fields maintain compatibility with the original entity fields in terms of data structure, field types, and inter-field relationships. The cloud model's data preprocessing and model inference processes do not require adaptation modifications to complete the inference task normally.

[0200] As an example, before sending the replaced entity fields to the cloud model, the server can also perform a data availability pre-check on the replaced entity fields. Specifically, a lightweight pre-check model can be deployed locally on the server. The server inputs the replaced entity fields into the lightweight pre-check model for pre-inference to obtain the pre-check inference results. Then, the validity of the pre-check inference results is determined. When the confidence level of the pre-check inference results is lower than the preset confidence level threshold, it is determined that the replaced entity fields may have insufficient data availability due to excessive desensitization processing. The replacement strategy parameters are adjusted and the replaced entity fields are regenerated. When the confidence level of the pre-check inference results reaches the confidence level threshold, the server sends the replaced entity fields to the cloud model for model inference.

[0201] In some embodiments, before performing model reasoning on the replaced entity field using a cloud model in step 104 to obtain the reasoning result corresponding to the replaced entity field, the following technical solution may also be performed: extracting the enterprise registration address and address name from the replaced entity field; performing a consistency check on the enterprise registration address and the address name to obtain a consistency check result; when the consistency check result indicates that there is no address conflict between the enterprise registration address and the address name, performing model reasoning on the replaced entity field using a cloud model to obtain the reasoning result corresponding to the replaced entity field.

[0202] As an example, a company's registered address is the address information recorded in the company's data that the company has registered with the industrial and commercial registration authority. The company's registered address contains multiple address level elements such as province, city, district / county, road, and house number. For example, the company's registered address can be "No. XX, Road C, District B, City A".

[0203] As an example, the server iterates through all entity fields in the replaced entity fields, identifies entity fields whose field names or semantic tags match preset address field identifiers such as "enterprise registered address", "registered address", and "registered address", and extracts the content of the entity field as the enterprise registered address.

[0204] The server iterates through all entity fields in the replaced entity fields, identifies entity fields whose field names or semantic tags match preset address name field identifiers such as "address name", "location", "city", and "region", and extracts the content of the entity field as the address name.

[0205] For the registered address of an enterprise, the server breaks down the registered address according to the administrative division hierarchy and extracts the provincial, municipal and county-level administrative division information contained in the registered address. For the address name, the server breaks down the address name according to the administrative division hierarchy and extracts the administrative division hierarchy information contained in the address name.

[0206] The server compares the administrative division level information of the company's registered address with that of the address name layer by layer. Specifically, it compares the provincial-level administrative division information in the company's registered address with that in the address name; it compares the prefecture-level administrative division information in the company's registered address with that in the address name; and it compares the district / county-level administrative division information in the company's registered address with that in the address name. The server also verifies the inclusion relationship between the company's registered address and the address name, determining whether the administrative region indicated by the address name is a superior or equivalent region to the administrative region indicated by the company's registered address.

[0207] When the registered address and address name of an enterprise match at all administrative division levels and the inclusion relationship verification passes, the consistency test result indicates that there is no address conflict between the registered address and address name of the enterprise; when the registered address and address name do not match at any administrative division level, or the inclusion relationship verification fails, the consistency test result indicates that there is an address conflict between the registered address and address name of the enterprise.

[0208] When the consistency check result indicates that there is no address conflict between the enterprise's registered address and address name, the server determines that the replaced entity field passes the address consistency check. The server then uses the cloud model to perform model inference on the replaced entity field and obtains the inference result corresponding to the replaced entity field.

[0209] When the consistency check result indicates that there is an address conflict between the enterprise's registered address and address name, it is determined that the replaced entity field has failed the address consistency check, an address conflict alarm message is generated, the replaced entity field is not sent to the cloud model, the replaced entity field with address conflict is corrected or marked, and the address consistency check is re-executed until the consistency check result indicates that there is no address conflict between the enterprise's registered address and address name.

[0210] As an example, the server can also preload the National Administrative Division Benchmark Database, which stores standard administrative division hierarchical relationships and administrative division name mapping tables. When performing consistency checks on the company's registered address and address name, the administrative division information in the company's registered address and address name can be matched and verified with the standard data in the National Administrative Division Benchmark Database.

[0211] When the administrative division information in the company's registered address cannot be found in the national administrative division benchmark database, the company's registered address itself is deemed to have an address validity anomaly. The consistency check result is marked as an address conflict between the company's registered address and the address name. Similarly, when the administrative division information in the address name cannot be found in the national administrative division benchmark database, the server also determines that the consistency check result is an address conflict.

[0212] By employing the above methods, the issue of regional dimension deviations in cloud model inference results caused by internal contradictions in address information potentially introduced during replacement processing is resolved, ensuring the accuracy of inferences in dimensions such as enterprise regional affiliation analysis and regional economic environment assessment during enterprise profile construction. Simultaneously, address consistency verification is performed locally on the server, without increasing the additional computational overhead of the cloud model. Furthermore, the replaced entity fields, after successful verification, have eliminated the potential for address conflicts, improving the quality of input data received by the cloud model and further enhancing the reliability and credibility of enterprise profile inference results.

[0213] In step 105, the second subfield in the reasoning result is replaced with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0214] As an example, a business profile is a comprehensive analysis result that accurately corresponds to the real identity information of the business in the business data. Business users can make business decisions directly based on the business profile. The business profile includes, but is not limited to, multi-dimensional analysis conclusions such as business industry classification, business size assessment, business credit rating, business risk warning, and business competitive position analysis. The analysis conclusion of each dimension in the business profile is bound to the real information of the business corresponding to the first subfield. Business users can accurately identify the business entity corresponding to each conclusion.

[0215] As an example, the server parses the inference result and extracts all parameter fields contained in the inference result. Specifically, the server identifies the data type and field role of each parameter field in the inference result, distinguishes between parameter fields belonging to the second subfield and parameter fields belonging to the original field. The server identifies the second subfield by matching the parameter fields with the set of second subfields. The server compares each parameter field in the inference result with the recorded set of second subfields one by one, and the parameter field that matches successfully is the second subfield in the inference result.

[0216] The server recalculates the mapping relationship based on the generation rules and parameters of the second subfield. When the second subfield is deterministically generated through hash calculation and pseudo-random generation function, the server can re-execute the generation process based on the same input parameters to reconstruct the correspondence between the first and second subfields.

[0217] The server retrieves the first subfield corresponding to the second subfield. The server replaces the content of the second subfield in the inference result with the first subfield. The server performs reverse replacement processing on each second subfield in the inference result one by one until all second subfields in the inference result are replaced with the corresponding first subfield.

[0218] After the server completes the reverse replacement of all the second subfields in the reasoning result, it obtains the enterprise profile corresponding to the enterprise data. The enterprise identification information, business statistics information and address information in the enterprise profile have all been restored to the real data of the enterprise. The reasoning analysis conclusions of each dimension of the enterprise profile have established an accurate correspondence with the real identity information of the enterprise. The server presents the enterprise profile in a preset output format, including visual charts, structured data reports or interface (API) responses.

[0219] As an example, after completing the reverse replacement of all second subfields, the server iterates through and checks the replaced inference results to see if any unreplaced second subfields remain. The server then matches each parameter field in the replaced inference results with the set of second subfields again. When an unreplaced second subfield is detected, the server generates a replacement integrity exception alarm and re-executes the mapping relationship lookup and reverse replacement for the unreplaced second subfields until the replaced inference results no longer contain any second subfields. When no residual second subfields are detected in the replaced inference results, the server confirms that the replacement integrity verification has passed and outputs the replaced inference results as the enterprise profile corresponding to the enterprise data.

[0220] The above method solves the problem of the disconnect between enterprise profiles and real enterprise information caused by the inclusion of virtual entity fields in cloud model inference results. After the enterprise data has been processed for privacy protection and completed cloud model inference, enterprise users can obtain enterprise profiles that can be directly used and are accurately linked to the real enterprise information.

[0221] In some embodiments, after replacing the first subfield with the second subfield in step 103 and obtaining the replaced entity field, the following technical solution can also be performed: constructing a first mapping table between the first subfield and the second subfield, wherein the key in the first mapping table is the first subfield and the value is the second subfield; performing a mapping transformation on the first mapping table to obtain a second mapping table, wherein the key in the second mapping table is the second subfield and the value is the first subfield.

[0222] As an example, the first mapping table is a data structure built during the process of replacing the first subfield with the second subfield to record the correspondence between the first and second subfields. The key in the first mapping table is the first subfield, and the value is the second subfield. The first mapping table is used in the forward replacement phase. When the server needs to find the corresponding second subfield based on the first subfield, it can quickly obtain the corresponding second subfield by matching the key in the first mapping table with the first subfield as the key. For example, if the first subfield "XX Technology Co., Ltd." is replaced with the second subfield "Virtual Enterprise A", then the first mapping table stores the data row with the key "XX Technology Co., Ltd." and the corresponding value "Virtual Enterprise A".

[0223] The second mapping table is a data structure obtained by mapping and transforming the first mapping table. The key-value relationship in the second mapping table is the reverse of that in the first mapping table. The key in the second mapping table is the second subfield, and the value is the first subfield. The second mapping table is used in the reverse restoration stage. When the server needs to find the corresponding first subfield based on the second subfield in the reasoning result, it can quickly obtain the corresponding first subfield by matching the key in the second mapping table with the second subfield as the key. For example, the second mapping table stores the data row with the key "Virtual Enterprise A" and the corresponding value "XX Technology Co., Ltd."

[0224] As an example, after each replacement operation from the first subfield to the second subfield, the server writes the correspondence between the first and second subfields into the first mapping table. The server adds a new data row to the first mapping table using the first subfield as the key and the second subfield as the value. After the server completes the replacement operation for all the first subfields that need to be replaced in the entity fields one by one, the first mapping table will contain all the mapping entries between the first and second subfields.

[0225] When adding a mapping entry, the server checks whether the same first subfield key already exists in the first mapping table. If the same key already exists in the first mapping table, it means that the first subfield has already been assigned a second subfield. The server directly retrieves the existing second subfield value using the first subfield as the key, without needing to regenerate the second subfield. If the same key does not exist in the first mapping table, the server generates a new second subfield and writes the key-value pair into the first mapping table.

[0226] The server stores the completed first mapping table in a local secure storage area. The storage method includes serializing the first mapping table into a structured data file for persistent storage, or saving the first mapping table in a key-value pair storage structure in memory. The server sets access permissions for the first mapping table to ensure that the first mapping table can only be read in the secure environment of the server and is not transmitted to the cloud environment.

[0227] The server iterates through all mapping entries in the first mapping table, performing a key-value swap operation on each entry. Specifically, for the i-th mapping entry in the first mapping table, the server reads the key Ki (i.e., the first subfield) and value Vi (i.e., the second subfield) of that entry, and creates a new mapping entry in the second mapping table with Vi as the key and Ki as the value. After the server completes the iteration, the second mapping table contains the same number of mapping entries as the first mapping table, and the key-value relationship of each mapping entry is the reverse of the corresponding entry in the first mapping table.

[0228] The server stores the second mapping table obtained from the mapping transformation in a local secure storage area. The first and second mapping tables are logically inverse indexes of each other. The server can choose to use the first or second mapping table based on the actual search direction. Alternatively, the server can store only the first mapping table and dynamically perform the mapping transformation to generate the second mapping table when reverse restoration is needed, in order to save storage space, but at the cost of increased computational overhead during reverse restoration. Or, the server maintains the second mapping table while building the first mapping table, that is, when writing key-value pairs to the first mapping table, it simultaneously writes inverse key-value pairs to the second mapping table, thereby completing the synchronous construction of the bidirectional mapping table during the mapping relationship establishment stage.

[0229] As an example, the data structure of the mapping table can be as follows:

[0230] MappingTable:

[0231] forward: {original_value → pseudonym} (used during desensitization)

[0232] reverse: {pseudonym → original_value} (used during restoration)

[0233] type_counters: {EntityType → count} (Statistics and uniqueness control)

[0234] used_pseudonyms: set (collision avoidance set)

[0235] In some embodiments, replacing the second subfield in the inference result with the first subfield in step 105 to obtain the enterprise profile corresponding to the enterprise data can be achieved by the following technical solution: based on the mapping relationship in the second mapping table, replacing the second subfield in the inference result with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0236] As an example, the server performs structural parsing on the inference result to identify its data organization format. This format can include key-value pairs, arrays, nested objects, or text strings. Based on the data organization format, the server determines the set of target nodes for the second subfield matching and replacement within the inference result. Specifically, when the inference result is a key-value pair structure, the server identifies each value node as a matching target; when the inference result is a nested object structure, the server extracts the values ​​of all leaf nodes recursively as matching targets; and when the inference result is a text string structure, the server uses the entire text string as the matching target.

[0237] The server iterates through all mapping relationships in the second mapping table, comparing the key (i.e., the second subfield) in each mapping relationship with the content of the current matching target in the inference result. The comparison methods include exact matching and substring matching. Exact matching means that the second subfield is completely consistent with the content of the matching target; substring matching means that the second subfield appears as a substring in the content of the matching target.

[0238] When the server finds a second subfield key in the second mapping table that matches or is contained within the matching target, the server retrieves the corresponding first subfield value from that mapping relationship. The server then replaces the content of the second subfield at the matching target position in the inference result with the first subfield. For exact matches, the server directly replaces the entire second subfield with the first subfield. For substring matches, the server replaces the substring portion corresponding to the second subfield in the matching target with the first subfield, while the rest of the matching target remains unchanged.

[0239] After confirming that all second subfields in the inference results have been replaced with first subfields, the server uses the inference results after replacement as the enterprise profile corresponding to the enterprise data. Each analysis conclusion in the enterprise profile establishes an accurate correspondence with the real information of the enterprise through the first subfield. Enterprise users can directly obtain multi-dimensional analysis information of each enterprise based on the enterprise profile.

[0240] As an example, after the server completes the construction or mapping transformation of the second mapping table, it can sort all the mapping relationships in the second mapping table in descending order according to the character length of the key (i.e., the second subfield).

[0241] When performing the second subfield matching in the inference result, the server retrieves the second subfield keys in descending order for matching. Prioritizing longer keys avoids mismatches of shorter keys. For example, if the second mapping table contains both the second subfield key "Virtual Enterprise A" and the second subfield key "Virtual Enterprise A Group Co., Ltd.", if ascending order matching is used, the second subfield key "Virtual Enterprise A" might first match a substring portion of "Virtual Enterprise A Group Co., Ltd.", leading to an incorrect partial replacement. By using descending order, the longer second subfield key is matched first, avoiding substring mismatches and improving the accuracy of the replacement.

[0242] During the reverse restoration phase, the server performs direct key matching lookup using the second subfield as the key. The lookup efficiency of each replacement operation is not affected by the size of the mapping table, which solves the performance bottleneck problem of inference result restoration processing in scenarios with large amounts of enterprise data. At the same time, through the complete mapping relationship coverage provided by the second mapping table, the omission or incorrect replacement of the second subfield is avoided, ensuring the data integrity and restoration accuracy of the enterprise profile.

[0243] The following is combined with Figure 3 This application provides an overall flowchart illustrating a method for layered de-identification and result recovery of enterprise data for cloud-based large language model inference. Figure 3 This is a flowchart illustrating the actual implementation of an enterprise data layering desensitization and result recovery method for cloud-based large language model inference, provided by the present invention.

[0244] like Figure 3 As shown, Figure 3 It consists of two parts: a local trusted environment and a cloud API located outside the local trusted environment. The local trusted environment is defined by the dashed border in the diagram, and the cloud API is located outside the dashed border. The cloud API only receives anonymized data and cannot be associated with real enterprise data.

[0245] Within the local trusted environment, there are the enterprise's original privacy data (i.e., the aforementioned enterprise data), a layered de-identification engine, a prompt word assembly, a mapping table, a result recovery engine, and a corresponding node for the final report. During runtime, the enterprise's original privacy data first enters the layered de-identification engine. The engine performs layered de-identification on the original privacy data and forms mapping tables related to the de-identification (i.e., the first and second mapping tables mentioned above). These mapping tables exist only in local memory and reside within the local trusted environment. The layered de-identification engine then passes the de-identified data to the prompt word assembly. The prompt word assembly generates de-identified prompt words (i.e., the replaced entity fields mentioned above) based on the de-identified data and sends the de-identified prompt to the cloud API.

[0246] After receiving the anonymized prompts, the cloud API returns a response containing pseudonyms to the result recovery engine (i.e., the inference result mentioned above). This pseudonymous response travels from outside the local trusted environment to the result recovery engine within that environment. Simultaneously, the result recovery engine receives data from the mapping table and, based on the mapping table stored only in local memory, performs result recovery on the pseudonymous response, generating a final report containing the real data (i.e., the enterprise profile mentioned above). This final report resides within the local trusted environment and is output by the result recovery engine. Through this data flow path, the enterprise's original privacy data is not directly sent to the cloud API. The cloud API receives the anonymized prompts and returns a response containing pseudonyms; the real data is processed by the result recovery engine within the local trusted environment to form the final report.

[0247] In the process of layered anonymization of enterprise data, the data type can be identified first. When the enterprise data is determined to be identity-related data, it can be completely anonymized. Specifically, for the enterprise name, only the unique identifier part (trade name) can be replaced, while retaining the regional prefix, industry keywords, and organizational form suffix; for natural persons' names, the names of legal representatives, shareholders, etc., can be replaced with randomly generated fictitious names; for the unified social credit code, it can be replaced with a fictitious code that complies with the format but does not exist; for precise address numbers, the provincial / municipal / district administrative division prefix can be retained, while only the street and address numbers are replaced; for contact information, telephone numbers, email addresses, etc., can be replaced with fictitious values; and for document numbers, ID card numbers, etc., can be replaced with fictitious numbers with the correct format.

[0248] When the enterprise data is determined to be statistical data, the magnitude of the values ​​can be kept unchanged, so that the cloud model's judgment of the scale of the values ​​is not affected, and the proportional relationship between fields remains approximately unchanged (such as the profit margin and debt-to-equity ratio deviation is less than 5%).

[0249] When enterprise data is determined to be of a business semantic type, it should be fully retained, such as date information (establishment date, approval date, etc.) for time-based analysis; operating status (existing, revoked, deregistered, etc.) for risk assessment; industry classification keywords for industry benchmarking analysis; geographic level information (province / city / district) for location analysis; risk indicator counts (number of persons subject to enforcement, number of illegal records, tax arrears status, etc.) for compliance assessment; and personnel size information (number of people with social security contributions, number of recruits, etc.) for judging the scale of operations.

[0250] For entity fields that require desensitization, the entity field can first be split into multiple subfields (i.e., the first subfield mentioned above). During the splitting process, specific steps can be taken, such as extracting suffixes to identify and separate organizational form suffixes ("Limited Liability Company" / "Joint-Stock Company", etc.); then, extracting regional prefixes by matching administrative division keywords such as "province / autonomous region / city / district / county / banner" using regular expressions; next, extracting industry keywords based on a predefined industry thesaurus (containing 50+ industry categories) to locate industry descriptive terms from the portion after removing the region and suffixes; then, replacing the font size only by replacing the font size with random values ​​from a pre-defined fictitious font size pool; finally, performing a retention-based recombination, recombining the company name according to the structure of "original region + fictitious font size + original industry + original suffix".

[0251] For example, see Figure 4 , Figure 4 This is a schematic diagram of the first process of text desensitization provided by the present invention, as shown below. Figure 4 As shown, entity field A is "Inner Mongolia Bokai Steel Trade Co., Ltd." By extracting the suffix, we can obtain the suffix of entity field A as "Limited Liability Company". By extracting the geographical prefix, we get "Inner Mongolia". By extracting the industry keyword, we get "Steel Trade". By replacing the font size, we can replace "Bokai" with the random value "Mingrui". Finally, by performing a retention-based recombination, we get "Inner Mongolia Mingrui Steel Trade Co., Ltd."

[0252] In addition, during the process of splitting entity fields, we can first use hierarchical regular expression matching (prioritizing district / county level > city level > province level) to extract the finest-grained administrative region prefix from the original address, and then replace the street name, house number, floor information, etc. after the administrative region with randomly generated fictitious values.

[0253] For example, see Figure 5 , Figure 5 This is a schematic diagram of the second process of text desensitization provided by the present invention. Figure 5In the example, entity field B is “No. 88, D Street, District C, A Autonomous Region B City C”. First, through hierarchical regular expression matching, the administrative division prefix of entity field B is obtained as “A Autonomous Region B City C District”. Then, the street name “No. 88, D Street” after the administrative division is replaced with the fictitious value “No. 142, 12th Floor, E Road”. Finally, “No. 142, 12th Floor, E Road, District C, A Autonomous Region B City C” is obtained.

[0254] The following is combined with Figure 6 This invention describes an enterprise data layering desensitization and result recovery device for cloud-based large language model inference. Figure 6 This is a schematic diagram of the structure of an enterprise data layering desensitization and result recovery device for cloud-based large language model reasoning provided by the present invention. The enterprise data layering desensitization and result recovery device for cloud-based large language model reasoning described below and the enterprise data layering desensitization and result recovery method for cloud-based large language model reasoning described above can be referred to and correspond to each other.

[0255] Extraction module 601 is used to extract entities from enterprise data to obtain the entity fields included in the enterprise data;

[0256] The splitting module 602 is used to split each entity field to obtain the first subfield included in each entity field;

[0257] The replacement module 603 is used to replace the first subfield with the second subfield to obtain the replaced entity field, wherein the second subfield is a virtual entity field;

[0258] The inference module 604 is used to perform model inference on the replaced entity field through the cloud model to obtain the inference result corresponding to the replaced entity field;

[0259] The replacement module 603 is also used to replace the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

[0260] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7As shown, the electronic device may include: a processor 710, a communications interface 720, a memory 730, and a communication bus 740, wherein the processor 710, communications interface 720, and memory 730 communicate with each other through the communication bus 740. The processor 710 can call logical instructions in the memory 730 to execute a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference. This method includes: extracting entities from enterprise data to obtain entity fields included in the enterprise data; splitting each entity field to obtain a first subfield included in each entity field; replacing the first subfield with a second subfield to obtain a replaced entity field, where the second subfield is a virtual entity field; performing model inference on the replaced entity field through a cloud model to obtain an inference result corresponding to the replaced entity field; and replacing the second subfield in the inference result with the first subfield to obtain an enterprise profile corresponding to the enterprise data.

[0261] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0262] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the above-described method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference. The method includes: extracting entities from enterprise data to obtain entity fields included in the enterprise data; splitting each entity field to obtain a first subfield included in each entity field; replacing the first subfield with a second subfield to obtain a replaced entity field, wherein the second subfield is a virtual entity field; performing model inference on the replaced entity field through a cloud model to obtain an inference result corresponding to the replaced entity field; and replacing the second subfield in the inference result with the first subfield to obtain an enterprise profile corresponding to the enterprise data.

[0263] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, as provided by the methods described above. This method includes: extracting entities from enterprise data to obtain entity fields included in the enterprise data; splitting each entity field to obtain a first subfield included in each entity field; replacing the first subfield with a second subfield to obtain a replaced entity field, wherein the second subfield is a virtual entity field; performing model inference on the replaced entity field using a cloud model to obtain an inference result corresponding to the replaced entity field; and replacing the second subfield in the inference result with the first subfield to obtain an enterprise profile corresponding to the enterprise data.

[0264] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0265] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0266] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0267] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for layered de-identification and result recovery of enterprise data for cloud-based large language model inference, characterized in that, include: Entity extraction is performed on the enterprise data to obtain the entity fields included in the enterprise data; For each entity field, perform field splitting to obtain the first subfield included in each entity field; Replace the first subfield with the second subfield to obtain the replaced entity field, where the second subfield is a virtual entity field; By using a cloud-based model, model reasoning is performed on the replaced entity fields to obtain the reasoning results corresponding to the replaced entity fields; Replace the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

2. The method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference as described in claim 1, characterized in that, The process of splitting each entity field to obtain a first sub-field for each entity field includes: Perform the following processing for each of the entity fields: Perform type identification on the entity field to obtain the field type corresponding to the entity field; When the field type is a field type included in the type mapping table, each entity field is split according to the mapping relationship of the type mapping table to obtain the first sub-field included in each entity field.

3. The method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference according to claim 2, characterized in that, The method further includes: When the field type indicates that the entity field is a structured field, regular expression matching is performed on the entity field to obtain the matching field of the entity field; Using the matching field as the first subfield, the entity field is split to obtain all the first subfields included in each entity field.

4. The method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference according to claim 2, characterized in that, The method further includes: When the field type indicates that the entity field is a nested type, the entity field is recursively traversed to obtain the nested fields included in the entity field; The nested field is used as the first subfield, and the entity field is split to obtain all the first subfields included in each entity field.

5. The method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference according to claim 1, characterized in that, Before replacing the first subfield with the second subfield to obtain the replaced entity field, the method further includes: Perform field attribute identification on the first sub-field to obtain the field attributes of each first sub-field; The step of replacing the first subfield with the second subfield to obtain the replaced entity field includes: The first subfield, which represents the identity identifier, is replaced with the second subfield to obtain the replaced entity field.

6. The method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference according to claim 1, characterized in that, The step of replacing the first subfield with the second subfield to obtain the replaced entity field includes: The first subfield and the first identifier are concatenated to obtain the concatenated field, where the first identifier is the round identifier for entity extraction of the enterprise data; A hash calculation is performed on the concatenated field to obtain the hash value of the concatenated field, and a pseudo-random value corresponding to the hash value is generated based on the pseudo-random generation function; The pseudo-random values ​​are subjected to repeatability testing to obtain repeatability testing results; When the repeatability test result indicates that the pseudo-random value has passed the repeatability test, the pseudo-random value is used as the second sub-field. Replace the first subfield with the second subfield to obtain the replaced entity field.

7. A method for layered desensitization and result recovery of enterprise data for cloud-based large language model inference, as described in claim 5, is characterized in that... The step of replacing the first subfield with the second subfield to obtain the replaced entity field includes: When the field attribute indicates that the first subfield is a statistical number type field, a perturbation value is randomly selected from a preset perturbation range; The disturbance value and the first subfield are multiplied to obtain a first product result, and the first product result is used as the second subfield; Replace the first subfield with the second subfield to obtain the replaced entity field.

8. A method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, as described in claim 5, is characterized in that... The step of replacing the first subfield with the second subfield to obtain the replaced entity field includes: When the field attribute indicates that the first subfield is a door number address, a virtual door number address is randomly generated, and the virtual door number address is used as the second subfield; Replace the first subfield with the second subfield to obtain the replaced entity field.

9. A method for layered de-identification and result recovery of enterprise data for cloud-based large language model inference as described in claim 1, characterized in that, Before performing model inference on the replaced entity fields using a cloud-based model to obtain the inference result corresponding to the replaced entity fields, the method further includes: Extract the company's registered address and address name from the replaced entity fields; A consistency check is performed on the enterprise's registered address and the address name to obtain the consistency check result; When the consistency detection result indicates that there is no address conflict between the enterprise registration address and the address name, the replacement entity field is subjected to model reasoning through the cloud model to obtain the reasoning result corresponding to the replacement entity field.

10. A method for hierarchical desensitization and result recovery of enterprise data for cloud-based large language model inference, as described in claim 1, is characterized in that... After replacing the first subfield with the second subfield to obtain the replaced entity field, the method further includes: Construct a first mapping table between the first subfield and the second subfield, where the key in the first mapping table is the first subfield and the value is the second subfield; The first mapping table is transformed to obtain a second mapping table, where the key in the second mapping table is the second subfield and the value is the first subfield. The step of replacing the second subfield in the reasoning result with the first subfield to obtain the enterprise profile corresponding to the enterprise data includes: Based on the mapping relationship in the second mapping table, the second subfield in the reasoning result is replaced with the first subfield to obtain the enterprise profile corresponding to the enterprise data.

Images