Architecture standard inspection method and system based on artificial intelligence

Abstract

The invention provides an artificial intelligence-based architecture standard inspection method and system, and the method comprises the steps: determining a first business domain architecture specification and a first system set corresponding to a target development demand based on the received target development demand; and determining a second system set related to the first service domain architecture specification. And if the first system set comprises other systems except the second system set, obtaining a target system set and a target service domain architecture specification according to the first system set and the second system set. Calling a pre-trained artificial intelligence model to inspect at least one of interface calling, message content, log record and data flow of the system included in the target system set according to the target service domain architecture specification, and if at least one system includes development content which does not conform to the target service domain architecture specification, executing the step of executing the step of executing the step of executing the step of executing the step of executing the step of executing the step of executing the step of executing the step of executing the step of executing the step, and if yes, outputting exception prompt information related to the development content. According to the method, the inspection efficiency and the inspection accuracy of the system architecture standard inspection can be improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to an artificial intelligence-based method and system for verifying architectural standards. Background Technology

[0002] In the field of software development, for system function development applied to multi-system architectures, a single development requirement typically requires coordination and calls to multiple system architectures to achieve its functionality. Currently, while some enterprises have established business domain architecture specifications for system function development applied to multi-system architectures to integrate various relevant standards and requirements within the business domain, hoping to ensure reasonable system architecture planning and function implementation based on these specifications during actual development, and to guarantee that function calls and collaboration between multiple systems follow a unified and standardized process, thus ensuring the integrity, consistency, and stability of system functions, if the development process and results of a development requirement do not conform to the business domain architecture specifications, i.e., do not meet system architecture standards, problems such as missing architecture identification, difficulty in troubleshooting, and consequently inadequate rectification can arise, impacting business operations and causing losses. However, currently, the verification of whether the development process and results of a development requirement conform to system architecture standards mainly relies on manual verification, which suffers from low verification efficiency and poor verification accuracy.

[0003] Therefore, improving the efficiency and accuracy of system architecture standard verification is an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide an artificial intelligence-based method and system for verifying architectural standards, so as to improve the verification efficiency and accuracy of system architecture standard verification.

[0005] Firstly, this application provides an artificial intelligence-based method for verifying architectural standards, including: Based on the received target development requirements, a first business domain architecture specification corresponding to the target development requirements and a first system set corresponding to the functional parsing results of the target development requirements are determined. The first business domain architecture specification is related to the requirement description information in the target development requirements. Determine the second set of systems involved in the first business domain architecture specification; If the first system set includes other systems besides the second system set, then based on the first system set and the second system set, a target system set and a target business domain architecture specification corresponding to the target system set are obtained. The target business domain architecture specification includes the first business domain architecture specification and the second business domain architecture specification corresponding to the first system set. The pre-trained artificial intelligence model is invoked to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, to determine whether each system includes development content that does not conform to the target business domain architecture specification; If at least one of the systems includes development content that does not conform to the target business domain architecture specification, then an exception message related to the development content will be output.

[0006] Optionally, the pre-trained artificial intelligence model is invoked to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, to determine whether each system includes development content that does not conform to the target business domain architecture specification, including: The artificial intelligence model performs semantic parsing and feature transformation on the target business domain architecture specification to generate a specification feature matrix, and extracts fields and models features of the systems to be tested in the target system set to generate a feature matrix to be tested. Dimension mapping and alignment are performed on the standard feature matrix and the feature matrix to be tested to generate aligned feature pairs. Dimensional similarity calculation and weighted evaluation are then performed on the aligned feature pairs to obtain a matching degree matrix. The matching degree matrix is ​​subjected to threshold judgment and difference classification to generate difference evaluation results; Based on the difference assessment results, the corresponding system and specification clauses are mapped and associated to obtain system difference association items; The verification results determine whether the system includes development content that does not conform to the target business domain architecture specification based on the system difference correlation items.

[0007] Optionally, the step of performing semantic parsing and feature transformation on the target business domain architecture specification to generate a specification feature matrix includes: Receive the target business domain architecture specification text; The target business domain architecture specification text is processed by word segmentation and stop word filtering to obtain a specification keyword sequence; Semantic role labeling is performed on the specified keyword sequence to identify semantic roles including constraint subject, constraint condition, and constraint threshold; The annotated sequence of standard keywords is converted into structured constraint entries, which include constraint subject identifier, constraint condition expression, and constraint threshold range. Perform feature vectorization transformation on the structured constraint entries to map the constraint condition expression into a numerical feature vector and the constraint threshold range into an interval feature vector; The standardized feature matrix is ​​generated by concatenating the numerical feature vector and the interval feature vector according to the constraint subject dimension.

[0008] Optionally, the step of extracting fields and modeling features of the systems to be tested in the target system set to generate a feature matrix to be tested includes: Receive the test content of the systems included in the target system set; Perform field parsing and entity recognition on the content to be inspected to extract entities including field name, field value, and field relationship; Perform data type conversion and standardization on the field values ​​to map non-numeric field values ​​to numeric codes; Graph structure modeling is performed on the field relationships to generate a field relationship adjacency matrix; The standardized field values ​​are concatenated with the field association adjacency matrix according to the field dimensions to generate the feature matrix to be tested.

[0009] Optionally, the step of performing dimensional mapping and alignment processing on the standardized feature matrix and the feature matrix to be tested to generate aligned feature pairs, and performing dimensional similarity calculation and weighted evaluation on the aligned feature pairs to obtain a matching degree matrix, includes: According to the preset feature dimension mapping table, the dimension rearrangement and zero-padding process is performed on the normalized feature matrix and the feature matrix to be tested to obtain aligned feature pairs. In the aligned feature pairs, the dimension order and the number of feature dimensions of the normalized feature matrix and the feature matrix to be tested are consistent. The feature dimension mapping table contains a one-to-one correspondence between the normalized feature dimensions and the feature dimensions to be tested. Perform a dimension-wise cosine similarity calculation on the alignment feature pairs to obtain an initial matching degree vector; The initial matching degree vector is multiplied element by element by the preset constraint weight table to obtain the weighted matching degree vector. The constraint weight table contains the importance weights corresponding to each constraint subject. The matching degree matrix is ​​obtained by concatenating the weighted matching degree vector according to the system dimension.

[0010] Optionally, the step of determining whether the system includes development content that does not conform to the target business domain architecture specification based on the system difference correlation item includes: Perform deduplication on the system difference association items to remove duplicate target difference association items; Based on the system identifier and the importance of the constraint clauses, the deduplicated difference association items are sorted to obtain the sorted difference association items; Perform formatting transformation on the sorted difference-related items to generate structured report entries containing system name, difference type, clause content, actual value, and expected value; Perform statistical analysis on the structured report entries, calculate the number and severity of differences for each system, and obtain the statistical analysis results; Based on the structured report entries and the statistical analysis results, the test results for each of the systems are generated.

[0011] Optionally, the method further includes: Collect the first processing feedback result corresponding to the abnormal prompt information. The first processing feedback result includes the marking information of misjudged differences, the supplementary information of uncovered differences, and the correction information of difference classification errors. The structured report entries and statistical analysis results of each system are extracted from the results of the test, and the corrected difference type, corrected expected value, and new constraints are extracted from the first processing feedback results. The corrected difference type is associated with the matching degree matrix in the test results to determine the similarity calculation rules that need to be adjusted in the artificial intelligence model, and the similarity calculation rules are adjusted accordingly. The corrected expected value is correlated with the normalized feature matrix in the test results to determine the threshold judgment rule that needs to be adjusted in the artificial intelligence model, and the threshold judgment rule is adjusted accordingly. Based on the newly added constraints, update the canonical feature transformation rules in the artificial intelligence model; The artificial intelligence model is updated based on the adjustments to the similarity calculation rules, the threshold judgment rules, and the updates to the standardized feature transformation rules.

[0012] Optionally, the method further includes: Collect the second processing feedback result corresponding to the abnormal prompt information. The second processing feedback result includes feedback information for missing standard clauses and correction information for ambiguous standard clauses. Extract the statistical results of the number of differences and the distribution results of the difference types of each system from the results of the test, and extract the new normative clause suggestions and the revised normative clause descriptions from the second processing feedback results; Associate the frequently occurring difference types in the difference quantity statistics with the existing clauses in the target business domain architecture specification to determine the existing clauses that need to be supplemented or modified. Based on the proposed new specification clauses, new structured constraint entries are generated, which include constraint subject identifier, constraint condition expression, and constraint threshold range. The new structured constraint entries and the revised specification clause descriptions are verified for consistency to ensure that they do not conflict with existing clauses in the target business domain architecture specification. The validated new structured constraint entries and revised specification clause descriptions are added to the target business domain architecture specification to update the target business domain architecture specification.

[0013] Optionally, the method further includes: In the process of verifying at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, the associated systems involved in the system are determined, and the associated systems are related to the functional analysis results of the target development requirements; Based on the inspection objects related to the function parsing results in the associated system and the business domain architecture specifications corresponding to the inspection objects, the inspection objects in the associated system are inspected to obtain the inspection results of the associated system. The inspection objects include at least one of the following: interface calls, message content, log records, and data streams in the associated system. Based on the test results of the associated system, determine whether the associated system includes development content that does not conform to the business domain architecture specification corresponding to the test object; If at least one of the associated systems includes development content that does not conform to the business domain architecture specification corresponding to the test object, then supplementary error message information related to the development content will be output.

[0014] Secondly, this application provides an AI-based architecture standard verification system, which includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the AI-based architecture standard verification system implements the aforementioned AI-based architecture standard verification method.

[0015] The AI-based architecture standard verification method and system provided in this application, based on received target development requirements, determines a first business domain architecture specification corresponding to the target development requirements and a first system set corresponding to the functional analysis results of the target development requirements. The first business domain architecture specification is related to the requirement description information in the target development requirements. A second system set involved in the first business domain architecture specification is determined. If the first system set includes systems other than those in the second system set, then based on the first system set and the second system set, a target system set and the target business domain architecture specification corresponding to the target system set are obtained. The pre-trained artificial intelligence model is invoked to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification. This determines whether each system contains development content that does not conform to the target business domain architecture specification. If at least one system contains development content that does not conform to the target business domain architecture specification, an exception message related to the development content is output to promptly remind developers to correct the abnormal development content. This ensures that the development process and results conform to the business domain architecture specification, guaranteeing the stability and reliability of the system architecture. This avoids the shortcomings of existing technologies that rely primarily on manual inspection, which suffers from low inspection efficiency and poor accuracy, making it difficult to comprehensively and promptly identify development content that does not conform to the architecture standard. Such inspections can lead to various architecture-related problems after system deployment, affecting normal business operations. Therefore, this method improves the inspection efficiency and accuracy of system architecture standard verification. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] Figure 1 A flowchart illustrating an AI-based architecture standard verification method provided for embodiments of this application; Figure 2 This is a schematic diagram of an architecture standard verification system based on artificial intelligence, provided as an embodiment of this application.

[0018] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0020] Figure 1 This is a flowchart illustrating an AI-based architecture standard verification method provided in this application embodiment. It should be understood that in other embodiments, the order of some steps in this AI-based architecture standard verification method can be shared according to actual needs, or some steps can be omitted or maintained. Figure 1 As shown, the method may include the following steps: Step S110: Based on the received target development requirements, determine the first business domain architecture specification corresponding to the target development requirements and the first system set corresponding to the functional analysis result of the target development requirements. The first business domain architecture specification is related to the requirement description information in the target development requirements.

[0021] Step S111: Parse the requirement description information in the target development requirements to obtain the keyword set in the requirement description information.

[0022] Upon receiving the target development requirements, the first step is to analyze the requirement description information within those requirements.

[0023] For requirement description information, natural language processing techniques can be used for parsing. For example, word segmentation can be performed on the requirement description information, such as rule-based segmentation or statistical segmentation. After word segmentation, part-of-speech tagging is performed on the segmentation results to clarify the part of speech of each word, such as noun, verb, adjective, etc., to help extract keywords later. Through these operations, words with key semantics are extracted from the requirement description information to form a keyword set.

[0024] Step S112: Perform matching processing based on the keywords included in the keyword set to determine the first business domain architecture specification corresponding to the keyword.

[0025] In this step, matching is performed on the keywords included in the keyword set to determine the first business domain architecture specification corresponding to each keyword. Specifically, the first business domain architecture specification corresponding to a keyword can be obtained based on the mapping relationship between keywords and business domain architecture specifications. For example, each keyword in the keyword set can be compared with the keywords corresponding to each business domain architecture specification, such as using a string matching algorithm (e.g., the Levenshtein distance algorithm) to calculate the similarity between keywords. If the similarity reaches a certain threshold, the corresponding first business domain architecture specification is considered to have been found.

[0026] Step S113: Decompose the functional requirements of the target development requirements to obtain functional analysis results, which include multiple sub-functional requirements.

[0027] In this step, the functional requirements of the target development needs can be decomposed to obtain functional analysis results, which include multiple sub-functional requirements. Functional requirement decomposition can be achieved, for example, using a functional decomposition tree method, starting from the overall functional requirements and gradually breaking them down into smaller sub-functional requirements. For instance, for the development requirements of an e-commerce platform's rights management system, the overall functional requirements might be to achieve full-process management of rights. This can be decomposed into sub-functional requirements for rights creation, rights issuance, and rights verification, etc.

[0028] Step S114: Match the sub-functional requirements with the system functions in the preset system library to determine the system that can realize the sub-functional requirements.

[0029] In this step, sub-functional requirements are matched with system functions in a pre-defined system library to determine which systems can fulfill the sub-functional requirements. The pre-defined system library is a database storing detailed descriptions of various internal enterprise systems and their functions. During matching, the descriptions of sub-functional requirements are compared with the descriptions of system functions in the system library. For example, text similarity calculation methods such as Term Frequency-Inverse Document Frequency (TF-IDF) combined with cosine similarity calculations can be used to assess the similarity between sub-functional requirements and system functions. If the similarity exceeds a set threshold, the system is considered capable of fulfilling the corresponding sub-functional requirement.

[0030] Step S115: Combine all systems capable of fulfilling the sub-functional requirements to obtain the first system set corresponding to the functional analysis result of the target development requirements.

[0031] By combining all systems capable of fulfilling the sub-functional requirements, a first set of systems corresponding to the functional analysis results of the target development requirements is obtained. During the combination process, it is necessary to ensure the compatibility and collaborative working capabilities between the systems. For example, the system interfaces and data formats can be checked and evaluated to ensure they function correctly within the scenario of the target development requirements.

[0032] Step S120: Determine the second set of systems involved in the first business domain architecture specification.

[0033] In this embodiment, when determining the second set of systems involved in the first business domain architecture specification, a comprehensive text analysis of the first business domain architecture specification is first performed. For example, Named Entity Recognition (NER) methods from Natural Language Processing can be used to identify entities such as system names and system identifiers mentioned in the architecture specification text. Specifically, Named Entity Recognition can employ machine learning-based methods such as Conditional Random Field (CRF) models, learning from a large amount of labeled data to identify system-related entities in the text.

[0034] After identifying system-related entities, they are matched against the enterprise's internal system information database. This database stores detailed information about all of the enterprise's systems, including system names, functions, and interfaces. During matching, the identified system-related entities are compared with the system names and identifiers in the database. For example, string matching algorithms such as exact matching and fuzzy matching can be used. If a match is successful, the system is added to a second set of systems.

[0035] Furthermore, the business processes and data flows in the architecture specifications can be analyzed to infer potentially involved systems. For example, if the architecture specifications describe a business process that involves data transfer from one system to another, then both systems are likely involved. By analyzing the business processes and data flows, some systems that are not explicitly mentioned in the text but are actually relevant can be identified, thus completing the second set of systems.

[0036] Step S130: If the first system set includes other systems besides the second system set, then based on the first system set and the second system set, a target system set and a target business domain architecture specification corresponding to the target system set are obtained. The target business domain architecture specification includes the first business domain architecture specification and the second business domain architecture specification corresponding to the first system set.

[0037] In this embodiment, set operations can be used to compare the first system set and the second system set to identify other systems in the first system set that do not belong to the second system set. Specifically, for example, each system in the first system set can be iterated over to check if it exists in the second system set. If it does not exist, it is marked as an other system.

[0038] Once other systems are identified, the first and second system sets are merged to form the target system set. During the merging process, it is crucial to ensure the uniqueness of the systems and avoid adding duplicate systems. For example, data structures such as hash tables can be used to implement system uniqueness checks.

[0039] For the target business domain architecture specifications, in addition to the first business domain architecture specifications, it is also necessary to determine the second business domain architecture specifications corresponding to the first system set. Specifically, each system in the first system set can be analyzed in detail to understand its functions, data processing flows, etc. Based on this information, and in conjunction with the enterprise's internal architecture specification system, suitable architecture specifications for these systems can be identified. For example, for a newly introduced data analysis system, it may be necessary to follow data storage specifications, data analysis algorithm specifications, etc.

[0040] Then, the first business domain architecture specifications and the second business domain architecture specifications are integrated to form the target business domain architecture specifications. During the integration process, it is necessary to ensure consistency and compatibility between the specifications to avoid conflicts and contradictions.

[0041] Optionally, if the first system set does not include any other systems besides the second system set, then the target system set is either the second system set or the first system set, and the target business domain architecture specification corresponding to the target system set is the first business domain architecture specification.

[0042] Step S140: Invoke the pre-trained artificial intelligence model to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, and determine whether each system includes development content that does not conform to the target business domain architecture specification.

[0043] Step S141: The artificial intelligence model performs semantic parsing and feature transformation on the target business domain architecture specification to generate a specification feature matrix, and extracts fields and models features of the systems to be tested in the target system set to generate a feature matrix to be tested.

[0044] Step S1411: Receive the target business domain architecture specification text.

[0045] In this embodiment, the artificial intelligence model first receives the target business domain architecture specification presented in text form. The text of the target business domain architecture specification may come from various channels, such as the enterprise's internal document management system, the requirements specification of a project, etc. During the receiving process, the artificial intelligence model can perform a preliminary format check on the text of the target business domain architecture specification to ensure that the text content is complete and there are no problems such as garbled characters.

[0046] For example, if the text of the target business domain architecture specification is obtained from the document management system, there may be character loss or garbled characters during the format conversion process. The artificial intelligence model can identify and process these problems to ensure that the subsequent processed text is accurate and error-free.

[0047] Step S1412: Perform word segmentation and stop word filtering on the text of the target business domain architecture specification to obtain a sequence of standard keywords.

[0048] After receiving the text of the target business domain architecture specification, the artificial intelligence model can perform word segmentation on the text of the target business domain architecture specification. During the word segmentation process, the artificial intelligence model can consider the semantics and grammatical structure of words to ensure the accuracy of word segmentation. For example, for the sentence "The rule for rights distribution stipulates that the amount of rights distributed to a single user per time shall not exceed the specified threshold", after word segmentation, words such as "rights distribution", "rule", "stipulate", "single user", "per time", "rights distribution amount", "shall not exceed", "specified threshold" can be obtained.

[0049] Then stop word filtering is performed. Stop words are words that frequently appear in the text but have no actual semantics, such as "of", "is", "in", etc. The artificial intelligence model can use a pre-defined stop word list to remove the stop words in the word segmentation result. After stop word filtering, a sequence of standard keywords is obtained. Among them, stop word filtering can reduce the noise in subsequent processing and highlight the role of keywords.

[0050] Exemplarily, in the above example, after filtering stop words, keywords such as "rights distribution", "rule", "single user", "per time", "rights distribution amount", "specified threshold" may be obtained.

[0051] Step S1413: Perform semantic role labeling on the sequence of standard keywords to identify semantic roles including the constraint subject, constraint conditions, and constraint thresholds.

[0052] After obtaining the sequence of standard keywords, the artificial intelligence model can use a deep learning model such as an algorithm based on Long Short-Term Memory (LSTM) to perform semantic role labeling on the sequence of standard keywords. This deep learning model is a model that, through learning a large amount of labeled data, is capable of identifying the semantic roles of each word in a sentence.

[0053] For example, taking the rule that "the amount of benefits distributed to a single user in a single transaction shall not exceed a specified threshold" as an example, the deep learning model can identify that the subject of the constraint is "the amount of benefits distributed to a single user in a single transaction," the constraint condition is "shall not exceed," and the constraint threshold is "the specified threshold." During the annotation process, the deep learning model can also consider the grammatical relationships and semantic connections between words to accurately determine the semantic role of each word.

[0054] Step S1414: Convert the annotated sequence of standard keywords into structured constraint entries, wherein the structured constraint entries include constraint subject identifier, constraint condition expression, and constraint threshold range.

[0055] After semantic role labeling is completed, the AI ​​model converts the labeled sequence of standardized keywords into structured constraint entries. Specifically, for example, a set of structured constraint entry templates can be defined, and the labeled information can be filled into these templates. In the example above, the constraint subject identifier could be "single user, single-time benefit disbursement amount," and the constraint condition expression could be "less than or equal to" ("must not exceed" can be converted to "less than or equal to"), with the constraint threshold range determined according to actual regulations. During the conversion process, the AI ​​model can further process and standardize the semantic roles to ensure that the structured constraint entries accurately express the requirements of the regulations.

[0056] Step S1415: Perform feature vectorization transformation on the structured constraint entries to map the constraint condition expression into a numerical feature vector and the constraint threshold range into an interval feature vector.

[0057] For structured constraint entries, the artificial intelligence model can perform feature vectorization transformation. Specifically, constraint expressions can be mapped to numerical feature vectors using methods such as one-hot encoding. Different constraint expressions, such as "less than or equal to," "equal to," and "greater than or equal to," can be represented by different binary vectors. For example, "less than or equal to" can be represented by [1, 0, 0], "equal to" by [0, 1, 0], and "greater than or equal to" by [0, 0, 1], etc.

[0058] For constraint threshold ranges, they can be converted into interval feature vectors. Specifically, assuming the constraint threshold range is a specific interval, such as [lower limit, upper limit], this interval can be represented by a two-dimensional vector. During the feature vectorization process, the artificial intelligence model can accurately convert each part of the structured constraint item into vector form according to predefined encoding rules and mapping methods for subsequent calculation and processing.

[0059] Step S1416: Concatenate the numerical feature vector and the interval feature vector according to the constraint subject dimension to generate the normalized feature matrix.

[0060] After completing the feature vectorization transformation, the AI ​​model can concatenate the numerical feature vectors and interval feature vectors according to the constraint subject dimension. Specifically, during the concatenation process, methods such as zero-padding can be used to ensure that the vector dimensions are consistent. For example, if the numerical feature vector corresponding to a certain constraint subject has a dimension of 3 and the interval feature vector has a dimension of 2, then the concatenated vector will have a dimension of 5. Arranging the concatenated vectors corresponding to each constraint subject according to the order of the constraint subjects generates the canonical feature matrix. The canonical feature matrix can comprehensively reflect the feature information of the target business domain architecture specification, providing a basis for subsequent verification.

[0061] Step S1417: Receive the test content of the systems included in the target system set.

[0062] The content to be verified may include interface call data, message content, log records, data streams, etc., and the same type of content to be verified may have different formats and characteristics. The artificial intelligence model receives the content to be verified from each system in the target system set and performs unified reception and preliminary processing on it.

[0063] For example, API call data can be transmitted in JSON or XML format, and the AI ​​model can use a parsing method adapted to the corresponding format to parse it and extract key information; for log records, they can be in text format, and the AI ​​model can perform text preprocessing to remove useless information.

[0064] Step S1418: Perform field parsing and entity recognition on the content to be inspected to extract entities including field name, field value, and field relationship.

[0065] After receiving the content to be inspected, the artificial intelligence model performs field parsing and entity recognition. Specifically, different parsing methods can be used for different types of content to be inspected.

[0066] Specifically, for API call data, fields such as API name, call parameters, and return value can be parsed; for message content, fields such as message header and body information can be parsed. During the parsing process, the artificial intelligence model can extract the name and value of each field based on the data format and structure.

[0067] Meanwhile, AI models can use named entity recognition technology to identify entities such as system names, user identifiers, and data types within fields. For example, in API call data, the system name and user identifier of the caller can be identified. Through field parsing and entity recognition, key information can be extracted from the content to be examined, providing a foundation for subsequent feature modeling.

[0068] Step S1419: Perform data type conversion and standardization processing on the field value to map the non-numeric field value to a numeric code.

[0069] After extracting the field values, the AI ​​model needs to perform data type conversion and standardization. For non-numeric field values ​​such as strings and dates, encoding methods can be used to map them to numeric codes. For example, different user roles, such as "regular user," "VIP user," and "administrator," can be encoded using numbers like 1, 2, and 3 respectively. Date field values ​​can be converted to numeric forms such as timestamps. During the conversion process, the AI ​​model can select appropriate encoding methods based on different data types and business needs to ensure that field values ​​are processed in a consistent numeric form.

[0070] Step S14110: Perform graph structure modeling on the field association relationship to generate a field association adjacency matrix.

[0071] After determining the relationships between fields, the AI ​​model can use a graph database to store these relationships, thus creating a graph structure model of the field relationships. In this graph, nodes represent fields, and edges represent the relationships between them. For example, in a rights management system, the "User Rights Information" field and the "User Identity Information" field may be related; the field relationship model can connect these two nodes with edges in the graph.

[0072] By analyzing the graph structure, artificial intelligence models can generate field association adjacency matrices. These matrices can be, for example, two-dimensional matrices where elements represent whether a relationship exists between nodes. If two nodes are associated, the corresponding element in the matrix is ​​1; otherwise, it is 0. Through graph structure modeling and adjacency matrix generation, the relationships between fields can be clearly represented, providing a basis for subsequent feature concatenation.

[0073] Step S14111: Concatenate the standardized field values ​​with the field association adjacency matrix according to the field dimensions to generate the feature matrix to be tested.

[0074] After standardizing the field values ​​and generating the field adjacency matrix, the AI ​​model concatenates the standardized field values ​​with the field adjacency matrix based on the field dimensions. During this concatenation process, the dimensions and order of the matrices need to be considered to ensure comparability with the normalized feature matrix. For example, if the dimension of the standardized field value vector is n and the dimension of the adjacency matrix is ​​m×m, the dimensions of the concatenated matrix need to be adjusted accordingly.

[0075] By using the above splicing method, a feature matrix to be tested is generated that comprehensively reflects the feature information of the system to be tested in the target system set.

[0076] Step S142: Perform dimension mapping and alignment processing on the standard feature matrix and the feature matrix to be tested to generate aligned feature pairs, and perform dimension-wise similarity calculation and weighted evaluation on the aligned feature pairs to obtain the matching degree matrix.

[0077] Step S1421: According to the preset feature dimension mapping table, perform dimension rearrangement and zero-padding on the normalized feature matrix and the feature matrix to be tested to obtain aligned feature pairs. In the aligned feature pairs, the dimension order and number of feature dimensions of the normalized feature matrix and the feature matrix to be tested are consistent. The feature dimension mapping table contains a one-to-one correspondence between the normalized feature dimensions and the feature dimensions to be tested.

[0078] In this step, the operation can begin based on a predefined feature dimension mapping table. This table is predefined and clearly defines the correspondence between the standardized feature dimensions and the feature dimensions to be tested. For example, the standardized feature matrix contains dimensions such as "rights distribution amount" and "rights distribution time," while the feature matrix to be tested contains dimensions such as "distribution amount parameter" and "call time." The feature dimension mapping table can determine that "rights distribution amount" corresponds to "distribution amount parameter," and "rights distribution time" corresponds to "call time."

[0079] Based on this mapping relationship, the dimensions of the canonical feature matrix and the feature matrix to be tested can be rearranged. For the canonical feature matrix and the feature matrix to be tested, the column order is adjusted according to the correspondence in the mapping table to make their dimension order consistent. If the number of feature dimensions of the two matrices is inconsistent, zero-padding can be used to handle this.

[0080] For example, if the canonical feature matrix has 5 dimensions while the feature matrix to be tested only has 4 dimensions, a new dimension can be added to the feature matrix to be tested, and the elements of that dimension can be initialized to 0. Through dimension rearrangement and zero-padding, aligned feature pairs are obtained, ensuring that the canonical feature matrix and the feature matrix to be tested are consistent in dimensional order and number of feature dimensions, thus preparing for subsequent similarity calculations.

[0081] Step S1422: Perform a dimension-wise cosine similarity calculation on the aligned feature pairs to obtain an initial matching degree vector.

[0082] After obtaining the aligned feature pairs, a dimension-wise cosine similarity calculation is performed on them. Cosine similarity is determined by calculating the cosine of the angle between two vectors. For each column of the canonical feature matrix and the feature matrix to be tested in the aligned feature pair, it can be treated as a vector, and their cosine similarity is calculated. For example, the cosine similarity value is calculated for the first column vector of the canonical feature matrix and the first column vector of the feature matrix to be tested.

[0083] Arranging the cosine similarity values ​​of all columns in column order yields the initial matching vector. This vector reflects the similarity between the canonical feature matrix and the feature matrix to be tested across various dimensions, providing a basis for subsequent weighted evaluation.

[0084] Step S1423: Multiply the initial matching degree vector element by element with the preset constraint weight table to obtain a weighted matching degree vector. The constraint weight table contains the importance weights corresponding to each constraint subject.

[0085] In this step, a pre-defined constraint weight table can be used to weight the initial matching degree vector. This table assigns an importance weight to each constraint entity, which can be predefined based on actual needs. Different constraint entities may have different levels of importance in the business, thus requiring different weights. For example, in a rights management system, the constraint entity "Rights Issuance Rules" may be more important than "Rights Data Storage Format," therefore, "Rights Issuance Rules" would have a higher importance weight.

[0086] The AI ​​model multiplies each element of the initial matching degree vector with the corresponding weight of the constraint subject in the constraint weight table element-wise to obtain a weighted matching degree vector. For example, the first element of the initial matching degree vector corresponds to the matching degree of the "rights distribution rule," which is multiplied by its corresponding weight in the constraint weight table to obtain the corresponding weighted matching degree vector. This weighting process highlights the matching status of important constraint subjects.

[0087] Step S1424: Concatenate the weighted matching degree vector according to the system dimension to obtain the matching degree matrix.

[0088] In this step, each system in the target system set has a corresponding weighted matching degree vector. The artificial intelligence model can arrange these vectors according to the order of the systems to form a matrix. For example, if there are 3 systems in the target system set, and the weighted matching degree vector of each system has a dimension of n, then the concatenated matching degree matrix has a dimension of 3×n. By concatenating the system dimensions, the matching degree matrix is ​​obtained, which comprehensively reflects the matching situation of each system under different constraints, providing a basis for subsequent threshold judgment and difference classification.

[0089] Step S143: Perform threshold judgment and difference classification on the matching degree matrix to generate difference evaluation results.

[0090] In this embodiment, when performing threshold judgment on the matching degree matrix, a pre-set matching degree threshold can be used to judge the matching degree matrix. Specifically, for each element in the matching degree matrix, if its value is less than the threshold, it is considered that the constraint condition corresponding to that element has not been met, and there is a difference. Elements in the matching degree matrix that are less than the threshold can be marked as difference elements.

[0091] Then, the differences can be categorized based on factors such as the constraining entity and the constraining conditions. For example, for the architectural specifications of a rights management system, differences can be categorized into differences in rights issuance rules, differences in rights write-off processes, etc. Specifically, a set of difference classification rules can be defined to classify the differences into different categories based on the corresponding constraints and constraining entities.

[0092] Finally, by combining the threshold judgment results and the difference classification results, a difference assessment result is generated. This difference assessment result could be, for example, a report containing difference information, listing the difference category, number of differences, and severity for each system. The severity can be determined based on the importance of the constraint subject and the scope of the difference's impact.

[0093] Step S144: Map and associate the difference assessment results, the corresponding system and specification clauses to obtain system difference association items.

[0094] In this embodiment, after obtaining the difference assessment results, these results can be mapped and associated with the corresponding systems and regulatory clauses. For example, a mapping table representing the mapping relationship between systems, differences, and regulatory clauses can be established, associating the difference information of each system with the corresponding regulatory clauses. For instance, for a difference in the rights distribution rules of a certain system, the corresponding rights distribution rule regulatory clauses can be found and recorded in the mapping table.

[0095] This mapping and association allows us to clearly understand which specification clauses cause the differences in each system, providing a basis for subsequent troubleshooting and repair.

[0096] Step S145: Determine the verification results of whether the system includes development content that does not conform to the target business domain architecture specification based on the system difference correlation item.

[0097] In this embodiment, deduplication can be performed on the system difference association items first to remove duplicate target difference association items. For example, a data structure such as a hash table can be used to implement deduplication, and only one record is retained for duplicate difference association items.

[0098] Then, the deduplicated difference-related items can be sorted according to system identifier and the importance of constraint clauses. Specifically, for example, they can be sorted in ascending order by system identifier first, and then, for difference-related items within the same system, sorted in descending order by the importance of constraint clauses. This makes the arrangement of difference-related items more orderly, facilitating subsequent analysis and processing.

[0099] Next, the sorted difference-related items are formatted and transformed to generate structured report entries containing system name, difference type, clause content, actual value, and expected value. Specifically, a structured report entry template can be defined, and the information from the difference-related items can be filled into the template. For example, for a difference in the rights distribution rules of a certain system, information such as system name, difference type (e.g., rights distribution amount exceeds the specified threshold), clause content (the rights distribution rules stipulate that the amount of rights distribution per user per transaction shall not exceed the specified threshold), actual value (the actual amount of rights distributed), and expected value (the specified threshold) can be recorded in the structured report entry.

[0100] Next, statistical analysis is performed on the structured report entries to calculate the number and severity of discrepancies for each system. For example, the number of related discrepancies for each system can be counted as the number of discrepancies. The severity of discrepancies can be calculated based on the importance of the constraint clauses and the scope of the discrepancy's impact. For example, the severity of discrepancies involving important constraint clauses can be set higher; the severity of discrepancies with a wide impact can also be increased accordingly.

[0101] Finally, based on the structured report entries and statistical analysis results, the test results for each system are generated. These test results may include information such as the differences for each system, an assessment of the severity of the differences, and a conclusion on whether the system conforms to the target business domain architecture specifications.

[0102] Step S150: If at least one of the systems includes development content that does not conform to the target business domain architecture specification, then output an exception message related to the development content.

[0103] In this embodiment, when it is determined that at least one system includes development content that does not conform to the target business domain architecture specification, abnormal prompt information related to the development content can be output in various ways.

[0104] For example, exception messages can be sent to relevant developers and administrators via email. These messages can include detailed information such as the system name, difference type, terms and conditions, actual value, and expected value, allowing recipients to understand the specifics of the problem.

[0105] Alternatively, task tickets with exception alerts can be generated within the company's internal project management system. These tickets record detailed exception information, including a problem description, affected systems, and scope of impact. Priority and deadlines can be set, facilitating task allocation and progress tracking for the development team.

[0106] Additionally, anomaly alerts can be prominently displayed on the system's monitoring interface. For example, a red alert icon or a flashing notification box can be used to remind maintenance personnel to pay attention and address the issue promptly. When displaying anomaly alerts, detailed links can be provided; clicking these links will allow users to view a detailed report of the anomaly, including the difference assessment results and system difference correlation items.

[0107] The method provided in this application, based on received target development requirements, determines a first business domain architecture specification corresponding to the target development requirements and a first system set corresponding to the functional parsing results of the target development requirements. The first business domain architecture specification is related to the requirement description information in the target development requirements. A second system set involved in the first business domain architecture specification is determined. If the first system set includes systems other than those in the second system set, a target system set and a target business domain architecture specification corresponding to the target system set are obtained based on the first system set and the second system set. The pre-trained artificial intelligence model is invoked to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification. This determines whether each system contains development content that does not conform to the target business domain architecture specification. If at least one system contains development content that does not conform to the target business domain architecture specification, an exception message related to the development content is output to promptly remind developers to correct the abnormal development content. This ensures that the development process and results conform to the business domain architecture specification, guaranteeing the stability and reliability of the system architecture. This avoids the shortcomings of existing technologies that rely primarily on manual inspection, which suffers from low inspection efficiency and poor accuracy, making it difficult to comprehensively and promptly identify development content that does not conform to the architecture standard. Such inspections can lead to various architecture-related problems after system deployment, affecting normal business operations. Therefore, this method improves the inspection efficiency and accuracy of system architecture standard verification.

[0108] Step S210: Collect the first processing feedback result corresponding to the abnormal prompt information. The first processing feedback result includes the marking information of misjudged differences, the supplementary information of uncovered differences, and the correction information of difference classification errors.

[0109] In this embodiment, after outputting the abnormal prompt information, feedback from relevant personnel on the processing of these abnormal prompt information can also be collected.

[0110] Specifically, for collecting information on misjudged discrepancies, a dedicated marking option can be set in the feedback interface of the anomaly alert. When developers or operations personnel discover that a discrepancy is misjudged, they can click the corresponding marking option and fill in a brief explanation of why they believe it is a misjudgment. For example, the misjudgment may be due to errors in data collection or a misunderstanding of the specifications.

[0111] For supplementary information collection regarding uncovered discrepancies, relevant personnel can describe in detail the discrepancies not covered by the current specifications in the feedback interface. This includes the system in which the discrepancy occurs, its specific manifestation, and its potential impact. For example, if a new rights distribution scenario is discovered in the rights management system that is not explicitly addressed in the current architecture specifications, relevant personnel can supplement the feedback with detailed information about this new scenario.

[0112] Regarding the collection of information to correct categorization errors, when an inaccurate categorization is found, relevant personnel can select the correct categorization in the feedback interface and provide reasons for the correction. For example, if a difference was initially categorized as a difference in rights distribution rules, but further analysis reveals that it should actually be classified as a difference in rights data format, relevant personnel can correct this in the feedback and explain the reasons.

[0113] Step S220: Extract the structured report entries and statistical analysis results of each system from the results of the test, and extract the corrected difference type, corrected expected value, and newly added constraints from the first processing feedback results.

[0114] In this embodiment, extracting structured report entries and statistical analysis results from the test results requires parsing the test results. The structured report entries have already been generated in step S145, and these entries contain information such as system name, difference type, clause content, actual value, and expected value. In this step, this information can be extracted from the test results using a data extraction tool, according to a preset format and field definitions.

[0115] The statistical analysis results include information such as the number and severity of differences between the systems. These statistical data can be extracted from the test results using data query and statistical functions.

[0116] When extracting the corrected difference types, corrected expected values, and new constraints from the initial feedback results, the feedback results need to be filtered and organized. For corrected difference types, extraction can be based on the correct difference classification selected in the feedback; for corrected expected values, the correct expected values ​​provided in the feedback can be extracted; and for new constraints, the new constraint requirements described in detail in the feedback can be extracted. For example, in the rights management system, if the feedback proposes a constraint on the issuance frequency of a new rights type, this is a new constraint.

[0117] Step S230: Associate the corrected difference type with the matching degree matrix in the test results to determine the similarity calculation rules that need to be adjusted in the artificial intelligence model, and adjust the similarity calculation rules.

[0118] In this embodiment, when associating the corrected difference type with the matching degree matrix, the association can be achieved through information such as system identifier and constraint subject, finding the element in the matching degree matrix corresponding to the corrected difference type. For example, for correcting the difference type of a system's rights distribution rule, the elements related to the rights distribution rule of that system in the matching degree matrix can be found.

[0119] Then, based on the association results, determine the similarity calculation rules that need adjustment in the AI ​​model. If it is found that the matching degree calculation for a certain type of difference is inaccurate, leading to misjudgment or classification errors, the corresponding similarity calculation rules can be adjusted. For example, if it is found that the matching degree calculation for the amount of rights and benefits distributed is too lenient, resulting in some actual non-compliant situations not being detected, the weight or calculation method for the amount of rights and benefits distributed in the similarity calculation can be adjusted.

[0120] When adjusting similarity calculation rules, model fine-tuning methods from machine learning can be used. By adding or modifying training data, the artificial intelligence model can relearn the similarity calculation rules. For example, sample data corresponding to the corrected difference types can be added to the training set to retrain the model, enabling it to calculate similarity more accurately.

[0121] Step S240: Associate the corrected expected value with the normalized feature matrix in the test result to determine the threshold judgment rule that needs to be adjusted in the artificial intelligence model, and adjust the threshold judgment rule.

[0122] In this embodiment, when associating the corrected expected value with the normative feature matrix, the corresponding element in the normative feature matrix can also be found through information such as system identifier and constraint subject. For example, for the corrected expected value of the equity distribution amount of a certain system, the constraint threshold range of the equity distribution amount corresponding to that system in the normative feature matrix can be found.

[0123] Based on the correlation results, determine the threshold judgment rules that need to be adjusted in the artificial intelligence model. Specifically, if the revised expected value is inconsistent with the threshold range in the original specification feature matrix, the threshold judgment rules can be adjusted. For example, if the threshold range for the equity distribution amount in the original specification is a relatively wide range, but the revised expected value requires a more stringent range, the threshold range can be narrowed.

[0124] When adjusting threshold judgment rules, the parameters for threshold judgment in the artificial intelligence model can be directly modified. For example, the upper or lower limit of the threshold judgment can be adjusted to match the revised expected value. Simultaneously, the threshold judgment logic can be optimized, such as by adding mechanisms for dynamically adjusting thresholds, which can automatically adjust the thresholds based on different business scenarios or data characteristics.

[0125] Step S250: Update the canonical feature transformation rules in the artificial intelligence model according to the newly added constraints.

[0126] In this embodiment, newly added constraints can be analyzed to determine their constraint subjects, constraint expressions, constraint threshold ranges, and other information. For example, for constraints on new rights distribution scenarios, the constraints related to the rights type, distribution frequency, distribution quantity, and other constraint subjects, as well as the corresponding constraint conditions and threshold ranges, can be analyzed.

[0127] Then, this information is integrated into the standardized feature transformation rules. New fields or rules can be added to the existing feature transformation template to accommodate the new constraints. For example, if the new constraint involves a new equity status field, processing rules for that field can be added to the standardized feature transformation rules, including how to convert it into a numerical feature vector or an interval feature vector.

[0128] After updating the canonical feature transformation rules, the AI ​​model is retrained using canonical data containing the new constraints so that the AI ​​model can correctly transform the new constraints into a canonical feature matrix.

[0129] Step S260: Update the artificial intelligence model according to the adjustment of the similarity calculation rule, the adjustment of the threshold judgment rule, and the update of the standard feature transformation rule.

[0130] In this embodiment, the adjusted rules can be integrated into the corresponding modules of the artificial intelligence model. For example, the new similarity calculation rules can be integrated into the similarity calculation module, the adjusted threshold judgment rules can be integrated into the threshold judgment module, and the updated normalized feature transformation rules can be integrated into the normalized feature transformation module.

[0131] Then, the AI ​​model is retrained using the updated rules. For example, a new training set can be created using historical test data and newly added sample data to update the AI ​​model's training. During training, the parameters of the AI ​​model are continuously adjusted so that it can better adapt to the new rules and data.

[0132] Optionally, after training is complete, the updated AI model can be evaluated. For example, a test dataset can be used to test the updated AI model and evaluate its performance under the new rules, including metrics such as accuracy and recall. If the evaluation results meet the requirements, the updated AI model can then be deployed in real-world applications.

[0133] The method provided in this application collects the first processing feedback results corresponding to the abnormal prompt information, extracts key information such as the corrected difference type, the corrected expected value, and the newly added constraints, and makes targeted adjustments and updates to the similarity calculation rules, threshold judgment rules, and standardized feature transformation rules of the artificial intelligence model based on this information. Finally, the artificial intelligence model is retrained and evaluated by combining these rule changes, so that the artificial intelligence model can continuously adapt to various new situations and problems that arise in actual business, continuously optimize the model's ability to verify system architecture specifications, reduce the occurrence of misjudgments, uncovered differences, and classification errors, thereby improving the accuracy and reliability of the artificial intelligence-based architecture standard verification method, ensuring the quality of system development, reducing the risk of failures caused by architecture specification issues after the system goes live, and providing strong support for the stable operation of the system.

[0134] Step S310: Collect the second processing feedback result corresponding to the abnormal prompt information. The second processing feedback result includes feedback information on missing standard clauses and correction information on ambiguous standard clauses.

[0135] In this embodiment, when collecting the second processing feedback results, relevant information can also be collected through the feedback interface or a dedicated feedback channel. For feedback regarding missing specifications, relevant personnel can describe in detail the situations where the specifications are not covered in actual business operations. For example, in the rights management system, as business develops, new rights combination methods emerge that are not specified in the current architecture specifications; relevant personnel can provide feedback on this situation.

[0136] Regarding revisions to ambiguous clauses in regulations, when relevant personnel find that the wording of a certain clause is unclear and prone to ambiguity, they can propose revisions in the feedback. For example, if the description of the timing of rights issuance in the regulations is vague, relevant personnel can suggest clarifying the specific time range or calculation method.

[0137] Step S320: Extract the statistical results of the number of differences and the distribution results of the difference types of each system from the results of the test, and extract the newly added normative clause suggestions and the revised normative clause descriptions from the second processing feedback results.

[0138] In this embodiment, data statistics and analysis tools can be used to extract the statistical results of the number of differences and the distribution results of the difference types from the test results. The statistical results of the number of differences can be obtained by counting the difference-related items for each system; the distribution results of the difference types can be used to count the frequency of different difference types.

[0139] Then, when extracting the newly added regulatory clause suggestions and revised regulatory clause descriptions from the second processing feedback results, the feedback content is screened and organized. Specifically, for the newly added regulatory clause suggestions, the detailed descriptions of the new regulatory requirements can be extracted; for the revised regulatory clause descriptions, the clear and accurate regulatory expressions provided in the feedback can be extracted. For example, regarding the regulatory clauses for the rights issuance rules, the feedback proposed more detailed rights issuance conditions and procedures, which constitutes the revised regulatory clause description.

[0140] Step S330: Associate the frequently occurring difference types in the difference quantity statistics with the existing clauses in the target business domain architecture specification to determine the existing clauses that need to be supplemented or modified.

[0141] In this embodiment, when associating frequently occurring difference types with existing clauses, the statistical results of the number of differences can be sorted first to identify the difference types with higher frequencies. Then, using information such as system identifiers and constraint subjects, these frequently occurring difference types are matched with existing clauses in the target business domain architecture specification.

[0142] If existing clauses corresponding to a high-frequency difference type are found to be insufficient or inaccurate, those clauses can be supplemented or modified. For example, in the rights management system, if the existing clauses regarding frequently occurring differences in rights data formats are not detailed enough, those clauses can be supplemented to clarify the specific data format requirements.

[0143] Step S340: Based on the newly added specification clause suggestions, generate new structured constraint entries, which include constraint subject identifier, constraint condition expression, and constraint threshold range.

[0144] In this embodiment, the newly added regulatory clauses can be analyzed first to determine the binding subject, binding conditions, and binding thresholds. For example, for a new regulatory clause on the frequency of rights issuance, the analysis reveals that the binding subject can be the frequency of rights issuance, the binding condition can be "shall not exceed", and the binding threshold can be a specific issuance frequency value.

[0145] Then, this information is populated into a predefined structured constraint entry template to generate new structured constraint entries. The structured constraint entry template includes fields such as constraint subject identifier, constraint condition expression, and constraint threshold range, allowing the analyzed information to be accurately filled into the corresponding fields to generate new structured constraint entries.

[0146] Step S350: Perform consistency verification on the new structured constraint entries and the revised specification clause descriptions to ensure that there is no conflict with the existing clauses in the target business domain architecture specification.

[0147] In this embodiment, when performing consistency verification on the new structured constraint entries and the revised specification clause descriptions, semantic analysis can be performed on the new structured constraint entries and the revised specification clause descriptions first. Natural language processing techniques can be used to understand their expressed meaning and requirements.

[0148] Next, compare it with existing clauses in the target business domain architecture specification. Check for any conflicts or contradictions. For example, if a new structured constraint entry specifies new rules for rights granting, it's necessary to check whether these rules conflict with other existing rules regarding rights granting in the specification.

[0149] If a conflict is found, adjustments can be made to the description of the new structured constraint entries or the revised specification clauses. For example, communication can be conducted with relevant business personnel, developers, and operations personnel to obtain a reasonable solution, ensuring that the new clauses are consistent with the existing clauses.

[0150] Step S360: Add the verified new structured constraint entries and the revised specification clause descriptions to the target business domain architecture specification to update the target business domain architecture specification.

[0151] In this embodiment, after the consistency verification is completed, a document management system or version control system can be used to manage the updates of the architecture specification, so as to add the verified new structured constraint entries and the revised specification clause descriptions to the target business domain architecture specification.

[0152] Specifically, new structured constraint entries and revised specification clauses can be inserted into the corresponding positions in the target business domain architecture specification, following the format and structure of the specification. For example, if a new clause is a supplementary provision regarding a functional module of the rights and interests management system, it can be inserted into the chapter corresponding to that functional module.

[0153] After the update is completed, the version of the target business domain architecture specification can be recorded, including the content, time, personnel, and other information of the update, which will facilitate subsequent review and management.

[0154] The method provided in this application collects the second processing feedback results corresponding to the abnormal prompt information, accurately extracts the newly added specification clause suggestions and the revised specification clause descriptions from them, and obtains the statistical data on the number and type distribution of differences from the inspection results. Then, based on the high-frequency difference types, it locates the problems of existing clauses, generates new structured constraint items, and performs consistency verification on the newly generated and revised clauses. Finally, it adds the verified clauses to the target business domain architecture specification to achieve dynamic updating and optimization of the target business domain architecture specification. This allows it to keep pace with business development, promptly cover newly emerging business scenarios and specification requirements, reduce issues such as ambiguous or missing clauses, and improve the guidance and constraint of the specification on the business system. This ensures that the development and operation of the business system strictly follow the unified, accurate, and complete architecture specification, reduces the risk of system failures and data errors caused by incomplete specifications, improves the stability, reliability, and maintainability of the business system, and provides a solid guarantee for the continuous and healthy development of the business.

[0155] Step S410: During the process of verifying at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, the associated systems involved in the system are determined, and the associated systems are related to the functional analysis results of the target development requirements.

[0156] The functional analysis results contain multiple sub-functional requirements, each of which may involve collaboration between multiple systems.

[0157] In this step, the functional analysis results of the target development requirements can be analyzed in depth. By analyzing the data interactions and business processes between systems, related systems can be identified. For example, in the rights and benefits management system, the sub-functional requirement for rights and benefits distribution might involve the user information management system providing user identity information, and the order management system providing consumption information. By analyzing these data interactions and business processes, it can be determined that the user information management system and the order management system are related systems to the rights and benefits management system.

[0158] Alternatively, associated systems can be identified through system interface information. Since each system's interface typically interacts with other systems, analyzing interface call relationships and data transmission directions can help pinpoint associated systems. For example, if an interface of the rights management system calls an interface of the user information management system to retrieve user rights information, then the user information management system can be identified as an associated system.

[0159] Step S420: Based on the inspection objects related to the function parsing results in the associated system and the business domain architecture specifications corresponding to the inspection objects, inspect the inspection objects in the associated system to obtain the inspection results of the associated system.

[0160] In this embodiment, key elements such as specific functional modules, interface call relationships, and data flow paths involved in the functional analysis results can be used to determine the objects related to these key elements as the verification objects related to the functional analysis results. The verification objects may differ for different associated systems. For example, for a user information management system, the verification objects might be the query interface for user rights information and the storage format of user rights data; for an order management system, the verification objects might be the verification interface for rights usage in orders and the relationship between order data and rights data.

[0161] Then, based on the objects being tested, the corresponding business domain architecture specifications can be determined. For example, the business domain architecture specifications corresponding to each object can be determined based on the mapping relationship between the object being tested and the business domain architecture specifications. Different objects being tested may correspond to different architecture specifications, or they may correspond to the same or partially the same architecture specifications. For example, the user rights information query interface of the user information management system may correspond to the interface call specification, and the storage format of user rights data may correspond to the data storage specification.

[0162] Next, a method similar to steps S140-S145 described above can be used to test the objects of the association system. Specifically, this may include semantic parsing and feature transformation of the specification, field extraction and feature modeling of the objects of the test, calculation of the matching degree matrix, threshold judgment and difference classification, etc., to finally obtain the test results of the association system.

[0163] Step S430: Based on the test results of the associated system, determine whether the associated system includes development content that does not conform to the business domain architecture specification corresponding to the test object.

[0164] In this embodiment, the difference assessment results in the correlation system inspection results can be analyzed to determine whether there is any non-compliant development content in the correlation system. If there are discrepancies in the difference assessment results, it indicates that there is non-compliant development content in the correlation system. This analysis method can be similar to the content of the aforementioned step S140, and will not be repeated here.

[0165] Optionally, the severity of the problem can be further assessed based on the number and severity of the discrepancies. A large number of discrepancies with high severity indicate significant issues in the development of the related system, requiring immediate rectification. For example, in the inspection results of a user information management system, multiple discrepancies were found between the returned data format of the user rights information query interface and the specification requirements. These discrepancies could potentially affect the normal use of the rights management system, indicating that the interface's development does not meet the specifications.

[0166] Step S440: If at least one of the associated systems includes development content that does not conform to the business domain architecture specification corresponding to the inspection object, then output supplementary information on the exception prompt related to the development content.

[0167] The aforementioned exception prompts are used to indicate that the development content contains exceptions that do not conform to the target business domain architecture specifications corresponding to the target system set. The supplementary exception prompts are used to indicate that the development content contains exceptions that do not conform to the business domain architecture specifications corresponding to the related systems of the target system set. By using the related system dimension, supplementary exception prompts are provided for non-compliant content in the development content (that is, in addition to checking whether it conforms to the target business domain architecture specifications, it also checks whether the development content conforms to the business domain architecture specifications corresponding to the related system dimension). This allows for a more comprehensive and in-depth investigation of potential non-compliance issues in the development content, providing developers with more detailed and accurate rectification guidance, effectively reducing the risk of failures caused by architecture specification non-compliance after system launch, ensuring the overall stability and reliability of the system architecture under multi-system collaboration, and improving the quality and efficiency of system development.

[0168] In this step, the output method of the supplementary information for the exception prompt can be similar to that of the exception prompt information in step S150, such as outputting the supplementary information for the exception prompt via email, task work order of the project management system, system monitoring interface, etc.

[0169] The supplementary information for the anomaly report can describe in detail the name of the associated system, the non-compliant inspection object, the specific discrepancies, and the potential impact. For example, the supplementary information could include that the user rights information query interface of the user information management system returns data in a non-compliant format, specifically that the type of a certain field is inconsistent with the specification requirements, which may cause the rights management system to be unable to correctly parse user rights information.

[0170] The method provided in this application, when verifying a set of target systems according to the target business domain architecture specifications, accurately identifies the related systems associated with the functional analysis results of the target development requirements. Verification is conducted based on the verification objects of the related systems and their corresponding business domain architecture specifications. The compliance of the development content of the related systems is judged based on the verification results, and supplementary information is output when non-compliant content is found. This comprehensively reviews whether the development content conforms to the business domain architecture specifications from both the target system itself and the related systems, breaking the limitations of single-system verification and forming a more complete and detailed architecture specification verification system. This ensures that the development of each system in multi-system collaboration scenarios strictly follows the architecture specification requirements, thereby effectively reducing problems such as inter-system interaction failures and data errors caused by architecture specification non-compliance. It also reduces post-launch maintenance costs and risks, improves overall system stability and reliability, provides strong support for the efficient and stable operation of business, and provides developers with more accurate and comprehensive rectification directions, improving development efficiency and quality.

[0171] Figure 2 This is a schematic diagram of the structure of an artificial intelligence-based architecture standard verification system 100 provided in an embodiment of this application. Figure 2 As shown, the processor 120 can be used on the AI-based architecture standard verification system 100 and to perform the functions in this invention.

[0172] The AI-based architecture standard verification system 100 can be a general-purpose server or a special-purpose server; both can be used to implement the AI-based architecture standard verification method of this invention. Although only one server is shown in this invention, for convenience, the functions described in this invention can be implemented in a distributed manner on multiple similar platforms to balance the load.

[0173] For example, an AI-based architecture standards verification system 100 may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the AI-based architecture standards verification system 100 may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The method of the present invention can be implemented according to these program instructions. The AI-based architecture standards verification system 100 also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0174] For ease of explanation, only one processor is described in the AI-based architecture standard verification system 100. However, it should be noted that the AI-based architecture standard verification system 100 of this invention may also include multiple processors, and therefore the steps performed by one processor as described in this invention may also be performed jointly or individually by multiple processors. For example, if the processor of the AI-based architecture standard verification system 100 performs steps A and B, it should be understood that steps A and B may also be performed jointly by two different processors or individually by one processor. For example, the first processor performs step A, the second processor performs step B, or the first processor and the second processor jointly perform steps A and B.

[0175] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. 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 inventive effort.

[0176] Finally, it should be noted that the above-disclosed embodiments are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, 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. Such 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. An artificial intelligence-based architecture standard inspection method, characterized by, include: Based on the received target development requirements, a first business domain architecture specification corresponding to the target development requirements and a first system set corresponding to the functional parsing results of the target development requirements are determined. The first business domain architecture specification is related to the requirement description information in the target development requirements. Determine the second set of systems involved in the first business domain architecture specification; If the first system set includes other systems besides the second system set, then based on the first system set and the second system set, a target system set and a target business domain architecture specification corresponding to the target system set are obtained. The target business domain architecture specification includes the first business domain architecture specification and the second business domain architecture specification corresponding to the first system set. The pre-trained artificial intelligence model is invoked to examine at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, to determine whether each system includes development content that does not conform to the target business domain architecture specification; If at least one of the systems includes development content that does not conform to the target business domain architecture specification, then an exception message related to the development content will be output. 2.The AI-based architecture standard inspection method of claim 1, wherein, The pre-trained artificial intelligence model is invoked to examine at least one of the following in the target system set: interface calls, message content, log records, and data flows, according to the target business domain architecture specification, to determine whether each system includes development content that does not conform to the target business domain architecture specification, including: The artificial intelligence model performs semantic parsing and feature transformation on the target business domain architecture specification to generate a specification feature matrix, and extracts fields and models features of the systems to be tested in the target system set to generate a feature matrix to be tested. Dimension mapping and alignment are performed on the standard feature matrix and the feature matrix to be tested to generate aligned feature pairs. Dimensional similarity calculation and weighted evaluation are then performed on the aligned feature pairs to obtain a matching degree matrix. The matching degree matrix is ​​subjected to threshold judgment and difference classification to generate difference evaluation results; Based on the difference assessment results, the corresponding system and specification clauses are mapped and associated to obtain system difference association items; The verification results determine whether the system includes development content that does not conform to the target business domain architecture specification based on the system difference correlation items.

3. The method for verifying architectural standards based on artificial intelligence according to claim 2, characterized in that, The step of performing semantic parsing and feature transformation on the target business domain architecture specification to generate a specification feature matrix includes: Receive the target business domain architecture specification text; The target business domain architecture specification text is processed by word segmentation and stop word filtering to obtain a specification keyword sequence; Semantic role labeling is performed on the specified keyword sequence to identify semantic roles including constraint subject, constraint condition, and constraint threshold; The annotated sequence of standard keywords is converted into structured constraint entries, which include constraint subject identifier, constraint condition expression, and constraint threshold range. Perform feature vectorization transformation on the structured constraint entries to map the constraint condition expression into a numerical feature vector and the constraint threshold range into an interval feature vector; The standardized feature matrix is ​​generated by concatenating the numerical feature vector and the interval feature vector according to the constraint subject dimension.

4. The method for verifying architectural standards based on artificial intelligence according to claim 2, characterized in that, The step of extracting fields and modeling features of the systems to be tested within the target system set to generate a feature matrix to be tested includes: Receive the test content of the systems included in the target system set; Perform field parsing and entity recognition on the content to be inspected to extract entities including field name, field value, and field relationship; Perform data type conversion and standardization on the field values ​​to map non-numeric field values ​​to numeric codes; Graph structure modeling is performed on the field relationships to generate a field relationship adjacency matrix; The feature matrix to be tested is generated by concatenating the standardized field values ​​according to the field dimensions and associating them with the adjacency matrix of the field.

5. The AI-based architecture standard verification method according to claim 2, characterized in that, The process of performing dimensional mapping and alignment on the standardized feature matrix and the feature matrix to be tested to generate aligned feature pairs, and then performing dimensional similarity calculation and weighted evaluation on the aligned feature pairs to obtain a matching degree matrix, includes: According to the preset feature dimension mapping table, the dimension rearrangement and zero-padding process is performed on the normalized feature matrix and the feature matrix to be tested to obtain aligned feature pairs. In the aligned feature pairs, the dimension order and the number of feature dimensions of the normalized feature matrix and the feature matrix to be tested are consistent. The feature dimension mapping table contains a one-to-one correspondence between the normalized feature dimensions and the feature dimensions to be tested. Perform a dimension-wise cosine similarity calculation on the alignment feature pairs to obtain an initial matching degree vector; The initial matching degree vector is multiplied element by element by the preset constraint weight table to obtain the weighted matching degree vector. The constraint weight table contains the importance weights corresponding to each constraint subject. The matching degree matrix is ​​obtained by concatenating the weighted matching degree vector according to the system dimension.

6. The method for verifying architectural standards based on artificial intelligence according to claim 2, characterized in that, The verification result for determining whether the system includes development content that does not conform to the target business domain architecture specification based on the system difference correlation item includes: Perform deduplication on the system difference association items to remove duplicate target difference association items; Based on the system identifier and the importance of the constraint clauses, the deduplicated difference association items are sorted to obtain the sorted difference association items; Perform formatting transformation on the sorted difference-related items to generate structured report entries containing system name, difference type, clause content, actual value, and expected value; Perform statistical analysis on the structured report entries, calculate the number and severity of differences for each system, and obtain the statistical analysis results; Based on the structured report entries and the statistical analysis results, the test results for each of the systems are generated.

7. The method for verifying architectural standards based on artificial intelligence according to claim 1, characterized in that, The method further includes: Collect the first processing feedback result corresponding to the abnormal prompt information. The first processing feedback result includes the marking information of misjudged differences, the supplementary information of uncovered differences, and the correction information of difference classification errors. The structured report entries and statistical analysis results of each system are extracted from the results of the test, and the corrected difference type, corrected expected value, and new constraints are extracted from the first processing feedback results. The corrected difference type is correlated with the matching degree matrix in the test results to determine the similarity calculation rules that need to be adjusted in the artificial intelligence model, and the similarity calculation rules are adjusted accordingly. The corrected expected value is correlated with the normalized feature matrix in the test results to determine the threshold judgment rule that needs to be adjusted in the artificial intelligence model, and the threshold judgment rule is adjusted accordingly. Based on the newly added constraints, update the canonical feature transformation rules in the artificial intelligence model; The artificial intelligence model is updated based on the adjustments to the similarity calculation rules, the threshold judgment rules, and the updates to the standardized feature transformation rules.

8. The method for verifying architectural standards based on artificial intelligence according to claim 1, characterized in that, The method further includes: Collect the second processing feedback result corresponding to the abnormal prompt information. The second processing feedback result includes feedback information for missing standard clauses and correction information for ambiguous standard clauses. Extract the statistical results of the number of differences and the distribution results of the difference types of each system from the results of the test, and extract the new normative clause suggestions and the revised normative clause descriptions from the second processing feedback results; Associate the frequently occurring difference types in the difference quantity statistics with the existing clauses in the target business domain architecture specification to determine the existing clauses that need to be supplemented or modified. Based on the proposed new specification clauses, new structured constraint entries are generated, which include constraint subject identifier, constraint condition expression, and constraint threshold range. The new structured constraint entries and the revised specification clause descriptions are verified for consistency to ensure that they do not conflict with existing clauses in the target business domain architecture specification. The validated new structured constraint entries and revised specification clause descriptions are added to the target business domain architecture specification to update the target business domain architecture specification.

9. The method for verifying architectural standards based on artificial intelligence according to claim 1, characterized in that, The method further includes: In the process of verifying at least one of the interface calls, message content, log records, and data flows of the systems included in the target system set according to the target business domain architecture specification, the associated systems involved in the system are determined, and the associated systems are related to the functional analysis results of the target development requirements; Based on the inspection objects related to the function parsing results in the associated system and the business domain architecture specifications corresponding to the inspection objects, the inspection objects in the associated system are inspected to obtain the inspection results of the associated system. The inspection objects include at least one of the following: interface calls, message content, log records, and data streams in the associated system. Based on the test results of the associated system, determine whether the associated system includes development content that does not conform to the business domain architecture specification corresponding to the test object; If at least one of the associated systems includes development content that does not conform to the business domain architecture specification corresponding to the test object, then supplementary error message information related to the development content will be output.

10. An architecture standard verification system based on artificial intelligence, characterized in that, The invention includes a processor and a computer-readable storage medium storing machine-executable instructions, which, when executed by a computer, implement the AI-based architecture standard verification method according to any one of claims 1-9.

Images