Session-level document context replacement injection method and system

Abstract

The embodiment of the application discloses a kind of session level document context replacement injection method and system, wherein the method comprises: obtaining the input content of the current round of dialogue and identifying the session identifier corresponding to the current round of dialogue, and the input document in the input content is standardized;According to the session identifier, determine the corresponding context document, the context document includes original text content;Extract the input document in the input content, judge whether each input document exists in the context document;When at least one input document does not exist in the context document, generate standard text content according to all input documents, and replace the original text content with the standard text content, process the standard text content with a large language model to obtain a processing result;Otherwise, process the original text content with a large language model to obtain a processing result.Improve the accuracy and efficiency of large model processing to generate test cases.

Description

Technical Field

[0001] This invention relates to the field of software testing, and in particular to a session-level document context replacement injection method and system. Background Technology

[0002] In engineering practice, the common process for automatically generating test cases based on large language models is "user inputs requirement description → system reads document → model outputs test cases". However, this approach has the following shortcomings: First, document entry points are scattered and the workflow is complex. Uploading attachments, online links, and different file formats are often handled by different modules, lacking a unified document access layer. Test engineers need to manually convert document formats or switch operation paths, which is inefficient and prone to errors.

[0003] Second, document context pollution. The existing solution uses an append-only strategy, where each round of uploaded document content is continuously added to the existing context, resulting in a continuous accumulation of historical documents. When users upload new versions of requirement documents or switch test tasks, the model still references outdated content, causing the output test cases to deviate from the current requirements.

[0004] Third, there is the issue of redundant document parsing. When repeatedly querying the same requirement document, existing technologies re-parse the document each time, resulting in wasted computing resources and increased response latency, and lacking a mechanism for reusing parsing results.

[0005] Fourth, interference between dialogues. The lack of session-level document isolation capabilities allows document content from dialogues in different test tasks to easily become mixed up, affecting the accuracy of test case generation.

[0006] To address the aforementioned issues, several existing technical solutions exist, such as document question-answering systems based on Retrieval Augmentation Generation (RAG) and single-turn document processing tools based on file uploads. The RAG approach segments documents into semantic fragments and stores them in a vector database, allowing users to retrieve relevant fragments when asking questions. While suitable for large-scale knowledge base question answering, document segmentation can disrupt the integrity of requirement descriptions in test case generation scenarios. Furthermore, its retrieval mechanism cannot guarantee the consistency and controllability of document context across multiple rounds of dialogue, and inference biases caused by erroneous recall of historical fragments still exist. Single-turn document processing tools, on the other hand, process each round of dialogue independently and do not support maintaining document context across rounds. Users need to repeatedly upload the same documents, failing to meet the requirements of continuously evolving test designs.

[0007] There is currently no effective solution to the above problems in existing technologies. Summary of the Invention

[0008] To address the aforementioned issues, this invention provides a session-level document context replacement injection method and system. By maintaining an independent context document for each session, the method normalizes the format of all user-uploaded documents in each round of dialogue and determines whether they already exist in the current session. When a new document is added, the original document content is replaced entirely with the newly generated standard text; otherwise, the original content is reused. This unifies document entry points, avoids context pollution, eliminates redundant parsing, and achieves session isolation.

[0009] To achieve the above objectives, this invention provides a session-level document context replacement injection method, comprising: acquiring the input content of the current dialogue and identifying the session identifier corresponding to the current dialogue, and standardizing the input documents in the input content; determining the corresponding context document according to the session identifier, wherein the context document includes the original text content; extracting the input documents in the input content, and determining whether each input document already exists in the context document; when at least one input document does not exist in the context document, generating standard text content based on all input documents, and replacing the original text content with the standard text content, and performing large language model processing on the standard text content to obtain the processing result; otherwise, performing large language model processing on the original text content to obtain the processing result.

[0010] Further optionally, determining whether each input document already exists in the context document includes: obtaining the current document fingerprint set corresponding to the context document; for any input document, calculating the hash value of the input document as a document fingerprint; comparing whether the document fingerprint exists in the current document fingerprint set; if so, determining that any input document already exists in the context document; otherwise, determining that any input document does not exist in the context document.

[0011] Optionally, the step of generating standard text content based on all input documents and replacing the original text content with the standard text content includes: for any input document, if the document fingerprint of any input document does not exist in the current document fingerprint set, then parse the input document to obtain parsed text and store it; otherwise, obtain the stored parsed text corresponding to any input document; concatenate the parsed text corresponding to all input documents according to a preset rule to obtain the standard text content; replace the original text content with the standard text content, and update the current document fingerprint set with the document fingerprints corresponding to all input documents.

[0012] Further optionally, the step of parsing any input document to obtain parsed text includes: when the input document is a portable document format file, calling a PDF parsing library to extract the text and paragraph structure to obtain parsed text; when the input document is a word processing document file, calling a document parsing component to extract the main text content and structured elements to obtain parsed text; when the input document is a plain text file, performing encoding detection and fault-tolerant decoding to read the text content to obtain parsed text; when the input document is an online document link, retrieving the document main text through the application programming interface of the corresponding platform to obtain parsed text.

[0013] Optionally, before retrieving the document body through the application programming interface (API) of the corresponding platform, the process includes: reading the access token in the local cache and identifying the expiration time of the access token; calculating the remaining valid duration based on the current time and the expiration time; if the remaining valid duration is greater than a preset time threshold, using the access token to call the API; if the remaining valid duration is not greater than the preset time threshold, using the refresh token in the local cache to make a refresh request; if the refresh request is successful, obtaining the latest access token and the latest refresh token, and using the latest access token to call the API; otherwise, using an application-level token or a tenant-level token to call the API.

[0014] On the other hand, the present invention also provides a session-level document context replacement injection system, comprising: a data acquisition module, used to acquire the input content of the current round of dialogue and identify the session identifier corresponding to the current round of dialogue, and standardize the input documents in the input content; a text mapping module, used to determine the corresponding context document according to the session identifier, the context document including the original text content; a judgment module, used to extract the input documents in the input content and determine whether each input document already exists in the context document; and a data processing module, used to generate standard text content based on all input documents when at least one input document does not exist in the context document, and replace the original text content with the standard text content, and process the standard text content using a large language model to obtain a processing result; otherwise, process the original text content using a large language model to obtain a processing result.

[0015] Further optionally, the determination module includes: a fingerprint set acquisition submodule, used to acquire the current document fingerprint set corresponding to the context document; a hash calculation submodule, used to calculate the hash value of any input document as a document fingerprint for any input document; and a determination submodule, used to compare whether the document fingerprint exists in the current document fingerprint set, and if so, determine that any input document already exists in the context document; otherwise, determine that any input document does not exist in the context document.

[0016] Further optionally, the data processing module includes: a text parsing determination submodule, used to parse any input document if the document fingerprint of any input document does not exist in the current document fingerprint set, to obtain and store the parsed text; otherwise, to obtain the stored parsed text corresponding to any input document; a text concatenation submodule, used to concatenate the parsed text corresponding to all input documents according to a preset rule to obtain the standard text content; and a document fingerprint set update submodule, used to replace the original text content with the standard text content and update the current document fingerprint set with the document fingerprints corresponding to all input documents.

[0017] Further optionally, the parsed text determination submodule includes: a first parsing unit, used to call a PDF parsing library to extract the text and paragraph structure of any input document as a portable document format file, to obtain parsed text; a second parsing unit, used to call a document parsing component to extract the main text content and structured elements as a word processing document file, to obtain parsed text; a third parsing unit, used to perform encoding detection and fault-tolerant decoding and read the text content as a parsed text file as a plain text file; and a fourth parsing unit, used to retrieve the document main text through the application programming interface of the corresponding platform as an input document link, to obtain parsed text.

[0018] Optionally, the parsing text determination submodule further includes: an access token determination unit, used to read access tokens in the local cache and identify the expiration time of the access tokens; a first data retrieval unit, used to calculate the remaining valid duration based on the current time and the expiration time, and when the remaining valid duration is greater than a preset time threshold, to use the access token to call the application programming interface (API); and a second data retrieval unit, used to make a refresh request using a refresh token in the local cache when the remaining valid duration is not greater than the preset time threshold, and if the refresh request is successful, to obtain the latest access token and the latest refresh token, and to use the latest access token to call the API; otherwise, to use an application-level token or a tenant-level token to call the API.

[0019] The above technical solution has the following beneficial effects: By maintaining an independent context document for each session, document isolation between different test tasks is achieved, solving the problem of interference between conversations; by normalizing the format of all user-uploaded documents, the access point for attachments, links, and multi-format documents is unified, improving the efficiency of document processing; by determining whether the input document already exists in the current session, the original text content is directly reused when all documents already exist, avoiding repeated parsing of the same document in continuous follow-up queries, reducing computational resource consumption and response latency; when a new document is added, the original text content is replaced entirely with standard text instead of being appended, eliminating context pollution caused by the continuous accumulation of historical documents and ensuring that the model always generates test cases based on the latest requirements. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart of the session-level document context replacement injection method provided in an embodiment of the present invention; Figure 2 This is a flowchart of the input document existence determination method provided in the embodiments of the present invention; Figure 3 This is a flowchart of the context document update method provided in the embodiments of the present invention; Figure 4 This is a flowchart of the document parsing method provided in an embodiment of the present invention; Figure 5 This is a flowchart of the token determination method provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the session-level document context replacement injection system provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of the judgment module provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of the data processing module provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of the parsing file unit in the parsing text determination submodule provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of the parsing text determination submodule used to determine the token unit provided in the embodiment of the present invention.

[0022] Figure reference numerals: 100-Data acquisition module; 200-Text mapping module; 300-Judgment module; 3001-Fingerprint set acquisition submodule; 3002-Hash calculation submodule; 3003-Judgment submodule; 400-Data processing module; 4001-Text parsing and determination submodule; 4002-Text concatenation submodule; 40021-First parsing unit; 40022-Second parsing unit; 40023-Third parsing unit; 40024-Fourth parsing unit; 40025-Access token determination unit; 40026-First data retrieval unit; 40027-Second data retrieval unit; 4003-Document fingerprint set update submodule. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] To address the problems of scattered document entry points, multi-turn dialogue context pollution, duplicate document parsing, and inter-dialogue interference in existing technologies, embodiments of the present invention provide a session-level document context replacement injection method. Figure 1 This is a flowchart of the session-level document context replacement injection method provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes: S1. Obtain the input content of the current dialogue and identify the corresponding session identifier, and standardize the input document in the input content.

[0025] A session refers to the complete interaction process between a user and the system from the first interaction until the user exits or the timeout period ends. It consists of one or more consecutive interaction rounds (i.e., "dialogues"), and each session has a globally unique session identifier.

[0026] A dialogue refers to a single interactive process in which a user sends a message (which may include document attachments or links) to the system in a single request and receives a response from the system.

[0027] When a user interacts with the large language model-driven test case generation system through a front-end interface (such as a webpage, desktop application, or mobile application), this embodiment first receives the input content submitted by the user in this round of dialogue. The input content includes at least the text message entered by the user and an optional input document (document attachment or document link).

[0028] In practical applications, the present invention allows users to upload a complete set of documents (including requirement documents and their related attachments) required for the current test task in each round of dialogue, and performs replacement updates based on this complete set.

[0029] Each independent session corresponds to a globally unique session identifier. This session identifier can be generated by the frontend and sent to the backend when the user first opens the dialog window, or it can be generated by the backend and returned to the frontend when it first receives a request. All subsequent requests belonging to the same session carry this identifier. In practice, the session identifier is usually passed as a custom field in the HTTP request header (such as X-Session-Id) or as a parameter in the request body. The frontend automatically appends the session identifier corresponding to the current dialog window to the request each time it sends user input.

[0030] Upon receiving a request, the backend first parses the request data, extracting two key pieces of information: first, the user's input content for this round of dialogue (including text, attachment identifiers, links, etc.); and second, the session identifier carried in the request. If the request does not provide a session identifier (e.g., the first dialogue of a new session), the backend generates a new unique session identifier and initializes the data structure corresponding to that session in memory or a distributed cache.

[0031] In addition, the front-end uniformly receives various input documents submitted by users, performs type identification on each input document (distinguishing between document types, image types, etc.) and performs preliminary checks for duplicate uploads. For document attachments such as PDFs, Word documents, and plain text, they are encapsulated into uniform file data blocks; for image files, they are encapsulated into image data blocks. When sending user messages, the front-end carries the encapsulated data blocks as attachment parameters, and simultaneously scans the user's input text message, extracting the identified document links (such as Lark document links, direct PDF links, etc.) and carrying them as document link parameters.

[0032] Upon receiving a request, the backend applies the same processing strategy to all standardized input documents, no longer distinguishing between documents uploaded locally and those linked online, thus achieving unified normalization of the input channels. After this process, documents from all sources are converted into a standardized list of input documents.

[0033] S2. Determine the corresponding context document based on the session identifier. The context document includes the original text content.

[0034] Based on the session identifier, the context document corresponding to the current session is searched and determined in a pre-established mapping table. The mapping table uses the session identifier as the key and the document context object as the value. The document context object contains at least one document text content that is currently in effect in the session, i.e., the original text content. This original text content records the standardized document text that has been processed in the previous round (or initial) of the current session, and is used for replacement or reuse operations when there is new document input in the current round.

[0035] When a session is first established (i.e., when there is no entry for the session identifier in the mapping table), an empty document context object is created, in which the original text content is initialized to an empty string. Thereafter, each subsequent conversation request for the same session is retrieved directly from the mapping table using the session identifier, thus obtaining the current original text content of that session.

[0036] S3. Extract the input documents from the input content and determine whether each input document already exists in the context document.

[0037] Check if any new input documents are added to the message. Specifically, check if the attachment parameter contains an input document of type document attachment. If it exists, extract the document and mark it as a document to be parsed. Check if the document link parameter contains an input document of type document link. If it exists and the link is valid, extract the link and mark it as a link to be parsed.

[0038] If no input document is extracted during this extraction process, the raw text content will be directly processed by the large language model to obtain the processing results (such as test cases and test analysis results).

[0039] If at least one input document is extracted, it is necessary to determine whether each input document already exists in the context documents of the current session. This determination is based on comparing the unique identifiers of the input document with those of documents already stored in the context documents.

[0040] Specifically, the context document maintains an existing set of document identifiers (e.g., unique values ​​generated based on document content or metadata). For each input document, a corresponding unique identifier is generated and matched against this set. If a match is successful, it is determined that the input document already exists in the context document; if a match fails, it is determined that the document does not exist (i.e., a new document is added).

[0041] S4. When at least one input document does not exist in the context document, generate standard text content based on all input documents, replace the original text content with the standard text content, and process the standard text content using a large language model to obtain the processing result; otherwise, process the original text content using a large language model to obtain the processing result.

[0042] If all input documents in this round already exist in the context document, then the original text content in the context document is directly reused and input into the large language model to obtain the processing result.

[0043] If at least one input document does not exist in the context document (i.e., a new document exists), then standard text content is generated based on all the input documents in this round, and the original text content in the context document is replaced with this standard text content. Finally, the replaced standard text content is sent to the large language model for processing.

[0044] After updating the document context, the document text content of the current session needs to be passed to the large language model in an appropriate manner. Specifically, system prompt injection is used to embed the document content into the system prompt called by the model, rather than directly concatenating it into the user message, thereby ensuring the continued visibility of the document context in multi-turn dialogues.

[0045] If the current session's text content is not empty (i.e., the user has uploaded at least one valid document), insert a document context paragraph at the specified location indicated by the system, following the preset template. This paragraph is typically marked with a specific tag (such as...).<document_context> ...< / document_context> The system prompts the user to input text messages, including prompts such as "Please generate test cases based on the following document content" or "Refer to the above requirements document to answer the questions." If the document text content is empty (the user has never uploaded a document), no document-related paragraphs will be inserted into the system prompts, and the model will infer based solely on the text messages entered by the user.

[0046] After constructing a complete system prompt, it is used together with the text message entered by the user in this round (which may include questions, supplementary explanations, etc.) as input to the large language model, and the model interface is called for inference. When generating test cases, test analysis results, or other responses, the model will first refer to the document context injected in the system prompt (if it exists).

[0047] As an optional implementation method, Figure 2 This is a flowchart of the input document existence determination method provided in the embodiments of the present invention, such as... Figure 2 As shown, determining whether each input document already exists in the context document includes: S301. Obtain the current document fingerprint set corresponding to the context document.

[0048] Retrieves the set of document fingerprints stored in the current session. This set of document fingerprints records the content hash value (e.g., a string calculated using MD5, SHA-1, or SHA-256 algorithms) of each parsed document in the current session, used to uniquely identify the content of a document.

[0049] The fingerprint set is empty during session initialization; each time a new document is successfully parsed, the fingerprint of the newly parsed document is added to the set.

[0050] S302. For any input document, calculate the hash value of any input document as the document fingerprint.

[0051] For each input document, its corresponding hash value is calculated as the document's unique fingerprint.

[0052] The hash value is obtained by applying a one-way hash algorithm (such as MD5, SHA-256, etc.) to the binary content of the document (for file attachments) or the link address string (for online document links).

[0053] Specifically, for files uploaded as attachments, all binary data of the file is read and a hash value is calculated; for online documents passed in via link parameters, the hash value is calculated using the link address string (which can be combined with the document's metadata or content if necessary), and the calculated hash value is used as the document fingerprint of the input document.

[0054] S303. Check if the document fingerprint exists in the current document fingerprint set. If it does, determine that any input document already exists in the context document; otherwise, determine that any input document does not exist in the context document.

[0055] After calculating the document fingerprint of the input document, the document fingerprint is compared with each fingerprint in the current document fingerprint set.

[0056] If a matching fingerprint exists in the set, the input document is considered to already exist in the context document of the current session, meaning that the document has been previously uploaded and parsed, and its text content is stored in the context document for reuse. If no matching fingerprint exists in the set, the input document is considered not to exist in the context document, meaning that the document is a newly added document in this round and requires subsequent parsing and content updates.

[0057] As an optional implementation method, Figure 3 This is a flowchart of the context document update method provided in an embodiment of the present invention, such as... Figure 3 As shown, standard text content is generated based on all input documents, and the original text content is replaced with the standard text content, including: S401. For any input document, if the document fingerprint of any input document does not exist in the current document fingerprint set, then parse the input document to obtain the parsed text and store it; otherwise, obtain the parsed text corresponding to any input document that has been stored.

[0058] Iterate through each input document in this round, and determine how to obtain its text content based on whether its fingerprint already exists in the current document fingerprint set: if the fingerprint does not exist (i.e., a new document is added), perform parsing operations on the document (extract text according to document type, preserve paragraph structure, etc.) to obtain the parsed text, associate the parsed text with the document fingerprint, and save it to the corresponding file pool for reuse in this and subsequent rounds; if the fingerprint already exists (i.e., a document that has already been processed), directly read the stored parsed text corresponding to the fingerprint from the file pool, without needing to parse it again.

[0059] S402. Concatenate the parsed text corresponding to all input documents according to preset rules to obtain standard text content.

[0060] After obtaining the parsed text corresponding to each input document in this round (whether obtained by parsing newly added documents or by reusing stored document content from context documents), these parsed texts are merged into a complete string according to the preset concatenation rules, which serves as the final standard text content for this round.

[0061] The preset rules include, but are not limited to: concatenating documents in the order they were uploaded by the user; specifying that attachments come first and links come later if both are included; or following document type or lexicographical order of document names. During concatenation, explicit delimiters (such as line breaks, page breaks, or document title marks) can be inserted between each segment of parsed text so that the large language model can distinguish the boundaries between different documents during subsequent processing. Through this concatenation operation, the content of multiple previously scattered documents is integrated into a clearly structured and continuous standard text.

[0062] S403. Replace the original text content with standard text content, and update the current document fingerprint set with the document fingerprints corresponding to all input documents.

[0063] After obtaining the standard text content for this round, it is directly assigned to the document text content field in the current session context document, overwriting the original text content. This replacement operation is a complete overwrite, rather than adding or modifying paragraphs on top of the original content, thus ensuring that the context document always saves only the complete document set expected by the user in the latest round.

[0064] While replacing the original text content, the document fingerprints of all input documents in this round are combined into a new document fingerprint set, and the fingerprint set corresponding to the original text content is replaced with the new document fingerprint set.

[0065] As an optional implementation method, Figure 4 This is a flowchart of the document parsing method provided in an embodiment of the present invention, such as... Figure 4 As shown, any input document is parsed to obtain the parsed text, including: S4021. When any input document is a portable document format file, call the PDF parsing library to extract the text and paragraph structure to obtain the parsed text.

[0066] When the input document is a PDF file, the system calls an existing PDF parsing library (such as PyPDF2, PDFium, or Adobe PDF Extract API) to process the file. The parsing library reads the file content page by page according to the PDF's internal object model, extracts the text information, and simultaneously identifies paragraph boundaries (e.g., dividing paragraphs by text coordinates, line breaks, indentation, and other features), ultimately outputting plain text carrying paragraph structure information.

[0067] S4022. When the input document is a text processing document file, call the document parsing component to extract the main text content and structured elements to obtain the parsed text.

[0068] When the input document is a word processing file (such as a Microsoft Word .docx or .doc file), the appropriate document parsing component (such as Apache POI, python-docx, or a commercial library) is invoked to parse the file. The parsing component reads the document's underlying XML structure or binary stream, extracts the main text, and identifies and preserves structured elements, including paragraphs, heading levels, list items, tables (preserving row and column relationships), image captions, etc. For tables, the parsing component reads the cell content row by row and organizes it into text using delimiters (such as tabs or spaces); for lists, it preserves the numbering or bullet points.

[0069] S4023. When the input document is a plain text file, the text content is read after encoding detection and fault-tolerant decoding to obtain the parsed text.

[0070] When the input document is a plain text file (e.g., .txt, .log, etc.), the file is first subjected to encoding detection. Since plain text files may use different character encodings (e.g., UTF-8, GBK, GB2312, ISO-8859-1, etc.), the most likely encoding type is automatically identified by analyzing the statistical characteristics of the file's byte sequence or common encoding rules.

[0071] If automatic detection fails or the file contains illegal byte sequences, a fault-tolerant decoding strategy is employed. This includes using UTF-8 encoding and ignoring undecodeable characters, or replacing abnormal bytes with alternative characters. After encoding recognition is complete, the file content is read line by line, retaining the original newline characters as paragraph separators, and finally outputting all text content as parsed text.

[0072] S4024. When the input document is an online document link, the document body is retrieved through the application programming interface of the corresponding platform to obtain the parsed text.

[0073] When the input document is an online document link (such as a Lark Wiki / Doc link, a direct PDF link, etc.), the system identifies the corresponding open platform (such as Lark, DingTalk, WeChat Work, etc.) based on the link type and retrieves the original text content of the document through the application programming interface (API) provided by that platform.

[0074] Specifically, the platform type is first determined based on the linked domain name. Then, a pre-configured or dynamically obtained access credential (such as an Access Token) is used to call the platform's document retrieval interface. For Lark Docs, the interface for retrieving plain text content can be called; for direct PDF links, the PDF file is first downloaded via HTTP, and then the PDF parsing process is invoked. The content returned by the interface is usually in a rich text format (such as Markdown, HTML, or JSON structure), which is then converted into standardized plain text, while preserving basic structural information such as headings, paragraphs, and lists as much as possible.

[0075] As an optional implementation method, Figure 5 This is a flowchart of the token determination method provided in an embodiment of the present invention, such as... Figure 5 As shown, before retrieving the document body through the corresponding platform's application programming interface (API), the following steps are included: S4025. Read the access token in the local cache and identify the expiration time of the access token.

[0076] Before fetching the online document body via the application programming interface (API), attempt to read the access token used to access the platform's API from a local cache (such as a memory cache, Redis, or a local file). This access token is a temporary credential issued by the platform to the application to prove that the caller has permission to access a specific user's document. Simultaneously, read the expiration time (expires_in or expires_at) associated with the token to determine if the token is still valid.

[0077] S4026. Calculate the remaining valid duration based on the current time and the expiration time. When the remaining valid duration exceeds the preset time threshold, use an access token to call the application interface.

[0078] After obtaining the locally cached access token and its expiration time, the remaining validity period of the token (i.e., expiration time minus the current time) is calculated based on the current time. A preset time threshold (e.g., 5 minutes) is used to allow sufficient lead time to prevent the token from expiring during the API call. If the calculated remaining validity period is greater than the preset threshold, the token is considered to be within its safe validity period, and the access token is used directly to call the application interface to retrieve the online document content.

[0079] S4027. When the remaining valid duration is not greater than the preset time threshold, a refresh request is made using the refresh token in the local cache. If the refresh request is successful, the latest access token and the latest refresh token are obtained, and the application interface is called using the latest access token; otherwise, the application interface is called using the application-level token or the tenant-level token.

[0080] If the remaining valid duration is less than or equal to a preset time threshold (e.g., 5 minutes), the currently cached access token is about to expire or has already become invalid, and the credential needs to be actively updated. In this case, a refresh token is read from the local cache. This refresh token is issued by the open platform along with the access token, has a longer validity period, and is specifically used to exchange for a new access token.

[0081] Use the refresh token to initiate a refresh request to the platform's token refresh endpoint (e.g., send a POST request with the refresh_token parameter). If the refresh request succeeds, the platform will return a new set of credentials: a new access token and a new refresh token (usually with a new expiration time). Write the newly acquired access token and refresh token to the local cache, overwriting the old token, and update the expiration time record. Then, use the newly acquired access token to call the application programming interface (API) to retrieve the online document content.

[0082] If the refresh request fails (e.g., the refresh token itself has expired, there is a network error, or the platform rejects the request), a fallback strategy will be implemented.

[0083] Specifically, attempt to make API calls using pre-configured application-level tokens (App Access Tokens) or tenant-level tokens (Tenant Access Tokens). App-level tokens typically have lower permissions but are suitable for reading only public documents or the application's own resources; tenant-level tokens represent authorization for the entire tenant and can access shared documents within the tenant. Try these downgraded tokens in order of priority. If successful, continue fetching documents; if all fail, log errors and return a clear error message to the user (e.g., "Online document access authorization has expired, please re-authorize"). Throughout the refresh and downgrade process, the document processing flow of the current session is not interrupted, and existing document contexts remain unchanged, only affected when fetching online documents.

[0084] This invention also provides a session-level document context replacement injection system. Figure 6 This is a schematic diagram of the structure of the session-level document context replacement injection system provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the system includes: The data acquisition module 100 is used to acquire the input content of the current round of dialogue, identify the session identifier corresponding to the current round of dialogue, and standardize the input document in the input content.

[0085] A session refers to the complete interaction process between a user and the system from the first interaction until the user exits or the timeout period ends. It consists of one or more consecutive interaction rounds (i.e., "dialogues"), and each session has a globally unique session identifier.

[0086] A dialogue refers to a single interactive process in which a user sends a message (which may include document attachments or links) to the system in a single request and receives a response from the system.

[0087] When a user interacts with the large language model-driven test case generation system through a front-end interface (such as a webpage, desktop application, or mobile application), this embodiment first receives the input content submitted by the user in this round of dialogue. The input content includes at least the text message entered by the user and an optional input document (document attachment or document link).

[0088] In practical applications, the present invention allows users to upload a complete set of documents (including requirement documents and their related attachments) required for the current test task in each round of dialogue, and performs replacement updates based on this complete set.

[0089] Each independent session corresponds to a globally unique session identifier. This session identifier can be generated by the frontend and sent to the backend when the user first opens the dialog window, or it can be generated by the backend and returned to the frontend when it first receives a request. All subsequent requests belonging to the same session carry this identifier. In practice, the session identifier is usually passed as a custom field in the HTTP request header (such as X-Session-Id) or as a parameter in the request body. The frontend automatically appends the session identifier corresponding to the current dialog window to the request each time it sends user input.

[0090] Upon receiving a request, the backend first parses the request data, extracting two key pieces of information: first, the user's input content for this round of dialogue (including text, attachment identifiers, links, etc.); and second, the session identifier carried in the request. If the request does not provide a session identifier (e.g., the first dialogue of a new session), the backend generates a new unique session identifier and initializes the data structure corresponding to that session in memory or a distributed cache.

[0091] In addition, the front-end uniformly receives various input documents submitted by users, performs type identification on each input document (distinguishing between document types, image types, etc.) and performs preliminary checks for duplicate uploads. For document attachments such as PDFs, Word documents, and plain text, they are encapsulated into uniform file data blocks; for image files, they are encapsulated into image data blocks. When sending user messages, the front-end carries the encapsulated data blocks as attachment parameters, and simultaneously scans the user's input text message, extracting the identified document links (such as Lark document links, direct PDF links, etc.) and carrying them as document link parameters.

[0092] Upon receiving a request, the backend applies the same processing strategy to all standardized input documents, no longer distinguishing between documents uploaded locally and those linked online, thus achieving unified normalization of the input channels. After this process, documents from all sources are converted into a standardized list of input documents.

[0093] The text mapping module 200 is used to determine the corresponding context document based on the session identifier. The context document includes the original text content.

[0094] Based on the session identifier, the context document corresponding to the current session is searched and determined in a pre-established mapping table. The mapping table uses the session identifier as the key and the document context object as the value. The document context object contains at least one document text content that is currently in effect in the session, i.e., the original text content. This original text content records the standardized document text that has been processed in the previous round (or initial) of the current session, and is used for replacement or reuse operations when there is new document input in the current round.

[0095] When a session is first established (i.e., when there is no entry for the session identifier in the mapping table), an empty document context object is created, in which the original text content is initialized to an empty string. Thereafter, each subsequent conversation request for the same session is retrieved directly from the mapping table using the session identifier, thus obtaining the current original text content of that session.

[0096] The judgment module 300 is used to extract the input document from the input content and determine whether each input document already exists in the context document.

[0097] Check if any new input documents are added to the message. Specifically, check if the attachment parameter contains an input document of type document attachment. If it exists, extract the document and mark it as a document to be parsed. Check if the document link parameter contains an input document of type document link. If it exists and the link is valid, extract the link and mark it as a link to be parsed.

[0098] If no input document is extracted during this extraction process, the raw text content will be directly processed by the large language model to obtain the processing results (such as test cases and test analysis results).

[0099] If at least one input document is extracted, it is necessary to determine whether each input document already exists in the context documents of the current session. This determination is based on comparing the unique identifiers of the input document with those of documents already stored in the context documents.

[0100] Specifically, the context document maintains an existing set of document identifiers (e.g., unique values ​​generated based on document content or metadata). For each input document, a corresponding unique identifier is generated and matched against this set. If a match is successful, it is determined that the input document already exists in the context document; if a match fails, it is determined that the document does not exist (i.e., a new document is added).

[0101] The data processing module 400 is used to generate standard text content based on all input documents when at least one input document does not exist in the context document, and replace the original text content with the standard text content, and process the standard text content using a large language model to obtain the processing result; otherwise, it processes the original text content using a large language model to obtain the processing result.

[0102] If all input documents in this round already exist in the context document, then the original text content in the context document is directly reused and input into the large language model to obtain the processing result.

[0103] If at least one input document does not exist in the context document (i.e., a new document exists), then standard text content is generated based on all the input documents in this round, and the original text content in the context document is replaced with this standard text content. Finally, the replaced standard text content is sent to the large language model for processing.

[0104] After updating the document context, the document text content of the current session needs to be passed to the large language model in an appropriate manner. Specifically, system prompt injection is used to embed the document content into the system prompt called by the model, rather than directly concatenating it into the user message, thereby ensuring the continued visibility of the document context in multi-turn dialogues.

[0105] If the current session's text content is not empty (i.e., the user has uploaded at least one valid document), insert a document context paragraph at the specified location indicated by the system, following the preset template. This paragraph is typically marked with a specific tag (such as...).<document_context> ...< / document_context> The system prompts the user to input text messages, including prompts such as "Please generate test cases based on the following document content" or "Refer to the above requirements document to answer the questions." If the document text content is empty (the user has never uploaded a document), no document-related paragraphs will be inserted into the system prompts, and the model will infer based solely on the text messages entered by the user.

[0106] After constructing a complete system prompt, it is used together with the text message entered by the user in this round (which may include questions, supplementary explanations, etc.) as input to the large language model, and the model interface is called for inference. When generating test cases, test analysis results, or other responses, the model will first refer to the document context injected in the system prompt (if it exists).

[0107] As an optional implementation method, Figure 7 This is a schematic diagram of the structure of the judgment module provided in an embodiment of the present invention, as shown below. Figure 7 As shown, the judgment module 300 includes: The fingerprint set acquisition submodule 3001 is used to obtain the fingerprint set of the current document corresponding to the context document.

[0108] Retrieves the set of document fingerprints stored in the current session. This set of document fingerprints records the content hash value (e.g., a string calculated using MD5, SHA-1, or SHA-256 algorithms) of each parsed document in the current session, used to uniquely identify the content of a document.

[0109] The fingerprint set is empty during session initialization; each time a new document is successfully parsed, the fingerprint of the newly parsed document is added to the set.

[0110] The hash calculation submodule 3002 is used to calculate the hash value of any input document as a document fingerprint for any given input document.

[0111] For each input document, its corresponding hash value is calculated as the document's unique fingerprint.

[0112] The hash value is obtained by applying a one-way hash algorithm (such as MD5, SHA-256, etc.) to the binary content of the document (for file attachments) or the link address string (for online document links).

[0113] Specifically, for files uploaded as attachments, all binary data of the file is read and a hash value is calculated; for online documents passed in via link parameters, the hash value is calculated using the link address string (which can be combined with the document's metadata or content if necessary), and the calculated hash value is used as the document fingerprint of the input document.

[0114] The judgment submodule 3003 is used to compare whether the document fingerprint exists in the current document fingerprint set. If it does, it is determined that any input document already exists in the context document; otherwise, it is determined that any input document does not exist in the context document.

[0115] After calculating the document fingerprint of the input document, the document fingerprint is compared with each fingerprint in the current document fingerprint set.

[0116] If a matching fingerprint exists in the set, the input document is considered to already exist in the context document of the current session, meaning that the document has been previously uploaded and parsed, and its text content is stored in the context document for reuse. If no matching fingerprint exists in the set, the input document is considered not to exist in the context document, meaning that the document is a newly added document in this round and requires subsequent parsing and content updates.

[0117] As an optional implementation method, Figure 8 This is a schematic diagram of the structure of the data processing module provided in an embodiment of the present invention, as shown below. Figure 8 As shown, the data processing module 400 includes: The parsing text determination submodule 4001 is used to parse any input document if the document fingerprint of any input document does not exist in the current document fingerprint set, thereby obtaining and storing the parsed text; otherwise, it retrieves the stored parsed text corresponding to any input document.

[0118] Iterate through each input document in this round, and determine how to obtain its text content based on whether its fingerprint already exists in the current document fingerprint set: if the fingerprint does not exist (i.e., a new document is added), perform parsing operations on the document (extract text according to document type, preserve paragraph structure, etc.) to obtain the parsed text, associate the parsed text with the document fingerprint, and save it to the corresponding file pool for reuse in this and subsequent rounds; if the fingerprint already exists (i.e., a document that has already been processed), directly read the stored parsed text corresponding to the fingerprint from the file pool, without needing to parse it again.

[0119] The text concatenation submodule 4002 is used to concatenate the parsed text corresponding to all input documents according to preset rules to obtain standard text content.

[0120] After obtaining the parsed text corresponding to each input document in this round (whether obtained by parsing newly added documents or by reusing stored document content from context documents), these parsed texts are merged into a complete string according to the preset concatenation rules, which serves as the final standard text content for this round.

[0121] The preset rules include, but are not limited to: concatenating documents in the order they were uploaded by the user; specifying that attachments come first and links come later if both are included; or following document type or lexicographical order of document names. During concatenation, explicit delimiters (such as line breaks, page breaks, or document title marks) can be inserted between each segment of parsed text so that the large language model can distinguish the boundaries between different documents during subsequent processing. Through this concatenation operation, the content of multiple previously scattered documents is integrated into a clearly structured and continuous standard text.

[0122] The document fingerprint set update submodule 4003 is used to replace the original text content with standard text content and update the current document fingerprint set with the document fingerprints corresponding to all input documents.

[0123] After obtaining the standard text content for this round, it is directly assigned to the document text content field in the current session context document, overwriting the original text content. This replacement operation is a complete overwrite, rather than adding or modifying paragraphs on top of the original content, thus ensuring that the context document always saves only the complete document set expected by the user in the latest round.

[0124] While replacing the original text content, the document fingerprints of all input documents in this round are combined into a new document fingerprint set, and the fingerprint set corresponding to the original text content is replaced with the new document fingerprint set.

[0125] As an optional implementation method, Figure 9 This is a schematic diagram of the structure of the parsing file unit in the parsing text determination submodule provided in an embodiment of the present invention, as shown below. Figure 9 As shown, the text parsing and determination submodule 4002 includes: The first parsing unit 40021 is used to call the PDF parsing library to extract the text and paragraph structure of any input document as a portable document format file, and obtain the parsed text.

[0126] When the input document is a PDF file, the system calls an existing PDF parsing library (such as PyPDF2, PDFium, or Adobe PDF Extract API) to process the file. The parsing library reads the file content page by page according to the PDF's internal object model, extracts the text information, and simultaneously identifies paragraph boundaries (e.g., dividing paragraphs by text coordinates, line breaks, indentation, and other features), ultimately outputting plain text carrying paragraph structure information.

[0127] The second parsing unit 40022 is used to call the document parsing component to extract the main text content and structured elements when the input document is a text processing document file, so as to obtain the parsed text.

[0128] When the input document is a word processing file (such as a Microsoft Word .docx or .doc file), the appropriate document parsing component (such as Apache POI, python-docx, or a commercial library) is invoked to parse the file. The parsing component reads the document's underlying XML structure or binary stream, extracts the main text, and identifies and preserves structured elements, including paragraphs, heading levels, list items, tables (preserving row and column relationships), image captions, etc. For tables, the parsing component reads the cell content row by row and organizes it into text using delimiters (such as tabs or spaces); for lists, it preserves the numbering or bullet points.

[0129] The third parsing unit 40023 is used to perform encoding detection and fault-tolerant decoding on the input document as a plain text file, and then read the text content to obtain the parsed text.

[0130] When the input document is a plain text file (e.g., .txt, .log, etc.), the file is first subjected to encoding detection. Since plain text files may use different character encodings (e.g., UTF-8, GBK, GB2312, ISO-8859-1, etc.), the most likely encoding type is automatically identified by analyzing the statistical characteristics of the file's byte sequence or common encoding rules.

[0131] If automatic detection fails or the file contains illegal byte sequences, a fault-tolerant decoding strategy is employed. This includes using UTF-8 encoding and ignoring undecodeable characters, or replacing abnormal bytes with alternative characters. After encoding recognition is complete, the file content is read line by line, retaining the original newline characters as paragraph separators, and finally outputting all text content as parsed text.

[0132] The fourth parsing unit 40024 is used to retrieve the document body through the application programming interface of the corresponding platform when the input document is an online document link, and obtain the parsed text.

[0133] When the input document is an online document link (such as a Lark Wiki / Doc link, a direct PDF link, etc.), the system identifies the corresponding open platform (such as Lark, DingTalk, WeChat Work, etc.) based on the link type and retrieves the original text content of the document through the application programming interface (API) provided by that platform.

[0134] Specifically, the platform type is first determined based on the linked domain name. Then, a pre-configured or dynamically obtained access credential (such as an Access Token) is used to call the platform's document retrieval interface. For Lark Docs, the interface for retrieving plain text content can be called; for direct PDF links, the PDF file is first downloaded via HTTP, and then the PDF parsing process is invoked. The content returned by the interface is usually in a rich text format (such as Markdown, HTML, or JSON structure), which is then converted into standardized plain text, while preserving basic structural information such as headings, paragraphs, and lists as much as possible.

[0135] As an optional implementation method, Figure 10 This is a schematic diagram of the structure of the parsing text determination submodule used to determine the token unit provided in the embodiment of the present invention, as shown below. Figure 10 As shown, the text parsing determination submodule 4002 also includes: The access token determination unit 40025 is used to read the access token in the local cache and identify the expiration time of the access token.

[0136] Before fetching the online document body via the application programming interface (API), attempt to read the access token used to access the platform's API from a local cache (such as a memory cache, Redis, or a local file). This access token is a temporary credential issued by the platform to the application to prove that the caller has permission to access a specific user's document. Simultaneously, read the expiration time (expires_in or expires_at) associated with the token to determine if the token is still valid.

[0137] The first data retrieval unit 40026 is used to calculate the remaining valid duration based on the current time and the expiration time. When the remaining valid duration is greater than the preset time threshold, the application interface is called using an access token.

[0138] After obtaining the locally cached access token and its expiration time, the remaining validity period of the token (i.e., expiration time minus the current time) is calculated based on the current time. A preset time threshold (e.g., 5 minutes) is used to allow sufficient lead time to prevent the token from expiring during the API call. If the calculated remaining validity period is greater than the preset threshold, the token is considered to be within its safe validity period, and the access token is used directly to call the application interface to retrieve the online document content.

[0139] The second data retrieval unit 40027 is used to make a refresh request using a refresh token in the local cache when the remaining valid duration is not greater than a preset time threshold. If the refresh request is successful, the latest access token and the latest refresh token are obtained, and the application interface is called using the latest access token; otherwise, the application interface is called using an application-level token or a tenant-level token.

[0140] If the remaining valid duration is less than or equal to a preset time threshold (e.g., 5 minutes), the currently cached access token is about to expire or has already become invalid, and the credential needs to be actively updated. In this case, a refresh token is read from the local cache. This refresh token is issued by the open platform along with the access token, has a longer validity period, and is specifically used to exchange for a new access token.

[0141] Use the refresh token to initiate a refresh request to the platform's token refresh endpoint (e.g., send a POST request with the refresh_token parameter). If the refresh request succeeds, the platform will return a new set of credentials: a new access token and a new refresh token (usually with a new expiration time). Write the newly acquired access token and refresh token to the local cache, overwriting the old token, and update the expiration time record. Then, use the newly acquired access token to call the application programming interface (API) to retrieve the online document content.

[0142] If the refresh request fails (e.g., the refresh token itself has expired, there is a network error, or the platform rejects the request), a fallback strategy will be implemented.

[0143] Specifically, attempt to make API calls using pre-configured application-level tokens (App Access Tokens) or tenant-level tokens (Tenant Access Tokens). App-level tokens typically have lower permissions but are suitable for reading only public documents or the application's own resources; tenant-level tokens represent authorization for the entire tenant and can access shared documents within the tenant. Try these downgraded tokens in order of priority. If successful, continue fetching documents; if all fail, log errors and return a clear error message to the user (e.g., "Online document access authorization has expired, please re-authorize"). Throughout the refresh and downgrade process, the document processing flow of the current session is not interrupted, and existing document contexts remain unchanged, only affected when fetching online documents.

[0144] The above technical solution has the following beneficial effects: By maintaining an independent context document for each session, document isolation between different test tasks is achieved, solving the problem of interference between conversations; by normalizing the format of all user-uploaded documents, the access point for attachments, links, and multi-format documents is unified, improving the efficiency of document processing; by determining whether the input document already exists in the current session, the original text content is directly reused when all documents already exist, avoiding repeated parsing of the same document in continuous follow-up queries, reducing computational resource consumption and response latency; when a new document is added, the original text content is replaced entirely with standard text instead of being appended, eliminating context pollution caused by the continuous accumulation of historical documents and ensuring that the model always generates test cases based on the latest requirements.

[0145] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A session-level document context replacement injection method, characterized in that, include: Obtain the input content of the current dialogue and identify the session identifier corresponding to the current dialogue, and standardize the input document in the input content; The corresponding context document is determined based on the session identifier, and the context document includes the original text content; Extract the input documents from the input content and determine whether each input document already exists in the context document; When at least one input document does not exist in the context document, standard text content is generated based on all input documents, and the original text content is replaced with the standard text content. The standard text content is then processed by a large language model to obtain the processing result. Otherwise, the original text content is processed by a large language model to obtain the processing result.

2. The session-level document context replacement injection method according to claim 1, characterized in that, The step of determining whether each input document already exists in the context document includes: Obtain the current document fingerprint set corresponding to the context document; For any input document, calculate the hash value of the input document as the document fingerprint; If the document fingerprint is found in the current document fingerprint set, then it is determined that any input document already exists in the context document; otherwise, it is determined that any input document does not exist in the context document.

3. The session-level document context replacement injection method according to claim 2, characterized in that, The step of generating standard text content based on all input documents and replacing the original text content with the standard text content includes: For any input document, if the document fingerprint of any input document does not exist in the current document fingerprint set, then the input document is parsed to obtain the parsed text and stored; otherwise, the stored parsed text corresponding to any input document is obtained. The parsed text corresponding to all input documents is concatenated according to preset rules to obtain the standard text content; The original text content is replaced with the standard text content, and the current document fingerprint set is updated with the document fingerprints corresponding to all input documents.

4. The session-level document context replacement injection method according to claim 3, characterized in that, The step of parsing any input document to obtain parsed text includes: When any of the input documents is a portable document format file, the PDF parsing library is called to extract the text and paragraph structure to obtain the parsed text; When the input document is a text processing document file, the document parsing component is invoked to extract the main text content and structured elements to obtain the parsed text; When the input document is a plain text file, the text content is read after encoding detection and fault-tolerant decoding to obtain the parsed text. When the input document is an online document link, the document body is retrieved through the application programming interface of the corresponding platform to obtain the parsed text.

5. The session-level document context replacement injection method according to claim 4, characterized in that, Before retrieving the document body via the corresponding platform's application programming interface, the following steps are included: Read the access token from the local cache and identify the expiration time of the access token; The remaining valid duration is calculated based on the current time and the expiration time. When the remaining valid duration is greater than a preset time threshold, the access token is used to call the application interface. When the remaining valid duration is not greater than the preset time threshold, a refresh request is made using the refresh token in the local cache. If the refresh request is successful, the latest access token and the latest refresh token are obtained, and the application interface is called using the latest access token; otherwise, the application interface is called using an application-level token or a tenant-level token.

6. A session-level document context replacement injection system, characterized in that, include: The data acquisition module is used to acquire the input content of the current round of dialogue, identify the session identifier corresponding to the current round of dialogue, and standardize the input document in the input content; A text mapping module is used to determine the corresponding context document based on the session identifier, wherein the context document includes the original text content; The judgment module is used to extract the input documents from the input content and determine whether each input document already exists in the context document. The data processing module is configured to generate standard text content based on all input documents when at least one input document does not exist in the context document, replace the original text content with the standard text content, and perform large language model processing on the standard text content to obtain the processing result; otherwise, perform large language model processing on the original text content to obtain the processing result.

7. The session-level document context replacement injection system according to claim 6, characterized in that, The judgment module includes: The fingerprint set acquisition submodule is used to acquire the current document fingerprint set corresponding to the context document; The hash calculation submodule is used to calculate the hash value of any input document as a document fingerprint for any given input document. The determination submodule is used to compare whether the document fingerprint exists in the current document fingerprint set. If it does, it is determined that any input document already exists in the context document; otherwise, it is determined that any input document does not exist in the context document.

8. The session-level document context replacement injection system according to claim 7, characterized in that, The data processing module includes: The parsing text determination submodule is used to, for any input document, if the document fingerprint of any input document does not exist in the current document fingerprint set, parse the input document to obtain the parsed text and store it; otherwise, obtain the stored parsed text corresponding to any input document. The text concatenation submodule is used to concatenate the parsed text corresponding to all input documents according to preset rules to obtain the standard text content. The document fingerprint set update submodule is used to replace the original text content with the standard text content, and update the current document fingerprint set with the document fingerprints corresponding to all input documents.

9. The session-level document context replacement injection system according to claim 8, characterized in that, The parsed text determination submodule includes: The first parsing unit is used to call a PDF parsing library to extract the text and paragraph structure of any input document as a portable document format file, and obtain the parsed text. The second parsing unit is used to call the document parsing component to extract the main text content and structured elements to obtain the parsed text when the input document is a text processing document file; The third parsing unit is used to perform encoding detection and fault-tolerant decoding and then read the text content to obtain the parsed text when the input document is a plain text file. The fourth parsing unit is used to retrieve the document body through the application programming interface of the corresponding platform when the input document is an online document link, and obtain the parsed text.

10. The session-level document context replacement injection system according to claim 9, characterized in that, The text parsing and determination submodule also includes: An access token determination unit is used to read the access token in the local cache and identify the expiration time of the access token; The first data retrieval unit is used to calculate the remaining valid duration based on the current time and the expiration time. When the remaining valid duration is greater than a preset time threshold, the access token is used to call the application interface. The second data retrieval unit is used to make a refresh request using a refresh token in the local cache when the remaining valid duration is not greater than the preset time threshold. If the refresh request is successful, the latest access token and the latest refresh token are obtained, and the application interface is called using the latest access token; otherwise, the application interface is called using an application-level token or a tenant-level token.

Images