Business intent analysis method and device, electronic equipment, medium and program product

Abstract

The application discloses a business intention analysis method and device, electronic equipment, medium and program product. The method comprises the following steps: acquiring multi-source business data of a business object; filling a business attribute field corresponding to a preset structure intention template based on the multi-source business data to obtain a candidate field set of each business attribute field; calculating each candidate field based on a preset multi-dimensional evaluation index to obtain a comprehensive confidence of each candidate field; determining a conflict field, a rejected field and a trusted field in the candidate field set of all business attribute fields based on the comprehensive confidence of each candidate field; and generating structure intention information of the business object based on the trusted field and the conflict field of all business attribute fields. The business intention analysis accuracy is improved, and the balance between automation efficiency and result traceability is achieved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, apparatus, electronic device, medium, and program product for parsing business intent. Background Technology

[0002] In complex business processing scenarios such as dedicated government and enterprise lines, customer needs typically exist in multiple sources, including natural language, work order fields, attachment text, and historical records. Existing technologies, when performing structured parsing of this multi-source data, often rely on fixed rules or single-source priority for field extraction. This results in the generated structured intent information either directly adopting low-reliability data, leading to errors in subsequent processes, or frequently requiring manual confirmation due to the inability to automatically determine conflicts. Consequently, it is difficult to ensure the accuracy and traceability of structured results while maintaining the efficiency of automated workflows. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, medium, and program product for parsing business intent, which improves the accuracy of business intent parsing and achieves a balance between automation efficiency and result traceability.

[0004] On one hand, embodiments of this application provide a method for parsing business intent, including: acquiring multi-source business data of a business object; filling business attribute fields corresponding to a preset structural intent template based on the multi-source business data to obtain a candidate field set for each business attribute field; calculating the comprehensive confidence level of each candidate field based on a preset multi-dimensional evaluation index, wherein the preset multi-dimensional evaluation index includes at least two of the following: source reliability index, semantic matching index, and historical consistency index; determining conflicting fields, discarded fields, and accepted fields in the candidate field set of all business attribute fields based on the comprehensive confidence level of each candidate field, wherein accepted fields are used to fill the corresponding business attribute fields, conflicting fields are used to retain the corresponding business attribute fields, and discarded fields are used to remove the corresponding business attribute fields from the candidate field set; and generating structural intent information of the business object based on the accepted fields and conflicting fields of all business attribute fields.

[0005] On the other hand, embodiments of this application provide a business intent parsing apparatus, comprising: an acquisition unit, configured to acquire multi-source business data of a business object, and fill business attribute fields corresponding to a preset structural intent template based on the multi-source business data to obtain a candidate field set for each business attribute field; a first processing unit, configured to calculate the comprehensive confidence level of each candidate field based on a preset multi-dimensional evaluation index, wherein the preset multi-dimensional evaluation index includes at least two of the following: source reliability index, semantic matching index, and historical consistency index; a second processing unit, configured to determine conflicting fields, eliminated fields, and accepted fields in the candidate field set of all business attribute fields based on the comprehensive confidence level of each candidate field, wherein accepted fields are used to fill the corresponding business attribute fields, conflicting fields are used to retain the corresponding business attribute fields, and eliminated fields are used to eliminate the corresponding business attribute fields from the candidate field set; and a third processing unit, configured to generate structural intent information of the business object based on the accepted fields and conflicting fields of all business attribute fields.

[0006] In another aspect, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; and a method for parsing business intent when the processor executes the computer program instructions.

[0007] In another aspect, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and a method for parsing business intent when the computer program instructions are executed by a processor.

[0008] In another aspect, embodiments of this application provide a computer program product, wherein when the instructions in the computer program product are executed by the processor of an electronic device, a method for parsing the electronic device to perform a business intent is provided.

[0009] The business intent parsing method, apparatus, electronic device, medium, and program product of this application embodiment acquires multi-source business data of business objects, fills business attribute fields corresponding to a preset structured intent template based on the multi-source business data, and obtains a candidate field set for each business attribute field. This unifies business requirements scattered from different sources into a processing framework, reducing information omissions. By calculating the comprehensive confidence of candidate fields based on multi-dimensional evaluation indicators including source reliability, semantic matching degree, and historical consistency, information from multiple dimensions such as data source credibility, semantic relevance, and historical matching degree is integrated, providing a calibrable and objective quantitative basis for field selection. By dividing candidate fields into accepted fields, conflicting fields, and rejected fields based on comprehensive confidence, high-confidence fields can be filled to support the automated flow of business processes. At the same time, by retaining conflicting fields, a complete data context and decision basis are provided for subsequent manual review or secondary confirmation, avoiding business interruption or incorrect activation due to the mistaken rejection of potentially correct values. By generating structured intent information based on accepted fields and conflicting fields, unstructured or semi-structured business requirements are converted into executable structured objects. This improved the accuracy of business intent parsing and achieved a balance between automation efficiency and result traceability. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a method for parsing business intent provided in an embodiment of this application; Figure 2 A flowchart illustrating an overall method for parsing business intent according to an embodiment of this application is shown. Figure 3 A schematic diagram illustrating a multi-source input access method for parsing service intent according to an embodiment of this application is shown. Figure 4 A flowchart illustrating the dedicated line activation requirement determination method according to an embodiment of this application is shown. Figure 5 A flowchart illustrating the dedicated line domain entity identification and slot filling process of a business intent parsing method provided according to an embodiment of this application is shown. Figure 6 A flowchart illustrating the conflict resolution and missing field completion process of a business intent parsing method provided in an embodiment of this application is shown. Figure 7A flowchart illustrating the activation intent object generation process of a business intent parsing method according to an embodiment of this application is shown. Figure 8 A flowchart illustrating the activation intent object output of a service intent parsing method according to an embodiment of this application is shown. Figure 9 The flowchart illustrating the activation result feedback process of a service intent parsing method provided according to an embodiment of this application is shown. Figure 10 This is a schematic diagram of the structure of the business intent parsing device provided in the embodiments of this application; Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0013] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0014] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0015] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0016] Before delving into the specific embodiments of this application, a general overview of the current technical obstacles is provided to better understand the application scenarios of the technical solution. In complex business processing scenarios such as government and enterprise dedicated lines, customer needs typically enter the processing flow in multiple sources, including natural language, work order fields, attachment text, and historical records. Existing architectures face significant technical obstacles in processing this data. When data from different sources provides different values ​​for the same business attribute, there is a lack of conflict identification and hierarchical processing mechanisms based on multi-dimensional quantitative indicators. This results in the generated structured intent information either directly adopting low-reliability data, leading to errors in subsequent resource verification or solution generation, or frequently returning to manual confirmation due to the inability to automatically determine conflicts, making it difficult to ensure the accuracy of results while maintaining the efficiency of automated workflow.

[0017] To address the aforementioned technical issues, the following detailed description, in conjunction with the accompanying drawings, of a method, apparatus, electronic device, computer storage medium, and computer program product for parsing business intent provided by the embodiments of this application, through specific implementations and application scenarios.

[0018] This application provides a method for parsing business intent, such as... Figure 1 As shown, the method includes the following steps: Step S100: Obtain multi-source business data of the business object, and fill the business attribute fields corresponding to the preset structure intent template based on the multi-source business data to obtain a set of candidate fields for each business attribute field.

[0019] Here, "business object" refers to the target entity that requires business intent parsing, such as the business requirement object in a government / enterprise dedicated line activation scenario. "Multi-source business data" refers to business-related information from different channels and in different forms, specifically including natural language requirements, work order fields, electronic forms, attached text, historical business records, account manager notes, and confirmed business samples. "Preset structure intent template" refers to a predefined framework of business attribute fields used to standardize all attribute fields required by the business object. Specifically, as an example, multi-source business data can include natural language requirements verbally relayed by the customer, work order fields from the business system (such as customer name, product name, bandwidth, A-end address, Z-end address, expected activation time, etc.), electronic forms such as project activation application forms, attached text such as contract attachments or requirement specifications, historical business records of the same customer, product, or region, account manager notes, and confirmed activation samples. The pre-defined intent template can include basic attribute fields (such as customer ID, customer level, product type, bandwidth), location attribute fields (such as A-end address, Z-end address), network constraint fields (such as latency requirements, protection level, isolation requirements), implementation constraint fields (such as activation time limit, construction window), and traceability description fields (such as source tracing, reason tracking, overall confidence level, confirmation status flag). This step unifies business requirements scattered across different sources and formats into a standardized processing framework, providing a complete data foundation for subsequent confidence assessment and effectively reducing intent parsing bias caused by omissions of information from single sources.

[0020] Step S110: Calculate the comprehensive confidence level of each candidate field based on the preset multidimensional evaluation index. The preset multidimensional evaluation index includes at least two of the following: source reliability index, semantic matching index, and historical consistency index.

[0021] Among them, the source reliability index is a quantitative value used to reflect the credibility of the data source of a candidate field. The semantic matching index is a quantitative value used to measure the semantic relevance between a candidate field and its corresponding business attribute field. The historical consistency index is a quantitative value used to measure the matching degree between a candidate field and historically confirmed data. The overall confidence level is a quantitative value of the overall credibility of the candidate field obtained by integrating the evaluation results of multiple dimensions. Specifically, as an example, the source reliability index can be obtained by looking up a table based on the data source type of the candidate field. For example, the formal work order field is given a higher weight, the customer manager's remarks are given a medium weight, and unconfirmed attachments are used as a reference source; this weight is not fixed, but can be dynamically calibrated through historical successful activation records, manual confirmation records, and return correction records. The semantic matching index can be obtained by calculating the semantic similarity between the candidate field value and the standard definition of the corresponding business attribute field using a vector similarity model. The historical consistency index can be obtained by statistically analyzing the hit rate of historically confirmed data from the same customer, the same product, or the same region that matches the current candidate field. The overall confidence level is obtained by weighting the preset weights of each index. By using multi-dimensional quantitative evaluation, the subjectivity of traditional methods that rely solely on the priority of a single source is overcome, enabling field selection decisions to be based on calibrable objective data.

[0022] Step S120: Based on the comprehensive confidence level of each candidate field, determine the conflicting field, the elimination field, and the accepted field from the candidate field set of all business attribute fields. The accepted field is used to fill the corresponding business attribute field, the conflicting field is used to be retained in the corresponding business attribute field, and the elimination field is used to be removed from the candidate field set of the corresponding business attribute field.

[0023] In this context, "accepted fields" refer to candidate fields whose overall confidence level meets the acceptance criteria and are identified as filling the corresponding business attribute fields. "Conflicting fields" refer to candidate fields with similar overall confidence levels that cannot be automatically determined to have a unique acceptance value; these are retained in the corresponding business attribute fields for subsequent manual review or secondary confirmation. "Removed fields" refer to candidate fields whose overall confidence level is below a preset lower limit and are removed from the candidate field set. Specifically, as an example, when only one candidate field in the candidate field set for a certain business attribute field has a significantly higher overall confidence level than the other candidate fields, that candidate field is identified as an accepted field; when the overall confidence levels of multiple candidate fields are similar and all exceed the preset confidence level lower limit, these candidate fields are identified as conflicting fields; when the overall confidence level of a candidate field is below the preset confidence level lower limit, that candidate field is identified as a removed field. It should be noted that this embodiment adopts a strategy of retaining conflicting fields, which provides complete data context and decision-making basis for subsequent manual review or secondary confirmation. In high-risk business scenarios such as government and enterprise dedicated lines, directly discarding fields suspected of conflict may lead to the loss of key constraint information, which in turn may cause incorrect activation. However, retaining conflicting fields and marking their status can not only avoid business interruptions caused by mistakenly removing potentially correct values, but also enable reviewers to make accurate judgments based on the complete distribution of candidate values, thus achieving a balance between automation efficiency and result security.

[0024] Step S130: Based on the accepted fields and conflicting fields of all business attribute fields, generate the structural intent information of the business object.

[0025] Structural intent information refers to the output results that organize all business attribute fields of a business object in a structured form. Specifically, as an example, structural intent information uses a unified key-value structure, where each business attribute field includes a standard value, original value, source, candidate value, selection criteria, overall confidence level, whether inference is made, and whether manual confirmation is required. This structured output not only carries the final parsing result but also simultaneously outputs reason tracing and source tracking information, enabling downstream systems or manual review processes to clearly understand the generation logic and credibility of each field, achieving end-to-end traceability of the business intent parsing process.

[0026] In practical applications, the system establishes a unified access description for each type of input, including source identifier, source type, source time, source owner, original content, content format, and source status. For structured fields, the system retains the field name, field value, entry time, and source platform; for unstructured text, it retains the original paragraph, sentence position, and context window; for attached text, it segments the data according to paragraphs, table rows, table header fields, and key phrases; for historical records, it establishes a candidate reference set based on dimensions such as customer, product, region, bandwidth, and activation scenario. Subsequently, the system performs text denoising, format conversion, field splitting, unit identification, address fragment segmentation, and irrelevant information filtering on the input data. The source reliability labeling adopts a strategy of prior layering plus result calibration. The system first establishes initial prior weights based on source types such as formal work order fields, confirmed forms, manual confirmation records, attachment descriptions, account manager remarks, chat fragments, and historical samples. Then, it uses historical successful activation records, manual confirmation records, and return correction records to count the hit rate, correction rate, and proportion of subsequent process failures of each source on different business attribute fields, forming a source reliability table subdivided by source type, business attribute field type, and scenario type.

[0027] In practical applications, the intent recognition process comprehensively determines whether the input is a activation request, what type of service it belongs to, and whether it contains various constraints. The intent recognition confidence level can be calculated using the following formula: ; in, This represents the confidence level that the input belongs to the k-th type of opening intent; This indicates the weight of the input source, which reflects the credibility of sources such as official work orders, forms, attachments, remarks, and historical samples. This represents the semantic similarity between the input text q and the k-th intention template Tk; Indicates consistency with similar historical samples, used to measure the degree of consistency between historical activation records and current input for the same customer, product, region, or scenario; It represents contextual integrity and is used to measure whether the various business attribute fields form a complete semantic chain; , , , The set of coefficients, which are the confidence weights of the intent, can be initially determined by human experience and then calibrated using confirmed open samples, misjudged samples, and returned samples.

[0028] In practical applications, after generating structural intent information, a minimum executability condition determination is also required. The minimum executability condition refers to the set of business attribute fields that the structural intent information must possess before it can be included in subsequent resource verification and solution generation. The comprehensive executability score can be calculated using the following formula: ; in, A comprehensive executability score that represents structural intent information; The completeness of the structural intent information is determined by the ratio of the number of required business attribute fields that have been filled to the total number of required business attribute fields required for the minimum executable condition; This represents the average overall confidence level of the key business attribute fields; Indicates the number of unresolved conflict fields; , , This is a weighting coefficient for the executability score, used to balance the impact of completeness, average confidence of key business attribute fields, and the number of unresolved conflict fields on executability. This weighting is calibrated based on historical samples showing whether the data successfully entered subsequent processes, was rejected, or underwent manual correction. When completeness reaches the threshold, the overall executability score reaches the executability threshold, and the number of unresolved conflict fields is zero, the structured intent information can proceed to the subsequent resource verification process. When completeness meets the standard but low-confidence fields exist or the dynamic threshold is not passed, a semi-structured object and a confirmation list are output. When key fields are missing or conflicts remain unresolved, a supplementary explanation task is generated.

[0029] The process of generating structural intent information encapsulates the results of previous confidence calibration, conflict resolution, and minimum executable judgments into a unified object. Each field includes a standard value, original value, source, candidate value, selection basis, overall confidence level, whether inferred, and whether manual confirmation is required. Reason tracking, source tracing, and confirmation status markers are output synchronously. The reason tracking field records at least the field name, selected value, candidate value list, source identifier, source type, selection reason, overall confidence level, whether inferred, confirmation status marker, and manual feedback. Through reason tracking, subsequent reviewers can see why a field was selected, why it was completed, and why manual confirmation is required.

[0030] In practical applications, the activation result feedback optimization process can further transform subsequent resource verification results, scheme generation results, activation success results, manual modification results, return reasons, and customer confirmation results into calibration samples for source reliability, candidate field comprehensive confidence weights, dynamic conflict thresholds, and minimum executable thresholds. When the reason for resource verification failure is related to field identification errors, the erroneous field, along with its source tracing and reason tracking, is fed back to the negative sample set of the corresponding business attribute field. When a candidate field of a certain business attribute field is frequently modified by manual confirmation, the source weight and conflict determination threshold of that field are recalculated. When an expression is verified as belonging to the same product type or the same protection requirement in multiple successful activations, it is added to the product alias table or rule base and its related confidence contribution is increased. Through activation result feedback, the activation results are transformed into objective calibration data for the confidence model, making subsequent automatic flow decisions more stable.

[0031] In this embodiment, multi-source business data of the business object is acquired. Based on this multi-source business data, the business attribute fields corresponding to the preset structured intent template are populated, resulting in a candidate field set for each business attribute field. This unifies business requirements scattered across different sources into the processing framework, reducing information omissions. By calculating the comprehensive confidence level of candidate fields based on multi-dimensional evaluation indicators including source reliability, semantic matching degree, and historical consistency, information from multiple dimensions such as data source credibility, semantic relevance, and historical matching degree is integrated, providing a calibrable and objective quantitative basis for field selection. By dividing candidate fields into accepted fields, conflicting fields, and rejected fields based on comprehensive confidence level, high-confidence fields can be populated to support the automated flow of business processes. Simultaneously, retaining conflicting fields provides a complete data context and decision-making basis for subsequent manual review or secondary confirmation, avoiding business interruptions or incorrect activations due to the erroneous rejection of potentially correct values. By generating structured intent information based on accepted and conflicting fields, unstructured or semi-structured business requirements are converted into executable structured objects. This improves the accuracy of business intent parsing and achieves a balance between automation efficiency and result traceability.

[0032] In any of the above embodiments, optionally, to further improve the accuracy of field classification and the efficiency of automated processing, based on the comprehensive confidence level of each candidate field, conflicting fields, excluded fields, and accepted fields are determined from the candidate field set of all business attribute fields, specifically including the following steps: Step S1201: For each business attribute field's candidate field set, calculate the difference between the highest and second-highest comprehensive confidence scores, and use it as a judgment reference value.

[0033] The judgment reference value refers to the difference between the highest and second-highest comprehensive confidence scores, reflecting the discriminatory power between the highest and second-highest values ​​in the candidate field set. This indicator statistically quantifies the significant advantage of the optimal candidate value relative to other competing values. Specifically, a larger judgment reference value indicates that the optimal candidate value has a significant confidence advantage, and the system can automatically adopt it with high confidence; a smaller judgment reference value indicates the existence of multiple competing values ​​with similar confidence scores, and the risk of automatic adoption is higher. For example, if the highest comprehensive confidence score in the candidate field set for a certain business attribute field is 0.92 and the second-highest comprehensive confidence score is 0.85, then the judgment reference value is 0.07.

[0034] Step S1202: When the judgment reference value is greater than or equal to the preset judgment threshold, the candidate field corresponding to the highest comprehensive confidence level is determined as the accepted field.

[0035] The preset judgment threshold is a critical value used to determine whether the highest overall confidence level in the candidate field set has sufficient discriminative power. It's important to note that this preset judgment threshold is not simply a pre-fixed empirical threshold, but a dynamic parameter determined by the distribution of the confidence difference between the highest and second-highest candidate values ​​in historically confirmed samples, the manual correction rate, and the cost of erroneous data transfer. This design allows the threshold to adaptively adjust as business data changes, avoiding the inapplicability of fixed thresholds across different business stages or field types. For critical business attribute fields (such as bandwidth, A-end address, Z-end address, etc.), the cost of erroneous data transfer due to errors is far higher than that of ordinary memo fields. Therefore, differentiated preset judgment thresholds can be set for each business attribute field to achieve stricter control over high-risk fields.

[0036] Step S1203: When the judgment reference value is less than the preset judgment threshold, the candidate fields in the candidate field set are sorted in descending order according to the comprehensive confidence level to obtain the candidate field sequence.

[0037] Step S1204: Candidate fields in the candidate field sequence whose overall confidence level is lower than the preset confidence level lower limit are identified as fields to be removed.

[0038] The pre-set confidence threshold refers to the critical confidence value used to distinguish conflicting fields from excluded fields. This threshold filters out noisy data that, while participating in the ranking, has extremely low confidence, offers no substantial reference value for subsequent decisions, or may even be misleading, thereby simplifying the scope of conflict review and reducing the burden of manual review.

[0039] Step S1205: Candidate fields in the candidate field sequence whose overall confidence level is greater than or equal to the preset confidence lower limit are identified as conflicting fields.

[0040] It's important to note that this step aims to accurately identify and retain fields with high confidence levels but not uniquely identifiable characteristics. Unlike simply discarding them, these fields are marked as conflicting and retained in the structure because, although they didn't win, they still possess high confidence and are highly likely to be reasonable alternative values ​​due to differences in data sources or ambiguities in expression. Retaining these fields provides a complete data context for subsequent manual review or secondary confirmation, preventing the loss of potentially correct information due to algorithmic limitations.

[0041] In practical applications, determining and updating the preset judgment threshold is a continuously optimized closed-loop process. The system first calculates the confidence difference and final confirmation results of business attribute fields in historical samples; then, it selects the minimum confidence difference on the validation set that ensures the automatic workflow error rate does not exceed the risk threshold as the initial preset judgment threshold. During operation, when subsequent activation results show an increase in the number of rejections due to low-confidence automatic selection of a certain type of business attribute field, the system automatically increases the preset judgment threshold for that field, tightening the automatic acceptance conditions; conversely, when multiple batches of samples consistently verify correctness, the preset judgment threshold is appropriately lowered to improve the automation rate. The mathematical expression for conflict determination can be represented by the following formula: ; in, Indicates whether there is a conflict in the j-th business attribute field; This represents the j-th service attribute field, such as bandwidth, A-end address, Z-end address, or protection level. and Two candidate fields representing the same business attribute field; and These represent the combined confidence levels of the two candidate fields, respectively. This represents the conflict determination threshold (i.e., the aforementioned preset threshold). For key business attribute fields, calculations can be performed separately for each field. When the confidence difference in the validation set is lower than If the error rate exceeds the preset risk limit, automatically select the option and increase the risk level. Then it will be transferred to the manual confirmation process.

[0042] Specifically, as an example, in the scenario of opening a dedicated government-enterprise line, for the bandwidth field, the highest overall confidence level in the candidate field set is 0.88, the second highest is 0.86, and the calculated judgment reference value is 0.02. Assuming the preset judgment threshold for the current bandwidth field is 0.05, since 0.02 is less than 0.05, the system determines that the current automatic acceptance condition is not met and enters the conflict handling process. Subsequently, the candidate fields are sorted in descending order of overall confidence level to obtain the candidate field sequence [0.88, 0.86, 0.72, 0.45]. Assuming the preset confidence level lower limit is 0.80, the candidate fields [0.72, 0.45] with an overall confidence level lower than 0.80 are identified as exclusion fields and filtered out; the candidate fields [0.88, 0.86] with an overall confidence level greater than or equal to 0.80 are identified as conflict fields and retained in the structural intent information for subsequent processing.

[0043] In this embodiment, by calculating the difference between the highest and second-highest overall confidence levels as a judgment reference value, the degree of differentiation between candidate fields can be objectively quantified, providing a calculable basis for automated decision-making. When the judgment reference value is greater than or equal to a preset judgment threshold, the candidate field corresponding to the highest overall confidence level is directly determined as the accepted field, achieving efficient automated workflow in high-discrimination scenarios. When the judgment reference value is less than the preset judgment threshold, the candidate fields are sorted and processed hierarchically according to a preset confidence lower limit. Low-confidence noise fields are eliminated, while high-confidence fields that cannot be uniquely determined are retained as conflict fields. This avoids interference from invalid information and provides a complete data context for subsequent manual review. This hierarchical decision-making mechanism based on confidence difference, combined with a dynamically updated threshold strategy, ensures automation efficiency in high-determinism scenarios while retaining necessary decision-making basis and safety redundancy in uncertain scenarios, effectively solving the problem that traditional fixed rules are difficult to adapt to complex and ever-changing business data.

[0044] In any of the above embodiments, optionally, to further improve the interpretability and review efficiency of conflict handling, after determining the candidate fields in the candidate field sequence whose comprehensive confidence is greater than or equal to a preset confidence lower limit as conflict fields, the method further includes the following steps: Step S1206: Generate conflict cause labels for the conflict field. Conflict cause labels include at least one of the following: confidence gap too small, source conflict, or semantic contradiction.

[0045] Among these, "confidence gap too small" refers to a situation where the difference between the overall confidence scores of multiple candidate fields is less than a preset judgment threshold, making it impossible to automatically determine the state of the only accepted field based on confidence advantage. This label usually indicates that the model or rule's ability to distinguish between different data is insufficient, or that the data quality from multiple sources is indeed comparable, requiring manual intervention for value judgment. "Source conflict" refers to different data sources providing different values ​​for the same business attribute field, and these values ​​are reasonable within their respective source contexts. This label clearly points to inconsistencies at the data level, prompting auditors to focus on verifying the timeliness or authority of the data source. "Semantic contradiction" refers to inconsistencies in business logic between candidate fields, even if they may come from the same source or have similar confidence scores, but cannot simultaneously hold true at the business rule level. This label reflects deep-seated business constraint conflicts, often requiring more professional intervention than simple data value conflicts.

[0046] In practical applications, when executing steps S1202 or S1205, if the difference between the highest and second-highest comprehensive confidence scores is less than a preset judgment threshold, and both are higher than a preset confidence lower limit, a "confidence gap too small" label is generated. When multiple candidate values ​​for a retained conflict field are identified as being extracted from different types of multi-source business data (e.g., one from a formal work order field and another from contract attachment text), and their standardized values ​​differ, a source conflict label is automatically generated. When verification through a preset business rule base or field association graph reveals a mutually exclusive relationship between a candidate field and other accepted fields or conflicting fields in the same group (e.g., a standard internet leased line with millisecond-level hard isolation latency requirements, or the A-end address and Z-end address being the same), a semantic contradiction label is generated. It should be noted that the same conflict field may carry multiple conflict reason labels simultaneously. For example, if two candidate fields from different sources not only have different values ​​but also very similar confidence scores, the field will be simultaneously marked as source conflict and "confidence gap too small" to provide auditors with more comprehensive decision support information.

[0047] As a specific application scenario example, in the process of parsing the intent to activate government and enterprise dedicated lines, suppose that for the business attribute field of "product type," the system extracts the value "ordinary data dedicated line" from the work order system, with a comprehensive confidence level of 0.87; simultaneously, it extracts the value "low-latency data dedicated line" from the client's uploaded requirement specification attachment, with a comprehensive confidence level of 0.85. Since the difference between the two (0.02) is less than the preset judgment threshold of 0.05 and both are higher than the preset confidence lower limit of 0.80, both candidate fields are identified as conflicting fields. At this point, the system first generates a "source conflict" label because the two have different sources and values; secondly, it generates a "confidence difference too small" label because the confidence level difference is too small. When viewing the structural intent information, these two labels immediately reveal that the current conflict is due to both inconsistent data sources and the system's difficulty in automatically determining the superiority or inferiority, thus prioritizing verification of whether the attachment is the latest signed version, rather than blindly accepting the work order entry value. For example, for the bandwidth field, if the candidate value is 10G, and for the protection level field, the candidate value is single route without protection, although both fields have high confidence and no direct numerical conflict, according to the rules of the government and enterprise premium leased line business, 10G bandwidth should not usually be configured as single route without protection. After the system verifies the rules, it will generate a semantic contradiction label on the relevant fields, indicating that there may be configuration omissions or unremarked special customer requirements.

[0048] In this embodiment, by generating conflict cause labels for conflict fields, including those indicating small confidence gaps, source conflicts, or semantic contradictions, the abstract conflict state is transformed into concrete, machine-readable and human-readable attribution information. This mechanism significantly enhances the interpretability of the technical solution, effectively addressing the common black-box challenges in AI-based technical solutions. It transforms the retention of conflict fields from merely passive data storage into a proactive means of guiding subsequent processing. Conflict cause labels provide precise navigation for subsequent manual review, allowing reviewers to quickly locate the root cause of the problem without re-examining all the original data. It also provides a basis for automated routing; for example, the system can automatically route semantically contradictory conflicts to senior expert seats based on label type, while routing simple conflicts with small confidence gaps to ordinary confirmation seats. This optimizes the allocation of conflict handling resources and improves the efficiency and accuracy of overall business intent analysis.

[0049] In any of the above embodiments, optionally, when the judgment reference value is greater than or equal to a preset judgment threshold, the candidate field corresponding to the highest comprehensive confidence level is determined as the accepted field, which may specifically include: Step S1202a: The candidate field with the highest overall confidence level in the candidate field set is determined as the accepted field.

[0050] This step is applicable to scenarios where only one candidate field in the candidate field set has the highest overall confidence level. It is the most basic and frequently used acceptance logic in business intent parsing. Specifically, when the system calculates through the aforementioned multi-dimensional evaluation indicators that the overall confidence level of a certain candidate field is numerically significantly higher than that of all other candidate fields in the set, it indicates that the field has significant comprehensive advantages in dimensions such as source reliability, semantic matching degree, and historical consistency. In this case, it can be directly established as an accepted field without introducing additional arbitration rules. This approach can maximize the efficiency of automated processing, reduce unnecessary rule matching overhead, and cover the vast majority of routine business acceptance scenarios with good data quality and clear source orientation.

[0051] Step S1202b: When there are multiple highest values ​​with the same overall confidence level in the candidate field set, the accepted field is determined from the candidate fields corresponding to the multiple highest values ​​based on the data source priority of the candidate fields.

[0052] This step addresses the special boundary scenario where multi-source data exhibits numerical convergence after quantification and scoring. The data source priority refers to a pre-defined ranking rule based on the credibility of different data source types, providing a second dimension of decision-making when confidence scores cannot distinguish between superior and inferior data.

[0053] It's important to note that data source priority is not a static configuration but a flexible parameter that can be dynamically adjusted based on business feedback. Specifically, as an example, in the scenario of opening a dedicated government-enterprise line, the data source priority can be set as follows: formal work order fields take precedence over confirmed forms, which in turn take precedence over attachment descriptions, which take precedence over account manager remarks, which take precedence over chat logs, which take precedence over historical samples. This order reflects the legal validity and accuracy probability of the data source in the business process. Formal work order fields, usually signed by the customer or verified by the system, have the highest legal validity and data standardization. Confirmed forms are next. While attachment descriptions are original documents, they may have version lags or unstructured interpretation errors. Remarks and chat logs are mostly informal communications, with strong subjectivity and arbitrariness. Historical samples only have reference value and no current binding force. When the overall confidence level of two candidate fields is both 0.95, but the sources are the formal work order system and attachment descriptions respectively, the system will select the candidate field from the formal work order system as the accepted field because the data source priority of the formal work order system is higher than that of the attachment descriptions.

[0054] It should be understood that steps S1202a and S1202b are two parallel confidence determination schemes, which can be implemented independently, and there is no necessary order of execution or dependency between them. In actual system deployment, S1202a can be used as the default main path, and S1202b can be triggered as a fallback arbitration mechanism only when the confidence scores are completely equal or the difference is less than the floating-point precision threshold. Alternatively, one strategy can be pre-specified based on the type of business attribute field. For example, S1202b can be forcibly enabled for critical fields to ensure source authority, while S1202a can be used only for non-critical fields to improve processing speed. This parallel design not only enriches the implementation forms of the technical solution, but more importantly, it builds a defensive protection depth to prevent others from circumventing infringement by implementing only one simple scenario, and also reserves flexible space for subsequent differentiated configurations for different customer levels or product types.

[0055] In this embodiment, by directly determining the candidate field with the highest overall confidence level from the candidate field set as the accepted field, common scenarios with a single highest value are efficiently covered, ensuring the automated workflow speed of basic business processes. By determining the accepted field based on data source priority when multiple highest values ​​with the same overall confidence level exist in the candidate field set, the decision-making deadlock when multiple sources provide the same high confidence level result is accurately resolved, ensuring that a reasonable selection can still be made based on the inherent authority of business data even when numerical evaluation fails. These two parallel schemes together constitute a complete and robust acceptance determination strategy, improving the system's decision-making stability under extreme data conditions and enhancing the adaptability of the technical solution to different business environments through the dynamic adjustability of parameters.

[0056] In any of the above embodiments, optionally, in order to solve the problem of information loss that inevitably exists in multi-source business data and improve the usability of intent objects, after generating the structural intent information of the business object based on the accepted fields and conflict fields of all business attribute fields, the following steps are also included: Step S1301: Identify business attribute fields that are missing in the preset structure intent template.

[0057] Among these, "missing" business attribute fields refer to those where no candidate fields are accepted or conflictingly retained in the candidate field set. Specifically, this missing state includes not only empty field values ​​but also situations where candidate values ​​exist but are all rejected, resulting in no valid values ​​to fill the gaps. It's important to note that this identification step is a completeness check performed after generating preliminary structural intent information. Its purpose is to identify key parameters crucial for subsequent resource verification or solution generation, but not explicitly mentioned or effectively extracted from the current multi-source input. For example, in the scenario of government and enterprise dedicated line activation, even if the customer specifies the bandwidth and address, if the protection level is not mentioned, and this service type is required to have a protection level configuration according to regulations, then the protection level field is identified as missing. Through this step, the system can proactively detect information gaps, providing a clear target for subsequent intelligent completion.

[0058] Step S1302: Based on the acceptance fields of the business object and the preset field association rules, infer the business attribute fields that are in a missing state to obtain the inferred fields.

[0059] In this context, inferred fields refer to the completed values ​​derived from existing accepted fields and field association rules. Field association rules are rules that describe the logical relationships between different business attribute fields, such as the correspondence between product type and latency requirements, or the relationship between customer level and protection level. In practical applications, field association rules are not simply lookup tables, but rather a comprehensive reasoning system that integrates multiple knowledge sources. Specifically, the inference process first determines whether it can be inferred from the product template. For example, when "Government and Enterprise Premium Dedicated Line" is identified as a combination of "millisecond input" and "high-level customer", the relevant parameters of "low latency" and "hard isolation" can be inferred based on the product template rules. Secondly, it determines whether it can be inferred from historical samples of the same type of customer. For example, if the same customer accesses the same computing power node multiple times from the same park, the historical A-end or Z-end address can be used as a candidate for inference of the current missing address. Thirdly, it determines whether it can be inferred from general business rules. For example, if the bandwidth unit is missing but the text contains the word "10 Gigabit", it can be inferred as "10G" based on the unit conversion rules, or the activation time limit is written as "before the end of this month" which can be converted into a specific date range.

[0060] To quantify the reliability of the inference results and avoid the risks of blind completion, the confidence level of missing field completion can be calculated using the following formula: ; in, This indicates the confidence level of the missing business attribute field being filled in; This indicates the product template matching degree, reflecting the degree of matching between the current business type and the default values ​​of the template fields; This indicates the matching degree of historical samples, reflecting the reference value of historical samples from the same customer, product, or region to the current field; This indicates the business rule hit rate, reflecting whether field completion complies with the business activation rules; , , The weighting coefficient can be adjusted based on manual verification results. This formula transforms qualitative inferences into quantitative credibility indicators, providing a calculable objective basis for completion decisions. For example, if a missing field simultaneously matches a highly relevant product template and a highly consistent historical sample, its completion credibility will be significantly higher than if it only matches a single fuzzy rule.

[0061] Step S1303: Complete the structural intent information based on the inferred fields.

[0062] This step doesn't simply fill in the missing values; instead, it employs a tiered processing strategy based on the completion confidence level. Specifically, when the completion confidence level is higher than the auto-completion threshold and the field is an inferable field, the system generates a standard completion value and writes it into the structural intent information. However, the reason tracking field must record the inference source, basis, confidence level, and whether manual confirmation is required to ensure traceability and auditability in subsequent steps. When the completion confidence level is in the middle range, the system generates candidate completion values ​​and marks them as awaiting manual confirmation. In this case, although the field is filled, it is not used as the basis for automatic processing and requires manual review to take effect. When the completion confidence level is lower than a preset threshold, the system does not allow the inference result to be used as the final activation parameter, only outputting missing field prompts to prevent low-quality inferences from interfering with subsequent processes. This tiered completion mechanism ensures the integrity of structural intent information while strictly maintaining the bottom line of data quality, achieving a dynamic balance between automation efficiency and business security.

[0063] In this embodiment, by identifying missing business attribute fields in a preset structural intent template, incompleteness in the structural intent information can be accurately identified, providing a clear target for subsequent processing. Missing fields are inferred based on the accepted fields of the business object and preset field association rules. Utilizing multi-dimensional knowledge sources such as product templates, historical samples, and business rules, candidate completion values ​​are generated under the premise of interpretability and traceability, overcoming the limitations of traditional methods that rely solely on a single rule or human experience for completion. By performing hierarchical completion of structural intent information based on inferred fields and combined with completion credibility, the completeness of structural intent information is improved without sacrificing interpretability and security. This effectively reduces repeated manual questioning and process rollbacks caused by missing information, improving the overall efficiency of business intent parsing.

[0064] In any of the above embodiments, optionally, in order to further improve the accuracy and interpretability of missing field completion, based on the accepted fields of the business object and preset field association rules, the business attribute fields in the missing state are inferred to obtain the inferred fields, specifically including the following steps: Step S1302a: Construct a field association graph of the business object. The field association graph includes the association relationships and association strengths between the confirmed and accepted fields.

[0065] The field association graph refers to a network structure with confirmed and accepted fields as nodes and the association relationships and strengths between fields as edges, used to describe the inference basis relationships between different business attribute fields. Specifically, this graph is not a simple static lookup table or hard-coded rule base, but a structured semantic network that can be dynamically constructed based on historical activation samples or pre-trained using domain knowledge. Nodes represent various business attribute fields (such as product type, bandwidth, A-end address, protection level, etc.), while edges represent the dependencies, constraints, or accompanying relationships between fields in business logic. Association strength is a quantitative expression of the closeness of this relationship, which can be determined, for example, by statistically analyzing the frequency of two fields appearing simultaneously with compatible values ​​in historical data, or by constraint weights set based on expert knowledge. By introducing the quantitative dimension of association strength, the technical solution can distinguish between strong causal relationships (such as "low-latency leased line" necessarily implying "millisecond-level latency requirements") and weak correlation relationships (such as "high bandwidth" usually accompanied by "high-level protection" but not absolutely), thus providing a refined parameter basis for subsequent confidence calculations and avoiding the rigidity and misjudgment of traditional Boolean logic rules when dealing with complex business scenarios.

[0066] Step S1302b: Based on the field association graph, query the accepted fields that are related to the business attribute fields that are in a missing state, and use them as the inference basis fields.

[0067] The inference basis fields refer to the accepted fields in the field association graph that are related to the missing business attribute fields, providing a basis for inference for the missing fields. Specifically, the system uses the missing field as the target node and performs graph traversal or neighbor search operations in the field association graph to identify all accepted fields that are directly connected to the target node or indirectly connected via intermediate nodes. This step transforms the abstract "inference" process into a visualized path retrieval process, allowing each inference result to be traced back to the specific source field and connection path, significantly enhancing the interpretability of the technical solution. For example, when the "construction window" field is missing, the system may find the accepted "customer level" field (associated via the "VIP customer service specification" edge) and the "business type" field (associated via the "cutover safety regulations" edge) in the graph. These two fields together constitute the basis set for inferring the construction window.

[0068] Step S1302c: Calculate the inference confidence of the inference field based on the inference basis field and the corresponding association strength.

[0069] The inference confidence score refers to the credibility of the inferred field calculated based on the inference basis field and the correlation strength. This indicator comprehensively considers two core elements: the credibility of the source data and the reliability of the inference path. Specifically, the inference confidence score is calculated by fusing the overall confidence score of the inference basis field with the correlation strength between that basis field and the missing field. In a preferred implementation, for a single inference path, the inference confidence score equals the overall confidence score of the inference basis field multiplied by the corresponding correlation strength. When multiple inference paths point to the same inferred value, the maximum value of the calculated results for each path can be taken, or a weighted summation method can be used to aggregate the support of multiple evidence chains. This calculation mechanism ensures that the generated inference value has a high confidence score only when the source field itself is highly credible and its business correlation with the missing field is sufficiently close.

[0070] Step S1302d: When the inference confidence level is greater than the preset inference threshold, the inference field is filled into the business attribute field that is in a missing state.

[0071] This step establishes a security gating system for the inference results entering the structural intent information. A preset inference threshold serves as a baseline for assessing whether the inference result is sufficient to replace manual input. Only when the inference confidence exceeds this threshold will the system deem the inference value sufficiently reliable and automatically fill it in; conversely, if the inference confidence is below the threshold, the inference value is either retained as a candidate suggestion in the reason tracking record for manual reference or discarded directly to prevent low-quality guesses from contaminating subsequent business processes. It should be understood that the preset inference threshold can be configured differently based on the risk level of the business attribute fields. For example, a higher inference threshold can be set for the "Protection Level" field, which affects network security, while a lower threshold can be set for non-critical fields such as "Contact Notes," to achieve the optimal balance between security and automation.

[0072] Specifically, as an example, in the scenario of establishing a dedicated government-enterprise line, assuming the "Product Type" field has been accepted as "Low-Latency Computing Dedicated Line," its overall confidence level is 0.93. When the system executes step S1302b, it uses a field association graph to find a direct association edge between the "Latency Requirement" field and the "Product Type" field, and the association strength of this edge is 0.88 (indicating that "Low-Latency Computing Dedicated Line" has a very strong definitional constraint on "Latency Requirement"). Subsequently, in step S1302c, the inference confidence level of the "Latency Requirement" field is calculated to be... Assuming the current preset inference threshold for the "Latency Requirement" field is 0.75, since the inference confidence level of 0.8184 is greater than 0.75, the system automatically fills the inferred standard latency value (such as "≤5ms") into the "Latency Requirement" field of the structural intent information in step S1302d, and records in the reason tracking: "Inference Source = Product Type (Low Latency Inbound Dedicated Line), Association Strength = 0.88, Source Confidence = 0.93, Inference Confidence = 0.8184".

[0073] In this embodiment, by constructing a field association graph of business objects, the relationships and strengths of confirmed and accepted fields are quantified in a structured manner. This upgrades discrete field rules into a knowledge network with topological reasoning capabilities, providing a richer and more accurate structured basis for inferring missing fields than simple matching. By querying the inference basis fields based on the field association graph, the inference process is ensured to have clear path traceability, effectively addressing the black-box concerns of AI-based technical solutions. By calculating the inference confidence based on the inference basis fields and association strength, and only filling in the gaps when the inference confidence exceeds a preset inference threshold, a rigorous mathematical logic of "source credibility × transmission reliability = result credibility" is established. This ensures the reliability of the inference results, prevents low-confidence inference values ​​from entering subsequent processes, and significantly improves the robustness and practicality of business intent parsing in information-missing scenarios.

[0074] In any of the above embodiments, optionally, in order to improve the accuracy of intent parsing, the comprehensive confidence level of each candidate field is calculated based on a preset multi-dimensional evaluation index, specifically including the following steps: Step S1101: For each candidate field, calculate the source reliability index, semantic matching index, and historical consistency index respectively.

[0075] The source reliability metric is determined based on the data source type of the candidate field. This metric aims to quantify the trustworthiness of the data source, but it doesn't simply assign a fixed score based on the source type; instead, it dynamically calibrates by incorporating historical feedback data. Specifically, the source reliability metric can be obtained by querying a pre-defined source reliability table, which records the historical hit rate of different source types on different business attribute fields. For example, for source type t and business attribute field s, the number of times N_pos was manually confirmed or successfully verified as correct in historical samples, and the number of times N_neg was manually corrected or resulted in a rejection, are counted and then smoothed using the following formula: ; in, This represents the source reliability index of source type t on the business attribute field s; This is the source prior weight, reflecting the basic level of trust in the source in this field during system initialization; This is a smoothing coefficient used to prevent drastic fluctuations in weights due to random errors in small sample sizes. By introducing a smoothing calibration mechanism, the reliability of the source can reflect long-term statistical regularities while retaining the guiding role of prior knowledge, thus avoiding evaluation distortion in the cold start phase or sparse data scenarios.

[0076] The semantic matching score is determined based on the semantic similarity between candidate fields and their corresponding business attribute fields. This score measures the degree of semantic alignment between unstructured or semi-structured candidate values ​​and standardized field definitions. Specifically, the semantic matching score can be obtained by calculating the semantic similarity between candidate field values ​​and their corresponding standard definitions using a pre-trained semantic similarity model. For example, when the candidate field value is "10 Gigabit access" and the standard definition of the business attribute field is "10G bandwidth," the model can identify the equivalent semantics of both in the communication domain and output a high similarity score, thus compensating for the limitation of literal matching in covering synonymous expressions or industry terminology.

[0077] The historical consistency metric is determined based on the degree of matching between candidate fields and historically confirmed data. This metric leverages the inertia and stability of business behavior; that is, the same customer, similar product, or the same region often exhibits similar configuration preferences in historical activation records. Specifically, the historical consistency metric can be obtained by statistically analyzing the hit rate of consistency between the current candidate field and historically confirmed data for the same customer, product, or region. For example, if a customer selected "dual-route protection" for all three of their previous dedicated line activations, then when the customer applies again, the historical consistency metric for the "dual-route protection" candidate value will be significantly higher than other protection level options. This evaluation dimension based on historical statistics provides a third verification perspective for confidence calculation, independent of the current text content and source attributes, enhancing the stability of the evaluation results.

[0078] Step S1102: Based on the preset weights corresponding to each indicator, the source reliability indicator, semantic matching degree indicator, and historical consistency indicator are weighted and calculated to obtain the comprehensive confidence level.

[0079] This step enables the fusion of multi-dimensional evaluation information for decision-making. Specifically, as an example, the overall confidence score can be calculated using the following formula: ; in, This represents the overall confidence level of the i-th candidate field; This represents the i-th candidate field, such as a candidate A-end address, bandwidth value, or protection level; This indicates the reliability weight of the source corresponding to the candidate field on the current business attribute field (i.e., the aforementioned source reliability index). This indicates the semantic matching degree between the candidate field and the input text q; This indicates that the candidate field is consistent with historical activation samples; This indicates the completeness of the candidate field in the current context and the consistency of constraints between fields, and is used to supplement the evaluation of whether the candidate value conforms to the overall context and logical constraints of the current work order; , , , These are the weighting coefficients.

[0080] In practical applications, the determination of weight coefficients is not static but dynamically evolves through a combination of prior initialization, validation set calibration, and updates based on activation result feedback. Specifically, the system first assigns initial weights based on the source hierarchy and business experience; then, it constructs training and validation sets using historically confirmed activation samples, using the final confirmation status of candidate fields as labels, and employs algorithms such as logistic regression, gradient descent, or grid search to obtain the optimal weight combination for each dimension; when new activation results, manually modified results, or resource verification rejection reasons are fed back, the weights are incrementally updated according to the business attribute field type and business scenario. In particular, for key business attribute fields (such as bandwidth, A / Z address, etc.), the system sets the cost of automatic error routing higher than the cost of manual confirmation, thereby automatically increasing the confidence requirement for this field during weight optimization, forcing the model to be more conservative and cautious when facing key fields. This dynamic calibration mechanism enables the comprehensive confidence model to continuously adapt to changes in business rules and data distribution drift, avoiding the performance degradation problem of static models in long-term operation.

[0081] In this embodiment, candidate fields are independently and complementaryly evaluated from three dimensions—data credibility, relevance, and stability—by calculating source reliability, semantic matching, and historical consistency indicators, respectively, overcoming the one-sidedness of single-dimensional evaluation. A comprehensive confidence score is obtained through weighted calculation based on preset weights for each indicator, integrating evaluation results from multiple dimensions to form a quantifiable comprehensive judgment criterion. Through calibrable weight coefficients and a smooth calibration mechanism, the comprehensive confidence score calculation model not only adapts to the differentiated needs of different business scenarios but also continuously optimizes itself with the accumulation of business data, significantly improving the accuracy and robustness of business intent parsing in complex and ever-changing environments.

[0082] In any of the above embodiments, optionally, in order to improve the generation quality of the candidate field set and reduce noise interference in subsequent processing, the business attribute fields corresponding to the preset structure intent template are filled based on multi-source business data to obtain a candidate field set for each business attribute field, specifically including the following steps: Step S1001: Entity identification and relationship extraction are performed on the multi-source business data to obtain the business entities and their related relationships.

[0083] In this context, business entities refer to objects and attributes with business meaning identified from multi-source business data. In the scenario of government and enterprise dedicated line activation, business entities include not only general named entities but also domain-specific business parameters, such as customer name, customer level, product type, bandwidth, A-end address, Z-end address, computing power nodes, latency requirements, protection level, hard isolation requirements, activation time limit, construction window, and customer constraints. Relationships refer to the logical connections between business entities. These connections transcend syntactic dependencies in natural language processing, focusing more on constraints and dependencies at the business rule level. Specifically, relationships can include the attribution relationship between a customer and an address (used to determine if an address belongs to the customer's service scope), the configuration relationship between product type and bandwidth (used to verify if bandwidth values ​​conform to product specifications), the directional relationship between A-end and Z-end (used to distinguish link start and end points), and the compatibility relationship between protection level and latency requirements. Through relationship extraction, the system can organize discrete entity fragments into semantically structured business knowledge units, providing a logical foundation for subsequent contextual verification.

[0084] Step S1002: Perform attribute mapping on the business entity to obtain candidate attribute values ​​corresponding to the business attribute fields.

[0085] Attribute mapping refers to converting the identified business entity values ​​into standardized candidate values ​​corresponding to the business attribute fields in the preset structural intent template. Since the forms of expression for multi-source business data vary greatly, the raw values ​​used directly often cannot meet the format requirements of subsequent automated workflows; therefore, normalization processing is necessary. Specifically, as an example, in product type mapping, different expressions such as "millisecond-level computing dedicated line," "computing dedicated line," "low-latency computing network dedicated line," and "intelligent computing center access dedicated line" can be uniformly mapped to standard product type codes or names; in bandwidth mapping, "10 Gigabit," "10000M," "10Gbps," and "10G" can be uniformly converted to the standard unit "10G"; in computing node mapping, different aliases or abbreviations can be mapped to standard computing node names; in protection level mapping, expressions such as "primary and backup protection," "dual routing," "uninterrupted service," and "4A+ guarantee" can be mapped to standard protection level enumeration values; in construction window mapping, natural language descriptions such as "after get off work today," "weekend cutover," and "does not affect daytime office work" can be converted into standard time windows or Boolean constraints that the system can execute. It should be noted that the field standardization process strictly adheres to the principle of "not changing the original meaning of the customer's constraints." When the same expression can be mapped to multiple product templates, such as "dedicated line" which may correspond to a regular dedicated line or a premium dedicated line, the system will retain multiple template candidates and include them in the subsequent confidence calculation stage. When the standardization result comes from rule inference rather than the customer's explicit expression, the inference status will be marked as true in the reason tracking so that subsequent review can distinguish between factual data and speculative data. When standardization fails, the original text will be retained and marked as pending manual confirmation to ensure that no information is lost.

[0086] Step S1003: Based on the association relationship, perform contextual verification on the candidate attribute values ​​and exclude candidate attribute values ​​that do not conform to the contextual logic.

[0087] This step is a key improvement in this embodiment that distinguishes it from traditional entity recognition technology. Traditional entity recognition often focuses only on the extraction accuracy of individual entities, ignoring the logical consistency between entities in specific business scenarios. This leads to a large number of entities that are correctly identified but invalid in the current context entering subsequent processes, resulting in wasted computing resources and even misleading decisions. In this embodiment, context verification uses the association relationships extracted in step S1001 as verification rules to logically review the candidate attribute values ​​generated in step S1002. Specifically, as an example, if the system identifies a Z-end address from the attachments, but does not find a corresponding A-end address in the context of the entire multi-source business data, and the product type is not explicitly defined as a special business that does not require an A-end, then the Z-end address candidate value is considered an isolated entity and is excluded or downgraded. If the protection level is identified as "dual routing," but the construction window constraint is "only single cutover is allowed," there is a physical contradiction between the two in business implementation. The system will mark the relevant candidate attribute values ​​as logical conflicts, prompting subsequent steps to pay close attention. This pre-filtering based on business logic can effectively eliminate noisy data caused by OCR recognition errors, textual ambiguity, or residual historical information, significantly improving the purity of the candidate field set.

[0088] Step S1004: Use the verified candidate attribute values ​​as candidate fields, and obtain a candidate field set based on all candidate fields.

[0089] After entity recognition, attribute mapping, and context verification, the remaining candidate attribute values ​​are high-quality valid candidate fields. The system aggregates all valid candidate fields under the same business attribute field to form the final candidate field set, which is then used for comprehensive confidence calculation in subsequent step S110.

[0090] In practical applications, to support the efficient execution of the above steps, the system pre-constructs a dedicated line domain entity dictionary, product alias table, address standard library, computing node alias table, bandwidth unit table, protection level mapping table, and construction constraint vocabulary table. Simultaneously, it combines a pre-trained semantic model to identify new or variant expressions not found in the dictionary, ensuring the system's generalization ability. For address entity identification and verification, a hierarchical parsing strategy is adopted: first, it identifies hierarchical information such as administrative region, park, building, computer room, floor, room, or customer-side cabinet; then, it combines directional words, such as "from," "to," "access," or historically frequently used access point records to determine whether it belongs to end A or end Z. For computing node entities, it can identify various expressions such as cloud resource pool, computing center, edge node, and IDC data center. For latency entities, it can distinguish qualitative or quantitative requirements such as "low latency," "millisecond level," "less than 5ms," and "metropolitan area millisecond input," and map them to corresponding service level agreement parameters.

[0091] In this embodiment, entity recognition and relationship extraction are performed on multi-source business data to extract business entities with business meaning and their relationships from unstructured or semi-structured data, providing a structured semantic foundation for subsequent processing. By mapping attributes to business entities, diverse natural language expressions are converted into standardized candidate attribute values, achieving unified carrying and standardized representation of data from different sources. Contextual verification of candidate attribute values ​​based on relationships is performed, using business logic constraints to exclude isolated entities or contradictory data that do not conform to the contextual logic. This effectively improves the accuracy and purity of the candidate field set, reduces noise interference and computational overhead in subsequent confidence calculations, and thus enhances the efficiency and robustness of the overall business intent parsing.

[0092] Figure 2 A flowchart illustrating an overall method for parsing business intent according to an embodiment of this application is shown below: Step S300: Multi-source input access; Specifically, this step involves accessing business data from seven types of data sources, including natural language, work order fields, electronic forms, attachment text, historical records, confirmed samples, and cleaned input sets, to provide raw input for subsequent processing.

[0093] Step S310: Clean the markings; Specifically, this step performs text denoising, format conversion, and source credibility labeling on the input data to form a standardized cleaned input set. This step, together with S300, corresponds to the pre-processing stage in step S100 for acquiring multi-source business data.

[0094] Step S320: Intent recognition; Specifically, this step performs semantic vectorization and intent template matching on the cleaned input to comprehensively determine whether the input belongs to a dedicated line activation requirement and what type of service it is. This step corresponds to the pre-judgment stage of step S100, and its output determines the template selection for subsequent entity recognition.

[0095] Step S330: Entity recognition; Specifically, this step extracts entities from the cleaned text, including customer name, product type, bandwidth, A-end address, Z-end address, computing power nodes, latency requirements, protection level, and construction window. This step, together with S340, corresponds to the core processing step in step S100 of filling the candidate field set.

[0096] Step S340: Slot filling; Specifically, this step normalizes the identified entity values ​​and fills them into the corresponding business attribute field slots, forming a set of candidate values ​​for each slot. This step relies on the entity recognition results from the S330, and the two are executed sequentially.

[0097] Step S350: Field normalization; Specifically, this step calculates indicators such as source reliability, semantic matching degree, and historical consistency for each slot's candidate value, and then performs weighted fusion based on preset weights to obtain a comprehensive confidence score. This step corresponds to the engineering implementation of the comprehensive confidence score calculation in step S110.

[0098] Step S360: Conflict completion; Specifically, this step identifies field conflicts based on confidence difference, generates a list of fields to be confirmed for those that cannot be automatically resolved, and performs inference completion for missing fields. This step corresponds to the engineering implementation of steps S120 and S130.

[0099] Step S370: Output the object; Specifically, this step generates a standardized Intent object when the minimum executable conditions are met. This object contains fields such as standard value, original value, source, candidate value, selection criteria, confidence level, and confirmation flag, which serve as input for subsequent resource verification and solution generation. This step corresponds to the final encapsulation stage of generating structural intent information in step S130. The final output Intent object not only contains machine-readable execution parameters but also human-understandable source tracing, rationale tracking, and decision-making basis.

[0100] Figure 3 This diagram illustrates a multi-source input access method for parsing business intent according to an embodiment of this application. Specifically, it receives seven types of data sources through a unified access layer 100, including natural language, work order fields, electronic forms, attachment text, historical records, confirmed samples, and cleaned input sets. Natural Language: Unstructured natural language business requests input by customers through oral communication, instant messaging, and other channels, directly expressing the customer's original needs; Work Order Fields: Structured work order standard field data from the business acceptance system, including standardized information such as customer identifier, product type, bandwidth, service start and end addresses, and expected activation time; Electronic Forms: Semi-structured or structured form data such as project activation application forms and business acceptance forms submitted during the business acceptance process; Attachment Text: Unstructured document data such as contract attachments, customer requirement specifications, and network topology scheme descriptions related to the business; Historical Records: Historical leased line business data retained from the same customer, product, region, or activation scenario, providing historical reference for current requirement analysis; Confirmed Samples: Standardized historical business samples that have been manually verified and successfully activated, serving as a benchmark reference for field standardization and parsing result verification; Cleaned Input Set: Supplementary or retrospective business data output from the previous cleaning stage, which has undergone noise reduction and format standardization, serving as a supplementary input source for the access layer.

[0101] Various data sources are transmitted to the unified access layer 100 through corresponding data links. After the unified bearing of heterogeneous data on the entry side is completed by this layer, it is output to the subsequent business intent parsing links such as intent recognition and domain entity extraction.

[0102] Figure 4 A flowchart illustrating the dedicated line activation requirement determination method according to an embodiment of this application is shown below: Step S400: Semantic vectorization; Specifically, this step performs semantic vectorization processing on the cleaned input text, converting natural language expressions into computable semantic vector representations, providing a computational basis for subsequent template matching and intent classification.

[0103] Step S410: Template matching; Specifically, this step matches semantic vectors against a predefined set of intent templates. These intent templates cover various service types, including premium dedicated lines, compute dedicated lines, low-latency dedicated lines, and industry-specific dedicated lines. Each template contains the standard set of fields required for that service type and the constraints between those fields. The matching process does not rely on a single keyword but rather makes a comprehensive judgment based on semantics such as low latency, hard isolation, compute nodes, and service level agreements within the product template.

[0104] Step S420: Rule validation; Specifically, this step performs logical validation on the matching results based on the leased line service rules. For example, if the input is matched as "low-latency computing leased line" but no computing node information is provided, the matching result is marked as having a missing field; if the input is matched as "premium leased line" but the bandwidth value does not meet the minimum specification requirements, it is marked as having a specification conflict.

[0105] Step S430: Contextual judgment; Specifically, this step assesses whether the fields in the input text form a complete semantic chain, and determines whether the A-end and Z-end addresses are complete, whether the bandwidth and protection level match, and whether the product type and latency requirements are compatible. Expressions such as "want to know the leased line price" or "does it support future expansion" are identified by the system as inquiries or supplementary explanations, rather than formal activation requests.

[0106] Step S440: Intent classification; Specifically, this step, based on the combined results of the preceding stages, categorizes inputs into formal activation requests, consultation requests, change requests, or non-activation requests. The system calculates intent recognition confidence based on four dimensions: source weight, semantic similarity, consistency with similar historical samples, and contextual completeness. The weights of each dimension are calibrated using confirmed activation samples, misjudged samples, and returned samples.

[0107] Step S450: Minimum condition prediction; Specifically, this step determines whether the input meets the minimum executable conditions to proceed to the subsequent resource verification process. For government and enterprise dedicated line activation scenarios, it typically needs to include core fields such as customer entity, product type, bandwidth, and A-end and Z-end. When the semantic similarity is high but key executable fields are missing, the system determines it to be a consultation or a requirement to be supplemented.

[0108] Step S460: Confirm the mark; Specifically, this step adds a confirmation status marker to the classification result. For inputs determined to be formal activation requests, the system generates an intent type result containing intent type, service type, intent confidence, a list of required slots, a list of optional slots, and a confirmation marker, which serves as input for subsequent entity recognition and slot filling steps.

[0109] Specifically, as an example, the seven steps from S400 to S460 are executed sequentially, with each step producing traceable intermediate results, ultimately providing clear business type guidance and a list of field requirements for subsequent entity identification and slot filling.

[0110] Figure 5 A flowchart illustrating the dedicated line domain entity identification and slot filling process of a business intent parsing method according to an embodiment of this application is shown below: Step S500: Customer level identification; Specifically, this step extracts customer level information, such as "AAA-level customer" or "government and enterprise VIP," from the work order field or customer tagging system. This information will affect the priority of subsequent field inferences and conflict resolution strategies.

[0111] Step S510: Product bandwidth identification; Specifically, this step extracts product type and bandwidth information from natural language, forms, or attachments, maps different expressions such as "millisecond computing leased line," "input computing leased line," and "low-latency computing network leased line" to a unified standard product type, and converts "10 Gigabit," "10000M," and "10Gbps" into the standard unit "10G."

[0112] Step S520: Identify the addresses at both ends; Specifically, this step extracts address information from both the A-end and Z-end, and adopts a hierarchical parsing strategy. First, it identifies levels such as administrative regions, parks, buildings, and data centers, and then combines directional words (such as "from", "to", and "access") to determine whether it belongs to the A-end or the Z-end.

[0113] Step S530: Identification of computing power nodes; Specifically, this step identifies expressions such as cloud resource pools, computing centers, edge nodes, and IDC data centers, and maps them to standard computing node names.

[0114] Step S540: Delay protection identification; Specifically, this step extracts latency requirements and protection levels from customer constraint descriptions, mapping expressions such as "primary and backup protection," "dual routing," "uninterrupted service," and "4A+ guarantee" to standard protection level enumeration values.

[0115] Step S550: Construction window recognition; Specifically, this step converts natural language descriptions such as "after get off work today", "weekend cutover", and "does not affect daytime work" into standard time windows or Boolean constraints that the system can execute.

[0116] Step S560: Aggregate the candidate slot set; Specifically, this step aggregates the candidate attribute values ​​identified from each dimension according to the business attribute fields, forming a candidate field set for each field. This step is the convergence node from S500 to S550, and its output serves as the input for the confidence calculation in step S110.

[0117] Specifically, as an example, to support the efficient execution of the above identification steps, the system pre-constructs a dedicated line domain entity dictionary, product alias table, address standard library, computing power node alias table, bandwidth unit table, protection level mapping table, and construction constraint vocabulary. At the same time, it combines a pre-trained semantic model to identify new or variant expressions that do not appear in the dictionary, ensuring the system's generalization ability.

[0118] Figure 6 The flowchart illustrating the conflict resolution and missing field completion process of a business intent parsing method according to an embodiment of this application is shown below: Step S600: Candidate value aggregation; Specifically, this step groups all the candidate attribute values ​​produced in the previous steps according to the business attribute fields, forming a candidate field set for each field, providing input for subsequent confidence calculation.

[0119] Step S610: Confidence calculation; Specifically, this step calculates a comprehensive confidence score for each candidate field, which integrates the evaluation results of three dimensions: source reliability, semantic matching degree, and historical consistency. The calculation process of this step is independent of the conflict determination logic and can be integrated with S600.

[0120] Step S620: Conflict identification; Specifically, this step calculates the difference between the highest and second-highest overall confidence scores in the candidate set of each business attribute field. When the difference is less than a preset judgment threshold, the field is marked as conflicting. For example, for the bandwidth field, the highest overall confidence score is 0.88, the second-highest is 0.86, and the judgment reference value is 0.02, which is less than the preset judgment threshold of 0.05. Therefore, the system determines that the current bandwidth field is conflicting.

[0121] Step S630: Rule resolution; Specifically, this step resolves conflicts based on source priority, confidence difference, and historical consistency. For fields that can be automatically resolved, the system identifies the candidate field corresponding to the highest overall confidence level as the accepted field; for fields that cannot be automatically resolved, a list of fields to be confirmed, including conflict reason labels, is generated. Conflict reason labels include insufficient confidence difference, source conflict, or semantic contradiction.

[0122] Step S640: Missing item inference; Specifically, this step identifies missing business attribute fields in the preset structural intent template and calculates the completion credibility based on three dimensions: product template matching degree, historical sample matching degree, and business rule hit degree. When the completion credibility is higher than the automatic completion threshold and the field is an inferable field, the system generates a standard completion value and writes it into the structural intent information, while recording the inference source and basis in the reason tracking; when the completion credibility is in the middle range, candidate completion values ​​are generated and marked as awaiting manual confirmation; when the completion credibility is lower than the preset threshold, only a missing field prompt message is output.

[0123] Step S650: Manual confirmation; Specifically, this step presents all fields marked as pending confirmation to the reviewers in the form of a confirmation list. After the reviewers confirm, the system updates the acceptance status of the fields and records the manual feedback. This step is the only part of the process that requires manual intervention.

[0124] Step S660: Complete the slot set; Specifically, this step aggregates all accepted fields, conflicting fields, and complete fields to form structural intent information. This step is the convergence node for S600 to S650, and its output serves as the input for subsequent object encapsulation.

[0125] Figure 7 A flowchart illustrating the activation intent object generation process of a business intent parsing method according to an embodiment of this application is shown below: Step S700: Minimum executable condition determination; Specifically, this step, based on the completed slot set produced by the preceding process, determines whether the structural intent information meets the basic conditions for entering the subsequent resource verification process. For government and enterprise dedicated line activation scenarios, the minimum executable conditions typically require at least the following core fields: customer entity, product type, bandwidth, A-end, Z-end, and activation time limit; for inbound computing dedicated lines or low-latency dedicated lines, computing power nodes and latency requirements are also required.

[0126] Step S710: Comprehensive executability score; Specifically, this step calculates an executability score based on three dimensions: the completeness of the structural intent information, the average overall confidence level of key business attribute fields, and the number of unresolved conflict fields. The weights of each dimension are calibrated by the results of historical samples, including whether the process was successful, whether it was returned, and whether it was manually corrected after entering the subsequent process.

[0127] Step S720: Object encapsulation and output; Specifically, when the completeness reaches the threshold, the overall executability score reaches the executability threshold, and the number of unresolved conflict fields is zero, the system will encapsulate all fields in the slot set into a unified object, generating standardized structural intent information. This structural intent information adopts a unified key-value structure, and each business attribute field includes a standard value, original value, source, candidate value, selection basis, overall confidence level, whether inference is made, and whether manual confirmation is required.

[0128] Specifically, as an example, the reason tracking field is an important component of this embodiment. For the bandwidth field, reason tracking might record the following: the field name is "bandwidth", the selected value is "10G", the candidate value list includes "10G (source: work order field, overall confidence level 0.92)" and "1G (source: attachment text, overall confidence level 0.45)", the selection reason is "automatically accepted with the highest overall confidence level", and the confirmation status is marked as "no confirmation required". As another example, for the protection level field, the selected value is "dual-route protection", the candidate value list includes "dual-route protection (source: contract attachment, overall confidence level 0.86)" and "single route (source: account manager's remarks, overall confidence level 0.83)", the selection reason is "confidence level difference is too small, accepted after manual confirmation", and the confirmation status is marked as "manually confirmed". Through reason tracking, subsequent reviewers can see why a certain field was selected, why it was completed, and why manual confirmation was required, achieving full-link traceability of the business intent parsing process.

[0129] In practical applications, the confirmation status flag field is used to identify the confirmation status of each business attribute field, including three statuses: no confirmation required, recommended confirmation, and mandatory confirmation. When the overall confidence level of a field is higher than the automatic acceptance threshold and there are no conflicts, it is marked as no confirmation required; when a field has resolved conflicts but the confidence difference is within the boundary range, it is marked as recommended confirmation; when a field originates from inference or has unresolved semantic contradictions, it is marked as mandatory confirmation. The confirmation status flag is linked to the flow conditions of subsequent processes; fields marked as mandatory confirmation must undergo manual review before entering resource verification. When the completeness meets the standard but low-confidence fields exist, the system outputs a semi-structured object and a confirmation list; when key fields are missing or conflicts remain unresolved, the system does not enter automatic resource verification but instead generates a supplementary explanation task.

[0130] Figure 8 The flowchart illustrating the activation intent object output method of a service intent parsing method according to an embodiment of this application is shown below: Step S800: Enable intent object acquisition; Specifically, this step obtains the structured Intent object generated in the previous step, which contains the acceptance field, conflict field, and completion field of all business attribute fields, as well as the corresponding source tracing and reason tracking information.

[0131] Step S810: Resource verification parameter mapping; Specifically, this step maps key fields in the Intent object to input parameters required by the resource verification process, focusing on outputting fields such as customer identifier, product type, standard bandwidth, A-end standard address, Z-end standard address, computing power node, latency requirements, and protection level, which are used to query A / Z-end resource availability, bandwidth resource sufficiency, computing power node access capability, routing reachability, and protection capability.

[0132] Step S820: Parameter mapping for scheme generation; Specifically, this step maps the fields related to the scheme design in the Intent object to the input parameters required for the scheme generation process, and focuses on outputting fields such as product type, routing preference, hard isolation requirements, construction window and customer constraints, which are used to generate premium leased line activation schemes, low latency calculation schemes or protection routing schemes.

[0133] Step S830: Instruction orchestration parameter mapping; Specifically, this step maps network configuration-related fields in the Intent object to input parameters required by the instruction orchestration process, which are used to generate configuration instructions and scheduling commands for network devices.

[0134] Step S840: Work order backfilling; Specifically, this step writes back the standard field values, manual confirmation fields, and reason tracking summary from the Intent object to the work order interface of the business system, enabling account managers and reviewers to view the results of intent parsing and the basis for decision-making.

[0135] Step S850: Process receipt; Specifically, this step receives the execution results of subsequent processes and generates a receipt record. When the resource verification passes, the process continues towards solution generation and instruction orchestration; when the resource verification fails, the system backtracks the failure reason along with the field source tracing and justification, for use in subsequent rule optimization.

[0136] Specifically, as an example, during the automatic output process, the system ensures that unresolved conflict fields are not carried as final parameters, synchronously confirms low-confidence fields, retains the basis for inference for inferred fields, and only outputs semi-structured objects and supplementary lists for objects that do not meet the minimum executable conditions, without triggering automatic resource checks.

[0137] Figure 9 The flowchart illustrating the activation result feedback process of a service intent parsing method according to an embodiment of this application is shown below: Step S900: Enable result collection; Specifically, this step collects the execution results of subsequent processes, including resource verification results, scheme generation results, successful activation results, and failed activation results. These results reflect the accuracy and effectiveness of the preceding intent parsing.

[0138] Step S910: Manually modify the record; Specifically, this step records the manual modifications made by reviewers to each field in the Intent object, including the original value before modification, the confirmed value after modification, the reason for modification, and the modification time. When a candidate field of a business attribute is confirmed to be frequently modified manually, the system incorporates the modification frequency and direction of that field into the input for weight calibration.

[0139] Step S920: Failure Root Cause Analysis; Specifically, this step analyzes the reasons for resource verification failures, solution generation failures, and activation failures. When the failure reason is related to field identification errors, the system marks the erroneous field, along with its source tracing and reason tracking, as a negative sample; when the failure reason is related to product template matching errors, the system reduces the weight of the corresponding template mapping in the same scenario.

[0140] Step S930: Sample recovery; Specifically, this step transforms verified activation results into calibration samples. Only feedback results that have been manually confirmed, confirmed by the customer, or verified as successfully activated can be used to increase weights or decrease thresholds; failure records can be used to decrease the weight of incorrect mappings or increase the thresholds of key business attribute fields, but must not be directly used as the basis for default completion.

[0141] Step S940: Weight adjustment; Specifically, this step updates the source reliability table and overall confidence weights based on the recovered calibration samples, and incrementally updates the weight coefficients of each dimension according to the business attribute field type and business scenario. For key business attribute fields (such as bandwidth, A / Z address, etc.), the system sets the cost of automatic error routing to be higher than the cost of manual confirmation, thereby automatically increasing the confidence requirement of the field during the weight optimization process.

[0142] Step S950: Rule update; Specifically, this step updates the conflict determination threshold and the minimum executable threshold. When subsequent activation results show that the number of rejections increases due to the automatic selection of a certain type of business attribute field with low confidence, the system automatically raises the preset determination threshold for that field and tightens the automatic acceptance conditions; when multiple batches of samples are verified to be stable and correct, the preset determination threshold is appropriately lowered to improve the automation rate.

[0143] Step S960: Template optimization; Specifically, this step updates the product alias table, entity dictionary, and field mapping rules. When an expression is verified as belonging to the same product type or protection requirement in multiple successful activations, the system adds it to the product alias table or rule base and increases its related confidence contribution; when a low-confidence completion result is manually confirmed to be correct, the system increases the reliability weight of the corresponding completion rule.

[0144] Step S970: Closed-loop improvement; Specifically, this step summarizes the results of this round of optimization and outputs updated intent templates, entity dictionaries, slot rules, field mapping tables, conflict resolution rules, source reliability tables, dynamic thresholds, and executability scoring parameters. When the same rule exhibits significant differences in performance across different regions, customer levels, or product types, the system splits weights and thresholds according to scenarios. This allows source reliability, overall confidence weights, conflict determination thresholds, and minimum executability thresholds to adaptively adjust with changes in business data, continuously improving recognition stability and interpretability during large-scale deployment of government and enterprise dedicated lines.

[0145] like Figure 10 As shown, this application embodiment provides a business intent parsing device 200, the device 200 including: The acquisition unit 202 is used to acquire the multi-dimensional features of the current call event, and based on the multi-dimensional features of the current call event, obtain the feature interaction information of the current call event, wherein the multi-dimensional features include static attribute features and temporal behavior features; The first processing unit 204 is used to input the feature interaction information of the current call event into the pre-trained encoder for feature processing to obtain the call mode encoding of the current call event. The second processing unit 206 is used to calculate the abnormal score of the current call event based on the call mode code and the normal call mode code set in the preset memory. The preset memory updates the normal call mode code set based on the preset maintenance strategy. The third processing unit 208 is used to obtain the judgment result of the current call event based on the anomaly score of the current call event.

[0146] The service intent parsing device 200 provided in this application embodiment acquires multi-dimensional features of the current call event. Based on these features, it obtains the feature interaction information of the current call event, fully utilizing the complementarity of static attributes and temporal behavior to construct a complete and highly correlated representation of the call event, overcoming the deficiency of insufficient information from single-dimensional features. The feature interaction information is input into a pre-trained encoder to obtain call pattern encoding, enabling effective conversion from high-dimensional sparse raw data to low-dimensional dense semantic vectors, extracting essential call behavior features that are robust to noise and easy to compare. Anomaly scores are calculated based on the call pattern encoding and a preset memory, enabling anomaly quantification based on normal pattern comparison. By replacing static rules with dynamic benchmarks, the detection model gains adaptability to behavioral evolution. Based on the anomaly scores, a judgment result is obtained, outputting a clear detection conclusion and providing a reliable basis for subsequent handling decisions. Thus, real-time anomaly detection of telecommunications call events is achieved, effectively solving the problems of lagging updates and insufficient feature modeling capabilities in traditional methods.

[0147] Figure 11 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0148] The electronic device may include a processor 601 and a memory 602 storing computer program instructions.

[0149] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0150] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0151] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0152] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the business intent parsing methods in the above embodiments.

[0153] In one example, the electronic device may also include a communication interface 603 and a bus 610. For example, Figure 11 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0154] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0155] Bus 610 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0156] Furthermore, in conjunction with the business intent parsing methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the business intent parsing methods in the above embodiments.

[0157] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the business intent parsing methods described in the above embodiments.

[0158] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0159] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0160] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0161] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for parsing business intent, characterized in that, include: Obtain multi-source business data of the business object, and fill the business attribute fields corresponding to the preset structure intent template based on the multi-source business data to obtain a set of candidate fields for each business attribute field; The comprehensive confidence level of each candidate field is calculated based on a preset multidimensional evaluation index. The preset multidimensional evaluation index includes at least two of the following: source reliability index, semantic matching index, and historical consistency index. Based on the comprehensive confidence level of each candidate field, conflicting fields, elimination fields, and accepted fields are determined from the candidate field set of all business attribute fields. The accepted fields are used to populate the corresponding business attribute fields, the conflicting fields are used to be retained in the corresponding business attribute fields, and the elimination fields are used to be removed from the candidate field set of the corresponding business attribute fields. Based on the accepted and conflicting fields of all business attribute fields, generate the structural intent information of the business object.

2. The method according to claim 1, characterized in that, Based on the comprehensive confidence level of each candidate field, conflicting fields, exclusion fields, and accepted fields are determined from the candidate field set of all business attribute fields, including: For each business attribute field's candidate field set, calculate the difference between the highest and second-highest comprehensive confidence scores, and use it as a reference value for judgment; When the judgment reference value is greater than or equal to the preset judgment threshold, the candidate field corresponding to the highest comprehensive confidence level is determined as the accepted field; When the judgment reference value is less than the preset judgment threshold, the candidate fields in the candidate field set are sorted in descending order according to the comprehensive confidence level to obtain the candidate field sequence. Candidate fields in the candidate field sequence whose overall confidence level is lower than the preset confidence lower limit are identified as the fields to be eliminated. Candidate fields in the candidate field sequence whose overall confidence level is greater than or equal to the preset confidence lower limit are identified as conflicting fields.

3. The method according to claim 2, characterized in that, After determining the candidate fields in the candidate field sequence whose overall confidence level is greater than or equal to the preset confidence lower limit as the conflicting fields, the method further includes: Generate conflict cause labels for the conflict field, wherein the conflict cause labels include at least one of the following: confidence gap too small, source conflict, or semantic contradiction.

4. The method according to claim 2, characterized in that, When the judgment reference value is greater than or equal to the preset judgment threshold, the candidate field corresponding to the highest comprehensive confidence level is determined as the accepted field, including: The candidate field with the highest overall confidence level in the candidate field set is determined as the accepted field; or... When there are multiple highest values ​​with the same overall confidence level in the candidate field set, the accepted field is determined from the candidate fields corresponding to the multiple highest values ​​based on the data source priority of the candidate fields.

5. The method according to claim 1, characterized in that, After generating the structural intent information of the business object based on the accepted and conflicting fields of all business attribute fields, the following is also included: Identify business attribute fields that are missing in the preset structural intent template; Based on the accepted fields of the business object and the preset field association rules, the business attribute fields that are in a missing state are inferred to obtain the inferred fields; The structural intent information is completed based on the inferred fields.

6. The method according to claim 5, characterized in that, The method involves inferring missing business attribute fields based on the accepted fields of the business object and preset field association rules, resulting in inferred fields, including: Construct a field association graph for the business object, the field association graph including the association relationships and association strengths between the confirmed and accepted fields; Based on the field association graph, query the accepted fields that are associated with the business attribute fields that are in a missing state, and use them as the inference basis fields; Based on the inference criteria field and the corresponding association strength, calculate the inference confidence of the inference field; When the inference confidence level is greater than the preset inference threshold, the inference field is filled into the business attribute field that is in a missing state.

7. The method according to claim 1, characterized in that, The comprehensive confidence level of each candidate field is calculated based on a preset multidimensional evaluation index, including: For each candidate field, the source reliability index, the semantic matching index, and the historical consistency index are calculated respectively. Based on the preset weights corresponding to each indicator, the source reliability indicator, the semantic matching degree indicator, and the historical consistency indicator are weighted and calculated to obtain the comprehensive confidence level. The source reliability index is determined based on the data source type of the candidate field, the semantic matching index is determined based on the semantic similarity between the candidate field and the corresponding business attribute field, and the historical consistency index is determined based on the degree of matching between the candidate field and historically confirmed data.

8. The method according to claim 1, characterized in that, The process of filling the business attribute fields corresponding to the preset structure intent template based on the multi-source business data yields a candidate field set for each business attribute field, including: Entity identification and relationship extraction are performed on the multi-source business data to obtain business entities and their associated relationships; Perform attribute mapping on the business entity to obtain candidate attribute values ​​corresponding to the business attribute fields; Based on the aforementioned association, the candidate attribute values ​​are validated in context, and candidate attribute values ​​that do not conform to the contextual logic are excluded. The verified candidate attribute values ​​are used as the candidate fields, and the candidate field set is obtained based on all candidate fields.

9. A device for parsing business intent, characterized in that, The device includes: The acquisition unit is used to acquire multi-source business data of the business object, and fill the business attribute fields corresponding to the preset structure intent template based on the multi-source business data to obtain a set of candidate fields for each business attribute field. The first processing unit is used to calculate the comprehensive confidence level of each candidate field based on a preset multidimensional evaluation index. The preset multidimensional evaluation index includes at least two of the following: source reliability index, semantic matching index, and historical consistency index. The second processing unit is used to determine conflicting fields, elimination fields, and accepted fields from the candidate field set of all business attribute fields based on the comprehensive confidence level of each candidate field. The accepted fields are used to fill the corresponding business attribute fields, the conflicting fields are used to be retained in the corresponding business attribute fields, and the elimination fields are used to be removed from the candidate field set of the corresponding business attribute fields. The third processing unit is used to generate the structural intent information of the business object based on the accepted fields and conflict fields of all business attribute fields.

10. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the method for parsing business intent as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the parsing of the business intent as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the method for parsing the business intent as described in any one of claims 1 to 8.

Images