Data automatic compatibility and repair method and system under evolution of labeling mode

Abstract

A method and system for automatic data compatibility and repair under annotation pattern evolution. This relates to the field of annotation data management technology, specifically a method and system for automatic data compatibility and repair under annotation pattern evolution. By constructing a configuration semantic alignment relationship and combining it with a data-level verification mechanism, the optimal data migration path is selected in the candidate strategy space, achieving consistent adaptation of historical annotation data in the new configuration semantic space. The method divides the data repair problem into two stages: Stage A: Generating candidate strategies, specifically: obtaining migration task information; label definition modeling; label semantic alignment calculation; candidate strategy generation; Stage B: Evaluating strategy effectiveness, specifically: strategy execution; data consistency evaluation; optimal strategy selection; outputting repair results.

Description

Technical Field

[0001] This invention relates to the field of labeled data management technology, specifically to a method and system for automatic data compatibility and repair under the evolution of labeled patterns. Background Technology

[0002] In the actual operation of data annotation platforms, annotation tasks are typically defined through structured configuration information. Taking mainstream systems such as Label Studio as examples, annotation configuration covers the label category system, annotation tool components, data source binding relationships, and control logic and explicit / implicit condition rules between components. As annotation requirements continue to iterate and business scenarios migrate, annotation configurations inevitably evolve between different versions—label sets may undergo expansion, pruning, or semantic granularity re-division; annotation structures may be adjusted between single-selection, multi-selection, and hierarchical nesting forms; and dependencies and validation constraints between components may also be modified or enhanced.

[0003] However, after the above evolution of the annotation configuration, a large amount of annotation data generated based on the historical version will face systemic compatibility failure issues: the original labels may have been renamed, merged or split, resulting in semantic breaks between the old and new configurations; changes in the annotation structure make the organizational format of the historical data unable to directly adapt to the data model of the new configuration; some historical annotation results may even violate the logical constraints or conditional rules introduced by the new configuration, constituting a legality conflict.

[0004] To address these issues, the industry primarily employs the following four technical methods: (i) Based on the migration route of the tag renaming table or static mapping table, the correspondence between the old tag and the new tag is established at the tag name level. It is suitable for simple scenarios where the names are similar or the mapping relationship is known manually. However, it cannot provide stable and interpretable migration results for tag semantic merging, tag semantic splitting, tag granularity changes and homonymous cases. (ii) Based on the fixed rule script structure transformation route, some single structure changes can be handled by manually preset field renaming rules, field type conversion rules or format completion rules. However, when tag semantic changes, field structure changes and constraint changes occur in combination, conflicts are likely to occur between different rules, and the reusability of rules is poor and the maintenance cost is high.

[0005] (iii) The migration action route is directly generated based on the configuration difference results, which equates the version difference directly with the historical data repair action. Although it can output migration suggestions, it cannot guarantee the consistency of the data structure, constraint legality and semantic context after migration.

[0006] (iv) The approach of performing migration in batches first and then manually checking it attempts to make up for the defects of automatic migration through post-processing manual verification. However, in large-scale task scenarios, once the erroneous results spread, the cost of backtracking and correction is extremely high.

[0007] In summary, a long-standing technical challenge in this field is how to automatically migrate historical annotation data to the target configuration semantic space without relying on large-scale manual review when annotation configuration undergoes complex evolution at the three levels of label semantics, data structure, and logical constraints, while simultaneously ensuring semantic consistency, structural legality, and batch implementation feasibility in engineering. Summary of the Invention

[0008] To address the problem that existing technologies cannot automatically maintain compatibility with and repair historical labeled data during configuration evolution, this invention aims to propose a method and system for automatic data compatibility and repair under labeling pattern evolution. By constructing configuration semantic alignment relationships and combining them with a data-level verification mechanism, the optimal data migration path is selected from the candidate policy space, achieving consistent adaptation of historical labeled data in the new configuration semantic space.

[0009] The method includes the following steps: S1. Obtain migration task information: label definition information, historical annotation data information, and target configuration compatibility constraint information for each label to be migrated; S2. Based on the tag definition information, construct a tag definition object to obtain the old configuration tag definition table and the new configuration tag definition table; S3. For the old configuration tag definition table and the new configuration tag definition table, calculate the tag semantic consistency to obtain the tag semantic alignment score for each tag to be migrated. ; S4. Set the alignment threshold, iterate through the semantic alignment score of each tag to be migrated, and build a tag alignment relationship table; S5. Generate several candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. After the candidate strategies are generated, output the candidate strategy table, which includes: strategy identifier, atomic operation sequence, applicable conditions, and priority information. S6. Apply the candidate strategies generated in step S5 to the historical labeled data information, and perform label mapping, structure transformation, constraint compensation and result verification in the order of execution of the candidate strategies to obtain the execution results of the candidate strategies. S7. Define a data-level evaluation function to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. S8. Based on the optimal strategy, perform compatibility repair on the historical annotation data, verify the historical annotation data after compatibility repair, and output the repair result and verification result identifier.

[0010] Furthermore, historical annotation data information includes: source field identifier, source field type, source field level, source field value base, and historical field values; The target configuration compatibility constraint information includes: target field type, target field level, value range constraint, target configuration structure, mandatory constraints, and configuration constraints.

[0011] Furthermore, the label definition information includes old label definitions and new label definitions; The construction of the tag definition object specifically involves: extracting the tag name, tag alias, tag definition text, belonging annotation node, target data object, set of candidate tags at the same level, and constraint description of each tag to be migrated from the old tag definition and the new tag definition, and forming the old tag definition object and the new tag definition object; Generate old configuration tag definition tables and new configuration tag definition tables based on old tag definition objects and new tag definition objects; Both the old configuration label definition table and the new configuration label definition table include at least: label identifier, label name, label alias, label definition text, type of the label node to which it belongs, type of target data object, set of candidate labels at the same level, and constraint description.

[0012] Furthermore, the tag semantic consistency calculation includes: name semantic matching score calculation, definition semantic matching score calculation, and migration context matching score calculation; The semantic alignment score of each tag to be migrated The formula for calculation is:

[0013] in, , and All of these represent preset weight parameters. , Indicates the semantic matching score of the name. This indicates the definition of semantic matching score. This represents the migration context matching score.

[0014] Further, in step S4, the semantic alignment score of each tag to be migrated is traversed. When the semantic alignment score of the tag is greater than the alignment threshold, it is determined that the old configuration tag and the new configuration tag can establish a migration alignment relationship, a migration alignment relationship identifier is generated, and a tag alignment relationship table is constructed based on the migration alignment relationship identifier. Conversely, it is determined that the old configuration label and the new configuration label cannot establish a migration alignment relationship; The label alignment table includes: the old configuration label identifier, the new configuration label identifier, and the label semantic alignment score corresponding to each migration alignment identifier.

[0015] Furthermore, the generation of the candidate strategy includes the following steps: S51. When the old configuration label and the new configuration label corresponding to the migration alignment relationship label satisfy a one-to-one high-confidence alignment, perform the label mapping operation. S52. When the old configuration tag corresponding to the migration alignment relationship tag matches several new configuration tag tags in the target configuration compatibility constraint information, and each new configuration tag tag has mutually exclusive applicable conditions, perform a tag splitting operation on the old configuration tag tag. S53. When several old configuration tag identifiers corresponding to migration alignment relationship identifiers match the same new configuration tag identifier in the target configuration compatibility constraint information, perform a tag merging operation for the old configuration tag identifiers. S54. When the target field data structure corresponding to the migration alignment relationship identifier is inconsistent with the source field data structure, a data structure conversion operation is performed; the target field data structure and the source field data structure are determined through historical annotation data information and target configuration compatibility constraint information. S55. When the historical annotation data information corresponding to the migration alignment relationship identifier does not meet the mandatory constraints in the target configuration compatibility constraint information and does not have the completion conditions, perform data filtering operation; when there are default values, mappable source fields, derived field values ​​or constraint compensation rules, perform constraint compensation operation.

[0016] Furthermore, in step S6, during the process of performing label mapping, structure transformation, constraint compensation, and result verification in the order of execution of the candidate strategies, an intermediate result snapshot is output at each execution stage of the candidate strategy.

[0017] Furthermore, the data-level evaluation function is specifically as follows:

[0018] in, Indicates the first The policy score of each candidate policy. , and All represent strategy weights. , Indicates structural consistency score, Indicates the constraint satisfaction score. This indicates the context consistency score.

[0019] Furthermore, the verification specifically includes: S81. Determine whether the historical annotation data after compatibility repair meets the configuration constraints in the target configuration compatibility constraint information; If satisfied, the configuration constraint verification is marked as successful. Conversely, if the configuration constraint verification fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. S82. Based on the successful verification in S81, determine whether the label values, field structures, and contextual relationships in the historical annotation data after compatibility repair meet the semantic consistency requirements according to the label alignment relationship table. If satisfied, the semantic consistency check of the tag is successful; Conversely, if the semantic consistency check fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. S83. The historical labeled data after compatibility repair following verification in steps S81 and S82 is recorded as the repair result. The verification result identifiers include: configuration constraint verification passed, configuration constraint verification failed, semantic consistency verification passed, and semantic consistency verification failed.

[0020] An automatic data compatibility and repair system under annotation pattern evolution, the system is used to implement the above method, the system includes: a migration task acquisition module, a label definition module, a semantic alignment module, a policy generation module, a policy execution module, a data evaluation module, a verification rollback module, and a result output module; The migration task acquisition module is used to acquire migration task information; The tag definition module is used to build old configuration tag definition tables and new configuration tag definition tables based on migration task information; The semantic alignment module is used to calculate the semantic consistency of tags between the old and new configuration tag definition tables, and obtain the tag semantic alignment score for each tag to be migrated. ; Used to set alignment thresholds, iterate through the semantic alignment scores of each tag to be migrated, and build a tag alignment relationship table; The strategy generation module is used to generate several candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. The strategy execution module is used to apply several candidate strategies to historical labeled data information to obtain the execution results of the candidate strategies; The data evaluation module is used to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. The verification rollback module is used to load an intermediate result snapshot and roll back to the current candidate strategy processing stage when verification fails. The results output module is used to output the repair results and the verification result identifier.

[0021] The beneficial effects of the method described in this invention are as follows: (1) This invention constructs an old configuration label definition table and a new configuration label definition table, and performs label semantic consistency calculation based on label name, label alias, label definition text and migration context, so that the label migration relationship is based on semantic joint representation rather than on shallow string matching, thereby solving the problem of semantic breakage caused by label renaming, semantic merging, semantic splitting and homonymy that is difficult to handle in the existing technology, and fundamentally improving the semantic accuracy of historical annotation data repair.

[0022] (2) This invention integrates the target configuration structure, target field type, target field level, mandatory constraints, mutual exclusion constraints, condition triggering constraints and value range constraints into the target configuration compatibility constraint information, and generates candidate strategies accordingly. This makes historical data repair no longer limited to field rewriting or label replacement, but based on the dual conditions of "semantic alignment and legal results", thereby solving the problem in the prior art that although the migration results have completed the format transformation, they cannot meet the target configuration constraints.

[0023] (3) This invention organizes label mapping, label splitting, label merging, data structure transformation, constraint compensation and data filtering into a candidate strategy space, and performs data-level evaluation on the execution results of the candidate strategies. It quantitatively compares the results from three dimensions: structural consistency, constraint satisfaction and context consistency, and selects the optimal strategy based on the scoring mechanism. This solves the problem that migration path selection in the prior art relies on human experience and it is difficult to obtain high-quality repair results stably.

[0024] (4) This invention outputs intermediate result snapshots during the execution of candidate strategies and performs phased rollback based on intermediate result snapshots when configuration constraint verification or semantic consistency verification fails, thereby forming a recoverable automatic repair closed loop, thus solving the problems of lack of failure control capability, easy spread of erroneous results and difficulty in backtracking in batch migration scenarios of existing technologies, and improving the overall operational stability.

[0025] (5) This invention decouples the candidate strategy generation process from the data-level verification process. First, a candidate strategy space is constructed, and then the optimal strategy is selected by the execution result scoring and verification results. Its technical principle is to replace "single path hard-coded execution" with "multi-strategy generation + result verification and selection". Thus, it can directly complete automatic compatibility repair based on old configuration, new configuration and historical annotation data without relying on pre-generated difference analysis output or change set, reducing deployment prerequisites and improving cross-version adaptability.

[0026] (6) The method described in this invention can perform fine-grained strategy selection, verification and rollback for a single historical labeled data, and can also perform batch parallel processing for a preset batch of historical labeled data. Its technical principle is to bind the label definition object, candidate strategy table, strategy score and intermediate result snapshot to the data item level or batch level respectively, so as to simultaneously take into account the flexibility of single data item repair and the engineering scalability of large-scale task processing.

[0027] (7) This invention addresses the complex migration problem when label semantic changes, data structure changes, and logical constraint changes coexist. By organizing semantic alignment, constraint modeling, candidate strategy generation, data-level verification, and failure rollback into a unified closed-loop processing link, it solves the long-standing technical problem in the field of balancing semantic consistency, structural legality, and batch implementation, and provides a feasible technical path for the automatic compatibility and repair of historical annotation data under the evolution of annotation patterns. Attached Figure Description

[0028] Figure 1 This is a flowchart of the method described in this invention; Figure 2 This is a schematic diagram of the tag semantic alignment described in this invention; Figure 3 This is a schematic diagram of the strategy generation process described in this invention; Figure 4 This is a schematic diagram of the data-level verification process described in this invention. Detailed Implementation

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

[0030] Example 1 This embodiment provides a method for automatic data compatibility and repair under annotation pattern evolution. The method includes two stages: Stage A: Based on configuration semantic alignment, candidate strategies are generated, which mainly involves steps S1 to S5 of the method described in this invention. Phase B: Evaluate the effectiveness of candidate strategies through data-level verification, mainly involving steps S6 to S8 of the method described in this invention.

[0031] The flowchart of the method is as follows: Figure 1 As shown, the method includes the following steps: S1. Obtain migration task information: configuration version information, tag definition information, historical annotation data information, description of configuration differences, and target configuration compatibility constraint information for each tag to be migrated; The relevant operations in step S1 will be introduced with specific examples: The configuration version information includes the old configuration version identifier, the target configuration version identifier, the historical labeled data identifier, and the task batch identifier; The label definition information includes old label definitions and new label definitions; in this embodiment, the old label definitions include `car` and `truck`, and the new label definitions include "vehicle" and "truck".

[0032] The historical annotation data information includes the historical annotation data of the tags to be migrated, historical field values, historical tag values, source field identifiers, source field types, source field levels, source field value bases, and the association between historical annotation data and old configuration tags; The source field value base is used to indicate the number of values ​​supported by the source field, including single value, multiple value, list length range, or allowed number of values; for example, in the historical labeled data item `data_001`, the vehicle type field is `car`, the source field type is a single value field, and its associated old configuration label identifier is `old_label_car`.

[0033] The configuration difference description can originate from any difference analysis method, such as a semantic graph-based analysis method, but it is not a necessary prerequisite for the execution of this invention. The configuration difference description includes at least one of the following: tag addition, tag deletion, tag renaming, field structure changes, and constraint changes.

[0034] The target configuration compatibility constraint information is the constraint information obtained from parsing the target configuration to constrain the compatibility repair of historical annotation data. It includes the target configuration structure, target field type, target field level, mandatory constraints, configuration constraints, mutual exclusion constraints, condition triggering constraints, and value range constraints. For example, the new configuration requires the vehicle type field to be a list field and the vehicle type field to be a mandatory field.

[0035] The migration task information also includes historical labeled data identifiers, task batch identifiers, and target configuration version identifiers.

[0036] S2. Based on the tag definition information, construct a tag definition object to obtain the old configuration tag definition table and the new configuration tag definition table; The relevant operations in step S2 will be introduced with specific examples: The construction of the tag definition object specifically involves: extracting the tag name, tag alias, tag definition text, belonging annotation node, target data object, set of candidate tags at the same level, and constraint description of each tag to be migrated from the old tag definition and the new tag definition, and forming the old tag definition object and the new tag definition object; In this embodiment, the old label definition object corresponding to the old configuration label `car` may include: Label identifier: old_label_car; Tag name: car; Tag alias: automobile; Label definition text: Cars among road vehicles; Belongs to the label node: RectangleLabels; Target data object: Image; Candidate label set at the same level: {car, truck}; Constraint description: {single_choice}; The new label definition object corresponding to the new configuration label "vehicle" can include: Tag identifier: new_label_vehicle; Tag name: car; Tag alias: vehicle; Label definition text: Road vehicles; Belongs to the label node: RectangleLabels; Target data object: Image; Candidate tag set at the same level: {vehicle, truck}; Constraint description: {required, list_value}; Generate old configuration tag definition tables and new configuration tag definition tables based on old tag definition objects and new tag definition objects; The process of generating the old configuration label definition table and the new configuration label definition table is as follows: Traverse the old label definition object set and the new label definition object set respectively, using each label definition object as a candidate record; extract the label identifier, label name, label alias, label definition text, belonging annotation node, target data object, same-level candidate label set, and constraint description from the label definition object; perform field name unification, null value filling, alias format unification, set field deduplication, and order normalization on the extraction results; convert the normalized belonging annotation node into belonging annotation node type field, and convert the normalized target data object into target data object type field; then write the fields in the following order: label identifier, label name, label alias, label definition text, belonging annotation node type, target data object type, same-level candidate label set, and constraint description into table records; summarize all table records generated from the old label definition object set to form the old configuration label definition table, and summarize all table records generated from the new label definition object set to form the new configuration label definition table.

[0037] Preferably, the old configuration tag definition table and the new configuration tag definition table can be implemented using relational tables, key-value tables, JSON table structures, or other searchable structured record formats, as long as they can support querying by tag identifier, reading by field, and traversing by record.

[0038] Both the old configuration label definition table and the new configuration label definition table include at least: label identifier, label name, label alias, label definition text, type of the label node to which it belongs, type of target data object, set of candidate labels at the same level, and constraint description.

[0039] S3. For the old configuration tag definition table and the new configuration tag definition table, calculate the tag semantic consistency to obtain the tag semantic alignment score for each tag to be migrated. ; The relevant operations in step S3 will be introduced with specific examples: The tag semantic consistency calculation includes: name semantic matching score calculation, definition semantic matching score calculation, and migration context matching score calculation; The semantic alignment score of each tag to be migrated The formula for calculation is:

[0040] in, , and Both represent preset weight parameters, with a range of [0, 1]. This embodiment sets , , The specific value can be adjusted according to business needs; Indicates the semantic matching score of the name. This indicates the definition of semantic matching score. Indicates the migration context matching score; The name semantic matching score is calculated as follows: by using the edit distance algorithm or vector similarity algorithm, the text similarity of the tag names, tag aliases or normalized names in the old configuration tag definition table and the new configuration tag definition table is calculated, and the text similarity calculation results are normalized. The standardized name is the name obtained by unifying the case of the tag name, replacing synonyms, merging aliases, or cleaning the format. The semantic matching score calculation is defined as follows: using the term frequency-inverse document frequency (TF-IDF) algorithm or semantic vector model, the semantic similarity of the tag definition text in the old configuration tag definition table and the new configuration tag definition table is calculated, and the semantic similarity calculation results are normalized to obtain the score. The migration context matching score is calculated as follows: the context matching score is calculated by the overlap between the old configuration label definition table and the new configuration label definition table, based on the type of the label node, the type of the target data object, and the candidate labels at the same level. The context matching score is then normalized to obtain the result. The overlap of candidate labels at the same level is calculated based on the number of intersections and the number of unions between the set of candidate labels at the same level corresponding to the old configuration labels and the set of candidate labels at the same level corresponding to the new configuration labels. Tag semantic alignment score This is used to quantify the semantic alignment between two tags. The higher the semantic alignment score, the stronger the semantic consistency between the two tags.

[0041] In this embodiment, during the calculation of the semantic alignment score of the tag, the old configuration tag and the new configuration tag are represented as composite semantic objects containing name information, definition information and migration context information, respectively. Then, through the weighted fusion of multi-dimensional features, the originally scattered text clues, semantic clues and structural clues are uniformly mapped into comparable alignment scores, thereby avoiding making migration judgments based solely on a single tag name or a single field mapping.

[0042] Based on the above principles, the calculated tag semantic alignment score , it provides a unified semantic judgment basis for subsequent label mapping, label splitting, label merging, and candidate strategy generation, enabling the system to first determine "whether two labels can be semantically aligned and to what extent they can be aligned", and then decide whether to enter the specific migration processing. At the same time, it can also improve the accuracy and stability of cross-version label matching, reduce the probability of mis-matching in scenarios such as label renaming, label semantic merging, label semantic splitting, and same name with different meanings, thereby enhancing the reliability of subsequent candidate strategy generation and data repair results.

[0043] In this embodiment, according to the above-mentioned method for calculating the label semantic alignment score of the to-be-migrated labels, the following calculations are performed: Calculate the text similarity of the label names, label aliases, or normalized names of `car` and "车" to obtain the name semantic matching score; Calculate the semantic similarity of the label definition texts of the two to obtain the definition semantic matching score; Perform context matching on the所属标注节点类型, target data object types, and the set of candidate labels at the same layer of the two to obtain the migration context matching score.

[0044] S4. Set an alignment threshold, traverse the label semantic alignment scores of each to-be-migrated label, and construct a label alignment relationship table; The following is an introduction to the relevant operations in step S4 with a specific example: Traverse the label semantic alignment scores of each to-be-migrated label. As Figure 2 shown, when the label semantic alignment score is greater than the alignment threshold, it is determined that the old configuration label and the new configuration label can establish a migration alignment relationship, generate a migration alignment relationship identifier, and construct a label alignment relationship table based on the migration alignment relationship identifier; Otherwise, it is determined that the old configuration label and the new configuration label cannot establish a migration alignment relationship; The label alignment relationship table includes: the old configuration label identifier, the new configuration label identifier, and the label semantic alignment score corresponding to each migration alignment relationship identifier.

[0045] S5. Generate a number of candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. After the candidate strategy generation is completed, output a candidate strategy table, which includes: strategy identifier, atomic operation sequence, applicable conditions, and priority information; The following is an introduction to the relevant operations in step S5 with a specific example: Each candidate strategy is composed of an atomic operation sequence: S = {Op1 → Op2 →...}; As Figure 3 shown, the generation of the candidate strategy includes the following steps: S51. When the old configuration label and the new configuration label corresponding to the migration alignment relationship label satisfy one-to-one high confidence alignment, the label mapping operation is performed through the map function. The one-to-one high confidence alignment means that one old configuration label in the label alignment relationship table corresponds to only one new configuration label, and the corresponding label semantic alignment score is greater than the preset high confidence threshold. S52. When the old configuration tag corresponding to the migration alignment relationship tag matches several new configuration tag tags in the target configuration compatibility constraint information, and each new configuration tag tag has mutually exclusive applicable conditions, the old configuration tag tag is split by the split function, and triggering conditions are added to each split tag. The mutually exclusive applicable conditions are derived from the mutually exclusive constraints and condition triggering constraints in the target configuration compatibility constraint information. The triggering condition refers to the judgment condition obtained by parsing the condition expression, control logic, field dependency relationship, explicit / implicit rule or enable rule in the target configuration, which is used to limit the field value, context state or control condition of a certain split tag to be allowed to be selected, written or effective. The mutual exclusion application conditions are specifically determined by the following combination of information: First, the mutual exclusion relationship between candidate new tags obtained by parsing the target configuration, which is used to limit the simultaneous effectiveness of multiple new tags in the same target field, the same target data item, or the same trigger range; Second, the conditional expression, control node rule, or field dependency relationship obtained by parsing the target configuration, which is used to limit the field value, context state, or control condition that the corresponding new tag can be selected when they are satisfied. S53. When several old configuration tag identifiers corresponding to migration alignment relationship identifiers match the same new configuration tag identifier in the target configuration compatibility constraint information, perform a tag merging operation through the merge function for the old configuration tag identifiers and retain the source tag mark. S54. When the target field data structure corresponding to the migration alignment relationship identifier is inconsistent with the source field data structure, a data structure conversion operation is performed through the transform function; the target field data structure and the source field data structure are determined through historical annotation data information and target configuration compatibility constraint information. S55. When the historical annotation data information corresponding to the migration alignment relationship identifier does not meet the mandatory constraints in the target configuration compatibility constraint information and does not have the completion conditions, the data filtering operation is performed through the filter function.

[0046] The completion conditions include the existence of a default value, the existence of a mappable source field, the existence of a derivable field value, or the existence of a constraint compensation rule. The data filtering operation includes marking the corresponding historical labeled data item as non-migratable, or outputting the corresponding historical labeled data item to a set awaiting manual confirmation.

[0047] Each candidate policy includes at least the following composition information: label mapping table, label splitting rule, label merging rule, structure conversion rule, constraint compensation rule, data filtering rule, and execution order; among which, the label mapping table corresponds to the map operation result generated in step S51; the label splitting rule corresponds to the split operation result generated in step S52 and its additional trigger conditions; the label merging rule corresponds to the merge operation result generated in step S53 and the source label retention information; the structure conversion rule corresponds to the transform operation result generated in step S54; the constraint compensation rule and the data filtering rule correspond to the completion operation result or the filtering operation result generated based on the target configuration compatibility constraint information in step S55; the execution order is used to determine the sequence of execution of the foregoing various operations in the candidate policy.

[0048] The constraint compensation rule includes at least one of default value completion rule, field derivation rule, format completion rule, and conditional constraint completion rule.

[0049] The execution order includes at least a label mapping execution stage, a structure conversion execution stage, a constraint compensation execution stage, and a result verification stage.

[0050] After the candidate policy is generated, it is preferably to output a candidate policy table, and the candidate policy table includes at least a policy identifier, an atomic operation sequence, applicable conditions, and priority information; Among which, the policy identifier comes from the unique number or unique naming mark assigned to each candidate policy in the candidate policy generation stage; The atomic operation sequence comes from the result of combining the map, split, merge, transform, completion, or filter operations generated in steps S51 to S55 according to the preset execution order; The applicable conditions come from the trigger conditions, exclusive conditions, field type conditions, field level conditions, mandatory constraint conditions, or completable conditions parsed from the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information; The priority information comes from the sorting result determined in the candidate policy generation stage according to the label semantic alignment score, constraint matching degree, operation complexity, filtering operation usage, and source label retention integrity.

[0051] In this embodiment, when `car` and "车" satisfy one-to-one high-confidence alignment, a label mapping operation `map(car→车)` is generated; the one-to-one high-confidence alignment means that in the label alignment relationship table, `car` only corresponds to "车", and the corresponding label semantic alignment score is greater than the preset high-confidence threshold.

[0052] When the single-valued vehicle type field in the old configuration needs to be adapted to the list field in the new configuration, a data structure conversion operation `wrap_to_list` is generated; When the new configuration requires the vehicle type field to be a mandatory field, a constraint compensation operation is generated to check whether the field is empty after mapping or conversion.

[0053] Candidate strategies are thus formed, for example: Strategy_1 = map(car→车) + wrap_to_list + required_check Strategy_2 = filter(data_001) Among them, the execution order of `Strategy_1` includes a label mapping execution stage, a structure conversion execution stage, a constraint compensation execution stage, and a result verification stage; `Strategy_2` is used to filter corresponding data items when historical data fails to meet the target configuration constraints and cannot be repaired.

[0054] S6. Apply the several candidate strategies generated in step S5 to the historical annotation data information, and perform label mapping, structure conversion, constraint compensation, and result verification processing in sequence according to the execution order of the candidate strategies to obtain the candidate strategy execution results; The following is an introduction to the relevant operations in step S6 with a specific example: During strategy execution, according to the execution order of the candidate strategies, when performing label mapping, structure conversion, constraint compensation, and result verification processing on the historical annotation data information in sequence, intermediate result snapshots are output at each execution stage of each candidate strategy. The intermediate result snapshots at least include: the current data item identifier, the executed operation sequence, the current result field value, and the current constraint verification status.

[0055] In this embodiment, according to the above method, the following operations are performed: for the historical annotation data item `data_001`, when executing `Strategy_1`, first map the historical label value `car` to "车", then convert the single-valued field to a list field, and finally perform the mandatory constraint check.

[0056] Intermediate result snapshots are output at each execution stage. The intermediate result snapshots include the current data item identifier, the executed operation sequence, the current result field value, and the current constraint verification status. For example, after the label mapping execution stage, the intermediate result snapshot records that the current field value is "车"; after the structure conversion execution stage, the intermediate result snapshot records that the current field value is `["车"]`; after the constraint compensation execution stage, the intermediate result snapshot records that the mandatory constraint is satisfied.

[0057] S7. Define a data-level evaluation function to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. The relevant operations in step S7 will be introduced with specific examples: The data-level evaluation function is specifically as follows:

[0058] in, Indicates the first The policy score of each candidate policy. , and All represent strategy weights. , Indicates structural consistency score, Indicates the constraint satisfaction score. This indicates the context consistency score.

[0059] If multiple candidate strategies have the same score, the one that takes precedence is: A strategy with a small number of `filter` operations; Strategies that involve fewer data structure transformation steps; A strategy that retains relatively complete source tag information; The structural consistency score is the arithmetic mean of the structural compatibility scores; the structural compatibility score is calculated based on the consistency of field type, field hierarchy, and value cardinality between the field data structure corresponding to the candidate strategy execution result and the target field data structure in the target configuration compatibility constraint information; the field type consistency, field hierarchy consistency, and value cardinality consistency are respectively scored using binary scoring or weighted scoring; The constraint satisfaction score is the ratio of the number of satisfied constraints to the total number of constraints, which includes: mandatory constraints, mutually exclusive constraints, condition-triggered constraints, and value range constraints. Among them, both mutual exclusion constraints and conditional triggering constraints are derived from the target configuration compatibility constraint information; The target configuration compatibility constraint information is obtained by parsing the label definition, field definition, component configuration, single-selection or mutual exclusion rules, explicit / implicit control rules, conditional expressions, and component dependencies in the target configuration; the satisfaction of mutual exclusion constraints is preferably determined based on whether there are coexisting mutual exclusion labels, coexisting mutual exclusion field values, or simultaneously activated mutual exclusion components in the candidate strategy execution results; The satisfaction of conditional triggering constraints is preferably determined by whether the appearance status of a certain tag, field, or component in the execution result of the candidate strategy is consistent with its corresponding triggering condition. The context consistency score is the arithmetic mean of the degree of adjacency preservation; the degree of adjacency preservation is calculated based on the relationship preservation ratio between the migrated label and its corresponding labeled node, target data object, and associated constraints in the candidate strategy execution results; the relationship preservation ratio is the ratio of the number of preserved relationships to the number of relationships required by the target configuration. This step can be used to calculate the score of a single data item based on a single piece of historical annotation data, and to calculate the score of a batch based on a batch of historical annotation data.

[0060] In this embodiment, based on the above method, the following operations are performed: After `Strategy_1` is transformed by label mapping and field structure conversion, the historical data field value is `["car"]`, which satisfies the list field requirements and mandatory constraints in the target configuration. Its structure consistency score, constraint satisfaction score and context consistency score are all higher than `Strategy_2`. Therefore, `Strategy_1` is selected as the optimal strategy.

[0061] S8. Based on the optimal strategy, perform compatibility repair on the historical annotation data, verify the historical annotation data after compatibility repair, and output the repair result and verification result identifier.

[0062] The relevant operations in step S8 will be introduced with specific examples: like Figure 4 As shown, the verification specifically includes: S81. Determine whether the historical annotation data after compatibility repair meets the configuration constraints in the target configuration compatibility constraint information; If satisfied, the configuration constraint verification is marked as successful. Conversely, if the configuration constraint verification fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. When multiple candidate strategies have the same score, the candidate strategy with higher priority in the candidate strategy table is selected first. When the priority in the candidate strategy table is still the same, the candidate strategies with fewer `filter` operations, fewer data structure transformation steps, and more complete source tag information are selected first. S82. Based on the successful verification in S81, for the execution result of the same candidate strategy corresponding to the successful verification of the configuration constraint, according to the label alignment relationship table, determine whether the label values, field structure and context relationship in the historical annotation data after compatibility repair meet the semantic consistency requirements. If satisfied, the semantic consistency check of the tag is successful; Conversely, if the semantic consistency check fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. When multiple candidate strategies have the same score, the candidate strategy with higher priority in the candidate strategy table is selected first. When the priority in the candidate strategy table is still the same, the candidate strategies with fewer `filter` operations, fewer data structure transformation steps, and more complete source tag information are selected first. During rollback, the most recent intermediate result snapshot is used as the recovery point, and the result fields written by the current candidate strategy after the recovery point are cleared.

[0063] The rollback target is the currently labeled historical data item; when executed in batches, the data items that failed the verification are rolled back separately without affecting the data items that passed the verification.

[0064] S83. The historical labeled data after compatibility repair following verification in steps S81 and S82 is recorded as the repair result. When outputting the repair result, the candidate strategy identifier and the verification result identifier are also output.

[0065] When all candidate strategies fail to be validated, output the set of data items that need to be manually confirmed.

[0066] The verification result identifiers include: configuration constraint verification passed, configuration constraint verification failed, semantic consistency verification passed, and semantic consistency verification failed.

[0067] The optimal strategy can be selected either on a single historical labeled data point or on multiple historical labeled data points in a preset batch.

[0068] When executing according to a preset batch, the optimal strategy is preferably determined based on the average score or weighted score of each historical labeled data within the batch.

[0069] In this embodiment, based on `Strategy_1`, the historical labeled data item `data_001` obtained in step S1 is repaired for compatibility, and the repair result is obtained, for example: data_id=data_001 vehicle_type=["vehicle"] strategy_id=Strategy_1 check_status=pass.

[0070] Example 2 This embodiment further defines Embodiment 1, and provides an automatic data compatibility and repair system under the annotation mode evolution.

[0071] The system includes: a migration task acquisition module, a label definition module, a semantic alignment module, a policy generation module, a policy execution module, a data evaluation module, a verification rollback module, and a result output module; The migration task acquisition module is used to acquire migration task information; The tag definition module is used to build old configuration tag definition tables and new configuration tag definition tables based on migration task information; The semantic alignment module is used to calculate the semantic consistency of tags between the old and new configuration tag definition tables, and obtain the tag semantic alignment score for each tag to be migrated. ; The semantic alignment module is also used to set alignment thresholds, iterate through the semantic alignment scores of each tag to be migrated, and build a tag alignment relationship table; The strategy generation module is used to generate several candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. The strategy execution module is used to apply several candidate strategies to historical labeled data information to obtain the execution results of the candidate strategies; The data evaluation module is used to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. The verification rollback module is used to load an intermediate result snapshot and roll back to the current candidate strategy processing stage when verification fails. The results output module is used to output the repair results and the verification result identifier.

[0072] Example 3 This embodiment further defines Embodiment 1. This embodiment provides a method for automatic data compatibility and repair in a one-to-many tag splitting scenario.

[0073] In this embodiment, the old configuration contains the label `vehicle`, which is split into "car", "truck", and "bus" in the new configuration, and the three new labels have mutually exclusive application conditions. The target configuration compatibility constraint information includes mutual exclusion constraints and condition triggering constraints. The semantic alignment scores of `vehicle` with the three new labels are calculated respectively, and the alignment relationships that meet the threshold conditions are written into the label alignment relationship table.

[0074] The tag splitting operation is generated based on the tag alignment table, historical tagging data, and target configuration compatibility constraints, and trigger conditions are attached to each new tag. For example, when the vehicle type attribute field in the historical data is `truck`, a `split(vehicle→truck)` operation is generated; when the vehicle type attribute field is `bus`, a `split(vehicle→bus)` operation is generated.

[0075] The remaining steps are the same as those in Embodiment 1, and this embodiment outputs a repair result that satisfies the mutual exclusion constraint and the conditional trigger constraint.

[0076] Embodiment 4 This embodiment further limits Embodiment 1. This embodiment provides a method for automatically compatible and repairing data in a many-to-one label merging scenario.

[0077] In this embodiment, the labels `sedan` and `suv` exist in the old configuration, and in the new configuration, the two are merged into "car". Calculate the label semantic alignment scores of `sedan` and "car", and `suv` and "car" respectively, and output a label alignment relationship table. Generate a label merging operation according to the label alignment relationship table, the historical annotation data information, and the target configuration compatibility constraint information, and retain the source label markers in the candidate strategies.

[0078] The remaining steps are the same as those in Embodiment 1. After repair, the label values in the historical annotation data are uniformly "car", and at the same time, retain `source_label=sedan` or `source_label=suv` for subsequent traceability. This embodiment verifies whether the repaired historical annotation data meets the target configuration constraints and the semantic consistency requirements.

[0079] Embodiment 5 This embodiment further limits Embodiment 1. This embodiment provides a method for automatically compatible and repairing data in a structural change scenario.

[0080] In this embodiment, the vehicle type field in the old configuration is a single-choice field, and the vehicle type field in the new configuration is a multiple-choice field. The target configuration compatibility constraint information includes that the target field type is a list field. Generate a data structure conversion operation `wrap_to_list` according to the label alignment relationship table, the historical annotation data information, and the target configuration compatibility constraint information. Convert the single-value field in the historical annotation data into a list field, and retain the source markers corresponding to the original field values. Select candidate strategies that meet the requirements of the structural consistency score and the constraint satisfaction score. The remaining steps are the same as those in Embodiment 1, and this embodiment outputs a repair result and performs configuration constraint verification and semantic consistency verification.

[0081] The annotation object types, annotation methods, and data forms in the above embodiments can all be replaced or extended. The present invention is applicable to image, text, audio, video, and multi-modal annotation data, and its semantic alignment and repair process do not depend on the specific data type.

Claims

1. A method for automatic data compatibility and repair under evolution of annotation mode, characterized in that, The method includes the following steps: S1. Obtain migration task information: label definition information, historical annotation data information, and target configuration compatibility constraint information for each label to be migrated; S2. Based on the tag definition information, construct a tag definition object to obtain the old configuration tag definition table and the new configuration tag definition table; S3. For the old configuration tag definition table and the new configuration tag definition table, calculate the tag semantic consistency to obtain the tag semantic alignment score for each tag to be migrated. ; S4. Set the alignment threshold, iterate through the semantic alignment score of each tag to be migrated, and build a tag alignment relationship table; S5. Generate several candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. After the candidate strategies are generated, output the candidate strategy table, which includes: strategy identifier, atomic operation sequence, applicable conditions, and priority information. S6. Apply the candidate strategies generated in step S5 to the historical labeled data information, and perform label mapping, structure transformation, constraint compensation and result verification in the order of execution of the candidate strategies to obtain the execution results of the candidate strategies. S7. Define a data-level evaluation function to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. S8. Based on the optimal strategy, perform compatibility repair on the historical annotation data, verify the historical annotation data after compatibility repair, and output the repair result and verification result identifier.

2. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 1, characterized in that, Historical annotation data information includes: source field identifier, source field type, source field level, source field value base, and historical field values; The target configuration compatibility constraint information includes: target field type, target field level, value range constraint, target configuration structure, mandatory constraints, and configuration constraints.

3. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 2, characterized in that, The label definition information includes old label definitions and new label definitions; The construction of the tag definition object specifically involves: extracting the tag name, tag alias, tag definition text, affiliated annotation node, target data object, set of candidate tags at the same level, and constraint description of each tag to be migrated from the old tag definition and the new tag definition, and forming the old tag definition object and the new tag definition object; Generate old configuration tag definition tables and new configuration tag definition tables based on old tag definition objects and new tag definition objects; Both the old configuration label definition table and the new configuration label definition table include at least: label identifier, label name, label alias, label definition text, type of the label node to which it belongs, type of target data object, set of candidate labels at the same level, and constraint description.

4. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 3, characterized in that, The tag semantic consistency calculation includes: name semantic matching score calculation, definition semantic matching score calculation, and migration context matching score calculation; The semantic alignment score of each tag to be migrated The formula for calculation is: in, , and All of these represent preset weight parameters. , Indicates the semantic matching score of the name. This indicates the definition of semantic matching score. This represents the migration context matching score.

5. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 4, characterized in that, Step S4: Iterate through the semantic alignment score of each tag to be migrated. When the semantic alignment score is greater than the alignment threshold, determine that the old configuration tag and the new configuration tag can establish a migration alignment relationship, generate a migration alignment relationship identifier, and construct a tag alignment relationship table based on the migration alignment relationship identifier. Conversely, it is determined that the old configuration label and the new configuration label cannot establish a migration alignment relationship; The label alignment table includes: the old configuration label identifier, the new configuration label identifier, and the label semantic alignment score corresponding to each migration alignment identifier.

6. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 5, characterized in that, The generation of the candidate strategy includes the following steps: S51. When the old configuration label and the new configuration label corresponding to the migration alignment relationship label satisfy a one-to-one high-confidence alignment, perform the label mapping operation. S52. When the old configuration tag corresponding to the migration alignment relationship tag matches several new configuration tag tags in the target configuration compatibility constraint information, and each new configuration tag tag has mutually exclusive applicable conditions, perform a tag splitting operation on the old configuration tag tag. S53. When several old configuration tag identifiers corresponding to migration alignment relationship identifiers match the same new configuration tag identifier in the target configuration compatibility constraint information, perform a tag merging operation for the old configuration tag identifiers. S54. When the target field data structure corresponding to the migration alignment relationship identifier is inconsistent with the source field data structure, a data structure conversion operation is performed; the target field data structure and the source field data structure are determined through historical annotation data information and target configuration compatibility constraint information. S55. When the historical annotation data information corresponding to the migration alignment relationship identifier does not meet the mandatory constraints in the target configuration compatibility constraint information and does not have the completion conditions, perform data filtering operation; when there are default values, mappable source fields, derived field values ​​or constraint compensation rules, perform constraint compensation operation.

7. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 6, characterized in that, In step S6, during the process of label mapping, structure transformation, constraint compensation and result verification in the order of execution of candidate strategies, an intermediate result snapshot is output at each execution stage of the candidate strategy.

8. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 7, characterized in that, The data-level evaluation function is specifically as follows: in, Indicates the first The strategy score of each candidate strategy. , and All represent strategy weights. , Indicates structural consistency score. Indicates the constraint satisfaction score. This indicates the context consistency score.

9. The method for automatic data compatibility and repair under annotation pattern evolution according to claim 8, characterized in that, The verification process specifically includes: S81. Determine whether the historical annotation data after compatibility repair meets the configuration constraints in the target configuration compatibility constraint information; If satisfied, the configuration constraint verification is marked as successful. Conversely, if the configuration constraint verification fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. S82. Based on the successful verification in S81, determine whether the label values, field structures, and contextual relationships in the historical annotation data after compatibility repair meet the semantic consistency requirements according to the label alignment relationship table. If satisfied, the semantic consistency check of the tag is successful; Conversely, if the semantic consistency check fails, the current candidate strategy processing stage is rolled back based on the intermediate result snapshot, and the next candidate strategy is selected and re-executed in descending order of candidate strategy scores. S83. The historical labeled data after compatibility repair following verification in steps S81 and S82 is recorded as the repair result. The verification result identifiers include: configuration constraint verification passed, configuration constraint verification failed, semantic consistency verification passed, and semantic consistency verification failed.

10. A data automatic compatibility and repair system under annotation mode evolution, characterized in that, The system is used to implement the method according to any one of claims 1 to 9, and the system includes: a migration task acquisition module, a label definition module, a semantic alignment module, a policy generation module, a policy execution module, a data evaluation module, a verification rollback module, and a result output module; The migration task acquisition module is used to acquire migration task information; The tag definition module is used to build old configuration tag definition tables and new configuration tag definition tables based on migration task information; The semantic alignment module is used to calculate the semantic consistency of tags between the old and new configuration tag definition tables, and obtain the tag semantic alignment score for each tag to be migrated. ; Used to set alignment thresholds, iterate through the semantic alignment scores of each tag to be migrated, and build a tag alignment relationship table; The strategy generation module is used to generate several candidate strategies based on the label alignment relationship table, historical annotation data information, and target configuration compatibility constraint information. The strategy execution module is used to apply several candidate strategies to historical labeled data information to obtain the execution results of the candidate strategies; The data evaluation module is used to evaluate the execution results of several candidate strategies, obtain several strategy scores, and select the candidate strategy with the highest strategy score as the optimal strategy. The verification rollback module is used to load an intermediate result snapshot and roll back to the current candidate strategy processing stage when verification fails. The results output module is used to output the repair results and the verification result identifier.

Images