Office plug-in oriented knowledge enhancement streaming response protocol adaptation method and device

Abstract

The application discloses an office plug-in-oriented knowledge enhancement streaming response protocol adaptation method, and belongs to the technical field of large language models. A protocol adaptation service receives an intelligent processing request sent by a host rich-text office component, and determines a knowledge enhancement strategy according to the intelligent processing request; in a streaming response mode, a knowledge event frame is first output, then original streaming data of a heterogeneous model service is accessed, a complete event block is identified through a sliding buffer window and a streaming demultiplexing state machine, and visible text is extracted according to a candidate text field path set and a text writing condition; after streaming is completed, a document-level history record is generated based on the output visible text and necessary metadata. The method processes knowledge metadata, text increments and control events in layers, enables the plug-in end to perform reference display, text writing and state processing according to a unified frame format, and reduces the writing of non-text content into the text document and the history record.

Description

Technical Field

[0001] This application relates to the field of large language model technology, and in particular to a knowledge-enhanced streaming response protocol adaptation method and apparatus for office plugins. Background Technology

[0002] With the application of large language models in the field of office automation, office plugins can enhance the generation service by calling cloud model services, local private models, or enterprise knowledge bases to achieve intelligent processing such as document writing, rewriting, paraphrasing, polishing, proofreading, summarizing, and question answering. To adapt to the continuous writing scenario in office documents, the model service usually adopts a streaming response method to return the generated content in batches. After receiving the content, the office plugin writes it into the current document or rich text editing area.

[0003] In knowledge base augmentation generation scenarios, a single intelligent processing response may simultaneously include model-generated text, reference fragments retrieved from the knowledge base, source information, relevance scores, model debugging fields, call identifiers, usage statistics, end events, error events, and other internal metadata. Different upstream model services or gateways express streaming responses in different ways. Some return plain text increments, while others return data objects containing fields such as message, content, text, answer, output_text, delta.content, choices[0].delta.content, or token. Some may also output knowledge reference events or control events in the same streaming channel.

[0004] Rich text office components typically maintain a document object model, cursor position, paragraph structure, formatting status, and undo stack. If the plugin directly consumes raw streaming data from the upstream model service, it needs to adapt to multiple model protocols. When knowledge sources, relevance scores, JSON wrapper fields, control events, or debugging fields are returned in combination with incremental text, they may also be written into the rich text document body.

[0005] Furthermore, streaming data may be returned in segments, with incomplete event boundaries, or multiple events being returned merged during transmission. The plugin, while receiving data, also needs to display cited materials, incrementally write the main text, detect end or error statuses, and save document-level history. If history saving directly records the upstream raw event stream, raw JSON, knowledge metadata, or internal debugging fields, the historical context used in subsequent rounds of document processing may be inconsistent with the actual visible text in the document.

[0006] Therefore, a protocol adaptation solution is needed between the host rich text office component and the heterogeneous model service to perform layered processing of knowledge metadata, text increments, and control events within the same streaming channel. This solution should convert knowledge fragments, visible text, end events, and error events into a unified output format that the host rich text office component can process, and generate document-level historical records based on the output visible text and necessary metadata. Summary of the Invention

[0007] To address the technical challenges of existing technologies in knowledge-enhanced office writing scenarios—specifically, how to perform layered identification, text purification and writing, and historical record saving of knowledge metadata, incremental text, control events, error events, debugging fields, and JSON wrapper fields mixed in the same streaming channel—this application provides a method and apparatus for adapting a knowledge-enhanced streaming response protocol to office plugins. The technical solution is as follows: On the one hand, a knowledge-enhanced streaming response protocol adaptation method for office plugins is provided, applied to protocol adaptation services deployed between a host rich text office component and a heterogeneous model service. The method includes: Receive intelligent processing requests sent by the host rich text office component, wherein the intelligent processing requests include at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plug-in capability declaration; A knowledge enhancement strategy is determined based on the intelligent processing request. When knowledge enhancement is enabled, knowledge fragments are acquired and the knowledge fragments are standardized. Determine the response mode. If the response mode is streaming response mode, generate a knowledge event frame containing standardized knowledge fragments and send it to the host rich text office component before the main text data frame is output. The raw streaming data output from the heterogeneous model service is used to cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and the complete event blocks are identified by the streaming demultiplexing state machine. The event type is determined for the complete event block, visible text is extracted according to the candidate text field path set and text writing conditions, and visible text that meets the text writing conditions is re-encoded into plain text data frames in a unified format. Knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing the main text are excluded from the main text writing chain, and end events or error events are mapped to unified control frames; After the streaming response is completed, a document-level history associated with the document identifier is generated based on the output visible text data frames and necessary metadata.

[0008] Optionally, the knowledge enhancement strategy includes at least one of the following: whether to enable knowledge enhancement, knowledge base retrieval scope, knowledge fragment sorting rules, model service selection, response mode, and output frame type. Among them, the ranking score S of the candidate knowledge fragments i satisfy: S i =α·Sim(q,k i )+β·Sim(c,k i )+γ·R i +δ·T i And α+β+γ+δ=1, α, β, γ, δ≥0, where q represents user input, c represents document context, and k i Let R represent the i-th candidate knowledge fragment. i Indicates the reliability of the source, T i Indicates timeliness or version compatibility.

[0009] Optionally, the normalization process includes converting the knowledge fragment into a stable structure containing at least one of fragment content, source information, relevance score, fragment identifier, and citation display information; The knowledge event frame is used by the host rich text office component to display referenced materials or provide explanations, and does not participate in text cursor insertion, text DOM state updates, or rich text undo stack updates.

[0010] Optionally, the sliding buffer window is used to cache streaming data fragments that have not yet formed a complete event block, and outputs the complete event block when an event boundary is detected; The streaming demultiplexing state machine includes at least one of the following states: waiting for input, buffering, reading event name, reading data load, event block completion, event type determination, text extraction, control event processing, and exception event processing.

[0011] Optionally, the event type determination includes classifying the event block as at least one of a knowledge event, a text event, a control event, an abnormal event, or a non-text metadata event; The extraction of candidate text fields includes extracting field values ​​from at least one path among message, content, text, answer, output_text, delta.content, choices[0].delta.content, or token according to a preset set of candidate text paths, and determining candidate output text according to the priority of the set of candidate text paths.

[0012] Optionally, the text writing condition is determined by the text writing judgment value W. j express; W j=I(E j ∈E body )·I(P j ∈P white )·I(M j =0)·I(V j =1), where I is the indicator function, E j P represents the event type of the j-th event block. j Indicates the field path, M j V represents a non-text metadata identifier. j Indicates whether the field content is visible text; When W j When = 1, the corresponding candidate output text is written into the main text data frame.

[0013] Optionally, the non-text event frames include event frames containing knowledge sources, relevance scores, fragment lists, model debugging information, call identifiers, usage statistics, link tracing information, or control status; When the upstream repeatedly outputs knowledge event frames, event frames containing only knowledge metadata, or debugging event frames are parsed, the event frames are filtered, merged into metadata objects, or converted into non-text metadata that does not enter the text writing link. The plain text data frame does not contain JSON wrapper fields, knowledge fragment fields, source fields, score fields, or debugging fields from the upstream model service.

[0014] Optionally, the termination event and error event are mapped to a unified control frame output, which is used by the host rich text office component to terminate the streaming write or perform abnormal state handling. During the streaming response process, only the visible text that has been output to the plain text data frame is accumulated, and the document-level history text C is generated according to the following formula. hist : C hist =Concat(x) j |W j =1, j=1,...,N), where x j Let N represent the j-th candidate output text, and N represent the number of candidate outputs identified during the streaming response.

[0015] Optionally, the document-level history is associated with and saved in C. hist At least one of the following: user input, action type, document identifier, model information, knowledge metadata, response status, and time information; In non-streaming response mode, the protocol adaptation service calls the heterogeneous model service to obtain the complete output, and parses the complete output according to the model output protocol configuration. The model output protocol configuration includes at least one of the following: model service type, returned data format, candidate text field path set, knowledge metadata field path set, control status field path set, error field path set, and field priority rules.

[0016] On the other hand, a knowledge-enhanced streaming response protocol adaptation device for office plugins is provided, applicable to the aforementioned knowledge-enhanced streaming response protocol adaptation method for office plugins. The device includes: The request receiving module is used to receive intelligent processing requests sent by the host rich text office component. The intelligent processing request includes at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plug-in capability declaration. The knowledge enhancement processing module is used to determine a knowledge enhancement strategy based on the intelligent processing request, and to acquire knowledge fragments and perform normalization processing on the knowledge fragments when knowledge enhancement is enabled. The knowledge event generation module is used to determine the response mode. When the response mode is streaming response mode, it generates a knowledge event frame containing standardized knowledge fragments and sends it to the host rich text office component before the main text data frame is output. The streaming data access and demultiplexing module is used to access the raw streaming data output by the heterogeneous model service, cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and identify complete event blocks using a streaming demultiplexing state machine. The text extraction and re-encoding module is used to perform event type determination on the complete event block, extract visible text according to the candidate text field path set and text writing conditions, and re-encode the visible text that meets the text writing conditions into a plain text data frame in a unified format. The non-text exclusion and control frame processing module is used to exclude knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing text from the text writing link, and to map end events or error events to unified control frames. The history generation module is used to generate a document-level history associated with the document identifier based on the output visible text data frames and necessary metadata after the streaming response is completed.

[0017] Compared with the prior art, the present invention has the following significant advantages.

[0018] In this application's method, a protocol adaptation service is set up between the host rich text office component and the heterogeneous model service to uniformly process intelligent processing requests, knowledge fragments, raw streaming data, visible text, control events, and document-level history records. This enables knowledge enhancement processing, streaming data parsing, text extraction, control event processing, and history record storage to form a continuous information processing chain. Knowledge event frames are sent before the text data frame is output to separate knowledge reference information from the text writing chain. A sliding buffer window and a streaming demultiplexing state machine are used to identify complete event blocks, enabling the parsing of streaming data such as segmented returns, incomplete event boundaries, and merged returns of multiple events. Candidate text field paths and text writing conditions are used to classify candidate text data. The output text is filtered, and the visible text that meets the conditions is re-encoded into plain text data frames of a unified format, realizing unified adaptation of the output protocols of different heterogeneous model services. By excluding knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing text from the text writing link, and by performing unified control frame mapping on end events and error events, data layering processing of the knowledge layer, text layer, and control layer is realized. By generating document-level history based on the output visible text data frames, the history is kept consistent with the actual text written to the document, thereby reducing the complexity of protocol adaptation on the plugin side and reducing the writing of knowledge fragments, source information, debugging fields, control events, and JSON wrapper fields into the rich text document text and history. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the system structure provided in the embodiments of this application; Figure 2 This is a schematic diagram of the method flow provided in the embodiments of this application; Figure 3 This is a schematic diagram of streaming frame-level adaptation provided in an embodiment of this application; Figure 4 This is a schematic diagram of data layering provided for an embodiment of this application; Figure 5 A schematic diagram of a streaming demultiplexing state machine provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0022] Example 1

[0023] This describes the overall processing flow of the knowledge-enhanced streaming response protocol adaptation method for office plugins.

[0024] In this embodiment, as Figure 1 As shown, a protocol adaptation service 200 is set up between the host rich text office component 100 and the heterogeneous model service 400. The protocol adaptation service 200 can connect to the knowledge base or knowledge asset system 300 and can save the processed document-level history records to the document-level history record storage 500. The protocol adaptation service 200 includes a request parsing module 201, a knowledge retrieval and normalization module 202, a response mode determination module 203, a model output access module 204, a streaming demultiplexing state machine 205, a text extraction and recoding module 206, a control frame processing module 207, and a history saving module 208.

[0025] Figure 2 This embodiment illustrates the processing flow from receiving office plugin requests to outputting a unified streaming response and saving historical records (where the step numbers are unrelated to the numbers in the text and are described in the order shown in the figure). Figure 3 This illustrates the mapping relationship between upstream raw events, protocol adaptation processing, and unified output from the plugin side. Figure 4 This illustrates the data boundaries between the request layer, knowledge layer, text layer, control layer, and history layer. Figure 5 The state transitions of the streaming demultiplexing state machine are shown.

[0026] Step 101: Receive the intelligent processing request sent by the host rich text office component.

[0027] Intelligent processing requests include at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plugin capability declaration.

[0028] Specifically, the host rich text office component 100 can be a WPS plugin, an Office plugin, a Web rich text editor, an online document component, or an enterprise office document plugin.

[0029] The intelligent processing request is issued by the host rich text office component 100 and received by the request parsing module 201 in the protocol adaptation service 200.

[0030] Action type can be used to represent processing actions such as writing, rewriting, imitation, polishing, proofreading, summarizing, or Q&A; document identifier is used to identify the current office document; user input is used to represent the processing instructions or questions initiated by the user; context information is used to represent paragraphs, titles, selected text, context, or document structure information related to this intelligent processing in the current document; model parameters are used to represent model service selection, temperature parameters, maximum output length, or other calling parameters; knowledge base selection information is used to indicate whether to access a specified knowledge base, knowledge asset system, or knowledge scope; plug-in capability declaration is used to represent the transmission methods, frame type recognition capabilities, citation display capabilities, and text writing capabilities supported by the host rich text office component 100.

[0031] By incorporating the above information into the intelligent processing request, the protocol adaptation service 200 can form a stable input at the request layer. This request layer corresponds to... Figure 4 The output information of the request layer continues to flow to the knowledge layer, text layer, control layer, and history layer, avoiding problems such as interruption of document identification, user input, context information, or model parameters in subsequent processing.

[0032] Step 102: Determine the knowledge enhancement strategy based on the intelligent processing request, acquire knowledge fragments and perform normalization processing on the knowledge fragments when knowledge enhancement is enabled.

[0033] Specifically, the knowledge retrieval and normalization module 202 determines the knowledge enhancement strategy based on the action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plugin capability declaration. The knowledge enhancement strategy may include whether to enable knowledge enhancement, the knowledge base retrieval scope, knowledge fragment sorting rules, model service selection, response mode, and output frame type. If the knowledge base selection information indicates that access to the knowledge base or knowledge asset system 300 is required, the protocol adaptation service 200 initiates a knowledge retrieval request to the knowledge base or knowledge asset system 300 based on user input, document context, and document identifier to obtain candidate knowledge fragments.

[0034] Knowledge fragments can include fragment content, source information, relevance score, fragment identifier, and citation display information. Normalization is used to convert the different field structures returned by different knowledge bases or knowledge asset systems into a stable structure, enabling subsequent knowledge event frames to be transmitted in a unified format. The normalized knowledge fragments are... Figure 4 Data belonging to the knowledge layer does not directly enter the main text layer, nor does it enter the main text cursor insertion link.

[0035] Step 103: Determine the response mode. If the response mode is streaming response mode, generate a knowledge event frame containing standardized knowledge fragments and send it to the host rich text office component before the main text data frame is output.

[0036] Specifically, the response mode determination module 203 determines the response mode based on the model parameters, plugin capability declarations, and processing strategies in the intelligent processing request. The response mode can include streaming response mode and non-streaming response mode. In streaming response mode, the protocol adaptation service 200 generates a knowledge event frame containing standardized knowledge fragments, which is sent to the host rich text office component 100 before the main text data frame is output.

[0037] The knowledge event frame is used by the host rich text office component 100 to display cited materials or explanations. This knowledge event frame belongs to... Figure 3 The knowledge event frames in the protocol layer contain a standardized list of knowledge fragments as their data payload. The plugin handles this by displaying the cited materials independently, without including them in the main text. This setting separates the knowledge fragments from the subsequent main text data frames at the protocol layer, and also... Figure 4 The knowledge layer and the main text layer maintain a boundary.

[0038] In this embodiment, the knowledge event frame generated in step 103, the text data frame generated in step 105, and the unified control frame generated in step 106 can be encapsulated and transmitted using the frame types shown in Table 1. Table 1 illustrates the unified event frame structure output by the protocol adaptation service to the host rich text office component. The unified event frame structure includes knowledge event frames, text data frames, end control frames, error control frames, and heartbeat frames.

[0039] Table 1

[0040] As shown in Table 1, the knowledge event frame carries a list of standardized knowledge fragments for the host rich text office component to display cited materials or provide explanations, and does not participate in the main text writing; the data frame carries visible plain text that meets the conditions for main text writing, and inserts the document text in a streaming manner according to the current cursor position; the end control frame indicates the end status of the streaming response, allowing the host rich text office component to end the streaming writing process; the error control frame carries error codes, error messages, or abnormal states, allowing the host rich text office component to perform abnormal state handling; and the ping / heartbeat frame is used to maintain the connection status or detect the connection validity.

[0041] As shown in Table 1, the protocol adaptation service processes knowledge reference information, text content, control status, and connection status into different types of event frames. Only text data frames enter the text writing process; knowledge event frames, end control frames, error control frames, and ping / heartbeat frames do not participate in the rich text document text writing, thus ensuring clear data boundaries between knowledge layer data, text layer data, and control layer data.

[0042] Step 104: Access the raw streaming data output by the heterogeneous model service, cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and use the streaming demultiplexing state machine to identify complete event blocks.

[0043] Specifically, the model output access module 204 receives the raw streaming data output by the heterogeneous model service 400. The heterogeneous model service 400 can be a cloud-based model service, a local private model service, a local fallback model service, a large model compatibility interface service, or a non-streaming model interface service. The raw streaming data can be a server-sent event stream, a WebSocket message stream, or a chunked transmission response, and can also include JSON objects, plain text increments, control events, or knowledge events.

[0044] Because raw streaming data may be returned in segments, with incomplete event boundaries, or with multiple events merged during transmission, the protocol adaptation service 200 caches data fragments that have not yet formed complete event blocks using a sliding buffer window. The streaming demultiplexing state machine 205 identifies complete event blocks based on event boundaries, event names, data payloads, and end markers. Figure 5 It illustrates the state transitions between waiting for input, buffering, event block identification, event type determination, text extraction, control processing, and output recoding.

[0045] Step 105: Perform event type determination on the complete event block, extract visible text according to the candidate text field path set and text writing conditions, and re-encode the visible text that meets the text writing conditions into a plain text data frame in a unified format.

[0046] Specifically, the text extraction and recoding module 206 performs event type determination on the complete event block. The event block can be determined as a knowledge event, a text event, a control event, an exception event, or a non-text metadata event. For event blocks determined to be text events, the protocol adaptation service 200 extracts candidate output text according to the candidate text field path set. The candidate text field path set may include at least one path from message, content, text, answer, output_text, delta.content, choices[0].delta.content, or token.

[0047] After extracting candidate output text, the text extraction and re-encoding module 206 determines whether the candidate output text is visible text based on the text writing conditions. Candidate output text that meets the text writing conditions is re-encoded into a uniform format plain text data frame. This plain text data frame corresponds to... Figure 3 The data frame in the document contains visible plain text, and the host rich text office component 100 inserts the text in a streaming manner according to the cursor position.

[0048] Step 106: Exclude knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing the main text from the main text writing chain, and map the end event or error event to a unified control frame.

[0049] Specifically, the control frame processing module 207 works in conjunction with the text extraction and recoding module 206 to perform non-text processing on knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing text. Knowledge metadata may include knowledge sources, relevance scores, fragment lists, or citation display information; control metadata may include end status, error status, or call status; debugging fields may include model debugging information, call identifiers, usage statistics, or link tracing information.

[0050] When the complete event block is an end event or an error event, the control frame processing module 207 maps it to a unified control frame. The unified control frame can include end control frames and error control frames, used by the host rich text office component 100 to terminate streaming writing or perform exception handling. This control frame belongs to... Figure 4 The control layer data is not included in the main text layer, nor is it written to the main text of the rich text document.

[0051] Step 107: After the streaming response is completed, generate a document-level history associated with the document identifier based on the output visible text data frames and necessary metadata.

[0052] Specifically, after the streaming response is completed, the history saving module 208 generates document-level history text based on the visible text that has been output to the plain text data frame, and saves the document-level history text and document identifier to the document-level history storage 500. Necessary metadata may include user input, action type, document identifier, model information, knowledge metadata, response status, and time information.

[0053] The history preservation module 208 does not use raw streaming data, raw JSON objects, knowledge metadata event frames, or debug event frames as the source of the historical text. Instead, it uses the visible text that has already been output to the text data frame as the source of the historical text. As a result, the document-level history record is consistent with the actual visible text in the host rich text office component 100, and subsequent rounds of document processing can continue based on the purified historical content.

[0054] In this embodiment, by setting up a protocol adaptation service 200 between the host rich text office component 100 and the heterogeneous model service 400, intelligent processing requests, knowledge fragments, raw streaming data, visible text, control events, and document-level history are sequentially incorporated into the same processing chain. This enables the knowledge event frame, data text frame, end control frame, and error control frame to form a unified protocol contract. A sliding buffer window and streaming demultiplexing state machine are used to process streaming data with segmented returns, incomplete boundaries, and multiple event merging. Visible text is filtered using a candidate text field path set and text writing conditions, reducing the occurrence of knowledge metadata, control metadata, debugging fields, and JSON wrapper fields entering the rich text document text. By saving history based on the output visible text, document-level history can correspond to the text actually written by the user in the document.

[0055] Example 2

[0056] This embodiment illustrates the specific implementation of the knowledge enhancement strategy and candidate knowledge fragment ranking based on Embodiment 1. This embodiment further refines step 102 of Embodiment 1.

[0057] Based on step 102 of Example 1, the knowledge enhancement strategy includes at least one of the following: whether to enable knowledge enhancement, knowledge base retrieval scope, knowledge fragment sorting rules, model service selection, response mode, and output frame type.

[0058] Specifically, whether to enable knowledge enhancement is used to determine whether to initiate a search to the knowledge base or knowledge asset system 300; the knowledge base search scope is used to limit the searched knowledge base, document collection, enterprise knowledge assets, or user-specified knowledge scope; the knowledge fragment sorting rules are used to determine the sorting order of multiple candidate knowledge fragments; the model service selection is used to determine whether to call the cloud model service, the local private model service, the local fallback model service, or the compatible interface model; the response mode is used to determine whether to use the streaming response mode or the non-streaming response mode; and the output frame type is used to determine whether to output a knowledge event frame, a data body frame, an end control frame, or an error control frame.

[0059] Among them, the ranking score S of the candidate knowledge fragments i satisfy: Si =α·Sim(q,k i )+β·Sim(c,k i )+γ·R i +δ·T i And α+β+γ+δ=1, α, β, γ, δ≥0, where q represents user input, c represents document context, and k i Sim(q,k) represents the i-th candidate knowledge fragment. i ) represents the user input q and the i-th candidate knowledge fragment k. i The semantic similarity between them, Sim(c,k) i ) represents the document context c and the i-th candidate knowledge fragment k. i Semantic similarity between them. R i Used to indicate the reliability of a knowledge fragment's source, for example, it can be determined based on the type of knowledge source, source level, document review status, or the trustworthiness level of the knowledge asset. i Used to represent timeliness or version matching, for example, it can be determined based on the knowledge fragment update time, version number, document identifier association, or business version consistency. α, β, γ, and δ represent the weight parameters of each indicator, and the sum of the weights is 1, with each weight parameter not less than 0.

[0060] The protocol adaptation service 200 can sort candidate knowledge fragments according to the ranking score Si, and determine the candidate knowledge fragments that meet the threshold or are ranked higher as the knowledge fragments to be output. The knowledge fragments to be output are sent to the knowledge retrieval and normalization module 202 for normalization processing, and are encapsulated into knowledge event frames in streaming response mode.

[0061] In this embodiment, by incorporating user input, document context, source reliability, and timeliness or version matching into the ranking score Si, the selection of knowledge fragments can correspond to the current office document processing scenario. By linking the ranking results with knowledge event frames, the knowledge layer data can be organized and transmitted before the main text is output, providing a consistent data foundation for subsequent main text generation and citation display.

[0062] Example 3

[0063] This embodiment is used to illustrate the lower-level implementation of knowledge fragment normalization processing and knowledge event frames based on Embodiment 1. This embodiment further refines steps 102 and 103 in Embodiment 1.

[0064] Based on step 102 of Example 1, the normalization process includes converting the knowledge fragment into a stable structure containing at least one of fragment content, source information, relevance score, fragment identifier and reference display information.

[0065] Specifically, the fragment content represents the text content recalled by the knowledge base or knowledge asset system 300. Source information indicates the file name, document path, knowledge base name, page location, paragraph location, or business source corresponding to the knowledge fragment. The relevance score indicates the degree of matching between the knowledge fragment and the user input q or the document context c. The fragment identifier is used to identify the knowledge fragment during subsequent citation display, history saving, or issue tracking. Citation display information allows the host rich text office component 100 to display the knowledge source, cited materials, or reference explanations on the plugin side.

[0066] The data fields returned by different knowledge bases or knowledge asset systems may differ. For example, some knowledge bases return the `source` field, some return the `doc_id` field, and some return the `score` field. Normalization processes map these differing fields into a stable structure, enabling subsequent knowledge event frames to be reliably recognized by the host rich text office component.

[0067] Based on step 103 of Example 1, the knowledge event frame is used for the host rich text office component to display reference materials or provide instructions, and does not participate in the insertion of the text cursor, the update of the text DOM state, or the update of the rich text undo stack.

[0068] Specifically, the knowledge event frame can be located at the beginning of the streaming response and output before the data body frame. After receiving the knowledge event frame, the host rich text office component 100 can display knowledge fragments in the plugin sidebar, reference list, floating panel, or description area without writing them into the current document body. Text cursor insertion, text DOM state updates, and rich text undo stack updates are only triggered by the data body frame; the knowledge event frame does not trigger these text writing actions.

[0069] In this embodiment, by standardizing knowledge fragments and transmitting them independently using knowledge event frames, knowledge citation information can be separated from the text writing link at the protocol layer. By prohibiting knowledge event frames from participating in text cursor insertion, text DOM state updates, and rich text undo stack updates, the number of times citations, source information, or relevance scores enter the document text can be reduced.

[0070] Example 4

[0071] This embodiment illustrates the lower-level implementation of the sliding buffer window and the streaming demultiplexing state machine based on Embodiment 1. This embodiment further refines step 104 in Embodiment 1.

[0072] Based on step 104 of Example 1, a sliding buffer window is used to cache streaming data fragments that have not yet formed a complete event block, and outputs the complete event block when an event boundary is identified.

[0073] Specifically, raw streaming data may arrive at Protocol Adaptation Service 200 in chunks. A complete event block may be split into multiple data segments, or multiple complete event blocks may be merged into the same transmission segment. The sliding buffer window receives the currently arriving data segment and concatenates it with the preceding incomplete data segment to form buffer content. When an event boundary, line separator, data payload end marker, or streaming protocol-defined boundary is identified in the buffer content, the sliding buffer window outputs a complete event block; for the remaining data that has not formed a complete event block, the sliding buffer window continues to retain it until the next data arrival for processing.

[0074] Based on step 104 of Embodiment 1, the streaming demultiplexing state machine includes at least one of the following states: waiting for input, buffering, reading event name, reading data load, event block completion, event type determination, text extraction, control event processing, and exception event processing.

[0075] Specifically, the "Waiting for Input" state is used to wait for the heterogeneous model service 400 to output raw streaming data; the "Buffering" state is used to receive and cache data fragments that have not yet formed a complete event block; the "Read Event Name" state is used to identify the event name or default event type in the event block; the "Read Data Load" state is used to parse the data content in the event block; the "Event Block Complete" state is used to confirm that the current event block has met the output conditions; the "Event Type Determination" state is used to determine whether the current event block belongs to a knowledge event, text event, control event, abnormal event, or non-text metadata event; the "Text Extraction" state is used to extract candidate output text from the text event; the "Control Event Processing" state is used to map events such as knowledge / data / end / error to a unified control frame; and the "Abnormal Event Processing" state is used to handle parsing failures, missing fields, abnormal data formats, or upstream error events.

[0076] Table 2

[0077] As shown in Table 2, the streaming demultiplexing state machine in this embodiment processes the original streaming data according to the state, triggering condition, processing action, and next state. The state machine waits for upstream data segments in the waiting input state; upon receiving a data segment, it enters the buffer state and appends the data segment to the sliding buffer window; when the buffer in the sliding buffer window meets the event boundary conditions, it enters the event block identification state and segments out complete event blocks; after obtaining the complete event block, it enters the event type determination state to identify whether the current event block belongs to a knowledge event, text event, control event, or non-text event.

[0078] For event blocks identified as main content events, the state machine enters the main content extraction state, extracts the field values ​​corresponding to candidate main content paths from the event block, and performs field whitelist determination. For event blocks identified as end or error, the state machine enters the control processing state, mapping the event block to a unified control frame. For event blocks with abnormal format, upstream failure, or inability to be parsed correctly, the state machine enters the exception handling state, generating an error control frame or switching to the local fallback model. After the main content extraction or control processing is completed, the state machine enters the output recoding state, encapsulates the visible main content or control events into a unified contract frame and outputs it, then returns to the waiting input state to continue processing subsequent upstream data fragments.

[0079] Through the state transition mechanism shown in Table 2, the protocol adaptation service can continuously process segmented returns, incomplete event boundaries, multiple event merged returns, and abnormal events without interrupting the streaming response, thus forming a definite data flow relationship between complete event block identification, event type determination, text extraction, control processing, and output recoding.

[0080] Figure 5 The state transitions in the diagram show that the streaming demultiplexing state machine 205 does not simply pass on upstream events, but rather forms a continuous processing link between event boundary identification, event type determination, text extraction, and control processing. After the complete event block is identified, the data continues to flow to the text extraction and recoding module 206 or the control frame processing module 207.

[0081] In this embodiment, by using a sliding buffer window to cache incomplete event blocks and outputting complete event blocks at event boundaries, it is possible to handle segmented returns and multiple event merging in streaming transmission. By using a streaming demultiplexing state machine with 205 states to process event names, data payloads, event types, text extraction, and control events, it is possible to convert complex upstream streaming protocols into stable internal event processing flows.

[0082] Example 5

[0083] This embodiment is used to illustrate the lower-level implementation of event type determination and candidate text field extraction based on Embodiment 1. This embodiment further refines step 105 in Embodiment 1.

[0084] Based on step 105 of Example 1, the event type determination includes determining the event block as at least one of knowledge event, text event, control event, abnormal event, or non-text metadata event.

[0085] Specifically, knowledge events can include knowledge events or data events containing knowledge fragments, knowledge sources, and citation information. Content events can include data events, default content events, or data events containing candidate content increments. Control events can include end events, done events, finish events, or events indicating the end of a streaming response. Exception events can include error events, exception status code events, or model service call failure events. Non-content metadata events can include data events containing only model debugging information, call identifiers, usage statistics, trace information, or control status.

[0086] Event type determination can be performed based on event name, field path, data load structure, control status field, error field, or model output protocol configuration. The result of the event type determination determines whether the current event block enters the knowledge layer, text layer, control layer, exception handling process, or metadata processing process.

[0087] Based on step 105 of embodiment 1, the extraction of candidate text fields includes extracting field values ​​from at least one path among message, content, text, answer, output_text, delta.content, choices[0].delta.content or token according to a preset candidate text path set, and determining candidate output text according to the priority of the candidate text path set.

[0088] Specifically, different heterogeneous model services 400 may use different output fields to represent the generated text. Some model services use the message field to represent text content, some model services use the content field or text field to represent text content, some question-and-answer interfaces use the answer field to represent answer content, some compatible interfaces use the output_text field or choices[0].delta.content field to represent incremental text, and some streaming interfaces use the token field to represent text fragments of a single output.

[0089] The candidate text path set can be configured according to priority. For example, when choices[0].delta.content exists and its content is visible text, it is used as the candidate output text; when the path does not exist, paths such as content, text, answer, or token are checked. The protocol adaptation service 200 determines the candidate output text according to the field priority rules and sends the candidate output text into the text writing condition determination process.

[0090] As shown in Table 3, this embodiment configures candidate text paths and adapted output methods according to different upstream structure types.

[0091] Table 3

[0092] For regular JSON body, the protocol adaptation service can extract candidate body from the message, content, or text paths, and output it as a plain text body data frame after the body writing conditions are met; for large model compatible interface increments, the protocol adaptation service can extract incremental body from the choices[0].delta.content path, and re-encode the extracted visible text into a plain text body data frame; for local model token output, the protocol adaptation service can extract candidate output text from the token or output_text path, and output it as a plain text body data frame in streaming order.

[0093] For knowledge metadata events, fields such as `kb_snippets`, `sources`, or `score` represent knowledge fragments, knowledge sources, or relevance scores. These fields are not included in the main text writing process but can be included in the knowledge event frame or metadata object. For control events, fields such as `finish_reason`, `error`, or `status` represent the end status, error status, or response status. The protocol adaptation service maps these to a unified end control frame or error control frame. Thus, the protocol adaptation service can extract visible main text based on the candidate main text path set for the original structure returned by different heterogeneous model services, while separating knowledge metadata and control status from the main text writing process.

[0094] The path configuration shown in Table 3 corresponds to the event type determination, candidate text field extraction, and text recoding processing in step 105. Through this path configuration, ordinary JSON text, incremental outputs from large model-compatible interfaces, and local model token outputs can be uniformly converted into plain text data frames; knowledge metadata events and control events are respectively entered into knowledge event frames, metadata objects, or unified control frames, thus ensuring that text data, knowledge data, and control data are transmitted in a layered manner during protocol adaptation.

[0095] In this embodiment, by classifying event blocks into knowledge events, text events, control events, exception events, and non-text metadata events, different types of data can enter the corresponding processing links; by making the candidate text path set compatible with multiple model output fields, the repeated adaptation of the plugin to different upstream model services can be reduced, and the consistent naming of candidate output text in subsequent text writing condition determination can be maintained.

[0096] Example 6

[0097] This embodiment illustrates the specific implementation of the text writing conditions and text writing determination values ​​based on Embodiment 1. This embodiment further refines step 105 in Embodiment 1.

[0098] Based on 105 of Example 1, the text writing condition is determined by the text writing judgment value W. j express.

[0099] Specifically, the text is written to the judgment value W. j This indicates whether the j-th candidate output text can be included in the main text data frame. Main text write decision value W j satisfy: W j =I(E j ∈E body )·I(P j ∈P white )·I(M j =0)·I(V j =1), where I is the indicator function, E j P represents the event type of the j-th event block. j Indicates the field path, M j V represents a non-text metadata identifier. j Indicates whether the field content is visible text.

[0100] Specifically, I(E j ∈E body I(P) is used to determine whether the j-th event block belongs to the main text event type set. j ∈P white Used to determine field path P j Does it belong to the field whitelist set? I(M) j =0) is used to determine whether the field has not been marked as non-text metadata. I(V j =1) Used to determine whether the field content is visible text. W will only be active if all of the above conditions are met. j The value is 1.

[0101] In one possible implementation, when W j When = 1, the corresponding candidate output text is written into the main text data frame.

[0102] Specifically, when W j When W = 1, the text extraction and re-encoding module 206 treats the j-th candidate output text as visible text and re-encodes it into a plain text data frame in a unified format. This plain text data frame is then output to the host rich text office component 100, which then streams and inserts the document text according to the current cursor position. jWhen the value is not 1, the corresponding field will not enter the text writing chain and can be filtered, merged into a metadata object, or handed over to the control frame processing module 207 for processing.

[0103] In this embodiment, the determination value W is written into the text. j Combining event type, field path, non-text metadata identifier, and visible text judgment into a unified judgment logic can avoid directly writing to the text based solely on field name or event name; by only using W... j When the value is 1, the main text data frame is output, which makes the source of the main text data clear and provides a clear basis for the generation of subsequent document-level historical text (Chist).

[0104] Example 7

[0105] This embodiment illustrates the processing methods for non-text event frames, repeated knowledge event frames, and plain text data frames, based on Embodiment 6. This embodiment further refines step 106 in Embodiment 1.

[0106] Based on Example 6, non-text event frames include event frames containing knowledge sources, relevance scores, fragment lists, model debugging information, call identifiers, usage statistics, link tracing information, or control status.

[0107] Specifically, non-text event frames can originate from knowledge base retrieval results, model gateways, model service debugging information, or call chain information. Knowledge sources, relevance scores, and fragment lists belong to the knowledge layer data; model debugging information, call identifiers, usage statistics, and link tracing information belong to metadata or debugging data; and control status belongs to the control layer data. These fields can be used for reference display, call statistics, anomaly location, or status control, but are not part of the rich text document body.

[0108] When parsing upstream repeated output knowledge event frames, event frames containing only knowledge metadata, or debug event frames, the event frames are filtered, merged into metadata objects, or converted into non-text metadata that does not enter the text writing chain.

[0109] Specifically, in some heterogeneous model services 400 or model gateways, knowledge event frames may be repeatedly output in the upstream streaming channel, or knowledge metadata and model debugging events may appear mixed in the same streaming channel. After identifying such event frames, the protocol adaptation service 200 does not convert them into data body frames, but performs filtering, merging, or metadata processing based on field types. For example, duplicate knowledge event frames can be merged based on fragment identifiers; event frames containing only knowledge metadata can be merged into knowledge metadata objects; and debugging event frames can be added to debugging logs or link tracing objects.

[0110] The plain text data frame does not contain JSON wrapper fields, knowledge fragment fields, source fields, score fields, or debug fields from the upstream model service.

[0111] Specifically, the payload of the plain text data frame is visible plain text, without carrying the wrapper fields from the original JSON structure of the upstream model service, the knowledge fragment fields from the knowledge event frame, or the source, score, or debugging fields. For the JSON wrapper content in the upstream original event, the protocol adaptation service 200 only extracts the field values ​​that meet the text writing conditions from the candidate text field path set and outputs these field values ​​as plain text.

[0112] In this embodiment, by filtering, merging, or metadata processing the non-text event frames, the knowledge source, relevance score, fragment list, debugging information, and link tracing information can be retained in the knowledge layer, control layer, or metadata layer. By limiting the plain text data frames of the main text to not contain JSON wrapper fields, knowledge fragment fields, source fields, score fields, or debugging fields, the boundary of the main text writing can be further stabilized.

[0113] Example 8

[0114] This embodiment illustrates the specific implementation of the termination event, error event, and document-level history generation based on Embodiment 1. This embodiment further refines steps 106 and 107 of Embodiment 1.

[0115] Based on step 106 of Example 1, the end event and error event are mapped to a unified control frame output, which is used by the host rich text office component to end streaming writing or perform abnormal state handling.

[0116] Specifically, when the protocol adaptation service 200 parses "end," "done," "finish," or other events indicating the end of the streaming response, it maps the event to a unified end control frame. When the protocol adaptation service 200 parses "error," an exception status code, a model call failure message, or a response timeout message, it maps the event to a unified error control frame. After receiving the unified end control frame, the host rich text office component 100 can terminate the streaming write state; after receiving the unified error control frame, it can perform exception handling, such as stopping further writing, displaying an exception status, or preserving the written content based on existing text data frames.

[0117] Based on step 107 of Example 1, during the streaming response process, only the visible text that has been output to the plain text data frame is accumulated, and the document-level history text C is generated according to the following formula. hist : C hist =Concat(x)j |W j =1, j=1,...,N), where x j Let N represent the j-th candidate output text, and N represent the number of candidate outputs identified during the streaming response.

[0118] Specifically, Concat concatenates candidate output text in the order it was output during the streaming response. j For the j-th candidate output text, only when the corresponding body text is written to the judgment value W j When x = 1, j Only then was it included in the document-level history text C hist N represents the number of candidate outputs identified during the streaming response, not the number of original upstream events. Therefore, knowledge metadata events, control events, error events, debug events, JSON wrapper fields, and fields that do not meet the conditions for writing the main text will not be concatenated to C. hist .

[0119] In this embodiment, by using unified control frames to handle end events and error events, the host rich text office component 100 can identify the end of streaming write and abnormal states according to the unified protocol; through W... j Candidate output text generation C = 1 hist This allows document-level history text to originate only from the visible text that has already been output to the text data frame, reducing the possibility of history being polluted by raw JSON, knowledge metadata, or debugging fields.

[0120] Example 9

[0121] This embodiment illustrates the specific implementation of document-level history record association and non-streaming response mode based on Embodiment 8. This embodiment further refines step 107 in Embodiment 1 and supplements the non-streaming response mode.

[0122] Based on Example 8, document-level history records are associated and saved in C. hist At least one of the following: user input, action type, document identifier, model information, knowledge metadata, response status, and time information.

[0123] Specifically, C histThis is the document-level history generated from the visible text already output to the plain text data frame. User input represents the input content for this round of intelligent processing requests. Action type indicates processing types such as writing, rewriting, paraphrasing, polishing, proofreading, summarizing, or question-and-answer. Document identifier associates history with specific office documents. Model information indicates whether the cloud model, local private model, local fallback model, or compatible interface model is being invoked. Knowledge metadata records the knowledge fragment identifiers, source information, relevance scores, or citation display information used in this knowledge enhancement process. Response status indicates normal completion, error completion, timeout, or model service switching. Time information indicates the request time, response completion time, or history record retention time.

[0124] Through the aforementioned associated storage method, the document-level history storage 500 not only saves the visible text but also retains necessary request, model, knowledge, and state information. This document-level history can serve as the data foundation for subsequent document processing, multi-turn question answering, audit trails, or context building.

[0125] In non-streaming response mode, the protocol adaptation service calls the heterogeneous model service to obtain the complete output, and parses the complete output according to the model output protocol configuration. The model output protocol configuration includes at least one of the following: model service type, returned data format, candidate text field path set, knowledge metadata field path set, control status field path set, error field path set, and field priority rules.

[0126] Specifically, when the response mode determination module 203 determines that the response mode is a non-streaming response mode, the protocol adaptation service 200 does not enter the aforementioned streaming adaptation process, but instead calls the heterogeneous model service 400 to obtain the complete output. The complete output can be plain text, a JSON object, or a composite data structure containing body text, knowledge metadata, control status, and error information. The protocol adaptation service 200 parses the complete output according to the model output protocol configuration.

[0127] The model service type identifies cloud-based models, local private models, local fallback models, large model compatible interface services, or non-streaming model interface services. The returned data format identifies the data format of the complete output. The candidate text field path set is used to extract candidate text from the complete output. The knowledge metadata field path set is used to extract knowledge sources, fragment lists, or relevance scores. The control status field path set is used to extract response status. The error field path set is used to extract error codes, error messages, or exception states. The field priority rule determines the extraction order of candidate text, knowledge metadata, control status, or error messages when multiple fields exist simultaneously.

[0128] The protocol adaptation service 200 extracts candidate text from the complete output according to field priority rules, and performs field whitelist filtering, visible text determination, and separation of non-text metadata on the candidate text. The processed standardized knowledge fragments, visible text, control status, and error messages can be encapsulated into a unified response object and returned to the host rich text office component 100.

[0129] In this embodiment, by using C hist By associating and saving data with user input, action type, document identifier, model information, knowledge metadata, response status, and time information, the history records can contain both visible text and necessary contextual information. By configuring the parsing of the complete output using the model output protocol in non-streaming response mode, the protocol adaptation service 200 can cover both streaming and non-streaming model interfaces, while maintaining consistency in candidate text extraction, knowledge metadata separation, and error status handling.

[0130] In some embodiments, when the cloud model service is unavailable, times out, or does not meet the processing strategy, the protocol adaptation service 200 can switch to a local model service or a local fallback model service, while maintaining the protocol contract of the knowledge event frames, data body frames, and unified control frames output to the host rich text office component 100. Therefore, the host rich text office component 100 does not need to change its reference display, text writing, and state control logic due to changes in the model service source.

[0131] In some embodiments, the protocol adaptation service 200 can also output a unified response as at least one of a server-sent event stream, a WebSocket message stream, or a chunked transmission response, based on the capability declarations and transmission capabilities of different host rich text office components 100. Under different transmission methods, the logical meanings of the knowledge event frame, data body data frame, end control frame, and error control frame remain consistent; the difference lies in the transmission channel and message encapsulation method.

[0132] On the other hand, a knowledge-enhanced streaming response protocol adaptation device for office plugins is also provided, applicable to the aforementioned knowledge-enhanced streaming response protocol adaptation method for office plugins. The device includes: The request receiving module is used to receive intelligent processing requests sent by the host rich text office component. The intelligent processing request includes at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plug-in capability declaration. The knowledge enhancement processing module is used to determine a knowledge enhancement strategy based on the intelligent processing request, and to acquire knowledge fragments and perform normalization processing on the knowledge fragments when knowledge enhancement is enabled. The knowledge event generation module is used to determine the response mode. When the response mode is streaming response mode, it generates a knowledge event frame containing standardized knowledge fragments and sends it to the host rich text office component before the main text data frame is output. The streaming data access and demultiplexing module is used to access the raw streaming data output by the heterogeneous model service, cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and identify complete event blocks using a streaming demultiplexing state machine. The text extraction and re-encoding module is used to perform event type determination on the complete event block, extract visible text according to the candidate text field path set and text writing conditions, and re-encode the visible text that meets the text writing conditions into a plain text data frame in a unified format. The non-text exclusion and control frame processing module is used to exclude knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing text from the text writing link, and to map end events or error events to unified control frames. The history generation module is used to generate a document-level history associated with the document identifier based on the output visible text data frames and necessary metadata after the streaming response is completed.

[0133] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the knowledge-enhanced streaming response protocol adaptation method for office plugins described in any of the above embodiments.

[0134] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the knowledge-enhanced streaming response protocol adaptation method for office plugins provided in the above embodiments.

[0135] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0136] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above are merely optional embodiments of this application and are not intended to limit the application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A knowledge-enhanced streaming response protocol adaptation method for office plugins, characterized in that, The method, applied to a protocol adaptation service deployed between a host rich text office component and a heterogeneous model service, includes: Receive intelligent processing requests sent by the host rich text office component, wherein the intelligent processing requests include at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plug-in capability declaration; A knowledge enhancement strategy is determined based on the intelligent processing request. When knowledge enhancement is enabled, knowledge fragments are acquired and the knowledge fragments are standardized. Determine the response mode. If the response mode is streaming response mode, generate a knowledge event frame containing standardized knowledge fragments and send it to the host rich text office component before the main text data frame is output. The raw streaming data output from the heterogeneous model service is used to cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and the complete event blocks are identified by the streaming demultiplexing state machine. The event type is determined for the complete event block, visible text is extracted according to the candidate text field path set and text writing conditions, and visible text that meets the text writing conditions is re-encoded into plain text data frames in a unified format. Knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing the main text are excluded from the main text writing chain, and end events or error events are mapped to unified control frames; After the streaming response is completed, a document-level history associated with the document identifier is generated based on the output visible text data frames and necessary metadata.

2. The method according to claim 1, characterized in that, The knowledge enhancement strategy includes at least one of the following: whether to enable knowledge enhancement, knowledge base retrieval scope, knowledge fragment sorting rules, model service selection, response mode, and output frame type. Among them, the ranking score S of the candidate knowledge fragments i satisfy: S i =α·Sim(q,k i )+β·Sim(c,k i )+γ·R i +δ·T i And α+β+γ+δ=1, α, β, γ, δ≥0, where q represents user input, c represents document context, and k i Let R represent the i-th candidate knowledge fragment. i Indicates the reliability of the source, T i Indicates timeliness or version compatibility.

3. The method according to claim 1, characterized in that, The normalization process includes converting knowledge fragments into a stable structure that includes at least one of fragment content, source information, relevance score, fragment identifier, and citation display information; The knowledge event frame is used by the host rich text office component to display referenced materials or provide explanations, and does not participate in text cursor insertion, text DOM state updates, or rich text undo stack updates.

4. The method according to claim 1, characterized in that, The sliding buffer window is used to cache streaming data fragments that have not yet formed a complete event block, and outputs the complete event block when an event boundary is detected; The streaming demultiplexing state machine includes at least one of the following states: waiting for input, buffering, reading event name, reading data load, event block completion, event type determination, text extraction, control event processing, and exception event processing.

5. The method according to claim 1, characterized in that, The event type determination includes classifying the event block as at least one of the following: knowledge event, text event, control event, abnormal event, or non-text metadata event; The extraction of candidate text fields includes extracting field values ​​from at least one path among message, content, text, answer, output_text, delta.content, choices[0].delta.content, or token according to a preset set of candidate text paths, and determining candidate output text according to the priority of the set of candidate text paths.

6. The method according to claim 1, characterized in that, The text writing condition is determined by the text writing judgment value W. j express; W j =I(E j ∈E body )·I(P j ∈P white )·I(M j =0)·I(V j =1), where I is the indicator function, E j P represents the event type of the j-th event block. j Indicates the field path, M j V represents a non-text metadata identifier. j Indicates whether the field content is visible text; When W j When = 1, the corresponding candidate output text is written into the main text data frame.

7. The method according to claim 6, characterized in that, The non-text event frames include event frames containing knowledge sources, relevance scores, fragment lists, model debugging information, call identifiers, usage statistics, link tracing information, or control status. When the upstream repeatedly outputs knowledge event frames, event frames containing only knowledge metadata, or debugging event frames are parsed, the event frames are filtered, merged into metadata objects, or converted into non-text metadata that does not enter the text writing link. The plain text data frame does not contain JSON wrapper fields, knowledge fragment fields, source fields, score fields, or debugging fields from the upstream model service.

8. The method according to claim 1, characterized in that, The termination event and error event are mapped to a unified control frame output, which is used by the host rich text office component to terminate streaming or perform abnormal state handling. During the streaming response process, only the visible text that has been output to the plain text data frame is accumulated, and the document-level history text C is generated according to the following formula. hist : C hist =Concat(x) j |W j =1, j=1,...,N), where x j Let N represent the j-th candidate output text, and N represent the number of candidate outputs identified during the streaming response.

9. The method according to claim 8, characterized in that, The document-level history record is associated with and saved in C. hist At least one of the following: user input, action type, document identifier, model information, knowledge metadata, response status, and time information; In non-streaming response mode, the protocol adaptation service calls the heterogeneous model service to obtain the complete output, and parses the complete output according to the model output protocol configuration. The model output protocol configuration includes at least one of the following: model service type, returned data format, candidate text field path set, knowledge metadata field path set, control status field path set, error field path set, and field priority rules.

10. A knowledge-enhanced streaming response protocol adapter for office plugins, characterized in that, The apparatus, applicable to the knowledge-enhanced streaming response protocol adaptation method for office plugins according to any one of claims 1 to 9, comprises: The request receiving module is used to receive intelligent processing requests sent by the host rich text office component. The intelligent processing request includes at least one of the following: action type, document identifier, user input, context information, model parameters, knowledge base selection information, and plug-in capability declaration. The knowledge enhancement processing module is used to determine a knowledge enhancement strategy based on the intelligent processing request, and to acquire knowledge fragments and perform normalization processing on the knowledge fragments when knowledge enhancement is enabled. The knowledge event generation module is used to determine the response mode. When the response mode is streaming response mode, it generates a knowledge event frame containing standardized knowledge fragments and sends it to the host rich text office component before the main text data frame is output. The streaming data access and demultiplexing module is used to access the raw streaming data output by the heterogeneous model service, cache data fragments that have not yet formed complete event blocks through a sliding buffer window, and identify complete event blocks using a streaming demultiplexing state machine. The text extraction and re-encoding module is used to perform event type determination on the complete event block, extract visible text according to the candidate text field path set and text writing conditions, and re-encode the visible text that meets the text writing conditions into a plain text data frame in a unified format. The non-text exclusion and control frame processing module is used to exclude knowledge metadata, control metadata, debugging fields, and fields that do not meet the conditions for writing text from the text writing link, and to map end events or error events to unified control frames. The history generation module is used to generate a document-level history associated with the document identifier based on the output visible text data frames and necessary metadata after the streaming response is completed.

Images