Airline operation and maintenance multi-round question and answer method based on abstract and key entity

Abstract

The application discloses an aviation maintenance multi-round question and answer method based on abstracts and key entities, and belongs to the technical field of aviation maintenance knowledge base, document index, retrieval enhancement generation and multi-round dialogue management. The method comprises the following steps: reading historical abstracts, recent dialogues and maintenance object states; integrating conversation memory and arranging states; completing questions and forming the current state and retrieval conditions; positioning document anchors; recalling candidate materials and sorting them according to states; screening evidence and judging sufficiency, and supplementing retrieval when insufficient; generating a referenced answer or a material shortage statement; and updating the historical abstracts and states. The application can effectively prevent object confusion, reduce repeated suggestions and evidence-free answers by converting the maintenance object state into retrieval conditions, realizing state-driven retrieval enhancement closed loop.

Description

Technical Field

[0001] This invention relates to the fields of aviation maintenance knowledge base, document indexing, retrieval enhancement generation, and multi-turn dialogue management technology, specifically to a multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities. Background Technology

[0002] Aviation maintenance documentation typically includes various manuals such as AMM, FIM, SDS, AIPC, and WDM. These documents have a deep hierarchical structure, numerous coding rules, and a clear sequential relationship between fault isolation and maintenance procedures. The same component may even appear in different manuals. When troubleshooting, maintenance personnel usually ask a series of questions, such as first describing the fault symptoms, then providing details of completed checks and results, and finally inquiring about the next necessary checks or maintenance procedures.

[0003] Existing multi-turn question-and-answer systems generally handle historical dialogues in two ways: one is to directly append all historical messages to the current question, and the other is to compress the historical messages into a summary. The former method causes the input content to increase with each turn and mixes in information that is no longer valid or irrelevant to the current question; the latter method, although it can shorten the input, often fails to differentiate the fault symptoms, inspected items, eliminated causes, and items to be verified according to the specific repair object.

[0004] When multiple fault codes appear simultaneously in a dialogue involving the left and right engines, different components, or multiple fault codes, if the system cannot continuously save the current status of each repair object, the following results may easily occur in subsequent processing: the problem completion references the wrong object; the search results repeatedly return checks that have already been completed; information that conflicts with the user's inspection results is still ranked at the top; evidence from different objects is merged; and when there is insufficient information, a seemingly complete but manual-lacking answer is still generated.

[0005] Therefore, it is essential to design a multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities. This method saves the current troubleshooting status according to the maintenance object without retaining all historical dialogues, and allows the status to actually participate in question completion, search condition formation, candidate data screening, and the next round of status updates. This reduces object confusion, duplicate inspection suggestions, and unfounded answers. Summary of the Invention

[0006] The purpose of this invention is to provide a multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities. By converting the status of maintenance objects into search conditions, a state-driven search enhancement closed loop is achieved, which can effectively prevent object confusion, reduce duplicate suggestions and unfounded answers.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A multi-turn question-answering method for aviation operations and maintenance based on summaries and key entities includes: Step S1: Receive the current problem, read the historical summary, recent dialogue text, and existing maintenance object status saved at the maintenance object level corresponding to the current session; Step S2: Integrate historical summaries and recent dialogue transcripts into conversation memory, and organize the status of existing maintenance objects; Step S3: Utilize the session memory and the organized existing maintenance object status to complete the reference and maintenance object for the current problem, merge the user's newly stated status with the existing status to form the maintenance object status for this round, and generate search conditions accordingly; Step S4: Based on the normalized entities or codes extracted from the status of the maintenance objects in this round, locate the document anchor points and determine the priority document route for retrieval according to the task type; Step S5: Perform a hybrid search based on search criteria and document routing to retrieve candidate data, and sort the candidate data according to the status of the maintenance object in this round; Step S6: Select reliable evidence from the sorted candidate data and determine the sufficiency of the data; if the data is insufficient and the preset search limit has not been reached, generate supplementary search terms based on the missing content and return to step S5 to search again; Step S7: When the data is sufficient, generate an answer with cited sources based on reliable evidence and perform citation verification on the answer; when the data is insufficient and the search limit is reached, generate an explanation of insufficient data. Step S8: Update the historical summary and existing maintenance object status based on the current question, the status of the maintenance object in this round, the final answer and its source of reference, for use in the next round of sessions.

[0008] Furthermore, in step S1, the historical summary is a compressed text generated from the fault background, inspection results, and unresolved issues that are still valid in earlier rounds of dialogue; the recent dialogue text is a number of recent uncompressed user messages and system responses; and the existing maintenance object status is persistently saved using the entity identifier as the key.

[0009] Furthermore, in step S2, the status of existing maintenance objects is organized, specifically as follows: Organize them separately according to entity identifier. When there are multiple records for the same field under the same entity identifier, the latest valid record is obtained according to the version number and update time. Information whose belonging object cannot be determined is not merged into any known entity.

[0010] Furthermore, in step S3, using the session memory and the organized existing maintenance object status, the current problem is completed by referencing and completing the maintenance object. The newly stated status by the user is merged with the existing status to form the maintenance object status for this round, and search conditions are generated accordingly, specifically: Based on conversational memory and the status of existing maintenance objects, complete the omitted subject, maintenance object, location, fault code, and completed checks in the current problem; Extract the fault symptoms, inspection actions, and inspection results explicitly stated by the user, and merge them with the existing status to form the status of the maintenance object in this round; When multiple maintenance objects or multiple troubleshooting diagrams are involved, sub-tasks are created separately and each sub-task is bound to the corresponding entity identifier. Standardize entity names and maintenance-related codes; Search criteria are generated based on the status of the maintenance objects in this round: maintenance objects, fault phenomena, and standardized codes are used to limit or increase the priority of corresponding data; inspected items and results are used to identify troubleshooting progress; eliminated causes are used to filter or reduce the priority of related data; and items to be verified are used to increase the priority of data containing subsequent inspection content.

[0011] Furthermore, the search criteria include at least: limiting conditions or weighting coefficients formed by the repair object, fault phenomenon and standardized code, and priority adjustment information formed by the inspected items and results, ruled-out causes and items to be verified.

[0012] Further, in step S4, based on the normalized entity or code extracted from the status of the maintenance object in this round, the document anchor point is located, and the document route for priority retrieval is determined according to the task type, specifically as follows: Use normalized encoding for exact matching, use normalized entities and their aliases to match document chapters, and obtain the chapter identifier, document identifier, document type, applicable model, version and chapter path after a match; The document route for priority retrieval is determined based on the subtask type: troubleshooting tasks prioritize retrieving fault isolation manuals and aircraft maintenance manuals, while cause and principle-related tasks prioritize retrieving system description manuals and aircraft maintenance manuals; when the type cannot be determined or the document anchor point is not hit, a full database search is used.

[0013] Furthermore, in step S5, the candidate data is sorted according to the status of the maintenance object in this round, specifically as follows: When the maintenance object corresponding to the candidate data is inconsistent with the object in the status of the maintenance object in this round, it shall be filtered or downweighted. When the applicable premises or judgment conclusions of candidate data conflict with the inspection results explicitly given by the user, they shall be filtered or downgraded. Candidate data that merely repeats already completed checks and does not provide subsequent steps will be downgraded in weight. When candidate data covers the items to be verified in the current maintenance object status, or hits the exact code, or hits the document anchor point, its priority is increased.

[0014] Further, in step S6, reliable evidence is screened from the sorted candidate data and the sufficiency of the data is determined; if the data is insufficient and the preset search limit is not reached, supplementary search terms are generated based on the missing content, and the process returns to step S5 for another search, specifically: Eliminate candidate data that is irrelevant to the current subtask, does not match the repair object, conflicts with the user's explicit status, or is below the preset responsiveness threshold, and organize the evidence according to the task type; Determine whether the evidence after organization can fully answer the current subtask; If the data is insufficient, record the missing data types and the confirmed prior status, and generate the supplementary search terms; the supplementary search terms retain the maintenance objects and completed inspection results, and only supplement the missing operation stages or procedure types; Set a maximum number of retrieval rounds and a time limit for each subtask; if there is still insufficient data after reaching the limit, send the insufficient results to step S7.

[0015] Furthermore, in step S7, when sufficient data is available, an answer with cited sources is generated based on reliable evidence, and the answer undergoes citation verification; when insufficient data is available and the search limit is reached, an explanation of insufficient data is generated, specifically: When all necessary sub-tasks have sufficient data, an answer is generated based on reliable evidence, and the source of the citation is marked after the answer statement; the operation steps, parameters, fault codes, part numbers, and scope of application in the answer are consistent with the reliable evidence; When any necessary subtask has insufficient data and the retrieval limit is reached, an explanation of insufficient data is generated, and general knowledge is not used to supplement the maintenance conclusion. The generated answers are validated for citations, and at least the following checks are performed: whether the citation number exists, whether the cited statement is supported by corresponding evidence, and whether the model, version, and scope of application of the cited materials are consistent; if the validation fails, the relevant statements are regenerated or deleted.

[0016] Furthermore, in step S8, based on the current question, the status of the maintenance object in this round, the final answer and its cited sources, the historical summary and the existing maintenance object status are updated for use in the next round of sessions, specifically as follows: When updating the history summary, retain the model, component, fault code, current fault phenomenon, inspected items and results, eliminated causes and items to be verified, and delete duplicate or completed content that is irrelevant to subsequent troubleshooting. When updating the status of a repair object, only the fault symptoms, performed checks, and check results explicitly stated by the user in the current problem are written to the corresponding fields; suggestions that have not yet been implemented in the final answer are written to the pending verification items; ruled-out causes are only written when explicitly stated by the user or when preset verifiable rules are met. The status of different maintenance objects is updated separately, and version numbers are used to prevent old status from overwriting new status.

[0017] Furthermore, the status of the maintenance object is distinguished by an entity identifier, which is composed of multiple combinations of entity type, specification name, orientation or installation location, number or fault code; the maintenance object status corresponding to different entity identifiers is isolated from each other, and the inspection results of one maintenance object are not automatically copied to other maintenance objects.

[0018] In summary, the beneficial technical effects of the present invention are as follows: 1. By saving the conversation summary and the original text of recent conversations separately, the latest check results and referential information are preserved while controlling the input length, effectively avoiding retrieval noise and referential loss caused by excessively long input.

[0019] 2. Different maintenance objects are stored and isolated according to their physical identifiers, which fundamentally avoids confusion between the left and right engines, different parts and different fault codes, and prevents the incorrect object from being referenced in the problem completion.

[0020] 3. The checked items, eliminated causes, and pending verification items in the maintenance object status are converted into search conditions and directly participate in the filtering and sorting of candidate data, reducing the repeated return of completed checks and making the candidate data more relevant to the current troubleshooting progress.

[0021] 4. When data is insufficient, supplementary search terms are generated based on the missing content. Targeted supplementary searches are conducted while retaining the current fault and completed inspections. Once the upper limit is reached, the insufficient data is truthfully stated to avoid generating repair conclusions that lack manual support.

[0022] 5. After the answer is generated, a citation verification is performed. The status update strictly distinguishes between user statements, verifiable rules and system suggestions to ensure the traceability of the answer and prevent suggestions that have not yet been implemented from being mistakenly updated to the completed status. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0025] like Figure 1 As shown, this invention provides a multi-turn question-answering method for aviation operations and maintenance based on summaries and key entities, including: Step S1: Receive the current problem, read the historical summary, recent dialogue text, and existing maintenance object status saved at the maintenance object level corresponding to the current session; Step S2: Integrate historical summaries and recent dialogue transcripts into conversation memory, and organize the status of existing maintenance objects; Step S3: Utilize the session memory and the organized existing maintenance object status to complete the reference and maintenance object for the current problem, merge the user's newly stated status with the existing status to form the maintenance object status for this round, and generate search conditions accordingly; Step S4: Based on the normalized entities or codes extracted from the status of the maintenance objects in this round, locate the document anchor points and determine the priority document route for retrieval according to the task type; Step S5: Perform a hybrid search based on search criteria and document routing to retrieve candidate data, and sort the candidate data according to the status of the maintenance object in this round; Step S6: Select reliable evidence from the sorted candidate data and determine the sufficiency of the data; if the data is insufficient and the preset search limit has not been reached, generate supplementary search terms based on the missing content and return to step S5 to search again; Step S7: When the data is sufficient, generate an answer with cited sources based on reliable evidence and perform citation verification on the answer; when the data is insufficient and the search limit is reached, generate an explanation of insufficient data. Step S8: Update the historical summary and existing maintenance object status based on the current question, the status of the maintenance object in this round, the final answer and its source of reference, for use in the next round of sessions.

[0026] It should be noted that this invention effectively solves the problems of object confusion, repeated returns of completed checks, and unsubstantiated answers in the prior art by separately saving the session summary, recent dialogue text, and maintenance object status organized at the maintenance object granularity, and by closing the loop of actual participation of maintenance object status in question completion, search condition formation, candidate data screening, and status update. The following detailed description, in conjunction with specific steps and embodiments, further illustrates these issues.

[0027] Data preprocessing and index building: Before real-time question-and-answer processing, the aviation maintenance manual data needs to be preprocessed and various indexes established. The system saves the manual content by document, chapter, and data fragment, and records the document identifier, document type, applicable aircraft model, version, chapter path, chapter title, page number, main text, and identifiable ATA chapter number, DMC number, CMS / EICAS information, fault code, system name, and component name. The system normalizes the Chinese and English names, abbreviations, and common spellings of the same entity, establishing a mapping between standardized entities or codes and document chapters, forming a document anchor index.

[0028] Document anchor indexes can be implemented using knowledge graphs, relational tables, inverted indexes, or key-value mappings. When using knowledge graphs, systems, components, faults, documents, and chapters can be used as nodes, and relationships such as "belongs to system," "installed in," "has a fault," and "corresponds to chapter" can be stored. When using other index structures, mapping fields that can retrieve the same chapter location and related information are stored. In addition, vector indexes and keyword indexes are simultaneously created for manual document fragments. The above indexes are formed once in the preprocessing stage and read and used in subsequent steps S4 and S5; they are not modified during this round of question answering.

[0029] The main data involved in the method and their flow locations are shown in Table 1.

[0030] Table 1. Schematic diagram of key data and circulation locations

[0031] The inputs, outputs, and subsequent destinations of each step are shown in Table 2.

[0032] Table 2. Input, output, and destination diagrams for each step.

[0033] Next, the above steps will be explained in detail: Step S1: Receive the current problem and read historical data Step S1 is used to receive the current problem, read the historical summary corresponding to the current session, the original text of recent dialogues, and the status of existing maintenance objects saved at the granularity of maintenance objects.

[0034] Specifically, the input consists of the session identifier and the current question from the user request, as well as the stored historical summaries, historical messages, and maintenance object status records corresponding to that session. The system first verifies the validity of the session ownership and the current question. If the verification passes, the original expression of the current question is retained, and the system reads the most recently successfully saved historical summary, the most recent historical messages, and the maintenance object status, using the current round of user messages as boundaries. The aforementioned historical data can be empty upon the first request. The output consists of the current question, historical summaries, recent dialogue texts, and existing maintenance object statuses. The historical summaries, recent dialogue texts, and existing maintenance object statuses proceed to step S2, while the current question continues to be used in steps S3, S7, and S8.

[0035] Step S2: Organize the session memory and the status of existing maintenance objects. Step S2 integrates the historical summary and recent dialogue text into a conversation memory, and organizes the status of existing maintenance objects.

[0036] Specifically, the historical summary and recent dialogue text output in step S1 are organized into a hierarchical conversation memory in chronological order. The status of the maintenance object is organized by entity identifier; when multiple records exist for the same field under the same entity identifier, the latest valid record is selected based on version number and update time; information whose belonging object cannot be determined is not merged into any known entity. The output is the existing maintenance object status after hierarchical conversation memory and organization, which includes at least the fault phenomenon, inspected items and results, eliminated causes, items to be verified, information source, update time, and version number. This output, along with the current problem, proceeds to step S3.

[0037] Step S3: Complete the problem and form the status of the maintenance object and search conditions for this round. Step S3 utilizes the session memory and the organized existing maintenance object status to complete the reference and maintenance object for the current problem, merges the user's newly stated status with the existing status to form the maintenance object status for this round, and generates search conditions accordingly.

[0038] Specific processing includes: combining session memory and existing maintenance object status to complete the omitted subject, maintenance object, location, fault code, and completed inspections in the current problem; extracting the fault phenomenon, inspection actions, and inspection results explicitly stated by the user, and merging them with the existing status to form the maintenance object status for this round; this status is only used in this round of operation until persistence is completed in step S8. When multiple maintenance objects or multiple troubleshooting diagrams are involved, subtasks are created separately and each subtask is bound to the corresponding entity identifier; the entity name, ATA section number, DMC number, CMS / EICAS information, and fault code are standardized.

[0039] Then, search criteria are generated based on the status of the maintenance objects in this round: maintenance objects, fault phenomena, and standardized codes are used to limit or increase the priority of corresponding data; inspected items and results are used to indicate troubleshooting progress; eliminated causes are used to filter or reduce the priority of related data; and items to be verified are used to increase the priority of data containing subsequent inspection content. The resulting search criteria include at least the limiting conditions or weighting coefficients formed by maintenance objects, fault phenomena, and standardized codes, as well as priority adjustment information formed by inspected items and results, eliminated causes, and items to be verified.

[0040] The output includes the status of the maintenance object in this round, the complete problem, subtasks, normalized entities and codes, and search criteria. Problems involving small talk, identity inquiries, historical reviews, or those clearly outside the scope of aviation maintenance are marked separately; these problems skip steps S4 to S6 and proceed directly to step S7. Maintenance data problems proceed to step S4.

[0041] Step S4: Locate document anchor points and determine document routes Step S4 locates document anchors based on the normalized entities or codes extracted from the status of the maintenance objects in this round, and determines the document routes for priority retrieval according to the task type.

[0042] Specifically, first, standardized encoding is used for precise matching, then standardized entities and their aliases are used to match document chapters, and if necessary, entity names are combined with chapter titles for matching. Upon a match, the chapter identifier, document identifier, document type, applicable aircraft model, version, chapter path, page number, and associated information are obtained. When the document anchor index is implemented using a knowledge graph, the system, component, or fault node connected to the anchor chapter can be further read; when implemented using a relational table, inverted index, or key-value mapping, the corresponding associated fields are read. Subsequently, the document route for priority retrieval is determined based on the subtask type: troubleshooting tasks prioritize retrieving Fault Isolation Manual (FIM), Troubleshooting Manual (TSM), and Aircraft Maintenance Manual (AMM); cause and principle-related tasks prioritize retrieving System Description Manual (SDS), AMM, and FIM. If the document type cannot be determined or the document anchor is not matched, a full database search is performed without interrupting subsequent processing. The document anchor, anchor association information, and document route saved by subtask are output, and together with the complete question from step S3, the status of the maintenance object in this round, and the search conditions, proceed to step S5.

[0043] Step S5: Recall candidate data and sort them according to the status of the maintenance objects in this round. Step S5 performs a hybrid search based on search criteria and document routing to retrieve candidate data and sorts the candidate data according to the status of the maintenance object in this round.

[0044] This step's input includes the complete question, the current subtask, the status of the maintenance object in this round, normalized entities and codes, search criteria, document anchors, document routes, vector indexes, and keyword indexes. Supplementary searches also include the supplementary search terms output in step S6 and existing candidate data for the subtask. Vector retrieval is performed based on the complete question or supplementary search terms, and keyword retrieval is performed based on normalized codes and aviation maintenance terminology. The chapter / fragment corresponding to the determined document anchor is added to the candidate set. Candidate data is deduplicated by document, chapter, and fragment identifiers and then reordered.

[0045] The re-ranking process considers not only semantic relevance, keyword matching, and document anchors, but also matches, marks, and processes candidate data based on the status of the maintenance object in this round: candidate data belonging to other maintenance objects or conflicting with the inspection results explicitly given by the user are filtered or downgraded; candidate data that only repeats completed inspections without providing subsequent steps are downgraded, except in cases where the manual explicitly requires repeated confirmation; and candidate data that covers the project to be verified, hits an exact code, or hits a document anchor are given higher priority.

[0046] Output the sorted candidate data, source information, relevance score, object matching flag, status conflict flag, completed duplicate check flag, pending verification item coverage flag, and search round. All output proceeds to step S6. When step S6 returns supplementary search terms, this step merges the new results with the original candidate data and re-sorts them.

[0047] Step S6: Screen reliable evidence and determine data sufficiency Step S6 filters reliable evidence from the sorted candidate data and determines the sufficiency of the data; if the data is insufficient and the preset search limit is not reached, supplementary search terms are generated based on the missing content, and the process returns to step S5 to search again.

[0048] Specifically, candidate data that is irrelevant to the current subtask, does not match the repair object, conflicts with the user's explicit status, or is below the preset responsiveness threshold is first eliminated. Then, evidence is organized according to task type: troubleshooting evidence should include continuously executable inspection, isolation, or repair steps and applicable conditions; cause-and-principle evidence should include the cause, principle, or control relationship; fact-finding evidence should include the definition, parameters, location, code meaning, or list. Next, it is determined whether the evidence can completely answer the current subtask. If data is insufficient, the target repair object, the type of missing data, the confirmed prior status, and the operational stage requiring further investigation are recorded, and supplementary search terms are generated accordingly. Supplementary search terms retain the repair object and completed inspection results, only supplementing missing operational stages or procedure types.

[0049] Set a maximum number of search rounds and a time limit for each subtask. If the data is insufficient and the limit has not been reached, supplement the search terms and return to step S5; process the next subtask after the current subtask is sufficient; proceed to step S7 when all necessary subtasks are sufficient; if the data is still insufficient after reaching the limit, send the insufficient results and missing content to step S7.

[0050] Matching candidate data with the status of maintenance objects can be accomplished using deterministic rules, classification models, or large language models. Regardless of the implementation used, it should output information such as whether the object matches, whether it conflicts with the user's status, whether it duplicates already completed checks, and whether it covers items to be verified, for use in this step. Examples of status matching rules are shown in Table 3.

[0051] Table 3 Examples of State Matching Rules

[0052] Step S7: Generate an answer and validate the citation. In step S7, when the data is sufficient, an answer with cited sources is generated based on reliable evidence, and the answer is validated for citations; when the data is insufficient and the search limit is reached, an explanation of insufficient data is generated.

[0053] Specifically, for maintenance data questions, an answer is generated based on reliable evidence only after all necessary subtasks have passed a sufficiency test. The operating steps, parameters, fault codes, part numbers, tool numbers, DMC numbers, and applicable scope in the answer should be consistent with the evidence, and a citation should be added after the corresponding statements. If any necessary subtask is insufficient and reaches the retrieval limit, the missing data is directly stated without using general knowledge to supplement the maintenance conclusion. Non-maintenance data questions are handled according to preset branches.

[0054] After the answer is generated, a citation verification process is performed: This checks whether the citation number exists, whether the numbered statements are supported by corresponding evidence, and whether the model, version, and scope of application of the cited materials are consistent. If the verification fails, the relevant statements are regenerated or deleted; if deletion does not lead to a complete conclusion, it is replaced with an explanation of insufficient data.

[0055] Output the final answer and the actual sources cited. Return to the user and proceed to step S8. Candidate materials not adopted in the final answer are not used as the basis for status updates.

[0056] Step S8: Update historical summary and maintenance object status Step S8 updates the historical summary and existing maintenance object status based on the current question, the status of the maintenance object in this round, the final answer and its source of reference, for use in the next round of sessions.

[0057] When updating the history summary, retain the model, component, fault code, current fault symptoms, inspected items and results, eliminated causes and items to be verified, and delete duplicate or completed content that is irrelevant to subsequent troubleshooting.

[0058] When updating the status of a repair object, strict distinctions are made based on the source of information: Fault phenomena explicitly stated by the user in the current question, performed checks, and check results can be written into the corresponding fields; suggestions in the final answer that have not yet been implemented can only be written to items awaiting verification, not to items already checked; ruled-out causes are only written when explicitly stated by the user, or when the system has configured a verifiable "check results and exclusion conclusions" rule that simultaneously meets the corresponding evidence, and cannot be inferred by the model itself. Different repair objects are updated separately, and version numbers are used to prevent old tasks from overwriting new statuses. If a response is refused and no new facts are added, the original summary and status remain unchanged.

[0059] The updated historical summary and maintenance object status are persistently saved for the next step S1 to read.

[0060] Multiple subtasks can be processed sequentially or in parallel, with sufficiency checks performed separately after each subtask. Entity identifiers, candidate data, sufficiency results, and supplementary search counts for each subtask should be saved separately, and the results summarized after all subtasks have been processed.

[0061] Identification and isolation of the status of objects requiring maintenance: The status of a maintenance object is distinguished by an entity identifier, which is a combination of multiple factors including entity type, specification name, orientation or installation location, number, or fault code. Left and right engines should be saved as two different objects; when the same component is installed in different locations, it should also be distinguished by location or number. The inspection results of one object should not be automatically copied to other objects. In step S3, new statuses explicitly mentioned in the current problem are first written to the status of the maintenance object in this round, without immediately overwriting the persistent record; only after the source check and version merging are completed in step S8 are they written to the next round of readable statuses, thus isolating the maintenance object statuses corresponding to different entity identifiers.

[0062] Supplementary search strategies when data is insufficient: Supplementary search terms are formed by combining the missing content of the current subtask with the status of the repair object in this round, without expanding the scope of the original problem indiscriminately. For example, if "low oil pressure in the right engine" and "oil filter check normal" are known, but the existing data does not cover the next fault isolation procedure, the supplementary search terms retain the above known conditions and add the missing procedure type or operation stage. The new data obtained from the supplementary search are merged with the original candidate data and then reordered. Each subtask can set a maximum number of search rounds and a time limit; if the data is still insufficient after reaching the limit, it enters the insufficient data branch to ensure that no unfounded answers are generated.

[0063] The present invention also provides a parameter example of an implementation method and several specific embodiments, the parameter configuration of which is shown in Table 4.

[0064] Table 4. Parameter illustration of one embodiment

[0065] Historical summaries, recent dialogue transcripts, and maintenance object status can be stored in a session table, independent status table, or message metadata. When the storage location changes, the content read in step S1 and the content updated in step S8 should remain consistent. Vector indexes can use FAISS, Milvus, Elasticsearch, or other vector retrieval components; keyword retrieval can use BM25 or other inverted index retrieval methods; document anchor indexes can be implemented using knowledge graphs, relational tables, inverted indexes, or key-value mappings. Regardless of the structure used, it should be possible to obtain the corresponding document identifier, chapter identifier, document type, applicable machine model, version, chapter path, page number, and related information based on normalized entities or codes. Candidate materials should retain document identifiers, chapter paths, text, page numbers, entity identifiers, and relevance information.

[0066] Example 1: Initial Question The user initially asks, "What could be causing the low oil pressure in the right engine?" Step S1 retrieves an empty history summary and an empty repair object status. Step S2 outputs an empty existing repair object status. Step S3 extracts "right engine" and "low oil pressure" from the current question to form the current repair object status and identifies the problem as a cause-and-effect subtask. Steps S4 to S6 search for and verify evidence within the relevant manual. If sufficient information is available, Step S7 generates an answer with chapter and page number references. Step S8 writes the user's explicitly stated fault symptoms into the "right engine" status; unexecuted inspection suggestions in the answer are only written as items to be verified.

[0067] Example 2: User completes the completed checks Following Example 1, the user inputs: "The filter has been checked and the result is normal. What should I check next?" Step S1 reads the previous summary, recent dialogue text, and the "Right Engine" status. Step S3, combining the previous text, completes the question to "After the right engine oil pressure is low and the oil filter check is normal, what fault isolation checks should be performed next?" and adds "Oil Filter: Normal" to the status of the repair object in this round. Step S5 lowers the priority of candidate data that only repeats the filter check and has no subsequent steps, and raises the priority of data that includes subsequent check steps specified in the manual and has consistent applicable conditions. Step S8 writes "Oil Filter: Normal" explicitly stated by the user into the checked items; if there is no explicit statement from the user or a verifiable rule, the ruled-out cause is not automatically written.

[0068] Example 3: Differentiating between multiple repair objects The user continues to input: "The left engine has been vibrating abnormally recently, is it related to this?" If there is only one corresponding object in the preceding text, step S3 interprets "this" as the low oil pressure of the right engine mentioned in the previous round, and adds "Left Engine - Abnormal Vibration" as the current state, creating a subtask involving both objects. If there are multiple possible referents in the preceding text, ambiguity is preserved, and the user is retrieved or prompted to supplement object information separately, without directly merging multiple objects. Steps S5 and S6 save candidate data and reliable evidence according to entity identifiers, filtering or downgrading data corresponding to incorrect engines. Step S8 updates the states of the left and right engines respectively, without writing the abnormal vibration of the left engine into the state of the right engine, and without copying the checked items of the right engine.

[0069] Example 4: Precisely Encoding Chapters When the current issue contains ATA chapter number, DMC number, CMS / EICAS information, or fault code, step S3 standardizes letter case, spaces, hyphens, and number prefixes. Step S4 uses normalized encoding to match the corresponding chapter in the document anchor index and forms a definitive document anchor. If a normal search does not retrieve the chapter, step S5 adds the anchor chapter fragment to the candidate data. After verification in step S6, step S7 retains the original encoding, document number, chapter path, page number, and scope of application in the response.

[0070] Example 5: Insufficient Data If the initial search yields relevant information but does not cover subsequent inspection steps following the current state, step S6 records the subtask as having insufficient data and notes "Missing fault isolation procedures following the current state." Supplementing the search terms retains the repair object, fault symptoms, and completed inspection results, then adds the missing procedure type, and returns to step S5 for another search. If no reliable evidence is obtained after reaching the maximum number of search rounds or time limit, step S7 explains the missing data, without the model supplementing the repair conclusion. If there is a refusal to answer and no new facts are added, step S8 does not change the original historical summary or the repair object's state.

[0071] 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.

[0072] 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.

[0073] 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 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] Contents not described in detail in this specification are prior art known to those skilled in the art. It is hereby indicated that the above description is intended to help those skilled in the art understand this invention, but does not limit the scope of protection of this invention. Any equivalent substitutions, modifications, improvements, or simplifications of the above descriptions that do not depart from the essential content of this invention fall within the scope of protection of this invention.

Claims

1. A multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities, characterized in that, include: Step S1: Receive the current problem, read the historical summary, recent dialogue text, and existing maintenance object status saved at the maintenance object level corresponding to the current session; Step S2: Integrate historical summaries and recent dialogue transcripts into conversation memory, and organize the status of existing maintenance objects; Step S3: Utilize the session memory and the organized existing maintenance object status to complete the reference and maintenance object for the current problem, merge the user's newly stated status with the existing status to form the maintenance object status for this round, and generate search conditions accordingly; Step S4: Based on the normalized entities or codes extracted from the status of the maintenance objects in this round, locate the document anchor points and determine the priority document route for retrieval according to the task type; Step S5: Perform a hybrid search based on search criteria and document routing to retrieve candidate data, and sort the candidate data according to the status of the maintenance object in this round; Step S6: Select reliable evidence from the sorted candidate data and determine the sufficiency of the data; if the data is insufficient and the preset search limit has not been reached, generate supplementary search terms based on the missing content and return to step S5 to search again; Step S7: When the data is sufficient, generate an answer with cited sources based on reliable evidence and perform citation verification on the answer; when the data is insufficient and the search limit is reached, generate an explanation of insufficient data. Step S8: Update the historical summary and existing maintenance object status based on the current question, the status of the maintenance object in this round, the final answer and its source of reference, for use in the next round of sessions.

2. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S1, the historical summary is a compressed text generated from the fault background, inspection results and unresolved issues that are still valid in earlier rounds of dialogue; the recent dialogue text is a number of recent uncompressed user messages and system responses; and the existing maintenance object status is persistently saved with the entity identifier as the key.

3. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S2, the status of existing maintenance objects is organized, specifically as follows: Organize them separately according to entity identifier. When there are multiple records for the same field under the same entity identifier, the latest valid record is obtained according to the version number and update time. Information whose belonging object cannot be determined is not merged into any known entity.

4. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S3, using the session memory and the organized existing maintenance object status, the current problem is completed by adding references and maintenance objects. The newly stated status by the user is merged with the existing status to form the maintenance object status for this round, and search conditions are generated accordingly. Specifically: Based on conversational memory and the status of existing maintenance objects, complete the omitted subject, maintenance object, location, fault code, and completed checks in the current problem; Extract the fault symptoms, inspection actions, and inspection results explicitly stated by the user, and merge them with the existing status to form the status of the maintenance object in this round; When multiple maintenance objects or multiple troubleshooting diagrams are involved, sub-tasks are created separately and each sub-task is bound to the corresponding entity identifier. Standardize entity names and maintenance-related codes; Search criteria are generated based on the status of the maintenance objects in this round: maintenance objects, fault phenomena, and standardized codes are used to limit or increase the priority of corresponding data; inspected items and results are used to identify troubleshooting progress; eliminated causes are used to filter or reduce the priority of related data; and items to be verified are used to increase the priority of data containing subsequent inspection content. The search criteria include at least the following: limiting conditions or weighting coefficients formed by the repair object, fault phenomenon and standardized code, as well as priority adjustment information formed by the inspected items and results, ruled-out causes and items to be verified.

5. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S4, based on the normalized entity or code extracted from the status of the maintenance object in this round, the document anchor point is located, and the document route for priority retrieval is determined according to the task type, specifically as follows: Use normalized encoding for exact matching, use normalized entities and their aliases to match document chapters, and obtain the chapter identifier, document identifier, document type, applicable model, version and chapter path after a match; The document route for priority retrieval is determined based on the subtask type: troubleshooting tasks prioritize retrieving fault isolation manuals and aircraft maintenance manuals, while cause and principle-related tasks prioritize retrieving system description manuals and aircraft maintenance manuals; when the type cannot be determined or the document anchor point is not hit, a full database search is used.

6. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S5, the candidate data are sorted according to the status of the maintenance object in this round, specifically as follows: When the maintenance object corresponding to the candidate data is inconsistent with the object in the status of the maintenance object in this round, it shall be filtered or downweighted. When the applicable premises or judgment conclusions of candidate data conflict with the inspection results explicitly given by the user, they shall be filtered or downgraded. Candidate data that merely repeats already completed checks and does not provide subsequent steps will be downgraded in weight. When candidate data covers the items to be verified in the current maintenance object status, or hits the exact code, or hits the document anchor point, its priority is increased.

7. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S6, reliable evidence is screened from the sorted candidate data, and the sufficiency of the data is determined. If the data is insufficient and the preset search limit has not been reached, supplementary search terms are generated based on the missing content, and the process returns to step S5 for another search. Specifically: Eliminate candidate data that is irrelevant to the current subtask, does not match the repair object, conflicts with the user's explicit status, or is below the preset responsiveness threshold, and organize the evidence according to the task type; Determine whether the evidence after organization can fully answer the current subtask; If the data is insufficient, record the missing data types and the confirmed prior status, and generate the supplementary search terms; the supplementary search terms retain the maintenance objects and completed inspection results, and only supplement the missing operation stages or procedure types; Set the maximum number of retrieval rounds and time limit for each subtask; If the data is still insufficient after reaching the upper limit, the insufficient results are sent to step S7.

8. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S7, when sufficient data is available, an answer with cited sources is generated based on reliable evidence, and the answer undergoes citation verification; when insufficient data is available and the search limit is reached, an explanation of insufficient data is generated, specifically: When all necessary sub-tasks have sufficient data, an answer is generated based on reliable evidence, and the source of the citation is marked after the answer statement; the operation steps, parameters, fault codes, part numbers, and scope of application in the answer are consistent with the reliable evidence; When any necessary subtask has insufficient data and the retrieval limit is reached, an explanation of insufficient data is generated, and general knowledge is not used to supplement the maintenance conclusion. The generated answers are validated for citations, and at least the following checks are performed: whether the citation number exists, whether the cited statement is supported by corresponding evidence, and whether the model, version, and scope of application of the cited materials are consistent; if the validation fails, the relevant statements are regenerated or deleted.

9. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 1, characterized in that, In step S8, based on the current question, the status of the maintenance object in this round, the final answer and its source of reference, update the historical summary and the status of existing maintenance objects for use in the next round of sessions, specifically: When updating the history summary, retain the model, component, fault code, current fault phenomenon, inspected items and results, eliminated causes and items to be verified, and delete duplicate or completed content that is irrelevant to subsequent troubleshooting. When updating the status of a repair object, only the fault symptoms, performed checks, and check results explicitly stated by the user in the current issue should be written to the corresponding fields; suggestions that have not yet been implemented in the final answer should be written to the pending verification item. Excluded reasons are only written when explicitly stated by the user or when preset verifiable rules are met; The status of different maintenance objects is updated separately, and version numbers are used to prevent old status from overwriting new status.

10. The multi-turn question-and-answer method for aviation operations and maintenance based on summaries and key entities as described in claim 9, characterized in that, The status of the maintenance object is distinguished by an entity identifier, which is composed of multiple combinations of entity type, specification name, orientation or installation location, number or fault code; the status of maintenance objects corresponding to different entity identifiers are isolated from each other, and the inspection results of one maintenance object are not automatically copied to other maintenance objects.

Images