Harvester fault diagnosis method and device, electronic equipment and storage medium

Abstract

The invention relates to a harvester fault diagnosis method and device, electronic equipment and a storage medium. The method comprises the steps that fault information input by a user is acquired; carrying out vectorization coding on the fault information to obtain a query vector; according to the query vector, a preliminary retrieval result is obtained from a pre-constructed knowledge base, and the preliminary retrieval result comprises at least two fault-related historical cases corresponding to the query vector; and obtaining a fault diagnosis report through a pre-trained retrieval enhancement model according to the at least two historical cases and the query vector. By means of the method, the generated fault diagnosis report is comprehensive in content and clear in structure, explainable basis based on real cases can be provided, the reliability and operability of maintenance suggestions are enhanced, and finally the fault processing efficiency is improved, the misdiagnosis rate is reduced, and the downtime is shortened.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, and more specifically, to a method, apparatus, electronic device, and storage medium for diagnosing faults in a harvester. Background Technology

[0002] With the continuous improvement of agricultural mechanization, various harvesting machines (such as combine harvesters, corn harvesters, and silage harvesters) are playing an increasingly important role in agricultural production. However, due to their complex operating environment, high operating intensity, and diverse equipment structures, various types of malfunctions often occur during actual use, seriously affecting agricultural production efficiency and equipment lifespan.

[0003] Traditional methods for diagnosing agricultural machinery faults primarily rely on manual operation, including judgment based on human experience, consulting paper repair manuals, and simple electronic knowledge base searches. These methods suffer from slow response times, low accuracy, and outdated knowledge, making them ill-suited to the demands of modern agriculture for intelligent and efficient maintenance and management. In recent years, advancements in artificial intelligence technologies, particularly Natural Language Processing (NLP), Large Language Models (LLM), and information retrieval technologies, have provided new solutions for the intelligent diagnosis and handling of agricultural machinery faults. Among these, Retrieval-Augmented Generation (RAG) technology, by retrieving relevant information from large-scale corpora and combining it with a large language generation model to output high-quality responses, has shown promising application prospects in multiple fields.

[0004] Currently, some studies have attempted to apply retrieval-enhanced generation technology to fault diagnosis auxiliary systems for industrial equipment, such as in the fields of power equipment and automobile manufacturing. However, in the field of agricultural machinery, especially in the intelligent fault handling of harvesting machinery, a mature technical system has not yet been formed. A similar industrial intelligent fault handling system technical solution is a fault diagnosis system for steel production equipment based on a large language model. This system belongs to the field of steel production equipment fault diagnosis technology. Through the processing of domain data and model training, it constructs an intelligent fault diagnosis platform specifically for steel production equipment. It mainly includes the following modules: Data processing module; Large language model training module; Search enhancement generation module.

[0005] However, the system still has the following shortcomings: Low data update efficiency: The processes, equipment structure, and failure modes of steel production equipment change over time and with equipment upgrades. If the data processing module cannot acquire and process this new data in a timely and effective manner, the knowledge base will gradually lag behind, causing the system to be unable to accurately diagnose new types of failures.

[0006] Weak semantic understanding: The retrieval algorithm may not be able to accurately find the most relevant information to the current fault from a large-scale corpus, which may result in the system outputting inaccurate answers or missing important fault diagnosis information.

[0007] The generated results lack interpretability: While large language models can output high-quality answers, the generated content may contain some uncertainty and lacks detailed explanations of the diagnostic decision-making process. For fault diagnosis involving critical operations such as equipment maintenance, users may require clearer explanations and evidence to judge the reliability of the diagnostic results.

[0008] Insufficient generalization ability: It has poor adaptability to unseen fault types, which affects the practicality and promotion value of the system.

[0009] Therefore, there is an urgent need for an intelligent fault handling system that can overcome the above-mentioned defects and has stronger semantic understanding and knowledge retrieval mechanisms to improve the maintenance efficiency and intelligence level of harvesting machinery. Summary of the Invention

[0010] The technical problem to be solved by the present invention is to provide a method, device, electronic device and storage medium for diagnosing faults in a harvester, in order to solve at least one of the above-mentioned technical problems.

[0011] In a first aspect, the technical solution of the present invention to solve the above-mentioned technical problems is as follows: a harvester fault diagnosis method, the method comprising: Obtain fault information input by the user; The fault information is vectorized to obtain the query vector; Based on the query vector, preliminary search results are obtained from a pre-built knowledge base. The preliminary search results include at least two historical cases related to the faults corresponding to the query vector. Based on at least two historical cases and query vectors, a fault diagnosis report is obtained through a pre-trained retrieval enhancement model.

[0012] The beneficial effects of this invention are as follows: by acquiring fault information input by the user and performing vectorized encoding, the semantic features of the fault description can be accurately captured, thereby improving the ability to understand unstructured inputs such as natural language; relying on a pre-built knowledge base, at least two highly relevant historical cases can be quickly matched, significantly reducing manual retrieval time and improving the accuracy of initial screening; by combining a retrieval enhancement model to fuse historical cases and query vectors, the generated fault diagnosis report is not only comprehensive and clearly structured, but also provides interpretable evidence based on real cases, enhancing the credibility and operability of maintenance suggestions, and ultimately improving fault handling efficiency, reducing misdiagnosis rate and shortening downtime.

[0013] Based on the above technical solution, the present invention can be further improved as follows.

[0014] Furthermore, the aforementioned fault diagnosis report includes an analysis of possible causes of the fault, recommended maintenance suggestions, corresponding operation steps and visual aids for the recommended maintenance suggestions, and an explanation of the basis for the fault diagnosis report.

[0015] The beneficial effect of adopting the above-mentioned further solutions is that the fault diagnosis report simultaneously provides fault cause analysis, maintenance suggestions, operation step prompts, visual auxiliary instructions and basis explanations, so that on-site maintenance personnel can complete the maintenance by following the instructions without having to consult additional information, which significantly reduces the operation threshold and reduces secondary faults caused by missing information.

[0016] Furthermore, the above-mentioned fault information is vectorized and encoded to obtain a query vector, including: The fault information is vectorized using an embedding model to obtain the query vector.

[0017] The beneficial effect of adopting the above-mentioned further scheme is that by using the embedding model to vectorize and encode fault information, colloquial and fragmented descriptions can be uniformly mapped to a high-dimensional semantic space, which compresses storage while retaining key semantics, thereby achieving sub-second high similarity matching in the knowledge base and improving retrieval speed and accuracy.

[0018] Furthermore, the aforementioned knowledge base is constructed in the following manner: Acquire basic knowledge and multiple historical cases. The basic knowledge includes the mechanical principles, working principles and fault types of different types of harvesters. The multiple historical cases include fault cases corresponding to different fault types under different types of harvesters. The basic knowledge includes structured data and unstructured data. A knowledge base was built based on fundamental knowledge and multiple failure cases. Based on the query vector, the preliminary search results obtained from the pre-built knowledge base include: The harvester type and fault type corresponding to the fault information are determined based on the query vector; Based on the harvester type and fault type corresponding to the fault information, preliminary search results are obtained from the knowledge base.

[0019] The beneficial effects of adopting the above-mentioned further solutions are that the knowledge base is organized hierarchically according to harvester type and fault type and continuously updated incrementally to ensure that new models and new faults can still be quickly covered; the combination of vector retrieval and structured index can be used across models and can accurately locate specific scenario cases, realizing one-time construction and long-term reuse.

[0020] Furthermore, the above methods also include: Obtain user feedback on the fault diagnosis report; Adjust the fault diagnosis report and / or knowledge base based on the feedback results.

[0021] The beneficial effect of adopting the above-mentioned further solutions is that users can provide real-time feedback on diagnostic reports, and dynamically adjust the report content or knowledge base weights accordingly, forming a "use-feedback-optimization" closed loop, making the model more accurate with use and the knowledge base more up-to-date, continuously adapting to changes in the field without downtime for maintenance.

[0022] Furthermore, the aforementioned fault information is multi-source fault information, which includes at least one of voice, text, and image.

[0023] The beneficial effect of adopting the above-mentioned further solution is that the solution supports multiple input forms such as voice, text, and images. Maintenance personnel can quickly report faults by voice or photo in noisy fields or when their hands are occupied. The solution automatically integrates multimodal features to complete the diagnosis, significantly reducing the input threshold and improving the on-site response speed.

[0024] Furthermore, the above methods also include: Extract fault characteristics from fault information; The above-mentioned vectorization encoding of fault information yields a query vector, including: The fault characteristics are vectorized to obtain the query vector.

[0025] The beneficial effect of adopting the above-mentioned further scheme is that by first extracting fault features and then performing vectorized encoding, redundant information can be eliminated before entering the retrieval process, key fault dimensions can be focused on, noise interference can be reduced, and the accuracy and efficiency of subsequent retrieval and generation stages can be further improved. It is especially suitable for complex or compound fault scenarios.

[0026] Secondly, in order to solve the above-mentioned technical problems, the present invention also provides a harvester fault diagnosis device, the device comprising: The acquisition module is used to acquire fault information input by the user; The encoding module is used to vectorize the fault information to obtain the query vector; The preliminary retrieval module is used to obtain preliminary retrieval results from a pre-built knowledge base based on the query vector. The preliminary retrieval results include at least two historical cases related to the fault corresponding to the query vector. The fault diagnosis module is used to generate a fault diagnosis report based on at least two historical cases and a query vector, using a pre-trained retrieval enhancement model.

[0027] Thirdly, in order to solve the above-mentioned technical problems, the present invention also provides an electronic device, which includes 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 harvester fault diagnosis method of the present application.

[0028] Fourthly, in order to solve the above-mentioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the harvester fault diagnosis method of the present application.

[0029] Additional aspects and advantages of this application will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of this application. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below.

[0031] Figure 1 This is a flowchart illustrating a harvester fault diagnosis method according to an embodiment of the present invention; Figure 2 A schematic diagram of a system architecture provided for one embodiment of the present invention; Figure 3 A system flowchart is provided for one embodiment of the present invention; Figure 4 A flowchart corresponding to a retrieval enhancement generation module provided in one embodiment of the present invention; Figure 5 A flowchart corresponding to a multi-source heterogeneous knowledge base construction module provided in one embodiment of the present invention; Figure 6 This is a schematic diagram of the architecture of a user interaction and feedback module provided in one embodiment of the present invention; Figure 7 This is a schematic diagram of a harvester fault diagnosis device provided in one embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0032] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0033] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0034] The solution provided in this invention can be applied to any application scenario requiring intelligent diagnosis of harvester malfunctions. The solution provided in this invention can be executed by any electronic device, such as a user's terminal device, including at least one of the following: smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, smart TV, or smart in-vehicle device.

[0035] This invention provides a possible implementation, such as... Figure 1 The diagram shows a flowchart of a harvester fault diagnosis method. This method can be executed by any electronic device, such as a terminal device, or jointly executed by a terminal device and a server. For ease of description, the method provided in this embodiment will be described below using a terminal device as the execution subject as an example. Figure 1 The flowchart shown indicates that the method may include the following steps: S10, Obtain fault information input by the user; S20, the fault information is vectorized and encoded to obtain the query vector; S30, Based on the query vector, obtain preliminary search results from the pre-built knowledge base. The preliminary search results include at least two historical cases related to the faults corresponding to the query vector. S40: Based on at least two historical cases and query vectors, a fault diagnosis report is obtained through a pre-trained retrieval enhancement model.

[0036] By acquiring and vectorizing user-inputted fault information, the method of this invention can accurately capture the semantic features of fault descriptions, thereby improving the ability to understand unstructured inputs such as natural language. Relying on a pre-built knowledge base, it can quickly match at least two highly relevant historical cases, significantly reducing manual retrieval time and improving initial screening accuracy. By combining historical cases with query vectors using a retrieval enhancement model, the generated fault diagnosis report is not only comprehensive and clearly structured, but also provides interpretable evidence based on real cases, enhancing the credibility and operability of maintenance suggestions. Ultimately, this improves fault handling efficiency, reduces misdiagnosis rates, and shortens downtime.

[0037] The following specific embodiments further illustrate the solution of the present invention. The core objective of this invention is to provide a retrieval-enhanced intelligent fault handling method for harvesting machinery, addressing key technical problems in existing harvesting machinery fault diagnosis systems such as low intelligence levels, poor response efficiency, lagging knowledge updates, and lack of interpretability in maintenance suggestions. Specifically, current agricultural harvesting machinery faces the following technical challenges during use: 1. Fault information input is diverse and unstructured, making it difficult for traditional systems to accurately understand actual operations. Users often describe faults in natural language, such as "the cutting platform is not turning" or "the engine is emitting black smoke." Existing systems generally use keyword matching or fixed rule bases for parsing, resulting in weak semantic understanding capabilities, high misdiagnosis rates, and low diagnostic efficiency.

[0038] 2. Long knowledge base update cycle, unable to adapt to new fault scenarios. Existing harvesting machinery fault diagnosis systems rely on manually constructed knowledge bases or static expert systems, which have high knowledge acquisition costs, slow update speed, and difficulty in timely reflecting changes in equipment operating status and new fault types.

[0039] 3. The recommended results lack supporting evidence, which is not conducive to the adoption and implementation by technicians. Most systems can only output simple fault codes or maintenance suggestions without combining historical cases and contextual information for reasoning and explanation. This lack of interpretability and credibility affects the judgment and operational efficiency of on-site maintenance personnel.

[0040] 4. Poor system generalization ability, making it difficult to support fault handling across models and scenarios. Most current systems are designed for specific models of equipment, lacking versatility and migration capabilities. When faced with equipment of different brands, models, or operating conditions, the diagnostic effect is significantly reduced.

[0041] 5. The interaction method is too simple, resulting in a poor user experience. Most existing systems rely on text input and query interfaces, lacking multimodal interaction methods such as voice and images, making it difficult to meet the needs of front-line operators for efficient use in complex environments.

[0042] Therefore, this invention proposes a fault diagnosis method that integrates retrieval-enhanced generation technology with the fault handling process of harvesters. It aims to achieve intelligent, automated, and personalized services for agricultural machinery fault handling by introducing an efficient semantic understanding mechanism, a dynamic knowledge update strategy, a highly interpretable generative model, and a multimodal human-computer interaction method, thereby improving the efficiency of agricultural machinery maintenance, reducing operation and maintenance costs, and ensuring the continuity of agricultural production.

[0043] Based on this, the technical solution protected in this embodiment provides a harvester fault diagnosis method that may include the following steps: S10, Obtain fault information input by the user; Users can input fault information on the page of the APP that can perform fault diagnosis. The fault information can be multi-source fault information, including at least one of voice, text and image (specifically, images of the fault scene).

[0044] S20, the fault information is vectorized and encoded to obtain the query vector; Optionally, the above-mentioned fault information is vectorized to obtain a query vector, including: The fault information is vectorized using an embedding model to obtain the query vector.

[0045] The embedding model can be the bge-m3 model.

[0046] The following methods can also be used to vectorize fault information to obtain a query vector: Option 1: After segmenting and recognizing the fault information, only the three core entity phrases extracted—faulty components, fault phenomena, and operating parameters—are vectorized and encoded to generate lightweight query vectors. This option significantly reduces vector dimension and computational overhead while maintaining diagnostic accuracy by narrowing the encoding range, making it suitable for low-power scenarios on mobile or edge devices.

[0047] Option 2: If the fault information includes voiceprint or image features, the voiceprint or image features can be extracted first. The speech signal can be converted into a Mel spectrogram or the oil leak or crack area in the image can be converted into a visual feature vector. Then, these features are encoded separately with the text description and concatenated into a multimodal query vector. This option enables the system to utilize acoustic, visual and linguistic cues simultaneously, which can significantly improve the robustness and recognition accuracy in complex environments with noise, obstruction or unclear descriptions.

[0048] Optionally, the above method further includes: Extract fault features from fault information; among which, natural language processing technology can be used to identify fault features in fault information, that is, information related to the fault in the fault information.

[0049] Then, the fault information is vectorized and encoded, i.e., semantically encoded, to obtain the query vector, which may also include: The fault characteristics are vectorized to obtain the query vector.

[0050] It is understandable that the above-mentioned vectorization encoding of fault features to obtain query vectors can also be achieved through an embedding model.

[0051] S30, Based on the query vector, obtain preliminary search results from the pre-built knowledge base. The preliminary search results include at least two historical cases related to the faults corresponding to the query vector. Among them, "related to the fault corresponding to the query vector" means that the fault is similar to the fault corresponding to the query vector.

[0052] Optionally, after obtaining the initial search results from the pre-built knowledge base based on the query vector, since the initial search results may contain some low-relevance cases, at least two historical cases in the initial search results can be sorted according to their similarity to obtain the sorted historical cases.

[0053] Among them, bge-reranker-v2-m3 can be used to sort at least two initial cases according to their similarity.

[0054] After obtaining the sorted historical cases, the lower-ranked historical cases can be deleted to remove noise from the initial search results, i.e., historical cases with low relevance. The historical cases used in S40 are those after deletion.

[0055] Optionally, the above knowledge base is constructed in the following way: Acquire basic knowledge and multiple historical cases. The basic knowledge includes information on the mechanical principles, working principles and fault types of different types of harvesters. The multiple historical cases include fault cases corresponding to different fault types under different types of harvesters. The data corresponding to the basic knowledge and multiple historical cases includes structured data and unstructured data. A knowledge base is built based on fundamental knowledge and multiple failure cases.

[0056] The basic knowledge may also include various types of technical documents and user manuals provided by manufacturers, public and structured maintenance data on fault warnings and handling technologies released by equipment and electrical component manufacturers, national and industry standards, etc. Through this information, one can understand the mechanical principles, working principles and fault types of different types of harvesters.

[0057] Through the above processing, static or semi-static technical data in the field of agricultural machinery from multiple channels, in multiple formats, and in both structured and unstructured forms can be systematically collected, structurally extracted, semantically segmented, and vectorized to construct a vectorized knowledge system that supports efficient retrieval, dynamic updates, and semantic completeness.

[0058] The specific implementation process of building the knowledge base based on basic knowledge and multiple failure cases is as follows: This approach performs deep semantic analysis and structured knowledge extraction on unstructured data, transforming it into machine-understandable knowledge units. Specific functions include recognizing unstructured data (text content in scanned PDFs or image-based manuals) and restoring it to editable text; using document understanding models to identify structures such as titles, paragraphs, captions, headers, and footers in editable text, resulting in multiple knowledge entries. This avoids misclassifying irrelevant information into knowledge entries. A knowledge entry is the smallest granular unit of information in the knowledge base that can be retrieved, returned, and displayed. It can be a piece of text, an image, a video, or a structured record, and each knowledge entry can serve as a knowledge unit. Optionally, a table recognition OCR algorithm can be used to automatically extract key structured knowledge such as "fault code comparison table", "lubrication point distribution map" and "hydraulic system parameter table" from editable text, and convert them into multiple JSON objects or multiple database records. Each JSON object or each database record can be used as a knowledge unit. Furthermore, the "fault phenomenon - possible cause - recommended measures" triplet can be automatically extracted from the text corresponding to the knowledge entries, JSON objects or database records for rule-level knowledge construction. Optionally, if the unstructured data includes long documents, the long documents can be transformed into knowledge units in the following way: Specifically, the long documents are divided into semantically complete and appropriately granular knowledge units (chunks).

[0059] Different segmentation methods can be used for different types of text. As an example, for instruction text, a segmentation method based on semantic coherence detection is used; for parameter table or flowchart descriptions, the entire table or flowchart is treated as a single chunk to preserve contextual integrity; for maintenance operation text, it is segmented according to the segmentation methods used for instruction text and parameter table or flowchart descriptions to form independent knowledge units, facilitating the subsequent generation of structured maintenance guidelines; the length of each chunk is controlled between 128 and 512 tokens, and a sliding window approach is used for semantic block segmentation, setting a text overlap rate of 10%-20% to prevent the loss of key information due to segmentation; each chunk is bound with metadata tags, such as equipment model, fault category, component name, knowledge type, and knowledge source.

[0060] Transform structured data into a vector representation to obtain the encoded vector corresponding to the structured data; Each knowledge unit is vectorized and encoded using a pre-trained, high-efficiency semantic embedding model to obtain the encoding vector corresponding to each knowledge unit. Establish a composite index system that supports multimodal retrieval, store each encoded vector together with the original text and metadata in the knowledge base, and construct a composite index mechanism that integrates vector index, keyword index and metadata index to improve the accuracy and robustness of retrieval.

[0061] For each knowledge unit, there is a corresponding original text. The original text refers to the plain text content retained after the knowledge unit is segmented and cleaned; this is the text that will be displayed to the user and used to generate the diagnostic report. Metadata refers to structured fields that describe the external attributes of this knowledge unit. It does not participate in semantic vector calculation but is used for filtering, sorting, permissions, and version tracking. It can be understood as "tags" used by the system for retrieval, filtering, and management, such as harvester type or fault type. Thus, the knowledge base includes multiple knowledge units, multiple original texts, and multiple metadata.

[0062] In step S30 above, preliminary search results are obtained from the pre-built knowledge base based on the query vector, including: The harvester type and fault type corresponding to the fault information are determined based on the query vector; Based on the harvester type and fault type corresponding to the fault information, preliminary search results are obtained from the knowledge base.

[0063] In this application, based on the query vector, a multi-path hybrid recall strategy can be used to obtain preliminary search results from a pre-built knowledge base. The specific process is as follows: based on the query vector, a semantic vector recall method is used to obtain the first recall result from the pre-built knowledge base; based on the query vector, a keyword matching recall method is used to obtain the second recall result from the pre-built knowledge base; based on the query vector, a metadata filtering recall method and a rule recall method are used to obtain the third recall result from the pre-built knowledge base; all recall results are deduplicated and then merged into the preliminary search result.

[0064] Semantic vector recall refers to calculating vector similarity using query vectors in a pre-built knowledge base to recall historical cases that are semantically highly similar to the query vectors, even if these cases do not contain the exact same keywords as the input text. This method can capture semantic similarity and is suitable for fault descriptions using synonyms, near-synonyms, or different expressions but with the same meaning, improving the accuracy and generalization of recall. Keyword matching recall refers to: Keyword matching recall refers to extracting keywords (such as "engine" or "black smoke") from user-input fault information, converting these keywords into query vectors, and then retrieving historical cases containing these keywords from a knowledge base. This method relies on literal keyword matching and is suitable for retrieving high-frequency terms or specific fault codes. It can supplement explicit expressions that may be missed by semantic vector recall. Keyword matching recall is often used as a supplement to semantic vector recall to ensure that fault cases with common or standard terms can be accurately recalled.

[0065] Metadata filtering and recall refers to hard filtering based on the metadata tags (equipment model, fault type, component name, crop type, operating season, etc.) bound to each record in the knowledge base. For example, using query vectors (such as the vector corresponding to "combine harvester + hydraulic system + 2025 model") as filtering conditions, all cases outside this range are eliminated, forming an initial subset. This can quickly narrow down the search space, exclude obviously irrelevant records such as mismatched machine models or components, and reduce the computational load and false positive rate of subsequent vector or keyword matching.

[0066] Rule-based recall refers to recalling data using predefined business rules, either manually or through an expert system.

[0067] For example, rule formats include: IF-THEN, decision tables, priority lists, fault code-cause lookup tables, safety specifications, etc.

[0068] For example, if the fault code is "P0087" and the engine speed is <800 rpm, a mandatory recall will be issued for cases related to "low-pressure oil circuit blockage"; if the harvester type is a "corn harvester" and the operating area is "late season in Northeast China," then historical cases of "damp straw entanglement" will be recalled first. This recall method directly transforms explicit knowledge such as industry experience, standards, and regulations into recall conditions, compensating for the insufficient coverage of rare faults or new models by data-driven methods, while ensuring that the results comply with safety and manufacturer specifications.

[0069] The aforementioned knowledge base can be a comprehensive knowledge base containing information such as historical fault cases (history), maintenance manuals, expert experience, and technical documents.

[0070] The knowledge base can be designed in layers: Basic knowledge layer: including mechanical structure, working principle, common fault classification, etc.; Case layer: Stores past real-world fault handling cases and their solutions; Strategy layer: Contains maintenance recommendations for different types of faults; Rule Layer: Integrates industry standards, manufacturer recommendations, safety specifications, and other content. All content in the knowledge base complies with the various regulations and standards outlined in the rule layer.

[0071] The strategy layer may also include priority judgment rules, based on which query vectors of certain harvester types or fault types are processed preferentially.

[0072] Optionally, the knowledge base can be updated or expanded when there are historical cases of new harvester types, historical cases of new fault types, or new historical cases.

[0073] Optionally, in the knowledge base, content can be expressed in various forms such as text, images, and videos.

[0074] Optionally, the knowledge base can support access control and knowledge version tracking for different users, meaning that different users have different access permissions.

[0075] S40: Based on at least two historical cases and query vectors, a fault diagnosis report is obtained through a pre-trained retrieval enhancement model.

[0076] The specific implementation process of S40 above is as follows: Solution 1: To address the issue of low-relevance noisy cases in the initial retrieval results, a deep learning-based re-ranking mechanism is introduced in S40 to re-score and optimize the relevance between historical cases and query vectors in the initial retrieval results. Optionally, the implementation of S40 may include: employing a deep re-ranking model to form a "query-pair" between the query vector and each candidate case in the initial retrieval results, inputting it into the retrieval enhancement model. The model outputs a relevance score within the [0,1] interval to reflect the true matching degree between the case and the current fault. After sorting by score, the top-3 to top-5 historical cases with the highest relevance are selected, and a fault diagnosis report is determined based on these top-3 to top-5 historical cases with the highest relevance. Compared to traditional RAG which only uses vector similarity, this solution captures fine-grained semantic matching through a re-ranking model, thereby reducing the false detection rate. This solution significantly suppresses noisy segments through a three-level link of "coarse recruitment-fine ranking-deep generation," making the diagnosis report more focused and interpretable, while reducing the input length of a large model, thus lowering latency and cost.

[0077] Option 2: The highly relevant cases (historical cases from the initial search results) are structurally fused with the query vector to construct a high-quality prompt-based input retrieval enhancement model, resulting in a fault diagnosis report. The fused content includes standardized descriptions input by the user, fault causes, solutions, and operational steps from the search results.

[0078] As an example, the prompts include "Based on: Lovol Service Notice 2024-03," equipment context (equipment model, operating hours, and other relevant information), and knowledge credibility score. The constructed prompts include role settings (e.g., you are an agricultural machinery repair expert with rich practical experience, familiar with the structural principles and common fault handling procedures of mainstream agricultural machinery models (such as Lovol, John Deere, etc.), and able to make comprehensive judgments based on repair manuals, historical cases, and equipment operating data), user questions (standardized fault descriptions), reference cases (providing similar fault phenomena, causes, and solutions for analogical reasoning), and equipment information (model, operating time, and other context). A structured output format is also specified (including possible causes, repair suggestions, operating steps, and basis). Through multi-element collaboration, the model is guided to generate professional, reliable, and actionable diagnostic reports and repair suggestions, enhancing the interpretability and personalization of the generated results.

[0079] Optionally, since the knowledge base includes query vectors for different fault types, historical cases, and maintenance suggestions, the aforementioned retrieval enhancement model can be trained based on the knowledge base.

[0080] Optionally, the above method further includes: Obtain user feedback on the fault diagnosis report; Adjust the fault diagnosis report and / or knowledge base based on the feedback results.

[0081] Optionally, users can input fault information through a user interface. In this application, a graphical user interface can also be provided, supporting access from both computer and mobile devices, and possessing the following functions: Multimodal input support: Supports multiple fault description methods such as text input and image upload; Visualized output: The generated maintenance suggestions are presented in a graphic and textual format for easy understanding and implementation; User feedback mechanism: Allows users to rate, modify, or supplement the generated suggestions, forming a closed-loop feedback loop; Task collaboration management: Supports task allocation, progress tracking, and collaborative processing among technical personnel; Role-based access control: Differentiates between different permission levels such as ordinary users, technical personnel, and administrators to ensure system security; Remote assistance function: Supports experts to remotely view fault conditions and provide guidance and suggestions.

[0082] This significantly improves the user experience and provides data support for the continuous optimization of the knowledge base.

[0083] Based on and Figure 1 Based on the same principle as the method shown, this embodiment of the invention also provides a harvester fault diagnosis device 20, such as... Figure 7 As shown, the harvester fault diagnosis device 20 may include an acquisition module 210, an encoding module 220, a preliminary retrieval module 230, and a fault diagnosis module 240, wherein: The acquisition module 210 is used to acquire fault information input by the user; Encoding module 220 is used to vectorize the fault information to obtain a query vector; The preliminary retrieval module 230 is used to obtain preliminary retrieval results from a pre-built knowledge base based on the query vector. The preliminary retrieval results include at least two historical cases related to the faults corresponding to the query vector. The fault diagnosis module 240 is used to generate a fault diagnosis report based on at least two historical cases and a query vector, using a pre-trained retrieval enhancement model.

[0084] Optionally, the fault diagnosis report may include an analysis of possible causes of the fault, recommended maintenance suggestions, corresponding operation steps and visual aids for the recommended maintenance suggestions, and an explanation of the basis for the fault diagnosis report.

[0085] Optionally, when the above-mentioned encoding module 220 performs vectorized encoding on the fault information to obtain the query vector, it is specifically used for: The fault information is vectorized using an embedding model to obtain the query vector.

[0086] Optionally, the above knowledge base is constructed in the following way: Acquire basic knowledge and multiple historical cases. The basic knowledge includes the mechanical principles, working principles and fault types of different types of harvesters. The multiple historical cases include fault cases corresponding to different fault types under different types of harvesters. The basic knowledge includes structured data and unstructured data. A knowledge base was built based on fundamental knowledge and multiple failure cases. When the aforementioned preliminary retrieval module 230 obtains preliminary retrieval results from the pre-built knowledge base based on the query vector, it is specifically used for: The harvester type and fault type corresponding to the fault information are determined based on the query vector; Based on the harvester type and fault type corresponding to the fault information, preliminary search results are obtained from the knowledge base.

[0087] Optionally, the device further includes: The optimization and update module is used to obtain user feedback on the fault diagnosis report; and to adjust the fault diagnosis report and / or knowledge base based on the feedback.

[0088] Optionally, the fault information is multi-source fault information, which includes at least one of voice, text, and image.

[0089] Optionally, the device further includes: The fault feature extraction module is used to extract fault features from fault information; When the aforementioned encoding module 220 performs vectorized encoding on the fault information to obtain the query vector, it is specifically used for: The fault characteristics are vectorized to obtain the query vector.

[0090] Based on and Figure 1 Using the same principle as the method shown, this invention also provides a harvester fault diagnosis system, which can be found in the following examples. Figure 2 The system diagram shown comprises five modules: a data collection and preprocessing module, a multi-source heterogeneous knowledge base construction module, a retrieval enhancement generation module, a user interaction and feedback module, and a system control and scheduling module. Among these, [the system] combines... Figure 3 The flowchart shown above illustrates the functions of each module as follows: The data collection and preprocessing module is used to process and clean fault data from various sources, including operators, sensors, maintenance records, and user feedback. This fault data encompasses both structured information (such as equipment model, fault codes, timestamps, and operating parameters) and unstructured information (such as input natural language descriptions, fault scene images, and voice recordings). The specific functions implemented in this module are as follows: Data access and multi-source integration: Supports access from multiple terminals, including computers and mobile devices; that is, it can receive fault information sent from different terminals. Data cleaning and noise filtering: Remove duplicate, invalid, and erroneous data to improve the quality of data in subsequent processing; Text standardization and semantic normalization: Transform user-input colloquial fault descriptions into a unified format to facilitate semantic understanding; that is, if the fault information contains colloquial fault descriptions, the colloquial fault descriptions can be transformed into a unified format.

[0091] Key entity identification and intent extraction: using natural language processing techniques to identify fault features in fault information; Multimodal data parsing includes document layout detection and analysis, optical character recognition (OCR) and text extraction, table parsing and image understanding, and post-processing and structured output of the parsing results. This multimodal data parsing integrates document parsing and visual processing technologies, supporting layout analysis and table recognition of data containing multiple information formats simultaneously, automatically extracting data information and transforming it into structured knowledge.

[0092] The structured encapsulation and task distribution process encapsulates the cleaned, standardized, entity-identified, and multimodal parsing data into a unified message body, which is then forwarded to the next module via a RESTful API, and the retrieval enhancement generation module.

[0093] The data collection and preprocessing module also includes query analysis functions, which are used to perform intent recognition and semantic parsing on user input, and support preliminary processing and feature extraction of non-text data such as images and audio.

[0094] Through the above processing flow, the data collection and preprocessing module ensures that the input data has good consistency and usability, providing a high-quality data foundation for subsequent knowledge extraction, semantic understanding and generation.

[0095] See Figure 5 The multi-source heterogeneous knowledge base construction module systematically collects, extracts, semantically segments, and vectorizes static or semi-static technical data in the agricultural machinery field from various channels, formats, and both structured and unstructured sources. This constructs a vectorized knowledge system that supports efficient retrieval, dynamic updates, and semantic completeness. Unlike the "Data Collection and Preprocessing Module," which handles real-time user input and single-line fault descriptions, this module focuses on the accumulation of batch, long-term, real-time, and highly reliable agricultural machinery knowledge. Its goal is not to respond to single queries, but to provide an accumulative, traceable, and continuously optimizable knowledge foundation for the entire system's intelligent diagnostic capabilities, thereby providing high-quality contextual support for subsequent accurate retrieval and interpretable generation. This module has the following characteristics: Knowledge Source Access and Batch Import: Access and import technical knowledge resources in batches from authoritative channels related to agricultural machinery. These mainly include various types of technical documents and user manuals provided by manufacturers, public information on fault warnings and handling techniques released by equipment and electrical component manufacturers, structured maintenance data, historical case libraries, national and industry standards, etc.

[0096] Document structure extraction and knowledge extraction: Deep semantic analysis and structured knowledge extraction are performed on unstructured data to transform it into machine-understandable knowledge units. Specific functions include recognizing unstructured data (text content in scanned PDFs or image-based manuals) and restoring it to editable text; using document understanding models to identify structures such as titles, paragraphs, captions, headers and footers in editable text to obtain multiple knowledge entries, avoiding the inclusion of irrelevant information in knowledge entries. A knowledge entry is the smallest granular information unit in the knowledge base that can be retrieved, returned, and displayed. It can be a piece of text, an image, a video, or a structured record, and each knowledge entry can be considered a knowledge unit. Optionally, a table recognition OCR algorithm can be used to automatically extract key structured knowledge such as "fault code comparison table", "lubrication point distribution map" and "hydraulic system parameter table" from editable text, and convert them into multiple JSON objects or multiple database records. Each JSON object or each database record can be used as a knowledge unit. Furthermore, the "fault phenomenon - possible cause - recommended measures" triplet can be automatically extracted from the text corresponding to the knowledge entries, JSON objects or database records for rule-level knowledge construction. Semantic-aware intelligent chunking: Optionally, if the unstructured data includes long documents, the long documents can be converted into knowledge units in the following way; specifically, the long documents are divided into semantically complete and appropriately granular knowledge units (chunks).

[0097] Different segmentation methods can be used for different types of text. As an example, for instruction text, a segmentation method based on semantic coherence detection is used; for parameter table or flowchart descriptions, the entire table or flowchart is treated as a single chunk to preserve contextual integrity; for maintenance operation text, it is segmented according to the segmentation methods used for instruction text and parameter table or flowchart descriptions to form independent knowledge units, facilitating the subsequent generation of structured maintenance guidelines; the length of each chunk is controlled between 128 and 512 tokens, and a sliding window approach is used for semantic block segmentation, setting a text overlap rate of 10%-20% to prevent the loss of key information due to segmentation; each chunk is bound with metadata tags, such as equipment model, fault category, component name, knowledge type, and knowledge source.

[0098] Vectorization encoding and composite index construction: Transforming structured data into vector representation to obtain the encoded vector corresponding to the structured data; Each knowledge unit is vectorized and encoded using a pre-trained, high-efficiency semantic embedding model to obtain the encoding vector corresponding to each knowledge unit. Establish a composite index system that supports multimodal retrieval, store each encoded vector together with the original text and metadata in the knowledge base, and construct a composite index mechanism that integrates vector index, keyword index and metadata index to improve the accuracy and robustness of retrieval.

[0099] For each knowledge unit, there is a corresponding original text. The original text refers to the plain text content retained after the knowledge unit is segmented and cleaned; this is the text that will be displayed to the user and used to generate the diagnostic report. Metadata refers to structured fields describing the external attributes of this knowledge unit. It does not participate in semantic vector calculation but is used for filtering, sorting, permissions, and version tracking. It can be understood as "tags" used by the system for retrieval, filtering, and management, such as harvester type or fault type. Thus, the knowledge base includes multiple knowledge units, multiple original texts, and multiple metadata. A composite indexing mechanism is constructed, integrating vector indexes, keyword indexes, and metadata indexes to improve the accuracy and robustness of retrieval.

[0100] Layered Knowledge Organization and Credibility Modeling: A four-layered architecture is adopted to organize knowledge content, enhancing the reasonability and credibility of knowledge. The foundational knowledge layer includes content related to mechanical structure, working principles, and system composition, used to understand complex faults; the case study layer contains real-world repair cases with complete repair context, providing historical reference; the strategy layer includes recommended repair procedures and repair priority rules to guide the order of operations; and the rules layer includes industry standards, manufacturer recommendations, safety specifications, and precautions to ensure compliance in fault repair. A multi-source heterogeneous knowledge base construction module serves as the system's knowledge support hub, ensuring the system has continuous learning and expansion capabilities.

[0101] See Figure 4 The retrieval enhancement and generation module is responsible for deeply integrating preprocessed user fault descriptions with a structured knowledge base. Through a closed-loop process of "semantic understanding → precise retrieval → relevance screening → contextual fusion → interpretable generation," it outputs high-quality, highly reliable, and actionable fault diagnosis content and processing suggestions. Unlike traditional keyword matching or single generation models, this module adopts a three-level intelligent reasoning architecture ("recall + rerank + generate"), significantly improving diagnostic accuracy, interpretability, and generalization ability in complex fault scenarios of agricultural machinery. This module not only ensures "findability" but also guarantees "accurate screening" and "clear explanation." The specific process is as follows: Semantic Encoding and Query Representation Generation: This module accepts structured query input (such as standardized text, entity labels, and device information) from the "Data Collection and Preprocessing Module" and transforms it into a machine-computable vector representation. Specifically, it uses an embedding model to vectorize the user-input natural language fault description; if the input includes images or speech, their corresponding text semantic representations will also participate in vector encoding. The input query encoding (query vector) serves as the semantic anchor for subsequent retrieval, used to match similar knowledge entries in the vector space.

[0102] Multi-path hybrid recall: To overcome the potential omission of relevant information in single-vector retrieval, this module adopts a multi-path hybrid recall strategy, combining multiple retrieval methods to obtain a candidate case set, thereby improving recall coverage and robustness. The specific process is as follows: Based on the query vector, semantic vector recall is used to obtain the first recall result from the pre-built knowledge base; based on the query vector, keyword matching recall is used to obtain the second recall result from the pre-built knowledge base; based on the query vector, metadata filtering recall and rule recall are used to obtain the third recall result from the pre-built knowledge base; all recall results are deduplicated and merged into preliminary search results, which are then submitted to subsequent stages for further refinement.

[0103] Deep Re-ranking: To address the issue of low-relevance noisy cases in the initial retrieval results, a deep learning-based re-ranking mechanism is introduced to re-score and optimize the relevance between historical cases and query vectors in the initial retrieval results. Specifically, a deep re-ranking model is used to input the query vector and each candidate case in the initial retrieval results into a "question-fragment pair" into the retrieval enhancement model. The model outputs a relevance score in the [0,1] interval to reflect the true matching degree between the case and the current fault. After sorting by score, the top-3 to top-5 historical cases with the highest relevance are selected. Based on these top-3 to top-5 historical cases with the highest relevance, a fault diagnosis report is determined. Compared to traditional RAG which only uses vector similarity, the re-ranking model captures fine-grained semantic matching, thereby reducing the false detection rate.

[0104] Alternatively, contextual fusion and prompt word construction: Highly relevant cases (historical cases in the initial search results) are structurally fused with the query vector to construct a high-quality prompt word input generation model (retrieval enhancement model), resulting in a fault diagnosis report. The fused content includes standardized descriptions input by the user, fault causes, solutions, and operating steps from the search results.

[0105] As an example, the prompts include "Based on: Lovol Service Notice 2024-03," equipment context (equipment model, operating hours, and other relevant information), and knowledge credibility score. The constructed prompts include role settings (e.g., you are an agricultural machinery repair expert with rich practical experience, familiar with the structural principles and common fault handling procedures of mainstream agricultural machinery models (such as Lovol, John Deere, etc.), and able to make comprehensive judgments based on repair manuals, historical cases, and equipment operating data), user questions (standardized fault descriptions), reference cases (providing similar fault phenomena, causes, and solutions for analogical reasoning), and equipment information (model, operating time, and other context). A structured output format is also specified (including possible causes, repair suggestions, operating steps, and basis). Through multi-element collaboration, the model is guided to generate professional, reliable, and actionable diagnostic reports and repair suggestions, enhancing the interpretability and personalization of the generated results.

[0106] Interpretable Output Generation: The system calls a generative large language model (LLM) to generate a diagnostic report (fault diagnosis report), supporting multilingual output. The large language model includes, but is not limited to, open-source or commercial models based on the Transformer architecture (such as Qwen, DeepSeek, etc.). Output content includes analysis of possible fault causes, recommended repair measures, step-by-step operation prompts, visual aids, and supporting explanations. It can also output Chinese and English versions according to user needs. The generated results are formatted and returned to the "User Interaction and Feedback Module" for display.

[0107] This module not only improves the system's intelligence level, but also enhances the interpretability and practicality of the generated results.

[0108] See Figure 6 The user interaction and feedback module, serving as the human-machine collaboration interface and closed-loop optimization entry point for this system, not only provides an intuitive, efficient, and multimodal interactive experience but also plays a crucial role in transforming user behavior data into system optimization signals. It is the core hub for achieving the self-learning capability of "becoming more accurate with use." Unlike traditional static interfaces that only support text queries, this module caters to various roles, including frontline agricultural machinery operators, maintenance technicians, and expert teams. It constructs a cross-terminal, multimodal, collaborative, and traceable intelligent interaction platform, significantly improving the system's usability, adoption rate, and continuous evolution capabilities. This module has the following functions: Multimodal input support: Supports multiple fault description methods such as text input and image upload, adapting to the needs of efficient use in complex field operation environments.

[0109] Visualized output: The generated maintenance suggestions are presented in a visually appealing, clearly structured, and highly actionable format, facilitating on-site understanding and operation. Output content includes analysis of possible fault causes, recommended maintenance measures and priority suggestions, step-by-step operation prompts, visual aids (flowcharts, maintenance manual content, etc.), and supporting documentation (indicating the data source information for the corresponding knowledge), achieving a unified output that is readable, visual, and actionable.

[0110] User feedback mechanism: Allows users to evaluate and correct the generated results, forming a closed-loop feedback loop for continuous optimization.

[0111] Task Collaboration and Remote Assistance: The system supports integration with the customer service system, enabling automatic synchronization of work order information and task linkage, thereby constructing a complete closed loop from user repair requests to technical handling. Based on customer service work orders, administrators can accurately assign diagnostic tasks to designated maintenance personnel and set priorities and processing deadlines; the system has a built-in progress tracking mechanism, displaying task status in real time (pending, in progress, completed), and supports multi-role collaborative processing; frontline personnel can initiate remote assistance requests, and experts can view fault details, diagnostic reports, and multimodal information such as user-uploaded images and videos on a PC, providing real-time guidance through text chat, voice calls, screen sharing, etc. Expert opinions can be directly written into the diagnostic report and synchronized to the field, achieving efficient collaboration and knowledge closure.

[0112] Role-based access control: The system employs a hierarchical role management mechanism, configuring fine-grained operation permissions based on user identity to ensure compliance and security in function usage and data access. All user operations are automatically recorded in the audit log, supporting behavior traceability, accountability, and remote assistance. Experts can remotely view fault conditions and provide guidance and suggestions.

[0113] System Control and Scheduling Module: As the core control hub and operational support platform of this system, it is responsible for coordinating task scheduling, data flow, resource allocation, and anomaly handling among the five functional modules mentioned above, ensuring that the system achieves full-process automation, high availability, and secure and stable operation in complex working environments. This module consists of the following core functions working together to form the control of the entire system: Task workflow management and automated scheduling: The system achieves fully automated operation and intelligent scheduling from fault input to diagnostic output. It constructs an end-to-end automated execution workflow for diagnostic tasks, enabling intelligent scheduling across the entire chain from fault reporting to result output. The system receives diagnostic requests from the user interaction and feedback module via an API gateway. The system control and scheduling center then triggers subsequent processing steps according to a preset process: first, the "data collection and preprocessing module" completes text standardization and multimodal information parsing; then, it collaborates with the "retrieval enhancement and generation module" to retrieve knowledge and generate answers; finally, the diagnostic results are sent back to the front end for display. Furthermore, the system supports an asynchronous task queue mechanism to effectively handle high-concurrency requests, achieving task buffering and load balancing. It also provides a visual process monitoring interface, displaying the real-time stage and processing status of each task, facilitating maintenance personnel to understand system operation and intervene in abnormal processes promptly, ensuring stable and efficient service.

[0114] Task Distribution and Resource Scheduling: The system possesses intelligent task routing and dynamic resource scheduling capabilities. Based on request type, computational complexity, and current system load, it automatically matches the optimal processing path, improving overall concurrent processing capacity and response efficiency. Upon receiving a diagnostic request, the system automatically identifies its modality type and routes the task to the corresponding dedicated processing method: text requests are distributed to the NLP service cluster, image upload requests are scheduled to the OCR and visual recognition services, and voice input requests are forwarded to the Automatic Speech Recognition (ASR) microservice. It supports a multi-node distribution mechanism based on load balancing strategies, evenly distributing high-concurrency requests to parallel computing instances, effectively avoiding single-point overload. In edge computing deployment scenarios, it supports offloading lightweight tasks (such as keyword matching and basic rule judgment) to local edge servers for execution, uploading only complex semantic understanding and generation tasks to the cloud, significantly reducing network dependence and response latency, and achieving efficient resource utilization.

[0115] API Gateway and Service Exposure: As the system's unified external service portal, the API gateway provides standardized and manageable interface access capabilities, supporting the secure exposure of internal functional modules and efficient integration with external systems. It exposes a set of RESTful API interfaces, covering core diagnostic and interaction scenarios. The gateway integrates multiple management and security mechanisms: supporting standard authentication methods such as JWT and OAuth2 to ensure the legitimacy of interface access; and fully recording the request parameters, response results, and the user's last login time for each request, forming a traceable call log.

[0116] External Data Integration and API Analysis: The system supports integration with various external systems, proactively acquiring key contextual data needed for auxiliary diagnosis through standardized interfaces, improving the accuracy and environmental adaptability of fault diagnosis. The main integrated data sources include manufacturer-provided fault handling and maintenance knowledge base APIs, used to obtain the latest repair manuals, technical bulletins, service announcements, and typical fault solutions, ensuring that diagnostic basis keeps pace with product iterations. In addition, the system can also access the customer center service API to expand its knowledge of real-world agricultural machinery fault detection and handling.

[0117] Performance Monitoring and Operational Auditing: The system provides basic operational status monitoring and full-process operation auditing capabilities, ensuring service traceability and problem localization. The log system comprehensively records key behaviors such as user operations, diagnostic processes, module calls, and API access, forming a complete execution trajectory to support subsequent problem investigation and accountability. Leveraging the native capabilities of the container engine, the system allows real-time viewing of CPU utilization, memory usage, and GPU utilization for each service container (applicable to GPU-equipped inference services), facilitating rapid identification of resource bottlenecks or abnormal usage. Simultaneously, the system tracks the time consumption of core processing stages, such as fault preprocessing, knowledge retrieval, and report generation, helping to evaluate performance. When service anomalies, database connection failures, or model inference timeouts occur, the system can trigger alarms and notify relevant personnel. The auditing function supports querying historical diagnostic records by time, user, device model, and other criteria, completely tracing the processing process and meeting the basic needs of daily operation and maintenance and enterprise compliance management.

[0118] Deployment Modes and Security Protection: The system supports multiple deployment modes, allowing for flexible selection based on the actual network environment, data management requirements, and operational capabilities, meeting the security and availability needs of users of different sizes. Regarding security protection, the system integrates a basic yet effective multi-layered protection mechanism: request forwarding and HTTPS encrypted communication (SSL / TLS termination) are implemented through reverse proxy services such as Nginx to ensure secure data transmission; sensitive data is internally encrypted during transmission and storage to prevent information leakage; and a role-based access control system is combined to achieve hierarchical control of user operations, eliminating the risks of unauthorized access and accidental operations. The overall design balances security and deployment feasibility.

[0119] In summary, the intelligent fault handling system for harvesting machinery based on retrieval-enhanced generation proposed in this invention achieves a complete closed-loop process through the coordinated operation of five core modules, from fault data collection and preprocessing, knowledge base construction and management, intelligent fault understanding and generation, user interaction and feedback, to overall system control and scheduling. The modules are closely integrated, data flow is efficient, and functional complementarity is strong, providing an intelligent, interpretable, and sustainably optimized solution for fault diagnosis and maintenance of agricultural machinery in complex operating environments.

[0120] This invention proposes an intelligent fault handling method, device, and system for harvesting machinery based on retrieval-enhanced generation. By introducing advanced semantic understanding, information retrieval, and text generation technologies, it achieves intelligent, automated, and personalized services in the fault diagnosis process of agricultural machinery. The following will, from a technical implementation perspective, combine the specific technical solutions of this invention to deduce and summarize its significant advantages: 1. Enhance semantic understanding capabilities to improve the accuracy of fault identification. Traditional agricultural machinery fault diagnosis systems often rely on keyword matching or rule bases for fault identification, making it difficult to accurately understand the natural language descriptions input by users. This invention, however, introduces retrieval-enhanced generation technology, uses a semantic coding model to vectorize user input, and combines this with historical cases from a knowledge base for similarity calculation, thereby achieving a deeper level of semantic understanding.

[0121] Therefore, it can be deduced that: the system can accurately identify key information in unstructured fault descriptions; it can effectively distinguish synonyms, near-synonyms, and ambiguous expressions, reducing the misjudgment rate; and compared with traditional methods, it has stronger language adaptability and generalization ability.

[0122] 2. Integrate historical data with contextual information to enhance the interpretability of maintenance recommendations. Existing systems often lack supporting evidence when outputting maintenance recommendations, making it difficult for technicians to assess their reliability. This invention utilizes a retrieval-enhanced generation engine to search for relevant cases in a knowledge base and use them as contextual input to the generative model, thereby generating maintenance recommendations with clear sources and logical reasoning.

[0123] This leads to the conclusion that: the generated results include supporting explanations, increasing credibility; technicians can make judgments and verifications based on the reasons for the recommendations; and the adoption rate and execution efficiency of maintenance suggestions are improved.

[0124] 3. Build a dynamically updated knowledge base to ensure the system's timeliness and scalability. Traditional agricultural machinery fault diagnosis systems rely on static knowledge bases, resulting in long update cycles and high maintenance costs. This invention designs a multi-source heterogeneous knowledge base architecture that supports incremental updates, enabling automatic integration of new data and periodic optimization of the index structure.

[0125] Therefore, it can be deduced that: the knowledge base content can be continuously expanded with the iteration of equipment and changes in usage scenarios; it supports data migration and reuse across models and operating conditions; and the system has the vitality and adaptability for long-term operation.

[0126] 4. Introduce a user feedback mechanism to enable continuous learning and self-optimization of the system. This invention, by setting up a user feedback module, allows technicians to rate, modify, or supplement the generated suggestions, forming a closed-loop feedback mechanism.

[0127] This leads to the conclusion that the system can continuously adjust its generation strategy based on actual application results; the fault diagnosis model can be fine-tuned and optimized through feedback data; and the system can achieve "self-evolution" capabilities, thereby enhancing its long-term usability.

[0128] 5. Supports multimodal interaction, enhancing user experience and applicability. Compared to traditional systems that only support text input and query interfaces, this invention provides multiple interaction methods such as voice input, image upload, and graphic display to meet the usage needs of different operating environments.

[0129] This leads to the conclusion that: operators can use the system efficiently in complex working environments; the ease of operation and response speed of on-site maintenance personnel are improved; and the practicality and promotion potential of the system are enhanced.

[0130] In summary, this invention, through innovative means such as introducing retrieval enhancement generation technology, constructing a dynamic knowledge base, integrating contextual information, setting up a feedback mechanism, and multimodal interaction, outperforms existing technical solutions in terms of fault identification accuracy, interpretability of maintenance suggestions, system scalability, and user experience. It has significant technological progress and good prospects for widespread application.

[0131] The harvester fault diagnosis device of this invention can execute the harvester fault diagnosis method provided in this invention. The implementation principle is similar. The actions performed by each module and unit in the harvester fault diagnosis device in each embodiment of this invention correspond to the steps in the harvester fault diagnosis method in each embodiment of this invention. For detailed functional descriptions of each module of the harvester fault diagnosis device, please refer to the descriptions in the corresponding harvester fault diagnosis methods shown above. They will not be repeated here.

[0132] The aforementioned harvester fault diagnosis device can be a computer program (including program code) running on a computer device, such as an application software; the device can be used to execute the corresponding steps in the method provided in the embodiments of the present invention.

[0133] In some embodiments, the harvester fault diagnosis device provided in this invention can be implemented using a combination of hardware and software. As an example, the harvester fault diagnosis device provided in this invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the harvester fault diagnosis method provided in this invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0134] In other embodiments, the harvester fault diagnosis device provided in this invention can be implemented in software. Figure 7 A harvester fault diagnosis device stored in a memory is shown. It can be software in the form of programs and plug-ins, and includes a series of modules, including an acquisition module 210, an encoding module 220, a preliminary retrieval module 230, and a fault diagnosis module 240, for implementing the harvester fault diagnosis method provided in the embodiments of the present invention.

[0135] The modules described in the embodiments of the present invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0136] Based on the same principles as the methods shown in the embodiments of the present invention, the embodiments of the present invention also provide an electronic device, which may include, but is not limited to: a processor and a memory; the memory for storing computer programs; and the processor for executing the methods shown in any embodiment of the present invention by invoking the computer programs.

[0137] In one alternative embodiment, an electronic device is provided, such as Figure 8 As shown, Figure 8The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0138] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0139] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0140] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0141] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0142] Among these, electronic devices can also be terminal devices. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0143] This invention provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to execute the corresponding content in the aforementioned method embodiments.

[0144] According to another aspect of the present invention, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various embodiments described above.

[0145] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The computer-readable storage medium provided in this invention can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0148] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0149] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for diagnosing faults in a harvester, characterized in that, include: Obtain fault information input by the user; The fault information is vectorized and encoded to obtain a query vector; Based on the query vector, preliminary search results are obtained from a pre-built knowledge base, including at least two historical cases related to the faults corresponding to the query vector. Based on at least two historical cases and the query vector, a fault diagnosis report is obtained through a pre-trained retrieval enhancement model.

2. The method according to claim 1, characterized in that, The fault diagnosis report includes an analysis of possible causes of the fault, recommended maintenance suggestions, corresponding operation steps and visual aids for the recommended maintenance suggestions, and an explanation of the basis for the fault diagnosis report.

3. The method according to claim 1, characterized in that, The step of vectorizing the fault information to obtain a query vector includes: The fault information is vectorized and encoded using an embedding model to obtain a query vector.

4. The method according to any one of claims 1 to 3, characterized in that, The knowledge base is constructed in the following way: Acquire basic knowledge and multiple historical cases. The basic knowledge includes the mechanical principles, working principles and fault types of different types of harvesters. The multiple historical cases include fault cases corresponding to different fault types under different types of harvesters. The basic knowledge includes structured data and unstructured data. The knowledge base is constructed based on the aforementioned fundamental knowledge and multiple aforementioned fault cases; The step of obtaining preliminary search results from a pre-built knowledge base based on the query vector includes: The harvester type and fault type corresponding to the fault information are determined based on the query vector; Based on the harvester type and fault type corresponding to the fault information, preliminary search results are obtained from the knowledge base.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Obtain user feedback on the fault diagnosis report; The fault diagnosis report and / or the knowledge base are adjusted based on the feedback results.

6. The method according to any one of claims 1 to 3, characterized in that, The fault information is multi-source fault information, which includes at least one of voice, text, and image.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Extract the fault features from the fault information; The step of vectorizing the fault information to obtain a query vector includes: The fault features are vectorized and encoded to obtain a query vector.

8. A harvester fault diagnosis device, characterized in that, include: The acquisition module is used to acquire fault information input by the user; The encoding module is used to vectorize the fault information to obtain a query vector; The preliminary retrieval module is used to obtain preliminary retrieval results from a pre-built knowledge base based on the query vector. The preliminary retrieval results include at least two historical cases related to the faults corresponding to the query vector. The fault diagnosis module is used to generate a fault diagnosis report based on at least two historical cases and the query vector, using a pre-trained retrieval enhancement model.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

10. 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-7.

Images