Vehicle-mounted voice scheduling method and system and computer readable storage medium

Abstract

The invention provides a vehicle-mounted voice scheduling method and system and a computer readable medium, and relates to the technical field of voice interaction, and the method comprises the steps: receiving voice interaction information, sent by a vehicle-mounted terminal, of a user in a current voice interaction round; performing intention recognition classification on the voice interaction information to obtain at least two types of user intentions; inputting the at least two types of user intentions into corresponding scheduling modules in parallel to obtain an intention feedback result; and performing dynamic decision on the intention feedback result asynchronously output by each scheduling module so as to determine the scheduling mode of the intention feedback result to the vehicle-mounted terminal. According to the method, a parallel scheduling mode is adopted, heterogeneous requests such as navigation, weather and content generation can be responded at the same time in one-time voice interaction, the limitation of a traditional serial architecture is broken through, and the response speed during vehicle-mounted voice interaction is remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of voice interaction technology, and more specifically, to an in-vehicle voice dispatching method, system, and computer-readable medium. Background Technology

[0002] With the rapid development of artificial intelligence, in-vehicle voice assistants have become the central hub for intelligent interaction in vehicles. During voice interaction, users use large models to query and answer their questions.

[0003] However, existing voice systems generally adopt a serial processing architecture, requiring users to speak one sentence and wait for another. If a sentence contains multiple intentions, they also need to be queued and processed one by one by a large model before voice feedback is provided, resulting in long waiting times, response delays, and a poor user experience. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide an in-vehicle voice dispatching method, system and computer-readable medium to improve the response speed of voice interaction.

[0005] Firstly, a vehicle-mounted voice dispatching method is provided, applied to a cloud server, including: Receive user voice interaction information in the current voice interaction round sent by the vehicle terminal; Perform intent recognition and classification on voice interaction information to obtain at least two categories of user intent; At least two categories of user intents are input in parallel into the corresponding scheduling modules to obtain intent feedback results. Each scheduling module is configured to autonomously call the corresponding downstream service interface for the user intent it receives to generate intent feedback results. Dynamic decisions are made based on the asynchronous intent feedback results output by each scheduling module to determine the scheduling method to the vehicle terminal.

[0006] Optionally, the voice interaction information is subjected to intent recognition and classification to obtain at least two categories of user intents, including: Semantically segment the voice interaction information into multiple clauses; Named entity recognition is performed on each clause to obtain several named entities; Each clause and its corresponding named entity are input into a pre-trained intent recognition model to obtain an initial intent candidate set containing confidence scores. The initial intent candidate set is preprocessed to obtain user intents of at least two categories; each user intent includes an intent category label, an entity slot, and a target scheduling module identifier.

[0007] Optionally, preprocessing the initial intent candidate set to obtain user intents of at least two categories includes: The confidence level of each user intent in the initial intent candidate set is compared with a preset confidence threshold. Filter user intents with a confidence level lower than a preset confidence threshold; Based on semantic similarity, the filtered user intents are merged or deduplicated to obtain user intents of at least two categories.

[0008] Optionally, the scheduling module includes at least: a vehicle control scheduling module, a service query scheduling module, a creative intent scheduling module, a knowledge retrieval scheduling module, a data recognition module, and a quick reply module; The vehicle control and dispatch module is configured to generate standardized vehicle control commands based on the intents of vehicle control users; The service query scheduling module is configured to dynamically route to the corresponding service interface based on the user intent of the service query, and receive the intent feedback result returned by the service interface; The creative intent scheduling module is configured to construct restricted prompts based on creative intent and call a large language model to generate intent feedback results; creative intent includes at least character imitation and creative writing; The knowledge retrieval scheduling module is configured to retrieve factual answers based on retrieval intent using a structured knowledge base; The identification module is configured to output a rejection signal to prevent subsequent scheduling based on invalid, ambiguous, or non-operational user intents. The quick reply module is configured to generate intent feedback results based on preset reply templates for request intents that exceed the system's capabilities.

[0009] Optionally, the service query scheduling module includes a third-party domain landing module; the method also includes: When the user intent is a service query intent, determine whether the user intent includes a third-party application name entity; If included, the user's intent is input into the third-party domain matching module. The third-party domain matching module is configured to match the third-party application name entity based on a preset third-party application whitelist. If the match is successful, the corresponding third-party application interface is called to execute the service request. If the match fails, a prompt message is returned indicating that the third-party application is not yet supported, and the third-party application name entity is updated to the preset third-party application whitelist.

[0010] Optionally, the service query scheduling module also includes a standard service module and a customized domain module; if the user's intent is a service query intent and does not include a third-party application name entity, the method further includes: Determine the query category based on the user's intent. Query categories include factual query intent and subjective query intent. If the intent is factual, the user intent is input into the standard service module. The standard service module is configured to identify the service category based on the user intent and call the corresponding local or third-party service interface based on the service category to generate factual service query results. If the query intent is subjective, the user intent is input into the customized domain module. The customized domain module is configured to perform retrieval enhancement based on a preset service knowledge base and call the large language model to generate subjective service query results.

[0011] Optionally, before performing intent recognition and classification on the voice interaction information, the method further includes: The voice interaction information is matched using a pre-defined regular expression, which contains sensitive keywords. If a match is found, the voice interaction information is intercepted and a preset error code is returned.

[0012] Optionally, dynamic decision-making is performed on the asynchronous intent feedback results output by each scheduling module to determine the scheduling method to the vehicle terminal, including: Receive the intent feedback results asynchronously output by each scheduling module; For each newly arrived intent feedback result, its scheduling method is determined based on preset decision rules; the decision rules include at least: If the intent feedback result does not contain valid semantics, the result is discarded and not sent to the vehicle terminal; If there is no ongoing voice broadcast, the intent feedback result will be immediately sent to the vehicle terminal for broadcast. If an intent feedback result is already being broadcast, then the priority of the newly arrived intent feedback result is compared with that of the currently broadcast intent feedback result: If the newly arrived intent feedback result has a higher priority, the current broadcast is interrupted and the newly arrived intent feedback result is sent to the vehicle terminal; otherwise, the newly arrived intent feedback result is temporarily stored in the broadcast queue and sent in order of priority after the current broadcast is completed.

[0013] Secondly, an in-vehicle voice dispatch system is provided, including an in-vehicle terminal and a cloud server; the cloud server includes a receiving module, an intent recognition module, multiple dispatch modules and a decision module; The in-vehicle terminal is used to detect voice interaction information and upload it to the cloud server; The receiving module is used to receive the user's voice interaction information in the current voice interaction round sent by the vehicle terminal; The intent recognition module is used to classify and identify the intent of voice interaction information to obtain at least two categories of user intent; Each scheduling module is used to autonomously call the corresponding downstream service interface for the user intent it receives and generate intent feedback results; The decision module is used to make dynamic decisions on the intent feedback results asynchronously output by each scheduling module in order to determine the scheduling method to the vehicle terminal.

[0014] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements any of the methods of the first aspect.

[0015] This invention provides an in-vehicle voice scheduling method, system, and computer-readable medium. The method involves receiving voice interaction information from a user in the current voice interaction round, sent by an in-vehicle terminal; classifying the voice interaction information by intent recognition to obtain at least two categories of user intents; inputting these at least two categories of user intents in parallel into corresponding scheduling modules to obtain intent feedback results; and dynamically deciding on the asynchronous intent feedback results output by each scheduling module to determine the scheduling method to the in-vehicle terminal. This invention employs a parallel scheduling approach, enabling simultaneous responses to heterogeneous requests such as navigation, weather, and content generation within a single voice interaction, overcoming the limitations of traditional serial architectures and significantly improving the response speed during in-vehicle voice interaction.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of the structure of the in-vehicle voice dispatch system provided in an embodiment of the present invention is shown; Figure 2 A flowchart of an in-vehicle voice dispatching method provided by an embodiment of the present invention is shown; Figure 3 A schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of the present invention is shown. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0020] Given that existing voice systems generally adopt a serial processing architecture, users need to speak a sentence and wait for each sentence to be processed. If a sentence contains multiple intentions, they also need to be queued and processed by a large model before voice feedback is provided. This results in long waiting times, response delays, and a poor user experience.

[0021] Based on this, embodiments of the present invention provide an in-vehicle voice dispatching method, which is applied to an in-vehicle voice dispatching system, such as... Figure 1 As shown, the system includes an in-vehicle terminal 100 and a cloud server 200; The vehicle-mounted terminal 100 is used to detect voice interaction information and upload it to the cloud server.

[0022] In this embodiment of the invention, the vehicle terminal 100 includes a wake-word listener, a microphone, an audio player, and a communication module.

[0023] The microphone is used to collect the user's voice input; the wake word listener is used to continuously listen for preset wake words (such as "Xiaoqi, Xiaoqi"); when the wake word is detected, the voice acquisition process is triggered, and the microphone is activated to obtain the user's subsequent voice content.

[0024] The collected speech is converted into text by the Automatic Speech Recognition (ASR) engine in the vehicle terminal, forming voice interaction information, and then uploaded to the cloud server via the communication module. The vehicle terminal then receives the intent feedback result returned by the cloud server, converts the result into audio through a text-to-speech (TTS) engine, and plays it through an audio player.

[0025] In a single voice interaction round, if the duration of continuous silence exceeds a preset pause threshold (e.g., 2 seconds), the current voice input is determined to have ended, and the multiple consecutive sentences contained in the voice segment are uniformly converted into the corresponding text form and sent to the cloud server as the complete voice interaction information for this round.

[0026] In this embodiment of the invention, the cloud server 200 includes a receiving module 201, an intent recognition module 202, multiple scheduling modules 203, and a decision module 204.

[0027] The receiving module 201 is used to receive the user's voice interaction information in the current voice interaction round sent by the vehicle terminal; The intent recognition module 202 is used to classify and recognize the intent of voice interaction information to obtain at least two categories of user intent; Each scheduling module 203 is used to autonomously call the corresponding downstream service interface for the user intent it receives, and generate intent feedback results.

[0028] In this embodiment of the invention, the scheduling module 203 includes at least a vehicle control scheduling module 2031, a service query scheduling module 2032, a creative intent scheduling module 2033, a knowledge retrieval scheduling module 2034, a data recognition module 2035, and a quick reply module 2036. The vehicle control and dispatch module is configured to generate standardized vehicle control commands based on the intents of vehicle control users.

[0029] In one example, if the user says "open the driver's side window", the module generates the CAN bus command "WINDOW_DRIVER_OPEN" and then sends the command to the vehicle control unit without generating voice feedback.

[0030] The service query scheduling module is configured to dynamically route to the corresponding service interface based on the user intent of the service query, and receive the intent feedback result returned by the service interface.

[0031] For example, if a user asks, "Are there any coffee shops nearby with a rating of 4.8 or higher?", the module will call the in-vehicle map API to get a list of Points of Interest (POIs) and generate feedback text: "There is a Starbucks 300 meters ahead, with a rating of 4.9".

[0032] The creative intent scheduling module is configured to construct restricted prompts based on creative intent and call a large language model to generate intent feedback results; creative intent includes at least character imitation and creative writing.

[0033] For example, if a user says, "Write a poem about autumn in the style of Li Bai," the module will construct a prompt, "Please imitate Li Bai's unrestrained and elegant style and create a five-character quatrain with the theme of climbing a mountain in autumn," and call the large language model to generate the poem text as feedback.

[0034] The knowledge retrieval scheduling module is configured to retrieve factual answers based on retrieval intent using a structured knowledge base.

[0035] For example, if a user asks "What era did Cao Cao live in?", the module will retrieve "Eastern Han Dynasty" from a pre-built historical knowledge base and return a concise and authoritative factual answer.

[0036] The identification module is configured to output a rejection signal to prevent subsequent scheduling based on invalid, ambiguous, or non-operational user intents.

[0037] For example, if a user says, "I loved playing this game when I was little," the module determines that there is no clear intention to operate, outputs a rejection signal, and the system remains silent or only responds with a light reassuring word (such as "I'm here"), without triggering any service calls or content generation.

[0038] The quick reply module is configured to generate intent feedback results based on preset reply templates for request intents that exceed the system's capabilities.

[0039] For example, if a user says, "Book me a flight to Beijing," the module matches a pre-set template and returns a standardized reply: "Sorry, I cannot book a flight for you, but I can check flight information for you."

[0040] The decision module 204 is used to make dynamic decisions on the intent feedback results asynchronously output by each scheduling module in order to determine the scheduling method to the vehicle terminal.

[0041] This invention improves the immediacy of voice interaction by routing different intents in parallel to the corresponding scheduling modules (such as standard services, fact retrieval, generative intents, etc.), thereby enabling voice scheduling for service queries, knowledge Q&A, and content generation in parallel.

[0042] The following is a description through examples.

[0043] This invention provides a vehicle-mounted voice dispatching method, applied to a cloud server, such as... Figure 2 As shown, it includes the following steps: Step S201: Receive the user's voice interaction information in the current voice interaction round sent by the vehicle terminal.

[0044] For example, after a user wakes up, they might say, "Are there any good restaurants nearby? Also, check the weather forecast for Hefei tomorrow, and tell me a poem by Li Bai." After detecting continuous silence for more than 2 seconds, the in-vehicle terminal converts the entire speech into text using ASR and uploads it to the cloud.

[0045] Step S202: Perform intent recognition and classification on the voice interaction information to obtain at least two categories of user intent.

[0046] Following the previous example, the system identified three independent intents: Intent A: Service query intent (food POI search); Intent B: Service query intent (weather query); Intention C: Creative intention (stylized poetry creation).

[0047] Step S203: Input at least two categories of user intents in parallel into the corresponding scheduling module to obtain intent feedback results.

[0048] Each scheduling module is configured to autonomously invoke the corresponding downstream service interface in response to the user intent it receives, and generate intent feedback results.

[0049] Following the previous example, intent A is input to the service query scheduling module, which calls the vehicle's built-in map API and returns a structured list of POIs with a rating of 4.5 or higher for nearby Sichuan restaurants. Intent B is input to the service query scheduling module, which calls the weather API and returns "Hefei will be cloudy tomorrow, with temperatures ranging from 18 to 25 degrees Celsius". Intent C is input to the creative intent scheduling module, which constructs the prompt "Write a five-character quatrain about autumn in the style of Li Bai" and calls the large language model to generate the poem text.

[0050] In this step, each scheduling module executes independently and asynchronously without blocking each other, and each autonomously completes downstream service calls or content generation, outputting its own intent feedback results, effectively improving voice scheduling efficiency.

[0051] Step S204: Make dynamic decisions on the intent feedback results asynchronously output by each scheduling module to determine the scheduling method to the vehicle terminal.

[0052] User intents may be invalid or conflicting. Therefore, this step involves dynamic decision-making on the feedback results of each intent to ensure that they are effectively and orderly invoked to the vehicle terminal.

[0053] The embodiments of the present invention adopt a parallel scheduling method, which can simultaneously respond to heterogeneous requests such as navigation, weather, and content generation in a single voice interaction, breaking through the limitations of the traditional serial architecture and significantly improving the response speed during in-vehicle voice interaction.

[0054] Based on the above embodiments, the voice interaction information is classified by intent recognition to obtain at least two categories of user intent, including: Step S202A: Semantically segment the voice interaction information into multiple clauses.

[0055] In one feasible implementation, the voice interaction information can be segmented into multiple clauses based on punctuation, semantic coherence, and pause features (such as silence intervals).

[0056] In one example, a user might say after waking up, "Any good food nearby? Also, check the weather in Hefei tomorrow, and tell me a poem by Li Bai."

[0057] Based on punctuation, semantic coherence, and pause features (such as silence intervals), the long sentence is automatically segmented into three semantically independent clauses: Clause 1: "Where are some good places to eat nearby?" Clause 2: "While you're at it, check the weather forecast for Hefei tomorrow." Clause 3: "Tell me another poem by Li Bai." Step S202B: Perform named entity recognition on each clause to obtain several named entities.

[0058] In this embodiment of the invention, named entities refer to words or phrases in text that have specific meanings or refer to real-world objects. Common types include: location entities (such as "Hefei" and "Huangshan"); time entities (such as "tomorrow" and "3 PM"); person entities (such as "Li Bai" and "Jay Chou"); and application entities (such as "QQ Music" and "Gaode Maps"). Named entities are key clues for intent understanding and are used to fill subsequent entity slots.

[0059] Continuing from the previous example, named entity recognition is performed on each of the three clauses above: Clause 1 identifies the implicit location entity "nearby" (considered as the current location); Clause 2 identifies the time entity "tomorrow" and the location entity "Hefei"; Clause 3 identifies the person entity "Li Bai".

[0060] Step S202C: Input the identified named entities into the pre-trained intent recognition model to obtain an initial intent candidate set containing confidence scores.

[0061] Intent recognition models are a type of deep learning model that can employ techniques such as Transformer and BiLSTM-CRF. Their training process involves iterative training using named entities labeled with intent tags, which will not be elaborated upon here.

[0062] This intent recognition model can predict the intent category of a user's statement. Its output is a confidence score (between 0 and 1) for each intent category, reflecting the reliability of the model's judgment of that intent.

[0063] Specifically, each clause and its corresponding named entity are taken as input and fed into a pre-trained multi-label intent classification model, which outputs the intent probability distribution of each clause, continuing from the previous example: Clause 1 outputs candidate intents: {Service Query: 0.92, Casual Chat: 0.08}; Clause 2 outputs candidate intents: {Service Query: 0.89, Fact Retrieval: 0.11}; Clause 3 outputs candidate intents: {Creative intent: 0.95, Fact retrieval: 0.05}.

[0064] The candidate intentions of each clause and their respective confidence levels are combined to form an initial intention candidate set.

[0065] It should be noted that a clause can correspond to multiple intentions, for example, "Help me find good Sichuan restaurants nearby and the weather for tomorrow."

[0066] This step combines named entity recognition with deep learning intent models to enhance semantic understanding by leveraging entity context, significantly reducing ambiguity and misjudgment, such as distinguishing between "who is Li Bai" (fact retrieval) and "imitating Li Bai to write poetry" (creative intent).

[0067] Step S202D: Preprocess the initial intent candidate set to obtain user intents of at least two categories; each user intent includes an intent category label, an entity slot, and a target scheduling module identifier.

[0068] In this embodiment of the invention, entity slots refer to the fields to be filled in the extracted named entities, used to structurally represent user needs. For example, in the "check the weather" intent, typical slots include location and time; in the "play music" intent, slots may include artist, song title, etc. Slot filling serves as a bridge connecting natural language and service calls.

[0069] Continuing from the previous example, the intent output format for the three clauses is as follows: {meaning Figure 1 :"Service Query", Entity Slot:{query_type:"Food",location:"Nearby"},module:"Service Query Scheduling Module"}; {meaning Figure 2 :"Service Query",slots:{query_type:"Weather",location:"Hefei",time:"Tomorrow"},module:"Service Query Scheduling Module"}; {meaning Figure 3 :"Creative Intent",slots:{style:"Li Bai Style",topic:"Poetry"},module:"Creative Intent Scheduling Module"}.

[0070] By binding slot filling with module identifiers, standardized input is provided for subsequent parallel scheduling, ensuring that each scheduling module can accurately parse user requirements and call the corresponding services.

[0071] This invention utilizes semantic segmentation technology to effectively parse the complex semantic content expressed by users in single-turn voice interactions. It not only supports the identification of multiple intentions implicit within the same clause but also the accurate splitting and classification of multiple independent intentions distributed across clauses. This mechanism significantly improves the concurrency and response efficiency of voice scheduling, avoiding the intention omission or latency accumulation problems of traditional serial processing modes. Therefore, while ensuring driving safety, it provides users with a smoother, more efficient, and natural multi-tasking voice interaction experience.

[0072] Based on the above embodiments, preprocessing the initial intent candidate set to obtain at least two categories of user intents includes: Step S202D1: Compare the confidence level of each user intent in the initial intent candidate set with a preset confidence threshold.

[0073] Step S202D2: Filter user intents with confidence levels below the preset confidence threshold.

[0074] In one example, the preset confidence threshold is 0.85. After filtering based on the threshold: Clause 1 retains "Service Inquiry" (0.92 ≥ 0.85) and removes "Casual Chat" (0.08 < 0.85); Clause 2 retains "Service Inquiry" (0.87 ≥ 0.85) and removes "Fact Retrieval" (0.13 < 0.85); Clause 3 retains "creative intent" (0.95 ≥ 0.85) and removes "fact retrieval" (0.05 < 0.85).

[0075] Step S202D3: Merge or deduplicate the filtered user intents based on semantic similarity to obtain user intents of at least two categories.

[0076] In this step, cosine similarity can be used to compare the similarity of the filtered user intents.

[0077] For example, if a user says "Check nearby restaurants" and "What are some good places to eat nearby" in succession, both are identified as "service query" intents, and the semantic similarity is 0.96, which is higher than the preset deduplication threshold of 0.9. In this case, they are merged into a single intent to avoid duplicate scheduling. In the example above, the three intents belong to different categories (service query ×2, generative intent ×1), but the two "service query" intents have a semantic similarity of only 0.35 because the query objects are different (food vs. weather), so they are not merged and three independent intents are retained in the end.

[0078] This invention effectively filters low-quality or ambiguous intents by setting a confidence threshold, preventing invalid intents from entering the scheduling process and reducing system resource waste and the risk of erroneous responses. Furthermore, it merges similar intents based on semantic similarity, eliminating intent duplication caused by redundant user statements or repeated questions, avoiding multiple calls to the same service interface, saving cloud computing resources and network bandwidth, and improving scheduling efficiency.

[0079] Based on the above embodiments, the service query scheduling module includes a third-party domain landing module, a standard service module, and a customized domain landing module. Domain landing is an industry term in the Chinese context (especially in fields such as intelligent voice, large models, and in-vehicle interaction). Its core meaning can be understood as: landing user intent or requests into a preset, controlled business domain or processing path.

[0080] The method also includes: Step S205: When the user intent is a service query intent, determine whether the user intent includes a third-party application name entity.

[0081] For example, a user's voice might say, "Use Amap to navigate to station A" or "Play Jay Chou's 'Seven Mile Fragrance' via QQ Music." Named entity recognition detected explicit third-party application name entities such as "Amap" and "QQ Music."

[0082] Step S206: If included, input the user intent into the third-party domain module.

[0083] The third-party domain matching module is configured to match the third-party application name entity based on a preset third-party application whitelist. If the match is successful, the corresponding third-party application interface is called to execute the service request. If the match fails, a prompt message is returned indicating that the third-party application is not yet supported, and the third-party application name entity is updated to the preset third-party application whitelist.

[0084] In one example, if "Gaode Maps" is in the whitelist, the match is successful, and the Gaode Maps SDK is invoked to start navigation.

[0085] If a user says "play Rice Fragrance with Soft Music", but "Soft Music" is not in the third-party whitelist, the match will fail and the system will return the message: "Sorry, this service is not currently supported." At the same time, the system will record "Soft Music" as a new candidate entity and update it to the third-party application whitelist after security review in the background for future iterations.

[0086] This invention implements secure access for third-party applications through a whitelist mechanism. When a match fails, it only prompts "not supported" rather than executing an error. Newly added application entities can be automatically collected, reviewed, and added to the database, supporting continuous system evolution.

[0087] If the user intent is a service query intent and does not include a third-party application name entity, the method further includes the following steps: Step S207: Determine the query category of the user's intent.

[0088] The query categories include factual query intent and subjective query intent.

[0089] Factual query intent: The goal is to obtain objective, structured, and verifiable information. It usually contains words such as "search", "have", "how much", "whether" and the parameters are clear (such as location, time). Subjective query intent: The goal is to obtain recommendations, ratings, lists, or stylized descriptions, which usually include subjective expressions such as "recommended", "best", "unique", "favorite", "like..."

[0090] Example categories: "Where are the nearest gas stations?" is a factual statement. Judging what's good to eat in Hefei is rather subjective. "Which coffee shops nearby have a rating of 4.8 or higher?" → Although it includes ratings, it is essentially an objective selection and can be categorized as factual. The implicit preference judgment of "where is the best place to take the child to play" can be classified as subjective.

[0091] Step S208: If it is a fact-based query intent, then input the user intent into the standard service module.

[0092] The standard service module is configured to identify service categories based on user intent and call the corresponding local or third-party service interfaces based on the service category to generate factual service query results.

[0093] In one example, service categories include, for instance, media, navigation, food, weather, stocks, classical poetry, or flights.

[0094] Local or third-party service interfaces include, for example, map APIs, music players, and third-party content platforms. Third-party service interfaces refer to applications that are on the third-party application whitelist. Local service interfaces are those built into the vehicle at the factory.

[0095] Step S209: If it is a subjective query intent, then input the user intent into the customized domain module.

[0096] The customized domain module is configured to enhance retrieval based on a preset service knowledge base and call a large language model to generate subjective service query results.

[0097] This invention further divides the service query scheduling module into scheduling modules for three scenarios, thereby achieving refined identification of service query intent, intelligent traffic diversion, and scenario-based response, and improving the accuracy of voice scheduling.

[0098] Based on the above embodiments, before performing intent recognition and classification on the voice interaction information, the method further includes: Step S210: Perform regular expression matching on the voice interaction information based on a preset regular expression, where the regular expression contains sensitive information keywords.

[0099] Step S211: If the match is successful, intercept the voice interaction information and return the preset error code.

[0100] Upon receiving the error code, the vehicle terminal can play a standardized prompt: "Sorry, your request contains non-compliant content and cannot be processed."

[0101] The embodiments of the present invention perform sensitive content filtering before intent recognition, large model invocation, or service scheduling, effectively preventing illegal and harmful information, privacy data, or malicious instructions from entering the core processing link of the system, thus ensuring the security of the voice interaction process.

[0102] Based on the above embodiments, dynamic decision-making is performed on the asynchronous intent feedback results output by each scheduling module to determine the scheduling method to the vehicle terminal, including: Step S204A: Receive the intent feedback results asynchronously output by each scheduling module; Step S204B: For each newly arrived intent feedback result, determine its scheduling method based on preset decision rules.

[0103] Decision-making rules should include at least: If the intent feedback result does not contain valid semantics, the result is discarded and not sent to the vehicle terminal.

[0104] For example, if a user enters "Oh, I loved playing this game when I was little," and the intent feedback result is a recognized signal, it means that the statement is casual conversation and has no valid intent.

[0105] If there is no ongoing voice broadcast, the intent feedback result will be immediately sent to the vehicle terminal for broadcast.

[0106] When the system detects that the feedback comes from the vehicle control and dispatch module (such as "open the window"), it does not generate any voice broadcast, but only sends control commands to the vehicle bus for silent execution to avoid interfering with the driver's attention.

[0107] Process intent feedback results that do not require silent execution. If there is no ongoing voice broadcast, immediately send the intent feedback result to the vehicle terminal for broadcast.

[0108] If an intent feedback result is already being broadcast, then the priority of the newly arrived intent feedback result is compared with that of the currently broadcast intent feedback result: If the newly arrived intent feedback result has a higher priority, the current broadcast is interrupted and the newly arrived intent feedback result is sent to the vehicle terminal; otherwise, the newly arrived intent feedback result is temporarily stored in the broadcast queue and sent in order of priority after the current broadcast is completed.

[0109] In one example, assuming the weather forecast arrives first and there is no broadcast task at this time, the system immediately sends it to the vehicle terminal, and the TTS engine begins to broadcast: "Hefei will be cloudy tomorrow, with temperatures ranging from 18 to 25 degrees Celsius."

[0110] High priority interruption: Subsequently, the feedback results from the food search arrive; compare the priorities of the two: Weather (current report): Priority = 8; Food (New Arrival): Priority = 5; Since 5 < 8, the food results will not be interrupted; they will be temporarily stored in the waiting queue.

[0111] Ordered broadcasting in queues: After the weather broadcast ends, the system retrieves the food results from the queue to be broadcast, sorts them by priority, and sends them to the vehicle terminal to broadcast: "There is a Starbucks 300 meters ahead, rating 4.9."

[0112] If a higher priority result is added at this time (such as an emergency vehicle condition alert: "abnormal tire pressure"), the current broadcast will be interrupted immediately, and the higher priority message will be processed first.

[0113] This invention employs a streaming, asynchronous, rule-based dynamic decision-making mechanism to intelligently schedule multi-intent feedback results. Broadcasting can begin without waiting for all results to complete, significantly reducing end-to-end response latency. This is particularly suitable for scenarios where long-tail generation tasks (such as poetry creation) and short, fast services (such as weather) coexist. Priority comparison and interruption mechanisms ensure that highly timely and secure information (such as vehicle status alerts and navigation changes) can be promptly inserted, avoiding obstruction by low-priority content and improving driving safety. Furthermore, the introduction of a broadcast queue and priority sorting prevents simultaneous broadcasting of multiple results from causing voice overlap or confusion, achieving low-latency, high-priority, zero-interference, and orderly output.

[0114] The computer-readable storage medium 300 for the vehicle-mounted voice dispatching method provided in this embodiment of the invention, such as... Figure 3 As shown, the method includes a computer program 301, which includes instructions that can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0115] The vehicle-mounted voice dispatch system provided in this embodiment of the invention can be specific hardware on a device or software or firmware installed on the device. The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiments. For the sake of brevity, any parts not mentioned in the system embodiments can be referred to the corresponding content in the aforementioned method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, units, and processes described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0116] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces. Indirect couplings or communication connections between systems or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional units in the embodiments provided by the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0119] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, 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 network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0121] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. All should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A vehicle-mounted voice dispatching method, characterized in that, Applications to cloud servers include: Receive user voice interaction information in the current voice interaction round sent by the vehicle terminal; The voice interaction information is subjected to intent recognition and classification to obtain at least two categories of user intent; The user intents of at least two categories are input in parallel into the corresponding scheduling modules to obtain intent feedback results. Each scheduling module is configured to autonomously call the corresponding downstream service interface for the user intent it receives to generate intent feedback results. Dynamic decisions are made based on the asynchronous intent feedback results output by each of the scheduling modules to determine the scheduling method to the vehicle terminal.

2. The method according to claim 1, characterized in that, The intention recognition and classification of the voice interaction information to obtain at least two categories of user intentions includes: The voice interaction information is semantically segmented into multiple clauses; Named entity recognition is performed on each clause to obtain several named entities; Each clause and its corresponding named entity are input into a pre-trained intent recognition model to obtain an initial intent candidate set containing confidence scores. The initial intent candidate set is preprocessed to obtain user intents of at least two categories; each user intent includes an intent category label, an entity slot, and a target scheduling module identifier.

3. The method according to claim 2, characterized in that, The preprocessing of the initial intent candidate set to obtain at least two categories of user intents includes: The confidence level of each user intent in the initial intent candidate set is compared with a preset confidence threshold; User intents with a confidence level lower than the preset confidence threshold will be filtered out. Based on semantic similarity, the filtered user intents are merged or deduplicated to obtain user intents of at least two categories.

4. The method according to claim 1, characterized in that, The scheduling module includes at least: a vehicle control scheduling module, a service query scheduling module, a creative intent scheduling module, a knowledge retrieval scheduling module, a data recognition module, and a quick reply module; The vehicle control scheduling module is configured to generate standardized vehicle control commands based on the intents of vehicle control users; The service query scheduling module is configured to dynamically route to the corresponding service interface based on the user intent of the service query, and receive the intent feedback result returned by the service interface; The creative intent scheduling module is configured to construct restricted prompt words based on creative intent and call a large language model to generate intent feedback results; the creative intent includes at least character imitation and creative writing; The knowledge retrieval scheduling module is configured to retrieve factual answers using a structured knowledge base based on the retrieval intent; The identification module is configured to output a rejection signal to prevent subsequent scheduling based on invalid, ambiguous, or non-operational user intents. The quick reply module is configured to generate intent feedback results based on preset reply templates for request intents that exceed the system's capabilities.

5. The method according to claim 4, characterized in that, The service query and scheduling module includes a third-party domain landing module; the method also includes: When the user intent is a service query intent, determine whether the user intent includes a third-party application name entity; If included, the user intent is input into the third-party domain matching module, which is configured to match the third-party application name entity based on a preset third-party application whitelist. If the match is successful, the corresponding third-party application interface is called to execute the service request. If the match fails, a prompt message is returned indicating that the third-party application is not currently supported, and the third-party application name entity is updated to the preset third-party application whitelist.

6. The method according to claim 5, characterized in that, The service query scheduling module also includes a standard service module and a customized domain module; if the user intent is a service query intent and does not include a third-party application name entity, the method further includes: Determine the query category of the user's intent, which includes factual query intent and subjective query intent; If the intent is a factual query, the user intent is input into the standard service module. The standard service module is configured to identify the service category based on the user intent and call the corresponding local or third-party service interface based on the service category to generate factual service query results. If the query intent is subjective, the user intent is input into the customized domain module, which is configured to perform retrieval enhancement based on a preset service knowledge base and call a large language model to generate subjective service query results.

7. The method according to claim 1, characterized in that, Before performing intent recognition and classification on the voice interaction information, the method further includes: The voice interaction information is matched using a preset regular expression, which contains sensitive information keywords. If a match is found, the voice interaction information is intercepted and a preset error code is returned.

8. The method according to claim 1, characterized in that, The dynamic decision-making process for determining the scheduling method to the vehicle terminal based on the asynchronously output intent feedback results of each scheduling module includes: Receive the intent feedback results asynchronously output by each scheduling module; For each newly arrived intent feedback result, its scheduling method is determined based on preset decision rules; the decision rules include at least: If the intent feedback result does not contain valid semantics, the result is discarded and not sent to the vehicle terminal. If there is no ongoing voice broadcast, the intent feedback result will be immediately sent to the vehicle terminal for broadcast. If an intent feedback result is already being broadcast, then the priority of the newly arrived intent feedback result is compared with that of the currently broadcast intent feedback result: If the newly arrived intent feedback result has a higher priority, the current broadcast is interrupted and the newly arrived intent feedback result is sent to the vehicle terminal; otherwise, the newly arrived intent feedback result is temporarily stored in the broadcast queue and sent in order of priority after the current broadcast is completed.

9. A vehicle-mounted voice dispatch system, characterized in that, It includes an in-vehicle terminal and a cloud server; the cloud server includes a receiving module, an intent recognition module, multiple scheduling modules, and a decision-making module; The vehicle-mounted terminal is used to detect voice interaction information and upload it to the cloud server; The receiving module is used to receive the user's voice interaction information in the current voice interaction round sent by the vehicle terminal; The intent recognition module is used to classify the voice interaction information to obtain at least two categories of user intent. Each of the scheduling modules is used to autonomously call the corresponding downstream service interface for the user intent it receives, and generate intent feedback results; The decision module is used to make dynamic decisions on the intent feedback results asynchronously output by each of the scheduling modules, so as to determine the scheduling method to the vehicle terminal.

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 described in any one of claims 1-8.

Images