A post-call interactive diagnostic service optimization method and related products

Abstract

The application discloses a method for optimizing a post-call interactive diagnosis service and related products, which comprises the following steps: extracting semantic slots from a call recording, matching the semantic slots with knowledge side nodes to obtain a matching result; establishing an alignment edge with an initial weight between the semantic slots and the knowledge side nodes according to the matching result, and constructing a semantic alignment graph based on the alignment edge; generating a diagnosis card based on the semantic slots and the semantic alignment graph, and pushing the diagnosis card to a user terminal; calculating a path deviation vector based on interactive behavior data, the call recording and the diagnosis card; and feedback correcting the weight of the alignment edge in the semantic alignment graph based on the path deviation vector and the interactive behavior data, to obtain a corrected semantic alignment graph. The application feedback corrects the weight of the alignment edge based on the path deviation vector, so that correct alignment is positively reinforced and incorrect alignment naturally decays, and the technical defect that a static knowledge base cannot evolve by itself is overcome, and the application can be self-adaptively optimized without manual intervention.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for optimizing interactive diagnostic services after a call and related products. Background Technology

[0002] In post-call customer service scenarios, users are often driving or in a hurry. During the call, agents verbally provide multi-step troubleshooting instructions. After hanging up, when users try to replicate the process from memory, they frequently miss steps or get the order wrong, leading to failure. Existing solutions often use static image / text tutorial links to remedy this, but these tutorials are generic and lack a direct correlation with the specific context of the call. Users still need to manually match the call memory with generic documentation, resulting in a low success rate for reproducing the issue.

[0003] Meanwhile, existing systems can only record the tutorial push status and user open rate, but cannot obtain information on the actual steps the user has taken or where they got stuck during the actual operation; in other words, failure points are unobservable. When users call repeatedly, customer service can only inquire about the fault details and the operations already performed, leading to users repeatedly describing the same problem, resulting in a poor service experience and low agent efficiency. Furthermore, traditional service quality measurements rely on questionnaires sent separately after the call, with extremely low completion rates. There is no necessary correlation between user satisfaction ratings and whether their problems have actually been resolved; users may give high scores because of a friendly agent even if the problem is not solved, or they may give low scores even if the problem is solved but the process is cumbersome. There is a lack of mutual verification between satisfaction data, repeat call rates, and knowledge base quality, leaving knowledge optimization without data support. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method for optimizing post-call interactive diagnostic services and related products.

[0005] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a method for optimizing post-call interactive diagnostic services, the method comprising: Semantic slots are extracted from call recordings and matched with knowledge-side nodes to obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes. Based on the matching result, an alignment edge with initial weight is established between the semantic slot and the knowledge-side node, and a semantic alignment graph is constructed based on the alignment edge. A diagnostic card is generated based on the semantic slot and the semantic alignment graph, and the diagnostic card is pushed to the user terminal; Based on the interactive behavior data, the call recording, and the diagnostic card, a path deviation vector is calculated; the interactive behavior data is obtained by collecting the user's step-level operations on the diagnostic card. Based on the path deviation vector and the interaction behavior data, the weights of the alignment edges in the semantic alignment graph are corrected by feedback to obtain a corrected semantic alignment graph.

[0006] A second aspect of this application provides a post-call interactive diagnostic service optimization apparatus, the post-call interactive diagnostic service optimization apparatus comprising: The matching module is used to extract semantic slots from call recordings, match the semantic slots with knowledge-side nodes, and obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes. A module is established to create an alignment edge with initial weights between the semantic slot and the knowledge-side node based on the matching result, and to construct a semantic alignment graph based on the alignment edge. The generation module is used to generate diagnostic cards based on the semantic slots and the semantic alignment graph, and push the diagnostic cards to the user terminal; The calculation module is used to calculate the path deviation vector based on the interaction behavior data, the call recording, and the diagnostic card; the interaction behavior data is obtained by collecting the user's step-level operations on the diagnostic card; The correction module is used to perform feedback correction on the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data, so as to obtain a corrected semantic alignment graph.

[0007] A third aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the post-call interactive diagnostic service optimization method provided in the first aspect.

[0008] Compared with the prior art, this application has the following advantages: This application includes extracting semantic slots from call recordings, matching the semantic slots with knowledge-side nodes to obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes; establishing alignment edges with initial weights between the semantic slots and the knowledge-side nodes based on the matching results, and constructing a semantic alignment graph based on the alignment edges; generating diagnostic cards based on the semantic slots and the semantic alignment graph, and pushing the diagnostic cards to the user terminal; calculating a path deviation vector based on interaction behavior data, the call recordings, and the diagnostic cards; the interaction behavior data is obtained by collecting the user's step-level operations on the diagnostic cards; and performing feedback correction on the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data to obtain a corrected semantic alignment graph.

[0009] This application extracts semantic slots from call recordings, matches these slots with knowledge-side nodes that include at least knowledge base entry nodes, diagnostic step nodes, and agent dialogue nodes, and establishes alignment edges with initial weights between the semantic slots and knowledge-side nodes based on the matching results, forming a semantic alignment graph. Diagnostic cards are generated based on the semantic slots and the semantic alignment graph and pushed to the user's terminal. These steps constitute a complete compilation chain from a call to a personalized card. Since the semantic slots are directly derived from the call recording, and the semantic alignment graph establishes a computable association between the specific expressions in the call and the background knowledge resources, the generated diagnostic cards are not generic static tutorials, but rather personalized step sequences corresponding to the specific context of the call. The card content received by the user after hanging up is the operation guidance directly corresponding to the content of the call, eliminating the need for manual matching between call memory and general documents. This reduces the user's cognitive burden and the difficulty of operation reproduction, overcoming the technical shortcomings of static generic tutorials being disconnected from the call context and having a low success rate of reproduction in the prior art.

[0010] This application further collects user step-by-step operations on the diagnostic card to obtain interactive behavior data, and calculates a path deviation vector based on the interactive behavior data, call recordings, and the diagnostic card. Since the interactive behavior data is step-by-step, every user action, such as confirmation, pause, backtracking, and jumping, is recorded. The path deviation vector reflects the difference between the user's actual operation trajectory and the expected path. Therefore, it can automatically locate where the user deviated or got stuck, without requiring the user to actively describe it or customer service to ask again during repeat calls. Failure nodes automatically emerge, overcoming the technical shortcomings of the background technology, such as unobservable failure nodes, poor experience with repeat calls, and low agent efficiency. Simultaneously, the interactive behavior data is a natural behavioral trace generated by the user during the operation to solve actual problems. It is objective data generated in a task-driven, stress-free situation, rather than a satisfaction questionnaire filled out separately after the call. The path deviation vector reflects both whether the user successfully completed all steps and whether there were any pauses or confusions during the process, thus unifying satisfaction and resolution rate within the same measurement framework. This overcomes the technical shortcomings of the background technology, such as the lack of mutual verification between satisfaction scores and whether the problem was truly solved, and the lack of targeted knowledge optimization.

[0011] This application also uses path deviation vectors and interaction behavior data to provide feedback correction to the weights of alignment edges in the semantic alignment graph, resulting in a corrected semantic alignment graph. Since the weights of alignment edges directly affect the matching quality of semantic slots and knowledge-side nodes in subsequent calls, as well as the generation and ranking of diagnostic paths, the path deviation vectors and interaction behavior data act as feedback signals from actual user operations, inversely affecting the structural parameters of the alignment graph. This allows the system to continuously optimize matching accuracy and path rationality in real-world use. Correct alignments are positively reinforced by the user successfully completing the entire process, while incorrect alignments are naturally attenuated by frequent user stumbles. This achieves adaptive adjustment of semantic mapping relationships without manual intervention, overcoming the technical shortcomings of the static knowledge base mapping structure in the background technology, which is frozen once constructed and cannot self-evolve based on actual usage effects. Attached Figure Description

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

[0013] Figure 1 A flowchart illustrating an optimization method for post-call interactive diagnostic services provided in this application embodiment; Figure 2 This is a schematic diagram of the semantic alignment graph structure provided in this application; Figure 3 A flowchart was generated for the diagnostic path provided in this application; Figure 4 This is a schematic diagram of the three-terminal differentiated rendering state machine provided in this application; Figure 5 This application provides a schematic diagram of the interface of an engineering embodiment. Figure 6 The knowledge evolution closed-loop evidence chain diagram provided for this application; Figure 7 The feedback correction schematic diagram provided for this application; Figure 8 The full-link cross-system swimlane diagram for post-call service verification provided in this application; Figure 9 The topology diagram of the customer service call verification system provided for this application; Figure 10 Overall architecture diagram of the customer service call post-call interactive diagnostic service verification method provided in this application; Figure 11 This is a structural diagram of a post-call interactive diagnostic service optimization device provided in an embodiment of this application. Detailed Implementation

[0014] As described earlier, in post-call customer service scenarios, users often miss steps or get confused about the order of instructions when trying to recall them from memory after hanging up. Existing solutions often push static text and image tutorials, but the content lacks a direct correspondence with the context of the call, requiring users to manually match the information, resulting in a low success rate. Current systems can only record the push status and open rate, failing to track the user's progress or where they got stuck. Failure points are unobservable, and customer service representatives have to ask again when the call is repeated, leading to a poor experience and low efficiency. Traditional satisfaction measurement relies on post-call questionnaires, which have low completion rates and no necessary correlation between ratings and actual problem resolution. There is a lack of mutual verification between satisfaction data, repeat call rates, and knowledge base quality, hindering knowledge optimization.

[0015] In view of the above problems, this application provides a method and related products for optimizing interactive diagnostic services after a call. The method includes: extracting semantic slots from the call recording; matching the semantic slots with knowledge-side nodes to obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes; establishing alignment edges with initial weights between the semantic slots and the knowledge-side nodes according to the matching results, and constructing a semantic alignment graph based on the alignment edges; generating a diagnostic card based on the semantic slots and the semantic alignment graph, and pushing the diagnostic card to the user terminal; calculating a path deviation vector based on interaction behavior data, the call recording, and the diagnostic card; the interaction behavior data is obtained by collecting the user's step-level operations on the diagnostic card; and performing feedback correction on the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data to obtain a corrected semantic alignment graph.

[0016] This application extracts semantic slots from call recordings and constructs a semantic alignment graph. Based on this, it generates personalized diagnostic cards corresponding to the call context, replacing general static tutorials, reducing the user's memory burden, and overcoming the problems of tutorials being disconnected from context and low success rate of reproduction. This application collects user step-by-step operation behaviors, calculates path deviation vectors in conjunction with call recordings, automatically locates failure nodes, and unifies satisfaction and resolution rates, overcoming the shortcomings of unobservable failure nodes and the disconnect between satisfaction and resolution rates. This application uses path deviation vector feedback to correct alignment edge weights, so that correct alignment is positively reinforced and incorrect alignment is naturally decayed. It can adaptively optimize without manual intervention, overcoming the technical shortcomings of static knowledge bases that cannot self-evolve.

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

[0018] Figure 1 A flowchart illustrating a post-call interactive diagnostic service optimization method provided in this application embodiment is shown below. Figure 1 As shown, a method for optimizing post-call interactive diagnostic services includes: S101: Extract semantic slots from the call recording, match the semantic slots with knowledge-side nodes, and obtain matching results.

[0019] In this implementation, after the customer service representative ends the call with the user, the recorded data of the call is automatically acquired. The Automatic Speech Recognition (ASR) module is invoked to convert the customer service recording into a transcript. Natural Language Processing (NLP) technology is used to perform semantic analysis on the transcript to extract semantic slots. Semantic slots are structured representations of key information in the call, including at least the types of user-attempted actions, fault symptoms, preconditions for the action, and customer service troubleshooting suggestions. For example, when the user says, "I pressed remote start, but the car didn't respond," "remote start" is extracted as the "action performed" semantic slot, and "the car didn't respond" is extracted as the "fault data" semantic slot. The extracted semantic slots are then matched one-to-one with pre-built knowledge-side nodes.

[0020] Knowledge-side nodes are semantic representations of backend knowledge resources, comprising at least three types of nodes: knowledge base entry nodes, used to describe knowledge-based content such as function descriptions and problem definitions; diagnostic step nodes, used to describe standardized troubleshooting procedures; and agent script nodes, used to record the colloquial expression templates of historically successful agents. During the matching process, the text content of each semantic slot is compared with the text content of each knowledge-side node to calculate the similarity, resulting in a matching result that reflects the correspondence and degree of matching between the semantic slot and each knowledge-side node. By automatically converting unstructured call recordings into structured semantic slots and matching them with the three types of knowledge-side nodes, a computable mapping from call semantics to backend knowledge resources is achieved. This provides a data foundation for the subsequent generation of personalized diagnostic cards, overcoming the limitation of traditional solutions where call content cannot be automatically understood by the system.

[0021] S102: Based on the matching result, establish an alignment edge with initial weight between the semantic slot and the knowledge side node, and construct a semantic alignment graph based on the alignment edge.

[0022] In this embodiment, based on the matching results described above, this application establishes alignment edges between semantic slots and knowledge-side nodes. Each alignment edge represents the association between a semantic slot and a knowledge-side node. Each alignment edge is assigned an initial weight, which reflects the reliability of the association; a higher weight indicates a more reliable match between the semantic slot and the knowledge-side node. This application aggregates all alignment edges established during this call to form a semantic alignment graph. This semantic alignment graph is a directed graph structure, where semantic slots and knowledge-side nodes are nodes, and alignment edges are edges connecting nodes. The semantic alignment graph is temporarily constructed specifically for this call, created upon call instantiation and released upon service termination. However, the weights of the alignment edges are accumulated after feedback and correction, and can be reused in subsequent calls. For example, in a call about "remote start failure," this application established an alignment edge for "remote start (semantic slot) → remote start function description (knowledge base entry node)" with a weight of 0.88; an alignment edge for "remote start (semantic slot) → troubleshooting the cause of start failure (diagnostic step node)" with a weight of 0.66; and an alignment edge for "customer service suggestion to check battery level (semantic slot) → excellent agent script (agent script node)" with a weight of 0.68. These three alignment edges together constitute the semantic alignment graph of this call. By establishing alignment edges between semantic slots and knowledge-side nodes and constructing a semantic alignment graph, a computable association is established between the specific statements in the call and the background knowledge resources. This allows this application to understand "what the user said" and "which background knowledge should correspond to," providing a structured semantic mapping foundation for subsequent diagnostic path generation.

[0023] S103: Generate a diagnostic card based on the semantic slot and the semantic alignment graph, and push the diagnostic card to the user terminal.

[0024] In this embodiment, this application generates diagnostic cards based on the aforementioned semantic slots and semantic alignment graph. The diagnostic card is a sequence of steps combining text and graphics, where each step includes operation instructions, estimated time, and a confirmation button. After the diagnostic card is generated, this application sends it to the user terminal via a push channel. The user terminal can be a mobile app, a mini-program, or a vehicle infotainment screen. The key points of the verbal instructions given by the agent during the call are automatically compiled into personalized diagnostic cards and pushed to the user. The content of the diagnostic card directly corresponds to the specific context of the call, rather than a generic static tutorial. Users do not need to manually match the call memory with general documents, reducing memory burden and difficulty in reproducing operations. This overcomes the technical shortcomings of static tutorials being disconnected from the call context and having a low success rate of reproduction.

[0025] S104: Calculate the path deviation vector based on the interaction behavior data, the call recording, and the diagnostic card.

[0026] In this embodiment, after receiving the diagnostic card, the user begins to operate step by step. This application continuously collects step-by-step interaction data of the user on the diagnostic card in the background. The interaction data is obtained by collecting the user's step-by-step operations on the diagnostic card. For the mini-program, the interaction data is first temporarily stored in the user's local storage and then uploaded to the server in batches when network conditions permit. After obtaining the interaction data, this application calculates a path deviation vector by combining the call recording and the content of the diagnostic card to quantify the difference between the user's actual operation trajectory and the expected path. For example, if the user confirms in 5 seconds for each of the first two steps, but stays for 90 seconds and goes back twice in the third step "reissue command", then the clarity deviation and confusion deviation of the third step are marked as high values, and this application determines that the user is stuck in the third step. By collecting step-by-step interactive behaviors and calculating path deviation vectors, this application can automatically locate where the user deviated or got stuck, without requiring the user to actively describe the situation or customer service to ask again during repeat calls. Failure nodes automatically emerge, overcoming the technical shortcomings of traditional solutions such as unobservable failure nodes, poor experience with repeat calls, and low agent efficiency. At the same time, interactive behavior data is a natural behavioral trace generated by users to solve actual problems, and its authenticity and objectivity are superior to subjective questionnaire data.

[0027] S105: Based on the path deviation vector and the interaction behavior data, the weights of the alignment edges in the semantic alignment graph are corrected by feedback to obtain the corrected semantic alignment graph.

[0028] In this embodiment, based on the aforementioned path deviation vector and interaction behavior data, this application provides feedback correction to the weights of the alignment edges in the semantic alignment graph. This application does not update the weights immediately after a single interaction, but instead accumulates a preset number of interaction behavior data (e.g., 30 times) using a sliding window approach before performing a unified correction. For each interaction within the sliding window, this application calculates a behavior score s. The behavior score s is composed of three weighted factors: user confirmation rate (weight 50%), completion time achievement rate (weight 30%), and rollback rate (weight 20%, the fewer rollbacks, the higher the score). This application uses an exponential moving average method to update the alignment edge weights. This update method ensures that the old weights account for 80% and the new scores account for 20%, absorbing new interaction experience without overturning long-accumulated weights due to a single accidental error. Simultaneously, the confidence level of the slot position corresponding to the alignment edge is also adjusted in a synchronized manner: new confidence level = 0.9 × old confidence level + 0.1 × new score.

[0029] If the weight of an alignment edge remains below 0.2 for three consecutive sliding windows and does not recover, this application marks the alignment edge as a "degenerate alignment edge," automatically triggering a work order to remind knowledge operations personnel to review it. After feedback correction, this application outputs a corrected semantic alignment graph. For example, initially, the weight of the incorrect alignment edge is 0.68 and the weight of the correct alignment edge is 0.45. After six rounds of feedback correction through sliding windows, the weight of the correct alignment edge gradually increases to 0.72 due to frequent user confirmations, while the weight of the incorrect alignment edge naturally decreases to 0.31 due to frequent user stumbles. The correct edge surpasses the incorrect edge, and the sorting is automatically corrected. By introducing a feedback correction mechanism based on actual user interaction behavior, the weight of the alignment edge can be continuously optimized according to the actual usage effect. The correct alignment is positively strengthened because the user successfully completes the process, and the incorrect alignment is naturally decreased due to frequent user stumbles. The semantic mapping relationship can be adaptively adjusted without manual intervention, overcoming the technical defect that the static knowledge base mapping structure is frozen once built and cannot evolve itself according to actual usage effects.

[0030] The above describes the main technical solution of this application. Further implementations of the main technical solution are now introduced. Details are as follows: Regarding S102, which establishes an alignment edge with initial weights between the semantic slot and the knowledge-side node based on the matching result, this application provides an optional embodiment: In this embodiment, the process of establishing alignment edges and assigning initial weights between semantic slots and knowledge-side nodes employs a hierarchical matching strategy. For example, this application calculates the literal similarity *I* and semantic similarity *sem* between the text of the semantic slot and the text of the knowledge-side node. The literal similarity *I* is calculated using edit distance: the minimum number of editing operations (insertion, deletion, replacement) required to change the text of the semantic slot to the text of the knowledge-side node is counted, divided by the length of the longer string, and then 1 is subtracted from this ratio. For example, the edit distance between "remote start" and "remote start" is 1, and the length of the longer string is 4, so *I* = 1 - 1 / 4 = 0.75. The semantic similarity *sem* is obtained by inputting the two texts into a pre-trained semantic model (such as Sentence-BERT) to obtain semantic vectors, and then calculating the cosine similarity between the two vectors. For example, "car not responding" and "starting failed" are semantically similar in the context of car malfunction, and *sem* can reach 0.85.

[0031] Specifically, when the literal similarity between the text of the semantic slot and the text of the knowledge side node in the matching result is greater than or equal to a first threshold (e.g., 0.9), it enters the first matching channel and calculates the initial alignment confidence using the formula c0=α×I+β×sem+γ.

[0032] When the literal similarity is less than the first threshold and the semantic similarity between the text of the semantic slot and the text of the knowledge side node in the matching result is greater than or equal to the second threshold (e.g., 0.75), the second matching channel is entered, and the initial alignment confidence is calculated according to the formula c0=δ×sem.

[0033] An alignment edge is established between the semantic slot and the knowledge-side node, and the initial alignment confidence is assigned as the initial weight of the alignment edge; where c0 is the initial alignment confidence; sem is the semantic similarity between the text of the semantic slot and the text of the knowledge-side node; α, β and γ are all preset weight coefficients, for example α=0.7, β=0.2, γ=0.1; δ is a preset discount coefficient, for example δ=0.8.

[0034] The values ​​of α, β, γ, δ, as well as the first and second thresholds, can all be determined through offline calibration: business experts mark thousands of "user statements - knowledge base entries" from historical calls to see if they are correctly aligned, and use grid search to find the optimal combination of α, β, and γ in the first matching interval and the optimal combination of δ in the second matching interval, so as to control the false alarm rate to within 20%. After the target is met, the coefficients are frozen and put online.

[0035] The confidence level of the semantic slot itself is obtained by multiplying the confidence level of speech recognition and the confidence level of natural language processing extraction; the confidence level of the knowledge-side node is obtained based on the resolution rate and backtracking rate of the node in historical calls; the initial weight of the alignment edge is jointly determined by the confidence level of the semantic slot, the confidence level of the knowledge-side node, and the matching quality. Through a hierarchical matching strategy (exact matching and fuzzy matching) and a quantified weight calculation formula, an objective measurement of the matching degree between the semantic slot and the knowledge-side node is achieved; the first matching channel uses literal similarity as hard evidence to ensure high-credibility matching, while the second matching channel uses semantic similarity to handle synonymous expressions. The two complement each other, making the initial weight of the alignment edge both accurate and comprehensive.

[0036] Figure 2 This is a schematic diagram of the semantic alignment graph structure provided in this application, such as... Figure 2 As shown, the semantic alignment graph is a bipartite graph structure, with the left side being the semantic nodes (source nodes) on the call side and the right side being the knowledge side nodes. The lines connecting the left and right nodes are the alignment edges. Figure 2 Specifically, it shows the matching relationship between semantic slots and three types of knowledge-side nodes, node confidence, literal similarity and semantic similarity parameters, the weight calculation formulas for the two matching channels, and the initial weight assignment method for the aligned edges.

[0037] The semantic nodes on the call side consist of semantic slots extracted from the call recording. Each semantic node is labeled with a semantic slot type and a node confidence C(s). Figure 2Three semantic nodes are shown as an example: Remote start (the user has attempted to perform the operation, node confidence C(s) = 0.92) indicates that the system has a confidence level of 0.92 for the semantic slot of remote start extracted from the call; The vehicle does not respond (fault phenomenon, node confidence C(s) = 0.88), indicating that the system's confidence level for this fault phenomenon slot is 0.88; You first check the battery level (customer service suggestion, node confidence level C(s)=0.85), indicating that the system's confidence level for this customer service troubleshooting suggestion slot is 0.85.

[0038] The node confidence C(s) is obtained by multiplying the ASR identification confidence and the NLP extraction confidence. A low confidence in either ASR or NLP will lead to a decrease in the node confidence.

[0039] Knowledge-side nodes include at least three types of knowledge nodes: The first is the knowledge base entry node, which is used to describe knowledge-based content such as function descriptions and problem definitions. Figure 2 Four knowledge base entry nodes are shown as an example, each labeled with literal similarity I and semantic similarity sem: Node 1 (I=0.95, sem=0.98), Node 2 (I=0.40, sem=0.85), Node 6 (I=0.25, sem=0.76), and Node 5 (I=0.35, sem=0.80).

[0040] The second is the diagnostic step node, which describes the standardized investigation operation process. Figure 2 Three diagnostic step nodes are illustrated as an example, each labeled with literal similarity I and semantic similarity sem: Node 3 (I=0.30, sem=0.88) and Node 4 (I=0.45, sem=0.82). Figure 2 Two diagnostic step nodes are illustrated as examples: "Remote Startup Troubleshooting Startup Failure" (including sub-steps "Check Battery Level → Confirm Network → Resend", historical pass rate 88%) and "Detect Vehicle Battery Level" (including sub-steps "Check Battery Level → Charge If Necessary", historical pass rate 85%). Next to each diagnostic step node is annotated with the formulas for calculating the exact matching weight (i.e., the first matching channel): w = 0.7 × I + 0.2 × sem + 0.1 (condition: I ≥ 0.9) and the formula for calculating the fuzzy matching weight (i.e., the second matching channel): w = 0.8 × sem (condition: I < 0.9 and sem ≥ 0.75).

[0041] The third is the call center script node, which is used to record the colloquial expression templates of outstanding call center agents in history. Figure 2An example of a call center script node is shown, with the text "Please first check if the vehicle battery has sufficient power, then check the connection status. If it still cannot start, we can reissue the command for you." The historical pass rate is 90%.

[0042] The connection between the semantic node on the call side and the knowledge node on the knowledge side is the alignment edge, and the alignment edge is labeled with an initial weight w. Figure 2 The right side of the middle section is labeled to distinguish two matching types (interval graph): exact matching edges (when the literal similarity I ≥ 0.9, the weight is calculated according to the formula w = 0.7 × I + 0.2 × sem + 0.1) and fuzzy matching edges (when the literal similarity I < 0.9 and the semantic similarity sem ≥ 0.75, the weight is calculated according to the formula w = 0.8 × sem). Figure 2 In the process, the semantic node "remote start" on the call side and knowledge base entry node 1 are aligned by exact matching (I=0.95≥0.9), with an initial weight w=0.7×0.95+0.2×0.98+0.1≈0.96; the semantic node "car not responding" on the call side and the diagnostic step node "remote start troubleshooting start failure" are aligned by fuzzy matching (I<0.9 and sem≥0.75), with an initial weight w=0.8×sem≈0.70; the semantic node "please check battery level first" on the call side and the agent's script node are aligned by fuzzy matching, with an initial weight w=0.8×sem≈0.66. Figure 2 The relationship path from the call-side node confidence C(s) to the initial weight of the alignment edge is also shown. The call-side node confidence and the knowledge-side node confidence (based on historical pass rate) jointly participate in the determination of the initial confidence of the alignment edge.

[0043] Regarding S103 generating diagnostic cards based on the semantic slots and the semantic alignment graph, this application provides an optional embodiment: In this embodiment, the specific process of generating diagnostic cards based on semantic slots and semantic alignment graphs is as follows. Semantic slots include at least three categories: operated data, fault data, and preset troubleshooting data. Operated data records operations that the user has described attempting during the call, such as "I pressed remote start" or "I restarted the app." Fault data records the fault symptoms described by the user, such as "The car isn't responding" or "The car door won't open." Preset troubleshooting data records troubleshooting suggestions given by customer service during the call, such as "Please check your battery level first" or "Please check your network connection."

[0044] Specifically, based on the semantic alignment graph, the corresponding basic process template is retrieved from the preset standard troubleshooting process template library; for example, if the semantic alignment graph confirms that the user is inquiring about the "remote start failure" problem, then the basic process template for "remote start failure troubleshooting" is retrieved.

[0045] When the processed data matches any step in the basic process template, the step is marked as executed and skipped to obtain the adjusted process template; for example, if the user says "I have already restarted the APP", the "restart the APP" step in the template is marked as skipped.

[0046] Determine the troubleshooting steps corresponding to the fault data (such as additional troubleshooting operations required for the fault phenomenon), and insert the troubleshooting steps into the adjustment process template to obtain the insertion process template; for example, if the fault data is "the car is not responding", this application retrieves the troubleshooting step "check if the vehicle is in P gear" from the knowledge base and inserts it after the "check battery level" step.

[0047] Based on the preset investigation data (such as the order and importance of each step verbally emphasized by customer service during the call), the priority weight of each step in the inserted process template is determined, and each step in the inserted process template is sorted according to the priority weight (such as the earlier the customer service mentions the step or the more it is emphasized, the higher the priority weight), and a diagnostic path is generated. The diagnostic path is used as the content of the diagnostic card; the diagnostic card is the sequence of steps in the call recording.

[0048] Figure 3 Generate a flowchart for the diagnostic path provided in this application, such as Figure 3 As shown, Figure 3 As shown, the diagnostic path generation process includes four steps: skeleton selection (Step 1), attempted skipping (Step 2), phenomenon insertion (Step 3), and weight sorting (Step 4), ultimately outputting a personalized diagnostic path P.

[0049] Step 1 Skeleton Selection: This application determines the type of user's service request based on the direction and weight of the alignment edge in the semantic alignment graph, and retrieves the corresponding basic process template from the preset standard screening process template library. Figure 3 For example, "remote startup failed" is used as the service request type, and the basic process template of "investigating the cause of startup failure" is retrieved.

[0050] Step 2 Skipped: This application compares the user's action data contained in the semantic slots with each step in the basic process template. When the user describes a step they have already tried during the call that matches a step in the template, the step is marked as "executed" and skipped, and will no longer appear in the diagnostic card, thus preventing the user from repeatedly executing steps they have already performed.

[0051] Step 3 Phenomenon Insertion: This application determines the corresponding troubleshooting steps based on the fault data in the semantic slots and inserts these troubleshooting steps after the relevant operation steps in the adjusted process template to ensure that specific troubleshooting steps for the user's specific fault phenomena are included in the diagnostic path.

[0052] Step 4: Weighting and Ranking: This application prioritizes each step based on the order and importance emphasized verbally by customer service representatives during the call, combined with pre-defined investigation data, and then rearranges the step order. The comprehensive scoring function for step ranking is: score(n) = α×w score (n) + (1-α)×p score (n), where score(n) is the overall score for step n (the higher the score, the earlier the step appears), w score (n) is a weighting function based on the customer service emphasis order and preset investigation data (higher weight means earlier), p score (n) is a probability function based on the historical pass rate or priority of the steps (the higher the priority, the earlier it appears), and α is a preset weight coefficient used to adjust the relative importance between the customer service emphasis order and the historical pass rate of the steps. Figure 3 In this case, α takes the value of 0.6, and the range of α is from 0.5 to 0.7.

[0053] Figure 3 The bottom section uses "Remote start failure" as an example to illustrate the personalized diagnostic path P output after the above four steps. The skeleton selects and retrieves the basic template "Troubleshooting start failure"; steps already attempted to be skipped (assuming the user did not mention attempting any steps during the call (such as checking the network or battery level), therefore no steps are skipped); the symptom insertion steps insert troubleshooting steps such as "Troubleshooting start failure" based on the fault symptom "car not responding"; the weighted sorting steps arrange the steps according to the order emphasized by the customer service representative during the call: "Check battery level → Check network → Troubleshoot start failure → Reissue command → Confirm resolution". This step sequence is the final output personalized diagnostic path P.

[0054] When users call customer service while driving or in a hurry, the agent verbally guides them through multiple troubleshooting steps. After hanging up, users often only remember the first or last step, with the order of the intermediate steps confused. The diagnostic card automatically compiles the key points of the agent's verbal guidance into a personalized sequence of steps and pushes it to the user. Each time the user completes a step and clicks "confirm," if they get stuck at a step and time out or retry, the application automatically collects these actions and locates the failure point. Through a four-step process of "retrieving the basic template → skipping already performed steps → inserting troubleshooting steps → sorting according to the order emphasized by the agent," the generated diagnostic card fully integrates personalized information from the call. This avoids requiring users to repeat already performed operations, supplements specific troubleshooting steps for specific fault symptoms, and retains the order of verbal emphasis by the agent during the call. This ensures that the diagnostic card highly matches the context of the call, improving user efficiency and the success rate of reproducing the problem.

[0055] Regarding the step of S103, which involves pushing the diagnostic card to the user terminal, this application provides an optional embodiment: In this embodiment, when pushing the diagnostic card to the user terminal, a differentiated push strategy is adopted according to different terminal types. The terminal rendering engine in this application executes the differentiated strategy according to the terminal type, as follows: When the user terminal is a mobile application (such as the OnStar APP), the diagnostic card is pushed in real time via a long-connection channel. The APP pre-integrates the MQTT SDK, supporting real-time message delivery from the server to the client. The diagnostic card arrives on the user's mobile phone immediately after generation, with a push latency typically in the millisecond range. The APP is not subject to driving safety constraints and supports full-featured interaction, including step-by-step confirmation, image and text viewing, and video playback. The APP utilizes MQTT long-connections to achieve step-level real-time status synchronization, with the status reported immediately after the user completes each step.

[0056] When the user terminal is a mini-program, the diagnostic card is pushed via API polling. Due to the limitations of the mini-program's runtime environment, long connections cannot be maintained; therefore, this application pushes the diagnostic card via HTTPS API polling. The mini-program sends a polling request to the server every certain period of time (e.g., 2 seconds) to obtain the diagnostic card to be pushed. Due to the inherent delay in the polling mechanism, the arrival time of the card on the mini-program is usually about 2 seconds later than that on the app. Therefore, the expected completion time threshold for the step is increased by 50% to avoid timeout errors caused by polling delays. In addition to front-end clicks, user confirmation also supports asynchronous feedback via "service notifications." Clicking the notification is considered "confirmed viewing."

[0057] When the user terminal is a vehicle infotainment screen, the presentation of the diagnostic card is dynamically controlled according to the vehicle's driving status. This application distributes the diagnostic card to the in-vehicle infotainment system (IVI) via the T-Box vehicle-cloud channel. The vehicle infotainment screen interacts with the vehicle's intelligent agent. Due to driving safety constraints, the presentation of the diagnostic card needs to be dynamically controlled according to the vehicle's driving status: when the vehicle is in motion, the vehicle infotainment screen only activates the voice broadcast component to broadcast the content of the diagnostic card to the user in voice form, while the text and video components are locked; when the vehicle is stationary, this application unlocks the text component, allowing the user to view the complete text and image diagnostic card on the vehicle infotainment screen; when the vehicle is charging, this application further unlocks the video component, allowing the user to watch related operation demonstration videos.

[0058] Figure 4 This is a schematic diagram of the three-terminal differentiated rendering state machine provided in this application, such as... Figure 4 The key difference between the rendering state switching on the vehicle's infotainment screen, which is constrained by driving safety, and the full-function interaction on the mobile device (OnStar APP and mini-program), which is not constrained by driving safety, is illustrated.

[0059] like Figure 4 As shown, the terminal-differentiated rendering state machine of this application is divided into two parallel branches according to the terminal type.

[0060] Car infotainment screen branch: Due to driving safety constraints, the presentation of diagnostic cards on the vehicle's infotainment screen dynamically changes according to the vehicle's driving status. The diagnostic cards are sent to the in-vehicle infotainment system via the T-Box vehicle-cloud channel. When the vehicle is in motion, only the voice broadcast component is activated on the infotainment screen; the text / image cards and video components are locked, and the user can only receive the diagnostic card content via voice. Once the vehicle comes to a complete stop, the system automatically unlocks the text / image cards and video components, allowing the user to view the complete diagnostic card on the screen. When the user inserts the charging gun and begins charging, the system further unlocks the video component, allowing the user to watch related operation demonstration videos. When the vehicle starts moving, the system returns from a stationary or charging state to a driving state, reactivating the voice broadcast mode, and the text / image and video components are locked again.

[0061] Mobile version: The mobile platform includes the OnStar app and mini-program, both of which have no driving safety restrictions and support full-featured interaction, including step confirmation, image and text viewing, and video playback.

[0062] The OnStar app integrates the MQTT SDK, which uses the MQTT long connection channel to achieve real-time push of diagnostic cards and step-level status synchronization. The diagnostic card arrives on the user's mobile phone immediately after it is generated, and the push delay is usually in the millisecond range.

[0063] Due to runtime environment limitations, the mini-program cannot maintain a long connection and receives diagnostic cards via HTTPS API polling. Because of inherent latency in the polling mechanism, cards typically arrive on the mini-program about 2 seconds later than on the app. Therefore, the expected completion time threshold for each step is increased by a preset percentage (e.g., 50%) to avoid timeout errors caused by polling delays. In addition to front-end clicks, user confirmation also supports asynchronous feedback via "service notifications," where clicking the notification is considered "confirmed viewing."

[0064] Figure 4 The diagnostic card uses different colors to indicate the availability of each component in different terminals and states: green indicates that the component is available in the current state, and red indicates that the component is unavailable in the current state. The in-vehicle screen indicates areas where there is no interaction, meaning that text and video components are locked while driving, and the user cannot operate the interface. The mobile phone screen indicates the differences between MQTT long connection (APP) and polling mechanism (Mini Program), as well as the specific value of the 50% increase in the timeout threshold for the Mini Program.

[0065] Figure 4 The bottom shows the core differences between the in-vehicle screen and the mobile phone: the in-vehicle screen is constrained by driving safety, and the rendering state dynamically switches according to the vehicle's driving status (driving / stationary / charging), and the state transition is triggered by the vehicle status signal when shifting gears and starting or stopping; the mobile phone (APP / mini-program) is not constrained by driving safety, and all functions can be supported, with the only differences being the push protocol (MQTT long connection vs HTTPS API polling) and payment channels.

[0066] Furthermore, this application implements a staggered scheduling strategy: diagnostic cards are pushed immediately upon disconnection; satisfaction surveys are not pushed if the issue is resolved, but a call-back appointment is pushed if the issue remains unresolved; a conversation summary is pushed after a preset delay. The mini-program supports aggregating the summary with service account / video account content to the "Discover" page. By adopting differentiated push methods and presentation strategies for mobile apps, mini-programs, and in-vehicle screens, it ensures that users on all terminals receive diagnostic cards in a timely manner while fully adapting to the technical characteristics of each terminal. The app uses long connections for real-time pushes, the mini-program uses a polling mechanism to complete pushes in restricted environments and raises the timeout threshold, and the in-vehicle screen dynamically controls the presentation format according to driving safety regulations, achieving full terminal coverage and scenario adaptation.

[0067] In this embodiment, before pushing the diagnostic card to the user terminal, this application first performs an identity awareness and path trimming process. This application determines the user's identity type by identifying the current user's login information, device information, and account binding information. Identity types include at least: the vehicle owner (account bound to the vehicle and operating device consistent with the owner's usual device), a proxy user (the operating device is logged into someone else's account, such as a family member using the vehicle owner's account to log into the mini-program), and a visitor (a temporary user who has not completed vehicle owner authentication), specifically including: Identify the identity type of the currently operating user; When the identification result indicates that the current user is a proxy user, an identity verification step is added to the diagnostic card; for example, a step is inserted at the beginning of the diagnostic path, requiring the user to confirm "whether it is the vehicle owner operating", and prompting that operations involving the transfer of vehicle control require the vehicle owner's authorization.

[0068] When the identification result indicates that the current user is a guest and the diagnostic card contains preset function steps (such as owner-exclusive functions, such as extended warranty purchase, remote vehicle control, etc., which require owner authentication to perform), a step to guide the user to download the application and complete the authentication is added to the diagnostic card; for example, a step is inserted at the end of the diagnostic path to prompt the user "The current function requires owner authentication. Please download the APP and complete the owner authentication".

[0069] Furthermore, this application also involves identity awareness and path trimming during the diagnostic card generation process: for users logging in on behalf of others, identity verification is added to the steps involving the transfer of vehicle control; for visitors and when owner-exclusive functions (such as extended warranty purchase) are involved, a "guide to download the APP to complete owner authentication" step is automatically inserted to avoid invalid operation guidance on unauthorized terminals. Through identity awareness and path trimming, this application can dynamically adjust the content of the diagnostic card according to the actual identity of the current user. Users logging in on behalf of others are given an additional identity verification step to prevent unauthorized operations, and visitors are given an additional authentication guidance step to prevent invalid operations on unauthorized terminals. This ensures the security of vehicle control and improves the user experience for users with different identities.

[0070] Figure 5 The interface diagram of the engineering embodiment provided in this application is as follows: Figure 5 The diagram shows the different presentation effects of the same call semantics on three terminals: the OnStar APP, the vehicle's infotainment screen, and the mini-program.

[0071] like Figure 5As shown, all three terminals receive and display diagnostic cards generated based on the same call semantics. However, due to differences in the technical characteristics and security constraints of each terminal, the presentation and interaction methods of the diagnostic cards vary. The top left corner of the image displays a unified timestamp of 09:41, indicating that the diagnostic cards from all three terminals were generated based on the same call and pushed at the same time.

[0072] OnStar App: The OnStar app offers a full-featured interactive interface and supports real-time synchronization via MQTT long connections. The app's diagnostic cards display a personalized diagnostic path sequence: a battery check step (confirmed by the user, confirmation time 15 seconds), a network check step (the interface displays "Current Connection: No Signal" and provides a "Next" button), and a command reissue step (the interface displays a "Please confirm if this is the vehicle owner's operation" identity verification prompt). The app is not subject to driving safety constraints and supports full-featured interactive functions such as step confirmation, image and text viewing, voice recognition, and payment. Figure 5 The MQTT long connection identifier shown indicates that the APP uses a long connection channel to push diagnostic cards in real time and synchronize step-level status. After the user completes each step, the status is reported immediately.

[0073] In-vehicle infotainment system (IVI): Due to driving safety constraints, diagnostic cards are sent to the in-vehicle infotainment system via the T-Box vehicle-cloud channel on the vehicle's infotainment screen. Figure 5 The vehicle's infotainment system primarily displays diagnostic card content via voice broadcast, with the graphic components locked while the vehicle is in motion. The infotainment system also displays an identity verification prompt, "Please confirm if this is the vehicle owner operating this," but its presentation is constrained by driving safety; it only broadcasts via voice while the vehicle is in motion, and the graphic components unlock when the vehicle is stationary. The image is marked with "T-Box" and "Voice Wake-up," indicating that the infotainment system receives diagnostic cards through the T-Box vehicle-to-cloud channel and supports voice wake-up interaction.

[0074] Mini Program: Due to runtime environment limitations, the mini-program receives diagnostic cards via HTTPS API polling. The diagram shows "Delay < 2s" and "Timeout threshold increased by 50%", indicating that due to inherent delays in the polling mechanism, the expected completion time threshold for steps on the mini-program is increased by 50% compared to the app, to avoid false timeouts caused by polling delays. The mini-program also displays an identity verification prompt: "Please confirm if this is the vehicle owner operating this function." The "Identity Awareness" label indicates that the mini-program supports identity awareness; when it identifies a user as a proxy or a guest, it adds an identity verification step to the diagnostic card or guides the user to download the app and complete authentication.

[0075] Figure 5The bottom shows the core differentiating features of the three terminals: the left side shows the MQTT real-time heartbeat information from the APP (real-time synchronization via long connection); the middle shows the T-Box driving safety perception on the vehicle screen (dynamically controlled presentation form under driving safety constraints); and the right side shows the HTTPS polling + identity perception on the mini-program (polling delay with timeout threshold escalated, identity perception trigger path pruned). The diagnostic step sequence displayed by the three terminals is identical in content, but the interaction method (click confirmation / voice broadcast), communication protocol (MQTT / T-Box / HTTPS polling), and timeout threshold (standard / 50% escalation) are adapted differently according to the terminal type, reflecting the differentiated rendering strategy of the three terminals in this application.

[0076] Regarding S104's calculation of the path deviation vector based on interaction behavior data, the call recording, and the diagnostic card, this application provides an optional embodiment: Based on the actual dwell time of the user at each step in the diagnostic card recorded in the interaction behavior data and the expected threshold, a clarity deviation vector is obtained. The expected threshold is preset according to the complexity of the step; for example, the expected threshold for simple confirmation steps is 5 seconds, the expected threshold for steps requiring reading instructions is 15 seconds, and the expected threshold for steps requiring external operations is 30 seconds. For the mini-program, due to the inherent delay of the polling mechanism, the expected completion time threshold for the step is increased by 50%. When the actual dwell time of a step exceeds the expected threshold, this application calculates the excess ratio as a clarity deviation value. The greater the excess, the larger the clarity deviation, indicating that the guidance clarity of that step is insufficient.

[0077] The confusion bias vector is obtained by calculating the ratio of the number of back-switch attempts to the total number of forward attempts recorded in the interaction behavior data. A back-switch attempt refers to the user's operation of returning from the current step to the previous step. The higher the ratio of the number of back-switch attempts to the total number of forward attempts, the more the user hesitates between steps, indicating ambiguity in the step logic or expression, and the greater the confusion bias.

[0078] Based on the continuous unconfirmed status detection of the user in each step of the diagnostic card recorded in the interaction behavior data, a functional deviation vector is obtained; the target steps include functional steps; for steps involving specific vehicle functions (e.g., re-issuing remote start commands), if the user fails to confirm the step multiple times and repeatedly enters and exits, this application accumulates the status as a functional deviation value, indicating that the problem may stem from defects in the product function itself rather than unclear tutorials.

[0079] A service deviation vector is obtained based on the semantic similarity between the call recording and the diagnostic card. Specifically, this application inputs the verbal explanation in the customer service call recording and the standard procedure text in the diagnostic card into a pre-trained semantic model to obtain semantic vectors, and calculates the cosine similarity between the two vectors. The lower the semantic similarity, the greater the deviation between the agent's script and the standard procedure, and the greater the service deviation.

[0080] The path deviation vector is composed of clarity deviation vector, confusion deviation vector, functional deviation vector, and service deviation vector. By calculating deviation values ​​from four dimensions—stay time, rollback rate, unconfirmed functional steps, and deviation from the meaning of the message—the path deviation vector can accurately distinguish the different reasons why users get stuck. It can determine whether the tutorial is unclear (clarity deviation), the logical steps are confusing (confusion deviation), there is a bug in the product function (functional deviation), or the customer service is wrong (service deviation), providing a quantitative basis for subsequent refined attribution.

[0081] Regarding S105, which uses the path deviation vector and the interaction behavior data to perform feedback correction on the weights of the alignment edges in the semantic alignment graph to obtain a corrected semantic alignment graph, this application provides an optional embodiment: The attribution type is determined based on the path deviation vector. Attribution types include at least four: clarity type (significantly high clarity deviation in the path deviation vector, other deviations are normal), confusion type (significantly high confusion deviation in the path deviation vector), function type (significantly high function deviation in the path deviation vector), and service type (significantly high service deviation in the path deviation vector). The attribution judgment logic is as follows: if the user completes all the steps and finally confirms the solution, it is attributed to the tutorial being effective; if the user eventually solves the problem but gets stuck at a certain step for a long time, it is attributed to insufficient tutorial clarity; if the user repeatedly fails at the same functional step and it is concentrated on a few car models, it is attributed to a product functional defect; if what customer service says on the phone is inconsistent with what is written on the card (service deviation triggered), it is attributed to service quality.

[0082] Based on the attribution type, the target diagnostic step corresponding to the interaction behavior data is determined; the diagnostic card contains multiple diagnostic steps arranged in sequence, and the target diagnostic step is the diagnostic step corresponding to the interaction behavior data; the target alignment edge corresponding to the target diagnostic step is determined (i.e., the alignment edge between the semantic slot and the knowledge-side node related to the generation of the target diagnostic step in the semantic alignment graph).

[0083] Based on the attribution type, the weights of the target alignment edges are corrected using an update strategy that matches the attribution type, resulting in a corrected semantic alignment graph.

[0084] Different attribution types correspond to different update directions and magnitudes: Clarity type triggers negative correction (weight reduction) to the target alignment edge because users getting stuck at the comprehension stage indicates that the knowledge description corresponding to that step is not clear enough; Confusion type triggers negative correction (weight reduction) to the target alignment edge and related sorting edges because users repeatedly backtracking indicates that the step order is unreasonable; Function type triggers negative correction to the target alignment edge, but the magnitude is small (slight reduction) because the problem may stem from the product function itself rather than an alignment error, requiring comprehensive judgment based on subsequent multi-user data; Service type triggers negative correction (weight reduction) to the agent dialogue nodes associated with the target alignment edge because there is a deviation between the agent's verbal explanation and the standard process. After the above corrections, this application outputs a corrected semantic alignment graph. After completion, this application binds the attribution results with the corresponding call records and agent IDs for archiving, and anonymizes personal information to form a traceable attribution file for subsequent improvement. By implementing a four-step process of "attribution type determination → target step location → target alignment edge tracing → differentiated correction", the feedback correction is made more precise. Different types of stuck causes correspond to different correction strategies, rather than a one-size-fits-all adjustment. This makes the corrected semantic alignment diagram more reflective of the real root cause of the problem, improving the effectiveness and accuracy of feedback correction.

[0085] In this embodiment, after completing the feedback correction, the application also performs a knowledge evolution process, specifically including: When the ratio of any step in the diagnostic card recorded by the interaction behavior data exceeds a preset threshold, the step is marked as a bottleneck step, and an optimization work order corresponding to the bottleneck step is generated. The ratio includes at least the unconfirmed rate, the timeout rate, and the rollback rate. The unconfirmed rate refers to the proportion of users who select "unresolved" or skip unconfirmed steps at this step. The timeout rate refers to the proportion of users who stay at this step for longer than the expected threshold. The rollback rate refers to the proportion of users who go back to the previous step from this step. This application calculates the above three ratios for each step.

[0086] When any rate in any step exceeds a preset threshold, such as an unconfirmed rate exceeding 20% ​​or a timeout rate exceeding the mean plus twice the standard deviation, this application marks the step as a "high-risk step" and automatically generates an optimization work order for that step. The optimization work order includes the step's identifier, specific data on the risk (unconfirmed rate, timeout rate, and rollback rate), and suggested optimization directions (e.g., "This step's dwell time is too long; it is recommended to simplify the text" or "This step has a high rollback rate; it is recommended to adjust the step order"). Knowledge operations personnel modify and optimize the content of the high-risk steps based on the optimization work order.

[0087] After optimization, this application performs tests (such as A / B testing) on ​​the modified semantic alignment graph, and compares the difference data of the semantic alignment graph and the modified semantic alignment graph on preset indicators; when the difference data of the indicators meets the preset gating conditions, the semantic alignment graph is replaced with the modified semantic alignment graph, and the corresponding knowledge-side node attributes in the modified semantic alignment graph are updated synchronously.

[0088] The new diagnostic cards, generated based on the corrected semantic alignment graph, and the old diagnostic cards, generated based on the original semantic alignment graph, will be pushed to different user groups. Within a preset testing period (e.g., 14 days), the differences in completion rate, stall rate, and problem resolution rate will be compared between the two versions. The new version will not be immediately rolled out to all users; instead, it will first undergo a phased A / B testing, randomly selecting a subset of users to use the new version while the rest continue using the old version, comparing the data over 14 days.

[0089] When the indicator difference data meets the preset gating conditions—that is, the new version is significantly better than the old version in terms of completion rate and problem resolution rate (statistical significance test p<0.05, effect size h>0.5), and the failure rate is not higher than that of the old version—this application replaces the original semantic alignment graph with a revised semantic alignment graph and simultaneously updates the corresponding knowledge-side node attributes in the revised semantic alignment graph (e.g., updating the optimized step text to the corresponding diagnostic step node) to make the next match more accurate. If any of the three indicators fails to meet the gating conditions, this application automatically reverts to the old version of the semantic alignment graph and abandons this revision. Through a closed-loop process of "three-rate statistics → checkpoint identification → optimization work order → A / B testing → gating replacement", the knowledge base has achieved continuous evolution and data-driven optimization. Checkpoint steps are automatically identified and optimization work orders are generated. The optimized version is verified by rigorous A / B testing before it can be launched. The triple gating conditions ensure the credibility and security of the optimization effect. The automatic rollback mechanism for non-compliance avoids the risk of degradation, upgrading the optimization of the knowledge base from "manual spot checks" to "data-driven automated closed loop".

[0090] Figure 6 The knowledge evolution closed-loop evidence chain diagram provided for this application, such as Figure 6 As shown, the knowledge evolution closed loop involves six data entities: knowledge entries (IKMS), diagnostic steps (diagnostic path nodes), checkpoint data (high checkpoint markers), optimization work orders, ABTestResult (A / B test results), and version feedback. Figure 6 The process consists of six steps in sequence.

[0091] Knowledge Entries: Knowledge entry instantiation and distribution, and behavior data collection and feedback. Knowledge entries in the Customer Service Knowledge Base (IKMS) are instantiated as diagnostic path nodes and distributed to user terminals. During the execution of diagnostic steps, user interaction data is collected through step-level behavior collection and fed back to the system.

[0092] Diagnostic Steps and Bottleneck Data: High Bottleneck Marking and Work Order Generation. The system calculates the unconfirmed rate for each step based on interaction behavior data. The unconfirmed rate refers to the percentage of users who select "Unresolved" or skip the unconfirmed step. When the unconfirmed rate exceeds a preset threshold (e.g., 20%), the system marks the step as a "high bottleneck," generates corresponding bottleneck data (BottleneckMetric), and triggers the automatic generation of an optimization work order (KnowledgeTicket).

[0093] Optimize Work Orders: This involves revising and conducting A / B testing on optimized work orders. Knowledge operations personnel modify and optimize the steps involved in each bottleneck area based on the optimized work order, and then proceed with A / B testing.

[0094] A / B Test Results: A / B testing and triple gating verification. The new version of the diagnostic card (new version B) generated based on the corrected semantic alignment graph and the old version of the diagnostic card (old version A) generated based on the original semantic alignment graph were pushed to different user groups for comparative testing. Figure 6 For example, the unconfirmed rate of the old version A is 28%, while the unconfirmed rate of the new version B is 8%. The new version must meet three gating conditions to replace the old version: statistical significance test p<0.05, effect size h>0.5, and the problem resolution rate must not decrease.

[0095] Version Feedback: Automatic Replacement and Version Feedback. When all three metrics meet the preset gating conditions, the system replaces the original semantic alignment graph with the corrected one and synchronously updates the corresponding knowledge-side node attributes, completing version feedback (VersionSnapshot archiving). Automatic Rollback Mechanism. If any of the three metrics fails to meet the gating conditions, the system automatically rolls back to the old version of the semantic alignment graph, abandoning the current correction.

[0096] Figure 6 The bottom annotation shows the completeness of the knowledge evolution evidence chain: knowledge item (source) → diagnostic steps (execution) → checkpoint data (evidence) → optimization work order (handling) → test results (verification) → version feedback (archiving). Figure 6 The document also outlines compliance requirements, ensuring that every step of the operation is traceable, auditable, and auditable, meeting automotive-grade data management requirements.

[0097] Figure 7 The feedback correction schematic provided for this application, such as Figure 7 As shown, the feedback correction principle diagram is divided into two parts from top to bottom: the forward path and the feedback path. The right side shows the convergence curve of the alignment edge weight with the number of iterations.

[0098] Forward Path: The forward path starts with the instantiation of the semantic alignment graph G. The alignment edge weights of the semantic alignment graph are used to sort the steps of the diagnostic path, generate the diagnostic path P and push it to the user terminal. The user executes the diagnostic steps according to the diagnostic path.

[0099] Feedback Correction Path: After the user executes the diagnostic steps, this application collects the user's step-level interaction behavior on the diagnostic card and calculates the behavior score b(k). The behavior score b(k) is composed of three weighted factors: user confirmation rate (weight 50%), completion time achievement rate (weight 30%), and rollback rate (weight 20%, the fewer rollbacks, the higher the score). The behavior score b(k) serves as a feedback signal and is fed back to the semantic alignment graph via the feedback path to update the weights of the alignment edges.

[0100] The weight update formula is: w(k+1) = w(k)×(1-γ) + γ×b(k), where w(k) is the current weight, w(k+1) is the updated weight, b(k) is the behavior score calculated based on user interaction behavior within the current sliding window, and γ is the preset update coefficient (γ=0.2 in this application), which represents the proportion of the new score in the weight update.

[0101] This application incorporates a debouncing mechanism: the system does not trigger weight updates based on a single user interaction, but instead accumulates a preset number of interaction behavior data (e.g., 30 times) using a sliding window approach before performing a unified correction. This mechanism maintains stability at the single-behavior scale (a single abnormal behavior will not cause drastic fluctuations in weight) and ensures sensitivity at the sliding window scale (user behavior trends can be reflected after accumulating 30 interactions), achieving a separation of "stability" and "sensitivity" at the two time scales.

[0102] Figure 7 The right side shows the convergence curve of the alignment edge weight as a function of the number of iterations (or the number of statistical windows). The horizontal axis represents the number of iterations / number of statistical windows, and the vertical axis represents the alignment edge weight w. Figure 7 Different symbols are used to distinguish different types of alignment edges: solid red lines represent misaligned edges (closed-loop attenuation), solid blue lines represent correctly aligned edges (closed-loop reinforcement), dashed red lines represent misaligned edges (static open-loop solidification), and dashed blue lines represent correctly aligned edges (static open-loop suppression).

[0103] Under static, feedback-free conditions (as illustrated in the upper part of the diagram), the weight of the incorrectly aligned edge (0.68) is consistently higher than that of the correctly aligned edge (0.45), leading to continuous misleading sorting and a lack of self-correction. After introducing the feedback correction mechanism of this application, the incorrectly aligned edge naturally decays due to frequent user stumbles (low behavior score), while the correctly aligned edge is continuously strengthened because the user successfully completes the entire process (high behavior score). For example... Figure 7As shown in the convergence curve, after the 6th iteration, the weights of correctly aligned edges surpass those of incorrectly aligned edges, and the system automatically corrects the sorting, requiring no manual intervention throughout the process. This technical effect demonstrates the core advantage of the feedback correction mechanism in this application, which enables the semantic alignment graph to adaptively and continuously optimize based on real user interaction behavior.

[0104] Figure 8 The full-link cross-system swimlane diagram for customer service call verification provided for this application is as follows: Figure 8 As shown, the swimlane diagram is divided into three stages from top to bottom along the timeline: semantic layer construction (stage one), service layer execution (stage two), and correction layer evolution (stage three), involving a total of 13 action nodes. The three data streams are distinguished by dark blue arrows, light blue arrows, and red arrows.

[0105] Phase 1 comprises nodes 1 to 6, with arrows (depth-first search algorithm) indicating the data flow for semantic layer construction. Node 1 represents the car owner (end-user) calling customer service and verbally describing the fault; Node 2 represents the called user (agent) answering the call and conducting the conversation; Node 3 represents the agent (GSP / call center) uploading the call recording; Nodes 4 to 6 connect to three terminal entry points: the APP, the mini-program, and the in-vehicle screen, respectively. Other backend systems perform semantic slot extraction, semantic alignment graph construction, and knowledge agents return knowledge items / steps / scripts to other backend systems, completing the entire process of semantic layer construction from call recording to structured semantic slot extraction, knowledge-side node matching and edge building, and personalized diagnostic path generation.

[0106] Phase Two includes nodes 7 to 10, with arrows (using a breadth-first search algorithm) indicating the data flow executed at the service layer. Node 7 generates diagnostic paths for other backend systems; Node 8 compiles and pushes diagnostic cards to the application (APP / Mini Program / Vehicle Screen), compiling the diagnostic path into a diagnostic card and distributing it through the three-terminal push channel; Node 9 allows the vehicle owner to receive the card and perform step-by-step interactive operations; Node 10 collects step-by-step behavior data for the application (APP / Mini Program / Vehicle Screen), batch reports behavior logs, and temporarily stores the interactive behavior data locally on the user's terminal, uploading it to the system in batches when network conditions permit.

[0107] Phase 3 comprises nodes 11 to 13, with arrows (feedback corrections) indicating the data flow of the correction layer evolution. Node 11 performs path deviation vector calculation and satisfaction attribution for other backend systems. It calculates the path deviation vector based on interaction behavior data, call recordings, and diagnostic cards, performs attribution classification based on the path deviation vector, and corrects the weights of the alignment edges in the semantic alignment graph. Node 12 performs alignment graph feedback correction for other backend systems. Node 13 enables knowledge advancement and version feedback for the knowledge seat. It identifies high-stuck steps based on interaction behavior data and triggers knowledge base optimization and updates, completing the version feedback process.

[0108] The three-terminal access gateway is marked as a key node in Phase 1, responsible for unified access and differentiated routing for the three terminal entry points, which reflects the architectural advantage of this application in achieving cross-system semantic interoperability without changing the existing system interfaces.

[0109] Figure 9 The topology diagram of the customer service call verification system provided for this application is as follows: Figure 9 As shown, the system architecture of this application is divided into three layers from bottom to top: the existing system layer, the middleware layer, and the terminal layer. Data flow between each layer is achieved through standardized data interfaces.

[0110] The existing system layer is deployed at the bottom of the architecture and includes a call center and a voice analytics platform. The call center contains a CSP agent system, which generates call recordings and serves as the data source for post-call service verification. The voice analytics platform performs ASR transcription and semantic slot extraction on the call recordings, outputting a structured slot set S for the middleware layer to use. The existing system layer is marked as "existing system (non-modifiable)," indicating that this application achieves data integration with the existing system through standardized data interfaces without modifying the existing system interfaces.

[0111] The middleware layer, deployed above the existing system layer, is a newly added semantic alignment middleware in this application. The semantic alignment middleware comprises three functional modules: slot extraction, alignment mechanism construction, and path compilation. The slot extraction module extracts semantic slots from the structured slot set S output by the speech analysis platform; the alignment mechanism construction module matches the semantic slots with knowledge-side nodes, establishes alignment edges with initial weights, and constructs a semantic alignment graph; the path compilation module generates personalized diagnostic paths based on the semantic alignment graph and compiles them into diagnostic cards. The three modules of the middleware layer collaborate in a serial pipeline manner to complete the semantic compilation process from structured slots to diagnostic cards.

[0112] The terminal layer is deployed at the top of the architecture and includes three types of user terminal devices: the OnStar APP, the mini-program, and the in-vehicle screen. These three types of terminals interact with the middleware layer through different communication protocols and are subject to the constraints of terminal differentiation.

[0113] The OnStar app (iOS / Android) communicates with the middleware layer via a persistent MQTT connection, supporting full-featured interaction (including step confirmation, image and text viewing, video playback, etc.). Diagnostic path P is sent to the app via the persistent MQTT connection, and behavior logs are reported to the middleware layer through the same channel.

[0114] The mini-program communicates with the middleware layer via HTTPS API polling. Due to the inherent latency of the polling mechanism, the arrival time of cards on the mini-program is approximately 2 seconds later than on the app, hence the labels "Delay +2s" and "Timeout threshold increased by 50%" in the diagram. There is a scenario where a family member logs in on behalf of another user (labeled "Single Command Login Scenario"), where someone other than the vehicle owner logs in to the mini-program using the vehicle owner's account.

[0115] The in-vehicle infotainment system (IVI) communicates with the middleware layer via the T-Box vehicle-cloud channel. Due to driving safety constraints, the presentation of diagnostic cards on the IVI is dynamically controlled according to the vehicle's driving status: only voice broadcasts while driving (marked "only voice push while driving" in the figure), and the graphic component is unlocked when the vehicle is stationary (marked "unlock graphic component when stationary" in the figure).

[0116] Figure 9 The bottom uses illustrations to distinguish the nature of each component of the system: the existing system (which cannot be modified) is marked with a solid line box, the new modules added in this invention are marked with a dashed line box, the user terminal is marked with a rounded corner box, and the terminal differentiation constraints are marked with red text.

[0117] Figure 10 The overall architecture diagram of the customer service call post-call interactive diagnostic service verification method provided in this application is as follows: Figure 10 As shown, the overall architecture of this application is divided into three stages from left to right along the timeline: semantic layer construction (stage one), service layer execution (stage two), and correction layer iteration (stage three), which includes nine core steps from S1 to S9. Figure 10 Different labels are used to distinguish between the existing system and the new core steps of this invention, and arrows are used to indicate the two data paths: the forward data flow and the feedback correction flow.

[0118] Phase 1 includes S1 semantic slot extraction, S2 semantic alignment graph construction, and S3 diagnostic path generation. S1 semantic slot extraction extracts structured semantic slots from call recordings (including CSP agent systems) and ASR transcription text output from the voice analysis platform; S2 semantic alignment graph construction matches semantic slots with knowledge entry nodes, diagnostic step nodes, and agent dialogue nodes in the knowledge base (IKMS) to establish alignment edges with initial weights and form a semantic alignment graph; S3 diagnostic path generation generates personalized diagnostic paths based on the semantic alignment graph.

[0119] Phase Two includes S4 diagnostic card compilation and push, and S5 step-level behavior collection. S4 diagnostic card compilation and push compiles the diagnostic path into a diagnostic card, which is then distributed to the three terminals (APP / Mini Program / Vehicle Screen) through three push channels: MQTT long connection (APP), HTTPS API polling (Mini Program), and T-Box vehicle cloud channel (vehicle screen). Differentiated rendering is performed for the three terminals. S5 step-level behavior collection collects the user's step-level interaction behavior on the diagnostic card and generates behavior log L.

[0120] Phase 3 includes S6 path deviation vector calculation, S7 adaptive satisfaction attribution, S8 alignment graph feedback correction, and S9 checkpoint-driven knowledge evolution. S6 calculates the path deviation vector d based on behavior logs L, call recordings, and diagnostic cards; S7 performs attribution classification based on the path deviation vector d, outputting the attribution result A; S8 performs feedback correction on the weights of the alignment edges in the semantic alignment graph based on the attribution result A and interaction behavior data, outputting the updated weight matrix W. T S9 identifies high-risk steps based on interaction behavior data and triggers knowledge base optimization and updates, thus completing version feedback.

[0121] Figure 10 The bottom shows the existing systems reused in this application: the call center provides call recording data sources, the voice analysis platform provides ASR transcription and semantic slot extraction capabilities, and the knowledge base (IKMS) provides three types of knowledge-side nodes: knowledge entries, diagnostic steps, and agent scripts. All of the above existing systems are marked as immutable; this application achieves data integration without modifying the interfaces of the existing systems.

[0122] The three terminal outputs are labeled with their corresponding push channels: the APP uses an MQTT long connection (real-time push, full-function interaction), the mini-program uses HTTPS polling (delay +2s, timeout threshold increased by 50%), and the vehicle screen uses the T-Box vehicle cloud channel (voice broadcast only while driving, text and images for unlocking when stationary, video for unlocking while charging). The data flow between Phase Two and Phase Three indicates that the behavior log L, deviation vector d, and attribution result A constitute the data basis for feedback correction. The feedback correction flow is indicated by an independent arrow, forming a complete closed-loop system together with the forward data flow.

[0123] Figure 11 A structural diagram of a post-call interactive diagnostic service optimization device provided in an embodiment of this application is shown below. Figure 11 As shown, based on the post-call interactive diagnostic service optimization method provided in the preceding embodiments, this application also provides a post-call interactive diagnostic service optimization device, including: The matching module is used to extract semantic slots from call recordings, match the semantic slots with knowledge-side nodes, and obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes. A module is established to create an alignment edge with initial weights between the semantic slot and the knowledge-side node based on the matching result, and to construct a semantic alignment graph based on the alignment edge. The generation module is used to generate diagnostic cards based on the semantic slots and the semantic alignment graph, and push the diagnostic cards to the user terminal; The calculation module is used to calculate the path deviation vector based on the interaction behavior data, the call recording, and the diagnostic card; the interaction behavior data is obtained by collecting the user's step-level operations on the diagnostic card; The correction module is used to perform feedback correction on the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data, so as to obtain a corrected semantic alignment graph.

[0124] As an optional embodiment, the module is specifically used for: When the literal similarity between the text of the semantic slot and the text of the knowledge-side node in the matching result is greater than or equal to the first threshold, it enters the first matching channel and calculates the initial alignment confidence according to the formula c0=α×I+β×sem+γ. When the literal similarity is less than the first threshold and the semantic similarity between the text of the semantic slot and the text of the knowledge-side node in the matching result is greater than or equal to the second threshold, the second matching channel is entered, and the initial alignment confidence is calculated according to the formula c0=δ×sem. An alignment edge is established between the semantic slot and the knowledge-side node, and the initial alignment confidence is assigned as the initial weight of the alignment edge. Where c0 is the initial alignment confidence; sem is the semantic similarity between the text of the semantic slot and the text of the knowledge-side node; I represents the literal similarity between the text of the semantic slot and the text of the knowledge-side node; and δ is the preset discount coefficient.

[0125] As an optional embodiment, the semantic slot includes operated data, fault data, and preset troubleshooting data. The generation module is specifically used for: Based on the semantic alignment graph, the corresponding basic process template is retrieved from the preset standard investigation process template library; When the processed data matches any step in the basic process template, the step is marked as executed and skipped to obtain the adjusted process template. Determine the troubleshooting steps corresponding to the fault data, and insert the troubleshooting steps into the adjustment process template to obtain the insertion process template; The priority weight of each step in the insertion process template is determined based on the preset investigation data, and the steps in the insertion process template are sorted according to the priority weight to generate a diagnostic path; The diagnostic path is used as the content of the diagnostic card; the diagnostic card is the sequence of steps in the call recording.

[0126] As an optional embodiment, the generation module is specifically used for: When the user terminal is a mobile application, the diagnostic card is pushed in real time through a long connection channel; When the user terminal is a mini-program, the diagnostic card is pushed through API polling. When the user terminal is a vehicle infotainment screen, the presentation of the diagnostic card is dynamically controlled according to the vehicle's driving status.

[0127] As an optional embodiment, the apparatus further includes: The identification module is used to identify the identity type of the current user. When the identification result indicates that the current user is a proxy user, an identity verification step is added to the diagnostic card. When the identification result indicates that the current user is a guest and the diagnostic card contains preset functional steps, a step to guide the user to download the application and complete the authentication is added to the diagnostic card.

[0128] As an optional embodiment, the computing module is specifically used for: Based on the actual dwell time of the user in each step of the diagnostic card and the expected threshold recorded in the interactive behavior data, a clarity deviation vector is obtained. The confusion bias vector is obtained based on the ratio of the number of back-to-back switches to the total number of forward switches recorded in the interaction behavior data; Based on the continuous unconfirmed state detection of the user in each step of the diagnostic card recorded in the interaction behavior data, a functional deviation vector is obtained; the target step includes the functional step. Based on the semantic similarity between the call recording and the diagnostic card, a service deviation vector is obtained; The clarity deviation vector, confusion deviation vector, function deviation vector, and service deviation vector are used as path deviation vectors.

[0129] As an optional embodiment, the correction module is specifically used for: The attribution type is determined based on the path deviation vector; the attribution type includes clarity type, confusion type, function type, and service type. Based on the attribution type, the target diagnostic step corresponding to the interaction behavior data is determined; the diagnostic card contains multiple diagnostic steps arranged in sequence, and the target diagnostic step is the diagnostic step corresponding to the interaction behavior data; Determine the target alignment edge corresponding to the target diagnosis step; Based on the attribution type, the weights of the target alignment edges are corrected using an update strategy that matches the attribution type, resulting in a corrected semantic alignment graph.

[0130] As an optional embodiment, the apparatus further includes: The optimization module is used to mark any step as a checkpoint step and generate an optimization work order corresponding to the checkpoint step when the ratio of any step in the diagnostic card of the interactive behavior data record exceeds a preset threshold; the ratio includes at least the unconfirmed rate, the timeout rate, and the rollback rate. The testing module is used to perform tests on the modified semantic alignment graph, compare the semantic alignment graph and the modified semantic alignment graph on preset indicators; when the indicator difference data meets the preset gating conditions, the modified semantic alignment graph is replaced with the modified semantic alignment graph, and the corresponding knowledge-side node attributes in the modified semantic alignment graph are updated synchronously.

[0131] This application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a post-call interactive diagnostic service optimization method.

[0132] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a post-call interactive diagnostic service optimization method.

[0133] This application provides a computer program product, including a computer program that, when executed by a processor, implements a method for optimizing interactive diagnostic services after a call.

[0134] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and equipment embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and equipment embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0135] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for optimizing interactive diagnostic services after a call, characterized in that, The method includes: Semantic slots are extracted from call recordings and matched with knowledge-side nodes to obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes. Based on the matching result, an alignment edge with initial weight is established between the semantic slot and the knowledge-side node, and a semantic alignment graph is constructed based on the alignment edge. A diagnostic card is generated based on the semantic slot and the semantic alignment graph, and the diagnostic card is pushed to the user terminal. Based on the interactive behavior data, the call recording, and the diagnostic card, a path deviation vector is calculated; the interactive behavior data is obtained by collecting the user's step-level operations on the diagnostic card. Based on the path deviation vector and the interaction behavior data, the weights of the alignment edges in the semantic alignment graph are corrected by feedback to obtain a corrected semantic alignment graph.

2. The method according to claim 1, characterized in that, The step of establishing an alignment edge with initial weights between the semantic slot and the knowledge-side node based on the matching result includes: When the literal similarity between the text of the semantic slot and the text of the knowledge-side node in the matching result is greater than or equal to the first threshold, it enters the first matching channel and calculates the initial alignment confidence according to the formula c0=α×I+β×sem+γ. When the literal similarity is less than the first threshold and the semantic similarity between the text of the semantic slot and the text of the knowledge-side node in the matching result is greater than or equal to the second threshold, the second matching channel is entered, and the initial alignment confidence is calculated according to the formula c0=δ×sem. An alignment edge is established between the semantic slot and the knowledge-side node, and the initial alignment confidence is assigned as the initial weight of the alignment edge. Where c0 is the initial alignment confidence; sem is the semantic similarity between the text of the semantic slot and the text of the knowledge-side node; I represents the literal similarity between the text of the semantic slot and the text of the knowledge-side node; α, β and γ are all preset weight coefficients; δ is a preset discount coefficient.

3. The method according to claim 1, characterized in that, The semantic slots include processed data, fault data, and preset troubleshooting data. The step of generating diagnostic cards based on the semantic slots and the semantic alignment graph specifically includes: Based on the semantic alignment graph, the corresponding basic process template is retrieved from the preset standard investigation process template library; When the processed data matches any step in the basic process template, the step is marked as executed and skipped to obtain the adjusted process template. Determine the troubleshooting steps corresponding to the fault data, and insert the troubleshooting steps into the adjustment process template to obtain the insertion process template; The priority weight of each step in the insertion process template is determined based on the preset investigation data, and the steps in the insertion process template are sorted according to the priority weight to generate a diagnostic path; The diagnostic path is used as the content of the diagnostic card; the diagnostic card is the sequence of steps in the call recording.

4. The method according to claim 1, characterized in that, The step of pushing the diagnostic card to the user terminal specifically includes: When the user terminal is a mobile application, the diagnostic card is pushed in real time through a long connection channel; When the user terminal is a mini-program, the diagnostic card is pushed through API polling. When the user terminal is a vehicle infotainment screen, the presentation of the diagnostic card is dynamically controlled according to the vehicle's driving status.

5. The method according to claim 1, characterized in that, Before pushing the diagnostic card to the user terminal, the method further includes: Identify the identity type of the currently operating user; When the identification result indicates that the current user is a user who logged in on behalf of another, an identity verification step is added to the diagnostic card. When the identification result indicates that the current user is a guest and the diagnostic card contains preset functional steps, a step to guide the user to download an application and complete the authentication is added to the diagnostic card.

6. The method according to claim 1, characterized in that, The calculation of the path deviation vector based on the interaction behavior data, the call recording, and the diagnostic card specifically includes: Based on the actual dwell time of the user in each step of the diagnostic card and the expected threshold recorded in the interactive behavior data, a clarity deviation vector is obtained. The confusion bias vector is obtained based on the ratio of the number of back-to-back switches to the total number of forward switches recorded in the interaction behavior data; Based on the continuous unconfirmed state detection of the user in each step of the diagnostic card recorded in the interaction behavior data, a functional deviation vector is obtained; the target step includes the functional step. Based on the semantic similarity between the call recording and the diagnostic card, a service deviation vector is obtained; The clarity deviation vector, confusion deviation vector, function deviation vector, and service deviation vector are used as path deviation vectors.

7. The method according to claim 1, characterized in that, The step of adjusting the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data to obtain a corrected semantic alignment graph specifically includes: The attribution type is determined based on the path deviation vector; the attribution type includes clarity type, confusion type, function type, and service type. Based on the attribution type, the target diagnostic step corresponding to the interaction behavior data is determined; the diagnostic card contains multiple diagnostic steps arranged in sequence, and the target diagnostic step is the diagnostic step corresponding to the interaction behavior data; Determine the target alignment edge corresponding to the target diagnosis step; Based on the attribution type, the weights of the target alignment edges are corrected using an update strategy that matches the attribution type, resulting in a corrected semantic alignment graph.

8. The method according to claim 1, characterized in that, The method further includes: When the ratio of any step in the diagnostic card of the interactive behavior data record exceeds a preset threshold, the step is marked as a checkpoint step, and an optimization work order corresponding to the checkpoint step is generated; the ratio includes at least the unconfirmed rate, the timeout rate, and the rollback rate. Perform tests on the modified semantic alignment graph and compare the difference data of the semantic alignment graph and the modified semantic alignment graph on preset indicators; When the index difference data meets the preset gating conditions, the semantic alignment graph is replaced with a corrected semantic alignment graph, and the corresponding knowledge-side node attributes in the corrected semantic alignment graph are updated synchronously.

9. A post-call interactive diagnostic service optimization device, characterized in that, The device includes: The matching module is used to extract semantic slots from call recordings, match the semantic slots with knowledge-side nodes, and obtain matching results; the knowledge-side nodes include at least knowledge base entry nodes, diagnostic step nodes, and agent script nodes. A module is established to create an alignment edge with initial weights between the semantic slot and the knowledge-side node based on the matching result, and to construct a semantic alignment graph based on the alignment edge. The generation module is used to generate diagnostic cards based on the semantic slots and the semantic alignment graph, and push the diagnostic cards to the user terminal; The calculation module is used to calculate the path deviation vector based on the interaction behavior data, the call recording, and the diagnostic card; the interaction behavior data is obtained by collecting the user's step-level operations on the diagnostic card; The correction module is used to perform feedback correction on the weights of the alignment edges in the semantic alignment graph based on the path deviation vector and the interaction behavior data, so as to obtain a corrected semantic alignment graph.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the post-call interactive diagnostic service optimization method as described in any one of claims 1-8.

Images