Air passenger collection of additional charges intelligent processing method and device

Abstract

This invention discloses an intelligent processing method and apparatus for air passenger surcharge collection. The method includes: constructing a multi-version domain knowledge base using rule text for air passenger surcharge collection; upon receiving a processing request for air passenger surcharge collection, parsing the flight itinerary structure and ticket sales date from the request; matching the flight itinerary structure and ticket sales date from the multi-version domain knowledge base to obtain ticket-matching rule knowledge units; decomposing the task using the flight itinerary structure and the ticket-matching rule knowledge units to generate multiple sub-tasks; scheduling and executing the multiple sub-tasks using a pre-trained large model; and summarizing the processing results of all sub-tasks to obtain the final processing result. This invention can accurately determine the applicable rule scope and improve the processing accuracy of air passenger surcharge collection.

Description

Technical Field

[0001] This invention relates to the field of aviation data processing technology, and in particular to an intelligent processing method and apparatus for collecting additional fees on behalf of air passengers. Background Technology

[0002] Additional charges collected on behalf of passengers by airlines refer to fees collected by airlines on behalf of airports, public institutions, or relevant departments in different countries or regions when selling tickets, in accordance with laws, regulations, or international practices. These fees are not part of the airlines' own revenue and are public fees that are collected on behalf of passengers in accordance with regulations, with clear purposes, and are required to be reported or declared. Their purpose is to ensure the normal operation of the civil aviation system and to fulfill international obligations.

[0003] Rules governing the collection of additional fees by air passengers typically have the following characteristics: (1) The rules come from a wide range of sources, involving different countries or regions, different rule-issuing entities, and different release times; (2) The rules are updated frequently, and multiple versions may be in effect in the same year or be adjusted in stages; (3) The rules are complex in their application logic. They may apply to the entire journey, or to a single segment, a single terminal, the departure process, the arrival process, or the sales process. (4) The rule text is usually expressed in natural language and contains a large number of conditions, exceptions, special application instructions and cross-article references; (5) The results of rule processing are not only used to assist in judgment in business, but also need to provide the rule basis reference information to support dispute handling, manual review and audit record keeping.

[0004] In existing technologies, some rules for collecting additional fees are usually transformed into static logical rules through manual sorting or rule engine configuration. Dedicated judgment logic is built for specific countries / regions or types of additional fees. When flight information is input, the system performs matching judgment according to preset rules and outputs the processing results.

[0005] While this type of solution can achieve a certain degree of automation within a specific scope, it still has the following shortcomings: (1) The cost of maintaining the rules is high. When the rule version is updated, the rule terms are adjusted, or the applicable conditions change, it is often necessary to modify the rule configuration, judgment logic or program implementation simultaneously. (2) It is difficult to adapt to scenarios with frequent changes in rule texts, an increase in interpretive clauses, and complex exception conditions, resulting in significant pressure for continuous maintenance; (3) For new countries or regions, new types of additional fees collected on behalf of others, or new versions of rules, a lot of development and configuration work is usually required, and the implementation cost is high. (4) Rule engines usually rely on converting natural language rule text into structured rule expression. During the conversion process, the contextual information, exception conditions, explanatory notes and reference relationships between clauses in the original rule text are easily lost, making it difficult to completely restore the text rules. (5) Structured rule expression is usually more inclined to system execution and technical implementation, which is not conducive to business personnel directly understanding the source of the rules, the basis for application and the judgment process. Therefore, business readability and review convenience are poor. (6) When the rules apply across countries / regions, stages, or multiple types of fees, the system’s ability to expand flexibly is weak, and the complexity of rule organization and maintenance increases further.

[0006] Therefore, existing solutions have several drawbacks in handling rules for additional charges collected on behalf of air passengers. These include difficulty in accurately determining the scope of applicable rules, reliance on heavy manual modeling and rule configuration, high development, implementation, and subsequent maintenance costs, and insufficient support capabilities in scenarios such as dispute resolution, manual review, and audit documentation. Summary of the Invention

[0007] This invention provides an intelligent processing method for additional fees collected on behalf of air passengers, which reduces reliance on manual labor, accurately determines the scope of applicable rules, and improves the accuracy and interpretability of processing additional fees collected on behalf of air passengers. The method includes: A multi-version domain knowledge base is constructed using the rule text for collecting additional fees on behalf of air passengers. The multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: issuing entity, fee type, applicable stage, version, and rule text fragment. When a processing request for collecting additional fees on behalf of air passengers is received, the flight structure and ticket sales date are parsed from the processing request; the flight structure includes segment information from the origin to the destination and sales location information; the processing request includes a description of the scope of processing for collecting additional fees on behalf of air passengers. Based on the flight itinerary structure and ticket sales date, rule knowledge units for ticket adaptation are obtained by matching from a multi-version domain knowledge base; The task is decomposed using the flight path structure and the rule knowledge unit adapted to the ticket, generating multiple sub-tasks; the sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; By pre-training a large model, multiple sub-tasks are scheduled and executed, and the processing results of all sub-tasks are summarized to obtain the final processing result. The final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

[0008] This invention also provides an intelligent processing device for collecting surcharges on behalf of air passengers, which reduces reliance on manual labor, accurately determines the scope of applicable rules, and improves the accuracy and interpretability of processing surcharges collected on behalf of air passengers. The device includes: The knowledge base construction module is used to construct a multi-version domain knowledge base using the rule text of air passenger surcharge collection. The multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: issuing entity, fee type, applicable stage, version, and rule text fragment. The request receiving module is used to parse the flight structure and ticket sales date from the processing request when it receives a processing request for air passenger surcharge collection. The flight structure includes segment information from the origin to the destination and sales location information. The processing request includes a scope description information for air passenger surcharge collection processing. The knowledge base routing module is used to match the ticket-fitting rule knowledge units from multiple versions of the domain knowledge base based on the flight path structure and ticket sales date. The task decomposition module is used to decompose tasks using the flight path structure and the rule knowledge unit adapted to the ticket, generating multiple sub-tasks; the sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; The task scheduling and result output module is used to schedule and execute multiple sub-tasks through a pre-trained large model, and summarize the processing results of all sub-tasks to obtain the final processing result. The final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

[0009] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0010] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0011] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0012] In this embodiment of the invention, a multi-version domain knowledge base is constructed using the rule text for collecting surcharges on behalf of air passengers. This multi-version domain knowledge base stores multiple rule knowledge units, each possessing at least one of the following: issuing entity, fee type, applicable stage, version, and rule text fragment. During the later processing of surcharge calculations, appropriate rule text fragments can be accurately matched based on the issuing entity, fee type, applicable stage, and version, improving the accuracy of determining the applicable rule scope for surcharge calculations and reducing rule version mismatches. Furthermore, during the fee calculation process, task decomposition and sub-task scheduling are performed, improving processing capabilities in complex flight scenarios. Efficiency; sub-tasks include fee calculation tasks for different applicable stages and geographical locations, further improving the processing accuracy of air passenger surcharges; with the assistance of a pre-trained large model, the final processing result includes at least one dimension of the issuing entity, fee type, applicable stage, version, amount, and rule basis reference information, improving the interpretability and business readability of air passenger surcharges, while enhancing the understanding and review convenience of business personnel regarding the source of rules, applicable basis, and judgment process. By achieving structured processing and intelligent auxiliary judgment while maintaining the traceability of rule text, it can better balance processing efficiency and business understandability. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a schematic diagram of the first process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention. Figure 2 This is a schematic diagram of the second process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention; Figure 3 This is a schematic diagram of the third process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention. Figure 4 This is a schematic diagram of the intelligent processing device for collecting additional fees on behalf of air passengers in an embodiment of the present invention. Figure 5 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0015] To facilitate a clear description of the technical solutions in the embodiments of the present invention, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order. In the embodiments of the present invention, the symbol " / " represents the meaning of "or," which will not be repeated here.

[0016] The existing solutions have the following main problems in the scenario of handling additional fees collected on behalf of air passengers: (1) There is a lack of collaborative processing mechanisms for different dimensions such as rule version, country / region, and business time, making it difficult to accurately determine the scope of applicable rules; (2) It relies heavily on manual modeling and rule configuration, resulting in high development, implementation, and subsequent maintenance costs; (3) Existing solutions generally cannot simultaneously ensure the complete preservation of rule text, the efficiency of structured processing, and the business readability, and it is difficult to achieve a balance between automatic processing capability and business readability. (4) The final processing conclusion lacks process processing basis, and therefore has insufficient support in scenarios such as dispute resolution, manual review and audit record keeping; (5) When the rule version is continuously updated, the applicable countries / regions are increased, the fee types are expanded, or the processing logic becomes more complex, the scalability and continuous adaptability of the existing solution are insufficient.

[0017] This invention aims to address the problems existing in the processing of rules for collecting additional fees on behalf of air passengers, such as inaccurate rule version determination, unclear rule text routing, difficulty in effectively decomposing complex requests, high processing overhead and maintenance costs, and unstable rule reference information. It provides an intelligent processing method, system, and device for collecting additional fees on behalf of air passengers based on a multi-version domain knowledge base and task decomposition scheduling.

[0018] The embodiments of the present invention further introduce a large model to participate in the semantic understanding of rule text, matching of applicable conditions, summarization of subtask processing results, and generation of rule basis binding. This not only enables the determination of rule version and knowledge base routing, but also improves the accuracy of rule understanding, the ability to interpret results, and the readability of business in complex rule text scenarios.

[0019] Through the embodiments of the present invention, the following can be achieved: (1) Determine the target rule version based on the input ticket sales date; (2) Construct a multi-version domain knowledge base with country / region as the first level and fee type as the second level; (3) Perform granular segmentation of the execution cost type in the rule document; (4) Routing to the target knowledge base partition based on version, country / region, and fee type; (5) Generate multiple rule-based sub-tasks based on the collection point and its type; (6) Perform unified aggregation, conflict resolution, and consistency verification on the results of multi-subtask processing; (7) Output intelligent auxiliary processing results with rule-based reference information to support business processing, dispute analysis and manual review.

[0020] The following describes in detail the intelligent processing method for collecting additional fees on behalf of air passengers in the embodiments of the present invention.

[0021] Figure 1 This is a schematic diagram of the first process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes: Step 101: Construct a multi-version domain knowledge base using the rules text for collecting additional fees on behalf of air passengers; the multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: issuing entity, fee type, applicable stage, version, and rule text fragment; Step 102: When a processing request for collecting additional fees on behalf of air passengers is received, the flight structure and ticket sales date are parsed from the processing request; the flight structure includes segment information from the origin to the destination and sales location information; the processing request includes a scope description of the processing of additional fees collected on behalf of air passengers. Step 103: Based on the flight itinerary structure and ticket sales date, obtain the rule knowledge unit for ticket adaptation from the multi-version domain knowledge base; Step 104: Decompose the task using the flight path structure and the rule knowledge unit that adapts to the ticket to generate multiple sub-tasks; the sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; Step 105: Schedule and execute multiple sub-tasks using a pre-trained large model, and summarize the processing results of all sub-tasks to obtain the final processing result; the final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

[0022] like Figure 1 The diagram shows the basic implementation flowchart of the intelligent processing method for collecting additional fees on behalf of air passengers.

[0023] First, version control is implemented for the relevant rules and texts on the collection of additional fees by air passengers, and a multi-version domain knowledge base is built.

[0024] For example, an initial rule text is used to build a knowledge base. Then, a new version is generated for each change or update of the rule text. The temporal sequence and dependency structure between versions are maintained to achieve complete tracking of the knowledge evolution process, thereby building a multi-version domain knowledge base that supports historical backtracking, version comparison and multi-time point query.

[0025] Rule knowledge units refer to structured or semi-structured knowledge fragments extracted, split, and organized from rule texts, which can be retrieved, matched, referenced, and processed.

[0026] In one embodiment, to achieve intelligent rule retrieval and auxiliary processing, this embodiment of the invention establishes a data model for the rule knowledge unit. The data model includes at least version information, country / region information, cost type information, applicable condition information, rule content information, and rule basis reference information, thereby enabling the rule knowledge unit to simultaneously support subsequent knowledge base construction, version routing, country / region routing, cost type routing, task decomposition and invocation, result aggregation, and rule basis reference information output.

[0027] The rule knowledge unit is derived from the text of the rules for collecting additional fees on behalf of air passengers, and is associated with at least the following: (1) The version to which it belongs, i.e. the version of the original text of the rules for collecting additional fees on behalf of others; (2) Country or region of origin; (3) Fee type refers to the category identifier of the additional fees collected on behalf of air passengers in the rule processing. Fee types include sales-related fees and transportation-related fees. (4) Applicable stages, including sales and transportation stages; (5) Applicable conditions, including effective date, applicable passenger type, behavior, etc.; (6) Rule-based text fragments; (7) Location of the original rule document or clause.

[0028] Figure 2 This is a schematic diagram of the second process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention, as shown below. Figure 2 As shown, a multi-version domain knowledge base is constructed using the rules text for collecting additional fees on behalf of airline passengers, including: Step 201: Obtain the text of the rules for collecting additional fees on behalf of air passengers, and record the metadata information of the text of the rules for collecting additional fees on behalf of air passengers; the metadata information includes at least one of the following: publication time, applicable start time, applicable end time, version, and source identifier; Step 202: Parse and split the rule text for collecting additional fees on behalf of air passengers according to the fee type to form multiple rule knowledge units; each rule knowledge unit is associated with a position in the original rule text; Step 203: Organize multiple rule knowledge units by region as the first level and cost type as the second level, and establish corresponding knowledge base partitions under different versions to form a multi-version domain knowledge base.

[0029] During implementation, the received rule text is parsed and split into rule knowledge units that can be retrieved and processed. The splitting is preferably performed along two dimensions: country / region and fee type, with the rule document segmentation completed at the fee type granularity.

[0030] In one embodiment, rule text splitting can be achieved by a splitting method based on clause structure, a splitting method based on semantic fragments, or a combination of both.

[0031] Based on the established rule-based knowledge units, a multi-version domain knowledge base is constructed. Preferably, the multi-version domain knowledge base is organized with country / region as the first level and fee type as the second level, and corresponding knowledge base partitions are established for different versions to avoid mixed retrieval of rules from different versions.

[0032] The two-tiered organization of country / region and cost type can be implemented using a predefined directory structure, tag structure, or hybrid organizational structure.

[0033] In this embodiment of the invention, the rule knowledge units in the multi-version domain knowledge base are preferably organized according to country / region as the first level and fee type as the second level, and the rule document is cut at the granularity of fee type, which improves the accuracy of subsequent version routing, knowledge retrieval and rule processing.

[0034] In implementation, multi-version domain knowledge bases can be implemented using physical database partitioning, logical partitioning, or a unified index with version tags.

[0035] In the embodiments, the rule knowledge unit data model is also used to provide controlled input boundaries for the pre-trained large model, enabling the pre-trained large model to perform rule semantic understanding and processing result generation within a limited version, limited country / region, and limited fee type, thereby reducing interference from irrelevant rules and improving processing accuracy.

[0036] To facilitate version management, in one embodiment, before organizing multiple rule knowledge units by region as the first level and cost type as the second level, and establishing corresponding knowledge base partitions under different versions to form a multi-version domain knowledge base, the method may further include: For multiple versions of the rules for collecting additional fees on behalf of air passengers issued by the same issuing entity in the same year, an independent version record is established for each version. The version record includes: a unique version identifier, an effective date, and the identifier of the previous version it replaces. It supports determining the order of each version on the timeline through the effective date and establishing a replacement relationship chain between adjacent versions through the identifier of the previous version.

[0037] In this example, version records are created for multiple rule versions within the same year, and the temporal and substitution relationships between versions are preserved for subsequent knowledge base routing and version matching processing.

[0038] When a processing request for collecting additional fees on behalf of air passengers is received, the flight itinerary and ticket sales date are parsed from the processing request.

[0039] During implementation, requests related to the processing of rules for collecting surcharges on behalf of air passengers will be received. Requests may include one or more of the following: flight information, passenger information, ticketing information, place of sale information, ticket sales date, and surcharge collection query criteria.

[0040] In one embodiment, the processing request is in the form of a natural language description or structured business parameters; Parsing the flight itinerary structure and ticket sales date from the processing request may include: By using a pre-trained large model, the flight path structure and ticket sales date are parsed from the processing request.

[0041] Specifically, based on the received request, the flight path structure and business conditions related to the application of the rules are parsed out. The flight path structure refers to the structured expression of the transportation process based on the passenger transportation route. The flight path structure includes at least the overall flight path, each transportation segment, departure point, arrival point, transit point, place of sale, and other transportation elements related to the application of the rules for collecting surcharges on behalf of passengers. The business conditions include at least the passenger category and the ticket sales date.

[0042] Then, in step 103, the target knowledge base is routed based on version, region, and fee type. The rule knowledge unit that matches the ticket is obtained from the multi-version domain knowledge base according to the flight structure and ticket sales date.

[0043] In practice, the rule knowledge units for ticket adaptation are obtained by matching the flight route structure and ticket sales date from a multi-version domain knowledge base. This may include: determining the adaptation region and adaptation fee type based on the flight route structure, and determining the adaptation version based on the ticket sales date; using the adaptation region, adaptation fee type, and adaptation version as the input constraint range of the pre-trained large model, and obtaining the rule knowledge units for ticket adaptation by matching the pre-trained large model with the multi-version domain knowledge base.

[0044] During implementation, the release date of the rule document can be used as the version. First, the target rule version is determined based on the input ticket sales date, and the target rule version is used as a prerequisite for subsequent knowledge base routing.

[0045] Based on the determined target rule version and the country information and levy type information corresponding to the rule processing object (i.e., the information such as the flight path structure and business conditions obtained in the previous step), routing is performed on the multi-version domain knowledge base to determine the corresponding regional and levy type level target knowledge base partitions.

[0046] After determining the target knowledge base partition, it further routes to the relevant rule knowledge unit set under the partition.

[0047] The output of step 103 is the target knowledge base routing result, which includes the regional and cost type-level target knowledge base partitions for ticket adaptation corresponding to the processing request, as well as the rule knowledge units under the partitions. The target knowledge base routing result also serves as the input constraint range for subsequent pre-trained large model processing, so that the large model only performs semantic understanding and result generation within the set of rule knowledge units corresponding to the current rule version, country / region, and cost type.

[0048] Step 104 involves task decomposition, utilizing the flight path structure and the rule knowledge unit for ticket adaptation to generate multiple sub-tasks.

[0049] Based on the obtained rule processing object information and the target knowledge base partition determined in step 103, the rule processing request is decomposed into multiple rule processing sub-tasks, referred to as sub-tasks.

[0050] In one embodiment, task decomposition is performed using rule-based knowledge units of flight path structure and ticket matching to generate multiple sub-tasks, which may include: Collection points are pre-constructed using rule knowledge units; the collection points include applicable rules and calculation rules for collecting additional fees, the applicable rules including geographical location and charging conditions; the calculation rule unit is used to handle condition judgments or calculation tasks; The collection point is determined based on the rule knowledge unit for ticket adaptation; Multiple sub-tasks are generated based on the flight path structure and collection points.

[0051] In this embodiment, the collection point refers to a business unit used to determine the scope, applicable country / region, and applicable stage of the collection fee during the processing of surcharges collected on behalf of air passengers. The collection point may correspond to the sales location, departure terminal, arrival terminal, or other business nodes related to the collection fee processing.

[0052] There are different types of collection points. The type of collection point refers to the classification of the collection point in the logic of the collection fee application. It includes at least sales-type collection points, departure-type collection points, and arrival-type collection points.

[0053] During implementation, corresponding rule-based sub-tasks are generated based on the collection point, collection point type, and fee type. These sub-tasks include fee calculation tasks for different applicable stages (sales stage, transportation stage) and different geographical locations (departure terminal, arrival terminal). Specifically, sub-tasks can at least include processing tasks for sales-type collection points, processing tasks for departure-type collection points, and processing tasks for arrival-type collection points.

[0054] In this example, considering that the applicable logic of the rules for collecting surcharges on behalf of air passengers is not singular, a task decomposition mechanism for rule processing was further established. This mechanism breaks down the request into multiple sub-tasks based on the flight structure, collection point, collection point type, and applicable surcharge logic. Task decomposition can be implemented using a rule template-driven approach, a model-based reasoning approach, or a hybrid approach. The rule template-driven approach refers to decomposing the task into sub-tasks according to fixed logic based on predefined rules or structured templates. The model-based reasoning approach refers to using a large model to understand the semantics of the task and dynamically decomposing the task through contextual reasoning.

[0055] In one embodiment, during task decomposition, for a flight route that includes multiple segments and multiple stations, the following can be identified: (1) Handling of sales-related fees applicable to the entire voyage; (2) The task of handling transportation fees applicable to each collection point; (3) The task of handling transportation fees applicable to each arrival-type collection point; (4) Supplementary processing tasks for special applicable conditions.

[0056] Each rule processing subtask forms a task input unit for the pre-trained large model, enabling the large model to perform fine-grained processing of the rule text under the conditions of limiting the collection point, the type of collection point, and the type of collection fee.

[0057] In this embodiment of the invention, the pre-trained large model (which may be referred to as the large model) refers to a language understanding and generation model trained on a large-scale corpus. It is used to perform joint semantic analysis, rule matching judgment, task processing interpretation, and result generation on rule text, rule knowledge units, flight path structure information, toll point information, fee type information, and applicable condition information.

[0058] In this embodiment of the invention, the pre-trained large model does not generate rule conclusions independently of the knowledge base. Instead, it works in conjunction with a multi-version domain knowledge base, a task decomposition and scheduling mechanism, and a rule reference information generation mechanism to improve the accuracy of rule understanding, condition matching, result summarization, and text reference binding.

[0059] During implementation, a pre-trained large model is used to achieve semantic understanding. Semantic understanding includes the process of using the pre-trained large model to identify, parse, and summarize the natural language expressions, conditional constraints, exception clauses, explanatory notes, inter-clause citations, and their correspondence with the input business conditions in the rule text.

[0060] Step 105 involves subtask scheduling and result summarization.

[0061] Based on the multiple subtasks generated in the previous step, perform task scheduling.

[0062] Each rule-processing subtask after task decomposition serves as the input processing unit for the large model. For each subtask, the large model receives the corresponding version of rule knowledge units, collection point information, collection point type, collection fee type, and applicable conditions. The large model then performs semantic understanding, applicability judgment, and result summarization on the rule text within the scope of that subtask. By breaking down complex requests into multiple controlled subtasks input into the large model, the contextual complexity of a single processing step is reduced, rule matching accuracy is improved, and the interpretability of the results is enhanced.

[0063] In one embodiment, multiple subtasks are scheduled and executed using a pre-trained large model, including: The execution order of subtasks is determined based on whether there are dependencies between them. For example, whether subtasks can be executed in parallel is determined based on whether there are dependencies such as input dependencies, condition dependencies, or result dependencies, and an execution strategy is provided for the subsequent scheduling module. During the subtask processing phase, at least the following processing is performed using the pre-trained large model: Identify the applicable conditions, exceptions, and explanatory notes in the rule text fragments of the rule knowledge unit that the ticket is adapted to; Determine the matching relationship between the rule text of the rule knowledge unit that the ticket is compatible with and the current collection point and collection fee type; Summarize the sub-task processing conclusions and corresponding explanatory information; The execution of subtasks is scheduled based on their execution order, processing results, and corresponding explanatory information.

[0064] For example, for multiple independent sub-tasks of processing collection points, rule retrieval is performed in parallel at the collection point level, and the large model is called to perform semantic understanding, condition determination and result summarization on the rule knowledge units corresponding to each sub-task; for sub-tasks with dependencies, they are executed in the order of dependency.

[0065] Subtask scheduling can also be implemented using thread parallelism, process engine scheduling, or distributed task scheduling.

[0066] Finally, after the subtasks are completed, the processing results of the multiple subtasks are summarized to obtain the final processing result; the final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

[0067] In one embodiment, summarizing the processing results of all subtasks to obtain the final processing result may include: The rule-based reference information is extracted from the rule knowledge unit involved in the processing; the rule-based reference information can locate the specific page number, paragraph, or clause position in the original rule text. By using a pre-trained large model, the processing results of all sub-tasks are classified, duplicate results are identified, conflict results are identified and resolved at least once, and the final processing result is output. The conflict result identification and resolution include conflict resolution based on version priority, conflict resolution based on applicable condition matching degree, and conflict resolution based on task weight.

[0068] Specifically, for the subtask processing results obtained from the aggregation, rule reference information corresponding to the final result is extracted from the rule knowledge units involved in the processing. The rule reference information includes at least rule text fragments (e.g., PDF format), rule version information, country information, and the location of the original rule document.

[0069] For conflict identification and resolution, for example, for the same toll point in the voyage, multiple rules may apply. The large model will discard the rule according to the requirements in the text, such as using the rule with the highest amount or the rule with the lowest amount.

[0070] For example, the final intelligent auxiliary processing results of the rules for collecting additional fees on behalf of air passengers, output through a pre-trained large model, should include at least: Collection point; Types of tax collection points; Types of fees levied; Name of the fee; Taxation by country / region; Amount levied; The rules are based on the cited information; Rule version information.

[0071] In one embodiment, the final processing result, namely the intelligent auxiliary processing result of the rules for collecting additional fees on behalf of air passengers, may also include explanatory text descriptions. These explanatory text descriptions may be generated by the large model based on the processing conclusions and rule reference information, thereby improving the business readability of the results.

[0072] In one embodiment, after obtaining the final processing result, the method may further include: calling a pre-trained large model to determine the semantic correspondence between the final processing result and the rule text fragments in the rule knowledge unit involved in the processing, and assisting in generating business review data; the business review data includes the binding data between the rule text fragments, rule version information, rule basis reference information and the final processing result.

[0073] During implementation, the large model is invoked to assist in generating the binding between the rule text fragments, rule version information, and original rule document location information and the processing conclusion based on the semantic correspondence between the final processing conclusion (i.e., the output collection country / region, xx fee type code, amount xxxx, and the referenced content is the detailed text of the applicable rule) and the candidate rule text fragments.

[0074] Considering that there may be many candidate rules, the final conclusion needs to be determined after processing the rule priorities. In one implementation, the large model is also used to determine the correspondence between the candidate reference content and the final processing conclusion, and to generate a basis description suitable for business review.

[0075] For example, given the country, fee code, and amount (xxxx), the output reference content would be: Passengers departing from country xx will be charged a fee of xxx, which is xxxx yuan for adults, xxxx yuan for children, and is waived for infants; For domestic travelers departing from country xx, a fee of xxx will be charged: adults xxxx yuan, children xxxx yuan, and infants are exempt from the fee. For individuals with special status, the fee is waived.

[0076] In one embodiment, the pre-trained large model displays a processing phase during the processing, receiving data from the user for corrective processing; After obtaining the final processing result, the method may further include: preserving the context information of the user-input correction processing data to optimize the processing of the pre-trained large model.

[0077] During implementation, for results that are manually confirmed or corrected during the dispute resolution process, the system will use them as optimization samples and feed them back into the knowledge processing flow.

[0078] In summary, for the intelligent processing scenario of collecting additional fees on behalf of air passengers, this invention proposes a set of intelligent rule processing flow: "rule text import and splitting - construction of multi-version domain knowledge base - receiving processing requests - determining rule version - routing by country and fee type - decomposition of rule processing tasks - scheduling and execution of sub-tasks - result aggregation - generation of rule based on reference information - output of intelligent auxiliary processing results".

[0079] Specifically, the first step is to version control the relevant rules for collecting additional fees on behalf of air passengers, and then organize the knowledge according to the country / region as the first level and the fee type as the second level. The rule documents are then segmented at the fee type level to form a multi-version domain knowledge base. Upon receiving a request related to flight itinerary, passenger, ticketing, or fee collection processing, the system determines the target rule version based on the input ticket sales date and routes it to the corresponding country / region and fee type knowledge base partitions by combining country / region information and fee type information. Subsequently, the system generates multiple rule-based subtasks based on the collection point, collection point type, and applicable collection fee logic, and performs scheduling processing on the independent subtasks. In each subtask processing, the system calls the large model to combine the corresponding rule knowledge unit, input business conditions and task context to perform semantic understanding, condition matching judgment, exception clause identification and result summarization of the rule text. The results of each subtask are then aggregated, conflict resolved, and consistency controlled. The large model then assists in generating rule reference information corresponding to the processing results, and finally outputs the intelligent auxiliary processing results.

[0080] While maintaining the traceability of rule text, this embodiment of the invention achieves a balance between rule processing efficiency and business understandability by organizing multi-version domain knowledge bases, task decomposition and scheduling, and semantic understanding, result summarization, and rule basis binding output with the participation of large models.

[0081] Figure 3 This is a schematic diagram of the third process of the intelligent processing method for collecting additional fees on behalf of air passengers in an embodiment of the present invention, as shown below. Figure 3 As shown, the method includes: Step S301: Receiving and registering the rule text.

[0082] Obtain the relevant rules text for collecting additional fees on behalf of air passengers, and record information such as the publication time, applicable start time, applicable end time, version identifier, and document source identifier of the rules text.

[0083] In one implementation, the system establishes version records for multiple rule versions within the same year and retains the temporal and substitution relationships between versions for subsequent knowledge base routing and version matching processing.

[0084] Step S302: Rule text splitting and rule knowledge unit construction.

[0085] The rule text received in step S301 is parsed and split into rule knowledge units that can be retrieved and processed. The splitting is preferably performed along two dimensions: country and fee type, with the rule document segmentation completed at the fee type granularity.

[0086] In one implementation, each rule knowledge unit is associated with at least the original rule text fragment, the rule version to which it belongs, the country to which it belongs, the type of levy to which it belongs, the applicable conditions, and the location of the original rule document.

[0087] Step S303: Construction of a multi-version domain knowledge base.

[0088] Based on the rule knowledge units formed in step S302, a multi-version domain knowledge base is constructed. The multi-version domain knowledge base is preferably organized according to the country as the first level and the fee type as the second level, with corresponding knowledge base partitions established under different versions to avoid mixed retrieval of rules from different versions.

[0089] Step S304: Process the request reception.

[0090] Receive requests related to the processing of rules for collecting additional fees on behalf of air passengers. Such requests may include one or more of the following: flight information, passenger information, ticketing information, place of sale information, ticket sales date, and fee inquiry criteria.

[0091] In one implementation, the request can be either a natural language description or a structured business parameter input.

[0092] Step S305: Analyze the flight path structure and determine the rule version.

[0093] Based on the request received in step S304, the flight path structure and business conditions related to the application of the rules are parsed out, including at least the overall flight path, each transport segment, departure point, arrival point, transit point, sales point, passenger category, and ticket sales date.

[0094] In one implementation, the system determines the target rule version based on the input ticket sales date and uses the target rule version as a prerequisite for subsequent knowledge base routing. For example, if there are four rule versions: 20240101, 20240401, 20240701, and 20241001, and the sales date is 20240301, then rule version 20240101 should be used for subsequent knowledge base partition retrieval.

[0095] Step S306: Target knowledge base routing based on version, country / region, and cost type.

[0096] Based on the target rule version determined in step S305, as well as the country / region information and fee type information corresponding to the rule processing object, routing is performed on the multi-version domain knowledge base to determine the corresponding country / region level and fee type level target knowledge base partitions.

[0097] After determining the target rule version, it is further routed to the target levy type knowledge unit set under the corresponding country.

[0098] Step S307: Decompose the rule processing task.

[0099] Based on the rule processing object information obtained in step S305 and the target knowledge base partition determined in step S306, the rule processing request is decomposed into multiple rule processing sub-tasks.

[0100] Based on the collection point, collection point type, and collection fee type, corresponding rule processing sub-tasks are generated. A rule processing task refers to a sub-task generated based on input flight information, passenger information, ticketing information, or query conditions, targeting a specific collection point, collection fee type, or applicable stage, for the intelligent processing objective of air passenger transport surcharge rules. For example, rule processing sub-tasks can at least include processing tasks for sales-type collection points, departure-type collection points, and arrival-type collection points.

[0101] In one implementation, each rule processing subtask forms a task input unit for the large model, enabling the large model to perform fine-grained processing of the rule text under the conditions of limiting the collection point, limiting the type of collection point, and limiting the type of collection fee.

[0102] Step S308: Subtask scheduling and parallel processing.

[0103] The system processes subtasks according to the rules generated in step S307 and performs task scheduling. For multiple independent collection point processing subtasks, the system performs rule retrieval in parallel at the collection point level and calls the large model to perform semantic understanding, condition judgment, and result summarization on the rule knowledge units corresponding to each subtask. For subtasks with dependencies, they are executed in the order of dependency.

[0104] In one implementation, the large model is used during the subtask processing phase to perform at least the following processes: (1) Identify the applicable conditions, exceptions, and explanatory notes in the rule text; (2) Determine the matching relationship between the rule text and the current collection point, collection point type, and collection fee type; (3) Summarize the sub-task processing conclusions and corresponding explanatory information.

[0105] Task scheduling includes mechanisms for processing subtasks based on their independence and dependencies, such as sequential execution, parallel execution, aggregated processing, or conflict resolution.

[0106] Step S309: Subtask results aggregation and conflict resolution.

[0107] The processing results of multiple subtasks obtained in step S308 are uniformly aggregated. The aggregation process includes at least result classification, duplicate result identification, conflict result identification, and conflict resolution based on version priority, applicable condition matching degree, and task weight.

[0108] In one implementation, the system also performs a consistency check on the aggregation results to determine whether there are logical contradictions or missing rule support information in the final results.

[0109] In one implementation, the system can also call a large model to help summarize the differences and conflict reasons between the processing results of multiple subtasks, so as to form a unified result description that is more suitable for business understanding and review.

[0110] Step S3010: The rule is generated based on the reference information.

[0111] Based on the rule processing results obtained in step S309, the system extracts the rule reference information corresponding to the final result from the rule knowledge units involved in the processing. It then calls upon the large model to assist in binding and generating the rule text fragments, rule version information, and original rule document location information with the processing conclusion, based on the semantic correspondence between the final processing conclusion and the candidate rule text fragments. The rule reference information can be implemented using page number location, paragraph location, clause number location, or rule knowledge unit identifier location.

[0112] In one implementation, the rule can locate a specific page number, paragraph, or clause in the original rule document based on the reference information.

[0113] In one implementation, the large model is used to determine the correspondence between candidate references and the final processing conclusion, and to generate supporting documentation suitable for business review.

[0114] Step S3011: Output the intelligent auxiliary processing results.

[0115] The intelligent auxiliary processing results include rule processing conclusions, candidate results, or applicable instructions generated by the system based on rule retrieval, semantic understanding, task decomposition, result aggregation, and rule-based citation information. These results are used to support manual judgment, business processing, dispute analysis, or subsequent process execution. The intelligent auxiliary processing results include at least: Collection point; Types of tax collection points; Types of fees levied; Name of the fee; Applicable countries; Applicable amount; The rules are based on the cited information; Rule version information.

[0116] In one implementation, the explanatory text in the intelligent assisted processing results can be generated by the large model based on the processing conclusions and rule reference information, thereby improving the business readability of the results.

[0117] During implementation, the final processing conclusion is output, along with the corresponding rule text fragments, rule version information, and the location of the original rule document, to establish a binding relationship of "conclusion-basis-version," thereby improving business comprehension, review convenience, and dispute resolution support capabilities.

[0118] Step S3012: Feedback recording and knowledge optimization.

[0119] Record the request information, knowledge base routing results, subtask execution results, final output results, and human feedback information during this rule intelligent processing process, and use them for subsequent optimization of rule knowledge unit splitting strategies, routing rules, task decomposition strategies, and processing prompt configurations.

[0120] In one implementation, for results that are manually confirmed or corrected during the dispute resolution process, the system uses them as optimization samples and feeds them back into the knowledge processing flow.

[0121] This invention also provides a system for implementing the above method, comprising: (1) Rule knowledge construction unit, used to receive rule text and perform version registration, country and fee type granularity splitting and rule knowledge unit construction processing; (2) Multi-version knowledge base management unit, used to build multi-version domain knowledge bases based on rule knowledge sets, and to organize, index and manage rule knowledge units according to country as the first level and fee type as the second level; (3) Request parsing and routing unit, used to receive rule processing requests, and parse the itinerary structure, passenger conditions, sales conditions and ticket sales date in the request, determine the target rule version, and route to the corresponding target knowledge base partition in combination with country information and levy type information; (4) Task decomposition and scheduling unit, used to decompose the rule processing request into multiple rule processing sub-tasks according to the collection point, collection point type and applicable logic of collection fee, and perform sequential scheduling or parallel scheduling according to the independence and dependency relationship between the sub-tasks. (5) Rule processing and result aggregation unit, which is used to perform rule retrieval on each rule processing subtask, and call the large model to perform semantic understanding, condition judgment and result summarization on the corresponding rule knowledge unit. At the same time, it aggregates, deduplicates, identifies and resolves conflicts of multiple subtask processing results to generate a unified rule processing result. (6) Rule reference information and result output unit, which is used to extract the corresponding rule reference information based on the final rule processing result, and call the large model to help generate the binding description between the processing conclusion and the rule text fragment, and output the intelligent auxiliary processing result containing the collection point, collection point type, collection fee type, collection fee name, applicable country, rule-specified amount, applicable amount and rule reference information.

[0122] Among them, the amount stipulated in the rules refers to the amount standard specified, published or clearly listed in the rule text, and the applicable amount refers to the amount that is ultimately applicable at the current collection point, in the current version and under the current applicable conditions.

[0123] A rule may have multiple paragraphs describing rules for different scenarios. The applicable conditions of these rule paragraphs are not necessarily mutually exclusive, but may all apply. The large model makes a secondary judgment based on the priority of the descriptions to arrive at the final applicable rule.

[0124] For example: Rule 1: Passengers traveling domestically from their home country will be charged 50 yuan; Rule 2: Passengers traveling on special aircraft types for domestic trips departing from this country are exempt from fees; In the process of identifying and resolving conflicts in the processing results of all sub-tasks, the large model automatically determines the priority as exemption from collection over collection. That is, if both rule 1 and rule 2 are met, rule 2 is taken.

[0125] The aforementioned units can be deployed on the same server or distributed across multiple processing nodes, and collaboratively complete the intelligent rule processing process through interface calls, task scheduling mechanisms, or message passing mechanisms.

[0126] The technical solution will be illustrated with specific examples.

[0127] Example 1: Rule version determination based on ticket sales date.

[0128] After receiving a rule processing request, the system first extracts the ticket sales date and matches the target rule version based on the ticket sales date. When multiple historical versions exist for the same country and the same levy type, the system only performs subsequent processing within the knowledge base of the target version corresponding to the sales date.

[0129] Example 2: Rule retrieval example based on country and levy type routing.

[0130] After determining the target rule version, the system routes the data to the target collection fee type knowledge unit set under the corresponding country based on the country and fee type information of the rule processing object, thereby avoiding retrieval in irrelevant countries or irrelevant collection fee type rules.

[0131] Example 3: Example of task decomposition and parallel processing based on the collection point dimension.

[0132] The system receives a rule processing request for a multi-segment international flight, parses out multiple collection points, and determines their types. Subsequently, the system generates corresponding rule processing subtasks for each collection point and performs parallel processing on these independent subtasks. Within each collection point's subtask, the system invokes a large model to perform semantic understanding and applicability assessment on rule knowledge units within the corresponding version, country, and collection fee type, and generates the processing results for each subtask.

[0133] Example 4: Example of outputting results with clause references.

[0134] After aggregating the results of multiple subtasks, the system obtains the final intelligent auxiliary processing result. Simultaneously, it extracts the corresponding rule text fragments, rule version information, applicable country information, and the location of the original rule document, and outputs them in a structured format, bound to the conclusion. Business personnel can directly use the rule-based citation information for dispute resolution and review. The system further invokes a large model to generate a rule-based explanation bound to the processing conclusion based on the semantic correspondence between the final processing conclusion and the candidate rule text fragments, and outputs citation information that business personnel can directly verify.

[0135] This invention also provides an intelligent processing device for collecting surcharges on behalf of air passengers, as described in the following embodiments. Since the principle by which this device solves the problem is similar to the intelligent processing method for collecting surcharges on behalf of air passengers, the implementation of this device can refer to the implementation of the intelligent processing method for collecting surcharges on behalf of air passengers, and repeated details will not be elaborated further.

[0136] Figure 4 This is a schematic diagram of the intelligent processing device for collecting additional fees on behalf of air passengers in an embodiment of the present invention, as shown below. Figure 4 As shown, the device 400 includes: The knowledge base construction module 401 is used to construct a multi-version domain knowledge base using the rule text of the air passenger additional fee collection; the multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: publishing entity, fee type, applicable stage, version, and rule text fragment; The request receiving module 402 is used to, when receiving a processing request for air passenger surcharge collection, parse the flight structure and ticket sales date from the processing request; the flight structure includes segment information from the origin to the destination and sales location information; the processing request includes a scope description information for air passenger surcharge collection processing; The knowledge base routing module 403 is used to obtain the rule knowledge unit for ticket adaptation from the multi-version domain knowledge base based on the flight path structure and ticket sales date. The task decomposition module 404 is used to decompose the task using the flight path structure and the rule knowledge unit adapted to the ticket, and generate multiple sub-tasks; the sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; The task scheduling and result output module 405 is used to schedule and execute multiple sub-tasks through a pre-trained large model, and summarize the processing results of all sub-tasks to obtain the final processing result; the final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

[0137] In one embodiment, the knowledge base construction module 401 is specifically used for: Obtain the text of the rules for collecting additional fees on behalf of air passengers, and record the metadata information of the text of the rules for collecting additional fees on behalf of air passengers; the metadata information includes at least one of the following: publication time, applicable start time, applicable end time, version, and source identifier; The text of the rules for collecting additional fees on behalf of air passengers is parsed and broken down according to the fee type, forming multiple rule knowledge units; each rule knowledge unit is associated with a position in the original rule text; Multiple rule knowledge units are organized by region as the first level and cost type as the second level, and corresponding knowledge base partitions are established under different versions to form a multi-version domain knowledge base.

[0138] In one embodiment, the device 400 further includes a version record processing module, used for: Before the knowledge base construction module 401 organizes multiple rule knowledge units into a multi-version domain knowledge base by region as the first level and fee type as the second level, and establishes corresponding knowledge base partitions under different versions, for multiple versions of the air passenger surcharge collection rule text published by the same publishing entity in the same year, an independent version record is established for each version. The version record includes: a unique version identifier, an effective time, and the identifier of the predecessor version it replaces. It supports determining the order of each version on the timeline through the effective time, and establishing a replacement relationship chain between adjacent versions through the predecessor version identifier.

[0139] In one embodiment, the processing request is in the form of a natural language description or structured business parameters; The request receiving module 402 is specifically used for: By using a pre-trained large model, the flight path structure and ticket sales date are parsed from the processing request.

[0140] In one embodiment, the flight path structure includes the overall flight route, each transport segment, departure point, arrival point, transit point, and sales point; the fee types include sales-related fees and transportation-related fees. The knowledge base routing module 403 is specifically used for: The appropriate region and fee type are determined based on the flight route structure, and the appropriate version is determined based on the ticket sales date. The appropriate region, appropriate cost type, and appropriate version are used as the input constraints of the pre-trained large model. The rule knowledge unit for ticket adaptation is obtained by matching the pre-trained large model with the multi-version domain knowledge base.

[0141] In one embodiment, the task decomposition module 404 is specifically used for: Collection points are constructed in advance using rule knowledge units; the collection points include applicable rules and calculation rules for collecting additional fees, and the applicable rules include geographical location and charging conditions; The collection point is determined based on the rule knowledge unit for ticket adaptation; Multiple sub-tasks are generated based on the flight path structure and collection points.

[0142] In one embodiment, the task scheduling and result output module 405 is specifically used for: The execution order of subtasks is determined based on whether there are dependencies between them. At least the following processing should be performed on a pre-trained large model: Identify the applicable conditions, exceptions, and explanatory notes in the rule text fragments of the rule knowledge unit that the ticket is adapted to; Determine the matching relationship between the rule text of the rule knowledge unit that the ticket is compatible with and the current collection point and collection fee type; Summarize the sub-task processing conclusions and corresponding explanatory information; The execution of subtasks is scheduled based on their execution order, processing results, and corresponding explanatory information.

[0143] In one embodiment, the task scheduling and result output module 405 is specifically used for: The rule-based reference information is extracted from the rule knowledge unit involved in the processing; the rule-based reference information can locate the specific page number, paragraph, or clause position in the original rule text. By using a pre-trained large model, the processing results of all sub-tasks are classified, duplicate results are identified, conflict results are identified, and at least one of these is resolved, and the final processing result is output. The conflict result identification and resolution include conflict resolution based on version priority, conflict resolution based on applicable condition matching degree, and conflict resolution based on task weight.

[0144] In one embodiment, the device 400 further includes a business review data generation module, used for: After the task scheduling and result output module 405 obtains the final processing result, it calls the pre-trained large model to determine the semantic correspondence between the final processing result and the rule text fragments in the rule knowledge unit that participated in the processing, and assists in generating business review data; the business review data includes the binding data between the rule text fragments, rule version information, rule basis reference information and the final processing result.

[0145] In one embodiment, the pre-trained large model displays a processing phase during the processing, receiving data from the user for corrective processing; The device 400 also includes a data retention module for: After the task scheduling and result output module 405 obtains the final processing result, it retains the context information of the user-input correction data for use in optimizing the processing of the pre-trained large model.

[0146] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0147] Figure 5This is a schematic diagram of a computer device in an embodiment of the present invention, such as... Figure 5 As shown, this embodiment of the invention also provides a computer device 500, including a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, it implements the above-mentioned intelligent processing method for collecting additional fees on behalf of air passengers.

[0148] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0149] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described intelligent processing method for collecting additional fees on behalf of air passengers.

[0150] Compared with the prior art, the embodiments of the present invention have the following beneficial technical effects: (1) By using a rule version determination mechanism based on the ticket sales date, rule version mismatch can be reduced; (2) By constructing a multi-version domain knowledge base organized at two levels, based on the country and the type of fee levied, the accuracy of rule routing and retrieval can be improved; (3) By segmenting rule documents at the cost type granularity, the targeting of rule processing can be improved; (4) By using a task decomposition and parallel scheduling mechanism based on the collection point dimension, the processing efficiency in complex flight scenarios can be improved; (5) By retaining rule text fragments and outputting rule basis reference information bound to the processing conclusion, business personnel can improve their understanding of the rule source, applicable basis and judgment process and the convenience of review; (6) By introducing large models to participate in the semantic understanding of rule texts, matching of applicable conditions, summarization of subtask results and generation of rule basis binding, the processing accuracy, interpretability and business readability in complex rule scenarios can be improved. (7) By achieving structured processing and intelligent auxiliary judgment while maintaining the traceability of rule text, it is possible to better balance processing efficiency and business understandability.

[0151] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0153] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0155] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for intelligently processing additional fees collected on behalf of air passengers, characterized in that, include: Utilize the rules text for collecting additional fees on behalf of airline passengers to construct a multi-version domain knowledge base; The multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: publishing entity, fee type, applicable stage, version, and rule text fragment; When a processing request for collecting additional fees on behalf of air passengers is received, the flight structure and ticket sales date are parsed from the processing request; the flight structure includes segment information from the origin to the destination and sales location information; the processing request includes a description of the scope of processing for collecting additional fees on behalf of air passengers. Based on the flight itinerary structure and ticket sales date, rule knowledge units for ticket adaptation are obtained by matching from a multi-version domain knowledge base; The task is decomposed using the flight path structure and the rule knowledge unit that adapts the ticket, generating multiple sub-tasks; The sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; By pre-training a large model, multiple sub-tasks are scheduled and executed, and the processing results of all sub-tasks are summarized to obtain the final processing result. The final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

2. The method as described in claim 1, characterized in that, Using the rules for collecting additional fees on behalf of airline passengers, a multi-version domain knowledge base is constructed, including: Obtain the text of the rules for collecting additional fees on behalf of air passengers, and record the metadata information of the text of the rules for collecting additional fees on behalf of air passengers; the metadata information includes at least one of the following: publication time, applicable start time, applicable end time, version, and source identifier; The text of the rules for collecting additional fees on behalf of air passengers is parsed and broken down according to the fee type, forming multiple rule knowledge units; each rule knowledge unit is associated with a position in the original rule text; Multiple rule knowledge units are organized by region as the first level and cost type as the second level, and corresponding knowledge base partitions are established under different versions to form a multi-version domain knowledge base.

3. The method as described in claim 1, characterized in that, Before organizing multiple rule knowledge units by region as the first level and cost type as the second level, and establishing corresponding knowledge base partitions under different versions to form a multi-version domain knowledge base, the following steps are also included: For multiple versions of the rules for collecting additional fees on behalf of air passengers issued by the same issuing entity in the same year, an independent version record is established for each version. The version record includes: a unique version identifier, an effective date, and the identifier of the previous version it replaces. It supports determining the order of each version on the timeline through the effective date and establishing a replacement relationship chain between adjacent versions through the identifier of the previous version.

4. The method as described in claim 1, characterized in that, The processing request can be in the form of a natural language description or a structured business parameter. The flight itinerary structure and ticket sales date are parsed from the processing request, including: By using a pre-trained large model, the flight path structure and ticket sales date are parsed from the processing request.

5. The method as described in claim 2, characterized in that, The flight path structure includes the overall flight route, each transport segment, departure point, arrival point, transit point, and sales point; the fee types include sales-related fees and transportation-related fees. Based on the flight itinerary structure and ticket sales date, rule knowledge units for ticket adaptation are obtained by matching from a multi-version domain knowledge base, including: The appropriate region and fee type are determined based on the flight route structure, and the appropriate version is determined based on the ticket sales date. The appropriate region, appropriate cost type, and appropriate version are used as the input constraints of the pre-trained large model. The rule knowledge unit for ticket adaptation is obtained by matching the pre-trained large model with the multi-version domain knowledge base.

6. The method as described in claim 1, characterized in that, The task is decomposed using the flight path structure and the rule knowledge units for ticket adaptation, generating multiple sub-tasks, including: Collection points are constructed in advance using rule knowledge units; the collection points include applicable rules and calculation rules for collecting additional fees, and the applicable rules include geographical location and charging conditions; The collection point is determined based on the rule knowledge unit for ticket adaptation; Multiple sub-tasks are generated based on the flight path structure and collection points.

7. The method as described in claim 1, characterized in that, By pre-training a large model, multiple sub-tasks are scheduled for execution, including: The execution order of subtasks is determined based on whether there are dependencies between them. At least the following processing should be performed on a pre-trained large model: Identify the applicable conditions, exceptions, and explanatory notes in the rule text fragments of the rule knowledge unit that the ticket is adapted to; Determine the matching relationship between the rule text of the rule knowledge unit that the ticket is compatible with and the current collection point and collection fee type; Summarize the sub-task processing conclusions and corresponding explanatory information; The execution of subtasks is scheduled based on their execution order, processing results, and corresponding explanatory information.

8. The method as described in claim 1, characterized in that, The processing results of all subtasks are summarized to obtain the final processing result, including: The rule-based reference information is extracted from the rule knowledge unit involved in the processing; the rule-based reference information can locate the specific page number, paragraph, or clause position in the original rule text. By using a pre-trained large model, the processing results of all sub-tasks are classified, duplicate results are identified, conflict results are identified and resolved at least once, and the final processing result is output. The conflict result identification and resolution include conflict resolution based on version priority, conflict resolution based on applicable condition matching degree, and conflict resolution based on task weight.

9. The method as described in claim 1, characterized in that, After obtaining the final processing result, it also includes: The pre-trained large model is invoked to determine the semantic correspondence between the final processing result and the rule text fragments in the rule knowledge unit involved in the processing, thereby assisting in the generation of business review data. The business review data includes the binding data between the rule text fragments, rule version information, rule basis reference information, and the final processing result.

10. The method as described in claim 1, characterized in that, The pre-trained large model displays the processing stage during the processing process and receives data from the user for correction and processing. After obtaining the final processing result, it also includes: The contextual information of the user-input correction data is preserved and used to optimize the processing of pre-trained large models.

11. A smart processing device for collecting additional fees on behalf of air passengers, characterized in that, include: The knowledge base construction module is used to build a multi-version domain knowledge base using the rules text for collecting additional fees on behalf of air passengers. The multi-version domain knowledge base stores multiple rule knowledge units, and each rule knowledge unit has at least one of the following: publishing entity, fee type, applicable stage, version, and rule text fragment; The request receiving module is used to parse the flight structure and ticket sales date from the processing request when it receives a processing request for air passenger surcharge collection. The flight structure includes segment information from the origin to the destination and sales location information. The processing request includes a scope description information for air passenger surcharge collection processing. The knowledge base routing module is used to match the ticket-fitting rule knowledge units from multiple versions of the domain knowledge base based on the flight path structure and ticket sales date. The task decomposition module is used to decompose tasks using the flight path structure and the rule knowledge unit adapted to the ticket, generating multiple sub-tasks. The sub-tasks include cost calculation tasks for different applicable stages and different geographical locations; The task scheduling and result output module is used to schedule and execute multiple sub-tasks through a pre-trained large model, and summarize the processing results of all sub-tasks to obtain the final processing result. The final processing result includes at least one of the following dimensions: publishing entity, fee type, applicable stage, version, amount, and rule basis reference information.

12. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 10.

Images