A method, an electronic device, and a storage medium for locally responding to a question and answer request

Abstract

This application relates to the field of question-and-answer request technology, and discloses a local response method, electronic device, and computer-readable storage medium for question-and-answer requests. The method includes: acquiring a question-and-answer request; rewriting the natural language query text and contextual data to generate a target query statement; retrieving the target query statement based on a preset vector index knowledge base and a structured knowledge base to obtain multiple candidate knowledge fragments; ranking the multiple candidate knowledge fragments according to relevance scores; truncating the ranked candidate knowledge fragments according to a preset input length limit threshold to obtain a target knowledge fragment; and inputting the target knowledge fragment and the natural language query text into a locally pre-deployed lightweight model for inference to respond to the question-and-answer request. Through the above method, this application achieves a good response to user question-and-answer requests on resource-constrained local devices.

Description

Technical Field

[0001] This application relates to the field of question-and-answer request technology, specifically to a local response method for question-and-answer requests, an electronic device, and a computer-readable storage medium. Background Technology

[0002] With the development of artificial intelligence (AI) technology, the application of AI technologies such as large language models and intelligent agents is becoming increasingly widespread. For example, in the automotive diagnostics industry, in order to improve the efficiency of fault diagnosis, more and more repair scenarios are using intelligent agents such as diagnostic assistants to assist technicians in their work.

[0003] Currently, diagnostic assistants typically run in the cloud, relying on cloud computing power and large models to respond to user queries. However, in real-world automotive repair scenarios such as workshops, parking garages, and roadside assistance, the unavailability of public networks or poor signal strength often renders cloud-based diagnostic assistants unusable, thus affecting the continuity and timeliness of diagnostic work.

[0004] To address network dependency issues, existing technologies attempt to deploy diagnostic tools such as diagnostic assistants on local devices. However, local devices (such as diagnostic tablets) are typically resource-constrained, with limited computing power and memory. This makes it difficult to run diagnostic assistant tools containing complex components such as large language models directly on resource-constrained local devices. Forcing them to run can easily lead to memory overflow, device lag, or even system crashes.

[0005] Therefore, how to respond well to users' question-and-answer requests on resource-constrained local devices has become a pressing technical problem. Summary of the Invention

[0006] In view of the above problems, embodiments of this application provide a local response method for question-and-answer requests, an electronic device, and a computer-readable storage medium to solve the problem in the prior art that it is difficult to respond well to user question-and-answer requests on resource-constrained local devices.

[0007] According to one aspect of the embodiments of this application, a local response method for question-and-answer requests is provided. The method includes: obtaining a question-and-answer request, wherein the question-and-answer request includes natural language query text and scene context data; rewriting the natural language query text and scene context data to generate a target query statement; retrieving the target query statement based on a preset vector index knowledge base and a structured knowledge base to obtain multiple candidate knowledge fragments; evaluating the relevance of the multiple candidate knowledge fragments to obtain a relevance score for each candidate knowledge fragment; sorting the multiple candidate knowledge fragments according to the relevance scores; truncating the sorted candidate knowledge fragments according to a preset input length limit threshold to obtain a target knowledge fragment; and inputting the target knowledge fragment and the natural language query text into a locally pre-deployed lightweight model for inference to respond to the question-and-answer request.

[0008] In one optional approach, the target query statement is retrieved based on a preset vector index knowledge base and a structured knowledge base to obtain multiple candidate knowledge fragments. This includes: vectorizing the target query statement to obtain a query vector; determining structured filtering conditions based on scenario context data; determining a target retrieval subspace from the vector index knowledge base based on the structured filtering conditions; performing a similarity retrieval within the target retrieval subspace based on the query vector to obtain a first retrieval result set; parsing the structured entities in the target query statement to obtain query entities; performing a retrieval in the structured knowledge base based on the query entities to obtain a second retrieval result set; merging the first and second retrieval result sets to generate multiple candidate knowledge fragments; and evaluating the relevance of the multiple candidate knowledge fragments to obtain a relevance score for each candidate knowledge fragment, including: determining the similarity between each candidate knowledge fragment and the target query statement to obtain a relevance score for each candidate knowledge fragment.

[0009] In one optional approach, the similarity between multiple candidate knowledge fragments and the target query statement is determined to obtain a relevance score for each candidate knowledge fragment. This includes: determining the similarity between multiple candidate knowledge fragments and the target query statement, obtaining a relevance score for each candidate knowledge fragment, and a confidence level for the relevance score; after sorting the multiple candidate knowledge fragments according to the relevance scores, the method further includes: if the confidence level of the relevance score of each candidate knowledge fragment is lower than a preset confidence threshold, then the question-and-answer request is subjected to intent recognition to obtain intent information; the response requirement type of the question-and-answer request is determined based on the intent information; if the response requirement type is external real-time data dependent, then an offline synchronization task is generated, wherein the offline synchronization task contains the identification information of the question-and-answer request, which is used to obtain real-time data from the cloud and generate a response based on the identification information when the network parameters meet preset conditions; if the response requirement type is non-real-time data dependent, then a response is generated based on preset heuristic rules.

[0010] In one alternative approach, after rewriting the natural language query text and contextual data to generate the target query statement, the method further includes: if no candidate knowledge fragments are found when searching the target query statement based on a preset vector index knowledge base and a structured knowledge base, then the intent of the question-and-answer request is identified to obtain intent information; the response requirement type of the question-and-answer request is determined based on the intent information; if the response requirement type is external real-time data dependent, then an offline task to be synchronized is generated, wherein the offline task to be synchronized contains the identification information of the question-and-answer request, which is used to obtain real-time data from the cloud and generate a response based on the identification information when the network parameters meet preset conditions; if the response requirement type is non-real-time data dependent, then a response is generated based on preset heuristic rules.

[0011] In an alternative approach, before obtaining the question-and-answer request, the method further includes: in response to the selected diagnostic scenario, loading a skill package configuration file corresponding to the diagnostic scenario, wherein the skill package configuration file includes a knowledge base index identifier and a tool invocation whitelist; retrieving the target query statement based on a preset vector index knowledge base and structured knowledge base to obtain multiple candidate knowledge fragments, including: parsing the question-and-answer request to generate a target tool invocation instruction, wherein the target tool invocation instruction contains an identifier of the tool to be invoked; verifying whether the identifier of the tool to be invoked exists in the tool invocation whitelist; if the identifier of the tool to be invoked exists in the tool invocation whitelist, injecting the knowledge base index identifier as a retrieval constraint parameter into the local retrieval tool corresponding to the identifier of the tool to be invoked; and, based on the local retrieval tool, retrieving the target query statement in the vector index knowledge base and structured knowledge base corresponding to the knowledge base index identifier to obtain multiple candidate knowledge fragments.

[0012] In one alternative approach, the skill pack configuration file also includes prompt word templates and domain role setting information; inputting target knowledge fragments and natural language query text into a locally pre-deployed lightweight model for inference to respond to question-and-answer requests includes: constructing system prompt instructions based on the domain role setting information and prompt word templates; concatenating the system prompt instructions, target knowledge fragments, and natural language query text into a target prompt word sequence according to a preset concatenation order; and inputting the target prompt word sequence into the lightweight model for inference to respond to question-and-answer requests.

[0013] In one alternative approach, the prompt word template includes a thought chain guidance template, which includes pre-configured logical steps for reasoning; inputting the target prompt word sequence into a lightweight model for reasoning to respond to a question-and-answer request includes: inputting the thought chain guidance template and the target prompt word sequence into the lightweight model for reasoning, so that the lightweight model generates reasoning text corresponding to the logical steps in sequence according to the thought chain guidance template; and responding to the question-and-answer request based on the reasoning text.

[0014] In one alternative approach, obtaining a question-and-answer request includes: acquiring the user's raw speech stream data; loading a pre-configured vocabulary bias library for the automotive diagnostics domain; decoding the raw speech stream data based on the vocabulary bias library to obtain an initial text sequence; and performing slot filling and intent classification on the initial text sequence to generate natural language query text and contextual data.

[0015] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement a local response method for a question-and-answer request as described in any of the preceding claims.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements a local response method for a question-and-answer request as described in any of the preceding claims.

[0017] This application embodiment obtains a question-and-answer request and rewrites the natural language query text and scene context data to generate a target query statement that accurately reflects the user's true intent and the current scene state. Based on a preset vector index knowledge base and structured knowledge base, the target query statement is retrieved to obtain multiple candidate knowledge fragments. These fragments are then evaluated for relevance, resulting in a relevance score for each fragment. The fragments are ranked according to their relevance scores to extract the core knowledge fragments most relevant to the user's true intent and the current scene state from the local knowledge subset slices. Redundant and low-relevance noise data are removed, thereby reducing invalid data processing volume and lowering the cost of local devices under limited local resources. The computational power consumption is reduced; the ranked candidate knowledge fragments are truncated according to a preset input length limit threshold to obtain the target knowledge fragment, thereby controlling the context length input to the local large model. This improves the memory consumption surge and slow inference caused by long text input, thus preventing memory overflow, lag, or even system crashes on the local device; the target knowledge fragment and natural language query text are input into the locally pre-deployed lightweight model for inference to respond to question-answering requests. This allows the lightweight model to obtain high signal-to-noise ratio context references even when offline and under computationally limited conditions, thereby effectively suppressing the generation of unfounded illusions and ensuring the accuracy and professionalism of the response to user question-answering requests in scenarios without network or with weak network. This achieves good response to question-answering requests on resource-constrained local devices.

[0018] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the local response method for question-and-answer requests provided in an embodiment of this application is shown. Figure 2 The embodiments provided in this application are shown. Figure 1 A flowchart illustrating the sub-steps of step S130; Figure 3 This paper shows a schematic diagram of the structure of a local response device for question-and-answer requests provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0021] The local response method for question-and-answer requests provided in this application can be applied to various business scenarios, such as vehicle diagnostics and equipment maintenance. The following description uses the vehicle diagnostics business scenario as an example.

[0022] The local device that executes the local response method for question-and-answer requests corresponds to a specific business scenario. For example, in an automotive diagnostic scenario, the local device is a diagnostic tablet or a ruggedized mobile terminal. This local device has limited local computing power and storage, and can deploy lightweight large language models, edge speech recognition models, and intelligent agents.

[0023] Figure 1 A flowchart illustrating a local response method for question-and-answer requests provided in an embodiment of this application is shown, as follows: Figure 1 As shown, the method includes the following steps S110~S170: S110, Obtain the question-and-answer request, wherein the question-and-answer request includes natural language query text and scene context data.

[0024] Users can input their questions and answers in various ways, such as having a technician input voice through a microphone and have it processed locally to be converted into text, or directly inputting text through a touchscreen.

[0025] Natural language query text is a colloquial question input by the user, such as "I received a fault code and entered 'How do I check if the engine is idling and vibrating'?"

[0026] Contextual data refers to structured parameter information closely related to the current diagnostic task, including but not limited to vehicle identification number prefixes, lists of read fault codes, vehicle series name, and model year. This data can be automatically read by local devices through the on-board diagnostic interface, or manually selected by technicians.

[0027] This step combines natural language query text with specific scene context data, providing a data foundation for subsequent retrieval and ensuring that the response content does not deviate from the actual condition of the current vehicle.

[0028] S120: Rewrite the natural language query text and contextual data to generate the target query statement.

[0029] Rewriting is the process of semantically reorganizing and expanding user input that is colloquial, may contain unclear references, or is incomplete. Rewriting can be achieved through techniques such as synonym expansion and reference resolution.

[0030] Because users' natural language query text may be quite brief, directly using it for retrieval often results in low recall. Therefore, the local device integrates the natural language query text with contextual data. For example, when the natural language query text is "How do I check this code on this car?", and the contextual data contains specific fault codes and vehicle information, the rewriting operation will replace colloquial references with specific parameters and supplement relevant technical terms to generate a target query statement that includes specific fault code definitions and vehicle status.

[0031] The target query statement can accurately reflect the user's true intent and the current scene state, thereby improving the accuracy of subsequent retrieval based on the target query statement.

[0032] S130: Based on the preset vector index knowledge base and structured knowledge base, the target query statement is retrieved to obtain multiple candidate knowledge fragments.

[0033] By embedding texts such as maintenance manuals and diagnostic trees pre-installed on local devices into high-dimensional vectors and building indexes, a vector index knowledge base can be obtained. The structured knowledge base is a database that stores structured data such as fault code interpretations and function path indexes in the form of tables and key-value pairs.

[0034] Since the local storage contains a sliced ​​subset of knowledge, the local device will perform retrieval operations in these two databases respectively, and summarize the matched text paragraphs, table records, etc. into multiple candidate knowledge fragments.

[0035] For example, for a target query containing fault codes and idling vibration, the retrieval will return the official definition fragment of the fault code and the corresponding troubleshooting guide fragment.

[0036] By combining vector-indexed knowledge bases and structured knowledge bases for retrieval, we can fully leverage the semantic understanding capabilities of vector retrieval and the precise matching capabilities of structured retrieval to extract relevant knowledge content from local knowledge subsets.

[0037] S140: Evaluate the relevance of multiple candidate knowledge fragments to obtain a relevance score for each candidate knowledge fragment.

[0038] The degree of matching between candidate knowledge fragments and target query statements in terms of semantic and literal features is calculated to achieve relevance evaluation of multiple candidate knowledge fragments.

[0039] By using a reordering model or cross-encoder, the target query can be deeply interactively computed with each candidate knowledge fragment, outputting a quantified relevance score.

[0040] During the retrieval phase, due to the coarse-grained recall strategy employed, the returned candidate knowledge fragments often contain redundant or low-relevance noisy data, such as troubleshooting guidelines for other irrelevant fault codes. Relevance assessment can accurately measure the degree of match between each fragment and the user's true intent, providing a quantitative basis for subsequent filtering and thus reducing the amount of invalid data processing under limited local resources.

[0041] S150: Sort multiple candidate knowledge fragments according to their relevance scores.

[0042] Candidate knowledge fragments are rearranged in descending order of relevance score.

[0043] By sorting, the core knowledge fragments that best match the user's true intent and the current scenario will be placed at the top, while noisy data with low relevance will be placed at the bottom.

[0044] By sorting, information can be prioritized, ensuring that the most critical and relevant diagnostic knowledge can be processed and retained by local devices first when resources are limited, thereby further reducing the computing power consumption of local devices in processing redundant data.

[0045] S160, the sorted candidate knowledge fragments are truncated according to the preset input length limit threshold to obtain the target knowledge fragment.

[0046] The preset input length limit threshold is a maximum input length limit pre-set based on the local device's memory capacity and the context window size of the locally pre-deployed lightweight model, for example, 2048 words.

[0047] Since local devices typically have limited memory, if the text input to a large model is too long, it can cause memory usage to increase exponentially, leading to slow inference, memory overflow, or system crashes.

[0048] Therefore, it is necessary to truncate the sorted candidate knowledge fragments, that is, to retain the top-ranked candidate knowledge fragments and discard subsequent fragments that exceed the length threshold.

[0049] By truncating the text, only the core knowledge fragments most relevant to the user's intent are extracted. This allows control over the length of the context input to the lightweight model, improving the memory consumption spikes and slow inference caused by long text inputs, and effectively preventing memory overflow and lag on local devices.

[0050] S170, input the target knowledge fragment and natural language query text into a locally pre-deployed lightweight model for inference in order to respond to the question-answering request.

[0051] Running a full-size large language model directly on a resource-constrained automotive diagnostic tablet can cause system lag or even memory overflow. To address this issue, the local device employs model quantization technology to compress the underlying large language model. Model quantization refers to the process of converting high-precision floating-point parameters in the model into low-precision integer representations, such as using a 4-bit or 8-bit quantization scheme, to reduce memory usage during large model loading and computational demands during inference.

[0052] The lightweight model, after quantization, can not only run smoothly on the central processing unit or neural network processor of the diagnostic tablet, but also maintain a high level of semantic understanding and generation capabilities. This provides a computing power foundation for answering question-and-answer requests in offline scenarios and prevents device crashes caused by forcibly running complex components.

[0053] The lightweight model can generate a natural language response based on the input text sequence through forward computation of a neural network.

[0054] The local device assembles the target knowledge fragments with high signal-to-noise ratio and the user's natural language query text and inputs them into the lightweight model. The lightweight model generates the final professional investigation suggestions based on these constrained context references.

[0055] Because the input context is filtered and its length is controlled, the lightweight model can still obtain high-quality reference information even when offline and with limited computing power. This effectively suppresses the generation of unfounded illusions and ensures the accuracy and professionalism of the response to user question-and-answer requests in scenarios with no network or weak network.

[0056] Due to limitations in local device storage and computing power, large-scale exhaustive searches cannot be performed as in the cloud. Figure 2 The embodiments provided in this application are shown. Figure 1 A flowchart illustrating the sub-steps of step S130 is shown below. Figure 2 As shown, step S130 includes sub-steps S131 to S137: S131, the target query statement is vectorized to obtain the query vector.

[0057] By utilizing a locally pre-deployed lightweight embedding model, the target query statement in text format is mapped into a numerical vector in a high-dimensional space to complete the vectorization processing of the target query statement.

[0058] The vector obtained by mapping is the query vector, which is a mathematical vector representation that can characterize the semantic features of the target query statement.

[0059] By converting text into vectors, local devices can measure semantic similarity by calculating the distance or angle between vectors.

[0060] S132, determine the structured filtering conditions based on the scene context data.

[0061] Structured filtering conditions refer to precise matching rules built based on vehicle attribute parameters. Specifically, the local device extracts structured fields such as vehicle identification number prefix, vehicle series name, and model year from the scene context data and transforms them into conditional expressions that can be used for database filtering.

[0062] Before performing a computationally intensive vector search, the search scope is first defined using precise vehicle attributes to avoid retrieving data from other vehicle series or irrelevant years, thereby reducing the computational load of the vector search.

[0063] S133, determine the target retrieval subspace from the vector index knowledge base based on structured filtering conditions.

[0064] The target retrieval subspace refers to the set of data in the vector index knowledge base that matches the characteristics of the current vehicle.

[0065] Since the vector index knowledge base may contain massive knowledge slices from numerous vehicle series, performing vector retrieval directly across the entire database would lead to wasted computing power and easily introduce cross-vehicle series interference. By using structured filtering conditions for gating, the local device pre-removes mismatched slices, retaining only the data region consistent with the current vehicle attributes as the target retrieval subspace, thereby reducing the scale of vector computation and lowering the computational pressure on the edge device.

[0066] S134, perform similarity retrieval within the target retrieval subspace based on the query vector to obtain the first retrieval result set.

[0067] Similarity retrieval refers to calculating the cosine similarity or inner product between the query vector and each knowledge slice vector within the target retrieval subspace, and recalling relevant segments according to the similarity score.

[0068] Query vector-based similarity retrieval can understand the semantics behind colloquial expressions. Even if the query statement uses different words than the original text in the knowledge base, it can still accurately recall queries based on semantic similarity.

[0069] S135, parse the structured entities in the target query statement to obtain the query entity.

[0070] Structured entities refer to terms or codes in the target query statement that have a clear professional focus. After parsing and extraction, the resulting query entities can be directly used for precise queries.

[0071] Local devices use named entity recognition technology or regular expressions to extract key entities such as specific fault codes, sensor names, and system assemblies from target query statements.

[0072] For example, a specific fault code can be parsed from the target query statement as the query entity in order to perform a precise structured query.

[0073] S136, based on the query entity, perform a retrieval in the structured knowledge base to obtain the second retrieval result set.

[0074] The structured knowledge base stores precise structured data such as official definitions of fault codes, diagnostic tree node relationships, and functional path indexes.

[0075] The local device uses the query entity as a key to search in the structured knowledge base, quickly obtaining the standard definition or exact path corresponding to the entity.

[0076] Conditional retrieval based on query entities has high accuracy and almost no semantic ambiguity.

[0077] S137, merge the first search result set and the second search result set to generate multiple candidate knowledge fragments.

[0078] The system deduplicates, standardizes, and merges results from different search paths.

[0079] Since the first search result set focuses on semantic fuzzy matching and the second search result set focuses on precise structural matching, there may be some overlap between the two.

[0080] The local device removes duplicate segments through methods such as identification comparison, and converts the remaining text paragraphs and structured records into a unified format of candidate knowledge segments.

[0081] By using a hybrid retrieval method, we retain the generalization and understanding capabilities of vector retrieval while incorporating the precise matching capabilities of structured retrieval, ensuring that the recalled candidate knowledge fragments are comprehensive and accurate.

[0082] Accordingly, step S140 includes the sub-step S141, determining the similarity between multiple candidate knowledge fragments and the target query statement, and obtaining the relevance score of each candidate knowledge fragment.

[0083] A rearrangement model is used to perform a second in-depth evaluation of the candidate knowledge fragments initially recalled.

[0084] In the recall phase, in pursuit of speed, a lightweight dual-tower model is usually used to encode queries and fragments separately. While this approach is fast, it lacks deep interaction between the two.

[0085] Therefore, cross-coding technology can be introduced in this step to concatenate the target query statement with each candidate knowledge fragment and input it into the lightweight reordering model. This allows the lightweight reordering model to capture the subtle relationship between the two at the lexical level, thereby outputting a more accurate relevance score. This enables effective filtering of noisy data on local devices with limited computing power at a low computational cost.

[0086] In real-world repair scenarios such as automotive diagnostics, limited by the size of the knowledge subset stored locally and the computing power, local devices inevitably encounter user requests that exceed the scope of their knowledge or have low matching accuracy. Forcing a lightweight model to respond based on low-quality context can easily lead to unfounded, illusory outputs. Therefore, in one optional approach, step S141 includes the sub-step: S141a, determining the similarity between multiple candidate knowledge fragments and the target query statement, obtaining the relevance score of each candidate knowledge fragment, and the confidence level of that relevance score.

[0087] When using a rearrangement model to calculate a relevance score, the rearrangement model not only outputs a quantified score value, but also outputs the confidence level of the score based on the score distribution characteristics or the prediction probability of the rearrangement model itself.

[0088] Because the local knowledge base is a truncated subset of knowledge, it may contain fragments that are relevant to the literal or semantic parts of the query but have little practical diagnostic value. By conducting confidence assessments, local devices can more accurately determine whether the local knowledge base truly covers the user's core needs, rather than relying solely on absolute score values ​​for decision-making.

[0089] Accordingly, after step S150, the method further includes steps S181 to S184: S181, if the confidence score of the relevance score of each candidate knowledge fragment is lower than the preset confidence threshold, then the intent of the question-and-answer request is identified to obtain intent information.

[0090] After sorting multiple candidate knowledge fragments according to their relevance scores, if the confidence level of the relevance score of each candidate knowledge fragment is lower than the preset confidence threshold, it indicates that there is no content in the current local knowledge base that can answer the question with high confidence.

[0091] At this point, the local device performs intent recognition on the question-and-answer request to obtain intent information. Intent recognition refers to the process of analyzing natural language query text and combining it with contextual data through a lightweight classification model or rule engine to interpret the user's true needs. For example, determining whether the user wants to query local troubleshooting steps for a specific fault code or wants to query recall information for the same model of vehicle across the entire network.

[0092] S182, determine the response requirement type of the question-and-answer request based on the intent information.

[0093] The response requirement type refers to the data source attribute required to complete the question and answer request, which is mainly divided into external real-time data dependency type and non-real-time data dependency type.

[0094] Local devices use a pre-configured mapping relationship between intent and type to transform user intent information into specific response request types. This allows local devices to distinguish which problems are limited by insufficient local knowledge but can be covered by experience, and which problems are limited by architecture and must rely on external networks, thus adopting different processing methods.

[0095] S183, if the response request type is external real-time data dependent, an offline task to be synchronized is generated. The offline task to be synchronized contains the identification information of the question and answer request, which is used to obtain real-time data from the cloud and generate a response when the network parameters meet the preset conditions.

[0096] If the response request type is external real-time data dependent, that is, the data required by the request needs to be obtained through the public network, such as querying vehicle recall status or the latest parts inventory, the local device will generate an offline task to be synchronized.

[0097] The offline synchronization task is a structured data record containing key fields such as the identifier of the question-and-answer request, the transcribed text, and the vehicle context. This task is persistently written to the local synchronization queue and is used to retrieve real-time data from the cloud and generate a response when network parameters meet preset conditions (such as the device reconnecting to the local area network or the public network).

[0098] By generating offline tasks to be synchronized, complex requests that cannot be processed during offline periods can be explicitly recorded and suspended, avoiding silent failures or pretending to have been answered.

[0099] S184. If the response request type is non-real-time data dependent, then the response will be based on the preset heuristic rules.

[0100] If the response request type is non-real-time data dependent, that is, the request does not require external real-time data, but is limited by the local knowledge subset not being covered or the current matching confidence being low, the local device responds based on preset heuristic rules.

[0101] Heuristic rules refer to pre-defined fallback diagnostic logic and safety disclaimers. For example, when the specific cause of a fault cannot be determined, heuristic rules will output basic troubleshooting suggestions, such as checking relevant wiring harness connections or asking if there are any other accompanying symptoms, along with a disclaimer prompting the technician to further diagnose the problem based on the actual vehicle conditions.

[0102] This response approach still provides technicians with guidance based on safety boundaries even in low-confidence scenarios, while managing user expectations and reducing liability disputes caused by over-promising.

[0103] By introducing confidence levels into the relevance assessment and classifying low-confidence requests into external real-time data-dependent and non-real-time data-dependent types based on intent recognition, and adopting offline synchronization and heuristic fallback strategies respectively, clear capability boundaries and degradation paths can be built on resource-constrained and completely offline local devices. This effectively prevents lightweight models from fabricating data when lacking evidence, and ensures the interpretability and accountability of diagnostic recommendations.

[0104] In a completely offline automotive diagnostic scenario, the size of the knowledge subset stored on the local device is limited. When the technician's question exceeds the coverage of the local knowledge subset, or when no matching items can be found in either structured or vector retrieval, the local device faces the extreme situation of having completely empty recall results. If an empty context is directly input into the lightweight model at this time, the lightweight model will rely entirely on its own parameters to perform arbitrary operations, resulting in hallucination output. Therefore, in an optional approach, after step S120, the method further includes steps S191~S194: S191, if the target query statement is retrieved based on the preset vector index knowledge base and structured knowledge base, and no candidate knowledge fragment is found, then the intent of the question-and-answer request is identified to obtain intent information.

[0105] No candidate knowledge fragments were found. This means that no results with semantic similarity meeting the standard were found in the target subspace of vector retrieval, and no corresponding fault codes or feature entities were matched in the structured knowledge base. In other words, the recall results of the two-way hybrid retrieval were empty. This situation usually means that the user's request exceeded the knowledge boundary of the current local device deployment.

[0106] To avoid blindly refusing service or fabricating information, local devices also need to perform intent recognition on question and answer requests.

[0107] The intent recognition process uses lightweight classification models or rule engines to analyze natural language query text and combine it with contextual data to interpret the user's true needs. For example, when a technician inquires about the nationwide recall information for a specific car model or the troubleshooting steps for a rare fault code, the local device uses intent recognition to determine whether the request relies on external network data or is simply a routine troubleshooting need not covered by local knowledge.

[0108] S192, determine the response requirement type of the question-and-answer request based on the intent information.

[0109] S193, if the response request type is external real-time data dependent, an offline task to be synchronized is generated. The offline task to be synchronized contains the identification information of the question and answer request, which is used to obtain real-time data from the cloud and generate a response when the network parameters meet the preset conditions.

[0110] S194. If the response request type is non-real-time data dependent, then the response will be based on the preset heuristic rules.

[0111] The implementation of steps S192 to S194 is the same as that of steps S182 to S184 in the previous text. Therefore, the implementation of steps S192 to S194 can be referred to the description of S182 to S184 in the previous text, and will not be repeated here.

[0112] By performing intent recognition and response demand type classification when the local mixed search results are completely empty, and adopting a fallback strategy of offline pending task records and heuristic rules as a fallback based on the response demand type, the lightweight model can be prevented from silently fabricating data when there is a lack of reference, thus ensuring the interpretability and accountability of diagnostic suggestions.

[0113] Furthermore, after generating offline synchronization tasks, when network parameters meet preset conditions—that is, when the local device reconnects to the local area network or public network—the local device uploads the offline synchronization queue and question-and-answer logs generated during the offline period to the cloud, participating in cloud-based re-inference or online policy orchestration, thereby achieving delayed response compensation. In addition, in hybrid deployment mode, the agent in the local device can access external data sources such as cloud-based diagnostic services or accessory libraries via standardized tool protocols such as the Model Context Protocol (MCP) to expand the tool ecosystem.

[0114] In real-world repair scenarios such as vehicle diagnostics, the required prompts, tools, and knowledge range vary significantly across different vehicle models or repair tasks. Loading knowledge and tools from all vehicle models simultaneously on the local device would lead to storage overflow and retrieval chaos. Therefore, in an optional approach, prior to step S110, the method further includes the step: S101, in response to the selected diagnostic scenario, loading a skill package configuration file corresponding to the diagnostic scenario, wherein the skill package configuration file includes a knowledge base index identifier and a tool invocation whitelist.

[0115] Diagnostic scenarios refer to specific operating environments categorized based on vehicle attributes or maintenance tasks, such as routine diagnostic scenarios for a certain first vehicle series or diagnostic scenarios for the high-voltage systems of a certain second vehicle series' new energy vehicles.

[0116] A skill pack configuration file is a lightweight data unit that packages together the configuration parameters required for a specific scenario. It is usually a disk directory or a signed compressed file, and it includes at least a knowledge base index identifier and a tool call whitelist.

[0117] A knowledge base index identifier is a pointer or identifier used to point to a slice of knowledge subset of a specific vehicle series or system.

[0118] The tool call whitelist refers to the list of local tool identifiers that are allowed to be called by the local device in this diagnostic scenario.

[0119] When a technician selects the diagnostic scenario for the vehicle being repaired through the local device's interface, the local device immediately loads the corresponding skill package configuration file.

[0120] By loading the skill pack configuration file, there is no need to redeploy or load the full large model weights. Simply by switching the configuration file and database pointers of a few thousand bytes, the locally pre-deployed lightweight model and retrieval can be switched to the professional state of the corresponding car series, saving local device storage resources and switching time.

[0121] Accordingly, step S130 also includes sub-steps S138a~S138d: S138a, parse the question and answer request and generate a target tool invocation instruction, wherein the target tool invocation instruction contains the identifier of the tool to be invoked.

[0122] Target tool call instructions refer to machine instructions that an agent plans according to its intent at runtime to call specific local functions or interfaces.

[0123] The tool identifier to be invoked refers to a unique identifier contained in the instruction that explicitly points to the tool being invoked.

[0124] When the intelligent agent in the local device receives the rewritten target query statement, it will combine the currently loaded skill package configuration file to make overall plans, determine which local tools (such as local fault code query tools and local circuit diagram retrieval tools) need to be called to obtain the required information, and generate a target tool call instruction containing the identifier of the specific tool to be called.

[0125] S138b, verify whether the identifier of the tool to be called exists in the tool call whitelist.

[0126] The tool identifier to be invoked in the instruction is compared with the tool invocation whitelist in the currently loaded skill pack configuration file.

[0127] Since local devices must refuse to call tools that require public access in pure offline mode, and the available toolsets differ in different diagnostic scenarios, a whitelist mechanism is used to create a sandboxed boundary for tool calls on local devices.

[0128] If an agent attempts to call a tool that is not in the current scenario whitelist, the local device will directly intercept the call request, thereby avoiding unauthorized calls and misuse of external data sources, and ensuring the enumerability and security of behavior boundaries.

[0129] S138c, if the identifier of the tool to be invoked exists in the tool invocation whitelist, then the knowledge base index identifier is injected as a retrieval constraint parameter into the local retrieval tool corresponding to the identifier of the tool to be invoked.

[0130] Search constraint parameters refer to the filtering conditions used to limit the scope of the search tool's query, while local search tools refer to the local modules that actually perform database query operations.

[0131] Once the tool call is permitted, the local device does not perform an indiscriminate search across the entire local knowledge base. Instead, it extracts the knowledge base index identifier from the skill package configuration file and injects it as a mandatory filtering condition into the local search tool to be executed. This ensures that subsequent search actions are limited to the knowledge subset slice corresponding to the current diagnostic scenario, preventing the retrieval of information from other vehicle series or irrelevant systems.

[0132] S138d, based on a local retrieval tool, retrieves the target query statement in the vector index knowledge base and structured knowledge base corresponding to the knowledge base index identifier, and obtains multiple candidate knowledge fragments.

[0133] The local retrieval tool performs the aforementioned vectorization and structured matching within a constrained, specific knowledge base subspace.

[0134] Since the search scope is limited by the knowledge base index identifier in the skill package configuration file, the local device does not need to perform traversal calculations in the entire knowledge base, which reduces the scale of vector calculations and the scope of structured queries, thereby significantly reducing the computational pressure on the client side and improving the relevance and accuracy of the search results.

[0135] By selecting the skill package configuration file to load before requesting a question and answer, and verifying the tool call whitelist and injected knowledge base index identifier as constraint parameters during the retrieval process, local devices can flexibly switch between tenants or vehicle series without redeploying the complete model weights, reducing the deployment cost of local devices. Simultaneously, by binding the tool sandbox and knowledge index, the scope of tool calls and knowledge retrieval boundaries are effectively limited, avoiding unauthorized calls and cross-scenario data pollution, ensuring the professionalism, security, and interpretability of responses in the offline diagnostic environment.

[0136] Furthermore, to ensure compatibility between local knowledge subsets and skill pack configuration files, the local device maintains an end-side deployment list and performs consistency checks during over-the-air (OTA) updates. If a mismatch is detected between the knowledge subset version and the currently activated skill pack, activation will be rejected and the system will revert to the default configuration.

[0137] On resource-constrained and completely offline local devices, lightweight models have a small parameter size. If users directly input their query text and search fragments, these models are prone to deviating from professional context, resulting in non-standard repair suggestions or even safety misrepresentations. Therefore, in one alternative approach, the skill pack configuration file also includes prompt word templates and domain role setting information.

[0138] Domain role setting information refers to descriptive text that defines the professional identity of the lightweight model in the current diagnostic scenario. For example, setting the model role as a high-voltage system certification technician for a specific new energy vehicle series. Prompt templates refer to pre-set structured instruction fragments for specific diagnostic scenarios, typically including safety prohibitions, operational constraints, and mandatory response constraints, such as a warning that a power-off procedure must be performed before handling high-voltage components. These configuration parameters are packaged in skill packs, allowing the same lightweight model to exhibit different domain-specific professional behaviors and safety boundaries by loading different skill packs without changing the model weights.

[0139] Accordingly, step S170 includes sub-steps S171 to S173: S171, construct system prompt instructions based on domain role setting information and prompt word templates.

[0140] The character setting text and prompt word template text in the skill pack are formatted and merged to form basic instructions for guiding the global behavior of the lightweight model before inference, thus completing the construction of system prompt instructions.

[0141] The local device parses the skill pack configuration file at runtime, concatenating the role settings with a template containing security prohibitions into a complete system-level prefix text. This system prompt clearly defines the professional language standards and safety red lines that the lightweight model must adhere to in this Q&A session, constraining the direction of lightweight model generation and reducing the probability of fabrication or omission of critical security items.

[0142] S172, according to the preset splicing order, the system prompt instructions, target knowledge fragments and natural language query text are spliced ​​into a target prompt word sequence.

[0143] The preset concatenation order refers to the structural arrangement rules pre-defined on the local device for organizing the input context of large models, typically in the order of main instructions, reference knowledge, and user questions. The target prompt word sequence is a standard input data stream generated after concatenation according to this order, which can be directly input into the lightweight model.

[0144] The local device places the aforementioned system prompt instructions at the beginning of the sequence, then splices together a high signal-to-noise ratio target knowledge fragment obtained after strict truncation and relevance sorting, and finally attaches the user's natural language query text.

[0145] This structured approach allows lightweight models to clearly distinguish between instruction constraints, reference materials, and core issues, thereby enabling efficient information utilization within a limited context window and forcing lightweight models to respond based on provided knowledge fragments, avoiding free divergence.

[0146] S173, input the target prompt word sequence into the lightweight model for inference in order to respond to the question-answering request.

[0147] The lightweight model generates natural language responses based on the input sequence of target prompts using a neural network for forward computation. During this process, because the system prompts include a mandatory-response constraint, the lightweight model must rely heavily on the content of the target knowledge fragment when generating its response, rather than calling upon its own internalized general parameter knowledge. For example, the lightweight model might generate specific inspection steps based on a fragment of a troubleshooting guide for a fault code, and attach an identifier for the knowledge fragment for tracing its origin.

[0148] This reasoning method based on structured cue word sequences can effectively suppress the generation of unfounded illusions on local devices with limited computing power, ensuring the professionalism, compliance, and explainability of the response content in offline scenarios.

[0149] On resource-constrained local devices, lightweight models, due to their smaller number of parameters, are prone to logical jumps or missing critical safety precautions if directly asked to output final diagnostic recommendations. Therefore, as an alternative approach, the prompt word template includes a thought chain guidance template, which includes pre-configured logical steps for reasoning.

[0150] A Chain of Thought (CoT) guidance template is a pre-built step-by-step diagnostic instruction structure on the device side, containing pre-configured logical steps of reasoning. These logical steps are typically set based on the experience of experts in the field of automotive diagnostics and safety specifications, and are arranged in the order of phenomenon, possible cause, suggested inspection items, and risk warnings.

[0151] By injecting this template into the prompt words, local devices can still force lightweight models to follow standard diagnostic thinking paths even under computing power constraints, avoiding the direct generation of assertions that are not fully validated.

[0152] Accordingly, step S173 includes sub-steps S173a~S173b: S173a, the thought chain guidance template and the target prompt word sequence are input into the lightweight model for reasoning, so that the lightweight model generates reasoning text corresponding to the logical steps in sequence according to the thought chain guidance template.

[0153] During the process of inputting the target cue word sequence into the lightweight model for reasoning, the local device inputs the thought chain guidance template and the target cue word sequence into the lightweight model for reasoning, so that the lightweight model can generate reasoning text corresponding to the logical steps in sequence according to the thought chain guidance template.

[0154] Among them, reasoning text refers to the intermediate reasoning step text generated by the lightweight model before generating the answer visible to the end user.

[0155] After receiving input containing a thought chain guidance template, the lightweight model does not output the final result all at once. Instead, it generates intermediate analysis content node by node according to the logical steps set in the template.

[0156] For example, a lightweight model first analyzes the fault phenomenon, then lists possible causes, followed by specific inspection suggestions, and finally generates risk warnings such as high-voltage power outages. These intermediately generated inference texts can be used for internal self-checking to ensure that key safety items are covered before the final recommendations are output, thereby reducing the probability of fabricated or missed detections.

[0157] S173b, responding to question-and-answer requests based on reasoned text.

[0158] After completing its internal step-by-step logical deduction, the lightweight model integrates the reasoning text from each step to generate the final natural language diagnostic suggestions for users.

[0159] In this stage, the lightweight model summarizes the possible causes and suggested checks analyzed in the preceding steps, and adds mandatory risk warnings and knowledge fragment references. Because the final response is generated step-by-step based on rigorous intermediate reasoning steps, rather than the free divergence of the lightweight model, its diagnostic recommendations are guaranteed in terms of professionalism and compliance.

[0160] By introducing a thought chain guidance template containing pre-configured logical steps into the prompt word template, the lightweight model is guided to generate intermediate inference text sequentially during inference and make the final response based on it. This effectively standardizes the inference path of the lightweight model in the offline environment without increasing the model parameter scale and computing power consumption. It enables the lightweight model to complete safety self-checks before output, reduces the risk of missing key diagnostic steps and safety prompts, and further improves the accuracy and rigor of responses of resource-constrained local devices in complex automotive repair scenarios.

[0161] In automotive repair settings, technicians' hands are often covered in oil and grease, and they may be working under lifts or during road tests, making touchscreen operation inconvenient. Therefore, voice interaction becomes the most natural method. However, the workshop environment is typically filled with complex noises such as air pump sounds and engine roars, and general speech recognition systems struggle to understand automotive repair terminology. To address this issue, in one optional approach, step S110 includes sub-steps S111~S114: S111 collects the user's raw voice stream data.

[0162] The local device acquires the voice signals emitted by the technician in real time through the built-in microphone or an external audio acquisition device.

[0163] Raw audio stream data refers to continuous analog or digital audio signals without any processing. In noisy workshop environments, this raw audio often contains a large amount of background noise. Due to the limited computing power of local devices, it is impossible to run the massive multi-channel array noise reduction algorithms used in the cloud. Therefore, during the acquisition stage, simple edge preprocessing algorithms are usually combined to perform preliminary energy filtering and noise reduction on the raw audio to ensure the audio quality of subsequent decoding and avoid system stuttering or a significant drop in recognition rate due to noise interference.

[0164] S112, Load the pre-configured vocabulary bias library for the automotive diagnostics domain.

[0165] Due to limitations in model size and computing power, edge-based automatic speech recognition models have poor recognition rates for automotive repair terminology (such as three-way catalytic converters, specific fault codes, and oxygen sensors). To improve the recognition rate of these specialized terms without increasing the number of language model parameters, the local device dynamically loads a pre-configured vocabulary bias library at runtime. This vocabulary bias library is a lightweight list of domain-specific hot words or language model bias parameters, containing high-frequency professional terms such as assembly names of common vehicle series, fault code rules, and names of specialized tools. By loading this bias library, the local device can guide the speech recognition model to prioritize matching automotive repair-related professional terms during decoding with minimal memory usage.

[0166] S113, decode the original speech stream data according to the vocabulary bias library to obtain the initial text sequence.

[0167] The edge-side speech recognition model converts the acoustic features of audio frames into text characters. In this process, the speech recognition model combines the acoustic model with a language model that has an embedded vocabulary bias library to perform probability calculations on the audio features.

[0168] When encountering syllables with unclear pronunciation or those that are easily confused, the lexical bias database increases the probability of outputting specialized terms, thereby accurately identifying the specialized vocabulary spoken by the technician.

[0169] For example, when a technician verbally describes a fault code, the speech recognition model can accurately output the code character, rather than outputting an unrelated Chinese character with a similar pronunciation. Ultimately, the speech recognition model outputs an initial text sequence containing the technician's colloquial expressions and technical terminology.

[0170] S114: Slot filling and intent classification are performed on the initial text sequence to generate natural language query text and scene context data.

[0171] Because technicians' spoken expressions often contain redundant information or unclear references, directly inputting large models can cause the retrieval and generation to deviate from the key points.

[0172] Slot filling refers to extracting key entities with clear business meaning from the initial text sequence through a lightweight natural language understanding model or rule engine, such as specific fault codes, system names, vehicle parts, etc. These extracted entities constitute part of the source of scenario context data; intent classification refers to analyzing the core purpose of the initial text sequence to determine whether the user wants to query the cause of the fault, find troubleshooting steps, or confirm the location of the part.

[0173] After slot filling and intent classification, the local device organizes the core questions (after removing redundancy) into natural language query text, and integrates the extracted key slot information with information such as vehicle identification codes automatically read by the local device into scene context data. These two elements together constitute a complete question-and-answer request, enabling subsequent rewriting and retrieval to directly utilize structured information, thus improving the efficiency and accuracy of edge processing.

[0174] By collecting voice stream data and loading a vocabulary bias library from the automotive diagnostics field for decoding, followed by slot filling and intent classification, structured natural language query text and contextual data are generated. This approach overcomes the challenges of complex workshop noise and low recognition rates of specialized vocabulary in general models on completely offline and computationally limited local devices. Through lightweight bias and intent processing, the colloquial voice input of technicians is transformed into high signal-to-noise ratio structured question-and-answer requests, providing an effective data foundation for subsequent large-scale model rewriting and retrieval, and ensuring the continuity and efficiency of diagnostic operations in network-free scenarios.

[0175] This application embodiment obtains a question-and-answer request and rewrites the natural language query text and scene context data to generate a target query statement that accurately reflects the user's true intent and the current scene state. Based on a preset vector index knowledge base and structured knowledge base, the target query statement is retrieved to obtain multiple candidate knowledge fragments. These fragments are then evaluated for relevance, resulting in a relevance score for each fragment. The fragments are ranked according to their relevance scores to extract the core knowledge fragments most relevant to the user's true intent and the current scene state from the local knowledge subset slices. Redundant and low-relevance noise data are removed, thereby reducing invalid data processing volume and lowering the cost of local devices under limited local resources. The computational power consumption is reduced; the ranked candidate knowledge fragments are truncated according to a preset input length limit threshold to obtain the target knowledge fragment, thereby controlling the context length input to the local large model. This improves the memory consumption surge and slow inference caused by long text input, thus preventing memory overflow, lag, or even system crashes on the local device; the target knowledge fragment and natural language query text are input into the locally pre-deployed lightweight model for inference to respond to question-answering requests. This allows the lightweight model to obtain high signal-to-noise ratio context references even when offline and under computationally limited conditions, thereby effectively suppressing the generation of unfounded illusions and ensuring the accuracy and professionalism of the response to user question-answering requests in scenarios without network or with weak network. This achieves good response to question-answering requests on resource-constrained local devices.

[0176] Figure 3 A schematic diagram of the structure of a local response device for question-and-answer requests provided in an embodiment of this application is shown. Figure 3 As shown, the local response device 200 for the question and answer request includes: an acquisition module 210, a rewriting module 220, a retrieval module 230, an evaluation module 240, a sorting module 250, a truncation module 260, and a processing module 270.

[0177] The acquisition module 210 is used to acquire question-and-answer requests, which include natural language query text and scene context data.

[0178] The rewriting module 220 is used to rewrite the natural language query text and scene context data to generate the target query statement.

[0179] The retrieval module 230 is used to retrieve the target query statement based on the preset vector index knowledge base and structured knowledge base, and obtain multiple candidate knowledge fragments.

[0180] The evaluation module 240 is used to evaluate the relevance of multiple candidate knowledge fragments and obtain a relevance score for each candidate knowledge fragment.

[0181] The sorting module 250 is used to sort multiple candidate knowledge fragments based on their relevance scores.

[0182] The truncation module 260 is used to truncate the sorted candidate knowledge fragments according to a preset input length limit threshold to obtain the target knowledge fragment.

[0183] The processing module 270 is used to input the target knowledge fragment and natural language query text into a locally pre-deployed lightweight model for inference in order to respond to question-answering requests.

[0184] The local response device 200 for question and answer requests provided in this application embodiment also includes a plurality of modules for performing each step of the local response method for the question and answer requests described above, which will not be described in detail here.

[0185] Figure 4 The diagram shows a schematic of the structure of an electronic device provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the electronic device 300.

[0186] like Figure 4 As shown, the electronic device 300 may include a processor 302 and a memory 304.

[0187] The memory 304 is used to store the computer program 306. The memory 304 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The computer program 306 may include computer-executable instructions.

[0188] The processor 302 is used to execute the computer program 306 to implement the local response method embodiment for the above-described question and answer request.

[0189] Processor 302 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Electronic device 300 may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0190] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned local response method embodiment for question-and-answer requests.

[0191] This application provides a computer program that can be executed by a processor to implement the above-described local response method for question-and-answer requests.

[0192] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned local response method for question-and-answer requests.

[0193] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, part or all of the technical solutions of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0194] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0195] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0196] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A local response method for a question-and-answer request, characterized in that, The method includes: Obtain a question-and-answer request, wherein the question-and-answer request includes natural language query text and scene context data; The natural language query text and the scene context data are rewritten to generate the target query statement; The target query statement is retrieved based on a preset vector index knowledge base and a structured knowledge base to obtain multiple candidate knowledge fragments; The relevance of the multiple candidate knowledge fragments is evaluated to obtain a relevance score for each candidate knowledge fragment; The candidate knowledge fragments are sorted according to the relevance scores. The sorted candidate knowledge fragments are truncated according to a preset input length limit threshold to obtain the target knowledge fragment; The target knowledge fragment and the natural language query text are input into a locally pre-deployed lightweight model for inference in order to respond to the question-answering request.

2. The method according to claim 1, characterized in that, The target query statement is retrieved based on a preset vector index knowledge base and a structured knowledge base, resulting in multiple candidate knowledge fragments, including: The target query statement is vectorized to obtain a query vector; The structured filtering conditions are determined based on the scene context data; The target retrieval subspace is determined from the vector index knowledge base based on the structured filtering conditions; Based on the query vector, a similarity search is performed within the target retrieval subspace to obtain a first retrieval result set; Parse the structured entities in the target query statement to obtain the query entity; Based on the query entity, a second search result set is obtained by searching the structured knowledge base. The first search result set and the second search result set are merged to generate the multiple candidate knowledge fragments; The relevance evaluation of the plurality of candidate knowledge fragments to obtain a relevance score for each candidate knowledge fragment includes: The similarity between the multiple candidate knowledge fragments and the target query statement is determined, and the relevance score of each candidate knowledge fragment is obtained.

3. The method according to claim 2, characterized in that, The process of determining the similarity between the plurality of candidate knowledge fragments and the target query statement, and obtaining a relevance score for each candidate knowledge fragment, includes: The similarity between the multiple candidate knowledge fragments and the target query statement is determined, and the relevance score of each candidate knowledge fragment and the confidence level of the relevance score are obtained. After sorting the plurality of candidate knowledge fragments according to the relevance score, the method further includes: If the confidence score of the relevance score of each candidate knowledge fragment is lower than the preset confidence threshold, then the intent of the question-and-answer request is identified to obtain intent information. The response requirement type for the question-and-answer request is determined based on the intent information; If the response request type is external real-time data dependent, an offline synchronization task is generated, wherein the offline synchronization task contains the identification information of the question and answer request, which is used to obtain real-time data from the cloud and generate a response based on the identification information when the network parameters meet the preset conditions; If the response request type is non-real-time data dependent, the response will be based on preset heuristic rules.

4. The method according to claim 1, characterized in that, After rewriting the natural language query text and the scene context data to generate the target query statement, the method further includes: If the target query statement is retrieved based on the preset vector index knowledge base and structured knowledge base, and no candidate knowledge fragment is found, then the intent of the question-and-answer request is identified to obtain intent information. The response requirement type for the question-and-answer request is determined based on the intent information; If the response request type is external real-time data dependent, an offline synchronization task is generated, wherein the offline synchronization task contains the identification information of the question and answer request, which is used to obtain real-time data from the cloud and generate a response based on the identification information when the network parameters meet the preset conditions; If the response request type is non-real-time data dependent, the response will be based on preset heuristic rules.

5. The method according to claim 1, characterized in that, Prior to obtaining the question-and-answer request, the method further includes: In response to the selected diagnostic scenario, a skill package configuration file corresponding to the diagnostic scenario is loaded, wherein the skill package configuration file includes a knowledge base index identifier and a tool call whitelist; The target query statement is retrieved based on a preset vector index knowledge base and a structured knowledge base, resulting in multiple candidate knowledge fragments, including: The question-and-answer request is parsed to generate a target tool invocation instruction, wherein the target tool invocation instruction contains an identifier of the tool to be invoked; Verify whether the identifier of the tool to be invoked exists in the tool invocation whitelist; If the identifier of the tool to be invoked exists in the tool invocation whitelist, then the knowledge base index identifier is injected as a retrieval constraint parameter into the local retrieval tool corresponding to the identifier of the tool to be invoked; Based on the local retrieval tool, the target query statement is retrieved in the vector index knowledge base and structured knowledge base corresponding to the knowledge base index identifier, resulting in multiple candidate knowledge fragments.

6. The method according to claim 5, characterized in that, The skill pack configuration file also includes prompt word templates and domain role setting information; The step of inputting the target knowledge fragment and the natural language query text into a locally pre-deployed lightweight model for inference to respond to the question-answering request includes: Based on the domain role setting information and the prompt word template, construct system prompt instructions; According to the preset splicing order, the system prompt instruction, the target knowledge fragment, and the natural language query text are spliced ​​into a target prompt word sequence; The target prompt word sequence is input into the lightweight model for inference in order to respond to the question-and-answer request.

7. The method according to claim 6, characterized in that, The prompt word template includes a thought chain guidance template, which includes pre-configured logical steps for reasoning; The step of inputting the target prompt word sequence into the lightweight model for inference to respond to the question-answering request includes: The thought chain guidance template and the target prompt word sequence are input into the lightweight model for reasoning, so that the lightweight model generates reasoning text corresponding to the logical steps in sequence according to the thought chain guidance template; Based on the reasoning text, respond to the question-and-answer request.

8. The method according to claim 1, characterized in that, The request to obtain question answers includes: Collect users' raw voice stream data; Load a pre-configured vocabulary bias library for the automotive diagnostics field; The original speech stream data is decoded according to the vocabulary bias library to obtain an initial text sequence; The initial text sequence is filled with slots and classified for intent to generate the natural language query text and the scene context data.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the local response method for question-and-answer requests as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the local response method for question-and-answer requests as described in any one of claims 1 to 8.

Images