Large model streaming answer data front-end receiving method and system, terminal and medium

Abstract

The invention relates to the technical field of front-end development, and particularly provides a large-model streaming answer data front-end receiving method and system, a terminal and a medium, and the method comprises the steps: configuring an end identifier according to request content, transmitting the configured end identifier to a rear end through an encryption channel before initiating SSE connection, and obtaining a configuration confirmation response; initiating an SSE connection establishment request to a back end, starting a data channel monitoring event, receiving the data block in real time through the event, and detecting an ending identifier of the received data block; and when an ending identifier conforming to the structured features is detected, closing the SSE connection to complete data receiving. According to the invention, clear identification of the data transmission end point is realized, the integrity of streaming data receiving is ensured, and the efficiency of front-end streaming receiving is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of front-end development, in particular to a large model streaming answer data front-end receiving method, system, terminal and medium. BACKGROUND

[0002] Streaming answer is widely used because it can return partial results in real time, but the front end has defects in judging the completion of data transmission when receiving streaming data. Related solutions mostly rely on the server to actively close the SSE connection, and the front end perceives the end through the onerror or onclose event, but cannot distinguish between normal end and abnormal disconnection caused by network fluctuations, which easily causes incomplete data reception or misjudgment of the end. Some solutions use a timeout mechanism, setting a fixed time threshold (such as 30 seconds without new data, which is considered to be the end), but the output length of large models varies significantly depending on the request content (such as short answer and long text analysis), making it difficult for a fixed threshold to adapt to diverse scenarios, often resulting in premature termination or invalid waiting. Some solutions use a preset fixed data packet size or byte size to determine the end, but the streaming output of large models is dynamic and the content length cannot be determined in advance, resulting in low accuracy. Another solution attempts to use special HTTP status codes such as 204 No Content to identify the end, but due to the characteristics of the SSE protocol, this method is difficult to effectively apply, further exacerbating the difficulty of the front end in determining the end of streaming data reception, resulting in resource waste. SUMMARY

[0003] To solve the above problems, the present application provides a large model streaming answer data front-end receiving method, system, terminal and medium, which realizes the explicit identification of the data transmission endpoint, ensures the integrity of streaming data reception, and improves the efficiency of front-end streaming reception.

[0004] In a first aspect, the technical solution of the present application provides a large model streaming answer data front-end receiving method, comprising the following steps: Configuring an end identifier according to the request content, transmitting the configured end identifier to the back end through an encrypted channel before initiating the SSE connection, and obtaining a configuration confirmation response; Initiating an SSE connection establishment request to the back end, starting a data channel listening event, and receiving data blocks in real time through the event and detecting the end identifier of the received data blocks; When the end identifier meeting the structured feature is detected, the SSE connection is closed to complete data reception.

[0005] In an optional embodiment, the end identifier is configured according to the request content, specifically including: Extracting the subject features of the user input prompt word, generating a prompt word abstract through a hash algorithm, and the subject features including text type label, domain keyword and complexity coefficient; generate an end identifier based on the prompt word digest and the theme feature, and a session context parameter; the session context parameter includes a user session ID and a current system timestamp.

[0006] In an optional embodiment, the theme feature of the user input prompt word is extracted, and the prompt word digest is generated by a hash algorithm, specifically including: determining the type of the user input prompt word by a pre-trained text classification model, and outputting a text type label; extracting a domain keyword from the user input prompt word by a TF-IDF algorithm combined with a domain dictionary; generating a complexity coefficient based on the length and semantic complexity of the user input prompt word; concatenating the text type label, the domain keyword, and the complexity coefficient into a feature string, and performing SHA-1 hash operation on the feature string to generate a hash value as the prompt word digest.

[0007] In an optional embodiment, the end identifier is generated by an encryption algorithm based on the prompt word digest and the theme feature, and a session context parameter, specifically including: calling a cryptographically secure random number generator to generate a 32-byte random number, wherein the first 8 bytes are XORed with the first 8 bytes of the prompt word digest, and the last 24 bytes remain the original random value; concatenating the user session ID, the current system timestamp, the 32-byte random number XORed with the prompt word digest, the feature code of the domain keyword, the complexity coefficient, the text type label, and the prompt word digest in order to form a first core data block; performing SHA-256 encryption on the first core data block to generate a hash value, and appending a first fixed header and tail separator to the front and back of the hash value to form a complete main end identifier.

[0008] In an optional embodiment, the end identifier is generated by an encryption algorithm based on the prompt word digest and the theme feature, and a session context parameter, specifically further including: calling a cryptographically secure random number generator to generate a 16-byte random number, wherein the first 8 bytes are XORed with the first 8 bytes of the prompt word digest, and the last 8 bytes remain the original random value; generating a new timestamp by offsetting the current system timestamp; concatenating the 16-byte random number XORed with the prompt word digest, the new timestamp, and the prompt word digest in order to form a second core data block; The HMAC-MD5 algorithm is performed on the second core data block to generate an HMAC value, the HMAC value is converted into a Base64 code to obtain a code string, and a second fixed head-tail separator is attached before and after the code string to form a complete standby end identifier.

[0009] In an optional embodiment, after starting the data channel listening event, the following steps are further included: detecting whether an identification update instruction of backend feedback is received; if yes, switching to another end identifier monitoring mode, and sending a switching confirmation message to the backend; the end identifier includes a main end identifier and a standby end identifier.

[0010] In an optional embodiment, closing the SSE connection completes data reception, specifically including: extracting a timestamp and a user session ID from the end identifier; checking the extracted timestamp and user session ID, and closing the SSE connection to complete data reception after the check is passed.

[0011] In a second aspect, the technical solution of the present application provides a large model streaming answer data front-end receiving system, including: an end identifier configuration transmission module configured to configure an end identifier according to request content, and transmit the configured end identifier to the backend through an encrypted channel before initiating an SSE connection to obtain a configuration confirmation response; a data receiving and detecting module configured to initiate an SSE connection establishment request to the backend, start a data channel listening event, and receive data blocks in real time through the event and detect the end identifier of the received data blocks; a channel closing module configured to close the SSE connection to complete data reception when an end identifier meeting a structured feature is detected.

[0012] In a third aspect, the technical solution of the present application provides a terminal, including: a memory configured to store a large model streaming answer data front-end receiving program; a processor configured to execute the large model streaming answer data front-end receiving program to realize the steps of the large model streaming answer data front-end receiving method according to any one of the above.

[0013] In a fourth aspect, the technical solution of the present application provides a computer readable storage medium, the readable storage medium stores a large model streaming answer data front-end receiving program, and the large model streaming answer data front-end receiving program is executed by a processor to realize the steps of the large model streaming answer data front-end receiving method according to any one of the above.

[0014] It can be seen from the above technical solution that the application has the following advantages: by configuring a dedicated end identifier according to the request content and synchronizing the backend through an encrypted channel, the backend adds an end identifier on the last data block, and the front end judges whether the data is received by detecting the end identifier of the data block, solves the problem that the traditional connection closing, timeout mechanism and the like cannot accurately judge the end, and realizes the explicit identification of the data transmission endpoint; at the same time, when receiving is timed out, whether the end identifier is detected or not can be used to judge whether the data is received, avoiding data loss or misprocessing caused by the inability to distinguish between "normal end" and "abnormal disconnection", and ensuring the integrity of the stream data reception; without relying on a fixed time threshold or a preset data amount, the scheme can adapt to different lengths and different types of large model output content, improving the adaptability of the scheme to dynamic scenarios, reducing invalid resource occupation, and improving the efficiency of the front-end stream reception. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the present application, the drawings required to be used in the description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and all other drawings obtained by those skilled in the art without creative labor based on these drawings also belong to the protection scope of the present application.

[0016] Figure 1 A large model stream answer data front-end receiving method process schematic diagram provided by the embodiment of the present application.

[0017] Figure 2 A large model stream answer data front-end receiving system structure schematic block diagram provided by the embodiment of the present application.

[0018] Figure 3 A terminal structure schematic diagram provided by the embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the application purpose, features and advantages of the present application more obvious and easy to understand, the technical solutions protected by the present application will be described in detail below with specific embodiments and drawings. Obviously, the following described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor also belong to the protection scope of the present application.

[0020] Unless otherwise defined, all technical and scientific terms used in the present application have the same meaning as understood by those skilled in the art to which the present application belongs. The terms used in the specification of the present application are only for the purpose of describing the specific embodiments and are not intended to limit the present application.

[0021] Figure 1 A large model streaming answer data front-end receiving method flowchart is provided for an embodiment of the present application. Wherein, Figure 1 The execution subject can be a large model streaming answer data front-end receiving system. The large model streaming answer data front-end receiving method provided by the embodiment of the present application is executed by a computer device, and accordingly, the large model streaming answer data front-end receiving system runs in the computer device. According to different needs, the order of steps in the flowchart can be changed, and some can be omitted.

[0022] As Figure 1 shown, the method comprises the following steps.

[0023] S1, configure an end identifier according to the request content, and transmit the configured end identifier to the back end through an encrypted channel before initiating an SSE connection to obtain a configuration confirmation response.

[0024] S2, initiate an SSE connection establishment request to the back end, start a data channel listening event, and receive data blocks in real time through the event and detect the end identifier of the received data blocks.

[0025] S3, when the end identifier conforming to the structured feature is detected, close the SSE connection to complete data reception.

[0026] As a refinement and expansion of the above embodiment, in order to completely describe the specific implementation process in the embodiment, the following will give a non-limiting description of the specific implementation of the above steps.

[0027] The method of the present embodiment configures an end identifier at the front end, and the back end sends data in segments. According to the data size and transmission speed, large data is divided into multiple data blocks, a unique identifier is added to each data block, so that the front end can assemble data, an end identifier of the current data block, such as "PART_END", is added at the end of each data block, and a final end identifier is added at the end of the last data block. The end identifier is the end identifier configured by the front end. The front end receives the data blocks sent by the back end, detects the end identifier of the data blocks, and when the final end identifier, that is, the end identifier configured by the front end, is detected, it means that the data transmission is complete.

[0028] SS1, configure an end identifier, and transmit the end identifier to the back end before initiating an SSE connection.

[0029] In some optional embodiments, a fixed end-of-file (EOF) representation can be configured on the visualization configuration interface of the front end, such as a preset identification option "EOF", "END", "DONE", etc., or can be customized, and the user selects the preset identification or inputs a custom string. The system automatically performs a legality check, and then transmits the configured end-of-file identification to the back end through an encrypted channel before initiating an SSE connection and obtains a configuration confirmation response.

[0030] In some optional embodiments, considering that the end-of-file identification relying on static configuration is susceptible to interference from the content of the large model output, the front end dynamically and adaptively configures the end-of-file identification according to the actual request content. The specific steps include the following.

[0031] SS101, extracts the topic features of the user input prompt word, and generates a prompt word digest through a hash algorithm. The topic features include a text type label, a domain keyword, and a complexity coefficient.

[0032] SS101.1, determines the type of the user input prompt word through a pre-trained text classification model, and outputs a text type label.

[0033] The pre-trained text classification model can be a lightweight classifier based on BERT, which determines the type of the user input prompt word and outputs a text type label. For example, if the prompt word contains code keywords (such as "def", "function", "print") or explicitly requires code generation (such as "write a Python script"), it is marked as "code type" (type code: 0x01); if the prompt word contains mathematical symbols or involves formula derivation (such as "deduce the Pythagorean theorem"), it is marked as "math type" (type code: 0x02); if the prompt word is a natural language question and answer, paragraph generation, etc. (such as "explain relativity" "write an essay"), it is marked as "natural language type" (type code: 0x03).

[0034] The output type code (1 byte) is the first dimension of the topic features.

[0035] SS101.2, extracts the domain keyword from the user input prompt word through the TF-IDF algorithm combined with the domain dictionary.

[0036] Specifically, the prompt word is segmented, stop words are filtered, the matching degree of the segmentation result with each domain dictionary is calculated, the domain with the highest matching degree is selected, the core keyword of the domain is extracted, and a 16-bit domain feature code (such as "quantum mechanics" mapped to 0x5A3F) is generated through hash mapping as the second dimension of the topic features.

[0037] SS101.3, generating a complexity coefficient based on the length and semantic complexity of the prompt word input by the user.

[0038] Specifically, first, the base length is calculated by the number of characters, for example, ≤50 characters is 30 points, 50-200 characters is 60 points, and >200 characters is 90 points; then the semantic entropy of the prompt word is calculated by the N-gram model, which is mapped to a semantic complexity score of 0-165 points. The sum of the base length score and the semantic complexity score is the total complexity coefficient, which is the third dimension of the topic feature.

[0039] SS101.4, concatenating the text type label, domain keyword, and complexity coefficient into a feature string, and performing SHA-1 hash operation on the feature string to generate a hash value as the prompt word digest.

[0040] The above three types of features are concatenated into a feature string in the format: [type code (1 byte)] [domain feature code (2 bytes)] [complexity coefficient (1 byte)]; SHA-1 hash operation is performed on the feature string to generate a 160-bit (20-byte) hash value as the prompt word digest.

[0041] SS102, based on the prompt word digest and topic feature, and the session context parameters, generating an end identifier using an encryption algorithm; the session context parameters include user session ID and current system timestamp.

[0042] The parameters output by step SS101 are used as inputs for end identifier generation. The inputs for end identifier generation include prompt word digest (denoted as H, 20 bytes), text type code (denoted as T, 1 byte), domain feature code (denoted as D, 2 bytes), complexity coefficient (denoted as C, 1 byte), user session ID (denoted as SID, 16 bytes, globally unique), and current system timestamp (denoted as TS, 4 bytes). Based on these outputs, an end identifier is generated to improve data reception efficiency and ensure stability. The primary end identifier and the backup end identifier are generated, which includes the following steps.

[0043] SS102.1, calling a cryptographically secure random number generator to generate a 32-byte random number, where the first 8 bytes are XORed with the first 8 bytes of the prompt word digest, and the last 24 bytes remain as original random values.

[0044] The first 8 bytes are XORed with the first 8 bytes of the prompt word digest to strengthen the association between the identifier and the prompt word, and the last 24 bytes remain as original random values to ensure unpredictability.

[0045] SS102.2, concatenate the user session ID, the current system timestamp, the 32-byte random number XORed with the prompt digest, the feature code of the domain keyword, the complexity coefficient, the text type label, and the prompt digest in order to form the first core data block.

[0046] Concatenate the fields in the following order to form the 64-byte first core data block: [Session ID (SID, 16 bytes)] + [Timestamp (TS, 4 bytes)] + [Random number (R, 32 bytes)] + [Domain feature code (D, 2 bytes)] + [Complexity coefficient (C, 1 byte)] + [Text type code (T, 1 byte)] + [Prompt digest last 8 bytes (H[12..19], 8 bytes)] SS102.3, perform SHA-256 encryption on the first core data block to generate a hash value, and append the first fixed head and tail delimiters to the front and back of the hash value to form the complete main end marker.

[0047] For example, the complete main end marker is represented as: [MainMarkerStart] ${M_hash} ${SID first 4 bytes} ${TS last 2 bytes} [MainMarkerEnd] Wherein, [MainMarkerStart], [MainMarkerEnd] are the first fixed head and tail.

[0048] SS102.4, call a cryptographically secure random number generator to generate a 16-byte random number, wherein the first 8 bytes are XORed with the first 8 bytes of the prompt digest, and the last 8 bytes remain the original random value.

[0049] The 16-byte random number is regenerated, and the generation seed is completely independent of the random number of the main end marker, and different random number generator initialization vectors can be used to implement.

[0050] SS102.5, offset the current system timestamp to generate a new timestamp.

[0051] For example, offset the current system timestamp by 30 seconds to avoid coinciding with the main marker timestamp.

[0052] SS102.6, concatenate the 16-byte random number XORed with the prompt digest, the new timestamp, and the prompt digest in order to form the second core data block.

[0053] For example, the second core data block is represented as: [Random number (R', 16 bytes)] + [Timestamp (TS+30, 4 bytes)] + [Prompt digest first 8 bytes (H[0..7], 8 bytes)] SS102.7, execute the HMAC-MD5 algorithm on the second core data block to generate an HMAC value, convert the HMAC value to a Base64 encoded string, and append the second fixed header and tail delimiters to the encoded string to form a complete backup end marker.

[0054] Here, the HMAC-MD5 algorithm is used, which is different from the SHA-256 formation algorithm used to generate the main end marker. The SID is used as the key to encrypt the second core data, generating a 16-byte HMAC value. To avoid invisible characters and improve transmission compatibility, the HMAC value is converted to a Base64 encoded string, and the second fixed header and tail delimiters are appended to the encoded string to form a complete backup end marker, represented as: [BackupMarkerStart]${B_enc}${complexity coefficient (hexadecimal representation of C)}[BackupMarkerEnd].

[0055] Where [BackupMarkerStart] and [BackupMarkerEnd] are the second fixed header and tail.

[0056] After generating the main end marker and the backup end marker, the two markers are verified. If the verification is passed, the main end marker, the backup end marker, and the generation parameters (such as encryption algorithm identifier, character encoding rule) are packaged into the MarkerSet structure, providing standardized input for subsequent transmission to the backend through the encryption channel.

[0057] The front end transmits the MarkerSet structure data to the backend through the asymmetric encryption channel. It can also configure the marker switching rule and transmit it to the backend at the same time. The marker switching rule can be to use the main end marker by default, and if the last data block contains the same content as the main end marker, switch to the backup end marker. The receiving backend returns a marker validity confirmation response, which includes the marker effective time window parameter.

[0058] SS2, establish a streaming channel and start the end marker monitoring.

[0059] Initiate an SSE connection establishment request to the backend, start a data channel listening event, and receive data blocks in real time through this event and detect the end marker of the received data block. In some optional embodiments, the fetchEventSource tool is used to achieve a persistent connection with the server, effectively handle Server-Sent Events (SSE), and ensure that the streaming data output by the large model can be transmitted to the client in real time and accurately.

[0060] The front end initiates a request through fetchEventSource, listens to data channel events, receives data blocks in real time and detects the end identifier. After the backend establishes a data transmission channel, it outputs streaming data blocks according to the preset fragmentation rule, each data block is attached with a check code and a transmission serial number, and an end identifier is attached on the last data block. A default main end identifier is attached, and if there is a conflict with the main end identifier, a backup end identifier is switched to.

[0061] Specifically, if the backend detects a conflict between the main identifier string and the content during data generation, it immediately generates an identifier update instruction and pushes it to the front end through an independent encryption channel. After receiving the update instruction, the front end atomically switches to the backup identifier monitoring mode and sends a switching confirmation message to the backend. During the generation of streaming data, the backend starts a real-time conflict monitoring thread and uses a sliding window scanning mechanism (window size is 2 times the length of the end identifier) to scan the current data block to be output. Specifically, for text data, it compares character sequences one by one to detect whether it contains a complete structured fragment of the main identifier. For code data, it uses a syntax parser to identify whether the identifier appears in a string constant, comment or code logic. Only when it appears in a non-comment / non-string area is it considered a valid conflict. For mixed content, a multi-mode scanning (text mode + code mode alternately switched) is enabled to ensure coverage of all content types.

[0062] When the sliding window detects a fragment matching the main identifier, the backend performs the following operations: records the conflict position (data block serial number, offset of the conflict fragment in the block) and conflict type, generates an identifier update instruction, interrupts the current data block output, and pushes the signed update instruction to the front end through an independent encryption channel (physically isolated from the SSE data channel, using a WebSocket encryption sub-channel). After the front end confirms receipt, the backend re-shards the current data block (splits the conflict fragment to the next data block) and attaches a [ConflictMarker] marker at the end of the current data block to prompt the front end that the block has a conflict and needs special handling.

[0063] After the front end receives the update instruction pushed by the back end, the following verification steps are performed: the instruction signature is verified using the back end public key to confirm that the instruction has not been tampered with; the instruction validity field is checked to ensure that the current time is within the validity period; the conflictPos field is parsed to locate the conflict data block and offset, and the data block is marked as "to be checked"; the front end starts the lock-free switching mechanism to ensure that the identification detection logic switching is completed without interrupting data reception. The standby end marker detection thread is activated, the standby identification detection rule is consistent with the main identification, the result output of the main identification monitoring thread is frozen, the subsequent data of the data receiving buffer is directed to the standby identification monitoring thread, and the "to be checked" data block is scanned again using the standby identification rule to filter the conflict fragments. The front end generates a switching confirmation message, attaches the front end session signature, and sends it to the back end; after receiving the "switching takes effect" response returned by the back end, the main identification monitoring thread is closed, and the standby identification monitoring thread takes over the detection and analysis of all data blocks, ensuring seamless connection of data flow.

[0064] When the end marker conforming to the structured feature is detected, the SSE connection is closed to complete data reception. In some optional embodiments, before the SSE connection is closed, a timestamp and a user session ID are extracted from the end marker; the extracted timestamp and user session ID are checked, and the SSE connection is closed to complete data reception after the check passes. Specifically, it is verified whether the timestamp is valid and the matching degree of the user session ID, and if the timestamp is valid and the user session ID matches, the check passes.

[0065] In some optional embodiments, if the front end does not receive a data block for more than a preset time period, and it is detected that no data block containing an end marker is received, it is determined as an abnormal disconnection, and the SSE connection does not need to be closed to ensure that complete streaming data is received subsequently.

[0066] In some optional embodiments, the front end initiates a request through fetchEventSource, and also listens to error events of fetchEventSource, such as network errors and server errors, displays corresponding error information according to the error type, provides a retry mechanism, and allows the user to manually or automatically reconnect the server and obtain data. In the front-end visualization interface, a progress bar or other visualization methods are used to display the progress of data reception in real time, such as displaying the amount of data received, the total amount of data, the remaining time, etc. The display speed of the progress bar can be dynamically adjusted according to the data transmission speed. Front-end caching technologies such as localStorage, sessionStorage, or IndexedDB are used to store the loaded data, and when needed, the data is obtained from the cache first to avoid repeated requests to the server and improve data loading efficiency. The validity period of the cache is set to ensure the timeliness of the data.

[0067] In some optional embodiments, after the front end receives data, in order to better display, the Marked library is integrated to convert the Markdown format text into HTML format in real time, realize the web visual display of the text, support custom Markdown syntax extension, and meet diversified display requirements. Specifically, the extension functions provided by the Marked library are used, for example, tables, github-flavored-markdown, and the like, to support syntaxes such as tables and code blocks; new Markdown syntaxes are allowed to be customized by the user, and corresponding parsing rules are provided, the supported Markdown syntaxes and extension methods can be specified in detail in the document. A preset Markdown style theme is provided, and the user is allowed to customize the style of the Markdown text, for example, font, color, font size, background color, and the like. Loading and display of Markdown pictures are supported, the picture size adjustment function is provided, the picture lazy loading function is supported, the picture is loaded only when the picture enters the visible area, the page loading speed is optimized, the picture uploading function is provided, and the user is facilitated to upload the picture and insert the picture into the Markdown text.

[0068] The above describes an embodiment of a large model streaming answer data front end receiving method in detail, and based on the large model streaming answer data front end receiving method described in the above embodiment, the embodiment of the present application further provides a large model streaming answer data front end receiving system corresponding to the method.

[0069] Figure 2 A large model streaming answer data front end receiving system structure schematic block diagram is provided in the embodiment of the present application, in the embodiment, the large model streaming answer data front end receiving system 200 can be divided into a plurality of functional modules according to the functions performed by the large model streaming answer data front end receiving system 200. The module referred to in the present application refers to a series of computer program segments that can be executed by at least one processor and can complete a fixed function, which are stored in the memory.

[0070] The end identifier configuration transmission module 210 is configured to configure an end identifier according to the request content, and transmit the configured end identifier to the backend through an encrypted channel and obtain a configuration confirmation response before initiating the SSE connection.

[0071] The data receiving and detecting module 220 is configured to initiate an SSE connection establishment request to the backend, start a data channel listening event, and receive data blocks in real time and detect the end identifier of the received data blocks through the event.

[0072] The channel closing module 230 is configured to close the SSE connection to complete data receiving when the end identifier meeting the structured feature is detected.

[0073] The large model streaming answer data front-end receiving system of the embodiment is used to implement the large model streaming answer data front-end receiving method, and therefore the specific implementation in the system can be seen from the embodiment part of the large model streaming answer data front-end receiving method, and therefore the specific implementation can be referred to the description of the corresponding embodiment part, which will not be introduced here.

[0074] In addition, since the large model streaming answer data front-end receiving system of the embodiment is used to implement the large model streaming answer data front-end receiving method, the role thereof corresponds to the role of the method, which will not be repeated here.

[0075] Figure 3 A structure schematic diagram of a terminal 300 provided by the embodiment of the application includes a processor 310, a memory 320 and a communication unit 330. The processor 310 is used to implement the following steps when implementing the large model streaming answer data front-end receiving program stored in the memory 320. According to the request content configuration end identifier, before initiating the SSE connection, the configured end identifier is transmitted to the backend through an encrypted channel and a configuration confirmation response is obtained; A SSE connection establishment request is initiated to the backend, a data channel listening event is started, data blocks are received in real time through the event, and the end identifier of the received data block is detected; When the end identifier conforming to the structured feature is detected, the SSE connection is closed to complete the data reception.

[0076] The terminal 300 includes a processor 310, a memory 320 and a communication unit 330. These components communicate through one or more buses, and those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation to the application, which can be a bus structure, a star structure, or include more or fewer components than shown in the figure, or combine certain components, or different component arrangements.

[0077] The memory 320 can be used to store the execution instructions of the processor 310, and the memory 320 can be realized by any type of volatile or non-volatile storage terminal or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 can execute part or all of the steps in the following method embodiments.

[0078] The processor 310 is a control center of the storage terminal, connects various parts of the entire electronic terminal by using various interfaces and lines, and executes various functions of the electronic terminal and / or processes data by running or executing software programs and / or modules stored in the memory 320 and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, can be composed of a single packaged IC, or can be composed of multiple packaged ICs connected together. For example, the processor 310 can only include a central processing unit (CPU). In the embodiments of the present application, the CPU can be a single operation core or can include multiple operation cores.

[0079] The communication unit 330 is used to establish a communication channel, so that the storage terminal can communicate with other terminals. Receive user data sent by other terminals or send user data to other terminals.

[0080] The present application also provides a computer storage medium, wherein the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM) and the like.

[0081] The present application also provides a computer storage medium, wherein the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM) and the like.

[0082] The computer storage medium stores a large model streaming answer data front-end receiving program, and the large model streaming answer data front-end receiving program is executed by the processor to realize the following steps: Those skilled in the art can clearly understand that the technical solutions in the embodiments of the present application can be implemented by means of software plus necessary universal hardware platforms. Based on such an understanding, the technical solutions in the embodiments of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a USB flash disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, and includes a plurality of instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, or the like) to execute all or part of the steps of the methods described in the embodiments of the present application.

[0083] In several embodiments provided by the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0084] The units described as separated components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments of the present application.

[0085] In addition, each function unit in the embodiments of the present application can be integrated in a processing unit, or each unit can exist physically as a separate unit, or two or more units can be integrated in one unit.

[0086] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined in the present application can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown in the present application, but will conform to the widest scope consistent with the principles and novel features disclosed in the present application.

Claims

1. A large model streaming answer data front-end receiving method, characterized in that, The method comprises the following steps: According to the request content configuration end identifier, the configured end identifier is transmitted to the backend through the encrypted channel before initiating the SSE connection, and a configuration confirmation response is obtained; Initiate an SSE connection establishment request to the backend, start a data channel listening event, receive data blocks in real time through the event, and detect the end identifier of the received data blocks; When the end identifier conforming to the structured feature is detected, the SSE connection is closed to complete data reception.

2. The large model streaming answering data front-end receiving method according to claim 1, characterized in that, According to the request content configuration end identifier, specifically comprising: Extract the topic features of the user input prompt word, generate a prompt word abstract through a hash algorithm, and the topic features include text type label, domain keyword and complexity coefficient; Based on the prompt word abstract and topic features, and the session context parameters, an encryption algorithm is used to generate an end identifier; the session context parameters include user session ID and current system timestamp.

3. The large model streaming answering data front-end receiving method according to claim 2, characterized in that, Extract the topic features of the user input prompt word, generate a prompt word abstract through a hash algorithm, specifically comprising: Determine the type of the user input prompt word through the pre-trained text classification model, and output the text type label; Extract the domain keyword from the user input prompt word through the TF-IDF algorithm combined with the domain dictionary; Generate a complexity coefficient based on the length and semantic complexity of the user input prompt word; Concatenate the text type label, domain keyword and complexity coefficient into a feature string, and perform SHA-1 hash operation on the feature string to generate a hash value as the prompt word abstract.

4. The large model streaming answering data front-end receiving method according to claim 3, characterized in that, Based on the prompt word abstract and topic features, and the session context parameters, an encryption algorithm is used to generate an end identifier, specifically comprising: Call a cryptographically secure random number generator to generate a 32-byte random number, wherein the first 8 bytes are XORed with the first 8 bytes of the prompt word abstract, and the last 24 bytes remain as the original random value; Concatenate the user session ID, current system timestamp, 32-byte random number XORed with the prompt word abstract, feature code of the domain keyword, complexity coefficient, text type label and prompt word abstract in sequence to form a first core data block; Perform SHA-256 encryption on the first core data block to generate a hash value, and append a first fixed header and tail separator to the front and back of the hash value to form a complete main end identifier.

5. The large model streaming answering data front-end receiving method according to claim 4, characterized in that, Based on the prompt word abstract and topic features, and the session context parameters, an encryption algorithm is used to generate an end identifier, specifically comprising: Call a cryptographically secure random number generator to generate a 16-byte random number, wherein the first 8 bytes are XORed with the first 8 bytes of the prompt word abstract, and the last 8 bytes remain as the original random value; Offset the current system timestamp to generate a new timestamp; Concatenate the 16-byte random number XORed with the prompt word abstract, the new timestamp and the prompt word abstract in sequence to form a second core data block; Perform HMAC-MD5 algorithm on the second core data block to generate HMAC value, convert the HMAC value to Base64 encoding to get encoding string, and append a second fixed header and tail separator to the front and back of the encoding string to form a complete backup end identifier.

6. The large model streaming answering data front-end receiving method according to claim 5, characterized in that, After starting the data channel listening event, the following steps are further included: Detect whether an identifier update instruction fed back by the backend is received; If yes, switch to another end identifier monitoring mode, and send a switching confirmation message to the backend; the end identifier includes a main end identifier and a backup end identifier.

7. The large model streaming answering data front-end receiving method according to claim 5, characterized in that, The SSE connection is closed to complete data reception, specifically including: Extracting a timestamp and a user session ID from the end identifier; Verifying the extracted timestamp and user session ID, and closing the SSE connection to complete data reception after verification.

8. A large model streaming answering data front-end receiving system, characterized in that, It includes: An end identifier configuration transmission module configured to configure an end identifier according to request content, and transmit the configured end identifier to the backend through an encrypted channel before initiating an SSE connection, and obtain a configuration confirmation response; A data reception and detection module configured to initiate an SSE connection establishment request to the backend, start a data channel listening event, receive data blocks in real time through the event, and detect the end identifier of the received data blocks; A channel closing module configured to close the SSE connection to complete data reception when an end identifier meeting the structured feature is detected.

9. A terminal, characterized by comprising: It includes: A memory configured to store a large model streaming answer data front-end receiving program; A processor configured to implement the steps of the large model streaming answer data front-end receiving method according to any one of claims 1 to 7 when executing the large model streaming answer data front-end receiving program.

10. A computer-readable storage medium, characterized in that, The readable storage medium has a large model streaming answer data front-end receiving program stored thereon, and the large model streaming answer data front-end receiving program implements the steps of the large model streaming answer data front-end receiving method according to any one of claims 1 to 7 when executed by the processor.

Images