Streaming data processing method and device, equipment, medium and product
By defining a multi-level labeling system for streaming data and using a state stack to manage label nesting, the problem of identifying nested labels in streaming data is solved, enabling accurate parsing and real-time processing of streaming data.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HANGZHOU NETEASE ZHIQI TECH CO LTD
- Filing Date
- 2025-12-15
- Publication Date
- 2026-05-12
AI Technical Summary
Existing technologies struggle to accurately identify and process nested structure tags in streaming data, leading to inaccurate data parsing.
A multi-level tag system is predefined for streaming data. The correct nesting relationship of tags is ensured through hierarchical validation, the nesting state of tags is managed using a state stack, the tag boundaries are matched using regular expressions, and incomplete tags are handled through a caching mechanism.
This ensures the accuracy of streaming data processing, avoids parsing errors, and improves the real-time performance and stability of data processing.
Smart Images

Figure CN122019599A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, specifically to methods, apparatus, equipment, media, and products for processing streaming data. Background Technology
[0002] Stream processing enables real-time computation on continuous data streams. For example, it can process and analyze continuous data streams output in real time from large language models (LLMs). This technology is mainly applied in LLM streaming generation scenarios.
[0003] Currently, existing solutions for streaming data processing struggle to accurately identify the label structure in streaming data, particularly nested labels, which affects the accuracy of data parsing. Summary of the Invention
[0004] In view of this, this application provides a method, apparatus, device, medium and product for processing streaming data to solve the problem of difficulty in accurately processing multi-layered labels in streaming data.
[0005] In a first aspect, this application provides a method for processing streaming data, the method comprising: Acquire the target streaming data to be processed; The target streaming data is labeled to determine the target labels in the target streaming data; the target labels are predefined with corresponding label levels. The target tag is validated according to its tag hierarchy. If the target tag passes the hierarchical verification, the target tag is parsed accordingly.
[0006] Secondly, this application provides a streaming data processing apparatus, the apparatus comprising: The acquisition module is used to acquire the target streaming data to be processed; The identification module is used to identify tags in the target streaming data and determine the target tags in the target streaming data; the target tags are predefined with corresponding tag levels; The processing module is used to perform hierarchical verification on the target tag according to the tag hierarchy of the target tag; The parsing module is used to perform corresponding parsing processing on the target tag when the target tag passes the hierarchical verification.
[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the streaming data processing method of the first aspect or any corresponding embodiment described above.
[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the streaming data processing method of the first aspect or any corresponding embodiment described above.
[0009] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the streaming data processing method of the first aspect or any corresponding embodiment described above.
[0010] The streaming data processing method provided in this application predefines multiple levels of labels for streaming data, forming a nested multi-layered label system. For the target streaming data to be processed, the layer verification can be performed according to the label level of the target labels, thereby verifying the nesting relationship and legality of the target labels, ensuring the correct nesting relationship of the labels, guaranteeing the accuracy of subsequent data processing, and effectively avoiding parsing errors and other problems. Attached Figure Description
[0011] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0012] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application; Figure 2 This is a schematic flowchart of a first method for processing streaming data according to an embodiment of this application; Figure 3 This is a schematic diagram of a second process for processing streaming data according to an embodiment of this application; Figure 4 This is a flowchart of tag segmentation and caching processing according to an embodiment of this application; Figure 5 This is a schematic diagram of a label integrity detection according to an embodiment of this application; Figure 6 This is a schematic diagram of a two-level tag architecture according to an embodiment of this application; Figure 7This is a schematic diagram of a hierarchical verification process according to an embodiment of this application; Figure 8 This is a flowchart of the fault-tolerant processing for verification failure according to an embodiment of this application; Figure 9 This is a schematic diagram of a state stack management mechanism according to an embodiment of this application; Figure 10 This is a schematic diagram of the state stack change process according to an embodiment of this application; Figure 11 This is a schematic diagram of the label recognition process according to an embodiment of this application; Figure 12 This is a schematic diagram of a third method for processing streaming data according to an embodiment of this application; Figure 13 This is a schematic diagram of the lifecycle management of large model tool calls according to an embodiment of this application; Figure 14 This is a flowchart of a tool invocation processing mechanism according to an embodiment of this application; Figure 15 This is a schematic diagram of the streaming accumulation processing of AI tool parameters according to an embodiment of this application; Figure 16 This is a schematic diagram of the coordination mechanism between tool invocation and content generation according to an embodiment of this application; Figure 17 This is a schematic diagram of an overall architecture of a streaming data processing method according to an embodiment of this application; Figure 18 This is a structural block diagram of a streaming data processing apparatus according to an embodiment of this application; Figure 19 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0014] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.
[0016] Currently, the main technical solutions in the field of streaming data processing are as follows: 1. Simple text stream processing: This involves processing the text stream character by character or line by line, lacking the ability to recognize structured data. 2. Regular expression-based tag matching: Uses regular expressions to identify specific tags, but cannot handle complex nested structures; 3. WebSocket data stream processing: This is for real-time communication data stream processing, mainly used to ensure real-time communication, but it lacks intelligent content recognition.
[0017] To address issues such as the lack of intelligent tag recognition (e.g., inability to automatically identify and classify different types of data blocks based on business logic) or the absence of a hierarchical verification mechanism (e.g., inability to ensure the correct nesting relationship of tags, easily leading to parsing errors), this application provides a method for processing streaming data. This method predefines multiple levels of tags for the streaming data, forming a nested multi-layered tag system. For the target streaming data to be processed, hierarchical verification can be performed based on the tag level of the target tags. This verifies the hierarchical nesting relationship and legality of the target tags, ensuring the correct nesting relationship of the tags, guaranteeing the accuracy of subsequent data processing, and effectively avoiding parsing errors.
[0018] As one optional application scenario in the embodiments of this application, such as Figure 1 As shown, application 101 is installed in terminal device 110, and user 130 can interact with application 101 through terminal device 110 and / or access device of terminal device 110.
[0019] For example, application 101 can be any application or browser capable of interacting with the LLM. For instance, application 101 could be a question-and-answer interactive application, such as a text-to-text application, an image-to-text application, etc. Figure 1 In the application scenario shown, if application 101 is active, the terminal device 110 can display the interface 102 of application 101. The interface 102 may include various pages that application 101 can provide, such as interactive pages, settings pages, query pages, etc.
[0020] In some embodiments, terminal device 110 is communicatively connected to server 120 to provide services to application 101. Terminal device 110 may be a mobile terminal, fixed terminal, or portable terminal, etc., including but not limited to mobile phones, desktop computers, laptop computers, multimedia tablets, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of interface, and server 120 may be various types of computing systems or servers capable of providing computing power, including but not limited to mainframes, edge computing nodes, computing devices in cloud environments, etc.
[0021] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this application.
[0022] According to an embodiment of this application, a method for processing streaming data is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0023] This embodiment provides a method for processing streaming data, which can be used in the aforementioned terminal devices or servers. Figure 2 This is a flowchart of a streaming data processing method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps.
[0024] Step S201: Obtain the target streaming data to be processed.
[0025] In this embodiment, the real-time generated streaming data can be processed accordingly, such as parsing. For ease of description, the streaming data to be processed is referred to as the target streaming data.
[0026] Generative large language models typically output their generated content as streaming data. For example, in response to a user's question, a large language model can generate a streaming answer. In this embodiment, the target streaming data can specifically be the data stream output by the large language model.
[0027] Step S202: Perform label recognition on the target streaming data to determine the target labels in the target streaming data; the target labels are predefined with corresponding label levels.
[0028] In this embodiment, labels are defined for the output of the large language model, and multi-level labels are defined to form multi-level nested labels. Furthermore, each label has a predefined corresponding level, i.e., a label level. For example, if the label system is divided into first-level labels and second-level labels, and a first-level label can be the parent label of a second-level label, then the label level of the first-level label is first-level, and the label level of the second-level label is second-level.
[0029] Furthermore, the target streaming data contains one or more labels, and these labels can be extracted by label recognition. For ease of description, the labels in the target streaming data are referred to as target labels. It can be understood that each target label also has a corresponding label hierarchy.
[0030] Step S203: Perform hierarchical verification on the target tag according to the tag hierarchy of the target tag.
[0031] In this embodiment, the target label itself has a label hierarchy, and the target label also has a certain actual hierarchy in the target streaming data. If the predefined label hierarchy of the target label is different from the actual hierarchy, it can be said that the target label in the target streaming data is abnormal and cannot pass the hierarchy verification.
[0032] Conversely, if the predefined tag level of the target tag is the same as the actual level, it can be basically concluded that the target tag in the target streaming data is normal and can pass the level verification.
[0033] Step S204: If the target tag passes the hierarchical verification, perform corresponding parsing processing on the target tag.
[0034] If the target tag passes the hierarchy validation, it means that the target tag is a correct tag. At this time, the target tag can be parsed according to the preset parsing method, such as parsing the attribute information in the target tag, and then combining the hierarchy relationship between various tags to achieve comprehensive parsing. Conversely, if the target tag fails the hierarchy validation, it means that the target tag has an error, and it can be processed in other ways, such as treating the target tag as plain text and performing text processing.
[0035] The streaming data processing method provided in this embodiment predefines multiple levels of tags for streaming data, forming a nested multi-layered tag system. For the target streaming data to be processed, it can perform hierarchical verification based on the tag level of the target tags, thereby verifying the hierarchical nesting relationship and legality of the target tags, ensuring the correct nesting relationship of the tags, guaranteeing the accuracy of subsequent data processing, and effectively avoiding parsing errors and other problems.
[0036] This embodiment provides a method for processing streaming data, which can be used in the aforementioned terminal devices or servers. Figure 3This is a flowchart of a streaming data processing method according to an embodiment of this application, such as... Figure 3 As shown, the process includes the following steps.
[0037] Step S301: Obtain the target streaming data to be processed. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.
[0038] Step S302: Perform label recognition on the target streaming data to determine the target labels in the target streaming data; the target labels are predefined with corresponding label levels.
[0039] The streaming data generated by the large language model is segmented, which can lead to incomplete streaming data received by the backend for processing, especially since some tags may be incomplete. This necessitates waiting, and the processing capacity for incomplete or erroneous tags is limited, resulting in insufficient fault tolerance and impacting the real-time performance of streaming data processing. In this embodiment, by detecting the integrity of the target streaming data, complete data can be processed promptly.
[0040] Specifically, step S302, "to identify the target streaming data and determine the target label in the target streaming data", may include steps S3021 to S3022.
[0041] Step S3021: Perform integrity checks on the target streaming data to determine the integrity of the data in the target streaming data.
[0042] In this embodiment, after acquiring the target streaming data, its integrity is first checked, such as the integrity of the tags, and then the complete data can be extracted. It can be understood that if the target streaming data does not contain incomplete data (e.g., no incomplete tags), then the target streaming data can be directly treated as complete data.
[0043] In some optional implementations, step S3021, "perform integrity detection on the target streaming data to determine the complete data in the target streaming data", may include steps A1 to A2.
[0044] Step A1: Determine whether there are incomplete labels in the target streaming data.
[0045] Step A2: In the case of incomplete labels, treat all data in the target streaming data except for the incomplete labels as complete data.
[0046] In this embodiment, to address the problem that tags may be split during streaming transmission, the integrity of each tag in the target streaming data can be detected. If there is an incomplete tag in the target streaming data, it can be determined that the incomplete tag cannot be directly processed. At this time, the data in the target streaming data other than the incomplete tag can be used as complete data. Conversely, if there is no incomplete tag in the target streaming data, the entire target streaming data can be used as the complete data.
[0047] For example, taking the XML format as an example, the target streaming data is: content<file type=. The "<" here is the start character of the tag "file", and the content following it is incomplete. Therefore, it contains the incomplete tag "<file type=", and the remaining content "content" can be used as complete data.
[0048] Optionally, each tag generally has a corresponding start character and end character. In this embodiment, based on the positional relationship between the start character and the end character, it is determined whether there is an incomplete tag in the target streaming data. Specifically, step A1, "Determine whether there is an incomplete tag in the target streaming data", includes steps A11 to A13.
[0049] Step A11, search in the target streaming data for: the earliest start character and the earliest end character, and / or, the last start character and the last end character.
[0050] In the case where the earliest start character is after the earliest end character, it is determined that there is an incomplete tag in the target streaming data, and the partial data before the earliest end character in the target streaming data is used as the incomplete tag.
[0051] In the case where the last start character is after the last end character, it is determined that there is an incomplete tag in the target streaming data, and the partial data after the last start character in the target streaming data is used as the incomplete tag.
[0052] In this embodiment, under normal circumstances, the earliest start character and the earliest end character in the target streaming data are the two characters of the first tag, and the start character is in front and the end character is behind. If the earliest start character is after the earliest end character, it means that the first tag character in the target streaming data is the end character, which is obviously abnormal. Therefore, it can be determined that there is an incomplete tag in the target streaming data at this time; and, the partial data before the earliest end character in the target streaming data corresponds to an incomplete tag.
[0053] Similarly, for the last start character and the last end character in the target streaming data, normally, the two are the two characters of the last tag, and the start character is in the front and the end character is in the back. If the last start character is after the last end character, it means that the last tag character in the target streaming data is the start character, which is obviously abnormal. Therefore, it can be determined that there is an incomplete tag in the target streaming data at this time; and, the part of the data after the last start character in the target streaming data is used as the incomplete tag.
[0054] It can be understood that for a target streaming data, the incomplete tags identified in step A12 and step A13 may exist simultaneously.
[0055] Taking the discrimination method shown in step A13 as an example, Table 1 below shows the comparison of the detection results of different streaming data.
[0056] Table 1
[0057] The processing method in Table 1 above is the processing method for streaming data, which will be described later.
[0058] Step S3022, perform label recognition on the complete data to determine the target label in the complete data.
[0059] For the complete data therein, it has a correct and complete tag. Therefore, at this time, only the tag in the complete data needs to be recognized, that is, the target label can be determined.
[0060] Optionally, the method further includes: in the case of an incomplete tag, storing the incomplete tag in the cache, or, forming a complete tag by combining the incomplete tag with the data recorded in the cache to parse the complete tag.
[0061] In this embodiment, in the case where the incomplete tag is at the tail position of the first streaming data (the last start character is after the last end character), the incomplete tag is stored in the cache; in the case where the incomplete tag is at the head position of the first streaming data (the first start character is after the first end character), the incomplete tag is combined with the data recorded in the cache to form a complete tag, and the data recorded in the cache is deleted. At this time, this complete tag can also be used as a target tag to perform subsequent processing.
[0062] Figure 4 Shows a flowchart of tag splitting and cache processing. As Figure 4 shown, for the first data block 1, process the complete content "content" (i.e., the complete data), and cache the incomplete tag: <file type=. After receiving the second data block 2, the tag in the cache "<file type="”与数据块2中的不完整标签""create"">Merge them to get the complete tags: <file type="create">At this point, the complete data can specifically be: <file type="create">file content。
[0063] In another example, if the streaming data block 1 is: start content<file type="cre, then process: start content, and cache: <file type="cre.
[0064] Then the streaming data block 2 is received: ate" path="test.js">content. At this time, the merged result is: <filetype="create" path="test.js". Therefore, at this time, the complete file tag can be processed, and the original content: content can be processed.
[0065] Then the streaming data block 3 is received:< / file> The end content is complete and can be processed directly.
[0066] Figure 5 This illustrates a schematic diagram of tag integrity detection. For example... Figure 5 As shown, for the received data stream (i.e., the target streaming data), tag integrity detection can be implemented based on the positions of the start character "<" and the end character ">". If there are incomplete tags, they are cached or merged with existing cached data (i.e., previously cached incomplete tags). Furthermore, the complete data is sorted out and processed directly to identify the target tags. The target tags are then passed to the tag recognizer for hierarchical verification.
[0067] In this embodiment, the integrity of tags can be dynamically detected, complete content and incomplete tags can be intelligently separated, and tags across data blocks can be processed using a caching mechanism to achieve tag reorganization and ensure processing continuity.
[0068] Step S303: Perform hierarchical verification on the target tag based on its tag hierarchy. For details, please refer to [link to relevant documentation]. Figure 2 Step S203 of the illustrated embodiment will not be described again here.
[0069] In some optional implementations, step S303, "performing hierarchical verification of the target label based on its label hierarchy," may include steps B1 to B2.
[0070] Step B1: If the target label is the start label, determine whether the label level of the start label matches the current stack depth of the state stack; the state stack is used to record labels of multiple levels.
[0071] Step B2: If the tag level of the start tag matches the current stack depth of the state stack, determine that the start tag has passed the level verification.
[0072] Furthermore, the method also includes pushing the start tag onto the state stack if the start tag passes the hierarchical verification.
[0073] In this embodiment, a data structure for nested label states is maintained by a State Stack; and a multi-level label system can be predefined to ensure the accuracy of data processing according to strict hierarchical relationships and verification algorithms.
[0074] Figure 6 A schematic diagram of a two-level tag architecture is shown, such as Figure 2 As shown, top-level tags can include: plan, reasoning, answer, retrieval, file, etc., while second-level tags include: content, search, etc. It can be understood that the required tag types and hierarchical relationships can be defined according to business needs.
[0075] In this embodiment, top-level labels can only appear at the root level (where the state stack depth is 0), and second-level labels can only appear within a specific top-level label. Furthermore, the state stack depth is 1. The state stack depth is used to implement hierarchical verification, ensuring the correct nesting relationship of labels and preventing parsing errors.
[0076] Figure 7 A flowchart illustrating a hierarchical verification process is shown. For example... Figure 7 As shown, when performing hierarchical verification on the target label, the label type is obtained to determine its corresponding label level; and the current stack depth of the state stack is obtained.
[0077] If the target label is a top-level label (first-level label), then check if the current stack depth is 0 (i.e., whether there are other labels in the state stack); if the stack depth is 0, the level verification is successful. For second-level labels, it is necessary to check if the current stack depth is 1 (i.e., whether there is a corresponding parent label in the state stack); if the stack depth is correct, it can be further determined whether the target label supports the parent label.
[0078] Specifically, parent tag verification is achieved by checking the top element of the stack. Step B2, "If the tag level of the start tag matches the current stack depth of the state stack, determine that the start tag passes the level verification", may include steps B21 to B22.
[0079] Step B21: If the tag level of the start tag matches the current stack depth of the state stack, and the start tag is a secondary tag, determine whether the top tag of the state stack is allowed to be the parent tag of the start tag.
[0080] Step B21: If the top label of the state stack is allowed to be the parent label of the start label, determine that the start label passes the hierarchical verification.
[0081] In this embodiment, only a portion of the first-level tags can have lower-level sub-tags, so that... Figure 6 Taking the tag system shown as an example, secondary tags (search, content) must be within the first-level file tag. For secondary tags, if the current stack depth of the state stack is correct (i.e., stack depth = 1), the top tag of the state stack is the parent tag of the secondary tag (i.e., the target tag). At this time, it can be further determined whether the top tag of the state stack is allowed to be the parent tag of the start tag; if it is allowed, the verification passes; otherwise, the verification fails.
[0082] When validation fails, the process can gracefully degrade to content processing. Specifically, the method may further include: performing text processing on the text content corresponding to the target tag if the target tag fails hierarchical validation.
[0083] In addition, it supports custom validation rule extensions. For example... Figure 7 As shown, if the target tag is another user-defined tag, it can be verified based on the custom extended verification logic. This embodiment does not limit the extended verification logic.
[0084] by Figure 6 Taking the labeling system shown as an example, some of the hierarchical verification rules can be seen in Table 2 below.
[0085] Table 2
[0086] As shown in Table 2, the root-level plan and file tags are processed normally, the content and search tags within the file are processed normally, and the plan tags within the file are processed as ordinary text, for example, passed to the callback system; the root-level content tags are completely ignored and are also processed as ordinary text.
[0087] Figure 8 A flowchart illustrating the fault-tolerant handling process for verification failures is shown. Figure 8 As shown, in this fault-tolerant processing mechanism, the first-level label <plan>Within the tag "file", the hierarchical validator checks the hierarchical validation rules, which will determine if validation fails at this point, i.e., it's a first-level tag. <plan>If the verification fails, a progress callback for the text content will be triggered, meaning the callback system will... <plan>As with ordinary text processing, the state stack will not be processed at this time, that is, the state stack will not be modified.
[0088] The fault-tolerant processing mechanism provided in this embodiment does not create stack frames for invalid tags. The tag content is passed to the callback system as ordinary text, and the state stack remains stable, without affecting subsequent processing.
[0089] In this embodiment, the stack data structure can be managed based on the state stack manager to maintain the nested state of tags and support tag processing at any depth.
[0090] Figure 9 This diagram illustrates a state stack management mechanism. The stack frame structure within the state stack can specifically include: tag type (tagType), tag attributes (attributes), content buffer (content), and delimiter flag (hasDelimiter, a boolean value). For example, a file stack frame might be: tagType: "file", attributes: {type:"modify", path: "src / component.ts"}; a content stack frame might be: tagType: "content", content:"updated code", hasDelimiter: true.
[0091] Operations related to the state stack include pushing operations (creating new stack frames), pop operations (destroying stack frames), and state queries. During state maintenance, state marking can be performed to distinguish between labeled buffers and unlabeled content buffers, and also to mark states related to AI tools.
[0092] Specifically, when each tag begins, a new stack frame is created and pushed onto the stack; when a tag ends, the corresponding stack frame is popped. Based on this, complete tag nesting state information is maintained, and state rollback and exception recovery are supported.
[0093] Optionally, the tag matching is verified during each pop operation. Specifically, step S303, "perform hierarchical verification of the target tag according to the tag level of the target tag", may also include steps B3 to B4.
[0094] Step B3: If the target label is an end label, determine whether the end label matches the top label of the state stack. For example, check if the label names are the same.
[0095] Step B4: If the end label matches the top label of the state stack, determine that the end label has passed the level verification.
[0096] Furthermore, the method also includes: removing the top label of the state stack if the end label passes the hierarchical verification.
[0097] For example, the input streaming data is: <file type="create" path="test.js"> <content> ===File Content===< / content> < / file> The state stack change process can be described as follows: Figure 10 As shown. Figure 10 As shown, in the initial state: the stack is empty []; the start label is encountered. <file>A stack push operation is performed, and the stack frame is: [FileFrame{type:"create", path:"test.js"}]; then the start tag is encountered. <content> Push the data onto the stack again, and the stack frame in the state stack is: [FileFrame, ContentFrame]. Then, the end tag is encountered.< / content> A pop operation is performed, the stack frame is restored to [FileFrame], and finally the end tag is encountered.< / file> Then, the pop operation is performed again. At this point, the processing is complete, and the state stack is restored to its initial empty state, so that subsequent tags can continue to be processed.
[0098] Step S304: If the target tag passes the hierarchical verification, perform the corresponding parsing processing on the target tag. For details, please refer to [link to details]. Figure 2 Step S204 of the illustrated embodiment will not be described again here.
[0099] Optionally, multiple callback functions can be pre-set, which can be triggered at any stack depth, including the current context. Specifically, step S304, "perform corresponding parsing processing on the target tag," may include: triggering a preset start callback function when the target tag is a start tag; triggering a preset completion callback function when the target tag is an end tag; and triggering a preset progress callback function for the content block when there is a content block in the target streaming data located between the start tag and the corresponding end tag.
[0100] In this embodiment, for complete data, the identified target tags can be used to divide the complete data into blocks, distinguishing between tag blocks and content blocks, thereby triggering corresponding callback functions. The content block is the data block corresponding to the content between the start tag and the end tag.
[0101] Figure 11 A schematic diagram illustrating the tag recognition process is shown. For example... Figure 11 As shown, for the data block to be processed (such as target streaming data, or the complete data obtained after processing), the first step is to perform tag boundary detection and content segmentation, decomposing the mixed content into tag blocks and content blocks for block-by-block classification processing.
[0102] In this embodiment, for each tag block, the tag category can be determined based on regular expressions to identify the start tag and the end tag.
[0103] For example, the start label format is: <tagname key="value" ...>Its regular expression can be: startTag: / ^<([a-zA-Z][a-zA-Z0-9] )\b([^>] )>$ / . Similarly, the closing tag format is:< / tagname> Its regular expression can be: endTag: / ^<\ / ([a-zA-Z][a-zA-Z0-9] If the attribute format is key="value", then the regular expression for attribute extraction can be: attributes: / ([a-zA-Z][a-zA-Z0-9] )\s =\s "([^"] )" / g.
[0104] Based on this regular expression, it can be determined that: <file type="create" path="test.js"> , is a valid start tag;< / file> , is a valid closing tag; <plan>, is a tag without attributes. <invalid-tag><123invalid> is an error tag (hyphens are not supported), and <123invalid> is also an error tag (cannot start with a number), etc.
[0105] For start tags, hierarchical validation can be performed, which will not be elaborated further. If the validation passes, a corresponding stack frame can be created for the start tag, thereby triggering the start callback function. If the validation fails, the start tag will be treated as plain text and processed as text content, at which point the progress callback function will be triggered.
[0106] For the closing tag, the tag matching is verified according to steps B3 to B4. If the tag matches, a stack pop operation is performed, removing the top tag from the state stack (i.e., popping the stack frame), which triggers the completion callback function. If the tag does not match, the closing tag will be treated as ordinary text, triggering the progress callback function.
[0107] For the content block between two tag blocks, you can directly process its content, which will also trigger the progress callback function.
[0108] For example, if the input streaming data is: before <file type="create"> content< / file> After, the segmentation result after processing is: ["before ", " <file type="\"create\""> ", "content", "< / file> ", " after"].
[0109] The processing procedure for this segmentation result is as follows: "before" → Content block → Triggers progress callback; " <file type="\"create\"">→ Tag block → Create a file stack frame and trigger the start callback; "content" → Content block → Triggers progress callback (in the file context); "< / file> → The tag block → pops the stack frame and triggers the complete callback; "after" → Content block → Triggers progress callback.
[0110] In addition, when extracting and parsing attributes of the start tag, regular expression matching can be performed on the corresponding attribute strings to extract key-value pairs and then construct the attribute object.
[0111] For example, if the input attribute string is: <file type="modify" path="src / components / MyComponent.vue">The corresponding parsing result is: {type: "modify", path: "src / components / MyComponent.vue"}.
[0112] In this embodiment, callbacks are used to implement an event-driven asynchronous processing mechanism. Pre-compiled regular expressions are used for efficient tag matching, and strict tag matching verification prevents misidentification and ensures the correctness of the tag structure. This fault-tolerant processing guarantees system stability. Furthermore, this method can accurately identify tag boundaries, supports the correct segmentation of multiple consecutive tags, avoids interference from angle brackets in the content, maintains the original order of tags and content, and provides the correct processing context for each segment.
[0113] This embodiment provides a method for processing streaming data, which can be used in the aforementioned terminal devices or servers. Figure 12 This is a flowchart of a streaming data processing method according to an embodiment of this application, such as... Figure 12 As shown, the process includes the following steps.
[0114] Step S1201: Obtain the target streaming data to be processed.
[0115] Please see details Figure 2 Step S201 of the illustrated embodiment will not be described again here.
[0116] Step S1202: Determine whether there is a tool call request in the target streaming data.
[0117] In large-scale model applications, developers predefine a series of tools (such as agents), which are usually functions in the program or external APIs, and describe the functions, parameters and return values of these tools to the model. This is known as tool calling, which enables large language models to interact with the external world.
[0118] Specifically, when a user asks a question, the large model determines whether it's necessary to use these tools to obtain information or perform operations based on the question's content. If so, the large model doesn't answer directly but outputs a structured tool invocation request, typically a JSON object specifying the tool name to be invoked and the required parameters. This request is captured by the system, and the backend code actually executes the tool. After execution, the tool's return result is used as new context and input back into the large model. The large model combines the original question and the tool's return result to generate the final, natural language answer.
[0119] In this embodiment, the target streaming data to be processed may specifically include text-formatted content (e.g., XML-formatted content containing various tags) and / or tool calling requests. After obtaining the target streaming data to be processed, it can be determined whether a tool calling request exists in the target streaming data.
[0120] Step S1203: If there is a tool call request for the first tool in the target streaming data and there is currently an active second tool, determine whether the first tool and the second tool are the same tool.
[0121] In this embodiment, if a tool invocation request exists in the target streaming data, and the tool invocation request is used to invoke a first tool (e.g., an AI tool), then the first tool can be used. To accurately manage the usage status of each tool, it can be determined whether there is currently an active tool. If there is a currently active second tool, it is further determined whether the two tools are the same, that is, whether the first tool to be used and the currently active second tool are the same tool.
[0122] In step S1204, if the tools are not the same, the second tool is terminated and the first tool is invoked.
[0123] In this embodiment, if the first tool and the second tool are not the same tool, it means that the tool called by the large model has changed. At this time, the currently active second tool is terminated and the first tool is called to update the tool's calling status. Subsequently, the corresponding tasks are executed based on the first tool until the processing is completed.
[0124] Figure 13 This diagram illustrates the lifecycle management of large model tool calls. For example... Figure 13 As shown, initially, no tools are active. After the large model outputs a tool call request (tool_calls), the corresponding AI tool becomes active. Furthermore, if a new AI tool (such as the first tool) is called during this process, a tool switch can be performed. After the tool switch is complete, the new AI tool can be called. During the AI tool's active state, tool parameters (arguments) can be accumulated, which will be explained later.
[0125] Furthermore, in AI-driven streaming responses, the AI tool generates a plain text response after each generation. This characteristic can be used to determine when the tool's streaming transmission has ended. Specifically, once the AI tool generates plain text (such as XML formatted text), the tool call is considered complete, and the AI tool can be actively terminated, returning to a state without active tools.
[0126] Step S1205: Perform label recognition on the target streaming data to determine the target labels in the target streaming data; the target labels are predefined with corresponding label levels.
[0127] Please see details Figure 2 Step S202 of the illustrated embodiment will not be described again here.
[0128] Step S1206: Perform hierarchical verification on the target tag according to the tag hierarchy of the target tag.
[0129] Please see details Figure 2 Step S203 of the illustrated embodiment will not be described again here.
[0130] Step S1207: If the target tag passes the hierarchical verification, perform corresponding parsing processing on the target tag.
[0131] Please see details Figure 2 Step S204 of the illustrated embodiment will not be described again here.
[0132] In some optional implementations, the above step S1203, "If there is a tool call request for the first tool in the target streaming data and there is currently an active second tool, determine whether the first tool and the second tool are the same tool", may specifically include steps C1 to C2.
[0133] Step C1: If a tool call request exists in the target streaming data, extract the corresponding tool information.
[0134] Step C2: If the tool information includes the tool name of the first tool, and a second tool is currently active, then determine whether the tool name of the first tool is the same as the tool name of the second tool.
[0135] Furthermore, the method may also include steps C3 to C4.
[0136] Step C3: If the tool information does not contain a tool name, determine whether the tool information contains tool parameters.
[0137] Step C4: If the tool information includes tool parameters, and there is currently an active tool, accumulate the tool parameters until the tool call is completed.
[0138] In this embodiment, when calling a tool, the relevant tool information may specifically include the tool name (function.name) and tool parameters (function.arguments). For example, the data structure for calling a tool in a large model may be as follows: {"tool_calls": [ { "index": 0, "id": "call_123abc", "type": "function", "function": { "name": "create_component", "arguments": "{\"name\": \"MyComponent\", \"type\": \"React\"}" }}]} When performing streaming data processing, the tool name is transmitted at the beginning, and only the tool parameters may be transmitted later. Based on this, the state management of tool calls and parameter accumulation are carried out.
[0139] Figure 14 A flowchart illustrating a tool invocation processing mechanism is shown. For example... Figure 14 As shown, for the tool call data flow of LLM, we can first determine whether it needs to call a tool, that is, determine whether there is a tool call request.
[0140] If a tool call request exists, the relevant tool call array can be traversed to extract tool information, as shown above. This tool information may include the tool name and / or tool parameters. If the extracted tool information includes a tool name, the tool corresponding to that name is called the first tool, and it is further determined whether there are currently any active tools. In streaming parsing, the transmission of tool parameters takes time; when a tool parameter is transmitted, that tool is considered an active tool.
[0141] If there is an active tool, for example, the second active tool, it can be further determined whether the two tools are the same tool. For example, it can be determined whether the tool name of the first tool is the same as that of the second tool. If they are the same tool, the currently active tool can continue to be used. If tool parameters (usually in JSON format) are also included at this time, the tool parameters are accumulated, i.e., accumulated JSON parameters. If they are not the same tool, the currently active second tool is terminated, and the invocation of a new tool, i.e., the first tool, is started.
[0142] If the tool name is not found in the tool information, the system further checks whether tool parameters exist. If tool parameters exist, it checks whether there are currently active tools. If there are active tools, it means that the tool parameters are the remaining parameters from previous tool call requests in the streaming data, so they can be accumulated, for example, stored in the cache. If there are currently no active tools, or if the tool information does not contain tool parameters, the tool information can be ignored.
[0143] In this embodiment, if the data stream does not require tool invocation, it is treated as ordinary AI response content and processed as plain text. This includes processes such as the aforementioned tag hierarchy verification. Tool management can also be performed even when no tool invocation is required. Specifically, the method further includes: if no tool invocation request exists in the target streaming data, determining whether an active tool currently exists; if an active third tool exists, terminating the third tool's operation.
[0144] like Figure 14 As shown, when processing regular AI response content, if there is an active tool, the active tool will be terminated, such as a third tool. At this time, the completion callback of the third tool can be triggered, and the relevant AI response content can be processed.
[0145] Similarly, the corresponding callback process will be triggered in other situations. For example... Figure 14 As shown, once a new tool is invoked, a start callback function for the new AI tool (i.e., the first tool) can be triggered, and the tool invocation status can be updated. During the process of accumulating JSON tool parameters, a progress callback function for active tools can also be triggered in real time.
[0146] Figure 15 This diagram illustrates the streaming accumulation processing of AI tool parameters. For example... Figure 15 As shown, the parameter streaming accumulation process is as follows: Initially, the corresponding tool (tool name: create_file) is called, and the start callback (onAIToolStart callback) is triggered. At this time, the initial parameter is empty: "". After receiving parameter stream 1, the accumulated parameter is: "{\"path\": \"src / "; after receiving parameter stream 2, the accumulated parameter is: "{\"path\": \"src / test.js\",\"type\": \"create\"}". After receiving the AI's response, the tool call is completed. At this time, it can be parsed into a JSON object and the completion callback (onAIToolComplete callback) is triggered. Furthermore, during the parameter parsing process, the callback (onAIToolProgress callback) can be triggered in real time.
[0147] Furthermore, AI tool calls can be coordinated with the content generation of the model. Figure 16 A schematic diagram illustrating the coordination mechanism between tool invocation and content generation is shown. For example... Figure 16 As shown, during the tool invocation, the JSON parameters output by the LLM (function.arguments) are accumulated, and a tool progress callback is triggered. When AI content appears, the tool invocation automatically ends and switches to content processing mode, i.e., processing the AI response content.
[0148] In this system, the tool invocation status and tag processing status are managed independently to achieve state isolation management; furthermore, AI tool callbacks and ordinary content callbacks are processed separately to achieve intelligent callback separation.
[0149] In this embodiment, an intelligent state management and parameter accumulation processing flow is implemented for the tool callback process in the large language model. This flow can specifically handle the streaming data format of large model tool calling. Furthermore, it can intelligently identify the start, progress, and end states of AI tool calls, supporting dynamic switching and concurrent state management of multiple tools. By accumulating JSON parameters in blocks, it can process the JSON parameters output in blocks from the large model, which is beneficial for the subsequent automatic parsing process. In addition, the tool call is automatically terminated when a normal AI response appears, enabling coordinated processing with AI content generation.
[0150] Figure 17 A schematic diagram of the overall architecture of this streaming data processing method is shown. Figure 17 As shown, for the input streaming data, if it is used for tool invocation, the corresponding processing can be performed based on the tool invocation processor, which will not be elaborated further. If the streaming data contains text, incomplete tag detection is performed first. Incomplete tags are reassembled and tag recognition is performed synchronously with the complete data block. If it is a start tag, a hierarchy verification can be performed to verify whether the tag hierarchy is valid. If valid, a stack push operation is performed; if invalid, it is treated as ordinary content. If it is an end tag, a stack pop operation is performed, popping the corresponding stack frame. If it is ordinary content, the content processing is performed in the same way.
[0151] The system manages relevant states using a state stack manager, which can include the states corresponding to AI tools. Furthermore, depending on the situation, corresponding callback functions in the callback system can be triggered, and the system can also adaptively extend its processing based on business logic.
[0152] The streaming data processing method provided in this embodiment, by constructing a hierarchical labeling system, a state stack management mechanism, and an intelligent callback system, can achieve intelligent label recognition and hierarchical state management of streaming data, enabling real-time, accurate, and flexible processing of streaming data.
[0153] It supports true streaming processing, allowing processing to begin without waiting for complete data, thus improving real-time performance. Utilizing a multi-level tag system ensures correct tag nesting relationships; it supports various tag systems and business scenarios, offering excellent scalability. A stack data structure is used to maintain the nesting state of tags, with dynamic stack frame pushing and popping operations enabling tag nesting processing at arbitrary depths; hierarchical validation and state management ensure data processing accuracy. When encountering illegal tags or hierarchical errors, they are treated as ordinary content, ensuring system stability.
[0154] By analyzing the start and end positions of tags, complete content and incomplete tags are automatically separated, and complete tags are reassembled in subsequent data. It has good processing capabilities for incomplete tags and abnormal data, solves the problem of tags being segmented in streaming transmission, and realizes true streaming processing.
[0155] Based on different tag types and processing stages, corresponding callback events are automatically distributed, supporting the decoupling of business logic. Standardized interfaces and callback mechanisms are available, facilitating integration into various systems. Furthermore, it intelligently identifies the start, progress, and end states of tool calls, supports dynamic tool switching and parameter accumulation, employs incremental processing and state reuse, and boasts excellent performance.
[0156] This embodiment also provides a streaming data processing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0157] This embodiment provides a streaming data processing device, such as... Figure 18 As shown, the device includes: The acquisition module 1801 is used to acquire the target streaming data to be processed. The identification module 1802 is used to identify tags in the target streaming data and determine the target tags in the target streaming data; the target tags are predefined with corresponding tag levels; Processing module 1803 is used to perform hierarchical verification on the target tag according to the tag hierarchy of the target tag; The parsing module 1804 is used to perform corresponding parsing processing on the target tag when the target tag passes the hierarchical verification.
[0158] In some optional implementations, the identification module 1802 performs tag identification on the target streaming data to determine the target tags in the target streaming data, including: Perform integrity checks on the target streaming data to determine the integrity of the data within the target streaming data; The complete data is subjected to label recognition to determine the target label in the complete data.
[0159] In some optional implementations, the identification module 1802 performs integrity detection on the target streaming data to determine the complete data in the target streaming data, including: determining whether there are incomplete tags in the target streaming data; if there are incomplete tags, treating the other data in the target streaming data other than the incomplete tags as complete data.
[0160] In some optional implementations, determining whether incomplete tags exist in the target streaming data includes: searching in the target streaming data for: the first start character and the first end character, and / or, the last start character and the last end character; if the first start character is after the first end character, determining that incomplete tags exist in the target streaming data, and taking the data before the first end character in the target streaming data as incomplete tags; if the last start character is after the last end character, determining that incomplete tags exist in the target streaming data, and taking the data after the last start character in the target streaming data as incomplete tags.
[0161] In some optional implementations, the processing module 1803 is further configured to: store the incomplete tag in a cache when an incomplete tag exists, or combine the incomplete tag with the data recorded in the cache to form a complete tag, so as to parse the complete tag.
[0162] In some optional implementations, the step of performing hierarchical verification on the target tag based on the tag level of the target tag includes: when the target tag is a start tag, determining whether the tag level of the start tag matches the current stack depth of the state stack; the state stack is used to record tags of multiple levels; when the tag level of the start tag matches the current stack depth of the state stack, determining that the start tag passes the hierarchical verification. The processing module 1803 is further configured to: push the start tag onto the state stack if the start tag passes the hierarchical verification.
[0163] In some optional implementations, determining that the start label passes the level verification when the label level of the start label matches the current stack depth of the state stack includes: if the start label is a secondary label, determining whether the top label of the state stack is allowed to be the parent label of the start label; and if the top label of the state stack is allowed to be the parent label of the start label, determining that the start label passes the level verification.
[0164] In some optional implementations, the step of performing hierarchical verification on the target tag based on the tag level of the target tag further includes: if the target tag is an end tag, determining whether the end tag is consistent with the top tag of the state stack; if the end tag is consistent with the top tag of the state stack, determining that the end tag passes the hierarchical verification. The processing module 1803 is further configured to: remove the top label of the state stack if the end label passes the hierarchical verification.
[0165] In some optional implementations, the processing module 1803 is further configured to: perform text processing on the text content corresponding to the target tag if the target tag fails the hierarchical verification.
[0166] In some optional implementations, the corresponding parsing processing of the target tag includes: triggering a preset start callback function when the target tag is a start tag; triggering a preset completion callback function when the target tag is an end tag; and triggering a preset progress callback function for the content block when there is a content block in the target streaming data located between the start tag and the corresponding end tag.
[0167] In some optional implementations, the processing module 1803 is further configured to: determine whether there is a tool call request in the target streaming data; if there is a tool call request for a first tool in the target streaming data and a second tool is currently active, determine whether the first tool and the second tool are the same tool; if they are not the same tool, then terminate the second tool and start calling the first tool.
[0168] In some optional implementations, when there is a tool call request for a first tool in the target streaming data and a second tool is currently active, determining whether the first tool and the second tool are the same tool includes: extracting the corresponding tool information when there is a tool call request in the target streaming data; and determining whether the tool name of the first tool is the same as the tool name of the second tool if the tool information includes the tool name of the first tool and a second tool is currently active. The processing module 1803 is further configured to: determine whether the tool information contains tool parameters if the tool information does not contain a tool name; and if the tool information contains tool parameters, accumulate the tool parameters if there is an active tool until the tool call is completed.
[0169] In some optional implementations, the processing module 1803 is further configured to: determine whether there is an active tool if there is no tool call request in the target streaming data; and terminate the third tool if there is an active third tool.
[0170] The streaming data processing apparatus provided in this disclosure can execute the streaming data processing method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.
[0171] Figure 19 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0172] The following is a detailed reference. Figure 19 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1902 or a program loaded from memory 1908 into random access memory (RAM) 1903. The RAM 1903 also stores various programs and data required for the operation of the electronic device. The processor 1901, ROM 1902, and RAM 1903 are interconnected via bus 1904. An input / output (I / O) interface 1905 is also connected to bus 1904.
[0173] Typically, the following devices can be connected to the I / O interface 1905: input devices 1906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1909. Communication devices 1909 allow electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 19 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.
[0174] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1909, or installed from a memory 1908, or installed from a ROM 1902. When the computer program is executed by the processor 1901, it performs the functions defined in the streaming data processing method of embodiments of this application.
[0175] Figure 19 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0176] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the streaming data processing method shown in the above embodiments is implemented.
[0177] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0178] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.< / file> < / plan> < / plan> < / plan> < / plan> < / file> < / file>
Claims
1. A method for processing streaming data, characterized in that, The method includes: Acquire the target streaming data to be processed; The target streaming data is labeled to determine the target labels in the target streaming data; the target labels are predefined with corresponding label levels. The target tag is validated according to its tag hierarchy. If the target tag passes the hierarchical verification, the target tag is parsed accordingly.
2. The method according to claim 1, characterized in that, The step of performing label recognition on the target streaming data to determine the target labels in the target streaming data includes: Perform integrity checks on the target streaming data to determine the integrity of the data within it; The complete data is subjected to label recognition to determine the target label in the complete data.
3. The method according to claim 2, characterized in that, The step of performing integrity checks on the target streaming data to determine the integrity of the data includes: Determine whether there are incomplete tags in the target streaming data; In the presence of incomplete labels, all other data in the target streaming data except for the incomplete labels are treated as complete data.
4. The method according to claim 3, characterized in that, The determination of whether there are incomplete labels in the target streaming data includes: Search in the target streaming data for: the first start character and the first end character, and / or, the last start character and the last end character; If the first start character is located after the first end character, it is determined that there are incomplete tags in the target streaming data, and the part of the data before the first end character in the target streaming data is regarded as an incomplete tag; If the last start character is located after the last end character, it is determined that there are incomplete tags in the target streaming data, and the part of the data after the last start character in the target streaming data is regarded as an incomplete tag.
5. The method according to claim 3, characterized in that, The method further includes: In the case of incomplete tags, the incomplete tags are stored in the cache, or the incomplete tags are combined with the data recorded in the cache to form complete tags for parsing.
6. The method according to claim 1, characterized in that, The step of performing hierarchical verification on the target tag based on the tag hierarchy of the target tag includes: If the target label is a start label, determine whether the label level of the start label matches the current stack depth of the state stack; the state stack is used to record labels at multiple levels. If the tag level of the start tag matches the current stack depth of the state stack, the start tag is determined to have passed the level verification. The method further includes: If the start tag passes the hierarchical verification, the start tag is pushed onto the state stack.
7. The method according to claim 6, characterized in that, Determining that the start label passes the level verification when the label level of the start label matches the current stack depth of the state stack includes: If the tag level of the start tag matches the current stack depth of the state stack, and if the start tag is a secondary tag, determine whether the top tag of the state stack is allowed to be the parent tag of the start tag. If the top label of the state stack is allowed to be the parent label of the start label, then the start label is determined to have passed the hierarchical verification.
8. The method according to claim 6, characterized in that, The step of performing hierarchical verification on the target tag based on the tag hierarchy of the target tag further includes: If the target label is an end label, determine whether the end label is consistent with the top label of the state stack; If the end label matches the top label of the state stack, it is determined that the end label has passed the hierarchical verification. The method further includes: If the end label passes the hierarchical verification, remove the top label of the state stack.
9. The method according to claim 1, characterized in that, The method further includes: If the target tag fails the hierarchical verification, the text content corresponding to the target tag is processed.
10. The method according to claim 1, characterized in that, The corresponding parsing process for the target tag includes: If the target tag is a start tag, a preset start callback function is triggered; If the target tag is an end tag, a preset completion callback function is triggered; If there is a content block located between the start tag and the corresponding end tag in the target streaming data, a preset progress callback function is triggered for the content block.
11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: Determine whether a tool invocation request exists in the target streaming data; If there is a tool call request for the first tool in the target streaming data, and there is currently an active second tool, determine whether the first tool and the second tool are the same tool; If they are not the same tool, then the second tool is terminated and the first tool is invoked.
12. The method according to claim 11, characterized in that, When a tool invocation request for a first tool exists in the target streaming data, and a second tool is currently active, determining whether the first tool and the second tool are the same tool includes: If a tool call request exists in the target streaming data, extract the corresponding tool information; If the tool information includes the tool name of the first tool, and if there is currently an active second tool, then it is determined whether the tool name of the first tool is the same as the tool name of the second tool. The method further includes: If the tool information does not contain a tool name, determine whether the tool information contains tool parameters; If the tool information includes tool parameters, and there is currently an active tool, the tool parameters are accumulated until the tool call is completed.
13. The method according to claim 11, characterized in that, The method further includes: If no tool invocation request is found in the target streaming data, determine whether there is currently an active tool. If a third tool is currently active, then terminate the third tool.
14. A streaming data processing apparatus, characterized in that, The device includes: The acquisition module is used to acquire the target streaming data to be processed; The identification module is used to identify tags in the target streaming data and determine the target tags in the target streaming data; the target tags are predefined with corresponding tag levels; The processing module is used to perform hierarchical verification on the target tag according to the tag hierarchy of the target tag; The parsing module is used to perform corresponding parsing processing on the target tag when the target tag passes the hierarchical verification.
15. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the streaming data processing method according to any one of claims 1 to 13.
16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method for processing streaming data as described in any one of claims 1 to 13.
17. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the method for processing streaming data according to any one of claims 1 to 13.