Data processing method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The invention provides a data processing method and device, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: when instruction data input by an object is obtained, performing intention recognition on the instruction data to obtain a plurality of first intentions of the object; performing issuing mode identification on each first intention to obtain an issuing mode of each first intention, and screening out a plurality of second intentions of which the issuing modes are non-streaming issuing modes from the plurality of first intentions; performing field identification on each second intention to obtain a field to which each second intention belongs; when the fields to which the at least two second intentions belong are the same, combining the at least two second intentions to obtain a target intention; the target intention and the uncombined first intention are issued to a terminal, and the terminal is used for executing operation corresponding to the target intention and operation corresponding to the uncombined first intention. Through the application, the instruction input times of the object can be reduced, and the interaction efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the development of artificial intelligence and natural language processing technologies, inputting commands to smart terminals (such as mobile phones, smart speakers, and in-vehicle systems) via voice and text has become the mainstream interaction method. To improve user experience and system efficiency, intent recognition models are typically used to semantically parse user input to determine the intended operation and trigger corresponding functions accordingly.

[0003] In related technologies, users often express multiple intentions in a single sentence. However, after segmenting and semantically matching the user's input text, only the most matching intention (such as "play video" or "adjust volume") can be returned, and this intention is directly sent to the terminal for execution. Therefore, this approach requires users to repeatedly input information, increasing the interaction cost. Summary of the Invention

[0004] This application provides a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product that can merge non-streamed intents from the same field into a single target intent for delivery, reducing the number of instruction inputs required from the target and improving interaction efficiency.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a data processing method, the method comprising: when receiving instruction data input by an object, performing intent recognition on the instruction data to obtain multiple first intents of the object; performing delivery mode recognition on each first intent to obtain a delivery mode for each first intent, and filtering out multiple second intents from the multiple first intents whose delivery mode is a non-streaming delivery mode; performing domain recognition on each second intent to obtain the domain to which each second intent belongs; when at least two second intents belong to the same domain, merging the at least two second intents to obtain a target intent; and sending the target intent and the unmerged first intents to a terminal, wherein the terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

[0006] This application provides a data processing apparatus, including: The intent recognition module is used to perform intent recognition on the instruction data when the object inputs it, and obtain multiple first intents of the object; The pattern recognition module is used to perform distribution pattern recognition on each first intent to obtain the distribution pattern of each first intent, and to filter out a plurality of second intents from the plurality of first intents whose distribution pattern is a non-streaming distribution pattern. A domain identification module is used to identify the domain of each second intent and obtain the domain to which each second intent belongs; The merging module is used to merge at least two second intentions to obtain a target intention when at least two second intentions belong to the same domain. The delivery module is used to deliver the target intent and the unmerged first intent to the terminal, wherein the terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

[0007] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the data processing method provided in the embodiments of this application.

[0008] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the data processing method provided in this application when executed by a processor.

[0009] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the data processing method provided in this application.

[0010] The embodiments of this application have the following beneficial effects: After acquiring the input instruction data, intent recognition is performed on the instruction data to obtain multiple first intents. For each first intent, delivery pattern recognition is performed to filter out multiple second intents with non-streaming delivery patterns. Then, based on domain recognition, second intents belonging to the same domain are merged into a single target intent. Finally, this target intent is combined with the unmerged first intents. Figure 1 The commands are sent to the terminal for execution, allowing users to complete multiple operations with a single command. Since the second intents within the same domain are merged and sent uniformly, the number of intents that the terminal needs to respond to independently is reduced, improving terminal processing efficiency. Simultaneously, the terminal receives and executes the merged target intent and the operations corresponding to the unmerged first intent, ensuring the overall integrity of the user's multi-intent requests. Therefore, the embodiments of this application can reduce the number of command inputs for the object and improve interaction efficiency. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the architecture of the data processing system provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1 ; Figure 4 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 2 ; Figure 5 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 3 ; Figure 6 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 4 ; Figure 7 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 5 ; Figure 8 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 6 ; Figure 9 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 7 ; Figure 10 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 8 ; Figure 11 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 9 ; Figure 12 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 10 ; Figure 13 This is a schematic diagram of the client interface for inputting voice commands provided in the embodiments of this application. Figure 1 ; Figure 14 This is a schematic diagram of the client interface for instruction execution provided in the embodiments of this application. Figure 1 ; Figure 15 This is a schematic diagram of the client interface for inputting voice commands provided in the embodiments of this application. Figure 2 ; Figure 16 This is a schematic diagram of the client interface for instruction execution provided in the embodiments of this application. Figure 2 ; Figure 17This is a schematic diagram of the protocol packet delivery format provided in the embodiments of this application; Figure 18 This is a schematic diagram of the client's processing flow of protocol packets provided in an embodiment of this application; Figure 19 This is a schematic diagram illustrating the execution result of the streaming intent provided in the embodiments of this application; Figure 20 This is a schematic diagram of the delivery process for a combination of streaming intents and non-streaming intents provided in an embodiment of this application. Figure 1 ; Figure 21 This is a schematic diagram of the delivery process for a combination of streaming intents and non-streaming intents provided in an embodiment of this application. Figure 2 ; Figure 22 This is a schematic diagram of the delivery process of streaming intents and streaming intent combinations provided in the embodiments of this application; Figure 23 This is a schematic diagram of the process of intent processing between the server and the terminal provided in the embodiments of this application; Figure 24 This is a schematic diagram of the business side provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0015] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0016] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0017] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0018] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0019] 1) Intent: The specific operation goal that the user wants the terminal to perform, expressed through voice or text input, such as "play video", "adjust volume", "full screen display".

[0020] 2) Non-stream delivery: This refers to a transmission method where the server sends a complete intent protocol packet along with a single Server-Sent Event (SSE) to the terminal at once. It is suitable for operation scenarios where all parameters can be predetermined (such as control intents and direct access intents). An intent protocol packet is a standardized data structure used to encapsulate one or more intents and the relevant data required for the corresponding operation to be performed.

[0021] 3) Streaming delivery: This refers to a transmission method in which the server splits an intent protocol packet into multiple parts in stages and sends them to the terminal in segments through multiple SSE events. It is suitable for scenarios where data is continuously generated or needs to be received and processed simultaneously (such as video or vertical intents).

[0022] 4) Intent Category: This refers to the tag that categorizes intents based on business attributes. It is used to determine whether multiple intents belong to the same functional module, such as "playback", "control", "video" and "vertical".

[0023] 5) Protocol packet: A data structure that carries one or more intentions and their related attributes (such as operation instructions, parameters, priorities, etc.) and is encapsulated in a standardized format.

[0024] 6) Large Language Model: A deep learning model trained on massive corpora that can understand natural language semantics and output structured results. It can be used to assist in tasks such as intent recognition and domain classification.

[0025] 7) Automatic Speech Recognition (ASR): This refers to the technology that converts user voice input into structured text data. It is the first step in achieving natural language understanding in voice interaction systems and is used to support subsequent intent recognition and semantic parsing.

[0026] 8) Smart Big Screen (Over The Top, OTT): A platform that provides users with services such as video, games, and shopping through terminals such as Internet TVs or smart boxes.

[0027] 9) Software Development Kit (SDK): refers to a set of application programming interfaces (APIs), documentation, and tools provided by developers for integrating specific functional modules (such as speech recognition, intent processing, and protocol parsing), making it easy for third-party applications to quickly access and call the relevant capabilities.

[0028] 10) Natural Language Processing (NLP): refers to the technology in the field of computer science and artificial intelligence that uses machine learning, deep learning and computational linguistics methods to enable computers to understand, analyze and generate human language. It is the core technological foundation for realizing user intent recognition and semantic parsing.

[0029] 11) Human-Computer Interaction Interface: Refers to the interface form used to receive user input commands and display system response information, including but not limited to Graphical User Interface (GUI), Voice User Interface (VUI), Augmented Reality (AR) interface, Virtual Reality (VR) interface, interactive projection interface, eye-tracking interface, holographic interface, multimodal interface, and Brain-Machine Interface (BMI) interface. In the embodiments of this application, the human-computer interaction interface is mainly used to receive user voice or text commands and feed back the processed operation results to the user in a visual or voice manner, realizing the one-time reception and overall execution of multi-intent commands.

[0030] In related technologies, the server's Natural Language Processing (NLP) intent recognition model typically includes word segmentation in the semantic analysis stage. Based on the segmentation results, it retrieves matching intents and their corresponding actions from a large-scale corpus. Subsequently, the first matched intent is returned to the terminal. For example, when a user inputs "Play the second episode of season 2 of XX TV series in full screen," the server will only return the intent to play the second episode of season 2, ignoring the "full screen" action intent. This forces the user to issue the "full screen play" command again after the video playback has started to complete the corresponding action. Therefore, users cannot achieve the coordinated execution of multiple intents with a single complete command; they must input them step by step, resulting in low interaction efficiency.

[0031] To address the aforementioned problems, embodiments of this application provide a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can reduce the number of instruction inputs and improve interaction efficiency. The following describes exemplary applications of the electronic device provided in this application. The electronic device provided in this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or it can be implemented as a server.

[0032] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of a data processing system provided in an embodiment of this application. To support the capacity adjustment application of a computing cluster, the data processing system 100 includes at least a terminal 400, a network 300, and a server 200. The terminal 400 is connected to the server 200 through the network 300, which can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0033] In some embodiments, the present application can be implemented collaboratively by a server and a terminal. See also Figure 1Users can input command data through the client of terminal 400. Terminal 400 encapsulates the command data into a data processing request and sends the data processing request to server 200 through network 300. In response to the data processing request, server 200 performs intent recognition on the command data to obtain multiple first intents of the object; server 200 performs distribution pattern recognition on each first intent to obtain the distribution pattern of each first intent, and filters out multiple second intents from the multiple first intents whose distribution pattern is a non-streaming distribution pattern; server 200 performs domain recognition on each second intent to obtain the domain to which each second intent belongs; when at least two second intents belong to the same domain, server 200 merges at least two second intents to obtain the target intent; server 200 sends the target intent and the unmerged first intents to terminal 400, and terminal 400 executes the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

[0034] In some embodiments, the present application embodiments can be implemented by the terminal 400 alone. A user can input instruction data through the client of the terminal 400. When the terminal 400 receives the instruction data input by the user, it performs intent recognition on the instruction data to obtain multiple first intents of the object. The terminal 400 performs delivery mode recognition on each first intent to obtain the delivery mode of each first intent, and filters out multiple second intents from the multiple first intents whose delivery mode is a non-streaming delivery mode. The terminal 400 performs domain recognition on each second intent to obtain the domain to which each second intent belongs. When at least two second intents belong to the same domain, the terminal 400 merges the at least two second intents to obtain the target intent. The terminal 400 sends the target intent and the unmerged first intents to other terminals, and the other terminals execute the operations corresponding to the target intent and the operations corresponding to the unmerged first intents.

[0035] The data processing method provided in this application can be applied to any intelligent interaction scenario, reducing the number of command inputs and improving interaction efficiency. Specific application scenarios may include: 1) Smart TV Voice Interaction Scenario: After a user issues the command "Play XX TV series Season 2 Episode 2 in full screen," the server performs intent recognition on the command, obtaining two primary intents: "play" and "full screen." Based on the delivery pattern recognition, it filters out non-streaming delivery intents (such as "full screen" and "play"), and then confirms through domain recognition that both belong to the "play" category, merging them into a single target intent. Subsequently, the server combines this target intent with the unmerged primary intents... Figure 1 The input is sent to the smart TV terminal, which then parses and executes the corresponding operations in sequence, enabling multiple controls to be completed with a single input.

[0036] 2) In-vehicle voice control system: When the user says "Navigate to region A and turn on the air conditioning", the server recognizes two intentions: "navigation" and "air conditioning adjustment". Based on the delivery mode, it filters out non-streaming intentions (such as "air conditioning adjustment") and determines that the two belong to different categories (navigation and control) through domain recognition, so they are not merged. Finally, the server sends the two intentions to the in-vehicle terminal separately, and the terminal executes them in sequence to ensure priority response to critical tasks.

[0037] 3) OTT large-screen video platform: When a user inputs "Play XX video and switch the resolution to HD", the server recognizes two intents: "play" and "switch resolution". Both belong to the "play" category and are not streamed, so they are merged into one target intent; this intent, along with other unmerged intents... Figure 1 The data is sent to the terminal, which then parses and executes all operations at once, significantly reducing interaction latency.

[0038] 4) Multimodal interactive terminals (such as Augmented Reality (AR) glasses): After the user issues the command "open the map and switch to panoramic mode", the server recognizes two intents. Domain identification determines that both are "navigation-related" and are not streamed, so they are merged into a target intent. The server then combines this target intent with the unmerged intent. Figure 1 The commands are sent to the terminal, which then executes the composite instructions collaboratively, improving the smoothness and accuracy of the interaction.

[0039] In some embodiments, the electronic device implementing the data processing method provided in this application may be Figure 1 Server 200. See also Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Figure 2 The illustrated electronic device includes at least one processor 210, a memory 230, and at least one network interface 220. Various components in server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 2 The general labeled all buses as Bus System 240.

[0040] Processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0041] The memory 230 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 230 may optionally include one or more storage devices physically located away from the processor 210.

[0042] The memory 230 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 230 described in this application embodiment is intended to include any suitable type of memory.

[0043] In some embodiments, memory 230 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0044] Operating system 231 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 232 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A data processing device 233 stored in memory 230 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: an intent recognition module 2331, a pattern recognition module 2332, a domain recognition module 2333, a merging module 2334, and a distribution module 2335. These modules are logically connected and can therefore be arbitrarily combined or further split according to the functions they implement. The functions of each module will be described below.

[0045] The data processing method provided in the embodiments of this application will be described below. As mentioned above, the electronic device implementing the data processing method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0046] See Figure 3 , Figure 3 This is a flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1, will combine Figure 3 The steps shown are explained as follows: Figure 3 As shown, the method is illustrated using a server as the execution subject of the data processing method. The method includes the following steps 101 to 105.

[0047] In step 101, when the instruction data input by the object is obtained, the instruction data is subjected to intent recognition to obtain multiple first intents of the object.

[0048] Here, the object is the user who initiates the interaction request through a client on the terminal. The terminal is the physical device that runs client software and provides a human-computer interaction interface, such as a smart TV, smartphone, or in-vehicle screen. The client is the application module deployed on the terminal. The instruction data is the specific content of the interaction request initiated by the object through the human-computer interaction interface of the client, such as text, voice content, or gestures, used to express one or more operation goals that the object expects the client to perform.

[0049] For example, in a smart TV scenario, the object is the user watching the program, the terminal is the smart TV device used by the user, the client is the voice assistant application installed on the TV, the interaction request is the user waking up the voice assistant application to make voice input, and the instruction data is the original voice content of the voice input, such as "Play XXX TV series Season 2 Episode 2 in full screen".

[0050] In this embodiment, the first intent is a single operation target identified from the instruction data, such as playing a video, displaying in full screen, or adjusting the volume. Intent recognition is a process based on a natural language processing (NLP) model that performs word segmentation, syntactic analysis, and semantic matching on the instruction data to extract multiple possible operation targets. The output of this process is the multiple first intents.

[0051] For example, when a user says "Play XXX TV series Season 2 Episode 2 in full screen" through the smart TV's voice assistant, the server first converts the command data into command text, and then performs intent recognition on the command text to obtain two primary intents: "Play XXX TV series Season 2 Episode 2" and "Play in full screen".

[0052] In some embodiments, see Figure 4 , Figure 4 The intention recognition of the instruction data in step 101 to obtain multiple first intentions of the object can be achieved through the following steps 1011A to 1014A.

[0053] In step 1011A, the instruction data is converted into instruction text.

[0054] Here, the instruction text is the structured text containing the specific content of the instruction data. When the object inputs instruction data via text, the instruction data is directly used as the instruction text. When the object inputs instruction data via voice, speech recognition is performed on the instruction data to obtain the instruction text. When the object inputs instruction data via gesture, gesture recognition is performed on the instruction data to obtain the instruction text.

[0055] Taking voice input as an example, Automatic Speech Recognition (ASR) technology is used to transcribe voice commands into text. For instance, when a user says "Play XXX Season 2 Episode 2 in full screen" through a smart TV voice assistant, the voice command is first converted into structured text using ASR: "Play XXX Season 2 Episode 2 in full screen". This text is the command text used in subsequent steps.

[0056] In some embodiments, gesture recognition of instruction data to obtain instruction text can be achieved as follows: The instruction data is divided into multiple gesture fragments, and the following processing is performed on each gesture fragment: First, multiple key points of the object's hand are extracted from the gesture fragment data at multiple sampling times; then, for each sampling time, the distance and angle between every two key points are determined, and the static features of the sampling time are determined based on the distance and angle between every two key points; next, dynamic features are determined based on the multiple key points at multiple sampling times, and the gesture fragment data is classified based on the dynamic features and the static features at multiple sampling times to obtain gesture categories; finally, a mapping table is queried based on the gesture category to obtain the text corresponding to the gesture fragment data, wherein the mapping table includes a preset association between gesture categories and text; the text corresponding to multiple gesture fragments is concatenated to obtain the instruction text.

[0057] Here, gesture fragment data refers to temporal information segments containing a complete gesture action extracted from instruction data, such as a video frame sequence of a user making a "play" gesture in the air. Static features are local geometric features calculated based on the distance and angle between keypoints within a single sampling moment. Dynamic features are temporal change features extracted based on the motion patterns of keypoints across multiple sampling moments. The mapping table is a dictionary of predefined associations between gesture categories and corresponding text, used to convert gesture categories into text.

[0058] In this embodiment, the input instruction data (such as a video stream) is divided into multiple gesture segment data. For each gesture segment data, the following processing is performed sequentially: coordinates of key hand points at multiple sampling times are extracted; the distance and angle between key points at each sampling time are calculated to generate static features; parameters such as velocity and acceleration are calculated by combining the trajectories of key points at multiple sampling times to construct dynamic features; the static and dynamic features are fused to obtain fused features, which are then fed into a classification model to output the gesture category of the gesture segment data. Finally, the corresponding text is obtained by querying a mapping table, and the texts of multiple gesture segment data are concatenated into the final instruction text.

[0059] For example, when a user makes a "swipe right" gesture in front of a smart TV to indicate "next episode," it is identified as a gesture fragment data. Key points at five sampling moments are extracted, and static features (such as finger spacing and wrist angle) are calculated for each sampling moment. Dynamic features (such as movement direction and speed) are determined based on the time series. The classification model determines that the gesture fragment data belongs to the "next episode" gesture category, queries the mapping table to obtain the corresponding text "next episode," and finally concatenates it with other gesture fragment texts to form the complete instruction text: "Play next episode."

[0060] In step 1012A, multiple keywords are extracted from the instruction text, and a first semantic vector for each keyword is determined.

[0061] Here, keywords are words in the instruction text that represent intent, such as "play," "full screen," and "TV series." The first semantic vector is a numerical vector representing the semantic features of the keyword. For example, the first semantic vector of the keyword "play" could be [0.8, -0.2, 0.5, ...].

[0062] In this embodiment, multiple keywords are extracted from the instruction text, which can be achieved in the following way: the instruction text is segmented into multiple words; candidate keywords that meet the intent representation characteristics are selected from the multiple words according to preset rules. The preset rules may include at least one of the following: action-related keyword rules: filtering verbs or verb phrases that represent user operation needs, such as play, pause, switch, record, screenshot, etc.; object-related keyword rules: filtering nouns or noun phrases that represent operation targets, such as TV series, video, music, picture, etc.; attribute-related keyword rules: filtering adjectives or noun phrases that represent operation parameters or operation states, such as full screen, high definition, mute, loop, etc.

[0063] For example, in the instruction text "Play XXX Season 2 Episode 2 in full screen", multiple keywords are extracted: "full screen", "play", "XXX", "Season 2", "Episode 2", etc., and the first semantic vector is generated for each.

[0064] In this embodiment, for each keyword, a pre-trained embedding model (e.g., Word to Vector (Word2Vec), Bidirectional Encoder Representations from Transformers (BERT)) is used to encode the keyword, resulting in a first semantic vector. The pre-trained embedding model is a deep learning model capable of extracting semantic features of keywords, outputting a fixed-dimensional numerical vector, and the cosine similarity between the first semantic vectors is positively correlated with the semantic similarity of the keywords.

[0065] In step 1013A, the first semantic vectors of multiple keywords are merged to obtain the second semantic vector, and the second semantic vector is classified to obtain the probability distribution.

[0066] The probability distribution includes the probability that the second semantic vector belongs to each preset intent.

[0067] Here, the second semantic vector is the overall semantic representation obtained by fusing the first semantic vectors of multiple keywords, used to characterize the semantic features of the entire instruction text. The probability distribution is the set of probabilities output after classifying the second semantic vector. Each probability corresponds to a preset intent and represents the confidence value of that preset intent (ranging from 0 to 1), used to determine the intent category to which the second semantic vector most likely belongs. The preset intent is a pre-constructed operation target used to match the semantics of the user instruction. Each preset intent corresponds to a specific operation, such as "play video," "adjust volume," and "switch resolution," and has a unique identifier. For example, "play," "full screen," and "adjust volume" are all preset intents.

[0068] This application does not limit the specific method of fusing multiple first semantic vectors. For example, attention mechanisms or average pooling can be used to fuse multiple first semantic vectors to obtain a second semantic vector. Then, the second semantic vector is input into an intent classification model (such as a fully connected network or a Transformer model) to output a probability distribution.

[0069] For example, the first semantic vectors of keywords such as "full screen", "play", and "Joy of Life" are fused into a second semantic vector and then input into the classification model. The final output probability distribution includes: the probability of play intention is 0.85 and the probability of full screen intention is 0.78.

[0070] In step 1014A, multiple preset intents with a probability greater than a preset threshold are identified as multiple first intents.

[0071] Here, the preset threshold is a confidence threshold used to determine whether the intent is valid. Its value ranges from 0 to 1, and it is used to determine whether the probability distribution corresponding to the second semantic vector contains a sufficiently credible preset intent. The preset threshold value can be set according to actual needs, for example, 0.6.

[0072] In this embodiment of the application, the probability distribution is traversed, and all preset intentions with probabilities greater than a preset threshold are selected as the first intention.

[0073] For example, if the preset threshold is 0.6, and the probability of the preset intent "play" is 0.85 and the probability of the preset intent "full screen" is 0.78, both of which are higher than the preset threshold, then these two preset intents are determined as the first intent.

[0074] This application's embodiments achieve efficient intent recognition of commands in multiple input forms, such as voice and gestures, through layered processing including multimodal command to structured text conversion, accurate extraction of intent keywords, semantic vector fusion, and intent probability filtering. This improves the accuracy and robustness of intent recognition under complex commands, while also supporting parallel determination of multiple intents to adapt to the diverse interaction needs of smart terminals.

[0075] In some embodiments, see Figure 5 , Figure 5 The intention recognition of the instruction data in step 101 to obtain multiple first intentions of the object can be achieved through the following steps 1011B to 1012B.

[0076] In step 1011B, the instruction data is converted into instruction text.

[0077] In this embodiment, the specific process of converting instruction data into instruction text in step 1011B is similar to the specific process of converting instruction data into instruction text in step 1011A in the above embodiment, and will not be described again.

[0078] In step 1012B, prompt words are constructed based on the instruction text, and the prompt words are input into the language model to obtain multiple first intentions.

[0079] Among them, prompt words are used to guide the language model to parse the intent expressed in the instruction text.

[0080] Here, the language model can be a Large Language Model (LLM), a natural language processing model based on deep learning. It can understand the semantics of natural language and generate logically consistent text output, parsing instruction text through input prompts. The prompts guide the language model to parse the semantics of the instruction text and output structured instructions with multiple intentions.

[0081] In this embodiment, constructing prompt words based on instruction text can be achieved as follows: Instruction text is filled into a prompt word template to obtain prompt words. The prompt word template includes task requirements for guiding the language model to perform a specific task, and variables to be filled. Instruction text is filled into these variables to obtain prompt words.

[0082] For example, the prompt template could be: "Please extract the user's intent from the following text: [Instruction text]". If the instruction text is "Play XXX Season 2 Episode 2 in full screen", then the prompt would be "Please extract the user's intent from the following text: [Play XXX Season 2 Episode 2 in full screen]". Inputting this prompt into a Large Language Model (LLM) will output two primary intents: "Play XXX Season 2 Episode 2" and "Play in full screen".

[0083] This application embodiment simplifies the intent recognition process by reusing a mature instruction data to text conversion process and combining prompt word template construction with the intent parsing capabilities of a large language model. It can efficiently and accurately extract multiple user intents from instruction text, thereby improving the convenience and adaptability of intent recognition.

[0084] In step 102, a delivery pattern is identified for each first intent to obtain the delivery pattern of each first intent, and multiple second intents with a non-streaming delivery pattern are selected from multiple first intents.

[0085] Here, the delivery mode refers to the transmission method where a first intent is sent from one electronic device to another, such as the transmission method where a server sends data to a terminal. Delivery modes can include streaming delivery modes or non-streaming delivery modes. Streaming delivery mode involves dividing the data associated with an intent into multiple ordered data fragments and sending them sequentially and segmentedly from one electronic device to another. Streaming delivery mode is suitable for data that needs to be transmitted in segments (such as video intents), and is typically sent from one electronic device to another in stages via the SSE event protocol. For example, the server sends the first part of the first intent (event=intent_part_first), the middle segment of the first intent (event=intent_part_middle), and the last part of the first intent (event=intent_part_end) to the terminal. Non-streaming delivery mode involves sending all the data associated with an intent as a single, indivisible data unit from one electronic device to another in one go. Non-stream delivery mode is suitable for data that can be transmitted in a complete manner at once (such as control intents). Typically, the server sends a single complete protocol packet to the terminal via the SSE event protocol. For example, sending a complete protocol packet (event=intent_full, indicating that the complete protocol packet of the first intent is ready and can be received and executed by the terminal at once) to the terminal.

[0086] For example, the first intent "play video" belongs to the non-streaming delivery mode, while the first intent "video recommendation" belongs to the streaming delivery mode.

[0087] In this embodiment of the application, a delivery mode for each first intent is determined. For each first intent, if the delivery mode of the first intent is a non-streaming delivery mode, then the first intent is used as a second intent.

[0088] For example, the instruction text is "Play XXX Season 2 Episode 2 in full screen, and recommend some similar TV series." Three primary intents are identified: "Play XXX Season 2 Episode 2," "Play in full screen," and "Recommend TV series." The primary intents "Play XXX Season 2 Episode 2" and "Play in full screen" are both non-streaming delivery modes, so they are treated as two secondary intents. The primary intent "Recommend TV series" is a streaming delivery mode.

[0089] In some embodiments, the delivery pattern recognition for each first intent in step 102 to obtain the delivery pattern of each first intent can be achieved in the following way: First, for each first intent, the first intent is classified to obtain the intent category of the first intent; then, when the intent category of the first intent is a first preset category, the delivery mode of the first intent is determined to be a streaming delivery mode; when the intent category of the first intent is a second preset category, the delivery mode of the first intent is determined to be a non-streaming delivery mode.

[0090] Here, intent categories are business attribute tags used to distinguish different types of intent operation targets, such as "video," "vertical," "control," and "direct access." Each intent category corresponds to a fixed delivery mode. Video intents refer to intents directly related to video content search, recommendation, and management; the operation object is video resources, and data is usually transmitted in segments, making streaming delivery suitable. Examples include "recommend TV series" and "search for XXX." Vertical intents refer to intents used to request operations within a specific vertical domain (e.g., games, shopping, education); data is usually transmitted in segments, making streaming delivery suitable. Examples include "play folk song playlist" for music, "launch XX mobile game" for games, and "open English online class" for education. Control intents refer to user requests to control device status (e.g., "full screen display," "adjust volume," "turn lights on / off"); these can usually be transmitted in one complete session, making non-streaming delivery suitable. Direct access: refers to the user's intention to directly jump to a specific function or service (such as "open XX video" or "play season 2 episode 2"). It can usually be transmitted completely in one go and is suitable for non-streaming delivery mode.

[0091] In this embodiment, the first preset category is a pre-defined set of intent categories applicable to streaming delivery mode. Each intent in the first preset category needs to transmit data in segments, such as "video" or "vertical". The second preset category is a pre-defined set of intent categories applicable to non-streaming delivery mode. Each intent in the second preset category can transmit data completely at once, such as "control" or "direct access".

[0092] For example, if the first intent is "Play Season 2, Episode 2", and the intent category of the first intent is direct access (second preset category), then the delivery mode of the first intent is non-streaming delivery mode. If the first intent is "Check today's weather", and the intent category of the first intent is vertical (first preset category), then the delivery mode of the first intent is streaming delivery mode.

[0093] This application embodiment divides the first intent into different categories according to business attributes and establishes a precise mapping rule between intent categories and delivery modes, thereby achieving adaptive matching of streaming and non-streaming delivery modes. This satisfies the segmented data transmission requirements of video and vertical intents while ensuring efficient one-time transmission of control and direct-access intents, thus improving the flexibility and transmission efficiency of intent command delivery.

[0094] In step 103, domain identification is performed on each second intent to obtain the domain to which each second intent belongs.

[0095] Here, the domain refers to the vertical service scenario to which the business function corresponding to the intent belongs. It is a further subdivision and classification of the application scenario of the intent. For example, the domain can include video domain, audio domain, smart home domain, life service domain, and system control domain, etc.

[0096] For example, the second intent "playing episode 2 of season 2" belongs to the video domain, and the second intent "adjusting the volume" belongs to the system control domain.

[0097] In some embodiments, see Figure 6 , Figure 6 The step 103 shows that domain identification is performed for each second intent to obtain the domain to which each second intent belongs, which can be achieved through the following steps 1031 to 1033.

[0098] In step 1031, the word set for each preset domain is obtained from the domain thesaurus.

[0099] Here, the preset domains are vertical service categories divided according to business function boundaries, such as video, audio, and smart home domains. The domain lexicon is a pre-built database containing multiple preset domains and a set of words for each preset domain. For each preset domain, the word set includes multiple feature words corresponding to that preset domain. These feature words contain the core actions, operational objects, and business terms of that domain, used to characterize the semantic features of that preset domain.

[0100] In this embodiment, word sets corresponding to all preset domains are retrieved from a pre-built domain lexicon. Each word set must cover the core semantic elements of the corresponding preset domain. For example, the word set for the video domain includes feature words such as "play," "full screen," "episode," and "picture quality," while the word set for the audio domain includes feature words such as "music," "playlist," "volume," and "sound effects."

[0101] In step 1032, for each second intent, the semantic similarity between the second intent and the word set of each preset domain is determined.

[0102] Here, semantic similarity is a quantitative indicator that measures the degree of semantic association between the second intention and the word set of the preset domain. The value range is usually [-1, 1]. The closer the semantic similarity is to 1, the higher the semantic matching degree between the second intention and the preset domain.

[0103] In this embodiment, for each second intent, semantic encoding is performed to obtain an intent semantic vector. This embodiment does not limit the specific implementation process of semantic encoding; for example, encoding can be performed using a pre-trained embedding model (such as Word2Vec or BERT). For each word set in a preset domain, semantic encoding is performed on each feature word in the word set to obtain a feature word vector; vector aggregation is then performed on the feature word vectors of all feature words in the word set to obtain a domain semantic vector for the preset domain. This embodiment does not limit the specific method of vector aggregation; for example, weighted averaging or attention fusion can be used. Then, the similarity between the intent semantic vector of the second intent and the domain semantic vector of the preset domain is calculated, and this similarity is used as the semantic similarity between the second intent and the word set of the preset domain. This embodiment does not limit the method of calculating the similarity; for example, cosine similarity or Euclidean distance can be used.

[0104] For example, the second intent "Play XXX Season 2 Episode 2 in full screen" is encoded as an intent semantic vector; word sets from three preset domains are aggregated to generate video domain vector V1, audio domain vector V2, and smart home domain vector V3. The semantic similarity between this second intent and the video domain is calculated to be 0.92, with the audio domain 0.21, and with the smart home domain 0.15.

[0105] In step 1033, the preset domain corresponding to the maximum semantic similarity is determined as the domain to which the second intent belongs.

[0106] Here, for each second intent, the similarity calculation results between the second intent and all preset domains are traversed, and the preset domain corresponding to the maximum semantic similarity is selected, and the preset domain is taken as the domain to which the second intent belongs.

[0107] Continuing with the example in step 1032, the maximum semantic similarity is 0.92. The preset domain corresponding to the maximum semantic similarity is the video domain. Therefore, the video domain is determined as the domain to which the second intent belongs.

[0108] This application embodiment constructs a domain lexicon covering various vertical business categories, and combines semantic vector encoding and aggregation strategies to quantitatively match the second intent with a preset domain word set. Based on the maximum similarity, it accurately determines the domain to which the intent belongs. This not only improves the accuracy and objectivity of domain identification, but also allows for rapid adaptation to new business domains through flexible expansion of the lexicon, enhancing the scalability and practicality of the solution.

[0109] In step 104, when at least two second intentions belong to the same domain, the at least two second intentions are merged to obtain the target intention.

[0110] Here, when at least two of the multiple second intentions belong to the same domain, all second intentions belonging to the same domain are filtered out from the multiple second intentions, and all second intentions belonging to the same domain are merged to obtain the target intention.

[0111] For example, if the domain of second intention A "Play XXX Season 2 Episode 2" is the video domain, and the domain of second intention B "Full Screen Display" is the video domain, then second intention A and second intention B meet the merging conditions and can be merged. The domain of second intention C "Adjust Volume" is the audio domain, which is different from the domains of second intentions A and B, therefore it cannot be merged with second intentions A and B.

[0112] In some embodiments, see Figure 7 , Figure 7 The step 104 shows that merging at least two second intentions to obtain the target intention can be achieved through steps 1041 to 1043.

[0113] In step 1041, the target category is determined based on the intent category of each of the at least two second intents.

[0114] Here, the target category is the intent type label determined by combining the intent categories of multiple second intents involved in the merging.

[0115] In this embodiment, for all second intentions in the same domain participating in the merging, the intention category of each second intention is extracted; based on the preset category integration rules, the target category is determined. For example, the category integration rule could be that if the intention category of one second intention participating in the merging is a direct access category and the intention category of another second intention is a control category, then the target category could be "video category"; if the intention category of the first second intention participating in the merging is a control category and the intention category of another second intention is also a control category, then the target category could be "playback control category".

[0116] In some embodiments, the target category is determined based on the intent category of each of the at least two second intents, which can be achieved in the following ways: when the intent categories of the at least two second intents are the same, the same intent category is determined as the target category; when the intent categories of the at least two second intents are different, a third preset category is determined as the target category.

[0117] Here, the third preset category is a predefined unified category label used to carry the intention of merging multiple different categories, such as "video category" and "playback control category".

[0118] In this embodiment, all second intents involved in the merging process are obtained, and the intent category corresponding to each second intent is extracted. All extracted intent categories are iterated over to determine if they are identical. If all second intents have the same intent category (e.g., all are "control" or all are "direct access"), then that identical intent category is directly identified as the target category. If the second intents have two or more different intent categories (e.g., one is "control" and the other is "direct access"), then a preset third category is invoked and identified as the target category.

[0119] For example, the second intents involved in the merging (both belonging to the video domain) include: Second Intent A: "Turn on bullet comments" (intent category: control) and Second Intent B: "Adjust the speed to 1.5x" (intent category: control). Since both second intents have the same intent category, the target category is determined to be "control".

[0120] For example, the second intents involved in the merging (all belonging to the video domain) include: Second Intent C: "Play XXX Season 3 Episode 5" (Intent Category: Direct Access), Second Intent D: "Switch to 4K resolution" (Intent Category: Control), and Second Intent E: "Turn on subtitles" (Intent Category: Control). Since the intent categories of the three second intents are not entirely the same, the predefined third preset category "video" in the video domain will be used as the target category.

[0121] This application's embodiments eliminate the need for complex category weight calculations and semantic fusion models. The target category can be quickly determined simply through the rule of "reusing the same categories and summarizing the different ones," reducing server computing power consumption. This is particularly suitable for lightweight deployment scenarios on the terminal side (such as smart TVs and smart speakers with limited computing power). It avoids the category determination confusion caused by algorithmic deviations during multi-category fusion. Intent merging in the same scenario yields a unified target category, ensuring consistency in downstream structure matching and intent execution. By pre-setting a third preset category, it can flexibly cover scenarios involving "merging multiple different category intents." When adding a new domain or intent category, only the corresponding third preset category configuration needs to be added; no modification to the core determination logic is required, significantly improving the solution's adaptability to business iterations.

[0122] In step 1042, when a structure of the target category is stored locally, an operation field is added to the structure, and each second intent is filled into a slot in the operation field to obtain the target intent.

[0123] Here, "local" can refer to the local database of an electronic device. It's important to note that the local storage contains a structure representing the target category, indicating that an electronic device and another electronic device have pre-established an intent transmission protocol for that target category. For example, if "local" is the server's local database, the target category structure represents the pre-established intent transmission protocol between the server and the terminal for that target category. The structure is a predefined, standardized data template for storing intent information, containing fixed fields such as the target category field and the operation field. The operation field is the core field in the structure used to store specific intents, containing multiple slots that can be filled with intent content. Each slot corresponds to an operation related to a second intent participating in the merging process. A slot is the smallest data unit within the operation field used to carry a single second intent; it is a pre-defined blank placeholder in the structure used to store the content of the second intent to be merged.

[0124] In this embodiment, the locally stored structure library is checked. If a structure matching the target category exists, it is directly retrieved. A new operation field is added to this structure, and a corresponding number of slots are enabled within this operation field. Each second intent is then sequentially filled into the slots. After filling, the integrated information carried by this structure becomes the target intent. It should be noted that multiple second intents within the same domain may have dependencies, but during the construction of the target intent, multiple second intents can be randomly filled into multiple operations without considering dependencies.

[0125] For example, if the instruction text is "Switch to 4K and fast forward to the 10th minute," then the second intents involved in the merging include "Switch to 4K" and "Fast forward to the 10th minute." The target category is playback control. A structure matching "playback control" is found locally, and a "multicast control operation" field is added to this structure. Then, the second intents are filled into multiple slots (slot types) of the operation field to obtain the target intent. The target intent can be as follows: { "intention":{ "Target Category": "Playback Control", "Operation": "Multicast Control Operation" }, "Intent Slot":[ {"Slot Type":"Fast Forward", "Value":"10"}, {"Slot Type": "4K Resolution"} ] } In step 1043, when the target category structure is not stored locally, a blank structure for the target category is created, and an operation field is created in the blank structure. Each second intent is filled into one slot of the operation field to obtain the target intent.

[0126] Here, if the structure corresponding to the target category does not exist in the local structure library, a blank structure is created based on the target category. Operation fields are defined in this blank structure, and corresponding slots are set according to the number of second intents to be merged. After all second intents are filled into the slots, the structure corresponding to the target category is generated, and the information it carries is the target intent.

[0127] For example, if the instruction text is "Play episode 15 of XXX at minute 10 in 4K full screen", then the second intents involved in the merging include "Switch to 4K", "Play episode 15 of XXX at minute 10", and "Play in full screen". If the target category is video, and no structure matching "video" can be found locally, a new blank structure for that target category is created, and a "Search and Playback Control" operation field is added to this blank structure. Then, the second intents are filled into multiple slots (slot types) of this operation field to obtain the target intent. The target intent can be as follows: { "intention":{ "Target Category": "Video", "Actions": "Search and Playback Controls" }, "Content":{"Album":{"Direct Access":Yes,"Album ID":"123123","Number of Episodes":15}} "Intent Slot":[ {"Slot Type":"Fast Forward", "Value":"10"}, {"Slot Type": "Enable Bullet Comments"}, {"Slot Type": "4K Resolution"}, {"Slot Type": "Full Screen"} ] This application embodiment determines a unified target category based on the categories of each second intent, ensuring that the merged intents revolve around the same core business attribute and avoiding cross-category semantic confusion. Furthermore, it utilizes standardized fields (operation fields, slots) of the structure to carry each second intent, giving the target intent a standardized data format. Downstream execution modules can directly parse it according to the protocol, significantly reducing the possibility of parsing failures due to inconsistent intent formats. For scenarios where the target category structure is already stored locally, this application embodiment directly retrieves the structure and adds operation fields and fills slots, eliminating the need to repeatedly build data templates. Relying on a pre-established intent transmission protocol, it improves the efficiency of intent merging and protocol compatibility. For incremental scenarios where the corresponding structure is not stored locally, it supports dynamically creating blank structures and customizing operation fields and slots, quickly adapting to new composite intent requirements without requiring large-scale modifications to the overall system architecture, significantly improving the solution's adaptability to business iterations. By merging multiple scattered second intents within the same domain into a single target intent, the number of intent transmissions between the terminal and the server is reduced, thus lowering network bandwidth usage and interaction latency. At the same time, it avoids the execution order confusion or operation conflicts that may occur when multiple intents within the same domain are issued independently, ensuring that complex operation requirements can be implemented coherently and improving the user's intelligent interaction experience.

[0128] In step 105, the target intent and the unmerged first intent are sent to the terminal.

[0129] The terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the first intent that has not been merged.

[0130] Here, the target intent carries operation instructions corresponding to multiple original second intents that participate in the merging. The unmerged first intents include the second intents that were filtered as non-streaming delivery mode in step 102 but did not participate in the merging, as well as the first intents in streaming delivery mode.

[0131] In this embodiment, the target intent and the unmerged first intent are encapsulated into structured protocol packets (such as JSON format) and sent to the terminal through a unified interface (such as SSE event). The target intent carries multiple operation instructions, while the unmerged first intent is processed as an independent instruction. After receiving the data, the terminal executes all operations in a preset order or priority without requiring the user to input the data again.

[0132] For example, the two secondary intents involved in the merging, "full screen display" and "turn on bullet comments", are merged into the target intent. The secondary intent "increase volume" is not merged. The server then sends the target intent and the secondary intent "increase volume" together to the smart TV terminal. After receiving the terminal, it executes the operations "full screen display", "turn on bullet comments", and "increase volume" in sequence to complete all operations of the user's one-line command.

[0133] In some embodiments, see Figure 8 , Figure 8 The step 105, which sends the target intent and the unmerged first intent to the terminal, can be achieved through the steps 1051 to 1053.

[0134] In step 1051, the first data required to perform the operation corresponding to the target intent is obtained, and the target intent and the first data are encapsulated to obtain the first protocol packet.

[0135] Here, the first data consists of additional parameter information required to execute the operation corresponding to the target intent, such as the episode identifier (ID) required for "playing episode 2" and the screen resolution required for "full-screen display". The first protocol packet is a structured data unit that encapsulates the target intent and its required first data, and is used by the terminal to parse and execute multiple operation instructions at once.

[0136] In this embodiment, all the first data required to execute the operation corresponding to the target intent is first identified and acquired, including core parameters (such as the episode ID, episode number, and resolution of the playback intent), auxiliary configurations (such as the resolution parameters for full-screen display), and permission information (such as user verification data for some operations), ensuring that the data completely covers the operation execution requirements. Then, the target intent and the acquired first data are integrated and encapsulated using a preset communication protocol format to generate a standardized first protocol packet.

[0137] For example, if the instruction text is "Play XXX Season 2 Episode 3 in full screen, then adjust the volume to 50%, and check today's weather," then the merged target intent is "Play XXX Season 2 Episode 3 in full screen" (derived by merging the two second intents in the same video domain, "Play XXX Season 2 Episode 3" and "Full screen display"). The two unmerged first intents include "Adjust volume" and "Check today's weather," where the first intent "Adjust volume" is in non-streaming delivery mode, and the first intent "Check today's weather" is in streaming delivery mode. The first protocol packet is obtained by encapsulating the target intent "Play XXX Season 2 Episode 3 in full screen" and the first data (episode ID, episode number = 3, resolution = default, full screen resolution parameters, etc.).

[0138] In step 1052, the unmerged first intent is encapsulated to obtain the second protocol packet.

[0139] Here, the second protocol packet is a structured data unit that encapsulates the unmerged first intent separately, for the terminal to independently execute a single operation. The unmerged first intent may include first intents in streaming delivery mode, or first intents in non-streaming delivery mode but belonging to different domains. Therefore, it is necessary to first determine the quantity and delivery mode of the unmerged first intents in order to select the corresponding encapsulation method.

[0140] For example, the two unmerged first intents include "adjust volume" and "check today's weather". Encapsulating the first intent "adjust volume" and the required data (volume value = 50, audio device identifier, etc.) yields a second protocol packet 1. Encapsulating the first intent "check today's weather" and the required data (geographic location, query date = today, etc.) yields another second protocol packet 2.

[0141] In some embodiments, see Figure 9 , Figure 9 The encapsulation of the unmerged first intent in step 1052 to obtain the second protocol packet can be achieved through steps 10521A to 10522A.

[0142] In step 10521A, when each unmerged first intent includes a third intent with a non-streaming delivery mode, second data required to perform the operation corresponding to the third intent is obtained for each third intent.

[0143] Here, the number of unmerged first intents can be multiple or single. If all unmerged first intents are delivered in a non-streaming mode, it means that the domains of all unmerged first intents are different from each other and different from the domains of the second intents participating in the merging. In this case, the unmerged first intents are treated as third intents. The third intent is an intent whose intent category is control or direct access, which can transmit data completely in one go, such as "adjust volume".

[0144] In this embodiment, for each selected third intent, all second data required to execute the corresponding operation is accurately identified and obtained. The second data may include key information such as core parameters covering operation execution, target object identifier, and state configuration, and must satisfy the non-streaming characteristic of "complete acquisition at once" (no segmented transmission required). For example, the second data required for the third intent "adjust volume to 50%" includes: target volume value (50%), audio device identifier (such as the current playback device ID), volume adjustment priority, etc.

[0145] In step 10522A, the third intent and the second data are encapsulated to obtain the second protocol packet corresponding to the third intent.

[0146] Here, for each third intent, a non-streaming communication protocol format is used to integrate and encapsulate the third intent and the corresponding second data according to the field specifications of a preset protocol, resulting in a second protocol packet corresponding to the third intent.

[0147] This application's embodiments, by accurately acquiring all the second data required for execution and combining it with a one-time complete encapsulation strategy, avoid the delay or data omission issues caused by segmented transmission of non-streaming intents, thus adapting to its core characteristic of "one-time execution" and improving data transmission and parsing efficiency. The use of a preset non-streaming protocol format for encapsulation ensures a unified structure for the second protocol packets generated from third intents in different fields (audio, smart home, system control, etc.), reducing parsing complexity on the terminal side and enhancing protocol compatibility in multi-device and multi-field scenarios. The design of a single third intent corresponding to a single dedicated protocol packet avoids intent command confusion and reduces the terminal's cost of distinguishing and processing multi-intent data.

[0148] In some embodiments, see Figure 10 , Figure 10 The encapsulation of the unmerged first intent in step 1052 to obtain the second protocol packet can be achieved through steps 10521B to 10523B.

[0149] In step 10521B, when the number of unmerged first intents is 1 and the delivery mode is streaming delivery mode, the third data required to perform the operation corresponding to the unmerged first intent is obtained.

[0150] Here, when there is one unmerged first intent and the delivery mode is streaming, the intent category of the unmerged first intent may be video or vertical.

[0151] In this embodiment, all third data required to perform the operation corresponding to the unmerged first intent is obtained. The third data is characterized by large data volume or strong temporal sequence, and cannot be transmitted completely at once (such as audio and video data streams of long videos, pixel data of high-definition image sets, etc.), and needs to meet the segmentation adaptation requirements of streaming transmission.

[0152] For example, if the unmerged first intent is "search for XXX video", then the intent category of the first intent is video and the delivery mode is streaming delivery mode.

[0153] In step 10522B, the third data is divided into multiple first data fragments based on the unmerged first intent.

[0154] Here, based on preset streaming transmission standards (such as data size thresholds, temporal order, and business logic segmentation), the complete third-party data is divided into multiple ordered first data fragments. The first data fragments can be subject to the following rules: the size of a single first data fragment is adapted to the network transmission bandwidth (avoiding transmission stuttering due to excessively large fragments and transmission redundancy due to excessively small fragments); the temporal or logical correlation of the data is preserved (such as video data being fragmented according to time frame order, and image sets being fragmented according to sequence number order); each first data fragment carries a unique identifier (such as fragment sequence number, total number of fragments, and start or end position) to facilitate reassembly after terminal reception.

[0155] For example, if the unmerged first intent is "search for XXX video", then the third data contains basic information (video title, cover link, duration, number of views), details link, category tags, etc. of all videos that match the search criteria, with a total data volume of approximately 1GB (due to the large number of resources, it cannot be transmitted completely at once). Divided into preset chunk sizes of 100MB, this results in 10 first data chunks, labeled as "Cheap 1 (0-100MB)", "Cheap 2 (100-200MB)", ... "Cheap 10 (900-1000MB)".

[0156] It should be noted that the first data fragment needs to carry a marker indicating the start of transmission, while the last data fragment carries a marker indicating the end of transmission.

[0157] In step 10523B, each first data fragment is encapsulated with an unmerged first intent to obtain a second protocol packet corresponding to each first data fragment.

[0158] Here, for each first data fragment, the first data fragment and the unmerged first intent are encapsulated according to preset protocol field specifications to generate a second protocol packet specific to that first data fragment. Each second protocol packet may include "intent basic information field, fragment identifier field, fragment data field, checksum field, and resume flag field," where the checksum field is used to verify the integrity of a single fragment of data, and the resume flag is used to indicate whether it is the last first data fragment (to facilitate terminal confirmation of data transmission completion). The encapsulation process is executed sequentially for all first data fragments according to their fragment sequence numbers, generating a set of ordered second protocol packets (one second protocol packet corresponding to one first data fragment), ensuring that the terminal can receive, verify, and reassemble the first data fragments in sequence.

[0159] This application embodiment divides the third data into ordered fragments, achieving "segmented transmission and fragment-by-fragment parsing." This avoids network congestion, transmission delays, or terminal memory overflow problems caused by transmitting large amounts of data at once, and is particularly suitable for the transmission needs of streaming scenarios such as video and high-definition resources. Each fragment carries fragment identifiers, checksums, and retransmission markers during encapsulation. The terminal can reassemble data using fragment sequence numbers and verify fragment integrity using checksums. If a fragment is lost or transmission fails, the missing fragment can be located based on the retransmission marker, and a retransmission can be requested. The design of a single intent corresponding to a set of ordered protocol packets ensures the continuity of streaming operations (e.g., during video playback, fragments can be received and decoded simultaneously to achieve a "instant opening" effect). At the same time, the fragment size can be dynamically adjusted according to network bandwidth, enhancing the adaptability of the solution to different network environments.

[0160] In some embodiments, see Figure 11 , Figure 11 The encapsulation of the unmerged first intent in step 1052 to obtain the second protocol packet can be achieved through steps 10521C to 10523C.

[0161] In step 10521C, when the unmerged multiple first intents include at least two fourth intents with a streaming delivery mode, the at least two fourth intents are merged to obtain a fifth intent.

[0162] Here, there are multiple unmerged first intents, and these multiple unmerged first intents include at least two fourth intents with a streaming delivery mode. All fourth intents may be in the same or different domains.

[0163] In this embodiment, the specific process of merging at least two fourth intentions to obtain a fifth intention is similar to the specific process of merging at least two second intentions to obtain a target intention in step 104 of the above embodiment, and will not be described again.

[0164] For example, if fourth intent A is "check the weather" and fourth intent B is "check the stock market", then both fourth intent A and fourth intent B are vertical categories, and both fourth intent A and fourth intent B are distributed in streaming mode. Fourth intent A and fourth intent B can be merged to obtain the fifth intent.

[0165] In step 10522C, the fourth data required to perform the operation corresponding to the fifth intent is obtained, and based on the fifth intent, the fourth data is divided into multiple second data fragments.

[0166] Here, all the fourth data required to execute the operation corresponding to the fifth intent is obtained. The fourth data is streaming data that meets the requirements of the fifth intent (such as full video resource information from search results, complete data streams of long audio files, etc.), characterized by large data volume and the need for segmented transmission. Based on preset streaming segmentation standards (such as single segment data size thresholds and business logic pagination rules), the complete fourth data is divided into multiple ordered second data segments. Each second data segment must carry unique identification information: segment sequence number, total number of segments, data start and end range, and corresponding business content tag, ensuring that the terminal can reassemble the data in order. Segmentation principles may include: single segment size adapting to network bandwidth to avoid transmission lag due to excessive size and protocol packet redundancy due to excessive size; segmentation maintaining business logic integrity; and segmentation order consistent with business requirements (such as segmenting by video popularity).

[0167] In step 10523C, each second data fragment is encapsulated with the fifth intent to obtain a second protocol packet corresponding to each second data fragment.

[0168] Here, for each second data fragment, a streaming communication protocol format is used to integrate and encapsulate the second data fragment with the fifth intent according to the preset protocol field specifications, generating a second protocol packet specific to that second data fragment. All second data fragments are encapsulated sequentially according to their fragment number, generating a set of ordered second protocol packets for the fifth intent, ensuring that the terminal can receive, verify, reassemble, and execute them in sequence.

[0169] This application embodiment merges multiple streaming fourth intents within the same domain into a single fifth intent, avoiding the problem of a surge in protocol packet count caused by independent fragmentation of multiple streaming intents. This reduces the frequency of interaction between the server and the terminal, saving network bandwidth. The merged fifth intent retains the streaming fragmentation transmission logic, solving the transmission bottleneck of massive data while ensuring data integrity and resustainability through fragmentation identifiers, checksums, and continuation markers. It also supports a streaming experience of receiving and executing simultaneously (such as loading and displaying search results), adapting to diverse streaming scenarios such as video search and long audio playback. By integrating multiple streaming intents into a single fifth intent fragmented protocol packet, the terminal only needs to process one set of ordered protocol packets, eliminating the need to distinguish between fragments of multiple independent streaming intents. This simplifies the terminal's fragmentation reassembly and business execution logic, reducing parsing complexity and memory usage.

[0170] In step 1053, the first protocol packet and the second protocol packet are serially sent to the terminal according to the order of the target intent and the unmerged first intent in the instruction data.

[0171] Here, the initial expression order of each intent in the original instruction data is extracted, and the order of the target intent and the unmerged first intent in the instruction data is determined based on this initial expression order. The order of the target intent is determined by the order of the second intent that appears first in the original instruction among the multiple second intents participating in the merging. The order of the second intent that appears first in the instruction data among the multiple second intents participating in the merging of the target intent is taken as the order of the target intent.

[0172] For example, the user's command data is: "Play XXX Season 2 Episode 3 in full screen, adjust the volume to 50%, check today's weather." Four primary intentions are identified: Figure 1 "Full-screen playback" means Figure 2 "Playing XXX Season 2 Episode 3" Figure 3 "Adjust volume" and meaning Figure 4 "Check today's weather." (The meaning is...) Figure 1 "Full-screen playback" and meaning Figure 2 The combined intents "Play XXX Season 2 Episode 3" result in "Play XXX Season 2 Episode 3 in full screen". Of the two secondary intents involved in the merging, the intention... Figure 1 The initial sort is 1 (first), therefore the sort of the target intent is determined to be 1.

[0173] Continuing with the example in step 1052, the packet delivery order is: first protocol packet → second protocol packet 1 → second protocol packet 2. Terminal execution result: First, the specified episode is played in full screen, then the volume is adjusted to 50%, and finally today's weather information is displayed, perfectly matching the user's original operation logic.

[0174] This application employs adapted encapsulation logic for both the target intent and the unmerged intent, ensuring complete data transmission of the merged intent while simplifying the encapsulation process for a single intent. Furthermore, by using a preset protocol format, it improves the compatibility and success rate of terminal parsing. Protocol packets are sent serially according to the initial order of intents in the instruction data, avoiding operational logic confusion caused by parallel or out-of-order sending, ensuring consistency between terminal operations and user requirements, and enhancing the coherence and accuracy of intelligent interaction. By merging intents within the same domain to generate a single first protocol packet, the number of protocol packets for complex operations is reduced, lowering network transmission redundancy. Simultaneously, unmerged intents are encapsulated separately into protocol packets, ensuring independent execution of cross-domain operations, achieving a dual balance between efficiency and accuracy.

[0175] In some embodiments, see Figure 12 , Figure 12 The data processing method provided in the embodiments of this application further includes steps 201 to 204.

[0176] In step 201, when there is no second intent with a non-streaming delivery mode among the multiple first intents, the multiple first intents are merged to obtain a sixth intent.

[0177] Here, all the first intents obtained from intent recognition of the instruction data are delivered in streaming mode, making it impossible to filter out the second intent from multiple first intents. In this case, all the first intents are directly merged to obtain the sixth intent.

[0178] In this embodiment, the specific process of merging all first intentions to obtain the sixth intention is similar to the specific process of merging at least two second intentions to obtain the target intention in step 104 of the above embodiment, and will not be described again here.

[0179] For example, if the instruction data is "I want to know today's stock market and weather", the first intent A is identified as "check the weather" and the first intent B is "check the stock market". The intent categories of the first intent A and the first intent B are both vertical categories, and the delivery mode of the first intent A and the first intent B are both streaming delivery modes. The first intent A and the first intent B can be merged to obtain the sixth intent.

[0180] In step 202, the fifth data required to perform the operation corresponding to the sixth intent is obtained, and based on the sixth intent, the fifth data is divided into multiple third data fragments.

[0181] Here, the fifth data is the complete data required to execute the sixth intent. Taking the instruction "I want to know today's stock market and weather" as an example, the fifth data can include weather data: today's temperature, humidity, probability of precipitation, wind force and direction, hourly weather forecast, etc.; stock market data: real-time trend of the market index, rise and fall of popular stocks, industry sector rankings, closing summary, etc. The total data volume is approximately 800MB.

[0182] Following the preset rule of 80MB per fragment, the 800MB of fifth data is divided into 10 ordered third data fragments, labeled "Fragment 1 (0-80MB)" to "Fragment 10 (720-800MB)". Among them, fragments 1-4 contain weather-related data, and fragments 5-10 contain stock market-related data. Each fragment carries identification information such as fragment number, total number of fragments, data type label, and data start and end range.

[0183] In step 203, each third data fragment is encapsulated with the sixth intent to obtain the third protocol packet corresponding to each third data fragment.

[0184] Here, for each third data fragment, it is encapsulated in conjunction with the sixth intent information to generate the corresponding third protocol packet.

[0185] In step 204, multiple third protocol packets are serially sent to the terminal.

[0186] For example, 10 third-party protocol packets are serially sent to the terminal in the order of fragment numbers 1 to 10. After receiving the packets, the terminal verifies the fragmented data in sequence, parses and displays them as it receives them, first loading and displaying weather-related data, then loading and displaying stock market-related data, without waiting for the full data transmission to complete, thus achieving a smooth streaming query result display experience.

[0187] This application embodiment merges multiple independent streaming first intents into a single sixth intent, avoiding the problem of a surge in protocol packet number caused by independent fragmentation and encapsulation of multiple streaming intents. This reduces the frequency of interaction between the server and the terminal, saving network bandwidth and device computing power. The merged sixth intent uses the streaming fragmentation transmission logic, supporting the terminal to receive fragments and execute operations simultaneously, solving the stuttering problem of transmitting massive amounts of data at once. At the same time, fragmentation identifiers and checksums ensure data integrity and resumability. Multiple streaming intents are integrated into a set of ordered third protocol packets. The terminal only needs to process one set of fragmented data, without needing to distinguish the fragmentation sequences of multiple independent streaming intents. This simplifies the terminal's fragmentation reassembly, business parsing, and execution logic, reducing the terminal's memory usage and processing complexity.

[0188] In some embodiments, after receiving the target intent and all unmerged first intents, the terminal is configured to sequentially execute the operations corresponding to the target intent and the operations corresponding to the unmerged first intents based on the order in which the target intent and the unmerged first intents were sent. The terminal is also configured to determine the execution order of the multiple operations corresponding to the target intent, and sequentially execute the multiple operations corresponding to the target intent based on the execution order.

[0189] Here, the terminal executes the operations corresponding to the target intent and the unmerged first intent sequentially based on the protocol packets sent by the server, ensuring that the overall operation order is consistent with the expression logic of the user's original instructions. For the target intent (composed of multiple second intents), the target intent itself does not contain the execution order information of the operations. The terminal needs to determine the execution order of the multiple operations corresponding to the target intent and then execute them sequentially according to that execution order to avoid logical conflicts in the merged composite operations.

[0190] In this embodiment of the application, the terminal can determine the execution order of multiple operations corresponding to the target intent based on a preset operation priority rule base (the rule base is divided according to business scenarios and includes judgment dimensions such as core operation priority and basic operation priority).

[0191] For example, the instruction data is "Play XXX Season 2 Episode 3 in full screen, adjust the volume to 50%, check today's weather". The server sends protocol packets in the following order: the first protocol packet of the target intent (play XXX Season 2 Episode 3 in full screen) → the second protocol packet 1 of the unmerged first intent (adjust the volume to 50%) → the second protocol packet 2 of the unmerged first intent (check today's weather). The terminal parses the target intent protocol packet and splits it into two operations to be executed: operation 1 (play XXX Season 2 Episode 3) and operation 2 (full screen display). The terminal calls the preset video domain operation priority rule "content loading core operations take precedence over display attribute auxiliary operations", and determines the execution order to be operation 1 → operation 2. The terminal executes them serially according to the determined order: first, it executes "play XXX Season 2 Episode 3" to complete the loading and playback of the video stream, ensuring that the screen content is output normally; then it executes "full screen display" to switch the playback screen to full screen mode. Then it executes the operation of adjusting the volume to 50%, and then it executes the operation of checking today's weather.

[0192] In this embodiment, the global operation order follows the order of protocol packets sent by the server, ensuring that the terminal execution flow and the expression logic of the user's original instructions are consistent, and avoiding a decline in the interactive experience due to disordered order. For target intentions without built-in execution order, the terminal autonomously determines the operation order through preset priority rules, solving the problem of disordered execution of core and auxiliary operations and improving the stability of composite operation execution. The operation priority rule library supports dynamic expansion by domain (such as configuring rules separately for the video domain and the smart home domain). When adding new business scenarios, only the corresponding rules need to be added, without modifying the terminal's core execution logic, adapting to diverse intelligent interaction needs.

[0193] In some embodiments, when the target intent is issued before the unmerged first intent, and the multiple operations corresponding to the target intent include direct access operations and control operations, the direct access operations are executed before the control operations; the terminal is used to call the application corresponding to the target intent to display the details page of the video to be played corresponding to the direct access operation; the terminal is used to call the application to execute the direct access operation to jump to the playback interface of the video to be played; the terminal is used to call the application to execute the control operations during the playback of the video.

[0194] Here, the protocol packet corresponding to the target intent is sent to the terminal before the unmerged first intent protocol packet. The terminal processes all operations of the target intent first, and then executes the operations of the unmerged first intent. The core of direct access operations is to "locate and display the target content" (such as "play XXX Season 2 Episode 3"). After parsing the target intent, the terminal first calls the corresponding video application. Based on the parameters of the direct access operation (episode ID, number of episodes, copyright information, etc.), the application displays the details page of the video. The page contains core information such as the video cover, description, play button, and episode selection entry.

[0195] After the details page loads, the terminal automatically triggers the core command for direct access operations, calling the application's playback interface to redirect the details page to the video playback interface, simultaneously initiating the loading and playback of the video stream. The core of control-type operations is adjusting playback attributes (such as "full-screen display," "switch to 4K quality," or "fast forward to the 10-minute mark"), which relies on the normal loading of the video playback interface and the continuous playback of the video stream. After confirming that the video has entered playback mode, the terminal calls the application's control interface to execute all control-type operations sequentially, ensuring that control commands apply to the currently playing video and avoiding the "no playback content when control command is issued" exception.

[0196] For example, taking the user command "Play XXX Season 2 Episode 3 in full screen, adjust volume to 50%" as an example, the complete execution flow is as follows: The server first sends the first protocol packet containing the target intent "Play XXX Season 2 Episode 3 in full screen," and then sends the second protocol packet containing the unmerged first intent "Adjust volume to 50%." The target intent is split into two operations: direct access operations (play XXX Season 2 Episode 3) and control operations (full screen display). The terminal calls the video application, and based on the episode ID "XXX Season 2 Episode 3," displays the episode's details page (cover, synopsis, and "Play Now" button); the terminal triggers the "Play Now" command, jumps to the video playback interface, and starts playing XXX Season 2 Episode 3; the terminal performs the control operation: during video playback, it calls the application's display control interface to switch the playback interface to full screen mode; the terminal performs the unmerged first intent operation: after completing all operations of the target intent, it then executes the "Adjust volume to 50%" operation.

[0197] In some embodiments, the first protocol packet is sent to the terminal via a non-streaming delivery mode. The terminal is used to invoke the recognizer to parse the first protocol packet, obtain the first object packet, invoke the distributor to distribute the first object packet to the corresponding processor, and invoke the processor to control the corresponding application to execute the operation corresponding to the target intent.

[0198] Here, the first protocol packet may include a flag representing the non-streaming delivery mode. After receiving the first protocol packet, the terminal reads the flag and proceeds with the non-streaming delivery mode processing flow. The first object packet is a standardized executable data object generated by the terminal after parsing the non-streaming first protocol packet. It is the core relay carrier between the protocol packet (transport layer) and the processor (execution layer). The first object packet converts the structured characters (such as intent identifiers, operation parameters, data verification information, etc.) in the first protocol packet into an object-oriented data format (such as JSON objects, structure instances, etc.) that the terminal can directly recognize, eliminating the difference between the protocol transmission format and the execution layer data format, and realizing the conversion of "transmitted data → executable object".

[0199] This application's embodiments construct a standardized process for terminal-side intent processing through a three-tier architecture of recognizer, distributor, and processor. This avoids the confusion in processing logic for intents with different protocol formats and domains, and improves the parsing and execution efficiency of non-streaming protocol packets. The recognizer is responsible for protocol parsing, the distributor is responsible for routing and traffic distribution, and the processor is responsible for operation execution; each module has a single and independent responsibility. When adding a new business domain intent, only the corresponding processor needs to be added and the distributor mapping table updated; there is no need to modify the core parsing and distribution logic, thus enhancing the system's scalability.

[0200] In some embodiments, when the second protocol packet is sent to the terminal via a non-streaming delivery mode, the terminal invokes an identifier to parse the second protocol packet, obtains a second object packet, invokes a distributor to distribute the second object packet to the corresponding processor, and invokes the processor to control the corresponding application to execute the operation of the first intent corresponding to the second protocol packet. The second protocol packet may include a flag representing the non-streaming delivery mode. After receiving the second protocol packet, the terminal reads the flag and performs the non-streaming delivery mode processing flow.

[0201] In some embodiments, when a second protocol packet is sent to the terminal via streaming mode, the terminal is configured to call the recognizer to parse the first second protocol packet to obtain the first second object packet, call the distributor to distribute the first second object packet to the corresponding processor, set the pipeline instance corresponding to the processor, and call the processor to control the corresponding application to execute the operation corresponding to the first second object packet; the terminal is also configured to call the recognizer to parse the nth second protocol packet to obtain the nth second object packet, send the nth second object packet to the processor via the pipeline instance, and call the processor to control the corresponding application to execute the operation corresponding to the nth second object packet.

[0202] Here, the second protocol packet may include a marker representing the streaming delivery mode. Upon receiving the second protocol packet, the terminal reads the marker and proceeds with the streaming delivery mode processing flow. After receiving the first streaming second protocol packet from the server, the terminal calls the recognizer to parse the first second protocol packet and obtain the first second object packet. The distributor reads the target processor identifier of the second object packet and matches it with the corresponding dedicated processor (such as a video search processor or a real-time data processor). The terminal creates a dedicated pipeline instance for the matched processor. This pipeline instance is a dedicated data transmission channel between the processor and the terminal's protocol packet receiving module, used for the targeted forwarding of subsequent second protocol packets. It also marks the associated intent identifier of the pipeline to avoid confusion with pipelines of other streaming intents. After receiving the first second object packet, the processor calls the corresponding application to execute the operation corresponding to that data segment (such as displaying the first batch of video search results).

[0203] The terminal receives the nth second protocol packet (n≥2, corresponding to subsequent data fragments of the streaming intent) from the server. The terminal calls the recognizer to verify the fragment sequence number, integrity, and associated intent identifier of the nth protocol packet, converting it into the nth second object packet. This second object packet carries an intent identifier consistent with the first second object packet, used for matching pipeline instances. Based on the intent identifier of the nth second object packet, the terminal finds the created pipeline instance and sends the second object packet directly to the corresponding processor through the pipeline instance, without requiring the dispatcher to route and match again. The processor continuously receives subsequent second object packets through the pipeline instance, parses the fragmented data sequentially (such as the second and third batches of video search results), and calls the application to execute operations sequentially (such as loading more content on the same search results page). When the processor receives the last second object packet marked "Continue download flag = Completed", it completes the corresponding operation, automatically deletes the pipeline instance, and releases terminal resources.

[0204] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0205] The data processing method provided in this application is an intent merging scheme based on a large-scale artificial intelligence (AI) model. It merges intents within the same domain (e.g., playback) into a composite intent (corresponding to the target intent in the above embodiments). Upon receiving the composite intent, the service provider (e.g., the player) parses out the operation instructions carried within it (e.g., play episode X, full screen, switch resolution, etc.) and executes these instructions one by one to complete all the user's intent commands. This scheme reduces the number of times the user needs to input voice input and improves the user experience.

[0206] In a smart TV scenario, the user inputs voice commands (corresponding to the command data in the above embodiments) through a client. The voice commands are then processed by ASR (Automatic Speech Recognition) to obtain the command text, which is displayed at the bottom of the screen. Simultaneously, the command text is sent to the server's NLP (Natural Language Processing) service for intent recognition. The server then returns the intent, prompting the client to execute it.

[0207] Figure 13 This is a schematic diagram of the client interface for inputting voice commands provided in an embodiment of this application. Figure 1 See also Figure 13 The user inputs the voice command "Please continue playing XXX" through the terminal, and the text of the voice command is displayed in the input box 1301 at the bottom of the screen. The video playback application client 1302 also displays recommendation information for multiple videos on the interface. Figure 14 This is a schematic diagram of the client interface for instruction execution provided in the embodiments of this application. Figure 1 See also Figure 14The client executes the voice command "Help me continue playing XXX", displays the video of "XXX" on the client interface 1302, and displays the execution result "XXX has been opened for you" in the input box 1301.

[0208] Figure 15 This is a schematic diagram of the client interface for inputting voice commands provided in an embodiment of this application. Figure 2 See also Figure 15 The user inputs the voice command "turn off bullet comments" through the terminal, and the text of the voice command is displayed in the input box 1301 at the bottom of the screen. The video playback application client 1302 also displays bullet comments 1303 during video playback, such as "Looking forward to it, looking forward to it" and "Wow, it's here." Figure 16 This is a schematic diagram of the client interface for instruction execution provided in the embodiments of this application. Figure 2 See also Figure 16 When the client executes the voice command "Turn off the bullet comments", the bullet comments will no longer be displayed on the client interface 1302, and the execution result "Bullets have been turned off for you" will be displayed in the input box 1301.

[0209] The intent types (corresponding to the intent categories in the above embodiments) are described below. Based on the intent type, the protocol packets carrying the intent are classified into two types: streaming and non-streaming. Figure 17 This is a schematic diagram illustrating the delivery configuration of the protocol packet provided in an embodiment of this application. See also... Figure 17 The server returns protocol packets to the client in both streaming and non-streaming modes. If the intent type is manipulation or direct access, the protocol packet carrying that intent is sent via non-streaming mode. This intent is a single, complete intent, and the protocol packet is sent to the client along with the SSE event (full intent, event=intent_full). This protocol packet constitutes a complete intent protocol. If the intent type is video or vertical, the protocol packet carrying that intent is sent via streaming mode. The protocol packet is sent to the client in segments along with the SSE events (first intent segment event=intent_part_first, middle intent segment event=intent_part_middle, last intent segment event=intent_part_end).

[0210] Figure 18 This is a schematic diagram illustrating the client's processing flow of protocol packets according to an embodiment of this application. See also... Figure 18The complete protocol packet (data_full) is a non-streaming intent protocol packet, while protocol packets 1 (data_part1), 2 (data_part2), and 3 (data_part3) are streaming intent protocol packets. For the non-streaming intent protocol packets, the Recognizer 1801 identifies the complete protocol packet to obtain the object packet VoiceV1. The object packet VoiceV1 is then sent to the Protocol Dispatcher 1802, which distributes it to the corresponding Protocol Handler 1803.

[0211] For streaming intent protocol packets, Recognizer 1801 identifies the first protocol packet 1 (corresponding to the data fragment in the above embodiment) to obtain the first object packet VoiceV1 of the first fragment (i.e., the first protocol packet). Recognizer 1801 then sends the first object packet VoiceV1 to distributor 1802, which distributes it to the corresponding processor 1803. Processor 1803 sets up a pipeline instance 1804. Subsequent protocol packets, such as protocol packet 2, are sequentially identified by Recognizer 1801 to obtain the corresponding object packet VoiceV1, and then directly enter pipeline instance 1804, from where they are passed to processor 1803.

[0212] In this application embodiment, multiple intents may exist in the following ways: 1) Intents are unrelated and independent of each other, such as cross-domain (video + vertical category, video + system control), and same-domain but independent (video control: bullet comments, resolution). 2) Intents are dependent on each other, for example: the user input instruction data is "play XXX episode 15 at 25 minutes in full screen and switch to full-definition resolution to turn on bullet comments", the intent of this instruction data has direct access type and control type, and there are dependencies between multiple intents.

[0213] The following describes independent intent schemes. If the user input command data includes multiple streaming intents, the multiple streaming diagrams are merged into one streaming intent, so that the content of the two intents is delivered along with the same intent streaming. Figure 19 This is a schematic diagram illustrating the execution result of a streaming intent provided in an embodiment of this application. See also... Figure 19When a user inputs "I want to know today's stock market and weather," the convection diagrams "Check Stock Market" and "Check Weather" are merged to obtain a composite intent. This composite intent is then streamed to the terminal, causing the execution result to be displayed on the terminal interface: "Based on the current information, here is an overview of today's stock market and weather: Stock Market: XXXXX; Weather: XXXX." The terminal interface then displays "Answer complete. Press and hold the [voice button] to speak again."

[0214] If the user input instruction data includes both streaming and non-streaming intents, or vice versa, since there is no dependency between the multiple intents, the existing form of the protocol structure can be maintained, and the order of intent delivery can be determined according to the order of intents in the user instruction data. Figure 20 This is a schematic diagram of the delivery process for a combination of streaming intents and non-streaming intents provided in an embodiment of this application. Figure 1 See also Figure 20 The user input command data is "Recommend some movies and turn down the volume for me". The command data includes the streaming intent "Recommend movies" and the non-streaming intent "Turn down the volume". Following the order in the command data, the protocol packet 2001 for the streaming intent "Recommend movies" is sent first. Protocol packet 2001 includes the first intent fragment (intent_part_first), multiple intermediate intent fragments (intent_part_middle), and the final intent fragment (intent_part_end). Then, the complete protocol packet 2002 (intent_full) for the non-streaming intent "Turn down the volume" is sent.

[0215] Figure 21 This is a schematic diagram of the delivery process for a combination of streaming intents and non-streaming intents provided in an embodiment of this application. Figure 2 See also Figure 21 The user input command data is "Play episode 15 of XXX and recommend several similar TV series". The command data includes a non-streaming intent "Play episode 15 of XXX" and a streaming intent "Recommend TV series". The protocol packet 2101 (intent_full) for the non-streaming intent "Play episode 15 of XXX" is sent first, followed by the protocol packet 2102 for the streaming intent "Recommend TV series". Protocol packet 2102 includes a first intent fragment (intent_part_first), multiple intermediate intent fragments (intent_part_middle), and a final intent fragment (intent_part_end).

[0216] Figure 22 This is a schematic diagram illustrating the delivery process of streaming intents and combinations of streaming intents provided in an embodiment of this application. See also... Figure 22The user input command data is "Play episode 15 of XXX and adjust the volume to 50%". The command data includes the non-streaming intent "Play episode 15 of XXX" and the non-streaming intent "Adjust volume". Following the order in the command data, the protocol packet 2201 (intent_full) for the non-streaming intent "Play episode 15 of XXX" is sent first, followed by the protocol packet 2202 (intent_full) for the non-streaming intent "Adjust volume".

[0217] Protocol distribution and execution: The server sends out intents sequentially, and the terminal also needs to distribute and execute these intents sequentially. It is necessary to ensure that the previous intent is completed before the next intent is executed. Currently, on the SDK side, the protocol distribution and execution are synchronous. However, on the business side, there is synchronous execution within the SDK and asynchronous execution across processes such as scenario matching. The execution results cannot all be processed synchronously.

[0218] The following describes a multi-intent scheme with interdependencies. For example, if the user inputs the instruction "Play episode 15 of XXX at the 10th minute in 4K full screen and turn on the subtitles", the multiple intents included in this instruction are dependent on each other. The order of the multiple intents is as follows: Direct access to video (VIDEO: SEARCH): index = 15; Playback control (VIDEO_PLAYER_CONTROL: ACTION_SEEK / OPEN_DANMU / 4K resolution / FULL_SCREEN).

[0219] In one approach, intents are executed sequentially. The server needs to understand the order of dependent intents, sending the direct intent first, followed by the playback control intent. The advantage of this approach is the reuse of the protocol parsing and distribution framework. Disadvantages include: significant workload for business-side modifications, coupling between business modules, complex inter-module logic, and the need for later-executed business components to be aware of and await the results from earlier-executed business components.

[0220] In another approach, intents are merged for execution. Intent merging prioritizes intents within the same domain, as consumers of intents within the same domain also come from the same business module. For example, in the video domain, intents can be divided into two types: direct video access and playback control, which are also the most commonly used intents by users within an application (APP). Multiple intent combinations based on these two types can be categorized into two types: Direct access intent + playback control intent: suitable for any scenario, for example, playing episode 15 of XXX in 4K full-screen mode at the 10th minute. Playback control intent + playback control intent: suitable for playback scenarios, for example, switching to 4K and fast-forwarding to the 10th minute; turning on subtitles and switching to 4K. The server can merge multiple intents within the same domain into a new intent, or use existing intents, simply adding an operation (corresponding to the operation field in the above embodiments) to the intent. The service (corresponding to the target category in the above embodiments) and operation can be: service = video (VIDEO), operation = search and play control (SEARCH_AND_PLAYER_CONTROL). Then, the operation that each intention is to perform is used as the value of the slot type (slot_type) in the slot. Since the slot is a JSON object, the expansion space of the value is relatively large.

[0221] For example, if the user inputs the instruction data as "Play episode 15 of XXX at the 10th minute in 4K full screen", the combined intent's protocol content format (corresponding to the structure in the above embodiment) is as follows: { "intention":{ "Services": "Videos", "Actions": "Search and Playback Controls" }, "Content":{"Album":{"Direct Access":Yes,"Album ID":"123123","Number of Episodes":15}} "Intent Slot":[ {"Slot Type":"Fast Forward", "Value":"10"}, {"Slot Type": "Enable Bullet Comments"}, {"Slot Type": "4K Resolution"}, {"Slot Type": "Full Screen"} ] } For example, if the user inputs the instruction "Switch to 4K and fast forward to the 10th minute", the combined intent's protocol content format (corresponding to the structure in the above embodiment) is as follows: { "intention":{ "Services": "Playback Control", "Operations": "Multicast Control Operations" }, "Intent Slot":[ {"Slot Type":"Fast Forward", "Value":"10"}, {"Slot Type": "4K Resolution"} ] } The advantages of this solution include: no need to change the protocol structure; reuse of the protocol parsing and distribution framework; operations in the intent can be converged to a single business processor for execution; the server does not need to care about the order of operation execution, the client decides which operation to execute first; there is no coupling between business processes, resulting in fast response speed and a good user experience.

[0222] Protocol execution: After the intent is merged, the business will execute multiple slots in the operation serially. Based on the aforementioned multiple slots in the merged new protocol package, there may be dependencies, or the next slot must wait for the previous one to finish before it can be executed. Therefore, the execution of the operation cannot be placed in the voice SDK. All slots must be packaged together and sent to the business side, and the business side will perform the sequential execution of these slots. This is because only the business side knows the execution order and the execution result.

[0223] Figure 23 This is a schematic diagram illustrating the process of intent processing between the server and the terminal according to an embodiment of this application. See also... Figure 23 The user sends a multi-intent command to the terminal. After receiving the multi-intent command, the terminal's recognizer 2301 requests the intent from the server 2302. The server 2302 then initiates intent parsing with the large language model 2303. The large language model 2303 parses the direct intent and playback control intent from the multi-intent command, merges the direct intent and playback control intent to obtain a composite intent, and sends the composite intent to the server 2302. The server 2302 distributes the intent, sending the composite intent to the terminal's recognizer 2301. The recognizer 2301 parses the composite intent, obtains the object packet VoiceV1 through the intent protocol, and then sends the object packet to the distributor 2304, which allocates the object packet to the corresponding processor 2305. The processor 2305 parses the direct parameters and playback parameters from the object packet, generates the intent, and launches the details page. The video application displays the details page on the interface, parses the intent, initiates video playback, and then sets the playback parameters.

[0224] Figure 24 This is a schematic diagram of the business side provided in an embodiment of this application. See also... Figure 24The business-side process includes the following steps 2401 to 2405.

[0225] Step 2401, package composite intent.

[0226] Here, the voice application (APP) in the terminal parses the user's voice command to obtain a composite intent that combines the direct intent and the broadcast control intent, and then packages the composite intent.

[0227] Step 2402: Launch the details page.

[0228] Here, after the voice application triggers the direct intent, it opens the details page (the details page of the video to be played) and enters the corresponding video application (APP).

[0229] Step 2403: Initialize the video application.

[0230] Here, after the video application is activated, it executes an initialization process, which includes: loading the basic resources required for the video application to run, and parsing the direct parameters in the composite intent on the details page.

[0231] Step 2404: Start playing the video and parse the playback control instructions.

[0232] Here, the video application jumps to the corresponding time frame of the video based on the direct parameters to start playing the video. It detects the playback status and parses one or more playback control commands from the intent.

[0233] Step 2405: Execute broadcast control instructions according to the broadcast control status.

[0234] Here, when the playback control status indicates that the video is playing, the playback control instructions in the playback control intent are executed according to the playback control parameters. Playback control instructions need to be executed sequentially; the next instruction can only be executed after the previous one has finished. If a restart operation is involved, the next operation can only be executed after successful restart, i.e., after receiving the playback callback; otherwise, invalid settings may occur. For example, after confirming successful video playback control, the resolution can be switched.

[0235] This application embodiment allows users to express multiple intentions with a single sentence, eliminating the need to repeatedly input voice commands, thus improving user experience and reducing the number of requests to the server's natural language processing (NLP) service, thereby reducing server load and network bandwidth consumption.

[0236] The following description continues to illustrate the exemplary structure of the data processing device 233 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the data processing device 233 of the memory 230 may include: The intent recognition module 2331 is used to perform intent recognition on the instruction data when the input instruction data of the object is obtained, so as to obtain multiple first intents of the object; The pattern recognition module 2332 is used to perform pattern recognition on each first intent, obtain the distribution pattern of each first intent, and filter out multiple second intents with a non-streaming distribution pattern from multiple first intents. Domain identification module 2333 is used to identify the domain of each second intent and obtain the domain to which each second intent belongs; The merging module 2334 is used to merge at least two second intentions to obtain the target intention when at least two second intentions belong to the same domain. The delivery module 2335 is used to deliver the target intent and the unmerged first intent to the terminal, wherein the terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

[0237] In some embodiments, the delivery mode includes a streaming delivery mode or a non-streaming delivery mode. The pattern recognition module 2332 is further configured to classify each first intent to obtain an intent category; when the intent category of the first intent is a first preset category, the delivery mode of the first intent is determined to be a streaming delivery mode; when the intent category of the first intent is a second preset category, the delivery mode of the first intent is determined to be a non-streaming delivery mode.

[0238] In some embodiments, the domain identification module 2333 is further configured to obtain a word set for each preset domain from a domain lexicon; determine the semantic similarity between the second intention and the word set of each preset domain for each second intention; and determine the preset domain corresponding to the maximum semantic similarity as the domain to which the second intention belongs.

[0239] In some embodiments, the merging module 2334 is further configured to determine a target category based on the intent category of each of the at least two second intents; when a structure of the target category is stored locally, an operation field is added to the structure, and each second intent is filled into a slot in the operation field to obtain the target intent; when a structure of the target category is not stored locally, a blank structure of the target category is created, and an operation field is created in the blank structure, and each second intent is filled into a slot in the operation field to obtain the target intent.

[0240] In some embodiments, the merging module 2334 is further configured to determine the same intent category as the target category when at least two second intents have the same intent category; and to determine a third preset category as the target category when at least two second intents have different intent categories.

[0241] In some embodiments, the sending module 2335 is further configured to obtain first data required to perform the operation corresponding to the target intent, and encapsulate the target intent and the first data to obtain a first protocol packet; encapsulate the unmerged first intent to obtain a second protocol packet; and serially send the first protocol packet and the second protocol packet to the terminal according to the order of the target intent and the unmerged first intent in the instruction data.

[0242] In some embodiments, the delivery module 2335 is further configured to, when each unmerged first intent includes a third intent whose delivery mode is a non-streaming delivery mode, obtain second data required to perform the operation corresponding to the third intent for each third intent; encapsulate the third intent and the second data to obtain a second protocol packet corresponding to the third intent.

[0243] In some embodiments, the delivery module 2335 is further configured to, when the number of unmerged first intents is 1 and the delivery mode is streaming delivery mode, obtain the third data required to perform the operation corresponding to the unmerged first intent; divide the third data into multiple first data fragments based on the unmerged first intents; and encapsulate each first data fragment with the unmerged first intent to obtain a second protocol packet corresponding to each first data fragment.

[0244] In some embodiments, the delivery module 2335 is further configured to: merge at least two fourth intentions to obtain a fifth intention when the unmerged plurality of first intentions include at least two fourth intentions whose delivery mode is streaming delivery mode; obtain fourth data required to perform the operation corresponding to the fifth intention; and divide the fourth data into a plurality of second data fragments based on the fifth intention; and encapsulate each second data fragment with the fifth intention to obtain a second protocol packet corresponding to each second data fragment.

[0245] In some embodiments, the delivery module 2335 is further configured to: merge the multiple first intentions to obtain a sixth intention when there is no second intention with a delivery mode of non-stream delivery mode among the multiple first intentions; obtain the fifth data required to perform the operation corresponding to the sixth intention; divide the fifth data into multiple third data fragments based on the sixth intention; encapsulate each third data fragment with the sixth intention to obtain a third protocol packet corresponding to each third data fragment; and serially deliver the multiple third protocol packets to the terminal.

[0246] In some embodiments, the intent recognition module 2331 is further configured to convert instruction data into instruction text; extract multiple keywords from the instruction text and determine a first semantic vector for each keyword; fuse the first semantic vectors of multiple keywords to obtain a second semantic vector, and classify the second semantic vector to obtain a probability distribution, wherein the probability distribution includes the probability that the second semantic vector belongs to each preset intent; and determine multiple preset intents with a probability greater than a preset threshold as multiple first intents.

[0247] In some embodiments, the intent recognition module 2331 is further configured to convert instruction data into instruction text; construct prompt words based on the instruction text, and input the prompt words into a language model to obtain multiple first intents, wherein the prompt words are used to guide the language model to parse the intent expressed in the instruction text.

[0248] This application provides a computer program product, which includes a computer program or computer executable instructions. The processor of an electronic device executes the computer executable instructions or computer program, causing the electronic device to perform the data processing method described in this application.

[0249] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the data processing method provided in this application. For example, ... Figure 3 The data processing method is shown.

[0250] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0251] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0252] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0253] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located in one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0254] In summary, the embodiments of this application enable users to input multiple intents with a single sentence, eliminating the need for repeated voice commands, thus improving interaction efficiency and enhancing user experience. Furthermore, these embodiments can reduce the request pressure on the server interface, further lowering bandwidth consumption.

[0255] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: When instruction data input by an object is obtained, intent recognition is performed on the instruction data to obtain multiple first intents of the object; For each first intent, a delivery pattern is identified to obtain the delivery pattern of each first intent, and from the plurality of first intents, a plurality of second intents whose delivery pattern is a non-streaming delivery pattern are selected; For each second intent, perform domain identification to obtain the domain to which each second intent belongs; When at least two second intentions belong to the same domain, the at least two second intentions are merged to obtain the target intention; The target intent and the unmerged first intent are sent to the terminal, wherein the terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

2. The method according to claim 1, characterized in that, The delivery mode includes either streaming delivery mode or non-streaming delivery mode; The step of performing delivery pattern recognition on each first intent to obtain the delivery pattern of each first intent includes: For each first intent, the first intent is classified to obtain the intent category of the first intent; When the intent category of the first intent is the first preset category, the delivery mode of the first intent is determined to be the streaming delivery mode; When the intent category of the first intent is the second preset category, the delivery mode of the first intent is determined to be the non-streaming delivery mode.

3. The method according to claim 1, characterized in that, The step of performing domain identification on each second intent to obtain the domain to which each second intent belongs includes: Retrieve the word set for each preset domain from the domain thesaurus; For each second intent, determine the semantic similarity between the second intent and the word set of each preset domain; The preset domain corresponding to the maximum semantic similarity is determined as the domain to which the second intent belongs.

4. The method according to claim 1, characterized in that, The merging of at least two second intentions to obtain the target intention includes: The target category is determined based on the intent category of each of at least two second intents; When the target category structure is stored locally, an operation field is added to the structure, and each second intent is filled into a slot in the operation field to obtain the target intent. When the target category structure is not stored locally, a blank structure for the target category is created, and an operation field is created in the blank structure. Each second intent is filled into a slot in the operation field to obtain the target intent.

5. The method according to claim 4, characterized in that, The determination of the target category based on the intent category of each of at least two second intents includes: When at least two second intentions have the same intention category, the same intention category is determined as the target category; When at least two second intentions have different intention categories, the third preset category is determined as the target category.

6. The method according to claim 1, characterized in that, Sending the target intent and the unmerged first intent to the terminal includes: Obtain the first data required to execute the operation corresponding to the target intent, and encapsulate the target intent and the first data to obtain a first protocol packet; The unmerged first intent is encapsulated to obtain a second protocol packet; The first protocol packet and the second protocol packet are serially sent to the terminal according to the order of the target intent and the unmerged first intent in the instruction data.

7. The method according to claim 6, characterized in that, The encapsulation process of the unmerged first intent to obtain a second protocol packet includes: When each of the unmerged first intents includes a third intent whose delivery mode is the non-streaming delivery mode, for each third intent, second data required to perform the operation corresponding to the third intent is obtained; The third intent and the second data are encapsulated to obtain the second protocol packet corresponding to the third intent.

8. The method according to claim 6, characterized in that, The encapsulation process of the unmerged first intent to obtain a second protocol packet includes: When the number of unmerged first intents is 1 and the delivery mode is streaming delivery mode, obtain the third data required to perform the operation corresponding to the unmerged first intent; Based on the unmerged first intent, the third data is divided into multiple first data fragments; Each first data fragment is encapsulated with the unmerged first intent to obtain a second protocol packet corresponding to each first data fragment.

9. The method according to claim 6, characterized in that, The encapsulation process of the unmerged first intent to obtain a second protocol packet includes: When multiple unmerged first intents include at least two fourth intents whose delivery mode is streaming delivery mode, the at least two fourth intents are merged to obtain a fifth intent; Obtain the fourth data required to execute the operation corresponding to the fifth intent, and divide the fourth data into multiple second data fragments based on the fifth intent; Each second data fragment is encapsulated with the fifth intent to obtain a second protocol packet corresponding to each second data fragment.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: When there is no second intent whose delivery mode is non-stream delivery mode among the plurality of first intents, the plurality of first intents are merged to obtain a sixth intent; Obtain the fifth data required to execute the operation corresponding to the sixth intent, and divide the fifth data into multiple third data fragments based on the sixth intent; Each of the third data fragments is encapsulated with the sixth intent to obtain a third protocol packet corresponding to each of the third data fragments; Multiple third protocol packets are serially sent to the terminal.

11. The method according to any one of claims 1 to 9, characterized in that, The intention recognition process on the instruction data yields multiple first intentions of the object, including: Convert the instruction data into instruction text; Multiple keywords are extracted from the instruction text, and a first semantic vector is determined for each keyword; A first semantic vector is obtained by fusing multiple keywords to obtain a second semantic vector, and the second semantic vector is classified to obtain a probability distribution, wherein the probability distribution includes the probability that the second semantic vector belongs to each preset intent; The plurality of preset intentions with a probability greater than a preset threshold are determined as the plurality of first intentions.

12. The method according to any one of claims 1 to 9, characterized in that, The intention recognition process on the instruction data yields multiple first intentions of the object, including: Convert the instruction data into instruction text; Based on the instruction text, prompt words are constructed and input into a language model to obtain the plurality of first intentions, wherein the prompt words are used to guide the language model to parse the intentions expressed in the instruction text.

13. The method according to any one of claims 1 to 9, characterized in that, The terminal is used to sequentially execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent based on the order in which the target intent and the unmerged first intent are sent. The terminal is also used to determine the execution order of multiple operations corresponding to the target intent, and to execute the multiple operations corresponding to the target intent serially based on the execution order.

14. A data processing apparatus, characterized in that, The device includes: The intent recognition module is used to perform intent recognition on the instruction data when the object inputs it, and obtain multiple first intents of the object; The pattern recognition module is used to perform distribution pattern recognition on each first intent to obtain the distribution pattern of each first intent, and to filter out a plurality of second intents from the plurality of first intents whose distribution pattern is a non-streaming distribution pattern. A domain identification module is used to identify the domain of each second intent and obtain the domain to which each second intent belongs; The merging module is used to merge at least two second intentions to obtain a target intention when at least two second intentions belong to the same domain. The delivery module is used to deliver the target intent and the unmerged first intent to the terminal, wherein the terminal is used to execute the operation corresponding to the target intent and the operation corresponding to the unmerged first intent.

15. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the data processing method according to any one of claims 1 to 13.

16. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the data processing method according to any one of claims 1 to 13.

17. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the data processing method according to any one of claims 1 to 13.

Images