Method and system for constructing e-commerce customer service field knowledge graph empowered by large model

Abstract

The application relates to the technical field of e-commerce intelligent question and answer, in particular to an e-commerce customer service field knowledge graph construction method and system empowered by a large model, which comprises the following steps: based on an after-sales rule configuration server, effective rules are sorted and an access code set is formed, a consultation stage gear is obtained by combining an order state and consultation time, consultation text and customer service answer text are marked by a large model reasoning service, a customer service semantic code group is generated, an access conflict identifier is formed after checking after-sales rule condition nodes, and a knowledge graph node relationship is registered accordingly, and a graph construction state is obtained. By converting rules within a valid period into access codes, generating a consultation stage gear in combination with an order performance process, forming a customer service semantic code group according to pre-training language semantic recognition, obtaining an access conflict identifier through category, time period and voucher condition verification, only receiving verified nodes and relationship edges for graph registration, invalid rule paths are compressed, and human-computer question and answer deviation caused by business condition deviation is relieved.

Description

Technical Field

[0001] This invention relates to the field of e-commerce intelligent question answering technology, and in particular to a method and system for constructing knowledge graphs in the e-commerce customer service field empowered by large models. Background Technology

[0002] The field of e-commerce intelligent question answering technology involves user inquiry understanding, question intent recognition, product information retrieval, order service Q&A, after-sales problem handling, customer service knowledge management, and human-computer interaction response in e-commerce scenarios. It primarily targets industries such as e-commerce platforms, online retail, brand customer service, after-sales service, and intelligent customer service systems. Specifically, the traditional e-commerce customer service knowledge graph construction method involves using data collection, entity recognition, relation extraction, ontology modeling, knowledge fusion, and knowledge storage techniques to structure and organize e-commerce customer service-related knowledge objects and their relationships, based on data such as product information, user questions, order status, after-sales rules, logistics information, and customer service scripts.

[0003] Traditional construction processes tend to extract static knowledge from customer service corpora and rule texts. Similar text content is easily included in the same associated path. Category scope, fulfillment stage, signing cycle, voucher status and responsibility attribution lack joint verification at the current consultation time. Rule version changes are difficult to synchronize with the conversation scenario. Candidate answer criteria have overlapping conditions in the graph, edge relationships are confusing, there is a lack of isolation between different after-sales stages of the same order, and subsequent customer service search results have business condition deviations. Summary of the Invention

[0004] To address the technical problems existing in the prior art, embodiments of the present invention provide a method and system for constructing a knowledge graph in the e-commerce customer service domain empowered by a large model. The technical solution is as follows: On the one hand, it provides a method for constructing knowledge graphs in the e-commerce customer service domain empowered by large models, including the following steps: S1: Configure the server based on after-sales rules, obtain the text of the currently effective after-sales rules, compare the rule name with the matching items of the after-sales action code, filter the same category code in the platform category tree, adjust the voucher requirement to voucher identifier, and obtain the set of access codes; S2: Based on the access code set, call the order status code in the order information server, compare the order receipt time and the consultation time, determine the after-sales rule time period in which the consultation time is located, and obtain the consultation stage level; S3: Based on the consultation stage, obtain the user consultation text and customer service answer text, analyze the word tokens output by the large model inference service, filter the words related to after-sales actions and product categories, and obtain the customer service semantic code group; S4: Based on the customer service semantic code group, call the after-sales rule condition node in the access code set, compare the product category code matching item, determine the order status code and the signature period belonging item, and obtain the access conflict identifier; S5: Based on the access conflict identifier, compare the access markers of the customer service answer slot node and the after-sales rule condition node, determine the registration status of the slot access relationship edge, filter the node association records in the graph database, and obtain the graph construction status.

[0005] On the other hand, the access code set includes rule version number, category path code and voucher material identifier; the consultation stage level includes performance process stage, receipt cycle interval and after-sales application window; the customer service semantic code group includes appeal intent slot, product entity slot and voucher semantic slot; the access conflict identifier includes category exclusion type, performance status deviation and time period boundary mark; and the graph construction status includes node registration status, relationship edge registration status and rule version trace.

[0006] On the other hand, the steps for obtaining the admission code set are as follows: S101: Based on the after-sales rule configuration server, obtain the effective after-sales rule text, compare the rule name with the after-sales action code registration name, filter records with consistent name semantics, determine the correspondence between the rule version number and the action code, and obtain the action code version index; S102: Based on the action code version index, compare the product range words with the platform category tree level name, filter the same category code records, determine the order status conditions and the order status dictionary registration status, adjust the category code and order status code mapping records, and obtain the category process access chain. S103: Based on the category process access chain, compare the voucher requirement statement with the voucher material identifier, filter the material name matching record, determine the submission conditions and voucher registration mark attribution, adjust the rule version number and category path code mapping record, and obtain the access code set.

[0007] On the other hand, the specific steps for obtaining the consultation stage level are as follows: S201: Based on the access code set, call the order status code registration item, compare the two types of status code registration names and process node markers, filter records with consistent status codes, determine the after-sales entry to which the current process node of the order belongs, and obtain the process entry belonging item; S202: Based on the process entry attribution item, call the order receipt time and consultation time, compare the time sequence, determine whether the consultation time is in the pre-receipt stage or the post-receipt stage, adjust the process node and time sequence mark mapping record, and obtain the receipt consultation time sequence chain. S203: Based on the signed consultation time sequence chain, call the after-sales rule time period, compare the consultation time point with the start and end boundaries of the rule time period, filter the records with overlapping time periods, determine the order's after-sales stage, and obtain the consultation stage level.

[0008] On the other hand, the specific steps for obtaining the customer service semantic code group are as follows: S301: Based on the consultation stage, obtain the user consultation text and customer service answer text, analyze the return and exchange semantics in the consultation statement and the reply statement, compare the semantic mark with the registration name of the after-sales action field, filter the action hit record, and obtain the after-sales request semantic code. S302: Based on the after-sales request semantic code, call the large model inference service to output the word token, analyze the position of the product name before and after the word token, compare the product name word token with the registered name in the product category field, filter the category hit records, and obtain the product category semantic code. S303: Based on the product category semantic code, call the voucher submission status code registration content, analyze the submitted pending review and unsubmitted semantics in the text, compare the material submission semantics with the status code registration name, determine the voucher status attribution, and obtain the customer service semantic code group.

[0009] On the other hand, the steps for obtaining the access conflict identifier are as follows: S401: Based on the customer service semantic code group, call the access code set, compare the product category field with the product category code in the after-sales rule condition node, determine whether the category path level registration is consistent, filter out the category code mismatch records, and obtain the category exclusion type. S402: Based on the category exclusion type, compare the order status code with the access status code registration node, determine whether the process node falls within the after-sales action access range, and obtain the performance status deviation. S403: Based on the aforementioned performance status deviation, call the receipt period attribution record and after-sales rule period, compare the receipt period with the rule period boundary, determine whether the after-sales action registration period is consistent, and obtain the access conflict identifier.

[0010] On the other hand, the steps for obtaining the map construction status are as follows: S501: Based on the access conflict identifier, analyze the access markers in the customer service answer slot node and the after-sales rule condition node, compare the category exclusion record with the node registration content, determine the exclusion registration between the slot node and the condition node, adjust the access marker attribution, and obtain the node access verification marker. S502: Based on the node access verification mark, compare the registration content of slot access relationship edges in the graph database, determine the consistency between the start and end registration of the customer service answer slot node and the after-sales rule condition node, filter out conflicting relationship edges, and obtain the relationship edge registration status; S503: Based on the registration status of the relationship edges, analyze the associated records of the knowledge graph nodes, compare the node registration status with the rule version traces, determine the consistency between the associated records and the registration content, filter and verify inconsistent positions, and obtain the graph construction status.

[0011] On the other hand, the rule text refers to the after-sales processing rules that are currently in effect on the e-commerce platform, the rule name refers to the entry name of each after-sales rule in the configuration system, and the platform category tree refers to the product classification hierarchy maintained by the e-commerce platform, which identifies the category to which the product belongs.

[0012] On the other hand, the order status code refers to the current order process status code recorded in the order information server, and the slot node refers to the customer service answer semantic node formed by the customer service semantic code group in the knowledge graph.

[0013] On the other hand, it provides a knowledge graph construction system for the e-commerce customer service domain empowered by large models. This system applies to the knowledge graph construction method for the e-commerce customer service domain empowered by large models, including: The rule coding module is based on the after-sales rule configuration server. It obtains the text of the currently effective after-sales rule, compares the rule name with the after-sales action code matching items, filters the same category code in the platform category tree, adjusts the voucher requirement to the voucher identifier, and obtains the set of access codes. The stage determination module, based on the set of access codes, calls the order status code in the order information server, compares the order receipt time with the consultation time, determines the after-sales rule time period in which the consultation time is located, and obtains the consultation stage level. Based on the consultation stage, the semantic recognition module obtains the user's consultation text and the customer service's answer text, analyzes the word tokens output by the large model inference service, filters the words related to after-sales actions and product categories, and obtains the customer service semantic code group. The conflict determination module, based on the customer service semantic code group, calls the after-sales rule condition node in the access code set, compares the matching items of the product category code, determines the order status code and the attribution item of the signing period, and obtains the access conflict identifier. Based on the access conflict identifier, the graph construction module compares the access markers of the customer service answer slot node and the after-sales rule condition node, determines the registration status of the slot access relationship edge, filters the node association records in the graph database, and obtains the graph construction status.

[0014] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: By converting valid rules into access codes, generating consultation stage levels in conjunction with the order fulfillment process, generating customer service semantic code groups based on pre-trained language semantic recognition, and forming access conflict identifiers based on category, time period, and voucher conditions, the graph registration process only accepts nodes and relationship edges that have passed access verification. Invalid rule paths are compressed, the source of the response basis remains stable, different after-sales stages of the same order are isolated, and the human-machine question-and-answer deviation caused by business condition deviation is alleviated. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of the main steps of the present invention; Figure 2 This is a flowchart of steps S1 of the present invention; Figure 3 This is a flowchart of steps S2 of the present invention; Figure 4 This is a flowchart of steps S3 of the present invention; Figure 5 This is a flowchart of step S4 of the present invention; Figure 6 This is a flowchart of steps S5 of the present invention; Figure 7 This is a system block diagram of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0018] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0019] This invention provides a method for constructing a knowledge graph for e-commerce customer service empowered by a large model, such as... Figure 1 As shown, it includes the following steps: S1: Configure the server based on after-sales rules, obtain the text of the currently effective after-sales rules, compare the rule name with the matching items of the after-sales action code, filter the same category code in the platform category tree, determine the matching items of the status code in the order status dictionary, adjust the voucher requirement to the voucher identifier, and obtain the set of access codes. S2: Based on the set of admission codes, call the order status code in the order information server, compare the order receipt time with the consultation time, determine the intersection of the consultation time and the after-sales rule time period, filter the after-sales stage to which the order belongs, and obtain the consultation stage level; S3: Based on the consultation stage, obtain the user consultation text and customer service answer text, analyze the lexical tags output by the large model inference service, compare the lexical tags with the matching items of the after-sales action field, identify the related lexicals of the product category field, determine the mapping relationship between the voucher status description and the voucher submission status code, and obtain the customer service semantic code group. S4: Based on the customer service semantic code group, call the after-sales rule condition node in the access code set, compare the matching items of the product category code, determine the relationship between the order status code and the signing time period, filter and verify inconsistent positions, and obtain the access conflict identifier; S5: Based on the access conflict identifier, compare the access markers of the customer service answer slot node and the after-sales rule condition node to determine the registration status of the slot access relationship edge, filter the knowledge graph node association records in the graph database, and obtain the graph construction status.

[0020] The access code set includes rule version number, category path code and voucher material identifier; the consultation stage level includes the performance process stage, the signing cycle range and the after-sales application window; the customer service semantic code group includes the request intent slot, the product entity slot and the voucher semantic slot; the access conflict identifier includes category exclusion type, performance status deviation and time period boundary mark; the graph construction status includes node registration status, relationship edge registration status and rule version trace.

[0021] In S1, the rule text refers to the content of the after-sales processing rules currently in effect on the e-commerce platform, which originates from the after-sales rule configuration server; the rule name refers to the entry name of each after-sales rule in the configuration system, used to distinguish different after-sales processing rules; the after-sales action code refers to the result of after-sales actions such as returns, exchanges, refunds, repairs, replacements, and invoicing after being encoded by the system; the platform category tree refers to the product classification hierarchy maintained by the e-commerce platform, used to identify the category to which a product belongs; the order status dictionary refers to the data dictionary in which the e-commerce platform uniformly defines the order process status; the status code matching item refers to the status code that the order status condition in the after-sales rule matches in the order status dictionary; the voucher requirement refers to the provisions in the after-sales rule regarding the submission conditions of materials such as pictures, videos, invoices, and logistics documents; and the access code set refers to the code set transformed from rule conditions such as after-sales actions, product categories, order status, and voucher requirements.

[0022] In S2, the order status code refers to the current order process status code recorded in the order information server; the time period intersection refers to the judgment result that there is an overlap between the consultation time and the effective time range of the after-sales rules; the after-sales stage refers to the business stage of the order in the after-sales processing, such as the unshipped refund stage, the return stage after signing, and the warranty and repair stage; the consultation stage level refers to the consultation business stage obtained by combining the order status, signing time, consultation time, and after-sales rule time period.

[0023] In S3, lexical tags refer to the semantic categories marked after the large-scale model inference service segments the user inquiry text and customer service answer text; after-sales action fields refer to structured fields used to record after-sales action categories such as returns, exchanges, refunds, repairs, replacements, and invoicing; voucher status descriptions refer to the natural language content in the user inquiry text or customer service answer text regarding the voucher submission status; voucher submission status codes refer to the codes of voucher submission progress or review results recorded in the order after-sales system; and customer service semantic code groups refer to the encoding combinations transformed from the semantic content such as after-sales actions, product categories, and voucher status in the inquiry text and customer service answer text. The large-scale model inference service performs word segmentation, semantic tagging, and slot attribution identification on the user inquiry text and customer service answer text, and outputs lexical tags corresponding to the after-sales action field, product category field, and voucher status field. The large-scale model inference service can be implemented using a language model based on the Transformer architecture or a generative language model based on a self-attention mechanism.

[0024] In S4, the after-sales rule condition node refers to the node in the knowledge graph used to carry the applicable conditions of the after-sales rule; the verification inconsistency position refers to the field position where a conflict occurs when the customer service semantic code group and the admission code set are checked; the admission conflict identifier refers to the identifier used to record the conflict of conditions such as product category, order status, and receipt time.

[0025] In S5, a slot node refers to a customer service answer semantic node formed by a customer service semantic code group in the knowledge graph; an admission marker refers to a status marker indicating whether an association is allowed between a customer service answer slot node and an after-sales rule condition node; a relation edge registration status refers to the registration result of the admission relationship between a customer service answer slot node and an after-sales rule condition node; an association record refers to the knowledge graph node and relation edge record already formed in the graph database; and the graph construction status refers to the overall status result formed after the knowledge graph node and relation edge have been registered.

[0026] like Figure 2 As shown, the specific steps for obtaining the admission code set are as follows: S101: Based on the after-sales rule configuration server, obtain the effective after-sales rule text, compare the rule name with the after-sales action code registration name, filter records with consistent name semantics, determine the correspondence between the rule version number and the action code, and obtain the action code version index; The process involves retrieving the rule title, rule number, version number, action registration field, and release batch. The rule title is broken down into after-sales action terms, product-specific terms, time-specific terms, and voucher-specific terms. Then, each action term (return, exchange, refund, repair, reissue, invoicing, etc.) is compared with the action code registration name. During comparison, spaces, full-width characters, connectors, and synonyms are standardized. For example, if the rule title is "Repair after appliance receipt," and the action code registration name is "Repair," the action is considered consistent. If the rule title is "Clothing no-reason return," and the action code registration name is "Exchange," the action is considered inconsistent. Next, the rule version number and the applicable version range of the action code are checked. For example, if the rule version is V3.2, and the action code WX is applicable to versions V3.0 to V3.5, the record is retained. If the rule version is lower than the action code's enabled version, it is removed. For cases where the same rule matches multiple action codes, matching records are retained based on the position of the action term and the consistency of the registration name. For duplicate records, the record with the newer release batch is prioritized to obtain the action code version index.

[0027] S102: Based on the action code version index, compare the product range words with the platform category tree level name, filter the same category code records, determine the order status conditions and the order status dictionary registration status, adjust the category code and order status code mapping records, and obtain the category process access chain; The system retrieves the product scope terms, action codes, rule numbers, and version numbers. It then retrieves the first-level, second-level, third-level, and final-level category codes and start / stop flags from the platform's category tree. The product scope terms are broken down into main category terms, specification limiting terms, and exclusion limiting terms, and compared level by level with the category tree names. For example, if the product scope term is "mobile phone," the category tree "Digital—Mobile Communication—Mobile Phone" matches, and the final-level category code C010203 enters the candidate record. If the product scope term is "mobile phone accessories," but the rule limits the object to after-sales service for complete phones, then the category codes for data cables, chargers, and protective cases are removed. Next, the system reads the order status conditions and checks them against the registered status in the order status dictionary. For example, if the rule condition is "signed for," and the dictionary status code E40 corresponds to "buyer has signed for," then a mapping is established between category code C010203 and status code E40. If the status code is in a disabled state, the mapping is not performed. When both the parent category and the last category are matched, the code of the last category is retained first, and the parent category is registered as a path field to obtain the category flow admission chain.

[0028] S103: Based on the category process access chain, compare the voucher requirement statement with the voucher material identifier, filter the material name matching record, determine the submission conditions and voucher registration mark attribution, adjust the rule version number and category path code mapping record, and obtain the access code set; Retrieve the rule number, action code, version number, category path code, and order status code from the chained records; then locate the voucher requirement statement in the rule text, extracting the material name, submission action word, review action word, time period limitation word, and negation word. Next, retrieve the voucher material identifier table, checking each material name ("damaged photo," "logistics waybill," "invoice," "repair and inspection report," "outer packaging photo") against the registration identifier; for example, if the voucher requirement is "returns require uploading a photo of the shoe box exterior," and the shoe box exterior photo matches the outer packaging photo, it is registered as IMG Outsourcing. Submission conditions are marked according to textual attribution: "must upload" or "required" is marked as 1; "can be supplemented" or "recommended submission" is marked as 2; "no upload required" is marked as 0; and "submit after review" is marked as 3. If the rule statement matches the voucher registration identifier, it is written into the mapping record; if the registration form is optional but the rule statement is mandatory, it is not automatically registered. Finally, duplicates are removed based on rule version number, category path code, order status code, and material identifier, retaining the records with the newest release batches to obtain the set of access codes.

[0029] like Figure 3 As shown, the specific steps for obtaining a pricing level during the consultation phase are as follows: S201: Based on the access code set, call the order status code registration item, compare the two types of status code registration names and process node markers, filter records with the same status code, determine the after-sales entry to which the current process node of the order belongs, and obtain the process entry belonging item; Starting with the status access record in the access code set, the system obtains the rule version number, action code, category path code, access status code, and process node marker. Then, it reads the current order status code, status registration name, fulfillment node marker, and after-sales entry marker from the order status code registration item. The two types of status codes are first aligned item by item according to their codes. If both the access status code and the current order status code are E40, name verification is performed. If the access-side registration name is "Signed," and the order-side registration name is "Buyer Signed," both are grouped into the same signing node. If the access-side is E30 and the order-side is E40, even if both registration names contain the word "shipped," they are not registered as identical. Process node markers are read according to four categories: not shipped, in transit, signed, and transaction completed. "Not shipped" corresponds to a refund entry, "in transit" corresponds to a logistics interception entry, "signed" corresponds to a return / exchange entry, and "transaction completed" corresponds to a repair or resend entry. For example, if an order's current status code is E40, the fulfillment node is marked as 3, the category C020401 in the access code set corresponds to status code E40, and the action code TH corresponds to the return entry, then this order is selected for the status consistency record. If the same order has a status code of E20, a fulfillment node is marked as 1, but the access status code requirement is E40, then this record will not be included in the after-sales entry attribution judgment. Finally, the order number, action code, category path code, status code consistency mark, process node mark, and entry category are written into the same record to form the process entry attribution item.

[0030] S202: Based on the process entry attribution item, call the order receipt time and consultation time, compare the time sequence, determine whether the consultation time is in the pre-receipt stage or the post-receipt stage, adjust the process node and time sequence mark mapping record, and obtain the receipt and consultation time sequence chain. Based on the order process node in the process entry category, the system retrieves order receipt records, inquiry records, logistics node markers, and entry categories. When a receipt record exists, the receipt completion time is used as the boundary; for inquiry records, the time when the user first submitted a after-sales request is used as the comparison item. During comparison, the system first checks if the receipt field is empty. If the receipt field is empty and the process node is "not shipped" or "in transit," the inquiry time is classified as the pre-receipt stage. If the receipt field exists, the inquiry time is compared sequentially with the receipt completion time. For example, if an order receipt occurs at the 48th hour of fulfillment and the user inquiry occurs at the 50th hour of fulfillment (a 2-hour difference), the inquiry time is recorded as after receipt. If the user inquiry occurs at the 36th hour of fulfillment and the receipt occurs at the 48th hour of fulfillment, the inquiry time is recorded as before receipt. If the order process entry point is the logistics interception entry point, but the consultation time is later than the receipt completion time, the original "in transit" node will be changed to the "after receipt" node. If the order process entry point is the return / exchange entry point, but the receipt record is empty, this record will be registered as a time sequence inconsistency. Subsequently, the process node markers, along with the pre-receipt marker, post-receipt marker, and time sequence inconsistency marker, will be written into the mapping record item by item. For example, E40 corresponds to post-receipt marker 2, E30 corresponds to pre-receipt marker 1, and the abnormal status corresponds to marker 9, ultimately generating a receipt consultation time sequence chain.

[0031] S203: Based on the receipt consultation timeline chain, call the after-sales rule time period, compare the consultation time point with the start and end boundaries of the rule time period, filter the records with overlapping time periods, determine the order's after-sales stage, and obtain the consultation stage level; Based on the time sequence markers in the receipt and inquiry timeline, the system retrieves the action code, category path code, order status code, receipt and inquiry markers, and the inquiry time. Then, it retrieves the start boundary, end boundary, applicable action code, and applicable category path from the corresponding after-sales rule time period. During comparison, the system first aligns by action code: return actions are only checked against return time period records, and repair actions are only checked against repair time period records. Next, it aligns by category path: if the lowest-level category matches, the lowest-level time period is prioritized; if the lowest-level category is not registered, the time period of the higher-level path is read. For example, if the return rule for category C020401 is registered as day 0 to day 7 after receipt, and the order inquiry occurs on day 3 after receipt, the inquiry time falls within this time period and is registered as a time period overlap. If the inquiry occurs on day 10 after receipt, it is not included in the return time period overlap record. Pre-receipt inquiries are checked separately under two entry points: non-shipped refund and in-transit interception. Orders with status E20 and inquiries occurring before the shipment stage are registered as non-shipped refunds; orders with status E30 and inquiries occurring before receipt are registered as being processed in transit. For records matching multiple rule time periods, records with identical status codes are first selected, followed by records with deeper category paths. If both are still identical, the record with the action code matching the user's request is selected. Finally, the fulfillment process stage, receipt period, and after-sales application window are entered into the same record category to obtain the inquiry stage category.

[0032] like Figure 4 As shown, the specific steps for obtaining the customer service semantic code group are as follows: S301: Based on the consultation stage, obtain the user's consultation text and customer service answer text, analyze the return and exchange semantics in the consultation and reply statements, compare the semantic tags with the registration name of the after-sales action field, filter the action hit records, and obtain the after-sales request semantic code. The system retrieves the order number, action code candidates, fulfillment process stage, after-sales application window, user inquiry text, and customer service response text. The user inquiry text is broken down into several sentence fragments based on punctuation, interjections, and action words. The customer service response text is broken down into several reply fragments based on confirmation statements, guiding statements, rejection statements, and material prompt statements. Then, the system reads the action expressions such as return, exchange, refund, repair, reissue, and invoicing from each fragment, and groups colloquial expressions such as "want to return," "don't want it anymore," "send it back for replacement," "reissue one," and "repair it" to their corresponding action registration names. During comparison, the system first checks the action words in the inquiry fragment, then checks the action words in the response fragment. If a user says, "The shoe size is not right, can I exchange it for a pair?" and the customer service response is "you can apply for an exchange," then both "exchange a pair" and "exchange" point to the exchange registration name, the action hit count is 2, and it is registered as an exchange request. If a user says, "The product is damaged and I want to return it," and customer service replies, "You can submit photos for review first, and if they meet the requirements, you can return the product and get a refund," then both "return" and "return and refund" appear simultaneously. First, the after-sales application window in the consultation stage is read. If this window is registered as a return window after signing for receipt, the action is registered as a return and refund. If the window is registered as a warranty / repair window, repair is listed as a candidate action and a manual review mark is retained. For cases where both returns and exchanges occur simultaneously in the same conversation, the explicit action in the customer service's final reply is read. If the reply ends with "It is recommended to apply for an exchange," the exchange record is prioritized in the hit record. Finally, the order number, consultation stage, action registration name, hit segment position, and reply confirmation mark are written into the same semantic record to obtain the after-sales request semantic code.

[0033] S302: Based on the after-sales request semantic code, call the large model inference service to output the lexical token, analyze the position of the product name before and after the lexical token, compare the product name lexical token with the registered name in the product category field, filter the category hit records, and obtain the product category semantic code. The system retrieves the action registration name, the location of the matched statement, the user's inquiry text, the customer service answer text, and existing category path candidates. Then, it retrieves the lexical tagging table output by the large model inference service, reading the lexical content, lexical number, lexical category, preceding lexical, following lexical, and position within the sentence item by item. For the product name position, it first checks the five lexicals before and after the action word. If the action word is "return," the preceding lexicals are "this pair" and "sports shoes," and the following lexicals are "size" and "runs small," so "sports shoes" is registered as a product name candidate. If the text is "I don't want the phone case anymore, the phone is fine," then "phone case" and "phone" appear simultaneously. The system reads the nearest product lexical to the action word; "phone case" is one lexical away from "don't want," and "phone" is four lexical away from the action word, so "phone case" is selected as a candidate. The product name keywords are then compared level by level with the registered names in the product category field, starting with the lowest-level name and then the highest-level name. If the product keyword is "sports shoes" and the lowest-level registered name in the category field is also "sports shoes," then category code C020401 is matched. If the product keyword is "shoes" and also matches "sports shoes," "leather shoes," and "children's shoes," then supplementary keywords from the customer service response are read. If the response contains "shoe box" or "size," and the order category path candidate is C020401, then C020401 is selected. If the product keyword is "charger," but the order category path candidate is "mobile phone," then it is registered as a category inconsistency candidate. Finally, the action semantic code, product name keywords, registered category name, category path code, and matched position are written into the same record to obtain the product category semantic code.

[0034] S303: Based on the product category semantic code, call the voucher submission status code registration content, analyze the submitted pending review and unsubmitted semantics in the text, compare the material submission semantics with the status code registration name, determine the voucher status, and obtain the customer service semantic code group; The system retrieves the action registration name, category path code, order status code, material identifier candidate, user inquiry text, and customer service answer text. It then retrieves the voucher submission status code registration content, reading the status registration names and status codes for each item: submitted, pending review, not submitted, review rejected, and supplementary submission. During text processing, it first locates the material terminology, then reads the submission status expression from the six terms before and after the material terminology. If the user says, "The photo has been uploaded, and I'm still waiting for review," the material terminology is "photo," and the status expression is "uploaded" and "awaiting review." "Uploaded" is first registered as a submitted candidate, then "awaiting review" is registered as a pending review candidate, and finally, the status is confirmed as pending review based on the reply statement. If the customer service reply is, "The system has not received the damaged photo; please re-upload," then both "not received" and "re-upload" point to the unsubmitted status, and the registration status code is unsubmitted. If the user says, "The invoice has been replaced," and the customer service reply is, "Invoice information is under review," then the system first confirms the invoice voucher corresponding to "invoice information" according to the material identifier table, and then aligns "under review" with the pending review registration name. When comparing the semantic meaning of submitted materials with the registered status code, first check items with completely identical status words, then check items with synonyms. "Uploaded," "Transmitted," and "Submission Completed" are classified as submitted; "Not Uploaded," "Not Submitted," and "Not Received by System" are classified as unsubmitted; and "Under Review" and "Waiting for Platform Review" are classified as pending review. If the same material appears as both unsubmitted and submitted, read the last status description in the customer service response. If the last description is "Still need to supplement the logistics waybill," then classify it as unsubmitted. Finally, merge the request intent slot, product entity slot, and voucher semantic slot to obtain the customer service semantic code group.

[0035] like Figure 5 As shown, the specific steps for obtaining the access conflict identifier are as follows: S401: Based on the customer service semantic code group, call the admission code set, compare the product category field with the product category code in the after-sales rule condition node, determine whether the category path level registration is consistent, filter out records where the category code is not matched, and obtain the category exclusion type. The system retrieves the request action, product name keywords, product category semantic code, order category path, and voucher semantic slot. It then retrieves the category path code, rule condition node number, and category level marker under the same action code from the access code set. Category comparison first checks the last-level category code. If the product entity slot is registered as C010205 and the rule condition node is registered as C010203, the last-level codes are inconsistent. Next, it checks the parent path. If both belong to C0102, it's registered as a mismatch between the same parent's last-level code; if their parents are different, it's registered as a mismatch across parent levels. For example, if the user text is "I don't want the phone case anymore and want to return it," the product keyword matches "phone case," the customer service semantic code group is registered as C010205, and the access code set only registers the return action for the entire phone (C010203), then this record enters the mismatch set. If the user text is "Sneaker size is not suitable", and the product entity slot is registered as C020401, and the rule node is also registered as C020401, then this record will not enter the exclusion set. Hierarchical consistency is checked according to the number of path segments. If the first level hits but the last level is missing, it is registered as a generalization inconsistency of the upper level. If the last level hits but the order category is registered as another last level, it is registered as an order product inconsistency. Finally, the product terminology, semantic category code, admission category code, parent hit status, and last level hit status are written into the same conflict record to obtain the category exclusion type.

[0036] S402: Based on the category exclusion type, compare the order status code with the access status code registration node to determine whether the process node falls within the after-sales action access scope and obtain the performance status deviation. Obtain the current order status code, semantic action code, process node marker, category exclusion number, and admission status code registration node; then verify the order status code against the admission status code item by item. If the current order status is E20, the registration name is "Paid but Not Shipped," the semantic action code is "Refund," and the admission node is registered as E20 or E21, then the status is consistent. If the semantic action code corresponding to the same status is "Return," then read E40, which is required for the return action in the admission node. Since E20 is not currently within the admission scope, register it as an early process. If the current order status is E40, the registration name is "Buyer Has Signed for Received," the semantic action code is "Exchange," and the admission status node is registered as E40, then the process node falls within the admission scope. If the order status is E50, the registration name is "Transaction Completed," the semantic action code is "Refund Only," and the admission node only registers E20 and E30, then register it as a delayed process. Process nodes are registered as 1 to 5, where 1 represents unpaid, 2 represents paid but not shipped, 3 represents in transit, 4 represents signed for, and 5 represents completed transaction. The action access scope is directly read from the registered node: refunds correspond to 2 or 3, returns and exchanges correspond to 4, and repairs correspond to 5. Finally, items with consistent status codes, process ahead of schedule, process behind schedule, and action status mismatches are registered separately to obtain the performance status deviation.

[0037] S403: Based on the deviation in performance status, call the receipt period attribution record and the after-sales rule period, compare the receipt period with the rule period boundary, determine whether the after-sales action registration period is consistent, and obtain the access conflict identifier; The system retrieves the pre- and post-receipt markers, elapsed hours, inquiry node, and after-sales action code from the receipt and inquiry timeline chain. It then retrieves the start boundary, end boundary, action code, and category path from the after-sales rule time period. Time period comparison is first performed by aligning the action codes; for return actions, only the return time period is checked, and for repair actions, only the repair time period is checked. Next, alignment is performed by the category path; if the last-level path matches, the last-level boundary is used; otherwise, the boundary of the parent path is read. For example, if a return action is registered under category C020401 with a boundary of 0 to 168 hours, and the order inquiry occurs 96 hours after receipt, the time period is consistent; if the inquiry occurs 240 hours after receipt, it is registered as exceeding the end boundary. If the order is marked 1 before receipt, but the semantic action code is "return," and the rule time period requires a post-receipt marker 2, it is registered as a pre-receipt time period. If the order is marked 2 after receipt, but the semantic action code is "refund for non-delivery," and the rule entry only registers a pre-receipt marker 1, it is registered as a time period misalignment. For records of the same order that simultaneously have category exclusion, status deviation, and time period misalignment, write flag bits for the category, status, and time period fields respectively. Record 0 for no conflict and 1 for conflict, and finally merge them to form an access conflict identifier.

[0038] like Figure 6 As shown, the specific steps for obtaining the map construction status are as follows: S501: Based on the access conflict identifier, analyze the access markers in the customer service answer slot node and the after-sales rule condition node, compare the category exclusion record with the node registration content, determine the exclusion registration between the slot node and the condition node, adjust the access marker attribution, and obtain the node access verification marker. Obtain the slot node number, condition node number, appeal action code, product category code, order status code, time period flag, and conflict flag. Then, read the admission flags from both types of nodes. Admission flags are registered as 0, 1, 2, and 9, where 0 represents not registered, 1 represents admitted, 2 represents rejected, and 9 represents pending review. During verification, first check the category rejection records. If the customer service answer slot node is registered as "phone case return" with category code C010205, and the rule condition node is registered as "phone return" with category code C010203, and the parent path is the same but the final path is different, then the rejection registration is written as 2. If the customer service answer slot node is registered as "sports shoe exchange" with category code C020401, and the condition node is also C020401, and the status code and time period flag do not conflict, then the admission registration is written as 1. If a node in the same slot is associated with two condition nodes, the number of conflict bits is read first. If there are 0 conflict bits, the node is registered as admitted; if there are 1 to 2 conflict bits, it is registered as rejected; and if there are 3 conflict bits, it is registered as pending review. For example, if there are 1 item with a mismatched category, 1 item with a mismatched status, and 0 items with a consistent time period, the total number of conflict bits is 2, and the node is registered as rejected. Then, the node number, conflict source, original admission flag, and updated admission flag are written into the verification record to obtain the node admission verification flag.

[0039] S502: Based on the node admission verification mark, compare the registration content of slot admission relationship edges in the graph database, determine the consistency of the start and end registration of customer service answer slot nodes and after-sales rule condition nodes, filter out conflicting relationship edges, and obtain the relationship edge registration status; Obtain the customer service answer slot node number, after-sales rule condition node number, access flag, action code, category path code, and existing relation edge numbers in the graph database; then retrieve the relation edge registration content with the same start and end points in the graph database. During verification, first check if the start point number equals the customer service answer slot node number, then check if the end point number equals the after-sales rule condition node number; if the start point is N Customer Service 035, the end point is N Rule 122, and the graph database relation edge is also registered as N Customer Service 035 pointing to N Rule 122, then the start and end registrations are consistent. Next, verify the relation edge type: when the node access verification flag is 1, the relation edge type should be allowed access; when the flag is 2, the relation edge type should be excluded access; when the flag is 9, the relation edge type should be pending review. For example, consider a slot node "Damaged photo submitted" and a condition node "Return requires photo proof." The verification flag is 1, but if an existing relational edge in the graph database is registered as an exclusion, this edge enters the conflict set. If two relational edges of the same type exist for the same node pair, the record with the smaller edge number is retained, and the other is registered as a duplicate edge. If the start and end points are opposite, it is registered as an incorrect direction; if the start points are the same but the end point is missing, it is registered as a missing end point. Finally, normal edges, duplicate edges, incorrect direction edges, and edges of inconsistent types are registered separately to obtain the relational edge registration status.

[0040] S503: Based on the relationship edge registration status, analyze the knowledge graph node association records, compare the node registration status with the rule version traces, determine the consistency between the association records and the registration content, filter and verify inconsistent positions, and obtain the graph construction status; The process retrieves the registration status of slot nodes, condition nodes, relationship edges, rule version traces, action codes, category path codes, and voucher material identifiers. Then, it verifies each node's registration content against the rule version traces. Node registration status is recorded as 0, 1, or 2, where 0 represents not written, 1 represents written, and 2 represents written but replaced. If both the slot node and condition node are written, and the relationship edge is normal, then version verification begins. During version verification, the version number registered by the node and the version number of the rule condition node are read. If both are V3.2, the registration is consistent. If the slot node is still registered as V3.1, while the rule condition node is registered as V3.2, then it is considered a version inconsistency. For example, consider the customer service answer node "sports shoe exchange," with category path C020401, the same rule condition node path, and a relationship edge indicating allowed access. However, if the rule version trace is V3.2, while the slot node trace is V3.0, then this location is entered into the inconsistency verification set. If a node is not registered but a relational edge already exists, it is registered as an isolated edge; if a node is registered but a relational edge is missing, it is registered as a missing edge. Finally, the node registration status, relational edge registration status, version tracking status, and inconsistency verification locations are merged and written into the construction record to obtain the graph construction status.

[0041] like Figure 7 As shown, the knowledge graph construction system for e-commerce customer service empowered by a large model includes: The rule coding module is based on the after-sales rule configuration server. It obtains the text of the currently effective after-sales rule, compares the rule name with the after-sales action code matching items, filters the same category code in the platform category tree, adjusts the voucher requirement to the voucher identifier, and obtains the set of access codes. The stage determination module is based on the set of access codes. It calls the order status code in the order information server, compares the order receipt time with the consultation time, determines the after-sales rule time period in which the consultation time is located, and obtains the consultation stage level. The semantic recognition module is based on the consultation stage level, obtains user consultation text and customer service answer text, analyzes the word tokens output by the large model inference service, filters words related to after-sales actions and product categories, and obtains customer service semantic code groups. The conflict determination module is based on the customer service semantic code group. It calls the after-sales rule condition node in the access code set, compares the matching items of the product category code, determines the order status code and the attribution item of the signing time period, and obtains the access conflict identifier. The graph construction module compares the access conflict markers of customer service answer slot nodes with the access markers of after-sales rule condition nodes, determines the registration status of slot access relationship edges, filters the node association records in the graph database, and obtains the graph construction status.

[0042] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for constructing knowledge graphs in the e-commerce customer service domain empowered by large models, characterized by: The method includes: S1: Configure the server based on after-sales rules, obtain the text of the currently effective after-sales rules, compare the rule name with the matching items of the after-sales action code, filter the same category code in the platform category tree, adjust the voucher requirement to voucher identifier, and obtain the set of access codes; S2: Based on the access code set, call the order status code in the order information server, compare the order receipt time and the consultation time, determine the after-sales rule time period in which the consultation time is located, and obtain the consultation stage level; S3: Based on the consultation stage, obtain the user consultation text and customer service answer text, analyze the word tokens output by the large model inference service, filter the words related to after-sales actions and product categories, and obtain the customer service semantic code group; S4: Based on the customer service semantic code group, call the after-sales rule condition node in the access code set, compare the product category code matching item, determine the order status code and the signature period belonging item, and obtain the access conflict identifier; S5: Based on the access conflict identifier, compare the access markers of the customer service answer slot node and the after-sales rule condition node, determine the registration status of the slot access relationship edge, filter the node association records in the graph database, and obtain the graph construction status.

2. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 1, characterized in that, The access code set includes rule version number, category path code and voucher material identifier; the consultation stage level includes performance process stage, receipt period interval and after-sales application window; the customer service semantic code group includes appeal intent slot, product entity slot and voucher semantic slot; the access conflict identifier includes category exclusion type, performance status deviation and time period boundary mark; the graph construction status includes node registration status, relationship edge registration status and rule version trace.

3. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 2, characterized in that, The specific steps for obtaining the admission code set are as follows: S101: Based on the after-sales rule configuration server, obtain the effective after-sales rule text, compare the rule name with the after-sales action code registration name, filter records with consistent name semantics, determine the correspondence between the rule version number and the action code, and obtain the action code version index; S102: Based on the action code version index, compare the product range words with the platform category tree level name, filter the same category code records, determine the order status conditions and the order status dictionary registration status, adjust the category code and order status code mapping records, and obtain the category process access chain. S103: Based on the category process access chain, compare the voucher requirement statement with the voucher material identifier, filter the material name matching record, determine the submission conditions and voucher registration mark attribution, adjust the rule version number and category path code mapping record, and obtain the access code set.

4. The method for constructing a knowledge graph in the e-commerce customer service domain empowered by a large model according to claim 3, characterized in that, The specific steps for obtaining the consultation stage tier are as follows: S201: Based on the access code set, call the order status code registration item, compare the two types of status code registration names and process node markers, filter records with consistent status codes, determine the after-sales entry to which the current process node of the order belongs, and obtain the process entry belonging item; S202: Based on the process entry attribution item, call the order receipt time and consultation time, compare the time sequence, determine whether the consultation time is in the pre-receipt stage or the post-receipt stage, adjust the process node and time sequence mark mapping record, and obtain the receipt consultation time sequence chain. S203: Based on the signed consultation time sequence chain, call the after-sales rule time period, compare the consultation time point with the start and end boundaries of the rule time period, filter the records with overlapping time periods, determine the order's after-sales stage, and obtain the consultation stage level.

5. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 4, characterized in that, The specific steps for obtaining the customer service semantic code group are as follows: S301: Based on the consultation stage, obtain the user consultation text and customer service answer text, analyze the return and exchange semantics in the consultation statement and the reply statement, compare the semantic mark with the registration name of the after-sales action field, filter the action hit record, and obtain the after-sales request semantic code. S302: Based on the after-sales request semantic code, call the large model inference service to output the word token, analyze the position of the product name before and after the word token, compare the product name word token with the registered name in the product category field, filter the category hit records, and obtain the product category semantic code. S303: Based on the product category semantic code, call the voucher submission status code registration content, analyze the submitted pending review and unsubmitted semantics in the text, compare the material submission semantics with the status code registration name, determine the voucher status attribution, and obtain the customer service semantic code group.

6. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 5, characterized in that, The specific steps for obtaining the access conflict identifier are as follows: S401: Based on the customer service semantic code group, call the access code set, compare the product category field with the product category code in the after-sales rule condition node, determine whether the category path level registration is consistent, filter out the category code mismatch records, and obtain the category exclusion type. S402: Based on the category exclusion type, compare the order status code with the access status code registration node, determine whether the process node falls within the after-sales action access range, and obtain the performance status deviation. S403: Based on the aforementioned performance status deviation, call the receipt period attribution record and after-sales rule period, compare the receipt period with the rule period boundary, determine whether the after-sales action registration period is consistent, and obtain the access conflict identifier.

7. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 6, characterized in that, The specific steps for obtaining the map construction status are as follows: S501: Based on the access conflict identifier, analyze the access markers in the customer service answer slot node and the after-sales rule condition node, compare the category exclusion record with the node registration content, determine the exclusion registration between the slot node and the condition node, adjust the access marker attribution, and obtain the node access verification marker. S502: Based on the node access verification mark, compare the registration content of slot access relationship edges in the graph database, determine the consistency between the start and end registration of the customer service answer slot node and the after-sales rule condition node, filter out conflicting relationship edges, and obtain the relationship edge registration status; S503: Based on the registration status of the relationship edges, analyze the associated records of the knowledge graph nodes, compare the node registration status with the rule version traces, determine the consistency between the associated records and the registration content, filter and verify inconsistent positions, and obtain the graph construction status.

8. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 1, characterized in that, The rule text refers to the after-sales processing rules currently in effect on the e-commerce platform. The rule name refers to the entry name of each after-sales rule in the configuration system. The platform category tree refers to the product classification hierarchy maintained by the e-commerce platform, which identifies the category to which the product belongs.

9. The method for constructing a knowledge graph for e-commerce customer service empowered by a large model according to claim 1, characterized in that, The order status code refers to the current order process status code recorded in the order information server, and the slot node refers to the customer service answer semantic node formed by the customer service semantic code group in the knowledge graph.

10. A large-model-enabled knowledge graph construction system for e-commerce customer service, the system being used to implement the large-model-enabled knowledge graph construction method for e-commerce customer service as described in any one of claims 1-9, characterized in that, The system includes: The rule coding module is based on the after-sales rule configuration server. It obtains the text of the currently effective after-sales rule, compares the rule name with the after-sales action code matching items, filters the same category code in the platform category tree, adjusts the voucher requirement to the voucher identifier, and obtains the set of access codes. The stage determination module, based on the set of access codes, calls the order status code in the order information server, compares the order receipt time with the consultation time, determines the after-sales rule time period in which the consultation time is located, and obtains the consultation stage level. Based on the consultation stage, the semantic recognition module obtains the user's consultation text and the customer service's answer text, analyzes the word tokens output by the large model inference service, filters the words related to after-sales actions and product categories, and obtains the customer service semantic code group. The conflict determination module, based on the customer service semantic code group, calls the after-sales rule condition node in the access code set, compares the matching items of the product category code, determines the order status code and the attribution item of the signing period, and obtains the access conflict identifier. Based on the access conflict identifier, the graph construction module compares the access markers of the customer service answer slot node and the after-sales rule condition node, determines the registration status of the slot access relationship edge, filters the node association records in the graph database, and obtains the graph construction status.

Images