A ticket request processing method, device, equipment and medium
By extracting keywords from ticketing request processing and querying the knowledge base for semantic parsing and compliance verification, the problems of low efficiency and insufficient intelligence in ticketing processing are solved, achieving automated and efficient ticketing processing.
Patent Information
- Application Number
- CN202611100069.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-23
- Publication Date
- 2026-08-25
AI Technical Summary
Existing technologies suffer from low ticketing processing efficiency, unintelligent processing methods, and poor results, especially in addressing complex ticketing issues.
By extracting multiple ticketing keywords from the ticketing request to be processed, querying the rule information in the preset ticketing processing knowledge base, performing semantic parsing and operation compliance verification, generating ticketing request processing text, and automatically parsing and generating processing text corresponding to the ticketing request to be processed.
Without requiring manual intervention, it improves the efficiency and intelligence of ticketing processing, ensures processing results, and achieves automated and accurate ticketing.
Smart Images

Figure CN122633862A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of data processing technology, specifically relating to a ticket request processing method, apparatus, device, and medium. Background Technology
[0002] With the rapid development of urban rail transit, the daily passenger flow of public transportation such as subways and buses is gradually increasing. As a core link in passenger service, ticketing processing efficiency and accuracy directly affect the travel experience of passengers and the service effectiveness of operating companies.
[0003] In existing technologies, ticketing processing mainly relies on human customer service and self-service ticketing terminals such as automatic ticket vending machines and automatic ticket gates. However, human customer service suffers from limited service hours and low efficiency, while self-service ticketing terminals cannot handle complex ticketing issues and suffer from insufficient intelligence and poor processing results. Summary of the Invention
[0004] This application provides a ticketing request processing method, apparatus, device, and medium, which solves the problems of low ticketing processing efficiency, insufficient intelligence, and poor processing effect in the prior art. By extracting multiple ticketing keywords from the ticketing request to be processed to query ticketing processing rule information, and verifying the compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target, the corresponding ticketing processing interface identifier is determined, and ticketing request processing text is generated. This can automatically parse and generate ticketing processing text corresponding to the ticketing request to be processed without manual intervention, thereby improving the efficiency and intelligence of ticketing processing and ensuring the processing effect.
[0005] In a first aspect, embodiments of this application provide a ticketing request processing method, the method comprising: Get the ticketing requests to be processed, extract multiple ticketing keywords from the ticketing requests to be processed, and query the ticketing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base; Semantic parsing is performed on the ticketing requests to be processed to obtain the ticketing processing target, and the operation compliance of the ticketing processing target is verified based on the operable information in the ticketing processing rules information and the target operation information in the ticketing processing target; If the operation compliance verification of the ticketing processing target passes, the ticketing processing target is matched with the preset processing interface identifier database to obtain the ticketing processing interface identifier; The ticket request processing text is generated based on the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier.
[0006] Furthermore, the operable information includes multiple operable items and the corresponding operable permissions for each operable item; Based on the operable information in the ticketing processing rules and the target operation information in the ticketing processing target, the compliance of the ticketing processing target is verified, including: Identify the operable attributes of each operable item in the ticketing processing rule information, and group multiple operable items according to the operable attributes to obtain multiple operable item sets; Calculate the union of the operable permissions corresponding to multiple operable items in each operable set to obtain the operable permission range corresponding to each operable set; Based on the target operation information in the ticketing processing target, determine the target operation item corresponding to the ticketing processing target, and determine the target operation attribute and target operation permission corresponding to the target operation item; Based on the target operation attributes, operable attributes, operable permission scope, and target operation permissions, the operation compliance of the target operation item is verified to obtain the operation compliance verification result of the ticketing processing target.
[0007] Furthermore, based on the target operation attributes, operable attributes, operable permission scope, and target operation permissions, the target operation item is subjected to operation compliance verification to obtain the operation compliance verification result of the ticketing processing target, including: Perform an operation attribute consistency check on the target operation attribute and the corresponding operation attributes of each operation set, and determine the target operation set to which the target operation item belongs based on the operation attribute consistency check result; Determine the target operable set corresponding to the target operable permission range based on the operable permission range, and determine whether the target operation permission is within the target operable permission range; If the target's operation permissions are within the scope of its operable permissions, the compliance verification of the ticketing processing target's operation is confirmed to be successful.
[0008] Furthermore, the ticketing processing objectives include target operation attributes, target business scenarios, and target operation permissions; The ticketing processing target is matched with the preset processing interface identifier database to obtain the ticketing processing interface identifier, including: The target operation attributes, target business scenarios, and target operation permissions are combined and encoded according to the preset feature code structure to generate the ticketing processing target feature code; Calculate the similarity between the target feature code for ticketing processing and each candidate feature code in the preset feature code interface mapping database, and use the interface identifier corresponding to the candidate feature code with the highest similarity as the corresponding ticketing processing interface identifier.
[0009] Furthermore, semantic parsing is performed on the ticketing requests to be processed to obtain the ticketing processing targets, including: Semantic parsing is performed on the ticketing requests to be processed, and the semantic integrity of the semantic parsing results is verified based on the preset complete semantic necessary information; If the semantic parsing result is incomplete, a clarification text is generated according to the preset question template and sent to the ticketing processing terminal to guide the user to supplement the necessary information. Obtain the necessary information, and based on the necessary information, perform semantic completion on the semantic parsing results to obtain the ticketing processing target.
[0010] Furthermore, the preset ticketing processing knowledge base includes multiple candidate ticketing processing rule information; Query the ticketing processing rules information corresponding to multiple ticketing keywords in the preset ticketing processing knowledge base, including: Identify multiple rule keywords in the ticketing processing rule information of each candidate; Calculate the keyword overlap between multiple ticketing keywords and multiple rule keywords in each candidate ticketing processing rule information, and take the candidate ticketing processing rule information with the highest keyword overlap as the ticketing processing rule information corresponding to the ticketing request to be processed.
[0011] Furthermore, after generating the ticket request processing text based on the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier, the method also includes: The system aggregates the ticketing requests to be processed and the ticketing request processing text, and generates a ticketing processing knowledge vector based on the aggregation results. Calculate the vector similarity between the ticketing processing knowledge vector and each historical ticketing processing knowledge vector in the preset ticketing processing knowledge base; If the vector similarity is less than the preset association similarity threshold, the aggregation result is added to the preset ticketing processing knowledge base according to the preset ticketing processing knowledge format for incremental updates to the preset ticketing processing knowledge base.
[0012] Secondly, embodiments of this application provide a ticketing request processing apparatus, the apparatus comprising: The processing rule query module is used to obtain ticket requests to be processed, extract multiple ticket keywords from the ticket requests to be processed, and query the ticket processing rule information corresponding to the multiple ticket keywords in the preset ticket processing knowledge base; The target verification module is used to perform semantic parsing on the ticketing request to be processed, obtain the ticketing processing target, and verify the operation compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target. The processing interface determination module is used to match the ticket processing target with the preset processing interface identifier database to obtain the ticket processing interface identifier after the operation compliance verification of the ticket processing target has passed. The ticketing processing module is used to generate ticketing request processing text based on the ticketing request to be processed, ticketing processing rule information, and ticketing processing interface identifier.
[0013] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.
[0014] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.
[0015] Fifthly, embodiments of this application also provide a computer program product comprising a computer program stored in a computer-readable storage medium, wherein at least one processor of the device reads from the computer-readable storage medium and executes the computer program, causing the device to perform the method described in the first aspect.
[0016] In this embodiment, a ticketing request to be processed is obtained, multiple ticketing keywords are extracted from the request, and ticketing rule information corresponding to the multiple ticketing keywords is queried from a preset ticketing processing knowledge base. The ticketing request is semantically parsed to obtain a ticketing processing target, and the operational compliance of the target is verified based on the operable information in the ticketing rule information and the target operation information in the target. If the operational compliance verification of the target passes, the target is matched with a preset processing interface identifier database to obtain a ticketing processing interface identifier. A ticketing request processing text is generated based on the ticketing request to be processed, the ticketing rule information, and the ticketing processing interface identifier. The above-described ticketing request processing method solves the problems of low efficiency, lack of intelligence, and poor processing results in existing technologies. By extracting multiple ticketing keywords from the ticketing request to be processed to query ticketing processing rule information, and verifying the compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target, the method determines the corresponding ticketing processing interface identifier and generates ticketing request processing text. This method can automatically parse and generate ticketing processing text corresponding to the ticketing request to be processed without manual intervention, thereby improving the efficiency and intelligence of ticketing processing and ensuring the processing effect. Attached Figure Description
[0017] Figure 1 This is a flowchart of a ticket request processing method provided in an embodiment of this application; Figure 2 This is a flowchart of a ticketing processing target determination method provided in an embodiment of this application; Figure 3 This is a flowchart of a ticketing processing target operation compliance verification method provided in an embodiment of this application; Figure 4 This is a structural block diagram of a ticket request processing device provided in an embodiment of this application; Figure 5 This is a structural block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application are described in detail below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. Furthermore, it should be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.
[0019] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.
[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0021] Firstly, this solution can be used in scenarios involving ticket purchase, usage, and inquiry, particularly in urban rail transit such as subways and buses. By extracting multiple ticketing keywords from the ticket request to be processed, it queries ticketing processing rules. Based on the operable information in the ticketing rules and the target operation information in the ticketing target, it performs operational compliance verification on the ticketing target, determines the corresponding ticketing processing interface identifier, and generates the ticket request processing text. This allows for automatic parsing and generation of the ticketing processing text corresponding to the ticket request without manual intervention, improving the efficiency and intelligence of ticketing processing and ensuring effective processing.
[0022] Based on the above usage scenarios, it is understood that the execution subject of each step in this solution can be a computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as a PC (Personal Computer) or other terminal devices, or a server or other devices. This application embodiment does not limit this.
[0023] The following description, in conjunction with the accompanying drawings, details a ticketing request processing method, apparatus, device, and medium provided in this application through specific embodiments and application scenarios.
[0024] Figure 1 This is a flowchart of a ticket request processing method provided in an embodiment of this application. Figure 1 As shown, the method is applied to a base station and specifically includes the following steps: S101, obtain the ticketing request to be processed, extract multiple ticketing keywords from the ticketing request to be processed, and query the ticketing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base.
[0025] The pending ticketing requests can be instructions related to ticketing services input by users via voice or text through a smart customer service terminal. Examples include: "I want to buy a ticket," "My card can't exit the station," "How do I top up my card," and "Why am I being charged?" Ticketing keywords can be core terms extracted from the pending ticketing requests that represent the intent of the ticketing service. Examples include: "buy ticket," "purchase ticket," "single-journey ticket," "station," "ticket card," "top up," and "amount." The pre-built ticketing processing knowledge base can be a structured or vectorized database that pre-constructs and stores subway ticketing service rules. This knowledge base includes ticketing policies, fare rules, entry / exit verification rules, ticket card top-up, unlocking, supplementary fare, and refund rules, executable operations, permission scope, and constraints. Ticketing rule information can be rules matched from the pre-built ticketing processing knowledge base used to process pending ticketing requests. Examples include: ticket purchase rules, top-up rules, unlocking rules, query rules, and risk control rules.
[0026] In one embodiment, obtaining a ticketing request to be processed and extracting multiple ticketing keywords from it can be done by: receiving the ticketing request from the user through an interaction interface, identifying business entities, action intentions, and scenario-specific words in the request using semantic feature extraction, filtering the identified words for semantic validity and business relevance, and removing redundant modifying words without actual business semantics to obtain multiple core words that can be used to accurately locate or describe the business intention of ticketing processing as multiple ticketing keywords. Querying the ticketing rule information corresponding to the multiple ticketing keywords in a preset ticketing processing knowledge base can be done by: identifying multiple rule keywords in each candidate ticketing rule information; calculating the keyword overlap between the multiple ticketing keywords and the multiple rule keywords in each candidate ticketing rule information, and using the candidate ticketing rule information with the highest keyword overlap as the ticketing rule information corresponding to the ticketing request to be processed. The preset ticketing processing knowledge base includes multiple candidate ticketing rule information.
[0027] The candidate ticketing processing rule information can be multiple independent and complete ticketing business rule entries pre-stored in a preset ticketing processing knowledge base. Each candidate ticketing processing rule corresponds to a fixed ticketing business scenario and includes complete rule content such as operable items, operable permissions, business constraints, and processing conditions under that business. Examples include: ticket purchase business rule information, ticket card recharge business rule information, ticket card abnormal exit unlocking rule information, overdue / over-distance ticket replacement rule information, and ticket refund rule information. Rule keywords can be characteristic words representing the business scope and restricted functions of the corresponding candidate rule. For example, the rule keywords for a ticket purchase candidate rule are: ticket purchase, one-way ticket, departure station, arrival station, and ticket price; the rule keywords for a recharge candidate rule are: ticket card, recharge, recharge amount, and account balance. Keyword overlap can be defined as the percentage of identical or semantically similar words that overlap between multiple ticketing keywords extracted from the user side and multiple rule keywords in each candidate ticketing processing rule information. It is used to quantify the degree of business fit between the current ticketing request to be processed and each candidate ticketing processing rule information. The higher the overlap, the stronger the business requirements and rule adaptability.
[0028] In one embodiment, identifying multiple rule keywords in each candidate ticketing processing rule information can be achieved by: segmenting and semantically analyzing the text content of each candidate ticketing processing rule information, extracting business type terms, operation action terms, business entity terms, and scenario constraint terms, and removing invalid terms such as conjunctions, modifiers, and interjections without business meaning or constraint function, thus obtaining multiple rule keywords corresponding to each candidate ticketing processing rule information. Calculating the keyword overlap between multiple ticketing keywords and multiple rule keywords in each candidate ticketing processing rule information can be achieved by: comparing the multiple ticketing keywords corresponding to the ticketing request to be processed with the rule keywords of each candidate ticketing processing rule information, counting the number of overlapping keywords, and calculating the ratio of the number of overlapping keywords to the total number of all ticketing keywords, thus obtaining the keyword overlap between the ticketing request to be processed and each candidate ticketing processing rule information. One way to use the candidate ticketing rule information with the highest keyword overlap as the ticketing rule information corresponding to the ticketing request to be processed is to compare the keyword overlap of all candidate ticketing rule information and use the candidate ticketing rule information with the highest keyword overlap value as the ticketing rule information that is exactly matched with the current ticketing request to be processed.
[0029] This solution identifies rule keywords in candidate ticketing rules within a pre-defined ticketing knowledge base and calculates the keyword overlap between the ticketing keywords of the ticketing request to be processed and the keywords of each candidate rule. It then selects the candidate ticketing rules with the highest overlap as the matching rules. This enables automated quantitative comparison and precise filtering of massive candidate ticketing rules, eliminating the drawbacks of traditional rough matching with single keywords. It effectively improves the matching degree between ticketing rules and actual user requests, reduces rule mismatches and omissions, and enhances the automation level and processing efficiency of rule retrieval and matching.
[0030] S102, perform semantic parsing on the ticketing request to be processed to obtain the ticketing processing target, and perform operation compliance verification on the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target.
[0031] Semantic parsing involves semantically breaking down the text or voice content of the ticketing request to be processed, identifying intent, and extracting information elements to uncover the business needs, operational intentions, and scenario-related elements contained in the request. The ticketing processing target can be information describing the user's ticketing business processing request, including key information elements such as the specific operation the user needs to perform, the relevant business scenario, and the required permissions. For example, if a user's pending ticketing request is "My card can't be used to exit," semantic parsing determines the corresponding ticketing processing target to be "Ticket card abnormality, exit failure, application for unlocking access." Operable information can be information in the ticketing processing rules used to define the scope of business operations, including multiple operable items and the corresponding operable permissions, used to define the types of ticketing operations and permission ranges allowed when using ticketing processing rules. Target operation information can be information related to the operation to be executed, parsed from the ticketing processing target, including the target operation item, target operation attribute, and target operation permission. Operational compliance verification can be based on the operable information of the ticketing processing rules, and perform attribute matching, set classification, and permission scope comparison with the target operation information of the ticketing processing target to determine whether the target operation to be executed complies with the operation allowed by the rules and the operation required by the permissions.
[0032] In one embodiment, semantic parsing of the ticketing request to be processed yields the ticketing processing target in the following manner: Figure 2 As shown. Figure 2 This is a flowchart of a ticketing processing target determination method provided in an embodiment of this application. Figure 2 As shown, the specific steps include the following: S201, perform semantic parsing on the ticketing request to be processed, and perform semantic integrity verification on the semantic parsing result based on the preset complete semantic necessary information.
[0033] The preset essential semantic information can be pre-defined, fixed information that constitutes an indispensable part of a complete ticketing business request, used to determine the ticketing processing target. Examples include: ticketing operation type, ticket identification information, site information, business scenario information, and transaction amount information. The absence of any one of these elements will prevent accurate identification of the ticketing processing target corresponding to the ticketing request. Semantic integrity verification can be a process used to determine whether the semantic information of the ticketing request is missing and whether the user needs to be guided to supplement information. This includes comparing the semantic elements obtained from parsing the ticketing request with the preset essential semantic information item by item to determine whether the current semantic parsing result covers all the preset essential semantic information.
[0034] In one embodiment, the semantic parsing of the ticketing request to be processed can be performed as follows: semantic decomposition, intent recognition, and element extraction are performed on the received text or speech-converted text content of the ticketing request to be processed, identifying business information elements such as business operation type, business entity, business scenario, and constraints, forming a structured semantic parsing result. The semantic integrity verification of the semantic parsing result based on preset complete semantic necessary information can be performed as follows: the identified business information elements in the semantic parsing result are extracted, and the identified business information elements are matched one by one with all the necessary information elements included in the preset complete semantic necessary information. The missing necessary information elements in the current semantic parsing result are counted. If no missing necessary information elements are found, the semantic parsing result is determined to be semantically complete; if missing necessary information elements are found, the semantic parsing result is determined to be semantically incomplete.
[0035] S202, if the semantics of the semantic parsing result is incomplete, generate a clarification text for the rhetorical question according to the preset rhetorical question template, and send the clarification text to the ticketing processing terminal to guide the user to supplement the necessary information.
[0036] Semantic incompleteness can refer to situations where the semantic parsing result fails to cover all essential elements of the pre-defined complete semantic information, resulting in missing key business information. This makes it impossible to uniquely determine the user's true ticketing intention or directly proceed with subsequent business processing. For example, including only the business operation type information "recharge" but lacking the business entities "ticket information" and "recharge amount" constitutes semantic incompleteness. Pre-defined question templates are standardized question templates pre-configured for different types of missing information, specifically designed to ask users about missing business elements. Examples include question templates corresponding to missing amounts, missing stations, and missing ticket information. Clarification text can be a targeted question generated by calling the corresponding pre-defined question template and combining it with the currently missing essential information. This is used to accurately point out the missing content to the user and guide them to complete the information. Examples include: "How much do you need to recharge?" and "What is your departure station?". Ticketing processing terminals are interactive devices where users initiate ticketing requests, receive system question scripts, and can input supplementary information, including intelligent customer service terminals, subway self-service terminals, and mobile customer service mini-program terminals. Necessary information can be key business elements that exist in the pre-defined complete semantic necessary information but are missing in the ticketing request to be processed. It is the information that must be supplemented to complete the user's ticketing request and form a complete and identifiable ticketing processing target, such as ticket number, recharge amount, departure station, arrival station, business processing scenario, etc.
[0037] In one embodiment, when the semantics of the semantic parsing result is incomplete, generating a clarification text according to a preset question template and sending the clarification text to the ticketing processing terminal to guide the user to supplement the necessary information can be done by: identifying the specific type of necessary information missing in the semantic parsing result, matching the preset question template corresponding to the missing information type, filling the preset question template with the missing necessary information, generating a targeted clarification text, and pushing the generated clarification text to the corresponding ticketing processing terminal for display, so as to prompt and guide the user to supplement the missing necessary information.
[0038] S203, Obtain necessary information, and perform semantic completion on the semantic parsing results based on the necessary information to obtain the ticketing processing target.
[0039] In one embodiment, obtaining necessary information and semantically completing the semantic parsing result based on the necessary information to obtain the ticketing processing target can be: receiving necessary business information supplemented by the user and filling the necessary information into the semantic parsing result where there is missing information, supplementing the missing business elements, and generating a ticketing processing target with complete information and elements.
[0040] The technical solution provided in this application performs semantic parsing on ticketing requests and verifies the completeness of the parsing results based on preset essential semantic information. This allows for the rapid identification of key business elements missing in user ticketing requests. When the semantic parsing results are incomplete, a clarification text is automatically generated using a preset question template and sent to the ticketing processing terminal. This standardizes and accurately guides users to actively fill in the missing essential information. By acquiring the supplementary essential information from the user and supplementing and improving the original semantic parsing results, a complete and semantically sound ticketing processing target is ultimately formed. This effectively avoids ticketing parsing deviations and misjudgments in business processing caused by incomplete user requests or missing key information, thereby improving the completeness, accuracy, and intelligent interactive processing capabilities of ticketing request semantic parsing.
[0041] In one embodiment, the method for verifying the operational compliance of a ticketing processing target based on the operable information in the ticketing processing rules information and the target operational information in the ticketing processing target is as follows: Figure 3 As shown. Figure 3 This is a flowchart illustrating a method for verifying the compliance of ticketing processing target operations, as provided in an embodiment of this application. Figure 3 As shown, the operable information includes multiple operable items and the corresponding operable permissions for each operable item, specifically including the following steps: S301, identify the operable attributes of each operable item in the ticketing processing rule information, group multiple operable items according to the operable attributes, and obtain multiple operable item sets.
[0042] Among them, operable items can be the operations allowed to be performed on the pending ticketing request when the ticketing processing rule is applied, as included in the ticketing processing rule information. Examples include: ticket purchase, ticket card top-up, ticket card unlocking due to abnormality, ticket replacement for exceeding time or travel limits, refund of business information, and ticket inquiry. Operable permissions can be the access conditions, processing restrictions, transaction limits, scenario constraints, and identity permission requirements corresponding to each operable item, used to define the allowed processing boundaries of the corresponding operable item. Operable attributes can be categorized labels for each operable item according to business function and business type, used to represent the business category to which the operable item belongs. Examples include: transaction attributes, inquiry attributes, appeal unlocking attributes, and refund settlement attributes. An operable item set can be a grouped set formed by grouping multiple operable items with the same business attribute together, where all operable items within the same operable item set share the same business attribute.
[0043] In one embodiment, identifying the operable attributes of each operable item in the ticketing processing rule information can be achieved by: reading each operable item contained in the ticketing processing rule information one by one, and matching corresponding operable attributes to each operable item based on its business function and business type. Grouping multiple operable items according to their operable attributes to obtain multiple operable item sets can be achieved by: grouping multiple operable items with the same operable attribute into the same group, with each attribute group forming a corresponding operable item set, ultimately resulting in multiple operable item sets corresponding to different business attributes.
[0044] S302, calculate the union of the operable permissions corresponding to multiple operable items in each operable set to obtain the operable permission range corresponding to each operable set.
[0045] In one embodiment, the method for calculating the union of operable permissions corresponding to multiple operable items in each operable set to obtain the operable permission range corresponding to each operable set can be as follows: extract all operable permission constraint entries corresponding to each operable item in the same operable item set, classify and sort all operable permission constraint entries in the set, take the union of the ranges of the same type of permission restrictions, retain all compatible access conditions, processing time periods, quota ranges and scenario permission ranges, and eliminate duplicate and redundant permission constraints within the set to obtain the corresponding operable permission range for each operable set.
[0046] S303, determine the target operation item corresponding to the ticketing processing target based on the target operation information in the ticketing processing target, and determine the target operation attribute and target operation permission corresponding to the target operation item.
[0047] The target operation item can be the specific ticketing operation that the user needs to perform, parsed from the target operation information. Examples include: purchasing tickets, recharging ticket cards, unlocking tickets after abnormal exits, purchasing replacement tickets, inquiring about services, and requesting refunds. The target operation attribute can be the operation category obtained by classifying the target operation item according to its corresponding function. For example, if the target operation item is ticket card recharging, the corresponding target operation attribute is "funds transaction." The target operation permission can be the permission requirements such as access identity, processing conditions, quota limits, and scenario permissions required to perform the target operation item.
[0048] In one embodiment, determining the target operation item corresponding to the ticketing processing target based on the target operation information in the ticketing processing target can be done by: performing intent recognition on the target operation information in the ticketing processing target based on a pre-trained intent recognition model to obtain target operation intent information; matching the target operation intent information with a preset ticketing operation item database to obtain the target operation item matching the ticketing processing target. The preset ticketing operation item database can be a pre-set database representing the correspondence between operation intent information and operation items. In one embodiment, determining the target operation attribute and target operation permission corresponding to the target operation item can be done by: determining the operation function of the target operation item based on the correspondence between preset operation items and operation functions; classifying and matching the operation functions according to preset operation function categories to obtain the target operation attribute corresponding to the target operation item; and determining the operation permission required to execute the target operation item based on the correspondence between preset operation items and operation permissions to obtain the target operation permission.
[0049] S304. Based on the target operation attributes, operable attributes, operable permission scope, and target operation permissions, perform operation compliance verification on the target operation item to obtain the operation compliance verification result of the ticketing processing target.
[0050] In one embodiment, the operation compliance verification of the target operation item is performed based on the target operation attribute, operable attribute, operable permission scope, and target operation permission to obtain the operation compliance verification result of the ticketing processing target. This can be achieved by: performing an operation attribute consistency verification between the target operation attribute and the operable attribute corresponding to each operable set, and determining the target operable set to which the target operation item belongs based on the operation attribute consistency verification result; determining the target operable permission scope corresponding to the target operable set based on the operable permission scope, and determining whether the target operation permission is within the target operable permission scope; and determining that the operation compliance verification of the ticketing processing target is passed if the target operation permission is within the target operable permission scope.
[0051] The operation attribute consistency check can be a process of comparing the target operation attribute corresponding to the target operation item with the operable attributes corresponding to each operable item set to determine whether the attributes are the same. The target operable set can be the set of operable items that completely match the target operation attribute and belong to the set after the operation attribute consistency check; it is the rule grouping set to which the target operation item belongs. The target operable permission scope can be the operable permission boundaries and constraints uniformly applied to the entire set, pre-calculated and merged from the target operable set.
[0052] In one embodiment, the method for performing an operation attribute consistency check on the target operation attribute and the corresponding operation attributes of each operation set, and determining the target operation set to which the target operation item belongs based on the operation attribute consistency check result, can be as follows: The target operation attribute is sequentially compared and matched with the corresponding operation attributes of each operation set to complete the operation attribute consistency check. The operation set that is completely consistent with the target operation attribute is then selected and determined as the target operation set to which the target operation item belongs. The method for determining the target operation permission range corresponding to the target operation set based on the operation permission range, and determining whether the target operation permission is within the target operation permission range, can be as follows: The pre-calculated operation permission range of the target operation set is retrieved and used as the target operation permission range. The target operation permission is compared with the target operation permission range to determine whether the target operation permission is within the allowed constraint range. If the target operation permission is within the target operation permission range, the method for determining that the operation compliance check of the ticketing processing target has passed can be as follows: If the target operation permission is within the allowed range of the target operation permission range, then the operation corresponding to the ticketing processing target is directly determined to meet the business rule requirements, and the operation compliance check is determined to have passed.
[0053] This solution quickly and accurately identifies the target operable set to which the target operation belongs by comparing and verifying the consistency between the target operation attribute and the operable attributes of each operable set. This enables precise classification of business operations. Based on the defined operable permission range, it matches the permission boundary corresponding to the target operable set and then determines whether the target operation permission falls within the compliant permission range. Only when the target operation permission is within the legal permission range is the compliance verification considered passed. Through the layered verification logic of first classifying attributes and then verifying permission boundaries, this solution achieves standardized and refined compliance review of ticketing business operations, effectively avoiding unauthorized operations and irregular handling of ticketing business, and improving the rigor, accuracy, and standardization of ticketing request compliance verification and business control.
[0054] S103, if the operation compliance verification of the ticketing processing target passes, the ticketing processing target is matched with the preset processing interface identifier database to obtain the ticketing processing interface identifier.
[0055] The pre-built processing interface identifier database can be a dataset that pre-builds and stores the association between various ticketing services and their corresponding interface identifiers. The database is pre-configured and bound with unique identifiers for the corresponding backend business processing interfaces according to different ticketing service types and operation categories, used for business routing matching after compliance approval. A ticketing processing interface can be a dedicated function call entry point corresponding to different ticketing service types, used to receive ticketing request processing text and execute the corresponding ticketing service processing function. Examples include: ticket purchase interface, recharge interface, ticket refund interface, and unlocking interface. The ticketing processing interface identifier can be a number, name, or identifier that uniquely identifies the ticketing service processing interface.
[0056] In one embodiment, the method for matching the ticketing processing target with a preset processing interface identifier database to obtain the ticketing processing interface identifier can be as follows: The target operation attribute, target business scenario, and target operation permission are combined and encoded according to a preset feature code structure to generate a ticketing processing target feature code; the similarity between the ticketing processing target feature code and each candidate feature code in the preset feature code interface mapping database is calculated, and the interface identifier corresponding to the candidate feature code with the highest similarity is used as the corresponding ticketing processing interface identifier. The ticketing processing target includes the target operation attribute, target business scenario, and target operation permission.
[0057] The preset feature code structure can be a predefined fixed encoding format and field arrangement rule. The ticketing processing target feature code can be a unique code that uniquely represents the overall characteristics of the current ticketing processing target, generated by aggregating, encoding, and concatenating the target operation attributes, target business scenarios, and target operation permissions contained in the ticketing processing target according to the preset feature code structure. The preset feature code interface mapping database can be a pre-built database storing multiple candidate feature codes and ticketing processing interface identifiers corresponding to each candidate feature code, used to find the corresponding business interface through feature code matching. Candidate feature codes can be standard business feature codes generated according to the same preset feature code structure and pre-stored in the preset feature code interface mapping database, serving as alternative feature codes to be compared with the ticketing processing target feature code for similarity.
[0058] In one embodiment, the method for generating a ticketing processing target feature code by combining and encoding the target operation attribute, target business scenario, and target operation permission according to a preset feature code structure can be as follows: The target operation attribute, target business scenario, and target operation permission are standardized and encoded according to the field order, encoding rules, and concatenation format specified in the preset feature code structure. The encoded parts are then sequentially concatenated and combined according to a fixed structure to generate a ticketing processing target feature code uniquely corresponding to the ticketing processing target. The method for calculating the similarity between the ticketing processing target feature code and each candidate feature code in the preset feature code interface mapping database, and using the interface identifier corresponding to the candidate feature code with the highest similarity as the corresponding ticketing processing interface identifier, can be as follows: The generated ticketing processing target feature code is compared with each candidate feature code in the preset feature code interface mapping database, and the pairwise feature similarity is calculated. The similarity values of all candidate feature codes are compared, and the candidate feature code with the highest similarity is selected. The interface identifier pre-bound to this candidate feature code is retrieved and determined as the matched ticketing processing interface identifier.
[0059] This solution combines three core dimensions—target operation attributes, target business scenarios, and target operation permissions—into a pre-defined feature code structure to generate a ticketing processing target feature code. This code completely and uniquely represents the overall characteristics of the current ticketing business. Then, by calculating the similarity between the generated ticketing processing target feature code and each candidate feature code in the pre-defined feature code interface mapping database, the solution selects the interface identifier corresponding to the candidate feature code with the highest similarity as the ticketing processing interface identifier. This breaks away from the traditional, crude mode of fixed interface binding and manual configuration of mapping relationships, enabling adaptive intelligent matching of processing interfaces based on business characteristics. This significantly improves the accuracy, versatility, and automated adaptation capabilities of ticketing processing interface matching, reduces manual maintenance costs, and allows for flexible scheduling and processing of various ticketing businesses under multiple scenarios and permissions.
[0060] S104. Generate ticket request processing text based on the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier.
[0061] The ticketing request processing text can be a text used to inform the ticketing processing terminal how to process the ticketing request. The ticketing request processing text includes the ticketing processing rules to be followed when processing the request and the identifiers of the ticketing processing interfaces to be invoked.
[0062] In one embodiment, the method for generating ticket request processing text based on the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier can be: integrating the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier according to a preset request processing text structure to generate ticket request processing text.
[0063] In one embodiment, after generating the ticket request processing text based on the ticket request to be processed, ticket processing rule information, and ticket processing interface identifier, the method further includes: performing aggregation processing on the ticket request to be processed and the ticket request processing text, and generating a ticket processing knowledge vector based on the aggregation processing result; calculating the vector similarity between the ticket processing knowledge vector and each historical ticket processing knowledge vector in the preset ticket processing knowledge base; and, if the vector similarity is less than a preset association similarity threshold, adding the aggregation result to the preset ticket processing knowledge base according to the preset ticket processing knowledge format for incremental updates to the preset ticket processing knowledge base.
[0064] The aggregation processing result can be the corresponding entries of the ticketing requests and ticketing request processing texts obtained by associating and summarizing the ticketing requests to be processed. The ticketing processing knowledge vector can be a vector representing the ticketing request and its corresponding processing method, generated after semantic feature extraction and quantization transformation of the aggregation processing result. The preset ticketing processing knowledge base can be a pre-built database for storing vectors of historical ticketing requests and their corresponding processing methods. Historical ticketing processing knowledge vectors can be vectors stored in the preset ticketing processing knowledge base that correspond to historical ticketing requests and their corresponding processing methods. The preset association similarity threshold can be the minimum similarity used to determine whether a ticketing processing knowledge vector overlaps with existing historical ticketing processing knowledge vectors in the preset ticketing processing knowledge base. Incremental update can be the operation of storing ticketing processing knowledge vectors in the preset ticketing processing knowledge base without modifying the original data, thereby achieving a supplementary update of the knowledge base.
[0065] In one embodiment, the method of aggregating the ticketing request to be processed and the ticketing request processing text, and generating a ticketing processing knowledge vector based on the aggregation result, can be as follows: The ticketing request to be processed and the ticketing request processing text are aggregated and integrated to obtain an aggregation result; then, semantic feature extraction and vectorization encoding are performed on the aggregation result to generate the corresponding ticketing processing knowledge vector. The method of calculating the vector similarity between the ticketing processing knowledge vector and each historical ticketing processing knowledge vector in the preset ticketing processing knowledge base can be as follows: Traverse all historical ticketing processing knowledge vectors in the preset ticketing processing knowledge base, and calculate the vector similarity between the ticketing processing knowledge vector and each historical ticketing processing knowledge vector. When the vector similarity is less than the preset association similarity threshold, the aggregation result is added to the preset ticketing processing knowledge base according to the preset ticketing processing knowledge format. The method for incrementally updating the preset ticketing processing knowledge base is as follows: when the similarity between the ticketing processing knowledge vector and all historical ticketing processing knowledge vectors is less than the preset association similarity threshold, it is determined that there is no duplicate historical knowledge. The aggregation processing result is then rectified according to the preset ticketing processing knowledge format and added to the preset ticketing processing knowledge base, thereby completing the incremental update of the preset ticketing processing knowledge base.
[0066] This solution aggregates and integrates the pending ticketing requests with the ticketing request processing text to generate corresponding ticketing processing knowledge vectors. It simultaneously merges the user's original requests with standardized business processing information, fully preserving all the characteristics of a single ticketing transaction. By calculating the vector similarity between the current ticketing processing knowledge vector and historical ticketing processing knowledge vectors in the preset ticketing processing knowledge base, it can accurately determine whether the current business knowledge highly overlaps with existing historical knowledge. If the vector similarity does not reach the preset association similarity threshold and is determined to be entirely new business knowledge, the aggregation results are incorporated into the preset ticketing processing knowledge base in a standardized format for incremental updates. This eliminates the need for manual data entry and automatically accumulates new ticketing business knowledge, continuously enriching the knowledge base's coverage. It enables autonomous iteration and dynamic optimization of the knowledge base, improving the accuracy and adaptability of subsequent ticketing rule matching, semantic parsing, and business processing.
[0067] The technical solution provided in this application involves: acquiring a ticketing request to be processed; extracting multiple ticketing keywords from the ticketing request; querying ticketing rule information corresponding to the multiple ticketing keywords in a preset ticketing processing knowledge base; performing semantic parsing on the ticketing request to be processed to obtain a ticketing processing target; verifying the operational compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target; if the operational compliance verification of the ticketing processing target passes, matching the ticketing processing target with a preset processing interface identifier database to obtain a ticketing processing interface identifier; and generating a ticketing request processing text based on the ticketing request to be processed, the ticketing processing rule information, and the ticketing processing interface identifier. The above-described ticketing request processing method solves the problems of low efficiency, lack of intelligence, and poor processing results in existing technologies. By extracting multiple ticketing keywords from the ticketing request to be processed to query ticketing processing rule information, and verifying the compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target, the method determines the corresponding ticketing processing interface identifier and generates ticketing request processing text. This method can automatically parse and generate ticketing processing text corresponding to the ticketing request to be processed without manual intervention, thereby improving the efficiency and intelligence of ticketing processing and ensuring the processing effect.
[0068] Figure 4 This is a structural block diagram of a ticket request processing device provided in an embodiment of this application. Figure 4 As shown, it specifically includes: The processing rule query module 401 is used to obtain the ticketing request to be processed, extract multiple ticketing keywords from the ticketing request to be processed, and query the ticketing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base; The target verification module 402 is used to perform semantic parsing on the ticketing request to be processed, obtain the ticketing processing target, and verify the operation compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target. The processing interface determination module 403 is used to match the ticket processing target with the preset processing interface identifier database to obtain the ticket processing interface identifier when the operation compliance verification of the ticket processing target passes. The ticketing processing module 404 is used to generate ticketing request processing text based on the ticketing request to be processed, ticketing processing rule information, and ticketing processing interface identifier.
[0069] Furthermore, the operable information includes multiple operable items and the corresponding operable permissions for each operable item; The target verification module 402 is specifically used for: Identify the operable attributes of each operable item in the ticketing processing rule information, and group multiple operable items according to the operable attributes to obtain multiple operable item sets; Calculate the union of the operable permissions corresponding to multiple operable items in each operable set to obtain the operable permission range corresponding to each operable set; Based on the target operation information in the ticketing processing target, determine the target operation item corresponding to the ticketing processing target, and determine the target operation attribute and target operation permission corresponding to the target operation item; Based on the target operation attributes, operable attributes, operable permission scope, and target operation permissions, the operation compliance of the target operation item is verified to obtain the operation compliance verification result of the ticketing processing target.
[0070] Furthermore, the target verification module 402 is specifically used for: Perform an operation attribute consistency check on the target operation attribute and the corresponding operation attributes of each operation set, and determine the target operation set to which the target operation item belongs based on the operation attribute consistency check result; Determine the target operable set corresponding to the target operable permission range based on the operable permission range, and determine whether the target operation permission is within the target operable permission range; If the target's operation permissions are within the scope of its operable permissions, the compliance verification of the ticketing processing target's operation is confirmed to be successful.
[0071] Furthermore, the ticketing processing objectives include target operation attributes, target business scenarios, and target operation permissions; The interface determination module 403 is specifically used for: The target operation attributes, target business scenarios, and target operation permissions are combined and encoded according to the preset feature code structure to generate the ticketing processing target feature code; Calculate the similarity between the target feature code for ticketing processing and each candidate feature code in the preset feature code interface mapping database, and use the interface identifier corresponding to the candidate feature code with the highest similarity as the corresponding ticketing processing interface identifier.
[0072] Furthermore, the target verification module 402 is specifically used for: Semantic parsing is performed on the ticketing requests to be processed, and the semantic integrity of the semantic parsing results is verified based on the preset complete semantic necessary information; If the semantic parsing result is incomplete, a clarification text is generated according to the preset question template and sent to the ticketing processing terminal to guide the user to supplement the necessary information. Obtain the necessary information, and based on the necessary information, perform semantic completion on the semantic parsing results to obtain the ticketing processing target.
[0073] Furthermore, the preset ticketing processing knowledge base includes multiple candidate ticketing processing rule information; The processing rule query module 401 is specifically used for: Identify multiple rule keywords in the ticketing processing rule information of each candidate; Calculate the keyword overlap between multiple ticketing keywords and multiple rule keywords in each candidate ticketing processing rule information, and take the candidate ticketing processing rule information with the highest keyword overlap as the ticketing processing rule information corresponding to the ticketing request to be processed.
[0074] Furthermore, the ticketing processing module 404 is also used for: The system aggregates the ticketing requests to be processed and the ticketing request processing text, and generates a ticketing processing knowledge vector based on the aggregation results. Calculate the vector similarity between the ticketing processing knowledge vector and each historical ticketing processing knowledge vector in the preset ticketing processing knowledge base; If the vector similarity is less than the preset association similarity threshold, the aggregation result is added to the preset ticketing processing knowledge base according to the preset ticketing processing knowledge format for incremental updates to the preset ticketing processing knowledge base.
[0075] The technical solution provided in this application includes a processing rule query module, used to obtain a ticketing request to be processed, extract multiple ticketing keywords from the ticketing request, and query ticketing processing rule information corresponding to the multiple ticketing keywords in a preset ticketing processing knowledge base; a processing target verification module, used to perform semantic parsing on the ticketing request to be processed to obtain a ticketing processing target, and to perform operation compliance verification on the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target; a processing interface determination module, used to match the ticketing processing target with a preset processing interface identifier database to obtain a ticketing processing interface identifier if the operation compliance verification of the ticketing processing target passes; and a ticketing processing module, used to generate ticketing request processing text based on the ticketing request to be processed, the ticketing processing rule information, and the ticketing processing interface identifier. The aforementioned ticketing request processing device solves the problems of low efficiency, lack of intelligence, and poor processing results in existing technologies. By extracting multiple ticketing keywords from the ticketing request to be processed to query ticketing processing rule information, and verifying the compliance of the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target, it determines the corresponding ticketing processing interface identifier and generates ticketing request processing text. This allows for the automatic parsing and generation of ticketing processing text corresponding to the ticketing request to be processed without manual intervention, thereby improving the efficiency and intelligence of ticketing processing and ensuring processing results.
[0076] The ticketing request processing device in this application embodiment can be configured in a device, or as a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.
[0077] The ticketing request processing device in this application embodiment can be an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.
[0078] The ticketing request processing apparatus provided in this application embodiment can implement the various processes implemented in the above method embodiments. To avoid repetition, it will not be described again here.
[0079] like Figure 5 As shown, this application embodiment also provides an electronic device 500, including a processor 501, a memory 502, and a program or instructions stored in the memory 502 and executable on the processor 501. When the program or instructions are executed by the processor 501, they implement the various processes of the above-described ticket request processing method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0080] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.
[0081] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described ticket request processing method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0082] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0083] This application also provides a program product including program code. When the program product is run on a computer device, the program code causes the computer device to perform the steps of the methods described above according to various exemplary embodiments of this application. For example, the computer device can execute a ticket request processing method described in the embodiments of this application. The program product can be implemented using any combination of one or more readable media.
[0084] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0085] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0086] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
[0087] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.
Claims
1. A method for processing ticket requests, characterized in that, The method includes: Obtain the ticketing request to be processed, extract multiple ticketing keywords from the ticketing request to be processed, and query the ticketing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base; The pending ticketing requests are semantically parsed to obtain the ticketing processing target, and the operation compliance of the ticketing processing target is verified based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target. If the operation compliance verification of the ticketing processing target passes, the ticketing processing target is matched with the preset processing interface identifier database to obtain the ticketing processing interface identifier; The ticket request processing text is generated based on the ticket request to be processed, the ticket processing rule information, and the ticket processing interface identifier.
2. The ticketing request processing method according to claim 1, characterized in that, The operable information includes multiple operable items and corresponding operable permissions for each operable item. The step of verifying the operational compliance of the ticketing processing target based on the operable information in the ticketing processing rules information and the target operational information in the ticketing processing target includes: Identify the operable attributes of each operable item in the ticketing processing rule information, and group the multiple operable items according to the operable attributes to obtain multiple operable item sets; Calculate the union of the operable permissions corresponding to multiple operable items in each operable set to obtain the operable permission range corresponding to each operable set; Based on the target operation information in the ticketing processing target, determine the target operation item corresponding to the ticketing processing target, and determine the target operation attribute and target operation permission corresponding to the target operation item; Based on the target operation attribute, the operable attribute, the operable permission range, and the target operation permission, the operation compliance of the target operation item is verified to obtain the operation compliance verification result of the ticketing processing target.
3. The ticketing request processing method according to claim 2, characterized in that, The step of performing operation compliance verification on the target operation item based on the target operation attribute, the operable attribute, the operable permission range, and the target operation permission to obtain the operation compliance verification result of the ticketing processing target includes: Perform an operation attribute consistency check on the target operation attribute and the corresponding operation attributes of each operation set, and determine the target operation set to which the target operation item belongs based on the operation attribute consistency check result; Based on the operable permission range, determine the target operable set corresponding to the target operable permission range, and determine whether the target operation permission is within the target operable permission range; If the target's operation permissions are within the scope of the target's operable permissions, the operation compliance verification of the ticketing processing target is determined to be successful.
4. The ticketing request processing method according to claim 1, characterized in that, The ticketing processing objectives include target operation attributes, target business scenarios, and target operation permissions; The step of matching the ticketing processing target with a preset processing interface identifier database to obtain the ticketing processing interface identifier includes: The target operation attribute, the target business scenario, and the target operation permission are combined and encoded according to a preset feature code structure to generate a ticketing processing target feature code; Calculate the similarity between the ticketing processing target feature code and each candidate feature code in the preset feature code interface mapping database, and use the interface identifier corresponding to the candidate feature code with the highest similarity as the corresponding ticketing processing interface identifier.
5. The ticketing request processing method according to claim 1, characterized in that, The semantic parsing of the pending ticketing requests to obtain the ticketing processing target includes: The pending ticketing requests are semantically parsed, and the semantic integrity of the parsing results is verified based on preset complete semantic necessary information. If the semantics of the semantic parsing result is incomplete, a clarification text is generated according to a preset question template, and the clarification text is sent to the ticketing terminal to guide the user to supplement the necessary information. Obtain the necessary information, and perform semantic completion on the semantic parsing result based on the necessary information to obtain the ticketing processing target.
6. The ticketing request processing method according to claim 1, characterized in that, The preset ticketing processing knowledge base includes multiple candidate ticketing processing rule information; The query of ticketing processing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base includes: Identify multiple rule keywords in each of the candidate ticketing processing rule information; Calculate the keyword overlap between the multiple ticketing keywords and the multiple rule keywords in each of the candidate ticketing processing rule information, and take the candidate ticketing processing rule information with the highest keyword overlap as the ticketing processing rule information corresponding to the ticketing request to be processed.
7. The ticketing request processing method according to claim 1, characterized in that, After generating the ticket request processing text based on the ticket request to be processed, the ticket processing rule information, and the ticket processing interface identifier, the method further includes: The pending ticketing requests and the ticketing request processing text are aggregated, and a ticketing processing knowledge vector is generated based on the aggregation results. Calculate the vector similarity between the ticketing processing knowledge vector and each historical ticketing processing knowledge vector in the preset ticketing processing knowledge base; If the vector similarity is less than a preset association similarity threshold, the aggregation result is added to the preset ticketing processing knowledge base according to the preset ticketing processing knowledge format for incremental updates to the preset ticketing processing knowledge base.
8. A ticket request processing device, characterized in that, The device includes: The processing rule query module is used to obtain ticketing requests to be processed, extract multiple ticketing keywords from the ticketing requests to be processed, and query the ticketing rule information corresponding to the multiple ticketing keywords in the preset ticketing processing knowledge base; The target verification module is used to perform semantic parsing on the ticketing request to be processed to obtain the ticketing processing target, and to perform operation compliance verification on the ticketing processing target based on the operable information in the ticketing processing rule information and the target operation information in the ticketing processing target; The processing interface determination module is used to match the ticket processing target with a preset processing interface identifier database to obtain the ticket processing interface identifier when the operation compliance verification of the ticket processing target passes. The ticketing processing module is used to generate ticketing request processing text based on the ticketing request to be processed, the ticketing processing rule information, and the ticketing processing interface identifier.
9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of a ticket request processing method as described in any one of claims 1-7.
10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of a ticketing request processing method as described in any one of claims 1-7.